《怎样解题》读书笔记：波利亚四阶段方法的实践用法

2026 年 9 月扩写：原文只有一句话。本次修订把它整理成可实践的读书笔记，不虚构个人阅读日记，也不大段引用原书。

乔治·波利亚的《怎样解题》出版于 1945 年，主题是数学解题，但它更持久的贡献超出了数学：它让“我不知道”到“我有一个可以辩护的答案”之间通常被隐藏的工作变得可观察。普林斯顿大学出版社把本书描述为对启发法——发现与发明方法——的介绍，并指出它自 1945 年以来持续再版，已有多种译本。

选择版本，或者先借阅

本文讨论的是方法，不依赖某一版的页码。找书时，最好按 ISBN 而不是封面辨认：

出版版本、价格和可购性会因国家或地区而变化。购买前如想合法借阅，可先查询本地或大学图书馆；Open Library 的版本记录可以帮助定位馆藏，并且只会在相应版本和地区确有可借资源时显示借阅入口。

希望支持独立书店的读者，可以查看普通、无追踪的 Bookshop.org 美国书目或 Bookshop.org 英国书目。美国站与英国站是分开的地区服务。这些不是联盟链接，本文目前不会从中获得佣金。

著名框架分为四个阶段：

  1. 理解问题；
  2. 拟定计划；
  3. 执行计划；
  4. 回顾检查。

这张表很容易背，也很容易被低估。它的价值不在于把四个标题当成保证成功的算法，而在于每个阶段所提出的问题，以及当计划暴露出理解错误时允许我们退回上一步。

1. 理解问题

在计算或写代码之前，先把问题写成别人也能检查的形式。

可以问：

  • 未知量是什么？
  • 已知事实、输入和限制是什么？
  • 哪些词语含糊不清？
  • 什么结果才算正确？
  • 能否画图、构造一个小例子，或用自己的话重述任务？

这一阶段能避免一种常见失败：为错误的问题给出技术上正确的答案。“让程序更快”还不是可测试的问题；“在输出不变的前提下，把固定数据集的处理中位时间从 12 秒降到 8 秒以内”就清楚得多。

这个阶段的产出应是一段简短的问题陈述、已知与未知、限制条件，以及成功检查方法。

2. 拟定计划

计划是一条值得尝试的路线，不是成功预言。波利亚的启发法包括寻找相关问题、考虑更简单的情形、引入合适的符号、添加辅助元素、分解目标，以及从期望结果反推。

在实际工作中，尽可能准备多个候选方案：

  • 用最小输入复现失败；
  • 比较一个正常案例和一个失败案例；
  • 隔离较大流程中的一个阶段；
  • 从期望输出向后追踪；
  • 用可控替代物换掉复杂组件；
  • 寻找应该始终保持不变的量。

然后选择成本最低、能够消除最多不确定性的方案。一个五分钟就能推翻假设的诊断，往往比花一小时实现这个假设更有价值。

3. 执行计划

执行需要纪律。写下假设，每次只做一个可解释的变化，并检查中间结果。如果某一步无法推出，就停下来修补推理，不要用更多工作把缺口盖住。

在软件工作中，这意味着保存失败输入、记录完整错误、增加针对性检查，并只改变一个变量。在数学中，这意味着说明每次变换的理由，确认所用定理的条件确实成立。在研究中，这意味着区分观察与推断，并记录足够上下文以便复现。

计划失败时，失败本身就是证据。带着新限制回到前两个阶段，而不是更用力地重复同一个尝试。

4. 回顾检查

第四阶段能把一个已经解决的案例变成可复用知识。

检查：

  • 答案是否满足原始条件？
  • 能否用第二种方法或极限情况验证？
  • 哪个假设是关键？
  • 是否有更简单的解释？
  • 这个方法能否解决更广的一类问题？
  • 什么测试、笔记或工具能避免下一次出现同样困惑？

修复后的程序错误应该变成回归测试。完成的推导应该用代入、量纲或独立路线核查。有效工作流应该成为一张小清单，而不是只留下一段故事。

示例：批处理程序悄悄漏掉文件

假设一个程序接收十个文件，却只生成八个输出。

理解：记录准确输入列表、预期的一对一对应、输出目录、日志、退出状态和两个缺失文件名。“有时会漏文件”被换成可复现的问题陈述。

计划：比较一个成功文件与一个缺失文件；把批次缩小到这两个；检查筛选、文件名解析和逐文件异常；从写出结果的阶段向前追踪。

执行：给各阶段增加计数，运行双文件案例，每次只改变一个可疑条件。证据也许显示，大写扩展名没有通过区分大小写的筛选器。

回顾：统一扩展名，增加混合大小写和特殊文件名测试，确认十个输出全部生成，并记录输入规则。修复现在保护以后所有批次，而不只是救回这一次运行。

这个示例不是波利亚原书中的内容，只是用来说明同一套阶段怎样迁移到技术维护中。

这个框架做不到什么

四阶段不能代替领域知识、证据、创造力和判断。结构清楚的计划仍可能建立在错误数据上。有些问题有多个可接受答案；另一些问题受到伦理、法律、成本或不确定性约束，而不是只有一个数学证明。

这套框架也不是严格线性的。测试计划时，理解会继续加深；回顾时，也可能发现原问题定义得不好。循环是它的特点，不是缺陷。

一张精简工作表

问题：
期望结果与成功检查：
已知事实：
未知量：
限制条件：

候选计划：
成本最低且信息量最大的测试：

步骤与观察：
被推翻的假设：

验证：
更简单的解释：
可复用的测试、笔记或工具：
下一个问题：

这个习惯很符合 Lazying.Art 的想法：把一次艰难获得的解法变成清楚的成果，让别人或未来的自己可以复用，从而减少重复摩擦。开源项目正是这些成果变成代码、文档与工具的地方。

2018 年原文

原帖全文只有一句英文：

This book introduced a way to analyze problems and develop solutions.

参考资料

Leave a Reply