Meshery 仓库 gepetto 技能中的 AI 需求访谈协议从模糊 spec 到可执行实现计划的提问设计与落地【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery导读本文围绕 Meshery 仓库.agents/skills/gepetto技能中的interview-protocol.md参考文档系统拆解在AI 辅助实现规划流水线中如何设计一轮高质量的需求访谈从访谈在整体工作流中的位置与运行约束、提问技术与好坏问题判别到停止条件与转录存档规范。读者读完可以掌握一套可复用的从用户脑中提取隐含需求的提问框架并将其直接套用到自己的 AI 编码 Agent 或需求分析流程中。一、访谈协议在 gepetto 流水线中的定位gepetto 是 Meshery 仓库.agents/目录下的一套 Claude Code 技能其核心使命是把模糊的初始 spec粗糙的木料雕琢成可执行的、分节化的实现计划。完整的流水线为Research → Interview → Spec Synthesis → Plan → External Review → Sections在 gepetto/SKILL.md 中流水线被划分为 17 个步骤其中详细访谈Step 6: Detailed Interview与保存访谈转录Step 7: Save Interview Transcript直接引用本文档 interview-protocol.md。访谈是承上启下的关键节点上游承接claude-research.md的研究发现下游产出claude-interview.md转录供第 8 步 Spec 综合Spec Synthesis把初始输入 研究发现 访谈答案三者合并为完整的规格说明书。二、为什么访谈必须运行在技能主上下文中interview-protocol.md开篇就给出了一条关键约束The interview runs directly in this skill (not subagent) becauseAskUserQuestiononly works in main conversation context.这是由 Claude Code 的工具能力边界决定的AskUserQuestion向用户弹出带选项的提问 UI只能在主对话上下文中工作子代理subagent无法调用它。因此访谈环节不能像研究、外部审查、章节撰写那样分派给并行子代理而必须由主上下文的 Agent 亲自执行。这一约束直接影响了整个 gepetto 工作流的设计——研究环节可以并行见 research-protocol.md 中Subagents Return Results, Parent Writes Files的模式而访谈则被刻意保留在主线程上。三、访谈的上下文输入spec 与研究发现的配合文档明确规定了访谈应被哪些信息所告知初始 spec始终可用用户启动/gepetto path/to/spec.md时传入的 Markdown 文件是访谈的起点。spec 可以非常详细也可以只是若干条要点——访谈阶段正是用来补齐细节的。研究发现如果第 5 步产生了claude-research.md研究报告的存在会改变访谈策略。当研究已经完成时协议要求访谈做三件事跳过已被研究回答的问题——避免浪费用户的问答轮次针对研究发现中暴露的取舍trade-offs与模式提出澄清性问题在研究揭示复杂性的领域深挖——研究能指出哪些区域存在隐藏的复杂度访谈则负责让用户明确偏好。这套研究先行、访谈聚焦的组合保证了每一轮问答都落在信息缺口上而不是重复已知事实。四、访谈哲学把自己当作对实现负责的高级架构师文档用四条原则定义了访谈的心智模型你是一名对该实现负责的高级架构师senior architect accountable for this implementation把用户已知但未提及的一切都挖掘出来Surface everything the user knows but hasnt mentioned假定初始 spec 是不完整的Assume the initial spec is incomplete从用户脑中提取上下文Extract context from users head。其中假定 spec 不完整是最核心的思维转变用户的原始描述天然会遗漏边界条件、失败场景、规模预期与既有代码模式访谈的责任不是验证 spec而是补全 spec。五、提问技术聚焦、开放、逐层深挖interview-protocol.md给出了四条可操作的提问纪律使用AskUserQuestion提出聚焦的问题每轮 2~4 个——一次性抛出的选项过多会稀释回答质量问开放式问题而非 Yes/No 问题——封闭式问题只能拿到一个布尔值无法暴露上下文不要问 spec 里已经写明答案的显而易见问题——那是对用户注意力的浪费当答案暴露出复杂性时继续深挖并定期总结以确认理解一致——Dig deeper when answers reveal complexity, Summarize periodically to confirm understanding。5.1 好问题与坏问题的判别文档用两组对照示例给出了可复用的判别标准好问题聚焦于失败场景、既有模式、规模预期当 X 失败时会发生什么我们应该重试、记录日志还是呈现给用户失败场景代码库中是否已有我们应该遵循的 Y 模式既有模式预期的规模是多少——几十、几千还是几百万的 Z规模预期坏问题过于宽泛、无法引导出有效信息的开放式泛问还有其他什么吗Anything else?就这些吗Is that all?你还有其他需求吗Do you have any other requirements?这三类坏问题的共同点是它们把思考负担完全推给用户用户通常会回答没有了而实际上隐藏需求并未被触达。好问题则相反它主动为回答框定了维度失败、模式、规模用户只需在给定维度内补充事实。六、停止条件何时结束访谈文档给出了明确的停止标准——当且仅当你确信自己能够做到以下三点时访谈才算完成能写出一份详尽的实现计划Write a detailed implementation plan对需求零假设Make no assumptions about requirements——即不再有任何猜测成分能处理用户关心的所有边界情况Handle all edge cases the user cares about。配套两条兜底策略不确定就问如果仍有任何不确定再多问一轮。文档的立场是宁可过度澄清也不要基于错误假设开工Better to over-clarify than make wrong assumptions。用户主导权丧失则止损如果用户对大多数问题都以我不知道或你决定回答说明继续追问的边际收益已经很低此时应停止访谈、继续推进而不是无休止地消耗轮次。七、转录存档claude-interview.md 的格式规范访谈结束后主 Agent 必须把完整的问答对保存为planning_dir/claude-interview.mdplanning_dir即 spec 文件所在的父目录。文档规定了三条格式要求每个问题以 Markdown 标题heading呈现在标题下方完整记录用户的回答原文Include the users full answer below为问题编号以便引用Q1、Q2 等。这份转录是下游 Spec 综合Step 8的直接输入同时它也是 gepetto 断点续跑机制的一部分在 SKILL.md 的续跑状态表中只要检测到claude-interview.md存在工作流就会从 Spec 综合步骤继续而不会重复向用户提问。也就是说转录文件的质量直接决定了整个规划流程的可恢复性与可追溯性。八、与上下游协议的整体衔接interview-protocol.md并非孤立文档它与.agents/skills/gepetto/references/目录下的其他协议共同构成完整流程参考文档覆盖环节与访谈的关系research-protocol.mdStep 4-5 研究决策与执行研究结论写入claude-research.md作为访谈的上下文输入interview-protocol.mdStep 6-7 详细访谈与转录本文主体产出claude-interview.mdexternal-review.mdStep 10 外部 LLM 审查访谈澄清需求后计划再交由 Gemini/Codex CLI 独立审查两者形成人机双保险section-index.mdStep 13 章节索引计划落地为可并行实现的 section 单元从 README.md 的产出文件清单可以清楚看到这条数据链claude-research.md→claude-interview.md→claude-spec.md→claude-plan.md→reviews/→sections/。访谈协议正是这条链上把用户脑中的隐性知识转写为可被机器执行的规格文本的关键一环——它的好坏直接决定了后续计划是建在实地上还是沙地上。九、实践建议将协议迁移到自己的 AI 编码流程基于上述协议可以在自己的 AI 辅助开发流程中落地以下三条可操作规则设问维度化把你还有什么需求替换为按维度设问的模板——失败行为重试/记录/提示、既有代码模式、规模量级几十/几千/几百万、兼容性边界、安全约束。每个维度对应一轮 2~4 个问题的AskUserQuestion。设定显式终止条件在访谈开始前就把能写出零假设的实现计划 覆盖用户关心的边界情况作为完成判据写入 TODO避免无限追问或过早收工同时为用户大量回答我不知道/你决定设置止损点。结构化存档问答对每轮访谈立即以问题标题 完整答案 编号Q1/Q2…的格式写入claude-interview.md这不仅服务于 spec 综合也让你在上下文耗尽时能够无损续跑——正如 gepetto 的断点续跑机制所证明的。十、小结interview-protocol.md虽然只有数十行却浓缩了一整套可工程化的需求访谈方法论明确运行上下文约束、定义信息输入、建立架构师心智 假设不完整的哲学、给出提问纪律与好坏问题判别、设定可验证的停止条件并以严格的转录格式把访谈沉淀为下游可消费的产物。对于任何想为 AI 编码 Agent 或需求分析流程引入结构化访谈能力的团队这套协议都是一份可以直接复用的参考范本。【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考