AI Native Builder

主题

第 5 章｜从工具愿望到可验证场景 ​

前四章为了说明角色责任，提前展示了澄川项目的部署、交接和一次运行事故。从这一章开始，我们把时间拨回立项当天，沿着 AI Native Builder 的项目过程重新走一遍。

销售经理在会上提出：“我们应该做一个销售 Agent。它能自动整理会议、填 CRM、提醒下一步，最好还能直接写跟进邮件。”这句话听起来目标明确，项目组甚至能立刻列出功能。

会议纪要里还写了三个数字：团队有 12 名销售，每周大约开 35 场客户会议，每次会后整理约需 45 分钟。按这个估算，自动化似乎可以节省大量时间。

问题是，三个数字都来自经理的经验。没人说明 35 场是否包括内部会议，45 分钟从哪个动作开始计算，也没人确认销售真正卡在整理、查资料、跨系统复制，还是等待售前答复。

如果项目组当天开始做原型，后续所有设计都会建立在未经检查的叙述上。模型可能把纪要写得很快，却没有改变最费时间的步骤；CRM 字段可能更完整，行动项仍会因为没有负责人而逾期。

本章要完成的工作，是把“做一个销售 Agent”改写成一个值得进入流程设计的问题。你会看到项目组怎样收集证据、比较候选场景、建立临时基线、排除不用 AI 的方案，并写出一份完整的问题一页纸。

工具名称藏住了什么 ​

“知识库”“智能客服”“会议助手”“销售 Agent”都在描述一种可能的方案。它们没有告诉我们谁在何时遇到什么困难，也没有说明困难造成了什么影响。

当团队围绕方案名称讨论，问题会被工具能力牵着走。有人讨论选哪个模型，有人讨论要不要做 RAG，有人展示语音转写。用户、任务、基线和责任人反而留在会后再补。

Builder 需要先把名词改写成事件。一个可调查的场景应当包含：具体角色、触发事件、当前任务、可观察现象、业务影响、现有处理方式和风险边界。

澄川最初的“销售 Agent”，可以先改成：

销售完成一次客户会议后，需要核对客户需求、查找当前产品依据、更新 CRM 并安排下一步。项目组尚未确认各步骤的耗时、错误和等待分布，也不知道哪些问题来自信息处理，哪些来自流程责任。第一轮场景发现要找出其中可验证、可试点且风险可控的任务。

这段表述没有承诺使用 Agent。它也没有把 45 分钟写成事实。方案被暂时拿掉以后，团队才能比较 AI、规则、表单、系统集成和流程调整。

场景发现（discovery）要回答哪些问题 ​

场景发现不是一次宽泛的“需求访谈”。它要支持一个具体决定：这个问题是否存在，是否值得现在处理，是否适合用 AI，是否具备进入工作流设计的条件。

GOV.UK Service Manual 的 discovery 用户研究指南建议团队了解用户是谁、他们试图完成什么、当前怎样完成，以及过程中遇到什么障碍。指南同时建议使用观察、访谈、现有数据、后台流程和支持记录，而不是只依赖一种材料。

OpenAI 的企业 AI 场景指南提出先收集候选场景，再用影响和投入等维度排序。它还把重复任务、技能瓶颈和需要处理模糊信息的工作列为常见机会来源。

这些资料提供的是调查方向，不会自动选出澄川该做什么。项目组仍要回答四组本地问题。

第一组关于任务：谁在做，什么事件触发，任务从哪里开始，到什么状态才算结束？第二组关于现象：操作、等待、返工和错误分别发生在哪里？

第三组关于影响：这些现象是否影响时间、质量、收入、客户体验或风险？第四组关于可改变性：普通规则能否处理，AI 需要什么数据，出错能否被发现，谁愿意为试点提供资源并承担结果责任？

问题越靠近一次具体任务，证据越容易取得。问“销售效率是否需要提升”，得到的通常是态度。问“最近一次客户会后，你打开了哪些系统，在哪里等待，最后怎样确认记录完成”，得到的才可能是流程事实。

带着可被推翻的假设进入现场 ​

Builder 不需要假装毫无预设。完全空白的访谈容易变成漫谈。更有效的做法是把现有认识写成假设，同时标明什么证据会支持或反驳它。

澄川项目组先写下三条：会后整理普遍需要约 45 分钟；主要负担是撰写会议摘要；CRM 字段遗漏导致后续行动逾期。每条后面都加了“来源：销售经理估计，待验证”。

然后，项目组为每条假设安排材料。耗时问题需要观察实际任务并区分操作时间与等待时间；摘要负担需要看销售怎样分配时间；逾期原因要把 CRM 记录、任务负责人和后续状态放在一起检查。

证据计划还要写明权限。会议内容涉及客户信息，不能因为处于场景发现阶段就随意复制。澄川只允许观察已获同意的任务，记录脱敏后的步骤和时间，不把原始客户内容带出授权环境。

这一做法保护用户，也提高证据质量。研究对象知道哪些内容会被记录、用于什么决定；项目组也会先确认使用权限，再收集数据，不会等到大量数据已经堆积，才回头讨论是否有权使用。

一次调查怎样推翻最初叙述 ​

以下记录继续属于教学材料。样本规模和日期只服务于方法演示，不能当作企业项目的通用研究标准。

项目组先跟随 4 名销售观察了 8 次会后处理。8 次任务从会议结束到销售认为“可以离开”之间，耗时从 24 分钟到 61 分钟不等。这个范围说明 45 分钟并非毫无根据，但小样本还不足以成为稳定基线。

更有用的是时间去向。销售通常很快就能整理出摘要。较长任务多花在核对产品限制、寻找最新版资料、等待售前确认，以及把同一信息改写后填进不同字段。

一名销售甚至没有重写摘要。他把转写工具生成的内容放在一边，直接从自己的手写笔记提取行动项。若项目只优化摘要，技术指标可能提高，用户仍然不会改变工作方式。

项目组又抽查了 30 条历史会后记录。其中 9 条缺少明确的下一步负责人或日期，但这 9 条并不都来自字段遗漏。有 4 条已经写明任务，只是依赖内部报价审批；另有 2 条因为客户没有给出时间而保持开放。

这次抽查改变了第三条假设。行动项逾期不能全部归因于记录不完整。资源等待、审批和客户不确定性同样会产生逾期。一个自动提醒工具可以提高可见性，却不会消除这些原因。

访谈也暴露了角色差异。销售经理关心团队能否看见下一步，销售关心查资料和重复录入，销售运营关心字段口径，IT 则担心项目把新的写入逻辑直接接到正式 CRM。

没有哪个角色在说谎。他们看到的是任务的不同部分。Builder 的工作是把这些叙述放回同一条流程，用观察、样本和系统记录判断它们各自支持什么，不能支持什么。

证据不是一堆附件 ​

调查结束后，项目组容易掉进另一个陷阱：访谈纪要、截图和表格越来越多，决定却没有变清楚。证据只有进入判断，才对项目有用。

澄川用一份证据日志区分五种记录。

“8 次观察的会后处理耗时为 24—61 分钟”属于事实，因为可以回到观察记录。“销售觉得找资料最烦”属于一线用户判断。“接入产品资料检索会降低净人工负担”仍是假设，需要后续验证。

“第一轮不自动发送客户邮件”属于决定，要有作出决定的人和日期。“尚未取得会议类型在整支团队中的分布”属于缺口，它限制了现有样本可以代表的范围。

这种分类防止表述在层层传递中被夸大。一个人的感受不会因为进入汇报页就变成团队事实，一次小样本观察也不会被写成已经证明长期收益。

中心结论最好由不同类型的证据交叉支持。访谈可以解释用户为什么绕开流程，观察可以确认绕开是否发生，系统记录则帮助估计发生频率。三种材料对不上时，往往意味着还有没看到的环节，值得追下去。

先建立候选池，再谈优先级 ​

澄川的调查没有只产生一个需求。项目组看到至少四个候选场景：会议摘要、产品资料核对、CRM 更新准备，以及对外跟进邮件。

如果直接做经理最先提出的完整 Agent，四个场景会被捆成一次大交付。失败后，团队很难判断是摘要价值不足、资料不可靠、CRM 集成复杂，还是外发风险太高。

候选池把它们拆开比较。比较维度包括业务影响、发生频率、现有证据、数据可得性、边界、试点速度、错误后果和负责人。1—5 分可以帮助讨论，但小数点不会把弱证据变强。

澄川的第一次比较如下：

候选场景现场证据预期影响首轮难点决定
自动生成完整会议摘要已有工具可生成，用户未把摘要视为主要负担可能节省少量整理时间价值证据弱暂不优先
检索当前产品资料并显示依据8 次观察中较长任务常出现查找或确认减少查找与错误引用资料版本和权限保留候选
准备 CRM 更新预览重复录入和字段口径差异可观察降低录入负担并改善记录字段语义、人审和写入边界首个试点范围
自动发送跟进邮件经理有兴趣，缺少用户和风险证据可能缩短发送时间对外承诺、责任和不可逆影响本阶段排除

表格没有证明 CRM 预览一定成功。它只解释为什么这项任务比另外三项更适合作为第一轮验证：问题可观察，输入输出相对清楚，可以先停在预览，错误仍由销售在提交前发现。

高价值、高风险、低证据的场景不应自动排在最前。第一个试点更需要快速获得可信反馈。先挑一个范围小、边界清楚的场景动手，哪些假设有问题很快就能暴露出来。

在选择 AI 前做一次反 AI 检查 ​

候选场景进入排序，不表示它必须使用 AI。Builder 应当主动比较更便宜、更稳定的处理方式。

澄川的“遗漏下一步负责人”可以先靠 CRM 必填规则解决。如果字段结构清楚，普通校验比模型判断更可靠。“同一客户信息重复录入”可能需要系统集成，不需要语言模型参与。

“产品资料难找”也不必立刻做 Agent。团队可以先清理过期资料，指定权威来源并改善搜索。若资料本身冲突，接入 RAG 只会让冲突更快出现在答案里。

AI 更适合介入的部分，是从非结构化会议记录中提取候选事实，结合当前资料生成有依据的字段建议，并把不确定项交给销售判断。即使在这里，字段校验、权限控制和写入仍应由确定性系统处理。

你可以用四个问题做快速检查：删除这个步骤能否解决；标准化输入能否解决；规则、表单、搜索或系统集成能否解决；问题是否来自权限、激励、资源或管理。

如果其中一个替代方案已经够用，直接选它，Builder 的价值不会因此打折。拦下一个不该做的 AI 项目，省下来的资源本身就是建设成果。

基线要说明自己看见了多大范围 ​

“每次 45 分钟”缺少时间窗口、样本和口径，不能直接用于计算收益。基线要让后来的人知道数字从哪里来，也知道它没有覆盖什么。

澄川把第一轮记录称为“临时基线 v0.1”。它只覆盖 4 名愿意配合的销售和 8 次任务，观察窗口为 3 个工作日。耗时从会议结束开始，到销售完成内部记录为止；等待售前回复单独记录，不混入纯操作时间。

质量基线来自 30 条历史记录，由销售运营按当时有效的字段规则复核。9 条缺少负责人或日期，只能说明这批样本存在记录问题，不能说明整个团队的长期缺失率。

风险基线则记录了资料版本冲突、客户敏感信息和可能形成对外承诺的字段。项目组没有用“当前没有事故”推导出风险很低，因为现有流程主要由人判断，未来系统的动作范围尚未确定。

临时基线可以支持范围选择，却不一定足以支持收益承诺。澄川因此把扩大样本写成进入试点前的待办，而不是把小样本比例写进立项收益。

一份可用基线至少要带上指标定义、来源、时间窗口、样本范围、记录人和限制。数字不完整时可以写“待测”。编造精确数字会让后续评估拥有一个漂亮却错误的起点。

从证据写出问题一页纸 ​

问题一页纸不是项目宣传，也不是把所有材料压成一张表。它要让下一章的流程设计者知道：当前任务怎样发生，哪些判断已有证据，准备改变哪一段工作，哪些事情明确不做。

下面是澄川在第一次评审前形成的 v0.2。所有内容仍是教学示范。

澄川客户会后记录：问题一页纸 v0.2 ​

角色与触发。 目标用户为一线销售。一次外部客户会议结束后，销售需要核对客户需求和产品依据，更新 CRM，并安排内部下一步。销售经理与销售运营是结果和字段规则的共同负责人。

当前现象。 8 次现场观察的端到端处理耗时为 24—61 分钟。较长任务常出现查找产品资料、等待售前确认和重复录入。30 条历史记录中有 9 条缺少负责人或日期，但部分逾期来自审批或客户时间不确定。

证据边界。 观察只覆盖 4 名自愿参与者和 3 个工作日，历史样本也未按会议类型分层。现有材料能证明问题存在，不能代表全年水平，也不能直接支持节省时间的承诺。

首个试点范围。 系统从已授权的会议记录中准备 CRM 字段建议，区分客户原话、销售判断和建议动作，并显示当前产品资料的来源与版本。销售检查后决定是否提交。

期望结果。 第一轮验证关注净人工处理时间、关键字段完整性、销售修改原因和放弃情况。目标值要在扩展基线后由销售负责人确认，不以“生成速度”代替任务结果。

不用 AI 的部分。 参会人和客户编号由现有系统提供；必填字段、字段类型和权限使用规则校验；资料版本治理先由内容负责人处理。

本阶段不做。 不自动发送客户邮件，不自动修改价格、预计成交日期或正式商机阶段，不把未核验的经理估计写成业务收益。

风险与停止条件。 未授权读取客户内容、引用失效资料、未经销售确认写入正式 CRM 或生成对外承诺，都会触发暂停和事件处理。工具写入仍留在沙盒，直到后续章节完成状态、权限和恢复设计。

核心假设。 若系统能把非结构化会议内容转成有来源、可检查的 CRM 更新预览，销售的净人工负担会下降，关键记录也会更完整。该判断仍需通过目标流程演示和小范围试点验证。

待补证据。 项目组还需扩展会议类型和用户样本，区分操作时间与外部等待，确认资料负责人和 CRM 字段规则，并记录拒绝或绕开新流程的用户。

这份一页纸没有把解决方案藏起来：问题定义阶段暂时拿掉的方案，在这里以受证据约束的试点范围的形式回来了。它还保留了替代解释和待补材料，下一位参与者不会把 v0.2 误读成最终需求。

这个问题值得继续吗 ​

完成问题调查后，团队需要判断现有证据是否足以支持继续设计流程。这是一次阶段决定，不是行业统一标准，也不是对商业成功的保证。

团队可以决定继续、有条件继续、返工、暂停或终止。继续表示现有证据足以进入下一阶段；有条件继续允许团队画目标流程，但必须在约定的决定节点前补齐关键缺口。

返工适用于问题可能存在，但用户、流程、基线或边界仍过于模糊。暂停通常来自授权、数据或负责人缺失。终止则意味着当前问题不值得做、风险无法控制，或者普通流程改动已经足够。

澄川得到的是“有条件继续”。评审同意先设计 CRM 更新预览，不同意自动发信，也不接受用 45 分钟估计承诺收益。进入小范围真实试点前，项目组必须扩大基线、确认资料和字段负责人，并完成权限审查。

这个决定把不确定性留在明面上。项目组可以学习目标流程，不必假装所有数字已经稳定；管理者也知道哪些证据缺口会阻止下一次扩大范围。

停止或改用普通自动化同样是有效成果。Builder 对建设结果负责，不需要用一个 AI 原型证明自己做过工作。

常见失败为什么会发生 ​

只访谈经理，会把管理视角当成用户事实。经理擅长说明目标和资源，不一定知道销售每天如何绕过系统。只访谈最热心的销售也有问题，他可能比多数同事更愿意尝试新工具。

只看平均值，会把不同任务混在一起。一次简单续约会和一次复杂技术方案会的会后处理差异很大。基线至少要保留任务类型和范围，避免一个平均数遮住真正适合试点的任务范围。

先承诺系统形态，会让调查围绕既定方案搜集支持材料。团队问“你愿不愿意用会议 Agent”，通常只得到态度；观察最近一次任务，才可能发现摘要根本不是主要负担。

只按高价值排序，会选中影响很大却无法在当前条件下验证的项目。没有数据、负责人或可恢复路径时，高价值只会放大交付风险。

最后一种失败是把一页纸写成结论汇报。它列出明确数字，却不说明来源和限制；写了成功目标，却没有替代解释和停止条件。这样的文档方便批准，也最容易在后续阶段制造错误确定性。

把方法迁移到自己的场景 ​

假设财务负责人说：“做一个发票审核 Agent，减少月末工作量。”一个较弱的问题定义会写成：

财务每月需要审核大量发票，效率较低。项目使用 AI 自动审核，提高效率和准确率。

它没有用户、触发、当前步骤、证据、风险和负责人。“大量”“较低”“提高”都无法验证，自动审核也提前承诺了动作权限。

一个合格的起点可以写成：

应付会计在月末收到发票与采购记录后，需要核对主体、金额、订单和异常原因。当前任务量、处理时间和异常分布均待测。场景发现阶段将观察实际审核、抽查历史样本并核对系统记录，判断规则校验能解决哪些问题，AI 是否只适合解释非结构化异常。付款批准不在范围内，财务负责人决定是否进入试点。

第二个版本没有凭空补数字，也没有保证 AI 一定适合。它已经告诉调查者要看什么、怎样比较替代方案，以及哪项高风险动作不进入范围。

你的练习 ​

从自己的工作里收集至少三个候选场景。每个场景先写成“角色—触发—当前任务—可观察问题”，再记录业务影响、证据、数据条件、风险、负责人和不用 AI 的替代方案。

选择一个候选，至少使用两类证据。可以组合访谈与观察、样本与系统记录，或其他能相互校验的材料。若只能使用虚构案例，在文档顶部标明“教学模拟”，不要声称获得了真实授权或基线。

然后完成一份问题一页纸，并决定这个问题是否值得进入流程设计。你可以直接使用练习册中的场景机会池、证据日志和问题一页纸：机会池用于比较，证据日志用于区分事实与假设，一页纸负责把决定交给下一阶段。

怎样判断答案是否合格 ​

先把方案名称删掉。如果删掉“Agent”“知识库”或“助手”后，你仍能说清用户、任务、现象和影响，问题才有独立存在的可能。

再检查中心判断能否回到证据。至少一项证据应来自真实行为、样本或系统记录；只有访谈态度时，应把结论降为待验证假设。

基线必须写明定义、来源、窗口、样本和限制。没有数字可以写待测，不能用行业数字替代本地基线。候选选择还要出现一个被排除的 AI 方案和排除理由。

最后看责任和停止条件。谁确认业务结果，谁提供数据或系统边界，出现什么情况暂停，都要能找到具体角色。只写“项目组负责”还不够。

本章小结：下一章需要什么输入 ​

场景发现把工具愿望改写成了一份可以被反驳的问题契约。澄川没有得到“销售 Agent 值得建设”的结论，只确认了一个更小的候选：为客户会后的 CRM 更新准备有依据、可检查的预览。

第 6 章将使用这份一页纸和现场记录，画出真实现状流程。我们会继续追问：哪些步骤应该删除，哪些交给规则或 AI，哪些决定必须由人承担，以及异常发生时流程怎样停止和回退。

下一章：重构人—AI—系统工作流

本章来源与框架边界 ​

证据日志、临时基线、问题一页纸和“是否继续”的决定是本书的教学整理。澄川案例中的人物、数字、观察与评审结果均为教学设定，不代表外部机构的标准或真实企业收益。