岗位 Brief 是 AI Skill 的输入合同：它把模糊的“做一个助手”压缩成一个有触发场景、材料边界、输出字段和责任人的岗位动作。本文逐项说明 Brief 应记录什么、哪些信息必须由负责人确认，以及如何用成功和错误样例让后续 Prompt、模板和测试有共同依据。文中只讨论可复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再按自己的版本、权限和数据补充实验。
那这套技能包从哪里开始？
不是先打开 Claude，也不是先写系统提示词，而是先让客户填写一张岗位 Brief。它更像 AI Skill 的输入合同：明确这个岗位动作什么时候发生，输入什么，输出什么，谁能做决定，哪些事情不能交给模型。
如果 Brief 写得模糊，后面的 Prompt 越长，错误也可能越稳定地重复。
一、岗位 Brief 不是需求愿望清单
很多客户会这样描述需求：
这不是可以直接开发的岗位动作，而是一组没有边界的愿望。
岗位 Brief 要把它压缩成一个具体结果：
这个版本已经可以测试：有触发时间，有输入材料，有输出结果，也写清楚了不能做什么。
二、岗位 Brief 的 9 个必填字段
建议让客户在项目开始前完成下面 9 项。信息不完整时，不要直接猜，标记“待负责人确认”。
1. 触发场景
写清楚什么时候打开 Skill，而不是只写岗位名称。
还要写不适用场景。例如没有原始材料、正在处理投诉升级、需要即时对外承诺时，不应使用普通整理 Skill。
2. 输入材料和格式
输入字段越清楚，输出越稳定。至少说明：
不要只写“上传相关资料”。“相关”对设计者来说很清楚，对新员工来说通常等于没有说明。
3. 目标输出
客户需要看到的是具体交付物，不是“帮我分析一下”。
例如销售跟进表可以规定：
每一个字段都应说明来源、是否必填和允许的空值。没有日期就显示“待确认”，不要让模型自行编造一个日期。
4. 不能交给 AI 的内容
这一项很容易被忽略，但它决定了系统的责任边界。
可以写成：
这不是为了让 Skill 变得保守，而是为了让团队知道哪些动作仍然属于岗位负责人的判断。
5. 判断规则
客户经常会说“按我们平时的方式处理”。这句话必须继续追问：平时到底按什么优先级？
把规则写成可以执行的条件：
规则没有来源时，不要把它伪装成确定政策，应标记“待负责人确认”。
6. 两个成功样例
样例必须是完整案例，包含原始输入、最终输出以及为什么这样处理。
只给一张“理想结果截图”不够。模型和设计者都需要看到：
成功样例不是用来机械复制格式，而是用来暴露团队真正重视的判断。
7. 常见错误
请客户列出过去最容易漏、错或返工的地方，例如：
错误样例比“请输出高质量内容”更有价值，因为它直接告诉 Skill 哪些结果不能接受。
8. 使用人和审核人
至少区分三类角色：
| 角色 | 主要责任 |
|---|---|
| 使用人 | 准备输入、启动 Skill、检查格式和完整性 |
| 业务负责人 | 确认事实、优先级、价格和对外承诺 |
| 管理或系统负责人 | 管理权限、版本、日志和保存位置 |
一个人可以同时承担多个角色，但不能让系统默认“谁提交谁就可以发布”。
9. 权限和保存位置
Brief 中要写清楚：
如果企业使用多个项目、多个团队和多种模型，还需要说明数据是否允许进入外部模型，以及哪些字段必须先脱敏。
三、如何用 Brief 生成 Skill 初稿
拿到 Brief 和两个完整成功样例后，可以让 Claude 先生成一份可测试的流程初稿。
这条 Prompt 的重点不是让模型自由发挥，而是限制它只能从已确认材料中提炼规则。没有依据的地方，宁可暴露不确定，也不要生成一条听起来合理的公司政策。
四、六类交付文件怎么写
一条长 Prompt 不适合承载完整岗位技能。建议把交付拆成六类文件，每一类只负责一个问题。
文件 1：操作说明
它是新员工第一次打开 Skill 时看到的文档，至少包含：
操作说明不要只描述“系统有什么功能”，要写用户下一步该做什么。
文件 2：输入表单
输入表单要把口头要求变成可填写字段：
| 字段 | 填写说明 | 缺失时处理 |
|---|---|---|
| 任务名称 | 用一句话描述本次动作 | 停止提交 |
| 原始资料 | 上传或粘贴来源材料 | 提示补充 |
| 负责人 | 填写已确认的负责人 | 标记待确认 |
| 截止时间 | 只填来源中已有日期 | 不自动推测 |
| 输出位置 | 选择项目和文件夹 | 提示权限 |
| 特殊限制 | 填写不能自动处理的内容 | 转人工确认 |
表单的意义是把“输入质量”变成可检查的前置条件。
文件 3：Prompt 或工作流配置
这一部分只处理约定的岗位动作，不要顺手塞进十个相邻功能。
一个合格的配置需要写清：
如果企业有多个 Skill，Prompt 中还应标注版本号和生效日期，避免新旧规则混用。
文件 4：输出模板
输出模板是验收的参照物。它应包含：
输出模板不宜把所有内容都写成一大段自然语言。能拆成字段的地方尽量拆开，方便检查、复制和写回业务系统。
文件 5：检查表
检查表要写“谁检查什么”，而不是只写“请仔细检查”。
可以按下面的责任分配：
每一项都要有不通过处理：回到哪个字段、补哪份证据、由谁重新提交。
文件 6：异常处理卡
异常卡应该让新员工知道遇到问题后先停在哪里，而不是继续反复点击。
五、让没有参与设计的人回放案例
Skill 初稿写完后，最有效的测试不是设计者自己再跑一遍，而是找一个没有参与设计的人，让他只看交付文档操作。
准备 2 个历史案例，观察他在哪里停住：
每一个停住点都不是“用户笨”，而是交付文档缺了一步。设计者熟悉内部背景，很容易把默认知识误当成说明；新员工回放可以把这些隐含规则暴露出来。
回放记录建议保存为：
六、上游 API 如何承接企业多模型调用
岗位 Brief 和六类交付文件描述的是工作方法，上游 API 解决的是企业模型调用基础设施。
例如一个内容岗位 Skill 可能需要调用：
如果每个 Skill 都直接保存不同供应商的 URL、Key 和请求格式，后续维护会变得困难。可以让业务系统通过企业 API 网关调用，再由 上游 API 统一处理：
- API Key 按团队、项目和环境分组。
- 不同任务使用不同能力和价格的模型。
- 记录模型、耗时、失败、重试和成本。
- 给长文本、图片和高价模型配置预算。
- 在替换模型时尽量保持业务层输入输出不变。
推荐的职责分层是：
上游 API 不会替企业自动判断某个员工能不能看客户资料，也不应代替业务负责人确认价格或对外承诺。这些权限要由业务系统、知识库和人工审批共同控制。
七、Brief 和交付文件的边界
Brief 解决什么
- 客户到底要处理哪一个岗位动作。
- 输入、输出和判断规则是什么。
- 成功和失败分别长什么样。
- 谁使用、谁审核、谁维护。
交付文件解决什么
- 新员工如何开始一次任务。
- 输入如何填写，输出如何阅读。
- 哪些环节必须停下来检查。
- 异常如何回滚，规则如何更新。
模型网关解决什么
- 模型从哪里调用。
- 谁可以调用什么模型。
- 一次调用耗时和成本多少。
- 失败、重试和备用路由如何记录。
三者不能互相替代。把所有内容塞进 Prompt，既不能替代岗位 Brief，也不能替代企业权限和审计。
八、交付前验收清单
Brief
- 有明确触发场景和不适用场景。
- 输入字段、格式和缺失处理已经写清。
- 输出字段可以被业务负责人检查。
- 已列出不能交给 AI 的内容。
- 有两个完整成功样例和常见错误。
- 使用人、审核人、管理员和保存位置明确。
六类文件
- 新员工只看操作说明就知道下一步。
- 输入表单有填写示例和必填字段。
- Prompt 或工作流只处理一个岗位动作。
- 输出模板有待确认项、风险项和版本信息。
- 检查表写清谁核什么以及退回方式。
- 异常卡覆盖缺失、冲突、敏感、超时和写回失败。
企业接入
- Skill 不包含明文 API Key。
- 生产、测试和不同团队的调用已经分组。
- 上游 API 或其他企业 API 网关可以追踪模型、路由和成本。
- 高风险写入和对外发送有人工审批。
- 外部模型的数据范围、保留时间和脱敏规则已确认。
总结
岗位 Brief 是 AI Skill 的输入合同，六类交付文件是新员工的操作界面。没有 Brief，设计者只能凭感觉写规则；没有交付文件，客户只能靠老员工口头传承。
把成功样例、错误样例、权限边界和异常处理写进去，Skill 才有机会从“看起来能用”变成“团队真的敢用”。再通过 上游 API 统一管理企业多模型入口、Key、路由、日志和成本，岗位工作流才能继续扩展，而不是每接一个模型就重新搭一遍。
结论
本文给出了问题定位、配置或创作流程的可执行路径。实际结果仍取决于当前版本、权限和运行环境，提交前应按官方文档复核可变字段，并保留失败证据和回滚边界。
