13 Prompt Thực Chiến Cho Claude Fable 5: Thư Viện Từ Đội Ngũ Every Và Anthropic

Bạn đang giúp tôi xác định phần nào trong công việc của tôi xứng đáng được nâng cấp lên Claude Fable 5. Chưa thực thi bất kỳ công việc nào. Nhiệm vụ của bạn là kiểm tra bối cảnh của tôi, tìm ra các ứng viên mạnh, và biến những ứng viên tốt nhất thành bản brief sẵn sàng chạy cho Fable.

Vai trò và mục tiêu hiện tại của tôi:

[Mô tả vai trò, ưu tiên, đội nhóm, mục tiêu kinh doanh, mục tiêu sáng tạo, hoặc các giới hạn vận hành cá nhân của bạn.]

Sử dụng bối cảnh sau:

[Liệt kê các nguồn bạn có thể kiểm tra: repository, thư mục dự án, tài liệu, Notion, Slack, Linear/Jira, email, lịch, dữ liệu phân tích, nghiên cứu khách hàng, các phiên làm việc agent trước đó, danh sách công việc, hoặc bất cứ thứ gì liên quan khác.]

Các ràng buộc:

[Liệt kê deadline, giới hạn quyền riêng tư, tài khoản hoặc công cụ không được phép dùng, ngân sách, khu vực nhạy cảm, quy tắc phê duyệt, và công việc nào bắt buộc phải do con người thực hiện.]

Trước tiên, hãy kiểm tra toàn bộ bối cảnh hiện có. Không đưa ra các ví dụ chung chung.

Xây dựng một danh mục gồm:

1. Các dự án đang hoạt động. 2. Các quy trình lặp lại. 3. Các quyết định đang bị đình trệ. 4. Các backlog lộn xộn. 5. Công việc trải rộng trên nhiều công cụ hoặc nguồn. 6. Công việc mà việc lập kế hoạch, phán đoán, xác minh hoặc theo sát tốt hơn sẽ cải thiện đáng kể kết quả.

Sau đó xác định các ứng viên tốt nhất cho Fable.

Chấm điểm mỗi ứng viên từ 1 đến 5 theo các tiêu chí:

1. Bối cảnh đa nguồn. 2. Mức độ phù hợp để giao việc. 3. Mức độ cần phán đoán. 4. Vạch đích rõ ràng. 5. Đòn bẩy tạo ra. 6. Mức độ phù hợp với Fable.

Chỉ đề xuất Fable khi công việc đủ lớn để biện minh cho một lượt chạy chậm hơn và tốn kém hơn. Hạ điểm những công việc ngắn, hiển nhiên, cần tương tác liên tục, khó xác minh, hoặc phù hợp hơn với một mô hình Claude nhanh hơn hay với con người.

Trả về:

1. Top 10 use case xứng đáng dùng Fable, đã xếp hạng. 2. Bằng chứng bạn tìm được cho từng use case. 3. Vì sao mỗi use case xứng đáng hoặc không xứng đáng dùng Fable. 4. Kết quả bàn giao dự kiến. 5. Phương pháp xác minh. 6. Bối cảnh, công cụ và quyền truy cập có khả năng cần thiết. 7. Rủi ro, điểm nghẽn, hoặc quyết định cần con người. 8. Một bản Fable Brief sẵn sàng chạy cho 3 ứng viên hàng đầu.

Với mỗi Fable Brief sẵn sàng chạy, hãy bao gồm:

- Vấn đề cần giải quyết. - Kết quả cuối cùng. - Các nguồn cần kiểm tra. - Các ràng buộc. - Quy trình đề xuất. - Các điểm cần con người xác nhận. - Bằng chứng cần có trước khi hoàn tất.

Dừng lại sau danh sách xếp hạng và 3 bản brief. Không bắt đầu bất kỳ công việc Fable nào cho đến khi tôi chọn một trong số đó.

Tôi muốn bạn giải quyết vấn đề sau:

[Mô tả vấn đề gốc rễ. Chỉ nêu công việc hoặc sản phẩm bàn giao đầu tiên nếu điều đó giúp giải thích rõ vấn đề.]

Kết quả tôi muốn là:

[Mô tả kết quả cuối cùng, thế nào là tốt, và kết quả sẽ được dùng như thế nào.]

Sử dụng các nguồn sau:

[Liệt kê repository, tài liệu, nghiên cứu, dữ liệu, ghi chú cuộc họp, các thread Slack, ví dụ, công cụ, tài khoản, và các bối cảnh khác mà agent có thể dùng.]

Các ràng buộc quan trọng:

[Liệt kê đối tượng, deadline, ngân sách, phạm vi, phê duyệt, giới hạn bảo mật, quy tắc thương hiệu, và những quyết định phải do con người đưa ra.]

Sử dụng dynamic workflow, subagent, loop, xác minh, và các skill đã cài đặt khi chúng phù hợp với công việc. Với công việc phần mềm, hãy dùng pipeline LFG của Compound Engineering. Sau một lượt chạy có ý nghĩa, dùng Compound Engineering để lưu lại những bài học đáng giữ.

Trước khi thực thi:

1. Kiểm tra tài liệu nguồn. 2. Diễn đạt lại vấn đề mà bạn tin mình đang giải quyết. 3. Xác định bối cảnh còn thiếu, các chỉ dẫn mâu thuẫn, và các giả định có thể làm thay đổi kết quả. 4. Quyết định xem công việc có cần một loop, một dynamic workflow, hạ tầng mới, hay chỉ cần một cách tiếp cận trực tiếp đơn giản hơn. 5. Cho tôi xem cách tiếp cận đề xuất và bằng chứng bạn sẽ dùng để xác minh kết quả.

Sau khi được phê duyệt, hãy thực thi công việc. Giao những phần việc độc lập cho các subagent và tiếp tục trong khi chúng chạy. Chỉ tạm dừng khi gặp một hành động phá hủy hoặc không thể đảo ngược, một thay đổi phạm vi thực sự, hoặc thông tin chỉ tôi mới có thể cung cấp. Đừng dừng lại ở việc phân tích hay đưa ra khuyến nghị nếu bạn có công cụ và quyền để bàn giao kết quả thực tế.

Trước khi báo cáo tiến độ hay hoàn thành, hãy đối chiếu từng nhận định với kết quả thực tế từ công cụ trong phiên làm việc này. Nếu điều gì đó chưa được xác minh, hãy nói rõ điều đó.

Khi hoàn tất, trả về:

1. Kết quả, trong một câu. 2. Những gì bạn đã hoàn thành và các quyết định quan trọng nhất bạn đã đưa ra. 3. Bằng chứng cho thấy kết quả hoạt động. 4. Bất cứ điều gì bạn không thể xác minh. 5. Điều gì nên được lưu lại hoặc cải thiện để lượt chạy tiếp theo tốt hơn.

Tôi giao cho bạn công việc này để chạy không giám sát qua đêm: [mô tả công việc]

Hoàn thành nghĩa là: [định nghĩa thế nào là xong]

Sử dụng bối cảnh sau: [repository, tài liệu, quyền truy cập, ràng buộc]

Hãy làm việc đến khi hoàn tất. Nếu gặp điểm nghẽn, đừng dừng lại. Dùng mock, stub, hoặc các giả định có ghi chú rõ ràng khi phù hợp. Ghi lại từng cách xử lý tạm thời và tiếp tục với mọi phần không cần tôi quyết định.

Đến sáng, để lại cho tôi:

1. Những gì bạn đã hoàn thành 2. Những gì bạn đã xử lý tạm và lý do 3. Những gì vẫn cần tôi quyết định 4. Bằng chứng cho thấy công việc hoạt động đúng như dự định

Đây là log phiên làm việc của một agent khi thử thực hiện quy trình này: [mô tả quy trình]

Nó gặp khó khăn ở: [thời gian, chi phí, lỗi, kết quả kém, hoặc thất bại lặp lại]

Phân tích xem công cụ, skill, hoặc quy trình hiện tại đang gãy ở đâu. Xác định nguyên nhân gốc rễ thay vì chỉ vá triệu chứng gần nhất.

Kiểm tra log phiên làm việc, công cụ, skill và file nguồn. Tìm ra điểm nghẽn mang tính cấu trúc, sau đó xây dựng cải tiến có thể tái sử dụng nhỏ nhất: một skill, công cụ dòng lệnh, hook, quy trình, file context, hoặc thay đổi ở tầng hệ thống.

Kiểm thử quy trình đã nâng cấp trên một công việc tương đương. Dùng một verifier mới để so sánh kết quả cũ và mới về chất lượng, thời gian, chi phí và tỷ lệ thất bại.

Trả về:

1. Nguyên nhân gốc rễ 2. Thay đổi bạn đã thực hiện 3. Kết quả trước và sau 4. Hạ tầng mà các mô hình nhanh hơn hoặc rẻ hơn có thể tái sử dụng 5. Bất kỳ thất bại nào bạn không thể giải quyết

Dùng bộ tài liệu nguồn đính kèm để phân tích [lĩnh vực kinh doanh, đợt ra mắt, đối tượng khách hàng, hoặc phễu bán hàng].

Các nguồn bao gồm: [dữ liệu khảo sát, nghiên cứu khách hàng, dashboard phân tích, bối cảnh website, tài liệu kế hoạch, ghi chú cuộc họp, thảo luận Slack, và mục tiêu nội bộ]

Mục tiêu của chúng tôi là [mục tiêu kinh doanh cụ thể] cho [khách hàng mục tiêu hoặc nhóm đối tượng].

Kiểm chứng các giả định của chúng tôi với bằng chứng thực tế. Đừng xem sự đồng thuận nội bộ là sự thật hiển nhiên.

Trước tiên, hãy tạo ra:

1. 10 phát hiện có khả năng cao nhất làm thay đổi cách chúng tôi vận hành 2. Danh sách xếp hạng 10 việc chúng tôi nên triển khai, thử nghiệm, hoặc dừng lại 3. Bằng chứng đằng sau mỗi khuyến nghị 4. Các xung đột giữa nguồn dữ liệu, quy tắc đã lỗi thời, định nghĩa chỉ số chưa rõ ràng, và các giả định cần được xác minh

Đánh dấu những kết luận phụ thuộc nặng vào một nguồn hoặc một quy tắc nội bộ duy nhất. Sau đó dừng lại để tôi chọn việc cần hành động.

Sau khi tôi chọn, hãy thực thi công việc đã được duyệt. Với các thay đổi phần mềm, dùng pipeline LFG của Compound Engineering để brainstorm, lập kế hoạch, xây dựng, review, kiểm thử, và chuẩn bị pull request. Xây dựng hạ tầng còn thiếu nếu nó cản trở kết quả. Xác minh công việc trong môi trường thực tế và không merge hay deploy khi chưa có sự phê duyệt rõ ràng từ tôi.

Xây dựng phiên bản hoạt động đầu tiên của [sản phẩm, website, hoặc công cụ].

Đặc tả sản phẩm: [dán đặc tả vào đây]
Người dùng: [phục vụ đối tượng nào]
Bối cảnh chuyên môn: [thuật ngữ, quy trình, ví dụ, và ràng buộc]
Các trường hợp phức tạp: [edge case]
Hành vi bắt buộc: [yêu cầu]
Những điểm chưa hoàn thiện có thể chấp nhận: [giới hạn phạm vi]

Dùng pipeline LFG của Compound Engineering để brainstorm, lập kế hoạch, xây dựng, review, và kiểm thử phiên bản đầu tiên. Giữ việc triển khai trong đúng phạm vi đã nêu. Kiểm thử trong môi trường nó sẽ được sử dụng và chuẩn bị một pull request.

Khi hoàn tất, hãy cho tôi:

1. Hướng dẫn để dùng thử 2. Các quyết định quan trọng bạn đã đưa ra 3. Những gì bạn đã bỏ qua 4. Kết quả kiểm thử và các bằng chứng khác 5. Những khu vực tôi nên xem xét kỹ nhất

Trước khi viết code, hãy giúp tôi lập kế hoạch cho [dự án hoặc tính năng].

Bối cảnh hiện tại: [nó làm gì, phục vụ ai, và đang chạy ở đâu hiện nay]

Hướng phát triển sắp tới: [quy mô dự kiến, thời gian biểu, và giai đoạn phát hành]

Hãy thách thức mọi hạ tầng hoặc lớp trừu tượng không phù hợp với giai đoạn này. Tránh lập kế hoạch cho một quy mô mà chúng ta chưa có, và tránh những đường tắt sẽ khiến bản phát hành sắp tới trở nên mong manh.

Cùng tôi cân nhắc các đánh đổi cho đến khi chúng ta thống nhất được kiến trúc.

Sau đó tạo ra một tài liệu duy nhất tôi có thể chia sẻ với cả đội: một trang HTML hoặc tài liệu markdown có sơ đồ, kiến trúc đã chọn, các phương án đã bị từ chối, và lý do vì sao.

Với mỗi thay đổi bạn thực hiện trên [ứng dụng hoặc tính năng], hãy đính kèm bằng chứng cho thấy nó hoạt động.

Thực hiện các luồng thao tác thực tế bằng [tài khoản staging hoặc test] và dữ liệu mang tính đại diện. Chụp ảnh màn hình mọi màn hình bạn đã thay đổi, kể cả trạng thái lỗi và các trường hợp biên. Ghi lại một video ngắn của luồng thao tác chính.

Xem lại chính những gì bạn đã ghi lại. Tua qua video và đánh dấu các animation bị lỗi, bố cục bị xô lệch, trạng thái còn thiếu, và bất cứ điều gì người dùng có thể gặp phải mà bài test chưa bao phủ.

Trả về kết quả kiểm thử, bộ sưu tập ảnh chụp màn hình, video, các vấn đề bạn tìm thấy, và bất kỳ điều gì còn chưa chắc chắn.

Tôi cần chuyển [codebase hoặc module] từ [ngôn ngữ A] sang [ngôn ngữ B] vì [lý do].

Trước khi bắt đầu chuyển đổi, hãy thiết kế quy trình và cho tôi xem bằng code. Quy trình nên:

1. Vẽ bản đồ hệ thống hiện tại và viết đặc tả hành vi của nó. 2. Dịch từng module một. 3. Kiểm thử từng module ngay khi nó được dịch xong. 4. Chạy một đợt review mang tính phản biện ở cuối để tìm phần bị bỏ sót và thay đổi hành vi. 5. Ghi lại bất cứ điều gì cố ý bị loại khỏi việc chuyển đổi và lý do vì sao.

Sau khi tôi phê duyệt quy trình, hãy chạy nó từ đầu đến cuối.

Khi việc chuyển đổi hoàn tất, hãy cho tôi thấy nó cải thiện so với bản gốc ở đâu, hành vi có thể khác biệt ở đâu, và khu vực nào xứng đáng được con người xem xét kỹ nhất.

Thu thập phản hồi về [sản phẩm, tính năng, hoặc quy trình] từ: [kênh Slack, ticket hỗ trợ, bản ghi màn hình, ảnh chụp màn hình, log production, cuộc gọi khách hàng, và ghi chú cuộc họp]

Nhóm các phản hồi theo chủ đề. Tách riêng:

1. Những thay đổi rõ ràng có thể hành động ngay 2. Những quyết định cần phán đoán của tôi 3. Những yêu cầu mâu thuẫn với chiến lược, chân dung người dùng, hoặc định hướng sản phẩm của chúng ta 4. Bằng chứng hỗ trợ cho mỗi chủ đề

Giữ lại một bản ghi những gì bạn đã xử lý để phản hồi không bị lặp lại. Tạo một kế hoạch nhất quán cho các thay đổi có thể hành động. Sau khi tôi phê duyệt kế hoạch, dùng pipeline LFG của Compound Engineering để triển khai chúng thành một đợt duy nhất. Chạy bước hoàn thiện và xác minh sản phẩm trước khi bàn giao kết quả.

Trả về những gì đã thay đổi, những gì bạn đã bỏ qua, những gì vẫn cần review, pull request, và bằng chứng cho thấy các thay đổi hoạt động đúng. Việc merge và đóng vòng phản hồi hãy để lại cho tôi.

Tôi cần bạn hoàn thành công việc phức tạp sau:

[Mô tả công việc, kết quả cuối cùng, và vì sao nó quan trọng.]

Bối cảnh và công cụ hiện có:

[Liệt kê các nguồn, repository, công cụ, tài khoản, môi trường, và ràng buộc.]

Sử dụng dynamic workflow của Claude để điều phối công việc.

Quy trình nên:

1. Chia công việc thành các giai đoạn với mục đích rõ ràng và bài kiểm tra hoàn thành cụ thể. 2. Quyết định giai đoạn nào có thể chạy song song và giai đoạn nào phụ thuộc vào công việc trước đó. 3. Giao việc nghiên cứu, xây dựng, kiểm thử, và review mang tính phản biện cho các subagent riêng biệt khi hữu ích. 4. Lưu lại những phát hiện trung gian quan trọng để các giai đoạn sau có thể sử dụng. 5. Lập lại kế hoạch khi có bằng chứng mới khiến hướng đi hiện tại không còn hợp lý. 6. Tiếp tục cho đến khi thỏa mãn định nghĩa hoàn thành, kể cả khi quy trình thay đổi dọc đường.

Cho tôi xem quy trình, các điểm có khả năng thất bại, và một số ít các điểm cần con người thực sự phán đoán.

Sau khi được phê duyệt, hãy thực thi từ đầu đến cuối. Giữ các subagent độc lập chạy song song và lập lại kế hoạch khi bằng chứng thay đổi. Trả về kết quả, bằng chứng, quy trình bạn đã dùng, và những chỗ nó đã thay đổi.

Tôi muốn biến công việc lặp lại này thành một loop:

[Mô tả input lặp lại, output mong muốn, quy trình hiện tại, và tần suất.]

Ví dụ về input và output trước đây:

[Đính kèm các ví dụ mang tính đại diện, kể cả các lần thất bại và các lần con người phải sửa lại.]

Dùng khả năng loop của Claude để thiết kế và kiểm thử một loop có thể:

1. Thu thập hoặc phát hiện input mới. 2. Theo dõi những gì đã xử lý để tránh làm trùng lặp. 3. Quyết định xem input có thể hành động được không. 4. Lập kế hoạch và giao việc. 5. Tạo ra hoặc bàn giao output. 6. Xác minh kết quả theo các tiêu chuẩn rõ ràng. 7. Chuyển những quyết định cần phán đoán của con người đến đúng người. 8. Thử lại các thất bại có thể khắc phục và ghi nhận các thất bại không thể khắc phục. 9. Ghi lại các lần sửa lỗi và cập nhật hệ thống để lượt chạy sau tốt hơn.

Xác định trigger, lịch chạy, bối cảnh, công cụ, quyền truy cập, trạng thái, bộ nhớ, và các quy tắc định tuyến mô hình mà loop cần. Dùng Fable cho phần phán đoán khó và điều phối; dùng các mô hình nhanh hơn cho các giai đoạn thông thường. Xây dựng phiên bản nhỏ nhất có thể hoạt động.

Trả về:

1. Một sơ đồ hoặc bản đồ mô tả loop 2. Bản triển khai hoạt động được hoặc kế hoạch triển khai 3. Các điểm cần con người xác nhận 4. Phương pháp xác minh 5. Cách việc học hỏi sẽ được lưu lại giữa các lượt chạy

Kiểm tra toàn bộ bối cảnh hiện có cho mảng công việc này:

[Mô tả dự án, vai trò, hoặc quy trình lặp lại.]

Các nguồn hiện tại:

[Liệt kê thư mục, tài liệu, database, repository, ghi chú cuộc họp, style guide, ví dụ, và các file memory.]

Thiết kế một hệ thống context sẵn sàng cho agent.

Hệ thống nên:

1. Cho Claude Code một file CLAUDE.md khởi đầu ngắn gọn duy nhất. 2. Giải thích mỗi nguồn chứa gì và khi nào nên dùng. 3. Tách các quy tắc ổn định khỏi bối cảnh dự án mang tính tạm thời. 4. Xác định các xung đột, trùng lặp, hướng dẫn lỗi thời, và thông tin còn thiếu. 5. Bao gồm các ví dụ về kết quả xuất sắc và các kiểu thất bại đã biết. 6. Giữ các file nguồn lớn luôn sẵn sàng mà không bắt mỗi lượt chạy phải tải toàn bộ. 7. Chuyển các quy trình lặp lại thành skill thay vì làm phình to CLAUDE.md. 8. Định nghĩa cách các quyết định và sửa lỗi mới nên được lưu lại.

Tạo thư mục, file chỉ mục, hoặc template markdown cần thiết để hệ thống có thể dùng được. Triển khai cấu trúc này khi bạn có công cụ và quyền thực hiện.

Trả về bản đồ context mới, những gì bạn đã thay đổi, các xung đột chưa giải quyết, và hướng dẫn để giữ nó luôn cập nhật.

Giúp tôi phát triển ý tưởng viết này:

[Mô tả ý tưởng, mâu thuẫn, câu hỏi, hoặc câu chuyện bạn đang cân nhắc.]

Sử dụng bối cảnh sau:

[Đính kèm bản ghi phỏng vấn, tư liệu điều tra, ghi chú, bản nháp trước đó, code hoặc lịch sử sản phẩm liên quan, hướng dẫn văn phong, và ví dụ về tác phẩm của bạn.]

Tác phẩm cuối cùng nên đạt được:

[Mô tả đối tượng độc giả, hiệu ứng mong muốn, mâu thuẫn trung tâm, và điều một tác phẩm hay sẽ khiến độc giả hiểu hoặc cảm nhận được.]

Hãy khám phá tư liệu trước khi viết nháp.

1. Kiểm tra bối cảnh và xác định những mâu thuẫn, bất ngờ, phân cảnh, và câu hỏi còn bỏ ngỏ thú vị nhất. 2. Phỏng vấn tôi về những lựa chọn cần đến phán đoán hoặc trải nghiệm cá nhân của tôi. 3. Đề xuất một vài luận điểm hoặc cấu trúc kể chuyện khả dĩ. 4. Giải thích mỗi phương án nhấn mạnh điều gì và bỏ qua điều gì. 5. Chờ tôi chọn một hướng đi.

Sau khi tôi chọn, hãy tạo một dàn ý sắp xếp thông tin theo trình tự phù hợp cho một độc giả không có cùng bối cảnh với tôi. Sau đó viết nháp tác phẩm.

Giữ tư liệu khám phá tách biệt khỏi bản nháp cuối cùng. Đánh dấu những chỗ bản nháp dựa vào một giả định, thiếu bằng chứng, hoặc lệch khỏi kết quả tôi đã mô tả.

Thêm chỉ dẫn này vào cấu hình agent của bạn:

Sau mỗi phiên làm việc agent đã hoàn tất, hãy hỏi tôi: "Bạn có muốn đúc kết (compound) phiên này không?" Không tự động chạy quy trình đúc kết. Chờ tôi phê duyệt.

Dùng compound skill của Compound Engineering để review phiên làm việc agent đã hoàn tất này:

[Đính kèm prompt, kế hoạch, kết quả, các lần gọi công cụ, bằng chứng kiểm thử, phản hồi của con người, và kết quả cuối cùng.]

Xác định điều gì nên được rút ra từ lượt chạy này.

Tách riêng:

1. Bài học lâu dài áp dụng được cho công việc tương lai 2. Sự kiện đặc thù của dự án thuộc về bối cảnh dự án 3. Sở thích cá nhân hoặc của đội nhóm 4. Cải tiến công cụ hoặc quy trình 5. Những sai lầm không nên trở thành quy tắc chung 6. Chi tiết một lần không nên được lưu lại

Với mỗi bài học được đề xuất:

- Trích dẫn bằng chứng từ phiên làm việc. - Giải thích nó nên được lưu ở đâu. - Cho thấy chính xác thay đổi bạn đề xuất. - Kiểm tra xem có xung đột với các chỉ dẫn hiện có không.

Lưu các giải pháp lâu dài vào hệ thống tri thức của dự án với đủ tiêu đề, metadata, từ vựng, và liên kết chéo để một agent trong tương lai có thể tìm thấy. Chỉ cập nhật CLAUDE.md cho những chỉ dẫn ngắn gọn áp dụng cho mọi phiên làm việc. Đưa các quy trình lặp lại vào skill. Giữ mỗi thay đổi nhỏ và cụ thể.

Trả về:

1. Những gì bạn đã lưu 2. Bạn đã lưu nó ở đâu 3. Những gì bạn cố ý không lưu 4. Lượt chạy tiếp theo nên cải thiện như thế nào