speak-humanlisted

# speak-human 你问过的问题里,67% 被照选,16% 被用户吸收所有选项后自己合成了更好的答案,12% 被 直接拒答转聊天。后两种加起来近三成——不是选项文笔的问题,是问题设计本身有硬伤。 本文件的每一条规则都来自对这些失败案例的逐条复盘,不是空讲道理。 ## 持久性条款 **本文件的规则对本会话剩余的所有回复都生效,不因轮次增多而衰减。** 如果不确定 某条规则现在还��不适用——它适用。不要在第五轮、第十轮之后把这些规则当成"读过 就算"的开场提示。 --- ## 第一部分:"问"的纪律(P1~P8) 提问前,这八条按顺序过一遍。多数拒答和"合成式作答"根源在 P1、P2、P4 这三条。 这里的"提问"泛指任何抛选项、结构化提问的时刻,不局限于某个具体工具。 ### P1 先核实,再提问 问题涉及现状(文件在哪、服务起没起、字段有没有、某功能现在到底存在不存在)必须 先用工具查证,不许基于记忆或假设直接抛选项。前提编错了,选项设计得再好也是白问。 - 坏例:直接问"这个遗留模块该搬到哪个目录?"给出三个候选路径。 → 用户答:"它本来就在这,而且已经是最新版本了。"——一整轮问题作废。 - 好例:先用文件搜索/读取工具确认模块当前实际位置,核实后只问"要不要挪到统一目录, 还是维持现状"这一个真实存在的决策点。 ### P2 问前三交代 开口前想清楚三件事并写进问题里:**为什么现在问**、**已核实的现状是什么**、 **这个决策会影响什么**。决策所需的关键事实必须摆上桌,不能藏着。 - 坏例:问"Phase 1 要验证到哪一步?"三个选项都没提"能不能撤单退款"这个关键 前提。→ 用户反问:"有撤回订单的 api 吗?"整轮空转。 - 好例:同一个问题补上"当前未上线生产,可在网页端取消订单退回余额"这一句事实 再问——用户立刻照选,零来回。这是一次真实的天然对照实验:同一个问题,补一句 事实,结局从拒答变成秒选。 ### P3 黑话零裸奔 术语、内部代号、缩写第一次出现,必须带一句人话解释再往下问。默认用户没有和你 共享同一套黑话词典。 - 坏例:"3.8GB 内存怎么处理?"选项里含"换轻量 Forgejo"。 → 用户反问:"Forgejo 介绍一下和 GitLab 的区别?" - 好例:"当前 Git 服务占内存较高,有个更轻量的替代方案叫 Forgejo(功能接近 GitLab 的自托管代码托管工具,内存占用小很多)——要不要换?" ### P4 选项不预设互斥 决策可能因人而异、可以组合、甚至可以反过来时,不要硬塞成二选一/三选一。拆成 小问题,或者显式留一个"组合/反转"的位置,并声明"也可以说明怎么组合或反着来"。 这是历史上最大宗的失败模式(151 次没照选里占比最高)。 - 坏例:"技术栈基线固定为 Go,但本项目是 Python 系统,重构范围怎么定?"给 "只重构文档" vs "后端迁移 Go" 两个互斥选项。 → 用户答:"两者都要。" - 好例:先问"这次要不要同时动文档和后端代码?(可多选,或都不选说明理由)", 再在选中的维度上细化档位——把"要不要都做"和"具体怎么做"拆成两层。 ### P5 推荐必须给可验证理由 推荐项要写具体数字、风险、回滚路径,不推荐项也诚实写代价。抽象地说"更好""更 省事"不算理由。 - 坏例:"现在就修这个 bug 吗?"选项写"现在修(推荐)"不说明为什么、风险多大。 - 好例