AI 能把代码写出来，这件事已经没有争议了。但从「一句需求」到「能跑的代码」中间还隔着好几段：需求要落成文档、文档要落成模型、模型要落成规格、规格要落成任务。这几段在多数团队里要么没人写，要么写了也没人看，要么写完了下次重来一遍。
我们拿一个云管平台 MVP 试了一遍：从三方访谈到可运行代码，每一段的产出和 prompt 都留在仓库里，整条链路在 Claude Code 里可以按阶段重放。
仓库：https://github.com/ForceInjection/ai-native-devops，案例在 cloudpilot-case/。
下面先说书，再说我们的案例是怎么实现的，最后把两边的账对一遍，聊聊这本书适合谁读、怎么读。
一、先说这本书
书的作者陈康贤，十余年电商技术背景（手机淘宝首页、飞猪酒店交易、双十一核心链路），曾任阿里巴巴高级技术专家，上一本书是《大型分布式网站架构设计与实践》。
这几年他转到了 AI 工程：推动 Claude Code 在团队里规模化落地，把大模型和 Agent 用到商品与品牌信息自动审核、商品素材自动生成这类生产场景。
这个背景决定了书的写法：一个把 AI 编码工具推进团队、并要求它上生产的人，写下来的落地笔记。
全书五篇，376 页：
第三篇讲的 OpenSpec（把需求写成 Requirement 加 Scenario 的规格工具）和我们这边对得上：我们一直在用的 OpenSpec-practise 仓库和 CloudPilot 案例里的 OpenSpec 工作区是同一套方法。读这一篇的时候，两边可以对着看。
读法建议是「按目录顺序读，边读边打开终端跟着做」，理由是这不是一本可以跳着读的参考手册。下面两节，先按它的顺序把方法论过一遍，再把我们这边的实战摊开。
二、书里的核心概念：四样东西，一个地基，一条底线
2.1 四样东西，各管一件事
CLAUDE.md 管长期记忆。 它是每次会话自动加载的持久指令，分三层：全局层是个人偏好，项目层是技术栈与目录约定，目录层管模块特有规则，越靠近代码的约定优先级越高。
书里对「写什么」给了一条很硬的判据：项目 CLAUDE.md 的价值，来自「项目做了特定选择、而 Claude Code 不知道」的地方。 不是把 README 搬进去，而是写四类东西：技术栈里「有多种选择、我们选了这种」、目录结构与分层约定、禁止事项、历史决策。
其中禁止事项这一段，书里的原话是「CLAUDE.md 里投入产出比最高的部分」，给了一组具体写法：
- 不要在 Controller 层直接调用 Repository，必须通过 Service 层调用
- 不要使用 System.out.println，统一使用 SLF4J logger
- 不要引入新的 Maven 依赖，先和我确认
- 不要修改 src/lib/ 目录下的文件，除非明确讨论过
书里同时给了不写会怎样：它会在项目规定用 SLF4J 的情况下坚持 System.out.println，会在约定走 Service 层的项目里直接在 Controller 里查数据库，会随手引入 java-jwt，而项目用的却是 jjwt。
模型会用它认为「合理」的方式解决问题，而「合理」未必符合你的项目约定。它不是在捣乱，它只是不知道。
Skill 管流程资产。 一个 Skill 就是一个 SKILL.md，放在 .claude/skills/<名称>/ 下。它的精妙之处在渐进式披露：平时只加载每个 Skill 的一行 description，请求匹配上了才读正文。这意味着你可以攒几十个 Skill，平时几乎不占上下文。
书里给了一个可以直接抄的 /review 示例，description 是这么写的：
description: 多维代码审查。当用户要求审查改动、检查 diff，或在发 PR 请求前自检时使用。
argument-hint: "[可选重点，如 security / performance]"
注意它写的是用户会怎么说（「审一下改动」「看下 diff」「发 PR 前自检」），而不是生硬的「代码审查」。这一句差异决定它能不能被自动触发。
正文里还有一行动态注入，技能被激活时先执行命令把改动内容替换进来：
!'git diff HEAD'
等你看到审查结果时，diff 早就在上下文里了。
子 Agent 管分工。 它存在的理由是上下文窗口有限，注意力会随职责数量稀释。机制是：无先验上下文（只看任务描述，不看主对话历史）、独立上下文窗口、独立工具权限、可配 git worktree 隔离。
书里把成本也算清楚了：三个各需 15 分钟的子任务并行，总耗时从 45 分钟压到约 18 分钟（余下的是任务分解、上下文传递、结果整合的协调开销），代价是三倍 token。判断标准是：单个子任务预计超过 20 分钟、且子任务之间弱依赖时，才值得并行。
Hook 管硬约束。 CLAUDE.md 是软约束，靠模型自觉遵守；想让某件事无条件发生，得用 Hook。书里给的场景是自动格式化、保护敏感文件、改完跑相关测试，以及一条经验红线：Hook 同步执行，2 秒内返回，超过 5 秒会明显拖慢响应，全量回归这类耗时检查别塞进去。
书里把退出码总结成「Hook 是把关人，不是拦截器」。这个说法只对了一半：按 Claude Code 的文档，退出码 2 是硬拦截（PreToolUse 的「拦住对 .env 的写入」靠的正是它），其余非 0 才是非阻塞错误。书里那三个场景里最实用的那个，恰好依赖它没讲的那一条。（我们一个都没配，原因见第四节。）
2.2 地基：上下文是有限资产
书里用了一个比喻：把上下文窗口想象成一张固定大小的桌面，每读一个文件、每聊一轮就往上面摞一摞纸。桌面不会变大，纸摞得越高，抽出有用的那张越难。
由此推出一条反直觉的事实：Claude Code 在两次回复之间没有记忆。 每按一次回车，整段对话会被重新打包发给模型，它从头读一遍再生成下一句。所以问题不是「满了才出现」，而是有效信息密度一直在降。
书里列了四个污染症状，前两个出现就该动手：
处置方式是四个分支：
2.3 底线：判断权不能外包
书里在最后一章点了三类任务，说它们不是「模型能力不足」，而是其核心就是判断：架构选型（要权衡团队能力、业务预期、运维成本，这些约束只有当事人了解）、安全评审（它能扫常见漏洞模式，但权限设计是否符合团队的安全要求必须由人签字）、产品决策（它不知道你的核心用户是谁、竞品在做什么）。
书里给的正确用法是一句话的 prompt：
你：梳理单体架构 vs 微服务架构的技术利弊，不需要给出推荐，我自己来做决定。
书里讲的这些合起来，回答的是「工具怎么配」。但配好之后还有个问题：装进什么流程？书里第 5 篇用几个端到端项目给了示范，我们这边则是把它装进了一条八阶段的流程。
三、我们的实战：一个云管平台 MVP 的八阶段
八阶段里每一段的跑法都是同一个组合：一个执行者（主 Agent 或专用 Subagent）、一组为该阶段定制的 Skill、一份规定了产出形状的契约。案例里的专用 Subagent 是 ddd-modeler 和 openspec-author，分别负责建模和规范两段。这个组合在下面几段里会反复出现。
3.1 链路
ai-native-devops 这个仓库提了一个八阶段框架：
cloudpilot-case/ 是照这个框架走下来的一条实录：一个私有云资源自助管理的 MVP，管云服务器、数据库、对象存储、缓存、负载均衡的申请、审批、配置、回收。案例覆盖了从业务调研到实现工作流的七段：
这条链路可以重放。仓库里有一个 Claude Code skill 叫 cloudpilot-demo，按阶段依次执行、每阶段停下来等人确认；openspec 和 ocr 两个命令行工具分别负责规范校验和代码评审。
产出都进了仓库，不是聊天记录，只有 P7 那段代码没入库。下面挑几段真实材料。
3.2 一条 prompt 长什么样
案例 README 把主要工件的生产 prompt 贴了出来，7 个工件里覆盖 5 个，可以逐字重放。第一段是这样的：
角色：业务分析师。
输入：${meeting_transcripts}（三场访谈：研发负责人 R-Lead、运维 OPS、财务 FIN）。
任务：综合访谈记录，输出 markdown，包含：
1. frontmatter（阶段 / 上游输入 / 下游消费 / 责任人 / AI 草稿置信度）
2. 三方访谈正文（角色 / 时长 / 关键 Q&A 摘录，保留原话特征）
3. 痛点清单 P1~PN（频次 / 影响 / 来源）
4. 功能种子 F1~FN（映射到痛点，标注 must-have / nice-to-have / 后续迭代）
5. 范围声明（in-scope / non-goals）
约束：仅人工已表达的诉求入表；不要臆造功能。
输出：写入 ${output_file}（默认 ./01-interview-notes.md）。
这段 prompt 里有两处细节。
成品形状在 prompt 里就确定了，连 frontmatter 要写哪五个字段都写明了。这不是让模型自由发挥、人来整理，而是先规定输出结构再让它填。
最后那句约束：「仅人工已表达的诉求入表；不要臆造功能」。访谈阶段最怕的就是模型替客户补需求，把「他没说但听起来合理」的东西写进痛点清单。整段 prompt 里，这一句是专门堵这个洞的。
（这套材料里编号多套并用：P1–P8 是框架阶段，P1~PN 是访谈列的痛点，FR-NN 是 PRD 里的功能需求，F1~FN 是访谈列的功能种子。）
这和第二节里那条「把禁止事项写进 CLAUDE.md」是同一个动作：把模型默认行为里你不想要的那一种，提前点名。区别只在生效范围：写在 CLAUDE.md 里是全仓库生效，写在 prompt 里只对这一份产出生效。
3.3 从一条不变量到一条规格
领域建模那一步由 9 个 ddd-* Skill 串成五个阶段跑完：发现 → 战略 → 战术 → 验证 → 规范。这五步产出子域划分、限界上下文、领域事件等一批东西，其中对下游约束力最强的是 8 条编号不变量。取其中一条：
到了规范阶段，它变成这样一条 Requirement：
### Requirement: 状态转换合法路径（IV-2）
状态转换 SHALL 仅遵循：`PENDING → APPROVED`、`PENDING → REJECTED`、
`APPROVED → PROVISIONED`、`PROVISIONED → RELEASED`。
#### Scenario: 拒绝后进入 REJECTED 终态
- **GIVEN** `ResourceRequest.status = PENDING`
- **WHEN** 审批人调用 `RejectRequest(requestId, approver, reason)`
- **THEN** `status = REJECTED`
- **AND** 发布 `RequestRejected` 事件
- **AND** 后续任何命令对该资源申请无效
标题里的 （IV-2） 就是上表那条不变量，我们叫它回指。规范阶段有一条硬规则：不新增模型未提及的概念，有缺口先回溯到建模阶段。所以这条链是单向可查的：从 spec 里任何一个编号，都能退回去找到模型里的同一条不变量。
SHALL 也不是随手写的。产出契约规定规范性语言只许用 SHALL/MUST，禁用 SHOULD/MAY，理由是后者留了模糊空间，模型和人都容易和稀泥。
3.4 什么时候算通过
建模流水线的第四阶段是验证，交出来的是一张验收表：
最后一行是这套流水线的刹车：验证不达标回溯到战术设计，边界有争议回溯到战略设计。这次没触发，但报告写明了下次会触发的条件：「如后续 FR-11（到期告警）加入，需回到 @ddd-aggregates 加 RequestExpiry VO 与 IV-9 不变量」。
3.5 spec 怎么变成代码
规范阶段产出三份 spec，代码桥接阶段给出一张映射表，逐条 Requirement 落到具体的代码文件和测试文件：
（表为节选，源表列到 IV-6。）对照的口径是：每个 ### Requirement: 对应一个或多个实现文件，每个 #### Scenario: 对应一个或多个测试用例。这张表是「Spec 是单一事实源」唯一可验证的地方：需求、代码、测试三者之间能对得上号。书里第三篇讲的 OpenSpec 是方法，落到我们这边就是那三份 spec；这张映射表补的是它和代码之间缺的那一环。
这张表原本还有一行对不上。仓库后来发现，代码桥接文档里的 IV-3、IV-5、IV-6 三个编号和领域模型里的对不上：模型里 IV-3 是「审批超时告警」，桥接文档写成了「REJECTED 终态不可再激活」。6 号文档为此发了一条勘误，写明「编号冲突以模型为准」，ADR 里也记了一笔。
这件事恰好说明 3.3 那条纪律为什么值钱。编号一旦能被回查，写错就会被发现；如果只是文字描述，这种错会一直躺在文档里没人知道。
3.6 每个工件的抬头
案例里多数工件都以一段抬头开头。以 02-prd.md 为例：
阶段：AI-Native DevOps P1 愿景 → PRD
上游输入：01-interview-notes.md痛点清单 P1~P6 与功能种子 F1~F6
下游消费：cloudpilot-mockup.html（UI/UX）、03-ddd-modeling.md（领域建模）
责任人：R-Lead（业务方）· AI 出草稿，三方评审定稿
AI 草稿置信度：高（基于完整访谈记录提取，结构化字段已对齐）
config.yaml 要求所有生成的 markdown 都带这五个字段，实际执行到位的只有 PRD、proposal、tasks 这几份，其余几份的抬头只写了阶段和上下游，没标置信度。置信度本身分三档：高（>90% 结构化字段已对齐）、中（70–90% 需人工补充）、低（<70% 仅作为讨论起点）。下游拿到一份工件，先看这一行就知道该以什么姿势使用它。
四、对照：书里讲的四样，落在 CloudPilot 的哪儿
前四条对得上，但落到具体用法上，有三处和书里不一样：有多的，也有少的。
子 Agent 的用法和书里不同。 书里讲的并行多维审查，是拿三个子 Agent 换时间；我们这两个是拿各自独立的上下文窗口换专注：建模那个只做建模，规范那个只读模型。这不是并行的收益，是分工的收益，书里那句「单个子任务超过 20 分钟才值得并行」的成本判断在我们这里不适用。
有一处得说清楚：这两个 Subagent 的定义在本机 .qoder/agents/ 下，跑在 Qoder 上，不在 Claude Code 里；cloudpilot-demo 那个 skill 走的才是 Claude Code 的路径，它驱动的是主 Agent 加 9 个 DDD Skill。
上下文管理落在了两处。 书里讲的主要是会话内外的处置（/clear、/compact，以及每天收工写一份 session-notes.md、第二天从快照重开）；我们在会话外另加了一层：一份把产出契约写死的 config.yaml，管 proposal、spec、design、tasks、抬头、命名六类规则。它的作用是把「这个工件该长什么样」从对话里挪进文件里，下一轮谁来跑都按同一份规则。
工件追溯是我们加的。 3.3 里那个 （IV-2）、3.5 那张映射表、3.6 那段抬头，都属于这一条。书里没有，但它和书里「判断权不能外包」是同一个方向：判断交给人，但人得看得见哪儿是 AI 的草稿、草稿的可信度有多少、这条需求是从哪儿来的。
Hook 我们一个都没配。 书里给的三个场景（自动格式化、保护敏感文件、改完跑测试）对这个案例关联不大，但 2.1 里那两条工程细节我们之前完全没概念，真配的时候大概率会踩。
最后是一处说明：案例那张生产表里，两个 Subagent 的定义和全部 10 个 Skill 都不在仓库里，大家想学习请提 issue，博主后面整理后再开源出来。
五、这本书适合谁读
如果你已经在用，但东西留不下来，比如每次都要重新交代项目背景，或者上一个项目的经验带不到下一个，那就从熟练篇开始。CLAUDE.md 那一章解决的就是这件事。
如果你想搭一条能上生产的链路，扩展篇（自定义命令、Hook、MCP、Skills 与子 Agent）是重点，读完再回来看 cloudpilot-case/ 里那张可重放的 prompt 表。
书里的示例代码以 Java 为主，兼顾 TypeScript 与 Swift。方法本身不绑语言，难的是把例子在自己的工具链里重搭一遍。
最后说回这本书，它把最重的一节留给了「什么时候不该让它自己决定」，而不是提示词技巧。这一点和我们做完这个 MVP 之后的体会一致：真正要提前设计的不是提示词，是判断权交出去多少、草稿的可信度怎么标、规格该在代码之前还是之后。
书目
