文章

Agent 启发面:让用户知道如何使用 AI

把原先的 AI 认知代偿收敛为 Plato 的启发面:帮助用户发现 AI 能做什么、如何描述任务、如何生成任务包,并把成功经验沉淀为 Playbook。

2026/06/08 更新于 2026/06/08
  • Agent
  • 产品设计
  • AI 产品
  • Plato

AI Agent 产品有一个很容易被低估的问题:

用户并不知道如何使用 AI,也不知道 AI 在当前场景下能做哪些事。

这不是用户懒。

也不是用户不愿意学习。

而是因为 AI 的能力边界太宽,任务表达方式太开放,用户很难在空白输入框前稳定形成一个高质量任务。

过去我把这个问题叫做“AI 认知代偿”。

现在在 Plato 的产品架构里,我更愿意把它收敛成一个更清晰的概念:

启发面。

启发面要解决的不是执行问题,而是使用问题。

它帮助用户理解:

  • AI 在这个场景下可能做什么;
  • 用户应该提供哪些上下文;
  • 模糊目标如何变成可执行任务;
  • 一个任务应该如何拆解;
  • 如何判断 AI 输出是否足够好;
  • 成功经验如何沉淀为下一次可复用的工作方式。

在 Plato 里,Agent 产品至少有三个平面。

启发面
  帮助用户发现能力、澄清任务、生成任务包

控制面
  把任务变成可执行、可约束、可验证的流程

信任面
  让执行过程可见、可审计、可恢复、可解释

这篇文章聚焦启发面。

为什么需要启发面

很多 AI 产品默认用户知道自己要什么。

于是界面给用户一个输入框:

Ask AI anything...

这个设计看起来极简,但它把最困难的事情留给了用户。

用户需要自己判断:

  • AI 能不能做这件事;
  • 这件事应该怎么描述;
  • 需要提供哪些文件和背景;
  • 任务范围应该多大;
  • 验收标准是什么;
  • 是否应该让 AI 先调研、先计划、先写代码、先 review,还是直接执行;
  • 如果失败了,应该如何调整。

对经验丰富的 AI power user 来说,这些动作可能已经内化成习惯。

但对普通用户来说,这就是门槛。

用户用不好 AI,不一定是因为模型不够强,而是因为他们不知道如何把自己的意图转化为 AI 可以稳定执行的任务结构。

这就是启发面要补上的缺口。

空白输入框不是好入口

自然语言输入框很强,因为它开放。

但也正因为开放,它不适合承担所有产品入口。

空白输入框要求用户同时完成四件事:

  • 想象 AI 能力;
  • 组织任务上下文;
  • 表达目标边界;
  • 设计验收标准。

这对大多数用户太重了。

尤其在 Agent 场景里,任务质量会极大影响输出质量。

同样是让 Codex 或 Claude Code 改一个功能,下面两种输入会得到完全不同的结果。

低质量输入:

帮我优化一下这个项目。

高质量任务包:

目标:降低文章详情页的阅读负担。

当前问题:
- 长文缺少章节导航;
- 读者不知道文章结构;
- 回到上一节成本高。

约束:
- 不改变现有内容集合 schema;
- 保持移动端可读;
- 不引入新的 UI 框架。

建议步骤:
1. 阅读文章详情页组件。
2. 使用 Astro render headings 生成目录。
3. 桌面端显示左侧 sticky TOC。
4. 移动端隐藏 TOC。
5. 构建验证。

完成标准:
- npm run format:check 通过;
- npm run build 通过;
- 新文章页面目录链接可跳转。

用户真正需要的,不是“更大的输入框”。

而是系统帮助他们从模糊意图走到高质量任务包。

启发面不是 Prompt 美化

启发面容易被误解成 Prompt enhancer。

但它不是把一句话改得更华丽。

Prompt 美化通常解决的是:

这句话怎么写得更像提示词?

启发面解决的是:

这个目标应该如何被 AI 理解、拆解、执行、验证和沉淀?

二者差别很大。

启发面需要做的事情包括:

  • 判断用户目标是否过宽;
  • 识别缺失上下文;
  • 提醒用户补充文件、限制和标准;
  • 推荐合适的执行策略;
  • 暴露当前场景下 AI 可以做的能力;
  • 生成可交给 Agent 的任务包;
  • 在任务完成后沉淀 Playbook;
  • 在任务失败后做失败复盘。

所以启发面不是“帮用户写 prompt”。

它是“帮助用户组织 AI 工作”。

三个平面的分工

启发面必须和控制面、信任面分开。

如果不分开,产品很容易变成一个混乱的大 Agent 平台。

启发面

启发面解决:

用户不知道如何使用 AI,也不知道 AI 能做哪些事。

它负责:

  • 场景识别;
  • 能力发现;
  • 任务质量诊断;
  • 上下文补齐建议;
  • 任务包生成;
  • Playbook 推荐;
  • 失败后的策略建议。

它的用户体验应该是启发式的。

不是命令用户,而是帮助用户形成更好的任务。

控制面

控制面解决:

Agent 如何把任务变成可执行、可约束、可验证的流程。

它负责:

  • task state;
  • plan;
  • checkpoint;
  • permission;
  • workflow;
  • skill;
  • tool boundary;
  • validation gate;
  • fallback path。

控制面更像 Agent 的操作系统。

它不需要每个细节都暴露给用户,但必须让执行过程有结构。

信任面

信任面解决:

用户为什么敢把任务交给 Agent?

它负责:

  • 执行过程可见;
  • 关键操作可确认;
  • 工具调用可追踪;
  • 结果可验证;
  • 错误可恢复;
  • 决策可解释;
  • 历史可审计;
  • 风险可暴露。

信任面不是“做一个漂亮日志”。

它是让用户能理解、控制和接受 Agent 行为。

这三个平面可以画成:

User intent

启发面
  discover capability, improve task, generate task package

控制面
  plan, execute, validate, checkpoint

信任面
  observe, explain, approve, recover, audit

User confidence

启发面要做的五件事

我认为启发面至少包含五个产品机制。

1. Task Quality Diagnosis

用户输入任务后,系统不要急着执行。

它应该先判断任务质量。

例如:

  • 目标是否明确;
  • 范围是否过宽;
  • 上下文是否缺失;
  • 是否需要引用文件;
  • 是否需要先调研;
  • 是否有验收标准;
  • 是否涉及高风险修改;
  • 是否应该拆成多个阶段。

输出不应该是冷冰冰的评分,而应该是可操作的改进建议。

这个任务目前可以执行,但成功率不高。

主要缺口:
- 没有说明目标用户;
- 没有说明不希望改动的范围;
- 没有验收标准。

建议补充:
- 这个功能服务谁;
- 哪些文件不能改;
- 完成后如何判断有效。

这不是阻止用户。

而是帮用户把任务从“模糊愿望”变成“可执行请求”。

2. Capability Radar

用户经常不知道 AI 能做什么。

能力发现不应该只发生在文档里,而应该发生在用户当前场景里。

例如用户上传一份 PRD,系统可以提示:

基于这份 PRD,我可以帮你:

- 提炼核心用户问题;
- 生成用户故事;
- 拆分开发任务;
- 识别需求矛盾;
- 生成验收标准;
- 生成测试用例;
- 转成 Codex 任务包;
- 生成面试展示版项目说明。

用户正在处理 bug,系统可以提示:

我可以帮你:

- 整理复现步骤;
- 定位相关文件;
- 生成排查计划;
- 创建最小复现;
- 编写回归测试;
- 生成给 Codex 的修复任务包。

这就是 Capability Radar。

它不只是展示功能列表,而是根据上下文告诉用户:

在你现在这个场景里,AI 还能怎么帮你。

3. Task Package Generator

自然语言输入只是原材料。

启发面应该把它编译成可执行任务包。

一个 Task Package 至少包含:

goal: 用户真正要达成的目标
context: 当前相关文件、文档、背景和约束
scope: 本轮允许处理的范围
non_goals: 明确不做什么
steps: 建议执行阶段
permissions: 是否需要用户确认
validation: 完成标准和验证方式
risks: 可能失败或偏航的地方
handoff: 交给哪个 Agent / Skill / 工具执行

Task Package 的价值在于:

  • 用户不必学会写复杂 prompt;
  • Agent 接到的是结构化任务;
  • 控制面可以据此生成计划和检查点;
  • 信任面可以据此解释执行是否偏离。

这和我在 Task Context 文章里的观点是一致的:

Prompt 只是渲染结果。

任务结构才是稳定资产。

4. AI Playbook

每次成功完成任务后,系统不应该只保存聊天记录。

它应该把成功经验沉淀成 Playbook。

Playbook 不是普通模板。

它应该包含:

  • 适用场景;
  • 输入要求;
  • 推荐任务包结构;
  • 执行步骤;
  • 可用 Skill;
  • 工具调用策略;
  • 验证方式;
  • 常见失败;
  • 输出模板;
  • 复用条件。

例如:

Playbook: 从 PRD 生成 Codex 开发任务

适用场景:
  已有产品需求文档,但还没有开发任务拆解。

输入:
  PRD、目标用户、技术边界、优先级。

输出:
  issue list、验收标准、测试建议、Codex task package。

验证:
  每个 issue 都有明确完成标准和非目标。

这会让用户的 AI 使用经验越用越强,而不是每次从零开始。

5. Failure Retrospector

Agent 失败后,很多产品只会告诉用户:

执行失败。

这不够。

启发面应该帮助用户理解失败原因,并把失败转化成下一次更好的任务策略。

失败可能来自:

  • 用户目标过宽;
  • 上下文不足;
  • 权限不够;
  • Skill 选择错误;
  • 验证标准缺失;
  • 工具不可用;
  • Agent 误解了项目结构;
  • 任务被拆得太大;
  • 结果没有被真实验证。

Failure Retrospector 应该输出:

这次失败主要不是执行能力问题,而是任务包缺少验收标准。

下次建议:
- 在任务开始前声明 expected behavior;
- 提供失败前后的截图或日志;
- 要求 Agent 先写测试再改代码;
- 使用 bug-fix playbook;
- 在修改前请求用户确认影响范围。

这样失败也能沉淀成资产。

为什么这不是万能 Agent 平台

一个常见误区是:

既然 Agent 很强,那就做一个能编排所有 Agent 的平台。

但我现在更谨慎。

平台能力当然重要,但一开始做万能编排平台,容易把复杂度直接暴露给用户。

用户通常不关心:

  • 有几个 Agent;
  • prompt 是怎么分层的;
  • workflow graph 有多少节点;
  • skill 怎么配置;
  • tool schema 怎么定义;
  • memory 怎么召回。

用户关心的是:

我的事情能不能更稳定地做好?

所以启发面应该优先从具体场景切入,而不是先做抽象平台。

开发者场景是一个合理入口。

因为开发者能明显感受到任务质量、上下文、测试、PR、代码规范和工具链对 Agent 成败的影响。

例如:

  • 需求 → 技术方案 → Codex 任务包;
  • Bug 描述 → 排查计划 → 复现步骤 → 回归测试;
  • PRD → 开发任务拆解 → issue list → 测试计划;
  • 旧项目 → 架构理解 → AGENTS.md 建议 → 常用 Playbook;
  • 失败的 Agent 执行记录 → 失败复盘 → 下一次自动修正。

先在一个高频场景里证明:

同样的 Codex / Claude Code,经过启发面组织后,任务成功率明显提高。

这比“支持所有 Agent 编排”更有产品说服力。

启发面的指标

如果产品定位是启发面,指标不应该只看调用量。

更重要的是它是否降低了用户的认知负担,并提高任务成功率。

可以关注:

  • 模糊任务到可执行任务包的转化率;
  • 用户接受系统建议的比例;
  • 任务首次成功率;
  • 任务返工次数;
  • 失败原因中“上下文不足”的比例;
  • Playbook 复用率;
  • 用户从空白输入到提交任务的时间;
  • 用户是否能发现原本不知道的 AI 能力;
  • 用户是否愿意把系统建议作为团队流程复用。

这些指标比“生成了多少 prompt”更接近产品价值。

因为启发面真正卖的不是 prompt 数量。

而是:

让用户更容易把模糊意图变成高质量 AI 工作。

风险和取舍

启发面也有风险。

第一,概念容易过于抽象。

如果不能落到具体场景,它会变成泛泛的 AI 助手。

第二,用户可能不喜欢被教育。

产品不能让用户感觉“你不会用 AI”。更好的体验是:系统直接帮用户省事,而不是居高临下地纠正用户。

第三,底层 Agent 也会补齐启发能力。

Codex、Claude Code、ChatGPT 这类工具会不断增强任务建议、上下文理解和使用引导。独立产品必须有跨工具、团队资产和场景深度的价值。

第四,只生成 prompt 不够。

如果启发面不能观察执行结果、复盘失败、沉淀 Playbook,就会停留在 prompt enhancer。

第五,场景不能过宽。

早期不要做“让所有人更会用 AI”的产品。

应该先选一个高频、可验证、有明显任务成功率差异的场景。

对 Plato 的定位意义

这篇文章对 Plato 很关键。

它把 Plato 从“Agent 编排平台”拉回到更清楚的产品目标:

帮助用户把模糊产品工作转化为可执行、可验证、可复用的 AI 协作流程。

Plato 不应该只做底层执行层。

它需要三个平面配合。

启发面
  让用户知道 AI 能做什么,以及如何把目标表达成任务包

控制面
  让任务可以被计划、执行、验证、检查点化

信任面
  让用户看见过程、理解风险、确认关键动作、恢复失败

这三个平面对应三类产品问题:

平面用户问题产品能力
启发面我不知道 AI 能帮我做什么,也不知道怎么提任务能力发现、任务诊断、任务包、Playbook
控制面我不知道 Agent 会怎么执行,也怕它乱跑workflow、permission、checkpoint、verifier
信任面我不知道它为什么这么做,也不知道能不能信trace、audit、explain、review、rollback

对 Agent 产品来说,这比“多 Agent 编排”更接近真实用户价值。

用户不是为了配置 Agent 而来。

用户是为了把事情做好而来。

结论

启发面要解决的问题很明确:

用户不知道如何使用 AI,也不知道 AI 能做哪些事。

它不是 prompt 美化,也不是普通模板库。

它是从用户模糊意图到高质量 AI 工作之间的产品层。

它帮助用户:

  • 发现 AI 能力;
  • 澄清任务目标;
  • 补齐上下文;
  • 生成任务包;
  • 选择 Skill 和 Playbook;
  • 复盘失败;
  • 沉淀成功经验。

如果说控制面让 Agent 能执行,信任面让用户敢交付,那么启发面解决的是更靠前的问题:

用户如何开始一段正确的 AI 协作?

这可能是 Agent 产品真正的入口。