编者按：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% 工作量的部分，并说明哪些区域只是做了较浅层的审查。