软件工程领域从不缺乏方法论和原则，但有些原则直指人性本身。Miller 原则（The Miller Principle）正是这样一条看似戏谑却发人深省的工程准则：No one reads anything，直译即为「没有人会阅读任何东西」。这一原则并非某位学术权威的系统总结，而是由技术博主 Pure Danger 多年前提出，却在软件工程社区中持续引发共鸣。它所揭示的现实，对我们编写文档、设计接口、乃至整个开发流程都有深远的指导意义。

Miller 原则的核心内涵

Miller 原则的核心论断非常简单：无论你投入多少精力编写用户文档、设计规范、代码注释，或是精心打磨用户界面上的每一行文字，实际上几乎没有人会认真阅读它们。这并不是说文档和注释毫无价值，而是提醒工程师们在投入时间之前，应当首先思考一个根本问题：如何让信息在不依赖主动阅读的情况下被理解和获取？

该原则的具体适用范围涵盖了软件工程的多个层面。首先是用户文档，无论是传统的 PDF 手册还是在线帮助文档，真正逐字阅读的用户少之又少。其次是需求规格说明书，即便开发团队内部，也很少有人会通读整份文档。第三是代码注释，许多经验丰富的工程师都有过这样的经历：注释写得很详细，但维护者仍然视而不见。第四是用户界面上的文字提示，按钮标签、错误消息、引导文案，这些文本的存在本意是帮助用户理解操作，但实际使用中用户往往凭借直觉和视觉线索行动。最后是电子邮件，长篇大论的内部沟通邮件很少被完整阅读，关键信息往往在开头几行就决定了阅读者是否会继续下去。

理解这一原则的现实基础需要从认知负荷和注意力经济两个角度切入。人类的工作记忆容量有限，这是认知心理学的基本事实；当信息量超过承载能力时，人们自然会采取捷径 —— 跳过、略读或直接忽略。与此同时，现代软件产品带来的信息过载使得用户的注意力成为稀缺资源，他们没有动力也没有时间去阅读每一段文字。因此，Miller 原则本质上是对这一人性特征的真实描述，而非倡导放弃文档编写。

工程实践中的转化策略

既然 Miller 原则揭示了「无人阅读」的现实，那么软件工程师应当如何应对？答案不在于不写文档，而在于转变文档的生产方式，使其更加适应真实的使用场景。

在代码层面，「自文档化」（Self-Documenting Code）是应对 Miller 原则的首要策略。这意味着变量命名应当足够清晰以至于不需要额外注释就能理解意图，函数应当保持短小以降低理解成本，模块和类的职责应当单一且明确。当代码本身已经成为最好的文档时，注释的角色就需要重新定位 —— 注释应当解释「为什么」而非「是什么」，即说明代码背后的业务决策、边界条件或非显而易见的实现逻辑，而非重复代码已经表达的内容。

在用户界面设计层面，Miller 原则要求采用「渐进式披露」（Progressive Disclosure）模式。一次性展示所有功能和选项会徒增用户的认知负担，而按照用户的使用阶段逐步展示相关信息，则能显著提升可用性。错误消息的设计也应当遵循这一原则，过于技术化的错误描述对普通用户毫无帮助，简明扼要且提供下一步行动建议的消息更能发挥作用。

在文档编写层面，应当优先投资于可发现性和可操作性文档。传统的冗长手册已经难以满足需求，更有效的方式是提供场景化的快速入门指南、在用户需要帮助的上下文环境中嵌入即时提示、以及建立结构化的知识库支持模糊搜索。这意味着文档的存在形态从「一次性编写的长文本」转变为「持续维护的模块化内容」，每个模块都可以独立存在并被按需访问。

在团队协作层面，Miller 原则对内部沟通同样适用。冗长的技术方案文档往往在评审时被一带而过，更有效的做法是在文档之外附加执行摘要，用关键决策点和结论先行抓住读者的注意力。设计评审和代码审查会议也需要在会前提供足够的上下文，使得会议时间可以集中在讨论而非信息同步上。

与现代工程实践的融合

Miller 原则与现代软件工程的若干主流实践天然契合。API 优先设计（API-First Design）本质上就是为了让接口在文档之外也能自解释，良好的 RESTful 约定、GraphQL schema 定义、以及 gRPC 的.proto 文件都允许开发者通过代码生成文档，而无需依赖额外的文字说明。开发者体验（Developer Experience，DX）这一概念的兴起也呼应了 Miller 原则的精神 —— 优秀的 API 应当像优秀的用户界面一样，通过设计本身传递信息，而非依赖大量的使用教程。

持续集成与持续交付实践同样受到 Miller 原则的影响。当构建脚本、部署配置和基础设施即代码（Infrastructure as Code）足够清晰时运维人员无需阅读冗长的运维手册，配置项的含义通过命名和结构就能传达。测试驱动开发（TDD）中的测试用例本身也成为一种文档形式，它们通过可执行的代码表达了系统的预期行为，比静态的自然语言描述更加可靠且易于维护。

值得注意的是，Miller 原则并非鼓励工程师完全放弃文档编写，而是提醒我们重新思考文档的价值定位。在某些场景下，文档仍然不可或缺 —— 法律合规要求的说明、复杂业务规则的解释、跨团队协作的接口约定，等等。关键在于判断何时文档的投资回报率足够高，以及如何设计文档使其能够在「无人阅读」的现实下仍然发挥作用。

工程化参数与落地建议

将 Miller 原则转化为可执行的工程实践，需要在团队层面建立若干共识和操作规范。首先，在代码审查中将注释质量纳入评估标准，鼓励删除冗余注释的同时保留解释性注释，审查者需要判断注释是否真的在传递代码本身无法表达的信息。其次，在文档产出上采用「除非必要否则不写」的原则，每个文档都应当有明确的目标受众和使用场景，无明确读者的文档应当被推迟或取消。第三，在用户界面设计中遵循「三次点击原则」的延伸理念：任何重要功能都应当在用户目光所及的三秒内被发现或被理解，无需用户主动搜索帮助文档。第四，在技术方案评审中将执行摘要设为必须部分，摘要长度不超过一页，内容聚焦于决策结论和风险要点，正文仅供需要深入了解细节的成员阅读。

Miller 原则的更深层启示在于，软件工程的核心挑战不仅是技术实现，更是人机交互和人际协作中的信息传递效率。当我们认识到「没有人会阅读任何东西」这一现实后，工程师的设计决策就应当更多地考虑信息的可发现性、可推断性和可操作性，而非假设用户会主动学习和阅读。这种思维转变最终会体现在更好的产品、更高效的团队协作和更低的维护成本上。

资料来源：Pure Danger Tech - The Miller Principle（https://puredanger.github.io/tech.puredanger.com/2007/07/11/miller-principle/）