kiss-principle

K.I.S.S 原则编排技能

此技能帮助你应用 K.I.S.S 原则——“Keep It Simple, Stupid”（保持简单，别犯傻）——系统性地减少不必要的复杂性，同时保持功能和有效性。简洁并非去除必要功能，而是消除不必要的繁琐。

快速参考：何时加载哪种资源

你的情况	加载资源	原因
需要了解 KISS 基础知识，以及简洁为何重要	resources/kiss-fundamentals.md	学习核心概念、历史和实证优势
审查代码、设计或系统中是否存在不必要的复杂性	resources/complexity-analysis.md	识别复杂性来源、反模式和危险信号
想要经过验证的方案来简化解决方案	resources/simplification-strategies.md	学习 10 种以上可行技巧及软件/UX 示例
在构建或设计新事物时贯彻 KISS	resources/kiss-driven-design.md	在设计、架构和功能规划中应用 KISS
比较简单与复杂的方案	resources/decision-frameworks.md	使用框架评估权衡，做出明智选择
查看有效简化的实例	resources/case-studies.md	真实案例：代码重构、API 设计、UX 改进

核心原则

简洁是终极的复杂。 — Leonardo da Vinci

K.I.S.S 原则指出，大多数系统保持简单时，比变得复杂时运作得更好。不必要的复杂性：

• 增加 Bug 和维护负担
• 使系统更难理解和修改
• 降低性能和可靠性
• 浪费开发时间和资源
• 给用户和开发者造成认知过载

目标： 以最低限度的必要复杂性解决问题，同时保持正确性并为用户创造价值。

编排协议

阶段 1：评估你的情况

快速确定你要简化什么，以及原因：

上下文类型：

• 代码审查/重构：现有代码存在不必要的复杂性 → 加载 complexity-analysis.md
• 功能设计：规划新功能 → 加载 kiss-driven-design.md
• 架构/系统设计：构建基础设施或大型系统 → 加载 simplification-strategies.md
• 问题解决：寻找技术难题的解决方案 → 加载 decision-frameworks.md
• UX/文档：提升清晰度和易用性 → 加载 simplification-strategies.md
• 学习：理解 KISS 原则 → 加载 kiss-fundamentals.md

复杂度：

• 轻度：小幅改进，范围较小 → 直接使用 simplification-strategies.md
• 中度：需要重大重新设计，范围适中 → 使用 complexity-analysis.md + decision-frameworks.md
• 重度：重大架构变更，涉及系统级复杂性 → 系统性地使用所有资源

操作： 根据情况加载相应的资源文件。

阶段 2：分析和规划

根据上下文，按照以下步骤进行：

步骤	操作	资源
1. 识别复杂性	是什么让它变得复杂？哪些部分是不必要的？	complexity-analysis.md
2. 理解权衡	每种方案会带来什么或失去什么？	decision-frameworks.md
3. 选择策略	哪些简化技巧适用于此处？	simplification-strategies.md
4. 简化设计	如何以 KISS 为指导进行设计？	kiss-driven-design.md
5. 验证价值	简单方案能满足需求吗？	decision-frameworks.md
6. 参考示例	其他人如何以简单的方式解决此问题？	case-studies.md

第 3 阶段：执行与验证

简化之前：

• 保留核心功能和要求
• 记录当前复杂性的成因
• 明确利益相关者实际需要什么，而非想要什么
• 如有需要，制定回滚计划

简化过程中：

1. 每次只移除一层复杂性
2. 每次变更后验证功能
3. 衡量改进情况（LOC、圈复杂度、性能）
4. 记录决策及其依据

简化之后：

• 进行全面测试（复杂的代码中往往藏着更多 Bug）
• 收集团队和用户的反馈
• 监控性能和稳定性
• 记录更简单的方案，供日后参考

复杂性评估框架

快速评估某项内容是否过于复杂：

危险信号——过于复杂：

• ❌ 无法用 2-3 句话解释清楚
• ❌ 需要大量文档才能理解
• ❌ 新团队成员需要数周才能修改它
• ❌ 存在许多相互依赖和副作用
• ❌ 性能问题随着功能增加而出现
• ❌ 该组件总是出现 Bug
• ❌ 条件判断嵌套过深（超过 3 层）
• ❌ 多层抽象叠加
• ❌ 设计过度，超出当前和可预见的需求

良好信号——简单恰当：

• ✅ 能在 1-2 分钟内清楚地解释
• ✅ 新开发者能快速理解
• ✅ 做好一件事（单一职责）
• ✅ 依赖关系明确且最少
• ✅ 稳定，Bug 较少
• ✅ 代码易读且能自我说明
• ✅ 满足当前需求，不做臆测

KISS 与过度工程化

方面	KISS	过度工程化
范围	解决当前问题	预判未来需求
代码	约 100-200 LOC	约 500+ LOC
交付时间	1-2 周	4-8+ 周
维护	易于修改	修改复杂
性能	足够好	高度优化
Bug	少且明显	多且隐蔽
方法	需要时再增加复杂性	尽可能移除复杂性

请牢记的关键原则

1. 必要性检验：每个组件、每行代码和每项功能是否都满足当前用户需求？
2. 清晰优先：清晰的代码胜过巧妙的代码
3. 单一职责：每个函数或模块都做好一件事
4. 尽量减少依赖：连接越少，故障点越少
5. 显式优于隐式：代码应一目了然，而非充满魔法
6. 优化前先衡量：不要过早优化
7. 渐进式重构：逐步简化，持续测试

常见复杂性反模式

详细分析请参阅 resources/complexity-analysis.md：

• 过度抽象（层级过多）
• 过早优化（分析性能前就开始优化）
• 过度修饰（添加锦上添花的功能）
• 臆测式泛化（过度泛化）
• 功能蔓延（范围扩大）
• 意外复杂性与本质复杂性
• 技术债务累积

简化策略

10 多种经过验证的技巧请参阅 resources/simplification-strategies.md：

• 基于约束的设计
• 默认假设
• 移除功能
• 合并逻辑
• 扁平化架构
• 消除抽象
• 统一方法
• 以及更多……

资源文件摘要

resources/kiss-fundamentals.md

基础与理念：

• KISS 原则的定义与历史
• 简单性为何重要（实证依据）
• 简单性与复杂性的权衡
• 有效简化的原则
• 常见误解

resources/complexity-analysis.md

识别并理解复杂性：

• 复杂性的来源与类型
• 衡量复杂性（圈复杂度、LOC、耦合度）
• 识别不必要的复杂性
• 识别过度工程化
• 危险信号与反模式

resources/simplification-strategies.md

可执行的简化技巧：

• 10 种以上经过验证的简化策略
• 每种策略的适用时机
• 多种语言的代码示例
• UX 简化方法
• 架构简化模式

resources/kiss-driven-design.md

从一开始就践行 KISS：

• 简化设计
• 以 KISS 为指导收集需求
• 推动简化的架构模式
• 功能设计原则
• 文档与沟通

resources/decision-frameworks.md

权衡取舍的决策：

• 简单与复杂的评估框架
• 复杂性何时有其必要
• 功能的成本效益分析
• 架构选择的决策树
• 衡量简化的 ROI

resources/case-studies.md

成功简化的真实案例：

• 代码重构案例
• API 设计简化
• 架构改进
• 通过简化改善 UX
• 决策示例

此技能的工作方式

1. 评估当前情况：你要简化什么？为什么？
2. 分析复杂性：找出不必要的复杂之处
3. 选择方法：选取相关策略和框架
4. 规划简化方案：设计更简单的解决方案
5. 谨慎执行：逐步更改，持续测试
6. 验证：确认简单的解决方案满足所有需求
7. 学习：参考案例和模式，为未来决策提供依据

快速入门：5 分钟简化检查

1. 你能用 2 句话解释它吗？（如果不能 → 说明过于复杂）
2. 尽可能简单的版本会是什么样？
3. 哪些复杂性不可或缺？哪些是可选的？
4. 能否移除一个组件，同时不影响功能？
5. 新开发者会在哪些地方遇到困难？

模板与检查清单

• resources/complexity-analysis.md 中的复杂性评估检查清单
• resources/simplification-strategies.md 中的简化规划模板
• resources/decision-frameworks.md 中的决策框架模板
• resources/kiss-driven-design.md 中的设计检查清单

常见场景

场景 1：代码审查 → 加载 complexity-analysis.md → 找出问题 → 加载 simplification-strategies.md → 提出改进建议

场景 2：功能设计 → 加载 kiss-fundamentals.md → 加载 kiss-driven-design.md → 以简化为目标进行规划

场景 3：架构重新设计 → 加载 complexity-analysis.md → 评估当前状态 → 加载 decision-frameworks.md → 评估权衡取舍 → 加载 simplification-strategies.md → 规划改进

场景 4：从示例中学习 → 加载 case-studies.md → 研究方法 → 加载 decision-frameworks.md → 理解权衡取舍

后续步骤

1. 确认你正在处理的内容（代码、设计、系统或决策）
2. 从上表加载适用的资源
3. 评估复杂性并找出问题区域
4. 选择简化策略或设计方法
5. 逐步规划并执行更改
6. 验证简单版本满足所有要求
7. 记录决策，供团队学习

---

请记住：目标是以尽可能低的必要复杂性正确解决问题。简化需要自律——抵制过度设计的冲动，并果断重构，去除不必要的复杂之处。

“凡事都应尽可能简单，但不能过于简单。”——阿尔伯特·爱因斯坦