本页要点
在写任何代码之前，先用 AI 头脑风暴，把需求打磨成详尽的 spec.md 文件。Osmani 称之为「15 分钟瀑布流」——用传统瀑布模型的严谨性，但以 AI 辅助的速度完成。清晰的规格让人和 AI 站在同一起跑线上。
AI 编程质量在需求规格层就已经决定了成败，而不是在代码生成层。你需要的不是更好的模型，而是更清晰的需求描述。
—— Addy Osmani
Spec-Driven 开发流程
Osmani 提出的核心做法是：先和 AI 坐下来「聊需求」，通过反复对话把模糊的想法打磨成结构化的 spec.md 文件。这份文件应当包括功能边界、边界场景、验收标准和技术约束。他把这个过程形象地比喻为「15 分钟瀑布流」——虽然采用了传统瀑布模型的严谨思路，但借助 AI 的速度，整个过程可以压缩到十几分钟完成。清晰的规格文档让人和 AI 对齐了目标，是后续一切高质量产出的基石。
拆成小块，逐步推进
BREAK INTO SMALL ITERATIVE CHUNKS
本页要点
不要让 AI 一次性生成大量代码。每次只做一件事——一个函数、一个 bug 修复、一个小功能。Osmani 警告说，给 AI 一个庞大任务，就像把工作丢给十个互不沟通的开发者。迭代式开发类似于 TDD 的精神，能有效防止模型跑偏。
给 AI 一个庞大的任务，相当于让十个开发者各干各的但彼此不交流。结果就是不一致和重复。
—— Addy Osmani
每次只处理一个函数、修复一个 bug 或实现一个功能点
大规模的单体输出容易产生不一致和代码重复
小步迭代与 TDD 的理念高度一致——先验证，再前进
每个小步骤完成后立即审查和测试，确认通过再进入下一步
这种纪律性是防止 AI 模型「跑偏」的最有效手段
可以生成结构化的「提示计划」文件，让 Cursor 等工具逐一执行预定义的任务序列
核心思路非常清晰：把大任务拆解为最小的独立单元。不要让 Claude Code 或 Gemini 一口气生成整个模块。写好一个函数，测通了，提交了，再开始下一个。这种做法和 TDD 的精神一脉相承——每一步都有明确的验证标准。它同时也是一种风险控制策略：如果 AI 在某一步产出了有问题的代码，损失仅限于这一小块，而不是整个系统。现在已经有工具支持这种分块工作流——比如 Cursor，你可以预先生成一份结构化的提示计划文件，工具会按序逐个执行每个任务。
提供充足的上下文
PROVIDE EXTENSIVE CONTEXT
本页要点Context Packing——把一切相关信息都塞给 AI。Osmani 的做法是进行一次彻底的「大脑倾倒」，把所有可能相关的代码、文档、错误日志全部提供给模型，绝不让 AI 在信息不完整的情况下工作。
永远不要让 AI 在不完整的信息上操作。上下文就是一切——宁可给多，不可给少。
—— Addy Osmani
用 gitingest 将整个代码仓库提取为可消化的文本格式
用 repo2txt 把代码库转换为纯文本供 AI 阅读
用 Context7 MCP 获取第三方库的实时最新文档
利用 Claude Projects 持久保存项目知识库
Chrome DevTools MCP 将浏览器调试信息直接输入 AI
直接粘贴 API 文档——不要假设 AI 记得任何东西
注意 token 上限，但要把有限的上下文窗口用到极致
Claude Skills 将重复提示打包为可复用的模块化能力，实现一致的上下文感知输出
用注释和规则主动引导 AI——在代码片段前标注「这是 X 的实现，需要扩展做 Y，注意不要破坏 Z」
上下文不足是 AI 编程中最常见的失败原因。Osmani 的策略可以概括为两个字：「塞满」。把相关的代码文件、类型定义、API 文档、错误日志全部喂给模型。即使你觉得 AI 应该「知道」某个库的用法，也要直接粘贴最新版文档，因为模型的训练数据可能已经过时。当然，token 是有限的，所以需要策略性地选择「塞什么」——优先提供直接相关的接口定义、依赖关系和已有代码模式。此外，Osmani 特别推荐 Claude Skills——它们将过去脆弱的重复提示转变为持久、可复用的模块化能力，让工具在请求匹配时自动应用领域专业知识，从一次性交互转向可重复的工作流。他还强调用注释主动引导 AI：在代码片段前写上「这是 X 的当前实现，需要扩展做 Y，注意不要破坏 Z」——这些小提示大有帮助，因为 LLM 是字面主义者，会忠实遵循具体的指令。
选择合适的模型
CHOOSE THE RIGHT MODEL FOR THE JOB
本页要点
不同的 AI 模型有不同的「个性」和擅长领域。Osmani 提倡 Model Musical Chairs——当一个模型卡住的时候，切换到另一个试试。始终使用最新的 Pro Tier 模型。在长时间的对话协作中，模型的用户体验和「语气」也很重要。
不同的模型有不同的「个性」。你不会只用一把螺丝刀修所有东西，AI 模型也一样。
—— Addy Osmani
Claude Code：复杂推理和长上下文理解的首选
Gemini：Google Chrome 生态集成的天然选择
GPT：快速原型开发和通用编程任务
始终使用最新的 Pro Tier 模型——前沿模型之间的能力差距巨大
当一个模型卡壳时，立即切换到另一个重新尝试
长期对话中，模型的交互体验和「语气」影响工作效率
Osmani 将这种做法命名为Model Musical Chairs——像「抢椅子游戏」一样在不同模型间切换。核心洞察是：没有任何一个模型在所有任务上都是最优解。某个模型可能更擅长算法实现，另一个在 UI 代码上表现更好。他还特别提到了一个容易被忽视的因素：在每天和 AI 长时间对话的工作模式中，模型的交互体验和语气风格也是选择的重要考量。你会偏好和一个「沟通舒适」的 AI 搭档协作。
全流程 AI 工具
AI ACROSS THE DEVELOPMENT LIFECYCLE
本页要点
AI 不只是写代码的——它贯穿了整个开发生命周期。从克隆仓库到运行测试、修复 bug、提交 PR，命令行工具和异步 agent 可以自动化大量流程。但 Osmani 警告：目前这些工具还不适合完全无人值守的工作，必须采用有监督的方式。
6+
主流 AI 开发工具
CLI
命令行 + Agent 模式
Claude Code：CLI 模式下可克隆仓库、跑测试、修 bug、开 PR
OpenAI Codex CLI：命令行原生的 AI 编程工具
Google Gemini CLI：Google 生态下的命令行 AI 工具
Jules：Google 的 AI 编程 agent，自主规划与执行
GitHub Copilot Agent：深度集成在 GitHub 生态中
Conductor：Google 的 AI 开发编排工具
目前还不适合完全无人值守——必须「有人看着」
Osmani 描绘了一个 AI 工具贯穿整个开发生命周期的图景：从最初的需求分析到最终的代码部署，每个环节都有对应的 AI 工具。但他同时发出了清醒的警告——虽然这些异步 agent 可以自动完成很多工作，但目前它们还不够可靠，不能放任不管。正确的做法是「有监督的自动化」：让 AI 去做重复性劳动，但人类始终保持注意力，在关键节点进行审查和决策。Osmani 亲身体验过这种未来感：「你下达一个命令，比如『为 X 重构支付模块』，过一会儿就收到一个包含代码变更和通过测试的 PR——我们确实生活在未来。」他也尝试过用 Conductor 同时运行 3-4 个 agent 处理不同功能——效率惊人，但同时监控多个 AI 线程「在心理上非常累人」。
人类必须在回路中
HUMAN IN THE LOOP: NEVER BLINDLY TRUST
本页要点
永远不要盲目信任 AI 的输出。把 AI 生成的代码视为一个「过度自信且容易出错」的初级开发者的产出。进行 Code Review——包括人类审查和 AI 交叉审查。逐行检查代码。测试必须集成在工作流中。核心原则：永远不要提交你无法解释的代码。
AI 生成的代码本质上是过度自信且容易出错的。把它当作初级开发者的输出来审查，而不是高级工程师的成果。
—— Addy Osmani
AI 输出的代码 = 过度自信且容易犯错的初级开发者产出
将测试深度集成到工作流中——自动化测试 + 手动验证
既要人类审查也要 AI 交叉审查：让一个 AI 审查另一个 AI 的输出
逐行检查代码，不要跳过任何部分
当心 AI 的讨好倾向——它可能会顺着你的错误想法走
用 Chrome DevTools MCP 让 AI 直接访问浏览器运行时数据，基于实际状态精准调试
一位开发者的惨痛教训：过度依赖 AI 生成代码导致「不一致的混乱」——重复逻辑、不匹配的方法名
永远不要提交你无法解释的代码。如果你不理解 AI 生成的某段逻辑在做什么，就不要把它合并进代码库。
—— Addy Osmani
这是 Osmani 全文最核心的原则。Human in the Loop 不是可选项，而是必需品。AI 的一个危险特质是：它能写出看起来完美、读起来流畅，但实际上暗含微妙 bug 的代码——而且它会非常自信地这么做。Osmani 推荐的双层审查策略很巧妙：先让人类工程师从架构和业务逻辑角度审查，再让另一个 AI 模型从代码风格和边界条件角度再审一遍。两种视角互补，大幅降低漏检率。Osmani 还分享了 Chrome DevTools MCP 在调试中的价值——它「给你的 agent 一双眼睛」，让 AI 直接访问 DOM、性能追踪、控制台日志和网络请求，基于实际运行时数据高精度诊断 bug。他还引用了一个警示故事：一位开发者在赶工中过度依赖 AI，结果代码变成了「不一致的混乱」——重复的逻辑、不匹配的方法名、没有连贯的架构。「他意识到自己一直在构建、构建、构建，而没有退后一步审视 AI 编织出了什么。」
利用社区的 Big Daddy Rules 等规则集来约束 AI 行为——「禁止幻觉/禁止欺骗」条款
这是一个非常实用的建议。CLAUDE.md 放在项目根目录，Claude Code 每次启动时会自动读取。你可以在里面写上「使用 TypeScript strict mode」「组件使用 Composition API」「不要假设未导入的库存在」等具体规则。Osmani 强调的最关键技巧是：不要只写文字描述——要提供真实的代码片段作为范例。一段好的示例代码，比十段文字说明都管用。它能直接「引导」模型按照你期望的模式生成代码。Ben Congdon 曾表示他很震惊地发现极少有人使用 Copilot 的自定义指令——尽管效果如此显著。社区还发展出了创造性的规则集，比如 Big Daddy Rules，通过添加「禁止幻觉」「不确定时主动询问而不是猜测」等条款来有效约束 AI 行为。
测试：力量倍增器
TESTING AS A FORCE MULTIPLIER
本页要点
强大的 CI/CD 流水线是 AI 编程的安全网。ESLint、Prettier、Linters、Type Checkers 构成自动化 Quality Gates。AI 能从测试失败的输出中学习——失败日志就是 AI 最好的修复指南。这让自动化测试成为 AI 编程的「力量倍增器」。
测试不仅仅是验证——它是 AI 编程的力量倍增器。测试失败的日志是 AI 最精确的修复线索。
—— Addy Osmani
搭建健壮的 CI/CD 流水线——每次提交自动验证
ESLint + Prettier 作为代码质量的自动守门员
AI 能从工具输出中学习——错误信息就是反馈信号
测试失败 → 将日志喂给 AI → AI 迭代修复 → 形成协作调试闭环
TDD 在 AI 时代焕发了全新的价值
自动化检查让 AI 保持「诚实」——不会轻易蒙混过关
用 CodeRabbit 等 AI 审查机器人作为额外的质量过滤层——审查反馈直接转化为修复提示
部分 agent 会拒绝宣称任务「完成」直到所有测试通过——这是正确的严谨态度
Osmani 把测试称为「力量倍增器」，因为在 AI 编程场景下，测试同时承担了两个角色：验证代码正确性（传统功能）和为 AI 提供调试输入（新功能）。当测试失败时，错误消息、堆栈跟踪、断言的具体失败内容——这些都是极高质量的反馈信号。AI 读取这些信号后可以精确定位问题并修复。这就形成了一个闭环：写代码 → 跑测试 → 读错误 → 修复 → 再跑测试。自动化测试让这个循环可以高速运转。AI 编程 agent 本身也越来越多地集成了自动化钩子——一些 agent 会拒绝说代码「完成」，直到所有测试通过。CodeRabbit 等代码审查机器人则作为另一层过滤器，其反馈可以直接作为 AI 改进的提示。Osmani 的目标是加强 AI 代码贡献周围的质量关卡：更多测试、更多监控，甚至 AI 对 AI 的代码审查。
持续学习，不断精进
CONTINUOUSLY LEARN AND GROW
本页要点
AI 是能力的放大器，而不是基础技能的替代品。拥有深厚工程功底的人能从 AI 中获取最大价值。AI 能帮你接触新语言和新框架，解放人类专注于设计和架构。审查 AI 代码本身就是学习的过程。把 AI 当作你的研究助手。
AI 放大的是你已有的能力，而不是替代你需要掌握的基础。资深工程师之所以用 AI 效果最好，是因为他们知道什么才是对的。
—— Addy Osmani
AI 让你更容易接触和学习新的语言、框架和技术栈
它放大的是已有的专业能力——你的基础功力决定了收益上限
资深工程师的技能在 AI 时代价值更高，而不是更低
AI 释放人类的时间，让你专注于更高层次的设计和架构决策
认真审查 AI 的代码，本身就是加深理解的学习过程
把 AI 当作研究助手——探索不熟悉的技术领域
经常要求 AI 解释代码和修复的理由——就像「面试候选人」一样从中获取洞见
有意识地定期在没有 AI 辅助的情况下编程，保持原始技能的敏锐度
这个观点戳破了一个流行的幻想：「AI 让所有人都变成高级工程师」。现实恰恰相反——你越懂工程，AI 对你的帮助就越大。因为你知道该审查什么、什么才算好的架构、哪些边界场景需要测试。一个初级开发者可能会接受 AI 输出的看似正确但暗含隐患的代码，而资深工程师能立刻识别问题。Osmani 同时指出了一个积极的面向：认真审查 AI 的代码，本身就是一种高效的学习方式——你在审查的过程中会接触到新的编码模式和解题思路。他还推荐了一个独特的学习技巧：经常要求 AI 解释其代码或修复背后的理由，「有点像不断面试候选人关于其代码」，从 AI 的回答中获取洞见。同时他也提醒：有意识地定期在没有 AI 辅助的情况下编程，以保持你的原始技能敏锐——毕竟开发者 + AI 的组合比任一方单独都要强大，而这个组合中的开发者必须撑起自己那一半。
AI 增强的软件工程
CONCLUSION: AI-AUGMENTED SOFTWARE ENGINEERING
本页要点
Osmani 将这种工作方式定义为「AI 增强的软件工程」。经典的工程实践——先设计再编码、全面测试、版本控制、编码规范——在 AI 时代不但没有过时，反而变得更加关键。人类工程师扮演的是「导演」角色。他还推荐了他在 O'Reilly 出版的相关书籍。
AI 时代最好的工程师不是那些会使用最多工具的人，而是那些最懂得何时以及如何指导 AI 的人。人类是导演，AI 是演员。
—— Addy Osmani
经典实践（先设计再编码、测试、版本控制、规范）比以往更重要
人类工程师是「导演」——AI 执行你的创作意图
这不是替代人类工程的未来，而是人机协作的新范式
掌握正确方法论的工程师会成为 AI 时代的超级生产力
Osmani 在 O'Reilly 出版了关于 AI 编程工作流的书籍，进一步系统化了这些方法论
Osmani 在结尾回到了一个宏观视角：AI 编程并没有让软件工程的基本原理过时，恰恰相反——当你拥有一个强大但需要引导的 AI 搭档时，「先设计再编码」「写好测试」「做好版本控制」「遵循编码规范」这些经典准则变得前所未有地重要。他把这种工作模式命名为「AI 增强的软件工程」，强调的是「增强」而非「替代」。人类工程师的角色从「码农」升级为「导演」——你定义愿景、把控质量、做出关键决策，而 AI 负责执行和加速。
原理解析：规格驱动
DEEP DIVE: SPEC-DRIVEN PRINCIPLES
补充解析
深入剖析「规格先行」和「小步迭代」背后的工程原理，理解为什么这两个原则在 AI 协作时代如此关键。
1. 为什么规格先行如此重要
AI 模型本质上是「模式匹配引擎」——它根据你的输入来生成统计上最可能的输出。如果你给它一句模糊的需求（比如「帮我写个登录页面」），模型只能猜测你想要的样子。但如果输入是精确的规格说明（框架选型、表单字段、验证规则、错误处理、响应式要求），输出质量就会发生质的飞跃。这和人类开发者面对模糊需求时的困境完全一样——需求不清，代码必乱。spec.md 本质上是在用结构化语言消除歧义。
2. 「15 分钟瀑布流」的方法论内核 「15 分钟瀑布流」这个比喻巧妙地揭示了一个转变：传统瀑布模型之所以被敏捷取代，不是因为「先规划再执行」的思路有误，而是因为在人力驱动下规划周期太长、反馈太慢。AI 彻底改变了这个等式——借助 AI 的速度，原本需要数周的需求分析可以在十几分钟内完成。瀑布模型的严谨性 + AI 的执行速度 = 全新的开发节奏。
3. 小步迭代为何能防止 AI 跑偏
大语言模型有一个内在特性：生成的文本越长，累积偏差就越大。前面的内容会影响后续的生成方向，一旦在第 50 行代码里出现了一个错误的假设，后面数百行代码都可能建立在这个错误之上。迭代式开发通过在每一小步设置「检查点」，及时截断这种偏差累积。就像导航系统每隔几公里重新校准一样，小步迭代让 AI 始终保持在正确轨道上。
原理解析：上下文策略
DEEP DIVE: CONTEXT STRATEGY
补充解析
深入分析上下文管理为何是 AI 编程的隐形竞争力，以及工具链如何将隐性知识转化为显式输入。
6. MCP 协议为何改变了游戏规则 Context7 MCP 和 Chrome DevTools MCP 的背后是 Anthropic 推出的 Model Context Protocol——一套标准化的 AI 与外部工具交互协议。这意味着 AI 不再局限于你手动粘贴的文本，而是能够主动获取实时的外部信息：最新的库文档、浏览器运行时状态、API 响应内容。这从根本上改变了 AI 编程的信息流——从「人类喂数据」转变为「AI 自主获取数据」。
原理解析：模型选择逻辑
DEEP DIVE: MODEL SELECTION LOGIC
补充解析
理解不同模型的差异化特质，以及 90% 自编写代码这一数据背后的深层含义。
7. 「模型抢椅子」的深层逻辑
每个大语言模型在训练过程中都形成了独特的「偏好」。Claude Code 倾向于更安全、更详尽的输出，GPT 在创意性任务上表现突出，Gemini 对 Google 技术栈的理解更为深入。这些不是缺陷——这是特性。就像一个优秀团队需要技能互补的成员，你的 AI 工具箱也应该多元化。Model Musical Chairs 的精髓在于：当一条路走不通时，不要死磕，换一个「思维方式不同」的模型来尝试。
8. 90% 自编写代码意味着什么
当一个 AI 编程工具能写出 90% 的自身代码时，它实际上已经跨越了一个重要门槛：自我改进的能力。这会形成一个飞轮效应——模型写的代码越好，下一个版本就越强大，然后又能写出更好的代码。Osmani 引用这个数据是为了说明一个关键转折：AI 编程已经不再是「辅助工具」的层级，而是一种核心生产力。这也意味着那些还没有系统性采纳 AI 编程方法论的工程师，正在被快速拉开差距。
9. 讨好倾向：AI 的隐性风险 讨好倾向（Sycophancy）是 AI 模型的一个已知问题——模型倾向于附和用户的观点，即使用户是错的。在编程场景中，这意味着如果你提出了一个有缺陷的设计思路，AI 可能不会反驳你，反而会顺着你的思路写出「完美实现一个错误方案」的代码。这就是为什么 Osmani 反复强调批判性思维的重要性——你不能只依赖 AI 来发现问题，因为 AI 可能会「讨好」你而忽略问题。
原理解析：测试哲学
DEEP DIVE: TESTING PHILOSOPHY
补充解析
解读测试在 AI 编程中角色的根本性转变，以及「人在回路中」原则的工程学基础。
10. 测试作为「AI 调试接口」
传统测试的首要目的是验证代码正确性。但在 AI 编程时代，测试多了一个同等重要的功能：作为 AI 的调试输入通道。当测试失败时，错误消息、堆栈跟踪、断言失败的详细内容——这些都是品质极高的「反馈信号」。AI 读取这些信号后能精确定位问题所在并生成修复方案。这就是 Osmani 称测试为「力量倍增器」的原因——它同时服务于验证和修复两个目标，效能翻倍。
11. 「永远不要提交你无法解释的代码」的工程学基础
这条原则的核心不是关于代码质量——而是关于工程责任。当你提交了一段你不理解的代码，你实际上是在向代码库中引入一个「黑箱」。未来任何人（包括你自己）在修改这段代码时，都无法预判改动会产生什么后果。在传统开发中这已经是坏习惯，在 AI 编程中更加危险——因为 AI 生成代码的速度远快于你理解代码的速度。不理解就不提交，这是一道不可逾越的红线。
12. 自动化质量检查如何让 AI「保持诚实」 ESLint、Prettier、Linters、Type Checkers 这些自动化工具构成了一道道Quality Gates——AI 生成的代码必须通过所有这些检查才能进入代码库。这就像给 AI 设置了一系列「考试」，每一道都不能跳过。没有这些自动化检查，AI 可以非常自信地产出格式不统一、类型不安全、存在潜在空指针的代码。自动化是让 AI 保持「诚实」的最有效手段。
原理解析：工作流整合
DEEP DIVE: WORKFLOW INTEGRATION
补充解析
从宏观视角理解各个原则如何形成一个有机的整体，以及「AI 增强工程」这一理念的长远意义。
13. 规则定制为什么是最被低估的环节 CLAUDE.md 和 GEMINI.md 这类规则文件看起来只是配置，但 Osmani 认为它们是 AI 编程中投资回报率最高的环节。道理很简单：一份好的规则文件会在项目生命周期内被执行成千上万次。你花 30 分钟精心编写的一条规则，可能会在未来几个月的每一次 AI 调用中持续发挥作用。这是一种「一次投入、持续回报」的高杠杆行为。
14. 版本控制在 AI 时代的新角色 Git 在 AI 编程工作流中的角色发生了微妙但重要的升级。传统上 Git 主要用于记录变更历史和支持团队协作。在 AI 时代，它增加了两个新功能：一是作为 AI 协作的「安全网」（游戏存档点），让你可以随时撤销 AI 的错误修改；二是作为「实验平台」，通过 Worktrees 和分支，让多个 AI 在隔离环境中并行尝试不同方案。
15. 「AI 增强工程」的长期愿景 「AI 增强的软件工程」不是一种临时策略，而是软件行业的新范式。Osmani 的核心论点是：AI 并没有让工程原理过时——恰恰相反，当你拥有一个强大但需要引导的 AI 搭档时，经典工程实践（需求分析、架构设计、测试验证、版本管理、编码规范）的价值反而在提升。最终，那些同时精通工程基本功和 AI 协作技巧的工程师，将定义下一代软件开发的标准。
完整工作流总览
THE COMPLETE WORKFLOW TIMELINE
本页要点
将 Osmani 的全部原则串联成一条完整的日常 AI 编程工作流。从规格撰写到代码提交，每一步都有对应的最佳实践和工具选择。
Phase 1 · 规格先行
用 AI 头脑风暴，撰写详尽的 spec.md：功能边界、边界场景、验收标准、技术约束
整个工作流的核心逻辑可以提炼为五个字：「明确→充实→选择→执行→验证」。先明确要做什么（spec），再确保 AI 拥有足够的信息（上下文），然后选择最合适的工具（模型），以最小单元执行（小步迭代），最后严格验证每一步的产出（审查+测试+提交）。这不是一个线性过程——每个阶段都可能循环回前一步。核心纪律：永远不要在未完成验证的情况下推进到下一步。