用事实清单约束 AI 生成项目文档

AI 生成的 README，参数名和退出码看着像真的，核验却要逐项翻代码。dev.to 上的一篇文章提出：先用脚本提取项目事实，再让模型围绕固定占位符写说明，最后通过构建检查拦截未登记的数字和标识符，把事实变更单独交给审阅者。

目前能确认什么

作者给出的流程从命令行帮助、环境变量和自检退出码中提取事实，保存为清单。每条事实记录标识、类型、准确值和责任归属，示例还包含来源字段。参数名可以由机器负责，弃用承诺这类内容则需要明确的人来负责。

模型只填写模板中划定的说明区域，事实值由渲染器替换占位符。人工待办标记必须保留，不能让模型猜答案。

构建检查会扫描模型撰写区域中的数字和反引号标识符；如果它们不在事实清单或允许列表里，就让构建失败。作者建议在持续集成（CI）中，针对生成文档的同一提交提取事实，并将清单纳入版本管理，方便单独查看差异。

我的判断

这套方法能缩小参数和数字的核验范围，但不能证明整句说明正确。

例如，参数名登记过，不代表模型对参数用途的解释就正确；退出码存在，也不代表触发条件写对了。词法检查识别的是字符，语义仍要人工审阅。

对维护 CLI 和工具库的程序员，这个思路比较具体：把容易写错、又能自动提取的内容交给脚本，让审阅者集中检查事实差异和解释是否匹配。

目前节选中的校验脚本并不完整，占位符防篡改如何落实、缺失标记能否被拦截，还需要完整实现确认。文章也披露了 MonkeyCode 产品推广背景，流程思路与工具宣传应分别判断。