加载失败
讨论围绕一篇断言“因简洁没人升职”的文章展开，评论通过面试实例（有人在面试里建议用 Google Sheets、或在 Stripe 的收购面试里说用 Postgres）来说明现实与面试期望常常错位。参与者讨论了系统设计面试（system design interview，一种考察架构与权衡能力的面试形式）、组织晋升机制（promotion packet/晋升材料）、以及 AI 代码生成对复杂化的放大效应。多数回复认为问题在于激励与可见性：复杂方案容易写出“可讲的故事”被量化表彰，而简洁的长期价值必须被转译成业务或运维指标（如 SLO、MTTR、成本节省）才能被管理层识别。最终共识是按情境权衡：既要避免无谓复杂，也要学会把简洁的影响做成可证明的输出。
多条评论以“建议用 Google Sheets 或直接用 Postgres”这类务实回答为例，指出面试官常把系统设计题当成展示复杂技术路线的机会，从而惩罚提出现成可行方案的候选人。评论里有人把这种情况归结为面试训练不足：合格的流程应先承认实用答案，再明确是否要考察设计能力或通过增加约束（比如用户数、权限需求、跨系统集成）来推进讨论。对神经多样性候选人而言，模糊的面试目的尤其不公平；许多回复建议候选人在给出务实方案后补充“如果不能用现成工具，我会怎么做”来兼顾现实与演练。总的共识是，面试者应主动引导场景或明确目标，而不是以“你没按我想的答”作为淘汰理由。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
大量评论认为公司晋升与可见度机制更容易奖励复杂、可叙事化的工程（例如引入抽象层、构建事件总线等），而将简单、低维护成本的解决方案视为“看不见”的贡献，从而造成“promotion-driven development”。讨论中提到的现实做法包括 CV/packet 驱动的研发、用技术花哨程度当作评价信号，以及通过委员会和层级机制放大这种偏好。为对抗这一点，评论建议把简洁的价值翻译成业务指标：用减少事故、降低运维成本、缩短 MTTR 或直接的美元节省来写晋升材料，甚至倡导“删代码也能被公开表扬”的文化。也有人指出组织博弈（game theory）会自我强化地偏好复杂方案，使得简单难以自然获得奖励。
评论普遍认为 LLM/AI 编码工具把构建复杂架构的门槛降得很低：一个“scalable event-driven architecture”可以在几分钟内被生成出来，但生成物往往缺乏可理解性、测试和长期维护的上下文。很多人警告这会把更多看似“高大上”的架构快速投产，从而把调试、运维和 on‑call 成本留给后来的人。讨论中也提到用策略文件（如 AGENTS.md）加入 KISS、YAGNI 等指导原则可以缓解一部分问题，但多位评论者强调 AI 仍需人类监督与设计判断，否则会把复杂化放大并加速技术债累积。少数人反驳说当前生成物还远不能替代有经验工程师的架构判断，但一致的忧虑是长期拥有可维护性的能力没有因此自动得到改善。
评论里提出了若干把“简洁”转化为可被奖励事实的做法：把改进写成一页商业案（量化节省和回收期）、用监控（如 Prometheus/Grafana）把 SLO/MTTR 改善数据化、在晋升材料里列出删掉的代码/降低的运维工时。还有人建议在 PR 和设计评审里同时列出复杂方案与简单方案，并写明选择简单方案的成本/收益比较，以便评审和管理层能看到权衡过程。写清楚“如果要扩展需要做什么、现在不做的成本是多少”比单纯做出简单实现更容易说服不看好简洁的决策者。
许多回帖提醒：是否选择简单方案取决于组织规模、业务约束和未来可维护性。评论举例说在多数面试设定里 Postgres 足以满足吞吐与一致性需求，但在像大厂那样要求内部认证、跨区 n+2 可用性的环境下，直接用 Postgres 需要额外的整合和审核，因而会被视为“不够标准”。也有反向示例：为了解决千行重复样板代码而先做大量抽象（比如把 OpenAPI 当 AST 来生成代码），短期复杂化换取长期对开发者的简化与一致性。结论是要用具体的规模、约束与运维成本来权衡，而不是把“简单”或“复杂”作为道德判断。
Google Sheets（Google 表格）: Google 的云端电子表格工具，评论中作为“现成可用、低成本解决方案”的代表，用来说明在工程选择上应优先考虑既有工具而非重造轮子。
Postgres（PostgreSQL）: 开源关系型数据库，评论里多次被举为能够满足许多系统设计面试中吞吐与一致性要求的实用选项，常被用来反驳面试中不必要的复杂化。
YAGNI（You Aren't Gonna Need It）: 软件工程原则，主张不要为未证实的未来需求提前设计和实现功能，以避免不必要的复杂性。
KISS（Keep It Simple, Stupid）: 设计格言，鼓励尽量保持方案简单，避免过度设计，以提高可读性和可维护性。
Pub/Sub（publish–subscribe）: 发布/订阅消息传递架构，一种常见的事件驱动设计模式，评论中常作为“复杂方案”的示例（例如替代直接用数据库的简单实现）。
SLO / MTTR（Service Level Objective / Mean Time To Recovery）: SLO 是服务级别目标，用于定义可接受的可靠性；MTTR 是平均修复时间。评论建议用这些可量化的运维指标（配合 Prometheus/Grafana 等监控工具）把简洁带来的收益转为晋升材料的证据。
Promotion packet（晋升材料 / promotion packet）: 晋升评估时提交的文档集，包含项目叙事、指标与影响说明。讨论中强调要把简洁價值翻译成可度量的商业/运维指标写入此包以提高可见度。