第15章 CTO/CIO：技术底座、数据与采购决策

15.1 自建 vs 采购的判断框架

2023年3月，摩根士丹利宣布与OpenAI合作；同年9月18日，AI@Morgan Stanley Assistant 全员上线。约98%的投顾团队用上了它，约1.5万名投顾开始每天检索公司内部约10万份文档。

对CTO和CIO来说，这个案例最值得看的不是"用了哪个模型"，而是官宣到上线之间那半年。半年时间，大部分花在数据打通和工程改造上，不是"再想想做什么"。技术底座的真实构成就是这样：模型只是最上面一层，底下是数据、权限、流程和交付能力。

所以，技术负责人最纠结的"自建还是采购"，答案不取决于预算，取决于一句话：这是不是你的核心能力。模型可以买，数据与场景内的交付能力必须自建。

判断用三问。这能力是否构成你的业务差异？不是的话，说明它是公共能力，市场上买更划算。市场上有无成熟产品？有成熟产品还坚持自建，通常是在为技术自尊付钱。你能否承受锁定风险？供应商的模型可以换，供应商把数据和流程都吸走，代价你扛不扛得住。三个问题答案越靠"是、有、能承受"，越倾向采购。

三问还有个省事的用法：拿到立项申请，先让申请人自己答一遍，再让采购和法务各答一遍，三份答案对不上的那一问，往往就是项目真正的风险所在。下次评审会只讨论这一问，会议从辩论赛变成对答案，效率高得多（此为作者建议的评审动作）。

参考系是现成的。Palantir 把AIP平台化卖给客户，但驻场交付能力始终握在自己手里，靠着它签下美国陆军Maven智能系统4.8亿美元的合同。那是一纸驻场交付型合同，买的不是软件授权，是工程师进现场把系统跑起来。Glean、Sierra 这类公司，把企业搜索、客服Agent做成可采购的产品；但企业买下产品之后，仍然需要自己养"整合+落地"的人，把产品接进自己的系统和流程。

还要破一个误区：以为买了大厂平台就完成了AI落地。平台只是底座。第4章讲过选场景的分量，场景识别、数据打通、流程改造，这些才是成本的大头，也是平台买不来的部分。

四象限可以直接套用：横轴看市场上成熟不成熟，纵轴看对你核心不核心。四个格子，每格配一个判断问句。

核心且成熟，自建。判断问句：这项能力做好之后，竞争对手会不会因此紧张？会，就别外包。这是你的差异化来源，别人的产品再好，也贴不出你的业务。

非核心且成熟，采购。判断问句：市面上能不能至少找到三家供应商，比得了价、换得了人？能，说明它已经是公共能力，采购比自建便宜，也更快。

核心但不成熟，小成本试点再定。判断问句：这个不成熟，是全行业都不成熟，还是只有你不成熟？全行业都不成熟，反而可能是拉开差距的窗口，值得自己投人；只有你不成熟，先补课，别急着投入大额建设。

非核心且不成熟，先放一放。判断问句：一年之后这项能力变得又便宜又成熟，你会不会后悔今天投进去的钱？会，现在就别碰，把预算让给前面两格。

把这张四象限连问句一起贴在立项评审的第一个页面，很多争论当场就结束了。

四象限是动态的。今天不成熟的能力，跑通两个试点之后可能变成成熟，那时候要重新决策，而不是守着当年的结论不放。

15.2 模型选型与数据准备的优先级

CTO 的第二道坎：选哪个模型，先准备什么数据。

模型选型是次优问题，数据与场景是主优问题，这个结论有点反直觉。毕竟大多数失败不是模型不够强，而是数据没打通、场景没选对。模型能力正在趋同，选型的差别自然小于落地的差别。

摩根士丹利用的是GPT-4系模型，配RAG检索约10万份内部文档。RAG可以理解成"先检索再回答"：AI的每个回答，都要在内部文档里找到出处。这套方案能跑通约98%的投顾团队，靠的不是模型参数，是那10万份文档怎么被清洗、分块、打权限、嵌进投顾工作流。

数据准备的优先级，一句话：先打通业务主数据和高频交互数据，再谈模型微调。Palantir 的Skywise就是这样长出来的。约2015年，它的工程师驻进空客图卢兹总装线，A350正在产能爬坡，跨系统的数据对不上，总装线卡脖子。工程师把数据捋顺，这条经验在2017年产品化成了Skywise平台，到2024年底，约1.16万架在役飞机、140多家航空公司接入（据公开报道口径）；2026年2月，双方又宣布续约多年（据公司公告）。这个平台从数据打通起家，模型是后来越攒越厚的一层。

模型策略也一样：通用模型起步，场景验证之后再考虑专用模型或联合微调。Harvey 在律所行业做"深度定制、联合建模"，把一个行业的工作流改造成模型能处理的结构。这类垂直能力，是在联合建模和驻场协作里一点点磨出来的。

所以，给CTO的节奏是：把"数据就绪度评估"放在"模型选型"之前。评估用一张检查清单：数据在哪？谁拥有？能否出域？质量如何？四问里，"质量如何"最容易被跳过：数据在，也归你管，但脏到没法用，等于没有。四问答不全，先别急着比模型参数。

四个问题各给一个答法（口径为作者建议，按自家监管环境收紧）。数据在哪：说得出系统名和表名才算数，"大概在ERP里"等于不知道。谁拥有：能叫出一个可以为这项数据签字的人名，叫不出就是没人拥有。能否出域：按第9章先做数据分级，公开、内部、敏感三档，敏感档能不能脱敏后用，让法务给一句书面结论。质量如何：抽一百条真实记录人工过一遍，错漏超过一成，先治理再谈AI。这份清单不难填，难的是答到一半发现处处标红，那也是收获：至少钱还没花出去。

先问数据通没通，再问模型行不行。

15.3 对"万物Palantir化"的清醒认识

这本书把FDE讲了这么多，该听听反方的声音。

硅谷知名投资机构a16z提出过一个警告，叫"万物Palantir化"：大多数模仿FDE模式的公司，最后会沦为披着SaaS外衣的咨询公司。他们建议把FDE用在早期"脚手架"阶段，解决起步问题，而不是让它变成永久定制。

这个警告值得认真听。它戳中的是FDE模式最真实的软肋：驻场越深，越难从"项目"变成"产品"。如果一家公司只是把工程师派到客户那里，做一单算一单，不做产品、不做平台，那它和贵价的咨询公司没有区别。企业买AI也一样：只雇一群FDE来假装转型，而不是让FDE式的方法长进组织，钱花得越多，依赖越深。

"脚手架"这个词值得拆开看。它的意思是临时支撑：用来把房子立起来，房子立好后要拆掉，换成组织的骨架。a16z 反对的不是脚手架，是把脚手架当成永久建筑。

但反方观点也有它的盲区，Palantir 用二十年回答了它：驻场可以产品化。空客总装线上的驻场项目，长成了覆盖140多家航空公司的Skywise平台；AIP于2023年4月发布，用4到5天的驻场共创营做标准化入口，据其管理层称已举办数百场。商业客户成规模增长，收入结构从政府主导向商业主导迁移（客户数与增速，第8章、第10章详细讲过）。它的驻场经验，确实回流成了产品与平台。

对准备引进FDE式方法的企业，落地含义是：立项时就要设"方法内化"目标。这支队伍要能把自己做没，把能力留给业务。衡量标准很残酷，也很简单：换掉这批人之后，业务还跑不跑得动。跑得动，能力留下了；跑不动，你只是买了一次驻场。

本书的立场由此明确：提倡的不是"人人雇FDE"，是"人人掌握FDE式的交付能力"。

15.4 与六步法对应的技术管理节奏

技术管理要跟着业务节奏走，而不是反过来。六步法每一步，都有对应的技术动作和检查点。下面这张表，可以直接贴在技术团队的墙上。

几个检查点值得多说一句。这张表的用法是分层检查：90天试点过前四行，年度规划看全表；哪一行卡住，就回到对应章节补课。表不必一次全过，但每个检查点的答案要能落到人名和日期，落到"下次再议"就等于没过。

权限是早期最容易卡死的点。FDE小队没有生产权限，就只能做演示，做不了交付。第6章讲过POC和生产的区别，责任是其中一堵墙：敢不敢让驻场的人碰生产代码，决定了项目是演示还是生产。90天上线期，灰度、监控、回滚预案是"敢上线"的底气；没有回滚预案就上线，出了问题就没有退路。"能不能复制到下一个场景"是规模化和一次性的分水岭，第8章讲过横向复制，第二个场景的成本如果和第一个一样高，那复制只是重做项目。治理期的三道闸门，数据安全、内容合规、幻觉兜底，前两道对应的是权限模型，最后一道对应的是审计日志和幻觉兜底机制，都要在规模化之前落地，不能等出事再补。

技术节奏不是技术决定的，是业务节奏决定的。表里的检查点，本质上是把业务问题翻译成技术问题：真实数据、生产权限、真实用户、可复制、可审计。技术管理者的功课，就是提前把这五个翻译做完。

15.5 决策清单：技术负责人的五件事

第14章给了CEO五件事，这一节给技术负责人五件事，两节对着做，组织层面和技术层面就同步了。盘数据、定边界、立基线、配小队、设验收。五件事做完，技术底座就有了。

第一件，盘数据（对应15.2）：按候选场景输出数据就绪度清单，回答数据在哪、谁拥有、能否出域、质量如何。时限：第1到2周。交付物：数据就绪度清单。

第二件，定边界（对应15.1）：自建和采购各管哪一段，先划清楚，结论写进立项模板：哪些能力自建、哪些采购、哪些先试点。时限：第2周。交付物：立项模板里的边界条款。

第三件，立基线（对应第9章）：定数据安全与权限三道闸门的第一版，包括数据分级、访问权限、内容合规复核责任。时限：第2到3周。交付物：第一版权限与数据分级。

第四件，配小队（对应第5章）：与业务线共建FDE小队，确认四件事：成员名单、生产权限、汇报线、驻场差旅机制。权限这道坎怎么过，第5章讲过。时限：第3周。交付物：小队名单与权限表。

第五件，设验收（对应第7章）：立项模板里写死一条，验收用业务指标、业务Owner签字，纯技术验收不通过。时限：本月内。交付物：业务指标验收模板。

五件事都标了交付物和时限（附录F给了一组现成的OKR示例，照着换数字就能用）。衡量CTO，别数上线了几个项目，要看落地能力能不能复制。五件事做完，再看第16章那张九格自查表，很多格子已经自己填上了。