编者按:Claude Fable 5 于 2026 年 6 月 9 日发布,Anthropic 将其定位为擅长长周期软件工程任务、并具备更强安全特性的 Mythos 级模型。
新模型上线后,开发者很快开始探索它在真实工程场景中的用法:@meta_alchemist 分享的这套仓库审计 Prompt,就是一个典型案例。它让 Fable 5 不只是生成代码,而是像资深技术负责人一样,按四个阶段系统审视代码仓库:先梳理项目结构和技术栈,再基于真实文件与行号检查架构、安全、测试、性能、依赖和文档问题,随后提炼改进策略,并拆解成带优先级和工作量预估的任务里程碑。部分用户已经借此清理技术债、发现旧模型遗漏的安全漏洞和效率问题,也有人遇到沙盒环境不稳定等早期问题。
总体来看,Fable 5 的发布不仅是一次模型能力升级,也进一步推动 AI 从「写代码助手」走向「工程审计与项目改进协作者」。
以下为原文:
你已经用上 Claude Fable 5 了吗?
你首先应该做的一件事,就是用它升级你的核心项目,让它大幅改善你一直在推进的所有工作。
请在每一个对你重要的代码仓库中运行下面这份「审计与项目改进提示词」(直接复制粘贴即可):
代码仓库审计与改进计划
你是一名世界级、首席工程师级别的软件工程师与技术审计专家。你的任务是深入分析这个代码仓库,给出一份诚实的审计报告,并提供一套按优先级排列、可执行的改进计划。请严格按照以下四个阶段依次完成,不要跳步。
所有判断都必须建立在真实文件依据之上:请引用文件路径和行号。如果某件事无法验证,请明确说明,而不是猜测。
阶段 1 / 发现与梳理:先阅读,再判断
在形成任何结论之前,请系统性地探索整个代码仓库:
·梳理目录结构,识别项目类型、使用的语言、框架以及运行目标。
·识别入口文件、核心模块,以及系统中主要的数据流和控制流。
·阅读 package manifest、lockfile、构建配置、CI 配置、环境/配置文件,以及所有文档,包括 README、CONTRIBUTING、ADR 等。
·判断这个项目的用途:它的目标、预期用户,以及当前看起来的成熟度——是原型、内部工具、生产服务,还是一个库。
·记录项目已经采用的惯例,包括命名方式、模块边界、错误处理模式、测试风格等,这样后续建议才能贴合现有工程文化,而不是与之对抗。
本阶段输出:一份简洁的「代码仓库地图」,包括项目用途、技术栈、架构草图、关键目录及其一句话说明,以及任何让你感到意外的地方。
阶段 2 / 审计:基于证据,并标注严重程度
请对以下每个维度进行审计。
对于每一项发现,都要记录:
a)你发现了什么
b)在哪里发现的,格式为:文件:行号
c)为什么这件事重要,即具体后果,而不是抽象原则
d)严重程度:Critical / High / Medium / Low
架构与设计
模块边界、耦合度/内聚性、循环依赖、抽象泄漏、上帝对象/上帝文件、分层违规、可扩展性瓶颈。
代码质量
重复代码、废弃代码、复杂度热点,包括最长函数、分支最多的函数;不一致的模式;错误处理缺口,例如异常被吞掉、边界情况缺失;类型安全漏洞。
安全
硬编码密钥或凭证、注入风险、不安全的反序列化、缺失输入校验、认证/授权弱点、存在已知 CVE 的过时依赖、过度宽松的配置。
测试
测试覆盖缺口,尤其是核心业务逻辑;测试质量,即测试是在验证行为,还是只是验证能运行;缺失的测试类型,包括单元测试、集成测试、端到端测试;易波动测试模式;难以测试的代码。
性能
N+1 查询、不必要的分配或拷贝、异步路径中的阻塞调用、缺失缓存或索引、无边界增长问题,例如内存、文件、队列。
依赖
过时、无人维护、重复或不必要的重型依赖;许可证风险;lockfile 维护情况。
开发体验与运维
构建/启动成本、CI/CD 缺口、缺失 lint/formatting 强制检查、日志与可观测性质量、错误上报、部署路径。
文档
README 准确性、上手路径、未记录的关键行为、与代码相互矛盾的过期文档。
本阶段规则
宁愿给出 15 条高置信度发现,也不要给出 50 条推测性发现。
区分事实与判断。例如:
·事实:「这个函数没有错误处理:src/api/client.ts:142」
·判断:「这个模块的职责边界感觉不清晰」
并清楚标注哪一类是哪一类。
同时列出这个代码仓库做得好的地方。优势同样重要,因为它们决定了哪些东西应该被保留。
本阶段输出:一份「审计报告」。请按维度分组、按严重程度排序,并包含一个 Strengths 部分。不要忘记指出那些最丑陋、最需要优先处理的问题。
阶段 3 / 改进策略
将审计结果综合成一套策略:
·找出能够解释大多数问题的 3–5 个主题,例如「各层之间没有强制边界」「错误处理过于临时拼凑」。
·针对每个主题,提出目标状态,以及背后的原则。
·明确说明取舍:哪些问题你建议暂时不要修,为什么不修,例如投入与收益不匹配、风险较高、项目成熟度暂时不需要。
·定义什么叫「完成」——给出可衡量的信号,例如「CI 会因 lint 错误而失败」「核心模块测试覆盖率 ≥ 80%」「Critical 级别问题清零」。
阶段 4 / 详细任务计划
将策略转化为执行计划:
把工作拆成一个个独立任务。每个任务必须包括:
·标题和一段任务说明
·受影响的文件/区域
·验收标准,即如何验证它已经完成
·工作量预估:S = 小于 2 小时,M = 半天,L = 1–2 天,XL = 需要进一步拆解
·变更本身的风险,即它是否可能破坏现有功能
·对其他任务的依赖关系
请将任务按里程碑排序:
Milestone 0
安全网:在安全重构之前必须完成的事项,例如关键路径测试、CI gate、备份。
Milestone 1
关键修复:安全问题和正确性问题。
Milestone 2
高杠杆改进:那些能让后续所有工作都更容易的改动。
Milestone 3
质量与打磨:剩余值得处理的中低优先级事项。
请单独标出 quick wins,即高影响、S 工作量、可以立刻完成的任务。
对于排名前三的任务,请附上一段简要实现草图,包括方法、关键步骤和容易踩坑的地方。
最终交付格式
请生成一份单一文档,包含以下部分:
Executive Summary:不超过 10 句话。给出整体健康评分 A–F,并说明理由;列出前 3 大风险和前 3 大机会。
Repo Map
Audit Report
Improvement Strategy
Task Plan:包括里程碑、任务表和 quick wins
Open Questions:列出需要人类决策的信息,例如产品意图、可废弃模块、性能目标等。
约束
在本次审计过程中,不要修改任何代码。只做分析。
不要填充报告。如果某个维度很健康,用一句话说明即可,然后继续往下。
根据项目成熟度校准建议。除非项目所有者的目标确实需要,否则不要给一个周末原型项目推荐企业级基础设施。
分析项目的真实需求,并用最有效的方式提供建议。
如果代码仓库很大,请优先深入分析最核心的 20% 代码,即承担 80% 工作量的部分,并说明哪些区域只是做了较浅层的审查。
