个人立场声明

为什么需要这篇声明

每一本技术书籍背后都有作者的偏见。区别在于：有些书假装没有偏见，有些书把偏见明确写出来。

假装没有偏见更危险——读者在不知不觉中接受了一套特定的价值预设，却以为自己读到的是客观事实。把偏见写出来，至少给了读者一个选择：了解了作者立场之后，自主决定哪些判断值得采信，哪些需要打折。

这篇声明提供校准信息。知道望远镜的光轴偏了多少度，观测数据就仍然有用。

本书的所有论证都以三条信念为根基。这三条信念写书之前就有了，也在实践中反复验证过。

战略判断的权重远大于战术执行。

架构决策的重要性远大于实现细节。选择把 LLM 定位为核心引擎还是胶水层，这个判断的影响远大于 prompt 怎么写、用哪个框架、调什么参数。花大量时间在战略层面想清楚，比在战术层面精雕细琢更有价值。战略对了，战术粗糙也能补救；战略错了，战术再精也白搭。

知道和做到之间隔着人性的弱点。

"应该用简单方案"几乎是共识，但实际选择时，复杂方案给人一种"考虑周全"的安全感。引入一个框架比自己写 50 行代码显得更"专业"。用微服务架构比用单体应用显得更"先进"。这些心理倾向——对确定性的渴望、对复杂性的迷恋、从众——是工程决策中最隐蔽的陷阱。

不确定性是约束条件，不是敌人。

LLM 的概率性输出是本质属性。硬要把 LLM 压成确定性函数——比如用极低的 temperature 加极严格的约束——往往会废掉 LLM 最有价值的能力。正确的做法是：承认不确定性存在，用类型系统和测试框架约束它到可接受的范围，把不确定性水平当成已知条件去做系统设计。

这三条原则在第二章展开详细论证。

以下偏好贯穿全书，列在这里供读者校准：

声明式优于命令式。 描述"要什么"比描述"怎么做"更不容易出错，更容易验证，更容易组合。SQL 优于手写循环遍历表，类型定义优于运行时检查，Pydantic 模型优于手动 JSON 解析。第三章（Code as Prompt）和第四章（类型系统与契约）集中体现了这个偏好。

简单方案优于"看起来高级"的方案。 如果 50 行代码能解决的问题，不要用一个框架。如果一个 API 调用能完成的任务，不要用 Agent 编排。复杂性有代价，每多一层抽象都增加理解和维护的负担。选复杂方案只有一个说得通的理由：简单方案确实无法满足需求，而且你已经验证过，不是靠推测。

结构驱动优于流程驱动。 好的结构自然地引导出正确的流程，反过来则不成立。先定义数据结构和接口契约，流程自然浮现。

类型系统优于运行时检查。 能在编译期（或定义期）捕获的错误，不要留到运行时。类型注解是可执行的规格说明。在 LLM 应用中，Pydantic 模型定义本身就是最好的 prompt——这个观点在第四章详细论证。

显式依赖优于隐式约定。 系统的每个依赖关系都应该能在代码里看到。在大模型应用中，这意味着 prompt 由什么拼成、模型用了什么参数、上下文从哪来，都应该追踪得到。

组合优于继承。 用小而专一的组件组合出复杂系统，而不是靠继承层次扩展功能。LLM 调用本身就是天然适合组合的独立单元。

这些偏好都有适用边界，都有反例。声明它们是为了让读者知道：当本书在两个同样合理的方案之间做出选择时，选择背后的倾向是什么。

作者的背景：数学与计算机科学双学位本科，计算机科学（数据科学方向）硕士。四年大厂工作期间主导设计过 Python 的类 Spring 框架。

数学训练带来了从基本假设正向推导的偏好，但不是所有问题都适合这样处理，有些工程问题的最优解法是"差不多就行"——本书可能在某些地方用力过猛。

大厂期间虽然身处团队，但核心工作习惯偏向独立设计：自己想清楚再推动落地。这导致本书对沟通成本、共识建设、妥协的艺术讨论不足。

对"先想清楚再动手"的偏好，可能低估了快速原型和迭代试错的价值。