大模型演示惊艳，上线却频频翻车？问题不在模型能力，而在产品设计。本文从任务拆解、幻觉控制到长上下文陷阱，教你如何将模型能力转化为稳定可靠的产品功能。

过去两年，我听得最多的一类需求是“能不能接个大模型”。客服希望它自动回复，设计部门希望它审图，运营希望它直接出方案，管理层则希望看到一个会查资料、会调用系统、还能自己推进任务的智能体。

这类需求很容易做出让人兴奋的演示。准备几份干净文档，选一个能力较强的模型，再配上一段经过反复打磨的提示词，十分钟就能看到颇像成果的回答。它能解释术语，也能整理表格，还能给出下一步建议。会议室里的第一反应通常很一致，既然回答已经这么像专家，离上线应该不远了。

真正的产品工作从这一刻才开始。

把同一个功能交给真实用户，输入会立刻变脏。半句话、旧版制度、写错的零件名称都可能进入系统，一个问题里还可能混着三个目标。模型可能引用过期条款，也可能补出原文里没有的参数。接上工具以后，风险又多了一层。一次不准确的回答还可以修改，一次错误写库、误发邮件或误停设备，后果很难靠一句“模型会犯错”带过。

因此，讨论大模型的能力边界，价值并不在于列出一张“能做”和“不能做”的清单。模型版本在变，价格在变，评测榜单也在变。产品经理需要找到更稳定的判断方法，把每一项能力落到具体任务、输入条件、验证手段和责任人上。只有这样，模型升级时产品不会推倒重来，业务提出新需求时团队也知道边界该往哪里移动。

演示为什么总比上线顺利

大模型最容易制造的一种错觉，是把表达质量当成任务完成度。

它擅长处理语言中的模糊。用户说“帮我把这段话写得专业一点”，模型不需要一套精确规则也能给出不错的版本。用户上传一份会议纪要，它可以快速提取议题、行动项和争议点。需求越依赖语言理解、归纳和改写，它越容易在第一次展示中显出优势。

问题出在展示环境里，大量困难被提前拿掉了。演示所用文档往往完整、清晰、版本唯一，提问方式也经过设计。团队知道正确答案大致长什么样，即使模型漏掉一处信息，也能当场补一句提示让它重来。真实业务没有这样的照顾。输入来源更多，规则彼此冲突，用户也不会按产品说明书发问。

以合同审查为例。演示时上传一份结构规范的采购合同，要求识别付款节点、违约责任和交付日期，模型通常能给出清楚的摘要。上线后，用户可能上传扫描件，附件里还有一份补充协议。正文写着到货后支付百分之七十，补充协议把比例改成百分之六十，邮件里又约定分批验收。此时任务已经从“读懂一份文本”变成了版本识别、证据排序、冲突检测和责任判断。

模型仍然可以生成一段流畅结论，但流畅只说明它找到了合理的语言序列。合同团队真正需要的是每个结论能定位到原文，冲突能够被标出，缺失信息明确进入待确认状态。两者的差距，正是从能力展示走向产品交付的距离。

产品经理在演示阶段就该追问几个不太讨喜的问题。换一份格式混乱的材料还能不能完成，去掉关键字段以后会不会主动停下，知识库里出现相互矛盾的版本会选哪一份，答案错误时谁能在业务动作发生前发现。能够把这些问题讲清楚，演示才开始具备产品意义。

能力边界要落到任务颗粒度

“这个模型能不能做机械设计”几乎无法直接回答。机械设计包含需求澄清、方案比较、结构计算、标准件选型、三维建模、工程图生成、工艺评审和签字放行。不同环节对准确性、解释性和责任的要求差别很大。把它们合在一个问题里，答案只能变成笼统的可以或不可以。

更有效的做法，是把能力判断压到一个可观察的任务单元。比如从自然语言里提取轴径、长度、台阶位置和孔系参数，模型的作用是把口语整理成结构化字段。字段进入参数校验后，程序检查尺寸范围和依赖关系，再由确定性建模脚本生成几何体。模型可以参与需求理解，却不直接决定最终拓扑是否闭合，也不负责强度是否满足工况。

同样是“审图”，任务也要继续拆。识别标题栏、提取尺寸和公差、判断标注是否齐全、核对企业规则、解释风险、形成整改建议，这些步骤需要的能力并不相同。OCR负责把图上的字符转成文本，视觉模型辅助识别符号和区域，规则引擎核对明确条款，检索系统找到对应标准，大模型把证据和问题组织成人能读懂的说明。最终签审仍由具备资质的人完成。

这类拆法会让需求文档少一些想象力，却会让研发、测试和业务拥有同一把尺子。团队可以分别测量字段抽取准确率、规则命中率、证据定位率和高风险问题召回率。出现错误时，也能知道它发生在识别、检索、推理还是生成环节。

产品经理需要同时看三个边界。模型边界描述单次调用能稳定完成什么，系统边界说明模型周围有哪些检索、规则、工具和权限控制，业务边界则规定结果能影响到哪一步。很多争论源于大家讨论的层次不同。算法同学说模型已经能识别，业务负责人问的却是能否据此放行一张图纸。

一个朴素的判断方法是看闭环。先确认输入和输出能否被定义、被检查，再看错误拦截与动作撤销有没有着落。这里任何一处含糊，都不宜把任务整段交给模型。

幻觉首先是一份产品契约

模型产生错误事实时，团队常把注意力集中到提示词和模型版本上。换更大的模型、增加检索、要求逐步思考，确实可能降低错误率，却很难把错误清零。OpenAI在二〇二五年发布的研究指出，常见训练和评测方式会奖励猜测。面对不确定问题，给出一个答案还有机会得分，直接承认不知道往往拿不到分。这样的激励会留下过度作答的倾向。

这条结论对产品设计的提醒很直接。系统不能只定义“答对了是什么样”，还要定义“证据不足时该怎样结束”。

很多产品只有成功态和失败态。模型返回文字就算成功，接口报错才算失败。业务真实需要的状态至少还包括信息不足、来源冲突、权限不足和需要复核。它们不是报错，更接近一种受控暂停。系统知道自己缺了什么，并把缺口交还给用户或专业人员。

例如，用户问某台水泵为什么振动升高。知识库里只有常见故障案例，没有这台设备最近的振动频谱、轴承温度和维修记录。模型可以列出联轴器不对中、轴承磨损、气蚀等可能性，但产品界面不能把其中一项包装成确诊。合理的输出应当先列已知证据，再提示需要补采的数据，最后给出低风险检查顺序。涉及停机、拆检和电气操作时，流程进入人工确认。

置信度也需要谨慎。把模型自己生成的百分比直接展示给用户，看起来精确，实际很可能没有经过校准。一个写着百分之九十二的结论，并不会因此拥有百分之九十二的正确概率。更稳妥的置信信号来自可测量环节，比如检索相似度、关键字段完整率、多个证据是否一致、规则是否全部通过，以及同类样本在离线评测中的表现。

产品契约里还要写清错误成本。营销文案出现一个不够贴切的形容词，编辑几秒就能改掉。维修建议漏掉高风险故障，可能让设备继续带病运行。两个任务即便拥有相同准确率，也不该使用同一套发布策略。前者可以默认生成并允许人修改，后者需要来源、风险提示和明确的升级路径。

当团队把拒答率、澄清率和人工升级率纳入核心指标，模型才有机会学会“停”。只盯回答率和自动化率，产品会持续鼓励它在信息不足时补全故事。

长上下文不等于真正理解了资料

上下文窗口越来越长以后，很多团队倾向于把整套制度、几十份报告甚至完整代码库一次性塞给模型。直觉上，材料都在输入里，模型就应该都看到了。

“能放进去”和“能稳定使用”之间仍有差距。《Lost in the Middle》研究在多文档问答和键值检索任务中观察到，关键信息位于长上下文中部时，模型表现会明显下降，相关信息放在开头或结尾时更容易被使用。新模型持续改进长文本能力，这个现象提醒产品团队，窗口长度只是容量指标，不能代替任务评测。

在企业知识库里，错误通常沿着一条更长的链路发生。文档可能没有及时入库，解析时表格结构被打散，切片把适用条件和结论分开，召回结果混入旧版本，重排阶段又把真正相关的段落放在后面。最终生成看起来像模型幻觉，根因也许早在检索之前就出现了。

因此，RAG的价值在于为回答提供可更新、可追溯的外部证据。它无法天然保证答案正确，也不能替代权限和版本治理。知识库里放入一百份错误文件，只会让系统更有根据地犯错。

一套能上线的知识流程，首先要回答资料从哪里来。标准、工艺文件、设备台账、维修记录和历史案例拥有不同责任人，更新频率也不同。其次要记录生效日期、适用设备、所属车间、版本状态和保密等级。检索时除了语义相似度，还应加入关键词、元数据过滤和版本优先级。生成阶段只使用达到阈值的证据，并把引用位置回传到界面。

机械工程场景尤其需要保留结构。一个尺寸数字离开视图、基准、公差带和技术要求后，意义可能完全改变。把整张图纸简单转成一串文本，再用向量相似度查找，容易丢掉空间关系。更可靠的方案会并行保留图纸页码、区域坐标、对象类型和相互引用。大模型负责解释，证据层负责让解释有出处。

长上下文适合临时提供任务材料，RAG适合管理经常更新的知识，两者都需要评测。产品经理应准备一批位置被打乱、版本相互冲突、答案确实不存在的样本。系统能否找到正确证据固然重要，找不到时能否明确停下同样重要。

Memory要像产品状态一样治理

当对话轮次变多，用户很快会提出另一个期待，希望AI记住自己。于是产品把历史消息拼进上下文，或者把对话摘要存进向量库，下次提问时再取出来。短期体验可能更连贯，新的问题也随之出现。

聊天记录里既有长期偏好，也有只对当次任务有效的临时信息。用户上周说“这个项目预算控制在二十万元”，并不代表今后的所有项目都使用同一预算。工程师在故障排查时提出的猜测，也不能在下一次检索中变成已经确认的设备事实。若系统不区分信息类型，Memory会把过去的不确定判断重新包装成今天的上下文。

产品层的记忆至少需要区分会话状态、用户偏好、业务事实和操作记录。会话状态帮助任务连续推进，完成后可以失效。用户偏好可以跨会话保留，但应允许用户查看、修改和删除。业务事实必须绑定来源、对象、版本和确认人。操作记录用于审计，不能被模型随意改写。

以水厂设备问诊为例，“用户习惯先看振动趋势”可以作为界面偏好；“二号送水泵上月更换轴承”属于设备履历，需要从维修工单读取；“可能存在气蚀”只是某次诊断中的候选原因。三句话都可能出现在对话里，持久化策略却完全不同。

记忆召回也要经过权限过滤。班组成员能看到本班次工单，不代表能访问其他厂区的设备数据。员工离岗、项目结束或授权变化后，旧记忆应随权限收回。敏感字段还需要设置保存期限，防止系统为了“更懂用户”长期积累不必要的信息。

一个可靠的Memory功能，会让用户知道系统记住了什么，也能解释本次回答使用了哪条历史信息。模型生成的摘要可以帮助压缩内容，真正写入长期记忆前应经过字段校验，关键事实还要由业务系统确认。记忆越接近组织资产，治理要求就越接近数据库，不能只按聊天体验来设计。

工具让模型能做事，也让错误有了后果

聊天产品里的错误大多停留在屏幕上。Agent接入邮件、数据库、工单、浏览器或生产系统后，输出会变成动作。能力提升很明显，责任面也随之扩大。

一个采购助手可以读取供应商报价、比较交付周期、生成询价邮件。如果它只有读取权限，最坏结果可能是一份错误摘要。获得发送邮件权限后，它可能把内部底价带给外部联系人。继续开放下单接口，错误就会进入真实交易。模型本身没有发生变化，产品风险已经完全不同。

OpenAI对提示注入的说明里举过类似风险。Agent读取网页或邮件时，外部内容可能藏有诱导指令，让模型偏离用户原本的任务。简单关键词过滤很难覆盖所有情况，因为攻击内容可以写得像正常业务文本。防护重点需要落在来源和动作的连接处。哪些内容属于不可信输入，哪些工具能够产生敏感后果，二者相遇时应当触发怎样的限制。

工具设计最好从最小权限开始。查询库存与修改库存分成两个接口，生成邮件与发送邮件分成两步，草拟维修工单与下发停机指令也不能共用一个按钮。高风险动作在执行前展示对象、参数和影响范围，交由用户确认。确认页面要让人看得懂，不能只显示一段原始JSON。

可撤销性是另一个常被忽略的边界。添加草稿可以撤销，转账和删除生产数据很难恢复。产品团队可以按读操作、可逆写操作和不可逆写操作分级，再配置不同的确认、审批和审计要求。同一个Agent无需拥有所有工具，任务结束后也不必继续保留临时权限。

Agent loop同样需要硬限制。模型提出计划，调用工具，读取结果，再决定下一步，这个循环赋予系统连续行动能力。循环并不会自动带来更好的判断。工具返回异常、网页结构变化或模型误读状态时，它可能在错误方向上继续尝试。每一次尝试看起来都合理，累计结果却逐渐偏离目标。

所以循环要有步数上限、预算上限、超时、重复检测和终止条件。涉及外部写入时还要考虑幂等，避免重试造成重复下单或重复建单。日志中既要保存最终答案，也要保留模型看到了什么、选了哪个工具、传了哪些参数、系统返回了什么。缺少这些过程信息，线上问题很难复现。

对Agent产品而言，“完成任务率”只能描述结果的一部分。越权调用率、错误动作拦截率、人工确认后的取消率、单任务平均步骤数和失败恢复时间，更能反映系统是否可控。

多Agent解决分工，解决不了确定性

单个模型难以完成复杂任务时，常见方案是拆成多个Agent。一个做规划，一个查资料，一个执行，一个复核。分工能减少单次上下文的负担，也能让流程更容易观测。在跨文件编码、研究整理和方案生成中，这种结构很有用。

但多个Agent仍可能共享同一类盲点。规划Agent误解需求后，后续角色会沿着错误目标认真工作。检索Agent召回了旧标准，写作Agent会把旧标准组织得更顺，复核Agent如果依赖同一份证据，也可能给出通过结论。角色数量增加，只代表多了几个处理节点。

多Agent还会放大误差传播和成本。上游输出通常成为下游输入，前一步丢失的条件很难自动回来。每个角色都拥有自由生成空间时，系统状态会越来越难定义。问题发生后，团队要判断是规划、路由、工具、记忆还是复核出了偏差，排查成本会迅速上升。

更稳的做法是让生成能力与确定性组件配合。以自然语言生成机械零件为例，模型可以把“做一根中间粗、两端装轴承的阶梯轴”转成参数草案，并主动询问载荷、配合和加工约束。进入建模环节后，尺寸依赖、草图约束、布尔运算和拓扑检查应由可执行程序处理。生成完成后，再由几何检查、规则校验和测试用例判断是否通过。模型参与理解和解释，程序负责可重复执行。

审图场景也一样。文字和符号识别交给OCR与视觉模型，尺寸链、公差组合、材料牌号和标准条款由结构化规则核对。大模型适合把问题说明成工程师容易处理的整改意见，也适合把用户追问映射到对应证据。涉及强制性规范、计算校核和最终放行时，必须由规则结果与专业人员签审承接。

上海市经济和信息化委员会公开的一则工业设计案例显示，上海核工院借助大模型对设计文档进行智能审查，已检查十七万份设计文件。这个数字说明大模型能够进入规模化工程流程，也提示我们注意表述里的“智能审查”。工程产品的价值通常来自模型、企业数据、审查规则和人员流程的组合，单独一轮生成无法覆盖整条责任链。

专家系统在这里仍然重要。它的规则维护成本高，覆盖新情况的速度也有限，却能对已经明确的条件给出一致结果。某材料在特定温度下是否允许使用，某公差组合是否违反企业标准，某报警达到哪个等级必须停机，这些判断需要清晰来源、固定阈值和可追溯版本。大模型可以帮助工程师查询和解释规则，最终判定应由确定性逻辑承载。

一套成熟系统通常允许两种能力各自发挥长处。大模型处理表达差异、非结构化资料和交互，规则系统守住明确约束，传统算法完成计算与匹配，人工处理例外并承担授权。架构图看起来没有“一个模型包办全部”那么简洁，却更接近真实组织的工作方式。

产品经理要设计一条可退出的路径

不少AI功能把交互做成一个大输入框。用户可以问任何问题，系统也尽量回答。开放感很强，边界却被藏了起来。用户只有在得到错误结果后，才知道产品没有能力处理这件事。

边界清楚的产品，会在任务开始前收窄输入。机械零件生成可以先让用户选择零件类型、单位制和用途，再收集主要尺寸。合同审查可以要求选择合同类别和适用地区。设备问诊可以先确认设备编号、报警时间和当前运行状态。自然语言入口仍然保留，但关键条件要落入明确字段。

这样设计并非要压缩用户的表达空间。系统需要知道哪些信息已经获得，哪些仍然缺失。自由文本适合描述复杂背景，结构化字段适合做校验和流程控制。两种输入合在一起，比单独依赖提示词稳定得多。

输出也要拆层。用户先看到结果摘要，点开后能够核对文档名称、版本、页码或图纸区域。证据不足的地方单独标出不确定项和待确认条件。高风险任务还应提供人工升级入口，用户不必重新描述一遍问题，已有输入、检索证据和模型过程可以一并转交。

“转人工”不等于系统失败。它是产品预先设计的正常分支。资料冲突、低频异常、责任要求和不可逆操作，本来就需要不同处理方式。真正糟糕的体验，是系统一路给出肯定语气，直到最后一步才提示无法完成。

退出路径还包括失败恢复。Agent填写表单到一半遇到页面变化，系统可以保存已完成字段并告诉用户卡在哪里。检索没有找到有效证据，可以返回缺少的文档类型。规则引擎发现输入越界，应直接指出哪一个参数违反哪一条规则。错误信息越具体，用户越容易继续完成任务。

人工介入的时机最好由风险触发，不要简单规定“所有结果都要人工看一遍”。如果每个低风险摘要也必须审批，自动化价值会迅速消失。可以把影响范围、可逆性、证据完整度和异常程度组合起来。低风险且证据充分的任务自动完成，中风险任务抽样复核，高风险动作逐项确认。规则应随线上数据调整，但调整过程必须留痕。

评测要逼近真实流量

很多团队在上线前准备几十道标准问题，模型答对大部分，就宣布效果达标。这样的评测可以比较版本，却很难说明产品是否能承受真实使用。

真实评测集需要包含容易被忽略的输入。错别字、口语简称、扫描噪声、缺失附件、旧版规则、互相矛盾的来源、超长文档和答案不存在的问题都应该出现。还要加入高风险少数样本，因为整体准确率很容易被大量简单问题抬高。

以机械图纸审核为例，一百张图里九十张没有严重问题，系统全部判为通过，也能拿到百分之九十的表面准确率。对业务有意义的指标是高风险缺陷能召回多少，误报给工程师增加多少复核时间，证据能否定位，系统漏掉的问题属于哪一类。指标必须对应实际损失。

Golden set适合保存已经由专家确认、业务意义稳定的代表性样本。它不宜只收录成功案例，还要覆盖边界和失败。每次更换模型、修改提示词、调整切片或新增工具，都用同一批样本做回归，观察哪些能力上升，哪些任务退化。

离线评测之后，还可以用影子模式观察系统。AI读取真实输入并生成结果，但暂时不影响业务，团队把它与人工处理结果比较。影子模式能暴露数据分布、流程接口和异常类型，也能让业务人员提前形成预期。等关键指标稳定，再逐步开放低风险场景。

线上阶段要保留反馈闭环。用户点击“不准确”价值有限，因为团队仍不知道错在哪里。反馈选项可以细分为事实错误、证据不符、遗漏关键信息、表达难懂和建议不可执行。高价值错误进入复盘，补充到评测集或规则库。模型版本、知识版本和提示词版本需要同时记录，否则同一个问题可能无法重现。

评测也要计算成本。一次回答需要多少模型调用、多少检索、多少工具步骤，人工复核需要多久，失败后恢复需要多少操作，这些都会影响产品是否值得上线。一个准确率略高却成本高出数倍的方案，未必适合高频低价值任务。产品经理要把质量、时延、费用和人工工作量放在同一张账上。

发布门槛要写成业务能够执行的条件

能力边界如果只留在架构评审会上，很快会被交付压力冲淡。临近上线时，团队最容易用一句“先放出去看看”跳过尚未解决的问题。产品经理需要把边界转成发布条件，让业务、研发、测试和运营都能判断当前版本可以开放到哪里。

一项功能通常可以分成参考、辅助和执行三个等级。参考级只生成内容，用户自行决定是否采用。辅助级会读取业务数据并形成候选结果，关键字段需要人确认。执行级能够写入系统或触发外部动作，必须具备权限控制、参数校验、审计与回滚。等级变化意味着责任变化，不能因为同一个界面里多加了一个按钮就悄悄完成升级。

客服场景里，知识问答可以先以参考级上线，坐席看到答案和出处后再回复客户。等政策命中率、引用准确率和坐席采纳率稳定，再开放低风险问题的自动回复。退款承诺、价格变更和投诉定责仍然进入人工队列。每一步都有明确范围，业务也能看到自动化率提高带来的真实收益。

机械审图产品可以采用相似路径。最早版本只提取标题栏和技术要求，帮助工程师减少抄录。下一阶段标记缺失尺寸、疑似公差冲突和标准引用，并展示所在区域。经过足够样本验证后，系统可以自动通过部分低风险格式检查。涉及结构安全、材料替代和计算书一致性的结论，继续由专业人员签审。

发布条件应该包含反例。系统在常规样本上达到目标以后，还要经过缺字段、错版本、无答案、恶意输入和工具异常。高风险样本出现一次漏检，是否阻断发布，需要在测试前约定。否则同一个结果会在评审会上被不同角色解释。

运行保障也要进入门槛。模型服务不可用时产品怎样降级，知识库更新失败时是否继续使用旧版本，调用成本突增时是否限流，人工队列积压时是否缩小自动化范围。这些问题和模型效果同等现实。用户感受到的是完整服务，不会区分故障来自模型、向量库还是业务接口。

发布以后，边界仍要定期复查。业务规则会变，用户会找到新的使用方法，模型供应商也会更新版本。一次升级可能提升推理，同时改变拒答倾向或结构化输出表现。保留灰度、回归和快速回滚，团队才有资格把模型升级称为产品升级。

模型选型要服从风险和流程

模型选型会议很容易围绕榜单展开。参数更多、推理更强、上下文更长，看起来代表更高上限。但企业产品真正购买的是某个任务在既定成本下的稳定完成率。

同一产品可以使用多种模型。意图分类、关键词扩展和格式整理交给轻量模型，复杂规划和跨文档分析使用能力更强的模型，高风险结论再经过规则或人工复核。路由依据来自任务难度和风险，不能只看用户是否愿意等待。

选型测试应使用自己的样本，保留统一提示词和输出协议。除了正确率，还要观察结构化输出成功率、拒答表现、长文本稳定性、工具参数错误率、中文专业术语和重复调用的一致性。模型在公开榜单上的平均表现，很难替代垂直任务里的实测。

成本估算也不能只乘Token单价。完整成本包括检索与重排、模型重试、工具调用、日志存储、人工复核和异常处理。模型便宜但经常返工，业务成本可能更高。模型较贵却能让低风险任务一次通过，也可能更划算。

还有一个经常被忽视的变量是迁移成本。提示词里如果塞入大量模型特有习惯，工具协议又依赖某家接口细节，后续切换会很痛苦。把任务协议、字段定义、评测集和业务规则保留在模型之外，团队才能在新版本出现时快速验证，而不是重新猜一遍系统为什么有效。

真正值得产品经理负责的部分

大模型持续变强，很多今天需要工程兜底的任务，明天可能被模型直接完成。能力边界会移动，但责任边界不会跟着自动消失。企业仍然需要知道数据从哪里来，哪个动作由谁授权，错误如何发现，结果怎样追溯。

AI产品经理的价值，逐渐从“找到一个能回答的模型”转向“定义一套能交付的系统”。需求文档里要出现输入条件、证据要求、拒答规则、权限等级、人工节点和回归指标。交互稿里要画出信息不足、来源冲突和执行失败。上线计划里要包含影子模式、灰度范围和回滚方案。

这份工作没有演示那么耀眼，却决定了用户会把AI当成偶尔试用的新鲜功能，还是愿意放进每天的工作流。

当业务方再次提出“让模型直接做完”时，我更愿意先画出任务路径。图上要标明需要语言理解的环节、必须遵守的固定规则，以及可能产生不可逆后果的动作。验证与签字位置也要提前确定。模型放在它擅长的位置上，产品就能获得速度和弹性。边界写进流程以后，用户也不必靠运气判断这一次回答能不能信。

大模型的下一次升级当然值得期待。对正在做产品的人来说，更重要的进展发生在日常细节里。系统减少无根据的猜测，证据位置变得清楚，危险动作得到确认，人工接手时也能直接沿用已有信息。可交付的AI产品，就是在这些具体改动中慢慢长出来的。