说实话，让AI写README文档这事儿，最让人头疼的一个问题就是——它太爱“自由发挥”了。你明明只想让它基于当前项目的真实依赖和功能做说明，它却可能自动脑补出一堆“建议使用TypeScript重写”“推荐接入Sentry监控”之类的高级方案。结果呢？文档是漂亮了，可新来的同事照着跑一遍，全是坑。

怎么才能让海螺AI老实点？方法其实挺简单：用一条“前置锚定”指令，从源头锁死它的发挥空间。

具体操作是这样的：打开项目根目录下的package.json或requirements.txt，找到其中最关键的一行依赖声明——比如"express": "^4.18.2"。把这行代码原封不动粘贴到提示词的最开头，然后在后面跟一句：“以上为本README唯一依据来源，AI不得引用任何未在该文件中显式声明的模块、版本号、协议条款或外部文档链接。”

这一步非常关键，漏了它，海螺AI就会自动“补全”那些训练数据里的高频延伸项。而问题是，你的仓库里根本没有tsconfig.json，它却可能大谈特谈TypeScript迁移方案。

必须确保你选的那行依赖真实存在于当前仓库，不能虚构，也不能截取片段。

结构化禁用指令：精准剔除三类冗余

锚定法之后，还需要一套清晰的“禁区指令”，把AI的发挥空间进一步压缩。

方法一是“编号式否定清单”。在提示词末尾另起一行，直接写清楚：

【禁止出现以下内容：
① 未在package.json或requirements.txt中间出现的包名、版本号、许可证关键词；
② 使用“建议”“应”“可考虑”“未来支持”等非强制性措辞；
③ 提及“微服务架构”“容器化部署”“灰度发布”等超出单仓库能力边界的系统级描述。】

方法二是“动词绑定法”。所有操作步骤必须以“运行”“执行”“安装”“启动”等现在时动词开头，并且宾语必须是package.json中已经声明的命令（比如npm start）或requirements.txt中已列出的库（比如requests）。如果某句话的主语是“开发者”“团队”“运维人员”，那整句话直接过滤——因为这些主语往往意味着AI在描述通用做法，而不是你项目里的具体指令。

路径验证法：当场核验名词真实性

指令写得再漂亮，最后生成的文档也得过“真实关”。这里有一套三步验证法：

第一步：文档生成后，用Ctrl+F逐个搜索所有出现的名词——比如“axios”“dotenv”“Dockerfile”。
第二步：打开项目根目录，逐一确认这些名词是否真实存在于package.json、requirements.txt或同级文件名中。
第三步：如果搜不到，直接删除包含该名词的整句话。举个例子，如果文档写着“需启动Redis服务”，但你搜了package.json里根本没有“redis”这一项，那这句话就是无效的，删掉。

还有一点需要特别注意：对所有带版本号的表述做反向验证。比如文档说“Python 3.9+”，那你就去requirements.txt里查有没有明确写python>=3.9，否则视为AI的臆测，必须删除。

【禁止出现以下内容：① 未在package.json或requirements.txt中间出现的包名、版本号、许可证关键词；② 使用“建议”“应”“可考虑”“未来支持”等非强制性措辞；③ 提及“微服务架构”“容器化部署”“灰度发布”等超出单仓库能力边界的系统级描述。】

话说回来，这整套方法的本质其实就是一句话：别让AI替你“想当然”。你给它锚定了真实依赖，设好了禁区，最后还要亲手验证一遍——这三个步骤走下来，生成的README文档才真正是你的“项目说明书”，而不是AI的“幻想小说”。