第二节：让项目规则可读、可验证

把规则当作可维护的项目文档

CLAUDE.md 适合保存团队共同使用的项目结构、构建方式、测试入口和约束。它不等于数据库或永久聊天记录。先收集仓库里真实存在的命令，避免把猜测写成项目规范。

规则要对应一个可观察的动作

与其写“代码要高质量”，不如写“修改解析器时运行解析器测试，并记录通过或失败”。给目录、命令和验收方式，比堆积口号更有用。下面是本站练习模板，命令必须替换为当前项目真实入口。

# 项目协作约定
## 结构
- src/: 业务实现
- test/: 对应测试
## 验收
- 修改后运行：<项目真实测试命令>
- 未运行时注明原因，不宣称通过
## 边界
- 不把凭据写入代码或日志
- 发布和外部写入按任务授权执行

区分共享规则与个人设置

团队规则提交到仓库，个人习惯和本地路径应放在适合个人的配置中。不要在共享文档保存密钥。子目录规则应补充局部约定，避免与根目录互相矛盾；具体加载范围按当前版本文档核对。

用对照任务检查是否有效

选择一个需要触发规则的任务，例如修改一个函数。记录加载了哪些文件、输出是否包含测试证据。规则写进文件不代表每次都被正确遵循，关键操作还要通过程序校验和人工审查。