团队规模化 AI 辅助编程规范与规则治理实践

规则碎片化：团队协作的大敌

如果每个工程师都在自己的 IDE 里随意配置提示词，AI 产出的代码风格就会千奇百怪：有人写函数式，有人写 OOP；有人用 Tailwind，有人写裸 CSS。

代码仓库版本化管理：将规则文件（如 .cursorrules 或 PROJECT_STANDARDS.md）提交至 Git 根目录，随着业务架构升级共同通过 PR 迭代；
三段式结构原则：
- 技术栈声明：严禁猜测未安装的三方库（如：“本项目一律采用 Zustand 管理状态，严禁引入 Redux”）；
- 目录与架构约定：组件放置在 components/，工具函数放置在 lib/；
- 红线禁止清单（Negative Constraints）：严禁使用 any 类型，严禁内联硬编码密码；
简明扼要：规则文件不要写成裹脚布，控制在 100~200 行以内，避免冲淡模型的注意力。

团队规模上来之后，一层规则文件不够用，建议按作用域分三层：

冲突时以仓库层为准——前提是你在文件开头显式写明了优先级，否则模型的取舍行为并不稳定（经验值）。

规则修改走 PR 评审，与改代码同等对待，由架构负责人批准合并；
每周做一次"规则复盘"：收集本周 AI 产出的反例，凡是本该被一条规则避免的错误，就讨论是否新增规则；
执行删除纪律：凡是已被 Linter 或 CI 检查覆盖的条目，从规则文件中删掉。规则文件的职责是引导注意力，不是重复机器能做的事；
保留完整变更历史，出现批量风格回归时第一时间排查近期规则改动。规则的发布与回滚可以并入提示词版本管理与 GitOps：智能体 Prompt 的回归测试与发布流水线描述的流水线。

每个季度做一次一致性抽检：从各团队随机取若干段 AI 生成代码做盲评，统计风格与目录约定符合率；同时挑选几个历史典型任务作为固定测试集，在每次规则大改动前后跑一遍，确认新规则没有把旧问题重新放出来。

规则治理是否有效，看一个指标就够：新成员不做任何私人配置、开箱使用默认设置时，AI 产出的代码是否已接近团队平均水平。如果风格仍然高度依赖个人提示词技巧，说明规则只写给了机器没写进流程——先把规则 PR 评审和每周复盘两个动作建立起来，再谈扩充条目。