工程团队让AI遵守开发规范，最有效的做法不是反复在对话里叮嘱，而是把规矩写进项目级规则文件——OpenCode的AGENTS.md把默认开发分支、生成代码禁止手改、包之间的单向依赖、测试从哪个目录跑等隐性约束显性化，让智能体开工前先读同一套操作前提。

　　一、规则文件首先要锁死“凭经验猜错”的仓库事实

　　分支与提交：明确以origin/dev为基准分支、提交采用type(scope):summary格式，避免AI按习惯添加团队不用的变更文件

　　生成代码边界：公开Protocol或Server API后必须从指定包执行生成命令，不得手改生成的客户端文件

　　依赖方向：写明底层Schema被Core与Protocol依赖、Client不得反向依赖Core或Server，防止AI为图方便制造环形依赖

　　二、把“怎样才算做对”拆成可执行的规格与验证入口

　　六格工程规格：在生成代码前先填目标、输入、不变式、异常、产物、验收六项，例如明确“禁止按自适应阈值调参”“遇到NA严禁补0”，把含糊需求翻译成不可妥协的契约

　　验证权威层级：规则文件需指明单测从包目录跑、根目录全量检查与局部类型检查各自用哪条命令，Bun与tsc冲突时以tsc为准，杜绝“测试通过但跑错目录”的伪确定性

　　先检索再动手：把“遇到不熟悉功能先查GitHub上维护活跃、许可证明确的同类项目，比较依赖和已知问题”写进项目提示词，减少自信造轮子式的返工

　　三、规则文件是底线不是终点，权限与CI才是硬围栏

　　规则文本的局限：AGENTS.md本质上仍是指令文本，不能替代权限控制、自动检查与代码评审；关键约束应尽量让CI、类型系统、生成脚本或静态检查去强制执行

　　认知卸载的分化风险：Google的律师实验显示，把工作全交给AI的初级律师能力更差，用得合理恰当的反而更强；团队应把规则文件当作协作基线，同时保留人对关键路径的判断与签字

　　从代码跑到结果可信：推荐的工作协议是“先定规格再列计划、先建测试再改代码、改完独立验证、确认可信再提交”，规则文件要据此设计，而非只约束代码风格

本文由AI生成