为什么 AI 落地实施越来越像一项咨询工作？

导读：AI项目先找准价值，再用运营和软件持续实现价值。

AI落地实施正在变得越来越像一项咨询工作

今年做 AI 项目，我越来越明显地感觉到：AI落地实施正在变得越来越像一项咨询工作。

这并不是说，实施团队以后不用做产品、不用写代码了；也不是说，只要多开几次会、多写几份报告，就算是做了咨询。

真正的变化是，过去很多信息化项目的起点，是客户已经比较清楚自己要什么，项目团队需要解决的主要问题，是怎么把这些需求做成系统。现在不少AI项目的起点，却只是一个比较大的方向：建设企业级 AI 平台、建设知识库、做智能问答、做智能体，或者让大模型帮助某个部门提效。

方向通常没有错，但距离一个真正可建设、可使用、可验收的项目，还差得很远。

所以，项目前半程最重要的事情，正在从“确认功能”变成“和客户一起发现价值”：到底要解决谁的什么问题，AI在其中能发挥什么作用，哪些事情不能交给AI，以及怎样把一个听起来不错的想法，变成一套真正可行的建设方案。

可以复制的是经验，不是答案

不同客户之间当然有很多经验可以复制。

比如做企业知识库时，知识接入、文档解析、切分、检索、问答、权限和反馈，这些能力在很多项目中都会出现。做客服、制度查询、研发助手、营销支持，也会逐渐沉淀出一些典型场景和实施路径。

但我越来越觉得，可以复制的是方法和经验，不能直接复制的是项目答案。

同样叫“制度问答”，在不同企业里可能完全不是同一件事。有的企业主要关心的问答准确率的问题，有的企业更关心文档版本是否正确，有的企业要解决的是多步骤的任务型Agent要解决的事情；还有的企业最看重权限、引用依据和回答风险。

表面看都是一个知识问答系统，背后的业务价值、知识来源、责任部门、权限边界和验收标准却完全不同。如果把上一个客户的方案改改名字就拿过来，功能也许能上线，但项目价值很可能落不了地。

因此，客户现场的认真调研仍然不可替代。项目团队不能只问“需要哪些功能”，还要去看实际工作是怎么完成的：谁在什么环节遇到了问题，现在靠什么方式处理，一次要花多长时间，什么情况下容易出错，出了问题由谁负责，最终结果又由谁判断。

这些内容，很多时候并不会天然出现在一份需求清单里。它们需要在访谈、观察、材料分析和多轮讨论中，一点点提炼出来。

AI 项目的总体设计，首先要回答价值问题

传统信息系统已经形成了相对稳定的讨论框架。业务流程、用户角色、功能模块、数据结构、系统接口、非功能指标，通常都有比较明确的分析方法。只要业务边界相对清楚，需求分析和总体设计就能够沿着这些框架逐步展开。

AI 项目则多了一层不确定性。

一方面，大模型能力升级很快，半年前需要专门开发的能力，今天可能已经成为模型或平台的标准能力；另一方面，新的工程方法也在不断出现，知识库、RAG、智能体、工具调用、多模态和上下文工程都在快速变化。我们很难像建设传统信息系统一样，拿出一套几年不变的固定套路。

更重要的是，AI能做什么，并不等于客户应该建设什么。

客户说“想做一个知识库”，我们还需要继续追问：是为了缩短信息查找时间，降低新人培养成本，减少制度解释偏差，还是让某个智能体获得可靠的企业知识？这些目标看起来接近，最后决定的建设重点却并不一样。

所以现在编写软件需求和总体设计，除了原来的功能、接口、性能和安全等内容，还会有以下几类问题：

1. 这个场景具体服务谁，解决哪个工作环节的问题？
2. 现有方式的成本、效率和风险是什么，改进基线在哪里？
3. 哪些工作适合交给 AI，哪些仍然需要规则、原有系统或人工判断？
4. 项目需要哪些数据、知识、权限、责任人和配套流程？
5. 上线以后用什么指标证明有效，又怎样持续迭代？

说得直白一点，以前的总体设计主要回答“系统怎么建”，现在还必须先回答“为什么建、先建什么、怎样证明值得继续建”。

这就是它越来越像咨询工作的原因：不是只替客户记录需求，而是要在建设目标的大框架下，与客户共同提炼价值点，判断约束条件，再把价值点变成可实施、可验收的方案。

像咨询，并不意味着没有方法可循

AI项目存在不确定性，不代表每个项目都只能临场发挥。恰恰相反，越是不确定，越需要稳定的方法作为抓手。

企业级AI知识库就是一个很典型的例子。

早期大家比较关注的是软件能力：支持多少种文件、文档怎么切分、向量库怎么选、召回率怎么样。这些当然重要，但随着知识范围扩大、使用部门增加、业务场景变多，项目的主要矛盾会逐渐从“系统能不能找到知识”，转向“系统里到底应该有什么知识”。

我们在梳理AIS知识库运营管理方法时，总结过一句话：技术决定能力上限，运营决定长期价值。

如果知识本身已经过期、冲突、缺失，或者没有清晰的权限和责任人，再强的检索能力，找到的也只能是混乱。一个企业级知识库要长期有效，至少要同时解决三件事：

• 知识生命周期：知识怎样产生、加工、准入、使用、反馈、更新和退出；
• 知识质量：怎样保证准确、完整、一致、及时、可用；
• 知识价值：知识服务什么场景，是否真正被使用，是否带来了业务改善。

这里面很多问题，本质上不是一个软件按钮的问题，而是管理问题。

例如，接入一个文件目录并不等于完成了知识接入。真正需要确定的是：这批知识来自哪里，归哪个部门负责，具体责任人是谁，多长时间更新一次，属于什么权限等级。如果这些问题没有回答清楚，接入得越快，后面的治理成本可能越高。

再比如，知识上线也不应该只是“上传成功”。什么知识允许进入正式知识库，何时生效，由谁审核，适用于哪些对象，为什么值得纳入，都需要有明确规则。知识投入使用以后，还要把用户反馈变成新的生产入口：发现问题、定位原因、分派责任、修改审核、重新验证，最终形成闭环。

所以，企业知识库并不是一次性的资料整理工程，更像是一套持续运行的知识生产和经营体系。

软件的比重在变化，但软件并没有变得不重要

在AI项目的价值构成中，单纯“把功能做出来”的比重确实在下降，运营管理工作的比重正在上升。在我们的一些客户项目中，知识库运营管理方法甚至已经成为方案的核心。

但这不意味着软件可以退居其次。更准确地说，软件功能会越来越细，越来越贴近管理动作，为运营方法服务。

知识接入功能，不只是把文件搬进来，还要记录来源、责任和更新机制；知识工程，不只是解析和切分，还要完成清洗、脱敏、标准化、标注和质量检查；知识治理，需要把权限、版本、有效期、健康度和变更影响落实到系统中；知识使用，也不能停留在问答页面，还要支持引用溯源、问题反馈、效果评测和场景分析。

从这个角度看，产品不是知识运营本身，而是制度、组织、流程和责任的数字化执行载体。

没有运营方法，软件容易变成一个功能很多但没人持续维护的资料仓库；没有合适的软件，运营又会依赖表格、人工提醒和少数人的责任心，很难规模化，也很难度量。

准确、稳定和好用，仍然是软件的基本功

还有一个容易产生的误解是：既然项目更像咨询，运营又越来越重要，那么软件本身是不是就没有那么重要了？

我的看法正好相反。

越是要承载企业级的制度、流程和责任，软件的准确性、稳定性和交互友好度就越重要。

准确性不只是模型回答得像不像，还包括文档是否解析正确、表格和段落有没有丢失、检索结果是否引用了正确版本、权限是否被严格执行、高风险问题是否能够拒答或转人工。

稳定性也不只是页面能不能打开。知识同步失败能不能发现，处理任务能不能重试，版本能不能回溯，系统升级会不会影响已有知识和应用，这些都会直接影响客户是否敢于长期使用。

交互友好则决定运营方法能不能真正落地。业务人员是否容易完成审核和发布，知识责任人能否快速找到待处理问题，普通用户能否看懂回答依据并方便反馈，这些看似是产品细节，实际上决定了一套管理制度的执行成本。

好的咨询和运营方法，不能替代扎实的软件工程；好的软件，也不能替代对业务价值和运营机制的理解。三者不是谁取代谁，而是分工不同：

• 咨询分析决定做什么、为什么做；
• 运营管理保证知识和场景持续有效；
• 软件产品让这些方法可执行、可规模化、可度量。

最后

AI项目实施越来越像咨询，背后反映的其实是项目交付目标发生了变化。

客户需要的，不再只是一个按需求清单开发完成的系统，而是一套能够把 AI 能力转化为业务价值的办法。项目团队既要理解模型和软件，也要理解业务、组织和管理；既要能够设计系统，也要能够和客户一起识别问题、判断优先级、建立评测标准，并考虑上线以后的持续运营。

这会让项目前半程看起来更“慢”一些，因为需要花更多时间调研、讨论和验证。但如果价值点没有找准，后面的开发越快，可能只是越快地做出一个不被真正使用的系统。

真正成熟的AI项目，不是上线一个会回答问题的产品，而是与客户一起建立一套持续发现价值、生产高质量知识、验证效果并迭代应用的能力。

从这个意义上说，AI落地既是一项咨询工作，也是一项运营工作，最后还必须由可靠、稳定、好用的软件把它真正承载起来。