关注"怎么想"而非"怎么做"
不是 prompt 技巧手册，不是框架使用指南。是对"大模型时代的软件工程应该是什么样子"的系统性回答。
大模型应用的工程哲学
当软件系统的核心组件从确定性函数变成概率性语言模型，软件工程的基本原则会发生什么变化，又有什么不会变。
以下节选自第七章「把不确定性当缺陷」。如果你正在做 LLM 应用开发，看看这个场景是否眼熟：
当开发者试图通过堆叠更多规则来消除输出的不稳定性时，会进入一个恶性循环。
第一阶段：发现模型的输出不够"稳定"，于是在 prompt 中添加更多规则。"必须按以下格式输出"、"不得包含任何额外信息"、"严格遵循以下模板"。
第二阶段：更多的规则产生了新的问题。规则之间出现冲突——满足规则 A 的输出可能违反规则 B。模型在多个约束之间"挣扎"，输出质量反而下降。
第三阶段：为了应对规则冲突导致的质量下降，添加更多的规则来处理冲突。Prompt 从 200 token 膨胀到 2000 token。开发者花费大量时间调优 prompt 的措辞，每一个词的修改都可能引发蝴蝶效应。
第四阶段：维护成本失控。一个 2000 token 的 prompt 变成了"碰不得的遗留代码"——没有人敢修改它，因为没有人完全理解每一条规则的存在理由和它们之间的相互作用。
这个循环的根源是目标就错了：试图在 prompt 层面实现确定性控制，但 prompt 本来就提供不了确定性控制。书里讨论了正确的替代思路。
把不确定性当缺陷 -- prompt 越写越长、约束越堆越多、temperature 设为 0、重试逻辑越来越复杂——如果你正在做这些事情，你可能在和大模型的本质属性对抗。
编排框架的过度设计 -- 15 行代码能完成的事情，框架用了七层抽象。这不是工程，是仪式。
AI 辅助编程的正确姿势 -- "AI 写代码，人来审查"这个模型从根本上就是错的。高效的人机协作是分层控制，不是流水线质检。
Schema as Workflow -- Schema 的字段排列定义了 LLM 的推理路径。每个字段承担一个推理步骤，字段级单一职责是声明式思维链的前提条件。