一个 Agent 要帮你改报表页。它先问布局，再问配色，接着问加载方式；每轮都有 A、B、C，A 后面总跟着「推荐」。你认真选了几轮，后来只想让它快点开始，于是一路确认。
这是个构造的场景，但和 Maggie Appleton 在 《Design Engineering with Maggie Appleton》访谈整理文里讲的困扰很像：规划阶段选择接连不断，人累了，就顺着推荐项答应下去。她用问到第 20 个问题时已经疲惫来形容这种感受。这是个人观察，不是决策能力的实验阈值。
系统收到了一堆回答，用户却未必更清楚最后会拿到什么。问题出在点确认之前：人有没有看到足够的依据。
推荐项替你省掉了哪一步
推荐本身有用。一个了解项目约束的 Agent，能给出判断，说清为什么某条路更合适。麻烦在于只写「推荐」两个字，人不知道它在优化什么。
回到报表页。A 是紧凑表格，B 是卡片，C 是分步浏览。开发者也许觉得表格省空间、好实现，而使用者要在手机上比几项关键数据。三种布局各有道理。模型如果还没弄清设备、数据和使用目的，就把 A 排在首位，用户很难判断这条推荐是否适合自己的任务。
这时再补一句「是否确定选择 A」，缺的信息并不会因此出现。问句多了，判断依旧悬着。
好的推荐会交代采用它的条件，以及什么情况下该改选。 比如：以桌面端比较多列数据为主，先做表格；手机是主要场景，就得另看小屏上的阅读路径。值得讨论的是这些条件，A 和 B 只是编号。
留下理由，后来纠偏也方便。项目原本服务桌面用户，后来改成移动优先，团队翻回去能找到旧选择依据的前提，不用猜当时那句「可以」到底指什么。
这不是说模型该先写一页免责声明。一两句有根据的建议，往往比一串同样郑重的选择题更好用。真正未知的关键条件仍要问；已经回答过、也没有变化的条件，就带进后续工作，不必再问一遍。
有些问题，先画出来
整理文里还有个更具体的做法。Maggie 会让编码 Agent 做一个带滑杆、颜色选择器等控件的原型，边看边调。这类辅助试验的小工具，Maggie 称为 jigs。
面对「间距用多大」，几个数字摆在一起，人很难看出区别。把同一组数据放进页面就不同了：拥挤的行、被截断的标签都摆在眼前，选择有了对象。调间距变成比较实际效果，用户还可能发现，原来的三个选项都不合适。
DialKit 的官方项目说明展示了类似的实现方向：用控件调整运行中界面的参数，比较不同版本。这些控件已经可以使用。至于能否改善决策，还要看具体交互与使用结果。
给报表页做这样一个小原型，我会先固定数据和任务，只放出本轮真要比较的变量。比如让行密度可调，加一个窄屏预览，再塞几条超长名称和空值。普通情况要看，会把布局撑坏的内容也要看。
变量不是越多越好。二十道题换成二十根滑杆，照样让人无从下手。原型只服务当下这个问题；数据加载策略、权限、发布环境，不必都挤进同一个调参面板。
看完之后得能留下选择。用户调出一组值，下一轮生成又回到默认配置，这次比较就白做了。把所选参数、示例数据的版本和关键截图记在任务里，至少能说清团队接受的是哪一种具体效果。
导出按钮比圆角更该问清楚
可视化擅长让人看到效果，另一类取舍却牵涉业务后果，光看画面看不出来。
假设报表加了个导出按钮。模型问「导出全部还是当前页」，用户选了听起来更完整的「全部」。可这个「全部」指什么？是当前筛选结果，还是整个数据集？仍受当前账户的访问范围限制吗？用户已经设好的筛选会不会丢？
这些不是颜色偏好。含糊的词原样写进代码，就变成别人实际拿到的数据。
更有用的做法是先给出一个具体方案：保留当前筛选，只导出该账户可见的记录，屏幕上显示预计条数和字段预览，让用户对照本次目的判断。业务确实要另一种范围的话，就写明它会改变什么，交给有权决定的人。
这个例子是设计建议，不是 Maggie 团队披露的实现。同样叫「确认」，背后的工作可以完全不同：有的要一个能比较的画面，有的要补业务信息，有的其实是执行权限的边界。
用户点头不能替代权限检查。 页面上写着「仅可见记录」，服务端查询就得按执行身份真的收窄范围，不能因为浏览器传来一个选项，就当授权已经解决。预览和真正导出之间数据若有变动，也要让使用者知道预览的有效范围，免得旧的行数被当成承诺。
界面让用户看见后果，实现另行独立校验。少了后一半，那句记下来的「同意」就只是一条记录。
同意预览，不等于同意上线
提问过多还有一个原因：系统没有区分工作阶段。
如果预览任务已经授权 Agent 修改本地文件、运行现有检查，且任务范围和环境没有变，每走一步都重问一次，只会把注意力消耗在重复回答上。可一旦从预览走向生产，动作的对象和影响都变了。先前对方案的认可，不能顺势延伸成任意执行的许可。
只审预览时，可以这样交接：
当前版本：preview-17
本次可检查：报表布局、筛选交互、导出字段预览
尚未执行：生产发布、真实数据导出
下一步：根据反馈修改预览
这只是交互信息的示意，不是授权系统。真实工具仍要校验操作者身份和动作范围；要执行许可的步骤，先拿到对应的许可再做。超时、沉默、预选了某个答案，都算不上同意。
记录还得指向当时看过的版本。用户认可的是 preview-17，之后导出字段或执行对象一变，旧记录就不足以说明新动作已获许可。这时再要求确认，该展示的是这次改了什么，而不是又抛一句没有对象的「是否继续」。
所以想少问几次，前提是把已有的决定存好，而且存的不能只是一个布尔值：哪一版方案、什么范围、后来变了什么，都得追得到。至于授权本身，页面上的记录只是呈现，约束要在执行端生效。
一个人按下的 A，团队未必看得见
Maggie 在 2026 年 4 月的 《One Developer, Two Dozen Agents, Zero Alignment》演讲文字里谈过另一层问题：一个人可以同时驱动好几个 Agent，团队却未必对该做什么达成一致。Maggie 希望协作和规划早点发生，别把分歧一路留到代码生成之后。
这给连续确认的问题补上一块。有人在私人对话里接受了某个推荐，不代表产品、设计和工程同事都看过这个选择，更不代表当事人能独自拍板所有业务变化。
设想报表的导出范围由业务负责人定，界面布局归设计，实施归开发。这时系统该把待解决的问题送到对应的人面前。让当前操作者一路代答，交互上很顺，后面却可能整段重做。
把完整聊天记录丢给同事也不行。更好的交接是一份短小的决定摘要：要解决什么问题，采用了哪版方案，依据是什么，还有哪些分歧没解决。再配上原型或具体变更，别人才看得懂；需要时再展开对话和证据。
少问之后，看决定有没有变好
不过，少问并不是目标。
一个从不提问、很快交差的 Agent，可能只是带着错误假设跑得更远。反过来，一次必要的追问也许拦住了范围错误的导出，耗时长了，结果更好。
评估新的交互，可以先固定一组有代表性的任务，比较使用者能否讲清选择的后果、能否发现不合适的推荐、后面在哪些地方返工。选择题少了多少、用了多久，照样记录；误解、权限错误和未获许可的执行也一并观察，别让速度把它们盖住。
这里没有现成的提升比例，也没有适用于所有人的题数上限。原文提出的困扰，最终还得在使用中检验：人能不能看清方案、找到依据，并对自己有权决定的事作出选择。
一次确认的价值，在于它对应着一个人看得懂、改得动、也有权决定的具体方案。
留言