你最该用Claude Fable 5做什么？给代码仓库做一次全面体检

Claude Fable 5 于 2026 年 6 月 9 日正式发布。Anthropic 对其定位很明确：这是一款擅长长周期软件工程任务、同时具备更强安全特性的 Mythos 级模型。

新模型上线后，开发者社区很快就开始探索它在真实工程场景中的价值。

总体来看，Fable 5 的发布不仅是模型能力的又一次提升，更在推动 AI 从一个“写代码的助手”向“工程审计与项目改进的协作者”角色演进。

那么，如果你已经用上了 Claude Fable 5，第一件值得做的事是什么？答案很简单：用这份 Prompt 升级你的核心项目，让它系统性地改善你正在推进的所有工作。

下面这份“审计与项目改进提示词”，直接复制粘贴到你最重要的代码仓库里运行即可。

代码仓库审计与改进计划

提示词由 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% 工作量的部分），并说明哪些区域只是做了较浅层的审查。