【由 ChatGPT 辅助翻译】
来源 URL：https://addyo.substack.com/p/my-llm-coding-workflow-going-into
发布时间：2025-12-18T15:30:46+00:00
AI 编码助手在今年成为了颠覆性的工具，但要真正发挥它们的威力，需要技巧与结构化的方法。 这些工具显著提升了 LLM 在真实世界编码中的能力，许多开发者（包括我自己）都积极拥抱了它们。
以 Anthropic 为例，工程师对 Claude Code 的采用程度之高，以至于 今天 Claude Code 约 90% 的代码是由 Claude Code 自己编写的。然而，将 LLM 用于编程并不是一键魔法式的体验——它“困难且不直观”，要获得优秀的结果需要学习新的模式。批判性思维依然至关重要。经过一年多的项目实践，我逐渐收敛出一种与许多资深开发者相似的工作流：把 LLM 当作一个强大的结对程序员，而不是具备自主判断力的实体——它需要清晰的指令、充分的上下文以及持续的监督。
在本文中，我将分享我在迈向 2026 时如何规划、编码并与 AI 协作，总结我个人经验以及社区集体学习中沉淀下来的技巧与最佳实践。这是一种更有纪律性的 “AI 辅助工程（AI-assisted engineering）” 方法——在积极利用 AI 的同时，依然自豪地对最终产出的软件负责。
如果你对我更多的工作流细节感兴趣，可以参考《The AI-Native Software Engineer》；若不想深入了解，我们直接进入我学到的一些经验教训。
先制定清晰的计划（先有规格说明，再写代码）
不要只是把愿望丢给 LLM ——先定义问题并规划解决方案。
一个常见的错误是，用一个含糊的提示直接让 AI 生成代码。在我的工作流（以及许多人的实践）中，第一步是与 AI 一起头脑风暴并制定一份详细的规格说明，然后在编写任何实际代码之前，先列出一个逐步的计划。对于一个新项目，我会描述想法，并让 LLM 不断向我提问，直到我们把需求和边界情况都理清。最终，我们会将这些内容整理成一份完整的 spec.md，其中包含需求、架构决策、数据模型，甚至测试策略。这份规格说明构成了开发的基础。
接下来，我会把 spec 输入给一个具备推理能力的模型，并提示它生成一份项目计划：将实现拆解为逻辑清晰、易于消化的任务或里程碑。AI 实质上是在帮助我完成一份迷你的“设计文档”或项目计划。我通常会对这份计划反复迭代——编辑它、让 AI 批评或完善——直到它足够连贯且完整。只有在这之后，我才会进入编码阶段。前期的这种投入看起来可能有些慢，但回报极高。正如 Les Orchard 在这里所说，这就像是在 “15 分钟内做一次瀑布式开发”——一个快速而结构化的规划阶段，让后续编码顺畅得多。
有了清晰的规格和计划，当我们真正释放代码生成能力时，人和 LLM 都非常清楚要构建什么、以及为什么要这么做。简而言之，先规划能迫使你和 AI 达成共识，避免无谓的反复。这一步很多人容易跳过，但经验丰富的 LLM 开发者如今已经把健壮的规格/计划视为整个工作流的基石。
将工作拆分为小而可迭代的任务块
范围管理至关重要——给 LLM 可管理的任务，而不是一次性丢整个代码库。
我学到的一个关键经验是：避免让 AI 一次性产出庞大、整体化的结果。相反，我们应该把项目拆解成迭代的小步骤或工单，并逐个完成。这本来就是良好的软件工程实践，但在 AI 参与时尤为重要。LLM 在面对聚焦的问题时表现最好：一次实现一个函数、修复一个 bug、添加一个功能。举例来说，在完成规划后，我会对代码生成模型说：“好，我们来实现计划中的第 1 步。”我们完成这一步，测试它，然后进入第 2 步，如此往复。每个块都足够小，既在模型的上下文能力范围内，也便于你理解生成的代码。
这种方式能有效防止模型“跑偏”。如果你一次性要求太多，它很容易困惑，或者生成一个 “杂乱无章的混合体”，难以梳理。有开发者反馈，当他们试图让 LLM 生成大块应用代码时，最终得到的是不一致和重复——“就像 10 个开发者各干各的，却从不沟通”。我也深有体会；解决办法就是停下来、后退一步，把问题拆成更小的部分。每一轮迭代，我们都会带着已有的上下文继续构建。这也非常契合 测试驱动开发（TDD）——我们可以在过程中为每个模块编写或生成测试（稍后会详细谈测试）。
现在已有不少编码代理工具明确支持这种分块式工作流。例如，我经常生成一个结构化的 “prompt plan” 文件，里面包含每个任务对应的一系列提示，这样 Cursor 等工具就可以按顺序逐条执行。核心原则是：避免大跨度跳跃。通过小循环迭代，我们可以显著降低灾难性错误的概率，并快速纠偏。LLM 擅长快速、受控的小任务——善用这一点。
提供充分的上下文信息和指导
LLM 的能力取决于你提供的上下文——把相关代码、文档和约束展示给它。
在处理代码库时，我会确保把 AI 所需的全部信息都提供到位，包括它需要修改或参考的代码、项目的技术约束、以及已知的坑或偏好的实现方式。现代工具在这方面有所帮助：例如，Anthropic 的 Claude 在 “Projects” 模式下可以把整个 GitHub 仓库引入上下文；Cursor 或 Copilot 这类 IDE 助手会自动把当前打开的文件加入提示。但我往往会更进一步——如果我怀疑模型并不了解某些内容，我会使用像 Context7 这样的 MCP，或者手动把关键代码或 API 文档粘贴进对话。
资深 LLM 用户非常强调这种“上下文打包（context packing）”。例如，在编码前做一次**“脑内倾倒（brain dump）”**，把模型需要知道的一切都告诉它：高层目标与不变量、优秀方案的示例、以及应当避免的做法。如果我要让 AI 实现一个棘手的方案，我可能会提前说明哪些朴素解法太慢，或者给出一个外部参考实现。如果我使用的是冷门库或全新的 API，我会直接贴上官方文档或 README，避免模型“盲飞”。所有这些前置上下文都会显著提升输出质量，因为模型不再需要猜测——它掌握了事实与约束。
现在也有一些工具可以自动化上下文打包。我尝试过 gitingest 和 repo2txt，它们本质上是把代码库中相关部分“导出”为一个文本文件供 LLM 阅读。在处理大型项目时，这类工具非常救命——你生成一个 output.txt，把关键源文件打包给模型即可。原则很简单：不要让 AI 在信息不完整的情况下工作。如果修一个 bug 需要理解四个模块，就把这四个模块都给它。是的，需要关注 token 限制，但当前前沿模型的上下文窗口已经相当大（数万 token）。要明智地使用它们。我通常只选择性地包含与当前任务相关的代码，并明确告诉 AI 哪些内容不在范围内（以节省 token）。
我认为 Claude Skills 很有潜力，因为它们把原本脆弱、需要反复提示的流程，变成了可持久、可复用的能力模块——将指令、脚本和领域知识打包成 Skill，当请求匹配时由工具自动应用。这比泛泛的提示更可靠、更具上下文感知能力，也让我们从一次性互动，转向把可重复流程和团队知识编码进工作流中。社区里已经有不少整理好的 Skills 集合；我最喜欢的例子之一是 frontend-design skill，它可以“终结”LLM 生成 UI 中常见的紫色审美。在更多工具原生支持 Skills 之前，也有一些变通方案。
最后，在提示中用注释和规则来引导 AI。我可能会在代码片段前写：“这是 X 的当前实现，我们需要扩展它以支持 Y，但要注意不要破坏 Z。”这些小提示非常有用。LLM 是字面主义者——它们会遵循指令，所以请给出详细、有上下文的说明。通过主动提供上下文和指导，我们可以最大限度减少幻觉和跑题建议，得到真正契合项目需求的代码。
选择合适的模型（必要时同时使用多个模型）
并非所有编码型 LLM 都是一样的——有意识地选择工具，并且不要害怕在过程中切换模型。
在 2025 年，我们已经拥有了多种能力强大的、面向代码的 LLM。我的工作流中有一项重要内容是：为不同任务选择最合适的模型或服务。有时，甚至同时让两个或更多 LLM 并行尝试同一个问题、交叉对比它们的思路，也非常有价值。
每个模型都有自己的“性格”。关键在于：如果某个模型卡住了，或者给出的结果平庸，就换一个试试。 我确实经常把同一个提示，从一个聊天窗口原封不动地复制到另一个服务中，看是否能得到更好的处理结果。这种“模型换座位（model musical chairs）”的做法，在你撞上某个模型的盲区时，往往能救场。
同时，务必确保你使用的是当前最好的版本。如果条件允许，就用最新的 “pro” 级模型——质量真的很重要。是的，这通常意味着要付费，但生产力的提升往往值得。归根结底，选择那个与你**“合拍”**的 AI 结对程序员。我认识一些人更偏好某个模型，仅仅是因为他们喜欢那个模型回答问题的“感觉”。这完全合理——当你几乎是在与 AI 持续对话时，交互体验和语气本身就会产生影响。
就我个人而言，最近我在很多编码工作中更偏向使用 Gemini，因为它的交互感觉更自然，而且往往一次就能理解我的需求。但如果需要，我会毫不犹豫地切换到其他模型；有时，第二个意见能让解决方案浮现出来。总结来说：为任务选择最合适的工具，并记住——你手中拥有一整套 AI 武器库。
在整个软件生命周期中充分利用 AI 编码能力
在整个 SDLC 中使用面向编码的 AI，全面强化你的工作流。
在命令行层面，新的 AI 代理已经出现。Claude Code、OpenAI 的 Codex CLI，以及 Google 的 Gemini CLI，都是可以直接在项目目录中对话的 CLI 工具——它们可以读取文件、运行测试，甚至执行多步骤修复。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编码代理，它们会在云端 VM 中克隆你的仓库，在后台完成任务（编写测试、修复 bug），然后为你提交一个 PR。看到这一切发生其实有点诡异：你发出一个诸如“重构支付模块以支持 X”的命令，过一会儿就会收到一个包含代码变更且测试通过的拉取请求。我们确实活在未来。你可以在《从指挥到编排：未来的软件工程》中读到更多相关内容。
不过，这些工具并非万无一失，你必须理解它们的边界。它们极大地加速了编码中偏机械性的部分——生成样板代码、应用重复性修改、自动运行测试——但它们仍然非常依赖你的引导。例如，当我使用 Claude 或 Copilot 这类代理来实现功能时，通常会把前面步骤中的计划或待办清单一并提供给它，让它清楚每一步的执行顺序。如果代理支持，我会在下达执行指令前，把 spec.md 或 plan.md 加载进上下文，以确保它不跑偏。
我们还远未到可以完全放手让 AI 代理无人监督地完成整个功能，并指望它给出完美结果的阶段。 相反，我是以受监督的方式来使用这些工具：我会让它们生成并运行代码，但始终关注每一个步骤，一旦发现异常就及时介入。还有一些编排工具，比如 Conductor，允许你并行运行多个代理处理不同任务（本质上是扩展 AI 助手的规模）。一些工程师已经在尝试同时跑 3–4 个代理，分别负责不同功能。我也试过这种“高度并行”的方式——在短时间内完成大量工作时效果惊人，但同时监控多个 AI 线程在心理上也相当消耗精力！在大多数情况下，我仍然坚持一次只用一个主代理，必要时再加一个用于评审的辅助代理（下面会讲）。
记住，这些都是强力工具——扣动扳机和引导结果的，始终是你。
保持人工介入——对所有内容进行验证、测试和审查
**AI 会非常乐意生成“看起来合理”的代码，但你要为质量负责——始终审查并充分测试。**我最重要的一条原则之一是：绝不盲目信任 LLM 的输出。正如 Simon Willison 在这里所说，把 LLM 结对程序员看作是 **“过度自信、而且容易犯错”**的存在。它会用百分之百的笃定语气写代码——即使其中包含 bug 或胡言乱语——并且除非你发现问题，否则它不会主动告诉你哪里错了。因此，我会把每一段 AI 生成的代码，都当成来自一位初级工程师：逐行阅读、运行、并在需要时测试。你必须测试它写的东西——跑单元测试，或手动验证功能是否真的如它所说那样工作。更多内容可参考《“氛围式编码”并不是低质量工作的借口》。
事实上，我把测试直接织入了整个工作流。前期规划阶段通常就会包含每一步对应的测试列表或测试计划。如果我使用像 Claude Code 这样的工具，我会指示它在完成某个任务后运行测试套件，并在出现失败时自行调试。这种紧密的反馈循环（写代码 → 跑测试 → 修复）正是 AI 擅长的事情——前提是测试存在。因此，那些能最大化利用编码代理的人，往往也是测试实践非常扎实的人。对于像 Claude 这样的代理来说，一个完善的测试套件就像安全网；没有测试时，代理可能会轻率地认为“一切正常”，而实际上已经破坏了好几处。所以，投资测试——它会放大 AI 的价值，并增强你对结果的信心。
即便超越自动化测试，也要做代码评审——包括人工评审和 AI 辅助评审。我经常停下来，逐行审查目前生成的代码。有时我会开启第二个 AI 会话（或使用不同模型），让它去评审第一个模型生成的代码。例如，让 Claude 写代码，然后问 Gemini：“你能帮我检查这个函数是否有错误或改进空间吗？”这常常能发现细微问题。关键在于：不要因为代码是 AI 写的，就跳过评审。恰恰相反，AI 写的代码往往需要更多审查，因为它有时在表面上极具说服力，却隐藏着人类不容易第一时间察觉的缺陷。
我还使用了由我上一支团队构建的 Chrome DevTools MCP，作为调试与质量闭环的一部分，用来弥合静态代码分析与真实浏览器执行之间的鸿沟。它相当于“给 AI 装上眼睛”：允许我授权 AI 工具直接查看浏览器所看到的内容，检查 DOM，获取性能追踪、控制台日志或网络请求记录。这种集成消除了手动切换上下文的摩擦，使得通过 LLM 直接进行自动化 UI 测试成为可能，也让基于真实运行数据的高精度 bug 定位和修复成为现实。
忽视人工监督的严重后果已有记录。一位在赶项目时大量依赖 AI 生成代码的开发者描述最终产物是一个混乱不堪的系统——逻辑重复、方法命名不一致、架构支离破碎。他意识到自己只是不断“构建、构建、再构建”，却从未真正退后一步去理解 AI 编织出来的整体。修复它需要一次痛苦的重构，并发誓再也不让事情失控到这种程度。我对此深有感触。无论我使用多少 AI，我始终是那个负最终责任的工程师。
在实践中，这意味着：只有在我真正理解代码之后，才会合并或发布。如果 AI 生成了过于复杂的实现，我会让它加注释解释，或者干脆自己重写成更简单的形式。如果哪里感觉不对劲，我就会深入调查——就像对待一位人类同事提交的可疑代码一样。
一切归根结底是心态问题：LLM 是助手，而不是可以自主信赖的编码者。我是高级工程师；LLM 的职责是加速我，而不是替代我的判断。坚持这种立场不仅能产出更好的代码，也能保护你自身的成长。（有些人担心过度依赖 AI 会让技能退化——我认为只要你始终在回路中，积极审查并理解每一行代码，你实际上是在以更高速度打磨直觉。）总之：保持警惕，频繁测试，始终评审。 到最后，这仍然是你的代码库。
经常提交代码，并将版本控制作为安全保障。切勿提交自己无法解释的代码。
频繁提交就是你的存档点——它们让你能够撤销 AI 的失误，并理解发生了哪些变化。
当你与一个能够快速生成大量代码的 AI 一起工作时，事情很容易偏离正轨。我通过采用极其细粒度的版本控制习惯来缓解这一问题。我会尽早、并且频繁地提交代码，甚至比正常手写代码时还要频繁。每完成一个小任务，或每一次成功的自动化修改之后，我都会创建一次带有清晰提交信息的 git commit。这样一来，如果 AI 的下一条建议引入了 bug 或者造成了混乱的改动，我就能回退到最近的检查点（或者从中 cherry-pick），而不会丢掉数小时的工作。一位实践者把这种做法比作把提交当成**“游戏里的存档点”**——如果一次 LLM 会话走偏了，你总是可以回滚到上一个稳定的提交。我发现这个建议极其有用。当你知道必要时可以用 git reset 撤销改动时，去尝试一次大胆的 AI 重构就不那么有压力了。
恰当的版本控制在与 AI 协作时同样非常有帮助。由于我不能指望 AI 记住它做过的所有事情（上下文窗口的限制等等），git 历史就成了一份宝贵的日志。我经常浏览最近的提交，向 AI（或向我自己）说明发生了哪些变化。事实上，只要你把提交历史提供给 LLM，它们本身也能利用这些信息——我曾把 git diff 或提交日志直接粘贴到提示词里，让 AI 知道哪些代码是新的，或者之前的状态是什么。有趣的是，LLM 在解析 diff 以及使用诸如 git bisect 之类的工具来定位 bug 引入位置方面真的非常擅长。它们有着无限的耐心去遍历提交历史，这可以极大增强你的调试能力。但前提是：你一开始就要有一份整洁的提交历史。
还有一个好处：带有良好提交信息的小提交，本质上记录了开发过程，这在做代码审查（无论是 AI 还是人类）时非常有帮助。如果一个 AI 一次性做了五个改动，然后某处坏了，把这些改动分散在不同提交中，就更容易定位到底是哪个提交导致了问题。反之，如果所有内容都塞进一个名为“AI changes”的巨大提交里，那就自求多福吧。我因此严格要求自己：完成任务，运行测试，提交。 这也与前面关于把工作拆分成小块的建议非常契合——每一个小块最终都会成为一个独立的提交或 PR。
最后，不要害怕使用分支或 worktree来隔离 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 偏离脚本或引入我们不希望出现的模式的概率。
即便没有花哨的规则文件，你也可以通过自定义指令或 system prompt 来定调。GitHub Copilot 和 Cursor 都引入了相关功能，允许你在项目层面全局配置 AI 的行为。我就充分利用了这一点，写了一小段关于我们编码风格的说明，例如：“使用 4 空格缩进，在 React 中避免使用箭头函数，偏好描述性变量名，代码需通过 ESLint。”在这些指令就位之后，AI 的建议就会更加贴近人类队友的写法。Ben Congdon 在文章中提到，他很惊讶竟然很少有人使用 Copilot 的自定义指令，因为它们的效果非常显著——只要提前提供一些示例和偏好，他就能引导 AI 输出完全符合团队习惯的代码。我对此深有同感：花点时间教会 AI 你的期望。
另一个非常强大的技巧是提供行内示例，明确你想要的输出格式或实现方式。如果我希望 AI 以一种非常特定的方式来编写函数，我可能会先给它看代码库中已有的类似函数：“这是我们实现 X 的方式，请用类似的方法实现 Y。”如果我想要某种特定的注释风格，我甚至会先自己写一条注释，然后让 AI 按这种风格继续。本质上，这是在对模型进行 预热（prime），让它知道要遵循的模式。LLM 非常擅长模仿——给它一两个例子，它就会沿着同样的路子往下写。
社区中也出现了不少富有创意的“规则集”，用来驯服 LLM 的行为。你可能听说过 “Big Daddy” 规则，或者在提示词中加入“禁止幻觉 / 禁止欺骗”的条款。这些本质上都是在提醒 AI 要保持真实，不要过度编造并不存在的代码。例如，我有时会在提示词前加上一句：“如果你对某些事情不确定，或者缺少代码库上下文，请先请求澄清，而不是编造答案。”这能有效减少幻觉。另一条我常用的规则是：“在修复 bug 时，始终在注释中简要说明你的推理过程。”这样一来，当 AI 生成修复方案时，也会留下类似这样的注释：“// Fixed: Changed X to Y to prevent Z (as per spec).”这对后续审查非常有价值。
总而言之，不要把 AI 当成一个黑箱——要对它进行调校。通过配置 system 指令、共享项目文档，或明确写下规则，你可以把 AI 打造成团队中一个更加专业化的开发者。这就像新员工入职一样：你一定会给他风格指南和一些入门建议，对吧？同样地对待你的 AI 结对编程伙伴即可。投入产出比非常高——你会得到需要更少修改、并且能更顺畅地融入现有代码库的输出。
将测试和自动化视为放大效率的关键杠杆
善用 CI/CD、代码规范检查器和代码审查机器人——AI 在能够自动捕获错误的环境中表现最好。
这是“保持人在回路中并持续提供上下文”的一个自然延伸：一条运转良好的开发流水线会显著提升 AI 的生产力。我会确保所有大量使用 AI 编码的代码仓库，都具备一套健全的持续集成（CI）体系。这意味着：每次提交或 PR 都会自动运行测试，强制执行代码风格检查（如 ESLint、Prettier 等），并且理想情况下，每个新分支都能部署到一个可用的 staging 环境。为什么要这样做？因为我可以让 AI 主动触发这些流程，并据此评估结果。
例如，如果 AI 通过 Jules 或 GitHub Copilot Agent 之类的工具发起了一个 pull request，我们的 CI 就会自动运行测试并报告失败信息。我可以把这些失败日志再喂回给 AI：“集成测试在 XYZ 处失败了，我们来一起调试。”这样一来，修 bug 就变成了一个快速反馈的协作循环，而 AI 非常擅长处理这种模式（它提出修复方案，我们再次运行 CI，然后继续迭代）。
自动化的代码质量检查（如 linter、类型检查器）同样可以对 AI 起到引导作用。我有时甚至会把 linter 的输出直接放进提示词里。如果 AI 写的代码没有通过我们的规范检查，我就把错误信息复制到对话中，说一句：“请解决这些问题。”模型立刻就知道该做什么了。这就像有一位严格的老师在盯着 AI 写代码。根据我的经验，一旦 AI 看到了某个工具的输出（比如测试失败或 lint 警告），它就会非常努力地去修正——毕竟它“想要”给出正确的答案。这再次呼应了“提供上下文”的原则：把环境对其行为的反馈（测试失败等）提供给 AI，它就能从中学习和调整。
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 年构建顺利！🚀
我很高兴地分享，我已经与 O’Reilly 一起发布了一本新的 AI 辅助工程书籍。书籍网站上也有一些免费的实用技巧，感兴趣的可以查看。
