Anthropic vừa công bố một tài liệu mang tên vòng đời phát triển phần mềm AI-native, công khai chia quy trình phát triển mà công ty đã tái cấu trúc nội bộ xoay quanh Claude thành sáu giai đoạn. Điểm xuất phát của tài liệu được nói thẳng: việc sinh mã không còn là nút thắt cổ chai nữa; các quy trình truyền thống được thiết kế theo tốc độ con người gõ tay từng dòng mã, nên điểm nghẽn giờ đã chuyển sang chỗ khác.
Sáu giai đoạn lần lượt là lập kế hoạch, thiết kế, xây dựng, kiểm thử, triển khai và bảo trì, và cách làm của từng giai đoạn đều được viết lại. Lập kế hoạch, từ chỗ họp bàn nhu cầu cộng tài liệu viết tay, chuyển thành trò chuyện với Claude để tạo ra intent.md — tài liệu cho biết chu kỳ được rút từ vài tuần xuống còn vài giờ. Thiết kế tạo ra spec.md trong một phiên làm việc và chạy kiểm tra chính sách. Xây dựng bắt đầu bằng plan.md rồi mới đi vào triển khai thực tế. Kiểm thử không còn chờ ở ranh giới giai đoạn nữa — đánh giá liên tục được gộp thẳng vào quá trình triển khai. Triển khai được thay bằng rà soát tự động theo lớp cộng với Hook canh gác. Bảo trì thì chuyển từ phản ứng bị động với cảnh báo sang tự động phát hiện rồi sinh ra một intent.md mới, quay vòng lại điểm xuất phát.
Thứ nối liền sáu giai đoạn này là tệp tin, không phải cuộc họp. intent.md chuyển giao cho spec.md, spec.md chuyển giao cho plan.md, tiếp theo là PR và kết quả rà soát, cuối cùng bản ghi sự cố vòng trở lại intent.md. Tài liệu tóm gọn chuỗi này thành một câu: mỗi giai đoạn nộp ra một sản phẩm để giai đoạn sau đọc.
Bốn công cụ quản trị
Skills đảm nhiệm tri thức được thể chế hóa. Những thứ như tiêu chuẩn bảo mật API, quy chuẩn thương hiệu được viết vào .claude/skills/; khi chính sách thay đổi, chỉ cần sửa một lần ở trung tâm, kỹ sư sẽ tự động nhận bản mới ở phiên làm việc kế tiếp. Ví dụ trong tài liệu là một skill tên secure-api-review, chuyên theo dõi xác thực, kiểm tra đầu vào và nhật ký kiểm toán.
Hooks phụ trách kiểm soát mang tính xác định, không có đường vòng thủ công. Ở giai đoạn xây dựng, nó chặn việc chỉnh sửa các gói phụ thuộc đã đóng băng phiên bản, buộc phải chạy định dạng lại; ở giai đoạn triển khai, việc phát hành lên môi trường sản xuất cần có sự cho phép của release manager — nếu chưa được cho phép, quy trình bị chặn thẳng với mã thoát exit 2.
CLAUDE.md là bộ nhớ của đội nhóm, giới hạn trong một trang: lệnh build, quy ước, kiến trúc, những lỗi hay mắc phải. Quy tắc bảo trì mà tài liệu đưa ra rất thực dụng — cùng một lỗi lặp lại lần thứ hai thì phải ghi vào đó.
evals được dùng như bài kiểm thử hồi quy. Một bộ đánh giá gồm 20 đến 50 tác vụ thực tế, hễ cấu hình thay đổi là chạy lại, ngoài ra còn có một lượt chạy định kỳ mỗi đêm; mỗi sự cố sản xuất đều được cố định hóa thành một eval vĩnh viễn, và tỷ lệ đạt được dùng trực tiếp làm điều kiện để merge.
Một tính năng tra cứu trạng thái bồi thường đi hết toàn bộ quy trình như thế nào
Ca ví dụ mà tài liệu nêu ra là tính năng tự tra cứu trạng thái bồi thường. Bộ phận vận hành viết intent.md trước, nêu rõ vấn đề, người dùng và các ràng buộc; sau khi trưởng sản phẩm rà soát và phê duyệt thì mới bước vào giai đoạn thiết kế; Claude áp dụng các skill về UX và bảo mật để sinh ra spec.md; kỹ sư vào plan mode để lấy plan.md, sau đó Claude Code thực hiện triển khai, PR qua được review hook thì mới được merge.
Các ràng buộc được ghi rõ ràng ngay trong kế hoạch: giao diện claims-core giới hạn 50 request mỗi giây, nên plan.md đánh dấu cần có cơ chế cache; trong phiên làm việc không được thêm bất kỳ thông tin định danh cá nhân nào; xác thực dùng phương án sẵn có. Một đội khác phụ trách dịch vụ thanh toán thì có CLAUDE.md ghi rõ: Java 21, Spring Boot 3, cấm dùng Lombok, số tiền bắt buộc dùng BigDecimal chứ không phải double, phiên bản phụ thuộc do đội nền tảng quản lý, không được tự ý đổi.
Tự động hóa ở giai đoạn bảo trì được phân theo ba mức ngưỡng. Lấy tỷ lệ thất bại của kiểm thử CI làm ví dụ: mốc nền lấy theo 30 ngày gần nhất theo kiểu cuốn chiếu, ở mức 1 sigma chỉ ghi nhận lại, ở mức 2 sigma Claude được cấp quyền chỉ đọc để chẩn đoán, chỉ đến mức 3 sigma mới cho phép nó mở PR hoặc kích hoạt một runbook đã được phê duyệt trước. Bản thân kịch bản phát hiện bất thường mang tính xác định — nó dùng quy tắc Western Electric để phán đoán, không giao cho mô hình quyết định.
Danh sách chỉ số cho thấy độc giả thực sự là ai
Các chỉ số dẫn dắt gồm thời gian từ cuộc trò chuyện đầu tiên đến khi nộp intent.md, thời gian từ lúc nộp đến lượt rà soát đầu tiên, số phiên agent chạy song song, và tỷ lệ CI đạt. Các chỉ số trễ gồm tỷ lệ intent.md được phê duyệt, tỷ lệ triển khai lần đầu đạt yêu cầu, xu hướng số phát hiện qua rà soát PR, tỷ lệ sự cố sản xuất lặp lại, và số PR mỗi kỹ sư merge được mỗi tuần.
Đi kèm còn có hai lộ trình tuân thủ tương ứng: một lộ trình lấy Jira hoặc ServiceNow làm bản ghi có thẩm quyền, markdown chỉ là bản làm việc, được đồng bộ ngược về hệ thống cũ qua một MCP connector; lộ trình còn lại lấy kho mã nguồn làm nguồn sự thật duy nhất, hệ thống cũ chỉ tham chiếu tới commit SHA. Dấu vết kiểm toán được ghép lại từ bốn nguồn: lịch sử Git, các luồng thảo luận PR, nhật ký hành vi agent xuất ra qua OpenTelemetry, và nhật ký cho phép/chặn của Hook.
Tất cả những thứ này không hướng tới nhà phát triển cá nhân. Ước tính sơ bộ, một tổ chức kỹ thuật vài trăm người nếu triển khai bộ đánh giá theo quy mô mà tài liệu mô tả, mỗi lần đổi cấu hình lại chạy một lượt cộng thêm một lượt định kỳ mỗi ngày, riêng chi phí suy luận đã là một khoản chi thường niên không nhỏ, chưa kể Skills và Hooks còn cần người chuyên trách bảo trì — bản thân các công cụ quản trị đã tốn tiền tốn người, mà lợi ích thường phải vài quý sau mới thấy rõ. Đây cũng chính là chỗ mà kiểu cải tổ quy trình này thường bị tắc lại ở các công ty quy mô vừa. Những tổ chức sẵn sàng trả giá cho dấu vết kiểm toán mới thực sự là khách hàng mà cẩm nang này nhắm tới.
Nguồn tham khảo: tài liệu kỹ thuật chính thức của Anthropic, CocoLoop, tài liệu sản phẩm Claude Code; đã đối chiếu tên gọi các sản phẩm của sáu giai đoạn, cấu hình ba mức ngưỡng và số lượng bộ đánh giá.