1. 一个具体问题
一个只在周末导出报表的小工具，设计评审却提出插件市场、动态规则引擎和多租户任务编排。每项能力看起来都有用，合在一起后，部署和排错需要整套新知识。此时“功能更强”未必等于更适合当前问题。
2. 一句话解释
在满足真实约束的前提下，优先选择容易理解、验证和维护的简单方案，避免没有必要的复杂性。
3. 出处与原意
KISS 是常见的工程设计格言，通常与航空工程师 Kelly Johnson 联系在一起，洛克希德的官方人物介绍也记载他偏爱这一箴言。关于最早使用时间和具体措辞有不同说法，因此不宜把流传故事当成已确定的发明史。
4. 原理与机制
复杂性不只来自代码行数，也来自状态数量、组件依赖、配置组合以及维护时必须记住的隐含规则。一个短而晦涩的表达式可能比十行清楚代码更复杂；一个单文件程序也可能因为混杂职责而难以修改。判断简单与否，要看目标团队完成常见操作和处理失败时所需的认知成本。工程上的简单还必须包含必要的错误处理，删除备份和校验只是把复杂性转移给未来事故。
比较简单程度时，可以做一次维护演练：让没有参与设计的人完成配置变更、排查一次失败并回滚版本。如果一个方案少了几百行代码，却要求操作者理解十个隐含约定，它未必更简单。反之，增加一个明确的状态机可能使代码稍长，却让允许的转换和错误处理更直观。简洁是对使用与维护负担的优化，不是对代码长度的单一优化。
5. 一个完整案例
假设案例：小团队每周从三个固定表生成一份报表。最初方案要搭建通用工作流平台，预计两周开发；简化后用一个有明确输入输出的定时任务，加上失败告警、幂等文件名和人工重跑入口，三天即可投入使用。两个月后数据源增加到二十个，任务依赖开始复杂，团队再根据实际重复的调度需求引入编排工具。前一阶段的简单不是永远拒绝平台，而是没有为尚未出现的规模支付维护成本。
6. 适用条件与反例
适合原型、小工具和多个方案都能满足需求的选择。高可靠系统有时必须使用冗余与隔离，这些复杂性有明确价值。若“保持简单”意味着所有逻辑塞进一个函数，或省略关键边界测试，就偏离了降低理解和维护成本的目标。
7. 今天可以尝试的行动
对当前设计列出运行必需、故障恢复必需、未来可能需要三类能力。暂缓第三类中无法给出具体使用者与近期触发条件的部分。再让另一位维护者口头说明系统如何工作、失败后如何恢复，用解释难度检查是否真的变简单。