核心观点 轮次机制把「让 AI 快速实现」装进一条有轨道的循环里：每轮目标一句话可证伪，验收表每行能被一条命令判定，跨轮次发现的问题进 BACKLOG 而不是顺手改，连续两次不过就停下呼人。四条原则——小轮次、可证伪验收、风险前置、止损明确——决定了这套机制的形状。
Agent X-Ray 的 ROUNDS.md 开头有一句话说明拆解方法：「小轮次、可证伪验收、风险前置、止损明确」。这四条不是口号，每一条都对应一个机制。
| 原则 | 机制 | 落点 |
|---|---|---|
| 小轮次 | 每轮一个可以独立演示的结果；一轮的分支在审查通过后合并 | round-<名> 分支、任务卡 |
| 可证伪验收 | 目标一句话可证伪；验收表每行是「检查 + 命令或期望」 | 任务卡「目标」「验收」段 |
| 风险前置 | 第一轮是全项目最大的技术风险；里程碑表写止损 | ROUNDS.md「里程碑」；第 11 章 |
| 止损明确 | 同一验收项连续两次不过就写 BLOCKED 停下；禁止放宽验收 | rounds/round-<名>/BLOCKED.md |
为什么对 AI 协作尤其重要：agent 的实现速度快，一轮范围一旦过大，失败之后就不知道是哪里错了；agent 报告的「完成」需要外置的判定标准，否则验收就退化成「它说好了」；agent 遇到不通的地方会不断尝试，没有止损规则它会一直试下去。
ROUNDS.md 是仓库根目录的一份文件，四个部分各有职责。
功能边界与修订记录。 文件开头先写功能范围的唯一边界（设计稿画板 + 原型），然后按时间顺序记录每一次边界修订——到 2026-09-03 已有十次，每次都写日期、轮次代号、是不是规则的例外、理由是什么。这部分是给所有角色看的「什么在范围内」。
进度表。 一轮一行：内容、状态、完成日期，以及审查记录的摘要（几轮、几条 findings、几条采纳、high 级是否清零）。这张表是项目的账本。
里程碑与止损。 五个里程碑，每个写覆盖的轮次、含义、止损条件：
不是每个里程碑都有栏杆。M0、M2、M4 三处有：风险门禁不过就停、沙箱验收不过不得公网部署、上线检查单不全绿不上生产。
| 里程碑 | 覆盖 | 止损 |
|---|---|---|
| M0 | 环境 + 风险门禁 | R1 任一门禁不过 → 停，重新评估架构形态 |
| M1 | Runtime 核心真实化 | — |
| M2 | 内容库 + 管理面 + 安全沙箱 | 沙箱验收不过 → 不得进入任何公网部署轮 |
| M3 | 统计 + About | — |
| M4 | 预发 → 生产 | 上线检查单不全绿不上生产 |
止损条件在开工前写好，而不是失败之后再商量。M4 那条后来在收工时被所有者裁定放行——检查单在预发全绿、生产只做了部署冒烟——但任务卡把「未在生产重跑」和差的六项都写了下来。止损可以被裁定越过，但越过要留痕。
各轮拆解。 每轮一段：交付什么、验收要点、止损。任务卡从这一段起草。
每轮开工的第一步是从 rounds/TEMPLATE.md 复制一张任务卡。模板只有七段：
前五段开工前填好；「代码审查」与「本轮实测」两段虚线框，完成后回填。
目标。 一句话，可证伪。「Runtime 顶栏的 tokens 与 ctx 从硬编码换成真实数据，且在一轮对话结束时当场更新、重开会话后不回退」是可证伪的；「优化统计条」不是。任务卡还会紧接着写一段「可证伪」的具体判据：同一个会话连问两轮，数字单调增长且与 provider 报的 usage 一致；刷新之后不变；会话被回收重建后不回退。
前置。 依赖哪些轮次已完成、需要哪些环境或凭据。前置不满足就不开工。
交付物。 文件级清单，写到路径。这一段迫使实现前先想清楚会动哪些文件；审查时也用它核对有没有超出范围的改动。
验收。 一张表，每行是「检查 + 命令或期望」。表里不许出现「合理」「完善」「适当」这类词。以 R-USAGE 为例：
| # | 检查 | 命令 / 期望 |
|---|---|---|
| 1 | 编译与测试全绿 | dev.ps1 check；dev.ps1 test |
| 3 | 连问两轮，tokens 单调增 | 顶栏数字每轮结束时增长，与服务端日志里的每轮 token 累加一致 |
| 4 | F5 后不回退 | 刷新页面，数字与刷新前相同 |
| 7 | 帧里没有配置面 | 抓收尾帧：无 model / provider / baseUrl / cost |
| 8 | 样式零改动 | git diff 里没有 style / className / 布局改动 |
禁止。 本轮明确不许碰的东西。模板默认继承两条：不改前端样式（规则 7）、不加设计稿没有的功能（规则 8）。每轮再加自己的：R-USAGE 写了「不把 cost 送到前端」「不为落库失败新增补偿机制」。禁止段是给实现 agent 的护栏，也是审查者判定「超范围」的依据。
代码审查。 完成后回填：审查方式、findings 逐条处置、结论。这一段的写法在第 13 章。
失败处理。 固定一句：同一验收项针对性整改后连续两次验证仍不过 → 写 BLOCKED.md 停下呼人，禁止放宽验收标准自我通过。
本轮实测。 完成后回填：实际数字、踩的坑、与计划的偏离及原因。第 17 章讲这一段怎么写。
七段里有两段是「开工前不知道、完成后才能填」的。模板把它们留成空位，而不是让实现者自己决定要不要记——这就是模板的作用。
任务卡填好之后，一轮按固定顺序跑：
循环中途发现的问题掉进 BACKLOG，不改变本轮范围；连续两次过不去的验收项走向 BLOCKED，由人接手。
两条分支纪律值得单说。第一，每轮一个分支，分支名就是轮次代号，合并提交信息里带审查结论——这样 git log 本身就是一份可核对的记录。第二，两轮并行时后开的分支要合并 main 再继续，迁移文件编号冲突时改号（项目里发生过两次：R7 与 R8 并行时迁移改号 006，R-TITLE 与 R-WEBSEARCH 并行时改号 009）。
实现过程中一定会发现本轮范围之外的问题：一个门禁的盲区、一个上游库的缺陷、一个「要是有这个功能就好了」的想法。这些东西的去处是 rounds/BACKLOG.md，不是当场改掉。
条目格式固定：发现轮次、一句话、发现日期。文件分两个区：「工程」与「功能提案（需所有者裁定）」。到 2026-09-04 有 79 条，其中不少已经关闭，关闭时在原条目下面写去向，而不是删掉。
几条有代表性的：
「不当场顺手改」的理由有两个。一是范围：顺手改的东西没有验收、没有审查，混在本轮 diff 里会污染审查结论。二是裁定权：新功能想法必须经所有者裁定才能进轮次，agent 不能因为「顺手」就替所有者做决定。
止损规则只有一句：同一验收项针对性整改后连续两次验证仍不过，写 rounds/round-<名>/BLOCKED.md，停下呼人。禁止放宽验收标准自我通过。
到目前为止项目里没有一轮真正写过 BLOCKED 文件。但这条规则的价值不在于触发，而在于它改变了整改的行为：实现 agent 知道第三次尝试是不被允许的，于是第二次失败时就会停下来分析根因，而不是继续换一种写法试。
「禁止放宽验收」是这条规则的另一半。agent 在验收过不去时有一个天然倾向：改测试、改判据、把「必须」改成「尽量」。第 10 章的失败模式「为通过门禁而削弱门禁」在 AI 协作里会被放大，因为 agent 做这件事的速度比人快得多。
项目最初的 roadmap 是线性编号的 R0 到 R11。第二天就出现了第一个例外：R-BUN，一轮横切的基础设施改造（运行时统一为 bun，部署方式整改），它不属于线性序列。之后插在 R11 之前的加固轮与能力轮都用了命名轮的形式。
投产之后，所有者裁定了运行口径：较大迭代延续轮次机制（一律命名轮）；小修补可以直接进 main，但每次生产发版必须在 docs/releases.md 记一行。小修补也要在 ROUNDS.md「修补记录」表里记一笔，写清是不是走了审查。
判断「较大迭代」还是「小修补」的标准不是改动行数，而是有没有新的边界、迁移或机制。渲染器接 KaTeX 是修补，会话区恢复工具调用卡并加两个新态是一轮。
以进行中的 R-USAGE 为例，从头到尾看一遍：
这张卡的每一段都在回答一个审查者或下一个会话的 agent 会问的问题。它不是给人看的汇报，而是给整个工作系统看的契约。
切片过大。 一轮同时做三件事，失败后不知道是哪一件的问题。项目里的经验值是一轮一个可以独立演示的结果；R-SKILLS 拆成 1.0（只展示）与 2.0（agent 使用）两轮就是这个考虑。
验收写成形容词。 「页面响应要快」无法判定。写成「点击到 URL 变化不超过某个数」或者「加载态在 200ms 后出现」才行。
顺手改。 本轮 diff 里混进了 BACKLOG 该记的东西，审查者把它当本轮改动审，结论就不干净了。
放宽验收。 过不去就改判据。止损规则存在的意义就是把这条路堵死。
跳过回填。 任务卡「代码审查」「本轮实测」两段空着就合并。下一轮的人（或 agent）不知道这一轮验证过什么、没验证什么。
从七段模板起一张任务卡，为自己项目的下一个改动填前五段。检查验收表：每一行能不能被一条命令或一次操作判定；能不能找到一个词是「合理」「完善」「适当」——找到就改写。
苏公网安备32011402012723号