什么样的工作流，让我觉得 Fable 也不过如此

这又是一篇在草稿箱里停放 N 久的老文。不过几个月时间过去，我反而对这篇文章越发有自信了。我的诸多项目正是在这个工作流之下保持着高强度开发节奏，还能高质量高效率工作。希望我这篇文章中的思考对大家有帮助，有启发。

开篇我要先介绍一下我的思路，如果你只想照搬我的方案，可以跳到下面的“我的做法”章节

这标题有点挑衅，所以我先解释一下：我没有否认 Fable 的强度。恰恰相反，我觉得 Fable 展现出来的模型能力非常强。它可以在缺少人类监督和持续引导的情况下，写出质量很高、规模很大的代码。更可以独自深入研究，得到非常出彩的结论。

但是，我认为这不是我们工作的常态。在真实世界里，AI 始终是辅助；我们，人类开发者，才是主角——因为AI太聪明。它们太聪明，所以任何产品设计在它们眼里都很合理，因为他们能够理解，能够使用；但我们的客户没那么聪明，我们的客户仍然需要重点突出、边界清晰、文本友好的产品。这些都需要开发者把自己当傻瓜，不要让用户思考，才能做到。

所以，我越来越觉得，单纯讨论模型强不强，意义没有那么大。比起“写出一段很强的代码”，我们真正需要的是“稳定地帮我们完成工作”。

这两件事看起来接近，其实差别很大。而我的工作流，能让大部分 AI 模型，都很好的做到这一点。

Fable 很强，也太贵……

因为，Fable 很强，但是使用条件很苛刻，价格也非常昂贵。我相信大部分普通团队，都无法长期负担使用 Fable 的成本。

换句话说，我们要抬高稳定下限，而不能追逐偶发上限。从任何角度来看均是如此。

软件团队管理的第一要务，就是无论谁加入团队，都能融入我们，都能产出让大家满意的代码。能力高的人会负责攻克技术难关，能力低的人也不会拖累团队。放到 AI 环境里就是：Fable 能帮我们解决技术难题；但是当我们无法支付 Fable 的高昂成本时，换用不那么强的模型也能达到令大家满意的效果。

那么，如何做到呢？我需要先提纲挈领地思考。

AI 更像人，不像传统计算机程序

我之前写过一篇关于 AI 工作流的讨论，这次想再强调这个观点：

AI 其实更像人，不像传统计算机程序。

以前我们对待程序，追求的是确定性。输入是这样，输出就应该是这样。一个函数，如果同样的输入得不到同结的果，那就是 bug；一个接口，如果今天这样返回、明天那样返回，那就不行。

但 AI 的工作方式不同。

它会理解上下文，会带上对用户你的记忆，会根据需求去收集更多信息……于是，它会在不同任务里展现不同水平。你很难要求它像传统函数一样，每次都精准、固定、完全可预测。

它就像一个工作努力积极上进的同伴：他每次的表现都不一样，但他会努力做好；它的表现会有起伏，但它会努力遵守我们给它的指示。

好消息是，我们以前积累的跟人类同事协作的经验，在面对 AI 的时候，大部分都还有效。

传统计算机程序给我们确定性，也限制了灵活性

软件开发这么多年，本质上一直在和不确定性作斗争。

我们写代码，是为了把需求约束成确定的行为。类型系统让数据结构更确定，测试让关键路径更确定，Lint 和格式化让团队风格更确定，Review 让风险更早暴露，文档让决策不只存在于某个人脑子里。

这些东西共同构成了软件工程的价值。

但另一边，太确定的东西会变得不够灵活。

系统越复杂，约束越多，改动成本越高。为了保证质量，我们不断增加流程和规则；但流程和规则多到一定程度，又会让创新、试错和快速响应变慢。这是软件开发领域一直很难突破的矛盾：我们既想要稳定可靠，又不想让系统能够跟着需求一起成长。

AI 给我们带来新机会，让这个愿望得以成真。

它可以快速理解一段陌生代码，可以根据上下文生成方案，可以在不完整的信息下先推进一版实现。它突破了传统自动化脚本只能执行固定路径的限制，能够理解自然语言，能够处理模糊任务。

但如果没有边界，这种灵活性就会变成随机性。

所以问题转向另一个方向：如何找到确定性和灵活性之间的平衡点。

我的答案是：结合软件工程多年来的积累，好好利用 AI 超出人类的编码能力，打造一个 AI 工作流，既允许 AI 发挥判断和创造力，还能用工程手段确保结果质量稳定。

好的规范要给 AI 留空间

所以，我坚决反馈类似 grill-me 或者 superpower 之类的 skill。

因为他们它们会把 AI 变成机械执行器：每一步都规定死，每一个细节都玩命抠，什么都要确认，所有边界都过度兜底。这就好比你从顶级名校雇佣了几位有着丰富经验的绩优生，然后让他们照着对日外包的规格说明书搞代码完形填空。

好的规范应该定义目标、原则、边界和验收方式，不应该替 AI 决定所有细节。

好的工作流一定是在灵活性和确定性之间找平衡。

至于具体应该怎么做——我也说不清楚。这件事就跟创业、管理研发团队一样，很难，没有固定做法，我也不觉得我现在已经掌握最佳实践，所以一直在摸索。但我觉得这将近一年来，我的做法在大部分时间都取得了成功。

我的做法：好好用软件工程，打造新工作流

回想一下，当年我们怎么带领团队取得一个又一个迭代的成功的？现在只要照做就好了。而且现在我们的队友是能力更强，态度更好的 AI，理论上，这事儿不难。

首先，制定行为规范

在项目里，我会用 AGENTS.md 写清楚 AI 应该怎么协作：目标是稳定可靠的产品，优先考虑代码效率、架构稳定、可维护可复用；遇到不合理要求要直接指出；不要过度防御；约定大于配置，代码大于文档。

这类规则有实际作用。它们决定 AI 在模糊场景里优先做什么、避开什么。

我的行为规范参考：https://github.com/meathill/meathill/blob/master/AGENTS.md 。不长，我也会尽量控制它不要太长。其中大部分其实源于已有的最佳实践，比如 TDD，AI 可以很轻松的理解，照做。

其次，明确开发流程

我希望 AI 拿到任务后先理解文档和现状，再做计划，拆 todo。修 bug 时要先找到稳定复现方式，把复现方式固化成测试，再改代码。完成后跑格式化、类型检查、测试和构建。阶段性目标完成后，小步提交。

这些要求听起来很传统，但正是这些传统的软件工程动作，能把 AI 的不稳定输出变成可验收的工作结果。

我的开发流程也在上面的行为规范里约定了。

接着，要把知识沉淀下来

短期计划放在 WIP.md，长期计划放在 TODO.md，长期有效的框架知识和决策依据放在 DEV_NOTE.md。文档不需要覆盖所有东西，但重要信息要精准、及时、精简地留下来。

AI 最大的问题之一，是它每次进入项目时都可能缺少历史记忆。文档可以降低重新理解项目的成本。好的文档不需要全面，它只需要记录那些常识不能覆盖的部分。

我把这个工作拆分成两部份：

1. 在行为规范里要求 AI 输出文档

2. 通过定期维护（下一小节）提炼、整理、升级文档，确保文档不会成为另一个坑

还有，不能只推进度，要及时停下来加固，

随着开发深入，代码会腐坏，问题会越积越多。这个时候，我们就要使用各种经验和工具，周期性加固代码、清理垃圾、改善架构，延长代码寿命。

我使用这个 Skill 来维护代码：https://github.com/meathill/meathill/tree/master/skills/meathill-coding-skills/code-maintenance

这个 Skill 会帮我们沉淀文档，清理垃圾，加强测试，升级依赖。最初只有 6 项工作，现在已经有 9 项。其实模仿的是软件迭代过程中的需求评审、代码 review、代码质量验收等工作。

最后，沉淀 SOP，行成 Skill

很多工作会重复出现。比如 PR review、代码维护、产品文案审查、网站运营视角 QA、项目报价，等等。Skill 可以把这些经验固化成可复用的工作流，并且可以通过迭代来改善。

Skill 不宜多，宜精；不宜搜罗网上其他人的，宜自己总结生成迭代。

感兴趣的话，大家可以参考我的编程 Skill 集合 https://github.com/meathill/meathill/tree/master/skills/meathill-coding-skills ，但我还是建议大家结合自己的开发习惯和工作流程，微调成自己需要的样子。

总结一下

想想你在管理一只研发团队。团队里有名校顶尖好手，也有普校踏实骨干，还有半路出家的精神小伙，你该怎么做？

1. 让好手帮我们攻克技术难关

2. 让骨干踏实搓出大量核心代码

3. 给半路出家的文科生（没有对文科生不敬的意思）做好兜底，让他们也能稳定输出，成为不可或缺的力量

4. 低成本，高效率，保质保量完成研发工作

这就是我的整体思路，也是我的工作流的真正核心，源自我 20 多年来一线技术工作的提炼和总结。

希望这篇文章分享对大家有帮助，欢迎大家留言讨论。