AI 原生开放教材

外观

AI 工程从零到一（中文）源码研读·中文原文 ↗仓库 ↗

自动化前先设计交接 ​

Claude 完成任务后，工作流还没有结束。下一个人必须能够验证、决策、行动并恢复。

类型： Learn 语言： Python 前置要求： 验证主张，而非置信度、让能力受权责边界约束、Anthropic 工作流模式预计时间： 约 105 分钟

学习目标 ​

  • 先绘制当前工作流，再决定 Claude 应在哪里参与。
  • 判断工作流步骤应辅助、自动化、重新设计还是拒绝。
  • 明确步骤的输入、输出、负责人、门槛、备用路径和服务预期。
  • 构建保留证据、不确定性和决策权的人工交接数据包。
  • 衡量工作流价值，不忽略审核、失败和维护成本。

问题所在 ​

某产品团队把每周发布简报自动化了。Claude 阅读 issue 摘要、起草简报，并在每周五发布到共享频道。

前两份简报节省了时间。第三份包含一个已经移出范围的功能，第四份漏掉一项尚未解决的安全问题。过去负责汇总简报的工程师以为产品经理现在负责审核，产品经理则以为自动发布的内容已经获批。

团队自动化了文本生产，却删掉了责任模型。工作流没有来源截止点、批准门槛、升级路径，也没有数据不完整时的备用方案。

成功的工作流由一串职责组成，每项职责都有明确证据和可恢复状态。

核心概念 ​

先绘制当前状态 ​

添加 Claude 前，先观察工作实际如何流转：

  • 什么事件会启动工作？
  • 谁提供每项输入？
  • 哪些系统是记录来源？
  • 人们在哪里运用判断？
  • 哪些例外最耗时间？
  • 谁批准结果？
  • 接下来会触发什么下游操作？
  • 如何发现并恢复失败？

不要只记录理想流程。跟随几个真实案例，非正式检查往往承载着关键知识。如果没有把它们编码或分配给负责人就直接删除，质量会下降，而新工作流表面上仍显得高效。

先选干预方式，再选工具 ​

为每个步骤选择四种干预方式之一：

  1. 辅助： Claude 提议、总结、提取或起草，人员仍是操作主体。
  2. 自动化： 系统依据政策执行边界明确、经过充分测试且可逆的步骤。
  3. 重新设计： 当前步骤由糟糕的输入或系统重复造成浪费，应删除或重构。
  4. 拒绝： 由于数据、后果、模糊性或政策风险不可接受，该步骤不应使用 Claude。

自动化不一定代表成熟度最高。如果分析师花数小时核对两个相互冲突的电子表格，更快生成核对说明并不能解决来源冲突。

把每个步骤写成合约 ​

每个步骤都应包含：

text
Trigger:
Owner:
Allowed inputs and sources:
Transformation:
Output schema:
Pass criteria:
Timeout or service expectation:
Escalation condition:
Fallback:
Next owner:

合约让每个步骤都能独立测试，也能防止责任在多个系统之间消失。

对于发布简报提取步骤：

text
Trigger: Thursday 15:00 source freeze
Owner: release coordinator
Inputs: approved tracker view and signed security status
Output: structured candidate items with source IDs and status
Pass: all required teams represented; unresolved fields marked
Escalate: missing security status or conflicting launch state
Fallback: coordinator uses the manual template
Next owner: product manager validates inclusion decisions

根据后果与可逆性设置控制 ​

两个问题决定自动化深度：

  1. 如果结果错误，后果有多严重？
  2. 能否在造成伤害前，以低成本撤销操作？
后果可逆设计方向
低是可以采用带监控的边界自动化
高是先生成或暂存，发布前必须审核
低否增加确认、审计并缩小范围
高否保留授权人工决策门槛和可靠备用路径

保存待审核的草稿，与向数千名客户发送消息完全不同。把操作决策权视为一项独立能力。

选择符合依赖关系的工作流模式 ​

Claude 工作流通常使用少数几种模式：

  • Prompt chaining： 固定顺序，每个阶段都可以检查。
  • 路由： 对工作分类，并发送到专门路径。
  • 并行化： 并行运行相互独立的分析，再协调结果。
  • Orchestrator-workers： 协调者把可变工作拆成子任务，再综合结果。
  • Evaluator-optimizer： 生成、按标准审核并修订，直到通过门槛或达到限制。

优先选择能够表达工作的最简单模式。固定五阶段报告不需要开放式 agent。路由工作流则需要可观察的路由信号，以及模糊案例的备用路径。

mermaid
flowchart LR
    A["Intake and source freeze"] --> B{"Complete and approved?"}
    B -->|"no"| C["Human resolves or uses fallback"]
    B -->|"yes"| D["Claude extracts and drafts"]
    D --> E["Automated checks"]
    E --> F["Reviewer handoff"]
    F -->|"approve"| G["Publish"]
    F -->|"revise"| D
    F -->|"reject"| H["Close and record failure"]

交接本身就是产品 ​

交接应尽量减少重新调查。向下一位负责人提供：

  • 所需决策和截止时间。
  • 工作流范围与版本。
  • 来源 ID 和新鲜度状态。
  • 候选输出。
  • 已通过和失败的检查。
  • 已知不确定性与冲突。
  • 已执行的操作。
  • 可选操作：批准、修订、拒绝、升级。
  • 备用与恢复说明。

不要把关键限制藏在长记录末尾。交接应围绕决策组织。

接手人必须知道还有哪些职责归自己。“请审核”信息不足。应具体写明：“确认 R-14 和 R-19 已获准对外发布；其余检查均已通过。”

在失败时保留状态 ​

长工作流会失败。API 会超时，连接器会返回部分数据，审核者会错过截止时间，输入也可能在生成后发生变化。

在有意义的边界建立检查点：

  • 来源快照已接受。
  • 提取已验证。
  • 草稿版本已生成。
  • 审核发现已记录。
  • 批准已记录。
  • 外部操作已完成。

尽可能让重试具备幂等性。重试草稿生成通常安全；发送或财务操作如果没有幂等键，重试可能造成重复伤害。

上线前定义人工备用路径。如果当前没有任何员工能执行备用路径，这种韧性就是虚构的。

衡量完整工作流 ​

同时跟踪价值和风险：

text
net value = time saved
          - human review time
          - correction and incident cost
          - platform and model cost
          - maintenance cost

实用运营指标包括：

  • 端到端完成时间。
  • 排队与审核时间。
  • 首次通过率。
  • 高严重度误放率。
  • 升级与备用路径使用率。
  • 单案例返工量。
  • 单个获接受结果的成本。
  • 来源新鲜度失败。
  • 用户修正与申诉结果。

如果审核变得更困难，更快的生成阶段未必能缩短端到端时间。

按利益相关者沟通限制 ​

管理层需要预期价值、风险边界和就绪证据。操作人员需要确切输入、失败信号和备用步骤。审核者需要标准和决策权。安全与政策负责人需要数据流、权限、保留和事件控制。

不要把能力演示当成生产证据。要说明测试了什么、在哪些案例上测试、哪些部分仍由人工负责，以及哪些当前产品事实需要重新核验。

动手构建 ​

第 1 步：绘制一个真实案例 ​

画出当前流程中的角色和系统，并标记：

  • 等待时间。
  • 返工循环。
  • 判断节点。
  • 记录来源查询。
  • 外部操作。
  • 已知例外。

询问操作人员：哪项非正式检查能防止最严重的错误？

第 2 步：为候选干预评分 ​

对每个步骤按 1 到 5 分评分：

因素问题
重复性是否反复执行相同转换？
清晰度能否写出通过标准？
数据批准输入是否获批且受控？
可逆性错误操作能否被阻止或撤销？
可检测性失败能否在造成伤害前被发现？

低分步骤应采用辅助、重新设计或拒绝，不适合自动化。

第 3 步：编写未来状态合约 ​

定义每个步骤、负责人、门槛、检查点、备用路径和服务预期。明确写出人工路径，再让操作人员、审核者和政策负责人分别演练一个正常案例和一个例外。

第 4 步：构建交接数据包 ​

使用稳定模板：

text
Decision required:
Deadline and owner:
Workflow and source versions:
Candidate result:
Evidence:
Checks passed:
Checks failed:
Uncertainty:
Actions available:
Fallback:

如果数据包漏掉必需阻断项或来源版本，应拒绝接收。

第 5 步：以影子模式试点 ​

让 Claude 与现有流程并行运行，但不允许它执行外部操作。比较结果和审核投入。应包含例外，不要只测试简单案例。只有门槛通过、事件负责人准备就绪后，才进入有限发布。

交互实验 ​

使用审核门槛图调整后果、可逆性、模糊程度和证据完整性。控制应在进入不可逆状态前，从边界自动化转为强制审核。

figure
07-human-review-threshold

实践实验 ​

运行交接评分器。移除负责人、检查点、备用路径，或删除发布步骤的批准要求，观察合约如何失败。然后清除未解决的审核检查，比较推荐的下一步操作。

交付产物 ​

outputs/workflow-handoff-packet.json 是填写完成的发布简报工作流，包含步骤负责人、门槛、检查点、备用路径、服务预期和可直接行动的审核数据包。

验证 ​

在本地验证工作流：

bash
cd certifications/claude/lessons/07-workflow-design-and-human-handoffs/code
python3 main.py
python3 -m unittest discover tests -v

验证器会检查每个步骤是否具有负责人、门槛、升级条件、备用路径和下一位负责人；不可逆发布是否经过人工批准；交接是否列明失败检查和可选决策。

综合项目关联 ​

测验会检查当前状态绘制、重新设计、交接内容、重试安全、责任归属和影子模式就绪情况。把验证后的数据包作为 Associate 综合项目 29 的运营与审核交接。

上手使用 ​

考试决策模式 ​

对于工作流场景：

  1. 绘制当前决策、证据、角色和例外路径。
  2. 自动化前先消除流程浪费。
  3. 选择符合依赖关系的最简单模式。
  4. 在后果严重或不可逆边界保留人工决策权。
  5. 发送包含证据和失败检查的结构化交接。
  6. 上线前定义检查点、备用路径、监控和负责人。

常见坑 ​

  • 自动化文案，却删除负责人： 没人知道谁负责批准。
  • 把演示当部署证据： 正常示例会掩盖例外与运营问题。
  • 固定流程使用开放式 agent： 复杂度增加，却没有价值。
  • 把相互依赖的工作并行化： 证据尚未验证，综合就已经开始。
  • 把人工参与当口号： 没有审核数据包，也没有拒绝决策权。
  • 没有来源截止点： 输出审批期间，输入仍在变化。
  • 重试一切： 不可逆操作可能执行两次。
  • 只衡量节省时间： 审核、修正、失败与维护全被忽略。

练习 ​

  1. 绘制一项重复工作流，并找出一项非正式质量检查。
  2. 把每个步骤归类为辅助、自动化、重新设计或拒绝。
  3. 为价值最高的候选步骤编写步骤合约。
  4. 为只有五分钟时间的审核者设计交接数据包。
  5. 进行一次失败桌面推演：来源在批准后、发布前发生变化。
  6. 定义五项能揭示工作流是否创造净价值的指标。

关键术语 ​

  • 当前状态图： 表示工作如今实际如何流转的图。
  • 步骤合约： 工作流步骤的触发条件、负责人、输入、转换、输出、门槛、升级条件、备用路径和下一位负责人。
  • 交接数据包： 为下一位负责人准备的结构化状态和证据。
  • 检查点： 已验证阶段之后的持久恢复点。
  • 幂等性： 重复操作不会造成效果叠加的属性。
  • 影子模式： 运行新工作流，但不允许它控制真实结果。
  • 备用路径： 自动化路径不安全或不可用时，采用的经过测试的替代路径。
  • 来源截止点： 固定输出代表哪些输入版本的边界。

延伸阅读 ​

Claude 产品功能、连接器行为、模型能力、限制和成本都可能变化。这些来源于 2026-08-08 核验。把工作流从影子模式转入生产前，应重新核验当前官方文档和组织控制。