01｜把采购问题写成一个真实任务
“需要一个 AI 工具”不是采购问题。“每周把三场客户访谈整理成带来源的需求摘要，并在周五评审前交付”才是。前者会把团队带进功能列表，后者能定义输入、输出、频率、负责人和完成标准。
先记录当前做法需要多少时间、涉及哪些工具、哪里经常返工。新软件只有在相同任务上减少成本或提高质量，才创造了可以验证的价值。
- 任务每月至少发生几次？
- 什么结果可以被接受，什么错误绝不能出现？
- 谁执行、谁审核、谁承担失败风险？
02｜先设淘汰条件，再看亮点
团队最容易被演示中的“惊喜功能”带偏。更稳妥的方法是先写三类硬条件：数据不能去哪里、必须接入哪些系统、年度成本不能超过多少。任何候选项不满足硬条件，就不进入评分阶段。
这一步会主动减少候选数量。对于小团队，三款经过筛选的工具通常比十款浅层试用更有效，因为真正昂贵的是上下文切换、配置和迁移。
03｜计算第一年的真实成本
月费只是可见成本。第一年总成本还包括席位增长、用量超额、必要插件、迁移、培训、实施、支付费率和退出时的数据导出。促销价应单独列出，不能直接当作长期价格。
建议同时计算三种情景：当前团队、团队扩大一倍、使用量扩大三倍。如果第二种或第三种情景会触发更高版本，就应在试用前知道，而不是续费时才发现。
- 正常续费价和促销结束日期
- 席位、联系人、项目、存储或额度的升级阈值
- 导出、取消和数据迁移成本
04｜用同一份任务做 7 天试点
所有候选工具都应使用相同输入、相同负责人和相同评分表。不要用厂商准备好的示例。真实材料会暴露权限、格式、语言、导出和协作问题。
至少让执行者、审核者和管理员各参与一次。执行者关注速度，审核者关注错误和可追溯性，管理员关注权限、计费和退出。三者看到的是不同风险。
05｜把“不购买”保留为正式选项
如果试点没有显著改善原任务，最合理的决定可能是继续使用现有流程。采购评审表应包含“保持现状”，否则团队会因为已经投入试用时间而勉强选择一个工具。
最终记录四件事：为什么选择、哪些假设仍未验证、何时复盘、什么情况触发退出。软件选型不是一次永久判断，而是一项可以被重新检查的运营决定。