Anthropic 发了一套企业级 AI 开发流程，我一个人跑的系统照进去，能完整对上的只有两条
昨天 Anthropic 发了一份手册，讲怎么把软件开发流程改造成 AI 原生的。面向的是有产品负责人、技术负责人、平台团队和 CI 的组织。
我没有团队。我一个人维护一套内容系统，两个多月，三个仓库。写这篇时是 86 加 32 加 4 共 122 个提交，其中最后一个就是这篇。
我把手册六个阶段逐条对了一遍。第一遍数下来是四条已有、两条对不上，看着挺好。
收紧标准再数一遍，完整对上的只有两条，两条只对上一半，两条完全对不上。差别在于我做的是内容生产不是软件交付，有些机制看着像，其实不是同一件事。
对不上的那几条比对上的更值得说。
以下核对日期 2026-08-22，来源是 claude.com 原文，发布日期 2026-08-21，作者 Louis Claxton。
手册的核心其实只有一句话
它讲了六个阶段，但真正的机制只有一条。
每个阶段结束时，把一份产物写进版本控制。下一个阶段读这份产物才开始。
手册管这个叫 committed artifact。六份产物依次是 intent.md、spec.md、plan.md、代码改动和它的测试、PR 和审查发现、事故记录。
为什么要这样。手册的原话是，代码已经不是瓶颈了。AI 写代码快到一年前想不到的程度，而代码周围的流程还是老样子。评审、审批、交接、政策，全都按人的速度跑。结果是构建这一步塌缩成几小时，左右两边还是几周。
它给的解法是把审查的对象从代码换成产物。人不必跑得更快，改的是看什么。人不再逐行看代码，而是在每个关卡看上一阶段交出来的那份文件。
这个思路我认，因为我已经这么干了两个月，只是当时不知道它叫这个名字。
逐条对照
| 手册说的 | 我的系统 | 判定 |
| :--- | :--- | :--- |
| Plan 写 `intent.md`，人可读、机器可执行 | `success-criteria.md`，动手前写 | 完整对上 |
| Design 标准编码成 skills，在 git 里版本化 | 78 个技能，741 个文件在 git | 完整对上 |
| Build 机构知识做成 `CLAUDE.md` 和 skills | `CLAUDE.md` 12 行加 `AGENTS.md` 46 行加 `RULES.md` 121 行 | 对上一半 |
| Test 持续 eval 织进实现过程 | 一个校验器 55 项检查 | 只是类比 |
| Deploy hooks 作为审批关卡，PR 双向审查 | 有 hook，没有 PR | 对不上 |
| Maintain 控制带突破自动写回成新的 `intent.md` | 写回是有的，自动不是 | 对不上 |Build 那行为什么只算一半。 手册的 Build 是两件事，机构知识做成文件，以及测试和代码由 AI 生成。前半我有，后半我根本不产出代码，谈不上对上。
Test 那行为什么只算类比。 手册说的持续 eval 是在测代码对不对。我的 55 项检查测的是规则文件在不在、技能有没有漂移、发布记录有没有漏，是系统自检不是代码测试。形状像，测的东西不是一回事。
把这两条从「已有」里拿出来，是我写完初稿又数了一遍才做的。第一遍我很想说四条。
完整对上的第一条，动手前写下要证明什么
手册的 Plan 阶段说，想法不要等别人来整理，用提出者自己的话写成 intent.md，进版本控制，下一阶段直接读。
我这边的等价物是 success-criteria.md。目前四份，分别 61、81、44、45 行。
这个习惯是被坑出来的。8 月 14 日那次实测我漏了这一步，结论变成边做边收敛，事后自己都说不清哪些判断是预先定的、哪些是看到结果才补的。那次我把「成功标准没在实验前写」写进了限制。
下一篇我补上了。再下一篇又补上了。
它防的是一件很具体的事。 测完之后，人会不自觉地把测出好结果的那条划进「本来就想验的」。先写下来，这条路就堵死了。
完整对上的第二条，规则是文件不是习惯
手册说 Build 阶段的机构知识要做成版本化、机器可读的 CLAUDE.md 和 skills，别留在人脑子里。
我这边是三层。CLAUDE.md 12 行只管加载顺序，AGENTS.md 46 行管路由，RULES.md 121 行是唯一的规则真源。加上 CONTENT_SOP.md 181 行的执行流程。
关键不在有没有这些文件，在它们是不是真的被读。我这套的入口是 CLAUDE.md 指向 AGENTS.md，AGENTS.md 再按当前任务决定读哪几个。按需加载，不是每次全读。
78 个技能全在 git 里，741 个文件。这一条能对上是因为我 8 月初栽过一次。两个技能建好了，四个入口的链接都做全了，源头却从来没进过版本库。远端一个字节都没有。
只算类比的那条，自动检查必须会失败
手册的 Test 阶段说，把 QA 从阶段边界的关卡改成织进实现过程的持续 eval。
我这边是一个 PowerShell 校验器，55 项检查。它查规则文件在不在、技能有没有漂移、备份哈希对不对、发布记录有没有漏。
写这篇的今天，它有 3 项失败 1 项警告。 我没关掉，也没等修完再写。
先说清楚这条只算类比。手册的持续 eval 测的是代码对不对，我这 55 项测的是规则和记录，不是同一件事。但里面有个做法可以直接搬。
一个只会报绿的检查器和一个坏掉的检查器，输出长得一模一样。所以我给每一项新检查都做双向验证。造一个该失败的样本，确认它真的失败，再撤掉，确认它转绿。上周加两项检查时，我先放了个假技能进去让它报错，再删掉。
不这么做的话，你永远不知道那个 55 是真的 55，还是 55 个空转。
对不上的第一条，审查只有半边
手册的 Deploy 阶段讲双向审查。Claude 审别人的 PR，也回应自己 PR 上的审查意见。人的注意力上移一层，只看改动是否符合计划，以及代理标出来的地方。
我有 hook，一个 3,231 字节的脚本，会话启动时自动跑校验器，有失败就提示。今天开工时它就报了那 3 项。
但我没有 PR。 一个人的仓库，我提交，我推送，没有第二双眼睛。
手册说人的注意力移到关卡上，前提是关卡那头站着另一个人。我这边关卡两头是同一个人。
这不是小差别。我前两篇文章，每篇都靠自己反复检查抓出错误，一篇 11 处，一篇 9 处。
这里要说准。自动检查抓到了一部分，我有个文风脚本，专查提示性冒号、翻案句式和几十个禁用词，这篇它就抓了 14 处。但它只看句子的形状。
那 11 处和 9 处里的事实错误，一处都不是脚本抓到的。 技能数写成 74 实际 76，把 45 张图说成「已发布的封面」而其中八张根本没发过，预先登记了七条声明正文只列六条。这些全是我改完再读一遍读出来的。
其中最狠的一处，是我在一段专门讲自己有多严谨的文字里写错了事实。
自己审自己会漏，这是结构性的，不是态度问题。 手册没给单人方案，因为它面向的不是单人。
我目前的替代办法是把检查次数堆上去，同一份稿子查三遍，每遍换一个角度。先查数字和事实，再查逻辑和范围，最后按一张固定的标准表逐项核。有用，但明显不如换个人看一眼。
对不上的第二条，写回是手动的
手册的 Maintain 阶段是整个环的闭合点。监控发现控制带被突破，脚本自动叫起 Claude，它诊断、写出新的 intent.md，然后重新走一遍前面五个阶段。全程没有人在调用路径上。
我这边写回确实在发生，而且是我这套系统里最有价值的部分。举个真实的例子。
8 月 7 日我取了两条内容的阅读量，441 和 139，据此判断某类主题触达低，并改了选题方向。8 月 14 日同来源重取，同样两条是 3,827 和 4,624，是我账号里最高的两条。
差在哪里。441 和 139 是发布 3 小时和 27 分钟的读数。
我把取样时长当成了主题差异。那次之后我在规则文件里加了一条。快照必须同时记录「该内容当时已发布多久」，未成熟读数不得用于主题、格式或策略判断，跨内容对照必须同龄同来源。
这就是手册说的「控制带被突破，写回成新的规则」。机制对上了。
但触发它的是我自己起了疑心，不是任何自动的东西。 没有监控在盯，没有脚本会因为读数取样时长不一致而报警。如果那天我没顺手重取一次，那条错误的选题方向会一直执行下去。
自动化那一半，我没有。
一个人能抄的和不能抄的
手册整体是给组织写的。它的六个机制里，有几个跟人数没关系，有两个非要人数不可。我的经验是这样分。
能直接抄的三样
第一，每个阶段留下一份进版本控制的文件，下一阶段读它开始。一个人做这件事的收益比团队还大，因为你没有同事可以问「上次那个是怎么定的」。
第二，动手前把要证明什么写下来。这一条几乎零成本，防的是自我欺骗。
第三，把检查做成脚本，并且验证这个脚本会失败。
抄不了的两样
双向审查抄不了，因为你没有第二个人。堆检查次数是替代方案，不是等价方案，得知道它弱在哪。
自动那一半抄不了。写回规则可以手动做，但「监控发现异常自动触发」这半需要有东西在持续盯着，一个人的内容系统通常没有这个层。
你可以拿去对自己的六个问题
不用管你是几个人的团队。逐条回答，有就是有，没有就是没有。
一、你的每个阶段有没有留下一份文件，下个阶段读它开始。 如果关键决定只存在于聊天记录里，那就是没有。
二、你有没有在动手之前写下「怎样算成功」。 事后补的不算。
三、你的规则是文件还是习惯。 换一台电脑、开一个新会话，同样的规则还生效吗。
四、你的自动检查会失败吗。 造一个该报错的样本喂进去，它没报错，那这个检查是空转的。
五、谁在关卡那一头。 如果是你自己，承认这一点，然后决定用什么补，不要假装它等价。
六、发现问题之后，改的是这一次，还是规则。 只改这一次，同样的错还会再来。
第四条最容易被跳过，也最值钱。第五条最容易被含糊过去。
限制
我做的是内容生产，不是软件交付。Build 和 Deploy 两个阶段的对照本质上是类比，不是同构。手册讲的 PR、CI、生产监控，我这边没有对应的东西，是拿相似的机制去比，不是拿同样的东西去比。
我只有一个样本，就是我自己这套系统。它对上两条这件事，不能证明手册好，也不能证明我的做法对。
手册面向的是企业，我没有企业经验可以判断它在真实组织里跑得怎么样。这篇只回答「一个人的小系统照它能照出什么」。
校验器今天 3 项失败 1 项警告的状态，是我写这篇时的真实状态，没有等修完再写。两个新技能没分发到两个入口，一个镜像文件落后了 5 天，还有两个工作区的发布状态我自己都说不清，日志里查不到它们，我也没去线上核过。这些都在上面那六个问题里能被问出来。
全部对照基于 2026-08-22 的原文版本和我本机这套系统。