用 Cursor / Claude Code 指挥 AI：一个需求下来，通常会产出需求文档、任务文档、接口契约三份文件。

AI 给每份都写了编号，文件名看起来挺规范。

等你要对齐、变更、归档——三个编号各是各的，不知道该信谁。

AI 给三份文档各编一个号，需求/任务/契约却对不上。

第一版翻车：先设计格式

起点很朴素：文档按功能主题用中文命名，别默认英文短横线加日期前缀。

AI 设计了 [模块]-[动作]-[目标] 三段式主题串。用户接着要求：编号按全局递增，文件名加任务类型前缀（需求/任务/契约）。

格式上的坑踩过一遍了。真正关键的那一问才来：

三份文档的编号要保持一致，是不是建个编号字典？

第二版：登记册做唯一发号源

AI 列了三种方案对比：

方案	优点	风险
登记册	唯一数据源，发号权集中	需人工遵守「先读再写」
扫描文件名	自动化感强	竞态：两次扫描之间可能插入新文件
文档互引	看起来自洽	断链：一份没写引用就断了

答案很清楚：登记册为主、扫描校验为辅。

一份 Markdown 登记册，一行一条任务链，记文档编号、主题串、三份文档路径、全局序号计数。只有新建任务链时全局计数 +1；生成任务文档、契约文档禁止重新发号，必须从登记册里读同一个编号。

纪律四条

要点	规则
发号	登记册表格，全局递增，新建任务链才 +1
对齐	任务/契约禁止自己编号，只读登记册同一号
不可变	作废打标记，不回收序号
解析	编号与主题串都含 -，必须正则提取，不能 naive split

编号格式示例：20260522-A0004——日期段 + 字母序 + 全局序号，分段后不会被误读成「当天第 4 个」。

附带坑

规则落地做了批量重命名，更新了所有交叉引用，并用 rg 校验无残留——不做就会出现「新文件新格式、老文件老格式」的割裂。

能力边界也收敛了：不上数据库，不上脚本服务，一份文本登记册 + 规则约束 AI「先读后写」就够用。

和主流说法对齐

• Context Engineering（上下文工程）：AI 产出速度放大后，没有登记册的产物堆 = 不可审计的黑箱——本篇在 Context 层「命名与登记」。
• 产物链：Request / Task / FrontendContract 三份文档属于同一条任务链，编号必须对齐才可追溯。
• 系列 #0 提过登记册概念；#6 阶段一结尾提醒别急着上阶段二；本篇补 发号权怎么收紧。

两个教训

① 纪律比格式难——先定「谁和谁必须共号」，再谈文件名长什么样。格式只是让编号看起来一致；登记册的「唯一发号权」，才是让编号真的一致。

② 存量迁移要批量重命名 + rg 验残留——否则规则只对一半生效，裂痕很快蔓延。

你可以直接拿去用的提示语

📋 点击展开提示语模板（可直接复制使用）

我要给 AI 生成的文档定一套编号规则：需求文档、任务文档、接口契约各写一版，文件名都带编号，结果三个编号各是各的，最后不知道该信谁。

别一上来就设计编号格式——先解决纪律：
1. 定清楚「谁和谁必须共用同一个编号」（哪些产物属于同一条任务链、必须对齐）。
2. 再谈格式：编号怎么生成、放在文件名哪个位置、中文主题怎么带。
3. 给一条落盘前的校验：怎么防止同一链路的产物编号再次跑偏。

记住：纪律比格式难，先把「必须对齐」的关系定死，格式只是表层。

AI 给的是初稿——同步契约具体绑哪些路径、哪些文件算事实源，得你结合项目定。纪律怎么守还是靠你。

常见问题

能不能让 AI 每次扫描已有文件自动编号？
可以试，但有竞态：两次扫描之间可能插入新文件，号就乱了。登记册虽然要「先读再写」，但只有一个数据源。

没有需求文档能不能先发号？
可以。有些技术任务不需要独立需求文档，登记册里该项留空即可，但发号流程不变。

编号格式要多完美？
够用就行。先把发号权收紧到一处——剩下的慢慢调，都不会出大乱子。

---

同系列延伸阅读（本篇单独成立）：

· 第 1–10 篇见系列目录 · 本篇为第 11 篇

你的 AI 产物编号对不上过吗？评论区聊聊。