项目指令规则：约定、构建命令与测试命令

光有配置还不够，Codex 还需要知道这个项目怎么构建、怎么测、遵循什么约定。这类信息通过项目指令文件提供，它会被自动读入每次会话的上下文。本节讲清楚指令文件该放什么、不该放什么，以及如何用它把"老师傅的经验"固化给代理。

一、指令文件里最值钱的三类信息

1. 命令事实：安装依赖、构建、运行、测试、代码检查的准确命令。例如"测试用 npm test，不要用 npm run test:all"，这能避免代理凭语言类型瞎猜命令。
2. 结构与约定：目录职责、命名规范、哪些目录是自动生成不能手改、哪些模块有特殊耦合。
3. 验收标准：什么样算"改好了"，例如"必须先补测试再改实现""提交信息遵循 Conventional Commits""不要改动锁文件"。

二、写指令的两个常见错误

错误一：写成空泛的价值观。"写出高质量代码""保持整洁"这类话对代理没有约束力，因为它不知道在这个项目里"高质量"具体指什么。要写成可执行的判断：例如"新增函数必须带 JSDoc，超过三个分支要用表驱动"。

错误二：把过时信息写死。依赖版本、接口地址、临时脚本路径容易变动。指令里写"如何运行"而不是"某个版本号"，变动频率高的具体值让代理自己去读配置文件，避免指令变成新的信息孤岛。

三、让指令"活"起来

指令文件不是写完就锁死。每次你发现代理在某件事上反复犯错、需要你反复纠正，就把这条纠正追加进指令——这正是项目记忆的价值。定期复盘：哪些约定已经失效、哪些团队规范已经改变，及时删掉过期内容。一份精简、准确、随项目演化的指令文件，比一份冗长却过时的"百科全书"有用得多。