1. 为什么我会盯上这个组合先说结论这套组合是我在过去几个月里试了不下十种模型搭配之后留在主力工作流里没换掉的一套。核心原因就一个——在真实项目里它俩的分工刚好互补而且成本压得住。我平时的工作状态大概是这样手头同时开着两三个项目有需要快速出原型的有需要啃老代码的也有需要写大量重复性业务逻辑的。以前我的做法是全程用一个大而全的模型结果就是要么贵得肉疼要么在长上下文里开始胡言乱语。后来我把任务拆开让不同的模型干不同的活效率反而上来了。Claude Fable 5在我这里承担的是深度思考者的角色。它的强项在于理解复杂需求、拆解模糊问题、在长对话里保持逻辑一致性。我经常把一段几百行的遗留代码丢给它让它先给我讲清楚这段代码到底在干什么然后再提改造方案。它给出的分析往往能抓住那些我自己扫一遍容易忽略的边界条件。DeepSeek v4-flash则是快速执行者。它的响应速度非常快价格也友好适合处理那些模式固定、不需要太多推理的活——比如批量生成单元测试骨架、把一种数据格式转成另一种、写一些模板化的CRUD代码。这些活如果全交给贵模型纯属浪费。所以这套组合的本质是用贵的模型做决策和攻坚用便宜的模型做执行和铺量。听起来简单但实际落地时有不少细节要注意下面我一点点拆开讲。2. 两个模型的能力边界到底在哪2.1 Claude Fable 5 的强项与软肋我用了大概两个月时间把 Fable 5 放在各种场景里压测总结下来它的能力分布是这样的强项方面第一是长上下文里的逻辑追踪。我试过给它一个包含十几个文件的模块让它追踪一个请求从入口到数据库的完整链路它能准确指出中间经过了哪些转换、哪些地方可能丢数据。这种活换别的模型经常讲到一半就开始编。第二是模糊需求的澄清能力。你给它一个很粗糙的需求比如帮我做一个能自动整理下载文件夹的工具它不会上来就写代码而是会先问你几个关键问题按什么规则分类要不要处理重名要不要保留原始文件这种先确认再动手的习惯在真实项目里能省掉大量返工。第三是代码审查的深度。我让它 review 过一段并发处理的代码它不光指出了竞态条件还给出了三种不同复杂度的修复方案并说明了各自的取舍。这种层次感是很多模型做不到的。软肋也很明显。首先是速度在生成长代码时它的输出节奏明显偏慢如果你赶时间等它写完一个几百行的文件会有点煎熬。其次是成本虽然比某些顶级模型便宜但如果你拿它去干批量生成的活账单会很难看。最后是对某些新兴框架的细节掌握它偶尔会给出过时的 API 用法需要你自己核对文档。2.2 DeepSeek v4-flash 的定位DeepSeek v4-flash 的定位非常清晰快、便宜、够用。我实测下来它的首 token 延迟非常低生成速度也快特别适合那种我知道要什么你帮我写出来就行的场景。比如我有一批数据清洗脚本要写逻辑都差不多只是字段名和转换规则不同这种活交给它几分钟就能出一批而且质量稳定。它的代码补全和模板生成能力也让我满意。我经常用它来生成一些重复性的业务代码比如根据数据库表结构生成对应的实体类和基础 CRUD 方法。它对这些模式化的东西掌握得很好基本不需要怎么改。但它的边界也很清楚。当你给它一个需要多步推理的问题时它容易给出表面正确但实际有坑的答案。比如你问它这段代码在高并发下会有什么问题它可能会说没有明显问题而实际上存在资源竞争。所以我的原则是flash 负责写Fable 负责审。还有一个细节flash 在长上下文的一致性上不如 Fable 5。如果你给它一个很长的对话历史它有时会忘记前面约定好的约束条件。所以我在用 flash 时习惯把关键约束在每次提问时重复一遍或者干脆开新对话。2.3 一张表看清分工维度Claude Fable 5DeepSeek v4-flash响应速度中等偏慢快成本较高低长上下文逻辑追踪强一般模糊需求澄清强弱代码审查深度强一般模板化代码生成一般强批量任务处理不划算很划算新兴框架细节偶尔过时偶尔过时这张表是我自己用出来的体感不是官方参数。你在实际用的时候可以根据自己的项目特点调整。3. 我的实际工作流是怎么跑的3.1 需求拆解阶段让 Fable 5 先想清楚每次接到一个新需求我的第一步不是直接写代码而是把需求原文丢给 Fable 5让它帮我做三件事第一列出所有隐含的假设。比如需求说做一个用户登录功能它会指出要不要支持第三方登录密码强度要求是什么要不要记住登录状态这些假设如果不提前确认后面返工的成本很高。第二给出技术方案选项。它会列出两到三种实现路径并说明各自的优缺点。比如对于数据存储它可能会对比关系型数据库和文档型数据库在这个场景下的适用性。第三标出风险点。它会指出哪些地方容易出问题比如并发登录、token 过期处理、密码重置流程等。这一步的输出我会整理成一个简短的文档作为后续开发的依据。这个过程大概花 10 到 15 分钟但能省掉后面大量的沟通和返工。3.2 编码执行阶段flash 负责铺量方案确定之后进入编码阶段。这时候我会把任务拆成两类第一类是模式化的代码比如实体类、DTO、基础 CRUD、配置文件、单元测试骨架。这些活我全部交给 flash。我的做法是给它一个清晰的模板和约束比如请根据以下数据库表结构生成对应的 Java 实体类。 要求 1. 使用 Lombok 注解 2. 字段名用驼峰命名 3. 日期类型统一用 LocalDateTime 4. 每个字段加上 Swagger 注解 表结构 id BIGINT PRIMARY KEY user_name VARCHAR(64) created_at DATETIME ...这种指令 flash 执行得非常稳基本一次成型偶尔需要微调。第二类是核心业务逻辑比如复杂的计算、状态机、并发处理。这些我会自己写或者让 Fable 5 先给一个实现框架我再填充细节。因为这部分一旦出错排查成本很高不值得为了省时间而冒险。3.3 审查与修正阶段Fable 5 兜底代码写完一部分之后我会把关键模块丢给 Fable 5 做审查。我的审查指令通常是这样的请审查以下代码重点关注 1. 边界条件处理是否完整 2. 是否存在并发安全问题 3. 异常处理是否合理 4. 是否有性能隐患 请按严重程度排序并给出具体的修复建议。Fable 5 的审查报告通常很有价值。它不光会指出问题还会解释为什么这是问题以及在不同场景下应该怎么取舍。比如它曾经指出我一段缓存逻辑在缓存穿透时会导致数据库压力骤增并给出了布隆过滤器和空值缓存两种方案还对比了各自的适用场景。3.4 一个完整的例子让我用一个具体例子把整个流程串起来。假设我要做一个文件批量重命名工具需求是扫描指定目录按规则重命名文件支持预览和回滚。第一步我把需求丢给 Fable 5。它返回了以下分析隐含假设是否需要处理子目录重名冲突怎么处理是否支持正则表达式技术方案命令行工具 vs 图形界面Python vs Go风险点文件操作不可逆必须有回滚机制大目录扫描的性能问题第二步我确定方案用 Python 写命令行工具支持预览和回滚用 JSON 文件记录操作日志。第三步我把模式化的部分交给 flash生成命令行参数解析、JSON 读写、日志记录这些模板代码。核心的重命名逻辑和回滚逻辑我自己写写完让 Fable 5 审查。第四步Fable 5 指出我的回滚逻辑在文件被外部修改后会出错建议在日志里记录文件哈希。我采纳了这个建议。整个流程下来从需求到可用的工具大概花了两个小时其中大部分时间花在核心逻辑的思考和测试上而不是写模板代码。4. 成本控制的几个关键细节4.1 怎么判断一个任务该给谁这是整套组合里最核心的问题。我的判断标准有三条第一条看任务是否需要多步推理。如果一个问题需要先分析 A再根据 A 的结果决定 B最后综合 A 和 B 给出 C这种活给 Fable 5。如果任务是把 X 转成 Y给 flash。第二条看错误的代价。如果这个任务出错会导致线上故障或者数据丢失给 Fable 5。如果只是生成一些辅助代码出错了改一下就行给 flash。第三条看任务的重复性。如果同样的逻辑要写几十遍只是参数不同给 flash。如果每个任务都是独特的给 Fable 5。这三条标准我做成了一张速查表贴在显示器旁边任务特征推荐模型需要多步推理Fable 5错误代价高Fable 5任务独特不重复Fable 5格式转换类flash模板化生成flash批量重复任务flash辅助性代码flash4.2 提示词的长度也会影响成本这一点很多人忽略。Fable 5 的计费是按 token 算的你给的上下文越长成本越高。所以我养成了一个习惯给 Fable 5 的提示词尽量精简只给必要的信息。比如审查代码时我不会把整个项目都丢给它而是只给它相关的文件和必要的上下文。如果它需要更多信息它会主动问。反过来flash 因为便宜我可以给它更长的上下文让它一次性处理更多内容。比如批量生成代码时我会把所有的表结构一次性给它让它一次生成完而不是分多次。4.3 缓存和复用还有一个省钱技巧是复用对话。如果我在同一个项目里连续问 Fable 5 几个相关的问题我会在同一个对话里问这样它能利用之前的上下文我不需要重复解释背景。但要注意对话太长之后它的响应会变慢所以我会在适当的时候开新对话把关键结论复制过去。flash 这边我基本不依赖对话历史每次都是独立的请求。这样虽然少了上下文但胜在稳定和快。5. 踩过的坑和排查技巧5.1 Fable 5 给出的代码跑不起来这是最常见的问题。原因通常有三种第一种依赖版本不匹配。它给出的代码可能基于某个库的旧版本而你用的是新版本API 变了。解决办法是把它给的代码里的关键 API 拿去查一下官方文档确认版本兼容性。第二种环境差异。比如它假设你用的是某个特定的操作系统或运行时版本。解决办法是在提示词里明确说明你的环境比如我使用的是 Python 3.11运行在 Linux 上。第三种它自己编了一个不存在的 API。这种情况虽然不多但确实会发生。解决办法是看到不熟悉的 API 时先查文档再使用。5.2 flash 生成的代码有隐藏 bugflash 的代码通常看起来对但边界条件处理往往不到位。我遇到过几次空列表处理它生成的代码在列表为空时会抛异常除零错误没有检查分母是否为零编码问题处理中文时没有指定编码我的应对方法是flash 生成的代码必须过一遍单元测试。我会让它同时生成测试用例然后自己补充一些边界情况的测试。5.3 两个模型的输出风格不一致这个问题在混合使用时会出现。Fable 5 倾向于写更优雅的代码用一些设计模式flash 倾向于写更直接的代码怎么简单怎么来。如果同一个项目里混用代码风格会不统一。我的解决办法是在项目开始时定好代码规范然后在每次给模型的提示词里都带上这个规范。比如我会写请遵循以下规范使用 4 空格缩进、函数名用蛇形命名、每个函数不超过 50 行。这样两个模型的输出风格会接近很多。5.4 常见问题速查表问题现象可能原因解决办法Fable 5 代码跑不起来依赖版本不匹配核对官方文档Fable 5 代码跑不起来环境差异提示词里说明环境Fable 5 代码跑不起来编造 API查文档确认flash 代码有隐藏 bug边界条件未处理补充单元测试flash 代码有隐藏 bug异常处理缺失手动补充 try-catch两模型风格不一致缺少统一规范提示词里带规范Fable 5 响应慢上下文太长精简提示词flash 忘记约束对话历史太长开新对话或重复约束6. 一些进阶用法6.1 让两个模型互相审查这是一个我觉得很有价值的用法。具体做法是让 flash 生成代码然后让 Fable 5 审查再把 Fable 5 的审查意见反馈给 flash 让它修改。这样一轮下来代码质量会明显提升。我试过在一个数据处理脚本上用这个方法。flash 第一版生成的代码能跑但 Fable 5 指出了三个问题没有处理空输入、没有限制内存使用、日志级别不合理。flash 根据这些意见修改后代码健壮性好了很多。6.2 用 Fable 5 生成提示词模板如果你经常用 flash 做某类任务可以让 Fable 5 帮你设计一个提示词模板。比如你经常需要生成单元测试可以让 Fable 5 设计一个包含所有必要约束的模板然后你每次用 flash 时直接套这个模板。这样做的好处是你把思考的工作交给了 Fable 5把执行的工作交给了 flash而且模板可以复用长期来看省时省力。6.3 建立自己的代码片段库无论是 Fable 5 还是 flash 生成的代码只要质量好我都会存到一个本地的代码片段库里。下次遇到类似任务时我可以直接把片段给模型让它基于片段修改而不是从零生成。这样既快又稳。我的片段库按语言和场景分类每个片段都标注了来源和适用场景。这个习惯坚持了几个月现在我的开发速度比之前快了不少。7. 我个人的一些体会这套组合用下来最大的感受是不要指望一个模型解决所有问题。每个模型都有自己的能力边界关键是找到它们的边界然后让它们各司其职。Fable 5 像一个经验丰富的架构师适合做决策、做审查、啃硬骨头。flash 像一个手脚麻利的执行者适合做铺量、做重复劳动。把这两者结合起来既能保证质量又能控制成本。还有一个体会是提示词的质量比模型的选择更重要。同样一个任务提示词写得好flash 也能给出不错的答案提示词写得烂Fable 5 也会跑偏。所以我在提示词上花的时间比在选模型上花的时间多得多。最后分享一个小技巧如果你不确定一个任务该给谁先给 flash 试一下。如果它的输出你能接受就用如果不能接受再给 Fable 5。这样试错的成本最低。因为 flash 便宜又快试错代价小而 Fable 5 虽然强但每次调用都有成本能省则省。这套工作流我还在持续优化后面如果有新的发现再补充。