Fable 5 的编程与 Agent 能力怎么用？

先说结论：它强在哪？

强在能处理「需要读完一堆现有代码再动手」的任务。单文件的小函数谁都能写，难度在于改动要符合项目既有的结构、命名和依赖关系。

另一个被强调的能力是自我验证：改动之后能运行检查、根据报错回退或修正，而不是把带错误的结果直接交给你。

典型的编程使用场景

下面这几类是它相对更能发挥价值的地方。

1. 1仓库级理解：先读懂项目结构与约定，再动手改。
2. 2跨文件改动：重构、重命名、替换依赖等牵涉多处的修改。
3. 3补测试与修回归：定位失败用例并给出修复方案。
4. 4长任务自动化：把重复的维护工作交代一次后连续执行。

怎么把它接进工作流？

关键是把「约束」和「验收标准」一起交代清楚，而不是只描述需求。

1. 1先让它读项目结构和相关文件，输出一份改动计划再动手。
2. 2明确边界：哪些文件不能改、哪些接口必须保持兼容。
3. 3要求它自己运行测试或类型检查，并把结果贴出来。
4. 4让它分开列出「已验证」和「未验证」的部分。
5. 5改动较大时要求提供回退方案，而不是只给最终结果。

和人工评审怎么配合？

自动化改动越多，评审的重点就越应该从「代码写得好不好」转向「改动范围对不对」。先看它动了哪些文件、有没有超出你划定的边界，再看实现细节。

要求它把改动拆成可独立验证的小块，每一块都能单独回退。这样即使某一步方向错了，也不会污染整个分支。

最后一定要看它标注为「未验证」的部分。这些地方通常是它自己也不确定的地方，恰恰最容易出问题。

注意边界

它不会自动知道你们的业务规则和线上约定，这些必须由你显式说明；默认它会按通用最佳实践处理，未必符合你们团队的习惯。

另外，涉及生产环境、密钥和真实数据的操作，不要交给自动化流程直接执行。把范围限制在代码与测试环境里更安全。

常见的代码任务可以怎么拆？

第一类是理解型任务：让它先读某个模块，回答数据怎么流转、某个副作用从哪来、改动会影响哪些调用方。这类任务不产出代码，但能显著缩短你熟悉陌生仓库的时间，也最适合放在动手改之前先做一步。

第二类是改动型任务：加接口、补参数校验、修边界条件、迁移旧写法。交给它时最好一次只给一个明确目标，并说明必须保持不变的对外行为。第三类是验证型任务：补测试、复现报错、解释失败原因。把它当队友而不是许愿池，先给上下文和验收标准，产出质量会稳定很多。

把它接进工作流的几种常见方式

最轻的接法是问答式：自己把代码片段粘进去提问，产出的补丁再手动贴回编辑器，适合改动小、节奏快的场景。

再进一步是在 IDE 里用插件，让模型直接读当前文件和相邻依赖，改动可以一键应用，效率最高，但要注意别让它在你没看清的情况下批量改写文件。

更重的方式是交给命令行或持续集成：把任务写成脚本，让模型在独立分支上改代码、跑测试，产出的差异再走评审流程。三种方式的共同点是，最终合并到主干的动作都应该由人来确认。