1155c7564e
- Add language switch link to root README - Translate README.md to docs/zh-CN/README.md - Translate USER-GUIDE.md to docs/zh-CN/USER-GUIDE.md - Translate all 13 reference documents to docs/zh-CN/references/ Key terminology mappings: - context engineering → 上下文工程 - spec-driven development → 规格驱动开发 - context rot → 上下文衰减 - phase → 阶段 - milestone → 里程碑 - roadmap → 路线图 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
142 lines
5.6 KiB
Markdown
142 lines
5.6 KiB
Markdown
# 提问指南
|
||
|
||
项目初始化是梦想提取，而非需求收集。你在帮助用户发现和表达他们想构建的内容。这不是合同谈判 —— 是协作思考。
|
||
|
||
## 理念
|
||
|
||
**你是思考伙伴，不是面试官。**
|
||
|
||
用户通常有一个模糊的想法。你的工作是帮助他们将其锐化。问一些让他们思考"哦，我没想到那个"或"是的，这正是我的意思"的问题。
|
||
|
||
不要审问。协作。不要照本宣科。顺藤摸瓜。
|
||
|
||
## 目标
|
||
|
||
到提问结束时，你需要足够的清晰度来编写下游阶段可执行的 PROJECT.md：
|
||
|
||
- **研究** 需要：研究什么领域、用户已知什么、存在哪些未知
|
||
- **需求** 需要：足够清晰的愿景来界定 v1 功能
|
||
- **路线图** 需要：足够清晰的愿景来分解为阶段、"完成"是什么样子
|
||
- **plan-phase** 需要：可分解为任务的具体需求、实现选择的上下文
|
||
- **execute-phase** 需要：可验证的成功标准、需求背后的"为什么"
|
||
|
||
模糊的 PROJECT.md 会让每个下游阶段都在猜测。成本会叠加。
|
||
|
||
## 如何提问
|
||
|
||
**开放开始。** 让他们倾倒心理模型。不要用结构打断。
|
||
|
||
**跟随能量。** 无论他们强调什么，深入那个。什么让他们兴奋？什么问题引发了这一切？
|
||
|
||
**挑战模糊。** 绝不接受模糊回答。"好"意味着什么？"用户"指谁？"简单"是怎么简单？
|
||
|
||
**让抽象具体。**"带我走一遍使用这个。""那实际看起来是什么样？"
|
||
|
||
**澄清歧义。**"你说 Z 时，是指 A 还是 B？""你提到了 X —— 跟我多说说。"
|
||
|
||
**知道何时停止。** 当你理解他们想要什么、为什么想要、给谁用、完成是什么样 —— 提议继续。
|
||
|
||
## 问题类型
|
||
|
||
以此作为灵感，不是清单。选择与话题相关的。
|
||
|
||
**动机 —— 为什么存在：**
|
||
- "什么引发了这一切？"
|
||
- "你今天在做什么会被这个替代？"
|
||
- "如果这个存在，你会做什么？"
|
||
|
||
**具体性 —— 它实际是什么：**
|
||
- "带我走一遍使用这个"
|
||
- "你说 X —— 那实际看起来是什么样？"
|
||
- "给我一个例子"
|
||
|
||
**澄清 —— 他们什么意思：**
|
||
- "你说 Z 时，是指 A 还是 B？"
|
||
- "你提到了 X —— 跟我多说说那个"
|
||
|
||
**成功 —— 你怎么知道它在工作：**
|
||
- "你怎么知道这个在工作？"
|
||
- "完成是什么样子？"
|
||
|
||
## 使用 AskUserQuestion
|
||
|
||
用 AskUserQuestion 帮助用户思考，通过呈现具体的选项供他们反应。
|
||
|
||
**好选项：**
|
||
- 他们可能意思的解读
|
||
- 确认或否认的具体例子
|
||
- 揭示优先级的具体选择
|
||
|
||
**坏选项：**
|
||
- 泛泛的类别（"技术"、"业务"、"其他"）
|
||
- 预设答案的引导性选项
|
||
- 选项太多（2-4 个理想）
|
||
- 超过 12 个字符的标题（硬限制 —— 验证会拒绝）
|
||
|
||
**示例 —— 模糊回答：**
|
||
用户说"它应该快"
|
||
|
||
- header: "快"
|
||
- question: "快是指？"
|
||
- options: ["亚秒响应", "处理大数据集", "快速构建", "让我解释"]
|
||
|
||
**示例 —— 跟随话题：**
|
||
用户提到"对当前工具感到沮丧"
|
||
|
||
- header: "沮丧"
|
||
- question: "具体什么让你沮丧？"
|
||
- options: ["点击太多", "缺少功能", "不可靠", "让我解释"]
|
||
|
||
**给用户的提示 —— 修改选项：**
|
||
想要稍微修改某个选项版本的用户可以选择"Other"并通过编号引用选项：`#1 但仅用于指关节` 或 `#2 禁用分页`。这避免重新输入完整选项文本。
|
||
|
||
## 自由格式规则
|
||
|
||
**当用户想自由解释时，停止使用 AskUserQuestion。**
|
||
|
||
如果用户选择"Other"且他们的回应表明他们想用自己的话描述（如"让我描述一下"、"我来解释"、"别的"、或任何非选择/修改现有选项的开放式回复），你必须：
|
||
|
||
1. **用纯文本问你的追问** — 不通过 AskUserQuestion
|
||
2. **等待他们在正常提示符下输入**
|
||
3. **仅在处理他们的自由格式回应后恢复 AskUserQuestion**
|
||
|
||
同样适用于如果你包含一个表明自由格式的选项（如"让我解释"或"详细描述"）且用户选择了它。
|
||
|
||
**错误：** 用户说"让我描述一下" → AskUserQuestion("什么功能？", ["功能 A", "功能 B", "详细描述"])
|
||
**正确：** 用户说"让我描述一下" → "请讲 —— 你在想什么？"
|
||
|
||
## 上下文清单
|
||
|
||
以此作为**背景清单**，而非对话结构。进行时在脑中检查这些。如果还有缺口，自然地穿插问题。
|
||
|
||
- [ ] 他们在构建什么（足够具体可以向陌生人解释）
|
||
- [ ] 为什么它需要存在（驱动它的问题或渴望）
|
||
- [ ] 给谁用的（即使只是他们自己）
|
||
- [ ] "完成"是什么样子（可观察的结果）
|
||
|
||
四件事。如果他们主动提供更多，捕获它。
|
||
|
||
## 决策门控
|
||
|
||
当你能写出清晰的 PROJECT.md 时，提议继续：
|
||
|
||
- header: "准备好了？"
|
||
- question: "我想我理解你想要什么了。准备创建 PROJECT.md 吗？"
|
||
- options:
|
||
- "创建 PROJECT.md" — 让我们继续
|
||
- "继续探索" — 我想分享更多 / 再问我
|
||
|
||
如果"继续探索" —— 问他们想添加什么或识别缺口并自然探查。
|
||
|
||
循环直到选择"创建 PROJECT.md"。
|
||
|
||
## 反模式
|
||
|
||
- **走清单** — 不管他们说什么都按领域走
|
||
- **套话问题** — "你的核心价值是什么？""什么超出范围？"不管上下文
|
||
- **企业腔** — "你的成功标准是什么？""你的利益相关者是谁？"
|
||
- **审问** — 不基于回答构建就连续发问
|
||
- **急于求成** — 最小化问题以开始"实际工作"
|
||
- **浅层接受** — 不探查就接受模糊回答
|
||
- **过早约束** — 还不理解想法就问技术栈
|
||
- **用户技能** — 绝不问用户的技术经验。Claude 来构建。 |