给编程智能体设定可执行的项目规则

AI 编程代理把项目改坏，未必是模型不够聪明，也可能是它不知道哪些事绝不能做、哪些改动不在任务范围内。作者的办法是把项目规则缩短、排好优先级，让代理在每次会话开始时读取。

这套方法针对的都是日常麻烦：小修变重写、密钥进入前端、接口漏鉴权、同一个错误反复乱试。值得借鉴的是具体约束和检查方式，但原文没有给出对照实验，不能据此认定几份规则文件就能解决可靠性问题。

先排优先级，再要求代理完成任务

作者遇到的问题并不复杂：只需小改的文件被整体重写，无关代码被重命名、重新格式化；密钥进入客户端产物，或者 .env 被提交；新路由在正常流程下能用，却缺少鉴权；同一个错误连续尝试 5 次，修复效果越来越差。

作者的解释是：没有明确优先级时，「让它跑起来」容易压过安全和改动范围。

因此，他给指令排了三层顺序：

1. 安全约束最高，即使收到相反要求也不能违反。
2. 其次是用户提出的任务，并且要留在任务范围内。
3. 最后才是工作风格偏好。

指令冲突时，代理还要说明自己遵循了哪一层。这样，规则不只是列出禁令，也给出了发生冲突时的处理顺序。

让代理知道什么比完成任务更重要，是这套方法的起点。

小改动和停止条件，比一味重试更具体

作者要求代理先读将要修改的文件，以及调用这些文件的代码，再动手。只看报错所在的一行，往往不足以理解修改会影响谁。

接着是控制改动量：采用最小修改，不整体重写已经正常工作的文件。对需求歧义，先问一个简短问题，再继续推进。

调试也有明确边界：同一个 bug 修复失败 2 次，就停下来，汇总已经尝试的办法，在第 3 次尝试前询问用户。它并不是宣称两次之后就无法修好，而是给重复盲试设置一个检查点，让人有机会纠正方向。

安全规则则要持续生效：

• 密钥只放在服务端环境变量中。
• 敏感路径要检查调用方，不能只验证正常请求能否成功。
• 破坏性的 Git 操作、rm -rf 和 --force，必须有用户明确要求。
• 运行真实测试，不能靠跳过测试获得通过结果。

完成后，代理需要报告改了什么、运行了什么，以及哪些内容没有验证。作者尤其看重最后一项，因为一句「完成了」无法说明实际检查到了哪里。

规则放进仓库后，还要检查代理有没有读到

作者把共享规则放在 AGENTS.md，在 CLAUDE.md 中用 @AGENTS.md 引用。对于 Cursor，他建议在 .cursor/rules/ 下增加一份简短、始终启用的规则，让安全条款进入每次聊天。

这里的思路是共享主体内容，再为不同工具提供入口，避免每份文件都复制一套长篇规则。

作者提供的免费 MIT starter 包含这些文件、一份 10 项上线前检查清单和 3 个提示词。操作方法是把 3 个文件复制进项目，开启新聊天，然后让代理复述最高优先级规则和安全条款。如果答不出来，作者认为应检查文件是否放在该工具能读取的位置。

这一步很实用：规则文件存在，不等于代理已经读到。

作者也提到 Etsy 上的付费 Vibe Coding Rules Kit，包含更多技术栈和一条命令的安装器。他在小仓库使用免费 starter，跨多个工具时使用付费套件，但原文没有展示安装命令，也没有提供两者效果的对照数据。

我的判断

我赞同把规则写短，并明确修改范围、停止条件和交付证据。相比给每个工具粘贴一份 400 行「章程」，这种做法更便于维护，也更容易检查代理是否理解了重点。

但「这些规则帮助了作者」仍是经验之谈。原文没有给出模型版本、项目规模、事故数量或前后对照，无法判断收益有多大，也无法证明问题主要来自规则缺失。

更关键的是，文字约束能表达要求，却不能保证执行。要求密钥留在服务端，不代表客户端构建产物必然安全；要求新路由鉴权，也不代表代理一定正确实现。代码审查、测试和权限控制仍然需要承担实际检查职责。

「失败 2 次就询问」也有使用前提。它适合人在场的交互式编程；对无人值守任务，还需要另行定义停止后如何交接。作者没有讨论这部分。

能拿来做什么

• 给前端或 Node 项目整理一份简短的 AGENTS.md，明确安全优先、任务范围其次，并要求修改前阅读相关文件及调用方。
• 在接入不同编程工具后，开启新会话，让代理复述优先级和安全条款，以此检查规则是否被读取。
• 修复同一个 bug 失败 2 次后，要求代理先列出尝试内容和结果，再决定第 3 次怎么做，避免重复相似修改。
• 把交付说明固定为「改了什么、运行了什么、未验证什么」，检查测试命令与结果，再判断任务是否完成。