面对AI方案选型，很多人一上来就纠结用Agent还是工作流，却忽略了更根本的问题：这个场景值不值得用AI？AI要扮演什么角色？本文作者总结了一套从价值判断到方案匹配的完整方法论，帮你避开“为了AI而AI”的坑，找到真正适合的解题模式。

笔者之前碰到过不少人问：「我这个场景要不要上AI？用Agent还是工作流？要不要搭RAG？」问得多了，发现一个共性——大家拿到问题就想方案，但很少先想清楚两个更根本的问题：这个场景值不值得用AI做，以及AI要在里面扮演什么角色。

这就跟产品经理做需求一样：不是所有需求都值得接，接之前得先看场景和价值。AI方案选型也是这个道理。

因此本文笔者要分享我自己的方法论就是——拿到一个想用AI解决的问题，怎么一步步判断该用什么方案。

一、先判断值不值得做

和产品平常做需求一样，在想”用什么方案”之前，得先搞清楚场景、痛点和价值。做AI方案还要多问几个落地相关的问题，问清楚了，才值得往下走：

1. 场景是什么？

谁用？在什么场景下用？是高频还是低频？是辅助人还是替代人？说不清场景的AI需求，大概率是伪需求——”别人都在做所以我们也要做”那种。

2. 痛点有多痛？

现在这个问题是怎么解决的？如果现在的方案已经够用、没人抱怨，就别急着上AI。AI要解决的是”现在解决得不好、或者解决成本太高”的问题，不是解决”没有问题”的问题。

3. AI在里面的角色是什么？

• AI是提效工具（辅助人更快完成，人还是决策者）？
• AI是自动执行（替代人完成明确动作）？
• AI是决策辅助（给出建议，人来拍板）？

角色不同，方案差异巨大。搞错了角色，要么过度设计（一个简单辅助硬上Agent），要么风险失控（高风险动作全自动执行）。

4. 出错代价多大？

• 错了改一下就行？→ 可以大胆试
• 错了要人工擦屁股？→ 需要人在回路
• 错了影响业务/客户/钱？→ 必须审批+审计+回滚

这个问题决定了安全底线，比方案选型重要得多。当然，这也是需要产品经理本来就要具备的基本功。

判断标准：场景真实、痛点明确、角色清晰、代价可控——四个都满足，值得做；有一个答不上来，先想清楚再动手。

二、再判断问题类型

值得做之后，先看清问题本身。笔者大致捋了六个维度：

这六个问题过一遍，问题基本就看清楚了。下面笔者会将把核心的AI解题模式挨个说一下。

三、核心解题模式

3.1 工作流：步骤固定就用它

流程步骤相对固定，每一步输入输出清晰，分支条件能提前定义，需要稳定可重复执行的，直接用工作流。

典型场景：审批流转、定时报表、数据同步、状态通知、标准作业流。

记一个判断窍门：步骤比判断多，用工作流；判断比步骤多，用Agent。

有个坑要留意：流程经常变的时候别用工作流，维护成本会飙升。复杂判断不要硬写死在流程里，让Agent做局部智能节点就好。（tips：25年的时候，当时笔者就有试过用dify搭建过比较复杂的工作流，后来发现维护成本巨大，而且后面模型更聪明后，反而这些复杂工作流成了累赘）

3.2 单Agent：目标给它，路它自己找

目标明确但完成路径不固定，需要理解上下文、拆解任务、选择工具的——用Agent。

典型场景：需求风险分析、资料搜集整理、自动查找涉及哪些文档和人、任务规划。

判断窍门：任务需要”自己想下一步做什么”时考虑Agent。有明确SOP就用工作流。

要注意：Agent执行结果不稳定，高风险写操作不能完全交给它，必须有人确认。还有，Agent的主Prompt尽量简练，只说清楚目标和边界，调用Skill、MCP、知识库这些稳定能力通过工具接进来，不要把所有规则都塞在Prompt里——塞得越满，Agent越容易注意力涣散、漏步骤、犯低级错。

3.3 Skill：反复做的事，沉淀下来

某类问题反复出现（3次以上），有成熟的经验、模板或判断标准，想把个人能力变成可复用的AI能力——就做成Skill。

典型场景：需求风险评审、月报生成、文档处理、TAPD操作——流程相似、输出格式固定的任务。

判断很简单：做了3次以上且流程差不多，就值得做成Skill。说穿了，Skill就是”提示词模板+工具调用说明+输入输出格式”的封装。

Skill别写太泛，”帮我写文档”这种没用。要具体到”输入什么，输出什么格式，按什么标准判断”。

3.4 知识库/RAG：让AI基于你的资料回答

资料多、更新快、需要引用来源，问题主要是”查找、理解、归纳已有知识”——搭RAG。

典型场景：公司制度问答、历史需求查询、项目资料检索、客服知识问答。

要注意：垃圾进垃圾出，文档质量差AI也好不了；权限必须隔离，不能谁都搜所有资料；检索不到就老老实实说不知道，别瞎编。复杂场景的知识库还要做好意图识别路由，结合入口端、提问内容做分类，再配合上下文关联和回复内容复核，效果才稳。

3.5 文档智能：从长文档里”抽”东西

大量文档需要摘要、比对、抽取字段、分类或结构化——用文档智能。

典型场景：合同条款抽取、会议纪要、PRD风险排查、邮件分类、文档差异比对。

关键信息（金额、日期、条款）必须人工复核。高风险文档不能只靠AI。

3.6 数据分析Agent：用自然语言查数

想用自然语言查数据、看趋势、解释异常——数据分析Agent。

典型场景：”本月哪些需求延期了？””哪些项目风险最高？””把这个表生成管理层摘要。”

前提是数据口径必须统一。同一个指标不同部门定义不一样的话，AI查出来的数不可信。底线要守住：AI只能查，不能改数据。

3.7 平台工具对接：让AI能读写系统

数据在TAPD、企微、在线表格、文档、BI里，AI需要读写这些系统而不是只在对话框里自嗨——接工具。

读和写权限分开。读可以相对放开，写必须有确认和回滚。能用API/MCP就别用RPA。

3.8 RPA：没API时的过渡方案

旧系统没接口，只能通过界面操作（点击、录入、下载、上传），又必须自动化——用RPA。

这是最不稳定的方案，页面一改就挂。能用API就不用RPA，它只是没得选时的过渡。

3.9 视觉/多模态：处理图片和视频

输入是图片、截图、扫描件、票据、视频——用视觉方案。

选哪个不复杂：图片里只有文字用OCR，要识别物体/位置/缺陷用视觉检测模型，要结合业务语义理解用多模态大模型。

图片质量直接影响结果，关键场景加置信度判断，低置信度的打回人工处理。

3.10 算法/求解器：求最优解不是生成内容

问题不是”写一段话”能解决的——排期怎么排最优、资源怎么分配、销量怎么预测——用算法或求解器。

大模型在这里是辅助角色（帮定义目标函数、解释结果），严肃的优化计算要用专门的算法。目标函数定义错了，结果就是”数学正确、业务错误”。像是auto gluon就是一个非常好的工具，里面集成了很多算法可以直接调用，非常安利大家——然后自己就可以兼任算法工程师（哈哈哈）

3.11 多Agent协作：多角色分工

一个问题天然需要多个角色从不同视角处理，单Agent上下文太大或职责混乱——用多Agent。

典型场景：需求全链路评审（产品+架构+测试视角）、复杂方案评估。

不是越复杂越要多Agent。两个能搞定的就别上五个，管理成本会反过来拖垮效率。要明确谁有最终决策权。

3.12 人在回路：AI出稿，人拍板

结果影响客户、财务、权限、生产系统，AI可以提效但不能完全自动决策——必须有人在回路。

人审不是走形式。如果AI每次都错到要全部重写，那不是人在回路，是人工干活AI看着——该回头优化AI了。

3.13 其他常见模式

还有一些模式不逐一展开了，列个表过一下：

四、组合使用才是真实世界

当然，更多时候其实还是组合多种模式来解决问题。下面是常见的一些组合模式：

组合时记住：提示词不堆细节，稳定能力外置成Skill。 把工具调用、评审标准、输出格式全塞提示词里，提示词会越来越长，AI注意力反而被稀释。稳定的东西做成Skill让AI调用，提示词保持简洁。

五、写在最后

其实本文笔者的核心方法论，拆开来看就三步：

1. 先做价值判断。 场景真实吗？痛点够痛吗？AI在里面是提效、自动执行还是决策辅助？出错代价多大？这四个问题对号入座，自己心里都有答案才可以。
2. 再做问题定性。 输入是什么？核心任务是什么？步骤固定不固定？要不要动外部系统？谁用？结果要稳到什么程度？问了自己这六个维度问题后，再确定方案方向。
3. 最后匹配并组合。 步骤固定的用工作流，判断为主的用Agent，反复出现的沉淀成Skill，需要知识的搭RAG。复杂场景别死磕单一模式，组合用。

总之拿到问题先走价值判断，再走问题定性，再走匹配加组合，最后别忘了安全底线——高风险动作加人在回路，进入真实业务补评测和治理。别上来就搭Agent，也别什么都扔对话框。

如果你有更好的方法论，或者踩过不一样的坑，欢迎在评论区聊聊。