从 Skill 到语义层，AI 落地的壁垒到底是什么
很多团队把 AI 落地的壁垒，理解成模型选得对不对、知识库建得大不大。腾讯研究院那份 FDE 报告里有一条更硬的判定线：如果第一个客户需要 10 个人月，第十个同类客户仍然需要 10 个人月，模式就没有跑通。 壁垒从来不在某一样东西上，而在你有没有把做过的事，分层沉淀成下一次能直接拿走的东西。
前三篇聊了 FDE 的成色要看项目结束留下什么、为什么做着做着变成外包、班子该怎么搭。上篇结尾留了个话头，说要聊更靠底层的问题——留下的那些东西，到底长什么样。
这篇就讲这个：它们分几层，每层解决什么问题，为什么我们研究过的团队里，大多只做完了第一层就停在那儿。
下面这些是我在客户前线跑出来的观察，也参考了腾讯研究院 2026 年 8 月那份《FDE模式行业观察与实践》。FDE 这套东西还很新，我们也是边干边摸索，谈不上成熟体系。观点来自我和 CheersAI 团队的实战复盘，已做脱敏处理，不对应任何一家客户的完整情况。
一句判定：看第十个客户，不看第一个
报告里给 FDE 模式留了一条很实在的判定线，也是我读完印象最深的一句。
如果第一个客户需要 10 个人月，第十个同类客户仍然需要 10 个人月，模式就没有跑通。
这句话的用处在于，它把判断变成了一道算术题。你不用解释自己有没有沉淀、有没有复用、有没有方法论，只要把两个数字摆出来：第一个同类客户花多少人月，第十个花多少人月。曲线不往下走，前面说的那些就都还没发生。
配套还有两个辅助判断：产品边界每个季度是否在向产品侧移动，以及成熟客户的现场投入是否持续下降。这两条我后来也拿去对照我们自己复盘过的项目，比问「你们有没有沉淀」有用得多——后者所有人都会答有，前者是能算出数来的。
我们复盘过的项目里，有一类情况很典型：第一个客户派了五个人驻场半年，做完很成功，案例写得很漂亮；第三个同类客户来了，派的人差不多，花的月数差不多，踩的坑甚至也差不多。看起来业务在增长，实际上每个项目都是一次重新开张。
这不是能力问题。是因为上一个项目结束时，留在公司手里的东西，和留在那五个人脑子里的东西，不是同一份。
四层结构：存下来、被理解、能复用、接得进去
那「留下的东西」到底有哪些？报告里给了一张很清楚的分层。
先说清楚口径：下面这四层不是我编的框架。报告 §2.6 的原话是，本体、Skill（可以理解成「可复用的能力包」）、连接器这三种沉淀形式对应不同层级——本体解决「业务对象如何被理解」，Skill 解决「能力如何被复用」，连接器解决「系统如何被操作」，分别对应知识沉淀、能力沉淀和系统连接沉淀；三者组合在一起，才构成一个可复用的行业解决方案。第三章和第四章又补了第四样：行业知识库。我把它们按「从底往上」的顺序排了一遍，便于对照。
| 层 | 解决什么问题 | 沉淀下来的是什么 | 缺了会怎样 | |---|---|---|---| | <strong>知识库</strong> | 资料存得下来吗 | 文档、聊天记录、工单、案例 | 人一撤，东西跟着走 | | <strong>语义层</strong>（报告里叫本体层） | 业务对象怎么被理解 | 术语、概念、关系和规则 | 同一个词，人和 AI 各理解一套 | | <strong>Skill</strong> | 能力怎么被复用 | 可重复调用的动作包、模板 | 每个项目重新写一遍 | | <strong>连接器</strong> | 系统怎么被操作 | 对接接口、调用权限、数据通路 | 每次对接重新谈一遍 |
这四层里，最容易被忽略、也最要命的是第二层。
知识库大家都在建，但「把文档存进去」和「让系统理解这些文档说的是同一件事」完全是两回事。报告里有个说法我特别认同：Palantir 真正值得学的，不是派工程师驻场这个动作，而是在数据与业务之间建立统一语义层，让 AI 和一线人员共同操作这层语义，而不是直接面对原始系统。
举个我们研究过的场景。一家客户上了知识库问答，员工问「上个月华东区的高价值客户有哪些投诉」，系统答不上来。不是因为文档没进库——投诉记录全在里头。是因为「高价值客户」这个说法，销售部的定义是年采购额超百万，客服部的定义是近半年工单少于两条且续约过一次，两套口径都存在知识库里，系统不知道该听谁的。
这就是语义层缺位。文档存下来了，但「业务里的概念到底指什么、它们之间什么关系」没有形成一层共识。少了这层，上层的 Skill 和连接器做得再花哨，也是建在沙子上。
一个常见现象：卡在「存下来」就不往上走了
按理说四层的道理不难懂。难的是现实里，想停在第一步，理由总是很好找。
报告第七章把这件事讲得很直白，叫本体层缺失的恶性循环：项目多、人手紧的时候，团队一定优先交付客户，沉淀永远排在后面；没有沉淀，下一个项目又得从零开始；效率低、人更累，于是更没有时间沉淀。这个循环一旦形成，规模化就没得谈了。
「项目多、人手紧」这六个字，在我们研究过的项目里反复出现。它听起来像是客观困难，往里看更像是优先级排序的结果——真要排，沉淀永远排不过本周要验收的功能。
更麻烦的是反馈链断在这一层。报告里的观察是：一线人员做完客户项目后，没有利益驱动把现场发现的新业务实体、新流程反馈给后端——考核只看项目有没有交付，不看对沉淀有没有贡献；而沉淀回来的东西要改、要发布、要培训，全是额外工作量。
于是就出现报告里说的那种评价：客户看到的是某几个工程师很能干，而不是这家公司的平台本身有价值。这几个人一旦离职，能力归零。
这里要补一句，避免误伤：「语义层缺失」不是指那个完整的重本体还没建。那需要客户规模和客单价撑着，急不来。它指的是更基础的问题——连最基本的术语标准化、Skill 积累、行业模板都没有，每次交付完全从零开始。这个程度的缺失才致命。
顺序不能反：先有 Skill，再有模板，最后才有完整语义层
那国内团队该怎么投？报告给的是分层投入，而且明确说了顺序。
第一步，任何行业都可以先做术语标准化和场景清单——把客户常见问题、业务对象和高频任务整理出来。这一步不需要客户规模，也不需要大投入，今天就能开始。
第二步，当同类客户达到一定数量，再把高频 Skill 组合成行业模板。
第三步，只有在客户数量、客单价和复用率都足够高的时候，才值得系统建设完整语义层。
报告里那句判断我原样抄下来：先有项目中的 Skill，再有跨项目的模板，最后才有系统化的本体层。顺序不能反。
我们观察到的一个常见做法是反过来走（包括我们自己早期也这么试过）：先花几个月把行业模型设计得漂漂亮亮，再拿去套客户。结果设计阶段没有真实项目喂，做出来的概念体系看着完整，一上现场全是空的——客户实际问的问题，一个都不在里面。
报告对这条路径也有个很务实的补充：不建「完整本体层」，不等于不做知识沉淀。 Skill、行业模板和轻量语义层，本身就是本体层的渐进形态。它们解决的是同一个问题——避免每次交付从零开始——差别只在于抽象深度和覆盖范围。
换句话说，本体层不是一套先验设计出来的宏大模型，而是从一个个真实项目里长出来的组织资产。这意味着小团队不必因为「我们建不起本体层」就干脆不沉淀。沉淀今天就能开始，只是不用一上来就想建个大的。
补充一个报告里提到的额外价值，我觉得对正在犹豫的团队有用：即使部分 Skill 未来被模型原生能力覆盖（报告观察到，过去需要复杂 Skill 才能完成的任务，新版本模型已经能直接处理），当下积累 Skill 仍有双重价值——短期直接服务客户，长期为模型能力提升提供行业语料和训练信号。所以这笔投入不会因为模型变强就白花。
一个容易踩的坑：以为 AI 让这层变便宜了
聊完路径，有个坑值得单独拎出来。
AI 确实降低了不少成本。报告第四章讲得很清楚，AI 同时改变了三项成本结构：行业知识蒸馏成本下降（一线人员能在现场直接写脚本、封装工具、搭原型，不用再排队等后方排期）、定制开发成本下降（从「理解业务、写需求、排期开发、测试上线」变成「理解业务、抽象语义、生成原型、现场验证」）、复合型人才供给成本下降（AI 工具补上了部分工程和文档能力）。
但语义层这一层，报告的态度是明确的：没有变便宜多少。
两个理由。
第一个是人工确认成本。即使有 AI 辅助抽取——从代码逆向、从设计文档自动生成——结果也需要领域专家逐条确认。报告里有一句话把这个成本讲得很清楚：AI 生成的结果可能 98% 是正确的，但要找出那 2% 的错误，人必须读完 100%。 所以别形成「AI 来了，建模成本就低了」的错觉。技术手段能加速初始抽取，最终确认和治理还是得靠人。
第二个是参照系不对。Palantir 那套本体（Ontology）耗时十余年、数百名专职工程师打磨，而且它的客户因安全许可要求天然有极高迁移成本，这在普通商业场景里不存在；它约 0.3% 的录用率带来的人才密度，也很难批量复制。拿硅谷六到七位数美元的年合同，去套国内大量仍在十万到百万人民币量级的项目，账根本算不过来。
所以报告给国内团队的建议也是「别照搬」：抓住核心逻辑——在数据与业务之间建立统一语义层——用更轻量的方式（Skill + 连接器 + 行业知识库）逐步逼近效果。
这也解释了开头那句判定为什么有效。AI 让工程执行变便宜了，但没有让判断变便宜，也没有让沉淀自动发生。工具越好用，「做出来」越容易，壁垒就越只剩下一样东西：你有没有把做过的攒下来。
适用边界
上面这套分层，来自公开研究报告的口径，加上我们自己复盘过的项目观察，两者混在一起用的地方我都标了出处，不是外部标准。
有几个边界要说明：
- 不是所有团队都要奔着完整语义层去。 客户数量、客单价、复用率三者不够高的时候，硬上就是浪费。做到术语清单和高频 Skill，对多数团队已经够用。
- 不同行业的数据底层差别很大。 报告也提到，国内多数企业的数据底层缺乏标准化治理，很多情况下语义不是从系统里「抽出来」，而是要在项目里「重新梳理出来」——这比想象中慢。
- 不同组织的资源禀赋和治理要求不一样。 四层怎么排优先级、每层投多少，得结合自身情况调，上面是参考框架不是标准答案。
如果手上资源有限、只能先动一件事，我会先做这个：把你们行业里最常见的 20 个术语和 10 个高频任务写下来，全团队统一口径。 不花钱、不用排期、不需要任何新工具，但它是四层里唯一一个「不做就永远没有」的东西。
三句话自检
- 第十个同类客户，还需要和第一个一样多的人月吗？
- 你们的产品边界，每个季度是在往「一次性交付」移动，还是往「产品」移动？
- 一线把新业务实体、新流程反馈回来，这件事在考核里算分吗？
前两问看结果，第三问看机制。第三问答不上来，前两问迟早会退化。
你们团队现在沉淀下来的，主要停在哪一层？欢迎在留言区说说，我挑典型的回。