AIDive

Chạy thử playbook Claude Code của Anthropic

Bởi AIDive · Đăng ngày

Coding agentTự động hoá & workflow

Playbook chưa ai đo

Anthropic đã công bố một playbook SDLC AI-native cho Claude Code: sáu giai đoạn, mỗi giai đoạn kết thúc bằng một file đã commit, được dạy dưới dạng khóa học miễn phí. Luận điểm trung tâm của nó là code không còn là nút thắt, và chuỗi artifact đã commit sẽ quản lý phần đang là nút thắt. Bản thân tài liệu không có bất kỳ phép đo nào — không có thời gian, không có chi phí, không có benchmark. Chúng tôi đã chạy bài thử có bấm giờ đầu tiên trên một repository thật: mười sáu phiên Claude Code có bấm giờ, mọi gate đều được tính giá, và một kết luận chia đôi chuỗi này. Trên đường đi, một lỗi sửa trong hai phút nhưng phải chạy qua toàn bộ chuỗi đã cho thấy giá của nghi thức, và chính lần deploy của chúng tôi bị chặn hai lần, một lần bởi bốn dòng shell.

Playbook và bộ thử nghiệm

Bộ thử nghiệm: mười sáu phiên Claude Code có bấm giờ, khoảng $12 chi phí tính toán, một repository thật. Playbook chạy qua sáu giai đoạn — plan, design, build, test, deploy, maintain. Mỗi giai đoạn kết thúc bằng một file đã commit, và giai đoạn sau đọc file đó: intent, spec, plan, pull request, bản ghi sự cố. Các commit chính là dấu vết kiểm toán. Anthropic dạy nó dưới dạng một khóa học miễn phí 14 bài, khoảng một giờ, viết cho các doanh nghiệp có cổng review; chúng tôi kiểm tra xem điều gì còn trụ được khi gặp một lập trình viên làm việc một mình.

Repository là ứng dụng demo RealWorld (Express, TypeScript, Prisma, Postgres) — một dự án thật với test thật, và một suite bị hỏng ngay khi clone mới (bốn suite pass, 14 test xanh, hai giây để chạy). Lỗi đó sau này trở thành nhóm đối chứng. Quy tắc chấm điểm: một gate đáng giá khi đầu ra của nó thay đổi thứ được ship, với chi phí thấp hơn giá trị mang lại.

Vé vào cửa là một file bộ nhớ ở thư mục gốc repo — lệnh, quy ước, kiến trúc, những lỗi mà model cứ lặp lại, giữ dưới một trang. File của chúng tôi được viết và commit trong 63 giây với $0.44. Một lưu ý trung thực về phương pháp: các lần chạy headless nén các buổi phỏng vấn của playbook thành những prompt đơn lẻ.

Plan: intent.md trong hai mươi chín giây

Gate đầu tiên ghi lại ý tưởng trước khi bất kỳ ai thiết kế gì. Yêu cầu tính năng: người đọc muốn tắt tiếng những tác giả làm ngập feed của họ. Playbook gọi kết quả là một proto-spec — viết cùng model, do bạn sở hữu — và cho phép ba nguồn gốc: một ý tưởng, một ticket đã tạo, hoặc một cảnh báo sự cố. Template có năm mục mà tiêu đề của chúng đã làm phần suy nghĩ: vấn đề, kết quả đề xuất, người dùng và hệ thống bị ảnh hưởng, ràng buộc, câu hỏi còn bỏ ngỏ. Vòng làm việc gồm năm bước: mô tả, brainstorm, sinh từ template, chỉnh sửa, commit.

intent.md thời gian chi phí
Tính năng tắt tiếng tác giả 29 s $0.18
Suite test bị hỏng 39 s —

Giá trị nằm ở cuối, trong các câu hỏi còn bỏ ngỏ: điều gì xảy ra với các mục yêu thích của một tác giả bị tắt tiếng? Trang của họ có còn truy cập được không? Đây là những quyết định mà một coding agent sẽ âm thầm tự đưa ra, giờ được viết ra và ghi ngày. File được commit, nên quyền tác giả và dấu thời gian còn lại sau cuộc chat, và product owner chỉnh bản nháp trước khi chấp nhận. Mục tiêu của chính Anthropic cho giai đoạn này là khai thác yêu cầu trong vài giờ thay vì vài tuần; làm một mình thì chưa đến một phút.

Design: spec tự chỉ ra điều kiện tiên quyết của nó

Gate thứ hai biến intent thành spec chỉ với một prompt của khóa học: đọc intent, tạo spec yêu cầu và thiết kế, áp dụng các skill có sẵn — những skill được cho là mang chính sách thương hiệu, bảo mật và UX của bạn. Hai phút sau chúng tôi có khoảng 2.300 từ spec khá tốt: endpoint, mô hình dữ liệu, hành vi của feed, các trường hợp biên. Nó thậm chí còn ghi lại những gì nó không thể đáp ứng, đúng như prompt yêu cầu.

Điểm đáng chú ý nằm ở các mối lo được gắn cờ, do chính model viết: "C0. No org skills available. This spec has not been checked against any policy." Toàn bộ tiền đề của giai đoạn này giả định những file mà hầu hết các thiết lập đều không có — các video giải thích bỏ qua điều kiện tiên quyết đó; agent đã ghi nó ra giấy trắng mực đen. Cờ thứ hai nhẹ hơn: các giá trị mặc định của câu hỏi bỏ ngỏ cần product sign-off trước khi build.

Bài học rất nghiêm về việc ghép cặp (spec và intent được commit cùng nhau, một con người phê duyệt việc chuyển sang build), và có một hóa đơn đọc: khoảng 12 phút thời gian của product owner cho mỗi spec. Playbook thậm chí còn theo dõi rework — các commit spec có ngày sau khi build bắt đầu sẽ bị tính là điểm trừ. Với một đội đã mã hóa chính sách của mình, gate này là nơi chúng được thực thi. Làm một mình, bạn đang trả tiền cho một lời hứa mà thiết lập chưa thể giữ.

Build: plan mode, TDD và vòng lặp thực sự kiểm tra gì

Gate thứ ba là Plan Mode, và tiêu chuẩn của nó khắt khe mà hữu ích: một kỹ sư chưa từng thấy cuộc hội thoại phải có thể triển khai chỉ từ plan. Plan Mode tự thực thi phần đọc: model không thể sửa file cho đến khi plan được chấp nhận. Plan của chúng tôi dài khoảng 4.000 từ, hoàn thành trong bốn phút, nêu tên các file thay đổi, thứ tự công việc, rủi ro và cách chứng minh, đồng thời ghi lại ba sai lệch có gắn nhãn so với spec, những sai lệch này sẽ quay lại ở bước review.

Quá trình build chạy trên một vòng lặp: viết test thất bại, làm cho nó pass, một mục tiêu, tất cả xanh hoặc nhiệm vụ chưa xong. Vòng lặp được bảo vệ (agent sửa code không được làm yếu phần kiểm tra trên đoạn code đó) và đi kèm một verifier — một lần kiểm tra thứ hai trong ngữ cảnh mới, không bị ảnh hưởng bởi phiên đã viết code.

Kết quả build giá trị
Thời gian agent ~9 phút, 91 lượt
Chi phí ~$2
Thay đổi 15 file, bảng Mutes, hai endpoint, cả hai feed đều được lọc
Test 5 suite, 50 test, tất cả xanh khi chạy lại độc lập
Merge ngay lần đầu có

Dấu hoa thị: màu xanh chỉ chứng minh những gì vòng lặp chứa, không hơn. End-to-end chưa bao giờ được chạy — nó cần một server thật và một cơ sở dữ liệu đã seed, và một vòng lặp nhắm vào các bản giả cũ sẽ sáng xanh y như vậy. Ở quy mô đội, có thêm các phiên song song trong worktree (hai hoặc ba là mức trần được nêu); chúng tôi chưa thử.

Deploy: review, và cổng đã nói không

Gate deploy có hai lớp, và cả hai đều nói không với chúng tôi. Lớp một đọc diff theo một chính sách viết sẵn ở thư mục gốc repo: ba lượt (lỗi, bảo mật, tuân thủ so với spec và plan), "Important" chỉ dành cho hành vi hỏng, dữ liệu bị rò rỉ hoặc vi phạm chính sách, tối đa năm nit còn phần dư được tóm tắt bằng một con số — chính sách tự giới hạn độ nhiễu của nó. Hai phút review, $0.80, và nó chạy các kiểm tra thật: test, build, lint so với baseline đã ghi trong plan, định dạng trên chín file. Kết luận: không có phát hiện Important nào, sáu nit, một nit vượt trần được tóm tắt. Nó khép lại bằng một câu chúng tôi không yêu cầu: agent này không phê duyệt — quyền phê duyệt vẫn thuộc về một code owner là con người đứng sau branch protection.

Lớp hai là chính cái gate. Chúng tôi yêu cầu deploy; model tự từ chối, vì tính năng chưa nằm trên nhánh ship. Đó là phán đoán, không phải cưỡng chế. Vậy nên chúng tôi merge và hỏi lại: bốn dòng shell trả lời trong 14 giây — bị chặn, cần có ủy quyền release. Exit code 2 dừng lệnh gọi tool và lý do được trả về cho model. Phía pipeline cũng được xử lý tương tự: một build hỏng được phân loại headless trong 11 giây với $0.13 — nó đọc log, chỉ ra nguyên nhân chính xác, và đề xuất diff mà không chạm vào file nào. Xác định luôn thắng lịch sự; một hook chỉ tốt bằng pattern của nó, và hook của chúng tôi chỉ khớp với một script.

Thuế của gate

Cùng một lỗi, cùng một điểm khởi đầu bị hỏng, hai con đường — thí nghiệm đối chứng. Đường một: cứ sửa thẳng. Đường hai: toàn bộ chuỗi, từ intent đến build.

sửa trực tiếp toàn bộ chuỗi hệ số nhân
Thời gian thực 2:13 11:31 ×5.2
Chi phí $0.70 $3.46 ×4.9
Lượt 40 169 —
Kết quả suite xanh suite xanh giống hệt

Hóa đơn máy móc chỉ là nửa nhỏ. Chuỗi đã viết khoảng 5.500 từ artifact cho một lỗi sửa một dòng — khoảng 27 phút con người đọc cho một diff mà bạn có thể lướt qua trong một lần. Chuỗi này biến thời gian viết thành thời gian đọc; đó là thuế của gate.

Playbook còn thêm một khoản phí định kỳ: continuous eval. Hai mươi đến năm mươi tác vụ thật, chạy lại với mỗi thay đổi cấu hình — mỗi case là một tác vụ thật trong quá khứ, prompt nguyên bản, chạy từ commit trước thay đổi, với tiêu chí chấp nhận kiểm tra được. Viết năm case từ lịch sử mất năm phút; chạy đúng thì không dễ như vậy — harness đầu tiên của chúng tôi nhắm hai case vào sai commit, và cả hai agent đều phát hiện ra thay vì giả vờ pass. Với khoảng một phút mỗi case, một suite đầy đủ tốn tới một giờ thời gian agent cho mỗi lần chạy, và mỗi sự cố production được cho là phải gia nhập suite như một regression eval vĩnh viễn. Với một đội chịu quy định, việc đọc đó chính là sản phẩm bàn giao; làm một mình, đó là chi phí thừa.

Kết luận: ba trên sáu gate đáng giá

Ba trên sáu gate tự bù được chi phí của mình:

Giai đoạn kết luận bằng chứng
Plan giữ 40 s mua được những câu hỏi chưa ai hỏi
Build giữ plan mode + vòng lặp test đã ship 50 test xanh
Deploy giữ review $0.80 với kiểm tra thật, chặn xác định trong 14 s
Design bỏ nếu làm một mình tính tiền bạn cho các chính sách bạn chưa mã hóa
Test (continuous eval) có thể đợi tới một giờ mỗi lần chạy, dễ nhắm sai
Maintain chưa được chứng minh cần nhiều tuần telemetry production

Maintain trên giấy rất thanh lịch — các script xác định theo dõi các dải kiểm soát, và một lần vượt dải sẽ viết ra một file intent mới — nhưng để chứng minh nó cần telemetry production mà chúng tôi không có. Tài liệu của chính Anthropic, như một nhà phân tích đã nói, không có phép đo nào ở bất kỳ đâu; đây là những con số đầu tiên, với những giới hạn hiển nhiên: một repo, một lập trình viên, một ngày.

Dữ liệu bên ngoài cho thấy áp lực này là có thật. Faros theo dõi hơn 10.000 lập trình viên trong hơn 1.200 đội: các đội áp dụng mạnh merge nhiều hơn 98% pull request, thời gian review tăng 91%, và pull request trung bình lớn hơn hơn gấp đôi. Báo cáo DORA mới nhất cũng cùng nhịp: thông lượng tăng khi có AI, độ ổn định giảm. Review đang trở thành nút thắt, và playbook nhắm đúng vào đó. Các biến thể từ cộng đồng đã cắt chuỗi xuống còn hai quyết định của con người — một biến thể cung cấp template và sổ cái gate, biến thể kia chỉ giữ con người ở design và test. Hãy áp dụng ba gate đáng giá, và mở rộng sang phần còn lại khi đội của bạn đủ lớn. Câu kết của chính Anthropic là lời đề từ phù hợp: vòng lặp vẫn tiếp tục chạy, phán đoán của con người vẫn đứng trên nó.

Nguồn

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

Playbook SDLC AI-native của Anthropic là gì?
Một khóa học Claude Academy miễn phí gồm 14 bài, cấu trúc việc phát triển bằng AI thành sáu giai đoạn (plan, design, build, test, deploy, maintain), mỗi giai đoạn kết thúc bằng một file đã commit mà giai đoạn sau đọc — intent.md, spec.md, plan.md, pull request và bản ghi sự cố.
Có đáng làm theo playbook SDLC AI-native không?
Đo trên một repo thật, ba trên sáu gate tự bù được chi phí: plan (29–40 s cho những câu hỏi chưa ai hỏi), build (plan mode cộng vòng lặp TDD đã ship một tính năng 15 file với 50 test xanh), và deploy (một lượt review $0.80 với kiểm tra thật cùng một hook chặn xác định). Design, continuous eval và maintain chỉ đáng giá khi một đội đã mã hóa chính sách và sở hữu telemetry production.
Toàn bộ chuỗi artifact tốn bao nhiêu so với sửa trực tiếp?
Với cùng một lỗi, sửa trực tiếp mất 2:13 và $0.70; toàn bộ chuỗi intent → spec → plan → build mất 11:31 và $3.46 — khoảng năm lần thời gian và chi phí cho cùng một kết quả, cộng thêm ~27 phút con người đọc.
Hook của Claude Code hoạt động như gate deploy thế nào?
Một hook PreToolUse đọc mọi lệnh Bash trước khi chạy; nếu lệnh khớp một pattern được bảo vệ (như deploy-prod), nó in ra lý do và thoát với exit code 2, điều này chặn lệnh gọi tool và trả lý do về cho model. Hook của chúng tôi trả lời trong 14 giây.
Continuous eval trong playbook là gì?
Một suite gồm 20–50 tác vụ thật trong quá khứ, chạy lại với mỗi thay đổi cấu hình, mỗi case có tiêu chí chấp nhận kiểm tra được. Viết năm case mất năm phút, nhưng một suite đầy đủ tốn tới một giờ thời gian agent cho mỗi lần chạy, và mỗi sự cố production được cho là phải gia nhập suite như một regression eval.
AI coding có thật sự chuyển nút thắt sang review không?
Dữ liệu thực địa nói là có: telemetry của Faros trên hơn 10.000 lập trình viên cho thấy các đội áp dụng mạnh merge nhiều hơn 98% pull request trong khi thời gian review tăng 91% và kích thước PR trung bình hơn gấp đôi; báo cáo DORA mới nhất cho thấy thông lượng tăng và độ ổn định giảm.

Video liên quan