北京
生成式起草把文档生产的成本压了下来，但瓶颈并没有消失，只是从“写”挪到了“审”。大多数文档评审仍然在通读整篇内容，而不是先看模型到底动了哪里。社区里已经有人把这种变化说得很直白：AI 让每个开发者都变成了审稿人，可围绕“审稿闭环”本身，至今没有一个像样的基准。
问题不在提示词，而在缺少一份生成清单
真正能落地的修补方案，不是继续打磨提示词，而是在写入阶段就生成一份清单文件。这份清单要记录模型具体触碰了哪些章节，让人类只针对清单标出的差异做复核。换句话说，模型写得多，人审得少，而“少”必须有一个机器可检查的定义。
Git 的作者元数据给不了这个定义。因为变基、压缩提交以及多人协作时的提交约定，会让提交级别以下的作者归属变得不可靠。免费起草能力一旦出现，清单门禁就从“可选”变成了“必需”——否则免费产能只会把审稿人面前的文章体量越推越大。
合同文件把抽象策略变成具体地图
这套流程从一个放在文档旁边的 YAML 合同文件开始。合同给每个章节分配三种归属之一：模型起草、人类拥有，或者带示例验证。它同时是模型和 CI 门禁的唯一事实来源，把“安全说明由人类负责”这类抽象策略，变成一张可以逐项对照的地图。
合同文件需要提交到仓库里，这样生成器和审稿人读的是同一份文件。每个归属值都会改变生成器、CI 门禁和审稿人各自要承担的义务。比如快速入门章节由模型起草，来源指向示例脚本，验证方式是运行；配置参考章节由人类拥有，来源为空，不做验证；接口错误码章节要求带示例验证，来源指向错误定义文件，验证方式同样是运行。
清单由起草过程直接写出，而不是事后重建
章节归属是策略，清单是策略的可执行形态。清单必须由生成草稿的同一个过程写出来，而不是事后从 Git 历史里重建。因为只有生成器自己清楚，它到底编辑了哪些标题，又读取了哪些源文件。这个设计把清单和风险评分分开：风险评分需要有人通读文档才能算出来，而清单在起草阶段就能免费生成。
这套起草流程围绕 MonkeyCode 的免费模型访问和免费服务器选项搭建。免费访问消除了反复起草的边际成本，免费服务器选项则让生成循环留在自己可控的环境里，而不是挂在一个共享端点上。最终产物是一个提交到仓库的 JSON 文件，里面列出每一个生成过的标题，以及喂给对应章节的源内容哈希。
门禁真正改变的是工作流，而不是工作量
便宜生成应该改变的是工作流，而不是简单增加工作量。模型可以写更多，人类需要核对的更少，前提是“更少”有明确的机器可检查边界。合同文件负责划定边界，清单文件负责执行边界，CI 门禁负责守住边界。三者合在一起，才让“人类只审模型真正改过的部分”从口号变成可以落地的流程。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
