shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringAPI key requirement unconfirmed

想法塑形

在实现之前、写代码或建任务之前，通过聚焦的协作式提问把模糊想法逼成成型的设计方案。一次只问一个问题、提出 2-3 个带权衡的方案、分块呈现设计、产出一份经过确认的设计文档。适合新功能、行为变更、有多种可行方案的重构。触发词：想法成型 / 头脑风暴 / brainstorm / 先别写代码，先设计。

personAuthor: BeelzububuuuhubOpenAPI
downloadDownload package

想法成型 / Idea Shaping

概述 / Overview

在动手实现之前，通过聚焦的协作对话，把想法变成完整的设计。 Turn ideas into fully formed designs through focused collaborative dialogue before any implementation begins.

核心原则： 完全理解问题之后，再提方案。一次一个问题。无情地做减法（YAGNI）。 Core principle: Understand the problem completely before proposing solutions. One question at a time. YAGNI ruthlessly.

开始时先声明： 「我正在用「想法成型」技能，在动手之前先把设计聊清楚。」 Announce at start: "I'm using the idea-shaping skill to explore the design before we build anything."

何时使用 / When to Use

  • 新功能或新组件 New features or components
  • 对现有系统的行为变更 Behavior changes to existing systems
  • 有多种可行方案的重构 Refactors with multiple valid approaches
  • 任何直接跳到写代码会操之过急的情况 Anything where jumping straight to code would be premature

跳过的情况： 错别字、单行修复、配置改动、需求已经非常明确的任务。 Skip for: Typos, one-line fixes, config changes, tasks with crystal-clear requirements already written.

流程 / The Process

第一阶段：理解想法 / Phase 1: Understand the Idea

提问以理解真正需要什么。每条消息只问一个问题。 尽量用选择题（降低认知负担）。 Ask questions to understand what's actually needed. One question per message. Prefer multiple-choice when possible (reduces cognitive load).

好问题： Good questions:

  • 「这是内部用还是对外公开？」（划定范围） "Is this for internal use or public-facing?" (scoped)
  • 「速度与正确性，哪个更重要？」（排优先级） "Which of these matters more: speed or correctness?" (prioritization)
  • 「它需要和 X 配合，还是可以独立存在？」（边界） "Does this need to work with X, or is it standalone?" (boundaries)

坏问题： Bad questions:

  • 「能描述一下整个功能吗？」（太宽泛） "Can you describe the entire feature?" (too broad)
  • 「所有需求是什么？」（偷懒，把活推给人） "What are all the requirements?" (lazy, makes human do the work)

当你能把功能复述回去、对方说「对，就是它」时，停止提问。 Stop asking when you can explain the feature back to them and they say "yes, that's it."

第二阶段：探索方案 / Phase 2: Explore Approaches

提出 2-3 个带清晰权衡的方案。永远包含一个推荐项和理由。 Propose 2-3 approaches with clear trade-offs. Always include a recommendation and why.

## 候选方案 / Approaches

### A：[名称]（推荐 / Recommended）
- 做法 / How: [简要描述]
- 优点 / Pro: [主要优势]
- 缺点 / Con: [主要劣势]

### B：[名称]
- 做法 / How: [简要描述]
- 优点 / Pro: [主要优势]
- 缺点 / Con: [主要劣势]

**推荐 / Recommendation：** A，因为 [针对这个项目的理由 / specific reason for this project]。

无情地做减法（YAGNI）——从所有方案里删掉非必需的功能。「我们还可以加 X」没有帮助，除非 X 是被要求的。 YAGNI ruthlessly - Remove unnecessary features from all proposals. "We could also add X" is not helpful unless X was requested.

第三阶段：呈现设计 / Phase 3: Present the Design

方案达成一致后，把设计按 200-300 词一块分块呈现。每块之后问：「这部分看起来对吗？」 Once approach is agreed, present the design in chunks of 200-300 words. Ask after each chunk: "Does this look right so far?"

不要一次性倒出 2000 词的大文档。拆分它： Don't dump a 2000-word spec. Break it up:

  1. 架构 / 高层思路 Architecture / high-level approach
  2. 关键接口 / 数据结构 Key interfaces / data structures
  3. 边界情况 / 错误处理 Edge cases / error handling
  4. 测试策略 Testing strategy

第四阶段：落文档 / Phase 4: Document

验证通过后，产出一份干净的设计文档： After validation, produce a clean design document:

# [功能名] 设计 / [Feature Name] Design

## 目标 / Goal
[一句话 / One sentence]

## 思路 / Approach
[2-3 句话 / 2-3 sentences]

## 成功标准 / Success Criteria
- [ ] 可衡量的结果 1 / Measurable outcome 1
- [ ] 可衡量的结果 2 / Measurable outcome 2

## 关键决策 / Key Decisions
- [决策 / Decision]: [理由 / Rationale]

## 非目标 / Non-Goals
- [我们明确不做的东西 / Thing we're explicitly NOT doing]

## 约束 / Constraints
- [硬性要求 / Hard requirement]

## 迁移 / 移除（如替换现有代码 / Migration/Removal, if replacing existing code）
| 旧代码 / Old Code | 新代码 / New Code | 动作 / Action |
|------------------|------------------|---------------|
| [现有文件/系统] | [替代物] | 删除 / 保留 / 迁移 (DELETE / KEEP / MIGRATE) |

**规则：**
**Rules:**
- 删除 / DELETE = 彻底移除，不留后路
- 保留 / KEEP = 因兼容性明确需要（说明原因）
- 迁移 / MIGRATE = 删除前需要数据迁移

**不要含糊。**「废弃或迁移」不是动作，选一个。
**No hedging.** "Deprecate or migrate" is not an action. Pick one.

常见错误 / Common Mistakes

| 错误 / Mistake | 修正 / Fix | |---------|-----| | 一次问太多问题 | 每条消息只问一个 | | 还没理解就提方案 | 先完成第一阶段 | | 塞入未被要求的特性 | YAGNI——删掉它们 | | 只抛一个方案 | 永远给 2-3 个并附推荐 | | 一次性甩大文档 | 拆成 200-300 词一块 | | 跳过确认 | 每块之后问「这部分对吗？」 |

红旗 / Red Flags

绝不要： Never:

  • 设计还没验证就开始写代码 Start coding before design is validated
  • 主动加「锦上添花」的功能 Add "nice to have" features unprompted
  • 没先就方案达成一致就呈现设计 Present design without getting approach agreement first
  • 跳过分块呈现（大段倾倒会被略读，而非细读） Skip the chunked presentation (giant dumps get skimmed, not read)
  • 用含糊语言描述代码移除（「废弃或迁移」「为兼容保留」） Use hedging language for code removal
  • 让旧代码命运模糊——要么删除、要么保留并写明理由 Leave old code fate ambiguous — DELETE or KEEP with explicit rationale

永远要： Always:

  • 一次一个问题 One question at a time
  • 尽量用选择题 Multiple-choice when possible
  • 每个方案都做减法 YAGNI every proposal
  • 继续之前拿到明确的确认 Get explicit sign-off before proceeding