AI工具箱:不是会多少工具,是知道什么时候用什么

选工具的逻辑不是"哪个火用哪个"，是"先判断你在解决什么问题"。

你是不是也这样？

AI工具越来越多，豆包、Trae、OpenClaw、Cursor……每个都试了试，但真遇到需求的时候，还是习惯打开最熟的那个。

上一篇我们讲了VIBE CODING——"帮你做出来"的核心工具。但用了之后你会发现，有些场景VIBE CODING很顺手，有些场景你需要先"想清楚"再动手，还有些场景你需要在多个工具之间切换。

业务方甩来一个模糊需求，你打开豆包开始写PRD。写到一半发现方向没想清楚，改；改完发现格式不对，再改；改完发现和存量需求有冲突，又改。来回折腾，PRD写了三版，评审还是过不了。

问题出在哪？不是工具不行，是选错了工具角色——你用"做出来"的工具去"想清楚"。

一、两类问题，不是三层工具

很多人的工具选型逻辑是：哪个火用哪个，或者哪个顺手就一直用哪个。

我之前也犯过同样的错。第一版这篇文章，我把工具分成三层：L1日常提效→L2工作流自动化→L3专业场景。看起来很整齐，但实际用起来处处别扭——

同一个工具跨层（豆包做翻译是L1，做需求理解就变成L2），暗示了线性递进（实际是来回跳的），而且"想清楚"这件事被压在L1里太小了。

后来我发现，分层标准不是工具本身，是使用场景。与其按工具复杂度分层，不如按你用工具在解决什么问题来分：

问题类型	核心动作	工具角色
想清楚	框架启发、方向校准、问题重构	写手+编辑
做出来	执行、自动化、协作	执行器

"想清楚"和"做出来"不是线性递进——是来回切换的。你用AI生成Demo，跑出来发现交互逻辑不对，这不是执行的问题，是你对需求的理解有盲点。回到"想清楚"重新拷问，再回来改Demo。

二、想清楚：写手和编辑，两个角色不能串

"想清楚"不是一次对话就完成的。我的实际流程是：

1. 你先写初稿（把模糊想法变成结构化表达）
2. Agent A帮你展开、补充、结构化（写手角色）
3. 产出方案文档
4. Agent B质疑、找漏洞、逼你澄清（编辑角色）
5. 方案定稿，切换到执行工具

写手和编辑是两种不同的角色：写手帮你展开——你说"战略和执行是来回切换的"，它帮你画出框架、补齐维度；编辑追问——"你说来回切换，但你的三层架构是线性的——这个矛盾你怎么解释？"

两个角色都要有，但不能串台。 只有写手没有编辑，方案会自洽但可能有盲点；只有编辑没有写手，你连初稿都写不出来。

我的做法是：一次对话，两个角色，切换Agent保证不串台。保留上下文是因为编辑需要看到写手的产出才能拷问；切换Agent是因为角色不能串。

"想清楚"的产出不是一段对话，是一份方案文档——结构化的、可交接的、能作为执行工具输入的文档。没有这个桥梁，你直接从模糊想法跳到执行，就像我第一版这篇文章，直接从三层架构跳到四条原则，中间缺了拷问，写出来的东西自己都不满意。

三、做出来：三档自动化，渐进升级

"做出来"内部按自动化程度分三档——从手动触发一步步升级上来：

手动触发——你说一次，它做一次。翻译、查信息、生成一个组件。适合低频、非标准化的任务，手动反而更灵活。

流程自动化——手动做多了，发现有些任务有固定模式，沉淀成可复用的能力单元（Skill），每次触发执行一遍。但Skill做多了，又发现有些多步骤任务AI容易跳步骤——这时候需要把执行路径固化下来，变成Pipeline（Workflow）。两种形态取决于确定性需求：

	Skill	Workflow
适合场景	单次执行，AI能自主判断	多步骤有依赖，必须按顺序
决策权	AI在框架内自主决定执行细节	流程决定做什么，AI只执行每一步
风险	AI可能跳步骤、自作主张优化	不可能跳，每一步有检查点

什么时候用Skill，什么时候用Workflow？看执行稳定性。Skill跑得稳就用Skill——轻量灵活。Skill执行不稳定（跳项、漏项），就沉淀成Workflow。比如需求文档批量校验：Skill模式下AI看到20个P1任务，选择"批量处理"思维，第一层检查只做了43%。转成Workflow后，每一步都有检查点，跳不过去。

持续运行——设定好规则，工具自己跑。每日08:00自动抓取100+信息源，08:30生成投资简报——你醒来就有情报。适合每天都在做的重复性任务。

不是所有事都值得持续运行

判断标准是两个指标：会做（做10次，9次AI自己跑通不需要人工干预）和做好（做10次，8次成功不需要人工干预）。想要持续运行，必须会做且做好。否则就是"半自动"——省了一部分力气，但还得人盯着，反而更累。

四、做出来发现想得不对，别硬做

三档自动化不是单向的。执行过程中发现问题，会回到"想清楚"重新拷问。

营销画布就是典型案例——那是一个可视化画布，运营人员拖拽节点配置营销流程。先把完整需求描述给AI让它一次性产出——崩了（想清楚不够，直接跳到做出来）；换成搭积木方式逐步验证——Demo跑起来了；画布中的"线"作为独立实体，工程复杂度激增——回退（做出来中发现想清楚有问题）；线改成附属关系——重新想清楚：抽象到位不是抽象到极致，是抽象到够用。

这个过程是"想清楚→做出来→发现想得不对→重新想→再做"——和"抽象到位，落地克制"一脉相承。

写在最后

选型逻辑不是"从工具列表里挑"，是"先判断你在解决什么问题，再选对应角色的工具"。

• 你在"想清楚"→选写手或编辑角色的工具
• 你在"做出来"→选执行器，按频率选自动化程度
• 你在"做出来"中发现想得不对→回到"想清楚"

下次打开工具之前，先问自己：我现在是要想清楚，还是要做出来？

行动建议：

1. 先判断问题类型：模糊的→"想清楚"，明确的→"做出来"
2. "想清楚"用写手+编辑：两个角色都要有，不能串台
3. "做出来"按频率选自动化：低频手动触发，高频流程自动化，每天做就持续运行
4. 做出来发现想得不对，别硬做：回到"想清楚"重新拷问

本文是「AI实践日志·产品管理专题」第16篇。上一篇：从周级到小时级——用VIBE CODING生成可交互Demo。下一篇：从文档驱动到Demo驱动——产品迭代方法的重构。

关注我，持续更新AI时代产品经理的实战方法论。