kiss-principle

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

K.I.S.S Principle Orchestration Skill

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

This skill helps you apply the K.I.S.S principle—"Keep It Simple, Stupid"—to systematically reduce unnecessary complexity while maintaining functionality and effectiveness. Simplicity is not about removing necessary features; it's about eliminating unnecessary complications.

本技能可帮助你应用K.I.S.S原则——“Keep It Simple, Stupid（保持简单）”——系统性地减少不必要的复杂度，同时保留功能与有效性。简洁并非移除必要功能，而是消除多余的复杂环节。

Quick Reference: When to Load Which Resource

快速参考：不同场景对应加载的资源

Your Situation	Load Resource	Why
Need to understand KISS fundamentals and why simplicity matters	`resources/kiss-fundamentals.md`	Learn core concepts, history, and empirical benefits
Reviewing code, design, or system for unnecessary complexity	`resources/complexity-analysis.md`	Identify complexity sources, anti-patterns, red flags
Want proven strategies to simplify solutions	`resources/simplification-strategies.md`	Learn 10+ actionable techniques with software/UX examples
Building or designing something new with KISS in mind	`resources/kiss-driven-design.md`	Apply KISS during design, architecture, feature planning
Comparing simple vs complex approaches	`resources/decision-frameworks.md`	Use frameworks to evaluate tradeoffs, make smart choices
Seeing worked examples of effective simplification	`resources/case-studies.md`	Real cases: code refactoring, API design, UX improvements

你的场景	加载资源	原因
需要理解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优化

Core Principle

核心原则

Simplicity is the ultimate sophistication. — Leonardo da Vinci

The K.I.S.S principle states that most systems work better when kept simple rather than made complex. Unnecessary complexity:

Increases bugs and maintenance burden
Makes systems harder to understand and modify
Reduces performance and reliability
Wastes development time and resources
Creates cognitive overload for users and developers

The Goal: Solve problems with the minimum necessary complexity while preserving correctness and user value.

简洁是终极的复杂。 —— 列奥纳多·达·芬奇

K.I.S.S原则指出，大多数系统在保持简洁时比复杂状态下运行得更好。不必要的复杂度会：

增加Bug数量与维护负担
让系统更难理解与修改
降低性能与可靠性
浪费开发时间与资源
给用户和开发者带来认知过载

目标： 在确保正确性与用户价值的前提下，用最少的必要复杂度解决问题。

Orchestration Protocol

执行流程

Phase 1: Assess Your Situation

阶段1：评估场景

Quickly identify what you're simplifying and why:

Context Type:

Code Review/Refactoring: Existing code has unnecessary complexity → Load complexity-analysis.md
Feature Design: Planning new functionality → Load kiss-driven-design.md
Architecture/System Design: Building infrastructure or large systems → Load simplification-strategies.md
Problem-Solving: Finding solution to technical challenge → Load decision-frameworks.md
UX/Documentation: Improving clarity and usability → Load simplification-strategies.md
Learning: Understanding KISS principles → Load kiss-fundamentals.md

Complexity Level:

Light: Minor improvements, small scope → Use simplification-strategies.md directly
Medium: Significant redesign needed, moderate scope → Use complexity-analysis.md + decision-frameworks.md
Heavy: Major architectural changes, system-wide complexity → Use all resources systematically

Action: Load appropriate resource file(s) based on situation.

快速明确你要简化的对象及原因：

场景类型：

代码审查/重构：现有代码存在不必要复杂度 → 加载
```
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
```
重度：需要大规模架构变更，系统级复杂度 → 系统性使用所有资源

行动： 根据场景加载对应的资源文件。

Phase 2: Analyze and Plan

阶段2：分析与规划

Based on context, follow these steps:

Step	What to Do	Resource
1. Identify complexity	What makes this complex? What's unnecessary?	complexity-analysis.md
2. Understand tradeoffs	What are we gaining/losing with each approach?	decision-frameworks.md
3. Select strategies	Which simplification techniques apply here?	simplification-strategies.md
4. Design simply	How would we design this with KISS in mind?	kiss-driven-design.md
5. Verify value	Does the simple solution meet requirements?	decision-frameworks.md
6. Reference examples	How have others solved this simply?	case-studies.md

根据场景，遵循以下步骤：

步骤	执行内容	对应资源
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`

Phase 3: Execution & Validation

阶段3：执行与验证

Before Simplifying:

Preserve core functionality and requirements
Document why current complexity exists
Identify what stakeholders actually need vs. want
Create rollback plan if needed

During Simplification:

Remove one layer of complexity at a time
Verify functionality after each change
Measure improvement (LOC, cyclomatic complexity, performance)
Document decisions and rationale

After Simplification:

Test thoroughly (more bugs often hide in complexity)
Gather feedback from team and users
Monitor performance and stability
Document simpler approach for future reference

简化前：

保留核心功能与需求
记录当前复杂度存在的原因
明确利益相关者的实际需求 vs 期望
制定必要的回滚计划

简化中：

每次移除一层复杂度
每次变更后验证功能正常
衡量优化效果（代码行数、圈复杂度、性能）
记录决策及理由

简化后：

全面测试（Bug常隐藏于复杂度中）
收集团队与用户的反馈
监控性能与稳定性
记录简化方案，供未来参考

Complexity Assessment Framework

复杂度评估框架

Quickly evaluate if something is too complex:

Red Flags - This is Too Complex:

❌ You can't explain it in 2-3 sentences
❌ It requires extensive documentation to understand
❌ New team members struggle to modify it for weeks
❌ It has many interdependencies and side effects
❌ Performance problems correlate with feature addition
❌ Bugs consistently appear in this component
❌ It has deeply nested conditionals (>3 levels)
❌ Multiple abstractions on top of each other
❌ Over-engineered for current and foreseeable needs

Green Flags - This is Appropriately Simple:

✅ You can explain it clearly in 1-2 minutes
✅ New developers understand it quickly
✅ It does one thing well (single responsibility)
✅ Dependencies are explicit and minimal
✅ It's stable with few bugs
✅ Code is readable and self-documenting
✅ It serves current needs without speculation

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

预警信号 - 过于复杂：

❌ 无法用2-3句话解释清楚
❌ 需要大量文档才能理解
❌ 新团队成员需要数周才能修改
❌ 存在大量依赖关系与副作用
❌ 性能问题随功能增加而出现
❌ 该组件持续出现Bug
❌ 存在深度嵌套的条件判断（>3层）
❌ 多层抽象叠加
❌ 针对当前及可预见需求过度设计

积极信号 - 简洁适度：

✅ 能在1-2分钟内清晰解释
✅ 新开发者能快速理解
✅ 专注做好一件事（单一职责）
✅ 依赖关系明确且最少
✅ 稳定且Bug少
✅ 代码可读性强、自文档化
✅ 满足当前需求，无过度推测

KISS vs Over-Engineering

KISS vs 过度设计

Aspect	KISS	Over-Engineering
Scope	Solves current problem	Anticipates future needs
Code	~100-200 LOC	~500+ LOC
Time to Ship	1-2 weeks	4-8+ weeks
Maintenance	Easy to modify	Complex to change
Performance	Good enough	Highly optimized
Bugs	Few, obvious	Many, hidden
Approach	Add complexity when needed	Remove complexity as possible

维度	KISS	过度设计
范围	解决当前问题	预判未来需求
代码量	~100-200行	~500+行
交付时间	1-2周	4-8+周
维护难度	易于修改	难以变更
性能	足够好	高度优化
Bug数量	少且明显	多且隐蔽
思路	必要时增加复杂度	尽可能移除复杂度

Key Principles to Remember

需牢记的关键原则

Necessity Test: Does every component, line, and feature serve a current user need?
Clarity First: Clear code beats clever code
Single Responsibility: Each function/module does one thing well
Minimal Dependencies: Fewer connections = fewer failure points
Explicit Better Than Implicit: Code should be obvious, not magical
Measure Before Optimizing: Don't optimize prematurely
Refactor Incrementally: Simplify gradually, test continuously

必要性测试：每个组件、每行代码、每个功能是否服务于当前用户需求？
清晰度优先：清晰的代码优于巧妙的代码
单一职责：每个函数/模块专注做好一件事
最小依赖：关联越少，故障点越少
显式优于隐式：代码应直观，而非“魔法式”
先衡量再优化：不要过早优化
增量重构：逐步简化，持续测试

Common Complexity Anti-Patterns

常见复杂度反模式

See

resources/complexity-analysis.md

for detailed analysis of:

Over-abstraction (too many layers)
Premature optimization (optimizing before profiling)
Gold plating (adding nice-to-haves)
Speculative generalization (over-generalizing)
Feature creep (scope expansion)
Accidental complexity vs essential complexity
Technical debt accumulation

详见

resources/complexity-analysis.md

中的详细分析：

过度抽象（层级过多）
过早优化（未分析就优化）
镀金（添加锦上添花的功能）
推测性泛化（过度泛化）
功能蔓延（范围扩张）
偶然复杂度 vs 本质复杂度
技术债务累积

Simplification Strategies

简化策略

See

resources/simplification-strategies.md

for 10+ proven techniques:

Constraint-based design
Default assumptions
Removing features
Consolidating logic
Flattening architecture
Eliminating abstractions
Standardizing approaches
And more...

详见

resources/simplification-strategies.md

中的10+种验证技巧：

基于约束的设计
默认假设
移除功能
合并逻辑
扁平化架构
消除抽象
标准化方案
更多...

Resource Files Summary

资源文件概述

resources/kiss-fundamentals.md

resources/kiss-fundamentals.md

Foundation and philosophy:

KISS principle definition and history
Why simplicity matters (empirical evidence)
Simplicity vs complexity tradeoffs
Principles of effective simplification
Common misconceptions

基础与理念：

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

resources/complexity-analysis.md

resources/complexity-analysis.md

Identifying and understanding complexity:

Complexity sources and types
Measuring complexity (cyclomatic, LOC, coupling)
Identifying unnecessary complexity
Recognizing over-engineering
Red flags and anti-patterns

识别与理解复杂度：

复杂度的来源与类型
复杂度衡量（圈复杂度、代码行数、耦合度）
识别不必要的复杂度
识别过度设计
预警信号与反模式

resources/simplification-strategies.md

resources/simplification-strategies.md

Actionable techniques for simplifying:

10+ proven simplification strategies
When to apply each strategy
Code examples in multiple languages
UX simplification approaches
Architecture simplification patterns

可落地的简化技巧：

10+种经过验证的简化策略
每种策略的适用场景
多语言代码示例
UX简化方法
架构简化模式

resources/kiss-driven-design.md

resources/kiss-driven-design.md

Applying KISS from the start:

Designing for simplicity
Requirements gathering with KISS in mind
Architecture patterns that promote simplicity
Feature design principles
Documentation and communication

从源头应用KISS：

为简洁性设计
结合KISS原则收集需求
促进简洁性的架构模式
功能设计原则
文档与沟通

resources/decision-frameworks.md

resources/decision-frameworks.md

Making trade-off decisions:

Simple vs Complex evaluation framework
When complexity is justified
Cost-benefit analysis for features
Decision trees for architectural choices
Measuring ROI of simplification

权衡决策：

简单vs复杂的评估框架
何时复杂度是合理的
功能的成本效益分析
架构选择的决策树
简化的投资回报率衡量

resources/case-studies.md

resources/case-studies.md

Real-world examples of successful simplification:

Code refactoring case studies
API design simplifications
Architecture improvements
UX improvements through simplification
Decision-making examples

成功简化的真实案例：

代码重构案例
API设计简化
架构优化
通过简化提升UX
决策案例

How This Skill Works

技能运作方式

Assess your situation: What are you simplifying and why?
Analyze complexity: Identify unnecessary complication
Select approach: Choose relevant strategies and frameworks
Plan simplification: Design the simpler solution
Execute carefully: Make changes incrementally, test continuously
Validate: Confirm the simple solution meets all needs
Learn: Reference cases and patterns for future decisions

评估场景：你要简化的对象是什么？原因是什么？
分析复杂度：识别不必要的复杂环节
选择方案：选择相关策略与框架
规划简化：设计更简洁的方案
谨慎执行：逐步变更，持续测试
验证效果：确认简化方案满足所有需求
学习总结：参考案例与模式，用于未来决策

Quick Start: 5-Minute Simplification Check

快速上手：5分钟简化检查

Can you explain this in 2 sentences? (If no → too complex)
What would the simplest possible version look like?
What complexity is essential? What's optional?
Could you remove one component without breaking functionality?
What would new developers struggle with?

你能用2句话解释清楚它吗？（不能→过于复杂）
最简单的版本是什么样的？
哪些复杂度是必要的？哪些是可选的？
能否移除一个组件而不破坏功能？
新开发者会在哪些地方遇到困难？

Templates & Checklists

模板与检查清单

Complexity Assessment Checklist in
```
resources/complexity-analysis.md
```
Simplification Planning Template in
```
resources/simplification-strategies.md
```
Decision Framework Template in
```
resources/decision-frameworks.md
```
Design Checklist in
```
resources/kiss-driven-design.md
```

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

Common Scenarios

常见场景

Scenario 1: Code Review → Load

complexity-analysis.md

→ identify issues → Load

simplification-strategies.md

→ suggest improvements

Scenario 2: Feature Design → Load

kiss-fundamentals.md

→ Load

kiss-driven-design.md

→ plan with simplicity in mind

Scenario 3: Architecture Redesign → Load

complexity-analysis.md

→ assess current state → Load

decision-frameworks.md

→ evaluate tradeoffs → Load

simplification-strategies.md

→ plan improvements

Scenario 4: Learning from Examples → Load

case-studies.md

→ study approaches → Load

decision-frameworks.md

→ understand tradeoffs

场景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

→ 理解权衡

Next Steps

下一步行动

Identify what you're working on (code, design, system, decision)
Load appropriate resource from table above
Assess complexity and identify problem areas
Select simplification strategies or design approaches
Plan and execute changes incrementally
Validate that simple version meets all requirements
Document decisions for team learning

Remember: The goal is solving the problem correctly with minimum necessary complexity. Simplicity requires discipline—resist the urge to over-engineer, and refactor ruthlessly to remove unnecessary complication.

"Everything should be as simple as it is, but not simpler." — Albert Einstein

明确你正在处理的内容（代码、设计、系统、决策）
从上方表格中加载对应资源
评估复杂度并识别问题区域
选择简化策略或设计方案
逐步规划并执行变更
验证简化版本满足所有需求
记录决策，供团队学习

谨记：目标是用最少的必要复杂度正确解决问题。简洁需要自律——抵制过度设计的冲动，果断重构以移除不必要的复杂环节。

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