一个团队引入 AI 辅助工具，试用期两周，几个人说"挺快"，于是全员开通。三个月后复盘：代码产出涨了，评审时间也涨了；没人能说清到底省了多少，也没人知道怎么退。
AI 工具与普通工具的差别不在"是不是新技术"，而在输出不确定、验证成本不可忽略、成本随使用量增长。这三点决定了它不能按常规选型流程评。
1. 与普通工具评估的差别
| 维度 | 普通工具 | AI 工具 |
|---|---|---|
| 输出确定性 | 同输入同输出 | 同输入不同输出，质量波动 |
| 验证成本 | 低，跑一遍用例即可 | 高，产出需要逐条核对 |
| 成本结构 | 固定（授权/席位） | 按量增长，随使用规模放大 |
| 收益可归因 | 容易（替代了哪一步） | 难，混在整体产能里 |
| 退出难度 | 中 | 中，但历史产出留痕 |
最后一点常被忽略：普通工具卸载即可；AI 的产出已混进代码库，退出时不只要停订阅，还要决定历史产出怎么处理。
因为验证成本高，"感觉快"不是结论：生成快而核对慢时，总时长可能不变，甚至更长。
2. 试用的三个要素
| 要素 | 要求 | 缺失后果 |
|---|---|---|
| 任务清单 | 明确列出要试的具体任务类型 | 试用变成随便用用 |
| 基线组 | 同任务的传统做法耗时 | 无法判断净收益 |
| 验收判据 | 每个任务的通过标准 | 结论只能靠印象 |
// 试用任务清单（示例：后端服务开发）
T1 新增一个 REST 接口：含参数校验、单元测试
T2 定位一个线上异常的根因：给定日志与代码
T3 重构一个长函数：保持行为等价
T4 为既有代码补测试：覆盖分支
T5 跨模块改动：查清全部调用点并改完
判据：T1/T3/T4 看通过率与返工率；T2 看定位是否可复核；T5 现阶段大概率不适合
试用清单要含预期会失败的任务，只挑适合的就没有参考价值。
3. 端到端时长与返工
省时的错觉大多来自只计"生成"这一步。判据必须是端到端：从提出问题到产出可用。
// 单任务计时口径（人分钟）
t_total = t_理解需求 + t_生成 + t_核对 + t_修正 + t_提交
省时判据：t_total_ai < t_total_base
返工定义：交付后一个迭代内因质量问题被回改的部分
| 环节 | 传统做法 | AI 做法 | 观察重点 |
|---|---|---|---|
| 理解需求 | 熟手快 | 需要写清提示 | 提示质量决定下限 |
| 生成 | 人写 | 秒级 | 不构成瓶颈 |
| 核对 | 抽检 | 必须逐条核对 | 最容易被低估 |
| 修正 | 少量 | 常见，含"看似对" | 隐性返工来源 |
结论要按任务类型分别给：不同任务的净收益可能差一个数量级，"整体快了 X%"会掩盖唯一有用的信息。
4. 试用期该观察什么
| 观察项 | 记录方式 | 用途 |
|---|---|---|
| 谁在用 | 按人/角色统计活跃 | 判断是普适工具还是少数人的工具 |
| 用在哪一步 | 任务环节打点 | 定位真实收益点 |
| 返工率 | 被回改比例与原因分类 | 判断质量成本 |
| 弃用点 | 什么情况下不再用它 | 铺开时的边界说明 |
| 时间分布 | 按周活跃变化 | 判断新鲜感消退后的留存 |
弃用点最有价值：用户在哪一步放弃使用，直接指出当前能力的硬边界，也构成"能说出不适合什么"的依据。另一点是新鲜感会造假数据，至少要跨过一次真实上线。
5. 铺开的门槛：能说出不适合什么
| 门槛 | 合格形态 | 不合格形态 |
|---|---|---|
| 适用范围 | "适合 X、Y，不适合 Z" | "挺有用，建议推广" |
| 边界依据 | 弃用点与返工记录 | 个人感觉 |
| 责任约定 | 产出质量由谁负责 | 默认"工具"负责 |
| 评审要求 | 哪些改动必须人工复核 | 无差别对待 |
| 数据约定 | 什么内容不能进提示 | 无规定 |
判据只有一句：能说出不适合什么，才算能推广。说不出来，说明试用只取得印象没取得边界，之后每次误用都要靠个案纠正。
6. 成本构成
// 年成本构成（人月 + 费用，避免只算订阅）
cost = 席位/调用费 + 集成与配置 + 培训
+ 评审增量（核对与返工）+ 合规与审计 + 退出成本
判据：cost <= 省下的工时折算 + 质量改善可计价部分
评审增量最常被漏算，而它随铺开范围线性增长
| 成本项 | 形态 | 漏算后果 |
|---|---|---|
| 调用费 | 按量或席位 | 铺开后预算超预期 |
| 集成 | 编辑器/CI/网关配置 | 一次性支出摊进日常 |
| 培训 | 提示写法与边界约定 | 用不起来就归因于"工具不行" |
| 评审增量 | 每个产出都要看过 | 产能提升被评审吃掉 |
| 退出 | 产出清理与流程回调 | 引入时完全不估 |
最后一项与"退出条件要在引入时写"是同一件事的两面：退出成本不知道，就没有真正的引入决策，只有一次不可逆的尝试。
7. 数据与代码边界
| 内容类型 | 可否进提示 | 理由 |
|---|---|---|
| 公开文档与依赖源码 | 可 | 无泄露面 |
| 自研非核心代码 | 视网关与协议而定 | 取决于是否留存、是否用于训练 |
| 生产数据样本 | 不可 | 脱敏不彻底即等于泄露 |
| 密钥、令牌、内网地址 | 不可 | 一次性误贴就会长期留存 |
| 客户标识与个人信息 | 不可 | 合规面最大 |
边界要写成可执行的规则："不要贴敏感信息"没有可操作性；"提交前跑扫描，命中即阻断"才是。规则之外还要有兜底——误贴之后怎么办，否则等于把责任推给个人自觉。
8. 退出条件要在引入时写
| 退出信号 | 判据形态 | 触发动作 |
|---|---|---|
| 净收益为负 | 端到端时长连续两个周期无改善 | 缩减范围或停用 |
| 评审负担过重 | 评审时长增长超过产能增长 | 限定使用场景 |
| 质量事故 | 因未复核产出导致线上问题 | 强制复核或停用 |
| 成本失控 | 费用超预算阈值 | 降级为席位制 |
| 协议变更 | 数据条款不利变化 | 评估替代方案 |
// 退出条件模板（与引入提案同页）
trigger: 连续 2 个迭代的 review_p50 涨幅 > 产出涨幅
action: 从强制使用降级为可选
fallback: 保留个人席位，关闭 CI 集成
cleanup: 删除自动生成的代码注释标记，恢复人工评审门禁
owner: 平台组，季度复核一次
有模板后，"退"是可执行动作，而不是一次需要重新说服所有人的争论。
9. 团队级与个人级的差别
| 维度 | 个人级 | 团队级 |
|---|---|---|
| 决策依据 | 个人体验 | 端到端数据 |
| 风险承担 | 自己 | 团队与客户 |
| 边界要求 | 自我约定 | 明文规则与审计 |
| 评审要求 | 常规 | 需明确哪些改动强制复核 |
| 退出成本 | 低 | 含流程与培训回滚 |
个人级可以"想用就用"；团队级每条规则都在替别人承担后果，因此必须写清。常见错位是把个人体验当团队结论：几个人的正反馈直接放大成全组织推广，跳过边界、评审与成本验证。
10. 供应商锁定与可换性
| 锁定点 | 检查方式 | 缓解做法 |
|---|---|---|
| 提示与配置 | 能否导出为通用格式 | 用可迁移的模板文件保存 |
| 集成深度 | CI/编辑器插件是否唯一入口 | 保留命令行直调路径 |
| 历史产出 | 产出是否带工具专属标记 | 标记规范化、可批量清理 |
| 模型可换 | 能否替换后端模型 | 经自有网关转发 |
// 可换性检查的最小动作
// 1) 提示与规则文件是否在仓库里，而非只在平台内
grep -rl "prompt\|rules" .config/ prompts/ 2>/dev/null | head
// 2) 是否保留绕过平台直调的路径
command -v PROVIDER_CLI || echo "no direct path"
// 3) 产出标记是否可批量识别与清理
grep -rn "GENERATED_BY" src/ | wc -l
判据：换掉供应商需要多久。答案是"几天"，锁定只是成本；是"几个月"或"无法估"，引入决策已实际不可逆。
11. 度量
| 指标 | 定义 | 用法 |
|---|---|---|
| adoption_rate | 周活跃占总人数比 | 判断是普适工具还是小众工具 |
| rework_rate | 一个迭代内被回改的产出占比 | 判断质量成本 |
| review_p50 | 评审时长的中位数变化 | 判断评审是否被吃掉 |
| exit_cost | 换供应商所需人天 | 判断锁定程度 |
| 边界命中率 | 误用被规则拦下的比例 | 判断规则是否有效 |
指标要一起看：只看 adoption 会推广高返工的工具，只看 rework 会否掉在特定任务上确实有效的工具。
12. 排错：引入评估的六种现场
| 现象 | 原因 | 处理 |
|---|---|---|
| 都说有用但算不出收益 | 只测生成，不测端到端 | 换成端到端计时口径 |
| 试用数据漂亮，铺开后回落 | 新鲜感 + 只试了适合的任务 | 拉长观察期，补失败任务 |
| 推广后评审堵住 | 评审增量未纳入评估 | 限定场景或补强制复核规则 |
| 有人误贴敏感内容 | 规则不可执行，只有原则 | 加扫描与阻断，补应急流程 |
| 想退但退不掉 | 集成深度与标记未治理 | 先恢复直调路径再清标记 |
| 结论反复摇摆 | 无判据，靠印象复评 | 固定判据与周期，写入度量表 |
第六条最常见：没有判据的评估会随人事变动反复重启；判据、度量与退出条件放同一份文件，复用成本才低。
13. 边界：不必正式评估的情形
| 场景 | 判断 | 做法 |
|---|---|---|
| 个人自费或用免费额度 | 风险自担 | 直接用，不写规则 |
| 只用于非交付内容（草稿、查询） | 不进产出链路 | 允许自由使用 |
| 已有等效替代且无切换成本 | 无决策 | 保持现状 |
| 试点极小（一两人、一周） | 决策成本高于试错 | 试完出结论，不入流程 |
| 明确不可用于交付内容 | 边界已定 | 只做能力评估，不做引入评估 |
反向边界：产出进入交付链路、涉及第三方数据、需要多人协作的场景，无论规模多小都要写清边界与评审要求，因为这三类风险不由使用者单独承担。
14. 自测
- AI 工具与普通工具评估的三点关键差别是什么？
- 试用清单为什么必须包含预期会失败的任务？
- 端到端计时里最容易漏掉的是哪一环？
- 为什么"能说出不适合什么"是团队推广的门槛？
- 退出条件应当写在引入文件的哪一部分，为什么？
- 判断供应商锁定程度，最直接的一个问题是什么？