Cập nhật: 13/07/2026
Trong vài tuần gần đây, cộng đồng AI nói rất nhiều về Fable 5: model mạnh, suy luận tốt, làm việc dài hơi ổn, nhưng quyền truy cập và chi phí có thể thay đổi bất cứ lúc nào.
Nhiều người phản ứng bằng cách hỏi: “Fable 5 có còn đáng trả tiền không?”
Mình nghĩ câu hỏi đó chưa phải câu quan trọng nhất.
Model không phải thứ đáng giữ nhất. Cách model làm việc mới là thứ đáng sao chép.
Nếu ngày mai Fable 5 bị giới hạn, tăng giá, hoặc không còn nằm trong gói bạn đang dùng, bạn không thể giữ lại trọng số của model. Nhưng bạn có thể giữ lại cách nó đọc đề bài, chia nhỏ vấn đề, tìm điểm rủi ro, tự phản biện, kiểm chứng và báo cáo kết quả.
Đó là điểm rất dễ bị bỏ lỡ trong các cuộc tranh luận về model. Khi một model mạnh sắp trở nên đắt hơn hoặc khó dùng hơn, phản xạ của nhiều người là tiếc nuối. Nhưng hướng đi thông minh hơn là thu hoạch nó: dùng chính model đó để viết lại cách nó vận hành, trước khi bạn không còn dùng nó thoải mái như cũ.
Nói cách khác: bạn không sở hữu trí thông minh thô của model, nhưng bạn có thể sở hữu quy trình tư duy mà model đó để lại.
Bài này sẽ hướng dẫn cách biến “cách nghĩ kiểu Fable 5” thành một tài liệu vận hành để Opus 4.8, Sonnet hoặc một model rẻ hơn làm việc có kỷ luật hơn. Đây không phải cách biến Opus thành Fable thật sự. Đây là cách làm cho Opus làm việc giống một người đã được huấn luyện tốt hơn: biết scope trước, tìm bằng chứng trước, tự phản biện, verify ở đúng tầng, rồi báo cáo có căn cứ.
Nói gọn hơn: nếu bạn đang tìm cách tạo Opus 4.8 suy nghĩ như Fable 5, thứ cần sao chép không phải “độ thông minh” của Fable, mà là operating manual phía sau cách nó làm việc.
Vì sao model không phải tài sản thật sự?
Mọi model AI rồi sẽ thay đổi. Model hôm nay rất mạnh, ngày mai có thể bị thay giá, đổi giới hạn, thay bằng phiên bản mới, hoặc bị route sang model khác trong một số tác vụ.
Nếu toàn bộ quy trình làm việc của bạn phụ thuộc vào một model cụ thể, bạn đang xây hệ thống trên đất thuê. Chủ đất đổi luật là bạn bị ảnh hưởng ngay.
Nhưng có một thứ bền hơn model: cách làm việc được viết thành văn bản.
Một model mạnh thường hơn model yếu ở vài thói quen quan trọng:
- Nó không chỉ đọc chữ trên bề mặt, mà cố hiểu yêu cầu thật sự phía sau.
- Nó biết chia việc khó thành từng phần có thể kiểm tra riêng.
- Nó biết điểm nào trong bài toán là rủi ro lớn nhất.
- Nó không tin một câu trả lời chỉ vì nghe có vẻ hợp lý.
- Nó tự tách cái đã biết khỏi cái đang đoán.
- Nó tự phản biện kết luận trước khi đưa cho bạn.
Những thói quen này không nằm hoàn toàn trong “ma thuật” của model. Phần lớn có thể viết thành một operating manual: tài liệu hướng dẫn cách làm việc mà model khác có thể đọc và làm theo.
Ví dụ dễ hình dung: nếu đưa Fable 5 cho một người mới dùng AI, rồi đưa một model yếu hơn cho một người rất giỏi thiết kế hệ thống và prompt, kết quả của người thứ hai vẫn có thể tốt hơn. Khác biệt không chỉ nằm ở model, mà nằm ở cách người đó hướng dẫn model, chia việc, tạo vòng lặp, kiểm chứng và buộc model báo cáo đúng cách.
Vì vậy, mục tiêu không phải là cố “giữ” Fable mãi mãi. Mục tiêu là giữ lại phần có thể chuyển giao: process.
Anthropic cũng minh họa Fable 5 bằng các tác vụ dài và giàu ngữ cảnh, như chơi Pokémon FireRed chỉ bằng vision, không cần bản đồ hay trạng thái game bổ sung. Nhưng với người làm việc thực tế, thứ đáng học không phải là “làm sao bắt model chơi game”, mà là cách model mạnh duy trì mục tiêu, quan sát trạng thái, tự điều chỉnh và đi tiếp.
Đừng hỏi Fable “bạn suy nghĩ thế nào”
Sai lầm phổ biến là hỏi model mạnh một câu rất chung:
Hãy giải thích cách bạn suy nghĩ.
Câu này thường trả về một đoạn nghe rất hay nhưng dùng không được: “tôi phân tích kỹ”, “tôi kiểm tra thông tin”, “tôi cân nhắc nhiều góc nhìn”. Vấn đề là những câu đó quá mơ hồ. Model yếu hơn đọc xong vẫn không biết phải làm gì ở bước tiếp theo.
Điều bạn cần không phải là mô tả cảm tính. Bạn cần quy trình đủ cụ thể để model khác có thể chạy.
Ví dụ:
- “Kiểm tra lại số liệu” là khẩu hiệu.
- “Với mọi chỉ số phần trăm, hãy tự tính lại từ hai đầu dữ liệu gốc trước khi chấp nhận kết luận” là thao tác.
Khác biệt nằm ở đó. Một skill tốt không nói “hãy cẩn thận”. Nó nói rõ phải cẩn thận ở đâu, kiểm tra bằng gì, và lỗi nào cần tránh.
Đây cũng là lý do bài gốc nhấn mạnh: đừng yêu cầu một bản tóm tắt. Hãy yêu cầu một manual mà model thay thế có thể chạy khi bạn không ngồi cạnh nó. Manual phải giống hướng dẫn bàn giao nghề từ một senior operator cho một junior thông minh, không phải một danh sách khẩu hiệu đạo đức nghề nghiệp.
Prompt để trích xuất “manual” từ model mạnh
Nếu bạn còn quyền dùng một model mạnh, hãy dùng nó như một người thầy sắp bàn giao nghề cho đội ngũ kế tiếp. Đừng bắt nó làm toàn bộ việc lặt vặt. Hãy bắt nó viết ra cách nó làm việc.
Bạn có thể dùng prompt sau:
Bạn là model mạnh nhất trong tài khoản của tôi. Tôi muốn trích xuất cách bạn làm việc để một model thấp hơn, ví dụ Opus 4.8, có thể chạy theo cùng kỷ luật tư duy.
Hãy viết một operating manual cho model thay thế. Viết như một senior operator đang bàn giao nghề cho một junior rất thông minh nhưng chưa có cùng độ phán đoán.
Hãy trình bày theo thứ tự:
1. Cách đọc yêu cầu thật sự phía sau câu chữ.
2. Cách chia vấn đề khó thành các phần có thể kiểm tra độc lập.
3. Cách xác định rủi ro lớn nhất và nơi cần dồn công sức.
4. Cách kiểm chứng một kết luận bằng cách tự suy ra lại, không tin vì nghe hợp lý.
5. Cách tách rõ điều đã biết, điều đang giả định, và điều cần kiểm tra thêm.
6. Cách tự phản biện kết luận trước khi bàn giao.
7. Cách báo cáo: trả lời trước, sau đó nêu bằng chứng, sau cùng nêu rủi ro.
8. Những lỗi trông có vẻ chuyên nghiệp nhưng thật ra là dấu hiệu làm việc ẩu.Với mỗi phần, hãy đưa ra: quy trình cụ thể, một ví dụ ngắn, và lỗi mà quy trình đó giúp tránh. Cuối cùng, viết 5 câu hỏi tự kiểm tra mà model phải chạy trước khi trả lời.
Nếu model trả lời quá ngắn, đừng hỏi lại từ đầu. Hãy yêu cầu nó mở rộng đúng phần yếu nhất, ví dụ:
Phần kiểm chứng vẫn còn chung chung. Hãy viết lại thành các thao tác cụ thể mà Opus 4.8 có thể làm theo, kèm ví dụ business, content và coding.
Sau vài vòng, bạn sẽ có một tài liệu quan trọng hơn nhiều so với một câu trả lời hay: bạn có một hệ điều hành tư duy có thể dùng lại.
Một manual tốt thường có ba thành phần trong từng mục:
- Procedure: model phải làm gì, theo thứ tự nào.
- Example: một ví dụ ngắn để model hiểu thao tác trong ngữ cảnh thật.
- Failure prevented: lỗi cụ thể mà thao tác đó giúp tránh.
Thiếu một trong ba phần này, manual rất dễ trở thành một đoạn văn nghe hay nhưng không điều khiển được hành vi.
Fable Mode: vòng 5 cổng để Opus làm việc kỷ luật hơn
Một cách gói manual này rất dễ hiểu là biến nó thành “Fable Mode”: một skill hoặc project instruction buộc model đi qua 5 cổng trước khi bàn giao kết quả.
Cổng 1: Scope trước khi làm
Trước khi chạm vào việc, model phải định nghĩa “xong” nghĩa là gì.
- Đầu ra cuối cùng là gì?
- Điều gì bắt buộc phải đúng?
- Cách kiểm tra kết quả là gì?
- Có giả định nào nếu sai sẽ làm hỏng toàn bộ hướng đi không?
Nếu model chưa nói được cách kiểm tra, nghĩa là nó chưa hiểu việc đủ rõ.
Cổng 2: Evidence trước khi suy luận
Không thiết kế từ trí nhớ. Không đoán file, API, số liệu hoặc thị trường “có lẽ là như vậy”. Phải nhìn dữ liệu thật nếu có thể.
Trong công việc thực tế, cổng này có nghĩa là: mở file thật, xem dashboard thật, đọc transcript thật, kiểm tra landing page thật, hoặc dùng nguồn mới nhất nếu thông tin có thể đã thay đổi.
Cổng 3: Attack trước khi chốt
Trước khi tin vào câu trả lời của mình, model phải đổi vai thành reviewer khó tính.
- Điều gì có thể khiến kết luận này sai?
- Có metric nào đang bị hiểu nhầm không?
- Có baseline nào bị đổi giữa chừng không?
- Có cách giải thích khác hợp lý hơn không?
Đây là phần nhiều model bỏ qua. Chúng thường đi tiếp vì câu trả lời nghe trơn tru, không phải vì câu trả lời đã được kiểm tra.
Cổng 4: Verify trước khi nói xong
“Nghe đúng” không phải là kiểm chứng. “Chạy không lỗi” cũng chưa chắc là kiểm chứng nếu claim của bạn nằm ở tầng khác.
Nếu claim là “bài viết dễ hiểu”, hãy đọc lại như người mới. Nếu claim là “trang render ổn”, hãy mở trang. Nếu claim là “chiến dịch hiệu quả hơn”, hãy tính lại unit economics thay vì nhìn một metric đẹp.
Cổng 5: Report có căn cứ
Báo cáo cuối cùng phải tách rõ:
- Cái gì đã xác minh.
- Cái gì đang giả định.
- Đã kiểm tra bằng cách nào.
- Rủi ro còn lại là gì.
Đây là điểm làm output đáng tin hơn. Model không cần tỏ ra biết tất cả. Nó cần nói rõ mình biết đến đâu.
Nạp manual vào Opus 4.8: transplant không phải copy-paste cho vui
Sau khi có manual, bước tiếp theo là đưa nó vào nơi Opus 4.8 thật sự đọc trước khi làm việc. Nếu manual chỉ nằm trong một đoạn chat cũ, nó không giúp gì nhiều.
Có ba cách đơn giản:
- Project instructions: tạo một project riêng, dán manual vào hướng dẫn dự án, rồi chọn Opus 4.8 hoặc model bạn muốn dùng.
- System prompt qua API: nếu bạn dùng API, đưa manual vào phần system để mọi request đều thừa hưởng kỷ luật đó.
- Skill file: nếu bạn dùng môi trường agent như Claude Code hoặc Codex, đóng gói manual thành file skill để gọi lại khi gặp task nhiều tầng.
Điểm quan trọng là manual phải được nạp trước nhiệm vụ cụ thể. Nếu bạn chỉ dán ở cuối prompt, model có thể xem nó như một ghi chú phụ thay vì kỷ luật vận hành.
Hãy nghĩ về bước này như một ca chuyển giao vận hành. Fable không còn trực tiếp làm mọi việc. Fable viết sổ tay. Opus đọc sổ tay đó trước khi nhận nhiệm vụ. Nếu làm đúng, Opus không thông minh ngang Fable, nhưng nó có thể làm việc giống một model được huấn luyện kỹ hơn.
Chứng minh transplant có thật sự hoạt động
Đây là bước nhiều hướng dẫn hay bỏ qua. Nạp manual vào model không có nghĩa là model đã thật sự dùng manual. Bạn phải kiểm tra bằng một câu hỏi có bẫy.
Một số ví dụ phổ biến dùng phép tính rất dễ, kiểu doanh thu từ 4.0M lên 4.2M mà gọi là tăng 20%. Bẫy đó bây giờ hơi yếu, vì phần lớn model mới đều bắt được.
Bẫy tốt hơn nên nằm ở định nghĩa metric, baseline, hoặc unit economics.
Ví dụ, hãy đưa cùng một câu hỏi cho Opus 4.8 thường và Opus 4.8 có Fable Mode:
Tháng này chi phí lead giảm từ 120.000đ xuống 80.000đ. Team marketing muốn tăng gấp đôi ngân sách vì lead rẻ hơn 33%. Nhưng tỷ lệ chốt từ lead sang khách giảm từ 8% xuống 3%. Có nên duyệt scale không?
Model trả lời hời hợt sẽ tập trung vào “lead rẻ hơn” và có thể khuyên scale có điều kiện.
Model có kỷ luật verify phải tự tính lại chi phí để có một khách hàng thật:
- Trước đây: 120.000đ / 8% = 1.500.000đ cho một khách hàng.
- Bây giờ: 80.000đ / 3% = khoảng 2.666.667đ cho một khách hàng.
Lead rẻ hơn, nhưng khách hàng thật lại đắt hơn. Nếu chỉ nhìn CPL, team sẽ scale một chiến dịch đang làm xấu unit economics.
Đây mới là kiểu test hữu ích cho AI business. Không phải kiểm tra AI có biết chia số không, mà kiểm tra AI có biết dừng lại để hỏi metric đẹp đó có đang đánh lừa mình không.
Cách test đúng là chạy hai phiên bản:
- Opus 4.8 bình thường, không có manual.
- Opus 4.8 có Fable Mode/manual được nạp trước.
Nếu bản có manual tự dừng lại, tính lại cost per customer, chỉ ra metric bị đánh tráo và từ chối scale ngay, transplant bắt đầu có tác dụng. Nếu nó vẫn trả lời chung chung, phần verification trong manual còn quá mềm. Khi đó, quay lại model mạnh và yêu cầu viết lại phần kiểm chứng thành thao tác cụ thể hơn.
Một bài test tốt đáng giá hơn một lời hứa. Bạn không đoán manual có hoạt động không. Bạn nhìn model bắt lỗi bằng chính mắt mình.
Spending logic: khi nào dùng model đắt, khi nào dùng model rẻ?
Bài học lớn hơn từ trend Fable 5 không phải là “hãy cố giữ Fable bằng mọi giá”. Bài học đúng hơn là: hãy dùng model mạnh đúng vai.
Một hệ thống AI tốt nên có bảng phân vai trong đầu:
- Thiết kế quy trình, viết manual, quyết định khó: dùng model mạnh nhất bạn có, vì đây là tài sản dùng lại lâu dài.
- Viết nháp, triển khai theo kế hoạch, phân tích vừa phải: dùng Opus/Sonnet hoặc model trung bình tốt, vì cần đủ thông minh nhưng không nhất thiết đắt nhất.
- Tóm tắt, phân loại, quét dữ liệu, scout thông tin: dùng model rẻ hơn, vì đây là tác vụ lặp lại, rủi ro thấp và dễ kiểm tra.
- Review cuối, phát hiện lỗi logic, kiểm tra rủi ro: dùng model mạnh hoặc model có manual tốt, vì đây là nơi lỗi nhỏ có thể gây hậu quả lớn.
Nguyên tắc rất đơn giản:
Cái gì tháng sau vẫn dùng lại, hãy đầu tư model mạnh để làm kỹ. Cái gì dùng xong bỏ, hãy chạy bằng model rẻ hơn.
Manual, skill, checklist, prompt hệ thống, workflow agent là tài sản. Bản nháp, tóm tắt nhanh, phân loại dữ liệu, dọn format là tiêu hao.
Đây là logic chi phí rất thực tế. Một lần dùng model mạnh để tạo manual có thể tiếp tục trả lợi ích trong hàng trăm lần gọi model rẻ hơn sau này. Ngược lại, nếu bạn dùng model mạnh nhất để viết từng bản nháp dùng xong bỏ, bạn đang trả tiền cho throughput chứ không tạo ra tài sản.
Cách chia đơn giản:
- Tài sản: system prompt, skill, operating manual, checklist review, quyết định chiến lược, quy trình có thể dùng lại.
- Tiêu hao: bản nháp, tóm tắt nhanh, phân loại sơ bộ, format lại nội dung, quét dữ liệu dễ kiểm tra.
Model mạnh nên dùng để tạo tài sản. Model rẻ nên dùng để chạy tiêu hao dưới sự kiểm soát của tài sản đó.
Biến việc lặp lại hằng tuần thành skill
Sau khi đã có “Fable Mode” tổng quát, bước tiếp theo là làm điều tương tự cho các workflow cụ thể của bạn.
Ví dụ, nếu mỗi tuần bạn đều phải nghiên cứu thị trường, viết content, soạn email, tạo landing page hoặc phân tích số liệu ads, hãy để model mạnh phỏng vấn bạn rồi viết thành skill.
Hãy phỏng vấn tôi về workflow [tên workflow], mỗi lần một câu hỏi, cho đến khi bạn hiểu rõ tôi làm việc đó như thế nào, output tốt trông ra sao, lỗi nào hay gặp, và tiêu chuẩn chất lượng là gì.
Sau khi phỏng vấn xong, hãy viết thành một skill document hoàn chỉnh để trợ lý AI tương lai có thể làm theo, bao gồm: trigger khi nào dùng, quy trình từng bước, checklist kiểm tra, lỗi cần tránh, và tiêu chuẩn bàn giao.
Đây là cách biến kinh nghiệm làm việc của bạn thành tài sản. Không chỉ model học bạn, mà hệ thống của bạn bắt đầu có trí nhớ vận hành.
Ứng dụng vào GiangXAI Lab
Đây cũng là lý do mình thích cách xây AI agent theo bộ quy trình thay vì chỉ sưu tầm prompt lẻ.
Một AI agent làm research không chỉ cần “tìm thông tin”. Nó cần biết khi nào phải kiểm chứng nguồn, khi nào không được suy luận từ trí nhớ, khi nào phải báo là thiếu dữ liệu.
Một AI agent viết content không chỉ cần “viết hay”. Nó cần biết hook nào hợp nền tảng, ví dụ nào đủ gần với thị trường Việt Nam, CTA nào tự nhiên, và khi nào nội dung đang nghe như báo cáo chứ không giống lời nói.
Một AI agent làm landing page không chỉ cần “viết sales page”. Nó cần biết offer là gì, objection nằm ở đâu, proof nào đáng tin, và phần nào cần đưa lên trước để người đọc không rời trang.
Trong GiangXAI Lab, hướng đi là đóng gói AI thành hệ thống agent có vai trò rõ: research, content, video, landing page, thanh toán/giao hàng, analytics và growth. Giá trị không nằm ở một model cụ thể, mà nằm ở bộ quy trình để model nào cũng có thể làm việc đúng vai hơn.
Nếu bạn muốn tự xây, hãy bắt đầu bằng manual trong bài này. Nếu bạn muốn có một bộ khung agent/skill thực chiến cho thị trường Việt Nam để triển khai nhanh hơn, bạn có thể tham khảo thêm hệ sinh thái GiangXAI Lab.
FAQ
Có thể thật sự biến Opus 4.8 thành Fable 5 không?
Không. Manual không chuyển được raw intelligence của Fable 5 sang Opus 4.8. Nhưng manual có thể chuyển được kỷ luật làm việc: cách scope, tìm bằng chứng, tự phản biện, kiểm chứng và báo cáo. Kết quả là Opus không trở thành Fable, nhưng có thể làm việc giống một model được hướng dẫn tốt hơn.
Fable Mode khác gì một prompt dài?
Một prompt dài chỉ hữu ích nếu nó có quy trình cụ thể. Fable Mode không nên là đoạn văn chung chung kiểu “hãy cẩn thận”. Nó phải có gate, checklist, ví dụ, lỗi cần tránh và tiêu chuẩn bàn giao. Điểm khác biệt nằm ở khả năng điều khiển hành vi của model.
Khi nào nên dùng model mạnh nhất?
Nên dùng model mạnh nhất cho những thứ còn dùng lại lâu dài: operating manual, skill, system prompt, workflow agent, checklist kiểm chứng hoặc quyết định khó. Với bản nháp, tóm tắt, phân loại và tác vụ lặp lại dễ kiểm tra, model rẻ hơn thường hợp lý hơn.
Làm sao biết manual đã hoạt động?
Hãy test bằng câu hỏi bẫy có lớp ngữ cảnh. Đưa cùng một câu hỏi cho model thường và model có manual. Nếu model có manual biết dừng lại, tự tính lại, chỉ ra giả định sai hoặc metric bị đánh tráo, manual đang có tác dụng. Nếu không, phần verify trong manual cần viết lại cụ thể hơn.
Kết luận
Trend Fable 5 có thể qua đi. Nhưng bài học phía sau nó sẽ còn lâu: model mạnh nhất không phải lúc nào cũng là lợi thế bền vững nhất.
Cách tạo Opus 4.8 suy nghĩ như Fable 5 không nằm ở một prompt thần kỳ. Nó nằm ở việc biến cách làm việc của model mạnh thành manual, rồi kiểm tra xem model rẻ hơn có thật sự dùng manual đó không.
Lợi thế thật sự nằm ở việc bạn có biết biến một lần dùng model mạnh thành tài sản dùng lại hay không.
Hãy dùng model mạnh để viết manual, tạo skill, đặt tiêu chuẩn kiểm chứng và thiết kế hệ thống. Sau đó để những model rẻ hơn làm phần việc phù hợp với chúng.
Đừng chỉ thuê AI thông minh. Hãy bắt AI thông minh viết lại cách nó làm việc, rồi biến cách đó thành hệ thống của bạn.