asking-questions

提问

目的

当答案会实质性地影响你要构建的内容时，提出澄清问题。这项技能有助于判断何时提问、如何有效组织问题，以及何时自主推进。

适用场景

在以下情况下提问：

1. 实现方案不明确 - 存在多种有效的技术方案（中间件还是封装函数、库的选择、架构模式）
2. 缺少关键信息 - 需要具体信息（数据库类型、部署平台、凭据管理）
3. 可能造成破坏的操作 - 请求可能被危险地解读（“清理文件”是指删除还是归档）
4. 需要明确范围 - “重构”“优化”或“改进”等含义模糊的词语
5. 需求冲突 - 目标可能相互矛盾（“提高速度” + “添加详尽的日志记录”）
6. 技术权衡 - 方案的成本和收益各不相同，取决于优先级

不适用场景

以下情况不要提问：

• 请求清晰明确 - 有一种显而易见的实现路径
• 可以从上下文中判断答案 - 代码库模式、项目结构、现有约定
• 过度澄清 - 问题不会实质性地影响实现
• 标准工程实践 - 代码库中已有成熟的模式

问题结构

模板

[Context: What you found/analyzed]

[Present 2-5 specific options with brief trade-offs]

[Direct question asking for preference]

[Optional: Offer to make reasonable default choice]

指南

1. 先确认你理解了情况 - 说明你已分析当前情况

   • “我找到了你的 API 端点，并看到你正在使用 Express……”

2. 给出明确选项 - 提供 2-5 个具体选项，并简要说明背景

   I can implement this in several ways:
   1. **Global middleware** - Catches all errors centrally (simplest)
   2. **Wrapper functions** - More granular control per endpoint
   3. **Custom error classes** - Typed errors with status codes
   

3. 直接提问 - 用清晰的问题引导对方做出选择

   • “哪种方案更适合你的需求？”

4. 可选：提供自主决定权 - 对不太重要的决定

   • “我可以按最稳妥的方案实现选项 2；如果你有其他偏好，也可以告诉我。”

渐进式披露

分层提问，不要一开始就把所有问题都抛出来：

好 ✓

• 首先：“对于实时更新，我应该使用 WebSockets、Server-Sent Events 还是轮询？”
• 然后：“如果使用 WebSockets，你想选 Socket.io（更简单）还是原生实现（更轻量）？”

不好 ✗

• “对于实时更新，我应该使用 WebSockets 还是 SSE 还是轮询？如果使用 WebSockets，我应该选 Socket.io 还是原生实现？还要不要实现重新连接？身份验证又该怎么处理……”

示例

好 ✓

“我看到你使用了 JWT 身份验证。要添加刷新令牌，我可以：

1. httpOnly cookies - 更安全，不易受到 XSS 攻击
2. localStorage - 更简单，可与移动应用配合使用
3. 仅存于内存中 - 最安全，但刷新后会丢失

哪种方案最适合你的使用场景？”

不好 ✗

“考虑到安全影响、XSS 漏洞、移动端兼容性、用户体验影响和合规要求，身份验证刷新令牌的存储机制应该如何实现？”

太冗长，没有清晰的选项，还一次问了所有问题

---

好 ✓

“你提到了‘清理迁移文件’。你想把它们归档到 /old-migrations，还是彻底删除？（注意：删除可能会影响尚未运行这些迁移文件的数据库）”

不好 ✗

“你说的清理是什么意思？”

太含糊，没有引导对方做出选择

收到回答后

1. 确认理解 - 确认你理解了对方的选择
2. 立即推进 - 不要再问对方是否希望你继续
3. 遵循偏好 - 如果对方曾选择“安全优先”，之后遇到类似选择时也优先考虑安全

核心原则

只在答案会实质性地影响你要构建的内容时提问。 避免做错东西，而不是为了提问而提问。