ARTICLE · 1090435
AI 工具越用越多,我的工作流却越来越短
AI PRODUCT REVIEW
真实使用经验 · 任务级测评 · AI 产品经理视角
我很爱记录，也很爱复盘。
做完一个项目，我会把中间的判断、走过的弯路和最后留下来的方法写下来。遇到值得聊的产品，我也习惯把它拆开看一遍。它解决了谁的什么问题，为什么把入口放在这里，用户在哪一步开始觉得麻烦。这些问题既是写作者的兴趣，也和我的工作有关。我是一名 AI 从业者，研究产品与使用产品很难完全分开。
前一段时间，我发现自己的电脑里常驻着好几个 AI 工具。同一个问题，我会先问 Kimi，再打开豆包看看有没有更直接的表达，随后把材料交给 Claude 整理。碰到复杂分析时，我会转到 Codex。需要改代码，再打开 Claude Code。文章写完以后，还要找一个图像模型配图。
每款产品都在帮我省时间，放到一起以后，我却花了不少时间搬运上下文。
最典型的一幕发生在写文章时。第一个模型已经知道我是谁、文章写给谁、我对这件事有什么判断。换到第二个模型，我又要从头解释一遍。第三个模型接手时，那段提示词已经长得像一份项目交接文档。模型给出的文字越来越完整，我自己的声音反而越来越淡。
我后来重新整理了这套流程。现在遇到任务，我很少先问哪款 AI 最强。我会先看这件事要做多久，需要多少上下文，结果出了问题以后能不能检查。工具选择因此简单了很多。
这篇文章记录的就是这次分工。它采用日常任务测评，不追求一张永远有效的模型排行榜。模型更新太快，排行榜的保质期很短。真实工作里更稳定的是任务本身，以及我愿意为结果承担多少责任。
四维任务测评框架
SECTION 01
我怎样测一款 AI 产品
很多模型测评从同一条问题开始，让几款模型分别回答，再比较谁写得长、谁看起来聪明。这种方法能看出表达差异，对实际工作还不够。
我更关心四件事。
我先看首轮可用率。模型第一次给出的内容，有多少可以直接留下。一次性任务尤其看重这一项，因为我不会为一段临时文案搭建复杂流程。
长文更考验上下文利用。给它五份材料，它有没有真正使用，能不能分清原始事实、参考文章和我的个人判断。长文写作和产品分析经常在这里拉开差距。
专业任务还要看过程能否检查。模型得出一个结论，我能不能找到依据。Agent 修改了文件，我能不能看到改动。代码跑起来以后，有没有测试结果。专业工作很难只凭一段读起来顺畅的回答验收。
最后再算返工量。模型完成任务用了十分钟，如果我还要花一个小时核对和重写，它带来的效率很有限。相反，有些工具第一步慢一些，交付物清楚，后面反倒省事。
这次复盘没有让所有产品回答同一道题。聊天助手、浏览器工作台和代码 Agent 的产品形态不同，强行横评很容易得到一个好传播、难复用的结论。我选了四类自己反复做过的任务，保留真实材料和原有验收方式，再记录工具在哪一步帮上忙，在哪一步需要我接管。
第一个样本是把一份零散会议记录整理成可以发给同事的纪要。我只提供原文、阅读对象和希望保留的栏目，不补充复杂提示词。Kimi 与豆包承担这一类任务时，我关注首次输出能否把事项、负责人和待确认信息分开。两者的价值主要出现在启动阶段。打开就能用，中文表达也容易继续修改。只要任务结束后不再复用这批材料，我没有理由把流程做重。
第二个样本是竞品分析。输入不再是一段文字，而是产品页面、访谈摘录、公开资料和我的观察。验收也从“读起来通顺”变成结论能否找到出处，事实与推测有没有分开，缺失信息是否被标记。Codex在这种任务里更适合我的原因，是它能围绕交付物继续读取文件、整理证据并检查产物。它也会走偏，所以我会在开始前限定资料范围和最终文件，而不会只给一句“帮我深度分析”。
第三个样本来自开发。问题可能只是一处页面异常，真正的任务却包括定位代码、修改文件和跑完测试。Claude Code的优势只有在进入代码库以后才成立。若它只给我一段示例代码，任务仍未完成。测试失败时能否根据日志继续修正，以及改动能否被开发者复核，才是我留下它的理由。
最后一个样本是长文写作。我要在几轮对话里保留作者背景、参考材料、结构取舍和修改意见。Tabbit里的Claude未必在每一段都给出我最喜欢的句子，却减少了材料搬运和重新解释。配图再交给Nano Banana Pro，文字流程与视觉流程在定稿处衔接。对持续创作而言，少一次上下文重建，往往比某一次生成快几秒更有意义。
这四个样本不能证明哪款模型普遍更强。它们能回答一个更实用的问题。在我的工作中，什么任务交给谁，返工最少，结果最容易验收。
我把常见任务放进这四个维度后，得到了一张任务路线图。它比从第一名排到第五名的榜单更适合日常工作。
临时、独立、完成后很少继续使用的任务，我通常交给 Kimi 或豆包。需要读取多份材料、从几个维度反复核对、最终留下文件的工作，我更愿意交给 Codex。代码开发进入 Claude Code。文章从选题到润色，主要留在 Tabbit 浏览器里的 Claude 对话中。配图则交给 ChatHub 里的 Nano Banana Pro。
这张路线图来自我的工作习惯。它不等于产品能力边界。Kimi 已经提供 Projects、Agent 和 Kimi Work，完全能够处理持续项目。Codex 也可以开发，Claude Code同样能做代码库分析。我只是把它们放到自己最愿意持续使用的位置上。
这点很重要。真实测评需要记录个人选择，也要防止个人选择冒充普遍结论。
我的 AI 任务路由图
SECTION 02
一次性任务，我看第一次交付
我会把短摘要、临时改写、会议内容整理和简单选题交给 Kimi 或豆包。这些工作有几个共同点。输入材料有限，目标容易说清，任务完成以后不会继续积累很多背景。
这类任务里，最有价值的能力往往很朴素。回答快，中文自然，格式不用反复调整，用户第一次输入就能拿到可用结果。
我不会为了改一段通知，先写一份角色设定，再列工作步骤和评价标准。产品需要承担更多默认判断。它应该知道一份通知要先交代什么，也应该在日期或对象缺失时提醒我补充。
Kimi 和豆包在我的流程里承担的就是这个位置。它们像随手可用的工作台，打开以后把当前问题解决。我尤其看重中文表达和低启动成本。遇到一份临时材料，我可以直接上传或粘贴，不需要先整理成项目。
这种使用方式也有边界。对话开始变长，材料越来越多，前面的约束需要反复保持时，我会主动换环境。原因很简单，我已经从一次性任务进入了持续任务。继续在临时对话里追加要求，后面常常要花更多时间找回早期信息。
Kimi 官方现在把 Project 定义为持续工作空间，可以保存项目文件、项目指令和多段对话。官方也建议，工作会持续发生、需要多个交付物或反复使用同一批材料时，建立 Project。这个变化说明产品也在尝试缩短普通问答与专业工作之间的距离。
从 AI 产品经理的视角看，一次性任务考验产品下限。用户没有耐心学习，也不应该先成为提示词专家。默认模型、推荐任务和补问方式，都会直接影响首轮结果。模型能力差不多时，产品设计往往决定用户会不会留下来。
SECTION 03
复杂分析，我开始看证据和完成条件
复杂分析是另一种工作。
我说的复杂，并不单指材料很长。一个任务同时包含多个对象、多个判断维度和不同形式的交付物，复杂度很快就会上来。比如做竞品分析，需要读产品页面、用户反馈和行业资料，还要分清官方说法与实际体验。最后的结论可能要落进报告、表格或下一步行动。
这类任务里，我常用 Codex。
它吸引我的地方并非某一次回答更漂亮。Codex可以把目标转成一连串动作，读取文件，运行工具，检查结果，再根据新发现继续处理。OpenAI 官方描述长任务时给出了一条很清楚的循环，包括计划、执行、验证、修复和继续推进。这个循环与我的分析习惯很接近。
以前我会把很多资料贴进一个对话框，要求模型一次给出结论。输出通常很完整，核对起来却麻烦。现在我更愿意先定义交付物。比如要求它输出一份带出处的分析报告，列出已确认事实、仍然缺失的信息和建议验证的方法。它读过哪些文件，使用了哪些依据，最后生成了什么，我都可以继续检查。
这一点改变了我对 AI 效率的理解。
模型写得快只是其中一部分。真正省下来的时间来自少返工、少遗漏，以及结果可以继续交给下一步使用。一个结论能追溯到来源，一份文件可以继续编辑，一段分析能够说明自己的边界，这些东西在专业场景里比华丽表达更值钱。
Codex也有使用成本。任务目标含糊时，它可能花很长时间走一条并不重要的路径。材料本身混乱，Agent也不会自动知道哪份文件更可信。权限越大，用户越需要提前划定范围。复杂任务交给 Agent 以后，人没有消失，只是从逐步操作转到目标定义和结果验收。
从产品设计看，Agent的核心指标也应该随之变化。聊天产品可以关注回答满意度，Agent还要看任务完成率、人工接管次数、错误恢复能力和交付物可用率。运行了很久不等于完成。用户看到一串工作轨迹，也不等于结果可信。产品必须给出清楚的完成条件和验证位置。
SECTION 04
开发任务，我需要一个真正进入代码库的工具
代码开发时，我会打开 Claude Code。
开发任务与普通问答差别很大。模型需要理解项目结构，找到相关文件，修改代码，运行命令，再看测试是否通过。它写出的解释很流畅，程序依然可能跑不起来。最终验收要回到代码、日志和测试。
Claude Code生活在终端和代码库里。Anthropic 对它的官方描述也很直接，它可以探索代码库、编写并运行测试、修复问题，同时把每一步控制留给用户。这样的产品形态与开发工作天然接近。
我在这里不会讨论谁是最强编程模型。Codex与Claude Code都能完成开发任务，Kimi Code也在快速扩展。对我而言，选择Claude Code更多来自工作习惯。它进入项目的方式直接，计划和修改都围绕代码库展开，适合把一个开发问题连续做完。
专业开发工具需要暴露更多信息。哪些文件发生变化，哪些命令会执行，测试为什么失败，Agent还准备做什么。这些信息在普通消费产品里可能显得复杂，对开发者却是安全感的来源。
这也提醒我，所谓易用并没有一套统一答案。普通用户希望产品替自己减少选择，专业用户需要保留控制。AI 产品经理要做的，是识别哪些复杂度应该藏起来，哪些信息必须让用户看见。
SECTION 05
写文章以后，我把模型和材料放回同一个地方
写作曾经是我切换工具最多的环节。
过去的流程大致是这样。先找一款 AI 想方向，再换一款 AI 搭大纲，完整稿出来以后交给另一个模型润色。每次切换都要复制正文，重新解释作者身份和目标读者。为了让模型理解，我开始维护越来越长的提示词。
问题很快暴露出来。提示词保存了规则，却没有保存我为什么形成这些判断。参考资料在浏览器标签页里，个人记录在文档里，对话模型只看到我最后复制进去的一小段。它能模仿我要求的语气，很难凭空获得我的经历。
现在我的文章方向、材料、大纲、完整稿和润色，主要留在Tabbit浏览器下的Claude对话中。
第一条指令只做一件事。我会交代自己是谁，文章写给谁，手里有哪些材料，最想讲清哪一个判断。模型先给出角度和结构，我确认方向以后再继续写。这个阶段如果发现材料不足，我会回去补记录或查资料，不急着生成五千字。
大纲通过以后，我让Claude完成第一稿。接下来的对话也不再笼统地要求它“写得更像真人”。我会逐段处理具体问题。哪一段没有材料，哪一句把个人判断写成了行业定论，哪里连续使用了太整齐的句式。每轮只解决一个问题，修改更容易判断。
Tabbit在这套流程里承担的角色接近工作环境。它可以把网页、标签组、截图和本地文件带入上下文，文章来源与对话留在相邻位置。资料不需要频繁搬家，我也更容易回到原页面检查。
文章定稿以后，我用ChatHub里的Nano Banana Pro配图。Google把Nano Banana Pro定位在高质量图像生成和编辑，强调复杂构图、文字渲染与信息图能力。对公众号写作而言，我最看重的是视觉能不能准确承接文章观点。封面负责让读者看懂问题，正文图负责解释关系。单纯生成一张好看的未来感图片，帮助不大。
我的新流程看起来只剩两个入口，一个负责文字与上下文，一个负责视觉。背后仍然使用了不同模型。工具数量没有真的消失，切换发生在合适的边界上，不再贯穿文章的每一步。
一次性问答与专业工作流的结构差异
SECTION 06
普通用户和专业用户，用到的像是两个产品
同一款AI，普通用户与专业用户常常得到完全不同的体验。
这里的普通与专业不按职位划分，也不代表谁更聪明。我更愿意看一个人和任务的关系。偶尔使用AI、任务完成后很少复用、结果出错影响有限，可以归到普通使用。工作频繁发生，输出要交给别人，错误会产生实际成本，就进入了专业使用。
普通用户通常从一句需求开始，希望第一次回答已经够用。专业用户会先定义目标、准备材料和完成标准，还会检查中间过程。普通用户觉得内容通顺就可以继续，专业用户会问事实从哪里来，哪些地方仍需确认。
差别最后落在产品设计上。
面对普通用户，产品需要提供更好的默认值。它应该识别常见任务，主动补问必要信息，用容易理解的方式展示来源和风险。让用户学习十种提示词结构，通常意味着产品把一部分设计工作留给了用户。
面对专业用户，产品需要提供更强的可控性。项目上下文怎样管理，权限开放到哪里，模型调用了什么工具，结果如何验证，成功流程能不能保存并复用。这些能力决定了AI能否从临时助手进入真正的生产流程。
两类需求并不冲突。优秀产品会把专业用户反复验证过的方法逐步做成默认能力。项目、记忆、Skills、Agent和可见执行轨迹都在做同一件事，让用户少重复解释，让复杂任务仍然可检查。
从AI产品经理的角度看，模型能力只是产品价值的一部分。用户不会长期为参数名称留下来。他们会记住第一次有没有完成，修改是不是容易，重要操作能不能放心交出去。
SECTION 07
让AI写得像人，先给它真实材料
写作流程缩短以后，我对“AI味”的理解也变了。
它经常来自几种缺失。没有具体材料，模型只能生成通用经验。没有作者判断，文章会把每个方向都照顾一遍。修改标准缺失时，润色会把句子改得越来越顺，内容却没有增加。
我现在会先把记录交进去。哪些工具我真的用过，哪一步让我觉得麻烦，我都会写清楚。后来改掉的选择单独补进材料。模型可以帮我整理这些东西，不能替我经历。
大纲阶段，我会检查每一部分依靠什么材料。找不到出处的章节，要么补材料，要么删掉。完整稿阶段，我会检查事实与判断有没有混在一起。润色阶段只处理句子，不允许模型临时增加新经历。
还有一个容易忽略的动作。我会保留一点不那么圆滑的表达。人对工具的使用很少像产品发布稿一样整齐。我们会偏爱一款产品，也会在某个场景里放弃它。一次体验只能说明当时的任务，不能替整个行业下结论。把这些边界留下来，文章才像一个具体的人在说话。
这也是我写这篇文章时最想保留的部分。
我仍然会试很多AI工具，也会继续关注新模型。现在我不会为了证明自己跟得上更新，把每一款产品都塞进日常流程。临时任务看第一次交付，复杂任务看证据和完成度，开发任务回到代码和测试，持续创作则看上下文能不能留下来。
工具越多，分工越要清楚。
对普通用户来说，保留一款顺手的日常AI，再准备一个能够处理复杂任务的Agent，已经能覆盖很多工作。对专业用户来说，更值得投入的是自己的材料、评价标准和验收方法。新模型发布时，用同一批真实任务再测一次，结论会比任何一张排行榜更接近你的工作。
AI产品还会继续变化。我的工具名单也一定会变。只要任务选择的方法还在，我就不需要每次从头开始。
参考资料
OpenAI Developers Using Goals in Codex OpenAI Developers Run long horizon tasks with Codex Anthropic Claude Code in an Hour Kimi Help Center Projects Tabbit Browser Browser-use AI Agent Google DeepMind Nano Banana Pro
FINAL NOTE
工具越多，分工越要清楚。把时间留给判断，把重复操作交给 AI。