由于 AI Coding Agent 不擅长理解你公司特有的业务逻辑、隐性规则、历史债务和领域术语，所以至少需要以下规约 business_glossary.md（业务术语表）、domain_rules.md（核心业务规则）。业务术语最好放到扩展记忆中，而规则则写到 md 中，每次请求必须带上。以下是我总结的 Rule 的一些心得。
特有的业务逻辑：比如还款必须按照本关息费的顺序按户冲抵
隐性规则：还款预报的匹配必须等值匹配
历史债务：账单服务为了财务特意冗余了费率数据，属于不合理的设计。有一些字段已经废弃，但还没有来得及删除清理
领域术语：比如事务项-委外还款、退费还款、往来退费还款等
【强制】分类书写
【强制】分类书写虽是好的，但文件不宜过多，否则难以维护。
比如4-5个基本就够用了，如下是我给团队规定的几个文件：
.
├── 数据库规约.md
├── 代码质量规则.md
├── 通用开发规则.md
├── git协作规则.md
└── MEMORY.md【强制】内容不宜太多，100行以内，否则会导致阅读困难。
【强制】只写必要的统一规范，避免重复内容。
现在的AI(基座大模型)已经比较智能了，很多知识已经固化，不必强行约定。
【反例】 请不要使用拼音命名。这种规约写了跟没写一样。
【正例】 创建的分支必须包含 ai- 前缀标识。这种你不写 AI 肯定不知道。
【正例】 强调，禁令
- 强调型
严格遵循阿里巴巴 Java 开发手册这种属于强调，AI 肯定学习过，但是你不强调，它是不会主动遵守的，但是你不用把 Java 开发手册的内容都一一列出来，只用激活记忆即可。
- 禁令型
- 禁止执行无 WHERE 条件的 UPDATE/DELETE
- 禁止在生产环境直接修改数据
- 禁止批量操作未先测试单条数据这种属于禁令，AI 肯定学习过，但是你不禁用，它是不会主动遵守的。
【强制】不要写无意义的规约。
【反例】 以下是我曾经写过的不合理规约：
# 通用开发规则
## 工作态度
- 每次工作都要用严谨的工作态度，保证完美的质量标准
## 沟通风格
- 直接输出代码或方案，禁止客套话（"抱歉"、"我明白了"等）
- 除非明确要求，否则不提供代码摘要
## 求真原则（禁止瞎猜）
- 不确定/信息不足时先查证或提问澄清
- 对环境/配置/源码/行为的结论必须有证据
- 回答里把"事实"和"推测/假设"分开写即可这个规则的问题在于"严谨"、"完美"是无效指令，LLM 无法量化，实际行为不变。
【强制】不要写带有冲突的规约。需要定期检查，一段时间后固化下来
