AI Native Builder

主题

第 6 章｜重构人—AI—系统工作流 ​

上一章没有批准建设一个“销售 Agent”。它只确认了一个更小的候选场景：销售结束客户会议后，系统准备一份有来源、可检查的 CRM 更新预览，由销售决定是否提交。

这仍然不等于可以开始开发。我们知道哪里存在负担，却还不知道应该删除哪些步骤、哪些工作交给规则、AI 应该处理什么，以及失败后由谁接手。

本章将把上一章的问题一页纸变成目标工作流。读完后，你应当能够从一次真实任务还原现状，解释每个改造选择，画出正常路径和异常路径，并用低成本演示决定方案是否值得构建。

一条 44 分钟的会后任务 ​

以下材料来自“澄川工业客户跟进助手”教学案例。人物、时间和系统行为只用于教学，不代表真实企业数据或通用基线。

周二 16:05，一名销售结束客户会议。她先用 6 分钟回看手写笔记和转写片段，确认客户提到的设备数量、上线时间和两个未解决问题。

接着，她在文档库里搜索一项产品限制。搜索结果出现两个名称相近的说明，一个标着上季度日期，另一个没有生效日期。她又花了 9 分钟打开文档、对照聊天记录，仍无法判断哪个版本有效。

16:20，她把问题发给售前。12 分钟后收到答复。这个等待并没有让她离开任务：她需要保留会议语境，期间又回到转写记录确认客户原话。

确认口径后，她用 10 分钟填写 CRM 的需求、风险和下一步字段，再用 4 分钟把下一步复制到个人任务清单。最后 3 分钟用于检查负责人、日期和措辞。16:49，任务结束。

这次任务总共 44 分钟，其中 32 分钟是操作，12 分钟是等待。上一章观察到的 8 次任务落在 24—61 分钟之间；44 分钟只是其中一条记录，不是平均值，更不能代替扩大后的基线。

若只看结果，可以把这段工作概括为“整理纪要并更新 CRM”。但这个概括漏掉了真正影响设计的东西：版本冲突、跨人等待、语境重建、重复录入，还有最后那一下责任判断。

现状流程要记录任务怎样发生 ​

现状流程的用途不是展示标准操作程序，而是保留事实。业务负责人给出的 SOP 可以帮助理解规则，但不能代替一线人员最近一次怎样完成任务。

记录时，从触发事件开始，按时间顺序写到业务状态真正改变为止。每一步都要保留实际角色、输入、动作、系统、输出、异常、操作时间和等待时间。返工发生时，不要把它并回原步骤。

澄川这条任务可以还原成下面的记录。表格用于压缩前面的叙事，不能替代现场观察。

#实际动作与角色输入和系统输出或状态操作 / 等待观察到的问题
1销售核对笔记与转写手写笔记、会议转写候选需求与问题6 / 0 分钟信息散落，需要重建语境
2销售搜索并比对产品说明文档库、聊天记录无法确认有效版本9 / 0 分钟两个来源冲突，生效日期不全
3销售询问售前IM、会议上下文获得当前口径0 / 12 分钟判断依赖个人，任务停住
4销售填写 CRM会议信息、售前答复、CRM字段草稿10 / 0 分钟同一事实被重新组织和录入
5销售复制行动项CRM、个人任务清单个人任务4 / 0 分钟重复输入，两个系统可能失去同步
6销售检查并完成CRM 草稿内部记录完成3 / 0 分钟最终判断和责任仍在人

“操作时间”和“等待时间”必须分开。AI 也许能减少搜索和填写，却不能直接消除等待售前的 12 分钟。如果等待来自资料所有权和审批制度，给模型更长上下文也不会解决它。

任务的终点也要写成状态，不能只写“生成完成”。对澄川而言，模型产出字段建议不算完成；销售确认记录内容，CRM 接受更新，内部下一步拥有负责人和日期，任务才结束。

同样慢，原因不同 ​

流程图上一个红点不等于一个 AI 机会。同样是“慢”，背后可能是多种问题，处理方法也不同。

第一类是不必要的动作。参会人、客户编号和会议时间已经存在于日历与 CRM，却仍由销售重新输入。稳定的字段映射和普通集成更适合处理这类重复工作。

第二类出在信息组织上。会议内容是非结构化语言，CRM 需要需求、风险、行动项等结构化字段。这里需要理解上下文和候选字段的含义，适合让大模型提取与生成，但输出仍应被视为建议。

第三类是知识治理问题。两个产品文档互相冲突，说明团队缺少权威来源、版本或生效规则。检索可以把冲突找出来，不能替组织决定哪份资料有效。内容负责人必须处理源头问题。

第四类落在业务判断上。客户说“希望九月前上线”，不等于销售可以把预计成交日期改为九月，也不等于公司已经承诺交付。模型可以引用原句并提出候选字段，授权销售仍要解释商业含义。

最后一类是控制缺口。现有 CRM 只保留最终字段，没有记录字段依据、销售修改和资料版本。即使结果正确，团队也难以复盘它为什么正确，更难发现某个旧口径正在反复进入记录。

AI Native Builder 在这一步要做的是组合判断：多余的步骤删掉，确定性连接补上，AI 的输入输出卡紧边界，知识责任、业务责任和系统控制再接回流程。只把“人工写字段”换成“AI 写字段”，剩下四类问题原封不动。

先比较四种改法 ​

澄川没有把每个痛点都交给同一个模型。项目组先为每一段工作选择最简单、最可检查的机制。

参会人与客户编号使用确定性映射，因为来源和规则清楚。CRM 字段类型、必填项和禁止修改字段也用代码校验；它们不需要概率判断。

产品资料先由内容负责人确定权威目录、版本和生效日期。系统检索这些资料并显示依据。两个有效来源冲突时，系统必须暴露冲突，而不是让模型自行挑一个看起来更合理的答案。

AI 只处理需要语言理解的部分：从已授权的会议记录中提取客户原话、候选需求、风险和行动项，并把产品资料与字段建议关联起来。它不能批准价格、交期或商机阶段。

最终提交仍由销售发起。确定性系统负责鉴权、显示差异、执行写入和记录结果。这样的分工不会让演示显得“全自动”，却能让每个错误回到可识别的责任位置。

问题首选机制选择理由
已有结构化信息重复录入字段映射或系统集成输入、输出和规则稳定
CRM 必填项遗漏表单与代码校验可明确判断通过或失败
会议语言转成字段候选LLM 工作流需要处理非结构化语义与不确定性
产品资料版本冲突内容治理 + 冲突阻塞权威性不能由模型擅自决定
正式 CRM 更新人工确认 + 确定性写入有业务副作用，需要身份、审计和结果确认

这一步也决定了架构。澄川的首轮路径稳定，使用的资料和工具固定，异常可以提前列出。项目组因此选择受控 LLM 工作流，不建设能够自行规划路径、动态选择大量工具的 Agent。

按照第 4 章逐动作判断权限的方法，AI 只对需求和风险的识别提出建议，并准备 CRM 更新预览。正式写入只有在销售确认后由确定性系统执行，AI 本身没有直接更新 CRM 的权限。

目标流程改变了什么 ​

目标流程不是未来系统的功能菜单。它要回答一次任务如何从触发走到完成，正常状态和失败状态分别怎样变化。

澄川的目标流程从会议结束开始。系统先读取已授权的会议记录，通过日历与 CRM 的确定性关联找到客户和参与者。关联失败时，销售补选客户，流程不会猜测。

AI 随后提取客户原话、未决问题和候选行动项。检索组件只查询经过批准的产品资料，并把文档标题、版本和片段放在建议旁边。没有依据的字段显示“待确认”，不补齐看似合理的内容。

销售在同一个预览界面核对“现有值—建议值—依据”。价格、预计成交日期和正式商机阶段默认不在可写字段内。销售可以接受、修改、拒绝，也可以把某一项升级给售前或销售运营。

字段通过规则校验后，系统生成 CRM 更新预览。销售确认，确定性写入工具才向沙盒提交。工具返回最终状态后，系统记录原始建议、人工修改、来源版本、确认人和写入结果。

把这条路径压缩成状态，可以写成：

text
会议结束
→ 关联客户与已授权记录
→ 提取候选事实并检索批准资料
→ 生成带依据和不确定项的字段建议
→ 销售核对、修改或升级
→ 规则检查与更新预览
→ 销售确认
→ 沙盒写入并核对最终状态
→ 完成，或转人工 / 暂停 / 恢复

相比现状，目标流程删除了已有字段的重复输入，把资料冲突提前暴露，把建议与依据放在同一处，并为修改与失败留下记录。它没有承诺消灭所有等待：售前必须处理的例外仍然存在，只是任务不会在 IM 中失去状态。

目标流程还新增了一些成本。销售需要审阅预览，内容负责人需要维护权威资料，技术团队需要处理权限、日志和恢复。未来评估要比较的是净人工负担和业务结果，不能只计算模型生成节省了几分钟。

GOV.UK Service Standard 关于完整用户问题的说明要求服务设计围绕用户目标理解端到端问题，而不是只看组织边界内的一小段系统流程。这个原则放到澄川，就是把“生成字段”放回“完成一次可靠会后记录”的全程中判断。

谁建议，谁判断，谁执行，谁负责 ​

“human in the loop”没有给出责任设计。人在哪里介入、看什么信息、可以做什么、多久要响应，以及无人响应时流程处于什么状态，都必须写清楚。

澄川的销售判断客户原话如何进入业务记录，并对提交内容负责。AI 负责生成候选和显示可能依据；它不拥有业务授权，也不能成为责任主体。

确定性系统负责身份验证、字段校验、状态转换、写入和日志。产品内容负责人决定哪些资料有效，销售运营负责人维护字段语义，IT 决定系统身份和环境权限。

Builder 负责把这些约束组合成可运行设计，验证各方对同一流程的理解。Builder 不能替内容负责人宣布旧文档失效，也不能替销售批准对客户含义有影响的字段。

流程决定或动作AI确定性系统人与最终责任
从会议中提取候选事实提取、区分原话与推断、标记不确定保存输入和版本销售核对业务含义
引用产品资料检索并提出候选依据限定来源、显示版本、检测冲突内容负责人决定权威性
形成 CRM 字段建议生成建议和理由校验类型、必填项和字段白名单销售接受、修改或拒绝
提交 CRM 更新不直接执行鉴权、写入、查询结果和审计销售确认；IT 管理权限
修改正式商机阶段或对外承诺不在范围内必须停止并转人工授权业务负责人按原流程处理

责任还需要与状态相连。“等待人工”不能无限悬挂。流程要记录等待谁、何时开始、可以怎样提醒，以及超时后是取消、保留草稿还是回到原流程。

一次资料冲突怎样走完 ​

正常路径只能证明界面会动，异常路径才能检验流程是否完整。项目组因此选用刚才那两个产品文档，设计第一次失败演示。

会议记录里，客户询问某设备是否支持离线模式。检索返回两份仍在批准目录中的文档：v2.1 写着“仅支持联网运行”，v2.3 写着“特定配置可离线运行”，但 v2.3 缺少生效日期。

系统没有要求模型选择较新的版本。它把这个字段标为“来源冲突”，并显示两段文字、版本号与缺失信息。对应的产品能力字段被阻塞，其余无争议字段仍可继续审阅。

销售可以把冲突升级给产品内容负责人，流程状态变成“等待内容确认”。在状态解决之前，系统不生成确定口径，不允许把该字段写入 CRM，也不生成对外承诺。

内容负责人核对发布记录后，将 v2.1 标为失效，为 v2.3 补上生效日期和适用配置。系统记录这次资料变更。销售重新运行被阻塞的字段，看到新依据后确认建议，流程才继续。

这个异常路径区分了三件事：模型的不确定、知识源的冲突和人的授权判断。把它们都显示为“低置信度”会丢失各自的责任归属；让销售手工选较新的文档，也会把内容治理问题转嫁给一线用户。

其他异常也应按同样方式写到可结束的状态。会议记录缺失时，系统提示补充或回到人工录入；权限不足时保留预览并发起授权，不要求用户复制敏感内容；写入结果未知时暂停并查询 CRM 最终状态，不能直接重试造成重复副作用。

Google PAIR 的 Errors + Graceful Failure 指南建议团队定义用户眼中的错误、识别错误来源，并为用户提供失败后的继续路径。

PAIR 的反馈与控制指南还强调，AI 输出应当可调整或关闭，早期产品尤其需要人工后备路径。

这两项原则在企业工作流里不能停在错误提示文案。继续路径必须包括状态、负责人、允许动作和最终业务结果；“请稍后重试”不是回退方案。

用五分钟演示做一次建设前评审 ​

流程图仍可能让不同角色各自想象。项目组需要把目标流程变成一个可以操作和争论的对象。原型可以是纸面、幻灯片、可点击界面或由团队成员在幕后手工完成的 Wizard of Oz 演示。

GOV.UK 的原型指南把原型用于建设前探索、分享和测试不同设计，并明确提醒不要直接把原型代码当作生产服务。原型的保真度应当服务于待回答的问题，而不是展示团队已经写了多少代码。

澄川第一版演示只展示了一张 AI 生成的 CRM 卡片。销售经理说“看起来不错”，销售问“它引用的是哪份资料”，IT 则问“点击确认会不会写正式 CRM”。演示没有提供回答这些问题的路径。

项目组重做了五分钟演示。前 30 秒说明本次任务与证据边界：44 分钟是一条模拟任务记录，目标是验证流程理解，不是证明收益。

接下来 60 秒走过现状流程，停在资料冲突、售前等待和重复录入三个位置。然后用 120 秒演示正常样本：系统关联会议、生成带来源的建议，销售修改行动项，预览新旧字段，确认后只写入沙盒。

第四段用 60 秒演示产品资料冲突。观众看到系统停止该字段、保留其他草稿、转交内容负责人，并明确知道未解决前不会写入。最后 30 秒展示本次不做的范围、仍待补齐的证据，以及团队需要决定这条流程是否值得建设。

第二次演示产生了可以改变设计的反馈。销售要求并排展示现有值和建议值，而不是只看最终文本；内容负责人要求冲突必须带文档版本；IT 要求原型中的“确认”只能写沙盒，并在按钮旁显示环境。

“喜欢这个界面”不能支持建设决定。有用的反馈要能落到具体地方：这步有没有省时间、边界清不清楚、敢不敢用——而且说出来之后能改变下一步设计。

原型评审也不是可用性测试的替代品。五分钟演示用于尽早发现理解分歧；进入真实试点前，还要让目标用户完成完整任务，观察他们是否看懂、是否绕开关键步骤，以及在哪里放弃。

这条目标流程是否值得建设 ​

第 5 章先判断问题是否得到足够证据支持。本章再判断重构后的方案是否值得付出系统建设成本。这两个阶段决定都属于本书的教学安排，不是行业统一标准。

这个决定不是投票问“大家是否喜欢”。评审者需要比较现状与目标流程，检查正常与异常路径，确认每个副作用的责任，并查看原型反馈是否已经改变设计。

澄川团队决定“有条件继续”。评审同意建设一个固定、受控的 LLM 工作流，不同意建设开放式销售 Agent，也不允许正式 CRM 自动写入。

建设范围包括：读取已授权会议记录和批准资料；准备带依据的字段建议；显示现有值与建议值；由销售确认后写入沙盒；记录建议、修改、来源和最终状态。

进入第 7 章的条件也被写进决定：资料需要版本和负责人；输入适配器先保持只读；写入工具必须限制字段与环境；来源冲突要阻塞；写入结果未知时必须先查询状态；正常与异常样本要留作后续评估材料。

这项决定没有证明目标流程会降低耗时，也没有证明用户会长期采用。它只说明方案已经具体到值得构建一个最小可运行方案，且主要风险都有可实施的控制手段。

如果演示发现用户审查建议比原流程更慢，或者内容负责人无法维护权威资料，团队应当返工或暂停。已经做出的界面不构成继续投入的理由。

几种看似合理的失败设计 ​

理想 SOP 常被误画成现状流程。图上没有等待、返工、私聊和临时表格，目标流程自然显得很顺。修正办法是回到最近一次任务，用时间线和材料还原实际动作。

另一个常见设计是把“人工写”改成“AI 写”。生成可能更快，查资料、确认口径、跨系统复制和责任判断仍然存在，流程还多出一次审稿。要逐段比较端到端变化与新增负担。

“AI 低置信时转人工”也过于模糊。谁收到任务、看到哪些依据、能作什么决定、多久后超时、系统怎样恢复，都没有答案。异常只有走到可结束状态，才算被设计过。

只演示顺利路径，会把风险讨论推迟到集成以后。至少选择一个真实可能发生的冲突、缺失、权限或未知状态，让评审者亲眼看到系统怎样停、谁接手、怎样继续。

还有些问题属于组织决策。售前回复慢可能源于资源不足，报价审批可能源于授权政策。AI 可以减少信息搬运，不能绕过这些责任。把政治和审批问题自动化，通常只会让越权发生得更快。

把方法迁移到合同初审 ​

假设法务团队希望“让 AI 自动审核合同”。较弱的目标流程可以写成：上传合同，AI 识别风险，自动批准低风险条款，完成审核。

这个流程没有说明风险定义、公司模板、历史版本、最终责任，也没有处理 AI 漏掉高风险条款的情况。“低风险”只是一个名字，尚未成为系统可以执行的规则。

更可用的设计会先观察一次合同初审。若主要时间花在定位非标准条款，AI 可以比较合同与当前模板，标出差异并引用原文；固定缺项由规则检查；法务判断风险和例外。

目标状态是“法务已确认初审结果”，不是“AI 已生成报告”。模板缺失、条款无法解析或来源冲突时，系统保留任务并回到人工路径，不自动批准，也不把未审内容推进下一流程。

迁移时不要照抄澄川的角色和异常。你需要保留的是推理顺序：观察任务，定位负担，比较非 AI 方案，选择人、AI 与系统的分工，再让异常走到一个明确状态。

你的练习 ​

从上一章的问题一页纸中选择一条真实任务。若你使用模拟材料，在文件顶部标注“教学模拟”，不要声称获得了现场证据。

先完成一次从触发到业务结束的观察记录。把操作、等待和返工分开，保留系统切换、隐性判断和异常。随后在每个痛点旁写下四个候选动作：删除、标准化、确定性自动化或 AI 辅助，并解释取舍。

再画目标流程。流程中至少要出现一个不使用 AI 的步骤、一个 AI 建议步骤、一个人工决定和一个确定性系统动作。为每个副作用写出确认人、记录和失败后的状态。

准备一个正常样本和一个失败样本，完成五分钟演示。不要提示参与者应该喜欢什么；记录他们在哪里犹豫、修改、拒绝或要求查看依据。

你可以直接使用练习册中的现状流程记录、目标流程与责任矩阵和五分钟原型。第一项保留现状证据，第二项连接目标步骤与责任，第三项记录演示材料和反馈。表格填完后，还要写下是否继续建设及其证据边界。

怎样判断答案是否合格 ​

先遮住所有 AI 节点，只看流程起点和终点。如果目标流程仍然没有完成用户真正的任务，它只是在优化局部输出。

再逐步问：这一步为什么存在，为什么由当前机制处理，出错后谁能发现？答不出时，不要用“智能体自动处理”填空。

检查异常是否真正结束。写“转人工”后，还要能找到接收角色、所需材料、等待状态、允许动作和恢复条件。未知写入状态不能默认重试，高风险动作不能靠提醒文字放行。

最后比较新增负担。人审时间、知识维护、支持、日志和权限管理都要进入后续指标。若目标流程只是把操作时间转成审查时间，应当返工。

一份合格作业最终能支持“继续、返工、暂停或终止”中的一个决定。决定必须带条件和负责人，不能只写“建议推进”。

本章小结：流程已经清楚，系统契约还没有 ​

澄川把一条 44 分钟的任务拆成了操作、等待、知识冲突、业务判断和控制缺口。项目组没有让 AI 接管整条流程，而是用确定性映射处理稳定数据，用 AI 准备有依据的候选，用人承担商业判断，再由受控系统执行和记录。

现有证据只支持建设一个边界清楚的最小方案。进入系统建设前，第 6A 章还要把流程中的触发、输入、判断、人审、异常和责任写成可检查的约束。没有这一步，工程团队仍需从流程图中猜测业务边界。

下一章：从 SOP 到智能体约束

本章来源与框架边界 ​

现状流程字段、逐动作权限判断、五分钟演示结构和“目标流程是否值得建设”的决定是本书的教学整理，不代表上述机构发布的统一标准。澄川案例中的人物、时间、流程、反馈和评审结论均为教学设定，不代表真实企业结果。