选择无聊的技术（2015）
一篇广为引用的文章呼吁团队“选择无聊的技术”，由此引发了关于何时应偏向成熟、充分理解的技术栈，而不是那些承诺更高回报但也带来更多风险的新工具的争论。许多工程师称赞“创新代币”之类的想法，认为它是限制系统中少数几个领域引入新颖性的实用方式，尤其是在初创公司或基础设施场景中，此时可靠性、共享平台和可维护性比简历驱动的选择更重要。另一些人则认为“无聊”这样的标签过于模糊，可能会阻碍恰当评估；他们指出，技术决策应由上下文、团队经验、不断演变的生态系统（从 Node 和 Kubernetes 到 AI 代理以及适合 LLM 的技术栈）和明确的需求共同驱动。
创新代币与“无聊”技术
- 许多评论者仍然喜欢“创新代币”的表述，认为它可以用来向非工程师解释取舍，并将风险集中在少数几个领域。
- 其他人则认为这个比喻比较模糊；决策应当明确围绕风险、测试、失败模式和团队专业知识来表述，而不是“无聊 vs 新”。
- 一些人强调，“无聊”是有上下文的：如果一个团队本来就熟悉 Node、Mongo、Rust 等，那么这些技术对他们来说也许就算无聊。
定义“无聊”
- 线程中的一个工作定义是：其能力、尤其是失败模式都已被充分理解，几乎不会出现“我没想到它还能这样”的惊喜。
- 常被提到的无聊技术示例包括：Postgres/MySQL、PHP/Ruby/Django、cron、memcached、基础的 Linux + HAProxy 栈。
- 有人认为，包括“无聊”的数据库在内，每个系统都有很多坑；无聊只是意味着“已知的、最不坏的选择”。
Node、JavaScript 与生态系统的快速更迭
- 普遍认为到 2026 年，Node 本身已经算“无聊”了，但很多人仍然觉得 JS 生态（npm 膨胀、工具链更迭、供应链风险）并不无聊。
- 对于 JS 生态里的任何东西能否与其他语言相比称得上成熟，也存在争论。
Kubernetes 与基础设施复杂性
- 对把 Kubernetes 视为无聊技术的说法反对声很强；许多人认为，对大多数公司来说它过于复杂，而且是故障和认知负担的主要来源。
- 有人主张，简单的裸机或 VPS 方案，配合一个小而稳定的技术栈（Linux + Postgres + PHP/Python），对大多数业务应用已经足够。
激励、职业生涯与“简历驱动开发”
- 一些评论指出，简历激励和英雄文化会奖励炫技技术和救火，而不是预防问题和无聊但可靠的系统。
- 也有人不喜欢“简历驱动开发”这类说法，认为它不公平地给人动机贴上坏标签。
AI/代理与无聊技术
- 有人建议把创新代币花在 AI/代理上，并让它们与模型熟悉的、分布内的无聊栈搭配使用（例如 Django、PHP、Go）。
- 也有人担心 LLM 会默认推荐流行或炒作中的栈（TypeScript/Next.js），从而扭曲选择。
- 还有人认为，LLM 实际上让人更容易有效地使用更老、更简单的技术。
对这一论点的批评
- 批评者说，“选择无聊的技术”可能变成一种终结思考的陈词滥调，用来阻止合适的创新，或者为不合适的遗留技术栈辩护。
- 替代主张是：始终“选择最合适的技术”，而“无聊”只是需求、工作负载匹配、招聘和运维成本等因素之一。