神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：2026年，代码的90%已由AI接管。但这绝非“一键生成”的魔法，开发者正从代码搬运工进化为严苛的系统导演，回归设计文档与测试驱动的“硬核工程”时代。文章来自编译。

这一年，AI 编程助手彻底改变了游戏规则，但要高效地驾驭它们，仍需要技巧和体系。这些工具极大提升了 LLM 处理现实世界编程任务的能力，许多开发者（包括我自己在内）都已将其纳入麾下。

以 Anthropic 为例，工程师们对 Claude Code 的依赖程度极高，如今 Claude Code 约 90% 的代码都是由它自己编写的。然而，利用 LLM 进行编程并非“一键式”的魔法体验——它既“困难且反直觉”，想要获得出色成果，必须学习新的模式。批判性思维依然是核心。经过一年的项目实践，我总结出了一套与许多资深开发者不谋而合的工作流：将 LLM 视为一名强大的结对编程伙伴，它需要明确的指令、上下文和监督，而非让其进行自主决策。

在本文中，我将分享步入 2026 年之际，我如何利用 AI 进行规划、编码和协作，并提炼出我与社区共同积累的技巧与最佳实践。这是一种更加严谨的“AI 辅助工程”方法——在积极利用 AI 的同时，对产出的软件保持高度的责任感。

从明确的计划开始（先写规格说明，再写代码）

不要只是向 LLM 许愿——先从定义问题和规划解决方案开始。

一个常见的错误是仅凭一段模糊的提示词就直接进入代码生成阶段。在我的工作流以及许多人的实践里，第一步是与 AI 共同构思一份详细的规格说明，然后勾勒出分步计划，最后才开始编写实际代码。对于新项目，我会描述构思，让 LLM 反复向我提问，直到我们理清了所有需求和边界情况。最后，我们会将其汇编成一份详尽的 `spec.md`——其中包含需求、架构决策、数据模型，甚至测试策略。这份规格说明构成了开发的基石。

接下来，我将规格说明输入具备推理能力的模型，并提示它生成项目计划：将实现过程分解为逻辑清晰、易于消化的任务或里程碑。AI 本质上是在帮我完成一份微型“设计文档”或项目计划。我会反复迭代这个计划——进行编辑，并要求 AI 评价或优化，直到它逻辑自洽且完整。只有在这之后，我才会开始编码。这种前期投入起初可能让人觉得节奏缓慢，但回报却是巨大的。正如 Les Orchard 所言，这就像是在 15 分钟内完成了一次“瀑布流开发”——一个快速且结构化的规划阶段，能让随后的编码过程顺畅得多。

有了明确的规格说明和计划，意味着当我们开启代码生成时，人类和 LLM 都清楚地知道我们要开发什么以及为什么要这么做。简而言之，先进行规划能强制你和 AI 达成共识，防止无效循环。虽然很多人倾向于跳过这一步，但经验丰富的 LLM 开发者现在都将稳健的规格/计划视为工作流的灵魂。

将工作拆分为小型的迭代模块

范围管理至关重要——给 LLM 提供可管理的任务，而不是一次性塞给它整个代码库。

我学到的一个关键教训是避免要求 AI 生成庞大、单一的输出。相反，我们将项目拆分为迭代步骤或任务单（tickets），并逐一解决。这借鉴了良好的软件工程实践，但在 AI 参与的情况下显得尤为重要。当给出聚焦的提示词时，LLM 的表现最为出色：一次只实现一个函数、修复一个错误或添加一个功能。比方说，规划完成后，我会提示代码生成模型：“好，让我们实现计划中的第一步。”我们编写代码、测试，然后进入第二步，以此类推。每个模块都足够小，确保 AI 能在上下文窗口内处理，而你也能看懂它生成的代码。

这种方法可以防止模型“跑偏”。如果你一次性要求太多，它很可能会感到困惑，或者产出一堆难以理顺的“乱麻”。有开发者反映，当他们尝试让 LLM 生成应用的一大堆东西时，最终得到的是前后不一和重复的代码——“就像 10 个开发者在互不沟通的情况下各写各的，”其中一人这样说道。我也曾深有感触；解决办法就是停下来，退后一步，将问题拆解成更小的碎片。在每次迭代中，我们都会推送已开发内容的上下文，并循序渐进地添加。这也非常契合测试驱动开发（TDD）的方法——我们可以在开发过程中给每一部分编写或生成测试（稍后会详细介绍测试）。

现在的几种编程助手工具已经明确支持这种分块工作流。比方说，我经常生成一个结构化的“提示词计划”文件，其中包含针对每项任务的一系列提示词，这样像 Cursor 这样的工具就可以逐一执行它们。关键点在于避免跨度过大。通过小步快跑的循环，我们极大地降低了发生灾难性错误的概率，并且能够快速纠偏。LLM 擅长处理快速、封闭的任务——请善用这一优势。

提供详尽的上下文和指导

LLM 的表现取决于你提供的上下文——向它们展示相关的代码、文档和约束条件。

在处理代码库时，我会确保为 AI 提供表现出色所需的所有信息。这包括它应该修改或参考的代码、项目的技术限制，以及任何已知的坑或首选方法。现代工具可以提供帮助：比方说，Anthropic 的 Claude 在“项目（Projects）”模式下可以将整个 GitHub 仓库导入其上下文，而像 Cursor 或 Copilot 这样的 IDE 助手会自动在提示词中包含打开的文件。但我通常会做得更深入——如果我觉得模型缺乏相关信息，我会使用 Context7 之类的 MCP，或者手动将代码库的重要部分或 API 文档复制到对话中。

资深 LLM 用户非常强调这种“上下文打包”步骤。比方说，在编码前进行一次“脑力倾倒”，把模型应该知道的一切都倒出来，包括：高层目标和不变性约束、优秀方案示例，以及关于应避免的方法的警告。如果我要求 AI 实现一个棘手的方案，我可能会告诉它哪些天真的方法太慢，或者提供来自其他地方的参考实现。如果我正在使用一个冷门的库或全新的 API，我会粘贴官方文档或 README，这样 AI 就不至于盲目摸索。所有这些前置上下文都能显著提高输出质量，因为模型不再是靠猜，而是事实和约束就在眼前。

现在已经有自动化上下文打包的实用工具了。我尝试过 `gitingest` 或 `repo2txt` 之类的工具，它们本质上是将代码库的相关部分“转储”到一个文本文件中供 LLM 阅读。在处理大型项目时，这些工具简直是救星——你生成一个包含关键源文件的 `output.txt` 包，让模型摄取即可。原则是：不要让 AI 在信息不全的情况下操作。如果修复一个 bug 需要理解四个不同的模块，那就把这四个模块都给它看。诚然，我们必须留意 Token 限制，但目前的最强模型拥有庞大的上下文窗口（数万个 Token）。请明智地使用它们。我通常会有选择地只纳入与当前任务相关的代码片段，并明确告诉 AI 哪些内容超出了范围，不要关注（以节省 Token）。

我认为 Claude Skills 非常有潜力，因为它们通过将指令、脚本和特定领域的专业知识打包成模块化的能力，将原本脆弱的重复提示词转变为持久且可复用的资产。当请求与 Skill 匹配时，工具可以自动应用。这意味着与通用的提示词相比，你可以获得更可靠、更具上下文感知的结果，并从零散的交互转向以一致方式编码可重复流程和团队知识的工作流。目前已有一些社区维护的 Skills 集合，其中我最喜欢的例子之一是前端设计技能，它可以彻底终结 LLM 生成的 UI 中普遍存在的“紫色设计审美”。在更多工具正式支持 Skills 之前，暂时可以使用替代方案。

最后，通过提示词内部的注释和规则来引导 AI。在代码片段之前，我可能会说：“这是 X 的当前实现。我们需要将其扩展以实现 Y，但要注意不要破坏 Z。”这些小提示非常有帮助。LLM 是原教旨主义者——它们会遵循指令，所以请给予它们详细且具上下文的指令。通过主动提供上下文和引导，我们可以最大限度地减少幻觉和不着边际的建议，获得契合项目需求的代码。

选择合适的模型（必要时使用多个模型）

并非所有的编程 LLM 都一样——请有意识地选择工具，并且不要害怕在中途切换模型。

2025 年，各种强大的编程 LLM 让我们眼花缭乱。我工作流的一部分就是为每个任务选择最适合的模型或服务。有时候，同时尝试两个或更多 LLM 进行并行交叉检查，看看它们对同一个问题的不同处理方式，也是非常有价值的。

每个模型都有自己的“性格”。关键在于：如果一个模型卡壳了或输出不咋地，那就换一个试试。我真的曾把同样的提示词从一个聊天框复制到另一个服务，看看它是否能处理得更好。这种“模型抢座位”的游戏可以在你遇到某个模型的盲区时救你一命。

此外，确保你使用的是可用的最佳版本。如果条件允许，请使用最新的“专业版”模型——因为质量至关重要。是的，这往往意味着需要付费，但生产力的提升足以证明这笔开销是值得的。归根结底，选择那个与你“气场”相合的 AI 结对编程伙伴。我认识一些人仅仅因为喜欢某个模型回应的感觉而偏爱它。这完全合理——当你实质上是在与 AI 进行持续对话时，用户体验和语气带来的效果确实会不一样。

就我个人而言，最近我更倾向于使用 Gemini 来进行大量的编程工作，因为它的交互感觉更自然，而且通常第一次就能理解我的要求。但我会毫不犹豫地在需要时切换到其他模型；有时候，第二意见有助于找到解决方案。总之：选择最适合任务的工具，记住你的军械库里有一群 AI 待命。

整个生命周期都利用 AI 编程

在整个软件开发生命周期（SDLC）中，利用针对编程优化的 AI 助手来增强你的工作流。

在命令行端，出现了新的 AI 智能体。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 都是你可以直接在项目目录中对话的命令行工具——它们可以阅读文件、运行测试，甚至分步修复问题。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编程代理，它们实际上会将你的仓库克隆到云端虚拟机中，并在后台处理任务（编写测试、修复错误，然后为你开启 PR）。亲眼目睹这一过程有点不可思议：你发出一个指令，比如“重构 X 的支付模块”，不久后你就会收到一个包含代码更改和测试通过的拉取请求。我们真的生活在未来。

话虽如此，这些工具并非万无一失，你必须了解它们的局限性。它们加速了编程中机械化的部分——生成样板代码、应用重复性更改、自动运行测试——但它们仍然从你的引导中获益匪浅。比方说，当我使用 Claude 或 Copilot 这样的智能体来实现某些功能时，我经常会向它提供之前步骤中的计划或待办事项清单，以便它知道确切的任务序列。如果智能体支持，我会在指示其执行之前，在上下文中加载我的 `spec.md` 或 `plan.md`。这能让它保持在正确的轨道上。

我们还没到能让 AI 智能体在无人看管的情况下编写整个功能并期待完美结果的阶段。相反，我以受监督的方式使用这些工具：我会让它们生成甚至运行代码，但我会盯紧每一步，一旦发现异样就随时介入。还有像 Conductor 这样的编排工具，可以让你并行运行多个智能体处理不同任务（本质上是扩展 AI 协助的一种方式）——一些工程师正在尝试同时运行 3-4 个智能体来开发独立功能。我也尝试过这种“大规模并行”的方法；在快速完成大量工作方面，它的效果惊人，但同时监控多个 AI 线程也确实让人心累！在大多数情况下，我一次只使用一个主智能体，或许再加一个辅助智能体进行审查（下文讨论）。

请记住，这些是电动工具——扳机依然由你控制，结果也由你引导。

AI 如何改善开发者体验的全面概览

需要人的参与——验证、测试并审查一切

AI 会很乐意产出看起来很像样的代码，但你要对质量负责——务必进行彻底的审查和测试。我的基本准则之一是永远不要盲目相信 LLM 的输出。正如 Simon Willison 所言，把 LLM 结对编程伙伴看作是“过度自信且易犯错”的人。它写代码时信心满满——哪怕其中包含 bug 或废话——除非你抓住了它，否则它不会告诉你哪里出了问题。因此，我对待每一段 AI 生成的代码片段，就像对待初级开发者写的东西一样：我会阅读代码、运行它，并根据需要进行测试。你绝对必须测试它写的内容——运行单元测试，或手动调试功能，以确保它确实实现了其声称的功能。

事实上，我将测试融入了工作流本身。我早期的规划阶段通常包括为每一步生成测试列表或测试计划。如果我使用像 Claude Code 这样的工具，我会指示它在完成任务后运行测试套件，并让它在失败时进行调试。只要测试存在，这种紧凑的反馈循环（写代码 → 运行测试 → 修复）就是 AI 所擅长的。毫不奇怪，那些从编程代理中获益最多的人，往往是拥有强大测试实践的人。像 Claude 这样的智能体在有了良好的测试套件作为安全网后，可以“飞速”推进项目。如果没有测试，智能体可能会盲目乐观地认为一切正常（“当然，都没问题！”），但实际上它已经搞坏了好几个地方。所以，投资测试吧——它能放大 AI 的效用和对结果的信心。

除了自动化测试，还要进行代码审查——包括人工审查和 AI 辅助审查。我会定期停下来，逐行审查目前生成的代码。有时候我会开启第二个 AI 会话（或使用不同的模型），让它评价或审查第一个 AI 产出的代码。比方说，我可能会让 Claude 编写代码，然后问 Gemini：“你能检查一下这个函数是否有误或有改进空间吗？”如此可以发现一些细微的问题。关键在于不要因为是 AI 写的代码就跳过审查。如果非要说有什么不同的话，AI 编写的代码需要额外的审查，因为它有时候可能看上去挺像那么一回事，却隐藏着人类可能不会立即察觉的缺陷。

我还使用了与上一个团队共同构建的 Chrome DevTools MCP，用于调试和质量循环，以弥合静态代码分析与浏览器实时执行之间的鸿沟。它可以“给你的智能体装上眼睛”。它让我能授予 AI 工具直接访问权限，查看浏览器所见的内容、检查 DOM、获取丰富的性能追踪、控制台日志或网络追踪。这种集成消除了手动切换上下文的摩擦，允许直接通过 LLM 进行自动化 UI 测试。这意味着可以根据实际运行数据高精度地诊断并修复 bug。

跳过人类监督的可怕后果早有记载。一位在紧急项目中严重依赖 AI 生成代码的开发者描述其结果简直是一团糟——逻辑重复、方法名不匹配、毫无架构可言。他意识到自己一直在“不停地开发”，却从未停下来审视 AI 编织出的整体。补救措施是痛苦的重构，他发誓以后再也不会让事情失控到那种地步。我对此铭记在心。无论我使用多少 AI，我依然是那个负责任的工程师。

实际上，这意味着只有在我理解了代码之后，我才会合并或发布。如果 AI 生成了晦涩难懂的内容，我会让它添加注释进行解释，或者用更简单的术语重写。如果感觉不对劲，我就深入挖掘——就像人类同事提交了触发红线的代码时我会做的那样。

这完全关乎心态：LLM 是助手，而非自主可靠的编程者。我是资深开发者；LLM 的存在是为了加速我的工作，而非取代我的判断。保持这种立场不仅能产生更好的代码，还能保护你作为开发者的成长。（我听过一些人担心过度依赖 AI 会使技能退化——我认为只要你保持参与，积极审查并理解一切，你依然在磨练直觉，只是速度更快了。）简而言之：保持警惕，经常测试，始终审查。到头来，这依然是你的代码库。

频繁提交并利用版本控制作为安全网。永远不要提交你解释不了的代码。

频繁的提交就是你的存档点——它们能让你撤销 AI 的失误并理解变更。

当与能够快速生成大量代码的 AI 合作时，事情很容易偏离轨道。我通过养成极其细致的版本控制习惯来缓解这一问题。我会尽早且频繁地提交，甚至比手动编码时还要频繁。在每个小任务完成或每次成功的自动编辑后，我都会提交一个带有清晰说明的 git commit。这样，如果 AI 的下一个建议引入了 bug 或混乱的更改，我有一个最近的检查点可以回滚（或从中择优挑选），而不会丢失数小时的工作。一位从业者将其比作把提交视为“游戏中的存档点”——如果 LLM 会话搞砸了，你总能回滚到上一个稳定的提交。我发现这个建议非常有用。当你知晓可以通过 `git reset` 撤销操作时，尝试大胆的 AI 重构所带来的压力会小得多。

良好的版本控制在与 AI 协作时也会有所帮助。由于不能指望 AI 记得它所做的一切（受限于上下文窗口等），git 历史就变成了一份宝贵的日志。我经常浏览最近的提交，向 AI（或我自己）简要说明发生了什么变化。事实上，如果你提供提交历史，LLM 自己也可以利用它——我曾将 `git diff` 或提交日志粘贴到提示词中，以便 AI 了解哪些代码是新的，或者之前的状态是什么。有趣的是，LLM 非常擅长解析 diff，并能使用 `git bisect` 之类的工具来查找 bug 是从哪里引入的。它们在遍历提交历史方面有着无限的耐心，这可以增强你的调试能力。但前提是，你得先有一个整洁的提交历史。

另一个好处是：带有良好注释的小型提交实质上记录了开发过程，这在进行代码审查（AI 或人工）时很有帮助。如果一个 AI 智能体一次性做了五处改动并导致程序崩溃，将这些改动分散在不同的提交中可以更容易地定位是哪次提交导致了问题。如果一切都塞进一个名为“AI 更改”的大规模提交里，那智能祝你好运了！因此，我约束自己：完成任务，运行测试，提交。这也与之前提到的将工作拆分为小块的技巧完美契合——每个小块最终都会成为一个独立的提交或 PR。

最后，不要害怕使用分支或 `worktrees` 来隔离 AI 实验。我采用的一种高级工作流（受 Jesse Vincent 等人的启发）是为新功能或子项目创建一个全新的 git `worktree`。这让我可以在同一个仓库中并行运行多个 AI 编程会话而互不干扰，稍后再合并更改。这有点像让每个 AI 任务都在自己的沙盒分支中运行。如果一个实验失败了，我就扔掉那个 `worktree`，主分支毫发无伤。如果成功了，我就将其合并。这种方法在我让一个 AI 实现功能 A，同时我自己（或另一个 AI）处理功能 B 时至关重要。版本控制让这种协调成为可能。总之：频繁提交，用分支组织工作，并拥抱 git 作为控制机制，使 AI 生成的变更可管理、可逆。

通过规则和示例定制 AI 的行为

通过提供风格指南、示例甚至“规则文件”来引导你的 AI 助手——少量的前期调优就能换来更优质的输出。

我学到的一点是，你不必接受 AI 默认的风格或方法——你可以通过提供准则来深度影响它。比方说，我有一个定期更新的 `CLAUDE.md` 文件，其中包含让 Claude（Anthropic 的模型）遵循的过程规则和偏好（使用 Gemini CLI 时也有类似的 `GEMINI.md`）。这包括诸如“按我们项目的风格写代码、遵循我们的 lint 规则、不要使用某些函数、偏好函数式风格而非 OOP”等内容。开始会话时，我会将此文件提供给 Claude，使其与我们的规范保持一致。正如 Jesse Vincent 所指出的，这种方法在保持模型“不跑偏”方面效果惊人——它减少了 AI 自作主张或引入我们不想要的模式的倾向。

即使没有花哨的规则文件，你也可以通过自定义指令或系统提示词来定下基调。GitHub Copilot 和 Cursor 都推出了允许你为项目全局配置 AI 行为的功能。我利用了这一点，写了一段简短的关于我们编码风格的文字，比方说：“使用 4 空格缩进，在 React 中避免使用箭头函数，偏好描述性的变量名，代码应通过 ESLint。”有了这些指令， AI 的建议会更接近人类队友的写法。Ben Congdon 提到他很惊讶竟然很少有人使用 Copilot 的自定义指令，毕竟它们非常有效——他只需在前期提供一些示例和偏好，就能引导 AI 输出符合团队惯用语的代码。我也深有同感：花点时间教 AI 你的预期。

另一种强大的技术是提供你想要的输出格式或方法的内联示例格式。如果我想让 AI 以非常特定的方式编写函数，我可能会先向它展示代码库中已有的类似函数：“这是我们实现 X 的方式，请对 Y 使用类似的方法。”如果我想要某种注释风格，我可能会自己写一段注释并要求 AI 继续沿用该风格。本质上，这是在为模型提供可遵循的模式。LLM 非常擅长模仿——给它们展示一两个例子，它们就会顺着这个路子走下去。

社区还想出了一些创造性的“规则集”来驯服 LLM 的行为。你可能听说过“Big Daddy”规则，或者在提示词中加入“禁止幻觉/禁止欺骗”条款。这些基本上是提醒 AI 保持诚实、不要凭空捏造不存在的代码的小技巧。比方说，我有时会在提示词前加上：“如果你对某事不确定或缺少代码库上下文，请请求澄清，而不是编造答案。”这减少了幻觉。我使用的另一条规则是：“在修复 bug 时，务必在注释中简要说明你的推理。”这样，当 AI 生成修复方案时，它还会留下一条类似“// 修复：将 X 改为 Y 以防止 Z（按照规格说明）”的注释。这对后续审查非常有用。

总之，不要把 AI 当作黑盒——去调优它。通过配置系统指令、分享项目文档或写下明确的规则，你可以将 AI 变成团队中更专业的开发者。这就像新员工入职一样：你会给他们风格指南和一些入门提示，对吧？对你的 AI 结对编程伙伴也这样做。投资回报率是巨大的：你会得到更少需要微调、能更顺畅集成到代码库中的产出。

拥抱测试与自动化，将其作为力量倍增器

利用你的 CI/CD、Linter 和代码审查机器人——AI 在能够自动捕捉错误的环境中表现最佳。

这是保持在环并提供上下文的必然结果：运行良好的开发流水线能提高 AI 的生产力。我会确保在使用重度 AI 编程的任何仓库中都有稳健的持续集成（CI）设置。这意味着每次提交或 PR 都会运行自动化测试，强制执行代码风格检查（如 ESLint、Prettier 等），理想情况下，任何新分支都有可用的暂存环境。为什么？因为我可以让 AI 触发这些并评估结果。比方说，如果 AI 通过 Jules 或 GitHub Copilot Agent 等工具开启了一个拉取请求，我们的 CI 会运行测试并报告失败。我可以将失败日志反馈给 AI：“集成测试因 XYZ 失败，让我们调试一下。”这把修复 bug 变成了一个带有快速反馈的协作循环，而 AI 非常擅长处理这类任务（它们建议修复，我们再次运行 CI，然后迭代）。

自动化代码质量检查（Linter、类型检查器）也能引导 AI。我有时甚至会在提示词中包含 Linter 的输出识别。如果 AI 写的代码没能通过我们的 Linter，我会将错误信息复制到对话中并说“请解决这些问题”。模型随后就会确切知道该怎么做。这就像有一个严厉的老师在 AI 肩后盯着。根据我的经验，一旦 AI 意识到某个工具的输出（如失败的测试或 lint 警告），它会非常努力地去修正——毕竟，它“想要”产出正确答案。这又回到了提供上下文：给予 AI 它在环境中所做操作的结果（测试失败等），它会从中学习。

AI 编程代理本身也越来越多地加入自动化钩子。有些代理在所有测试通过之前会拒绝将代码任务标记为“完成”，这正是你想要的严谨性。代码审查机器人（无论是否基于 AI）充当了另一层过滤器——我将它们的反馈视为改进的额外提示。比方说，如果 CodeRabbit 或其他审查者评论“这个函数正在执行 X，这不太理想”，我会问 AI：“你能根据这个反馈进行重构吗？”

通过将 AI 与自动化相结合，你开始进入一个良性循环。AI 编写代码，自动化工具捕捉问题，AI 进行修复，如此循环往复，而你负责监督高层方向。这种感觉就像拥有一个速度极快、其工作被不知疲倦的 QA 工程师即时检查的初级开发人员。但请记住，那个环境是由你搭建的。如果你的项目缺乏测试或任何自动化检查，AI 的工作可能会带着细微的 bug 或低劣的质量混过关，直到很久以后才暴露。

因此，随着我们迈入 2026 年，我的目标之一是加强围绕 AI 代码贡献的质量门槛：更多的测试、更多的监控，甚至可能是“AI 对 AI”的代码审查。这听起来可能有些矛盾（AI 审查 AI），但我确实见过它发现一个模型遗漏的情况。底线是：对 AI 友好的工作流必须拥有强大的自动化——利用这些工具让 AI 保持诚实。

持续学习与适应（AI 放大你的技能）

将每一次 AI 编程会话都视为学习机会——你懂的越多，AI 能帮你的就越多，从而形成良性循环。

在开发中使用 LLM 最令人兴奋的方面之一，就是我在过程中学到了很多东西。AI 并没有取代我对知识的需求，反而让我接触到了许多如果靠自己可能永远不会尝试的新语言、框架和技术。

这种模式具有普遍性：如果你带着扎实的软件工程基础来到桌前，AI 会让你的生产力倍增。如果你缺乏这种基础，AI 可能只会放大困惑。经验丰富的开发者观察到，LLM 会“奖赏现有的最佳实践”——编写清晰的规格、拥有良好的测试、进行代码审查等，在 AI 参与时都会变得更加强大。在我的经验中，AI 让我能在更高的抽象层次上操作（专注于设计、接口、架构），而它则负责产出样板代码，但我首先需要具备这些高阶技能。正如 Simon Willison 所指出，几乎所有让人成为资深工程师的要素（设计系统、管理复杂性、知道什么是自动化什么是手写）现在都是利用 AI 获得最佳结果的关键。因此，使用 AI 实际上推动了我在工程领域的进步——我对规划更加严谨，对架构更加自觉，因为我实际上是在“管理”一个速度极快但有些天真的程序员（AI）。

对于那些担心使用 AI 会退化能力的人：我认为如果做得对，情况恰恰相反。通过审查 AI 代码，我接触到了新的惯用语和方案。通过调试 AI 的错误，我加深了对语言和问题领域的理解。我经常要求 AI 解释它的代码或修复方案背后的逻辑——有点像不断就代码问题面试候选人——并从它的回答中获取见解。我还把 AI 当作研究助手：如果我不确定某个库或方法，我会让它列举选项或比较利弊。这就像有一个百科全书式的导师随时待命。所有这一切都让我成为了一个博学的程序员。

站在更高的角度来看，AI 工具放大了你的专业知识。进入 2026 年，我不怕它们“抢走我的工作”——我感到兴奋的是，它们将我从琐事中解放出来，让我能花更多时间在软件工程中富有创造力和复杂的方面。但我也意识到，对于那些没有扎实基础的人来说，AI 可能会导致“达克效应”大爆发（你可能觉得自己做出了很棒的东西，直到它土崩瓦解）。所以我的建议是：继续磨练你的手艺，并利用 AI 来加速这一过程。也要有意识地定期在没有 AI 的情况下编程，以保持原生技能的敏锐。最终，“开发者 + AI”的双人组远比其中任何一方单独行动更强大，而作为开发者的这一半必须守好自己的阵地。

结语

随着我们进入 2026 年，我已经完全将 AI 融入了我的开发工作流——但是以一种深思熟虑、专家驱动的方式融入。我的方法本质上是“AI 增强型软件工程”，而非“AI 自动化软件工程”。

我学到了：当你在 AI 协作中应用经典的软件工程纪律时，效果是最好的。事实证明，我们所有辛苦积累的实践——编码前的设计、编写测试、使用版本控制、维护标准——不仅依然适用，而且在 AI 编写你一半的代码时显得更为重要。

我对未来感到兴奋。工具在不断进步，我的工作流也必将随之进化。也许全自动的“AI 开发实习生”将处理更多的脏活累活，而我们则专注于更高层次的任务。也许会涌现出新的调试和代码探索范式。无论如何，我都打算保持在环——引导 AI、向它们学习，并负责任地放大我的生产力。

对我而言，底线是：AI 编程助手是不可思议的力量倍增器，但人类工程师始终是这场戏的导演。

既然如此……祝各位在 2026 年开发愉快！🚀

译者：boxi。