Claude Fable 5 có khả năng vượt trội hơn các mô hình trước đó, nhưng khả năng này có thể đi theo cả hai hướng. Nếu bạn yêu cầu nó thực hiện một tác vụ thông thường với mức độ nỗ lực cao, nó sẽ thu thập ngữ cảnh, cân nhắc và chỉnh sửa mã mà bạn không bao giờ yêu cầu nó đụng vào; đốt cháy token và phút mà bạn không cần phải chi tiêu. Viết prompt tốt, mô hình tương tự sẽ hoàn thành nhanh hơn, trả về ít thông tin thừa hơn và hoạt động lâu hơn trên những vấn đề khó mà bạn thực sự muốn nó xử lý. Prompt là đòn bẩy quyết định mức độ hiệu quả của mỗi yêu cầu.
Hướng dẫn này biến hướng dẫn prompt Fable 5 chính thức của Anthropic thành một cẩm nang thực tế, sau đó chỉ ra cách kiểm tra và tinh chỉnh các prompt đó với Apidog để bạn đo lường hiệu quả thay vì đoán mò. “Mở rộng việc sử dụng” không phải là một mánh khóe để lách giới hạn; đó là việc đạt được nhiều công việc hữu ích hơn từ mỗi cuộc gọi bằng cách điều chỉnh mức độ nỗ lực, phạm vi và độ chi tiết phù hợp với công việc.
Những gì “mở rộng việc sử dụng của bạn” thực sự có nghĩa
Ba yếu tố kiểm soát chi phí của một yêu cầu Fable 5 và những gì bạn nhận lại được:
- Mức độ nỗ lực (Effort). Đây là sự đánh đổi chính giữa trí thông minh, độ trễ và chi phí. Anthropic khuyến nghị `high` là mặc định, `xhigh` cho các khối lượng công việc khó nhất và `medium` hoặc `low` cho công việc thông thường. Mức độ nỗ lực thấp hơn trên Fable 5 vẫn hoạt động tốt, và thường vượt trội hơn `xhigh` trên các mô hình cũ hơn. Giảm mức độ nỗ lực cho các tác vụ đơn giản là cách lớn nhất để tiết kiệm ngân sách của bạn.
- Token đầu ra (Output tokens). Không được hướng dẫn, Fable 5 sẽ diễn giải chi tiết; nó khảo sát các tùy chọn mà nó sẽ không theo đuổi, giải thích nguyên nhân gốc rễ một cách dài dòng và viết các bình luận tường thuật dòng tiếp theo. Một hướng dẫn ngắn gọn giúp cắt giảm điều đó mà không làm mất đi nội dung cốt lõi.
- Thời gian chạy (Run length). Đối với các tác vụ khó, Fable 5 duy trì các lần chạy dài, có định hướng mục tiêu; đôi khi vài phút mỗi yêu cầu, đôi khi hàng giờ tự động. Đó là nơi bạn muốn khả năng được sử dụng, vì vậy nhiệm vụ của prompt là ngăn nó chi tiêu quá mức cho công việc dễ dàng và để nó hoạt động trên những phần khó.
Làm đúng ba điều này trong prompt và bạn sẽ mở rộng việc sử dụng của mình theo cách duy nhất có ý nghĩa: nhiều công việc hoàn thành hơn trên mỗi token. Các mẫu dưới đây thực hiện chính xác điều đó.
Các mẫu prompt giúp tối ưu hóa mọi cuộc gọi
Những điều này đến trực tiếp từ hướng dẫn của Anthropic. Mỗi điều là một chỉ dẫn ngắn gọn mà bạn đưa vào một system prompt; Fable 5 tuân thủ các chỉ dẫn đủ tốt để bạn điều khiển hành vi bằng một câu thay vì một danh sách kiểm tra.
Điều chỉnh mức độ nỗ lực phù hợp với tác vụ
Đừng để mức độ nỗ lực ở một cài đặt duy nhất. Hãy sử dụng `high` làm mức cơ bản của bạn, chỉ tăng lên `xhigh` cho các công việc nhạy cảm về khả năng, và giảm xuống `medium` hoặc `low` cho các cuộc gọi thông thường. Nếu một tác vụ hoàn thành đúng nhưng mất nhiều thời gian hơn mức cần thiết, hãy giảm mức độ nỗ lực. Thay đổi này giúp tiết kiệm chi phí nhiều nhất, vì hầu hết các cuộc gọi không cần mức độ cân nhắc tối đa. Nếu bạn đang theo dõi chi tiêu, phân tích của chúng tôi về chi phí API Claude và giới hạn tốc độ API Claude cho thấy tại sao việc kiểm soát mức độ nỗ lực lại mang lại hiệu quả về số lượng.
Yêu cầu nó hành động khi có đủ thông tin
Fable 5 có thể lập kế hoạch quá mức cho các tác vụ mơ hồ; khảo sát các tùy chọn thay vì hành động. Một hướng dẫn ngắn gọn sẽ khắc phục điều đó:
When you have enough information to act, act. Do not re-derive facts already established
in the conversation, re-litigate a decision the user has already made, or narrate
options you will not pursue. If you are weighing a choice, give a recommendation, not an
exhaustive survey. This does not apply to thinking blocks.
Bắt đầu bằng kết quả
Đây là công cụ tiết kiệm token của bạn. Yêu cầu mô hình đặt câu trả lời lên đầu sẽ cắt giảm những phần mở đầu dài dòng làm tăng token đầu ra:
Lead with the outcome. Your first sentence after finishing should answer "what happened"
or "what did you find": the thing the user would ask for if they said "just give me the
TLDR." Supporting detail and reasoning come after. Being readable and being concise are
different things, and readability matters more.
Hạn chế phạm vi
Ở mức độ nỗ lực cao hơn, Fable 5 có thể tái cấu trúc hoặc “dọn dẹp” vượt quá yêu cầu của tác vụ. Hãy giới hạn nó:
Don't add features, refactor, or introduce abstractions beyond what the task requires. A
bug fix doesn't need surrounding cleanup. Don't add error handling, fallbacks, or
validation for scenarios that cannot happen. Only validate at system boundaries (user
input, external APIs). Do the simplest thing that works well.
Xác thực tuyên bố tiến độ trong các lần chạy dài
Trong các lần chạy tự động dài, hãy yêu cầu mô hình kiểm tra các tuyên bố của nó dựa trên kết quả công cụ thực tế từ phiên làm việc này. Anthropic báo cáo rằng điều này gần như loại bỏ các báo cáo trạng thái bịa đặt:
Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so
explicitly.
Đưa ra lý do, không chỉ yêu cầu
Fable 5 hoạt động tốt hơn khi nó biết ý định đằng sau một tác vụ, bởi vì ngữ cảnh cho phép nó kết nối công việc với những gì quan trọng thay vì đoán mò:
I'm working on [the larger task] for [who it's for]. They need [what the output
enables]. With that in mind: [request].
Xây dựng file ghi nhớ cho công việc lặp lại
Fable 5 hoạt động tốt khi nó có thể ghi lại các bài học và tham chiếu chúng sau này. Một tệp Markdown đơn giản sẽ hiệu quả: mỗi bài học một mục, một dòng tóm tắt ở trên cùng, được cập nhật thay vì trùng lặp. Đối với các quy trình làm việc lặp lại, điều này sẽ tích lũy; các lần chạy sau sẽ bỏ qua những lỗi mà các lần trước đã mắc phải.
Kiểm tra và tinh chỉnh prompt của bạn trong Apidog
Đây là phần mà hướng dẫn chính thức để lại cho bạn: biết liệu một thay đổi prompt có thực sự hữu ích hay không. Cách diễn đạt nghe có vẻ chặt chẽ hơn có thể tạo ra cùng số lượng token; một hướng dẫn ngắn gọn có thể phản tác dụng và gây ra từ chối. Cách duy nhất để biết là chạy cả hai phiên bản và so sánh. Apidog là một nơi lý tưởng để làm điều đó, bởi vì nó cho phép bạn lưu yêu cầu, hoán đổi biến, xác nhận phản hồi và mock API để quá trình lặp lại vẫn tiết kiệm chi phí. Nếu bạn chưa bao giờ chạy thử nghiệm prompt bên ngoài cửa sổ trò chuyện, thì đây là quy trình làm việc tương tự như kiểm thử API không cần Postman, hướng tới điểm cuối Messages.
1. Tham số hóa prompt và mức độ nỗ lực
Tạo một yêu cầu đến API Messages và đưa các phần dễ thay đổi; system prompt, mức độ nỗ lực, khóa API; vào các biến môi trường của Apidog. Giờ đây, bạn có thể chuyển mức độ nỗ lực từ `high` sang `medium` hoặc hoán đổi toàn bộ system prompt chỉ với một thay đổi, mà không cần chỉnh sửa phần thân yêu cầu mỗi lần.
POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json
{
"model": "claude-fable-5",
"max_tokens": 2048,
"system": "{{SYSTEM_PROMPT}}",
"messages": [
{ "role": "user", "content": "{{TASK}}" }
]
}
2. A/B hai biến thể prompt và đo lường sự khác biệt
Lưu hai phiên bản của yêu cầu; một có hướng dẫn về sự ngắn gọn và phạm vi của bạn, một không; và chạy cả hai với cùng một tác vụ. Sau đó so sánh những gì thực sự thay đổi:
- Token đầu ra (Output tokens) từ `usage.output_tokens` trong phản hồi. Đây là tín hiệu chi phí trực tiếp của bạn. Một hướng dẫn ngắn gọn tốt sẽ làm giảm đáng kể nó.
- Độ trễ (Latency), hiển thị trong thời gian phản hồi của Apidog. Mức độ nỗ lực thấp hơn sẽ thể hiện ở đây.
- Chất lượng (Quality), do bạn tự đánh giá. Rẻ hơn chỉ tốt hơn nếu câu trả lời vẫn hoàn thành công việc.
Giờ đây, “prompt hoàn hảo” là một con số bạn có thể chỉ ra, chứ không phải một linh cảm. Giữ phiên bản cho ra kết quả tương tự với ít token hơn.
3. Xác nhận stop_reason và xử lý các trường hợp từ chối dự phòng
Fable 5 chạy các bộ phân loại an toàn và có thể trả về `stop_reason: "refusal"`, mà nhiều thiết lập sẽ dự phòng sang Opus 4.8 để xử lý. Một prompt quá mạnh tay, hoặc một prompt yêu cầu mô hình lặp lại lý do của nó, có thể kích hoạt những điều này thường xuyên hơn bạn nghĩ; và các dự phòng ngầm sẽ thay đổi chi phí và hành vi của bạn. Thêm một xác nhận trong Apidog rằng `stop_reason` là `end_turn`, để một sự tăng đột biến trong các trường hợp từ chối xuất hiện dưới dạng một thử nghiệm thất bại thay vì một bất ngờ trên hóa đơn của bạn. Coi xác nhận đó là một phần của hợp đồng prompt của bạn.
4. Lập kế hoạch cho các lượt chạy dài hơn
Fable 5 chạy lâu hơn các mô hình cũ hơn; các yêu cầu tác vụ khó riêng lẻ có thể mất nhiều phút với mức độ nỗ lực cao. Trước khi triển khai, hãy đặt một thời gian chờ hợp lý cho yêu cầu của bạn trong Apidog và xác nhận rằng client của bạn xử lý phản hồi chậm hoặc được truyền tải một cách sạch sẽ thay vì bị treo. Nếu bạn thấy các lỗi timeout bắt đầu xuất hiện, đường dẫn gỡ lỗi trong khắc phục lỗi timeout yêu cầu upstream áp dụng trực tiếp. Giảm mức độ nỗ lực cũng là một giải pháp hợp lệ khi một tác vụ hoàn thành đúng nhưng chậm hơn mức bạn cần.
5. Mock API để quá trình lặp lại không tốn phí
Bạn sẽ chạy một prompt hàng chục lần trong khi tinh chỉnh nó. Bạn không muốn mỗi lần lặp lại đều bị tính phí. Mock server của Apidog có thể thay thế điểm cuối Messages, trả về một hình dạng phản hồi đã lưu; bao gồm cả các trường hợp từ chối và lỗi; để bạn có thể kiểm tra cách xử lý của client, các xác nhận và logic timeout mà không tốn token. Chuyển URL cơ sở trở lại API trực tiếp cho các lần chạy so sánh thực tế. Nếu bạn đang xây dựng điều này thành một quy trình tự động, hướng dẫn Apidog CLI và các kỹ năng Claude cho thấy cách chạy các kiểm tra này trong CI.
Câu hỏi thường gặp
Một prompt tốt hơn có nghĩa là ít token hơn trên Fable 5 không? Thường là có. Một hướng dẫn ngắn gọn bắt đầu bằng kết quả sẽ cắt giảm phần mở đầu và tường thuật mà Fable 5 tạo ra khi không được hướng dẫn, điều này làm giảm `output_tokens`. Hãy đo lường nó trong Apidog thay vì giả định; một số chỉnh sửa lại không thay đổi số lượng.
Cách nhanh nhất để cắt giảm chi phí Fable 5 là gì? Giảm mức độ nỗ lực cho các tác vụ thông thường. Mức độ nỗ lực là đòn bẩy chính về chi phí và độ trễ, và `medium` hoặc `low` trên Fable 5 vẫn hoạt động tốt. Dành `high` và `xhigh` cho những công việc thực sự khó.
Tại sao yêu cầu Fable 5 của tôi bị timeout trong khi prompt tương tự hoạt động trên Opus? Fable 5 chạy lâu hơn cho các tác vụ khó; vài phút mỗi yêu cầu ở mức độ nỗ lực cao là bình thường. Tăng thời gian chờ của client, xử lý luồng, hoặc giảm mức độ nỗ lực nếu tác vụ hoàn thành đúng nhưng quá chậm.
Tại sao tôi đột nhiên nhận được phản hồi Opus khi tôi yêu cầu Fable 5? Một `stop_reason: "refusal"` đã kích hoạt một phương án dự phòng. Các prompt yêu cầu mô hình tái tạo lý do của nó, hoặc những prompt chạm đến các bộ phân loại an toàn, làm tăng tỷ lệ từ chối. Xác nhận `stop_reason` trong Apidog để phát hiện điều này.
Tôi có thể kiểm tra các thay đổi prompt mà không tốn tiền không? Có. Mock điểm cuối Messages trong Apidog để phát triển và kiểm tra logic client của bạn miễn phí, sau đó chỉ chạy API trực tiếp cho các lần chạy so sánh nơi bạn đo lường token và độ trễ thực tế.
Tổng kết
Mở rộng việc sử dụng Fable 5 của bạn không phải là lách hạn ngạch; đó là về việc viết các prompt phù hợp với mức độ nỗ lực, phạm vi và độ chi tiết của tác vụ để mỗi cuộc gọi thực hiện được nhiều việc hơn. Hướng dẫn của Anthropic cung cấp cho bạn các mẫu; điều chỉnh mức độ nỗ lực theo độ khó, bắt đầu bằng kết quả, hạn chế phạm vi, xác thực tiến độ và đưa ra lý do. Apidog mang đến cho bạn bằng chứng; tham số hóa prompt, A/B các biến thể, đo lường token và độ trễ, và xác nhận chống lại các trường hợp từ chối dự phòng. Tải xuống Apidog, kết nối yêu cầu Messages của bạn và biến “prompt này có vẻ chặt chẽ hơn” thành một con số bạn có thể tin tưởng.