Thời gian miễn phí của Fable 5 kết thúc vào ngày 7 tháng 7.
Hôm nay là ngày 3 tháng 7 năm 2026. Nói cách khác, thời gian "sử dụng Fable vì nó miễn phí" sắp kết thúc trong vài ngày tới, và từ ngày 8 tháng 7, nó sẽ chuyển sang hệ thống tín dụng dựa trên mức sử dụng.
Vậy, chúng ta sẽ làm gì từ ngày 8 tháng 7?
Sonnet 5 có sẵn trên tất cả các gói, bao gồm cả Gói Miễn phí.
Giá giới thiệu đến ngày 31 tháng 8 là 2 đô la cho mỗi 1 triệu token đầu vào và 10 đô la cho mỗi 1 triệu token đầu ra. Sau đó, giá sẽ là 3 đô la cho đầu vào và 15 đô la cho đầu ra. Fable 5 có giá 10 đô la cho đầu vào và 50 đô la cho đầu ra.
Ngay cả ở mức giá thông thường, chênh lệch cũng khoảng 3,3 lần. So với giá giới thiệu của Sonnet 5, chênh lệch là 5 lần.
Hơn nữa, Sonnet 5 có cửa sổ ngữ cảnh 1M và đầu ra 128k. Khả năng đọc các tài liệu dài và mã nguồn cũng giống như Fable 5.
Nếu vậy, điều duy nhất còn thiếu có thực sự chỉ là "hiệu suất" không?
Kết luận của tôi hơi khác một chút. Bí mật sức mạnh của Fable 5 không chỉ là sự thông minh. Đó là hành vi.
Suy nghĩ lâu dài. Xác định điều kiện thành công trước. Nghi ngờ. Xác minh. Ghi chép. Và cuối cùng, báo cáo trung thực về những gì đã đạt được và những gì chưa.
Một phần đáng kể của hành vi này có thể được tích hợp vào CLAUDE.md và cài đặt môi trường.
CLAUDE.md là một bản ghi nhớ cấu hình mà Claude Code đọc liên tục, cho nó biết "cách hành xử trong dự án này." Nó không phải là một lời nhắc bạn dán vào mỗi cuộc trò chuyện. Nó là một hướng dẫn được đặt ngay trong môi trường.
Kỹ thuật của những người dán lời nhắc mỗi lần cũng rất mạnh. Bắt nó tạo điều kiện chiến thắng, so sánh bản nháp, chia nhỏ mọi thứ và hoàn thành. Mô hình đó rất hiệu quả.
Tuy nhiên, bạn sẽ quên những thứ phải dán mỗi lần. Chúng càng dài, chúng càng trở nên tẻ nhạt. Chúng biến mất khi phiên làm việc thay đổi.
Đó là lý do tại sao lần này, chúng ta sẽ làm cho nó trở nên vĩnh viễn.
Mượn một câu nói đang thịnh hành ở nước ngoài:
Lời nhắc là tạm thời. Cấu trúc là vĩnh viễn.
Trong bài viết này, tôi sẽ cung cấp các cài đặt CLAUDE.md để đưa Sonnet 5 đến gần hơn với Fable 5 ở định dạng có thể sao chép-dán.
Hơn nữa, đây không chỉ là những cài đặt do tôi nghĩ ra.
Sử dụng chế độ headless của Claude Code—cụ thể là hỏi qua claude -p từ terminal—tôi đã phỏng vấn chính cả Sonnet 5 và Fable 5.
Hỏi người đàn em, Sonnet 5, về điểm yếu của chính nó.
Hỏi người đàn anh, Fable 5, cách đào tạo người đàn em.
Cuộc phỏng vấn kép này đã mang lại một số câu trả lời rất thú vị.
Bản Chất Thực Sự của Fable 5 là "Hành Vi Bền Bỉ"
Khi bạn sử dụng Fable 5, nó chắc chắn rất thông minh.
Nhưng nếu bạn nhìn kỹ vào đầu ra, sức mạnh của nó không chỉ là lượng kiến thức. Cách nó tiếp cận công việc khác biệt.
Nó không bắt đầu xây dựng ngay lập tức. Nó xác định điều kiện thành công trước.
Nó không tin tưởng ngay vào ý tưởng của chính mình. Nó tìm kiếm những nơi có thể thất bại trước.
Nó không chỉ nói "nó hoạt động." Nó cho thấy những gì nó đã sử dụng để xác minh.
Nó không lấp đầy những lỗ hổng kiến thức bằng vẻ ngoài hiểu biết.
Và ngay cả trong các tác vụ dài, nó cố gắng duy trì các ràng buộc ban đầu cho đến cuối cùng.
Điều này rất dễ hiểu nếu bạn thay thế nó bằng công việc của con người.
Fable 5 trông giống như một người đàn anh có năng lực cao. Ngay cả khi được giao một yêu cầu mơ hồ, trước khi vội vã chạy đi, nó quay lại và hỏi, "Thành công trông như thế nào ngay từ đầu?" Nếu một kế hoạch thất bại, nó loại bỏ kế hoạch đó và bắt đầu lại.
Sonnet 5 là một người đàn em có năng lực cao. Nhanh nhẹn. Biết vâng lời. Trung thành với hướng dẫn. Tuy nhiên, nếu không có cấu trúc, nó có thể trả lời quá trôi chảy.
Trong trường hợp đó, chúng ta chỉ cần cho người đàn em thói quen làm việc của người đàn anh.
Nơi để đặt điều đó là CLAUDE.md.
Điểm Yếu Rõ Ràng Được Xác Định Bằng Cách Phỏng Vấn Chính "Bản Thân" Sonnet 5
Đầu tiên, tôi đã hỏi chính Sonnet 5.
"Tôi nên viết gì trong CLAUDE.md để đạt được kết quả ngang tầm Fable 5?"
Bản tự phân tích mà nó trả về khá trung thực.
Sonnet 5 đã nói điều này về chính nó:
"Tôi có xu hướng trả lời trôi chảy, và sự không chắc chắn thường ẩn trong phong cách viết của tôi."
Điều này rất quan trọng.
Câu trả lời của AI có thể nguy hiểm khi văn bản quá tốt. Nếu nó được viết rõ ràng, con người có xu hướng tin vào nó. Nhưng trên thực tế, nó có thể chứa "có thể," "chưa được xác nhận," hoặc "phần này đáng ngờ."
Do đó, cài đặt đầu tiên cần bao gồm là:
**Bắt nó nêu rõ mức độ tự tin cho những phần không chắc chắn.
Đừng để nó ẩn đằng sau các trạng từ mơ hồ.
Nếu độ tự tin thấp, hãy bắt nó xác nhận trước khi tiếp tục.**
Lý do nó hoạt động rất đơn giản. Nó không còn có thể che giấu sự lo lắng trong phong cách viết của mình nữa.
Tiếp theo, Sonnet 5 thừa nhận nó có xu hướng "triển khai trước và điều chỉnh sau." Để ngăn chặn điều này, hãy bắt nó viết các điều kiện thành công trước.
Trước khi viết mã hoặc văn bản, hãy bắt nó xuất ra các tiền đề, điều kiện thành công có thể xác minh và các chế độ thất bại. Không phải "nó hoạt động" hay "cảm thấy tốt," mà ở dạng có thể được đánh giá như các bài kiểm tra, đầu ra, màn hình hoặc các điều kiện văn bản cụ thể.
Điều quan trọng ở đây là biến các điều kiện thành công thành một "sự phán xét" chứ không phải là một "tâm trạng."
"Tạo một bài viết hay" là yếu.
"Đề cập đến thời hạn ngày 7 tháng 7 ở đầu bài. Bao gồm sự khác biệt về giá. Đặt 6 hoặc nhiều hơn các cài đặt có thể sao chép-dán cho CLAUDE.md. Đừng che giấu những khoảng cách mà Fable không thể lấp đầy."
Nếu bạn viết được nhiều như vậy, bạn có thể so sánh nó ở cuối.
Sonnet 5 kết luận bằng cách nói:
"Fable 5 có thể tự suy nghĩ sâu sắc. Tôi di chuyển nhanh chóng và chính xác nếu được cung cấp cấu trúc. Thu hẹp khoảng cách đó bằng CLAUDE.md là bản chất."
Cốt lõi của bài viết này chính là điều đó.
Kết Quả Phỏng Vấn Fable 5
Tiếp theo, tôi đã hỏi chính Fable 5 về cùng một chủ đề.
Phản hồi đầu tiên thật tuyệt vời.
"Báo cáo tự đánh giá của một mô hình không phải là dữ liệu đáng tin cậy."
Chính xác. Chỉ vì tôi hỏi mô hình không có nghĩa là nó trở thành một điểm chuẩn. Tự đánh giá từ bên trong là thiên vị.
Vì vậy, trong bài viết này, tôi sẽ không coi "những gì chúng nói" là chân lý tuyệt đối. Tôi sẽ coi chúng như những gợi ý để tạo ra một mẫu sử dụng.
Nói vậy, sự khác biệt mà Fable 5 xác định rất sắc bén.
Nó nói sự khác biệt là "điều gì xảy ra khi không có cấu trúc, hoặc khi cấu trúc được đưa ra bị sai."
Nếu thông số kỹ thuật rõ ràng, các bài kiểm tra tồn tại và quy trình được thiết lập, sự khác biệt là nhỏ.
Sự khác biệt xuất hiện khi bản thân các thông số kỹ thuật bị sai. Khi một kế hoạch thất bại. Khi duy trì các ràng buộc ban đầu cho đến khi kết thúc một tác vụ dài. Khi cần tự kiềm chế để không thêm các cải tiến không được yêu cầu.
Và Fable 5 thừa nhận điểm yếu của chính nó.
Chi phí đơn vị cao. Suy nghĩ quá nhiều ngay cả với các tác vụ đơn giản. Thua trong các cuộc đua tốc độ cho xử lý hàng loạt.
Nói cách khác, "Fable cho mọi thứ" là một sự quản lý sai lầm về mặt kinh tế.
Vì vậy, `CLAUDE.md` mà Fable 5 đã viết cho người đàn em của nó, Sonnet, là gì?
Sắp xếp các điểm trùng lặp với phía Sonnet, đây là 7 mẹo cần ghi nhớ.
7 Mẹo cho `CLAUDE.md` để Biến Sonnet 5 Thành Fable
Đầu tiên là các điều kiện thành công. Cả hai mô hình đều đưa ra điều này một cách độc lập.
1[Đánh giá hoàn thành một cách máy móc]2Xác định "hoàn thành" trong một dòng trước khi bắt đầu.3Ví dụ: Bài kiểm tra này vượt qua. Lệnh này trả về exit 0. Tiêu đề này có trong nội dung.4Nếu bạn không thể viết nó, hãy hỏi những gì cần được quyết định trước khi tiếp tục.
Thứ hai là nhiều cách hiểu. Cả hai cũng đồng ý về điều này.
1[Không tự ý chọn giữa nhiều cách hiểu]2Nếu một hướng dẫn có hai hoặc nhiều cách hiểu, đừng âm thầm chọn một.3Liệt kê các cách hiểu ứng viên và xác nhận với một đề xuất.4Tuy nhiên, nếu đầu ra vẫn giống nhau bất kể cách hiểu nào, bạn có thể tiến hành.
Thứ ba là phạm vi.
1[Nghiêm cấm cải tiến ngẫu nhiên]2Không thực hiện các thay đổi không được yêu cầu.3"Đã sửa nó trong lúc rảnh" hoặc "đã tạo một thiết kế tốt hơn" bị nghiêm cấm.4Nếu bạn tìm thấy các khu vực liền kề cần cải thiện, hãy liệt kê chúng như các đề xuất thay vì thực hiện chúng.
Thứ tư là báo cáo xác minh.
1[Báo cáo 'đã xác minh' thay vì 'nó hoạt động']2Báo cáo hoàn thành phải bao gồm bằng chứng như các lệnh xác minh đã thực thi, giá trị trả về, kết quả kiểm tra và xác nhận ảnh chụp màn hình.3Không viết "nó sẽ hoạt động" cho những thứ chưa được thực thi.4Nêu rõ lý do cho bất kỳ xác minh nào bị bỏ qua.
Thứ năm là cách kiên trì vượt qua cùng một thất bại. Kiên trì rất quan trọng, nhưng kiên trì theo hướng sai sẽ lãng phí thời gian.
1[Tối đa 2 lần thử lại cho cùng một lỗi]2Nếu một bản sửa lỗi cho cùng một lỗi thất bại hai lần, đừng thử biến thể thứ ba.3Báo cáo ngắn gọn trạng thái hiện tại, những gì đã thử và các giả thuyết còn lại, sau đó thay đổi hướng đi.
Thứ sáu là vai trò của người phản biện.
1[Thực hiện đánh giá lần đọc đầu tiên trước khi hoàn thành]2Trước báo cáo hoàn thành, hãy xem xét các thay đổi của bạn như thể đang đọc chúng lần đầu tiên.3Xác định một chức năng liền kề có thể bị hỏng.4Viết những gì một người đàn anh hoài nghi sẽ nói để phản đối, và trả lời sự phản đối đó.
Thứ bảy là sự tự tin và tiến độ trung thực. Điều này phản ánh sự tự phân tích của chính Sonnet 5.
1[Báo cáo sự tự tin và tiến độ trong 3 điểm]2Đính kèm mức độ tự tin (Cao, Trung bình, Thấp) vào các phần không chắc chắn.3Nếu độ tự tin là Trung bình hoặc Thấp, hãy hỏi xem bạn có nên xác nhận trước khi tiếp tục không.4Trong các tác vụ dài, chỉ báo cáo ba điểm sau tại mỗi cột mốc:5Những gì đã hoàn thành. Những gì cần làm tiếp theo. Những gì bạn đang lo lắng.6Các báo cáo chỉ bao gồm "tiến hành không có vấn đề gì" bị nghiêm cấm.
7 mẹo này không phải là cài đặt để thêm khả năng.
Chúng là các cài đặt chủ động chặn các chế độ thất bại nơi khoảng cách xuất hiện.
Đừng rơi vào hố thông số kỹ thuật. Đừng tự quyết định những điều mơ hồ. Đừng thổi phồng phạm vi. Đừng tuyên bố hoàn thành mà không xác minh. Đừng tiếp tục một kế hoạch sai lầm.
Tóm lại, chúng ta đang gắn kết bên ngoài các hành vi mà Fable 5 làm một cách tự nhiên vào môi trường của Sonnet 5.
Những Gì Chúng Ta Thấy Trong So Sánh
Điều thú vị là câu trả lời của Sonnet 5 và Fable 5 khớp nhau đáng kể ngay cả khi được hỏi riêng rẽ.
Đầu tiên, đừng tự ý chọn nhiều cách hiểu.
Cả hai đều nói điều này. Khi được đưa ra các hướng dẫn mơ hồ, AI có xu hướng chọn một cách hiểu hợp lý và tiến hành. Từ góc nhìn của con người, bạn nghĩ, "Tôi muốn bạn kiểm tra điều đó."
Tiếp theo, ngoại hóa việc xác minh.
Thay vì để nó nói "nó hoạt động," hãy bắt nó xuất ra những gì nó đã thực thi, những gì đã vượt qua và những gì nó đã thấy. Ngay cả trong các phương pháp hay nhất chính thức, việc cho Claude một cách để xác minh công việc của chính nó được coi là quan trọng nhất.
Cung cấp các kiểm tra dẫn đến kết quả đạt hoặc không đạt, như kiểm tra, bản dựng hoặc so sánh ảnh chụp màn hình. Điều này đóng vòng lặp.
Hơn nữa, việc tách biệt đôi mắt xác minh là rất lớn.
Nếu người tạo tự chấm điểm cho mình, họ sẽ dễ dãi. Hãy có một tác nhân phụ xác minh trong một ngữ cảnh mới kiểm tra sự khác biệt so với kế hoạch. Nó giống như có một người đánh giá riêng biệt với tác giả trong thuật ngữ của con người.
Và cuối cùng, khoảng cách không thể thu hẹp cũng khớp nhau.
Duy trì ngữ cảnh dài hạn.
Trong một công việc liên quan đến hàng chục lệnh gọi công cụ và kéo dài vài giờ, khả năng duy trì các ràng buộc được quyết định lúc đầu cho đến cuối cùng. Điều này không thể được lấp đầy hoàn toàn chỉ bằng CLAUDE.md.
Nếu tôi che giấu điều này, bài viết sẽ trở thành một lời nói dối.
Những Bước Hoàn Thiện Về Phía Môi Trường
Nó không kết thúc chỉ với việc viết CLAUDE.md.
Sonnet 5 có cài đặt effort để chỉ định độ sâu của suy nghĩ. Trong các bảng tương ứng chính thức, "medium" của Sonnet 5 tương đương với "high" của Sonnet 4.6, và "high" của Sonnet 5 tương đương với "max" của Sonnet 4.6.
Nếu bạn thấy suy luận nông cạn, hãy tăng effort thay vì điều chỉnh lời nhắc. Đây là khuyến nghị chính thức.
Nếu bạn muốn Claude Code luôn suy nghĩ sâu sắc, hãy thêm nội dung sau vào settings.json:
"effortLevel": "high"
Điều này đẩy Sonnet 5 về phía "kiên trì" ngay từ đầu.
Tuy nhiên, CLAUDE.md không nên chỉ dài.
Lý tưởng nhất là nó nên dưới 60 dòng. Tối đa là 200 đến 300 dòng. Đối với mỗi dòng, hãy tự hỏi, "Nếu tôi xóa dòng này, Claude có mắc lỗi không?" Nếu câu trả lời là Không, hãy xóa nó.
Đừng viết những thứ có thể suy luận từ mã nguồn. Đừng viết các thông lệ tiêu chuẩn. Hãy để những gì có thể được xử lý bởi một trình linter cho trình linter.
Những gì bạn nên viết là các lệnh khó đoán, các thực hành độc đáo, cách chạy kiểm tra, cạm bẫy và các quyết định kiến trúc.
Đặt các hướng dẫn quan trọng ở đầu. Sử dụng các từ mạnh như "Phải" hoặc "Nghiêm cấm" thay vì "Khuyến nghị."
CLAUDE.md không phải là một lá thư yêu cầu gửi đến AI. Nó là các quy tắc làm việc của nhóm.
Các Tình Huống Bạn Vẫn Nên Sử Dụng Fable 5
Sau khi đọc đến đây, bạn có thể nghĩ, "Vậy thì tôi không cần Fable 5 nữa sao?"
Không.
Fable 5 là cần thiết. Tuy nhiên, bạn nên thu hẹp phạm vi sử dụng nó.
Khoảng cách có thể thu hẹp là trong công việc mà câu trả lời đúng có thể được đánh giá một cách máy móc.
Các bản sửa lỗi triển khai có thể được đánh giá bằng các bài kiểm tra. Phân loại, trích xuất và tóm tắt hàng loạt. Các thay đổi nhỏ mà một người sẽ xem xét anyway. Sonnet 5 với một CLAUDE.md tốt có thể cạnh tranh tốt trong các tác vụ này.
Các khoảng cách không thể thu hẹp chủ yếu là ba:
1. Công việc mà không thể viết được một công cụ kiểm tra.
Thiết kế này có ổn không? Có lỗ hổng nào trong kế hoạch di chuyển này không? Ngay từ đầu nên xây dựng cái gì? Nếu việc viết các tiêu chí chấp nhận chính là cốt lõi của công việc, bạn không thể chạy một vòng lặp xác minh trước.
2. Phán xét về việc áp dụng quy tắc.
Ngay cả khi bạn viết "giữ nó đơn giản," mô hình quyết định thế nào là đơn giản. Ngay cả khi bạn viết "đừng trừu tượng hóa nếu không được phép," nơi trừu tượng hóa bắt đầu thay đổi theo tình huống.
3. Duy trì ngữ cảnh dài hạn.
Đây là sự khác biệt về sức mạnh thô. Trong khi các lời nhắc có thể cải thiện nó, nó sẽ không biến mất hoàn toàn.
Các tiêu chí phán xét do chính Fable 5 cung cấp là thực tế nhất.
Nếu bạn có thể viết bài kiểm tra chấp nhận trước, hãy sử dụng Sonnet. Nếu việc viết bài kiểm tra chấp nhận tự nó khó khăn, hãy sử dụng Fable. Nếu không chắc chắn, hãy bắt đầu với Sonnet, và chỉ chuyển sang Fable cho các tác vụ dẫn đến hai lần làm lại liên tiếp.
Tôi nghĩ điều này là ổn.
Bạn không cần phải ném mọi thứ cho Fable ngay từ đầu. Ngược lại, nói rằng mọi thứ có thể được xử lý bởi Sonnet cũng là bất cẩn.
Bắt đầu với Sonnet rẻ hơn. Giảm thất bại bằng cấu trúc. Chuyển sang Fable sau hai lần thất bại.
Đây là cách thực tế để phân biệt cách sử dụng sau ngày 8 tháng 7.
Những Gì Cần Làm Hôm Nay
Đầu tiên, hãy dán 7 mẹo từ bài viết này vào CLAUDE.md của dự án bạn.
Tiếp theo, đặt effortLevel thành high trong settings.json.
Sau đó, cho tác vụ tiếp theo của bạn, hãy đảm bảo bắt nó xuất ra "Điều kiện Thành công," "Nhiều Cách hiểu," và "Báo cáo Xác minh."
Đối với các tác vụ dài, hãy tách biệt vai trò triển khai và vai trò xác minh. Đừng để người tạo tự chấm điểm cho mình; hãy cho Claude xem trong một ngữ cảnh khác.
Và chỉ chuyển sang Fable 5 cho các tác vụ mà việc làm lại tiếp tục hai lần.
Ngay cả khi thời gian miễn phí của Fable 5 kết thúc, những gì kết thúc chỉ là thời gian dùng thử miễn phí.
Những gì bạn thực sự nên giữ lại là hành vi của Fable 5.
Biến Sonnet 5 thành Fable 5.
Bước đầu tiên không phải là dán các lời nhắc ma thuật dài mỗi lần.
Đó là đặt khuôn mẫu công việc trong CLAUDE.md.
Nhưng sau khi đọc đến đây, chắc hẳn bạn đã nghĩ:
"Tôi hiểu các cài đặt. Nhưng tôi không biết xây dựng cái gì hoặc kiếm tiền như thế nào với AI nâng cấp này."
Ngược lại. AI đã trở nên rẻ hơn và thông minh hơn trước tiên nên được sử dụng để sản xuất hàng loạt nội dung thu hút khách hàng. Nếu bạn có thể tích hợp sự kiên trì ở cấp độ Fable vào Sonnet, bạn có thể chạy các bài đăng hàng ngày, bài viết, kênh bán hàng, ý tưởng sản phẩm và vòng lặp cải tiến với chi phí thấp.
Các chi tiết cụ thể được tóm tắt trong bài viết ghim của tôi. Đối với những ai nghiêm túc muốn "sử dụng AI một cách rẻ và thông minh để kết nối với việc thu hút khách hàng và kiếm tiền," vui lòng vào đây ↓
