“给全员开 AI 账号，再做一次 Prompt 培训”，很像给所有开发者装好 IDE，然后宣布研发效能改造完成。
Google Workspace 9 月 2 日发布的 AI adoption playbook 也点出了这层差别：采购许可不等于改变工作方式；通用 AI 素养只是起点，价值要进入部门特有的工作流。文章还建议不同岗位沉淀各自的 Prompt 或工作流资料库。
从工程角度看，问题在于培训交付的是知识，生产需要的是 runtime contract。员工知道怎么和模型说话，不等于模型拿到了当前上下文、正确工具、输出 Schema 和验收标准。
我更愿意把可复用单位叫作 Role Pack。
Role Pack 解决什么边界
它不是一条更长的 system prompt，而是一组可以独立版本化的岗位资产：
type RolePack = {
identity: RoleIdentity
context: ContextSource[]
workflow: WorkflowGraph
templates: OutputTemplate[]
capabilities: CapabilityPolicy
evals: EvalCase[]
version: SemVer
}
Context：避免每轮重新做 RAG 项目
岗位需要的是有来源、有效期和权限的上下文，不是越多越好的向量片段。
可以把上下文源分成 stable、dynamic 和 run-scoped：品牌定位属于稳定资料，价格与平台规则属于动态资料，当日热点属于本轮资料。动态资料过期时应触发刷新或人工确认。
type ContextSource = {
uri: string
owner: string
freshness: 'stable' | 'daily' | 'per-run'
access: 'public' | 'private'
onStale: 'refresh' | 'warn' | 'block'
}
把 stale policy 写清楚，比让模型“尽量使用最新信息”更可执行。
Workflow：流程图负责控制，模型负责判断
纯 Prompt 工作流常把计划、执行、重试和验收混在一次上下文里。任务变长后，模型很容易忘记哪些步骤已经完成，或者把工具返回 ok 当成业务成功。
Role Pack 里的 Workflow Graph 应该显式保存状态：
RESEARCHED -> DRAFTED -> REVIEWED -> PREFILLED -> VERIFIED
\-> NEEDS_HUMAN
节点之间传结构化产物，失败时回到对应节点。最终是否公开，由可验证的外部状态决定，不由 Agent 自述决定。
Templates：输出 Schema 不等于固定文风
模板最容易被误做成范文复制器。
更好的做法是约束必填字段、长度、图片规格、引用格式和平台选项，同时把标题节奏、案例和结尾留给生成。这样同一业务事实进入不同平台，输出仍然能适配消费场景，而不是变成一稿多投。
{
"required": ["title", "body", "cover", "summary", "tags"],
"constraints": {"titleMax": 30, "coverRatio": "16:9"},
"humanGate": ["finalPublish"]
}
Capabilities：岗位拥有能力，模型只发起请求
把所有 Skill、MCP 和账号权限接给一个通用 Agent，短期很方便，长期会让工具路由和风险面一起膨胀。
岗位包应该声明最小能力集：研究员可读网页，视觉岗位可读素材并写入图片，发布岗位接触本机登录态，但公开发布需要确认。Agent 提出 tool call，不代表策略层必须执行。
这也让复制和审计更容易：复制一个岗位时，可以同时看到它带走了哪些资料和权限。
Evals：失败样例比“认真一点”有用
Role Pack 不只需要标准答案，还要保存坏样例：过期价格、夸张标题、错误标签、缺少封面、点击后没有成功记录。
每个失败样例最好对应一个检测器和回退策略：
if (result.pageState === 'unknown') {
return transition('NEEDS_HUMAN', { retrySubmit: false })
}
“不要重复提交”是一条可执行策略；“请谨慎操作”只是态度。
版本管理比共享文档更重要
岗位资产会同时变化，但不该绑在一起发布。
- Context 可按资料版本更新；
- Workflow 变更要跑回归任务；
- Capability 扩权要单独审批；
- Template 变化要做平台预览；
- Eval 新增不应破坏旧的通过标准。
一个轻量的 manifest 就能让变更可见：
name: content-operator
version: 2.1.0
requires:
context: brand-kit@3
workflow: content-loop@2
template: juejin-article@5
permissions: publisher-limited@1
eval_suite: content-quality@7
如果岗位升级后效果变差，至少知道该回滚哪一层，而不是去几百轮聊天记录里找“那句以前很好用的提示词”。
培训对象也应该改变
通用培训仍然有用，但它应该教人三件事：怎样给出业务目标，怎样判断结果，什么时候接管。至于每个岗位的资料、步骤和工具，不该要求每个人从头拼装。
这也是我们做 Tipkay 时采用岗位化 AI 员工的原因。官方员工预先组合经验、流程、Skill 和 MCP，用户可以直接从真实任务开始，再复制并加入自己的业务资料与规则；需要跨岗位时让不同员工交接产物，最终发布等关键动作仍由人确认。
这里没有“岗位包一次配置永久有效”的承诺。平台规则、业务资料和模型都会变，持续维护与版本升级本身就是产品的一部分。但它至少把学习成本集中在可复用资产上，不必让每位员工重复交配置税。
AI adoption 的终点不该是“账号激活率很高”，也不该是“全员都会写 Prompt”。更靠谱的判断是：当最懂 AI 的那个人不在场时，这个岗位是否仍能借助同一套资产，完成可验收的交付。
参考：
