2026 年用 AI 编程的正确姿势：来自 Google 资深工程师的实战工作流

原文来源：Medium - Addy Osmani — Google Chrome 团队资深工程师分享的 2026 年 AI 辅助编码最佳实践

AI 编程助手在 2025 年取得了质的飞跃。以 Anthropic 为例，Claude Code 的代码中大约 90% 是由 Claude Code 自己写的。但用 LLM 编程并不是"按个键就出完美代码"的魔法体验——恰恰相反，它"困难且反直觉"，要获得好的结果需要学习全新的模式。

Addy Osmani 是 Google Chrome 团队的资深工程师，也是 O'Reilly 出版的《AI 辅助工程》一书的作者。他在过去一年里与各种 AI 编程工具深度协作，总结出了一套经过实战检验的工作流。这篇文章把他的核心方法论翻译整理出来。

核心原则只有一句话：把 LLM 当作一个强大的结对编程伙伴，它需要清晰的指导、充分的上下文和持续的监督，而不是让它自主做判断。

第一步：先写规格，再写代码

不要把模糊的需求直接扔给 LLM——先定义问题，再规划方案。

这是最容易被忽视的一步，也是最有价值的投资。

常见错误是上来就写一个模糊的提示词，让 AI 直接生成代码。正确做法是：

1. 向 LLM 描述你的想法，让它迭代式地提问，直到把需求和边界条件都搞清楚
2. 最终产出一份 spec.md，包含需求、架构决策、数据模型甚至测试策略
3. 把 spec 喂给一个推理能力强的模型，让它生成项目计划——把实现拆解为逻辑上独立的小任务

写 spec 这个前置投入看起来慢，但效果显著。正如一位开发者所说，这相当于做了一次 "15 分钟的瀑布模型"——快速的结构化规划阶段，让后续的编码流畅得多。

规划优先强迫你和 AI 站在同一页面上，避免浪费循环。

第二步：把工作拆成小块

范围管理就是一切——给 LLM 可管理的任务，不要一次扔整个代码库。

这是 AI 辅助编程中最关键的技巧。

很多人的做法是：把整个项目靠给 AI，让它一次性生成大量代码。结果往往是一团乱麻——"像 10 个开发者在各做各的，互相没交流"。

正确的做法是：

• 把项目拆成迭代式的步骤或工单，一个一个处理
• 每个任务足够小，让 AI 能在上下文窗口内处理它
• 每完成一步，测试、验证、提交

比如规划完成后，告诉模型"好，我们从计划的步骤 1 开始实现"。写完测试，然后进入步骤 2，以此类推。

这样做的好处是：如果 AI 偏离方向，你不会损失太多。发现有问题，回退到上一个 commit，重新来。

第三步：提供大量上下文

LLM 的表现取决于你给它的上下文质量——给它看相关代码、文档和约束。

AI 不知道你项目里有什么，除非你告诉它。

在实践中，你需要给 AI 喂它需要知道的所有信息：

• 要修改的目标代码
• 项目的技术约束
• 已知的陷阱和偏好做法
• 相关 API 的文档
• 第三方库的 README

Addy 的做法更进一步：他会在开始编码前给 AI 做一次 "脑 dump"——把所有的目标、约束、好方案的例子、要避免的坑，全部倒给模型。

现在有一些工具可以自动化这个上下文打包过程：

• gitingest：把你的代码库相关部分打包成文本文件
• repo2txt：类似工具，把关键源文件导出给 AI 读

原则很简单：不要让 AI 在信息不全的情况下工作。如果一个 bug 修复需要理解四个模块，就给它看这四个模块。目前的 AI 模型都有相当大的上下文窗口（数万 token），用好它们。

Addy 还特别提到，Claude Skills 是一个很有潜力的方向——它将脆弱、重复的提示词变成了可复用、可持久化的模块，把指令、脚本和领域知识打包成可自动应用的能力。

第四步：用测试驱动

不要让 AI 的代码通过审查——让它生成的代码通过测试。

测试是 AI 辅助编程中最重要的安全网。Addy 的做法：

• 先写测试，再让 AI 生成实现代码（TDD）
• 让 AI 自己生成测试，同时测试它的输出
• 把 linter 的输出也包含在提示词中

他发现，一旦 AI 知道某个工具的输出（比如测试失败或 lint 警告），它会非常努力地修正问题——毕竟它"想要"给出正确答案。在提示词中包含 linter 输出，效果出奇地好。AI 会努力消除所有警告和错误，生成的代码质量明显更高。

连续集成是必须的。如果项目没有测试或自动化检查，AI 生成的内容可能会混入细微的 bug 或低质量代码，直到很晚才被发现。

第五步：频繁提交，用版本控制做安全网

频繁的 commit 就是你的存档点——它们让你能撤销 AI 的错误操作，并理解每次变更。

与 AI 合作时，版本控制的重要性被放大了一个数量级。

• 小任务完成后立即提交：每完成一个小任务或成功的自动编辑，就做一个 git commit
• 把 commit 当作"游戏存档"：如果 AI 下一步的建议出了问题，可以回退到最近的稳定点

Addy 发现 LLM 非常擅长解析 diff 和使用 git bisect 来定位 bug——它们有无限的耐心去遍历提交历史。但这需要你有整洁的 commit 历史。

另一个实用技巧：使用分支或 worktree 来隔离 AI 实验。这样可以在同一个仓库上并行运行多个 AI 编码会话，互不干扰。如果某个实验失败，扔掉那个 worktree，main 分支不受影响。

第六步：定制 AI 的行为

你不必接受 AI 的默认编码风格——你可以通过规则文件来影响它。Addy 的推荐做法：

"使用 4 空格缩进，React 中避免箭头函数，优先使用描述性变量名，代码必须通过 ESLint"

有了这些指令，AI 的输出会更接近人类团队成员的风格。

• 用 CLAUDE.md（对 Claude Code）、.cursorrules（对 Cursor）等配置文件设置全局规则
• 给 AI 一些代码示例让它模仿
• 告诉它"修复 bug 时在注释中简要解释你的推理过程"

不要把 AI 当作黑盒——调校它。就像你入职一个新同事，给 TA 看风格指南和入门提示一样。对 AI 编程伙伴做同样的事。

第七步：持续学习与适应

Addy 的一条忠告：AI 放大了你的能力上限，但它不能替代基础。

如果你的底层编程能力薄弱，AI 只会放大你的困惑。AI 让你能在更高的抽象层面工作（专注于设计、架构、接口），但你仍然需要具备这些高层次的技能本身。

他的建议：

• 坚持定期脱离 AI 写代码，保持原始技能
• 用 AI 加速学习过程——让它解释概念、检查代码、提供不同方案
• 保持批判性思维：AI 给出的建议不一定正确，你需要判断和验证

最终总结

用 Addy 自己的话来结束：

AI 编程助手是令人难以置信的杠杆，但人类工程师仍然是这场演出的导演。

2026 年的 AI 编程已经不是要不要用的问题，而是怎么用好的问题。这套工作流的核心——先规划、小块切、给上下文、写测试、频繁提交——不是什么高深的东西，它本质上就是好的软件工程实践，只是在 AI 时代变得更加重要。

你在用 AI 编程吗？你现在的工作流是什么样的？