!封面
你有没有想过一个问题——Git、脚本、工作区规则，这三节课讲的东西之间到底有什么关系？
表面上看，三个独立模块：一个管版本，一个管自动化，一个管行为约束。但放在一起看，有一条隐藏的主线把它们串了起来——控制。
Git 是对文件状态的精确控制。脚本是对执行过程的精确控制。工作区规则是对 AI 行为输出的精确控制。
三件事指向同一个结论：Harness——控制系统——才是 Agent 的核心。模型只是引擎。
这篇文章是前面几篇的总纲。它试图回答一个问题：当我们讨论怎么用好 AI 的时候，我们到底在讨论什么？
Harness 是什么
先拆一个词。
Agent 由两部分构成：模型和控制系统（Harness）。模型负责推理、生成、理解语义；Harness 负责约束模型的行为边界、定义工作流程、决定模型在什么场景下该做什么。
一个不太精确但好懂的类比：
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 300">
<rect width="600" height="300" fill="#fff" rx="6"/>
<text x="300" y="35" text-anchor="middle" font-size="18" font-weight="700" fill="#333">模型 = 引擎，Harness = 方向盘 + 刹车 + 导航</text>
<!-- Left: Engine -->
<rect x="30" y="65" width="240" height="90" rx="4" fill="#f5f5f5" stroke="#999" stroke-width="1.5"/>
<text x="150" y="95" text-anchor="middle" font-size="15" font-weight="700" fill="#555">模型（引擎）</text>
<text x="150" y="118" text-anchor="middle" font-size="13" fill="#777">决定"能跑多快"</text>
<text x="150" y="138" text-anchor="middle" font-size="13" fill="#777">推理能力 / 知识广度 / 生成质量</text>
<!-- Arrow between -->
<text x="310" y="120" text-anchor="middle" font-size="28" fill="#bbb">+</text>
<!-- Right: Harness -->
<rect x="330" y="65" width="240" height="90" rx="4" fill="#f5f5f5" stroke="#333" stroke-width="2"/>
<text x="450" y="95" text-anchor="middle" font-size="15" font-weight="700" fill="#333">Harness（控制系统）</text>
<text x="450" y="118" text-anchor="middle" font-size="13" fill="#333">决定"往哪开、在哪停、走什么路线"</text>
<text x="450" y="138" text-anchor="middle" font-size="13" fill="#333">规则 / 脚本 / 版本管理 / 工作流</text>
<!-- Bottom line -->
<line x1="30" y1="185" x2="570" y2="185" stroke="#ddd" stroke-width="1"/>
<!-- Bottom insight -->
<text x="300" y="215" text-anchor="middle" font-size="14" font-weight="700" fill="#333">Harness 不让你跑得更快，它让你跑对方向。</text>
<text x="300" y="240" text-anchor="middle" font-size="13" fill="#666">引擎决定性能上限，控制系统决定产出质量的下限。</text>
<text x="300" y="265" text-anchor="middle" font-size="12" fill="#999">模型会换代，但你的方向盘不会过期。</text>
</svg>要点很简单：引擎决定车能跑多快，方向盘、刹车、导航决定车往哪开、在哪停、走什么路线。法拉利的引擎装在一辆没有方向盘的车上，除了直线撞墙没别的结局。
AI 圈有一个现象我观察了很久：所有人的注意力都钉在模型上。GPT-5 什么时候出？Claude 和 Gemini 谁更强？国产模型追上了没有？但很少有人问一个前置问题——你控制模型的能力，有没有同步增长？
这个问题的答案，取决于你把 AI 当成什么。
如果你把 AI 当工具，你不会问它。工具嘛，等供应商出一个好用的，直接用就行了。但如果你把 AI 当伙伴——一个能规划、能调用工具、能跑长程任务、甚至能在对话中越来越懂你的伙伴——控制就不再是加分项。它是必需品。你得教它、约束它、对齐它。
这就是 Harness 的意义所在。
第一层控制：Git 对文件状态的控制
你平时怎么管理文件版本？
大概率是这样：在文件夹里建若干个文件，名字后面加日期或编号——法律意见书_v1.docx、法律意见书_v2.docx、法律意见书_最终版.docx、法律意见书_最终最终版.docx。
这个方法能跑，但有一个结构性缺陷：它只能记录终点，不记录路径。
你不知道 v2 比 v1 具体改了什么。你不知道"最终版"和"最终最终版"之间差了几行字。文件多了以后，你甚至分不清哪个是哪个。
Git 解决的就是这个问题——它是程序员群体的标准版本管理工具。工作方式不是"保存多个副本"，而是每次改动形成一个快照。你可以随时跳到历史上的任意一个快照，看一眼当时文件的样子，再跳回来。这更像 Mac 电脑里的时间机器，而不是文件夹里那串 v1、v2、v3。
CloudCode 本身也有回退功能——按两次 ESC，回到之前的某一轮对话。乍一看好像也能做版本管理，但它有三个关键局限：
- 不能挑单文件回退。 如果这一轮对话改了三个文件，你对其中某一个不满意，你只能选"三个都回退"或"三个都不回退"。
- 不能跨轮次跳转。 你回到第 8 轮，第 9 到第 30 轮的全部记录就消失了。你做不到"跳到第 8 轮看一眼，再跳回第 29 轮"。
- 它不是文件级管理。 CloudCode 的回退基于对话历史，不是基于文件状态。如果你用外部 CLI 工具做了改动，CloudCode 甚至没有办法把它回退回去。
Git 完全不同。每一次 commit，是对当时工作区全部文件状态的一次完整快照。你可以随时：
- 翻出任意一个历史版本中任意一个文件的完整内容
- 对比任意两个版本之间的差异，精确到行
- 从主线分出一条分支，尝试一个激进的新方向——失败了丢弃，成功了合并回去
对于法律人，Git 的学习成本不需要很高。用我在课上的话说："你不需要像一个程序员掌握得那么深，但你要知道存在这个功能。"当你写脚本、搭工作区规则、起草重要文件的时候，Git 给你的是一个随时可以反悔的安全网。你不需要在动手之前把所有可能性想清楚——你知道搞砸了可以退回去。
这是第一层控制：对文件状态的精确控制。
第二层控制：脚本对执行过程的控制
Git 管的是"文件变成了什么样"。脚本管的，是"事情该怎么做"。
大模型有一个极容易被滥用的场景：让它做确定性任务。
什么叫确定性任务？三个条件：确定输入、确定流程、确定输出。
"把这个 PDF 转成 Markdown"——输入是一个 PDF 文件，流程是调用 MinerU 做转换，输出是一个 Markdown 文件。每一步都是确定的，不需要语义理解，不需要判断。
但如果你丢一个 PDF 给大模型，说"帮我把它转成 Markdown"，会发生什么？大模型要先理解你的意图，然后分析用什么工具，然后调用工具，然后把结果给你。在这个过程中，大模型真正创造价值的部分——语义理解和决策——几乎为零。它只是当了一个语音助手，帮你启动了一个你本可以直接启动的工具。
确定性的任务，不应该消耗大模型的 token。
不只是因为 token 要钱。更是因为大模型在确定性任务中的"理解"环节本身就是冗余——你的意图不需要被理解，它从一开始就是明确的。
脚本解决的就是这件事。
写一个脚本，等于把一条自动化流水线固化下来：输入什么、调什么工具、输出什么。写好了以后，每次运行不需要大模型参与。零 token 消耗，零理解成本，零等待时间。三个好处：
- 零 token 消耗。 脚本是一个纯程序，运行它只费电。
- 可跨工作区复用。 你在合同审核工作区写的 PDF 转 Markdown 脚本，在案件分析工作区、咨询工作区同样可以用。
- 可嵌入 skill 和 agent。 复杂 skill 走到某一步，自动调对应脚本——确定性环节交给确定性工具，不确定性环节留给大模型。
你可能会问：我不会写代码，脚本从哪来？
用大模型写。你不需要会 Python，你只需要能把需求讲清楚："我要一个脚本，用户拖入一个文件夹，里面有多层子文件夹和多种格式的文件——PDF 转 Markdown，Excel 转 JSON，图片提取文字——转换后的输出保留原始文件夹结构。"它会帮你写出来，你测试发现 bug 它帮你修。你等于用大模型开发了一个只属于你自己的小软件。开发过程中消耗了 token，开发完之后，零成本运行。
适合脚本的场景：格式转换、视频下载、批量信息提取、基础脱敏。比如从一万份裁判文书中提取案号、法院名称和裁判日期——这些结构化信息不依赖语义理解，纯脚本就能搞定。
不适合脚本的场景：需要上下文判断的任务。比如人名脱敏——两个字的可能是人名，也可能不是；一个字的就更难了。这时候你需要大模型的语义理解。
这里有一个认知跃迁值得点出来：用脚本做确定性任务，不只是在省 token。你是在把 token 省下来，用在真正需要判断的地方。
这是第二层控制：对执行过程的精确控制。你不再依赖模型去"理解"你的意图——脚本本身就是意图的固化。
第三层控制：工作区规则对行为输出的控制
Git 控制了文件状态，脚本控制了执行流程。还剩一个问题没解决——你如何告诉 AI，在什么场景下该做什么、按什么顺序做、用什么标准判断？
这就是工作区规则干的事。
CLAUDE.md 加上 rules/ 目录，构成了一套指令系统。它们不是平铺的，是分层的：
- 用户级规则（
~/.claude/CLAUDE.md和~/.claude/rules/）：对所有工作区适用的通用规则。比如"引用法条必须标注出处和时效性""法律研究先检索知识库再考虑外部来源"。这些是共性的，不该在每个项目里重复写。 - 项目级规则（项目目录下的
.claude/CLAUDE.md和.claude/rules/）：针对特定工作类型的规则。比如"合同审核工作区：收到合同后先识别主体、再逐条审查、最后输出批注版合同和法律意见书"。
为什么要分层？你试想一下把所有规则塞进一个工作区——它会像一个集成了洗衣、炒菜、音响功能的家电，每一样都做不好。小孩作业辅导的规则和法律咨询的规则放在同一个 CLAUDE.md 里，它们会互相打架。
一个典型的法律工作区规则，定义的是一条四段式流水线：
输入（接收问题或文件）→ 处理（按规则检索知识库、调 MCP 验证法条、做法律分析）→ 输出（生成结构化解答，附法条原文和来源标注）→ 归档（按问题建独立文件夹，保存输入、研究过程和最终输出）
规则不是一次性设计出来的。它是一轮一轮养出来的。
你用工作区处理了一个法律问题，发现输出没有附法条原文——你跟它说"以后每次都要附上引用的法条原文"。它改了规则文件。下一次处理问题时，输出就带了法条原文。你又发现字数限制太死，复杂问题展不开——再改。它又进化了一次。
这个过程，就是在把你的隐性判断标准变成 AI 的显性行为边界。每改一次规则，等于重新校准一次 AI 的方向盘。
还有一个容易忽略的事实：规则资产是可迁移的。
"今天 Claude Code 能用，移植到 Codex 也能用，移植到 Cursor 也能用。"所有 Agent 框架的大逻辑都一样——读上下文、遵循指令、调用工具、输出结果。CLAUDE.md 和 rules/ 的内容是纯文本 Markdown，不依赖任何特定平台。你今天在 Claude Code 里养的这套规则，哪天换了一个 Agent，把规则文件复制过去，它照样能跑。
这是第三层控制：对行为输出的精确控制。你不再需要每次从头告诉 AI 怎么做——规则已经写好了，它自己会读。
三层控制谱系
把这三层放在一起看：
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 340">
<rect width="600" height="340" fill="#fff" rx="6"/>
<text x="300" y="35" text-anchor="middle" font-size="18" font-weight="700" fill="#333">三层控制谱系</text>
<!-- Top layer: Rules -->
<rect x="60" y="60" width="480" height="60" rx="4" fill="#f0f0f0" stroke="#333" stroke-width="2"/>
<text x="300" y="83" text-anchor="middle" font-size="16" font-weight="700" fill="#333">工作区规则</text>
<text x="300" y="105" text-anchor="middle" font-size="12" fill="#555">对"行为输出"的控制 — 告诉 Agent 在什么场景下做什么、按什么顺序、用什么标准</text>
<!-- Arrow down -->
<line x1="300" y1="122" x2="300" y2="145" stroke="#999" stroke-width="1.5"/>
<polygon points="295,142 300,152 305,142" fill="#999"/>
<!-- Middle layer: Scripts -->
<rect x="60" y="152" width="480" height="60" rx="4" fill="#f5f5f5" stroke="#666" stroke-width="1.5"/>
<text x="300" y="175" text-anchor="middle" font-size="16" font-weight="700" fill="#555">脚本</text>
<text x="300" y="197" text-anchor="middle" font-size="12" fill="#777">对"执行过程"的控制 — 固化确定性任务为自动化流水线，零 token 消耗</text>
<!-- Arrow down -->
<line x1="300" y1="214" x2="300" y2="237" stroke="#999" stroke-width="1.5"/>
<polygon points="295,234 300,244 305,234" fill="#999"/>
<!-- Bottom layer: Git -->
<rect x="60" y="244" width="480" height="60" rx="4" fill="#fafafa" stroke="#999" stroke-width="1"/>
<text x="300" y="267" text-anchor="middle" font-size="16" font-weight="700" fill="#888">Git</text>
<text x="300" y="289" text-anchor="middle" font-size="12" fill="#999">对"文件状态"的控制 — 时间机器级的版本管理，随时跳到任意历史快照</text>
<!-- Right annotation -->
<text x="555" y="95" text-anchor="start" font-size="11" fill="#999">不确定</text>
<text x="555" y="187" text-anchor="start" font-size="11" fill="#999">半确定</text>
<text x="555" y="279" text-anchor="start" font-size="11" fill="#999">确定</text>
<!-- Bottom note -->
<text x="300" y="325" text-anchor="middle" font-size="12" fill="#aaa">从底层到顶层：控制精度递增，任务不确定性递增，AI 参与度递增</text>
</svg>底层是 Git——对文件状态的控制。 它解决的是"我刚才改了什么东西"和"我能不能退回去"。这一层处理的确定性最高：文件的状态就是文件的状态，没有歧义。
中层是脚本——对执行过程的控制。 它解决的是"这件事能不能不用大模型就做完"。这一层处理半确定性的任务：流程是确定的，但你可能需要大模型帮你写脚本——写完以后，脚本就是独立工具，零 token 消耗。
顶层是工作区规则——对行为输出的控制。 它解决的是"AI 的行为可预测吗，可调校吗"。这一层处理不确定性最高的需求：每个法律问题的分析路径有差异，但你仍然可以通过规则约束分析的方法、顺序和标准，让输出保持在可接受的偏差范围内。
三层不是互相隔离的。脚本可以被规则调用——你在工作区规则里写"如果用户提供 PDF 文件，先调 PDF 转 Markdown 脚本做格式转换"。Git 可以管理规则文件的版本——你改了一次规则发现效果不好，一个 git revert 就回到上一个版本。它们互相嵌入，共同构成你的 Harness。
为什么控制比引擎更重要
课上有句话容易被人忽略："规则资产可以套不同的 Agent 壳——今天 Claude Code 能用，移植到 Codex 也能用。"
这句话背后的事实是：模型会迭代、会替换，但你的 Harness 不会过期。
2023 年大家用 GPT-4，2024 年换 Claude Opus，2025 年可能又换了国产模型。每一次模型切换，你都忙着重新测试、重新适应。但如果你手里有一套成熟的 Harness——规则、脚本、工作流——换一个模型，你的工作方式不需要推倒重来。规则文件还是那些规则文件，脚本还是那些脚本，Git 仓库还是那些 Git 仓库。可能微调一些参数，但骨架不动。
这就引出了一个更根本的判断：真正产生差异化价值的，不是"用哪个模型"，而是"你如何控制模型"。
模型是供应商给你的，Harness 是你自己建的。模型的差距会缩小，甚至有一天所有主流模型在常规任务上的表现趋同。到那时候，拉开差距的就是每个人对 AI 的控制能力——你有没有一套成熟的规则体系？有没有积累可复用的脚本工具链？有没有用 Git 管理好你的每一次迭代？
这才是你的护城河。
从今天开始积累你的 Harness
方法论讲到这容易变成空谈，所以最后说四点具体的。
把注意力从"选哪个模型"转移到"怎么控制模型"。 少看点模型评测，多写点规则。
从写一条规则开始。 不用一上来就建完整的工作区体系。你今天用 AI 处理一个问题，发现某个环节总需要你手动纠正——把那个纠正写进规则里，让 AI 下次自己读。就这一条。积累 30 条，AI 的行为方式就完全不同了。
把脚本当资产来管理。 大模型帮你写了一个好用的脚本，不要用完就扔。给它写一个 README，放在固定的文件夹里，用 Git 管理版本。下次遇到同类问题，直接复用。
分层思考。 一件事丢给 AI 之前先判断：这里面有没有不需要 AI 的环节（脚本能解决）？AI 的判断标准需不需要被规范化（规则能解决）？把这些确定性环节抽离出来以后，剩下的那部分，才是真正需要大模型去理解和推理的。把 token 花在刀刃上。
这套方法论就是我理解的"法律人的 AI 控制论"。它不是抽象理论——你可以从今晚开始就动手构建。
模型会过时，但你的 Harness 不会。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。