!封面

上个月，一个做合同审核科技的北京创始人联系我，他在 GitHub 上看到了我开源的项目，想听听我对他的产品的看法。

聊了一个小时。这一小时里，我反复感受到一种错位——我说的和他听到的，不在同一个维度上。

我说：律师审合同的尺度不是固定的。同一个客户，专项业务里的合同和顾问业务里的合同，审法不一样。有的客户不喜欢你提太多问题，只打七寸，能把业务推进下去就行。有的客户要你把所有小毛病都挑出来。你现在的产品没有给律师一个地方来积累客户习惯、确定尺度。

他说：你说的很有道理。但我们的逻辑是，只要现在这个产品形态有人买单，商业上就成立。下一步收集反馈再迭代。

对话到这里，我突然意识到：这不是一个产品功能讨论。是两种思维方式在对话。

法律思维：从结论出发

我是律师，做了十五年。我太熟悉法律人的思维习惯了。

给法律人一个问题，脑子里第一反应是：最终结论是什么？这个案子能赢吗？这个条款有效吗？这个交易结构有没有风险？

然后从结论往回推——需要查什么法条、找什么案例、补什么证据。

这个过程有一个特点：中间步骤都在大脑里运转，外部看不到。你看到的是输入和输出，中间是一个黑箱。黑箱里装的是经验、专业知识和判断力，但它不透明。

这种思维方式在传统法律服务中是有效的，甚至是必需的。客户花钱买的就是这个黑箱——把复杂问题吞进去，吐出可执行的判断。

但当你开始用 AI，这个思维方式出了问题。

有一个学员分享了场景：他是劳动仲裁员，需要根据劳动者七八个月的打卡数据，计算每周工作时长是否超过 40 小时。规则很明确——工作日记 8 小时，休息日记 6.5 小时，中间扣除休息时间，打卡前后几分钟取整到整点。

他把规则和打卡数据给了 DeepSeek，让它统计。

结果是错的。

反复纠正——这一周算错了重新算，下一周又错了再重新算。花的时间比用 Excel 函数手动计算还要长。

他的困惑是：规则这么清楚，AI 这么强大，为什么连四则运算都做不对？

答案：大语言模型做数学题不是"算"的，是"猜"的。它是基于概率生成下一个最可能的 token，不是执行确定性的计算程序。让它做 1+1，它不是真的在做加法，而是在猜"在人类的语言文本里，1+1 后面最常出现的是什么"。

这本身没有问题——概率生成是 LLM 的核心能力，也是它能写出流畅文本、做出合理推理的原因。问题在于，法律人把 LLM 当成"全能的智能体"来用，没意识到同一个任务里，有些步骤适合用模型的大脑，有些步骤必须用确定性的工具。

判断哪一步该用什么——恰恰是工程思维的核心。

工程思维：从"能跑"出发

工程思维的第一步不是"正确"，是"能跑"。

工程师面对需求，不会上来就设计完美方案。先做一个最小可行产品（MVP）——能跑起来就行，功能可能只覆盖 60% 的场景，界面可能很丑。扔出去，收反馈，改，再扔，再改。

这个逻辑对法律人来说是反直觉的。法律人的职业训练告诉我们：但凡开口了，就一定要是到达终点的结论。说出去的话就是专业判断，要负责。不可能跟客户说"这是我的最小可行法律意见，你先用着，有问题我再改"。

这种职业训练塑造了一种深层思维模式：追求一步到位的完美输出。

但在 AI 应用这个场景里，这个思维模式有三个代价：

第一，不愿意把中间步骤暴露出来。 法律人的工作过程是黑箱化的——脑子里想了什么，别人不知道，AI 也不知道。但 AI 需要你把过程拆开：先做什么、再做什么、每一步用什么工具、判断标准是什么。不拆，AI 就只能猜，猜就容易错。

第二，容错率太低。 AI 的输出不会是完美的，一定需要迭代。第一次得到不满意的结果就放弃了，觉得"这个东西不好用"。但工程思维的人会看：是哪一步出了问题？是数据没读进去？是 prompt 不够精确？是应该换一个工具来做这一步？调，调完再试。

第三，不做"显性化"。 法律人有很多隐性知识——知道这个条款"感觉不对"，但不太会去分析这种感觉是由什么触发的。是某个关键词？是某个数字区间？是和某个先例的对比？在 AI 时代，能不能把隐性知识显性化为规则，直接决定了能不能把它嵌入 AI 的工作流。

不是谁对谁错

我不是在说法律思维不好、工程思维好。

法律人的严谨、对结论负责、追求确定性——这些是专业服务的基石。没有这些，律师不值得被信任。

问题是，AI 应用这件事需要的不是放弃法律思维，而是在法律思维之外，叠加一层工程思维。需要同时具备两种思维，并且知道在什么环节切换。

具体来说：

需求定义阶段，用法律思维。 场景是什么、痛点在哪、风险怎么判断——这些是律师的专业领地，工程师替代不了。

流程设计阶段，切换到工程思维。 把场景拆成可以自动化执行的步骤。每一步回答三个问题：这一步的目标是什么？用什么工具来完成（模型推理 / 脚本计算 / 数据库查询 / MCP 调用）？怎么验证这一步做对了？

验证阶段，切回法律思维。 AI 产出的初稿质量可能已经很高了，但最终审核必须是人。专业判断是最后一道防线。

这个切换不是一次性的，是在一个任务循环里反复发生的。

一个具体的例子

回到那个劳动仲裁加班的场景。

用"法律思维 + 工程思维"来解，路径是这样的：

  1. 需求定义（法律思维）：需要根据打卡数据和工作日/休息日的时间规则，统计每周工作时长，判断是否超过 40 小时，计算加班工资基数。
  2. 流程拆解（工程思维）：这不是"让 AI 直接算"的问题。这是"让 AI 写一个 Python 脚本来算"的问题。Python 做四则运算是确定性的——给输入和规则，输出一定正确。AI 的角色不是做计算，是理解规则、编写脚本、解释结果。
  3. 验证（法律思维）：抽查几周手动计算结果，和脚本输出对比。确认规则有没有遗漏或偏差。

整个过程，律师做了什么？定义规则、设计流程、验证结果。AI 做了什么？理解规则、写脚本、跑数据、输出结果。

没有写一行代码。但懂了"这个任务应该用脚本来做"——这就是技术认知。知道怎么跟 AI 描述这个规则——这就是场景翻译。把两者连起来了——这就是连接能力。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 200">
  <rect width="600" height="200" fill="#fff" rx="6"/>

  <!-- Legal thinking -->
  <rect x="30" y="30" width="250" height="140" rx="4" fill="#f5f5f5" stroke="#ddd" stroke-width="1"/>
  <text x="155" y="60" text-anchor="middle" font-size="15" font-weight="700" fill="#c41e3a">法律思维</text>
  <text x="155" y="85" text-anchor="middle" font-size="12" fill="#555">定义问题：场景是什么、痛点在哪</text>
  <text x="155" y="107" text-anchor="middle" font-size="12" fill="#555">制定规则：什么算风险、什么不算</text>
  <text x="155" y="129" text-anchor="middle" font-size="12" fill="#555">验证结果：AI 的产出对不对、准不准</text>
  <text x="155" y="155" text-anchor="middle" font-size="12" fill="#555">承担最终责任</text>

  <!-- Engineering thinking -->
  <rect x="320" y="30" width="250" height="140" rx="4" fill="#f5f5f5" stroke="#ddd" stroke-width="1"/>
  <text x="445" y="60" text-anchor="middle" font-size="15" font-weight="700" fill="#333">工程思维</text>
  <text x="445" y="85" text-anchor="middle" font-size="12" fill="#555">拆解流程：这一步该用什么工具</text>
  <text x="445" y="107" text-anchor="middle" font-size="12" fill="#555">编排任务：模型推理/脚本计算/数据查询</text>
  <text x="445" y="129" text-anchor="middle" font-size="12" fill="#555">迭代优化：出错了调哪一步</text>
  <text x="445" y="155" text-anchor="middle" font-size="12" fill="#555">追求自动化与可复用</text>

  <!-- Arrow between -->
  <line x1="280" y1="100" x2="320" y2="100" stroke="#999" stroke-width="1.5" marker-end="url(#arrow)"/>
  <text x="300" y="90" text-anchor="middle" font-size="10" fill="#999">翻译</text>
</svg>

在四明山法师 AI 夜校里，我反复说一个词：业务和技术的双语者。落实到思维层面，就是这两种思维的切换能力。

纯法律人做 AI 落地，容易卡在"想要一步到位的完美输出"。纯工程师做 AI 落地，容易卡在"不知道这个场景下什么才算对"。两种思维都具备的人，才能把 AI 从玩具变成生产力。

我还没想清楚的是：这两种思维的融合到底能不能被"教会"？还是只能通过大量实践自己长出来？我能教的是框架和原理，但思维模式的切换——那种在"追求完美"和"先跑起来"之间自由横跳的能力——可能真的只能靠反复的动手、失败、调参、再试，慢慢练出来。

但有一件事我知道：不需要成为工程师才能拥有工程思维。工程思维是做事情的方法论，不是职业身份。就像不必成为数学家才能拥有逻辑思维。

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