一个关于软件的顿悟
一篇关于“把编程看作构建理论”的个人博客文章认为，软件开发真正的工作是在构建并维护关于系统的丰富心智模型；这也解释了为什么遗留代码难以修改、独立开发者有时能胜过团队，以及为什么重写常常比接手既有代码库更轻松。读者大体认同这一核心观点，并将其与心智模型、概念完整性、文档质量、领域知识，甚至 AI 生成代码如果缺少相应理论就会变成“黑箱”等问题联系起来。不过，许多人被网站上的一个带动画通知组件所困扰，该组件会追踪实时访客；这引发了对用户体验的强烈批评，以及使用阅读模式和广告拦截规则等规避方法，最终作者移除了该功能，并解释了最初的设计意图。
站点 UX 和通知弹窗
- 大多数评论都盯着页面底部的“实时访客”通知流。
- 许多人形容它很分心、让人“晕船”，甚至有癫痫风险；有些人原则上拒绝阅读这篇文章。
- 建议的规避方法包括：浏览器阅读模式、uBlock/NoScript 规则、用实体方式遮住屏幕底部。
- 有人认为用户不应该为了一个博客的 UX 去“修复”它；也有人说这篇文章足够好，值得做一点小小的规避。
- 作者后来出现在讨论串中，解释了其意图（让网站感觉“有生命”，并突出隐私影响），并表示在这波批评后该功能已被移除。
“理论” vs “模型” / 术语争论
- 几位评论者觉得“理论”这个词令人困惑，建议改用“模型”、“心智模型”、“抽象”或“理解”等更清晰的术语。
- 也有人为“理论”一词辩护，采用 Ryle/学术语境中的含义：一种内在的、部分无法言说的结构，使熟练行动成为可能。
- 讨论中有一些语义上的来回争辩，焦点在于理论是否必须可传达，以及它与意图或领域知识有何不同。
软件即理论 / 知识媒介
- 许多人认同这样一种观点：真正关键的资产是代码背后的共享心智理论，而不只是代码本身。
- 这一点被用来解释：
- 为什么遗留系统很难修改。
- 为什么对整个系统都了然于胸的独立开发者有时能胜过更大的团队。
- 为什么重写往往比接手陌生代码更容易。
- 也有人提出异议，认为真正的“产品”是业务结果/产出，而理论只是重要但次要的资产。
遗留代码、文档与集体理解
- 几位评论者描述了在文档很差的遗留系统上重建理论的真实经历。
- 有人坚持认为，高质量文档和版本历史可以捕捉到很大一部分缺失的理论；也有人说理论永远不可能被完全外化。
- 强调理解往往是集体性的，分布在团队之中，而不是某一个人的头脑里。
AI 辅助编程
- 有个讨论串把理论这一概念与对 AI 代码生成的不适联系起来：AI 的输出感觉像一个缺乏内部理论的“黑箱”。
- 也有人提出一种交互模式：AI 逐步帮助构建代码和解释，人类仍然能形成一个可用的理论。