title: "Fable 5 的正确用法：从聊天机器人变成自主执行者" tags:

Fable 5 的正确用法：从聊天机器人变成自主执行者

先说结论：Fable 5 不应该只被当成聊天机器人使用。

你要是还按“问一句、答一句”的方式用它，等于买了台越野车，天天只在小区里挪车位。它当然可以回答问题、改几句话、写一段文案，但这些都没有发挥它真正适合的工作方式。

更适合 Fable 5 的用法是：把一个有明确目标的任务交出去，让它自己读取资料、执行步骤、检查结果，遇到真正需要你决定的事情时再回来找你。

本文不讨论某个具体行业，也不要求读者会写代码。我们只解决一个问题：怎样把“聊天请求”改造成一份可以由 Agent 自主执行的任务。

一、先把它放回正确的位置

传统聊天模型的工作方式很简单：你发一条消息，它生成一段回复，然后等待下一条消息。这个模式适合查资料、问概念、润色句子和快速头脑风暴。

自主任务的工作方式则完全不同：你先给出目标、背景、限制和完成标准，模型再自己决定中间需要做哪些步骤。它可能需要阅读多个文件、搜索资料、运行命令、反复修改和再次检查。

两种方式没有谁绝对更好。区别在于任务是否需要连续推进：

任务类型 更适合的方式 例子
一次性回答 普通对话 解释一个概念、改一句话
多步整理 任务模式 把一批会议纪要整理成项目计划
需要反复检查 Agent 工作流 检查项目、修复构建、验证部署
长时间持续执行 循环工作流 定期汇总信息、持续跟踪一个项目

Fable 5 的优势如果要转化成实际收益，关键不是让它回答得更长，而是减少你在中间步骤里充当“人工遥控器”的次数。

二、它适合哪些长任务

长任务不是“字数很多的任务”，而是有多个连续步骤、需要在过程中做判断的任务。

1. 资料研究

让它研究一个行业，不应该只说“帮我写一篇行业分析”。更清楚的任务是：

请研究个人知识库产品的市场现状。

目标读者是没有技术背景的个人创作者。
请完成：
1. 找出 10 个有代表性的产品；
2. 记录核心功能、价格、部署方式和目标用户；
3. 优先使用官方文档和第一方资料；
4. 把事实、推断和作者判断分开；
5. 为价格、版本和能力结论标注信息日期；
6. 最后分别给个人用户、团队用户和开发者用户提出选择建议。

不要为了凑数量编造产品或数据。
无法确认的信息列入“待验证”，不要猜测。
输出一份可以继续编辑的 Markdown 报告。

这类任务的价值，不是它能保证一次写出最终答案，而是它可以完成资料收集、归类、初步比较和引用整理。你最后仍然需要判断来源是否可靠，尤其是价格、发布日期、性能和兼容性等会变化的信息。

2. 项目体检

一个已经做了一段时间的项目，往往比从零开始更难处理。里面可能有重复组件、临时脚本、旧配置、没有文档的环境变量和不知道能不能删除的目录。

可以先让 Fable 5 只读检查：

请检查当前项目，但第一轮不要修改任何文件。

请输出：
1. 项目如何安装、启动和构建；
2. 前端、后端和数据层分别在哪里；
3. 核心入口文件和关键依赖；
4. 当前可能影响上线的风险；
5. 没有测试覆盖的关键功能；
6. 可能包含敏感信息的配置；
7. 建议的处理优先级。

每个结论都引用具体文件路径。
无法确认的内容标记为“待确认”。
检查阶段不要重构、删除或安装任何东西。

先让它当观察者，再决定是否让它动手，成功率通常更高。它如果还没有理解项目结构，就直接开始重构，后面的每一步都会建立在猜测上。

3. 把模糊想法变成可执行方案

“我想做一个文章管理工具”是一个方向，不是一项开发任务。可以先让它帮助你把方向变成方案：

我想做一个个人文章管理工具，目前只有一个模糊想法。

请先不要写代码：
1. 只询问完成产品定义所必需的问题；
2. 每次只问一个问题；
3. 判断第一版最小可用范围；
4. 列出现在不应该加入的功能；
5. 设计页面、数据和最小开发顺序；
6. 最后生成一份可以交给编码 Agent 执行的任务书。

如果有多个合理方向，请列出差异，不要替我假设唯一答案。

好的 Agent 工作流不应该用一大串问题把人问懵，而是每问一个问题，都让产品更接近可以验证的状态。

三、任务书比提示词更重要

很多人说自己不会写提示词，其实他们缺的不是技巧，而是没有把任务想清楚。

一份合格的任务书至少包括五部分：

目标

最后要得到什么文件、页面、报告或结果？

背景

它需要知道哪些业务、项目和历史决策？

限制

哪些文件不能动，哪些数据不能访问，哪些技术不能引入？

验收标准

什么状态才算完成？用“看起来不错”作为标准，模型就无法自行判断是否应该停下。

汇报方式

哪些事情可以自己做，哪些事情必须暂停找你？最终要输出修改清单、风险清单还是测试结果？

比如，“帮我优化博客”太模糊；“不改变 URL 和文章内容，检查移动端布局，修改后运行构建并输出验证结果”就已经是一项可以执行的任务。

四、让它自己推进，但保留人工关卡

自主执行不等于完全放任。建议把一个大任务分成四个阶段：

  1. 观察：读取文件、资料和现状，不修改。
  2. 计划：列出方案、风险、文件和验证方式。
  3. 执行：按计划完成修改或操作。
  4. 验收：运行测试、检查输出并整理未解决问题。

观察阶段和计划阶段通常可以放心交给它。执行阶段需要根据风险设置权限。验收阶段则要要求它提供证据，而不是只说“已经完成”。

下面这段话可以作为通用的执行约束：

请按“观察、计划、执行、验收”四个阶段工作。
观察和计划阶段不要修改文件。
执行阶段每完成一个独立步骤，说明修改了什么以及如何验证。
遇到删除数据、修改账号权限、使用密钥、产生费用或发布到公网时暂停并等待确认。
验收阶段输出通过项、失败项、证据命令和剩余风险，不要把未验证内容写成已完成。

这比“你自己想办法搞定”更适合长任务。真正省心的前提，是把应该停下来的地方提前写出来。

五、视觉能力不要浪费

如果任务里有截图、表格、界面或图表，不要只把它们当成附件丢过去，再用文字描述一遍。

视觉输入比较适合这些场景：

不过，看到图不代表理解一定正确。密集图表、小字号文字、压缩截图和遮挡区域都可能导致误判。涉及具体数字时，应让它先列出识别结果，再回到原始 PDF、表格或页面核对。

网上经常流传一些“只靠看画面就完成复杂游戏”之类的案例。没有官方文档或可复现记录时，这类说法只能当作用户分享，不能直接写成模型已经稳定具备的能力。某些入口对图片尺寸、格式和数量也可能有自己的限制，使用前应以当前产品文档为准。

一个完整任务是怎样交出去的

以“把一批访谈记录整理成产品需求”为例。普通聊天方式通常是先上传一份记录，让模型总结；看完以后再补充要求；发现遗漏后再重新解释。文件一多，人的注意力就会被大量中间沟通消耗掉。

更适合 Agent 的交付方式是把完整上下文一次交代清楚：

当前目录的 interviews/ 中有 18 份访谈记录，目标是整理出产品需求初稿。

请按以下阶段执行：
1. 先读取文件名和文档结构，统计每份记录的日期、角色和长度；
2. 提取用户原话，不要把你的推断伪装成原话；
3. 将反馈按问题、场景、频率和影响程度归类；
4. 合并语义重复的问题，但保留不同用户的差异；
5. 为每个需求写出背景、目标用户、验收条件和证据来源；
6. 将无法判断优先级的内容列入待确认清单。

输出：
- research-summary.md：访谈摘要；
- product-requirements.md：需求初稿；
- open-questions.md：需要人工决定的问题。

限制：不要修改原始访谈文件，不要凭空补充用户没有说过的需求，不要自动创建任务或发送消息。
完成前检查文件数量、引用位置和重复需求。

这里最重要的不是提示词写得多，而是把原始资料、产出文件、禁止事项和验收方式一次说清楚。Agent 可以自行决定中间需要建立哪些临时表格，但最终交付物必须固定。

如何判断它真的完成了

长任务最容易出现“看起来完成”的假完成。它可能生成了三个文件，但文件内容互相矛盾；也可能说已经检查过，实际上只读了其中一部分。

所以最终汇报要包含证据：

请提交最终验收报告，包含：
1. 实际读取了哪些文件；
2. 新增、修改和未修改的文件；
3. 每个交付物解决了什么问题；
4. 执行过哪些检查和命令；
5. 哪些检查通过，哪些失败；
6. 哪些结论仍然需要人工确认；
7. 如果继续推进，下一步是什么。

如果任务涉及代码，还要补充构建和测试输出；如果任务涉及研究，要补充来源和日期；如果任务涉及设计，要补充截图或具体页面；如果任务涉及数据，要说明数据范围和缺失情况。

“我已经完成”只是状态描述，不是验收证据。

普通人最容易踩的四个坑

坑一：目标太大

“帮我经营账号”“帮我把公司数字化”“帮我做一个完整产品”都不是一轮任务可以稳定完成的目标。先拆成一个能在今天验收的结果，例如“整理过去 30 天的内容表现，输出三个可验证的选题假设”。

坑二：背景放在脑子里

你知道客户是谁、为什么不能改某个页面，但 Agent 不知道。没有写出来的背景，不能指望它每次都猜对。把关键背景写进项目文件或任务书里，比在中途不断补充更可靠。

坑三：没有写禁止事项

没有限制时，Agent 可能为了完成目标引入新依赖、修改公共接口、覆盖旧文件或扩大任务范围。把“不能做什么”写出来，和写“要做什么”同样重要。

坑四：只看最终产物

最终结果漂亮，不代表过程正确。尤其是研究、代码和数据任务，必须检查来源、修改记录和验证输出。必要时让它保留中间产物，方便抽查。

从聊天到工作流的升级路径

可以把使用方式分成四个阶段：

  1. 对话：让模型帮你解决眼前的问题。
  2. 任务书：把目标、背景和标准写清楚。
  3. Skill：把反复使用的方法保存下来。
  4. 循环：让 Agent 在明确边界内持续推进。

不要跳过前面的阶段。连一次性任务都没有稳定验收标准时，直接开启长时间自主执行，通常只会放大混乱。

结论

Fable 5 的基础用法，不是让它把一句话回答得更漂亮，而是把一个目标交给它，让它自己完成中间过程。

目标越清楚，背景越完整，边界越明确，验收标准越具体，它就越有机会从“聊天对象”变成“执行者”。但自主执行始终需要人工关卡：涉及数据、权限、密钥、费用和公网发布时，必须保留确认权。

下一步可以把稳定重复的做法沉淀成 Skill，再用循环工作流让它长期执行。这样才会从一次性的对话，逐渐形成可以复用的个人工作系统。

参考资料