interviewing-plans

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Interviewing 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

AskUserQuestion

with 2-4 related questions per batch. Group by category.

Before each batch, state your reasoning:

I notice the plan says "[quote]" but doesn't specify [gap].
This matters because [consequence if undefined].

使用

AskUserQuestion

，每次批量提出2-4个相关问题，按类别分组。

每次提问前说明理由：

我注意到计划中提到“[引用内容]”，但未明确[缺失的信息]。
这一点很重要，因为[若不明确可能导致的后果]。

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. 跟踪覆盖情况

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

依赖项	负责人	状态
[事项]	[人员/团队]	[已确认/待确认/阻塞]

undefined

Red 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个问题
未说明提问理由	解释每个问题的重要性
因疲惫而停止	参照完成标准，而非精力状态