AI采购指南：购买能力，而非表演
一场精心打磨的AI演示，能让一个糟糕的采购决策显得在理智上不可避免。模型的回答干净利落，界面配着雅致的渐变色，还有人把“智能体”这个词说得足够频繁，以至于没人会去问：当客户输入了格式错误的数据、当某项政策发生变化、或当模型干脆就是错的，会发生什么。
这份AI采购指南的出发点没那么讨喜：采购不是一次供应商选型的工作，而是一次主张验证的工作。你买的不是一个品类、一项基准测试，也不是创始人的自信。你买的是一套必须在你的运营约束条件内产出可衡量结果的系统。
这一区别就能淘汰掉市场上出人意料的一大部分。
为什么AI采购在部署前就已失败
大多数失败的AI采购，从狭义上说并不是技术失败。模型可能按设计正常运转。真正的失败在于，没有人定义清楚它应当改进的那个决策、它必须挺过的那道工作流程，或它必须跨过的那道经济门槛。
采购团队常常被要求去验证安全性、商业条款和供应商的稳定性，而此时业务方早已爱上了那场演示。到那个时候，真正的决策其实已经做出了。剩下的不过是围绕一个未经检验的假设而进行的文书工作。
常见的症状我们都很熟悉。某位高管发起一项宽泛的“AI转型”倡议，却说不清瓶颈在哪。某个业务部门选中一款工具，只因为竞争对手看起来在用类似的东西。某家供应商拿出准确率数字，却不解释任务的分布、错误的严重程度，以及要达到这些数字所需的人工介入。所有人开完会都觉得自己很现代。
然后系统撞上了生产环境。用户必须手动清洗输入，采纳率就此停滞。推理和审核成本在推销时被排除在外，单位经济效益因此恶化。模型在技术上确实有用，却无法接入工作实际发生的那些系统。六个月后，这个项目被描述为一次“宝贵的学习经历”，这是企业用来形容“花大价钱来回避做决策”的说法。
AI并非独有这种问题。它只是格外擅长把问题藏在令人信服的输出背后。
这份AI采购指南从决策出发，而非从工具出发
在评估供应商之前，先定义你需要改进的那个运营决策。不是愿景，不是“提升生产力”，而是一个有归属人、有基线、且一旦出错就有后果的决策或工作流程。
举例来说，一个客服团队可能需要减少起草常规回复所花的时间，同时不增加升级工单量。一个信贷工作流程可能需要从文档中提取特定字段，同时保留可审计的审核路径。一个数据平台可能需要帮助分析师更快地识别出故障的数据管道，并给出确凿的证据，而不是听起来合理的解释。
这些是不同的采购问题。它们需要不同的数据访问权限、延迟要求、评估方法、权限设置，以及对错误的容忍度。把它们当成同一种笼统的AI需求，正是团队最终花大价钱为一个本该重新设计工作流程的问题买了个昂贵文本框的原因。
采购说明书应当用平实的语言回答四个问题：
- 究竟哪项任务或决策会发生改变？
- 成本、速度、质量或收入的当前基线是什么？
- 什么样的错误可以接受，什么样的错误在商业上或运营上无法容忍？
- 上线之后由谁对结果负责？
如果这些答案含糊不清，就不要启动供应商流程，而要启动内部调研。供应商无法提供你自己拒绝去建立的内部清晰度。
在销售叙事最薄弱的地方检验系统
每家供应商都有自己偏爱的证明点。它可能是一项基准测试、一个招牌客户的品牌标识、一套令人印象深刻的模型架构，或是在理想条件下展示的工作流程。这些都不是毫无用处的，但也都不足以作为依据。
采购的职责，是把评估推向供应商宁愿留到以后再谈的那些条件：杂乱的源数据、边缘情况、用户行为、集成依赖、规模化后的成本，以及输出出错时的追责问题。
要求一套有代表性的评估数据集
不要把一次通用演示当作契合度的证据。提供一份受控的真实工作样本，按需做脱敏或保护处理，其中既要包含常规案例，也要包含最可能造成运营损害的案例。
目的不是要给供应商下套，而是要判断这款产品能否在你的环境中产出价值。一个在干净、常见的输入上表现良好的系统，仍可能是正确的采购对象。但你需要知道它会在哪里崩溃，以及这次崩溃会付出什么代价。
衡量的不只是模型准确率。要追踪完成率、审核耗时、纠正率、升级率、用户接受度，以及每完成一项任务的成本。如果一款产品声称消除了一个工作流程环节，却创造了一个新的验证环节，那就把这个验证环节也算进去。人力不会因为被从幻灯片上挪走就凭空消失。
把能力与集成区分开
一个模型可以确实有能力，却仍然对你的组织来说是一款糟糕的产品。如果实施需要数月的定制编排、一条脆弱的第三方依赖链，或一个根本不存在的内部小团队，那么这项能力对你来说还无法部署。
要问清楚：哪些是原生的，哪些是配置出来的，哪些是定制开发的，以及上线后客户必须自行运营哪些部分。这些不是语义上的差别。它们决定了时间表、支持负担、切换成本，以及供应商报出的价格与总成本之间是否还有半点相似之处。
这一点对智能体类产品尤其重要。“自主”可以指任何东西，从一套带审批关卡的实用工作流程，到一串需要人工不断救场的松散提示序列。要问清楚异常处理路径。要问清楚各项操作是如何被记录、撤销和归因的。要问清楚：当系统在上下文不完整的情况下采取行动时，由谁负责。
如果得到的答案本质上是“模型会随时间越来越好”，那你拿到的不是一份运营计划，而是一份天气预报。
诚实地为人力层定价
人工审核并不能证明一款AI产品失败了。在许多高风险后果的工作流程中，审核恰恰是正确的设计。问题在于，供应商是否诚实地说明了这道审核处在哪个环节、由谁来买单。
一个有用的采购模型应当包括软件费用、实施费用、数据准备、集成维护、推理或使用费用、内部监督，以及残留的人工审核。它还应当包括：当系统不可用或不确定时，那套后备流程的成本。
正确的采购对象仍可能带有相当分量的人力层。当它能提升吞吐量、一致性或决策质量时，这是合理的。但“人在环中”应当描述一种经过设计的控制机制，而不是一笔隐藏的人力补贴，用来撑住一款不可靠的产品不倒。
购买与不确定性相匹配的商业结构
长期合同常被用来营造一种坚定的假象。它们更多制造的，是在证据出现之前就形成的锁定。
对于一项尚未得到验证的工作流程，应围绕一个狭窄的生产成果来设计初期合作。在试点开始之前，先定义好用户群体、集成边界、评估窗口、成功指标、支持预期和退出条款。一个没有事先商定的决策规则的试点，只不过是一场附带采购订单的演示。
要避免那种旨在证明“技术能产出输出”的试点。那个问题在销售电话打来之前就已经有答案了。试点应当确立的是：在真实运营条件下，这套系统能否改变某个业务指标，以及组织能否支撑得起它。
扩大合作应当取决于观察到的价值，而不是供应商起草的客户拓展计划。如果使用量在增长，但纠正率居高不下，不要把活跃度误当成采纳度。如果一个团队很喜欢这款工具，却说不清它的经济影响，就不要称它为战略性的。用户情绪是有用的，但它不是商业论证。
对于投资人和董事会而言，在尽职调查中同样适用这套纪律。要问清楚：收入反映的是可复制的部署，还是少数几个高度依赖人工支持的项目。要按队列检视留存率、实施周期、服务密集程度、扣除模型和支持成本后的毛利率，以及产品嵌入客户工作流程的深度。一家公司可以拥有真实的收入，却仍然是在用AI叙事兜售定制人力。
一家可信的供应商应当乐于接受什么
最强的供应商不会反感尖锐的问题。他们会解释自己的失效模式，提供实施假设，把当前产品与路线图区分开来，并在你的应用场景界定不清时提出反对意见。这不是阻力，而是对方有人真正理解部署的证据。
要警惕过早到来的笃定。任何严肃的运营者，在不了解你的数据、系统、用户和治理约束之前，都无法保证结果。自信是有用的，但毫无保留的自信通常是一项销售资产，而非运营资产。
目标不是买下看起来最安全的产品，也不是因为某些局限而惩罚供应商。目标是买下一套你能管理其局限、并能验证其价值的系统。这才是深厚的技术能力如何变成受信任、能创收的基础设施，而不是又一个所有人都礼貌地不再提起的倡议。
一个好的采购流程，在开始阶段偶尔会让人觉得慢一些。但它仍然快过用一年时间去发现：你这次AI采购唯一实现自动化的，是它自己预算的审批。
您的领导方式在哪里有效，又在哪里正在消耗公司？
这个博客讨论的多数问题，最终都回到创始人如何经营公司这一点上。藤架领导力诊断把它拆成六个维度共24道行为锚定题：约12分钟，即时出结果，自助版免费。
开始藤架领导力诊断 →想了解兼职高管或顾问合作？预约探索性通话 →