你以为你在选工具，其实你在选关系

!封面

前阵子 Anthropic 发了一篇文章，讲 Claude 模型演进的五个阶段。前四个阶段——对话、推理、编程辅助、长程任务规划——都还好理解。第五个阶段他们用的词是"递归自我改进"：AI 开始分析自己、修改自己，进入了一个可以自我改造的阶段。

这不是未来学。是他们已经实现的事。

我把这篇文章转给几个律师朋友看。多数人的反应是"好的，等出了好产品告诉我"。这个反应本身没有问题。但它暴露了一个底层假设——而这个假设，决定了你未来三年能从 AI 那里拿到什么。

你把它当什么，决定了你愿意花多少力气

大多数法律人对 AI 的心态，我称之为"工具心态"。

逻辑很简单：AI 是一个更好用的 Westlaw，更好用的 Office。我不用关心它怎么工作，不用关心它有哪些扩展能力，不用关心 git 是什么、脚本怎么写、工作区规则怎么设计。我的任务是把法律问题丢进去，等它给我一个答案。至于它为什么答得好、为什么答得差、能不能答得更好——那是供应商的事。

这个逻辑放在传统的软件产品上完全成立。你不会为了用好 Word 去学 C++。你不会为了用好 Alpha 法律检索去研究搜索引擎的索引算法。你用螺丝刀的时候不需要理解冶金学。

但 AI 不是螺丝刀。

最近半年我在课堂上反复讲一个观点：现在的 AI 大模型，它跟互联网时代的软件产品有一个本质区别：它涌现出了自主性。它可以做规划，可以调用工具，有了行动的能力。而且随着你跟它交流越来越多，它会越来越了解你的偏好、你的判断习惯、你对"好"的定义。

换句话说：它不是一个你"使用"的东西。它是一个你可以"教"的东西。

这就是第二种心态——我称之为"伙伴心态"。

伙伴心态下，你的底层逻辑变了。你不会等着供应商给你出一个完美的法律 AI 产品，因为你知道：真正适配你的那个版本，只有你自己养得出来。你不会困惑"我一个律师为什么要学 git"——因为你发现 git 就是你跟 AI 协作的版本历史，就像你跟实习律师说"这个版本改了三处，你看看"。你不会觉得写工作区规则是额外负担，因为你意识到：写规则本质上是在把你的判断标准翻译成 AI 能理解的语言。

同一件事，在两种心态下完全不同。

工具心态：学 git 是浪费时间，我一个律师为什么要学程序员的工具。

伙伴心态：你在教一个实习生理解你的工作方式。你说"以后每次收到合同，先查客户清单确认我方身份，再按审查清单逐条过，最后输出三份文件"。这就是工作区规则。实习生需要这个，AI 也需要。

工具心态：写脚本是多此一举，AI 直接干不就行了。

伙伴心态：有些事是确定性的。PDF 转 Markdown、视频下载、批量提取案号——你教会它一次，它就永远会了，而且不消耗 token。这跟实习生一样：格式转换这种事，教一遍就够了，不用每次都解释。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 340">
  <rect width="600" height="340" fill="#fff" rx="4"/>
  <!-- Left column: 工具心态 -->
  <rect x="30" y="50" width="255" height="260" fill="#f5f5f5" rx="4"/>
  <text x="157" y="80" text-anchor="middle" font-size="16" font-weight="700" fill="#555">工具心态</text>
  <line x1="60" y1="95" x2="255" y2="95" stroke="#ddd" stroke-width="1"/>
  <text x="50" y="125" font-size="14" fill="#333">AI = 更好的 Westlaw</text>
  <text x="50" y="155" font-size="14" fill="#333">等着供应商出好产品</text>
  <text x="50" y="185" font-size="14" fill="#333">"我是律师，不学程序员工具"</text>
  <text x="50" y="215" font-size="14" fill="#333">学 git/写规则 = 额外负担</text>
  <text x="50" y="245" font-size="14" fill="#333">用就行了，不用理解</text>
  <text x="157" y="285" text-anchor="middle" font-size="13" fill="#999">→ 天花板 = 供应商的版本号</text>

  <!-- Right column: 伙伴心态 -->
  <rect x="315" y="50" width="255" height="260" fill="#f0f0f0" rx="4"/>
  <text x="442" y="80" text-anchor="middle" font-size="16" font-weight="700" fill="#222">伙伴心态</text>
  <line x1="345" y1="95" x2="540" y2="95" stroke="#ccc" stroke-width="1"/>
  <text x="335" y="125" font-size="14" fill="#111">AI = 可以教的实习生</text>
  <text x="335" y="155" font-size="14" fill="#111">自己养出适配你的版本</text>
  <text x="335" y="185" font-size="14" fill="#111">"我在教它理解我的判断标准"</text>
  <text x="335" y="215" font-size="14" fill="#111">git/规则/脚本 = 对齐工具</text>
  <text x="335" y="245" font-size="14" fill="#111">每次交互都在进化</text>
  <text x="442" y="285" text-anchor="middle" font-size="13" fill="#222">→ 天花板 = 你的迭代速度</text>
</svg>

控制系统的意义

在 Claude Code 的架构里，AI 被分成两部分：模型（model）和控制系统（harness）。模型负责理解和生成，控制系统负责管它——什么时候调什么工具、遵循什么规则、输出什么格式、存档到哪里。

我刚接触这个概念的时候，觉得 harness 就是一些技术配置。用得多了才意识到，harness 是你跟 AI 之间的对齐层。你通过它来告诉 AI：我是谁、我在做什么、我认为什么是好的、我习惯怎么做事。

拆开来看，harness 主要由这些东西构成：

Git。程序员用 git 管代码版本，法律人用文件名管文档版本（"法律意见书 v3 终稿真的终稿最终版.docx"）。git 让你随时回到历史上任何一个版本、开分支尝试不同方向、合并最好的结果。它不是"程序员的工具"，它是对"变更"这件事的管理方式。

脚本。确定性的工作——格式转换、视频下载、批量信息提取——不需要 AI 每次都"理解"一遍。写一个脚本，固定输入、固定流程、固定输出，零 token 消耗，永远可复用。脚本是你在告诉 AI："这种事以后不用问我，直接做。"

规则。这是 harness 里最核心的东西。规则是你把判断标准写下来：收到法律咨询先建文件夹、先查知识库再查商用数据库、输出必须附法条原文、碰到 PDF 先调转换脚本。规则越细，AI 越像你。

工作区。把上面这些东西按照一个特定工作场景组织起来，就是一个工作区。法律咨询是一个工作区，合同审核是另一个，案件分析是第三个。它们各有各的规则、各有各的知识库引用路径、各有各的输出模板。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 260">
  <rect width="600" height="260" fill="#fff" rx="4"/>
  <text x="300" y="32" text-anchor="middle" font-size="16" font-weight="700" fill="#333">Harness = 你与 AI 的对齐层</text>
  
  <!-- Center: Harness box -->
  <rect x="180" y="55" width="240" height="40" fill="#333" rx="4"/>
  <text x="300" y="80" text-anchor="middle" font-size="15" font-weight="700" fill="#fff">Harness（控制系统）</text>
  
  <!-- Four components -->
  <rect x="30" y="125" width="110" height="50" fill="#f5f5f5" rx="3" stroke="#ccc" stroke-width="1"/>
  <text x="85" y="148" text-anchor="middle" font-size="13" font-weight="600" fill="#333">Git</text>
  <text x="85" y="165" text-anchor="middle" font-size="11" fill="#888">版本管理</text>
  
  <rect x="155" y="125" width="110" height="50" fill="#f5f5f5" rx="3" stroke="#ccc" stroke-width="1"/>
  <text x="210" y="148" text-anchor="middle" font-size="13" font-weight="600" fill="#333">脚本</text>
  <text x="210" y="165" text-anchor="middle" font-size="11" fill="#888">确定性自动化</text>
  
  <rect x="280" y="125" width="110" height="50" fill="#f5f5f5" rx="3" stroke="#ccc" stroke-width="1"/>
  <text x="335" y="148" text-anchor="middle" font-size="13" font-weight="600" fill="#333">规则</text>
  <text x="335" y="165" text-anchor="middle" font-size="11" fill="#888">判断标准</text>
  
  <rect x="405" y="125" width="110" height="50" fill="#f5f5f5" rx="3" stroke="#ccc" stroke-width="1"/>
  <text x="460" y="148" text-anchor="middle" font-size="13" font-weight="600" fill="#333">工作区</text>
  <text x="460" y="165" text-anchor="middle" font-size="11" fill="#888">场景化组织</text>
  
  <!-- Arrows from components to bottom -->
  <line x1="85" y1="175" x2="85" y2="195" stroke="#999" stroke-width="1"/>
  <line x1="210" y1="175" x2="210" y2="195" stroke="#999" stroke-width="1"/>
  <line x1="335" y1="175" x2="335" y2="195" stroke="#999" stroke-width="1"/>
  <line x1="460" y1="175" x2="460" y2="195" stroke="#999" stroke-width="1"/>
  <line x1="85" y1="195" x2="460" y2="195" stroke="#999" stroke-width="1"/>
  <line x1="270" y1="195" x2="270" y2="220" stroke="#999" stroke-width="1"/>
  
  <!-- Result -->
  <rect x="170" y="220" width="260" height="28" fill="#eee" rx="3"/>
  <text x="300" y="239" text-anchor="middle" font-size="13" fill="#333">让 AI 越来越像你，而非越来越像所有人</text>
</svg>

工具心态下，你会问："为什么 Cloud Code 不能直接给我一个做好的工作区？"

伙伴心态下，你会发现这个问题本身就问错了。不是"为什么没有现成的"，而是"现成的怎么可能适配你"。你的知识库跟别人不一样，你的客户习惯跟别人不一样，你对"好"的判断标准跟别人不一样。你不把标准写进规则里，AI 就只会给你一个平均水平的答案。

"我是律师，不是程序员"

这是最常见的反对意见，也是最有道理的一个。

如果你把 AI 当工具，那要求律师学 git、写脚本、搭工作区确实荒谬。就像要求司机学会修发动机才能开车。

但如果你把 AI 当伙伴，这个类比就换了。

你不是在学修发动机。你是在学怎么跟一个能力很强但什么都不了解的实习生共事。你要告诉它你的工作习惯、你的判断标准、你希望它怎么跟你配合。这些东西的"语言"恰好涉及 git、脚本、规则——但它们是手段，不是目的。

我带过实习律师，也带过 AI。这两件事的底层逻辑惊人地相似。

实习律师来了，你不可能直接说"给我写一份法律意见书"。你要先告诉他文件夹怎么建、模板在哪里、碰到什么类型的法律问题去翻哪个数据库、翻完数据库不够再查什么、客户的特殊偏好是什么（"这个客户不喜欢长段落，结论要放在最前面"）。这些交代完了，他交上来的东西才勉强能用。然后你看一遍，告诉他哪里不对、为什么不对、下次怎么改。改了几轮，他开始能独立出活儿了。

AI 完全一样。

区别只有一个：实习律师你交代一次，他记住了（或者没记住，你要再交代一次）。AI 你交代一次，写进规则里，它就永远不会忘。

我给你一个具体的例子。

我的法律咨询工作区里有一条规则：收到任何法律问题，必须先在本地知识库里搜——不是先去网上搜，不是直接用模型预训练数据生成。本地知识库的检索顺序也有规定：先翻最高法的理解与适用，再查法条原文和标准资源，还不够才去扩展检索公众号存档。每一条引用的法条，必须通过商用数据库验证。输出必须带附录，把相关法条原文列出来。

这套规则不是一次写成的。第一次我只写了"查知识库"三个字，跑出来的结果不够好。我发现它检索的时候所有来源混在一起搜，噪音很大。于是我加了检索顺序。后来又发现引用的法条偶尔有误，于是加了验证步骤。再后来觉得输出太薄，于是加了附录要求。

每次迭代都花不了几分钟。但一年下来，这个工作区已经变成了一套高度适配我的法律研究系统。它知道我的知识库里有什么、知道先翻什么后翻什么、知道引用的法条必须验证、知道输出必须带原文附录。换一个人用这个工作区，效果会差一截——因为这套规则是为我的工作方式写的。

这就是"养"一个 AI，而不是"用"一个 AI。

你选的关系，决定你能走多远

回到开头那个问题：为什么大多数法律人把 AI 当工具？

不是因为工具心态是错的。而是因为工具心态符合我们过去二十年对软件的认知。软件就是产品，产品就是拿来用的，好产品应该开箱即用。

但 AI 不是软件产品。它更接近一个能力框架。你能从这个框架里拿到什么，取决于你往里面放了什么。你放了你的知识库，它就懂你的领域。你放了你的判断标准，它就按你的标准做事。你放了你的客户习惯，它就按客户的偏好输出。

什么都不放，它就给一个互联网平均水平——不差，但也不可能是你的。

Anthropic 那篇文章让我触动最大的不是"AI 能自我改造了"这个技术事实，而是它背后隐含的推论：AI 的进化速度取决于使用它的人怎么跟它互动。那些把它当伙伴、花时间教它、用 harness 跟它对 align 的人，他们的 AI 会以更快的速度变得更好。而那些把它当工具、等供应商更新的人，他们手里的 AI 永远停在上一站。

这不是"谁先用上 GPT-5"的差距。这是"谁能持续迭代自己的系统"的差距。

前者是一次性的。后者是复利的。

今天我在四明山法师 AI 夜校教律师们 git、脚本、工作区规则，有人觉得这些太技术了，跟法律工作没关系。我理解这个反应。但我想说的是：你看到的是一堆技术工具，我看到的是一套对 alignment 的语言——你在用它告诉 AI：这是我，这是我做事的方式，这样才算做得好。

你以为你在选工具，其实你在选关系。

作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。