当大模型的基础能力逐渐趋同，继续提升能力带来的边际收益开始下降时，一个更实际的问题随之出现：除了模型能力，还有什么决定 LLM 是否真正好用？
我的答案是，除了能力本身，还要看速度、指令遵循和可靠性；而在模型之外，使用者能否建立有效的反馈循环同样重要。
好用不只取决于能力
模型在 Benchmark 上得分更高，不代表它在每一项真实工作中都更好用。
一个模型可能知识丰富、推理能力很强，却经常忽略格式和范围限制，擅自改变需求，添加没有被要求的内容，或者在没有验证的情况下声称任务已经完成。另一个模型或许在极限推理上略弱，却响应更快、输出更稳定，也更愿意遵守约束。对于大部分日常工作，后者可能反而更有价值。
如果把模型的实用价值写成一个粗略的表达式，可以是：
Practical Value = Capability × Instruction Following × Reliability × Speed / Cost这里更接近乘法，而不是加法。任何一项明显不足，整体体验都会迅速下降。能力决定模型能否进入一个任务，其他因素则决定人是否愿意持续使用它、是否敢把真实工作交给它。
速度的价值，是缩短反馈回路
速度当然意味着少等待几秒，但它真正重要的地方在于缩短了反馈回路：
Idea -> Expression -> Feedback -> Revision -> Next Attempt反馈越快，人越容易保持原有的思维状态，也越愿意探索不同方向。当每次尝试都要等待很久时，用户倾向于把所有要求塞进一条复杂指令，希望模型一次完成；当反馈足够快时，交互会自然变成短周期、多轮次的小步迭代。
这不仅是产品体验的变化，也会改变人与模型协作的方式。
模型可能因此形成两种不同角色：一种像反射神经，追求低延迟和高频率，随时参与思考过程；另一种像研究员，可以慢一些，但负责高难度推理和长时间任务。速度不会在所有场景中压倒能力，却决定了模型能否进入更实时、更高频的工作流程。
指令遵循决定模型是否值得托付
“模型有没有能力做”和“模型会不会按要求做”是两回事。
在普通聊天中，多写一段内容可能只是令人厌烦；当模型能够修改代码、操作数据库或者发送消息时，自作主张就会变成可靠性和安全性问题。模型的执行权限越大，指令遵循越重要。
理想的指令遵循至少包含几层能力：
- 准确理解用户明确提出的目标和约束。
- 保留用户没有授权改变的内容。
- 识别指令之间的冲突，并说明取舍。
- 在关键歧义上请求确认，而不是擅自猜测。
- 在安全范围内补全不影响目标的细节。
- 完成任务后提供能够被检查的证据。
- 知道什么时候应该停止，并请求新的授权。
指令遵循也不等于机械服从。优秀的模型应当能够发现需求中的错误和风险，但不能因此悄悄替用户更换目标。更合理的行为是先指出问题、给出替代方案，再把最终决定权留给用户。
速度决定人是否愿意频繁使用模型，指令遵循则决定人是否敢把真实工作交给它。
人机交互决定能力能否转化为体验
速度和指令遵循看似是模型属性，最终却都要通过人机交互才能产生价值。
传统软件通常具有相对确定的输入、状态和结果，用户点击按钮以后，大致知道系统会做什么。LLM 则不同：自然语言给予了用户很大的表达自由，也同时引入了歧义。用户不知道模型如何理解要求、保留了哪些上下文、准备采取什么步骤，更不知道它会在什么地方犯错。
聊天框让 AI 看起来像一种自然的对话对象，却隐藏了大量系统状态。当界面只提供一个输入框和一段最终回答时，用户不得不把目标、背景、约束、例外和输出格式全部压缩进提示词，然后期待模型正确理解。所谓“完美提示词”的执念，某种程度上正是交互界面把沟通责任全部推给用户的结果。
微软研究团队在 CHI 2019 论文 Guidelines for Human-AI Interaction中提出了 18 条人机交互准则，覆盖初次使用、正常交互、系统出错和长期使用等阶段。其核心启发是：AI 会犯错，也会随着上下文和数据改变行为，因此界面不能只展示结果，还要帮助用户建立正确预期、理解当前状态，并从错误中恢复。
放到 LLM 和 Agent 场景中，一套好的交互至少应该提供几种能力：
- 能力边界可见：告诉用户系统擅长什么、不能做什么，以及哪些结果需要额外验证。
- 执行状态可见：展示模型对目标的理解、当前计划、正在使用的工具和任务进度。
- 过程可以纠偏：允许用户补充约束、修改方向或中断任务，而不必等到最终结果生成以后重新开始。
- 操作可以撤销：对代码修改、文件编辑和外部操作提供预览、差异比较、检查点与回滚能力。
- 权限与风险匹配：低风险、可恢复的操作可以自动执行；发送消息、付款或删除数据等高风险操作应当明确确认。
- 结果能够验证：区分事实、推论和不确定内容，并提供引用、测试结果、操作记录或其他证据。
- 长期上下文可管理：让用户知道系统记住了什么，并允许查看、修改和删除不再适用的偏好与背景。
Todo List 面板就是一种典型的结构化展示。相比让模型在聊天中说“我准备先分析需求，然后修改代码，最后运行测试”，面板可以把任务拆成独立条目，并明确显示每项工作的状态、顺序、依赖关系和完成条件：
[x] Inspect the existing implementation
[>] Update the authentication flow
[ ] Add regression tests
[ ] Run lint and build用户可以立即看出模型当前在做什么、还有哪些步骤没有完成，也可以调整优先级、补充任务或者取消不再需要的步骤。对于长时间运行的 Agent，这种面板还承担了跨轮次保存任务状态的作用，避免计划只存在于某一轮对话里。
它展示的不是模型完整的内部推理，而是与协作有关的外部状态。任务、进度、阻塞项和验收条件需要让用户看见，模型如何在内部生成每一步判断则没有必要全部暴露。
不过，Todo List 只有与真实执行状态同步时才有价值。如果模型先生成一张漂亮的清单，执行过程中却不更新状态，或者未经验证就把任务标记为完成，它就只是一种制造确定感的装饰。有效的 Todo List 应该允许编辑和纠偏，并让“已完成”对应代码差异、测试结果或其他可检查的产物。
这里的重点不是让用户确认每一个步骤。过多确认会打断思路，也会让人逐渐习惯无条件点击同意。真正有效的人在回路，不是把所有责任变成弹窗，而是根据操作的影响范围、可逆性和不确定性决定何时需要人工介入。
指令遵循也不应完全依赖模型自己记住所有要求。界面可以把目标、约束和验收标准结构化展示，运行系统可以在多轮任务中持续保留它们，执行前可以用计划和预览暴露理解偏差。模型能力相同的情况下，这些交互设计足以带来完全不同的可靠性和信任感。
因此，人与 LLM 的交互不应该只有“输入提示词—获得答案”这一条路径。随着模型开始执行长时间、多步骤任务，人的角色也会从提问者变成目标定义者、过程监督者和最终验收者。交互设计的任务，就是让这种分工清晰、低摩擦且可控。
“许愿式交互”为什么容易失败
很多人与 LLM 的交互仍然像在许愿：给出一句模糊目标，然后期待模型一次性还原所有隐含意图，直接交付正确的最终结果。
例如，“帮我做一个好看的个人网站”看似表达了目标，实际上没有说明受众、内容、风格、技术栈、完成范围和验收标准。模型只能自行填补这些空白。它可能生成一个视觉完整的网站，但这份结果很可能只是符合模型对“好看”的理解，而不是用户真正想要的东西。
许愿式交互的问题往往不在于提示词不够长或者不够华丽，而在于问题尚未完成建模。目标、背景、约束和判断标准都没有被表达出来，却希望模型替自己一次性做完所有隐含决策。
在简单、低风险的任务中，一次性生成完全没有问题。但任务越复杂、代价越高，用户就越不应该依赖模型猜测。
把模型当作反馈系统
更有效的方式，是把模型当作反馈系统，而不是答案机器：
- 澄清问题：先确认真正要解决的问题，而不是急着生成结果。
- 暴露假设：明确已有判断、限制条件和不确定之处。
- 拆分任务：先完成一个可检查的小步骤，而不是一次交付全部内容。
- 主动质疑：要求模型提出反例、风险和替代解释。
- 验证产物：用测试、数据、引用或实际运行结果检查结论。
- 迭代理解：根据反馈修改自己的问题模型，再进入下一轮。
这个过程不是为了把简单任务故意变复杂，而是让交互拥有可以纠正的中间状态。模型第一次理解错了并不可怕，可怕的是直到最终结果交付时，双方才发现对目标的理解从一开始就不同。
快速反馈也因此变得重要。它让用户能够用更低的成本发现偏差、修改方向，而不必在开头写出一份试图覆盖所有情况的“完美提示词”。
学习不是被动接受答案
以学习的心态使用 LLM，也不只是向它获取更多知识。更重要的是借助模型更快地建立和修正自己对问题的理解。
如果只是被动接受一段流畅的解释，人很容易产生“我已经懂了”的错觉。模型的语言越自然，这种错觉反而越隐蔽。真正的学习至少应该让使用者能够：
- 用自己的语言复述关键逻辑
- 区分事实、假设和推论
- 识别结论成立的条件和边界
- 为一个观点提出反例
- 通过数据、实验或其他资料进行验证
- 在没有模型代劳时保留基本判断能力
因此，与其只问“答案是什么”，不如继续追问：这个结论依赖哪些假设？最可能错在哪里？有没有相反证据？如果条件改变，结论是否仍然成立？
这些问题不会让模型自动变得正确，却能让使用者更早发现模型和自己共同忽略的部分。
真正稀缺的是问题建模能力
AI 时代的重要能力不只是“会写提示词”。提示词只是人与模型之间的界面，底层能力是把模糊愿望转化为目标、约束、步骤、反馈和验收标准。
当模型智能逐渐商品化，真正稀缺的不只是更强的模型，而是更短的反馈回路、更可靠的执行系统，以及使用者提出可验证问题的能力。
模型负责生成与推理，外部系统负责约束和验证，人则负责定义目标、判断取舍，并在持续反馈中修正自己的理解。人与模型最有效的关系，不是许愿者和答案机器，而是两个共同建立问题模型、不断纠正偏差的协作者。
参考资料
- Saleema Amershi et al., Guidelines for Human-AI Interaction, CHI 2019
- Microsoft, Guidelines for Human-AI Interaction — HAX Toolkit