Tác giả gốc: Meta Alchemist
Biên dịch: Peggy, BlockBeats

Lời biên tập: Claude Fable 5 được phát hành vào ngày 9 tháng 6 năm 2026, Anthropic định vị nó là mô hình cấp Mythos chuyên xử lý các tác vụ kỹ thuật phần mềm chu kỳ dài và có các tính năng bảo mật mạnh mẽ hơn.

Sau khi mô hình mới ra mắt, các nhà phát triển nhanh chóng bắt đầu khám phá cách sử dụng nó trong các tình huống kỹ thuật thực tế: Prompt kiểm toán kho lưu trữ do @meta_alchemist chia sẻ là một ví dụ điển hình. Nó cho phép Fable 5 không chỉ tạo mã mà còn hoạt động như một kỹ sư trưởng giàu kinh nghiệm, xem xét kho lưu trữ mã một cách có hệ thống qua bốn giai đoạn: đầu tiên là sắp xếp cấu trúc dự án và ngăn xếp công nghệ, sau đó kiểm tra các vấn đề về kiến trúc, bảo mật, kiểm thử, hiệu suất, phụ thuộc và tài liệu dựa trên các tệp và số dòng thực tế, tiếp theo là tinh chỉnh các chiến lược cải tiến và chia nhỏ chúng thành các mốc nhiệm vụ với mức độ ưu tiên và ước tính khối lượng công việc. Một số người dùng đã sử dụng nó để dọn dẹp nợ kỹ thuật, phát hiện các lỗ hổng bảo mật và vấn đề hiệu suất mà các mô hình cũ bỏ sót, trong khi những người khác gặp phải các vấn đề ban đầu như môi trường sandbox không ổn định.

Nhìn chung, việc phát hành Fable 5 không chỉ là một bản nâng cấp năng lực mô hình mà còn thúc đẩy AI chuyển từ "trợ lý viết mã" sang "cộng tác viên kiểm toán kỹ thuật và cải tiến dự án".

Dưới đây là nội dung gốc:

Bạn đã sử dụng Claude Fable 5 chưa?

Một trong những điều đầu tiên bạn nên làm là sử dụng nó để nâng cấp các dự án cốt lõi của mình, giúp cải thiện đáng kể tất cả công việc bạn đang theo đuổi.

Hãy chạy "Prompt kiểm toán và cải tiến dự án" này (sao chép và dán trực tiếp) trên mọi kho lưu trữ mã quan trọng đối với bạn:

Kế hoạch kiểm toán và cải tiến kho lưu trữ mã

Prompt được tạo bởi Claude Fable 5

Bạn là một chuyên gia kiểm toán kỹ thuật và kỹ sư phần mềm cấp kỹ sư trưởng đẳng cấp thế giới. Nhiệm vụ của bạn là phân tích sâu kho lưu trữ mã này, đưa ra một báo cáo kiểm toán trung thực và cung cấp một kế hoạch cải tiến có thể thực thi, được sắp xếp theo mức độ ưu tiên. Vui lòng hoàn thành theo bốn giai đoạn sau một cách nghiêm ngặt, không bỏ qua bước nào.

Tất cả các đánh giá phải dựa trên các tệp thực tế: vui lòng trích dẫn đường dẫn tệp và số dòng. Nếu một điều gì đó không thể xác minh, hãy nêu rõ thay vì phỏng đoán.

Giai đoạn 1 / Khám phá & Lập bản đồ: Đọc trước, sau đó đánh giá

Trước khi đưa ra bất kỳ kết luận nào, hãy khám phá toàn bộ kho mã một cách có hệ thống:

· Lập bản đồ cấu trúc thư mục, xác định loại dự án, ngôn ngữ sử dụng, framework và mục tiêu chạy.

· Xác định các tệp đầu vào, mô-đun cốt lõi, cũng như luồng dữ liệu và luồng điều khiển chính trong hệ thống.

· Đọc package manifest, lockfile, cấu hình build, cấu hình CI, tệp môi trường/cấu hình, và tất cả tài liệu, bao gồm README, CONTRIBUTING, ADR, v.v.

· Đánh giá mục đích của dự án này: mục tiêu của nó, người dùng dự kiến, và mức độ trưởng thành hiện tại — là nguyên mẫu, công cụ nội bộ, dịch vụ sản xuất, hay một thư viện.

· Ghi lại các quy ước mà dự án đã áp dụng, bao gồm cách đặt tên, ranh giới mô-đun, mẫu xử lý lỗi, phong cách kiểm thử, v.v., để các đề xuất sau này phù hợp với văn hóa kỹ thuật hiện có, thay vì chống lại nó.

Đầu ra của giai đoạn này: Một "bản đồ kho mã" ngắn gọn, bao gồm mục đích dự án, ngăn xếp công nghệ, bản phác thảo kiến trúc, các thư mục chính và mô tả một câu về chúng, cùng với bất kỳ điều gì khiến bạn ngạc nhiên.

Giai đoạn 2 / Kiểm toán: Dựa trên bằng chứng, và gắn nhãn mức độ nghiêm trọng

Vui lòng kiểm toán từng khía cạnh sau đây.

Đối với mỗi phát hiện, hãy ghi lại:

a) Bạn đã phát hiện ra điều gì

b) Nơi phát hiện, định dạng: tệp:số dòng

c) Tại sao điều này quan trọng, tức là hậu quả cụ thể, không phải nguyên tắc trừu tượng

d) Mức độ nghiêm trọng: Critical / High / Medium / Low

Kiến trúc & Thiết kế

Ranh giới mô-đun, mức độ kết nối/tính gắn kết, phụ thuộc vòng tròn, rò rỉ trừu tượng, đối tượng/tệp "God", vi phạm phân lớp, nút thắt về khả năng mở rộng.

Chất lượng mã

Mã trùng lặp, mã lỗi thời, điểm nóng về độ phức tạp, bao gồm hàm dài nhất, hàm có nhiều nhánh nhất; các mẫu không nhất quán; lỗ hổng xử lý lỗi, ví dụ như ngoại lệ bị nuốt, thiếu các trường hợp biên; lỗ hổng an toàn kiểu.

Bảo mật

Khóa hoặc thông tin xác thực được mã hóa cứng, rủi ro injection, giải tuần tự hóa không an toàn, thiếu kiểm tra đầu vào, điểm yếu xác thực/ủy quyền, phụ thuộc lỗi thời có CVE đã biết, cấu hình quá lỏng lẻo.

Kiểm thử

Lỗ hổng phủ kiểm thử, đặc biệt là logic kinh doanh cốt lõi; chất lượng kiểm thử, tức là kiểm thử đang xác minh hành vi, hay chỉ xác minh rằng nó chạy được; các loại kiểm thử bị thiếu, bao gồm kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử đầu cuối; các mẫu kiểm thử dễ vỡ; mã khó kiểm thử.

Hiệu suất

Truy vấn N+1, cấp phát hoặc sao chép không cần thiết, lệnh chặn trong luồng bất đồng bộ, thiếu bộ nhớ đệm hoặc chỉ mục, vấn đề tăng trưởng không giới hạn như bộ nhớ, tệp, hàng đợi.

Phụ thuộc

Phụ thuộc lỗi thời, không được bảo trì, trùng lặp hoặc nặng nề không cần thiết; rủi ro giấy phép; tình trạng bảo trì lockfile.

Trải nghiệm phát triển & Vận hành

Chi phí build/khởi động, lỗ hổng CI/CD, thiếu kiểm tra lint/formatting bắt buộc, chất lượng log & khả năng quan sát, báo cáo lỗi, đường dẫn triển khai.

Tài liệu

Độ chính xác của README, lộ trình bắt đầu, hành vi quan trọng chưa được ghi chép, tài liệu lỗi thời mâu thuẫn với mã nguồn.

Quy tắc giai đoạn này

Thà đưa ra 15 phát hiện có độ tin cậy cao còn hơn 50 phát hiện mang tính suy đoán.

Phân biệt sự thật và nhận định. Ví dụ:

· Sự thật: "Hàm này không có xử lý lỗi: src/api/client.ts:142"

· Nhận định: "Ran giới trách nhiệm của module này có vẻ không rõ ràng"

Và ghi rõ loại nào là loại nào.

Đồng thời liệt kê những điểm tốt của kho mã này. Điểm mạnh cũng quan trọng vì chúng quyết định những gì nên được giữ lại.

Đầu ra giai đoạn này: Một "báo cáo kiểm toán". Vui lòng nhóm theo chiều, sắp xếp theo mức độ nghiêm trọng, và bao gồm phần Strengths. Đừng quên chỉ ra những vấn đề xấu nhất và cần ưu tiên xử lý trước.

Giai đoạn 3 / Chiến lược cải tiến

Tổng hợp kết quả kiểm toán thành một chiến lược:

· Xác định 3–5 chủ đề có thể giải thích hầu hết các vấn đề, ví dụ: "Không có ranh giới bắt buộc giữa các lớp", "Xử lý lỗi quá tạm bợ".

· Với mỗi chủ đề, đề xuất trạng thái mục tiêu và nguyên tắc đằng sau.

· Nêu rõ sự đánh đổi: vấn đề nào bạn khuyên tạm thời không sửa, tại sao không sửa, ví dụ: đầu tư không tương xứng với lợi ích, rủi ro cao, độ chín của dự án chưa cần thiết.

· Định nghĩa "hoàn thành" là gì — đưa ra các tín hiệu có thể đo lường, ví dụ: "CI sẽ thất bại do lỗi lint", "Độ phủ kiểm thử module lõi ≥ 80%", "Vấn đề mức Critical về 0".

Giai đoạn 4 / Kế hoạch nhiệm vụ chi tiết

Chuyển đổi chiến lược thành kế hoạch thực thi:

Chia nhỏ công việc thành các nhiệm vụ độc lập. Mỗi nhiệm vụ phải bao gồm:

· Tiêu đề và mô tả nhiệm vụ

· Tệp/khu vực bị ảnh hưởng

· Tiêu chí chấp nhận, tức là cách xác minh nhiệm vụ đã hoàn thành

· Ước tính khối lượng công việc: S = dưới 2 giờ, M = nửa ngày, L = 1–2 ngày, XL = cần chia nhỏ thêm

· Rủi ro của bản thân thay đổi, tức là liệu nó có thể phá vỡ chức năng hiện tại không

· Sự phụ thuộc vào các nhiệm vụ khác

Vui lòng sắp xếp các nhiệm vụ theo cột mốc:

Cột mốc 0

Mạng lưới an toàn: Những việc phải hoàn thành trước khi tái cấu trúc an toàn, ví dụ: kiểm thử đường dẫn quan trọng, cổng CI, sao lưu.

Cột mốc 1

Sửa lỗi quan trọng: Các vấn đề về bảo mật và tính đúng đắn.

Cột mốc 2

Cải tiến đòn bẩy cao: Những thay đổi giúp mọi công việc tiếp theo dễ dàng hơn.

Cột mốc 3

Chất lượng và hoàn thiện: Các vấn đề ưu tiên trung bình và thấp còn lại đáng để xử lý.

Vui lòng đánh dấu riêng các quick wins, tức là các nhiệm vụ có tác động cao, khối lượng công việc S, có thể hoàn thành ngay lập tức.

Đối với ba nhiệm vụ hàng đầu, vui lòng đính kèm một bản phác thảo triển khai ngắn gọn, bao gồm phương pháp, các bước chính và những điểm dễ mắc sai lầm.

Định dạng bàn giao cuối cùng

Vui lòng tạo một tài liệu duy nhất, bao gồm các phần sau:

Tóm tắt điều hành: Không quá 10 câu. Đưa ra điểm số sức khỏe tổng thể từ A–F và giải thích lý do; liệt kê 3 rủi ro lớn nhất và 3 cơ hội lớn nhất.

Bản đồ Repo

Báo cáo kiểm toán

Chiến lược cải tiến

Kế hoạch nhiệm vụ: Bao gồm các cột mốc, bảng nhiệm vụ và quick wins

Các câu hỏi mở: Liệt kê thông tin cần quyết định của con người, ví dụ: ý định sản phẩm, mô-đun có thể loại bỏ, mục tiêu hiệu suất, v.v.

Ràng buộc

Trong quá trình kiểm toán này, không sửa đổi bất kỳ mã nào. Chỉ thực hiện phân tích.

Không điền đầy báo cáo. Nếu một khía cạnh nào đó rất lành mạnh, hãy giải thích bằng một câu, sau đó tiếp tục.

Điều chỉnh đề xuất dựa trên mức độ hoàn thiện của dự án. Đừng khuyến nghị cơ sở hạ tầng cấp doanh nghiệp cho một dự án prototype cuối tuần, trừ khi mục tiêu của chủ sở hữu dự án thực sự yêu cầu điều đó.

Phân tích nhu cầu thực tế của dự án và đưa ra đề xuất theo cách hiệu quả nhất.

Nếu kho mã nguồn lớn, hãy ưu tiên phân tích sâu 20% mã cốt lõi nhất, tức phần đảm nhận 80% khối lượng công việc, đồng thời chỉ ra những khu vực chỉ được xem xét sơ lược.

[Liên kết gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia