Đây là bài thực hành tổng hợp (capstone) của module quản lý hội thoại nhiều lượt (multi-turn conversation). Bốn topic trước đã trang bị cho bạn từng mảnh kỹ năng riêng lẻ: quản lý lifecycle của một session, tối ưu ở cấp độ từng turn, phát hiện và sửa drift (trôi hướng hội thoại), và kỹ thuật checkpoint (lưu điểm) để chuyển giao trạng thái giữa các session. Bài này ghép tất cả lại thành một quy trình duy nhất, áp dụng trên một case study cụ thể.

Cách dùng bài viết này: đừng đọc lướt. Hãy đọc case study, tự mình dự đoán câu trả lời trước khi xem phần diagnosis, rồi làm lại bài tập ở Step 5 với một conversation thật của chính bạn. Kỹ năng tái cấu trúc conversation không học được qua lý thuyết — nó chỉ hình thành sau khi bạn tự tay "phẫu thuật" một session bị phình to ít nhất một lần.

Ba nhóm nhân sự sẽ xuất hiện xuyên suốt case study: một kỹ sư phần trăm chính (backend/frontend), một QA engineer, và một product manager (PM) — vì trong thực tế, một feature như "checkout" hiếm khi chỉ có một người dùng AI agent, và mỗi vai trò sẽ có cách bloat và cách tái cấu trúc khác nhau.

Bối Cảnh: Session Xây Dựng Tính Năng Checkout (Thanh Toán)

Hãy tưởng tượng một nhóm phát triển tại một startup thương mại điện tử vừa nhận yêu cầu: xây dựng lại toàn bộ luồng checkout (thanh toán) cho ứng dụng, hỗ trợ nhiều phương thức thanh toán (thẻ, ví điện tử, COD), áp dụng mã giảm giá, và xử lý các trường hợp lỗi (hết hàng giữa lúc thanh toán, thẻ bị từ chối, timeout với cổng thanh toán).

Kỹ sư phụ trách — gọi là Minh — mở một cửa sổ chat mới với AI coding assistant và bắt đầu làm việc. Ban đầu mọi thứ suôn sẻ: agent giúp Minh phân tích yêu cầu, đề xuất kiến trúc, viết code cho luồng happy path. Nhưng vì công việc "cứ trôi tự nhiên" và không có điểm dừng rõ ràng nào, Minh không bao giờ đóng session lại. Anh cứ tiếp tục hỏi trong đúng một context window (bộ nhớ ngữ cảnh) đó, hết ngày này qua ngày khác, đến khi conversation đạt tới turn thứ 50.

Đây là bức tranh tổng thể về những gì đã xảy ra trong 50 turn đó:

• Turn 1–10 — Requirements và thiết kế. Minh mô tả yêu cầu nghiệp vụ, agent hỏi lại vài câu để làm rõ (loại thanh toán nào cần hỗ trợ, có cần lưu thẻ không, luồng khách vãng lai có khác luồng khách đã đăng nhập không). Agent đề xuất kiến trúc: một CheckoutService xử lý orchestration, tách riêng PaymentGateway adapter cho từng phương thức thanh toán, và một OrderStateMachine để quản lý trạng thái đơn hàng. Đây là phần giá trị nhất của cả session — quyết định kiến trúc được đưa ra ở đây.
• Turn 11–25 — Implementation, với nhiều lần chuyển hướng và vòng lặp sửa lỗi. Agent viết code cho CheckoutService, Minh test thử, phát hiện lỗi race condition khi hai request cùng áp mã giảm giá vào một đơn hàng. Sau đó Minh đổi ý về cách lưu trạng thái đơn hàng (từ lưu trong Redis sang lưu trực tiếp trong Postgres), khiến agent phải viết lại một phần lớn code đã có. Có ít nhất ba vòng lặp "code lỗi → paste stack trace → agent sửa → lỗi khác xuất hiện" trong khoảng này.
• Turn 26–35 — Xử lý edge case, drift nhiều nhất. Minh bắt đầu liệt tự các trường hợp biên: hết hàng giữa lúc thanh toán, thẻ bị ngân hàng từ chối, timeout với cổng thanh toán bên thứ ba, người dùng đóng tab giữa lúc redirect sang trang thanh toán. Nhưng xen giữa đó, QA của team (Lan) cũng nhảy vào cùng thread để hỏi agent về cách viết test cho một microservice khác hoàn toàn (service quản lý kho hàng) — một chủ đề không liên quan đến checkout. Agent phải xử lý cả hai chủ đề trong cùng context, và bắt đầu trộn lẫn thuật ngữ giữa hai domain.
• Turn 36–50 — Viết test và tài liệu, chất lượng phản hồi giảm rõ. Đến giai đoạn viết unit test và integration test cho CheckoutService, agent bắt đầu quên một số quyết định kiến trúc đã chốt ở turn 3–8 (ví dụ đề xuất lại dùng Redis dù nhóm đã chuyển sang Postgres từ turn 18). PM (Hùng) cũng ghé vào thread để yêu cầu agent viết tài liệu mô tả tính năng cho stakeholder, khiến agent phải vừa viết test code, vừa viết văn bản mô tả nghiệp vụ, vừa nhớ lại toàn bộ lịch sử quyết định — trong một context đã chứa hàng chục nghìn token của code, stack trace, và thảo luận không còn liên quan.

Đến turn 50, thời gian phản hồi của agent tăng rõ rệt, số lần agent đề xuất lại giải pháp đã bị bác bỏ tăng lên, và team nhận thấy phải nhắc lại "chúng ta đã quyết định dùng Postgres rồi" ít nhất năm lần trong 15 turn cuối. Đây chính là bức tranh điển hình của một bloated session (session phình to) — đúng dạng conversation mà module này dạy bạn tránh, và bây giờ bạn sẽ học cách "cứu" nó.

Mẹo:
- Nếu bạn nhận ra nhóm mình đang lặp lại cùng một quyết định kiến trúc nhiều lần trong một thread, đó là dấu hiệu sớm nhất cho thấy session cần được tái cấu trúc — đừng chờ đến turn 50 mới hành động.
- Khi nhiều người (kỹ sư, QA, PM) cùng dùng một thread cho các mục đích khác nhau, hãy coi đó là tín hiệu cảnh báo ngay từ đầu, không phải là điều "tiện lợi".

Step 1: Chẩn Đoán Session Bị Phình To

Trước khi tái cấu trúc bất cứ thứ gì, bạn cần một bản chẩn đoán rõ ràng: drift xảy ra ở đâu, thuộc loại nào, và tốn bao nhiêu token oan uổng. Đây là bước áp dụng trực tiếp taxonomy drift từ topic 03 (scope creep drift — trôi phạm vi, repair drift — trôi do sửa lỗi, elaboration drift — trôi do giải thích thừa, và tool-result drift — trôi do kết quả tool call).

Turn-by-turn drift audit (rút gọn)

Dưới đây là audit rút gọn theo từng cụm turn, mỗi cụm gắn nhãn loại drift chiếm ưu thế:

Tóm tắt chẩn đoán

Tổng hợp lại, session này có ba điểm chuyển chủ đề (topic-shift) rõ ràng — (1) từ thiết kế sang implementation ở turn ~11, (2) từ implementation sang edge case ở turn ~26, và (3) từ edge case sang test/docs ở turn ~36 — nhưng không có bất kỳ checkpoint hay reset nào được thực hiện ở cả ba điểm này. Đây là nguyên nhân gốc số một.

Nguyên nhân gốc thứ hai: code và thảo luận liên quan đến giải pháp Redis đã bị loại bỏ (khoảng turn 9–18) vẫn tồn tại trong context, chiếm chỗ mà không còn giá trị — đây là dạng "xác chết" điển hình của repair drift không được dọn.

Nguyên nhân gốc thứ ba: việc để QA và PM chèn câu hỏi không liên quan vào cùng thread (turn 26–35 và 39–50) buộc agent phải giữ đồng thời nhiều domain kiến thức không liên quan, làm tăng nguy cơ trộn lẫn thuật ngữ và giảm độ chính xác.

Ước tính thô: trong tổng số ~50 turn, khoảng 18–20 turn (36–40%) chứa nội dung có thể coi là drift thuần túy — không đóng góp vào kết quả cuối cùng nhưng vẫn tốn token xử lý ở mọi turn tiếp theo vì nó nằm trong context window. Nếu tính theo token thực tế (bao gồm cả code, stack trace, giải thích lặp lại), tỷ lệ token lãng phí có thể lên đến 40–45% tổng chi phí của session — tức là gần một nửa số tiền/token nhóm đã trả cho session này không tạo ra giá trị giữ lại.

Mẹo:
- Khi audit, đừng chỉ nhìn "turn này có ích hay không" — hãy nhìn "turn này có còn ích ở turn thứ 50 không". Một quyết định đúng ở turn 10 nhưng bị đảo ngược ở turn 18 thì phần thảo luận gốc gần như vô giá trị với các turn sau.
- Đánh dấu các điểm topic-shift ngay khi audit — đó chính là ranh giới session tự nhiên cho bước tái cấu trúc ở Step 3.

Step 2: Trích Xuất Checkpoint — Giữ Lại Điều Quan Trọng

Sau khi đã biết cái gì là noise (nhiễu) và cái gì là tín hiệu, bước tiếp theo là trích checkpoint (điểm lưu trạng thái) áp dụng cấu trúc 5 thành phần từ topic 04: (1) Goal và Status, (2) Key Decisions, (3) Artifact State, (4) Blockers, (5) Next Actions.

Quy trình trích xuất thực tế trông như sau: đọc lại toàn bộ 50 turn một lần, nhưng lần này chỉ với câu hỏi "nếu tôi phải tóm gọn điều này cho một người chưa từng thấy conversation, họ cần biết gì để tiếp tục công việc mà không phá vỡ những gì đã làm đúng?". Với case checkout, câu trả lời sẽ loại bỏ: toàn bộ thảo luận về giải pháp Redis đã bị bỏ, các đoạn giải thích lặp lại về idempotency, câu hỏi không liên quan của QA về service kho hàng, và các vòng lặp debug đã kết thúc bằng một fix cụ thể (chỉ giữ lại fix, không giữ lại quá trình dò lỗi).

Kết quả checkpoint trông như thế này:

## Checkpoint — Tính Năng Checkout — Session 1

### Goal & Status
Xây dựng luồng checkout hỗ trợ thanh toán thẻ, ví điện tử, COD; áp mã giảm
giá; xử lý edge case. Đã hoàn thành: kiến trúc + happy-path implementation.
Chưa hoàn thành: edge case xử lý đầy đủ, test suite, tài liệu cho stakeholder.

### Key Decisions
- Kiến trúc gồm 3 thành phần: `CheckoutService` (orchestration),
  `PaymentGateway` adapter theo interface chung cho từng phương thức
  thanh toán, `OrderStateMachine` quản lý trạng thái đơn hàng.
- Trạng thái đơn hàng lưu trực tiếp trong Postgres (bảng `order_state_log`),
  KHÔNG dùng Redis — đã thử Redis ở giai đoạn đầu, bỏ vì race condition
  khi áp mã giảm giá đồng thời và vì team cần audit trail bền vững.
- Áp mã giảm giá dùng optimistic locking trên cột `version` của bảng
  `orders` để tránh race condition đã phát hiện ở bản Redis.
- Idempotency key bắt buộc cho mọi request tạo đơn hàng, dùng header
  `Idempotency-Key`, lưu 24h trong bảng `idempotency_keys`.

### Artifact State
- `CheckoutService.createOrder()` — hoàn thành, đã test thủ công happy path.
- `PaymentGateway` interface — hoàn thành; adapter cho thẻ tín dụng đã
  implement, adapter ví điện tử và COD CHƯA implement.
- `OrderStateMachine` — hoàn thành states cơ bản (pending, paid, failed);
  CHƯA có state cho "hết hàng giữa lúc thanh toán".

### Blockers & Open Questions
- Chưa quyết định: khi cổng thanh toán bên thứ ba timeout, có nên tự động
  retry hay chuyển thẳng sang trạng thái failed và yêu cầu người dùng
  thanh toán lại?
- Chưa rõ: đội kho hàng có API nào để "giữ hàng tạm" trong lúc thanh toán
  không, hay checkout phải tự implement cơ chế reserve riêng?

### Next Actions
1. Implement edge case: hết hàng giữa lúc thanh toán (cần trả lời Blocker
   thứ hai trước).
2. Implement adapter ví điện tử và COD.
3. Viết unit test + integration test cho `CheckoutService` và
   `OrderStateMachine`.
4. Viết tài liệu mô tả tính năng cho stakeholder (PM).

Chú ý những gì bị loại bỏ có chủ đích: toàn bộ đoạn code Redis cũ và lý do từng cân nhắc nó (chỉ giữ lại kết luận "không dùng Redis, vì sao"); các đoạn agent giải thích lại khái niệm idempotency ba lần khác nhau (chỉ giữ lại quyết định cuối, không giữ cách agent trình bày); câu hỏi của QA về test cho service kho hàng (hoàn toàn không liên quan đến checkout, nên không thuộc checkpoint này — nó cần một checkpoint/session riêng nếu QA muốn tiếp tục); và các stack trace cụ thể từ những vòng debug đã đóng (chỉ fix cuối cùng có giá trị, không phải hành trình dò lỗi).

Điều được giữ lại có chủ đích: mọi quyết định kiến trúc (vì đảo ngược một quyết định kiến trúc tốn nhiều turn hơn nhiều lần so với chi phí ghi lại nó); trạng thái chính xác của từng artifact (để session sau biết chỗ nào đã xong, chỗ nào chưa, tránh implement lại từ đầu); và các Blocker chưa có câu trả lời (để không bị lãng quên khi chuyển session).

Mẹo:
- Nếu một quyết định đã bị đảo ngược trong session (như Redis → Postgres), chỉ ghi quyết định cuối cùng và lý do đảo ngược — đừng ghi cả hai quyết định như thể chúng ngang giá trị.
- Checkpoint tốt luôn có phần Blockers rõ ràng. Nếu bạn viết checkpoint mà không tìm ra Blocker nào, quay lại đọc kỹ hơn — hầu như session dài nào cũng có ít nhất một câu hỏi mở chưa trả lời.

Step 3: Thiết Kế Multi-Session Workflow Tối Ưu

Có checkpoint trong tay, giờ là lúc quyết định phần việc còn lại nên chia thành bao nhiêu session, và session nào nên chạy tuần tự (sequential), session nào có thể chạy song song (parallel) — áp dụng khung phân tích từ topic 05.

Phân tích phụ thuộc (dependency) của phần việc còn lại

Nhìn vào Next Actions trong checkpoint, ta có bốn nhóm việc: (1) xử lý edge case hết hàng, (2) implement adapter ví điện tử/COD, (3) viết test, (4) viết tài liệu cho PM.

Phân tích phụ thuộc:
- Edge case hết hàng phụ thuộc vào việc trả lời Blocker về API "giữ hàng tạm" từ đội kho hàng — đây là việc cần làm sâu, tuần tự, vì nó ảnh hưởng trực tiếp đến cách OrderStateMachine được mở rộng, và các quyết định ở đây sẽ định hình lại phần lớn logic core.
- Adapter ví điện tử và COD về cơ bản độc lập với edge case hết hàng — chúng implement theo interface PaymentGateway đã có sẵn, không cần biết cách xử lý hết hàng ra sao. Đây là ứng viên tốt cho parallel.
- Viết test phụ thuộc vào cả hai nhóm trên (không thể viết integration test đầy đủ khi adapter và edge case chưa xong) — nhưng unit test cho phần code đã ổn định (ví dụ CheckoutService.createOrder() happy path) có thể viết song song, độc lập.
- Viết tài liệu cho PM phụ thuộc vào việc các quyết định nghiệp vụ đã chốt, nhưng không phụ thuộc vào chi tiết code — PM cần biết "hệ thống hỗ trợ những gì, xử lý lỗi ra sao ở mức khái niệm", không cần biết implementation detail. Đây có thể chạy song song với nhóm kỹ thuật, miễn là checkpoint được chia sẻ đầy đủ.

Cấu trúc session tối ưu

Từ phân tích trên, đề xuất cấu trúc bốn session:

• Session 2 (sequential, sâu): giải quyết Blocker về giữ hàng tạm, rồi implement edge case hết hàng giữa lúc thanh toán. Đây phải là sequential vì nó là phần phức tạp nhất về logic và ảnh hưởng đến state machine core.
• Session 3a (parallel, độc lập): implement adapter ví điện tử và COD, cộng với unit test cho phần code đã ổn định.
• Session 3b (parallel, độc lập, chạy đồng thời với 3a): viết tài liệu mô tả tính năng cho PM, dựa trên checkpoint Session 1 — không cần chờ Session 2 hoặc 3a hoàn thành vì tài liệu chỉ cần các quyết định nghiệp vụ đã chốt.
• Session 4 (synthesis): gộp kết quả từ Session 2, 3a, 3b — viết integration test cho toàn bộ luồng (bao gồm cả edge case mới và adapter mới), rà soát tài liệu PM có khớp với implementation cuối cùng không, và tạo checkpoint tổng kết cho toàn bộ tính năng.

Bản thiết kế (blueprint) cho từng session

Dưới đây là ba blueprint chi tiết, có thể dùng trực tiếp làm opening prompt (prompt mở đầu) cho session mới.

Blueprint — Session 2 (Edge case hết hàng, sequential):

Goal: Implement xử lý edge case "hết hàng giữa lúc thanh toán" cho tính
năng checkout.

Scope boundary: CHỈ tập trung vào luồng hết hàng và mở rộng OrderStateMachine
liên quan đến nó. KHÔNG viết adapter thanh toán mới, KHÔNG viết tài liệu
cho PM trong session này — các việc đó thuộc session khác.

Opening prompt:
"Đây là checkpoint từ session trước về tính năng checkout:
[dán checkpoint Session 1 vào đây]

Trong session này, chúng ta chỉ giải quyết Blocker thứ hai: đội kho hàng
có API 'giữ hàng tạm' hay không, và dựa vào câu trả lời, implement luồng
xử lý khi sản phẩm hết hàng giữa lúc khách đang thanh toán. Trước khi
code, hãy đề xuất 2 phương án xử lý (một dựa trên reserve API nếu có,
một dự phòng nếu không có) và giải thích trade-off, tôi sẽ chọn hướng
trước khi mình bắt đầu implement."

Blueprint — Session 3a (Adapter thanh toán + unit test, parallel):

Goal: Implement PaymentGateway adapter cho ví điện tử và COD, viết unit
test cho các adapter và cho CheckoutService.createOrder() happy path.

Scope boundary: KHÔNG động vào OrderStateMachine liên quan đến edge case
hết hàng (việc đó thuộc Session 2, đang chạy song song). Nếu cần biết
interface PaymentGateway, dùng đúng interface đã chốt trong checkpoint,
không tự thay đổi signature.

Opening prompt:
"Đây là checkpoint từ session trước về tính năng checkout:
[dán checkpoint Session 1 vào đây]

Interface PaymentGateway đã có adapter thẻ tín dụng hoàn chỉnh làm mẫu.
Hãy implement adapter cho ví điện tử (giả định gọi qua REST API của nhà
cung cấp ví) và cho COD (không cần gọi API ngoài, chỉ cần xác nhận đơn
hàng ở trạng thái 'chờ thu tiền khi giao'). Sau đó viết unit test cho
cả hai adapter và cho CheckoutService.createOrder() ở luồng happy path.
Không cần xử lý edge case hết hàng — phần đó đang được làm ở một
session khác."

Blueprint — Session 3b (Tài liệu cho PM, parallel):

Goal: Viết tài liệu mô tả tính năng checkout cho stakeholder, dựa trên
các quyết định nghiệp vụ đã chốt.

Scope boundary: Chỉ mô tả ở mức khái niệm nghiệp vụ (phương thức thanh
toán hỗ trợ, cách xử lý lỗi ở mức người dùng nhìn thấy, mã giảm giá hoạt
động ra sao). KHÔNG cần chi tiết kỹ thuật implementation, KHÔNG cần chờ
kết quả từ Session 2 hoặc 3a.

Opening prompt:
"Đây là checkpoint từ session trước về tính năng checkout:
[dán checkpoint Session 1 vào đây]

Hãy viết tài liệu 1 trang cho stakeholder không rành kỹ thuật, mô tả:
tính năng checkout hỗ trợ phương thức thanh toán nào, cách áp mã giảm
giá, và cách hệ thống xử lý khi có lỗi (thẻ bị từ chối, timeout cổng
thanh toán) ở mức người dùng cuối nhìn thấy — không cần mô tả code hay
kiến trúc nội bộ."

Mẹo:
- Khi một phần việc còn Blocker chưa trả lời (như câu hỏi về API giữ hàng), luôn đưa nó vào session sequential đầu tiên — đừng để nó trôi sang session parallel vì các session song song thường không có cơ chế "hỏi và chờ trả lời" hiệu quả.
- Luôn dành riêng một session synthesis ở cuối, đừng giả định các session song song sẽ tự động khớp với nhau.

Step 4: So Sánh Chi Phí Token

Hãy ước tính (mang tính minh họa, dựa trên độ lớn context điển hình) chi phí của hai phương án cho phần việc còn lại sau checkpoint Session 1: tiếp tục đúng thread cũ (đã ở khoảng 45.000–50.000 token tích lũy) so với chuyển sang bốn session mới bắt đầu từ checkpoint.

Phương án A — Tiếp tục thread cũ (không tái cấu trúc):
Mỗi turn tiếp theo trong thread cũ phải "mang theo" toàn bộ lịch sử 50 turn (bao gồm code Redis đã bỏ, các đoạn giải thích lặp lại, câu hỏi không liên quan của QA). Giả sử còn cần khoảng 20 turn nữa để hoàn thành edge case, adapter, test, và docs, với context nền đã ở ~48.000 token và mỗi turn cộng thêm trung bình 800–1.200 token cả input lẫn output: tổng chi phí ước tính rơi vào khoảng 48.000 (nền, lặp lại ở mọi turn do không có caching hiệu quả với nội dung không liên quan) + 20 × 1.000 ≈ 68.000 token, kèm rủi ro cao agent tiếp tục đề xuất lại giải pháp Redis đã bị loại (như đã thấy ở turn 31–38), buộc phải sửa lại — tốn thêm turn ngoài dự tính.

Phương án B — Bốn session mới, mở đầu bằng checkpoint (~600–900 token mỗi lần):
- Session 2 (sequential): checkpoint (~800 token) + khoảng 8 turn thảo luận/implement edge case (~1.000 token/turn) ≈ 8.800 token.
- Session 3a (parallel): checkpoint (~800 token) + khoảng 6 turn cho adapter + unit test ≈ 6.800 token.
- Session 3b (parallel): checkpoint (~800 token, có thể rút gọn hơn vì PM không cần phần Artifact State chi tiết kỹ thuật) + khoảng 3 turn viết tài liệu ≈ 3.800 token.
- Session 4 (synthesis): checkpoint tổng hợp từ ba session trên (~1.200 token, vì phải gộp kết quả) + khoảng 5 turn để viết integration test và rà soát ≈ 7.200 token.

Tổng Phương án B ≈ 8.800 + 6.800 + 3.800 + 7.200 ≈ 26.600 token.

Tiết kiệm ước tính: khoảng 60% token (từ ~68.000 xuống ~26.600) cho cùng một lượng công việc hoàn thành. Ngoài chi phí token, chất lượng đầu ra cũng cải thiện rõ vì mỗi session giữ context sạch, tập trung — giảm gần như triệt để rủi ro agent đề xuất lại giải pháp đã bị loại (như đã xảy ra ở Phương án A), qua đó giảm số turn "sửa lại vì agent quên quyết định cũ" — một loại lãng phí khó lượng hóa bằng token nhưng ảnh hưởng trực tiếp đến thời gian của cả nhóm.

Mẹo:
- Khi ước tính chi phí, đừng chỉ tính token của Phương án A hiện tại — hãy cộng thêm "chi phí sửa lỗi do drift" (agent quên quyết định, đề xuất lại giải pháp cũ) vì đây thường là phần bị đánh giá thấp nhất.
- Nếu công cụ của bạn hỗ trợ prompt caching, checkpoint ngắn ở đầu mỗi session mới còn giúp tận dụng cache tốt hơn nhiều so với một context 48.000 token đã lẫn nhiều nội dung không liên quan.

Step 5: Áp Dụng Vào Công Việc Của Bạn — Bài Tập Tái Cấu Trúc

Giờ đến lượt bạn. Chọn một conversation thật của mình (hoặc của team) và chạy đúng năm bước dưới đây. Đừng chỉ đọc — hãy thực sự mở conversation đó ra và làm.

Step 1: Chọn một session mục tiêu

Ứng viên tốt là những session: dài trên 25–30 turn, đã trải qua ít nhất một lần đổi hướng lớn (đổi kiến trúc, đổi phạm vi), hoặc bạn cảm nhận rõ agent "phản hồi chậm hơn, ít chính xác hơn" so với lúc mới bắt đầu. Nếu bạn có nhiều session đang mở, hãy ưu tiên session mà bạn còn phải làm tiếp việc quan trọng trong đó — bài tập này có giá trị thực tế nhất khi bạn thật sự cần tiếp tục công việc đó.

Step 2: Audit session

Chia session thành các cụm turn (giống bảng ở Step 1), gắn nhãn loại drift (scope creep, repair, elaboration, tool-result) cho mỗi cụm. Câu hỏi tự vấn: có bao nhiêu điểm topic-shift đã xảy ra mà không có checkpoint/reset? Có đoạn code hoặc quyết định nào đã "chết" (bị thay bằng quyết định khác) nhưng nội dung cũ vẫn còn nằm trong context không?

Step 3: Trích checkpoint

Áp dụng đúng 5 thành phần: Goal & Status, Key Decisions, Artifact State, Blockers, Next Actions. Tự kiểm tra bằng câu hỏi ở Step 2 phía trên (topic 04): nếu đưa checkpoint này cho một đồng nghiệp chưa từng thấy conversation, họ có đủ thông tin để tiếp tục mà không hỏi lại bạn không?

Step 4: Thiết kế cấu trúc tối ưu

Liệt kê các phần việc còn lại từ Next Actions trong checkpoint. Với mỗi cặp phần việc, tự hỏi: "làm phần A có cần biết kết quả của phần B không?" Nếu có — sequential. Nếu không — ứng viên cho parallel. Đừng quên: nếu có bất kỳ Blocker chưa trả lời nào, phần việc phụ thuộc vào Blocker đó luôn phải là sequential và đi trước.

Step 5: Viết 2–3 blueprint session

Với mỗi session đề xuất, viết đủ ba phần: Goal (một câu), Scope boundary (nêu rõ cái gì KHÔNG thuộc session này), và Opening prompt đầy đủ (bắt đầu bằng việc dán checkpoint, sau đó nêu yêu cầu cụ thể). Nếu bạn không thể viết một opening prompt cụ thể cho một session — có thể phạm vi của nó vẫn còn quá mơ hồ, quay lại Step 4.

Mẹo:
- Làm bài tập này với một session bạn sắp phải quay lại trong vài ngày tới — bạn sẽ thấy giá trị ngay lập tức khi mở session mới bằng checkpoint và blueprint vừa viết.
- Nếu đây là lần đầu, hãy làm cùng một đồng nghiệp — một người audit, một người phản biện xem checkpoint có thiếu gì không. Việc này giúp phát hiện lỗi "biết ngầm nhưng quên ghi ra" rất nhanh.

Các Lỗi Thường Gặp Khi Tái Cấu Trúc Và Cách Sửa

Lỗi 1: Checkpoint quá muộn. Nhiều người chỉ nghĩ đến việc trích checkpoint khi session đã cực kỳ chậm và khó dùng (giống turn 45–50 trong case study) — lúc đó, chính việc đọc lại và trích checkpoint cũng phải "lội" qua rất nhiều nhiễu, tốn thời gian và dễ sót quyết định quan trọng. Cách sửa: đặt checkpoint tại đúng các điểm topic-shift (như turn ~11 và ~26 trong case study), không chờ đến khi session "cạn hơi".

Lỗi 2: Tách song song những phần thực ra phụ thuộc nhau. Một lỗi rất phổ biến ở người mới làm bài tập này là tách Session 3a và 3b ngay cả khi chúng chia sẻ một quyết định thiết kế chưa chốt — kết quả là hai session đưa ra hai giải pháp không tương thích, và Session synthesis phải làm lại từ đầu một phần. Cách sửa: trước khi tách parallel, tự hỏi "cả hai session này có cùng dựa vào một quyết định/API/interface chưa chốt không?" Nếu có, hãy chốt quyết định đó ở một session sequential ngắn trước, rồi mới tách song song.

Lỗi 3: Blueprint quá mơ hồ để dùng được. Viết "Session 2: xử lý edge case" rồi dừng lại không phải là một blueprint — đó chỉ là một cái tên. Một blueprint mơ hồ khiến session mới lại rơi vào đúng vết cũ: agent tự suy diễn phạm vi, rồi lại trôi dạt (drift) sang việc khác. Cách sửa: luôn viết đủ ba phần Goal/Scope boundary/Opening prompt với opening prompt đủ chi tiết để dán và dùng ngay, như các ví dụ ở Step 3.

Lỗi 4: Quên session synthesis. Sau khi chia việc thành các session song song, nhiều người coi các kết quả riêng lẻ là "xong việc" mà không dành một session để gộp và kiểm tra tính nhất quán — dẫn đến tình trạng adapter thanh toán mới (Session 3a) không khớp với tài liệu PM (Session 3b) mô tả, hoặc code chưa được test tích hợp với phần edge case từ Session 2. Cách sửa: luôn coi session synthesis là một bước bắt buộc, không phải tùy chọn, đặc biệt khi có từ hai session parallel trở lên.

Lỗi 5: Giữ quá nhiều "cho chắc" trong checkpoint. Vì sợ mất thông tin, một số người copy gần như toàn bộ đoạn hội thoại quan trọng vào checkpoint thay vì cô đọng lại thành quyết định. Kết quả là checkpoint dài 3.000–4.000 token, gần bằng chi phí lẽ ra phải tiết kiệm được. Cách sửa: checkpoint chỉ nên chứa kết luận và trạng thái, không chứa quá trình — nếu một đoạn giải thích dài ba lần nhưng kết luận chỉ nằm trong một câu, chỉ giữ câu đó.

Mẹo:
- Sau vài lần tái cấu trúc, hãy giữ lại các blueprint đã dùng thành công như mẫu (template) cho lần sau — phần lớn cấu trúc Goal/Scope boundary/Opening prompt có thể tái sử dụng cho các feature tương tự.
- Nếu team bạn thường lặp lại cùng loại bloated session (ví dụ luôn là feature end-to-end nhồi vào một thread), hãy chuẩn hóa checkpoint template theo vai trò (kỹ sư/QA/PM) ngay từ đầu dự án, thay vì chờ đến khi cần "cứu" một session.