Đồng Use Claude — Phần 4: PLAN, kế hoạch thi công cho AI

SPEC nói làm gì. PLAN nói làm theo thứ tự nào, đụng file nào, và chứng minh xong bằng cách nào. Khác biệt cốt lõi so với thuê ngoài truyền thống: plan ở đây không phải timeline cho người — nó là chỉ thị thi công cho AI, kèm tiêu chí nghiệm thu mà chính AI phải tự chứng minh.

Bài 4 trong series. Đã có INTENT và SPEC cho app sổ khách; giờ lập kế hoạch thi công.

Cấu trúc file PLAN

1. Files that change — bảng file sẽ tạo/sửa. Đây là phần bạn “khoá vùng” cho AI: đụng file ngoài bảng này phải hỏi lại.
2. Order of work — thứ tự làm, bước nào trước bước nào và vì sao.
3. Risks & mitigations — rủi ro kỹ thuật đã dự phòng trước.
4. Proof — tiêu chí chứng minh việc xong, viết trước khi code. Đây là phần biến bạn thành QA.

Nguyên tắc: proof viết trước code. Nếu viết tiêu chí nghiệm thu sau khi thấy app chạy, bạn sẽ vô thức hạ chuẩn cho vừa với cái đã có — giống nghiệm thu nhà xong mới vẽ bản vẽ.

Ví dụ hoàn chỉnh: PLAN-01.md cho sổ khách

# Plan: sổ khách (mini-CRM)
Ref: spec/SPEC-01.md

## 1. Files that change
| file             | action | chứa gì                        |
|------------------|--------|---------------------------------|
| package.json     | New    | deps: hono, wrangler (dev)      |
| wrangler.jsonc   | New    | Worker config + D1 binding `DB` |
| tsconfig.json    | New    | TS cho Workers                  |
| schema.sql       | New    | bảng customers [SPEC §3]        |
| src/index.ts     | New    | Hono app: API + trang HTML      |
| test/TEST-01.md  | New    | kịch bản nghiệm thu             |

Đụng file ngoài bảng → dừng, hỏi lại.

## 2. Order of work
1. schema.sql trước — UNIQUE(phone_norm) là nền [BR-2]
2. API trước, HTML sau — test API bằng curl được ngay
3. Import (FR-4) làm cuối — nó dùng lại hàm merge của FR-3

## 3. Risks & mitigations
- [RSK-1] Hai request cùng phone đến đồng thời, cả hai
  check "chưa có" rồi cùng insert → trùng.
  Mitigation: KHÔNG check-then-insert. Insert thẳng,
  UNIQUE constraint ném lỗi → catch → merge vào bản cũ.
- [RSK-2] D1 local khác production.
  Mitigation: test trên `wrangler dev` local trước,
  deploy rồi chạy lại kịch bản test trên URL thật.
- [RSK-3] Paste CSV lỗi format.
  Mitigation: dòng lỗi → skipped, không fail cả batch [BR-5].

## 4. Proof
- [PRF-1] POST tạo khách mới → 201, merged:false
- [PRF-2] POST lại cùng phone viết kiểu "+84 ..."
  → merged:true, trả về đúng id cũ
- [PRF-3] Import 3 dòng (2 trùng nhau) → added:1,
  merged:1, skipped:1
- [PRF-4] 10 request POST đồng thời cùng một phone
  → DB có đúng 1 row [BR-2]
- [PRF-5] Mở / trên trình duyệt điện thoại → form
  dùng được, không vỡ layout [SPEC §5]

Chỗ quan trọng nhất là [RSK-1] + [PRF-4]: kịch bản “10 người cùng tạo một số phone trong cùng giây” là thứ app demo-cho-vui không bao giờ giả được. Nếu AI implement bằng cách “tìm xem có chưa rồi mới insert”, cả 10 request đều thấy chưa có → tạo 10 bản ghi trùng. UNIQUE constraint ở database mới là chỗ chặn đúng — và đó là lý do nó nằm trong spec từ bài trước.

Cách làm với Claude Code

> Đọc intent/INTENT-01.md và spec/SPEC-01.md. Viết
  plan/PLAN-01.md theo cấu trúc: files-that-change,
  order of work, risks & mitigations, proof. Chưa viết
  code. Stack: Cloudflare Workers + Hono + D1, free tier.
  Proof phải là lệnh/kịch bản chạy được, không phải câu
  mô tả.

Sau khi có bản nháp, bạn — với tư cách Risk Owner — đọc kỹ hai mục cuối:

• Risks: có rủi ro nào AI không liệt kê mà bạn biết từ thực tế vận hành không? (VD: “nhân viên hay nhập phone có khoảng trắng đầu cuối” → thêm vào BR-1.) Đây là chỗ kinh nghiệm nghiệp vụ của bạn đáng tiền hơn cả việc viết code.
• Proof: mỗi PRF phải là thứ bạn tự tay kiểm được hoặc AI chạy được và show output. “App hoạt động đúng” không phải proof.

Dấu hiệu plan đủ tốt

• Một người khác cầm file này biết chính xác AI sẽ đụng file nào — bất ngờ ở bước build gần như bằng 0.
• Mỗi FR trong spec có ít nhất một PRF bao trùm.
• Mỗi rủi ro có mitigation là hành động cụ thể, không phải “cẩn thận”.

Bài tập

1. Viết plan/PLAN-01.md cho app của bạn.
2. Với mỗi BR quan trọng trong spec, viết một PRF tương ứng dạng “làm X → kỳ vọng Y”.
3. Chọn một kịch bản đối kháng (concurrent, input rác, mạng chập chờn) và bắt nó thành proof — đây là thứ phân biệt app thật và demo.

Nguồn tham khảo

• Phần 3 — SPEC
• The AI-native SDLC playbook — Anthropic

Bài tiếp theo: Phần 5 — BUILD.