编程即理论构建
Peter Naur 于1985年提出：程序不仅是代码，更是开发者头脑中关于系统如何工作、为何如此工作的鲜活理论。
源代码 (Source Code)
理论的有损表达
心智理论 (Mental Theory)
- 设计意图与权衡
- 架构决策的缘由
- 业务领域知识
- 系统演进的脉络
可视化隐喻：代码只是冰山一角，真正的程序存在于构建者的思想中。
理论失传危机
一个由经验断层和技术催化剂共同造成的完美风暴，正在侵蚀我们代码库的根基。
经验断层：一半是新人
开发者数量约每5年翻倍，这意味着在任何时刻，都有一半的开发者经验不足5年。
AI 加速了理论的消亡
反身性AI使用
未经思考，直接接受LLM生成的代码，错失了构建理解的认知过程。
领域盲区的代码
生成的代码缺乏业务上下文和架构考量，它只是“能运行”，但“不属于”这里。
理论真空与技术债
代码库变得不连贯，无人能解释其设计缘由，维护成本指数级增长。
两种协作路径
与AI的互动方式，决定了你是理论的消费者还是构建者。
反身性使用者
- 目标是快速获得能“用”的代码。
- 不深究原理，直接复制粘贴。
- 将AI视为答案提供者。
- 产出：功能孤岛，破坏系统理论一致性。
刻意协作者
- 目标是加深对问题的理解。
- 理解、质疑并重构AI生成的代码。
- 将AI视为高效的辅助工具。
- 产出：与系统理论相符，高质量且可维护的代码。
资深开发者：理论的守护者
在AI时代，他们的价值不减反增，因为他们从事的是机器无法替代的核心智力活动。
领域理论构建者
将业务领域知识转化为健壮的软件架构。
架构理论守护者
确保新代码符合系统理论，维护概念完整性。
刻意AI协作者
驾驭AI，让其服务于系统理论，而非破坏它。
理论与技艺导师
传承心智模型和解决问题的艺术，培养下一代理论构建者。
如何保护与传承理论？
组织必须投资于促进理论构建与传递的文化和实践。
捕获意图的文档
使用ADR等工具，记录“为什么”，而不仅是“是什么”。
知识共享实践
组织技术分享、结对编程，传递隐性的心智模型。
理论一致性审查
Code Review不仅检查正确性，更要评估新代码是否与系统理论契合。
建立导师制度
让资深开发者系统性地培养新人的理论构建能力。
结论：人是不可或缺的理论核心
LLM能生成代码，但无法构建理论。真正的软件工程，是关于构建、维护和演进那些赋予代码意义的心智模型。在一个代码泛滥的时代，能够驾驭理论的开发者，才是最宝贵的资产。编程的技艺（Craft）永不过时。
内容改编自 Christian Ekrem 的文章 "Programming as Theory Building"
信息图由 AI 协作构建