我把 AI 产品的筛选标准，从"谁最强"改成了"谁最好验收"。
这不是因为我不在乎能力。恰恰相反，能力越强，越容易让人放松警惕。一个能一口气写两千字、改十个文件、生成整套方案的模型，最危险的地方不是它做不到，而是它做得太快，快到你以为不需要检查。
过去两年，我装过二十多个 AI 产品。订阅开了又停，收藏夹越攒越满，最后每周都会打开的只剩三个。它们不是在每条赛道上最强的，但都有一个共同点：产出能在很短时间内被我验收。
这篇文章聊三款产品：Kimi、通义听悟、CodeArts。不是榜单，也不是购买建议，而是三份"使用边界说明"。我不讨论价格和版本号，产品能力以官方说明和你自己的试用为准；我只说我在什么任务上用它、怎么验收，以及哪些事不会交给它。
一、先算验收成本，再谈能力
我现在看一个 AI 产品，会先算一笔账：发现错误要多久，修正错误要多大代价，向别人解释结果又要花多少时间。这三项加起来，就是验收成本。
有些产品演示时很惊艳，真用起来却像在拆盲盒：格式很漂亮，结论很顺滑，但你不知道哪一句来自原文，哪一句是模型补的。为了确认一个数字，你得把原始材料再翻一遍。它帮你省了半小时，又让你多花四十分钟核对。
另一些产品能力没有那么"炸"，但输出结构稳定，来源清楚，错了也容易定位。用上三个月，它就会变成日常工具。
所以我的三个问题很简单：
- 结果能不能回查？
- 错误能不能被发现？
- 返工成本有多高？
这三个问题，比任何跑分都更接近真实体验。
二、Kimi：适合把厚材料读成可追问的笔记
我用 Kimi 最多的场景，是读长材料：行业报告、访谈记录、几份互相矛盾的竞品资料。
它的价值不是"替我读完"，而是把"读完"变成"可以继续追问"。一篇八十页的报告，自己从头看到尾，注意力会在三十页后明显下降；让工具先拆结构，我再按问题回去看原文，效率更高。
我的用法分三步。
第一步，不让它直接总结，先让它列出"这份材料试图回答的十个问题"，并标出每个问题对应的章节。这样我能快速判断材料值不值得细读。
第二步，按章节做摘要，要求每个结论后面保留小节号或原文位置。摘要里必须区分"作者观点"和"数据事实"，不能混在一起。
第三步，让它扮演反方：如果这份报告的结论是错的，最可能错在哪三个假设上？这一步常常比摘要更有价值，因为它把"接受信息"变成了"检查信息"。
Kimi 的局限也很清楚。长上下文不等于真正理解，材料之间的冲突有时会被摘要抹平；它给出的引用位置需要自己回查；遇到表格、扫描件和排版复杂的数据，识别质量会下降。更重要的是，涉及未公开的商业材料、客户信息和个人隐私，我不会上传。方便不能成为让渡保密义务的理由。
一句话：Kimi 适合"读厚"，不适合"替你判断厚材料里什么最重要"。
三、通义听悟：把会议变成可执行的记录
第二款是通义听悟。我主要用它处理访谈、评审会和课程录音。
开会时最浪费的不是说话，而是会后没人记得当时为什么做了那个决定。通义听悟能做的，是把录音转成文字，再整理出摘要和待办。它解决的是"记录"这一层的重复劳动。
我的流程是：会前把议题写清楚，录音时尽量围绕议题；会后先看转写原文，再看待办。顺序不能反，因为摘要会丢掉争论过程，而争论过程往往才是决策依据；对待办做一次人工改写，统一成"动词 + 对象 + 截止时间"。比如"优化一下登录"不是待办，"周三前把登录失败提示改成可复制的错误码"才是。
它的局限同样明显。多人抢话、口音、专有名词和缩写，都会让转写出错；摘要为了顺滑，可能把"没有达成一致"写成"已讨论"；录音本身还涉及知情同意和数据合规，不能因为工具方便就默认可以录。
我自己的判断是：会议纪要的价值不在于"记录了什么"，而在于"决定了什么、谁来做、什么时候交付"。工具能帮你把前一半做完，后一半仍然得由人负责。
四、CodeArts：把方案变成能运行的东西
第三款是 CodeArts。它更像一条研发流水线，而不是一个聊天窗口：从需求理解、编码，到测试和部署，尽量放在同一个上下文里。
我最常用它做三类事：从零搭一个能跑的服务骨架；修跨文件的 bug；把一句含糊的需求拆成可以验收的任务。
用法上，我吃过亏，也总结出一条：先写验收标准，再让它动手。
比如"做一个万圣夜小游戏"，如果只说这一句，结果大概率是一个能看但不能玩的页面。把标准写清楚——桌面和手机都能操作、开始后连续玩二十秒不崩、没有控制台报错、封面和 SEO 信息齐全——它才知道什么叫"做完"。
这次的小游戏就是这么做的。玩法、封面、部署和线上验证都定成可检查的条件，改起来反而快，因为每次都知道该看哪里。
CodeArts 的局限也很明显。第一，它重。改十行脚本也走完整工程流程，未必划算。第二，需求含糊时，它会非常自信地补全错误假设。第三，它不做业务取舍，也不会替你判断一个功能该不该做。生成结果仍然要过人的评审，尤其是权限、数据和支付相关的部分。
一句话：CodeArts 适合"把事做完"，不适合"替你决定做什么"。
五、三款产品怎么接力
把这三款放在一个真实需求里，大概是这样：
先用 Kimi 读行业材料和竞品文档，形成问题清单；开会用通义听悟记录争论和待办；需要落地时，把验收标准带进 CodeArts，切成小块实现、测试、部署；最后人来做验收和取舍。
中间最重要的是那张"交接单"，只有四行：目标是什么；输入是什么；怎么算验收通过；出错怎么回滚。
每次把任务从一个工具交给另一个工具，或者交回给人，都把这四行写清楚。它逼你把模糊的期待变成可检查的条件，也逼 AI 在边界内工作。
我不建议让一个工具从资料一路包办到上线。不是因为它做不到，而是因为一旦中间某一步错了，你很难知道错在哪。切成可验证的块，块与块之间用文档和测试交接，速度可能慢一点，但返工少得多。
六、什么时候我会关掉 AI
有四类事，我会主动关掉 AI：
高风险且不可逆的决策，比如涉及资金、合同、合规的最终判断；涉密或敏感数据，尤其是别人的隐私；需要审美、价值观和长期判断的事；我自己都说不清验收标准的事。
最后一条最容易被忽略。没有验收标准时，AI 不是在帮你做事，而是在替你定义什么叫"做完"。定义权一旦交出去，后面的检查就失去了意义。
工具会换，模型会升级，榜单每个月都不一样。真正能留下来的，是一套验收习惯：知道自己在要什么，知道错了怎么发现，知道什么不能交出去。
这比"最强"重要得多。
评论