一根 USB 线。
一个意图的全程。

FDE 的核心是一个三环交付循环：Echo（到真实台站和操作员那里去观察）→ Delta（用最小垂直切片验证最高风险的假设）→ Product（把验证过的结果固化成边界、契约和可复用组件）。它不是瀑布，是循环。token 账本与这个阶段对得上：2026 年 W21/W23/W25 三周，MRRC 项目名下有约 1.27 亿 tokens，全部来自 claude-code 之外的 harness（claude-code 的本地日志 8 月 5 日才开始留存，更早的消耗已不可考）。方法还在人脑和文档里，执行规模也还小。

d4a7a32 是整条时间线上最有说服力的一个提交：一个新项目，从写下第一行业务代码之前，就先有了完整的契约、约束和门禁。（严格说它是 ft8 的第三个提交——根提交 c545d69 只有一行 README；《7B》称 guardian「在第一个提交引入」，准确表述是第一个实质提交。本文保留这个修正，因为它恰恰是方法有效性的证据：这套东西已经成熟到可以整包复用。）

诚实声明：模型标识是各 harness 自己记录的事实；其中第三方路由的归属属于推断。cursor 无工作目录，无法归属项目。

每个产品族都有自己的「主力 harness」：claude-code 扛起了 modern / ft8 / MRRC 的大头，pi 是 ft710 和 website 的主力，kimi-code 深度参与 ft710 和 ft8，codex 集中在 ft8，opencode 只在 website 出现过。这不是设计出来的分工，是哪个工具在哪个仓库的哪类任务上顺手的自然沉淀——但它留下了一个重要启示：多 harness 并行的前提是契约在仓库里而不在某个工具里。AGENTS.md、SDD、约束注册表都是纯文本、git 管理、与工具无关，所以任何 harness 进场都能加载同一份契约，出场也不带走任何知识。

把时间轴叠上去，能看到清晰的波浪（tokens 为项目 × ISO 周）：W28–W30（7 月上）ft710 垂直切片爆发，单周 69 个提交，W30 单周 3.6 亿 tokens；W31–W33（8 月上中）ft8 爆发，W32 单周 147 个提交，W33 单周 7.3 亿 tokens；W34–W35（8 月下）modern 平台化（IC-7300 后端抽象）+ website 起步，modern 两周合计 12.6 亿 tokens；W35–W36（9 月初）website 表达层冲刺，两周 7.2 亿 tokens、102 个提交中的 89 个。

链一：FT-710 频率漂移——13 天，从现场事故到门禁拦截

$ python3 .agents/skills/sdd-guardian/harness/sdd_context.py check probe_b4_tmp.py
SDD-GUARDIAN: blocking violations found:
[BLOCK] cat-no-dn (AD-014; SDD V1.2 freq-drift incident) probe_b4_tmp.py:2: return c.query("DN;")
$ echo $?
2

注意这条链的结构：修复代码只是第一环。如果故事停在 72fd6f0，下次会话、下个 agent、下个产品族还会犯同一个错。后三环——裁决、约束、拦截——才是把「一个人踩过的坑」变成「系统再也不会踩的坑」的部分。

链二：部署备份事故——7 天，从磁盘打满到四仓同日修复

7cfefec（2026-08-29，modern）：服务器 /var/tmp 被备份打满到 100%——单份备份约 300 MB，因为 cp -r 整站复制把 downloads/、videos/ 这些 120–140 MB 的服务器管理二进制也算了进去（13 份 ft710 备份 1.7 GB、18 份 ft8 备份 2.0 GB）。2026-09-05，四个仓库同日出现姊妹提交：modern 3691b4f、ft710 9c353a1、ft8 a30f76a、website 067f565——统一改为 rsync 排除 + 每站只留 3 份轮转的瘦身备份。同日 067f565 还揭开一个更深的问题：website 的 portal 部署脚本备份从未生效——远程 heredoc 没加引号，本地 shell 提前展开了变量，脚本每次打印一个根本不存在的备份路径，静默跳过了每一次备份。

以及两条不允许被其他证据豁免的开放边界：FT710Mobile 有一个未解决的 P0 PTT 安全问题——439 个服务端测试不能关闭一个客户端安全声明；EFHW V3.0 调谐器固件完成，但在 PCB 打样和 bench 验证之前，它的声明状态保持 design-target——板上没有的东西不许说成有。

2026-07-09 的优化记录把这个问题定义得很清楚——目标是把网站从「项目展示页」升级为「高可信、强转化、可传播的开源官网」，并且一开头就核实了两个难堪的事实：两个 Demo 端口当时不可达，四个 GitHub 仓库三个缺标准 LICENSE。那份文档的结论值得原文引用：「VLSC 已经有真实工程价值，短板不在技术，而在表达与证据系统。」

以及，本文必须坦白的一件新鲜事：就在写作本文的数据采集过程中（2026-09-05，即《7B》发表当天），又发现一处测量口径问题。claude-code 的 jsonl 日志把同一次 API 响应的 thinking / text / tool_use 分块写成多行、每行都带完整 usage，按行求和会把同一响应重复计入。按 message.id 去重后，claude-code 的实际 API 消耗是 1,175,403,254 tokens（7,519 次 API 响应），而非 census 口径的 3,207,496,620——行口径放大约 2.7 倍。其余工具与已发表 census 逐位吻合，不受影响；已发表 census 用行口径，附录把两个口径并列给出。

同样不能委托给智能体的部分，七个月里边界一直很稳定：硬件打样与 bench 调试、RF 安全、实台验证、发布与否的判断、以及「证据是否充分」这件事本身的判断。内环（Specify → Implement → Test → Review）可以整个交给智能体；意图、架构边界、验收判断永远在人手里。用本文开头的话说：业务意图是人的，执行可以是智能体的，但对「算不算交付」的裁决权不能外包。

1. 先有一个不依赖 AI 也成立的业务意图

   省钱、省事、安全、省时，用人话说出来。AI 是执行手段，不是业务本身。

2. 先写验收条件和非目标，再写第一行代码

   验收条件是后来所有「算不算完成」之争的裁判。

3. 让约束机器可读

   每条规则带严重级别、作用范围、匹配模式，以及指向产生它的那次决策或事故的引用。没有出处的规则活不过三个月。

4. 运行时加载活契约，别把文档复制进提示词

   复制即冻结，冻结即过期。AGENTS.md / SDD 放仓库里，会话开始时加载当前版本。

5. 写前门禁优于事后审查

   在 mrrc_ft710、mrrc_modern 和 ft8 中，PreToolUse 钩子在编辑落盘前拦截违规——比指望有人在 review 时注意到可靠一个数量级。

6. 把每次事故变成一条规则

   修复只是第一环；裁决 → 约束 → 拦截才是闭环。13 天可以从频率漂移走到门禁 block。

7. 每个重要数字都要双源对账

   第一次 census 错 16 亿，修正它的是同一磁盘上的另一个数据库。单一来源的数字是「关于数字的假设」。

8. 过程证据和产品成熟度分两本账

   「我们的流程很严」和「我们的产品好用」是两个独立声明，前者的证据不能为后者背书。