把散落在各页的"怎么选 / 怎么判断"决策汇总到一页。这是一张路由表，不复述细节——纠结时来这里一眼看到判断框架，再跳转到详情页深读。
每节统一格式：什么时候纠结 → 判断逻辑 → 详情页。
决策：选哪个大模型
什么时候纠结：面对一堆模型（Claude / GPT / DeepSeek / 通义……），不知道选哪个当能力底座。
判断逻辑：
- 没有"最强模型"，只有"场景最优解"——先问业务最在乎什么，再倒推怎么选。
- 沿五个维度评估：效果 / 成本 / 速度 / 安全 / 可控，按场景给维度排权重（客服=速度>成本，法律=效果>安全，审核=成本>速度）。
- 至少纳入 3 个候选对比，用真实业务样本组成评测集打分，再算单次/月成本，综合决策；不靠 benchmark 分数和供应商推荐拍板。
- 选错代价分三类：选太强（账单吞毛利）、选太弱（口碑崩）、选错类型/部署（跑不通或合规事故）。
详情见 模型选型五维度（评什么）、模型选型方法论（怎么选的五步流程）
决策：要不要上 Agent（Agent vs Workflow）
什么时候纠结：一个 LLM 需求，不知道该写死流程（Workflow）还是让模型动态决策（Agent）。
判断逻辑：
- 本质区别是控制权在谁手里：Workflow=代码预定义路径，Agent=LLM 动态决定下一步。两者无高下，关键是匹配任务。
- 先用 5 问口诀自检：① 流程每次都不一样？② 下一步要看上一步结果定？③ 用户能等 3 分钟以上？④ 单次预算能超 1 元？⑤ 出错有降级方案？—— 3 个以上为"否"基本就别做 Agent。
- 路径确定后再克制叠加能力：超 3 步加 Planning、质量高+标准明确加 Reflection、有分工/可并行加 Multi-Agent。每加一层，成本和不可预测性都上升。
详情见 Agent vs Workflow（含 6 维对比、五种 Workflow 模式、决策树）
决策：怎么判断竞品类型
什么时候纠结：列竞品时怕遗漏、怕错判，不知道把谁当主要对手、给谁分析资源。
判断逻辑：按"用户是否相同"× "解决方案是否相同"两维度切四象限——
| 相同解决方案 | 不同解决方案 | |
|---|---|---|
| 相同用户 | 直接竞品（最紧迫） | 间接竞品（中） |
| 不同用户 | 潜在竞品（低但警惕） | 替代品（中低） |
紧迫度排序：直接 > 间接 ≈ 替代 > 潜在。找竞品时用"任务关键词"而非产品名搜，并直接问用户"除了我们你还在用什么"挖替代品。
详情见 竞品分类四象限
决策：现在该做 POC 还是 MVP 还是直接灰度
什么时候纠结：有个想法/新版本，不知道当前该投入哪个验证阶段。
判断逻辑：三段是漏斗，前一段不通过不进下一段——
| 阶段 | 回答的问题 | 何时进入 | 失败怎么办 |
|---|---|---|---|
| POC | 技术上能不能做？ | 想法刚提出、模型能力存疑 | 换技术方案或砍方向 |
| MVP | 用户愿不愿意用？ | POC 已验证技术可行 | 换需求方向或放弃 |
| 灰度 | 真实流量下扛不扛得住？ | MVP 验证用户价值后、要上线放量 | 暂停扩量、回滚旧版 |
"技术能做 ≠ 用户想要"，POC 通过但 MVP 失败是最常见的坑。任何会改变线上输出的改动（换模型、改 Prompt、更新 RAG）都应走灰度，不要 All in。
决策：需求做不做 / 先做哪个
什么时候纠结：需求池堆满，资源有限，不知道砍谁、先做谁。
判断逻辑：本质是取舍，从三组维度交叉判断——
- 价值 / 成本：优先级 ≈ 价值 ÷ 成本；同价值挑低成本，同成本挑高价值。
- 紧急 / 重要（艾森豪威尔）：紧急重要立刻做，不紧急重要规划做（决定上限），紧急不重要委托，不紧急不重要直接拒。
- 用户 / 商业 / 战略价值：三者常冲突，按阶段调权重——探索期重用户、成长期重商业、成熟期重战略。
- 实操：候选需求三维各打 1-5 分加权排序，但分数辅助讨论而非替代判断，且要定期 review。
详情见 需求优先级排序
决策：RAG vs 微调 vs 长上下文（怎么给模型补知识）
什么时候纠结：模型缺某块知识/能力，不知道该外挂检索（RAG）、再训练（微调）还是直接把资料塞进上下文。
判断逻辑（业界公认的定性权衡，三者也常组合使用）：
| 方案 | 它解决什么 | 适合 | 不适合 |
|---|---|---|---|
| RAG（检索增强） | 给模型外接一个可更新的知识库，回答时检索相关片段 | 知识频繁更新、需要引用来源可溯源、知识量大、想低成本接入 | 想改模型的风格/语气/输出格式；纯能力问题而非知识缺口 |
| 微调（Fine-tuning） | 用数据再训练，把能力/风格固化进模型权重 | 改风格语气格式、固定领域能力内化、有足够高质量训练数据 | 知识频繁变动（一变就得重训）；数据量不足；要可溯源 |
| 长上下文（Long Context） | 把资料直接放进 prompt，一次性喂给模型 | 一次性、少量文档；实现最简单、无需额外工程 | 文档量大或反复查同一批资料（长文成本高、且易丢失中段信息）；需要持久知识库 |
经验取舍：知识层面问题优先 RAG，能力/风格层面问题才考虑微调，临时少量资料用长上下文最省事。三者不互斥（如 RAG 召回 + 长上下文承载 + 微调定风格）。
注：本节只列公认的定性权衡，未列具体量化数字——实际选择需结合自身数据量、更新频率与成本实测。
相关页面
→ 模型选型五维度 → 模型选型方法论 → Agent vs Workflow → 竞品分类四象限 → POC验证 → MVP验证 → 灰度发布 → 需求优先级排序 → AIPM知识地图