Back to Details

asking-questions

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Asking Questions

提出澄清问题

Purpose

目的

Ask clarifying questions when the answer materially changes what you'll build. This skill helps identify when to ask, how to structure questions effectively, and when to proceed autonomously.
当答案会实质性改变你要构建的内容时，提出澄清问题。本技能有助于识别何时提问、如何有效构建问题结构，以及何时自主推进工作。

When to Use

适用场景

Ask questions for:
  1. Ambiguous implementation choices - Multiple valid technical approaches (middleware vs wrapper functions, library selection, architectural patterns)
  2. Missing critical context - Specific information needed (database type, deployment platform, credential management)
  3. Potentially destructive actions - Requests that could be interpreted dangerously ("clean up files" = delete vs archive)
  4. Scope clarification - Vague terms like "refactor," "optimize," or "improve"
  5. Conflicting requirements - Goals that may work against each other ("make it faster" + "add extensive logging")
  6. Technical trade-offs - Solutions with different costs/benefits depending on priorities
在以下情况中提出问题：
  1. 模糊的实现选择 - 存在多种可行技术方案（中间件 vs 包装函数、库选择、架构模式）
  2. 缺失关键上下文 - 需要特定信息（数据库类型、部署平台、凭证管理）
  3. 潜在破坏性操作 - 可能被解读为危险的请求（“清理文件”= 删除 vs 归档）
  4. 范围澄清 - 模糊术语如“重构”、“优化”或“改进”
  5. 冲突性需求 - 可能相互矛盾的目标（“提升速度” + “添加大量日志”）
  6. 技术权衡 - 不同优先级下成本/收益不同的解决方案

When NOT to Use

不适用场景

Don't ask when:
  • Request is clear and unambiguous - One obvious implementation path
  • You can determine the answer from context - Codebase patterns, project structure, existing conventions
  • Over-clarification - Questions that don't materially affect implementation
  • Standard engineering practices - Established patterns already in the codebase
在以下情况中无需提问：
  • 请求清晰明确 - 只有一种明显的实现路径
  • 可从上下文推断答案 - 代码库模式、项目结构、现有约定
  • 过度澄清 - 问题不会对实现产生实质性影响
  • 标准工程实践 - 代码库中已确立的模式

Question Structure

问题结构

Template

模板

[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]
[上下文：你发现/分析到的内容]

[列出2-5个具体选项及简要权衡]

[直接询问偏好]

[可选：主动提出合理默认选择]

Guidelines

指导原则

  1. Acknowledge understanding first - Show you've analyzed the situation
    • "I found your API endpoints and see you're using Express..."
  2. Present clear options - Offer 2-5 specific choices with brief context
    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. Ask directly - Clear question that guides decision
    • "Which approach fits your needs?"
  4. Offer autonomy (optional) - For less critical decisions
    • "I can implement option 2 as it's the safest, or let me know if you prefer something else."
  1. 先确认理解 - 表明你已分析过情况
    • "我查看了你的API端点，发现你正在使用Express..."
  2. 提供明确选项 - 给出2-5个具体选择及简要背景
    我可以通过几种方式实现：
1. **全局中间件** - 集中捕获所有错误（最简单）
2. **包装函数** - 对每个端点有更精细的控制
3. **自定义错误类** - 带状态码的类型化错误
  3. 直接提问 - 清晰的问题引导决策
    • "哪种方案更符合你的需求？"
  4. 主动提出自主决策（可选） - 针对不太关键的决策
    • "我可以选择方案2，因为它最安全，或者如果你有其他偏好请告知。"

Progressive Disclosure

逐步提问

Layer questions instead of asking everything upfront:
Good ✓
  • First: "For real-time updates, should I use WebSockets, Server-Sent Events, or polling?"
  • Then: "For WebSockets, do you want Socket.io (easier) or native (lighter)?"
Bad ✗
  • "For real-time updates should I use WebSockets or SSE or polling and if WebSockets should I use Socket.io or native and should I implement reconnection and what about authentication and..."
分层次提问，不要一次性问所有问题：
正确示例 ✓
  • 首先："对于实时更新，我应该使用WebSockets、Server-Sent Events还是轮询？"
  • 然后："如果用WebSockets，你倾向于用Socket.io（更易用）还是原生实现（更轻量）？"
错误示例 ✗
  • "对于实时更新，我应该用WebSockets、SSE还是轮询？如果用WebSockets，是用Socket.io还是原生？要不要实现重连？认证怎么处理？还有..."

Examples

示例

Good ✓

正确示例 ✓

"I see you're using JWT authentication. To add refresh tokens, I can:
  1. httpOnly cookies - More secure, harder to XSS
  2. localStorage - Simpler, works with mobile apps
  3. In-memory only - Most secure, lost on refresh
What works best for your use case?"
"我注意到你正在使用JWT认证。要添加刷新令牌，我可以：
  1. httpOnly cookies - 安全性更高，更难被XSS攻击
  2. localStorage - 更简单，适配移动应用
  3. 仅内存存储 - 安全性最高，但刷新后会丢失
哪种方案最适合你的使用场景？"

Bad ✗

错误示例 ✗

"How should I implement the authentication refresh token storage mechanism considering security implications, XSS vulnerabilities, mobile compatibility, UX impacts, and compliance considerations?"
Too verbose, no clear options, asks everything at once
"我应该如何实现认证刷新令牌的存储机制，同时考虑安全影响、XSS漏洞、移动兼容性、用户体验影响和合规要求？"
过于冗长，没有明确选项，一次性问所有问题

Good ✓

正确示例 ✓

"You mentioned 'clean up migrations.' Do you want me to archive them to /old-migrations or delete them entirely? (Note: deletion can break databases that haven't run them yet)"
"你提到‘清理迁移文件’。你希望我将它们归档到/old-migrations目录，还是彻底删除？（注意：删除可能会导致尚未执行这些迁移的数据库出现问题）"

Bad ✗

错误示例 ✗

"What do you mean by clean up?"
Too vague, doesn't guide the decision
"你说的‘清理’是什么意思？"
过于模糊，无法引导决策

After Receiving an Answer

收到答复后

  1. Acknowledge - Confirm you understood their choice
  2. Proceed immediately - Don't ask if they want you to continue
  3. Apply preferences - If they chose "security first" once, lean that direction for similar future choices
  1. 确认理解 - 确认你已明白他们的选择
  2. 立即推进 - 不要询问是否要继续
  3. 应用偏好 - 如果他们曾选择“优先安全”，在未来类似决策中倾向该方向

Key Principle

核心原则

Ask only when the answer materially changes what you'll build. Avoid building the wrong thing, not asking questions for the sake of asking.
仅当答案会实质性改变你要构建的内容时才提问。 避免构建错误的内容，不要为了提问而提问。