什么样的工作流，让我觉得 Fable 也不过如此
内容提要
作者认为AI更像人而非传统程序，不必追逐Fable等昂贵模型的偶发上限，而应抬高稳定下限。做法是结合软件工程：用AGENTS.md定行为规范，明确开发流程，沉淀WIP、TODO、DEV_NOTE等文档，定期加固代码，并把重复工作固化为精炼的Skill，实现低成本高质量开发。
延伸解读
为什么“稳定下限”比“偶发上限”更重要
作者指出，Fable 等昂贵模型虽然能写出高质量代码，但使用条件苛刻、成本高昂，普通团队难以长期负担。因此，与其追逐模型偶尔展现的极限能力，不如通过工作流抬高稳定下限，让能力普通的模型也能持续产出可验收的结果。这一思路源于团队管理经验：顶尖成员攻克难题，普通成员在规范下稳定输出，整体效率反而更高。
把 AI 当人看：协作经验比调参更有效
文章强调 AI 更像人而非传统程序，其表现会波动，但能理解上下文并努力遵守指示。因此，过去与人类同事协作的经验——如明确目标、边界和验收方式——在面对 AI 时依然有效。相反，过度规定每一步的 skill 会把 AI 变成机械执行器，扼杀其判断力和创造力。好的规范应留出空间，让 AI 在模糊场景中自主决策。
用软件工程动作把 AI 输出变成可验收结果
作者的工作流核心是复用传统软件工程实践：用 AGENTS.md 定义行为规范，明确开发流程（先理解、再计划、拆 todo、修 bug 先复现并固化为测试），沉淀 WIP、TODO、DEV_NOTE 等文档，并定期加固代码。这些动作能把 AI 不稳定的输出转化为可验收的工作结果，同时降低 AI 每次进入项目时重新理解历史的成本。
Skill 宜精不宜多：沉淀自己的 SOP
对于重复性工作，作者建议将其固化为精炼的 Skill，如 PR review、代码维护、产品文案审查等。但 Skill 不宜多，也不宜直接搜罗他人的，而应结合自身开发习惯总结生成并迭代。作者自己的编程 Skill 集合最初只有 6 项，现已扩展到 9 项，模仿的是软件迭代中的需求评审、代码 review 和质量验收等环节。
Q&A
为什么作者认为不必追逐Fable等昂贵模型？
因为Fable虽然能力强，但使用条件苛刻且价格昂贵，大部分普通团队无法长期负担。作者主张抬高稳定下限，而不是追逐偶发上限，即用不那么强的模型也能达到满意效果。
AI工作流中如何制定行为规范？
在项目里用AGENTS.md写清楚AI应该怎么协作：目标是稳定可靠的产品，优先考虑代码效率、架构稳定、可维护可复用；遇到不合理要求要直接指出；不要过度防御；约定大于配置，代码大于文档。
作者如何管理AI开发过程中的知识沉淀？
短期计划放在WIP.md，长期计划放在TODO.md，长期有效的框架知识和决策依据放在DEV_NOTE.md。文档不需要覆盖所有东西，但重要信息要精准、及时、精简地留下来。
为什么需要定期加固代码？如何做？
随着开发深入，代码会腐坏，问题会越积越多，因此需要周期性加固代码、清理垃圾、改善架构，延长代码寿命。作者使用一个code-maintenance Skill来沉淀文档、清理垃圾、加强测试、升级依赖。
Skill在AI工作流中起什么作用？
Skill可以把重复出现的工作（如PR review、代码维护、产品文案审查等）固化成可复用的工作流，并且可以通过迭代来改善。Skill不宜多，宜精；不宜搜罗网上其他人的，宜自己总结生成迭代。
作者的工作流核心思想是什么？
核心思想是结合软件工程多年积累，利用AI超出人类的编码能力，打造一个AI工作流，既允许AI发挥判断和创造力，还能用工程手段确保结果质量稳定。具体包括制定行为规范、明确开发流程、沉淀知识、定期加固代码、沉淀SOP形成Skill。
