interviewing-plans
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseInterviewing Plans
计划访谈
Overview
概述
Plans fail because of hidden assumptions, not missing features. This skill systematically interviews stakeholders to surface ambiguities before they become bugs.
Core principle: Every vague term is a bug waiting to happen. "Make it faster" means nothing until someone says "reduce P95 latency from 800ms to 200ms."
计划失败的原因往往是隐藏的假设，而非缺失的功能。此方法通过系统化地与干系人开展访谈，在歧义演变为漏洞之前就将其找出。
核心原则：每一个模糊术语都是潜在的漏洞。“加快速度”毫无意义，除非有人明确说明“将P95延迟从800ms降低至200ms”。
When to Use
使用场景
Trigger conditions:
- User invokes
/interview-plan <file> - Plan contains undefined qualitative terms ("better", "faster", "modern", "relevant")
- Requirements reference external artifacts without links ("design has mockups")
- Technical approach lacks specifics ("add caching", "use React")
- Timeline exists without milestone breakdown
- User complaints mentioned without specific pain points
Do NOT use for:
- Already-detailed specs with concrete acceptance criteria
- Simple bug fixes with clear reproduction steps
- Tasks where user explicitly wants implementation, not planning
触发条件：
- 用户调用
/interview-plan <file> - 计划中包含未定义的定性术语（如“更好”“更快”“现代化”“相关”）
- 需求引用外部工件但未提供链接（如“设计有原型图”）
- 技术方案缺乏具体细节（如“添加缓存”“使用React”）
- 存在时间线但未拆解里程碑
- 提及用户反馈但未说明具体痛点
请勿用于：
- 已具备具体验收标准的详细规格文档
- 具备清晰复现步骤的简单Bug修复
- 用户明确要求直接落地而非进行规划的任务
Required Categories
必备访谈类别
Interview is NOT complete until ALL categories are covered:
| Category | Must Surface |
|---|---|
| Technical | Architecture decisions, data flow, state management, API contracts |
| UX/Design | User flows, states (loading/empty/error), mobile strategy, accessibility |
| Tradeoffs | What are we NOT doing? What's MVP vs future? What's negotiable? |
| Edge Cases | High-volume users, empty states, failure modes, concurrent access |
| Security | Auth/authz, data exposure, input validation, audit requirements |
| Testing | How do we know it works? Unit/integration/E2E split, test data |
| Rollback | What if it fails in prod? Feature flags? Parallel running? |
| Dependencies | Who owns what? What's blocking? Who approves? |
访谈必须覆盖所有类别才算完成：
| 类别 | 必须明确的内容 |
|---|---|
| 技术类 | 架构决策、数据流、状态管理、API契约 |
| UX/设计类 | 用户流程、状态（加载/空数据/错误）、移动端策略、可访问性 |
| 取舍权衡 | 我们不会做什么？MVP与未来版本的区别是什么？哪些内容可协商？ |
| 边缘场景 | 高并发用户、空状态、故障模式、并发访问 |
| 安全类 | 认证/授权、数据暴露、输入校验、审计要求 |
| 测试类 | 如何验证功能可用？单元/集成/E2E测试的划分、测试数据 |
| 回滚方案 | 若生产环境出现故障该如何处理？是否使用功能开关？是否支持并行运行？ |
| 依赖项 | 各部分的负责人是谁？存在哪些阻塞项？谁负责审批？ |
Interview Protocol
访谈流程
1. Read and Analyze
1. 阅读与分析
Read the plan file. For each section, identify:
- Undefined terms: Words that mean different things to different people
- Missing specifics: Numbers, formats, thresholds not specified
- Assumed context: References to things not in the document
- Hidden dependencies: Things that must be true for the plan to work
阅读计划文档。针对每个部分，识别：
- 未定义术语：不同人可能有不同理解的词汇
- 缺失细节：未明确的数字、格式、阈值
- 隐含上下文：文档中未提及的参考内容
- 隐藏依赖：计划落地必须满足的前提条件
2. Ask in Batches by Topic
2. 按主题批量提问
Use with 2-4 related questions per batch. Group by category.
AskUserQuestionBefore each batch, state your reasoning:
I notice the plan says "[quote]" but doesn't specify [gap].
This matters because [consequence if undefined].使用，每次批量提出2-4个相关问题，按类别分组。
AskUserQuestion每次提问前说明理由：
我注意到计划中提到“[引用内容]”，但未明确[缺失的信息]。
这一点很重要，因为[若不明确可能导致的后果]。3. Challenge Vague Answers
3. 应对模糊回答
When user gives a deflecting or vague answer:
| User Says | You Respond |
|---|---|
| "We'll figure it out later" | "What specifically needs to be true before we can figure it out? Who decides?" |
| "It should be fast enough" | "What's the current latency? What would make you say 'this is too slow'?" |
| "Standard approach" | "Which standard? Can you point to an example in this codebase?" |
| "Design will handle that" | "Has design delivered this? If not, when? What's our fallback?" |
| "Users will understand" | "Which users? Have we tested this assumption? What's the support cost if wrong?" |
| "I trust you to figure it out" | "My job is to surface gaps, not make assumptions. What would happen if I guess wrong on [specific item]?" |
| "We're running out of time" | "I can compress into 2 more batches. But skipping categories means shipping bugs. Which risks do you want documented as 'owner: you'?" |
| "Just start building" | "Building with gaps means rework. 5 more minutes now saves days later. What's the real constraint - time or energy?" |
Never accept:
- Qualitative terms without quantitative definitions
- Future tense without owners and dates
- References to artifacts without links or locations
- "Someone" instead of a specific name/team
当用户给出回避或模糊的回答时：
| 用户表述 | 你的回应 |
|---|---|
| “我们之后再解决” | “在解决这个问题之前，必须满足哪些具体条件？由谁来决策？” |
| “速度足够快就行” | “当前的延迟是多少？什么情况会让你觉得‘这个速度太慢了’？” |
| “采用标准方案” | “哪种标准方案？能否指出代码库中的示例？” |
| “设计团队会处理这个” | “设计团队已经交付相关内容了吗？如果没有，什么时候交付？我们的备选方案是什么？” |
| “用户能理解的” | “指的是哪类用户？我们验证过这个假设吗？如果假设错误，支持成本会是多少？” |
| “我相信你能搞定” | “我的职责是找出漏洞，而非做出假设。如果我在[具体事项]上猜错了，会导致什么后果？” |
| “我们没时间了” | “我可以把剩余问题压缩成1-2批。但跳过某些类别意味着会带着漏洞上线。你希望哪些风险被记录为‘负责人：@你’？” |
| “直接开始开发吧” | “带着漏洞开发意味着返工。现在花5分钟澄清，能避免之后几天的返工。真正的约束是时间还是精力？” |
绝对不能接受：
- 无量化定义的定性术语
- 无负责人和日期的未来计划
- 未提供链接或位置的工件引用
- 用“某人”代替具体姓名/团队
4. Probe for Non-Obvious Gaps
4. 挖掘非显性漏洞
Obvious questions (avoid these as primary questions):
- "What are the requirements?"
- "What's the timeline?"
- "Who's the user?"
Non-obvious questions (these surface real gaps):
- "What happens to in-flight requests during deployment?"
- "If this succeeds beyond expectations, what breaks first?"
- "What's the most expensive assumption we're making?"
- "Which part of this plan are you least confident about?"
- "What would make you cancel this project tomorrow?"
- "Who will be upset when this ships, and why?"
- "What's the first thing users will try that we haven't designed for?"
显性问题（避免作为主要问题）：
- “需求是什么？”
- “时间线是怎样的？”
- “用户是谁？”
非显性问题（能挖掘出真实漏洞）：
- “部署过程中，正在处理的请求会如何？”
- “如果功能的成功超出预期，首先会出现什么问题？”
- “我们做出的最具风险的假设是什么？”
- “你对计划中的哪一部分最没信心？”
- “什么情况会让你明天就取消这个项目？”
- “功能上线后，谁会不满，原因是什么？”
- “用户首先会尝试但我们未做设计的功能是什么？”
5. Track Coverage
5. 跟踪覆盖情况
Maintain mental checklist. After each batch, assess:
- Technical architecture clear?
- UX states defined?
- Tradeoffs explicit?
- Edge cases identified?
- Security considered?
- Testing strategy exists?
- Rollback plan defined?
- Dependencies confirmed?
在脑中建立检查清单。每完成一批提问后，评估：
- 技术架构是否清晰？
- UX状态是否明确？
- 取舍权衡是否显性化？
- 边缘场景是否已识别？
- 安全因素是否已考虑？
- 测试策略是否存在？
- 回滚方案是否明确？
- 依赖项是否已确认？
Handling Time Pressure
应对时间压力
When stakeholder is impatient:
Compress, don't skip. Combine remaining categories into 1-2 dense batches. Never skip a category entirely.
Make risk explicit. If they insist on skipping: "I'll document [Security: TBD, Owner: @you] in the spec. You're accepting this risk."
Name the tradeoff. "5 more minutes now, or 2 days of rework when we discover [gap] in production. Your call."
Never rationalize:
- "They know their business" - They don't know what they haven't thought about
- "I can figure it out" - Your assumptions are bugs waiting to happen
- "They seem confident" - Confidence is not evidence of completeness
- "I'm being annoying" - Surfacing gaps IS the job
当干系人不耐烦时：
压缩流程，而非跳过环节。将剩余类别合并为1-2批密集提问。绝对不能完全跳过任何类别。
明确风险。如果他们坚持跳过：“我会在规格文档中记录[安全：待确认，负责人：@你]。你将承担此风险。”
点明取舍。“现在多花5分钟，能避免上线后发现[漏洞]导致的2天返工。请你决定。”
绝对不要找借口：
- “他们了解自己的业务”——他们不知道自己没考虑到的内容
- “我可以自己搞定”——你的假设就是潜在的漏洞
- “他们看起来很有信心”——信心不等于内容完整
- “我这样很烦人”——挖掘漏洞就是我的职责
Completion Criteria
完成标准
Interview is complete when:
- All vague terms operationalized - Every qualitative word has a number or concrete definition
- All categories covered - Checklist above is complete
- No deflections remaining - All "we'll figure it out" answers have been challenged and resolved
- Dependencies confirmed - External people/teams/artifacts are named and accessible
- You cannot find more gaps - Genuinely exhausted questioning, not just tired of asking
访谈完成的条件：
- 所有模糊术语已落地——每个定性词汇都有对应的数字或具体定义
- 所有类别已覆盖——上述检查清单全部完成
- 无回避回答残留——所有“之后再解决”的回答都已被挑战并解决
- 依赖项已确认——外部人员/团队/工件已明确命名且可访问
- 无法找到更多漏洞——确实已穷尽所有问题，而非只是不想再问
Output Format
输出格式
When interview is complete, write structured spec:
markdown
undefined访谈完成后，撰写结构化规格文档：
markdown
undefined[Project Name] - Implementation Spec
[项目名称] - 落地规格文档
Overview
概述
[1-2 sentences: what this is and why it matters]
[1-2句话：说明此内容是什么以及其重要性]
Success Criteria
成功标准
- [Measurable criterion with number]
- [Measurable criterion with number]
- [带数字的可衡量标准]
- [带数字的可衡量标准]
Technical Decisions
技术决策
| Decision | Choice | Rationale |
|---|---|---|
| [Area] | [What we're doing] | [Why, including rejected alternatives] |
| 决策领域 | 选择方案 | 理由 |
|---|---|---|
| [领域] | [我们要做的内容] | [原因，包括被否决的备选方案] |
User Experience
用户体验
Happy Path
正常流程
[Step by step flow]
[分步流程]
Edge Cases
边缘场景
| Scenario | Behavior |
|---|---|
| [Case] | [What happens] |
| 场景 | 行为 |
|---|---|
| [场景] | 会发生什么 |
Error States
错误状态
| Error | User Sees | Recovery |
|---|---|---|
| [Type] | [Message/UI] | [How to fix] |
| 错误类型 | 用户看到的内容 | 恢复方式 |
|---|---|---|
| [类型] | [提示信息/UI] | 如何修复 |
Security Considerations
安全考量
- [Item with mitigation]
- [带缓解方案的事项]
Testing Strategy
测试策略
- Unit: [What's covered]
- Integration: [What's covered]
- E2E: [Critical paths]
- 单元测试：[覆盖范围]
- 集成测试：[覆盖范围]
- E2E测试：[核心路径]
Rollback Plan
回滚方案
[How we undo this if it fails]
[若故障发生，如何撤销此变更]
Open Questions
未解决问题
- [Anything still unresolved, with owner]
- [仍未解决的事项，含负责人]
Dependencies
依赖项
| Dependency | Owner | Status |
|---|---|---|
| [Thing] | [Person/team] | [Confirmed/Pending/Blocked] |
undefined| 依赖项 | 负责人 | 状态 |
|---|---|---|
| [事项] | [人员/团队] | [已确认/待确认/阻塞] |
undefinedRed Flags - Dig Deeper
危险信号——需深入挖掘
When you hear these, the interview is NOT done:
- "That's a good question, we should think about that"
- "I'm not sure, but probably..."
- "The other team handles that"
- "We've always done it this way"
- "That won't happen" (about edge cases)
- "We'll add that later"
- "It's just like [other project]" (without specifics)
当听到以下表述时，访谈尚未完成：
- “这个问题很好，我们应该考虑一下”
- “我不确定，但可能……”
- “其他团队负责这个”
- “我们一直都是这么做的”
- “那种情况不会发生”（针对边缘场景）
- “我们之后再加上”
- “和[其他项目]一样”（未提供具体细节）
Common Mistakes
常见错误
| Mistake | Fix |
|---|---|
| Accepting first answer | Always ask "why?" at least once |
| Asking obvious questions | Lead with non-obvious probes |
| Moving on when stuck | Challenge deflections explicitly |
| Single questions | Batch 2-4 by topic |
| Not showing reasoning | Explain why each question matters |
| Stopping when tired | Check completion criteria, not energy level |
| 错误 | 解决方法 |
|---|---|
| 接受第一个答案 | 至少问一次“为什么？” |
| 提问显性问题 | 以非显性问题为先导 |
| 遇到阻碍就跳过 | 明确挑战回避性回答 |
| 单次只提一个问题 | 按主题批量提出2-4个问题 |
| 未说明提问理由 | 解释每个问题的重要性 |
| 因疲惫而停止 | 参照完成标准，而非精力状态 |