先交代一下背景。我在生态环境执法岗干了六年,每天最磨人的不是跑现场,而是回办公室之后的案头活:翻法条、写文书、理证据清单。这类工作不复杂,但极度吃时间,而且容错率低——一个条款序号引错,整本案卷就可能被退回重来。所以当我看到 WorkBuddy 里流行把工作流封装成 Skill(也就是给 AI 设定一套固定的岗位职责和操作手册)的玩法时,第一反应就是:把我手里这套「法条速查 + 文书起草」的流程也做成一个可复用的 Skill。这篇文章就是完整的实测记录,包括拆解思路、实现细节、踩过的坑,以及最终沉淀下来的可复制方法,给同岗位的朋友和有类似办公场景的读者做参考。
1. 为什么我要把执法岗的案头活变成Skill
1.1 一个普通案件从现场到归档,时间到底花在哪
我先拿自己过去三个月经手的案卷做了个粗略统计。一个常规案件,从现场检查结束回到办公室,到完成立案审批、责令改正、事先告知、处罚决定、送达归档这一整套流程,光文书环节就要五到六个小时。这还是在材料齐全、一次通过的情况下。如果办理过程中被打回一次,或者发现引用错了一个条款序号,实际耗时直接翻倍。
这些时间主要消耗在三个地方。第一是法条检索,一个案件往往横跨好几部规章,有时还要同时参照通用程序和专门领域的细则,翻文件本身不难,难的是在几十份材料里快速定位到准确的条款项。第二是文书起草,现场笔录、立案审批表、事先告知书、决定书,每一类都有固定格式,但内容必须与案件事实严丝合缝,尤其是当事人信息、时间地点、违法行为描述、处罚依据这几项,错一个字都会成为日后复核的隐患。第三是格式核对,字号、文号、签章位置、附注内容,这些机械性的检查非常消耗耐心。
这让我意识到,真正值得优化的不是"查法条写得准不准",而是"查法条和写文书之前的那些重复动作"。如果能把"根据案件类型自动检索相关条款"和"根据笔录要素生成文书初稿"这两步交给一个稳定工具来完成,剩下的就是人工审定,整体效率会有一个明显的提升。
1.2 法条速查的难点不是"查不到",而是"怕引错"
你可能会说,现在用普通AI对话工具也能查法条。我试过,确实能查到,但很难放心用。问题在于通用对话工具没有"知识边界"的概念,它倾向于把问题回答得完整顺畅,而这种倾向放到法条引用场景里就是灾难。典型的翻车方式有三种:条款序号对不上、把参考条款当成直接处罚依据、查不到时自行补一段看起来合理的内容。
举一个真实遇到的情况。某领域法规修订过一次,个别条文序号顺延了,AI检索出来的还是修订前的旧序号,条文内容却对应着修订后的新位置。如果直接把这个引用写进文书,整份案卷的法律依据部分就是错的。这种错误不是"有没有查到"的问题,而是"引用版本是否可靠"的问题,恰恰是普通AI对话工具最不擅长把守的一关。
所以我的需求很明确:这个技能必须基于我提供的有明确版本标记的离线法规素材库进行检索,而不是让模型凭记忆回答。同时,输出必须严格区分"直接依据"和"相关线索",查不到时宁可明确说查不到,也不能自行补全。
1.3 为什么选WorkBuddy Skill,而不是Excel模板或快捷键宏
很多人问,你直接做一个Excel模板或者搞一套自动化宏不就行了?我觉得这两种方案都不够通用。Excel模板能解决格式统一的问题,但解决不了内容生成的问题,填表之前你还是要自己去翻法条、理表述。自动化宏能提高输入效率,但它完全不具备语义理解能力,碰上表述相近但案情不同的案件,几乎派不上用场。
WorkBuddy Skill 的特点是:它把 AI 的语义理解能力和一套固定的工作流程绑在一起。你可以为这个技能设定角色,给它指定知识素材,规定输入输出的字段,甚至告诉它输出前必须完成哪些自检动作。这相当于给 AI 定了一个岗位,它在每次调用时都以同样的标准干活,不会因为换了案件、换了同事就出现明显偏差。
我在社区里看到不少人分享自建 Skill 的经验,有人做备课技能,有人做写作技能,还有人把绘图提示词封装成技能。思路完全相同,只是领域不同。我这套的定位是政务办公场景里的"文书生成加法规检索",属于对准确性和严肃性要求比较高的类型,所以实现思路会侧重约束和校验,而不是开放式生成。
2. 先从"拆工作流"入手:执法文书劳动到底由哪些动作构成
2.1 按动作而非按岗位切分技能
一开始我的想法是把"执法办案助手"做成一个大而全的 Skill,所有案头工作都往里面塞。结果试了一天就发现不行——指令一多,AI 就会顾此失彼,它自己都不知道优先执行哪一段逻辑。
后来我换了个思路:按动作拆,不按岗位拆。执法案头工作砍成几个核心动作:检索(查法条)、判定(判断违法事实对应的条款关系)、起草(生成各类文书初稿)、复核(检查格式与信息一致性)。每个动作对应一个独立的 Skill,彼此之间通过固定的输入输出衔接。比如"法条速查"Skill 输出一组带版本标记的条款引用,这份输出直接作为"文书起草"Skill 的输入参数;"文书起草"Skill 生成初稿后,再交给"材料复核"Skill 做格式和字段一致性检查。
这样拆的好处有两个。第一,每个技能的任务边界清楚,AI 在单一技能里的表现明显更稳定。第二,便于单独调优和复用。某个环节出了问题,只需要修对应的那个技能,不用动整条链路。比如后来我发现"法条速查"在引用新旧版本上有漏洞,就只改了那一个技能的素材库和约束规则,其他技能完全不受影响。
2.2 一个Skill的三件套:角色说明、知识素材、输出规范
我在 WorkBuddy 里搭 Skill 时,习惯把它分成三块来写:角色说明、知识素材、输出规范。这三块缺一不可。
角色说明解决的是"你是谁、你在干什么"的问题。比如法条速查技能的角色设定是:"你是生态环境执法岗的法规检索助理,你的职责是根据案件类型和行为描述,检索离线法规素材库,给出标准引用,不回答与检索无关的问题。" 角色定位清楚了,AI 就不容易跑偏去写长篇大论或者给出无根据的建议。
知识素材解决的是"你凭什么这样回答"的问题。这个必须是我上传和整理好的离线文本,而不是让 AI 自己去网上拼凑。素材要按照法规名称、版本年份、章节条号打标签,方便在提示词里精准指定检索范围。
输出规范解决的是"你交出来的东西长什么样"的问题。我给它规定了一套固定格式,包括完整的条款引用格式、直接依据与相关线索的分类、以及未检索到的兜底说明。下面是一个简化版的 Skill 结构示例:
skill_name: 法条速查_通用版 role: 你是生态环境执法岗的法规检索助理。 inputs: - 案件类型 - 违法行为描述 - 法条版本年份 process: 1. 拆解违法行为关键词 2. 检索离线法规素材库 3. 核对版本年份与条款序号 4. 输出标准化引用 output: - 直接依据条款(含法规名称、条、款、项) - 相关线索条款(标注“非直接依据”) - 未检索到说明(必须明确写出,不得编造)写的时候不需要特别复杂的脚本,关键是让模型清楚每一步的输出边界。这里我也建议,如果是刚开始接触 Skill 的读者,不要急着写很长的流程,先把一小段工作流跑通再逐步扩展。
2.3 命名、编号与目录规范:让小技能干活更稳定
Skill 建多了之后,命名和编号就变得非常重要。我给它们起了非常直白的名字,比如"法条速查_通用版"、"笔录起草_餐饮油烟类"、"决定书起草_通用版"。这样在调用的时候一眼就能知道该用哪个,不会出现在一堆相似命名的技能里反复试错的情况。
同时我习惯给每个 Skill 加一个版本编号和生效日期,类似"v1.0_2025-04"。这个习惯一开始是为了方便自己管理,后来发现特别关键——因为法规素材和文书模板都是会更新的,没有版本号,过两个月你自己都分不清这个技能里的素材是旧法还是新法。我在配套的说明文件里写清楚"本技能基于XX年X月现行法规库,旧案请参照案发当时版本",避免跨时间使用出错。
目录规范上,我会把知识素材单独放在一个子目录里,提示词模板放在另一个子目录,两者不混在一起。这样后续更新素材时不用动提示词文件,维护成本低很多。
3. 法条速查Skill:把"怕引错法条"这个压力点按下去
3.1 素材整理:离线法规库是地基
这一步是整个技能里最费时间、但也是最重要的部分。法规素材整理得好不好,直接决定后续引用质量高不高。
我从工作常用的几十份法规文件入手,把 PDF 全部转成纯文本,然后做三件事。第一是清洗,去掉页眉页脚、空白行、无关的附注说明,只保留正文。第二是分片,把每一部法规按照"章节—条款"的结构切成小段,每一段前面保留完整的"第X条"标记,方便模型定位。第三是打版本标签,在每份文件开头加一行元信息,写清楚法规名称、发布日期、修订日期、现行版本年份。
我这里没有用复杂的向量数据库接口,直接采用的是最朴素的方式:把处理好的文本按目录结构放进 Skill 的素材区,让模型在检索时直接读取指定文件范围。效果比我预想的要好,原因在于我的检索范围本身是封闭的,就几十份文件,模型不需要在浩如烟海的网络信息里瞎找,它只需要在确定范围内做匹配,准确性自然高不少。
另外提醒一句,素材整理时不要偷懒裁剪条款。有些法规条文之间互相引用,你只保留"看似有用"的几条,检索时模型就缺少上下文,很容易给出残缺的引用。我一开始剪掉过一个法规里看起来无关的程序性条款,结果导致生成告知书时遗漏了救济途径的写法,这个教训挺深刻的。
3.2 三条硬约束:在提示词里给AI焊上护栏
模型在法条引用上最喜欢犯的毛病是"补全"和"模糊化"。为了压住这两个毛病,我在提示词里写死了三条硬约束,执行效果立竿见影。
第一条,引用格式完整。所有条款引用必须是"《法规名称》第X条第X款第X项"的完整格式,缺任何一部分都不算完成。这条约束的目的很简单,就是逼着模型把引用落实到最具体的条款层次,而不是用"根据相关法规"这种模糊表述蒙混过关。
第二条,查不到必须明说。当素材库中没有检索到对应条款时,模型必须输出"未检索到直接依据"这句话,同时可以列出最接近的三条作为"相关线索",但必须在每一条前面标注"非直接依据,仅供参考"。这一条把"编造"这条路彻底堵死了,也保留了人工继续研判的线索。
第三条,禁止自行解释条款内容。模型只能引用条款原文,不能用自己的话"转述"条款含义。原因在于转述必然带来信息损失,哪怕损失很小,在法律引用场景里也不可接受。我在实测中发现,加了这条约束之后,输出明显更克制了,不会再出现那种用自己的理解去扩展法条含义的情况。
3.3 实测翻车现场:条款序号变更与"参考条款冒充依据"
就算有护栏,实测中还是翻过车。最典型的出现在新旧法规衔接的案件上。
有个案子涉及的违法行为,在旧法规里对应第 32 条,但该法规在 2024 年修订后,这条违法行为对应的条款序号变成了第 38 条。我最初制作素材库时装的是修订后的版本,检索时模型按照违法行为关键词匹配到了新版的第 38 条,但在输出引用格式时却沿用了旧版文件里的表述习惯,写成第 32 条。整段引用堪称"混血"状态,条款序号是旧的,条文内容是新版的位置。如果不逐字核对,根本发现不了。
另外一次翻车是"参考条款冒充依据"。当时我同时检索到一条直接规定违法行为的条款和一条程序性条款,模型把程序性条款也塞进了"直接依据"里。文书起草时它自动引用了这条程序性条款作为处罚理由,虽然证据链条无害,但严格来说引用层次不对。后来我单独给输出加了分类要求,明确规定只有直接设定法律责任和罚则的条款才能进入"直接依据",其余一律归入"相关线索"。
针对这两个场景,我在技能里增加了一个强制校验步骤:模型在输出引用前,必须自行核对一遍"条款内容是否与素材原文完全一致",并标注本次引用对应的素材文件编号。这个步骤听上去很简单,但能把绝大多数混搭引用问题拦在输出之前。我把校准前后的差异整理成了一个小表:
| 错误现象 | 根因 | 校准动作 |
|---|---|---|
| 条款序号与条文内容来自不同修订版本 | 素材库版本信息未被利用 | 素材文件按年份重命名,引用时强制标注版本年份 |
| 参考条款被当成直接处罚依据 | 检索结果未区分引用层级 | 强制输出“直接依据 / 相关线索”分类 |
| 未检索到时自行编造条款 | 模型倾向于补全答案 | 硬性输出“未检索到”,并列出相近条款作为备查线索 |
4. 文书起草Skill:从现场笔录到决定书的流水线怎么搭
4.1 四类高频文书拆成一条生产链
文书起草是整个流程里产出最多、也最容易出问题的环节。我把日常最常用的四类文书抽出来,做成一条连续的生产链:现场笔录、立案审批表、事先告知书、处罚决定书。每一类对应独立的模板和输入要求,但前后衔接非常紧密。
其中现场笔录是"源头数据",后面所有文书的核心信息都从它里面来。立案审批表需要从笔录里抽取出违法行为摘要和初步判定意见。事先告知书要基于立案审批确认的事实,给出拟处理意见和救济途径的提示。处罚决定书则要在告知书基础上结合当事人的陈述申辩意见,形成最终的正式文本。
为了让读者看清楚这套流水线怎么运转,我整理了一张分工表:
| 阶段 | 常用文书 | Skill输入 | 关键输出 |
|---|---|---|---|
| 现场取证 | 现场检查(勘察)笔录、询问笔录 | 现场记录原文、照片/采样记录描述 | 结构化事实要素 |
| 立案环节 | 立案审批表 | 案件摘要、初步判定意见 | 案件名称、违法事实摘要、建议立案依据 |
| 告知阶段 | 责令改正通知书、行政处罚事先告知书 | 违法事实、法律依据、处罚建议 | 拟处理意见、救济途径名称 |
| 决定阶段 | 行政处罚决定书 | 告知书内容、陈述申辩/听证意见 | 正式决定文本、缴款信息、履行期限 |
这一套链条跑下来,每个文书之间不是孤立的,而是前一环的输出直接成为后一环的输入,最大程度避免了信息在重复录入中走样。
4.2 先抽取字段再套模板:保证决定书和笔录"对得上"
在起草技能里,我设计了一个非常重要的中间步骤:字段抽取。也就是让 AI 先把案件材料中的关键信息整理成结构化数据,然后再用这些数据去填充文书模板。
字段抽取的目标信息包括:当事人信息、案发时间、案发地点、违法行为描述、证据清单、涉及法规。格式上让它输出成 JSON,方便后续直接套用。
{ "当事人": "", "案发时间": "", "案发地点": "", "违法行为": "", "证据清单": [], "涉及法规": [], "版本年份": "" }为什么要多此一举?因为在实测中我发现,如果让 AI 直接从原始笔录起草决定书,它会不自觉地把陈述变得"更顺",结果就是决定书里的表述与笔录原文出现细微出入,比如地址漏了个门牌号,时间从"15时30分"被改写成"下午三点半"。这类改动放到文书中就是大问题。但如果先抽取成结构化字段,再让模板逐项填充,事实要素就能保持最大程度的一致。
数据抽取之后,我还会让 AI 做一次"字段比对",把抽取结果和原始笔录原文逐项核对一遍。这一步在提示词里占用不了多少空间,但能有效减少落项或者错位的情况。实测下来,决定书的当事人信息和笔录完全一致的概率从大概一半提升到了九成以上。
4.3 AI翻车重灾区与人工复核红线
即便做了这些准备,AI 生成文书初稿后,我也不会直接拿来用。因为这类文书最终的认定权和签章责任必须由人来承担,工具再强也只能做辅助,这个边界我从一开始就想得很清楚。
AI在起草时最容易翻车的三个位置,我做成了人工复核红线表:
| 红线项 | 为什么不能动 | 我如何检查 |
|---|---|---|
| 文号、日期、签章 | 只能由经办人填写,AI不得生成 | 生成后检查是否存在虚构编号或日期 |
| 处罚金额 | 必须从输入参数读取 | 与告知书、决定书逐字比对完全一致 |
| 语气表述 | 执法文书必须客观强硬,禁用弱化词 | 全文检索“建议”“可能”“酌情”等词 |
| 当事人信息 | 必须与笔录绝对一致 | 逐字段核对,不放过一个标点差异 |
| 引用条款 | 必须来自法条速查Skill的素材库输出 | 查版本号与条款序号是否与素材一致 |
我做了个小总结:AI 作为文书起草辅助工具,最大价值是"把初稿做到七八十分",但最后那二十分,必须靠人的眼睛和判断力兜底。这也是我在这套 Skill 里最坚持的一个原则。
5. 我踩过的坑和校准方法(附一份评分卡)
5.1 第一次生成决定书:格式像模像样,细节不敢用
第一次用这套 Skill 生成处罚决定书的时候,我的观感非常复杂。版式工整,章节顺序也对,违法事实、法律依据、处罚内容几个大项都有,读上去还真像那么回事。但越往下读越发现不对劲:当事人地址和笔录差了一个字,处罚幅度也从应填的数值变成了一个"看起来合理但实际不对"的数。
原因出在我输入参数时不严谨。处罚金额这一项我在录入时漏填了,而 Skill 里设置的默认补全逻辑,让 AI 在参数缺失时自动按一个默认值补了进去。这个默认值恰好和真实应罚数额不同,但格式上完全合法。这个经历让我意识到,参数完整性和输入校验,可能比提示词本身还要重要。
从那以后我给自己定了个要求:每次调用文书起草技能前,必须逐项核对输入参数是否齐备,尤其是处罚金额、违法事实描述、当事人信息这三项。宁可花两分钟人工确认,也不要让 AI 在关键参数上做默认推断。
5.2 把自检评分卡写进Skill输出流程
后来我把那次翻车的教训固化进了技能本身的流程里。具体做法是在文书起草技能的输出规范中加一段"自检清单",要求 AI 在交付之前先逐项自查,并输出每个检查项的通过情况。
这个评分卡基本长这样:当事人信息一致性、引用条款版本正确性、处罚金额参数匹配、语气是否出现弱化词、是否存在虚构文号或日期。AI 生成完毕后要输出一个类似检查结果的文本:
自检结果: 1. 当事人信息一致性:通过 2. 引用条款版本正确性:通过 3. 处罚金额参数匹配:通过 4. 语气弱化词检查:通过 5. 文号日期真实性检查:通过我实际用下来的体会是,这个自检步骤并不能百分之百替代人的复核,但它确实把一些低级错误拦截在了交付之前。特别是"语气弱化词检查"这一项,几乎是每版初稿必抓出问题的环节。有一次它把"责令立即停止违法行为"写成了"建议尽快整改",评分卡直接把它拦下来了。
5.3 版本管理:让新法旧案各归其位
执法工作有一个无法回避的时间维度——案件行为发生时适用的法规,和当前生效的法规很可能不是同一版。为了让技能在跨时间场景下不乱套,我给它加了版本管理机制。
具体做法有三步。第一,所有素材文件以"法规名称_版本年份"的方式命名,例如"XX污染防治条例_2024版.md",让模型从文件名就能感知版本信息。第二,Skill 的输入参数里增加一个"法规版本参考年份",用户填案件发生时间,模型据此锁定检索范围,避免把新法套用在旧案上。第三,在输出文书中强制标注"本引用基于XX年XX月现行版本"的注释,这样即使后续法规更新,也能追溯当时引用所依据的版本。
实测中这个机制解决了一个实际问题:一个去年发生的案子,立案时使用的还是修订前的条款序号,但由于所有素材库现在都是修订后的新版本,如果不指定版本年份,模型会自然使用新法规。加了版本管理后,旧案引用旧条款、新案引用新条款,整个链条就顺了。
关于这一步,我想多说一句。有人建议我干脆做一个自动识别新旧法的功能,让 AI 自己判断案件时间适用哪一版。我试过,结论是不建议,因为新旧法规衔接的过渡规则往往非常细致,AI 的判断在这种场景下还是不够可靠,不如老老实实让用户指定版本年份,把判断交给人。
6. 这套Skill怎么复制给同事,以及换个岗位怎么改造
6.1 打包分发:一个目录加一份说明
做完之后我做的第一件事就是把这套 Skill 打包分享给同科室的同事。打包结构很简单,一个主目录里包含三块:技能配置与提示词文件、法规素材子目录、文书模板子目录,外加一份使用说明。
使用说明里我会写清楚几件容易忽略的事:Skill 部署到工作台之后,第一次使用前要检查素材目录路径是否正确;调用文书起草技能前,必须先把输入参数填完整,特别是版本年份和处罚金额;每次法规库更新后,要及时替换素材文件并更新技能版本号。
这里有一个经验想分享:打包分发时,不要在技能配置里写死绝对路径,改用相对路径,不然同事把技能拷到自己电脑上之后经常因为路径对不上而加载失败。我第一次给同事拷的时候就是路径没处理,对方反复加载不成功,差点以为是技能文件有问题。改成相对路径之后一切正常。
另外,社区里很多人提到 WorkBuddy 的 Skill 玩法时也经常讨论"如何让技能更通用",我的回答是:先专后通。你先把一个岗位场景下的技能做到顺手,再逐步做抽象和泛化,这是最稳的路径。直接做一个什么都能干的通用技能,往往什么都干不好。
6.2 跨岗位改造的五步方法论
这套方法同样可以复制到其他岗位。我梳理了一个五步流程,适用于大部分案头工作繁重、输出物固定的业务场景。
第一步,记录一周工作日志,列出所有高频案头动作,比如查资料、填表格、写报告、发通知。第二步,选定两三个最高频的动作,逐一明确输入和输出。输入是你要喂给 Skill 的原始材料,输出是它应该交出的成品形态。第三步,准备素材库,把工作中实际用到的制度文件、模板、规范说明整理成离线文本,这决定了 Skill 的专业下限。第四步,用三到五个真实案例做校准,根据生成结果修正提示词约束和输出格式。第五步,找一位完全没参与开发的同事做一次盲测,看他能否不借助你的口头说明就正确调用这个技能,这一步能暴露你的说明文档和命名规范里隐藏的坑。
这套流程我没有贴在某篇教程里,完全是实测走出来的经验。尤其是最后一步,盲测的价值远比你想象的大。我第一次做盲测时,同事拿到技能文件后完全不知道要先填版本年份参数,直接导致后续引用全部用了最新法规,等于白跑一轮。后来我把参数说明加大字号写进使用说明第一页,问题才算解决。
6.3 一段不算总结的收尾
现在这套「法条速查 + 文书起草」的 WorkBuddy Skill 已经陪着我把最近两个月的案件卷宗完整跑了一遍。要说最大的感受,是它并没有真的替我做决定,但它把我从"为翻法条翻到烦躁、为文书格式反复核对到麻木"的状态里解放了出来,让我能把注意力重新放到案件本身和最终的文字把关上去。
如果你也想做一套类似的技能,我想给出的最后一条建议是:不要一上来就追求完美提示词,先把你手头最头疼的那个动作做成一个最简单的 Skill,哪怕它的输出还很粗糙,跑通之后再一点点加约束、加素材、加校验。这套东西最有意思的地方在于,你越熟悉自己的工作流,沉淀出来的技能就越贴合自己,所谓可复用,本质上就是把你长期积累的岗位经验固化成了一个随时能调出来的数字助手。