GitHub法务用AI写工具 代码不再是唯一门槛

企业里有个常见的排队场景：业务部门想做个内部小工具，需求提上去，排进工程团队的下个迭代。合同模板整理、法务审查清单这类需求不大不小，通常要等上几周，等到了，优先级又常常被别的事情挤掉。

GitHub 法律团队最近公布的做法，把这个流程绕过去了。他们用 Copilot CLI 自己写了工具，全程没有找工程团队。

两个非工程师做出来的东西

Ngandu Kasuku 做的是合同起草工具 terms-ai。法务起草合同，过去靠人工复制粘贴模板，风格不统一。terms-ai 把法律风格指南和模板库收进一个工具，输出统一风格的合同草稿。

Jesse Geraci 做的是法律分析工作流，用于 DMCA 这类代码版权分析。他提到一个细节：核心"编程"其实是纯语言文件，由一组工作流指令集组成，不需要写代码。他在博客里说，没想到不靠工程支持能走这么远。

两个工具的共同点是：用结构化指令文件定义工作流，而不是写程序。这是 Copilot CLI 和之前"AI 写代码助手"的差别——用户不产出代码，产出的是流程描述。

工具的天花板换了一个地方

但这里有个容易被忽略的问题。工具的核心逻辑，现在取决于用户能不能把流程讲清楚，而不是能不能写代码。

合同审查、DMCA 分析这类工作，本质上可以拆成步骤、规则、例外情况。法律团队恰好是干这个的——他们每天都在把模糊的需求转成可执行的流程。这两个工具能跑起来，靠的不是 AI 有多强，而是这两个人对工作流的抽象能力。

反过来说，指令文件表达不了的复杂逻辑，仍然要工程团队介入。Copilot CLI 降低的是"写代码"的门槛，没有降低"把流程想清楚"的门槛。对流程本身一团乱麻的业务来说，工具不会自动出现。

换个角度看，这跟过去的低代码平台也不是一回事。低代码平台把流程画成图，业务人员拖拽配置，但底层的连接器、数据模型、权限体系还是 IT 部门在搭，维护成本也是 IT 在背。Copilot CLI 这种模式更接近"文档即程序"——指令文件本身就是逻辑，没有中间层。好处是灵活，坏处是出了问题，责任边界很模糊：是流程定义错了，还是模型理解偏了，还是工具版本升级改了行为？这类问题在低代码时代有平台兜底，现在得自己查。

真正变化的是工具资产的归属

对工程团队来说，这件事值得关注的不是 AI 能不能写代码，而是内部工具的归属变了。

以前业务工具在工程团队手里：有版本管理，有代码评审，有权限控制，有交接文档。现在这些纯语言指令文件散落在业务部门，问题就来了——谁来评审这些"代码"？改坏了谁负责？合同模板的更新有没有走审批？这些文件本质上和代码一样是需要管理的资产，但业务部门通常没有这套习惯。

还有一层容易漏掉的是安全。指令文件如果被篡改，或者模板里被塞进恶意指令，业务用户很难发现——他们不读日志，也不看版本差异。GitHub 内部有安全团队盯着，普通企业复制这个模式时，这部分往往没人管。

我倾向于认为，工程团队的角色会慢慢从"写工具的人"变成"工具治理的人"：定义好框架和边界，评审业务部门产出的指令文件，处理那些抽象不出来的复杂逻辑。这比亲自写每一个内部工具更现实——需求太多，写不过来。

指令文件也需要治理

比较好奇的是这些工作流的生命周期管理。GitHub 的博客展示的是成功案例，但没有说明这些指令文件怎么做版本管理、多人协作时怎么评审、出问题怎么回滚。法律团队的场景还相对安全，换成财务、风控这些直接接触敏感数据的部门，一个没人评审的指令文件造成的后果会大得多。

对大多数企业来说，现在的问题不是"业务部门能不能用 AI 写工具"，而是"他们写出来的东西谁来管"。这个问题想清楚之前，放开权限让每个部门自己造工具，未必是好事。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

• 官网：https://framewiki.com
• Gitee：https://gitee.com/wiki-framework
• GitHub：https://github.com/wiki-framework
• 示例项目：https://gitee.com/cdkjframework/framewiki-example
• 📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）