Fable 5 和 Claude Code 是什么关系？怎么配合用？

先说结论：两层东西别混

模型是能力来源，决定它写得对不对、能不能读懂你的代码库。命令行工具是使用方式，决定它能不能直接读文件、跑测试、把改动写回项目。

所以「效果不好」可能出在两层里任意一层：模型选错了，或者工具没给它足够的上下文。排查时先分清是哪一层的问题。

什么时候用命令行工具、什么时候用网页版

需要在既有项目里跨文件改动、跑测试、连续执行多步任务时，命令行方式更合适，因为它能直接读写文件并保留执行结果。

只是问一段逻辑、解释一个报错、写一个独立函数时，网页版更快，也不需要在本地配置任何东西。

还有一类任务适合放在中间：改动范围明确、但需要参照项目约定。这类可以先把相关文件贴进网页版讨论方案，再交给命令行执行。

接入要点

搭起来之前，把这几件事确认清楚可以省下大量返工。

1. 1确认使用的模型标识与实际可用的额度，避免中途因为额度不足中断。
2. 2密钥放进环境变量或密钥管理服务，不要写进代码仓库。
3. 3限定工作目录范围，明确哪些文件不允许修改。
4. 4让它先输出改动计划再动手，避免一上来就大范围改写。
5. 5要求它运行测试或类型检查，并区分「已验证」与「未验证」的部分。

一个典型的工作流

以一个中小型改动为例，比较顺的顺序是这样的。

1. 1先用一句话说明目标和不能破坏的行为。
2. 2让它读相关目录与依赖，产出改动清单和影响面。
3. 3确认清单后再让它动手，一次只推进一个明确目标。
4. 4跑测试与类型检查，让它自己修复失败项。
5. 5最后人工评审改动范围，确认没有越过边界再合并。

成本和额度怎么控制

仓库级任务的消耗主要来自上下文：读的文件越多、任务链越长，单次花费越高。控制成本最有效的办法是缩小范围，而不是减少验证。

可以先把任务拆成若干独立小步，每一步都能单独确认，避免一个长任务跑偏之后整段重来。长任务中途失败的代价通常比多跑几步高得多。

注意边界

不要让自动化流程直接操作生产环境、真实用户数据或支付相关配置。把执行范围限制在代码与测试环境，风险是可控的。

另外，团队约定、业务规则这些不会自动进入上下文，需要你在指令里写清楚，否则它只能按通用做法处理。

和人工评审怎么分工

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

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

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

如果改动涉及对外接口或数据结构，建议在合并前补一条最小回归用例，把这次确认过的行为固定下来，避免后续改动无意中推翻它。