Menü
引导用户形成完整技术问题描述，生成结构化问题草稿。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
自动化编排。触发：/hany:auto。根据用户描述自动调用 hany-require → planreview → hany-implement → 智能验证路由(verify-small/verify-project)，渐进式加载+验证修复循环+错误回退。
详细实现。触发：/hany:implement。基于hany:require确认的示例和方案，拆解任务+分配Agent→并行实现→完成前验证→提交。
需求确认+示例原型。触发：/hany:require。Brainstorming+Deep-interview式提问→歧义评分→确认需求→输出可行示例+技术说明+架构图+思维过程。
项目级验证。触发：/hany:verify-project。针对大功能、架构调整、多文件改动的完整验证：多视角并行审查+功能测试+回归验证+边界检查+修复循环+质量清单+根因分析。
hany skill 公共层：共享规则库、公共流程模式、公共配置。所有 hany-* skill 共享。
需求文档评审优化。触发：/hany:planreview。针对已创建的需求文档，挑战不合理性并优化文档质量。
Basierend auf der SOC-Berufsklassifikation
| name | hany-question |
| description | 引导用户形成完整技术问题描述，生成结构化问题草稿。 |
| author | hany |
| version | 1.0 |
触发方式：/hany:question
调用方：可独立触发
/hany:question，也可由hany-autoStep 1.5 自动调用（当原始描述模糊时）。
核心原则：推导但不猜测。通过引导式提问帮助用户补齐关键信息，最终生成高质量的技术提问草稿。
详见
hany-common/procedures/interaction_rules.md
详见
hany-common/procedures/quality_modes.md
读取
hany-common/rules/rules.md，11 条规则全程生效。
[按需加载] 执行时：
- 启动阶段：仅读"工作流程"和"Step 0：先想想看"即可开始
- 执行阶段：进入 Step 时跳读到对应章节
- 已完成阶段：用摘要替代详细内容
| 阶段 | 核心动作 | 确认节点 |
|---|---|---|
| Step 0 | 先想想看，判断是否需要执行 | — |
| Step 1 | 接收输入并评估完整度 | — |
| Step 2 | 判断分类（错误/行为/配置/概念） | — |
| Step 3 | 追问循环（含挑战者模式） | 每轮 AskUserQuestion |
| Step 4 | 生成草稿及持久化 | — |
| Step 5 | 最终确认 | AskUserQuestion |
见上方快速参考卡（按顺序从 Step 0 到 Step 5）。
⚠️ 若由
hany-auto调用，跳过此步（auto 已完成初步思考）。
触发后，先思考再执行。
hany-require？思考完后输出思路再进入 Step 1。
收到用户描述后，计算歧义评分（详见「歧义评分」章节）：
| 类型 | 触发条件 | 必填字段 | 选填字段 |
|---|---|---|---|
| 错误类 | 有报错信息或"不工作"类描述 | 报错信息、复现步骤 | 环境、代码、已尝试 |
| 行为类 | "期望A但实际是B"类描述 | 期望行为、实际行为 | 环境、代码 |
| 配置类 | 涉及配置/部署/环境搭建 | 期望配置、实际配置 | 环境 |
| 概念类 | 问"是什么/为什么/怎么理解" | 困惑点 + 场景 | 相关代码 |
不确定分类时默认按「错误类」处理。
概念类不是补信息，是确认用户理解的边界。先问：
根据回答决定回答方向（解决问题 vs 解释原理），然后直接进入第四步。
每次追问最多 2 个问题，先复述用户已说的，再指出缺失点：
追问策略：用对比式提问，不要像填表。避免连续问封闭式问题。
信息矛盾处理：当用户新回答和之前信息冲突时，用"你之前说 X，现在说 Y，是改主意了还是我理解错了？"确认。
追问终止条件：
多问题处理：用户同时有多个问题 → 先处理第一个，其余标记为「附带问题」。
根据追问轮次自动激活（每个模式只用一次）：
| 轮次 | 模式 | 注入指令 | 示例 |
|---|---|---|---|
| 第 4 轮+ | 反问者 | 挑战用户的复现步骤或问题框架 | "你提到在执行 X 时报错，但 X 不应该触发这个错误。你确定步骤是对的吗？" |
| 第 5 轮+ | 简化者 | 找到最简复现路径 | "这个报错能用更少的步骤复现吗？最简复现是什么？" |
追问终止后主动输出草稿（不要等用户要求）。
根据分类裁剪模板，去掉不适用的区块。模板应包含：分类、标题、已知信息、缺失信息、复现步骤（错误类）、期望/实际行为（行为类）、环境信息、相关代码片段。
将草稿写入 docs/hany/questions/YYYY-MM-DD-<主题>.md。
---
date: YYYY-MM-DD
category: 错误/行为/配置/概念
status: draft
ambiguity: {最终歧义度}%
rounds: {追问轮次}
---
{草稿内容}
输出草稿后问用户："这份草稿可以吗？有需要补充或修改的地方吗？"
选项：
/hany:require根据用户反馈调整，直到用户满意。
详见
hany-common/procedures/ambiguity_scoring.md
每轮追问后计算歧义评分。
详见
hany-common/procedures/entity_tracking.md
每轮追问提取关键名词，追踪稳定性。防止概念漂移。