岗位 Skill 该不该做成一个人的黑盒

这两个月我和不少业务线的朋友交流，发现大家用大模型理表格、拉数据已经成了日常习惯。不少业务骨干还顺着平台的功能，给自己搭出了一整套专用的 Skill。

上周有个做运营分析的朋友跟我聊起日常。他每天要汇总好几个系统的日报，以前手动清洗核对得折腾一上午。后来他自己写了段脚本，把长提示词、清洗规则与分析框架绑在一起拼成自动化流程。别人弄两三个小时的报表，他跑个脚本两三分钟就直接出结果。

我第一反应也是夸他业务熟、动手快。但我跟着问了一句：“要是你下周休年假或者调岗，组里其他人能接手跑这套流程吗？万一上游字段格式变了，谁来维护？”

他当场愣住了，苦笑着说：“那大家肯定跑不起来。很多数据映射写在我本地环境里，兜底全凭我脑子里的经验。真报错了，除了我自己肉眼盯，别人插不上手。”

这种状况在很多团队里很普遍：大家原本想把个人 SOP 沉淀到提示词与模型里，走着走着，工具就缩成了只有作者自己能玩转的私人黑盒。自己搭个黑盒短期确实省心，但长期留在团队里，到底是减负还是暗地挖坑？

什么是岗位 Skill？

先对齐一下概念。

技术视角上，厂商与开源框架都在强调给 Agent 装备调用外部环境的能力。比如 Anthropic：Agent Skills 这篇工程实践里系统提过：给智能体装配技能，绝不仅仅是丢给模型一段 prompt，而是要明确定义输入输出、调用外部 API 或运行沙箱代码，让模型能解决现实世界的问题。

回到具体业务岗位上，我理解的“岗位 Skill”，就是把一个具体岗位上的固定作业流程，用自然语言提示词、规则逻辑、外部工具调用（查库、调内部接口、读本地文档等）组装起来的复合执行单元。

常见场景随处可见：

电商客服争议判定：输入留言与订单记录，按政策输出责任判定并草拟安抚话术；
HR 初筛对比：输入简历与 JD，按既定维度输出横向对比表格与待面试清单；
财务或运营对账核验：把上游导出表格与流水做字段映射，自动核对差异并标红。

以前靠老带新口传、死磕表格或等技术排期。现在懂业务的同学自己就能拼低成本小工具。出发点很好，可隐患也恰恰埋在“个人随手拼装”这里。

相关课程AI视频与Agent实战查看课程 →

黑盒的好处与代价

为什么容易做成私人黑盒？单兵摸索阶段，它确实成本最低。

为什么大家习惯搭私有黑盒？

首先是快。做给自己用，不需要照顾别人的习惯。路径写死在本地，默认值全在脑子里，哪怕输入格式不规范，自己认得出就行。不用写说明，不用处理边缘异常，半天搭好，当天下班就能早走一个小时。

其次是改动灵活。业务规则经常变动，今天增加退款分类，明天修改投放口径。私有黑盒直接改改提示词里的几句话或换个正则随时能跑，不需要走繁琐的评审流程。

个人便利过后，代价常由团队埋单。

黑盒代价

黑盒带来的实际代价

第一，人员断层与知识孤岛。
如果岗位大半产出依赖一套只有员工本人能运行的黑盒工具，工具就成了隐形绑架。一旦人员调岗或离职，新人接手发现文档只有大纲，最关键的脏数据处理和过滤规则全闷在黑盒里。新人要么推倒重来，要么理解走样导致产出质量滑坡。这不是沉淀资产，而是给团队堆积技术债务。

第二，结果不可解释，审计成盲区。
在法务、风控、财务这些要求高准确性的场景里，如果业务全靠外界看不见的黑盒做辅助决策，一旦出事无法追责。模型跳过核查，究竟是原始输入异常、提示词逻辑有歧义，还是底层调用出错？现场既没有运行日志，也没有输入输出快照与版本记录。

第三，稳定性差。
个人做黑盒，通常喜欢“用魔法对抗魔法”——提示词越叠越长，里面堆砌大量补丁甚至彼此冲突。底层大模型微调一次权重，或上游表格多了两列，黑盒瞬间崩溃。这时候除了作者本人抓狂，没人能帮得上忙。

岗位 Skill 不该停在个人玩具。真有业务价值，就得从“个人外挂”变成“团队可复用资产”。

怎么做可复制的岗位 Skill？

不锁黑盒，该怎么做？是不是每个小工具都得拉技术立项重度开发？

没必要，流程太重会浇灭动手热情。可复用的关键是标准化与透明度。我落地时抓三件事就够：文档化、基准评测、权限剥离。

文档化/评测/权限

1. 拆掉魔法，完成最低限度的文档化

说明不用写几十页，三样关键信息写清就行：

输入契约（Input Schema）：接收什么格式的数据？缺字段了会怎样？支持上传 txt、csv 还是 pdf？
核心业务逻辑与约束：不要把整段提示词当机密藏着。业务按什么标准分类？哪些是硬规则，哪些是模型兜底的软推断？
输出规范（Output Format）：产出的是自由文本还是严格的 JSON？字段含义是什么？

把输入、核心规则、输出梳成几百字卡片挂协作文档，黑盒就破了一半。别人看得懂逻辑，出问题也有据可查。

2. 建立小而美的评测集（Eval Benchmark）

岗位 Skill 同样需要评测机制。

拿三五个例子测过全对就上线，是侥幸。模型输出有概率性，样例好看，换个偏一点的场景可能就漏。

想要稳妥交接，必须沉淀一套常态化的基准测试集（Golden Dataset）：

挑选 20 到 50 个典型的历史真实场景（做好脱敏处理）；
包含 80% 的日常标准输入与 20% 的边界 Case（字段缺失、恶意输入、极长文本、异常格式等）；
明确每个 Case 的预期输出。

以后不管是微调提示词、换模型还是新人接管，花几分钟把 Case 跑一遍，看看准确率有没有波动。有了量化依据，大家才敢把它接进生产流里。

3. 环境与执行权限解耦

很多黑盒在别人电脑上跑不起来，往往混杂了作者个人的本地环境：特有的运行环境、浏览器 Cookie、写死的临时 Token 等。

把环境剥离干净，可以参考这些做法：

尽量把纯逻辑部分挪到公司统一的 Agent 平台或共享空间里运行；
确实要在本地运行的脚本，把依赖列成标准清单，整理成通用执行脚本；
严禁把私有密钥和个人配置硬编码在提示词或脚本文件里。

守住数据边界：不能越权取数

交接难影响协作成本；数据违规与越权取数则是合规红线。

私人黑盒里最让人捏把汗的，往往是数据读取。

有的业务人员图省事会这么干：“我在后台有管理员权限，或者我拿到了一个权限很宽的 Token，直接写脚本把用户库、订单库底表拉出来，丢给大模型或者向量数据库去检索。”表面看小工具秒查明细无所不能，但在底层已经踩在违规边缘。

最小必要原则不是一句口号

我国法律法规层面，对个人信息处理有着明确底线规定。大家可以查阅个人信息保护法（全国人大法规库）里的核心条款。整部法律贯穿的基本原则就是处理个人信息应当具有明确、合理的目的，并应当与处理目的直接相关，采取对个人权益影响最小的方式，不得过度收集。

如果一个原本用于“辅助草拟客服回复”的 Skill，在运行中顺手把真实手机号、身份证号、收货地址等全量隐私字段捞取并上传到模型上下文，本身就违背了最小必要原则。此外，相关法规也明确要求，提供和使用生成式 AI 服务不得非法留存或向他人提供可识别身份的信息。私自接入未经评估的第三方外部模型，还存在泄露商业秘密的严重隐患。

权限对齐与凭证隔离

防范越权取数，在岗位 Skill 设计上必须守住三条底线：

执行者的身份继承：Skill 调用的接口权限，绝不能高于当前使用者的本人权限。数据调取必须带上当前操作者的个人凭据，人在权限内操作，工具在人的权限内执行。
数据脱敏前置：只要业务本身不需要精确的个人标识，必须在进入模型上下文之前完成脱敏。手机号掩码、姓名转代号，绝大多数分析用不着知道用户具体叫什么。
操作日志可回溯：谁在什么时间、触发了哪个 Skill、传了哪些参数、调取了哪些底表，底层必须留下清晰日志，确保异常时完整复盘。

先把数据安全底线筑牢，才谈得上推广。

总结：从个人私藏到组织资产

业务同学愿意自己搭智能体提效，值得肯定。

但要提防一种偏向：把工具做成自己的技术壁垒，晦涩难懂、私密运行。守着黑盒，给团队长期运行留下了很大的隐患。真正有价值的经验，从来不在于几句保密的提示词，而在于背后的业务洞察与判断力。把重复低效的流程拆解成公开、透明、带评测用例、权限合规的标准化 Skill，让整个团队都能顺畅用起来，反而更能体现一个人在业务上的系统化沉淀能力。

如果你电脑里也有个人脚本、提示词流程，不妨自问：下周交给同事，他脱离你还能独立跑吗？取数链路合规吗？有没有不小心抓取了无关的高敏信息？

打开黑盒、理顺规则、收拢权限，工具才算落到实处。

常见问题

Q1：业务部门自己做的小工具，非要搞标准化评测集吗？会不会太形式主义？
A：不会。大模型存在概率性波动，随手测几个例子容易漏掉边界缺陷。准备几十个涵盖典型场景与异常格式的真实样本，每次改动提示词或换模型时跑一遍，几分钟就能掌握准确率变化，这是保证交付质量最轻量的兜底手段。

Q2：如果必须使用外部大模型，涉及客户数据时该如何做到合规与防泄密？
A：抓好两点即可：一是前置脱敏，在本地剔除手机号、身份证、真实姓名与秘钥等高敏字段，仅将抽象事实传给模型；二是选用通过合规备案、具备企业级隐私承诺且明确数据不回流用于训练的正规商用 API，杜绝随意使用公共免费聊天入口。

Q3：把自己的 Skill 彻底公开交接给团队，个人的岗位价值会不会被稀释？
A：不会。简单的提示词和脚本本身没有壁垒，真正的核心壁垒在于对业务痛点的拆解能力。能把复杂经验提炼成规范文档、评测集与合规 Skill，不仅不会被替代，反而证明你具备了从单兵作业跃迁为团队效率赋能者的系统化工程能力。