原文编译：Peggy，BlockBeats 编者按：2026年6月9日，Anthropic正式推出Claude Fable 5，这是一款专为长周期软件工程任务打造、并具备更强安全机制的Mythos级模型。新版本上线后，开发者们纷纷探索其在真实工程场景中的实用技巧。@meta_alchemist 分享的这套仓库审计提示词就是一个经典实践——它让Fable 5不再仅仅生成代码，而是像资深技术负责人那样，对代码仓库进行系统性审视。具体来说，它会先梳理项目结构和技术栈，然后基于真实文件与行号检查架构、安全、测试、性能、依赖和文档等方面的隐患，紧接着提炼改进策略，并拆解成带优先级和工作量预估的任务里程碑。部分用户已借此清理了技术债、发现了旧模型遗漏的安全漏洞和效率低下问题；当然，也有人遭遇了沙盒环境不稳定等早期挑战。总体来看，Claude Fable 5的发布不仅是模型能力的升级，更标志着AI从“写代码助手”向“工程审计与项目优化协作者”的角色跃迁。 以下为原文内容： 你已经用上Claude Fable 5了吗？第一件事，你可以用它来对你的核心项目进行一次全面升级，让所有你正在推进的工作都获得显著改善。 请在每一个对你至关重要的代码仓库中运行下面这份“审计与项目改进提示词”**（直接复制粘贴即可）**： ## 代码仓库审计与改进计划 > 提示词由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%工作量的部分），并说明哪些区域只是做了较浅层的审查。