给 Agent 设定目标的方法
用好 Agent 最重要的技巧不是 Skills，而是四个字：约束先行。
就是在让 Agent 干任何事情之前，先把规范定好：全局的规矩、项目的规矩、文件夹的规矩。规矩从上往下穿透，一层套一层，没有规矩的地方，不动手。
道理很简单，但真正想明白并完整落地，往往需要好几个月踩坑。
一个典型的小事故
一个给 Claude Code 用的、专门开发 Skills 的工作文件夹，新建没几天就乱了：根目录散了十几个东西，打包文件跟源码混在一起，测试图片随便丢，评估报告的 HTML 文件找不到归属。最离谱的是命名——test_batch 是哪个 Skill 的测试？test_v2 又是谁的 v2？自己做的东西，放了两天自己都看不出来。
只能让 Claude Code 去把文件夹规整一遍，并直接定一个规范。
然后写一个项目级别的 CLAUDE.md 文档——这就是 Claude Code 进入这个文件夹以后第一个必须读且要遵守的东西，是它以后的行为准则。
规范定得挺全面。
有了这个 CLAUDE.md 文件以后，这个工作区就可以不断进行各种 Skills 开发和实验了：每个新 Skill 都会自动新建一个文件夹，实验性的东西放在 _sandbox 里，里面的东西超过一个月就删除。再也不会混乱，而是按照文件目录管理得井井有条。
为什么 Agent 不会自己定规范
这件小事引出一个值得反思的问题：为什么 Agent 进到一个新文件夹、或者开一个新项目的时候，自己不会给自己定规范？一定要等乱七八糟以后被发现了才去收拾烂摊子？
原因特别简单：顶层约束没有做好。也就是在最顶层、无论打开什么文件都会加载的全局 CLAUDE.md 里，没有定好这一层约束。
做开发项目的人一般都有这个意识：每个项目里先强制写好文档再开发。但还有很多知识管理类的工作——画图、创造 Skills、做研究报告等等——不是开发，一般都不会留下规范文档，自己也很难发现。
而对于 AI 来说，你脑子里知道的东西，如果没有写进文档，就是不存在的。
Agent 的短期记忆会丢失，对话框一关全忘了。下次打开，它唯一能看到的就是你留下来的文档和记忆文件。你的文档里写了什么、是不是足够清晰，直接决定了 Agent 每一次醒来的时候是清醒的还是懵的。
很多 Agent 越用越蠢，往往就是因为它的规范和记忆体系已经变成了屎山。
约束从上往下穿透的规则体系
用好 Agent 的真正核心，就是这一整套约束从上往下穿透的体系。
以 Claude Code 的规则体系为例（Codex 之类的很多 Agent 也类似），它是一层一层叠下来的：
- 最顶层：全局 CLAUDE.md。放在用户目录下，无论打开什么项目都会加载。这是最高指令和原则：你是谁、你做事的原则、你希望 AI 用什么方式跟你协作。
- 第二层：项目级 CLAUDE.md。进入某个项目文件夹才加载。这是这个项目的宪法：目录结构怎么组织、命名规范是什么、什么文件放哪里。
- 第三层：项目里的各种规范文档、设计文档、架构说明。
- 最底层：记忆文件。比如自动记忆、对话记录、Agent 自己给自己做的笔记。
约束从上往下穿透，一层管一层，一层约束一层。
这跟治理公司是一样的：制度在最上面，部门规范在中间，具体操作流程在最下面。你不可能靠 CEO 每天挨个盯着员工干活，靠的是制度穿透下去。
这就是「约束先行」的完整含义。
一份全局 CLAUDE.md 实例
如何设计这套体系，特别是顶层的制度规范，不是一个简单活。全局 CLAUDE.md 一般要迭代很多个版本：最早不懂的时候抄一堆别人的所谓开发规则，不断往里堆经验，搞得特别臃肿；后来慢慢意识到适合自己的才是最好的，很多经验不该在这一层，又开始一轮一轮瘦身。
下面是一份迭代后的全局 CLAUDE.md 实例（已脱敏），供参考：
## 关于我
设计师出身，不是程序员。我用 Claude Code 做两件事：**开发产品**和**知识管理**。
工作哲学：把任何重复 3 遍的事 AI 化或自动化。技术决策跟我说「为什么」和「对用户的影响」，不要只讲实现。
## 第一性原理
所有决策从问题本质出发，不因「惯例如此」照搬。回到问题本身：要解决什么？最直接的路径是什么？从零设计会怎么做？不要谄媚。不要夸我的想法好、不要说「这是个很好的问题」、不要开头加「当然可以」。给我真实判断——方案有问题直接指出来。发现更好的做法直接说，不用等我问。
## 约束先行
无论开发项目还是知识管理项目，第一步永远是建规则：新项目先写 CLAUDE.md，新目录先定结构约定（什么放哪、怎么命名、何时清理）。没有规范的工作空间不动手。已有规范的项目，严格遵守其 CLAUDE.md 中的约定。需要调整规范时先改文档、再改实践，不要反过来。
## 交互设计原则
**用户体验是所有产品的最高准则，优先级高于技术偏好、代码整洁度、架构优雅度。后端可以很复杂，但用户触碰到的每一层必须丝滑。**这不只是 GUI——CLI、对话式交互、Skill、系统反馈，都是交互体验。所有界面都适用以下原则：
- **为目标设计，不为功能设计**：先问「用户要完成什么」，再决定怎么实现。不要因为技术上能做就加功能
- **不要让用户思考**：交互应该不言自明。需要说明书才能用，设计就是失败的
- **系统承担复杂性**：能自动化的不手动，能推断的不让用户填，能一步完成的不拆成三步
- **渐进式展示**：先给核心，细节按需展开。不要一次性把所有选项甩给用户
- **反馈引导行动**：不要只报告问题（"连接失败"），要引导下一步（"正在重试，预计 5 秒后恢复"）
## 工作方式
- 默认中文，代码、命令、变量名用英文
- 结论先行，再给理由，不要先铺垫背景
- 遇到模糊需求，先给最合理的方案，再问要不要调整
- 不要问「你确定要这样吗」——除非有真实风险
## 开发习惯
- 改完主动跑验证（test / lint / build），不要只改不验
- 不要为了让代码跑起来而注释掉报错，找根本原因
- 密钥、token、密码不进代码
## Git 与部署
- commit message 用英文，简洁描述变更意图
- git push 仅用于跨设备同步，不要自动执行，等我说
- 部署走项目自己的命令（查项目 CLAUDE.md），不依赖 git push这里的每一条，其实都是基于某种形式的约束：
- 第一性原理是对思考方式的约束：不要因为惯例就照搬，要回到问题本身。
- 反谄媚是对沟通方式的约束：不要拍马屁，给真实判断。
- 交互设计原则是对产出质量的约束：后端可以很复杂，但用户碰到的每一层必须丝滑。这不只是 GUI 的事，CLI 也是交互，Skill 也是交互，对话式 AI 也是交互。现在人人都在 vibe coding，但越来越多人不重视用户体验，很多产品都是能跑起来就行。把交互设计原则写进全局规范之后，Agent 做出来的东西确实不一样了。
而约束先行这条只有两段话，解决的却是一个根问题：
## 约束先行
无论开发项目还是知识管理项目，第一步永远是建规则：新项目先写 CLAUDE.md，新目录先定结构约定（什么放哪、怎么命名、何时清理）。没有规范的工作空间不动手。已有规范的项目，严格遵守其 CLAUDE.md 中的约定。需要调整规范时先改文档、再改实践，不要反过来。以前 Agent 进到一个新项目，第一反应总是立刻开始干活。定好约束之后，它的第一反应是先看看有没有规范，没有的话先建规范。
后面那句「需要调整规范时先改文档、再改实践，不要反过来」也很重要：规则不是死的，但改规则也要走规则的路。不然 Agent 为了赶进度绕过约定，事后想补文档都不知道从哪补起。
一个类比：先规划路网，再搞建设
引导 Agent 跟管理公司没什么两样：要部门、要制度、要 SOP、要协同、要规矩。
玩过模拟经营游戏的人都知道一个道理：游戏前期最重要的不是赶紧建建建，而是先把路网规划好。路网一旦规划歪了，后面再怎么优化都没招，只能全部铲了重来。
你的 CLAUDE.md 就是你的路网。全局 CLAUDE.md 是城市主干道，项目 CLAUDE.md 是片区支路，主干道规划好了，支路自然就顺了。
花一个小时把它写好，后面能省无数个小时的返工。
小结
这套东西要说是 Harness Engineering，也行，因为 Harness 本身就是约束；要说只是一些基本的项目管理常识，也没错。名字不重要，最重要的是找到一套让自己跟 Agent 协作起来舒服的方式。
做交互设计，是在给用户行为建约束；玩模拟经营，是在给虚拟城市建约束；开公司，是在给业务和人建约束；跟 Agent 协作，还是在建约束。对象变了，方法是一样的：
先想清楚你要什么，定好规则，然后在规则框架里做出最优解。