读完 Ryrenz 的《一文看懂 Harness Engineering，帮你的 AI 提效 10 倍》之后，我对自己最近做的几个开源项目有了一个更准确的解释。

我原来以为自己是在做法律 AI 工具。

现在更准确地说，我是在给法律人搭 Harness。

这篇文章讲的不是一个新名词，而是一个很现实的问题：模型能力已经很强，但裸模型进入严肃工程任务时仍然会失败。文章用 ProgramBench、Terminal-Bench、Codex、Claude Code、Superpowers 等例子说明，真正拉开差距的，不只是模型本身，而是模型周围那套工程环境。

也就是 Harness。

它不是一个更长的 prompt。

它是上下文管理、工具执行、任务编排、反馈机制和架构护栏共同组成的一套工作系统。

这句话放到法律工作里，几乎可以直接成立。

法律 AI 的问题，也不是模型不会写。

恰恰相反，模型太会写了。

材料没读完，它可以写。

法规没核验，它可以写。

客户授权、审查立场、交付对象还没确认，它也可以写。

所以法律人真正需要的，不是一个更会说话的 AI，而是一套能让 AI 按法律工作方式运行的 Harness。

1. 从工程 Harness 到法律 Harness

Ryrenz 那篇文章把 Harness 拆成五个核心维度：

上下文管理
执行能力
任务编排
反馈机制
架构护栏

这五个词看起来是软件工程里的词。

但如果换成法律工作语言，其实就是：

上下文管理：AI 工作前应该读取哪些材料、规则、历史记录和身份边界
执行能力：AI 可以调用哪些工具、读取哪些文件、生成哪些中间产物
任务编排：一个法律任务应该先做什么、后做什么、在哪些节点停下来
反馈机制：输出前如何校验来源、事实、格式、隐私和交付边界
架构护栏：哪些事情无论模型多自信，都不能越权执行

这就是我理解的 Legal Harness Engineering。

它不是把 AI 包装成法律人。

它是把法律人的工作流程拆开，让 AI 在合适的节点参与，同时保留来源边界、权限边界和人工复核。

2. 为什么法律人不能只靠聊天框

法律工作不是一个单纯的文本生成任务。

它同时包含事实、证据、规则、期限、授权、程序、身份、格式和交付对象。

同一句“帮我看看这个合同”，背后可能是完全不同的任务：

  • 快速看几个明显风险；
  • 站在甲方或乙方立场完整审查；
  • 生成内部风险清单；
  • 生成给客户看的审查意见；
  • 输出带真实修订痕迹和批注的 Word 红线稿；
  • 把续约、付款、解除、违约事项写入台账。

这些都叫合同审查。

但它们不是同一个权限等级。

让 AI 摘要合同，和让 AI 修改合同正文，不是一回事。

让 AI 标记风险，和让 AI 形成正式交付，也不是一回事。

如果没有 Harness，AI 很容易直接跳到结论。

法律工作里，最危险的不是 AI 写不出来。

而是它在不该写的时候，写得很像那么回事。

3. 上下文管理：legal-skills 和法律 Wiki

Ryrenz 的文章里有一个核心判断：运行时拿不到的知识，对 Agent 来说就等于不存在。

这也是我做 legal-skills 和法律 Wiki 时最看重的一点。

legal-skills 不是一个法律提示词合集。

它是一套面向中国法律工作的 Agent Skill Harness。

项目地址：

https://github.com/pa1nrui1/legal-skills

官网项目页：

https://www.panrui.xyz/projects/legal-skills/

它以 法律工作总控 为入口，先判断任务类型，再路由到具体 Skill。法律咨询、合同审查、合同起草、民事一审、刑事辩护、劳动争议、破产、产品法务、监管合规、法规案例检索和文书导出，不应该共用同一套回答方式。

上下文管理在这里至少包含四层：

任务上下文：这是咨询、合同、诉讼、检索，还是文书交付
材料上下文：实际读取了哪些文件，哪些材料缺失，OCR 是否存疑
规则上下文：涉及哪些法条、司法解释、案例、地方规则或 Wiki 页面
交付上下文：输出给谁看，是内部草稿、客户沟通，还是正式文件

法律 Wiki 则承担知识底座的角色。

入口：

https://www.panrui.xyz/wiki/

Wiki 不是法律意见库。

它更像来源层：把法条、司法解释、争议点、证据审查提示和人工复核提醒整理成结构化知识。这样 Agent 在进入具体任务前，不是只靠模型记忆，而是有机会回到可追溯的材料。

这对应 Harness 里的第一件事：

不要把所有东西都塞给模型。

要把上下文分层、文件化、可检索。

4. 执行能力：AI 要有工具，但工具不能乱堆

Ryrenz 的文章里有一个很重要的反直觉原则：工具不是越多越好。

一个 Agent 接太多工具，模型每一步都要判断该用哪个，反而容易走错路。

法律工作也是一样。

如果给 AI 太多没有边界的能力，比如随意联网检索、随意修改文件、随意生成正式文书、随意访问客户资料，它看起来更强，实际风险更大。

所以在 legal-skills 里，我更愿意把执行能力限定在几个清楚节点：

读取材料
提取关键字段
生成来源边界
形成工作草稿
执行出稿前检查
导出可复核文件
记录缺口和待确认事项

它可以帮律师或法务推进工作。

但它不应该直接越过事实确认、法律依据核验和人工判断。

在 enterprise-legal-ops 里也是一样。

项目地址：

https://github.com/pa1nrui1/enterprise-legal-ops

官网项目页：

https://www.panrui.xyz/projects/enterprise-legal-ops/

企业法务场景里，AI 可以读取合同、制度、证照、员工资料、章程权限和提醒事项，帮助生成摘要、台账、缺口提示和本地问答。

但涉及签署、解除、担保、借款、融资、劳动处理、用印和章程权限时，必须进入严审流程。

执行能力要变成可控能力。

不是“AI 能做什么就让它做什么”，而是“这个节点允许 AI 做什么”。

5. 任务编排：从一次回答到 workflow

文章里讲长任务时提到一个典型失败：让 AI 一次性完成一个复杂功能，往往会越写越乱。更好的方式是先拆任务，再一步一步执行，并把进度外置到 progress.md、git commit 这类系统记录里。

法律工作同样不能 one-shot。

比如一项诉讼任务，不应该从“客户发来一堆材料”直接跳到“帮我写起诉状”。

更合理的 workflow 应该是：

确认任务类型
  -> 建立材料清单
  -> 读取并摘要材料
  -> 提取主体、时间、金额、证据、争议点
  -> 标记缺口和待确认事实
  -> 检索或读取规则
  -> 生成请求权或抗辩结构
  -> 形成工作草稿
  -> 出稿前审查
  -> 人工复核
  -> 正式交付

这就是 legal-skills 里“法律工作总控”的意义。

它不是为了多一道入口。

它是为了防止任务直接滑向结论。

agent-content-workspace 也是同一套思路。

项目地址：

https://github.com/pa1nrui1/agent-content-workspace

官网项目页：

https://www.panrui.xyz/projects/agent-content-workspace/

内容创作也不能只靠“帮我写一篇文章”。

它应该先读创作者定位、内容主线、平台规则、文风偏好和隐私边界，再做选题检查、草稿状态管理、发布前检查和复盘。

所以这个项目的 workflow 是：

读取创作者配置
  -> 检索历史内容
  -> 判断平台规则
  -> 生成选题和 outline
  -> 撰写 draft
  -> 做事实和隐私检查
  -> 生成平台版本
  -> 人工确认发布
  -> 记录复盘和 Learning

这和法律任务本质上是同一件事：

把一次性对话变成可持续工作的流程。

6. 反馈机制：AI 说完成了，不等于真的完成了

Ryrenz 的文章里有一句判断很适合迁移到法律场景：AI 说修好了没有用，跑通测试才算完成。

在法律工作里，可以换成：

AI 写完了没有用，过了复核门才算进入下一步。

法律工作里的反馈机制，不一定是单元测试，但一定要有验证门。

比如：

材料是否真的读过
关键事实是否有来源
法规案例是否核验
引用是否标注现行有效状态
结论是否超出材料
是否混淆事实、推断和建议
是否暴露客户、案件或隐私信息
输出是否符合交付对象
是否需要律师或法务确认

这就是为什么我在项目里反复使用 preflight、review gate、source boundary、human-in-the-loop 这些词。

它们不是装饰性的免责声明。

它们是 Harness 的反馈回路。

没有反馈机制，AI 很容易把“看起来完整”误认为“可以交付”。

7. 架构护栏：法律 AI 最重要的是不能越权

在软件工程里，架构护栏可以是 linter、pre-commit hook、CI gate。

在法律工作里，架构护栏首先是权限分级。

我在 legal-skills 里默认把人机分工拆成四层：

L1：读取与整理
L2：分析与标记
L3：草稿与执行
L4：确认与正式交付

L1 和 L2 可以让 AI 多参与。

比如读取材料、整理事实、标记风险、提出证据缺口、生成检索方向。

L3 可以让 AI 生成草稿或执行工程动作。

比如起草内部工作稿、生成结构化数据、导出待复核文档。

但 L4 必须由人接管。

包括正式法律意见、对外文件、关键商业判断、诉讼策略选择、是否签署、是否解除、是否用印、是否公开某个案例。

这不是保守。

这是法律工作本身的结构。

法律 AI 的 Harness 如果没有权限护栏，就会把效率变成风险。

8. 这几个项目其实是一套系统

把它们放在一起看，我现在做的不是四个孤立项目。

它们对应的是法律人使用 AI 的四个层面：

legal-skills：任务层
enterprise-legal-ops：资料和状态层
agent-content-workspace：公开表达和个人 GEO 层
法律 Wiki：知识来源层

它们共同回答一个问题：

一个法律人要真正使用 AI，不应该只问“用哪个模型”。

更应该问：

AI 工作前读什么？
AI 能调用什么？
任务如何拆分？
输出如何验证？
哪些事项必须人确认？
经验如何沉淀到下一次？

这也是我为什么把自己定位成：

法律人的 Harness Engineer。

这个定位不是为了造一个新头衔。

它只是更准确地描述了我正在做的事：作为一名执业律师，把法律、企业法务、内容表达、知识库和 Agent workflow 组织成可运行、可复核、可改造的系统。

9. 边界

最后还是要把边界说清楚。

这些项目都不提供法律意见。

它们输出的内容，应当被理解为供律师、企业法务、创作者或相关专业人士复核的工作草稿、管理记录、知识参考或流程模板。

真实法律事项必须由专业人士基于完整事实、有效授权、现行法律、可核验来源和具体语境作出独立判断。

AI 可以参与流程。

但最终判断不能从流程里消失。