My Mathematical Regression：当工程直觉遇上数学直觉

背景

这篇短文源自 Hacker News 社区的一篇热门讨论，作者回顾了自己十年前在 Project Euler（欧拉计划）项目中的代码仓库。Project Euler 是一个以解决数学和计算机科学问题为主的在线平台，旨在通过编程挑战提升逻辑思维和数学能力。

作者在整理旧代码时，偶然发现了一个名为 problem15.txt 的文件。这个文件并没有包含任何复杂的代码，而是一段纯文本记录。这段记录不仅展示了作者当年作为工程学生时的解题思路，更引发了作者对于“过去自我”与“现在自我”之间认知差异的感慨。这种反差在 AI 时代尤为引人深思：当现在的作者面对类似问题时，第一反应是调用 AI 或编写 Python 脚本，而十年前的自己则直接洞察到了背后的数学规律。

核心内容

原文的核心在于对比作者十年前（作为工程学生时）与现在（作为职场工程师/AI 使用者）面对同一数学问题时的不同解决路径。

1. 问题背景：Project Euler Problem 15

虽然原文未直接给出 Problem 15 的具体描述，但根据作者提到的 2x2、1x1 和 3x3 网格以及“从左上角到右下角的路径数”这一经典语境，可以推断这是经典的网格路径问题：在一个 $n \times n$ 的网格中，从左上角移动到右下角，每次只能向右或向下移动，共有多少种不同的路径？

2. 十年前的解法：数学直觉与组合数学

作者十年前在 problem15.txt 中记录了解题过程，这段记录完全摒弃了编程思维，直接运用了离散数学中的组合论知识：

• 小规模案例观察：
  • $1 \times 1$ 网格有 2 种解法。
  • $2 \times 2$ 网格有 6 种解法。
  • $3 \times 3$ 网格有 20 种解法。
• 模式识别： 作者敏锐地发现了这些数字遵循二项式系数（Binomial Coefficient）的规律，即 $(2n)$ 选 $n$，记作 $\binom{2n}{n}$。
• 最终计算： 对于 $20 \times 20$ 的网格（Project Euler Problem 15 的具体规模），作者直接应用公式： $$ \binom{40}{20} = 137,846,528,820 $$ 整个过程无需编写任何代码，完全依赖数学推导。

3. 现在的解法：工程思维与 AI 依赖

作者反思了如果现在在工作中遇到这个问题，自己的反应会是：

• 首选 Python：作为工程师，本能地选择编程语言。
• 暴力破解（Brute Force）：可能会先写一堆循环来尝试所有路径。
• 优化策略：如果暴力法太慢，会引入记忆化搜索（Memoization）或动态规划（Dynamic Programming）。
• AI 介入：作者坦诚地表示，在现代工作流中，他可能根本不会手动编写这些逻辑，而是直接将问题丢给 AI，让它生成代码或给出答案，然后继续下一天的工作。

4. 情感共鸣：阿西莫夫式的失落感

作者对过去的自己感到钦佩，因为那时的他拥有纯粹的数学直觉和抽象思维能力。与此同时，他对现在的自己感到一丝悲伤。这种感受被作者比喻为阿西莫夫（Isaac Asimov）小说中的情节：主角发现了古代人编码的古老知识，虽然那是知识，但那种通过自身智力直接触及真理的震撼感已经消失。作者意识到，自己从一名“探索者”变成了一名“使用者”或“管理者”。

关键要点

• 数学 vs. 工程思维：
  • 数学思维关注问题的本质结构，寻找通解公式（如组合数学），追求简洁和优雅，往往能绕过计算过程直接得出结果。
  • 工程思维关注实现路径，倾向于使用通用工具（如 Python、循环、动态规划）解决具体问题，注重可行性和通用性，但可能忽略更优的数学捷径。
• Project Euler Problem 15 的数学本质：
  • 该问题等价于在 $2n$ 步中选择 $n$ 步向右（或向下），因此解为二项式系数 $\binom{2n}{n}$。
  • 对于 $20 \times 20$ 网格，答案为 137,846,528,820。
• AI 时代的工作流变迁：
  • 过去：手动推导公式 -> 手动编码实现。
  • 现在：理解问题 -> 提示 AI -> 验证结果。
  • 这种变迁提高了效率，但也可能导致基础数学直觉和算法设计能力的退化。
• 认知退化与适应：
  • 作者提到的“Sadness”并非指能力丧失，而是指“智力自主性”的让渡。当 AI 能够瞬间完成推导和编码时，人类从“解题者”转变为“提问者”和“审核者”。
• Project Euler 的教育意义：
  • 这类平台不仅训练编程，更训练将现实/抽象问题转化为数学模型的能力。十年前的作者展示了这种核心能力，而现在的作者则展示了如何利用工具放大这种能力（或替代它）。

意义与影响

1. 对技术从业者的警示

这篇文章引发了关于“技能退化”的广泛讨论。随着 AI 编程助手（如 GitHub Copilot、Cursor 等）的普及，初级工程师可能不再需要深入理解动态规划或组合数学即可完成任务。然而，理解底层数学原理对于调试复杂系统、优化算法性能以及设计新颖解决方案依然至关重要。完全依赖 AI 可能导致“黑盒思维”，即在遇到 AI 无法处理的边缘情况时缺乏解决能力。

2. 教育模式的反思

传统计算机科学教育往往强调算法实现和数据结构，而离散数学和组合数学有时被视为理论课程。这篇文章表明，扎实的数学直觉可以极大地简化工程问题。未来的教育可能需要重新平衡“数学理论”与“工程实践”的比重，或者更好地教授学生如何与 AI 协作，同时保持自身的数学素养。

3. AI 作为“认知外骨骼”

作者的经历展示了 AI 作为一种“认知外骨骼”的角色。它接管了繁琐的计算和代码生成，让人类专注于更高层次的问题定义和结果验证。然而，这种外骨骼的有效性取决于使用者是否具备足够的“元认知”能力——即知道何时该信任 AI 的输出，何时该回归基础原理进行验证。

4. 怀旧与自我认同

在技术快速迭代的今天，技术人员常常面临身份认同危机。通过回顾十年前的代码，作者不仅是在回顾技术，更是在回顾一种思维方式和生活状态。这种怀旧情绪提醒我们，在追求效率的同时，不应完全放弃对知识本质的探索和对智力挑战的享受。

总之，这篇文章不仅是对一个数学问题的回顾，更是对 AI 时代人类智力角色演变的深刻反思。它提醒我们，虽然工具在变，但理解问题本质的能力依然是技术人员的核心竞争力。