30 个在软件工程中反复出现的思维模型——每个配一个技术决策案例
这份清单收录了 30 个在软件工程中最反复出现的思维模型。每个模型都配有：
不问"怎么成功"，问"怎么失败"——然后避免那些
Agent 映射：不问"Agent 怎么成功"，问"Agent 怎么搞砸"——无限循环、幻觉输出、权限滥用、成本失控。防护措施就是反演法的产出。
每个决策的连锁反应——一阶效应是直接的，二阶是间接的
Agent 映射：给 Agent 更多工具→能做更多事（一阶）→工具选择困难/选错（二阶）→限制工具集反而更好。
不做"最好"的选择，做"期望值最高"的选择
Agent 映射：Agent 输出不是"确定的"而是"概率性的"——设计时应该假设输出可能错误，需要验证层。
知道自己的知识边界，在圈内行动比在圈外冒险更高效
Agent 映射：Agent 也有能力圈——LLM 擅长文本处理，不擅长精确计算。给 Agent 计算器工具就是在扩展它的能力圈。
做 A 的成本是不做 B 的收益——每个"是"背后都有无数个"否"
Agent 映射：Token 预算有限——花在长上下文上的 token 就不能花在更多轮对话上。每个选择都有 token 机会成本。
在预期需求和实际能力之间留缓冲——系统韧性 > 系统效率
Agent 映射：Agent 的输出验证层、工具权限分级、Token 预算限制——都是安全边际在 Agent 设计中的体现。
最简解释优先——假设最少的解释最可能正确
Agent 映射：Agent 输出异常时，先查 Prompt 问题（最常见），再查数据问题，最后才归咎于模型。
不要归因于恶意，用愚蠢就够了
Agent 映射：Agent 出了有害输出？先假设是 Prompt 设计问题（疏忽），不是模型价值观问题（恶意）。
回归最基本的事实，从零推理——不用类比抄答案
Agent 映射：设计 Agent 时，先理解 LLM 的本质能力（语言理解、模式匹配），再从这些基本能力推导架构，而非照搬别人的 Agent 框架。
所有抽象都有泄漏——底层细节总会在某处暴露
Agent 映射：Agent 框架抽象了 LLM 调用，但 Token 限制、幻觉问题、上下文窗口溢出就是泄漏的细节——你不能完全不理解 LLM 就用好 Agent。
复杂性不会消失，只会转移——你简化了一面，另一面就更复杂
Agent 映射：简单的 Agent 架构（单次调用）→ 功能受限。复杂的 Agent 架构（多轮+工具+记忆）→ 调试和可靠性复杂。复杂性只是转移了。
做一次，收益 N 次——代码是杠杆，自动化是杠杆，文档也是杠杆
Agent 映射：Agent 本身就是杠杆——一次 Prompt 设计，重复使用。好的 Prompt 模板比好的代码复用性更高。
小的持续改进，长期产生指数级收益
Agent 映射：Agent 的 Prompt 迭代就是复利——每次小的改进都被后续所有调用继承。第 10 次迭代比第 1 次好 10 倍。
系统的产出由最弱的环节决定——优化非瓶颈环节是浪费
Agent 映射：Agent 响应慢→先找瓶颈在哪。是 LLM 推理？是工具调用？是检索？优化非瓶颈步骤不会改善用户体验。
正反馈加速增长，负反馈维持稳定——所有系统都由反馈环驱动
Agent 映射：Agent + 工具执行结果 = 反馈环。Agent 看到工具输出后调整行动——这就是负反馈（修正错误）。
系统中的延迟导致过冲和振荡——调得太猛反而更不稳定
Agent 映射：Agent 的多步推理中，每步之间有延迟。太长的推理链 → 延迟累积 → 用户等太久。短链+工具替代长链推理。
系统架构反映组织的沟通结构——4 个团队做出来的系统有 4 个模块
Agent 映射：多 Agent 系统的架构应该反映任务的自然分解，而非人为划分。Agent 的边界 = 信息流边界。
能力最低的人最倾向于高估自己——你不知道自己不知道的
Agent 映射：Agent 会自信地给出错误答案——这是 LLM 的 Dunning-Kruger。置信度校准是关键研究方向。
已经投入的成本不应影响未来决策——只看未来收益和成本
Agent 映射：Agent 在一条推理路径上走了很远但不通→应该切换路径而非"已经想了这么久继续想"。这需要显式的回退机制。
你只看到成功的案例，看不到失败的大多数
Agent 映射：看别人的 Agent 框架"跑通了"→觉得自己也能做。但你看不到无数失败的 Agent 项目。关注失败案例比成功案例更有价值。
模型/文档/设计图不等于现实——不要把描述和被描述的东西混淆
Agent 映射：Prompt 不是 Agent——写了个好 Prompt 不代表 Agent 在生产环境就靠谱。需要实际测试和监控。
80% 的效果来自 20% 的努力——找到那 20%
Agent 映射：80% 的 Agent 使用场景只需要 20% 的工具→精简工具集比大而全更有效。
系统中少量高影响力的干预点——找到它们，小改变大效果
Agent 映射：Agent 系统的杠杆点——Prompt 优化 > 工具增加 > 模型升级。改一个 Prompt 可能比加 10 个工具更有效。
简单规则组合产生复杂行为——整体大于部分之和
Agent 映射：多个简单 Agent 组合→涌现出复杂的协作行为，也可能涌现出意想不到的失败模式。需要系统级测试。
效率追求"刚好够"，韧性追求"够有余"——常态下效率好，危机时韧性救命
Agent 映射：Agent 的 Token 使用——100% 利用率（刚好够）vs 留余量（韧性）。余量让你应对意外输入。
一方比另一方知道得多——市场失灵的主要原因
Agent 映射：Agent 比用户更了解它的能力边界——如果 Agent 不主动告知局限，用户就会在信息不对称下做出错误决策。
用户越多，产品越有价值——正向飞轮
Agent 映射：Agent 生态的网络效应——越多开发者贡献工具/模板→Agent 越强大→更多用户→更多贡献者。
第一个接收到的信息会"锚定"后续判断
Agent 映射：Agent 的第一轮输出会锚定用户的期望——如果第一轮输出质量低，用户会低评价整个 Agent。
模型在训练数据上表现太好，在新数据上表现差——过度适应历史，不能泛化
Agent 映射：Prompt 过度针对特定场景优化→换个场景就崩。好的 Prompt 应该有一定泛化能力——用少样本而非大量硬编码规则。
已经存在很久的东西，预计还会继续存在很久——时间是最好的过滤器
Agent 映射：选择 Agent 框架时，Lindy 效应建议选存在更久的（如 LangChain）而非最新的——虽然新框架功能多，但老框架的稳定性经过了时间检验。
面对不同类型的决策，应该优先使用哪些模型？
| 决策类型 | 首选模型 | 次选模型 | 避坑模型 |
|---|---|---|---|
| 技术选型 | 第一性原理 + 能力圈 | 机会成本 + Lindy 效应 | 幸存者偏差（别只看成功案例） |
| 架构设计 | 复杂性守恒 + Conway's Law | 抽象泄漏 + 二阶效应 | 过度拟合（别为 3 个客户定制） |
| 故障排查 | 奥卡姆剃刀 + 汉隆剃刀 | 瓶颈理论 | 地图≠领土（文档可能过期） |
| 产品优先级 | 机会成本 + Pareto 原则 | 二阶效应 + 反馈环 | 沉没成本（别因为已投入就不砍） |
| 定价策略 | 机会成本 + 信息不对称 | 锚定效应 + 网络效应 | 达克效应（别高估自己对市场的理解） |
| Agent 设计 | 第一性原理 + 安全边际 | 能力圈 + 反馈环 | 涌现（多 Agent 有意外行为） |
| 团队管理 | 汉隆剃刀 + 能力圈 | 杠杆 + 复利 | 达克效应（别让新手做关键决策） |
把 30 个模型按 Agent 架构层面分组：
第一性原理（回归 LLM 本质能力）→ 奥卡姆剃刀（最简 Prompt）→ 过拟合（避免硬编码）→ 概率思维（输出不确定）
能力圈（只加 LLM 做不到的）→ 机会成本（每个工具的选择成本）→ 复杂性守恒（加工具加复杂性）→ 抽象泄漏（工具会暴露底层细节）
安全边际（输出验证+权限分级）→ 反演法（先想怎么失败）→ 汉隆剃刀（先想设计问题而非模型问题）→ 信息不对称（让用户知道局限）
反馈环（Agent+工具结果=反馈）→ 延迟效应（长推理链的延迟）→ 涌现（多 Agent 的意外行为）→ 韧性 vs 效率（Token 预算的余量）
瓶颈理论（找 Agent 响应慢的瓶颈）→ Pareto（80% 场景用 20% 功能）→ Lindy 效应（选成熟框架）→ 复利（小改进长期积累）