约束先行：AI Agent高效协作的终极四字法则
在近几个月高强度使用Agent的过程中，我逐渐总结出一条至关重要的心得，关于如何为Agent设定规则、使它工作得更加聪明高效。
就四个字：约束先行。
即在让Agent执行任何任务前，先确立规范——全局规范、项目规范、文件夹规范。规则自上而下贯穿，层层嵌套，没有规范的地方绝不轻易动手。
这个道理看似简单，我却花了数月才彻底想通并完整落地。或许有人会觉得我笨拙，但正因为我踩过坑，才更想把这份经验分享出来。
为什么我认为这四个字胜过一切Prompt技巧？这要从昨天发生的一件小事说起。
我有个毛病——完美主义强迫症，东西一旦杂乱无章就会浑身难受。这大概源于我的处女座特质，加上我身为交互设计师，又是重度的模拟经营游戏玩家。在《城市天际线》中，路网规划不佳我能推倒重建三次；《动物园之星》分区不合理能让我纠结整个下午；《双点医院》里即使已经盈利，某个科室的动线不顺畅我也会全部拆除重来。至今难忘当初玩《戴森球计划》时没日没夜设计生产线的日子。朋友常说我，对秩序有种近乎偏执的追求。虽然我欣赏KK所著的《失控》，也认同混乱中能涌现智慧，但秩序与规范，或许早已刻进我的骨子里。
于是昨天下午，当我无意间发现一个Claude Code工作文件夹变得杂乱不堪时，实在坐不住了。几天前新建的专门开发Skills的文件夹，根目录下竟散落着十几个文件。打包文件与源码混放，测试图片随意丢弃，评估报告的HTML文件无处归位。最离谱的是命名：test_batch是哪个Skill的测试？test_v2又是谁的版本？我自己做的内容，搁置两天后连自己都认不出来。
那一刻我几乎应激反应，一时无语凝噎，只能含泪让Claude Code出手整理，并直接为我制定一套规范。没过多久，它便完成了。
然后它生成了这个项目级的CLAUDE.md文档。你可以将此文档理解为Claude Code进入该文件夹后首先必须读取并遵循的东西，也就是它未来的行为准则。
规范相当全面。
有了这份CLAUDE.md，工作区便能持续进行各类Skills的开发与实验。每个新Skill都会自动创建独立文件夹，实验性内容归入_sandbox，其中的文件超过一个月便自动清理。从此告别混乱，一切按目录结构井然有序。
这件极小的事促使我认真反思：为什么Claude Code进入新文件夹或开启新项目时，不会自动建立规范？为什么非要等我发现混乱之后才去收拾烂摊子？原因很简单——我并没有做好顶层约束。也就是说，在最顶层、无论打开什么文件都会加载的全局CLAUDE.md文档中，我缺失了这层规范。
过去在各类开发项目中，我脑子里始终有这种意识，通常会要求先强制写好文档再开始开发。但对于知识管理类工作——比如绘图、创造Skills、撰写研究报告等——由于缺乏开发式管理意识，往往没有形成规范文档，我本人也未曾察觉。
而对AI来说，你头脑中存在的认知，若未写入文档，便等于不存在。Agent的短期记忆会消失，对话框关闭后一切遗忘，下次打开时，它唯一能看见的就是你留下的文档和记忆文件。文档内容及其清晰度，直接决定了Agent每次“苏醒”时是清醒还是迷茫。
OpenClaw之所以常常越用越蠢，根本原因正在于其规范与记忆体系混乱不堪；相比起来，Hermes agent要好得多。
因此，我今天想聊的核心正是：用好Agent的真正关键，就在于构建一套从顶层向下贯通穿透的约束体系。解释一下Claude Code的规则架构——包括Codex在内的许多Agent均采用类似分层的设计。
最顶层为全局CLAUDE.md，位于用户目录下，无论打开什么项目均会加载。这是最高指令与原则，定义了你的身份、做事准则，以及你希望AI以何种方式与你协作。第二层是项目级CLAUDE.md，进入特定项目文件夹时才加载，相当于该项目的宪法——规定目录结构、命名规范、文件归属等。第三层是项目内的各类规范文档、设计文档和架构说明。最底层则是记忆文件，如自动记忆、对话记录、Claude自行整理的笔记等。
约束自上而下贯通，层层相扣，环环约束。这与治理公司如出一辙：制度居于最高层，部门规范居中，具体操作流程落在最底层。你不可能靠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是交互，Skills是交互，对话式AI同样是交互。
当下这个人人vibe coding的时代，我发现越来越多人忽视用户体验，许多产品仅仅满足于「能跑起来」，根本不关心使用感受。我对此深感不妥。因此，我在全局规范中写入五条交互设计核心原则。自那以后，Claude产出的成果确实截然不同了。
而「约束先行」这条虽然只有两段话，但它解决的正是根问题。
## 约束先行无论开发项目还是知识管理项目，第一步永远是建规则：新项目先写 CLAUDE.md，新目录先定结构约定（什么放哪、怎么命名、何时清理）。没有规范的工作空间不动手。已有规范的项目，严格遵守其 CLAUDE.md 中的约定。需要调整规范时先改文档、再改实践，不要反过来。
过去，Agent进入新项目时，由于本性，第一反应总是立即动手干活。如今，设定好约束之后，它的首要动作变为检查有无规范，若没有则先建立规范。后面那句「需要调整规范时先改文档、再改实践，不要反过来」同样关键。规则并非僵化不变，但修改规则也须遵循既定的路径。否则Agent会为赶进度绕开约定，届时你想补文档都无从下手。
写到这里，我突然感觉，引导Agent，与管理公司其实并无二致。经营公司需要部门架构、规章制度、SOP、协同机制、规范准则，一切一切都如出一辙。不仅如此，许多模拟经营游戏的资深玩家都明白一条道理：游戏前期最重要的不是急于建设，而是先把路网规划妥当。路网一旦规划歪斜，后续无论如何优化都无济于事，只能全部铲除重来——我亲身经历过无数血泪教训。你的CLAUDE.md就是你的路网。全局CLAUDE.md是城市主干道，项目CLAUDE.md是片区支路；主干道规划得当，支路自然顺畅。花一个小时写好它，相信我，未来能省去无数小时的返工。
今天分享的这些，你若视作Harness Engineering也无不可，因为Harness的本质就是约束。你若认为这不过是基本项目管理常识，亦无妨。我个人觉得，名目并不重要，关键在于你是否找到一套让自己与Agent协作舒适的方式。
我有时会想，这辈子所做的，本质上都是同一件事。做交互设计，是为用户行为建立约束；玩模拟经营游戏，是为虚拟城市建立约束；经营公司，是为业务和人员建立约束；如今与Agent协作，依然是在建立约束。对象不同，方法却一脉相承。先想清楚你要什么，确立规则，然后在规则框架内寻求最优解。这就是最棒的方法。