3.5 Iterative Refinement Techniques

Những gì cần nắm

Làm việc với Claude Code là chuyện lặp. Output đầu tiên hiếm khi là output cuối. Đề thi kiểm tra xem bạn có biết những kỹ thuật cụ thể để lái Claude Code tới kết quả đúng hay không — và trong từng tình huống thì nên với tay lấy kỹ thuật nào trước.

Thứ tự ưu tiên của các kỹ thuật

Không phải kỹ thuật nào cũng ngang nhau. Có một trật tự rõ ràng:

1. Ví dụ input/output cụ thể (hiệu quả nhất khi model hiểu không nhất quán)

Khi bạn mô tả một phép biến đổi code bằng văn xuôi và Claude Code hiểu mỗi lần một kiểu, cách sửa không phải là viết thêm văn xuôi. Cách sửa là ví dụ cụ thể.

Đưa 2–3 ví dụ cho thấy chính xác input và chính xác output mong muốn:

Input:
  getUserData(userId: string): Promise<UserData>

Expected output:
  getUserData(userId: string): Promise<Result<UserData, ApiError>>

Input:
  fetchOrders(customerId: string): Promise<Order[]>

Expected output:
  fetchOrders(customerId: string): Promise<Result<Order[], ApiError>>

Model tổng quát hoá từ những ví dụ này đáng tin hơn hẳn so với bất kỳ mô tả bằng văn xuôi nào. Hai hoặc ba ví dụ cụ thể là đủ để định hình pattern, và model áp nó cho các ca mới. Đây là kỹ thuật cần dùng đầu tiên khi cách hiểu không nhất quán.

2. Test-driven iteration (hiệu quả nhất với phép biến đổi phức tạp)

Viết test trước. Định nghĩa hành vi mong muốn qua các test case bao phủ:

Happy path (phép biến đổi chuẩn như mong đợi)
Edge case (giá trị null, input rỗng, điều kiện biên)
Yêu cầu hiệu năng (nếu có)

Rồi đưa các test failure cho Claude Code. Failure cho phản hồi cụ thể, không mơ hồ, về thứ cần sửa. Không còn chỗ cho việc suy diễn khi output test nói thẳng “Expected X, got Y”.

FAIL: testMigrationHandlesNullValues
  Expected: null preserved in output JSON
  Actual: null replaced with empty string ""

Thông báo failure này nói với Claude Code chính xác phải sửa gì. Không cần giải thích bằng văn xuôi.

3. Interview pattern (hiệu quả nhất trong lĩnh vực bạn không rành)

Khi bạn làm trong một lĩnh vực mình thiếu chuyên môn, hãy để Claude hỏi trước khi triển khai. Cách này lôi ra những điểm bạn sẽ bỏ sót.

Thay vì áp đặt một giải pháp:

“Build me a caching layer for the API”

Dùng interview pattern:

“I need a caching layer for the API. Before implementing, ask me questions about the requirements, edge cases, and constraints I should consider.”

Claude có thể hỏi về chiến lược cache invalidation, chính sách TTL, yêu cầu về tính nhất quán, và các failure mode — những thứ một chuyên gia biết phải xử lý còn bạn thì có thể bỏ qua.

Phản hồi gộp hay tuần tự

Cách bạn đưa phản hồi có ảnh hưởng. Quy tắc:

Gộp vào một message khi các sửa đổi có liên đới với nhau:

Nếu đổi pattern xử lý lỗi cũng kéo theo thay đổi format logging và cấu trúc response, hãy đưa cả ba phản hồi trong một message. Model cần thấy toàn bộ ràng buộc liên đới cùng lúc để cho ra một bản sửa mạch lạc.

Three changes needed (they interact with each other):
1. Error responses must include an error code field
2. Logging must include the error code in structured format
3. The client SDK type definitions must reflect the new error code field

Lặp tuần tự khi các vấn đề độc lập nhau:

Nếu vấn đề naming convention và vấn đề thụt lề không ảnh hưởng gì tới nhau, hãy sửa từng cái một. Gộp các vấn đề độc lập có thể làm model rối, không biết phản hồi nào áp cho phần code nào.

First iteration: "Fix the function naming — use camelCase throughout"
[Wait for result]
Second iteration: "Now update the indentation to use 2 spaces"

Giao tiếp bằng ví dụ trong thực tế

Khi mô tả bằng văn xuôi cho ra kết quả không nhất quán, việc chuyển sang ví dụ đi theo một trình tự rõ ràng:

Nhận ra sự không nhất quán: Bạn mô tả một phép biến đổi, Claude Code làm mỗi lần một kiểu.
Chuyển sang ví dụ: Đưa 2–3 cặp before/after cụ thể thể hiện đúng phép biến đổi.
Kiểm tra khả năng tổng quát hoá: Thử trên một ca mới để xác nhận model tổng quát đúng pattern.
Thêm ví dụ edge case nếu cần: Nếu model xử đúng ca chuẩn nhưng trượt edge case, hãy thêm ví dụ chỉ riêng cho việc xử edge case.

Không phải cứ chất thêm thật nhiều ví dụ. Hai hoặc ba ví dụ chọn khéo, phủ ca chuẩn và một edge case quan trọng, là đủ. Model tổng quát hoá pattern; bạn không cần đưa cho nó mọi trường hợp có thể xảy ra.

Kỹ thuật nào cho tình huống nào

Tình huống	Kỹ thuật
Mô tả bằng văn xuôi bị hiểu mỗi lần một kiểu	Ví dụ input/output cụ thể
Phép biến đổi phức tạp với nhiều edge case	Test-driven iteration
Làm trong lĩnh vực không rành	Interview pattern
Nhiều vấn đề ảnh hưởng lẫn nhau	Phản hồi gộp (một message)
Nhiều vấn đề độc lập nhau	Phản hồi tuần tự

Bẫy thi

Tình huống luyện tập

Một developer mô tả một phép biến đổi code bằng văn xuôi. Claude Code hiểu mỗi lần một kiểu, cho ra kết quả không nhất quán. Developer nên thử kỹ thuật nào trước?

A. Viết lại mô tả văn xuôi với ngôn ngữ chính xác hơn và thuật ngữ kỹ thuật rõ hơn
B. Viết một bộ test đầy đủ rồi lặp bằng cách đưa các test failure
C. Dùng interview pattern để Claude hỏi lại cho rõ trước khi triển khai
D. Đưa 2–3 ví dụ input/output cụ thể thể hiện chính xác trước và sau khi biến đổi

Đáp án & giải thích

Đúng: D

A — Văn xuôi chính xác hơn vẫn dựa vào việc model diễn giải ngôn ngữ tự nhiên. Nếu việc diễn giải vốn đã không nhất quán, thêm chữ để diễn giải không chạm được vào nguyên nhân gốc.
B — Test-driven iteration hiệu quả nhưng nặng hơn mức cần thiết cho bước đầu. Ví dụ cụ thể nhanh hơn và đánh thẳng vào sự không nhất quán trong cách hiểu. Để dành test-driven iteration cho phép biến đổi phức tạp với nhiều edge case.
C — Interview pattern lôi ra những điểm developer có thể bỏ sót trong lĩnh vực không rành. Ở đây developer biết chính xác phép biến đổi — vấn đề là model hiểu không nhất quán. Ví dụ, chứ không phải câu hỏi, mới là cách sửa.
D — Ví dụ cụ thể triệt tiêu hoàn toàn sự mơ hồ trong diễn giải. Model thấy chính xác input trông thế nào và output phải trông thế nào. Nó tổng quát hoá từ ví dụ đáng tin hơn từ mô tả. Đây là kỹ thuật tuyến đầu được tài liệu ghi nhận.

Nguồn

Claude Code Iterative Development Documentation — Anthropic
Claude Certified Architect Foundations Exam Guide — Task Statement 3.5 — Anthropic

Exam Simulator

Năm câu trắc nghiệm theo format đề thi về Iterative Refinement Techniques. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

A. Đưa 2–3 ví dụ input/output cụ thể thể hiện chính xác trước và sau khi biến đổi
B. Viết lại mô tả văn xuôi với ngôn ngữ chính xác hơn và thuật ngữ kỹ thuật rõ hơn
C. Dùng interview pattern để Claude hỏi lại cho rõ trước khi triển khai
D. Viết một bộ test đầy đủ rồi lặp bằng cách đưa các test failure

Đáp án & giải thích

Đúng: A

A đúng vì: Ví dụ cụ thể triệt tiêu hoàn toàn sự mơ hồ trong diễn giải. Model thấy chính xác input trông thế nào và output phải trông thế nào. Nó tổng quát hoá từ ví dụ đáng tin hơn từ mô tả. Đây là kỹ thuật tuyến đầu được tài liệu ghi nhận.
B sai vì: Văn xuôi chính xác hơn vẫn dựa vào việc model diễn giải ngôn ngữ tự nhiên. Nếu việc diễn giải vốn đã không nhất quán, thêm chữ để diễn giải không chạm được vào nguyên nhân gốc.
C sai vì: Interview pattern lôi ra những điểm developer có thể bỏ sót trong lĩnh vực không rành. Ở đây developer biết chính xác phép biến đổi — vấn đề là model hiểu không nhất quán. Ví dụ, chứ không phải câu hỏi, mới là cách sửa.
D sai vì: Test-driven iteration hiệu quả nhưng nặng hơn mức cần thiết cho bước đầu. Ví dụ cụ thể nhanh hơn và đánh thẳng vào sự không nhất quán trong cách hiểu.

Câu 2

Một developer đang xây caching layer cho một API nhưng ít kinh nghiệm với chiến lược cache invalidation. Họ muốn Claude Code giúp thiết kế giải pháp. Kỹ thuật nào phù hợp nhất?

A. Đưa ví dụ input/output cụ thể về hành vi cache mong muốn, phủ hit, miss, eviction và TTL expiry trong từng ca
B. Viết test trước rồi lặp theo các failure
C. Dùng interview pattern — để Claude hỏi về yêu cầu, edge case và ràng buộc trước khi triển khai
D. Mô tả hành vi caching mong muốn bằng văn xuôi thật chi tiết, viết ra mọi quy tắc và mọi edge case trước khi viết code

Đáp án & giải thích

Đúng: C

A sai vì: Developer chưa biết đủ về caching để đưa ra ví dụ input/output có ý nghĩa. Họ có thể bỏ sót những edge case quan trọng quanh việc invalidation.
B sai vì: Viết test đòi hiểu hành vi mong đợi. Trong lĩnh vực không rành, developer có thể không biết phải test cái gì (ví dụ cache stampede, chính sách TTL).
C đúng vì: Interview pattern được thiết kế cho lĩnh vực không rành. Claude hỏi về chiến lược cache invalidation, chính sách TTL, yêu cầu tính nhất quán, failure mode — những thứ chuyên gia biết còn developer có thể bỏ qua.
D sai vì: Trong lĩnh vực không rành, mô tả văn xuôi nhiều khả năng bỏ sót những điểm then chốt. Interview pattern lôi chúng ra trước khi bắt đầu triển khai.

Câu 3

Một buổi code review phát hiện ba vấn đề: (1) cấu trúc error response cần thêm field errorCode, (2) format logging phải chứa errorCode, và (3) một biến đặt tên snake_case thay vì camelCase. Developer nên đưa phản hồi này cho Claude Code như thế nào?

A. Cả ba vấn đề trong một message, vì chúng được tìm thấy cùng lúc
B. Vấn đề 1 và 2 chung một message vì chúng liên đới, rồi vấn đề 3 riêng
C. Cả ba trong ba message tuần tự để tránh làm model quá tải
D. Vấn đề 3 trước (đơn giản nhất), rồi vấn đề 1 và 2 chung

Đáp án & giải thích

Đúng: B

A sai vì: Gộp một vấn đề độc lập (naming convention) chung với các vấn đề liên đới (cấu trúc error + logging) có thể làm model rối, không biết phản hồi nào áp cho phần code nào.
B đúng vì: Vấn đề 1 và 2 liên đới — field errorCode trong response ảnh hưởng tới format logging. Chúng phải được nhìn cùng lúc để có bản sửa mạch lạc. Vấn đề 3 (naming) độc lập nên sửa riêng để tránh lẫn lộn.
C sai vì: Sửa vấn đề 1 và 2 tuần tự khiến model xử cấu trúc error response mà không biết format logging cũng phải đổi. Bản sửa thứ hai có thể phá hoặc chọi với bản đầu.
D sai vì: Thứ tự theo độ đơn giản không quan trọng. Quan trọng là các vấn đề có liên đới hay không. Vấn đề 1 và 2 phải gộp vì chúng dùng chung cấu trúc errorCode.

Câu 4

Một developer đưa hai ví dụ input/output cụ thể cho một phép biến đổi kiểu dữ liệu. Claude Code áp đúng pattern cho các ca chuẩn nhưng xử sai giá trị null. Developer nên làm gì tiếp theo?

A. Viết mô tả văn xuôi đầy đủ phủ mọi edge case kể cả null
B. Viết lại hai ví dụ gốc kèm thêm comment giải thích cách xử null
C. Chuyển sang interview pattern và nhờ Claude chỉ ra các edge case
D. Thêm ví dụ thứ ba chỉ riêng cho việc xử giá trị null trong phép biến đổi

Đáp án & giải thích

Đúng: D

A sai vì: Nếu ví dụ cụ thể đã chạy đúng cho ca chuẩn, quay sang văn xuôi cho edge case là mời lại đúng vấn đề diễn giải không nhất quán. Hãy bám vào ví dụ.
B sai vì: Hai ví dụ gốc đã thiết lập đúng pattern chuẩn. Thêm comment vào chúng không thể hiện được pattern xử null. Cần một ví dụ riêng.
C sai vì: Developer đã biết cách xử null đúng. Họ không cần Claude lôi ra các điểm cần cân nhắc — họ cần minh hoạ cách xử edge case đúng bằng một ví dụ.
D đúng vì: Khi model xử đúng ca chuẩn nhưng trượt một edge case, hãy thêm ví dụ minh hoạ riêng edge case đó. Model tổng quát hoá pattern từ ví dụ — một ví dụ xử null dạy nó pattern cho edge case.

Câu 5

Câu nào mô tả đúng mối quan hệ giữa interview pattern và ví dụ cụ thể?

A. Chúng là hai kỹ thuật thay thế được cho nhau, cho cùng một bài toán
B. Interview cho lĩnh vực chưa rành, ví dụ cho lĩnh vực đã rành
C. Luôn phải thử ví dụ cụ thể trước interview pattern
D. Interview pattern hiệu quả hơn nên phải là lựa chọn mặc định

Đáp án & giải thích

Đúng: B

A sai vì: Chúng giải hai bài toán khác nhau. Dùng ví dụ khi bạn thiếu chuyên môn lĩnh vực nghĩa là bạn có thể bỏ sót edge case. Dùng interview pattern khi vấn đề là diễn giải không nhất quán chỉ làm chậm việc sửa.
B đúng vì: Bài toán khác nhau cần kỹ thuật khác nhau. Lĩnh vực không rành với những điểm khuất = interview pattern. Phép biến đổi đã biết rõ mà model hiểu không nhất quán = ví dụ cụ thể.
C sai vì: Không có thứ tự cố định. Lựa chọn tuỳ tình huống: bạn biết rõ phép biến đổi (dùng ví dụ) hay đang ở địa hạt lạ (dùng interview pattern)?
D sai vì: Không kỹ thuật nào tốt hơn trong mọi trường hợp. Hiệu quả phụ thuộc vào việc vấn đề là diễn giải không nhất quán hay thiếu kiến thức lĩnh vực.