▼

个人变快了，组织未必变强。

在第9届AI+研发数字峰会（AiDD 2026 上海站）上，很多分享并没有停留在“AI 能不能生成代码、回答问题、调用工具”这一层。

更反复出现的问题是：当AI 进入真实业务以后，项目为什么会卡住？为什么Demo 阶段看起来很顺，上线以后却难以被业务持续使用？为什么个人效率提升以后，组织交付并没有同步变快？

这类问题的共同指向很清楚：企业AI 落地不是单纯的工具问题，而是交付体系问题。一个AI 项目能不能落地，不只取决于模型能力，也不只取决于工程团队能不能把应用做出来。它更取决于业务意图是否清楚、结果是否可验证、知识是否可用、流程是否能嵌入、经验是否能沉淀、权限是否可控，以及上线后是否有人持续运营。

词元无限技术专家鲁奕志在《AI 驱动研发交付闭环，释放组织级效能》中提到一个值得警惕的现象：AI Coding 工具让个人效率明显提升，但组织交付仍可能原地踏步。这个判断放在企业AI 项目上同样成立。一个团队可以很快做出一个漂亮的AI Demo，但如果它没有进入组织的交付闭环，就很难变成一项真正可复用、可治理、可持续的业务能力。

前几天华为云CodeArts首席产品专家汪维敏在《华为云码道CodeArts代码智能体深度解读》(华为云创想者大会AiDD × 华为云AI 编程论坛)中提到，企业客户对智能编码的关注点，已经从“能不能写代码”转向企业级管理、代码增量开发、经验技能、质量与安全。换句话说，AI 项目真正进入企业后，首先要面对的不是模型参数，而是交付现场。

图1：汪维敏《华为云码道CodeArts代码智能体深度解读》：企业客户关注点从智能编码普及转向企业级管理、代码增量开发、质量与安全（PPT 第4 页）

因此，在一个AI 项目启动之前，企业真正需要先问清楚的，不是“这个模型能不能做”，而是下面7 个更接近交付现场的问题。

▍问题1：它解决的是真问题，还是技术反推出来的题目？

很多AI 项目一开始就跑偏，是因为团队先看到了技术能力，再反推出一个看起来合适的场景。模型能读文档，于是想做知识库；Agent 能调用工具，于是想做流程助手；多模态能力不错，于是想做图片质检。这些方向未必不对，但如果它们没有对应到业务现场反复出现的阻碍，就很难成为真正的项目。

AiDD上海站关于Spec Driven 和意图驱动交付的多场分享，都在强调同一个方向：AI 时代的项目起点，不能只是一个模糊需求或一句提示词，而应当是结构化的业务意图。兴云数科资深需求AI教练郑涛在《意图驱动交付：Agent 时代从交付系统到交付价值的实践》中提出，需求正在被重塑为可执行的数字化资产，而不是停留在一次性的文字描述。

这对AI 项目启动很关键。所谓“真问题”，不是一句“我们想做一个智能体”，而是能说清楚：谁在什么场景下遇到什么阻碍，现在靠什么方式解决，成本在哪里，AI 做得更好以后，业务指标或交付结果会发生什么变化。

如果这个问题说不清，项目后面越快，越可能只是更快地走向偏差。

图2：郑涛《意图驱动交付：Agent 时代从交付系统到交付价值的实践》：需求重塑，意图成为可执行的数字化资产（PPT 第20 页）

▍问题2：结果能不能被持续验证，而不只是“看起来还可以”？

AI项目最危险的评价标准，是“体验还行”。一段回答可能读起来很顺，却漏掉了关键限制；一份报告可能结构完整，却引用了错误事实；一个Agent 可能跑完了流程，却已经偏离了业务目标。

小红书资深工程师林能源在《从跑分到护栏：AI Agent 可观测和质量保障体系》中指出，Agent 落地的瓶颈正在从“能不能跑”转向“能不能评估”。传统软件可以用较明确的规则验证接口、按钮和数据状态，但Agent 的输出具有概率性、语义性和路径不确定性。如果没有评估集、质量维度和Bad Case 回流，项目很容易停留在主观试用。

所以，AI 项目启动前要先问：我们准备怎样判断它做对了？客服场景不能只看回答是否自然，还要看解决率、转人工率、投诉率和错误回答类型；研发场景不能只看代码生成速度，还要看任务完成率、测试通过率、缺陷逃逸率和人工Review 成本；知识库场景不能只看能不能回答，还要看召回准确率、引用可追溯性和答案可复核性。

没有可验证性，就没有真正的交付结果。一个智能体界面不是交付结果，一条模型调用链也不是交付结果，业务方能持续确认它解决了问题，才是交付结果。

林能源把这种变化进一步概括为AgentOps：Agent 与传统软件的根本差异，在于同一输入可能走向不同路径，决策过程、工具调用和结果质量都需要被持续观测、评估和治理。对企业来说，这意味着质量验证不能停留在上线前的一次性验收，而要变成贯穿运行期的工程机制。

图3：林能源《从跑分到护栏：AI Agent 可观测和质量保障体系》：Agent 时代需要新的Ops 范式（PPT 第10 页）

▍问题3：数据和知识是不是已经具备可用形态？

AI项目落不了地，很多时候不是模型不够强，而是它拿不到正确上下文。企业知识往往散落在文档、表格、工单、邮件、会议纪要、代码仓库和老员工经验里。人可以靠长期经验补全背景，AI 只能依赖系统提供给它的材料。

腾讯PCG 工程效能平台部刘琮玮在《AI 原生知识库及其实践与应用》中，将知识库从“资料存储”推进到“应用接口”。在他的分享里，知识库不只是把文档放进去等人搜索，而是要回答知识从哪来、怎么处理、怎么用、如何持续提升质量等问题。

这意味着，企业做AI 项目时要看的不是“有没有资料”，而是资料是否已经成为AI 可用的知识。关键业务规则、历史案例、异常处理方式是否齐全？PDF、图片、表格和系统记录能否稳定解析？哪些内容是最新版本，哪些只是个人经验？哪些可以被AI 调用，哪些受权限限制？这些问题会直接决定项目质量。

如果知识没有结构化、没有溯源、没有权限边界，也不能在错误发生后更新，项目很容易变成“聪明模型加糟糕上下文”的组合。短期能演示，长期一定会失真。

刘琮玮给出的知识库应用分层架构，也说明了同一件事：企业AI 能力不能只靠一次性上传资料，而要把知识接入、身份认证、权限判断、请求日志、意图理解、质量评估和接口调用组织成可治理的系统能力。

图4：刘琮玮《AI 原生知识库及其实践与应用》：知识库应用分层架构方案，强调定制、安全、可追溯、可扩展（PPT 第20 页）

▍问题4：它能不能嵌入真实流程，而不是停在独立页面？

很多Demo 之所以顺，是因为它暂时绕开了真实流程中的摩擦：不用处理权限审批，不用和现有系统对接，不用面对异常数据，也不用影响上下游岗位。但企业落地恰恰发生在这些摩擦里。

一个销售助手如果不能接入CRM、合同、客户历史和审批流程，就很容易停留在“帮我写一段话术”。一个研发Agent 如果不能接入代码仓库、任务系统、测试环境和Review 流程，也很难真正参与交付。一个运维Agent 如果不能读取监控、日志、知识库和变更记录，就很难承担排障责任。

鲁奕志在分享中给出的央企客户案例显示，AI 价值并不只是单点生成，而是把需求、方案和开发启动之间的断点补上，使从需求到开发启动的周期由5 天压缩到1 天。邮储银行高级研发工程师陆磊在《从需求到交付，Coding Agent 赋能研发流程新范式》中给出的研发流程全景图，也把同一个问题摊开了：从需求、设计、开发、测试到上线发布，每一步都有上下游依赖，AI 只有进入这条链路，才可能改变交付结果。

因此，项目启动时要问清楚：AI 在流程里接收什么输入，调用哪些工具，产出什么中间结果，交给谁审核，什么情况下继续执行，什么情况下停下来。没有流程位置的AI 项目，只是一个应用；进入流程闭环的AI 项目，才可能成为交付体系的一部分。

图5：陆磊《从需求到交付，Coding Agent 赋能研发流程新范式》：研发流程从需求到上线发布的全景链路（PPT 第4 页）

▍问题5：项目经验能不能沉淀为组织资产？

企业AI 落地的一个常见误区，是把项目看成一次性建设。团队做完一个智能体，交付一个应用，整理一份使用说明，就以为项目结束了。但从AiDD上海站多场分享看，真正长期有效的AI 能力，往往会从一次任务沉淀为知识、规则、模板、Skill、评测集和运营机制。

去哪儿旅行基础架构负责人、技术总监李佳奇在《去哪儿旅行L3 AI Coding 的研发平台与Skills 实践》中，给出了一个研发组织里的样本。去哪儿不是只看某个工程师有没有用AI 写代码，而是围绕研发数字化、AI Coding 工具和自动化流水线，持续沉淀可复用Skills。

Skills的意义，不是把提示词整理得更漂亮，而是把“怎么完成一类任务”的经验封装起来。它包含流程、工具、上下文、约束和验证标准。这样，AI 能力不再依赖少数高手的个人经验，也不只是散落在聊天记录里的技巧，而是进入组织可管理、可复用、可治理的资产池。

所以，判断一个项目能不能落地，还要看它会不会“留下来”：高质量案例能不能沉淀为Skill？失败案例能不能转成规则、护栏或评测样本？项目结束后，新团队和新Agent 能不能站在已有经验上继续工作？

汪维敏在华为云码道CodeArts代码智能体控制台部分的分享中，则从另一侧说明了组织资产为什么需要被管理：Agent、Skills、Rules、知识库如果只是散落在个人环境里，就难以复用；进入企业级管理平台后，才有可能被分层配置、按团队扩展、被统一观察和治理。

图6：汪维敏《华为云码道CodeArts 代码智能体深度解读》：码道代码智能体控制台支持企业级管理、分层分级权限管理与数据驱动决策（PPT 第7 页）

▍问题6：权限、责任和安全兜底是不是在设计第一天就清楚？

AI一旦能够调用工具，就不再只是内容系统，而是行动系统。它可能读取客户资料，查询内部数据，修改文件，创建工单，发起审批，提交代码，触发通知。这个时候，如果权限边界不清楚，项目风险会迅速放大。

汪维敏对企业级安全合规的拆解，正好补上了这类项目设计时必须提前考虑的内容：访问安全、数据安全、智能体安全、用户数据安全、行为可观测、隐私数据脱敏、权限与审计，都不是上线前的附加项，而是智能体能否进入企业流程的前提条件。

这类设计对企业AI 项目非常重要。权限清楚，意味着AI 能读什么、写什么、调什么接口、做什么动作，都有明确边界；责任清楚，意味着AI 给出建议、执行动作、触发错误时，人类负责人、业务负责人和技术负责人都能被找到；兜底清楚，意味着AI 失败、超时、冲突、低置信度或触碰高风险动作时，系统知道如何转人工、如何暂停、如何回滚。

很多团队会把这些问题留到上线前再补。但在AI 项目里，它们应该在设计第一天就出现。权限、责任和兜底不是安全部门额外增加的限制，而是AI 能不能进入真实业务系统的前提。

图7：汪维敏《华为云码道CodeArts代码智能体深度解读》：企业级安全合规覆盖访问安全、数据安全、行为可观测与权限审计（PPT 第15 页）

▍问题7：它能不能从PoC 走向持续运营？

最后一个问题，也是最容易被忽略的问题，是这个项目能不能从PoC 走向持续运营。PoC 的目标是证明方向可行，但企业真正需要的是可持续使用的AI 能力。两者之间的差距很大：PoC 可以由少数人盯着跑，可以使用小样本，可以绕开复杂异常，也可以靠项目组临时处理问题；运营阶段则要面对更多用户、更复杂输入、更长周期和更高稳定性要求。

陆磊在《从需求到交付，Coding Agent 赋能研发流程新范式》中，把上线发布Agent 拆成质量门禁、配置脚本变更核对、发布合规与风险分析、发布公告与版本日志等步骤。这个视角很重要：AI 项目不是“能生成”就算完成，越接近生产环境，越需要有按规矩留痕、可追溯、可回滚的发布机制。

高梦飞在《让智能体可观察、可评估、可进化：构建面向智能体的新一代可观测评估体系》中，则进一步展示了观测体系对智能体落地的意义。对企业来说，持续运营不是定期维护一下Prompt，而是让线上反馈、链路观测、Bad Case、知识更新和效果评估进入一个长期闭环。

这说明AI 项目的“上线”不是终点。上线只是把系统交到用户面前，落地则意味着它能在使用中持续积累证据、修正错误、补充知识、更新Skill，并逐步变得更稳定。

因此，项目启动前就要问清楚：谁来用，谁来改，谁来评估，谁来运营？哪些指标持续看，哪些错误要回流，哪些知识会更新，哪些能力可以复用？如果项目只有“做出来”的计划，没有“持续跑下去”的安排，它大概率会停在演示工程。

图 8：陆磊《从需求到交付，Coding Agent 赋能研发流程新范式》：上线发布 Agent 建立质量门禁、合规分析与全流程留痕（PPT 第 15 页）

图9：高梦飞《让智能体可观察、可评估、可进化》：OTel 架构在Agent 观测场景下的劣势（PPT 第14 页）

▍结语：AI项目落地，是把问题变成可运营的能力

企业AI 落地正在从“工具尝鲜”进入“体系建设”。一个项目能不能落地，不在于Demo 阶段是否足够惊艳，而在于它能不能回答这7 个问题：

问题是否真实，结果是否可验证，知识是否可用，流程是否嵌入，经验是否沉淀，权限是否可控，运营是否持续。

这7个问题不是为了劝企业少做AI，而是为了让AI 项目更值得做。真正成熟的企业AI 落地，不是把模型接进来，也不是做一个漂亮入口，而是把一个业务问题转化为可运行、可验证、可治理、可复用、可持续进化的AI能力。

这也是近两年企业重新讨论FDE 的原因。AI 时代需要一类人，既能进入业务现场追问真实问题，也能把问题转成技术架构；既能搭建MVP，也能组织评估、反馈、权限和持续运营；既懂模型和工具，也懂交付节奏和业务效果。