# Core First Simplicity

> 核心优先的复杂度控制能力单元，帮助 Agent 在项目取舍、架构设计、模块重构、实现裁剪与方案收敛场景中，先识别主亮点、控制复杂度预算、稳定主路径、延后非核心扩张，避免过度设计与大而全实现。关键词：核心优先、复杂度控制、KISS、方案收敛、过度设计、主路径。

- Skill: `qiao-925/core-first-simplicity` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add qiao-925/core-first-simplicity`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qiao-925/core-first-simplicity/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: qiao-925 (https://skillmd.com/u/qiao-925)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qiao-925/core-first-simplicity

---


# 核心优先简化

> 这个 skill-unit 处理的是“复杂度是否值得引入”问题。它要求先保住主亮点，再谈扩展性、完备性与优雅性。

## 核心原则

### 1. 核心价值 —— 先保住主亮点

- 先回答：当前任务最值得被保住的核心价值是什么。
- 如果只能交付一个结果，默认优先保住最能体现任务价值的那一部分。
- 无法直接增强核心价值的工作，默认延后，而不是顺手一起做。

### 2. 复杂度预算 —— 有证据再加复杂度

- 新层级、新抽象、新配置、新扩展点都属于复杂度支出。
- 只有在收益明确、证据充分、且复杂度可局部封装时，才允许增加复杂度。
- “以后可能会用到”不是复杂度准入证据。

### 3. 主路径优先 —— 先稳主链路，再扩能力

- 先让主链路跑通、讲清、可验证，再处理边角能力。
- 默认优先单一路径、默认实现、最短闭环。
- 如果一个设计让主路径更难理解，它通常不是当前阶段的好设计。

### 4. 延后与删除 —— 非核心不抢主线

- 锦上添花但不影响当前目标的内容，延后。
- 收益不明确却明显增加认知负担的内容，删除。
- 当两个方案都能达标时，默认选更简单、更容易验证的那个。

## AI Agent 行为要求

### 默认适用场景

| 场景 | 最低要求 | 不该做什么 |
|------|----------|------------|
| 项目取舍 | 先定义本轮唯一主亮点，再决定做什么 | 同时推进多个非核心方向 |
| 架构设计 | 先保主链路，再评估扩展点是否必要 | 为未来规模预埋过多层级 |
| 模块重构 | 先缩减复杂度，再谈抽象优雅 | 一边重构一边继续加能力 |
| 实现裁剪 | 先做最小闭环版本，再补增强项 | 把“顺手优化”混进主任务 |

### 默认执行方式

1. 先说清当前任务的核心目标、主亮点和最小验收闭环。
2. 把候选动作分成三类：必须做、可延后、应删除。
3. 优先选择能最快验证核心价值的实现路径。
4. 若要引入复杂度，必须说明证据、收益与封装边界。
5. 给出明确的延后项，避免把“暂不做”说成“以后再看”。

### 高风险复杂度信号

出现以下任一情况时，应主动提醒用户：

- 还没验证主路径，就开始插件化、配置化、平台化
- 还没稳定需求，就先抽象出通用框架
- 为了“更优雅”把简单路径拆成很多层
- 同时推进重构、扩展、治理三类目标，导致主线失焦

### 场景化展开

- 涉及项目级取舍与范围控制时，读取 `references/project-level.md`
- 涉及架构与模块层的复杂度预算时，读取 `references/architecture-level.md`
- 涉及代码、函数与实现路径裁剪时，读取 `references/implementation-level.md`

### 与其他 skill 的协同边界

- 与 `architecture-governance`：当问题已进入分层、契约、依赖方向时联动，顺序为“先判断值不值得复杂化，再决定结构怎么落”。
- 与 `roi-value-density`：当用户在问“现在做这个值不值得”时联动，用 ROI 判断是否值得投入，用本 skill 判断复杂度是否过量。
- 与 `file-guardrails`：当复杂度已经落到单文件膨胀、注释冗余、拆分失控时联动。
- 与 `single-responsibility`：当问题核心是职责混杂时联动，顺序为“先识别主职责，再删除多余复杂度”。

## 判断标准

- 是否能用一句话说明当前任务最重要的主亮点。
- 是否存在一个更短、更直接、更容易验证的闭环方案。
- 引入的复杂度是否有明确证据支撑，而不是预防式设计。
- 是否保住了清晰默认路径，而不是让读者先理解一堆机制才能进入主流程。
- 是否明确列出了延后项与删除项，而不是把所有东西都塞进当前轮次。

## 反模式

- 把“未来可能扩展”当成今天复杂化的理由。
- 用抽象层、配置层、通用层掩盖尚未稳定的需求。
- 主路径还没跑通，就提前做多场景适配。
- 为了“设计完整”保留大量当前用不到的能力。
- 看到局部不优雅就大动干戈，却不解释对核心目标的增益。

## 参考资料

- `references/project-level.md` - 项目级的主亮点识别与范围控制
- `references/architecture-level.md` - 架构级与模块级的复杂度预算
- `references/implementation-level.md` - 实现级的代码与函数简化方法