原文作者：Meta Alchemist
翻譯：Peggy，BlockBeats

編者按：Claude Fable 5 於 2026 年 6 月 9 日發布，Anthropic 將其定位為擅長長周期軟體工程任務，並具備更強安全特性的 Mythos 級模型。

新模型上線後，開發者很快開始探索它在真實工程場景中的用法：@meta_alchemist 分享的這套倉庫稽核 Prompt，就是一個典型案例。它讓 Fable 5 不僅是生成程式碼，而是像資深技術負責人一樣，按四個階段系統審視程式碼倉庫：先梳理專案結構和技術棧，再基於真實檔案與行號檢查架構、安全、測試、效能、依賴和文件問題，隨後提煉改進策略，並拆解成帶優先級和工作量預估的任務里程碑。部分使用者已經借此清理技術債、發現舊模型遺漏的安全漏洞和效率問題，也有人遇到沙盒環境不穩定等早期問題。

總體來看，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 閘道、備份。

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% 工作量的部分，並說明哪些區域只是做了較淺層的審查。

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia