怎么判断一个 AI 工具值不值得用：我们的五步评测法
每次有人问我「现在最好的 AI 工具是哪个」，我都会先反问一句：你要解决的是什么任务。这不是客套。同一类工具在不同任务上的表现差异，比不同产品之间的品牌差异大得多——一个在长文改写上很顺手的模型，放到结构化数据抽取上可能还不如小一号的专用模型。
第一步：先写清楚任务，而不是先看产品
我们把任务拆成四个要素：输入是什么形态、输出要满足什么约束、失败一次的代价有多大、多久做一次。这四个问题决定了后面所有判断。
举个具体的例子。「把会议录音整理成纪要」听起来是一个任务，但拆开之后差异巨大：输入是 1 小时多人对话还是一对一沟通，输出是纯文字摘要还是带责任人和截止时间的行动项，错漏一处的代价是内部不便还是对外承诺失误，频率是每天十场还是每周一场。这四个答案不同，选出来的工具可能完全不是一类。
第二步：用真实数据跑，不用示例数据
产品官网的 demo 永远是精心挑选过的。我们要求客户提供 20 条真实输入，其中至少 5 条是「已知的难例」——口音重的、格式乱的、信息残缺的。用这批数据跑一遍，再看输出。
这一步淘汰掉的产品最多。很多工具在标准示例上表现很好，一旦输入带上真实世界的噪声就崩了。而这件事在官网 demo 里永远看不出来。
第三步：把价格换算成单次任务成本
订阅价格是最容易误导人的指标。一个每月 20 美元但按次数限额的工具，和一个每月 60 美元但不限额的工具，哪个便宜取决于你每个月做多少次。
我们通常这样算：把月费除以实际可用次数，得到单次任务成本，再和人工完成同样任务的时间成本对比。这个换算经常会得出反直觉的结论——某些看起来很贵的工具，按单次成本算反而更便宜，因为它一次就能做对，不需要反复重试。
第四步：看它在出错时的表现
这一点几乎没人在评测里写，但它决定了工具能不能进生产环境。
好的工具在不确定时会停下来、给出现在能确定的范围、或者明确要求补充信息。差的工具会编一个看起来合理的答案，而且语气笃定。前者你可以用流程兜住，后者必须每条都人工复核——那省下来的时间就全还回去了。
第五步：检查退出成本
最后一步经常被跳过：如果这个工具明天涨价一倍、或者停止服务，你要多久能换掉它？
判断标准很朴素——你的数据和工作流是不是以通用格式存在自己手里。如果所有提示词、知识库、自动化流程都锁在某家的专有格式里，那这个工具再便宜，长期看也是贵的。
这五步之后
走完这五步，通常只剩两三个候选。这时候才值得开始谈价格和合同。我们从不建议跳过前面四步直接比价，因为比价只有在产品确实能完成同一件事的时候才有意义。
顺带说一句：如果走完五步发现没有工具能达标，那结论就是「现在还不该用 AI 做这件事」，这同样是一个有价值的结果。把它硬上，成本比不用更高。
去年到今年，我们经手了七八个企业知识库项目。其中有三个，上线三个月后的实际查询量是个位数。技术上都跑得通——检索准确率不低，回答也合理——但就是没人用。
复盘下来，原因高度一致，而且都不是模型或检索的问题。
原因一：答案没有出处，所以没人敢信
这是最常见也最致命的一个。员工问「这个客户的付款条款是什么」，系统给出一段看起来很专业的回答。但员工下一步要拿这个回答去和客户沟通，他必须确认这段话说的是真的。
如果答案下面没有原文链接、没有具体到段落的引用，他就必须自己再去翻一遍原始文档。既然要翻文档，那为什么不一开始就翻？知识库在这里没有节省任何时间，只增加了一步。
我们现在的默认要求是：每个回答必须能点到原文的具体位置。做不到这一点的场景，我们会直接说「这个不适合做知识库」。
原因二：更新机制缺失，文档过期了没人知道
知识库最大的隐性成本不是建设，是维护。政策改了、价格调了、流程变了，原始文档更新了，但索引里还是旧版本。
更麻烦的是，用户没有办法判断一个答案是新的还是旧的。一旦有人查到一个过期信息并因此出了错，整个系统就失去了信任，之后就再也拉不回来。
我们现在的做法是给每份文档加有效期，过期自动从检索结果里降权，并在界面上明确标出「该文档最后更新于 X 年 X 月」。宁可让用户看到一个诚实的「这条信息可能已过期」，也不要给一个查不到出处的确定答案。
原因三：切分方式一刀切
把所有文档按固定字数切开，是最省事也最糟的做法。产品手册的一节是一个完整语义单元，切成两半之后，任何一半单独拿出来都不完整；而会议纪要里一段话可能包含三个独立结论，整段检索出来则稀释了相关性。
我们按内容类型定策略：结构化文档按章节切，问答类按单条切，长文按段落切并保留上下文窗口。这件事没有通用解，必须按客户的文档形态单独调。
原因四：没人告诉员工它存在
这条听起来很蠢，但真实发生过。系统做完了，交付给 IT 部门，IT 部门发了一封内部邮件，然后就没了。三个月后我们回访，一线员工根本不知道有这个东西。
知识库是行为改变，不是软件交付。它需要被放进员工本来就会打开的地方——企业微信、钉钉、工单系统——而不是要求他们记住再多一个网址。
一个反过来的判断标准
我们现在评估一个知识库项目能不能成，会先问一个问题：如果这个系统做得很好，员工每周会用它几次？
如果答案是「偶尔查一下」，那这个项目的投入产出比大概率不成立，不如把文档整理好放进现有的搜索里。如果答案是「每天都要查好几次」，那它值得认真做，而且上面四个原因都必须解决。
先说结论：AI 在内容生产里最大的价值不是「写」，而是把写之前的准备工作从几小时压缩到几分钟。真正决定内容质量的仍然是人和事实，而这两件事恰好是 AI 最不该独立负责的。
我们现在的流程是四步，每一步的责任边界都很清楚。
第一步：选题与角度 —— AI 辅助，人决定
AI 可以做的事情：把一批关键词按搜索意图聚类，找出哪些是「想知道怎么做」、哪些是「想比较哪个好」、哪些是「想确认某个事实」。这个分类直接影响文章结构，用人工做得花一整天。
人必须做的事情：决定写哪个，以及用什么角度。这一步决定文章有没有价值，而 AI 给出的角度通常是搜索结果的公约数——也就是所有人都在写的那个角度。
第二步：结构与提纲 —— AI 生成，人修改
给定选题和意图分类，AI 可以很快产出五到八个一级标题。这个初稿的可用率大概在六成：结构大体合理，但会有明显的凑数段落。
人的工作是删。把「总结」「展望」这类没有信息量的段落直接拿掉，把两个重复的角度合并，把最重要的那个论点提到前面。这一步花十五分钟，但决定了读者会不会读下去。
第三步：初稿 —— AI 写，但只写「已知为真」的部分
这里有一条硬规则：AI 不允许写任何具体的数字、日期、人名、产品价格，除非这些信息在提示词里被明确给出。
原因很实际。大模型对这类事实性细节的编造率远高于一般文本，而且编造得非常自然——语气笃定，格式规范，看起来完全可信。一旦混进正文，后面的核验成本比不用 AI 更高。
我们的做法是让 AI 写框架、写解释、写过渡，把需要事实的位置留成占位符，由人填。
第四步：事实核验 —— 只能人做，没有捷径
这一步是整条流水线的瓶颈，也是唯一不能压缩的一步。
每一条事实性陈述都要回到原始来源确认：价格去官网看，数据找原始报告，产品功能自己试一遍。这一步占整个流程大约 40% 的时间，而且不随 AI 能力提升而下降。
有人问能不能让 AI 互相核验。我们试过，效果不好——它倾向于确认自己已经说过的内容，而不是质疑。让另一个模型来核对，本质上只是把同一个概率分布采样了两次。
产能提升来自哪里
拆完之后就很清楚了：产能提升来自第一步和第二步的加速，以及第三步里那些不需要事实的部分（解释、过渡、举例框架）。
第四步的时间没有变，但它在整个流程里的占比从 60% 变成了 40%，所以总时间下降。这个账算清楚之后，就不会再对「AI 能不能替代编辑」这类问题抱有幻想。
顺带说一个副作用：走完这套流程的人，对「什么算事实」的敏感度会明显提高。这可能是比产能更值钱的收获。
客户第一次提 Agent 需求时，往往会说「希望它能自动处理客户的问题」。这句话里藏着一个危险：什么叫「处理」？回复邮件是处理，退款也是处理，两者需要的权限差了几个数量级。
我们在每个 Agent 项目里都会先定三道边界，然后才写第一行提示词。
第一道：能读什么，能写什么
读和写必须分开授权。一个客服 Agent 需要读订单历史才能回答问题，但不需要写订单状态。把这两件事绑在一起，是绝大多数事故的来源。
具体做法是最小权限：先只给读权限跑两周，观察它实际需要什么，再逐项加。不要一开始就给全套权限然后指望提示词约束——提示词是建议，权限是事实。
第二道：什么动作必须人确认
我们把动作分成三档：
- 自动执行：只读查询、生成草稿、内部标注。做错了改回来成本很低。
- 执行后通知：发内部通知、创建任务、更新内部状态。做错了有人能看到并能撤销。
- 必须人确认：对外发送、涉及金额、修改客户可见的信息、删除数据。
第三档的清单要写死，不能由模型判断「这个动作重不重要」。我们已经见过模型把「给客户发一封说明邮件」判定为低风险内部操作。
第三道：出错之后怎么回退
每个 Agent 都必须能回答一个问题：如果它刚才做错了，我们怎么撤销？
如果答案是「没法撤销」，那这个动作就不该被自动化。我们要求所有写操作都可追溯——记录什么时间、基于什么输入、做了什么修改、原始值是什么。这样最坏情况下还能人工复原。
提示词仍然重要，但位置不同
提示词解决的是「怎么把事做对」，权限解决的是「做错了能有多糟」。这两件事不能互相替代。
一个提示词写得很好但权限过大的 Agent，和一个提示词一般但权限收得很紧的 Agent，后者在生产环境里一定更安全。前者的风险是尾部事件，平时看不出来，出事就是大事。
一个实践中的判断
如果客户说不清「这个 Agent 做错了会怎样」，那说明这个流程还不该自动化。先把它做成「AI 建议 + 人执行」，跑一两个月，等流程本身的边界清楚了，再考虑让 Agent 直接动手。
这个顺序不能反。先自动化再补权限，通常是在事故之后。
这个项目开始时，客户的官网上线三年，设计已经过时，但真正的痛点不是好看不好看——是移动端打开要等四五秒，投放的落地页跳出率高得离谱。
我们先做了一次完整的资源审计，结果比预想的更糟：首页 4.2MB，其中最大的一张轮播图单独就 2.2MB，还加载了 11 个第三方脚本——统计、客服、字体、图标库、两个轮播插件、一个动画库。
第一步：把「不需要」的删掉，而不是优化
优化的第一步永远是删除。11 个第三方脚本里，有 4 个从未被触发过（一个旧版客服工具的残留、两个统计工具的重复部署、一个已经停用的 A/B 测试 SDK）。删掉它们不需要任何技术工作。
字体是第二刀。原来从 Google Fonts 引了六个字族、十几个字重，实际用到的只有两个字族的三个字重。改成自托管子集之后，字体请求从 4 个跨域请求变成 2 个本地文件。
第二步：图片按实际显示尺寸出
2.2MB 的那张轮播图，实际显示区域在最大屏幕上是 1440×810。原图是 4000×2250 的 PNG。
处理方式很标准：转 WebP、按实际显示尺寸出图、用 srcset 给不同屏幕不同文件。这一项把首屏图片从 2.2MB 降到 120KB 左右。
这里有一个常被忽略的点：width 和 height 属性必须写，否则图片加载过程中页面会跳动，那个跳动本身会让用户觉得「慢」——即使实际加载时间没变。
第三步：动画不阻塞首屏
原站在 <head> 里同步加载了一个动画库，然后所有入场动画都依赖它。这意味着：动画库没下载完，页面内容是隐藏的。
我们改成 CSS 默认可见，JS 只负责「加一个类让元素从隐藏过渡到可见」。这样最坏情况——JS 加载失败——页面依然完整可读。
第四步：把第三方换成自建
原来有一个嵌在页面里的客服组件，加载了大概 300KB。我们和客户讨论后决定去掉它，改成页脚一个邮箱链接加一个表单页。客服量没有下降，因为原来那个组件的实际使用率极低。
图标库、轮播插件同理：实际用到的图标不到 40 个，用 SVG sprite 内联即可；轮播需求只是「手机上能横滑」，CSS scroll-snap 就够了。
结果
首页传输量从 4.2MB 降到约 180KB，请求数从 40 多个降到 12 个，移动端 LCP 从 4.6 秒到 1.5 秒。设计上没有做任何妥协——视觉稿是一致的。
最有说服力的数字不是这些，而是投放落地页的跳出率下降了三分之一。性能不是技术指标，它是转化率的一部分。
做咨询这一行，最难的不是接到项目，是劝客户不要做某个项目。但这件事对双方都有好处：做不成的项目会消耗信任，而信任比一个项目的收入值钱。
下面三种情况，我们通常会建议先别做，或者换个方式做。
场景一：错误代价极高，且无法撤销
典型例子是合同条款审核、医疗建议、涉及资金审批的流程。这类场景不是不能辅助，而是不能让 AI 直接输出结论。
判断方法很简单：问一句「如果它错了，最坏结果是什么」。如果答案是「无法挽回」，那就不该把决定权交给模型。
可以做的版本是：AI 先过一遍标出可疑点，人做最终判断。这样它省的是初筛时间，而不是决策责任。
场景二：数据本身是乱的
很多客户想做的第一件事是「用 AI 分析我们的业务数据」。但如果这些数据分散在五个系统里、字段口径不一致、同一张表里有两个不同的「客户数」定义，那再好的模型也分析不出东西。
这种情况下 AI 会把数据的混乱放大，而不是解决它——因为它会给出一个看起来合理的数字，而没人能验证这个数字对不对。
正确的顺序是先做数据治理：统一口径、打通系统、建立唯一数据源。这件事不性感，但绕不过去。我们自己接过的最痛苦的项目，就是接手一个跳过这步直接上 AI 的系统。
场景三：频率太低，不值得建设
有些任务是「一年做两次，每次两天」。比如年度报告的资料整理、大型活动的物料准备。
这类任务做自动化的投入产出比通常不成立：建设成本可能要两周，而它一年只能省下三天。更麻烦的是，低频流程做完之后没人记得怎么维护，第二年跑起来大概率是坏的。
更划算的做法是把这次的经验整理成一份可复用的清单或模板，下次照着做。这不需要任何技术投入，效果立竿见影。
一个通用的判断框架
把三个维度放一起看：
- 频率：每周至少几次？低于每周一次的要慎重。
- 错误代价：错了能不能撤销？不能撤销的必须保留人工确认。
- 输入质量：数据是否规范、来源是否可靠？数据乱的先治理。
三个维度都过关的场景，做下去大概率能成。任何一项明显不过关，就应该先解决那一项，而不是指望模型把它绕过。
说「不要做」的时候，我们通常会同时给出一个「可以做什么」的替代方案。这才是咨询该做的事——不是拒绝，是把钱花在对的地方。