法律团队不写代码，用自然语言给自己造出自动化工具

GitHub 法律团队在官方博客上分享了一个看似反直觉的场景：一群自称“不是工程师”的律师、项目经理和商务人士，用 GitHub Copilot CLI 把最枯燥的重复劳动变成了可复用的自动化工具。他们的起点不是写代码，而是用自然语言把需求说清楚，再让命令行里的 AI 助手照着做。这个经验说明，构建工具的能力可能并没有想象中那么高的门槛。

先简单介绍一下 Copilot CLI 是什么。它本质上是面向命令行的 AI 编程助手：普通 Copilot 在编辑器里帮你补全代码，CLI 版本则更像是终端里的对话式伙伴，你把想做的事用自然语言讲明白，它会尝试拆解请求、生成可执行的命令，甚至写出完整脚本。换句话说，这类工具把“编程”的一部分门槛转译成了“把需求描述清楚”。对长期处理合同、审阅代码样本、反复回答相似问题的法务人员来说，这种能力刚好击中痛点。

团队里的首席产品法律顾问 Ngandu Kasuku 就经历了这样的转变。有一段时间，他手头堆积着大量涉及数据、基础设施和产品集成的合作协议。每份协议差别很大，接新项目往往像从头开始。起初他只是用 Copilot CLI 零散处理单项任务，后来看到同事用 AI 搭出各种小工具，意识到自己可以围绕整个工作方式构建工具，而不是一次只处理一个问题。他创建了合同起草工具 terms-ai，核心是一套内部起草风格指南：从做商业律师时起，他就偏爱清晰直白的措辞，不理解为什么合同里总要用“heretofore”“therewith”这类生硬古旧的词。于是他把自己的风格原则、过往已完成协议和工作流程整理进仓库，工具在起草新协议时可以调用这些资源。敏感协议存放在经过授权、受控访问的内部环境中，对外开源的只是工具逻辑和工作流。按他的说法，用上这套工具后，审阅和起草时间大约减少了一半，不同协议之间的措辞一致性也明显提高。

另一位线上安全法律顾问 Jesse Geraci 的路径更接近“从零开始搭流程”。他的目标是快速、准确地分析源代码，用来评估 DMCA（数字千年版权法案）移除通知是否成立。最初，项目只是一组 Copilot 指令，处理版权问题分类、代码比对、许可证检查和规避措施审查这些重复工作。他希望能把大家各自零散编写的提示词变成一套法律团队可以信赖的规范流程。意外的是，没有工程支持，他也能走得相当远。核心“程序”是纯文字文档，包括工作流指令、政策参考材料和报告模板，不需要写传统代码，只需把律师擅长的语言组织能力用起来，就能将结构化判断嵌入工作流。后来系统加入了面向客户和律师两种不同模式：前者快速产出并给出升级建议，后者深入分析并列出双方论证。再往后，这套工作流演变成完整的桌面应用，支持合同审阅、保密协议（NDA）筛选、风险评估、合规检查和答复起草等任务。底层可以通过可复用的技能和智能体来分配任务，比如受理、规则匹配、风险评分、证据核实、升级路由、报告组装，但控制行为的关键仍然是可读性极强的 Markdown 文档。

从行业角度看，这两个案例的价值不只是“AI 节省了时间”，还在于它重新回答了“谁可以构建工具”这个问题。过去，非技术岗位想自动化一个流程，往往要先写出需求文档，排队等待工程资源；现在，能用文字清晰描述业务方法和输出标准的人，可以直接把经验变成应用。对普通用户来说，最直接的启发是：找一件反复浪费时间的事，把步骤、规则和理想输出写下来，然后尝试让 CLI 助手帮你搭一个简化版工具，哪怕刚开始只解决一小段环节，也比完全依赖他人更现实。

当然，这类工具的使用边界同样清晰。法律场景里充满合同、邮件等敏感内容，随手把文件丢给外部模型有合规风险。GitHub 法律团队的做法是把敏感协议留在访问受控的内部环境，开放出去的只是不含敏感信息的工具逻辑。这一安排对其他公司有参考价值：自动化不能以牺牲数据安全为前提。同时，自然语言描述的流程再“聪明”，也可能出现模型误判或看似合理实则错误的输出，人工复核仍然需要留在关键环节。律师团队自己也强调，Copilot 是决策支持工具，不是法律判断的替代品。

借用这篇分享的总结来说，如果律师和项目经理都能快速从重复劳动中突围，大多数岗位也可以。不必先成为全职程序员，也不必等待完美的软件供应商，把自己多年积累的方法论、标准和格式写清楚，剩下的交给人工智能去执行。那句“我永远不可能编程”的自我怀疑，正在被“我刚刚又搭出了个东西”所替代。