AI Native 团队完整开发落地手册
这份手册以 Anthropic《The AI-native SDLC Playbook》（Louis Claxton，2026-08-21）为骨架，补上我们自己团队跑下来踩过的坑：产物链、工作环境、验证系统、Eval、生产门禁，最后一个真实 bug 从头走到尾。命令和配置可以直接抄，路径和版本号按你仓库的实际情况替换。
Spots 
2026 年 8 月，Anthropic 发布《The AI-native SDLC Playbook》。它讨论的不是模型能写多少代码，而是另一个更现实的问题：…
2026 年 8 月，Anthropic 发布《The AI-native SDLC Playbook》。它讨论的不是模型能写多少代码，而是另一个更现实的问题：Agent 已经能在几小时内生成大量代码，规划、审查、部署却还是人速，代码快了，项目为什么没有一起快。 传统 SDLC 的每一环——PRD、估时、评审、审批——都诞生在 " 写代码最贵最慢 " 的年代。构建从几周压到几小时之后，原文总结出三个后果： 瓶颈转移。计划、审查/测试、部署位于构建两侧，仍按人的速度运行 控制失配。人写代码时逐行审查是合理的，Agent 写了大部分 diff 之后跟不上产量，要么审查队列堆积，要么代码带着未审查状态上线 治理成本上升。例外仍要走每周或每月开一次的委员会审批，接不住放大的代码量 所以要改的不是写代码这一步，是从想法出现到线上反馈回来的整条工作链。下面把原文的方法拆成可执行步骤。 AI Native SDLC 把线性流程改成循环，贯穿循环的是一条提交产物链：
每个阶段结束时提交一个产物进版本控制，下一阶段从读取它开始。产物被接受这件事本身就是触发器：intent.md 被接受触发设计，spec.md 被批准触发…
每个阶段结束时提交一个产物进版本控制，下一阶段从读取它开始。产物被接受这件事本身就是触发器：intent.md 被接受触发设计，spec.md 被批准触发 Plan Mode，PR 合并触发流水线，生产指标越界写出新的 intent.md，循环回到起点。
聊天记录撑不起这个位置。一次会话结束后，关键判断埋在几十轮对话里，下一个 Agent 拿不到同样的上下文；而提交的文件把当前结论固定下来，附带作者、时间和修改历…
聊天记录撑不起这个位置。一次会话结束后，关键判断埋在几十轮对话里，下一个 Agent 拿不到同样的上下文；而提交的文件把当前结论固定下来，附带作者、时间和修改历史。这条 commit 链同时就是审计记录：谁提出了什么、Agent 生成了什么、谁批准了它。 快循环保证这一次做对了，慢循环保证下一次不再错。后面每一节都落在这两个循环上。 原文给了一条务实建议：不必把 Jira 或 Figma 全部迁成 Markdown，但每种产物必须指定唯一的事实来源，其他系统只存副本或链接，最低限度是互相记录 ID 和 commit SHA。 流程从 intent.md 开始。它写得糊，后面全糊——AI 会把定义里的模糊处用它自己的猜测填满，而且填得很快。 方案式定义把实现选择提前锁死了：为什么是 CSV？为什么是按钮而不是定时邮件？检验办法是把陈述里的实现词删掉，看问题还成不成立。" 加导出按钮 " 删掉按钮就不成立了，说明它写的是方案。 " 期望的行为 " 这一节是分水岭：每一条都必须能翻成一个测试。" 提升体验 " 不是定义，是不可验收的愿望。 边界（不做什么）。没有边界，AI 会顺手把相关的都做了，然后进你的审查队列 约束（不能动什么）。技术债、遗留系统、性能红线全在你脑子里，AI 一无所知 反例（失败长什么样）。比如 " 导出文件用 Excel 打开乱码（UTF-8 BOM 问题，上次踩过）"。反例把抽象要求变成可判定的对错，约束力常常强于正面描述 自己列的要素永远是自己已经想到的，AI 问出来的才是你漏掉的。 我想解决 [粗糙描述]。先不要提任何方案。你的任务是问我问题，一次最多 5 个，直到你能向一个没参与的工程师完整转述这个问题。从影响面最大的信息缺口问起。 我想解决 [粗糙描述]。先不要提任何方案。你的任务是问我问题，一次最多 5 个，直到你能向一个没参与的工程师完整转述这个问题。从影响面最大的信息缺口问起。 用你自己的话复述这个问题，然后单独列出：你目前做出的所有假设（无论多小），以及哪些信息你仍然没有。
用你自己的话复述这个问题，然后单独列出：你目前做出的所有假设（无论多小），以及哪些信息你仍然没有。 这一步的价值在假设列表。AI…
用你自己的话复述这个问题，然后单独列出：你目前做出的所有假设（无论多小），以及哪些信息你仍然没有。 这一步的价值在假设列表。AI 不会把空白留白，它会默认填上；假设列表就是把它的默认填充摊到桌面上让你逐条否决。 基于以上讨论生成 intent.md。规则：保留 " 开放问题 " 一节；你做出的每个假设必须显式标注，不允许写进正文装成事实；不包含任何实现方案。 基于以上讨论生成 intent.md。规则：保留 " 开放问题 " 一节；你做出的每个假设必须显式标注，不允许写进正文装成事实；不包含任何实现方案。 新会话测试：开一个全新会话只给它 intent.md，它能准确复述问题吗。它就是未来读这份文件的 Agent 方案零渗透：文件里还有没有实现词（按钮、接口名、表结构） 没确认的事项写进 " 开放问题 "，让后续阶段带着它们去找决策者，比让 AI 在生成时静默替你拍板好得多——静默的决定你永远不会审查。 三、规格与计划：spec.md 与 plan.md 通过审核的 intent.md 交给 Claude 生成 spec.md，生成时读取团队的品牌、安全、合规、UX 规则（以 Skill 形式存在，见第四节）：
Read the attached intent.md and produce a requirements
Read the attached intent.md and produce a requirements and design spec. Apply the skills available to you. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.
Read the attached intent.md and produce a requirements
Read the attached intent.md and produce a requirements and design spec. Apply the skills available to you. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies. intent 里的开放问题是标着，还是被偷偷决定了 Agent 无法满足的要求、规则之间的冲突必须在这里标出来，在工程介入之前解决，不能等开发阶段靠工程师猜。
原文没明说、但实践中很关键的一点：文档生产的价值在下降，产品判断的价值在上升。AI 能快速生成 PRD 和设计规格，产品经理的精力就要移到 "…
原文没明说、但实践中很关键的一点：文档生产的价值在下降，产品判断的价值在上升。AI 能快速生成 PRD 和设计规格，产品经理的精力就要移到 " 问题是否值得解决、约束有没有遗漏、生成结果是否满足用户需求 " 上。实现越快，一个错误判断进入代码的速度也越快。 工程师拿到通过审核的 spec.md 后，构建仍然不会立即开始。在 Claude Code 的 Plan Mode 里： 给 Claude intent.md 和 spec.md，要求生成实施计划：改哪些文件、按什么顺序、用什么测试证明结果 追问三个问题：这个改动可能破坏什么？风险最高的步骤在哪？你考虑过又放弃的方案是什么，为什么？ 接受标准很朴素：一个没有参与前面对话的工程师，只看 plan.md 能否独立完成任务。不能就继续改。
这是全流程性价比最高的审查点。Plan Mode 下 Claude 只能读代码不能改文件，设计审查发生在代码生成之前，此时改方向还只是改一份文档；plan.md…
这是全流程性价比最高的审查点。Plan Mode 下 Claude 只能读代码不能改文件，设计审查发生在代码生成之前，此时改方向还只是改一份文档；plan.md 的每次修改和最终接受者都留在 git 历史里。实施偏离计划时，在同一 commit 里更新 plan.md（可以用 hook 强制同步）。
计划通过后 Agent 开始实施。等 CLAUDE.md 和测试能力成熟之后，常规任务可以进入 Auto…
计划通过后 Agent 开始实施。等 CLAUDE.md 和测试能力成熟之后，常规任务可以进入 Auto Mode，工程师不再逐次确认文件编辑，注意力转向审查完整产物。适用条件是三条同时成立：规格清楚、影响范围小、已有测试覆盖。高风险任务仍要逐步确认。团队不会因为 Agent 能连续工作就立刻放开所有权限——自主程度跟着护栏成熟度走。 Agent 的工作环境由三层配置构成。写错地方，效果是要么重要约束被淹没，要么根本不被执行。先做分流： 判断口诀：每次都要放 CLAUDE.md，特定任务才要放 Skill，必须执行放 Hook，只是背景放 docs 加指针。 CLAUDE.md 的定位是 " 一名新成员第一天需要知道的一切，且仅仅是这些 "。用 /init 生成初稿，然后裁剪到一页以内——每次会话开始都会读它，过期内容直接占用上下文。 规则写成三段：规则本身、一句为什么、怎么验证。" 为什么 " 不是装饰，它让 Agent 能在新场景下泛用这条规则，也防止三个月后有人清理时误删： 同一种错误第二次出现时立即写进去。第一次纠正，第二次固化 每月审一次，已不再犯的规则删掉，否则它在稀释重要规则的权重 CLAUDE.md 进 git，修改走 PR，和代码一样被 review。Agent 遵循的指令本身就是可审计的。 某类操作有固定的多步流程，又不是每次会话都发生时，从 CLAUDE.md 升级成 Skill：
News
AI Native 团队完整开发落地手册
这份手册以 Anthropic《The AI-native SDLC Playbook》（Louis Claxton，2026-08-21）为骨架，补上我们自己团队跑下来踩过的坑：产物链、工作环境、验证系统、Eval、生产门禁，最后一个真实 bug 从头走到尾。命令和配置可以直接抄，路径和版本号按你仓库的实际情况替换。
@spots
Source: Juejin