AI-native SDLC · 第 2 篇
同一套方法论，我用了三次，结果各不一样
auth9 近乎满分，orchestrator 归档，deck 把方法压到最小。半年三个项目之后，我明白了方法论的价值不是常量，它取决于条件。
这是《AI 能不能像人一样把软件打磨出来》的下半篇。上半篇写在 auth9 时期，回答的是”能不能”。这一篇写在半年后，回答”然后呢”。
2026 年 1 月到 9 月，我用同一套 AI-native 的开发方法做了三个项目：
| 项目 | 时间 | 规模 | 现在 |
|---|---|---|---|
| auth9 | 1 月–6 月 | 约 21.5 万行，491 次提交 | 实验结束，方法论近满分 |
| orchestrator | 2 月–8 月 | 约 20 万行 Rust，1,606 次提交 | 已归档 |
| deck | 8 月 27 日起 | 约 3.4 万行，10 天到 v0.5.15 | 我每天在用 |
三个结局完全不一样。写这篇是想把一件事讲清楚：方法论的价值不是常量，它是条件的函数。以及那些条件到底是什么。
auth9：条件对的时候
方法论的骨架上半篇写过了，这里只列要点：
- 16 个 skill，把”怎么修工单""怎么写测试""怎么管覆盖率”写成 agent 能直接执行的流程，镜像给 Claude、Gemini 和 Cursor；
- 224 篇带 SQL 校验的测试文档，manifest 是清单，lint 脚本防止它们烂掉；
- 所有测试一两秒跑完，禁止 testcontainers 和真实数据库；
- 一堆 agent 绕不过去的机械门禁：domain 边界检查、
clippy -D warnings、OpenAPI 同步测试、pre-commit 密钥扫描； - 我自己只做四件事：规划、审阅、纠偏、架构。QA 执行和工单修复完全自治，提交标题里那些 “Resolve 27 QA tickets: fix 9 bugs, close 14 false positives, defer 4 feature gaps” 都是流水线自己吐出来的。
五个月，我一个人加一组 agent（copilot-swe-agent 占了大约 5% 的提交），做出一个带 OIDC 一致性测试、SCIM、WebAuthn、V8 动作引擎、K8s 加 GitOps 自动部署的 IAM 平台。作为方法论实验，这个结果我很满意。
但有一个条件我当时没想明白：auth9 的”意图”是白送的。
什么是对的，RFC 和 OIDC conformance suite 说了算。该做哪些功能，Auth0 的功能清单说了算。安全要做到什么程度，威胁模型方法论说了算。整个项目从头到尾，方法论只需要回答一个问题：“实现符不符合意图？“它从来不用回答”意图应该是什么”。
在”正确性就是产品”的领域里，这套方法的杠杆是最大的。这解释了为什么它拿了高分，也带出一个我后来才体会到的推论：在最有利的领域做试点，试点的高分不能外推。
orchestrator：条件不对的时候
orchestrator 的想法很自然：既然这条流水线能让 agent 打磨出一个 IAM 平台，那就把流水线本身做成产品。一个给 agent 装上工作流、沙箱、审计的控制平面，K8s 风格的 manifest，plan → implement → test → review → fix 的循环能自己跑几天。
现在回头看，orchestrator 就是被产品化的 auth9 开发流程。它的 workflow 循环是 auth9 里 QA 工单批处理的泛化；30 个 skill 里大半直接承自 auth9 的 16 个，有个 skill 的目录候选里到现在还写着 auth9-core；连它预设的用户人格 “operator”，都是我自己在 auth9 里扮演的那个角色。
方法论在这个阶段确实有进化，有几样东西我到现在都觉得值钱：
- 变异验证。AI 生成的测试最危险的失败模式是”看着通过了，其实什么都没验”。记录里有好几次，第一版测试没扛过变异检验，被判无效重写。
- 类型化纪律。人类团队靠 code review 传规范，agent 没有记忆，每次都是新人。所以规范得下沉成编译器性质的东西。密钥脱敏被做成了”忘了脱敏就编译不过”的类型。
- 双向覆盖率棘轮。“覆盖率只许涨”的单向棘轮会悄悄失去回归检测能力：实际覆盖 52.86%、基线停在 35.49% 的时候，跌 17 个点门禁照样是绿的。所以涨太多不更新基线，也算失败。
- 概念预算，而且故意不做成门禁。新增一个顶层概念必须论证”为什么这不是一个字段”。但这条规则被明确拒绝写进 CI，因为门禁只能检查”存在某段论证文本”，用文本存在性去代理评审质量，比没有门禁更糟。
问题不在这些发明。问题在两笔账。
第一笔：制度的成本是固定的，收益跟用户数成正比。 101 道 CI 门禁、25 万字节每条都带实测数字的 CHANGELOG、freshness 记录、门禁自己的负面夹具元验证，这些是给多人长期维护的平台准备的。而团队是两个人，用户约等于零。归档前的最后一个月，提交记录里没有一个新功能，全是治理体系在给自己收敛：压缩治理记录、给门禁做性能分层。当治理体系需要为自己做治理，账已经透支了。这套方法度量了测试、覆盖率、门禁新鲜度、依赖漏洞，唯独没度量它自己值不值这个价。
第二笔：方法论能验证实现符不符合意图，但生成不了意图。 auth9 的意图来自标准，orchestrator 的意图来自我的个人偏好。K8s 式的心智模型是搞基础设施的人的审美，不是管一堆编码 agent 的个人开发者的审美。kubectl 那套隐喻预设用户是 operator，可真实的使用者想看着自己的终端，不想 apply 一份 manifest 然后等系统收敛。心智模型不只是交互风格，它是对”用户是谁”的断言。这个断言从第一天就错了，而方法论的全部严谨都压在这个没验证过的断言上面。品味可以当假设，不能当公理。orchestrator 的假设七个月没碰到过任何能证伪它的东西。
还有一个日期值得记下来：orchestrator 的第一次提交，距离 auth9 的第一次提交只有 11 天。扩张在验证结束之前就开始了。在最有利的领域试点然后泛化，和不等实验出结论就扩张，其实是同一件事的两面。
最后的自我诊断出现在 7 月的一份设计文档里：生产 workflow 膨胀到 443 行 YAML，大约 70% 是为”哑 agent 契约”付的协调成本，原话是 “The dumber the agent contract, the smarter the YAML must be”。当时的修法是让 agent 通过 typed tools 直接表达意图。但这个逻辑推到头，就走出了项目本身：agent 越聪明，外面套的 harness 存在的理由就越薄，而”agent 变聪明”这件事是模型厂商在推。8 月底，我把 orchestrator 归档了。
deck：把方法压到最小之后剩下什么
deck 是 orchestrator 归档第二天开始的。一个 macOS 原生看板，每张卡片是一个真实的 tmux 会话，board 只告诉你哪个 agent 有输出、安静了、退出了，看哪个由你决定。3.4 万行，8 个配置项，0 个 CLI 子命令。
方法论在 deck 上被压缩到几乎认不出来：没有技能库，没有 FR 注册表，没有门禁的元验证。但压缩不是丢掉。你对比一下”一个正常的 10 天项目该长什么样”，就能看见残留的骨架：312 个 Rust 测试加 121 个 JS 测试、70% 覆盖率硬线、真 WKWebView 冒烟测试、CI Action 全部钉死 commit SHA、隐私测试必须写真实文件（注释里写着 “never stub the writer and call it proven”）。这些肌肉是前两个项目练出来的，不需要制度来维持，因为已经变成习惯了。
真正留下来的是三样东西：
- 机器可验证的信任，但按需取用，不预先铺设。 deck 的状态显示一开始只是”15 秒没输出就变琥珀色”的启发式。用了几天发现它分不清”在干活的沉默”和”等我输入的沉默”，才引入 agent hooks 上报一组封闭的状态词。这恰好是 orchestrator streaming-runner 转向的核心思想（typed contract 取代对文本的猜测）的微缩版。方法论第一次以”一个被验证的需求签发一件机制”的方式回流。
- 对假绿灯的拒绝，从测试扩展到了产品本身。 调度器崩溃后宁可把投递标成 ambiguous，也不说”成功了”；状态文案明写”安静不等于就绪”。上半篇说验证是瓶颈，这一篇可以补一句：诚实是验证的产品化形态。
- 制度记忆换了载体。 从 25 万字节的 CHANGELOG 论证文集，变成一份判例集：每条踩坑记录标着 “each cost a real bug”，每个被撤回的设计写着为什么。单人短周期项目，判例集就是最合适的制度形态。
deck 真正新增的东西不是工程，是意图从哪来。deck 验证的是从产品出发的 AI-native SDLC：先有一个我每天在用的东西，需求由使用本身暴露出来，方法论再按需进来。上一代缺的那道题，这一代的答案是观察：意图来自真实使用，不来自外部规格，也不来自品味。
五条我会记住的
写给同样想用 agent 规模化写码的人：
- 先问意图从哪来。 方法论能把”实现符合意图”验证到极致，但生成不了正确的意图。规格外生的领域（协议实现、标准兼容、迁移）是它的主场；规格需要从使用中发现的领域，先解决发现问题，再上流水线。
- 给治理体系设预算线。 制度规模应该是团队规模乘用户规模的函数。度量一切的时候，也度量一下制度自己的成本。当你开始给治理记录做压缩、给门禁做性能优化，账已经透支了。
- 规范要下沉成机械的东西，因为 agent 没有记忆。 类型系统、编译期检查、CI 门禁，都好过写在文档里的约定。但门禁只能检查它看得见的东西。需要判断力的规则，老老实实留给人，别用”存在某段文本”去代理它。
- 把假绿灯当头号敌人。 变异验证、真实文件测试、双向棘轮，本质上是同一件事：不信任”通过”这个信号本身，要求它证明自己还能失败。
- 别外推试点的高分。 在最有利的领域验证方法论，高分说明的是契合，不是普适。扩张之前，让方法在一个”意图不白送”的领域再考一次，而且等考完再扩张，哪怕多等的只是几个月。
现在
这套方法论没有退役。它的内核变成了习惯，在 deck 里每天用着；制度层的那部分留在归档仓库里，是备选，不是计划。
deck 之后会需要什么，我现在不知道。它还在日常使用中，哪些问题会冒出来、哪些值得用机制解决，要用得够久才知道。谱系里已经有过一次”先构想、后验证”的教训，这次我不预设了。能确定的只有顺序：需求先从使用里暴露出来，再决定进口哪一件做法。
上半篇的问题是”AI 能不能像人一样打磨软件”，答案是能。这一篇的问题是”然后呢”，答案是：方法论没有失败，它只是比它的产品先成熟了。接下来的答案，从 deck 里学。