乐于分享
好东西不私藏

第5篇 全栈AI · 一个律师造了 45 个 AI Sk

第5篇 全栈AI · 一个律师造了 45 个 AI Sk

如果你在看这个系列的第 5 篇,那大概率已经接受了一个事实:AI 全栈不是“会调几个模型”,而是把自己的工作流拆开、编码、再让 AI 真的接进去。上一篇我们写的是 AI 绘图如何进入编码工作流,这一篇换一个更“硬”的场景——法律。

最近看到一个开源仓库:legal-skills。作者是一名诉讼律师,五个月里做了 45 个 Skill,累计 513 次 commit,拿到 255 个 GitHub Stars。它不只是一个“法律 AI 仓库”,更像是一个律师把自己的日常工作,系统地写成了 AI 能直接调用的能力层。

这件事真正值得看的,不是“45”这个数字,而是它背后的方法论:专业能力到底怎么从经验,变成可复用的文件;从文件,变成团队甚至个人的长期资产。

这不是“做一个 AI”,而是把工作流拆成 45 个可调用能力

很多人一提 AI 产品,第一反应是:我要做一个 Agent。

但这个仓库的思路更朴素,也更接近生产环境:先别急着做“会思考的系统”,先把那些高频、重复、规则明确的环节写成 Skill。这样做的好处很直接——AI 不需要每次从头理解业务,只要按已有技能执行就行。

legal-skills 里覆盖的并不是什么“虚空能力”,而是作者自己真的在用的东西。比如诉讼分析、合同审查、案件管理、法院短信处理、专利分析、OCR、语音转录、Markdown 转 Word、文章配图、去 AI 味润色等等。

它像一个律师版的工作底座:

  • 办案时,AI 能处理材料和规则;
  • 研究时,AI 能搜集和整理信息;
  • 创作时,AI 能把内容加工成可交付的形式;
  • 维护时,AI 能批量更新和发布技能。

这说明一件事:Skill 不是“灵感产品”,而是“工作流组件”。

一个律师为什么能做出 45 个 Skill

因为律师这个职业,本来就是一个典型的“产供销一体”角色。

你既要处理案件,也要整理知识,还要输出文章、课程、演示材料,最后还要维护这些内容的版本和分发。换句话说,律师不是单点任务,而是一条完整链路。

把它拆开看,会更清楚:

工作环节
典型需求
形成的 Skill 方向
价值
办案
证据整理、起诉状分析、裁判文书处理
litigation-analysis、court-sms、new-case
提升案头效率,减少重复劳动
研究
法条检索、案例梳理、资料转录
multi-search、wechat-article-fetch、funasr-transcribe
降低信息获取成本
创作
讲稿整理、文章输出、图文配套、格式交付
course-generator、svg-article-illustrator、md2word、de-ai-polish
让内容生产更稳定
维护
安装更新、批量提交、发布同步
skill-manager、git-batch-commit、subtree-publish
让技能本身可持续迭代

表面上看,这是 45 个 Skill;往深处看,这是一个人把自己工作的“操作系统”拆出来了。

这也是 AI 全栈里很关键的一步:不是只会“用 AI”,而是把 AI 变成你工作链路中的默认组件。

一个真正能用的 Skill 仓库,靠的不是堆数量

现在 GitHub 上各种 Skill 集合越来越多,但真正值得长期参考的,往往有几个共同点。

1)只写自己真正用的东西

这点非常重要。 如果一个人没有做过某类业务,却写出一套看起来很完整的 Skill,大概率只是把公开资料重新整理了一遍。它可能“像”,但不一定“能用”。

相反,真正实战型的仓库,往往有明显的个人业务痕迹。它不是为了覆盖所有行业,而是围绕作者自己最熟悉、最常碰到、最容易出问题的场景,持续打磨。

2)更新频率比文案更诚实

一个 Skill 上传后几个月不动,通常说明两个问题:要么作者自己不用,要么它还没进入真实场景。

而真正在线使用的 Skill,一定会不断暴露边界问题:格式不稳、边缘情况没覆盖、新场景不适配。暴露之后就修,修完就 commit。更新记录本身,就是使用痕迹。

3)结构上要能长期运行

一个适合持续迭代的 Skill,通常不止一个 SKILL.md。 还会配套:

  • CHANGELOG.md
    :记录变化;
  • archive/
    :保留处理痕迹;
  • config/
    :隔离用户偏好;
  • references/
    :承载规则、模板和细节。

这类设计的意义在于:让 Skill 不只是“给 AI 看”,也能让人维护、回溯、协作。

对普通团队更有用的,不是直接抄 45 个 Skill

如果你不是律师,也不必照着这个仓库的目录原样复制。更现实的做法,是从你自己的高频路径里挑一条,先做小而稳的 Skill。

我建议按下面三步走:

  1. 先找一个高频、规则清楚的任务 例如会议纪要整理、合同条款提取、内容润色、资料转写、表格清洗。

  2. 把输出格式固定下来 不要只写“帮我总结一下”,而是明确字段、顺序、例外情况、禁用项。

  3. 把失败样本也留下来 真正有用的 Skill,往往不是靠“成功案例”堆出来的,而是靠失败样本修出来的。

如果你想让 AI 真正进入你的日常工作,而不是停留在演示层,这三步比“找一个更强模型”更重要。

边界说明:Skill 不是万能,也不该替代专业判断

这里也要说清楚边界。

法律场景天然有高风险属性。Skill 能提高处理效率,但不能替代律师的专业判断,更不能替代正式审查、签字和责任承担。尤其是诉讼、合规、证据、时效这类问题,AI 只能做辅助,不能直接做结论。

所以更准确的理解是: Skill 负责把重复劳动标准化, 律师负责把关键判断兜住。

这才是 AI 全栈在专业场景里真正成立的方式。

结语

legal-skills 这类仓库最有启发的地方,不是“律师也开始玩 AI 了”,而是它证明了另一件事:专业工作一旦被认真拆解,就能变成可复用、可迭代、可分发的能力资产。

对于个人来说,这意味着你不一定要先做大产品,先把自己的工作流写成 Skill,就已经在积累资产。 对于团队来说,这意味着知识管理不该停留在文档,而要进入可执行层。 对于 AI 全栈来说,这意味着下一阶段的关键,不是“模型更聪明”,而是“你的业务被编码得更完整”。

下一篇,我们继续沿着这个方向,聊聊怎么把这些可复用能力,真正接进自己的日常开发和交付流程里。

相关学习资料