---
slug: "build-forward"
source_type: "skill_md"
source_url: "https://cdn.jsdelivr.net/gh/dmlin7777777/build-forward@main/SKILL.md"
repo: "https://github.com/dmlin7777777/build-forward"
source_file: "SKILL.md"
branch: "main"
---
---
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 出现时：先分类 → 评估破坏性 → 数消费者 → 选接入模式。让产品向前生长，不原地推倒。**