interview-me
在需求最模糊、任何 plan 和代码都还没出现时，用「一次一问 + 每问附 agent 猜测 + 显式置信度」的访谈式提问，把用户真正想要的意图（而非他觉得自己应该要的）挖出来，交付一份经显式确认的意图陈述，供下游 spec/plan 阶段使用。
仓库：addyosmani/agent-skills
热度证据：所属仓库 86.7k star，Trendshift 榜上仓库
五维评分
热度5/5
质量5/5
创新4/5
易用4/5
文档5/5
优秀点拆解
- 置信度数字 + 理由的诚实强制机制：每轮必须写下 0-100% 假设置信度，低于 70% 必须附缺失理由，让 agent 无法静默填补模糊需求
- Q + GUESS 提问格式把 agent 的假设推上台面：用户只需确认/反驳而非从零回答，认知负担低，两三问就能逼出真实意图
- 针对 sycophancy 的专门探测层：识别最佳实践腔/惯例 defer/流行词信号，用『如果不用向任何人交代，你真正想要什么？』等高杠杆提问破局
- 可检查的停止条件：『能否预测用户对接下来三个问题的反应』是可判定测试而非感觉，并带多轮不收敛即停的失败护栏
- 把『确认』定义到排他性程度：明确列出 what ever you think/sounds good 等不算 yes 的回答及替代动作，配 9 条 verification checklist 可自查审计
可复用的设计模式
- 访谈式需求澄清协议：一次一问 + 附猜测 + 显式置信度，直到能预测对方反应才停止，适合所有先对齐再动手的任务
- 反谄媚组合拳：信号识别清单 → 破局提问 → 偶尔故意猜错方向 → 显式列出哪些回答不算确认
- 定义『不合格确认』集合：把模糊表态（whatever you think、sounds good）列为非确认，换成二选一具体选项重问
- 带护栏的可验证退出条件 + 自查清单：停止条件写成可判定测试，流程可审计而非依赖自觉
适用场景
新项目/新功能起点只有一句模糊需求（build me X 但没说给谁、为什么、成功长什么样）用户显式要求被访谈（interview me、grill me、stress-test my thinking）两个合理价值冲突（简单 vs 灵活、成本 vs 速度）时用户没说明优化哪个agent 发现自己正打算基于未浮出水面的假设直接开干，需要先拉齐意图
边界与注意：必须真人实时响应，明令禁止在非交互环境（CI、定时任务、autonomous loop）使用；多轮对话消耗用户耐心，不适合明确机械操作和追求速度的批处理场景。
完整拆解分析文档
本页为摘要版，完整精读分析（核心机制、逐条优秀点拆解、写作过程）见本地 Markdown 文档：
analysis/addyosmani-interview-me.md