设计人和 AI 的分工

学完这一课，你可以

• 把一个维修任务拆成人、规则、检索、模型和工具各自负责的步骤。
• 分别写出草稿已准备、明确失败和状态未知时的界面与处理方式。
• 检查人工复核是否有信息、能力、时间、否决权和可行的接手安排。

开始之前

• 带上第 4 课的问题陈述、成功标准和停止条件；没有笔记时，先选择“核对维修资料并准备备件申请草稿”这个小任务。
• 阅读北辰案例：48 名现场工程师、6 名远程专家；初期助手只提供建议与草稿，不自动提交申请或停机。所有组织、事件与数据均为合成练习材料。

查看北辰案例与入门数据

先画出用户怎样完成任务

上一课确定了要解决的问题，这一课把它变成可以使用的工作方式。工程师需要的是完成一次处置，而不是多一段流畅回答。先写任务的起点、需要的输入、可以采取的行动和完成后的正式记录，再决定 AI 放在哪里。

以备件草稿为例：工程师打开工单，确认设备型号与现场信息，核对适用手册，查看建议，修改或拒绝，最后把经过核对的草稿交给现有审批流程。写完草稿不表示备件已订购；每次状态改变都应告诉用户还剩哪一步、由谁处理。

画图时分成四行：一线工程师看到和做什么；系统读什么、生成什么；业务与运行负责人怎样处理例外；设备客户怎样纠正信息或寻求人工解释。最后一行常被忽略，因为受影响的人未必有助手账号。

按任务选择最简单的实现

规则适合条件明确的检查，例如字段是否完整、数量是否在允许范围；检索帮助查找资料；模型适合把不同表达整理成建议或草稿。能调用工具的智能体会影响外部系统，需要另外说明动作授权、执行限制和最终状态怎样核对。

这些方式可以组合。先过滤用户可见的当前资料，再由模型整理，不代表资料一定真实、完整或适用于这台设备。检索增强生成（RAG）只是把检索结果交给模型使用；权限、版本与内容有效性仍要由系统和负责人分别检查。

Anthropic 的工程文章区分预先编排的工作流与由模型动态选择步骤的智能体。你可以借此比较选择，但不用把“更自主”当成目标：多次调用会增加等待、成本和出错路径，只有实际任务需要这种灵活性时才值得考虑。

跟着一条备件草稿走完整个流程

现在用一个不涉及真实设备的纸面例子走查。假设工程师认为可能需要 P-20 备件，数量是 2；这些参数用于演示，不表示设备已经诊断完成。不要让一个尚未核实的推测进入采购记录，先区分“用户提出的需要”与“已经确认的需求”。

准备两张纸：一张代表助手界面，另一张代表业务系统记录。每经过一步，都在两张纸上分别写出状态。这样能发现“界面说已完成，记录其实只有草稿”的差异，而不需要接通真实接口。

下面是可复用的步骤。任何一步缺少输入、权限或人力时，都写出暂时怎样完成工作；“找管理员”要具体到负责人、查证方式和没有回应时的下一步。

• 确认身份与任务范围：工程师只能查看获准区域的数据，本次只准备草稿。
• 核对设备、资料与来源：手册型号和版本适用，资料被撤回或信息不足时转人工查证。
• 展示草稿：列出备件、数量、依据和待确认项，允许工程师修改或拒绝。
• 准备记录：工具返回 prepared_not_submitted 时显示“草稿已准备，尚未提交”，保留请求编号。
• 处理后续：工程师按现有流程交给有权审批的人；助手不把这一步说成自动完成。

超时以后，先查状态再决定重试

请求超时只表示没有按时收到结果，不证明对方没有执行。实验环境中的故障发生在草稿记录已经保存、响应却丢失之后，返回 unknown_requires_reconcile。此时准确的提示是“状态未知，需要查证”，不是“失败，请重新申请”，更不是“已提交”。

幂等性指同一个操作被重复请求时，不应额外产生同样的业务影响。参考实现为草稿请求保存幂等键：相同键和相同参数返回已有结果；相同键但数量改变会被拒绝。真实系统是否提供相同保证，必须查接口约定并测试，不能只在前端生成一个编号就认为成立。

正确顺序是保留原请求编号与幂等键、暂停重复动作、查询正式业务记录、核对参数和状态，再决定是否需要继续或由人处理。若以后提议增加真实提交，必须重新验证该动作的授权与对账机制；草稿实验不能证明采购提交已经可靠。

明确失败也需要说明依据。实验里另一种故障在保存前发生，返回 not_submitted，系统能够确认未创建草稿；此时显示“草稿未创建”。只有确认未创建、输入与授权仍有效时，才可按接口约定考虑重试；普通超时不能直接归入这种情况。把原因、是否已有记录和下一步并排显示，不要只放一个红色“失败”。用户需要知道是补输入、申请权限、等待恢复，还是找负责人查证，不能被迫用重复点击来试探系统。

让人工复核真正能改变结果

“有人确认”不等于风险已经可控。复核者需要看得到来源和缺口，理解设备与任务，有足够时间形成自己的判断，并能让拒绝真的生效。拒绝以后还应有原流程或人工接手可用，否则人可能为了让任务继续而被迫点击同意。

先算容量，再承诺覆盖。为了演示，假设一个班次有 30 条需要复核的草稿，每条平均 4 分钟，需要 120 分钟。如果实际只留出 60 分钟，就不能声称全部得到充分复核。这些是假设数字，真实试点要观察耗时、波动与其他工作，并由运行负责人确认安排。

Microsoft 的相关指南提醒我们关注用户理解和过度依赖。对北辰可以试验：把来源与适用型号放在结论旁边；高后果任务让人先写初步判断；在独立练习环境放入错误样例观察是否发现。每项设计仍需测试，打开来源这一动作本身不能证明理解，更不能替代专业判断。

把失败、不可用和人工接手也设计出来

没有可用资料与模型服务故障不是同一个问题。前者可能是权限不足、知识过期或确实没有覆盖；对用户可以统一显示“没有可用且有权限的当前资料”，避免透露不可见文档。获准排障的人仍需区分原因，否则不知道该改访问范围、更新知识还是补充内容。

检索已找到有效资料，但模型在生成建议和任何工具调用之前故障时，可以展示获准查看的原文。只有系统确认这一步的执行记录后，才显示“本次没有生成建议，未执行工具动作”；若工具可能已经调用，就保留状态未知并查证。资料本身不可用时则不要用上次答案填空。系统恢复也不等于之前的任务都已完成：运行负责人需要核对排队草稿、未确认请求和需要继续人工处理的任务。

为夜班写出实际接手安排：谁当班、怎样联系、等待期间怎样工作、无人回应时暂停哪些能力。用户应能修改信息、拒绝建议和回到原流程；设备客户也要有可用的纠正与人工解释渠道。Anthropic 的上下文文章提供技术参考；在本练习中，压缩记录时仍要保留来源、版本、授权与未完成状态。

检查你的设计是否只是多了一句提醒

常见误区是只在页面底部写“仅供参考”，却把默认按钮设成自动接受；只说“人工负责”，却没安排时间和权限；只优化模型回答，却让撤回资料继续进入输入。这些问题要修改默认动作、任务范围或控制机制，提醒文案只能辅助说明。

另一个误区是把所有任务都升级给 6 名专家。专家还承担自己的日常工作，不能把人数直接换算成复核容量。先定义哪些任务一线能够完成、哪些必须交给有资格的人；没有合适接手安排的任务，留在原流程或暂时排除。

完成时请用工程师能理解的话说明：什么时候可以用，什么时候不能用；看到“草稿已准备”后还要做什么；看到“状态未知”时不要做什么、去哪里查证。让同伴照你的说明走一次；独自学习时，分别扮演用户与运行负责人，找出所有需要猜测的地方。

动手练习

检查你的理解

先写下自己的回答，再展开解析，看看还需要补充什么。

本课记录与下一步

一张人机分工图，附上成功、失败、状态未知的处理方法和人工接手安排。

把流程中仍需猜测的地方列成假设：资料是否可用、用户是否会核对、夜班是否有人接手。第 6 课用这份清单选择先做哪项小测试。