写一份真正有用的项目规则

如果每次都要说“本站只保留浅色模式”“不要另写一套容器宽度”，这些已经不是临时要求，适合进入项目规则。反过来，“这次把标题改成 AI”只属于一次任务，不应永久留在规则里。

规则应该替你省掉哪句话

好的规则同时说明动作和理由。例如：

- 页面外容器复用 page-shell；它与 site-frame 共享宽度变量。
  不在页面外层另加 max-width，避免导航与正文错位。
- 新增依赖、用户数据存储、部署或远程 Git 操作前先确认。
- 提交前执行 npm run verify；改可见页面还要检查桌面和手机。

“保持代码优雅”“所有东西必须高质量”缺少判断条件，不适合作为核心规则。能从类型定义直接读到的字段也不用整份复制，否则实现一更新，说明就可能失效。

最小示例

下面是本站约定的精简教学版，不是要求覆盖仓库现有文件：

# 项目入口
中文个人站；白底浅色模式；默认静态优先。
笔记内容：src/content/knowledge/
阅读顺序：src/lib/knowledge-map.ts
工具目录：src/lib/utility-tools.ts
 
# 修改边界
保留工作区已有改动。
布局复用 globals.css 中的共享容器与变量。
不要未经确认新增依赖、后端、持久化或外部写入。
 
# 检查
先读 package.json 确认可用命令。
代码改动运行现有测试；提交前运行 npm run verify。
可见页面检查桌面、手机和受影响的交互。
检查做不了时，说明缺口，不写“已通过”。

项目的特殊版本约定也值得保留。例如本站要求修改 Next.js 相关代码前先查安装版本附带文档，这能阻止模型凭旧版本经验猜接口。

两个工具怎样读取

Codex 使用 AGENTS.md；它会组合全局与项目目录链上的指令，靠近当前目录的规则可以细化上层约定。覆盖文件和具体加载行为见 AGENTS.md 官方说明。

Claude Code 使用 CLAUDE.md。如果已经维护 AGENTS.md，可以在仓库的 CLAUDE.md 中导入它：

@AGENTS.md

这是 Claude Code 文档明确支持的导入方式，不是假定两个工具自动识别同一文件。确实存在工具专属规则时，再在对应文件补充，不维护两份相同长文。

怎么确认规则有效

修改规则后，用一个新会话检查：

先只读检查当前项目规则。
列出本次实际读取的规则文件路径，
并说明：页面容器如何选、可运行哪些检查、哪些操作要确认。
若没有自动读到规则，请明确说明，不要假装已经加载。

然后做一个小任务，看它是否按规则行动。仅仅让模型复述规则，不能证明它之后必定遵守，更不能证明文件权限被限制。

别把三种东西混在一起

规则越长，越难发现冲突。每次项目结构变化时，核对受影响的入口、命令和限制；已经由测试固定的细节，文档保留意图与测试入口即可，不重复算法。