让组织接住任务与持续改进责任

一个助手可以由个人做出来，一项稳定业务能力却依赖多人接续。AI产品负责人不能用“业务负责正确性、技术负责系统”结束分工：字段冲突由谁解释？规则失效由谁更新？写入结果未知由谁调查？本章形成能运转的责任安排，不要求新建AI委员会。

围绕具体决定分工

沿合成商品建档任务，业务负责人定义可审核草稿及关键错误；运营专员使用、指出返工并参与标注；知识／数据维护者管理类目与属性口径；工程负责身份、工具、记录和恢复；产品负责人连接选择、交互、指标及版本优先级。小团队可由同一人承担几个职责，职责仍须可辨认。

表中的职责是参考安排。重点是事件发生后有人获得足够材料并能采取动作，而不是每一格都盖章。权限、安全与客户资料要求应在方案形成时接入；具体争议才升级到对应责任人。

分开岗位工作法、企业规则和执行保障

Knowledge Work Plugins把客服分诊、升级与知识沉淀组织成文件化工作法；customizer会发现企业工具、流程与服务时限约定，关键事实未知可以保持未配置。Skill要求“更新工单”不证明宿主已经写入，也不证明具备该记录权限。固定版本客服工作法 · 企业定制流程

以合成白屏工单为例：12人受影响，11:00要开会，旧Bug仍在调查，客户合同SLA未知。岗位工作法要求提取影响、核对相似问题、形成工程调查包与客户回复草稿；业务负责人确认严重等级、真实合同与承诺口径；宿主及应用负责授权、持久状态、实际提交和回执。三者分别验收：

若没有SLA，保留未知并找有权核对的人；若没有工程回执，回复仍写“待交调查”。不能把模板P2时限直接承诺给客户。低风险草稿可先用岗位插件；需要跨会话恢复、强制审批或系统写入时，再补应用能力。具体产物与平台选择见平台与采用专题。

选择探索、部门复用还是正式产品

个人探索适合检验少量低风险任务，输出由使用者检查；部门复用需要共同材料、支持入口、维护者和停止条件；正式产品通常还需稳定集成、身份映射、事务动作及运行保障。它们不是技术成熟度阶梯，部门工具可能长期适用，正式软件也可以只用规则与少量模型。

BBVA公开材料描述了采用团队、技术支持、内部目录、培训及分布式实践者，也描述法律咨询草拟后由专业人员复核。它支持“探索需要复用与维护接续”的判断，不证明任何企业都要设相同职务或采用其内部架构。目录中的每项能力应至少让人知道任务范围、材料维护者、复核责任与最近检查，而不是只有工具名称。

部门中最积极的人可能擅长演示，但不一定有维护业务规则的权限。选试点参与者应覆盖不同熟练度、异常任务和实际接手者；让负责审核的人在设计草稿界面时参与，而不是上线后才被通知增加复核。

把培训嵌入实际工作

培训目标是让用户知道何时使用、如何核对、出现异常怎样继续。建档训练可用三笔合成任务：正常生成草稿；识别120g与150g冲突；写入超时后保持待确认。合格表现是使用者能完成核对与接续，而非记住“不要相信AI”或会写更长Prompt。

训练同时暴露产品问题。如果每位用户都要手动找来源，先改善来源展示；若每次错误都要找工程师读日志，应提供任务ID和明确求助入口。重复提醒用户谨慎不能替代可操作的产品设计。

建立一个足够轻的改进循环

每周用实际失败讨论一次：发生在输入、口径、模型、工具、交互还是接续；谁修、修完看哪组任务、哪些用户需要知道。记录最少字段即可：任务ID、可分享的失败现象、影响、负责者、修改版本、复查结果。含客户信息的轨迹留在获准的私有系统，不把全文复制到公共知识库。

例如用户投诉“生成草稿很快但审核更慢”。先查看复核任务：来源难定位、冲突太多、还是字段本身错误？前者可能改交互，中者要追问供方或改范围，后者才可能改提取机制。反馈越接近完整任务，团队越不会把所有问题都交给Prompt工程。

什么条件下可以继续

进入现状流程调查前，应至少确认业务定义有人拍板、数据与接口有人维护、异常有人接手、试点参与者有真实工作时间。无需提前写完全套治理规则；缺了某个关键责任则缩小范围，例如先做离线草稿，不开放写入。

本篇结束后的共同成果是一项值得推进、能够检验、有人承接的任务。第二篇将展开现状流程与目标流程，把这里定义的结果和责任放到具体步骤、交互和数据中。

这里先确认调查与接续有人承担；完整责任安排会随现状发现和接口条件修订。参看观察到设计的协作交接，逐项说明谁提供材料、谁判断、产物交给谁，不要求在调查前完成全部实施安排。

参考资料

• BBVA部门采用（2025-01-07）：专业复核与采用支持。
• Knowledge Work Plugins固定版本：岗位工作法；公开插件不证明企业运行保障。
• 职责与白屏工单均为合成教学设计。

继续使用

上一章：定义任务与成功证据 · 下一章：还原现状流程 · 五篇阅读目录。相关工具：责任与例外接续。