作者 / 来源中智凯灵 / AiDD——从 PoC 到生产级智能体要决定的不是“能不能上线”而是“能不能放心放大”▼AI 项目容易在上线前变得含糊。Demo 跑通了业务方觉得方向不错项目组也已经投入了几轮迭代。这个时候如果直接问“要不要上线”答案往往会被会议气氛推着走既然看起来能用就先上小范围试试。但 AI 项目最危险的地方恰恰在于“看起来能用”和“可以进入真实业务”之间还有很长一段距离。一个智能体可能在演示样本上回答顺畅却在真实用户的长尾问题里频繁偏航一个研发 Agent 可能能生成代码却无法稳定通过测试、审查和发布流程一个知识库助手可能能读文档却无法判断哪份制度才是最新版本。所以企业 AI 项目上线前不应该只有一次“验收会”。它更需要一组清楚的Go/No-Go 门禁哪些条件满足才能放行哪些问题出现必须暂停哪些能力不足需要回炉哪些场景可以继续扩展。图 1AI 项目上线前的Go/No-Go 门禁不是单点审批而是一组从业务意图到持续运营的放行机制在第 9 届 AI研发数字峰会AiDD 2026 上海站和 FDE 深度工作坊中多场分享都指向同一个变化AI 项目的核心难题正在从“能不能做出来”转向“能不能稳定进入业务”。FDE 方法论也强调AI 项目需要小步快跑、快速验证并设置 Fail Fast 决策关口。Go/No-Go 的意义不是把项目一刀切成“成功”或“失败”而是帮助企业更早做出正确动作继续、暂停、缩小范围、补数据、补护栏、换场景或者进入下一阶段。▍第一道门业务意图是否已经被验证而不只是需求被实现AI 项目上线前第一道门不是技术门而是业务意图门。很多项目走到上线前团队已经实现了若干功能能问答、能总结、能调接口、能生成报告、能提交工单。但这些功能并不自动等于业务结果。企业真正要问的是这个 AI 能力到底要改变哪个业务场景要让谁少花时间、少犯错误、少等待或者更快做出决策兴云数科资深需求 AI 教练郑涛在《意图驱动交付Agent 时代从交付系统到交付价值的实践》中提出AI 时代的软件交付要从规格走向意图业务意图、解决方案意图和验证意图需要共同驱动 Agent 团队完成设计、实现与验证。这个判断放到上线前尤其关键如果项目只完成了功能规格却没有验证业务意图放行就会变成一次技术上线而不是一次业务能力上线。图 2郑涛《意图驱动交付Agent 时代从交付系统到交付价值的实践》意图与规范内建双向可追溯帮助上线前确认业务目标、约束和验收口径是否可验证PPT 第 19 页这道门的 Go 标准不是“需求列表都做完了”而是项目组、业务方和使用者能够共同说清三件事目标用户是谁核心业务结果是什么验收指标如何观察。如果只能回答“这个智能体可以回答问题”“这个 Agent 可以自动执行流程”但说不清它减少了哪类人工工作、降低了哪类风险、改善了哪类交付结果项目就应该 No-Go。不是因为它没有价值而是因为它还没有从技术能力变成业务能力。更现实的处理方式是回炉补意图重新定义场景边界收敛目标用户明确关键指标把“做了什么功能”改写成“解决了什么问题”。▍第二道门真实样本是否已经覆盖标准场景、高价值场景和异常场景第二道门是样本门。AI 项目在演示阶段经常使用干净样本字段完整、上下文清楚、用户表达标准、流程没有异常。这类样本适合展示能力却不适合判断能不能上线。真实业务里的输入通常更复杂历史数据缺失制度版本冲突用户描述模糊系统权限受限异常场景反而最能决定用户是否信任系统。FDE 深度工作坊在场景探索与 PoC 阶段强调PoC 不必一开始覆盖所有场景但必须聚焦核心逻辑并向用户、BA 或 AIBP 获取真实样本用来验证基本逻辑是否正确。这一点到了上线前要进一步升级项目不能只证明“典型 case 能跑通”还要证明“关键边界已经被看见”。图 3真实样本门至少要覆盖标准场景、高价值场景和异常边界场景这道门的 Go 标准是项目已经用三类样本做过验证。第一类是最高频的标准场景。它决定日常覆盖。第二类是业务方最关心的高价值场景。它决定项目是否值得继续投入。第三类是最容易出错的异常场景。它决定上线后会不会在关键时刻失控。如果一个 AI 项目只在标准样本上表现不错却没有碰过异常输入、权限冲突、口径不一致、知识缺失和用户追问就不应该直接上线。正确动作不是否定项目而是缩小上线范围把真实样本验证补齐。AI 项目上线前失败样本比漂亮样本更重要。漂亮样本告诉团队它能做什么失败样本告诉团队它不能做什么。▍第三道门数据和知识是否具备可追溯、可更新、可授权的形态第三道门是数据和知识门。很多 AI 项目上线风险不是模型能力不足而是上下文不可靠。企业资料散落在文档、表格、工单、代码仓库、会议纪要和老员工经验里。人可以靠经验判断哪份资料可信AI 只能使用系统提供给它的材料。材料一旦过期、冲突、缺失或越权输出就会跟着失真。腾讯 PCG 工程效能平台部刘琮玮在《AI 原生知识库及其实践与应用》中提到知识库正在从资料存储走向应用接口。知识从哪来、怎么处理、怎么用、如何持续提升质量都会影响大模型应用的实际成效。这意味着上线前不能只问“知识库有没有建好”而要问知识是否已经具备生产可用形态。图 4刘琮玮《AI 原生知识库及其实践与应用》知识库应用的新需求同时包含查询效果、个性化、安全性和可扩展性PPT 第 19 页这道门的 Go 标准至少包括四个条件。第一关键知识来源清楚。系统能说明答案来自哪份文档、哪条记录、哪个系统而不是只给出看起来合理的结论。第二版本和时效清楚。制度、价格、合同、产品规则、技术文档都有更新周期AI 必须知道该用哪一版。第三权限边界清楚。不同角色能看什么、不能看什么不能靠提示词约束。第四更新机制清楚。错误答案、缺失知识和过期材料要能回写到知识治理流程里。如果知识来源不可追溯、权限靠人工提醒、更新靠项目组临时维护项目就还没有准备好扩大使用。企业 AI 项目上线不是把资料喂给模型这么简单。真正上线的是一套知识使用机制能取数能解释能管权限也能随着业务变化继续更新。▍第四道门流程位置、工具权限和责任边界是否已经明确第四道门是流程和权限门。当 AI 只负责生成文本时风险主要是内容质量。一旦它开始调用工具、读取系统、修改数据、提交代码、创建工单、发起审批风险就变成了行动风险。这个时候AI 项目不再只是一个应用而是进入了企业流程。词元无限技术专家鲁奕志在《AI 驱动研发交付闭环释放组织级效能》中强调AI Coding 的价值不能停留在个人效率提升而要进入需求、方案、开发、测试等关键节点形成上下文流动、质量前置和过程可追踪的智能交付闭环。这个观点对所有企业 AI 项目都成立没有流程位置的 AI只是一个独立工具进入流程以后它才可能改变交付结果。图 5流程权限门要求 AI 的输入、动作、审核、回滚和责任边界都被定义清楚这道门的 Go 标准是每一个关键动作都有明确边界AI 接收什么输入调用哪些工具能执行到哪一步什么结果需要人工确认什么动作必须禁止谁对最终结果负责。例如销售助手可以生成客户沟通建议但能不能读取合同能不能自动更新 CRM能不能发出报价研发 Agent 可以提交代码建议但能不能直接合并能不能触发发布运维 Agent 可以分析日志但能不能自动执行修复脚本这些问题不提前说清上线后就会变成风险。权限设计的原则应该是最小权限、分级放行、关键动作留痕。低风险的信息整理可以自动完成中风险建议由人确认高风险的外部发送、资金、合约、生产变更和权限修改必须有人工门禁。如果项目组说不清“AI 可以做什么、不能做什么、谁来批准、失败后怎么回滚”就不应该 Go。它不是还差一个审批流程而是还差生产级系统最基本的责任边界。▍第五道门评估、观测和 Bad Case 回流是否已经形成闭环第五道门是质量护栏门。AI 项目最容易出现一种假象系统没有报错页面也能返回结果于是大家以为它是健康的。但 Agent 系统和传统软件不同它可能没有 500 错误也没有明显超时却已经偏离用户目标它可能每一步都执行成功最后结果却不符合业务判断。小红书资深工程师林能源在《从跑分到护栏AI Agent 可观测和质量保障体系》中指出Agent 落地的瓶颈正在从“能不能跑”转向“能不能评估”。传统软件靠单元测试和 CI/CD 保障质量Agent 则需要全链路观测、持续评估和决策治理。支付宝架构师高梦飞在《让智能体可观察、可评估、可进化》中也分享了类似实践智能体系统需要白盒化透视思考路径通过在线效果可观测、实时评测、自动归因和 Bad Case 修复形成质量闭环。图 6林能源《从跑分到护栏AI Agent 可观测和质量保障体系》离线评估与在线评估双轨并行通过灰度、CI 卡点和数据回流形成上线护栏PPT 第 29 页这道门的 Go 标准不是“人工体验还可以”而是项目已经具备三类能力。第一有上线前评估集。评估集里应该包含标准任务、高价值任务、边界任务和已知 Bad Case并且能反复回归。第二有上线后观测。系统要能看到任务成功率、人工接管率、错误类型、延迟、成本、用户反馈和链路状态。第三有回流机制。线上发现的问题不能只停在周报里而要进入知识更新、Prompt 调整、工具修复、权限规则或评估样本库。如果项目上线前没有评估集上线后没有观测指标失败后没有回流路径那就不是真正的生产级 AI 项目。它最多是一次可用性试验。质量护栏不是上线前最后补的一层测试。没有护栏的上线可能只是把风险更快交给用户。▍第六道门人工接管、降级和回滚机制是否可执行第六道门是兜底门。企业上线 AI 项目时经常会讨论准确率、响应速度和用户体验但更少追问一个问题当 AI 不确定、失败、超权、冲突或给出高风险建议时系统怎么办真实生产环境不会给项目组足够温柔的输入。用户会问模糊问题系统会遇到接口失败知识库会有缺失模型会出现幻觉工具调用会超时。没有接管和降级机制AI 的失败就会直接落到用户体验、业务损失或合规风险上。图 7人工接管门要求低置信度、高风险动作、异常失败和用户申诉都有明确兜底路径这道门的 Go 标准是兜底路径可执行而不只是文档里写了“必要时人工介入”。低置信度时系统要知道是追问用户、转人工、给出保守建议还是停止执行。高风险动作前系统要知道谁审批、审批记录在哪里、审批超时怎么办。工具调用失败时系统要知道是否重试、降级、排队或通知负责人。错误已经发生时系统要知道如何撤回、回滚、补偿和复盘。这类机制会让项目看起来“不够自动化”但它恰恰是企业愿意放行 AI 的前提。生产级 AI 不是永远不需要人而是知道什么时候必须把人拉回来。如果接管依赖项目组临时盯群降级依赖开发者临时改配置回滚依赖业务方自己发现问题项目就还没有准备好上线。▍第七道门运营责任、指标看板和复盘节奏是否已经准备好第七道门是运营门。很多企业把上线当成项目终点。但在 AI 项目里上线更像是进入真实学习环境的开始。模型会变业务规则会变用户使用方式会变知识库会变工具接口也会变。如果没有持续运营今天可用的智能体几周后就可能失准。FDE 深度工作坊把生产级智能体拆成场景探索与 PoC、迭代交付与用户试用、持续优化与可配置化、自主运营与持续监控四个阶段。最后一阶段的目标不是项目组继续事无巨细地维护而是让业务方具备自主运营能力FDE 转向监控和增量优化。图 8运营扩展门要求责任人、指标看板、复盘节奏和扩展决策同时到位这道门的 Go 标准是上线后至少有三类安排。第一有明确责任人。谁看业务效果谁看技术稳定性谁处理用户反馈谁决定下一轮优先级不能含糊。第二有指标看板。任务成功率、人工接管率、用户满意度、错误类型、成本、响应时间、知识命中率、Bad Case 修复率都应该有基本可见性。第三有复盘节奏。每周或每两周看什么问题每月是否扩展范围每季度是否调整模型、知识和流程都要有节奏。如果项目只有“上线发布计划”没有“上线后运营计划”就不应该进入大范围使用。因为 AI 能力不是一次性交付物而是需要被运营的业务能力。这也是 FDE 角色重新被讨论的原因。FDE 不是把系统做出来以后离场的人而是把业务意图、工程实现、评估反馈和持续运营组织起来的人。▍第八道门扩展范围是否经过分级而不是一次性全面铺开最后一道门是扩展门。AI 项目上线前企业经常会在两个极端之间摇摆要么过于保守一直停在小范围试用要么过于乐观一次性推给所有用户。更稳妥的方式是把上线设计成分级扩展而不是一次性放开。Go/No-Go 不应该只有一个结论。它至少应该有四种结果Go进入下一阶段Conditional Go带着限制上线No-Go暂停当前路径Pivot换场景、换目标或缩小范围。Conditional Go 在 AI 项目里尤其常见。比如只开放给内部专家用户只处理低风险场景只给建议不自动执行只读不写只在人工确认后进入下一步。这不是妥协而是把不确定性关进可控范围。扩展门的 Go 标准是项目已经定义清楚首批用户、场景边界、风险等级、放量节奏和退出条件。什么情况下扩大到更多团队什么情况下暂停放量什么情况下回滚到上一个版本什么情况下改为人工处理这些条件要在上线前就写清楚。如果企业无法回答这些问题最稳妥的选择不是“不上线”而是不要大范围上线。先限定用户、限定动作、限定数据、限定时间窗口再用真实运行结果决定下一步。AI 项目的成熟不在于一开始就全面自动化而在于能不能一点点放大范围同时让风险始终可见、可管、可退。▍结语门禁不是阻力而是 AI 项目进入生产的通行证AI 项目上线前要判断的不是“模型够不够聪明”而是“系统和组织是否准备好让它进入真实业务”。业务意图是否被验证真实样本是否诚实数据和知识是否可靠流程和权限是否清楚评估护栏是否闭环人工接管是否可执行运营责任是否明确扩展范围是否分级。这八道门看起来像限制实际上是在为 AI 项目争取更大的可信空间。没有门禁的上线短期看起来更快长期很可能把风险推给业务。真正成熟的上线是让每一次放行都有证据让每一次暂停都有理由让每一次扩展都有边界。 相关文章·别再只看写了多少代码AI 研发提效到底该怎么量·为什么FDE成了今年最火的岗位Palantir 给企业 AI 的启示·AI赋能研发组织提效的效果度量从“个人效率”走向“组织交付”的新标尺·从跑分到护栏AI Agent 规模化落地为什么必须先补上质量底座·从 AI Coding 到 Agentic Engineering研发提效正在进入第二阶段·为什么企业需要 Spec DrivenAI 写代码越快需求越要结构化·知识库、Skills 与组织资产AI 能力如何从一次性使用变成持续复利AI 项目上线前的故事上海站只是开篇。当企业从“试一试 AI”进入“把 AI 放进真实业务”更需要讨论的就不只是模型、工具和 Demo而是 Go/No-Go 决策、评估护栏、权限责任、持续运营和组织级交付机制。2026年 AiDD 北京站将在上海站的基础上继续关注 AI 研发、Agent 工程化、企业智能体和组织级落地。8 月 23-24 日的FDE 专题实践也会把这些问题带到更具体的业务场景里如何识别场景如何设计PoC如何建立评估与反馈闭环如何设置上线前门禁并把 AI 项目推向真实使用。AI 项目不是不能冒险。真正的问题是企业要让每一次冒险都可验证、可控制、可复盘、可继续。