一个答案可以事实正确、逻辑完整，却依然不好用。9月14日登上GitHub热门榜的i-have-adhd项目已获得超过4万颗星，它不改模型、不接新工具，只用一组输出规则要求编码Agent先给行动、编号步骤、压住支线，并以一个明确下一步收尾。它击中的不是“大家讨厌长文”，而是AI界面常把阅读成本转嫁给用户。
项目实际做了什么
项目仓库提供可安装到多种编码助手的Skill或插件。仓库列出十条规则，包括行动优先、多步骤编号、每轮重述状态、限制列表长度、用具体分钟描述耗时，以及避免寒暄和重复总结。作者明确说无需注意缺陷多动障碍诊断也能使用，并说明设计借鉴相关工具书，但适配对象是大模型输出，不是对人的医疗建议。
这是一个开源项目的自述，星标代表关注度，不代表临床有效性或生产效率已经被严格实验验证。它真正可验证的事实，是规则文本、支持的安装形式和公开代码。
为什么“完整回答”会制造摩擦
编码任务往往处于中断密集的环境：用户刚看完报错，又要切终端、文件和测试。如果助手先铺背景、罗列六种可能，再把唯一命令藏在末尾，人需要在工作记忆中持续筛选。输出越长，未必信息越多；大量与当前决策无关的内容会稀释信号。
我的核心判断是：提示词正在承担界面层的职责，优秀输出不是信息最多，而是让用户用最低切换成本完成下一步。 当Agent可以改文件、跑命令时，这种输出契约甚至比语气更重要，因为它决定用户能否看清当前状态与授权边界。
一个具体改造案例
用户问“登录测试为什么失败”。低可用回答可能先解释认证体系，再列缓存、时钟、密钥、Cookie等八种原因。行动优先版本可以写：“先运行单个失败用例，并贴出第一条断言：npm test -- auth.spec.ts。若提示令牌过期，再检查测试时钟。”它没有假装已知道根因，也没有删除必要背景，只把信息按决策顺序释放。
这种设计可以抽象为“渐进披露”：第一屏只放当前状态、下一动作和风险；执行失败后，再展开与错误相关的解释；用户主动询问时，才给完整原理。它与把回答粗暴截断不同。截断会丢信息，渐进披露则保留获取信息的路径，并让每一层都对应一个决策。
状态重述同样关键。长任务跨越几轮对话后，用户最容易忘记哪些文件已改、测试是否运行、还差什么。用三行固定格式写“已完成、当前阻塞、下一步”，比再次复述整段历史更省认知资源。这里的状态必须来自真实工具结果；如果没有运行测试，就应写“未运行”，不能用顺滑语气掩盖缺口。
适用边界
这种规则适合故障排查、部署、代码修改和需要频繁确认的长任务；也能帮助手机阅读、屏幕阅读器和容易被支线打断的人。它不适合未经调整地用于架构评审、风险分析、教学和需要保留多方案的决策，因为过度压缩可能隐藏假设、证据和替代路线。
“不加前言”也不应变成粗暴。高风险操作前必须说明影响与回滚方式；不确定时必须标记不确定；医学意义上的ADHD不能被十条提示规则概括。项目名称带来传播力，也可能让真实障碍被工具化，这是使用者应该保持的边界意识。
对于团队，最好把输出契约写成可切换的模式，而不是绑死在所有任务上。故障处理用“行动模式”，新人学习用“解释模式”，架构会议用“决策模式”。同一个模型根据场景切换信息密度，比试图寻找一套人人满意的万能提示更现实。
开发团队可以怎样验证
不要只问回答是否更短。选20个真实任务，比较两套输出契约：用户首次采取正确行动的时间、追问次数、误操作率、任务完成率，以及关键风险是否被遗漏。还可以把规则分层：默认先行动；用户请求“解释原理”时展开；涉及删除、付费或生产变更时强制显示风险块。
今天就能做的小实验是，把团队提示词加上三句：“第一行给当前建议；步骤不超过五个；最后只给一个下一动作。”运行一周后，抽样失败任务，检查究竟是模型能力不足，还是答案结构让人没有执行。
你的AI助手最常在哪一步把正确答案说得难以执行？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。
