4万星的Agent技能提醒我们：答案太全也可能不可用
内容提要
GitHub 项目 i-have-adhd 获 4 万星，它不修改模型，而是通过输出规则要求编码 Agent 行动优先、使用编号步骤、抑制支线并给出明确下一步。文章认为提示词正在承担界面职责，优秀输出应降低用户切换成本，采用渐进披露，先给状态与下一动作，再按需展开解释。该规则适合故障排查等任务，但架构评审、教学等需保留多方案，不宜过度压缩。
延伸解读
输出规则为何能替代界面设计
文章指出，i-have-adhd 不修改模型，仅通过输出规则要求 Agent 行动优先、编号步骤、压住支线。这相当于把界面层的职责转移给提示词：用户无需在长文中自行筛选，而是由规则决定信息释放顺序。当 Agent 能改文件、跑命令时，这种输出契约比语气更重要，因为它直接影响用户能否看清当前状态与授权边界。
渐进披露与粗暴截断的区别
文章用登录测试失败为例，说明低可用回答先铺背景、罗列多种原因，而行动优先版本先给单条命令和下一步。这种设计称为渐进披露：第一屏只放当前状态、下一动作和风险，失败后再展开解释。它与截断不同，截断丢信息，渐进披露保留获取路径，且每一层都对应一个决策，从而降低用户切换成本。
状态重述必须来自真实工具结果
长任务跨多轮对话后，用户容易忘记哪些文件已改、测试是否运行。文章建议用三行固定格式写“已完成、当前阻塞、下一步”，比复述整段历史更省认知资源。但状态必须来自真实工具结果；若未运行测试，就应写“未运行”，不能用顺滑语气掩盖缺口。这提醒读者，输出规则的有效性依赖真实执行反馈。
适用边界与团队验证方法
文章强调，行动优先规则适合故障排查、部署、代码修改等任务，但不适合架构评审、风险分析、教学等需保留多方案的场景，过度压缩可能隐藏假设与替代路线。团队可将输出契约写成可切换模式，如行动模式、解释模式、决策模式。验证时不应只看回答是否更短，而应比较首次正确行动时间、追问次数、误操作率等指标。
Q&A
i-have-adhd 这个 GitHub 项目具体做了什么？
它不改模型、不接新工具，只提供一组输出规则，可安装到多种编码助手。规则包括行动优先、多步骤编号、每轮重述状态、限制列表长度、用具体分钟描述耗时，以及避免寒暄和重复总结。
为什么说“完整回答”反而会制造摩擦？
编码任务处于中断密集环境，用户需要快速切换终端、文件和测试。如果助手先铺背景、罗列多种可能，再把唯一命令藏在末尾，用户需在工作记忆中持续筛选，输出越长未必信息越多，无关内容会稀释信号。
什么是“渐进披露”，它和粗暴截断有什么区别？
渐进披露指第一屏只放当前状态、下一动作和风险；执行失败后再展开相关解释；用户主动询问时才给完整原理。它与粗暴截断不同：截断会丢信息，渐进披露保留获取信息的路径，并让每一层都对应一个决策。
这种输出规则适合哪些场景，不适合哪些场景？
适合故障排查、部署、代码修改和需要频繁确认的长任务，也能帮助手机阅读、屏幕阅读器和容易被支线打断的人。不适合未经调整地用于架构评审、风险分析、教学和需要保留多方案的决策，因为过度压缩可能隐藏假设、证据和替代路线。
团队如何验证这种输出规则是否有效？
不要只问回答是否更短。选20个真实任务，比较两套输出契约：用户首次采取正确行动的时间、追问次数、误操作率、任务完成率，以及关键风险是否被遗漏。还可以把规则分层：默认先行动；用户请求解释原理时展开；涉及删除、付费或生产变更时强制显示风险块。
今天就能做的小实验是什么？
把团队提示词加上三句：“第一行给当前建议；步骤不超过五个；最后只给一个下一动作。”运行一周后，抽样失败任务，检查究竟是模型能力不足，还是答案结构让人没有执行。
