Kỹ thuật Prompt Claude Fable 5.1: Khắc phục mọi thay đổi hành vi chỉ với một dòng lệnh

Tối ưu prompt cho Claude Fable 5.1: 15 thay đổi cần kiểm tra

Anthropic cho biết các prompt Fable 5 hiện có sẽ hoạt động tốt trên Claude Fable 5.1 mà không cần thay đổi. Tuy nhiên, hành vi xung quanh câu trả lời đã khác: số lệnh gọi công cụ được gộp trong mỗi lượt, lượng cập nhật tiến độ, mật độ văn xuôi, cách định dạng hội thoại, việc viết lại tệp, phạm vi công việc và thời điểm mô hình xin phép. Mỗi khác biệt đều có cách khắc phục cụ thể trong hướng dẫn prompting Claude Fable 5.1.

Dùng thử Apidog ngay hôm nay

Bài viết này tổng hợp các thay đổi quan trọng, prompt mẫu và cách kiểm thử trước/sau. Xem thêm Claude Fable 5.1 là gì để có cái nhìn tổng quan về mô hình.

1. Điều chỉnh Effort trước khi sửa prompt

Effort là nút điều khiển chính để cân bằng trí thông minh, độ trễ và chi phí trên Fable 5.1.

Quy trình nên dùng:

1. Bắt đầu với high.
2. Chạy lại bộ đánh giá với bốn cấp độ còn lại.
3. So sánh với các tiêu chí riêng của sản phẩm.
4. Đừng giả định cùng một cấp độ tạo ra cùng lượng suy nghĩ như trên Fable 5.

Theo Anthropic:

• medium thường gần tương đương Fable 5 nhưng chi phí thấp hơn.
• low có thể cạnh tranh với Opus và Sonnet về chi phí mỗi tác vụ, đồng thời đạt điểm cao hơn trong một số bài kiểm thử.
• Lợi ích so với Fable 5 rõ nhất ở xhigh và max.

Tham khảo hướng dẫn Effort.

Fable 5.1 cũng cho phép thay đổi Effort giữa cuộc trò chuyện mà không cần reset prompt cache, bằng tin nhắn hệ thống rỗng kết hợp với output_config và beta header mid-conversation-output-config-2026-07-01. Xem hướng dẫn API để biết cấu trúc request.

2. Vị trí của instruction quan trọng hơn câu chữ

Các khối suy nghĩ được bảo toàn của Fable 5.1 chỉ hợp lệ trong đúng cuộc trò chuyện đã tạo ra chúng. Nếu chèn prompt vào một lượt trước đó rồi xóa prompt trong request tiếp theo, bạn đang chỉnh sửa lịch sử:

• Prompt cache bị khởi động lại.
• Với các tài khoản được tạo từ ngày 31/08/2026 trở đi, những khối suy nghĩ phía sau sẽ bị vô hiệu hóa.

Xem thêm về preserved thinking.

Instruction theo từng lượt

Nếu dùng beta mid-conversation-system-clear-at-2026-08-21, hãy thêm instruction dưới dạng tin nhắn hệ thống theo phạm vi lượt, đặt sau kết quả công cụ:

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "..."
}

Giữ nguyên mọi bản sao trước đó trong mảng. Khi tin nhắn người dùng tiếp theo xuất hiện, API sẽ xóa các bản sao cũ; chúng không tiếp tục tiêu tốn token.

Nếu không dùng beta này, hãy đặt instruction trong một khối văn bản sau các khối tool_result của cùng tin nhắn người dùng. Vẫn giữ các bản sao trước đó.

Không xóa hoặc viết lại một bản sao đã gửi.

Xem mid-conversation system messages và hướng dẫn preserved thinking.

Instruction cấp phiên

Đặt instruction cấp phiên trong system prompt hoặc tin nhắn người dùng đầu tiên. Anthropic lưu ý rằng instruction về phong cách đặt trong tin nhắn người dùng đầu tiên thường hiệu quả hơn cùng nội dung đặt trong system prompt.

3. Tác nhân có thể chỉ gọi một công cụ mỗi lượt

Khi yêu cầu lấy nhiều dữ liệu, Fable 5.1 vẫn có thể phát hành các lệnh gọi song song. Tuy nhiên, trong vòng lặp coding hoặc computer-use, các lần đọc độc lập chỉ được ngụ ý có thể bị tách thành một lệnh gọi mỗi lượt, trong khi Fable 5 thường gộp chúng.

Điều này làm tăng:

• Số lượt hội thoại.
• Số token.
• Round trip.
• Thời gian thực thi.

Trước khi thêm prompt khắc phục, hãy đo tỷ lệ lượt assistant có nhiều hơn một tool_use. Chỉ thêm prompt nếu tỷ lệ này thực sự giảm:

Privately list the separate things you need next; then request every item that does not depend on another item's result in this response.

Từ privately nên được giữ lại. Nếu bỏ từ này, mô hình đôi khi trả lời người dùng thay vì thực hiện việc lập danh sách nội bộ.

Đặt instruction trên dưới dạng system prompt theo từng lượt, ngay sau mỗi tool result. Một câu gần cuối của tin nhắn hiện tại thường ảnh hưởng đến số lượng lệnh gọi mạnh hơn cùng nội dung trong system prompt.

4. Ít cập nhật giữa các lần gọi công cụ

Fable 5.1 thường gửi ít cập nhật tiến độ hơn Fable 5 trong các lượt gọi công cụ dài, đặc biệt ở Effort cao. Người dùng có thể thấy tác nhân im lặng trong vài phút hoặc chỉ nhận được một tin nhắn cuối cùng nói về bước cuối.

Hãy xử lý theo thứ tự sau.

Bật hiển thị thinking updates

Mặc định, các ghi chú giữa các lần gọi công cụ trở về dưới dạng khối thinking rỗng với display: "omitted". Bật:

display: "updates"

Beta header tương ứng là thinking-display-updates-2026-08-18. Hiển thị mỗi khối suy nghĩ không rỗng như một dòng trạng thái.

Xóa instruction cũ yêu cầu im lặng

Loại bỏ các câu như:

Keep all findings for the final response.

Các instruction này từng hữu ích cho những mô hình thích cập nhật liên tục nhưng có thể khiến Fable 5.1 im lặng quá lâu.

Thêm yêu cầu cập nhật tiến độ nếu cần

Trước khi bắt đầu, hãy nói một dòng về những gì bạn sắp làm; các cập nhật ngắn gọn trong khi làm việc giúp người dùng theo dõi. Kết thúc bằng một bản tóm tắt ngắn gọn, tự đầy đủ, bao gồm những gì bạn đã tìm thấy, những gì bạn đã làm và những gì tiếp theo, để người đọc chỉ nhìn thấy tin nhắn cuối cùng vẫn có được bức tranh đầy đủ.

Nếu sản phẩm ẩn tool output, hãy nói rõ điều đó:

Chỉ bạn mới thấy đầu ra của lệnh đó. Nếu người dùng cần đọc bất kỳ phần nào của nó, hãy đưa nó vào câu trả lời của bạn.

Nếu không, mô hình có thể chạy thêm lệnh chỉ để “hiển thị” dữ liệu mà người dùng thực tế không thể nhìn thấy.

5. Lượt kết thúc trước khi hoàn thành công việc

Trong các tác vụ bất đồng bộ phức tạp, Fable 5.1 đôi khi mô tả bước tiếp theo thay vì thực hiện, hoặc xin phép cho một bước đã nằm trong yêu cầu ban đầu.

Thêm block system prompt sau:

Bạn đang hoạt động tự chủ. Người dùng không theo dõi theo thời gian thực và không thể trả lời các câu hỏi giữa nhiệm vụ, vì vậy việc hỏi “Bạn có muốn tôi...?” hoặc “Tôi có nên...?” sẽ làm tắc nghẽn công việc. Đối với các hành động có thể đảo ngược theo yêu cầu ban đầu, hãy tiến hành mà không cần hỏi. Chỉ dừng lại đối với các hành động phá hủy hoặc thay đổi phạm vi thực sự mà người dùng phải quyết định. Việc đưa ra các theo dõi sau khi nhiệm vụ hoàn thành là ổn; việc xin phép trước khi thực hiện công việc thì không.

Trước khi kết thúc lượt, hãy kiểm tra đoạn văn cuối cùng. Nếu đó là một kế hoạch, phân tích, câu hỏi, danh sách bước tiếp theo hoặc lời hứa về công việc chưa làm, hãy thực hiện công việc đó ngay bây giờ bằng các lệnh gọi công cụ. Chỉ kết thúc lượt khi nhiệm vụ hoàn thành hoặc bị chặn bởi đầu vào chỉ người dùng mới có thể cung cấp.

Anthropic kết hợp block trên với một block định nghĩa phạm vi kết quả:

• Không thu hẹp, mở rộng hoặc hoán đổi phạm vi yêu cầu.
• Hoàn thành mọi phần không bị chặn.
• Nêu rõ phần còn thiếu.
• Xem điều phát hiện ngoài yêu cầu là follow-up, không phải thay đổi phạm vi.
• Liệt kê các xác nhận vẫn cần người dùng cung cấp.

Giữ lại instruction yêu cầu mô hình tự kiểm tra công việc trước khi báo cáo. Khuyến nghị của Opus 5 về việc xóa instruction xác minh không áp dụng cho Fable 5.1.

6. Hạn chế sửa ngoài phạm vi và test thừa

Khi được yêu cầu triển khai một tính năng mở, Fable 5.1 đôi khi sửa thêm lỗi lân cận, mở rộng hành vi hoặc tạo nhiều tệp kiểm thử hơn mức cần thiết.

Dùng instruction sau:

Nếu trong lúc làm việc hoặc kiểm thử, bạn phát hiện một lỗi đã tồn tại, vấn đề hiệu suất hoặc hành vi không được nhiệm vụ đề cập, đừng sửa, tối ưu hóa hoặc mở rộng nó trong thay đổi này, trừ khi hành vi được yêu cầu không thể hoạt động nếu thiếu nó; hãy báo cáo như một follow-up trong phần tóm tắt. Hãy xác minh công việc theo cách bạn muốn; script nháp và kiểm tra nhanh không cần giữ lại. Chỉ commit các bài kiểm thử khi nhiệm vụ yêu cầu hoặc repository này đã có quy ước kiểm thử cho loại thay đổi đó, với kích thước tương đương các tệp lân cận. Điều này chỉ áp dụng cho phần bổ sung: mọi hành vi được yêu cầu vẫn phải được triển khai đầy đủ.

7. Tránh viết lại toàn bộ tệp cho thay đổi nhỏ

So với Fable 5, Fable 5.1 có xu hướng viết lại toàn bộ tệp thay vì chỉnh sửa đúng vị trí. Kết quả có thể giống nhau nhưng tiêu tốn nhiều token hơn.

Thêm vào system prompt hoặc tin nhắn người dùng đầu tiên:

Số lượng token dùng để chỉnh sửa tệp nên được giảm thiểu khi mọi yếu tố khác tương đương. Khi không ảnh hưởng đến kết quả cuối cùng, hãy chỉnh sửa chính xác thay vì viết lại toàn bộ tệp.

8. Giảm văn xuôi dài và dày đặc

Văn phong Fable 5.1 thường tốt hơn và ít sáo rỗng hơn, nhưng đôi khi lại dày đặc hơn Fable 5: câu dài hơn và ít ngắt đoạn hơn.

Anthropic định nghĩa “mannered prose” là lối viết dùng ẩn dụ, hoa mỹ để phô diễn thay vì truyền tải ý tưởng. Yêu cầu trực tiếp:

Hãy nói thẳng ý bạn và dùng cụm từ nghĩa đen khi có thể. Vui lòng loại bỏ tất cả văn xuôi kiểu cách.

9. Khôi phục cấu trúc hội thoại phù hợp

Các mô hình trước đây thường lạm dụng bullet và chữ in đậm, nên nhiều prompt có quy tắc chống định dạng. Fable 5.1 lại có xu hướng ngược lại: ít tiêu đề, danh sách và chữ in đậm hơn mức nội dung cần.

Thay vì cấm định dạng hoàn toàn, hãy quy định khi nào định dạng hữu ích:

Sử dụng danh sách khi người dùng yêu cầu hoặc khi nội dung có nhiều phần và danh sách giúp tăng độ rõ ràng. Tôn trọng yêu cầu rõ ràng về định dạng tối thiểu. Giữ văn xuôi đơn giản trong các cuộc trò chuyện hoặc trao đổi cảm xúc.

10. Đánh dấu trích dẫn khi tóm tắt tài liệu

Khi tóm tắt tài liệu, Fable 5.1 có xu hướng sao chép nguyên văn đoạn nguồn mà không đánh dấu đó là trích dẫn.

Thêm một ví dụ hoàn chỉnh vào system prompt, gồm:

1. Yêu cầu của người dùng.
2. Câu trả lời đúng, truyền đạt nguồn bằng lời nói gián tiếp của assistant.
3. Tối đa một trích dẫn ngắn được đánh dấu.
4. Một câu giải thích vì sao câu trả lời đúng.

Trong ví dụ của Anthropic, hãy thay các placeholder tool bằng tên công cụ thực tế của bạn.

11. Ở Effort thấp, mô hình có thể trả lời từ bộ nhớ

Với low, Fable 5.1 gọi công cụ tìm kiếm và truy xuất ít thường xuyên hơn Fable 5, đặc biệt với sản phẩm hoặc mô hình mà nó nhận ra nhưng có kiến thức đã lỗi thời.

Có hai cách khắc phục:

• Tăng Effort cho các lượt bị ảnh hưởng bằng cấu hình theo từng tin nhắn.
• Thêm instruction:

Nhận ra một tên trong lĩnh vực phát triển nhanh không có nghĩa là biết trạng thái hiện tại của nó. Hãy tìm kiếm trước khi trả lời. Trong ít nhất một truy vấn, hãy sử dụng chính xác tên theo cách người dùng đã viết.

12. Sản phẩm dài ở xhigh và max có thể mất nhiều thời gian

Ở xhigh, đặc biệt là max, Fable 5.1 có thể soạn phần lớn nội dung dài trong thinking rồi viết lại nội dung đó trong phản hồi. Điều này làm tăng thời gian chờ và token đầu ra.

Khuyến nghị:

1. Chạy ở high.
2. Chỉ tăng lên xhigh hoặc max sau khi đo được lợi ích.
3. Nếu vẫn dùng cấp độ cao, đặt max_tokens đủ lớn cho cả thinking và phản hồi.

Thêm ghi chú vào tin nhắn người dùng:

Mọi thứ được tạo trong một phản hồi, bao gồm cả phần lý do, đều dùng chung một giới hạn khoảng max_tokens thực tế của bạn. Soạn thảo toàn bộ sản phẩm trong phần lý do rồi viết lại trong phần phản hồi sẽ làm tăng gấp đôi lượt xử lý mà không cải thiện kết quả.

Giữ các bản sao trước đó của ghi chú này ở nguyên vị trí trong những request tiếp theo.

13. Cách diễn đạt coding lành tính để tránh bị từ chối

Các classifier của Fable 5.1 tạo ít false positive hơn Fable 5 khi ra mắt, và việc tìm lỗ hổng trong mã nguồn hiện được phép. Tuy vậy, false positive vẫn có thể xảy ra.

Thay đổi ba cách diễn đạt sau:

• Dùng “Chương trình này có lỗi nào không?” thay vì “Chương trình này có biên dịch mà không có lỗi không?”
• Cung cấp tài liệu tham chiếu khi làm việc với ngôn ngữ ít phổ biến.
• Không đưa vào context các tool trả về dữ liệu mã hóa base64.

Luôn giữ cấu hình fallbacks; hướng dẫn xử lý từ chối có đề cập đến cấu hình này.

14. Nếu tự nén context ở client, hãy chỉ rõ nội dung cần giữ

Fable 5.1 phản hồi tốt khi được hướng dẫn cụ thể về nội dung cần bảo toàn trong bản tóm tắt nén. Server-side compaction đã thực hiện việc này mặc định.

Nếu tự nén ở client, yêu cầu mô hình:

Tóm tắt nội dung bên trong thẻ <summary>. Bảo toàn theo đúng thứ tự:
1. Các khó khăn đã xảy ra và cách giải quyết.
2. Các phương pháp đã được thử hoặc gác lại và lý do.
3. Mọi câu hỏi hoặc quyết định, giữ nguyên cách diễn đạt chính xác.
4. Tình hình hiện tại.
5. Những vấn đề vẫn còn mở.
6. Các chi tiết khó tái tạo như tên, số và liên kết.

Không gọi bất kỳ công cụ nào khi viết bản tóm tắt này; chỉ phản hồi bằng văn bản.

Câu cuối rất quan trọng khi request tóm tắt vẫn mang theo các tool của cuộc trò chuyện.

15. Tác nhân phụ và khả năng xử lý hình ảnh

Hai cải tiến dưới đây thiên về kiến trúc hơn là prompt.

Tác nhân phụ trong coding

Để tác nhân chính tiếp tục làm việc trong khi tác nhân phụ chạy:

1. Tool khởi động tác nhân phụ và trả về ngay lập tức.
2. Mỗi kết quả được gửi trong một tin nhắn người dùng riêng sau đó.
3. Tác nhân chính có một tool riêng để gọi khi muốn chờ kết quả.

Biểu đồ dày đặc và bảng lồng nhau

Cung cấp một tool cắt xén để trả về vùng được chọn ở độ phóng đại lớn hơn, hoặc cung cấp container có các thư viện hình ảnh cơ bản.

Ở Effort low, mô hình có thể bỏ qua việc crop. Hãy kiểm tra log để xác nhận tool cắt xén thực sự được gọi.

Kiểm thử thay đổi prompt trong Apidog

Mỗi cách khắc phục trên nên được kiểm thử theo phương pháp before/after.

Trong Apidog:

1. Lưu ba lượt đầu tiên của agent loop thành một chuỗi request.
2. Tham số hóa system prompt.
3. Chạy cùng chuỗi với và không có từng prompt sửa lỗi.
4. Giữ nguyên mức Effort khi so sánh.
5. Đo các chỉ số phù hợp.

Các chỉ số cần theo dõi:

• Prompt gộp tool: số khối tool_use trên mỗi lượt assistant.
• Prompt chỉnh sửa mục tiêu và mật độ: usage.output_tokens.
• Prompt tự chủ: xác nhận phản hồi cuối không bắt đầu bằng Next, I.
• Prompt truy xuất: tỷ lệ tool search/retrieval được gọi.
• Prompt tiến độ: số khối thinking không rỗng và thời gian giữa các cập nhật.

Bạn có thể tải xuống Apidog để xây dựng chuỗi kiểm thử. Hướng dẫn Claude Code cũng chỉ ra những instruction nào phù hợp để đặt trong CLAUDE.md.

Câu hỏi thường gặp

Prompt Fable 5 của tôi có hoạt động trên Fable 5.1 không?

Có. Anthropic cho biết prompt sẽ hoạt động mà không cần thay đổi. Khác biệt chính nằm ở hành vi: ít tool call được gộp hơn, ít cập nhật tiến độ hơn, văn xuôi dày đặc hơn, ít định dạng hội thoại hơn, nhiều lần viết lại toàn bộ tệp hơn và phạm vi mở rộng hơn trong các tác vụ mở.

Nên chọn Effort nào?

Bắt đầu với high, sau đó chạy đánh giá. Theo Anthropic, medium gần tương đương Fable 5 với chi phí thấp hơn, còn low thường cạnh tranh với Opus và Sonnet về chi phí mỗi tác vụ.

Đặt instruction theo từng lượt ở đâu?

Dùng tin nhắn hệ thống theo phạm vi lượt với:

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "..."
}

Đặt sau tool result và giữ nguyên các bản sao trước đó. Không chèn rồi xóa văn bản khỏi những lượt đã gửi, vì việc đó có thể vô hiệu hóa preserved thinking và khởi động lại prompt cache.

Có nên xóa instruction “hãy xác minh công việc” như trên Opus 5 không?

Không. Khuyến nghị đó dành riêng cho hiện tượng xác minh quá mức của Opus 5. Hãy giữ instruction này trên Fable 5.1.

Làm sao ngăn Fable 5.1 viết lại toàn bộ tệp?

Thêm câu sau vào system prompt hoặc tin nhắn người dùng đầu tiên:

Khi không ảnh hưởng đến kết quả cuối cùng, hãy giảm thiểu token dùng để chỉnh sửa tệp và chỉnh sửa chính xác thay vì viết lại toàn bộ.

Tài liệu tham khảo

• Prompt engineering cho Claude Fable 5.1
• Claude Fable 5.1 là gì
• Effort
• Claude Fable 5.1 API
• Preserved thinking
• Mid-conversation system messages
• Hướng dẫn preserved thinking cho Claude Fable 5.1
• Prompting Claude Opus 5
• Tham số Fable 5 fallbacks
• Apidog
• Tải xuống Apidog
• Claude Code và Fable 5.1