项目规则
Project Rules
中级通用项目规则（Project Rules）是写给 AI Agent 的项目级协作约定，通常放在它能读取的项目文件中。它让多次开发任务沿用同一套技术选择、目录习惯和验证方式，减少你每次重新交代的成本。
你可能会说：「以后让 AI 改这个项目时，能不能自动按我们的技术栈和代码习惯来？」
读之前建议先了解
动手看看给订单后台连续加功能
1
先不加载项目规则，只告诉 Agent：给订单列表加筛选功能。它收到需求，却还不知道团队的目录和验证约定。
要点项目规则怎样帮你和 AI 协作？
- 1
把反复交代的约定留在项目里
你可以写下项目使用的框架、主要目录各放什么，以及修改代码后通常运行哪些检查。这样换一个任务或开启新对话时，AI 仍有机会读到这些背景，不必靠你每次从头解释。
- 2
写清适用范围和判断依据
“保持代码整洁”很难指导行动；“新增后台页面沿用现有表单组件，并补上对应测试”更容易执行。如果前后端有不同约定，就分别说明，免得 AI 把一种做法套到整个项目。
- 3
确认规则确实被读取和执行
不同 Agent 读取项目规则的方式不一样，文件放进仓库不等于每次都会生效。你可以让 AI 先说明它读到了哪些约定，再通过代码差异和测试结果检查产出；规则也不能代替你的验收。
容易混淆的地方
项目规则面向一个项目内反复出现的协作约定；提示词通常针对眼前这次任务，比如“给注册页加邮箱验证”。配置文件则主要供程序或工具读取，用来控制实际运行行为。规则可以告诉 AI 去参考配置文件，却不会因为写了“开启严格检查”，就自动改变检查工具的配置。
什么时候用
适合用
- 你和 AI 轮流开发同一个后台，想让它每次新增页面都沿用现有组件、目录和测试习惯。
- 团队成员各自使用 AI Agent 改同一仓库，需要共享项目特有的命名和验证约定。
- 项目分前端与后端，AI 经常混用两边的实现方式，你想说明各自的适用范围。
不适合用
- 只做一次性的按钮文案修改，直接在这次任务的提示词里说清目标和验收方式就够了。
- 想强制代码通过格式检查，应该配置并运行代码规范检查工具，而不是只写项目规则。
- 需要保存 API 密钥或生产环境密码，应使用受控的密钥管理或环境变量，不适合放进项目规则。
练一练选一个答案，看看解释
你让 AI Agent 多次修改一个网站，它总在新页面里重复造按钮组件，还常忘记运行测试。你会怎样处理？
让 AI 帮你做复制给 AI Agent 直接用
请先确认你能否读取本项目的项目规则，并概括与这次修改有关的约定。然后为后台新增用户列表页，优先复用现有组件，按规则完成检查。若规则与我的需求冲突，先指出冲突，不要自行猜测。