作者 / 来源：中智凯灵 / AiDD

——从 PoC 到生产级智能体，要决定的不是“能不能上线”，而是“能不能放心放大”

▼

AI 项目容易在上线前变得含糊。

Demo 跑通了，业务方觉得方向不错，项目组也已经投入了几轮迭代。这个时候，如果直接问“要不要上线”，答案往往会被会议气氛推着走：既然看起来能用，就先上小范围试试。

但 AI 项目最危险的地方，恰恰在于“看起来能用”和“可以进入真实业务”之间还有很长一段距离。

一个智能体可能在演示样本上回答顺畅，却在真实用户的长尾问题里频繁偏航；一个研发 Agent 可能能生成代码，却无法稳定通过测试、审查和发布流程；一个知识库助手可能能读文档，却无法判断哪份制度才是最新版本。

所以，企业 AI 项目上线前，不应该只有一次“验收会”。它更需要一组清楚的Go/No-Go 门禁：哪些条件满足才能放行，哪些问题出现必须暂停，哪些能力不足需要回炉，哪些场景可以继续扩展。

图 1：AI 项目上线前的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 Driven：AI 写代码越快，需求越要结构化

·知识库、Skills 与组织资产：AI 能力如何从一次性使用变成持续复利

AI 项目上线前的故事，上海站只是开篇。

当企业从“试一试 AI”进入“把 AI 放进真实业务”，更需要讨论的就不只是模型、工具和 Demo，而是 Go/No-Go 决策、评估护栏、权限责任、持续运营和组织级交付机制。

2026年 AiDD 北京站，将在上海站的基础上继续关注 AI 研发、Agent 工程化、企业智能体和组织级落地。8 月 23-24 日的FDE 专题实践，也会把这些问题带到更具体的业务场景里：如何识别场景，如何设计PoC，如何建立评估与反馈闭环，如何设置上线前门禁，并把 AI 项目推向真实使用。

AI 项目不是不能冒险。真正的问题是，企业要让每一次冒险都可验证、可控制、可复盘、可继续。