ideation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ideation

创意构思

Transform unstructured brain dumps into structured, actionable implementation artifacts through a confidence-gated workflow.

通过置信度驱动的工作流，将零散的想法转化为结构化、可落地的实施文档。

Critical: Use AskUserQuestion Tool

重要提示：使用AskUserQuestion工具

ALWAYS use the
AskUserQuestion
tool when asking clarifying questions. Do not ask questions in plain text. The tool provides structured options and ensures the user can respond clearly.

在询问澄清问题时，必须使用
AskUserQuestion
工具，不要用纯文本提问。该工具提供结构化选项，确保用户能清晰回复。

Workflow Pipeline

工作流管道

INTAKE → CONTRACT FORMATION → PRD GENERATION → SPEC GENERATION
              ↓
         confidence < 95%?
              ↓
         ASK QUESTIONS
              ↓
         (loop until ≥95%)

INTAKE → 合同拟定 → PRD生成 → 规格文档生成
              ↓
         置信度 < 95%？
              ↓
         发起提问
              ↓
         （循环直到置信度≥95%）

Phase 1: Intake

阶段1：接收输入

Accept whatever the user provides:

Scattered thoughts and half-formed ideas
Voice dictation transcripts (messy, stream-of-consciousness)
Bullet points mixed with rambling
Topic jumping and tangents
Contradictions and unclear statements

Don't require organization. The mess is the input.

接收用户提供的任何内容：

零散的想法和尚未成型的构思
语音听写转录内容（杂乱、意识流式的）
混合了冗长描述的项目符号列表
主题跳转和离题内容
矛盾和表述模糊的语句

无需要求用户整理内容，杂乱的输入正是处理对象。

Phase 2: Contract Formation

阶段2：合同拟定

2.1 Analyze the Brain Dump

2.1 分析零散想法

Extract from the raw input:

Problem signals: What pain point or need is being described?
Goal signals: What does the user want to achieve?
Success signals: How will they know it worked?
Scope signals: What's included? What's explicitly excluded?
Contradictions: Note any conflicting statements

从原始输入中提取以下信息：

问题信号：描述的痛点或需求是什么？
目标信号：用户想要达成什么？
成功信号：如何判断目标已达成？
范围信号：包含哪些内容？明确排除哪些内容？
矛盾点：记录任何相互冲突的表述

2.2 Calculate Confidence Score

2.2 计算置信度得分

Load

references/confidence-rubric.md

for detailed scoring criteria.

Score each dimension (0-20 points):

Dimension	Question
Problem Clarity	Do I understand what problem we're solving and why it matters?
Goal Definition	Are the goals specific and measurable?
Success Criteria	Can I write tests or validation steps for "done"?
Scope Boundaries	Do I know what's in and out of scope?
Consistency	Are there contradictions I need resolved?

Total: /100 points

加载

references/confidence-rubric.md

获取详细评分标准。

对每个维度评分（0-20分）：

维度	问题
问题清晰度	我是否理解我们要解决的问题及其重要性？
目标定义	目标是否具体且可衡量？
成功标准	我能否为“完成状态”编写测试或验证步骤？
范围边界	我是否清楚哪些内容在范围内，哪些在范围外？
一致性	是否存在需要解决的矛盾点？

总分：/100分

2.3 Confidence Thresholds

2.3 置信度阈值

Score	Action
< 70	Major gaps. Ask 5+ questions targeting lowest dimensions.
70-84	Moderate gaps. Ask 3-5 targeted questions.
85-94	Minor gaps. Ask 1-2 specific questions.
>= 95	Ready to generate contract.

得分	操作
< 70	存在重大信息缺口。针对得分最低的维度提出5个以上问题。
70-84	存在中等信息缺口。提出3-5个针对性问题。
85-94	存在轻微信息缺口。提出1-2个具体问题。
>= 95	可开始生成合同。

2.4 Ask Clarifying Questions

2.4 询问澄清问题

When confidence < 95%, MUST use
AskUserQuestion
tool. Structure questions with clear options when possible.

Question templates by dimension:

Problem Clarity:

"What specific problem are you trying to solve?"
"Who experiences this problem and how often?"

Goal Definition:

"What does success look like for this project?"
"What specific metrics should improve?"

Success Criteria:

"How will you know when you're done?"
"What tests would prove this feature works?"

Scope Boundaries:

"What is explicitly NOT part of this project?"
"What's the MVP vs. nice-to-have?"

Consistency:

"You mentioned [X] but also [Y]. Which takes priority?"

当置信度<95%时，必须使用
AskUserQuestion
工具。尽可能为问题设置清晰的选项。

按维度分类的问题模板：

问题清晰度：

“你试图解决的具体问题是什么？”
“谁会遇到这个问题，频率如何？”

目标定义：

“这个项目的成功标准是什么？”
“哪些具体指标应该得到提升？”

成功标准：

“你如何判断项目已完成？”
“哪些测试可以证明该功能正常工作？”

范围边界：

“哪些内容明确不属于这个项目的范围？”
“MVP（最小可行产品）和锦上添花的功能分别是什么？”

一致性：

“你提到了[X]但也提到了[Y]，哪个优先级更高？”

2.5 Generate Contract

2.5 生成合同

When confidence >= 95%:

Use
```
AskUserQuestion
```
to confirm project name
Convert to kebab-case for directory name
Create output directory:
```
./docs/ideation/{project-name}/
```

Write

contract.md

using

references/contract-template.md

Get approval before proceeding to PRD

当置信度≥95%时：

使用
```
AskUserQuestion
```
工具确认项目名称
将项目名称转换为短横线分隔格式（kebab-case）作为目录名
创建输出目录：
```
./docs/ideation/{project-name}/
```

使用

references/contract-template.md

编写

contract.md

在进入PRD生成阶段前获得用户批准

Phase 3: PRD Generation

阶段3：PRD生成

After contract is approved:

合同获批后：

3.1 Determine Phases

3.1 划分阶段

Break scope into logical implementation phases based on:

Dependencies (what must be built first?)
Risk (tackle high-risk items early)
Value delivery (can users benefit after each phase?)

根据以下因素将范围划分为逻辑化的实施阶段：

依赖关系（哪些内容必须优先构建？）
风险（尽早处理高风险项）
价值交付（用户能否在每个阶段后获得收益？）

3.2 Generate PRDs

3.2 生成PRD文档

For each phase, generate

prd-phase-{n}.md

using

references/prd-template.md

为每个阶段使用

references/prd-template.md

生成

prd-phase-{n}.md

。

3.3 Present for Review

3.3 提交审核

Use

AskUserQuestion

to gather feedback. Iterate until user approves.

使用

AskUserQuestion

工具收集反馈，迭代直到用户批准。

Phase 4: Spec Generation

阶段4：规格文档生成

After PRDs are approved:

PRD获批后：

4.1 Generate Implementation Specs

4.1 生成实施规格文档

For each approved phase, generate

spec-phase-{n}.md

using

references/spec-template.md

Include:

Technical approach
File changes (new and modified)
Implementation details with code patterns
Testing requirements
Validation commands

为每个获批阶段使用

references/spec-template.md

生成

spec-phase-{n}.md

。

文档需包含：

技术方案
文件变更（新增和修改的文件）
带有代码模式的实施细节
测试要求
验证命令

Output Artifacts

输出文档

All artifacts written to

./docs/ideation/{project-name}/

contract.md              # Lean contract
prd-phase-1.md           # Phase 1 requirements
prd-phase-2.md           # Phase 2 requirements
spec-phase-1.md          # Phase 1 implementation spec
spec-phase-2.md          # Phase 2 implementation spec

所有文档将写入

./docs/ideation/{project-name}/

contract.md              # 精简合同
prd-phase-1.md           # 阶段1需求文档
prd-phase-2.md           # 阶段2需求文档
spec-phase-1.md          # 阶段1实施规格文档
spec-phase-2.md          # 阶段2实施规格文档

Important Notes

重要注意事项

ALWAYS use
AskUserQuestion
tool for clarifications and approvals.
Never skip the confidence check.
Always write artifacts to files.
Each phase should be independently valuable.
Specs should be detailed enough to implement without re-reading PRDs.

在询问澄清问题和获取批准时，必须使用
AskUserQuestion
工具。
切勿跳过置信度检查步骤。
务必将文档写入文件。
每个阶段应具备独立的价值。
规格文档应足够详细，无需重新阅读PRD即可直接实施。