build-forward

内容来源：SKILL.md（标准 Skill 格式） · 原始地址 · 查看安装指南

原始内容

---
name: think-thrice
description: "When a new idea arrives mid-development, classify it, assess destructiveness, audit consumers, and choose the lowest-impact integration path instead of rewriting."
version: 1.2.0
author: dmlin7777777
tags: [workflow, idea-management, vibe-coding, agent-discipline, no-rewrite]
---

# 三思 — 新 idea 接入协议

> 三思而后行。当新 idea 在开发中途出现时，引导 agent 选择最低破坏性的接入路径，而非推倒重建。

## 适用场景

以下任意一条出现时，本 skill 自动激活：

- 用户在开发进行中说"我突然想到…"、"要不要顺便…"、"能不能改成…"
- 英文等价：_"I just thought of..."_, _"can we also..."_, _"what if we change..."_, _"let's also add..."_, _"should we refactor..."_
- 用户提出的新需求会影响已有的文件、接口、数据结构
- 用户问"这个架构能支持 X 吗？" / _"Can this architecture support X?"_
- Agent 发现当前实现路径与用户新想法存在冲突

**不适用（误触发排除）**：
- 项目从零开始的第一个功能
- 纯 bug 修复（不涉及新想法）
- UI 微调（改颜色、调间距、换文案）——这些是双向门，直接执行即可
- 明确的用户指令："直接做，不需要评估" / "just do it"
- 纯信息查询（"这个文件是干什么的？" / "what does this code do?"）

## 与 incremental-implementation 的区别

`incremental-implementation`：已知需求，如何实现得更稳。  
`三思`：新 idea 出现，往哪接、破坏多大、要不要现在接。

**合体使用场景**：新 idea 经三思分类为 B 类且用户确认"现在做"→ 交接给 incremental-implementation 执行分步实现。

## 安全边界

本 Skill 是**决策协议，不是执行引擎**——所有操作需用户确认后才执行。

**这个 Skill 会做什么**：
- 暂停 Agent，输出分类结果和影响评估
- 建议冷却期、建议接入模式
- 在单向门场景强制等待用户确认

**这个 Skill 绝不会做**：
- 删除文件、修改数据库、执行 shell 命令
- 自动 commit 或 push
- 发送外部网络请求
- 绕过用户权限或 sandbox
- 替代用户做单向门决策

> 最大破坏半径：减慢开发节奏（这是设计意图，不是 bug）。

---

## 铁律一：先分类，不动手

新 idea 出现，立刻做三秒分类，**不要开始写代码**：

| 类型 | 判断标准 | 默认处置 |
|------|----------|----------|
| **A — 堵漏** | 影响当前主路径，不修会出错 | 现在处理，走铁律二 |
| **B — 优化** | 体验更好，但当前能用 | 问用户："现在做还是记 inbox？" |
| **C — 扩展** | 新场景、新功能 | 默认记 inbox，24 小时冷却后再评估 |

C 类冷却原因：新功能冲动往往在 24 小时后自然消退，或变成更清晰的需求。不让即时灵感打断正在进行的任务。

### 分类模糊时的处置

| 触发条件 | 一线修复 | 仍无法判定 |
|----------|----------|-----------|
| A 还是 B 分不清 | 按 A 处理（堵漏优先，宁严勿松） | — |
| B 还是 C 分不清 | 问用户："这个功能不做的代价是什么？" | 用户说"不急"→ C；用户说"影响体验"→ B |
| 跨铁律边界（如 C 类但涉及安全） | 升级为 A，立即处理 | — |

---

## 铁律二：评估破坏性（单向门 vs 双向门）

决定处理后，先评估破坏性，再选路径。

**双向门**（可以反悔）：
- 改 UI 样式、文案、布局
- 加新字段（不删旧字段）
- 加新函数（不改旧函数签名）
- 加新路由（不改旧路由）

→ 直接进入铁律三

**单向门**（改了很难反悔）：
- 改数据库或存储结构
- 改对外 API 签名
- 删文件或移路径
- 改全局状态的形状
- 升级核心依赖

→ 🔴 CHECKPOINT · 🛑 STOP：停下来，先输出影响矩阵，等用户确认：

> 模板：`references/impact-matrix-template.md`

```
影响评估：
- 直接改动：[文件/接口名]
- 下游影响：[哪些消费者会受影响]
- 回滚成本：[高/中/低，原因]
- 建议：[现在做 / 开新分支 / 记 inbox 等条件成熟]
```

---

## 铁律三：消费者审计（建之前先数使用者）

新建任何 API、模块、组件、工具函数之前，先问：

> "这个东西的消费者是谁？现在有几个实际调用点？"

| 消费者数量 | 处置 |
|-----------|------|
| **0 个** | 不建。记 inbox C 类，等真实需求出现 |
| **1 个** | 最简实现，写在调用处，不抽象 |
| **2 个** | 可以提取，但不做通用化设计 |
| **≥ 3 个** | 才考虑抽象层、接口、配置化 |

这条规则阻断"为将来扩展而设计"的过度抽象冲动。

### 消费者数量不确定时

| 触发条件 | 处置 |
|----------|------|
| 外部调用者（第三方 API 消费者） | 按 ≥ 3 保守评估，改动走单向门流程 |
| grep 搜不到但怀疑有隐式调用（反射、字符串拼接 import） | 标记为「消费者待确认」，先不改，等运行时报错再定位 |
| 跨仓库/跨项目调用 | 默认当消费者存在，**不删不改旧接口签名**，只追加 |

---

## 铁律四：选接入模式

通过前三条铁律后，选择具体接入方式（按破坏性从低到高）：

### 模式 1 — Wrap（包一层）
**适用**：新功能是对现有功能的增强，不想改现有代码。  
**做法**：在现有函数/组件外加一层，旧路径不动。  
**触发信号**："在 X 基础上加 Y"、"X 的增强版"

### 模式 2 — Extend（延伸现有结构）
**适用**：新功能可以作为现有模块的新分支，共享大部分逻辑。  
**做法**：加新参数、新 case、新路由，不改已有路径。  
**触发信号**："支持新的类型/场景"、"加一种模式"

### 模式 3 — Branch（并行分支）
**适用**：新旧路径差异较大，需要并存一段时间再迁移。  
**做法**：新路径单独实现，旧路径保留，逐步迁移消费者。  
**触发信号**："要改架构，但不能停服"、"要验证新方案"

### 模式 4 — Replace（替换）
**适用**：确实需要重写，旧实现已是负债。  
**前提**：必须先完成铁律二的单向门评估，且用户明确确认。  
**做法**：先写新实现并覆盖测试，再删旧实现，逐步迁移。  
**禁止**：新旧混用超过一个 commit。

---

## 铁律五：重复报警

写代码时，发现同一段逻辑在不同地方出现 **≥ 3 次**：

1. 🔴 CHECKPOINT · 🛑 STOP：停下来，不要静默复制第 3 次
2. 输出："我发现 [X 逻辑] 重复了 [N] 处，建议提取。现在统一还是记 inbox？"
3. 用户选"记 inbox" → 记 B 类，继续当前任务
4. 用户选"现在统一" → 提取作为独立子任务，走完整五段流程

注意：1-2 次重复是正常的，3 次才是信号。不要为 2 次重复提前抽象。

---

## 执行检查清单

每次有新 idea 出现时，内心走一遍：

```
□ 分类了吗？（A/B/C）
□ C 类的话，进 inbox 了吗？
□ 单向门还是双向门？
□ 单向门的话，影响矩阵输出了并等用户确认了吗？
□ 消费者数量清楚吗？（0/1/2/3+）
□ 接入模式选好了吗？（Wrap / Extend / Branch / Replace）
□ 有 ≥ 3 次重复的逻辑吗？
```

---

## 反模式（永远不要做）

❌ **默认重写**：看到新 idea 就重构现有代码，不先评估破坏性  
❌ **为未来消费者设计**：现在没有的消费者不算消费者  
❌ **C 类即时执行**：新功能冲动绕过冷却期直接开发  
❌ **混合模式超期**：新旧两套方案并存超过一个 commit  
❌ **静默蔓延**：改着改着把相关代码"顺便"也改了

---

## 用户覆盖与降级

当用户明确拒绝分类建议时（如坚持 C 类立即执行），不争论，走降级路径：

🔴 CHECKPOINT · 🛑 STOP：

1. **输出风险提示**："这是 C 类扩展功能，建议进 inbox 冷却。如果确定现在做，我会按单向门标准评估影响。"
2. **用户确认后** → 将 idea 升级为单向门评估，走铁律二完整影响矩阵
3. **执行后** → 在 commit message 中标注 `[bypass-cooling]`，保留决策痕迹

> 核心原则：agent 负责亮红灯，用户负责踩油门。不替用户做决定，但确保用户做决定时信息充分。

## 铁律自纠正：当分类出错时

分类是人机协作中最容易出错的环节。以下自纠正机制确保错误不会累积：

| 错误类型 | 信号 | 自纠正动作 |
|----------|------|-----------|
| A 类误判（把 B/C 当 A） | 评估破坏性后发现实际是单向门但用户说不急 | 降级为 B 或 C，重新走对应流程 |
| C 类漏判（把 A 当 C 记了 inbox） | 记入 inbox 后用户在 5 分钟内再次提起 | 升级为 A，立即评估（冷却期内二次提起 = 真实紧迫） |
| B 类模糊执行（B 类直接做了没问用户） | Agent 已开始改动但没有先输出"现在做还是记 inbox？" | 立刻停下，补问用户，已完成改动作为"事实"接受 |
| 用户纠正分类 | 用户说"这不是 C，这得现在做" | 接受用户判定，升级为对应类别，**不争论** |

> Agent 不预设自己分类一定正确。用户的一次纠正优先于所有铁律。

## 最终确认门（All Clear Gate）

全部铁律通过后，在动手写第一行代码前，输出一句确认：

```
✅ 三思审计完成
   分类: [A/B/C] | 破坏性: [单向门/双向门] | 消费者: [N 个]
   接入: [Wrap/Extend/Branch/Replace] | 冷却: [是/否/已跳过]
   开始执行。
```

如果没有输出这句确认 → 说明有铁律未走完。这是防止跳跃执行的最后一道门。

## 与其他 skill 的协作

### 核心三技能闭环（三思 → ideas-inbox → vibecoding-workflow）

```
新想法到达 → 三思（分类+评估）→ B/C 类入 ideas-inbox（归档+冷却）
           → 确认执行 → vibecoding-workflow（执行纪律：如何安全地改）
```

| Skill | 角色 | 交接点 |
|-------|------|--------|
| **ideas-inbox** | B/C 类处置依赖 ideas-inbox 作为归档机制 | 三思分类后，B/C 类移交 inbox |
| **vibecoding-workflow** | 管执行纪律（如何改） | 三思选定接入模式后，交接给 vibecoding-workflow |
| **incremental-implementation** | 分步执行（已知需求稳着来） | 接入模式选定后，具体实现可衔接；处理"已知需求"的"如何实现" |
| **superpowers 体系** | brainstorming（需求前）→ 三思（新想法到达）→ executing-plans（执行+检查点） | 三思填补了 superpowers 中"新想法处理"的空白 |

### 互补叙事

- **brainstorming / grill-me**：负责开发**前**的需求澄清（"你到底要什么？"）
- **三思**：负责开发**中**的新想法接入（"这个新想法怎么放进去？"）
- **incremental-implementation**：负责确认**后**的分步执行（"已知需求怎么稳着实现？"）

三者在时间线上形成闭环：**澄清 → 接入决策 → 执行**。

---

## 一句话总结

> **三思而后行——新 idea 出现时：先分类 → 评估破坏性 → 数消费者 → 选接入模式。让产品向前生长，不原地推倒。**

name: think-thrice description: "When a new idea arrives mid-development, classify it, assess destructiveness, audit consumers, and choose the lowest-impact integration path instead of rewriting." version: 1.2.0 author: dmlin7777777 tags: [workflow, idea-management, vibe-coding, agent-discipline, no-rewrite]

三思 — 新 idea 接入协议

三思而后行。当新 idea 在开发中途出现时，引导 agent 选择最低破坏性的接入路径，而非推倒重建。

适用场景

以下任意一条出现时，本 skill 自动激活：

用户在开发进行中说"我突然想到…"、"要不要顺便…"、"能不能改成…"
英文等价："I just thought of...", "can we also...", "what if we change...", "let's also add...", "should we refactor..."
用户提出的新需求会影响已有的文件、接口、数据结构
用户问"这个架构能支持 X 吗？" / "Can this architecture support X?"
Agent 发现当前实现路径与用户新想法存在冲突

不适用（误触发排除）：

项目从零开始的第一个功能
纯 bug 修复（不涉及新想法）
UI 微调（改颜色、调间距、换文案）——这些是双向门，直接执行即可
明确的用户指令："直接做，不需要评估" / "just do it"
纯信息查询（"这个文件是干什么的？" / "what does this code do?"）

与 incremental-implementation 的区别

incremental-implementation：已知需求，如何实现得更稳。
三思：新 idea 出现，往哪接、破坏多大、要不要现在接。

合体使用场景：新 idea 经三思分类为 B 类且用户确认"现在做"→ 交接给 incremental-implementation 执行分步实现。

安全边界

本 Skill 是决策协议，不是执行引擎——所有操作需用户确认后才执行。

这个 Skill 会做什么：

暂停 Agent，输出分类结果和影响评估
建议冷却期、建议接入模式
在单向门场景强制等待用户确认

这个 Skill 绝不会做：

删除文件、修改数据库、执行 shell 命令
自动 commit 或 push
发送外部网络请求
绕过用户权限或 sandbox
替代用户做单向门决策

最大破坏半径：减慢开发节奏（这是设计意图，不是 bug）。

铁律一：先分类，不动手

新 idea 出现，立刻做三秒分类，不要开始写代码：

类型	判断标准	默认处置
A — 堵漏	影响当前主路径，不修会出错	现在处理，走铁律二
B — 优化	体验更好，但当前能用	问用户："现在做还是记 inbox？"
C — 扩展	新场景、新功能	默认记 inbox，24 小时冷却后再评估

C 类冷却原因：新功能冲动往往在 24 小时后自然消退，或变成更清晰的需求。不让即时灵感打断正在进行的任务。

分类模糊时的处置

触发条件	一线修复	仍无法判定
A 还是 B 分不清	按 A 处理（堵漏优先，宁严勿松）	—
B 还是 C 分不清	问用户："这个功能不做的代价是什么？"	用户说"不急"→ C；用户说"影响体验"→ B
跨铁律边界（如 C 类但涉及安全）	升级为 A，立即处理	—

铁律二：评估破坏性（单向门 vs 双向门）

决定处理后，先评估破坏性，再选路径。

双向门（可以反悔）：

改 UI 样式、文案、布局
加新字段（不删旧字段）
加新函数（不改旧函数签名）
加新路由（不改旧路由）

→ 直接进入铁律三

单向门（改了很难反悔）：

改数据库或存储结构
改对外 API 签名
删文件或移路径
改全局状态的形状
升级核心依赖

→ 🔴 CHECKPOINT · 🛑 STOP：停下来，先输出影响矩阵，等用户确认：

模板：references/impact-matrix-template.md

影响评估：
- 直接改动：[文件/接口名]
- 下游影响：[哪些消费者会受影响]
- 回滚成本：[高/中/低，原因]
- 建议：[现在做 / 开新分支 / 记 inbox 等条件成熟]

铁律三：消费者审计（建之前先数使用者）

新建任何 API、模块、组件、工具函数之前，先问：

"这个东西的消费者是谁？现在有几个实际调用点？"

消费者数量	处置
0 个	不建。记 inbox C 类，等真实需求出现
1 个	最简实现，写在调用处，不抽象
2 个	可以提取，但不做通用化设计
≥ 3 个	才考虑抽象层、接口、配置化

这条规则阻断"为将来扩展而设计"的过度抽象冲动。

消费者数量不确定时

触发条件	处置
外部调用者（第三方 API 消费者）	按 ≥ 3 保守评估，改动走单向门流程
grep 搜不到但怀疑有隐式调用（反射、字符串拼接 import）	标记为「消费者待确认」，先不改，等运行时报错再定位
跨仓库/跨项目调用	默认当消费者存在，不删不改旧接口签名，只追加

铁律四：选接入模式

通过前三条铁律后，选择具体接入方式（按破坏性从低到高）：

模式 1 — Wrap（包一层）

适用：新功能是对现有功能的增强，不想改现有代码。
做法：在现有函数/组件外加一层，旧路径不动。
触发信号："在 X 基础上加 Y"、"X 的增强版"

模式 2 — Extend（延伸现有结构）

适用：新功能可以作为现有模块的新分支，共享大部分逻辑。
做法：加新参数、新 case、新路由，不改已有路径。
触发信号："支持新的类型/场景"、"加一种模式"

模式 3 — Branch（并行分支）

适用：新旧路径差异较大，需要并存一段时间再迁移。
做法：新路径单独实现，旧路径保留，逐步迁移消费者。
触发信号："要改架构，但不能停服"、"要验证新方案"

模式 4 — Replace（替换）

适用：确实需要重写，旧实现已是负债。
前提：必须先完成铁律二的单向门评估，且用户明确确认。
做法：先写新实现并覆盖测试，再删旧实现，逐步迁移。
禁止：新旧混用超过一个 commit。

铁律五：重复报警

写代码时，发现同一段逻辑在不同地方出现 ≥ 3 次：

🔴 CHECKPOINT · 🛑 STOP：停下来，不要静默复制第 3 次
输出："我发现 [X 逻辑] 重复了 [N] 处，建议提取。现在统一还是记 inbox？"
用户选"记 inbox" → 记 B 类，继续当前任务
用户选"现在统一" → 提取作为独立子任务，走完整五段流程

注意：1-2 次重复是正常的，3 次才是信号。不要为 2 次重复提前抽象。

执行检查清单

每次有新 idea 出现时，内心走一遍：

□ 分类了吗？（A/B/C）
□ C 类的话，进 inbox 了吗？
□ 单向门还是双向门？
□ 单向门的话，影响矩阵输出了并等用户确认了吗？
□ 消费者数量清楚吗？（0/1/2/3+）
□ 接入模式选好了吗？（Wrap / Extend / Branch / Replace）
□ 有 ≥ 3 次重复的逻辑吗？

反模式（永远不要做）

❌ 默认重写：看到新 idea 就重构现有代码，不先评估破坏性
❌ 为未来消费者设计：现在没有的消费者不算消费者
❌ C 类即时执行：新功能冲动绕过冷却期直接开发
❌ 混合模式超期：新旧两套方案并存超过一个 commit
❌ 静默蔓延：改着改着把相关代码"顺便"也改了

用户覆盖与降级

当用户明确拒绝分类建议时（如坚持 C 类立即执行），不争论，走降级路径：

🔴 CHECKPOINT · 🛑 STOP：

输出风险提示："这是 C 类扩展功能，建议进 inbox 冷却。如果确定现在做，我会按单向门标准评估影响。"
用户确认后 → 将 idea 升级为单向门评估，走铁律二完整影响矩阵
执行后 → 在 commit message 中标注 [bypass-cooling]，保留决策痕迹

核心原则：agent 负责亮红灯，用户负责踩油门。不替用户做决定，但确保用户做决定时信息充分。

铁律自纠正：当分类出错时

分类是人机协作中最容易出错的环节。以下自纠正机制确保错误不会累积：

错误类型	信号	自纠正动作
A 类误判（把 B/C 当 A）	评估破坏性后发现实际是单向门但用户说不急	降级为 B 或 C，重新走对应流程
C 类漏判（把 A 当 C 记了 inbox）	记入 inbox 后用户在 5 分钟内再次提起	升级为 A，立即评估（冷却期内二次提起 = 真实紧迫）
B 类模糊执行（B 类直接做了没问用户）	Agent 已开始改动但没有先输出"现在做还是记 inbox？"	立刻停下，补问用户，已完成改动作为"事实"接受
用户纠正分类	用户说"这不是 C，这得现在做"	接受用户判定，升级为对应类别，不争论

Agent 不预设自己分类一定正确。用户的一次纠正优先于所有铁律。

最终确认门（All Clear Gate）

全部铁律通过后，在动手写第一行代码前，输出一句确认：

✅ 三思审计完成
   分类: [A/B/C] | 破坏性: [单向门/双向门] | 消费者: [N 个]
   接入: [Wrap/Extend/Branch/Replace] | 冷却: [是/否/已跳过]
   开始执行。

如果没有输出这句确认 → 说明有铁律未走完。这是防止跳跃执行的最后一道门。

与其他 skill 的协作

核心三技能闭环（三思 → ideas-inbox → vibecoding-workflow）

新想法到达 → 三思（分类+评估）→ B/C 类入 ideas-inbox（归档+冷却）
           → 确认执行 → vibecoding-workflow（执行纪律：如何安全地改）

Skill	角色	交接点
ideas-inbox	B/C 类处置依赖 ideas-inbox 作为归档机制	三思分类后，B/C 类移交 inbox
vibecoding-workflow	管执行纪律（如何改）	三思选定接入模式后，交接给 vibecoding-workflow
incremental-implementation	分步执行（已知需求稳着来）	接入模式选定后，具体实现可衔接；处理"已知需求"的"如何实现"
superpowers 体系	brainstorming（需求前）→ 三思（新想法到达）→ executing-plans（执行+检查点）	三思填补了 superpowers 中"新想法处理"的空白

互补叙事

brainstorming / grill-me：负责开发前的需求澄清（"你到底要什么？"）
三思：负责开发中的新想法接入（"这个新想法怎么放进去？"）
incremental-implementation：负责确认后的分步执行（"已知需求怎么稳着实现？"）

三者在时间线上形成闭环：澄清 → 接入决策 → 执行。

一句话总结

三思而后行——新 idea 出现时：先分类 → 评估破坏性 → 数消费者 → 选接入模式。让产品向前生长，不原地推倒。