编程开发 编辑复核
仓库 AI 协作规则文件
把项目里只有老成员知道的约定写成简短规则文件，让 AI 编码工具少犯重复性错误。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名仓库协作规则整理者。请把项目中不成文的约定整理成一份短小、具体、可执行的代理规则文件。
先把已知事实、合理假设和待核验信息分开；资料不足时写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 用三到五行写清项目做什么、技术栈和主要目录职责
2. 列出安装、开发、测试、构建和检查的准确命令
3. 只写本项目特有的约定，删掉任何通用编程常识
4. 标出不能随意改动的文件、目录和自动生成产物
5. 写明提交前必须通过的验证和提交信息要求
输入变量：
- 项目事实（{{repo_facts}}）：说明技术栈、目录结构和运行方式。
- 团队约定（{{team_conventions}}）：列出新人常踩坑的约定和历史包袱。
- 已发生的问题（{{agent_mistakes}}）：说明 AI 工具此前反复犯的错误。
约束：保留原始上下文和限定条件；每个结论都说明依据；涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 规则控制在一页以内，越长越容易被忽略。
- 一条约定配一个真实代码示例，比三段描述更有效。
WHEN IT FITS
适用判断
适合这些情况
- AI 工具反复违反同一条项目约定。
- 新人和代理都要花很久才摸清目录职责。
- 仓库已有 README 但缺少可执行的命令与禁区说明。
换个做法更好
- 要写给人看的项目介绍：用 README，不要混在一起。
- 约定还在团队内争论：先定下来再写入文件。
- 内容超过一页：拆成分目录的说明，按需引用。
FAILURE MODES
常见翻车与修正
- 规则文件写满通用建议，代理照样犯错。
删掉写好代码之类的空话，只保留本项目独有的命令、路径和约定，并附一个真实示例。
- 命令已经过期，代理照着执行就报错。
逐条在本地执行验证，并让命令来源指向脚本配置而不是记忆。
ACCEPTANCE
怎么判断输出合格
- 所有命令都在本地验证过。
- 规则全部是本项目特有内容。
- 禁改文件和验证要求单独成节。
- 全文控制在一页以内且不含敏感信息。
SAFETY BOUNDARY
使用边界
- 不要把密钥、内网地址和账号写进规则文件，用占位符代替。
- 规则文件会被工具读取并可能随仓库外发，涉密约定另放受控文档。