本期我们请到浙江数秦科技合伙人、高级副总裁王斐。他做过 8 年公务员，后来进入浙江大型国企负责信息化落地，又在阿里巴巴做过钉钉大政府业务。现在，他以创业者的身份继续参与企业 AI 项目。本文根据 FDE 实战营第 9 期直播整理，以王斐第一人称讲述。
————————————
2025 年初，DeepSeek 开源、能力得到验证后，我看到央国企出现了第一波很大的 AI 需求。
那一波需求很明确：买硬件、买算力，做私有化部署。
但设备买了，模型也部署了，有价值的业务需求并没有自然长出来。直到 2025 年下半年和 2026 年上半年，大家才逐渐把注意力从“有没有模型”，转向“AI 怎样真正进入管理和业务”。
我经历过省级机关、大型国企和互联网公司的不同位置，现在又在创业。回头看这些年的项目，我越来越觉得，央国企 AI 落地最容易被低估的，并不是模型能力，而是复杂组织怎样接受一个新东西，并愿意与外部团队一起把它做成。
我们在浙江服务过一家国企，合作持续了三年。
最初，我们部署信创一体机和 DeepSeek，接入知识库，用 Dify 编排流程；随后，我们开始做 AI 门户和 Agent 场景；到了第三年，容易想到、技术上能做的场景差不多都做过了，我们反而把培训和陪跑放到了更重要的位置。
这三年里，我们真正交付的，不只是几套系统。
我们还在回答一些技术方案里很少写清的问题：谁愿意推动项目？领导怎样看到成果？业务部门为什么要参与？需求变了以后谁来协调？最后一笔款能不能顺利通过验收？
这些问题没有解决，再好的 Demo，也很难变成一个持续运行的项目。
01
客户第一次把项目交给你，是相互信任的验证
央国企项目与中小企业项目，一个很重要的差别是信任。
在中小企业里，客户可能看过你的个人 IP 或公众号，觉得产品不错，就愿意直接购买。央国企通常不会这样。没有足够的信任基础，客户最初给你的项目不会太大，他更可能先让你做一小块，看看团队的能力和配合方式。
招投标时，客户还有长期供应商和入围要求。一个只有五六个人的 FDE 团队，即使技术很好，也可能无法直接进入项目。
站在甲方的角度，这个担心并不难理解：如果小团队明天不在了，谁来维护系统，谁来承担责任？
所以，大型项目里出现运营商、当地大数据集团或其他总集成方很正常。我在阿里时，也有很多项目由运营商负责总集成。这既是产品和合规要求，也是在为项目找一个能兜底的主体。
另一方面，客户也逐渐发现，真正能深入做 AI 落地的，往往又是更灵活的小团队。除少数大型互联网公司和云厂商外，很多总集成方并没有足够深入的 AI 交付能力，最后仍会寻找中小团队完成实际工作。
这意味着，小团队不必一看到总集成方就觉得自己没有机会。你需要理解自己在生态里的位置：总集成方有客户关系、合规能力和项目管理能力，你有 AI 能力和交付灵活性。关键是选择可信的合作方，也提前算清项目管理和协作成本。
但进入供应商体系，只是信任的第一层。
如果是独立接单，那从商机接触、售前沟通开始，客户已经在判断你们团队是否靠谱。
项目真正开始后，客户还会从很多小事判断你是否专业。交付文档有没有页码，标点、字体和格式是否统一，用词是不是这个组织熟悉的表达，都会影响他对团队的判断。
如果正式材料里全是互联网黑话和内部梗，错别字很多，还要客户替你改，他很自然会想：连这些事情都做不好，代码和系统会不会也一样？
客户未必比 FDE 团队更懂 AI，但他能感受到团队做事是否可靠。
我把这称为“情绪价值的交付”。它不仅是陪客户吃饭喝酒，也不是有了关系就可以不管产品，而是在整个项目周期里，让对方相信：你理解他的业务和工作方式，遇到问题不会躲，能和他一起把结果做出来。
02
想让项目往前走，先找到客户内部的“教练”
中小企业里，你可能直接面对老板。大型组织的决策链要长得多。
即使见到了董事长或总经理，也不是他一拍板，第二天就能购买。信息部门、业务部门、人事、采购、法务、合规，都可能出现在项目里。每个部门的职责和 KPI 不同，对 AI 的态度也不同。
做这类项目，我建议团队画一张客户关系图：谁向谁汇报，谁支持、谁中立、谁反对，项目结果与谁的业务或 KPI 关系最大。
如果关键角色中有人明确反对，至少要想办法让他变得中立。
更重要的是，找到一两个真正希望项目成功的人。在 To B 销售里，这类人常被称为“教练”。他会告诉你，方案应该从哪个方向写，该向哪位领导汇报，领导关心什么，业务部门真正想解决什么问题。
AI 转型可能由“一号位”提出，但一号位不会天天盯着具体实施。没有内部教练，外部团队很容易只剩下“几个外包人头”：甲方不断提问题，乙方觉得对方故意刁难，双方越做越对立。
我们合作三年的那家国企，最初对接的是技术部门。
技术部门对我们是甲方，但在企业内部，它又像半个乙方，要为业务部门提供技术实现。它既懂企业内部怎样运转，也能和我们的技术人员建立共同语言，这是项目能够继续推进的重要条件。
第一期，我们部署信创一体机和 DeepSeek，接入客户已有的知识库产品，再用 Dify 做流程编排，与客户一起设计场景。
做完两个场景，大家觉得有一些效果，新的问题也出现了：业务部门不一定会用，领导又希望尽快看到成果。
于是，我们开始增加 AI 门户等兼具展示和组织动员价值的交付，也发动员工参与制作 Agent。项目从底层部署进入了场景交付阶段。
这个变化不是给项目“做包装”。在大型组织里，领导能不能看到成果，会影响下一步预算，也会影响他能否协调更多部门参与。一个可以展示、可以在同类企业交流时讲清楚的标杆场景，本身就有推动组织继续投入的价值。
03
复杂组织的需求是综合的，不能只看业务价值
央国企项目中，有一类需求，我会直接称为“政治诉求”。
例如，项目能不能参与评奖，能不能被展示，能不能让推动 AI 的高层领导有感知、有获得感。
有些大型企业的领导仍然看纸质签报，再由办公室人员统一在 OA 里处理。他不一定是 AI 工具的直接使用者，但既然批准了几十万、上百万元的预算，自然会关心最后做出了什么。
这类诉求不能假装不存在，也不能简单理解成面子工程。一个标杆做得好，可能帮助项目争取下一期预算，推动更多部门参与，形成持续投入。
当然，不同国企对这件事的权重并不相同。
有的企业具有较强的公共服务或行政垄断属性，核心压力是保障民生和供给，经营方式也受到更多约束；有的国企处在充分竞争市场，管理层 KPI 与经营业绩、国有资产保值增值直接相关，降本增效会更受重视。
所以，不能拿一套场景清单去套所有客户。要从企业的经营状况、发起部门和项目语言里判断：这一期更需要让领导感知成果，还是业务部门已经遇到了传统人力和信息化难以解决的问题？
我们选择 AI 场景时，主要看两个方面：价值与可实现性。
价值不只有眼前业务收益。一个场景能否沉淀数据、流程和知识，围绕小切口继续迭代？客户能否用更少的人完成更多工作？交付团队能否从中沉淀可复用的能力？这些也属于价值。
可实现性也不等于“模型能做”。
技术上能不能实现，只是第一层。客户有没有组织条件推广，岗位职责是否允许调整，运行环境是否支持你选用的模型和工具，同样决定方案能否落地。
一个方案依赖海外大模型，客户却要求本地模型、国产化和信创适配，它在演示环境中再漂亮，也未必能够交付。
需求风暴以后，客户通常会提出很多想法。不要试图同时做完。现阶段甲乙双方对 AI 的认知都还在建立，行业也没有形成像传统软件工程那样稳定的交付标准。更合适的选择，是找一个价值较高、又相对能实现的小切口。
先赢得一次小胜利。
客户看到价值，乙方也能健康交付，信任才会增长，客户才愿意把下一件事交给你。我们把这个过程叫作“从胜利走向胜利”。那家客户之所以能与我们合作三年，也不是因为第一期就做了一个大而全的项目，而是双方一次次把小项目做成，再把客户在业务和同行比较中逐渐做成标杆。
04
第三年，我们反而把培训放到了技术前面
到了第三年，容易想到、技术上能做的场景差不多都做过了。
早期的知识库产品和流程编排，也暴露出各自的限制。比如算力不足时，Dify 的流程编排越复杂，运行可能越慢。继续堆流程，不一定能自动产生更有价值的业务场景。
我们开始意识到，AI 落地不能一直由技术部门替业务部门想需求。
于是，我们结合知识萃取和其他项目经验，向客户提出培训和陪跑，让更多业务部门参与进来，继续挖掘真正有价值的需求。
客户前两三年已经积累了一定的技术底座和业务认知。培训式业务挖掘开始后，业务和行政部门也能自己做一些小 Agent：写简单的提示词，调用技术部门准备好的 MCP 或 API，组合成小型应用。
这时，AI 才不再只是技术部门买回来的一套软件。业务人员开始具备发现和开发场景的能力，领导也能看到组织真的动了起来。
这段经历改变了我们现在做项目的顺序。今天再和很多国央企谈 AI 落地，我们反而会提出，把认知课或培训课前置。
这其实是把更重要更难的事情放在前面。
单谈技术合同相对容易。要让技术部门把人事、行政和业务部门拉进来，先讨论组织对 AI 的认识和培训需求，售前过程会复杂得多。客户也可能问：我想做 AI 转型，你为什么先让我上课？
市场上的 AI 培训良莠不齐，有些在做认知教育，有些只是在制造焦虑。客户有这种疑问很正常。
我们的做法是分层处理。习惯与外部咨询老师合作的大企业，可以接受更完整的培训；没有这类习惯的，可以先做半天认知分享，面向中层以上管理者，讲从数字化到智能化会遇到什么问题、行业里常见的做法是什么，同时结合后续可能交付的内容。
另一种方式，是先找一个较轻、较成熟的通用场景合作，例如官方内容的文生图、文生视频，或法务合同审核。无论从培训还是小场景切入，都要帮助客户形成正确预期。
认知分享也在帮助双方互相判断。客户会借这个机会看你是否理解国央企、是否理解他的行业；团队也能看到，这个组织面对AI转型目前准备到了哪一步。
FDE 团队里，需要有人搭起这座桥。很多技术很强的同学，在客户沟通上未必成熟。客户的话还没说完，就开始补充、纠正，做教育客户的事情，这既不符合人与人沟通的基本礼貌，也不适合大型组织的场域。
电商客户谈流量、公域和私域；国央企会谈政策文件、行业要求和正式材料。站到同一个话语体系里，才能开始理解需求。
05
验收不是项目末尾的动作，而是售前就要考虑的结果
传统软件项目最难的，有时不是拿单，而是验收。央国企项目往往分阶段付款，最后一笔款能不能拿到，与验收直接相关。
Demo、PoC 或初期上线只是阶段性产物。团队经常会觉得，需求已经分析过，产品也基本完成了，为什么还不能上线、不能验收？
因为验收不仅依赖产品，也依赖客户是否愿意与你一起完成这个任务。
我习惯把交付分成两部分：产品交付和服务交付。
产品交付是系统和功能本身。服务交付则是满足那些不直接写在功能列表里、却会影响项目成功的诉求，例如帮助客户形成标杆，准备汇报和展示材料，或者配合科研类客户总结成果。
服务交付不能替代产品。关系再好，产品做得差也不行。但如果双方把关系做成针尖对麦芒，乙方说产品已经完成，甲方说完全不能用，项目同样很难收尾。
有些问题应当在选场景时就避开。
例如，不要选择当前 AI 完成度不高、却要求百分之百正确的场景。国企里常见的“领导问数”，可以用 AI 做交互，但不能轻率承诺只靠自然语言转 SQL 就能稳定、可靠地完成全部工作。需要确定性的部分，该用传统软件实现，就用传统软件实现。
售前和合同阶段，也要写清基本约定。即使需求无法完全固定，报价和成本仍要留出缓冲。传统软件工程可能预留 20%—30% 的缓冲；AI 项目还要结合双方信任程度和合作周期评估，因为需求变化很难完全避免。
还要理解产品和服务之外的条件。例如大型节假日或重要时间节点，央国企可能封网，不允许更新生产系统。那不是客户故意阻止上线，而是当时确实不能上线。
如果双方信任充分，尤其当客户有自己的技术部门时，他会告诉你，项目怎样才能通过验收。如果乙方团队开始觉得客户总是在刁难技术落地，提出不切实际的要求，负责客户关系的合伙人或管理者就应及时介入。
否则，技术同学花很大力气做完功能，客户最后仍可能说：“这不是我想要的。”
验收也可能存在协商空间。有的客户因财务制度需要付款，但专家评审认为部分内容仍不达标，双方可能通过承诺函约定后续整改数据或需求。真正的项目交付，从来不是页面上出现一个“完成”按钮就结束了。
06
小团队的机会，在行业经验与AI能力的结合点上
很多 FDE 团队想进入央国企项目，一方面是看到了预算，另一方面也担心大型集成商和互联网厂商会不会把机会全部拿走。
我觉得不必过度担心。
大型厂商很难完全替代灵活的小型团队，小型团队也无法单靠 AI 能力补上客户关系、合规与行业经验。真正的机会，往往在彼此能力的互补点上，在多种能力的结合点上。
多参加社区和行业活动，是为了建立持续的人际连接。年轻创业者也不必简单排斥家人、长辈或已有关系。这些关系背后可能是多年共事、同学经历形成的信任，很难单靠产品在短时间内替代。
与此同时，可以多接触在垂直行业做了 10 年、20 年的传统软件公司。
它们有深厚的客户关系和行业理解，却可能缺少 AI 交付能力；FDE 团队熟悉 AI，却往往缺少行业经验。双方不一定只是竞争对手，也可能共同完成项目。
这段三年合作，从信创一体机、知识库和流程编排开始，后来做门户、做 Agent，再到培训和陪跑。回头看，技术底座一直重要，但让项目继续走下去的，是客户内部有人愿意推动，是业务部门逐渐学会参与，也是每一次小交付都没有透支彼此的信任。
模型还会变，工具还会变，今天看起来复杂的流程，明天也许会被更简单的方式替代。
但复杂组织采用新技术的过程，不会只靠一次模型升级自动完成。
它需要有人理解技术，也有人理解组织；有人能把产品做出来，也有人能把它讲成客户听得懂、愿意一起做的事情。
对 FDE 团队来说，这或许才是央国企 AI 项目里真正难以被复制的能力。
