成长 人人都是产品经理 · Hank · 6小时前 · AI 生成
不同AI场景，怎么落地？——我的三步走方法论 本文提供了一套从价值判断到方案匹配的AI落地三步方法论。作者反对一上来就陷入技术选型（Agent vs 工作流）的常见做法，主张先判断场景是否值得做、AI的角色和出错代价，再对问题类型进行定性，最后匹配具体的AI解题模式。文章列举了工作流、单Agent、RAG等十余种模式及其适用场景与坑，强调组合使用和人在回路的安全底线。适合正面临AI方案选型、希望避免“为了AI而AI”的产品经理和技术负责人阅读。原文 ↗ 原文 ↗
核心观点
▍ AI方案选型应遵循“三步走”方法论：先做价值判断（场景、痛点、角色、代价），再做问题定性（六个维度），最后匹配并组合具体的AI解题模式。 01 价值判断需回答四个问题：场景是否真实、痛点是否足够痛、AI是提效/自动执行/决策辅助、出错代价有多大。四个都满足才值得做，否则先想清楚。 02 问题定性通过六个维度判断：输入类型、核心任务（生成/分类/决策）、步骤是否固定、是否需要动外部系统、用户是谁、结果稳定性要求多高。 03 判断窍门：步骤比判断多用工作流，判断比步骤多用Agent；Agent主Prompt应简练，稳定能力（Skill、MCP、知识库）通过外置工具接入，避免Prompt臃肿导致注意力涣散。 04 Skill（可复用AI能力）的适用条件：某类问题反复出现3次以上，流程相似、输出格式固定。需具体定义输入、输出和判断标准，避免泛化。 05 多Agent协作适用于需要多角色分工、单Agent上下文过大或职责混乱的场景，但管理成本高，不应过度使用。 06 人在回路是安全底线：结果影响客户、财务、权限、生产系统的场景，必须有人确认。如果AI输出质量差到需要人工全部重写，应该先优化AI而非维持“人审”形式。 反方 / 局限
— 作者承认自身经验中的坑：曾在Dify搭建复杂工作流，后来发现维护成本巨大，且模型变聪明后复杂工作流反成累赘，暗示了过度设计工作流的风险。 — RPA被明确标注为“最不稳定的方案，页面一改就挂”，是“没得选时的过渡”，体现了对技术方案局限性的坦诚。 — 作者指出知识库“垃圾进垃圾出”，权限必须隔离，且AI检索不到时“老老实实说不知道，别瞎编”，强调了RAG方案的质量依赖和风险。
概念锚点 三步走：价值判断先于技术选型
多数团队拿到AI需求就纠结Agent还是工作流，作者Hank提出更根本的三步法：先判断场景是否真实（痛点够痛、角色清晰、出错代价可控），再定性问题类型（输入、任务、步骤、系统依赖、用户、稳定性六个维度），最后才匹配方案。核心主张是「别上来就搭Agent，也别什么都扔对话框」——价值判断不过关，方案选得再花哨也是伪需求。
▸ 2 条关联资料
▼
前置背景 Skills、工作流、Agent三者的本质区别
Skills是单点任务能力（如「写文案」），工作流是固定步骤的标准化流水线（如审批流转），Agent是能自主拆解目标、选择工具的智能体。三者不是替代关系，而是点、线、面的金字塔结构——Agent做决策者，工作流做执行路径，Skills做工具箱。理解这个分层，才能明白作者为什么说「步骤比判断多，用工作流；判断比步骤多，用Agent」。
▸ 0 条关联资料
▼
平行视角 80%的AI项目失败不在技术选型
MIT报告显示95%的企业AI投资看不到可衡量的业务回报。失败根因几乎从来不是「模型不够强」或「Agent选错了」，而是数据没准备好、工作流没改、目标不清晰、组织不配套。作者的三步法侧重技术匹配，但更大的坑在业务侧——买工具只是踏上桥的第一步，不是终点。如果场景痛点不真实，方案选得再对也是空中楼阁。
▸ 3 条关联资料
▼
常见误区 工作流维护成本飙升：当模型变聪明后反而成了累赘
作者自曝一个教训：2025年用Dify搭建的复杂工作流，后来模型更聪明后反而成了累赘，维护成本巨大。核心矛盾在于——工作流要求步骤固定，但业务逻辑会变；Agent能动态调整，但结果不稳定。很多团队把流程写死，模型一升级，原来的分支判断要么多余要么冲突。建议是「复杂判断不要硬写死在流程里，让Agent做局部智能节点」——稳定能力外置成Skill，提示词保持简洁。
▸ 2 条关联资料
▼
未来推演 2025年AI Agent从试点走向规模化的关键变量
2025年被行业称为「AI Agent元年」，OpenAI、Google等巨头纷纷押注「模型即Agent」路径，多Agent协作和MCP/A2A等互操作协议加速落地。但专家预测，Agent规模化真正的拐点不在技术突破，而在「人机协作分寸」的治理成熟——谁能把「人在回路」从形式主义变成可量化的安全网，谁就能从试点走向生产。数据孤岛和权限治理是当前最大的工程瓶颈。
▸ 3 条关联资料
▼
延伸追问 Agent执行结果不稳定，如何评估可靠性？
文章强调高风险操作必须「人在回路」，但实践中「AI输出正确但推理过程错误」的案例比比皆是。例如Agent用错误公式蒙对答案，上线后缓存失效导致批量故障。可靠性评估的关键不是看最终答案，而是追踪每一步推理轨迹（Trajectory Evaluation）——包括输入假设验证、工具调用顺序、中间结果合理性。问题在于：多高的轨迹准确率才算「可信任」，这个阈值因场景不同而迥异。
▸ 3 条关联资料
▼