6.1 AI 战略与就绪度

概述与动机

人工智能已经从一项研究新奇事物，转变为大型组织如今被期望能够负责任地、大规模部署的核心能力。对企业和政府机构而言，真正的问题已不再是 AI 能否在演示中展现出令人印象深刻的效果，而是某项具体投资能否比其他方案更好地解决一个真实问题，能否安全地运行多年，以及能否经受住审计、采购和公众监督的考验。AI 战略是这样一门学科：决定在哪些地方应用 AI、在哪些地方避免使用它，以及在第一个模型进入生产环境之前，你需要打好哪些基础。

对于大型团队来说，规模和惯性会放大风险。一个构思不当的项目可能烧掉预算、分散优秀工程师的精力，并在公开失败时侵蚀监管机构和公民的信任。而一个选择得当的项目则可以自动化繁琐工作，从你以前根本无法触及的数据中挖掘洞见，并把熟练人才解放出来做更高价值的工作。二者的差别很少在于模型本身，而在于你对问题的框定有多好、你的数据和人才准备得有多充分，以及你的商业理由有多诚实。

政府和受监管环境增加了更多约束。公共机构必须为支出提供正当理由、保证透明度、避免非法歧视，并对民选官员和公众负责。采购规则可能禁止唯一来源锁定，要求可解释性，并要求供应商公开模型行为。在这种环境中，要把合规性、可审计性和退出方案作为一等要求，而不是事后才想到的东西。

关键原则

从一个值得解决的问题出发，而不是从一项在寻找用途的技术出发。
优先选择能满足需求的最简单方案；AI 只是众多选项之一，而且往往不是最佳选项。
把数据就绪度、人才和平台成熟度当作先决条件，而不是可以留到以后再处理的并行工作流。
明确做出自建还是购买的决策，并随着市场和自身能力的变化重新审视这些决策。
量化总体拥有成本，包括运维、监控和最终的替换，而不仅仅是许可证或试点费用。
从第一天起就为退出而设计：避免那些会让切换供应商或模型代价高得离谱的架构。
在受监管和公共环境中，把透明度、采购合规性和问责制当作设计约束条件。
把不采取行动的成本，与采取行动的成本一并衡量。

建议

在选择技术之前先界定问题

写一份单页的问题陈述。指出你想改进的决策或任务、当前的基线、你想要的可衡量成果，以及系统出错时会发生什么。然后问一问这个问题究竟是否适合用 AI 来解决。是否有足够的相关数据？这项任务是基于模式而非基于规则的吗？你能否容忍概率性的答案？人是否可以检查输出结果？许多问题用确定性软件、更好的流程设计，或者仅仅是更好的数据卫生习惯就能更好地解决。明确写下 AI 不适合的场景：例如，法律要求必须完全可解释的决策，或者罕见错误的代价是灾难性的、且无法被察觉的场景。

使用”自建还是购买还是微调还是提示”的决策树

按从最便宜、最快，到最昂贵、最可控的顺序推进：

对现成的托管模型进行提示。 如果一个通用模型（例如 Anthropic 的 Claude，或其他提供商的类似产品）通过精心设计的提示和检索就能解决问题，那就优先这样做。成本最低，迭代最快，无需训练基础设施。
用检索或工具进行增强。 如果差距在于知识或行动能力，那么在触碰模型权重之前，先加入检索增强生成（RAG，在查询时获取相关文档并将其作为上下文提供给模型）和工具使用。
微调或适配。 如果仅靠提示无法持续达到所需的准确度、语气或格式一致性，就在你自己的数据上对一个较小的模型进行微调：也就是说，在一个预训练模型的基础上，用你自己的样本进一步训练，使其专业化。这样做能换来更多控制力，代价是需要一套 MLOps（机器学习运维）流水线。
购买专业化产品。 对于定义明确的领域（文档处理、欺诈评分），一款成熟的供应商产品可能胜过任何你自己构建的东西。
从零开始构建。 把训练基础模型（在广泛数据上预训练、可适配多种任务的大模型）这条路，留给那些拥有独特数据、深厚人才储备和战略理由的组织。对几乎所有企业和机构而言，这都是错误的选择。

建立数据、人才和平台方面的先决条件

审计你的数据在可获取性、质量、标注、血缘和使用的法律依据方面的状况。确认你确实拥有将其用于 AI 的权利，包括任何个人数据或第三方数据。诚实地评估人才现状：你不仅需要数据科学家，还需要机器学习工程师、数据工程师、能理解概率性系统的产品经理，以及能够评估输出结果的评审人员。在规模化之前，先搭建一套平台基线：实验跟踪、模型注册表（用于记录已训练模型版本及其批准状态的权威系统）、监控，以及安全的服务能力，这样每个新用例就不必重新发明一遍运维体系。

审慎处理受监管和政府环境

尽早引入采购、法务和风险团队。要求供应商披露模型来源、训练数据实践、评估结果和已知局限性。优先选择能授予你的数据和提示可移植性的合同，避免使用会把你困住的专有格式。在适当的情况下，公开面向公众的 AI 系统的用途和保障措施，并为人们提供一个申诉自动化决策的渠道。对齐公认的框架（见第 6.5 章），这样审计时就能找到一套有文档记录、站得住脚的流程。

计算总体拥有成本，并防范被供应商锁定

对全生命周期成本建模：推理或许可费用、数据流水线、人工评审、监控、再训练、事件响应和退役。将其与维持现状的成本以及各种替代方案的成本进行比较。通过把模型置于一个内部接口之后、保持提示和评估数据集的可移植性，并不时测试第二家供应商，来降低被锁定的风险。

权衡：优缺点

方式	优点	缺点	最适合的场景
对托管模型进行提示	快、便宜、无需基础设施、易于切换	控制力较弱、按调用计费、存在数据共享方面的疑虑	原型、通用任务、需求尚不确定
检索增强	让答案立足于你自己的数据、可更新	检索质量难以保证、增加基础设施	知识密集型任务
微调较小的模型	可控性强、在规模化后单次调用成本更低、可选择本地部署	需要 MLOps、数据和持续维护	稳定、高流量、专业化的任务
购买产品	成熟可靠、有支持、能快速见效	许可成本、被锁定、适配范围有限	定义明确的通用型问题
构建基础模型	最大程度的控制力和差异化	成本巨大、人才稀缺、风险极高	几乎从不适用，前沿实验室之外基本不会用到

主要的权衡在于控制力与成本和速度之间的取舍。提示方式带给你最快的速度和最大的灵活性，但控制力最弱；自建带给你最强的控制力，但需要耗费大多数组织不应承担的资源。大多数大型团队应当处于中间地带：先用提示和检索，有选择地进行微调，对通用需求则购买现成产品。被锁定是用短期便利换取长期风险，而这一点在政府领域尤其重要，因为那里常常存在多年期的退出义务。

与团队讨论的问题

我们排名前三的候选用例，分别处于”先提示、再检索、再微调、再购买、最后才自建”这个阶梯的哪一级，什么证据能让它上移或下移一级？ 这一点很重要，因为大多数被浪费的 AI 支出，都来自于一开始就站得太高：本来精心设计的提示就能奏效，却去训练一个模型。对于大型团队来说，就这个阶梯达成共识作为共同默认标准，能防止每个小组各自重新发明一套昂贵的流水线。为每个候选用例带来那份单页问题陈述、当前基线，以及对差距究竟是知识性的（检索）、一致性的（微调），还是一个已有解决方案的通用问题（购买）的诚实判断。在企业和政府环境中，还要加上每一级的采购和审计成本，因为一个微调模型会拖带一套托管调用所没有的 MLOps 负担。讨论的结果应当能让在场的人至少砍掉或降级一个范围设定过大的项目。
对于我们最依赖的供应商或模型，我们具体的退出方案是什么，我们真的测试过它吗？ 被锁定这件事，接受起来很便宜，解脱起来却很昂贵，而在政府领域，你可能背负着多年期的退出义务，如果从未演练过，就根本无法履行。带来你所依赖的专有功能清单，说明提示和评估数据集是否具有可移植性，以及模型是否被置于一个内部接口之后（或者并没有）。需要关注的信号是：是否有人曾经把你的评估套件跑在第二家供应商上；如果没有，你的退出方案就只是一种奢望，而不是一个真正的方案。如果诚实的答案是切换需要数月时间、还要重写核心代码，那就应当把它当作一个需要现在就修复的设计缺陷，而不是留到以后再跨越的一座桥。
一份诚实的就绪度记分卡，对我们的数据权利说了什么？今天它会排除掉哪些用例？ 跳过数据就绪度评估，正是那种会悄悄拖垮试点项目的失败方式：模型能用，但你从来没有使用这些数据的法律依据，或者数据没有标注、也没有血缘记录。对于大型组织来说，个人数据和第三方数据会带来因司法辖区和数据集不同而各异的同意与合同限制。为每个候选用例带来一份关于可获取性、质量、标注、血缘和法律依据的审计结果，并愿意把一些用例明确标记为”在数据基础打好之前予以阻断”。在受监管和公共环境中，一个站不住脚的法律依据不是一个延误，而是一个硬性停止点，为就绪度工作提供资金应当是计划中的明确一项，而不是事后才想到的补充。
我们如何知道一个正在运行的 AI 用例真的有效，什么样的证据会让我们决定终止它？ 大多数 AI 项目组合都会积累一批”僵尸项目”：已经上线、曾让某人印象深刻、如今却永远运行下去，没有人再去检查它是否还值得付出的成本。在上线前就商定基线和成功指标，然后设定一个明确的终止阈值，这样叫停的决定是提前定好的，而不是临场辩护出来的。带来当前的指标、每个结果所需的人工监督成本，以及自上线以来观察到的漂移情况。对于企业和政府的项目组合来说，要明确谁按固定节奏评审每一个系统，谁有权将其淘汰；一个没有人负责评审的用例，就是一个永远不会被关掉的用例。
人在哪里留在决策环路中，这种监督的成本是多少，我们真的为此做了预算吗？ 那些表面上看起来最便宜的 AI 用例，往往是悄悄假设完全自动化的那些，随后现实又通过评审、纠正和升级把成本一点点渗漏回来。要有意识地决定哪些决策必须由人来确认，哪些模型可以独立做出，哪些模型永远不得做出，然后为这背后隐含的人工时间定价。带来低置信度案例的数量、答错一次的代价，以及当前的升级路径。在受监管和公共环境中，把每一项自动化决策与一位负责的官员和一条申诉途径绑定起来，因为你无法描述清楚的监督，就等于没有监督。
我们是否拥有运行所提议方案所需的人才和平台，还是在悄悄假设自己拥有实际并不具备的能力？ 雄心勃勃的 AI 计划失败的原因，往往不在于模型本身，而在于那些不起眼的基础工作：没有人维护流水线，没有人能评估输出结果，没有平台可供部署。把每个候选用例与它实际需要的技能和基础设施进行匹配，并诚实地说明差距究竟是需要招聘、需要合作伙伴，还是根本不应该构建的理由。带来一份清单，说明谁能在生产环境中拥有每个系统的所有权、它将运行在什么平台上，以及你需要外购哪些能力。对于大型或公共组织来说，还要加上采购和招聘的前置周期，因为一个依赖你在相关时间窗口内根本招不到的人才的计划，注定会交付不足。

行业视角

初创企业。 速度和生存压倒一切。选择一个触及你核心价值、范围狭窄的用例，把它建立在一个托管模型之上、包一层薄薄的接口就上线，并严格控制支出上限。避免自建基础设施或训练模型：你最稀缺的资源是工程注意力，而一条你维护不起的微调流水线是负担，不是护城河。保持切换成本低廉，这样你才能跟上快速变化的市场。

小型企业。 你很可能没有数据科学家，预算也很紧张，所以要把 AI 当作嵌入在你已经在用的工具里、直接购买的东西，而不是一个需要配备专职人员的项目。把就绪度问题框定为数据卫生和隐私问题，而不是一个机器学习项目：清楚你持有哪些客户数据、你被允许用它做什么，以及一个错误的自动化答案在哪里会让你失去一位客户。优先选择那些让 AI 功能可选、透明、且易于关闭的供应商。

企业。 这里的问题是跨众多团队的组合治理：一套共享的自建 / 购买阶梯、一致的就绪度评估，以及锁定风险和总成本分析，从而让各团队不再各自重新发明昂贵的流水线。明确为 MLOps 和人工监督的负担做预算，把接口层标准化以保持供应商可替换，并把各个 AI 用例作为一个有明确指标和终止标准的项目组合来管理，而不是一堆零散的试点。

政府。 透明度、采购规则和问责制塑造着每一个选择。优先选择引用官方来源而非生成政策的系统，让一名人员对重大决策负责，并在合同中要求数据可移植性和模型局限性的披露。发布一份通俗易懂的说明和一条申诉途径，兑现你签署的任何多年期退出义务，并让 AI 远离那些必须由负责官员做出的最终评估决策。

示例

初创企业。 一家五人规模的排班初创公司，想要增加一个自然语言的”帮我预订会议”功能，又不想把两位工程师从核心产品上抽调开。它选择了一个最小但重要的问题（）把一个请求解析成一个建议的时间（）并借助一个托管模型、通过一层薄薄的内部 API 上线，以便日后可以切换供应商。团队设定了严格的月度支出上限，跟踪用户是否接受建议的时间，并约定只有当使用量真正证明值得投入额外工作时，才重新考虑微调模型。

企业。 一家跨国保险公司希望加快理赔分诊速度。它没有去训练一个定制模型，而是把问题狭窄地界定为（对收到的理赔申请进行分流和摘要），用一个托管模型加上对其保单文档的检索来做原型，并将其与人工处理的时间和准确度进行比较。只有在证明了价值之后，它才为流量最大的理赔类型微调了一个较小的模型，以降低单次调用成本。它把模型置于一个内部 API 之后，以便能够更换供应商，并对包含低置信度案例人工评审在内的三年期总体拥有成本进行了建模。

政府。 某国税务机关考虑引入一个 AI 助手，帮助工作人员回答公民的咨询。由于这些答案涉及法律义务，该机构坚持要求透明度：系统只能引用带有出处的官方指引，绝不能凭空编造政策，并且每一条自动化建议在发出之前都要经过人工审核。采购要求供应商披露模型的局限性并授予数据可移植性，该机构还发布了一份关于该系统的通俗说明和一条申诉途径。它把 AI 完全排除在最终评估决策之外，这类决策专门保留给负责的官员。

商业理由：动机、投资回报率与总体拥有成本

AI 战略的存在，是为了帮助你避免两种互为镜像的失败：在永远无法回本的 AI 上过度投资，以及在竞争对手或同行机构领先时投资不足。投资回报来自节省的人力、缩短的周期时间、降低的错误率，以及新启用的能力。要把这些与一个真实的基线进行比较衡量，并为人工监督这项几乎不会消失的真实成本打个折扣。

总体拥有成本必须包括那些不起眼的项目：数据流水线、监控、随着世界变化而进行的再训练、安全评审，以及最终的退役。一个看起来便宜的试点，一旦按规模运行多年，可能会变得昂贵。也要呈现出不采用的成本：更慢的服务、更高的人工成本，以及战略层面的落后。向领导层论证时，采用一种组合视角：少数几个高置信度的投注、明确的成功指标、失败时的终止标准，以及一份表明数据和人才基础确实存在的就绪度评估。要求领导层明确为就绪度工作拨款；如果跳过这一步，就必然会招致代价高昂的返工。

反模式与陷阱

在寻找问题的解决方案。 因为同行都在做而购买 AI，然后再去寻找一个用例。
跳过数据就绪度评估。 在不可获取、未标注或法律上不可用的数据上启动模型。
由演示驱动的决策。 仅凭一场精美的演示就做出承诺，而没有经过生产质量的评估。
忽视人工监督环节。 假设完全自动化并低估评审预算，而这恰恰是大部分成本隐藏的地方。
悄悄发生的锁定。 深度依赖某一家供应商的专有功能，却没有退出方案。
低估运维工作。 把部署当作终点，而不是维护义务的起点。
把合规当作事后补充。 在设计完成之后才补做透明度和可审计性，代价往往成倍增加。

成熟度模型

启动。 临时性实验，没有共享战略，决策由炒作和个人热情驱动。
发展。 部分项目已有问题框定；出现了第一版平台基线；自建还是购买有所讨论，但不一致。
标准化。 拥有一个具备明确指标的 AI 用例组合、一套有文档记录的决策树、就绪度评估，以及在各团队间一致应用的锁定风险和总体拥有成本分析。
管理。 对该组合进行度量：就绪度、投资回报率、总体拥有成本和人工监督成本都会与基线进行对比跟踪；终止标准基于证据得到执行；交付和质量影响驱动每一次继续或叫停的决策。
协同。 AI 战略与业务和风险规划深度整合；就绪度得到持续维护；组织会根据证据，常态化地淘汰、替换和重新界定 AI 系统的范围，并随着市场和风险状况的变化重新平衡整个项目组合。

讨论思路

你如何判断一个问题确实不适合用 AI 解决，谁有权说”不”？
什么样的就绪度门槛，应当决定一个项目能否从试点走向生产？
为了换取更快见效的时间，多大程度的锁定是可以接受的？
在政府领域，透明度义务应当如何影响自建还是购买的选择？
当供应商和热情推动者都有动机低估总体拥有成本时，你如何保持这些估算的诚实？
谁拥有这个 AI 项目组合，终止决策是如何做出的？

关键要点

战略从一个真实的问题和一个诚实的基线出发，而不是从一项技术出发。
优先选择最简单的选项：先提示，再检索，再微调，再购买，很少从零开始自建。
数据、人才和平台的就绪度是先决条件；为它们提供资金是计划的一部分。
受监管和政府环境要求在设计之初就纳入透明度、采购合规性和退出方案。
对完整的总体拥有成本和不作为的成本进行建模，并从第一个架构决策开始就防范供应商锁定。

参考文献与延伸阅读

Ajay Agrawal、Joshua Gans、Avi Goldfarb，《Prediction Machines: The Simple Economics of Artificial Intelligence》。
Eric Siegel，《The AI Playbook: Mastering the Rare Art of Machine Learning Deployment》。
Andriy Burkov，《The Hundred-Page Machine Learning Book》。
美国国家标准与技术研究院（National Institute of Standards and Technology），《AI Risk Management Framework (AI RMF 1.0)》。
经济合作与发展组织（Organisation for Economic Co-operation and Development），《OECD AI Principles》。
Thomas H. Davenport，《The AI Advantage: How to Put the Artificial Intelligence Revolution to Work》。