AI取代不了程序员，明年全流程上AI！谷歌工程负责人自曝：2026年AI编程完整工作流！经典软件工程纪律没过时，在AI时代更重要

2025年，AI 编程助手真正成为了改变游戏规则的工具

不少开发者已经拥抱了AI编程工具，比如大家熟知的Claude Code、Codex CLI、Cursor、Gemini CLI等等。但要真正高效驾驭它们，还需要技巧和结构化的方法。

谷歌工程负责人分享AI编程工作流

谷歌工程负责人、Chrome DevTools 和 JS Patterns 的设计者 Addy Osmani 结合自己一年多的项目实践经验，总结了一套AI Coding 的工作流。

进入 2026 年，他对 LLM 辅助编程的理解已经非常清晰：它不是“自动驾驶”，而是一位能力极强、但需要被正确引导的结对程序员。

Osmani系统性复盘了自己在走向 2026 的过程中，如何把 AI 真正纳入日常工程体系——从前期规划，到代码生成，再到团队协作，几乎覆盖了一整套可复用的实战方法论。在他的实践中，AI 并不是“写代码的黑箱”，而是被当作工程流程中的一环来精细管理。具体来说，这套方法包括：

• 在任何代码生成之前，先与 AI 一起打磨一份足够具体、可执行的项目方案，把需求、边界和目标一次性说清楚；
• 在 prompt 中大量使用明确的注释、约束和规则，主动限定 AI 的行为，而不是被动接收结果；
• 针对不同任务选择不同模型，而不是迷信“一个模型包打天下”；
• 保持高频、小步的代码提交，避免一次性生成或修改过多代码，导致项目状态失控；
• 为每一个新功能单独创建 worktree，将实验性改动与主线代码严格隔离；
• 通过规则文件约束 AI 的代码风格、目录结构和工程习惯，让生成代码更像“团队成员”而不是“临时外包”。

他的核心结论是：经典的软件工程纪律，不但没有过时，在 AI 时代反而更重要！

先设计、再编码；写测试；用版本控制；守住标准。当 AI 参与写一半代码时，这些原则的价值被进一步放大。

AI是加速成长的工具，而非替代品

此外，Osmani还分享了一个有趣的观点。很多人可能认为，AI Coding会加速程序员失业，取代程序员的岗位，但Osmani认为，用好AI才能加速你的成长。

在审 AI 的代码、纠 AI 的 bug、让 AI 解释思路的过程中，其实能够学到大量新知识；而对于有扎实基本功的人来说，AI能让生产力成倍放大。

Osmani表示，2026 年他将全面拥抱 AI，但方式是审慎、由专家主导的 。这是一种更加自律的“AI 辅助工程”方法：在激进地利用 AI 能力的同时，依然对最终产出的软件负全部责任。

从清晰的计划开始：先写方案，再写代码

不要只是把“愿望”一股脑丢给 LLM，应先定义问题，再规划解决方案。

一个非常常见的错误，是在提示语还很模糊的情况下，直接让 AI 生成代码。在我的工作流中（以及许多成熟实践中），第一步并不是写代码，而是和 AI 一起头脑风暴，产出一份详细的规格说明 ，然后再整理出清晰的分步计划。

对于一个新项目，我通常会先描述整体想法，并让 LLM 不断向我反问，直到需求、边界条件和潜在的边缘情况都被充分挖掘出来。最终，我们会把这些内容整理成一份完整的 spec.md，其中包含：功能需求、架构决策、数据模型，甚至测试策略。这份规格文档会成为整个开发过程的基石。

接下来，我会把这份 spec 交给一个具备推理能力的模型 ，让它生成项目计划：把实现过程拆解成逻辑清晰、粒度合适的小任务或里程碑。某种意义上，这是一个“迷你版设计文档 / 项目计划”。我通常会多次迭代这份计划——亲自修改，再让 AI 批判性地审视、优化——直到它足够完整、连贯，然后才进入真正的编码阶段。

这种前期投入乍看之下有点慢，但回报极高。正如 Les Orchard 所说，这就像是“15 分钟完成一次瀑布式设计”，一个快速而结构化的规划阶段，让后续编码变得异常顺畅。

有了清晰的规格和计划，当我们真正“释放”代码生成能力时，人和 AI 都非常清楚：我们要做什么，以及为什么要这么做。简而言之，先规划能让你和 AI 站在同一页上，避免无效反复 。很多人会跳过这一步，但如今有经验的 LLM 开发者，已经把高质量的 spec / plan 当成整个工作流的核心。

把工作拆分成小而可迭代的块

范围管理是一切的关键：给 LLM 可控的小任务，而不是一次性塞进整个代码库。

我学到的一个重要教训是：不要让 AI 一次性输出大量、整体性的代码 。相反，应把项目拆成一系列小步骤或“工单”，逐个完成。这本来就是良好的软件工程实践，但在引入 AI 之后变得尤为重要。

LLM 在聚焦型任务 上表现最好：实现一个函数、修复一个 bug、添加一个小功能。比如在完成规划后，我会直接对代码生成模型说：“好，我们来实现计划里的第 1 步。”完成后测试，再进入第 2 步，如此循环。每一个 chunk 都足够小，小到 AI 能在上下文中处理干净，而你也能真正理解它生成的代码。

这种方式能有效防止模型“跑偏”。如果一次性要求太多，模型往往会迷失方向，生成一堆“纠缠在一起的代码垃圾”，非常难以维护。很多开发者都有类似体验：让 LLM 一口气生成一个完整应用，结果代码风格不统一、逻辑重复，“就像 10 个程序员各干各的，彼此完全没沟通”。我自己也踩过这个坑，解决方法只有一个：停下来，退一步，把问题切小 。

每一轮迭代，我们都在已有上下文的基础上，增量式地推进。这也非常适合测试驱动开发（TDD）：每一步都可以同步编写或生成测试（后面会详细讲）。

不少编码 Agent 工具已经显式支持这种“分块”工作流。例如，我有时会生成一个结构化的“prompt plan”文件，里面包含每个任务对应的一条提示语，让 Cursor 这类工具按顺序逐条执行。核心原则只有一个：避免大跃进 。通过小步快跑，我们大幅降低灾难性错误的概率，也能更快纠偏。LLM 在快速、受限的任务上非常擅长，要顺势而为。

提供充足的上下文和明确的指导

LLM 的质量上限，取决于你提供的上下文质量。把相关代码、文档和约束条件都给它。

在处理真实代码库时，我会确保 AI 拥有完成任务所需的一切信息：相关源码、技术约束、已知坑点、推荐或禁止的方案。现代工具在这方面已经很强了：比如 Claude 的 Projects 模式可以直接导入整个 GitHub 仓库；Cursor、Copilot 会自动把当前打开的文件放进上下文。但我通常还会做得更多。

如果我怀疑模型缺乏某些关键信息，就会通过 MCP（比如 Context7），或干脆手动把重要模块、API 文档粘进对话里。资深 LLM 用户普遍强调这种“上下文打包（context packing）”的重要性，比如在编码前来一次完整的“信息倾倒”，包括：

• 高层目标与不变量
• 正确解法的示例
• 明确警告哪些方案不要用

如果任务本身比较棘手，我甚至会提前告诉 AI 哪些朴素解法性能不行，或者给它一个外部参考实现。如果使用的是冷门库或全新 API，我会直接贴官方文档或 README，避免它“蒙着眼睛飞”。

所有这些前置上下文，都会显著提升输出质量，因为模型不需要猜测，而是基于事实和约束进行生成。

现在也有不少工具能自动化上下文整理，比如 gitingest、repo2txt，它们可以把代码库的关键部分导出成一个文本文件，让 LLM 一次性读入。对于大型项目来说，这是救命工具。原则很简单：不要让 AI 在信息不完整的情况下工作 。一个 bug 如果涉及四个模块，就把这四个模块都给它。当然要注意 token 限制，但如今前沿模型的上下文窗口已经非常大（几万 token），合理利用即可。我通常只选取与当前任务相关的代码，并明确告诉 AI 哪些内容可以忽略，以节省上下文空间。

为不同任务选择最合适的模型

并非所有编码大语言模型都相同，需要有意识地选择工具，并在必要时切换模型。

当前，我们已拥有众多强大的代码模型。我的工作流中，一个关键环节就是：为不同任务选择最合适的模型或服务。有时，我甚至会并行尝试两个模型，以对比它们对同一问题的解决思路。

每个模型都有其独特的“性格”。关键在于：如果一个模型卡壳或输出平庸，立即更换另一个。我经常将同一个提示词原封不动地复制到另一个服务中，结果往往立竿见影。这种“模型轮换”策略在遇到思维盲点时非常有效。

此外，应尽量使用最新、最强的模型版本。如果条件允许，优先选择最新的专业级模型。这通常意味着付费，但生产力的提升往往物有所值。说到底，选择一个“合拍”的AI结对编程伙伴也很重要。有些人偏爱特定模型，可能只是因为其回应风格更符合个人偏好，这完全合理。当你需要与AI进行长时间对话时，交互体验和语气确实很重要。

就个人而言，最近许多编码工作我会优先使用Gemini，因其交互更自然，首次理解需求的概率更高。但我从不犹豫在必要时切换模型；有时，“第二意见”能让解决方案豁然开朗。总结一句：为任务选对工具，并记住你手中拥有整套AI工具箱。

在整个软件生命周期中使用AI编码能力

在软件开发生命周期的各个阶段引入AI，能让开发体验全面提速。

在命令行层面，新一代AI智能体已经出现：Claude Code、OpenAI Codex CLI、Google Gemini CLI等，都可以直接在项目目录中对话，读取文件、运行测试，甚至执行多步问题修复。我也使用过Google的Jules、GitHub Copilot Agent等异步编码智能体，它们会将你的仓库克隆到云端虚拟机，在后台完成任务（如编写测试、修复bug），然后直接提交一个拉取请求。第一次体验时感觉非常神奇：你只需下达一条指令，例如“重构支付模块以支持X功能”，稍后便会收到一个测试通过的拉取请求。我们确实活在未来。

当然，这些工具并非完美，必须清楚其边界。它们非常擅长加速机械性工作，如样板代码、重复性修改、自动运行测试等，但仍然高度依赖你的引导。例如，当我让Claude或Copilot Agent实现某个功能时，通常会附上之前整理好的计划或待办清单。如果工具支持，我会直接将 spec.md 或 plan.md 文件加入上下文，让它严格按照步骤执行。

我们远未达到可以完全放手、让AI独立实现完整功能并期待完美结果的阶段。我的使用方式始终是“有人监督”：让AI生成、运行代码，而我随时监控进度，一旦出现异常便立即介入。也有一些编排工具（如Conductor）支持并行运行多个智能体，让它们同时处理不同任务，本质上是在“规模化AI劳动力”。我也尝试过这种“多智能体并行”模式，效率惊人，但同时也非常耗费心智去监控。多数情况下，我仍会选择使用一个主智能体，再加一个辅助智能体进行评审。

请记住：这些都是电动工具。你仍然掌控着扳机。

始终让人留在回路中：验证、测试、审查一切

AI可以生成看起来非常逼真的代码，但质量责任始终在你。

我有一条铁律：永远不要盲目相信大语言模型的输出。正如Simon Willison所说，应将大语言模型视为一个“自信过头、但容易犯错的结对程序员”。它会以百分之百的确信度写出包含bug的代码，除非你指出来，否则它不会意识到问题。

因此，我将每一段AI生成的代码，都视为来自初级工程师的提交：逐行阅读、运行、测试。一定要进行测试。运行单元测试、手动验证功能是否符合预期。

事实上，我将测试直接嵌入工作流中。前期规划时就会包含测试清单或测试策略。如果使用Claude Code这类工具，我会明确指示它在完成任务后运行测试，并在失败时继续调试。只要测试存在，AI在“写代码 → 跑测试 → 修bug”的闭环中表现非常出色。这也是为什么最能榨取编码智能体价值的人，往往也是测试做得最好的人。拥有完善测试套件的项目，对AI来说就像安装了安全网；没有测试，智能体很容易在“看起来一切正常”的幻觉中破坏多个模块。

除了自动化测试，代码审查同样不可或缺——包括人工审查和AI辅助审查。我经常会暂停下来，逐行审查当前生成的代码，甚至开启第二个AI会话（或更换一个模型）来进行评审。例如，让Claude编写代码，再让Gemini审核一遍：“你能检查这个函数是否存在潜在问题吗？”这种方式经常能捕捉到一些微妙的bug。AI编写的代码，反而更需要审查，因为它往往“表面上很合理”。

我还会使用Chrome DevTools MCP（这是我和上一个团队共同开发的）来增强调试和质量闭环。它相当于“给AI装上眼睛”，让智能体能够看到浏览器的实际状态：DOM、性能追踪、控制台日志、网络请求。这极大地减少了上下文切换的摩擦，使大语言模型能够基于真实运行数据进行UI测试和精确修复。

忽视人类监督的代价已经有人替我们承担过。曾有开发者在赶项目时大量依赖AI生成代码，结果导致代码结构混乱、逻辑重复、命名不一致。他后来意识到自己一直在“向前堆砌代码”，却从未停下来进行整体审视。最终只能痛苦地进行重构，并发誓再也不让事情失控。我将这个教训牢记在心：无论AI使用得多频繁，我始终是最终负责的工程师。

在实践中，这意味着：只有在我真正理解代码之后，才会将其合并或上线。如果AI生成的代码过于复杂，我会让它添加注释进行解释，或者干脆重写成更清晰的版本。只要感觉不对劲，就深入挖掘——就像对待任何人类同事的可疑提交一样。

归根结底是心态问题：大语言模型是助手，而不是可靠的自主程序员。我是高级工程师，AI是加速器，而不是判断的替代品。这种立场不仅带来更好的代码，也能保护你作为开发者的长期成长。只要你始终参与其中、主动理解和审查，你并非在退化，而是在更高速度下锻炼判断力。

一句话总结：保持警惕，频繁测试，永远审查。代码库最终仍然是你的。

频繁提交，把版本控制当作安全网

永远不要提交你解释不清楚的代码。

在AI能快速生成大量代码的情况下，事情很容易失控。我的应对方式是：采用极端细粒度的版本控制习惯。我提交的频率比纯手写代码时代还要高。每完成一个小任务或一次成功的自动修改，就立即提交一次，并在提交信息中写清楚变更内容。

这样一来，如果AI的下一步操作引入了bug或糟糕的改动，我可以迅速回滚到最近的稳定点，或者进行拣选合并，而不是损失数小时的工作。有人将这种做法比喻为“游戏中的存档点”，我非常认同。有了这种安全感，你才敢大胆尝试AI驱动的激进重构。

用规则和示例定制 AI 的行为

通过风格指南、示例，甚至“规则文件”来引导 AI，前期的一点调校能换来长期的高质量输出。

一个关键认知是：你完全不必接受 AI 的默认风格。你可以强力地引导它。例如，可以维护一个 CLAUDE.md 文件（使用 Gemini CLI 时也有 GEMINI.md），其中定义流程规则和偏好，比如：
* 遵循项目代码风格
* 通过 lint 规则
* 禁用某些函数
* 偏好函数式而非面向对象编程

每次会话开始时将这个文件提供给模型，效果显著，能极大减少输出“跑偏”。这正如 Jesse Vincent 所言：它能让模型始终沿着既定轨道前进。

即使不使用规则文件，也可以通过自定义指令或系统提示达到类似效果。Copilot、Cursor 等工具都支持项目级别的行为配置。通常可以编写一小段说明，涵盖缩进规范、在 React 中避免箭头函数、变量命名要求、必须通过 ESLint 检查等。设置好后，AI 的输出就更像一个真正融入团队的工程师。Ben Congdon 曾感慨，很少有人使用 Copilot 的自定义指令，但其效果却出奇地好——我完全赞同。

另一个非常有效的技巧是：提供示例。如果希望 AI 以某种方式编写函数，就先给它看一个现有的实现；如果想要特定的注释风格，就先自己写一段示例。LLM 非常擅长模仿，一两个例子往往就足够了。

社区里还有不少“规则集”用来约束模型行为，比如明确写上“如果不确定，请提问而不是编造答案”。我自己经常加一条：“修复 bug 时请在注释中简要说明原因。”这会让后续的代码审查非常省心。

总结来说：不要把 AI 当作黑箱。像引导新同事一样，给它规则、示例和期望。投入产出比极高。

把测试和自动化当作放大器

CI/CD、代码检查工具、自动化审查机器人，会让 AI 发挥出最大价值。

这是前述原则的自然延伸：一个自动化程度高的工程环境，会极大放大 AI 的生产力。我确保所有大量使用 AI 的代码仓库，都配备了完善的持续集成流程：自动测试、代码风格检查，最好还有预发布环境部署。

这样一来，当 AI 生成代码并创建拉取请求后，持续集成失败的日志就能直接反馈给 AI：“集成测试失败，错误是 XYZ。”问题的修复立刻变成一个高速反馈回路，AI 非常擅长处理这种模式。

我甚至会将 linter 的报错信息直接粘贴到提示词中，让 AI 来修复。只要 AI“看到”了工具的反馈，它就会非常努力地纠正。这也是一些智能体在测试全部通过前，会拒绝宣称“任务完成”的原因——这正是我们所期望的行为。

当 AI 与自动化形成闭环时，感觉就像：一个极快的初级工程师，配上一个永不疲倦的质量保证人员。前提是，你得先把这样的环境搭建好。没有测试和自动检查，AI 产生的问题往往会被拖到很后期才暴露。

展望 2026 年，我计划进一步强化 AI 代码贡献的质量闸门：增加更多测试、更多监控，甚至尝试用 AI 审查 AI 生成的代码。这听起来有些悖论，但确实有效。底线很简单：一个对 AI 友好的工作流，必然是一个自动化成熟的工作流。

用好AI，能加速你的成长

把每次 AI 辅助编码都当作学习机会，可以形成正反馈循环。

使用 LLM 的一个意外收获是：我学得更多了，而不是更少。AI 让我接触到新的编程语言、框架和技巧，否则我未必会主动尝试。

一个普遍规律是：AI 会奖励良好的工程基础。拥有扎实基本功的人，其生产力会被成倍放大；而基础薄弱的人，其困惑也会被放大。LLM 让你能站在更高的抽象层上思考（如设计、接口、架构），但前提是你本来就具备这些能力。正如 Simon Willison 所说：几乎所有“高级工程师”的核心能力，正是如今用好 AI 的关键。

对于那些担心 AI 会让人“退化”的声音，我的看法恰恰相反：只要你始终参与审查和理解 AI 的输出，它反而会加速你的成长。通过审查 AI 的代码、纠正 AI 的 bug、让 AI 解释其思路，我学到了大量新知识。AI 也成了我随叫随到的研究助理，帮我比较方案、分析权衡。

宏观来看，AI 放大的是你的专业能力。进入 2026 年，我并不担心它“抢工作”，而是期待它把我从重复性体力活中解放出来。当然，前提是要有扎实的基础，否则 AI 可能会制造“邓宁-克鲁格效应”的加强版。

一句建议：持续打磨基本功，并用 AI 来加速这个过程。开发者与 AI 的组合，远比任何一方单独行动更强大。

结语：2026年全面拥抱AI编程

进入 2026 年，我已经全面拥抱 AI，但方式是审慎、由专家主导的。这是一种“AI 增强的软件工程”，而不是“AI 自动化的软件工程”。

我的核心结论是：经典的软件工程纪律，不但没有过时，在 AI 时代反而更重要。先设计、再编码；编写测试；使用版本控制；坚守标准——当 AI 参与编写一半的代码时，这些原则的价值被进一步放大了。

未来一定会继续演进。也许会出现更自主的“AI 实习生”，也许会出现全新的调试和代码探索范式。但无论如何，我都会始终留在控制回路中，引导 AI、向它学习，并负责任地放大自己的生产力。

对我来说，最终的结论只有一句：AI 编程助手是强大的杠杆，但人类工程师仍然是导演。

那么，祝你在 2026 年，构建愉快。

参考链接：
https://addyo.substack.com/p/my-llm-coding-workflow-going-into

关注“鲸栖”小程序，掌握最新AI资讯