Bài 8 — Vận hành thực chiến: quy trình end-to-end từ spec đến giao hàng

Bảy bài trước dạy từng mảnh. Bài này ghép chúng thành một quy trình vận hành bạn dùng được ngay cho một feature thật, và cách xử lý các tình huống phát sinh trong đời thực.

Quy trình end-to-end (một feature)

• Tạo nhánh: git switch -c feature/003-export.
• Viết spec vào specs/003-export.md (mục tiêu, AC đo được, ràng buộc, ngoài phạm vi, câu hỏi mở).
• Nhờ agent phản biện spec: "Chỉ ra chỗ mơ hồ/thiếu". Vá spec.
• Sinh plan: agent chia task, liệt kê giả định, ghi vào plans/003-export.plan.md.
• Duyệt plan: đối chiếu AC, soi giả định, sắp thứ tự, cắt phạm vi.
• Vòng lặp task: mỗi task → test-first → code → review diff → npm run check → commit.
• Cập nhật plan sau mỗi task (đánh dấu ✅ + commit hash).
• Nghiệm thu cuối: chạy full test, rà từng AC trong spec đã tick chưa.
• Mở PR tham chiếu spec; tự review lần cuối trước khi merge.

Ví dụ rút gọn một phiên thật

Bạn: Đọc specs/003-export.md + AGENT.md. Phản biện spec, đừng code.
Agent: 3 chỗ mơ hồ — định dạng ngày? encoding UTF-8 BOM? giới hạn số dòng?
Bạn: [vá spec: ISO-8601, UTF-8 BOM, tối đa 50k dòng/ file]
Bạn: Giờ tạo plan vào plans/003-export.plan.md, liệt kê giả định.
Agent: [plan 4 task]
Bạn: T3 (streaming) rủi ro cao, làm trước T2. Bắt đầu T1, test-first.
...

Bạn giữ quyền quyết định ở mỗi ranh giới; agent làm phần nặng nhọc.

Xử lý tình huống thực tế

Yêu cầu đổi giữa chừng: Đừng nhét thẳng vào chat. Sửa spec trước, rồi cho agent cập nhật plan (task nào thêm/bỏ), rồi mới code. Spec luôn là nguồn sự thật.

Agent kẹt vòng lặp sửa lỗi: Sửa mãi một test không xong thường là dấu hiệu spec/plan sai giả định. Dừng code, quay lại làm rõ spec, không để agent "thử mò" đốt token.

Feature lớn, nhiều phần phụ thuộc: Chẻ thành nhiều spec nhỏ (003a, 003b), mỗi cái một vòng lặp riêng, merge dần. Đừng gộp một spec khổng lồ.

Bàn giao cho người khác/AI khác: Spec + plan + test là tài liệu bàn giao. Người mới đọc chúng là hiểu, không cần bạn giải thích miệng.

Khung "cổng chất lượng" trước khi merge

Một PR spec-driven chỉ qua cổng khi:

• Mọi acceptance criteria trong spec đã tick và có test phủ.
• npm run check xanh, không có test bị vô hiệu/bị bóp ngưỡng.
• Diff không chứa gì ngoài phạm vi spec.
• Ràng buộc bảo mật/hiệu năng được test bảo vệ.
• Plan phản ánh đúng những gì đã làm và quyết định đã chốt.

Chỉ số cho biết bạn đang làm đúng

• Ít lần "làm lại từ đầu"; sửa lệch xảy ra ở bước spec/plan (rẻ), không ở cuối (đắt).
• Diff mỗi task nhỏ, review nhanh, hiếm khi có "bonus ngoài spec".
• Người khác đọc spec/plan là tiếp nối được ngay.
• Test đỏ trước, xanh sau — không có test giả.

Checklist giao hàng một feature

• [ ] Làm trên nhánh riêng, PR tham chiếu spec.
• [ ] Spec đã được phản biện + vá trước khi lập plan.
• [ ] Plan được duyệt, cắt phạm vi, sắp theo rủi ro.
• [ ] Mỗi task: test-first, review diff, check xanh, commit nhỏ.
• [ ] Mọi AC tick + có test; không thứ gì ngoài phạm vi lọt vào.
• [ ] Plan cập nhật đầy đủ để bàn giao.

Sai lầm thường gặp

• Nhét yêu cầu mới vào chat mà không sửa spec: Spec lỗi thời, nguồn sự thật vỡ, drift quay lại.
• Để agent "thử mò" khi kẹt: Đốt token, đào sâu hố sai. Quay về làm rõ spec.
• Gộp feature khổng lồ vào một spec: Plan phình, review đuối. Chẻ nhỏ.
• Bỏ cổng chất lượng vì "gấp": Nợ kỹ thuật dồn lại đắt gấp bội.
• Quay lại vibe coding khi thấy quen tay: Nhanh trước mắt, mất kiểm soát và drift ngay sau.

Tổng kết khóa học

Spec-driven với agent là kỷ luật đơn giản mà mạnh: viết spec → agent lập plan → code theo task → review từng bước. Bạn giữ quyền quyết định ở mọi ranh giới, agent lo phần nặng, và test là lưới an toàn tự động. Áp dụng nhất quán, bạn biến AI agent từ "cỗ máy sinh code hên xui" thành cộng sự kỹ thuật đáng tin. Hãy làm bài thi tổng kết để kiểm tra khả năng vận dụng.