Cách quản lý nhiệm vụ lớn: ngữ cảnh và các giai đoạn có thể kiểm chứng

Một nhiệm vụ lớn thường bắt đầu bằng một yêu cầu nghe có vẻ hợp lý: "Tạo danh mục locale: danh sách, chức năng tìm kiếm, lọc theo quốc gia và giao diện chỉn chu." Một giờ sau, trước mặt bạn là trang có danh sách mới làm được một nửa, tìm kiếm không chạy trên mọi trường, giao diện đã đổi hai lần, còn cuộc trò chuyện thì dài đến mức khó phân biệt kết quả đã kiểm tra với lời hứa suông.

Một nguyên nhân có thể là nhiệm vụ chưa được chia thành các phần có kết quả rõ ràng. Chia như vậy không loại trừ khả năng có lỗi trong mã, nhưng sẽ dễ kiểm tra hơn khi đã biết điều gì cần hoạt động ở thời điểm này. Ta sẽ tìm hiểu cách chia công việc lớn thành các giai đoạn có thể kiểm chứng, nên cung cấp thông tin nào cho agent ở giai đoạn hiện tại và cần ghi lại những gì để ngày mai tiếp tục - trong cùng cuộc trò chuyện hoặc một cuộc trò chuyện mới - mà không phải nhớ lại từ đầu.

Danh mục cần đạt được đúng như vậy: có danh sách tìm kiếm được, mỗi hàng gồm mã locale, ngôn ngữ, quốc gia, tiền tệ và tên miền. Hãy ghi nhớ bản phác thảo này - khi thực hành, nó hữu ích như một mẫu giao diện chứ không chỉ là hình minh họa.

Nhiệm vụ lớn và cuộc trò chuyện dài

Nhiệm vụ dài có thể bị đình trệ trước cả khi phát sinh lỗi mã: quy trình mất đi cấu trúc. Ngữ cảnh ngày càng phình to, giả thuyết lẫn với quyết định đã chốt, còn việc tìm kiếm thì âm thầm kéo theo cả việc sửa giao diện. Cửa sổ ngữ cảnh có giới hạn, nhưng vấn đề lớn hơn là không còn rõ ta đang làm gì và phần nào đã xong.

TASK_SPEC ghi lại mục tiêu, phạm vi và cách kiểm tra toàn bộ nhiệm vụ. Sau đó, dựa trên đặc tả này, hãy chia công việc thành các giai đoạn có thể kiểm chứng - milestone. Mỗi giai đoạn có kết quả và phạm vi riêng, chẳng hạn thêm chức năng tìm kiếm mà vẫn giữ nguyên dữ liệu và giao diện. Nhờ đó, Claude tập trung vào đúng việc, còn bạn biết nhiệm vụ đang ở đâu.

Nếu nhiệm vụ chưa rõ, giai đoạn đầu có thể là khảo sát: đọc hai hoặc ba tệp quan trọng, nêu các phương án và rủi ro, rồi làm rõ mô tả nhiệm vụ cùng những giai đoạn tiếp theo.

Hãy kết thúc mỗi giai đoạn bằng các bước kiểm tra và một bản tóm tắt ngắn (summary): đã làm gì, kiểm tra bằng cách nào và tiếp theo là gì. Nếu dự án dùng Git, hãy lưu các thay đổi đã kiểm tra trong một commit nhỏ. Bản tóm tắt lưu lại quyết định, commit lưu phiên bản mã; kết hợp lại, chúng giúp xác nhận kết quả và tiếp tục sau khi tạm dừng.

Thế nào là một giai đoạn

Milestone, hay cột mốc, là điểm mà tại đó nhiệm vụ có một kết quả trung gian và ta có thể kiểm tra được. Từ đây, ta gọi phần công việc dẫn đến điểm đó là một giai đoạn.

Một giai đoạn có ba phần cần thiết:

• kết quả - điều gì sẽ bắt đầu hoạt động;
• phạm vi - lần này không đụng đến những gì;
• cách kiểm tra - bạn sẽ xem gì để xác nhận.

Sự khác biệt thể hiện rõ qua cách diễn đạt. "Làm phần tìm kiếm" không có điểm kết thúc: có thể làm mãi, và ai cũng có thể tự quyết định lúc nào là "xong". "Tìm được bản ghi theo mã locale, còn truy vấn trống trả về toàn bộ danh sách" thì có điểm kết thúc cụ thể, có thể nhìn thấy trong trình duyệt chỉ sau nửa phút.

Không có giới hạn chung về thời gian hay số lượng tệp. Nhưng quy mô vẫn quan trọng: nếu một giai đoạn gộp nhiều thay đổi độc lập và bạn không thể kiểm tra kết quả theo một lượt rõ ràng, hãy chia nhỏ nó. Mốc tham khảo là kết quả hữu ích gần nhất mà bạn có thể tạo ra và kiểm tra riêng.

Chia kết quả thành các phần hoạt động được

Hãy lấy ví dụ danh mục locale để thực hành. Các trường của mỗi bản ghi giống như trong bản phác thảo phía trên: mã locale, ngôn ngữ, quốc gia, tiền tệ và tên miền. Để đơn giản, mảng dữ liệu có sẵn nằm ngay trong app.js, được liên kết với index.html. Trang không tải dữ liệu bằng một yêu cầu riêng, nên bạn có thể mở trang trong trình duyệt mà không cần server. Đây là bộ dữ liệu:

[
  { "code": "en-US", "language": "English", "country": "United States", "currency": "USD", "tld": ".us" },
  { "code": "de-DE", "language": "German", "country": "Germany", "currency": "EUR", "tld": ".de" },
  { "code": "fr-CA", "language": "French", "country": "Canada", "currency": "CAD", "tld": ".ca" },
  { "code": "ja-JP", "language": "Japanese", "country": "Japan", "currency": "JPY", "tld": ".jp" }
]

Yêu cầu đầy đủ là: danh sách, chức năng tìm kiếm và lọc theo quốc gia. Ta không tách "giao diện chỉn chu" trong phần mở đầu thành một giai đoạn riêng: trang có giao diện cơ bản ngay khi tạo danh sách ở M1, còn mục "để sau" chỉ dành cho giao diện mới, tức là đổi chủ đề. Hãy chia yêu cầu thành ba giai đoạn.

Trước tiên cần có danh sách hoạt động được: trên đó, ta dễ kiểm tra việc lọc bản ghi. Có thể thêm chức năng tìm kiếm và bộ lọc theo thứ tự khác nhau; ở đây ta chọn tìm kiếm trước, rồi kiểm tra chúng hoạt động cùng nhau ở M3. Mũi tên giữa các giai đoạn cho biết kết quả trước đó đã được kiểm tra, còn M3 màu xanh lá là giai đoạn hoàn tất toàn bộ yêu cầu.

Ở đây, ta chia việc theo kết quả. Mỗi giai đoạn đều có bước đọc mã, chỉnh sửa và kiểm tra. Kế hoạch "làm toàn bộ HTML trước, rồi đến JS, cuối cùng mới kiểm tra tất cả" sẽ dời việc kiểm tra hành vi đến tận cuối. Hoàn tất markup cũng có thể là kết quả trung gian hữu ích, nhưng vẫn chưa cho thấy chức năng tìm kiếm có hoạt động hay không.

Hãy lưu ý rằng agent thường tự chọn cách lập kế hoạch theo từng lớp như vậy: trước tiên là toàn bộ markup, sau đó là toàn bộ logic. Những người thường làm việc với AI agent cũng kể về điều này, chẳng hạn Matt Pocock trong workshop chia sẻ quy trình của mình - kế hoạch kiểu này vẫn xuất hiện ngay cả khi ta yêu cầu rõ là chia theo kết quả. Vì vậy, khi xem các giai đoạn agent đề xuất, hãy kiểm tra một điều: sau mỗi giai đoạn, bạn có thể mở thứ gì đó và thấy nó hoạt động không?

Ba giai đoạn ở đây chỉ là ví dụ, không phải quy tắc. Có thể là hai, cũng có thể là sáu.

Cung cấp ngữ cảnh cho giai đoạn hiện tại

Khi đã chọn giai đoạn, agent cần thông tin dành riêng cho giai đoạn đó chứ không phải toàn bộ dự án. Yêu cầu cho M2 trong danh mục locale mẫu có thể viết như sau:

Ta sẽ thêm chức năng tìm kiếm trong danh sách locale.
Danh sách gồm bốn bản ghi đã hoạt động. Hãy giữ nguyên các trường và
giao diện, không thay đổi nội dung mảng ban đầu. Chỉ thêm các thành phần tìm kiếm.

Đọc @index.html và @app.js.

Cần có:
- ô tìm kiếm phía trên danh sách;
- tìm theo mã locale và tên ngôn ngữ;
- truy vấn de-DE và German tìm thấy bản ghi de-DE;
- truy vấn zzz không để lại hàng nào trong danh sách;
- truy vấn trống hiển thị toàn bộ danh sách.

Lần này chưa thêm bộ lọc theo quốc gia.
Nếu cần tệp khác, hãy nêu tên và đọc tệp đó.
Trước tiên, hãy nêu kết quả và phạm vi của giai đoạn; chưa sửa tệp.

Nếu phạm vi agent đề xuất phù hợp, ở tin nhắn tiếp theo hãy yêu cầu thực hiện M2 và liệt kê các bước kiểm tra trong trình duyệt. Đồng thời, yêu cầu phân biệt điều agent tự kiểm tra với phần bạn vẫn cần kiểm tra.

Đường dẫn trong ví dụ chỉ là giả định, các tệp của bạn có thể khác. Nếu cần một nguồn chưa được nêu trong yêu cầu, agent nên chỉ ra và đọc nguồn đó: đoán nội dung tệp từ tên của nó là ý tưởng tồi, không nên yêu cầu làm vậy.

Ở đây, giao diện là một dạng thông tin riêng và ta cần giữ nguyên nó trong giai đoạn này. Đôi khi ngược lại: giao diện là một phần của kết quả giai đoạn, chẳng hạn khi trang được tạo lần đầu. Không thể mô tả nó chỉ bằng lời - yêu cầu "làm cho đẹp" không có gì để kiểm chứng, nên agent tự quyết định. Khi đó, hãy gửi kèm mẫu: bản phác thảo, ảnh chụp màn hình hoặc một tệp nhỏ có màu sắc và tên lớp.

Cũng nên nhớ một điều: câu "lần này chưa thêm bộ lọc" là chỉ dẫn, không phải rào cản kỹ thuật. Nó định hướng công việc nhưng không chặn thao tác nào, vì vậy bạn vẫn cần tự xem kết quả.

Khi nào cần chia nhỏ giai đoạn

Trong lúc làm, các giai đoạn có thể dần phình to. Ban đầu là tìm kiếm, rồi giữa chừng lại nảy ra ý tưởng đổi cấu trúc dữ liệu, tiện thể cập nhật giao diện và thêm thanh điều hướng phía trên. Chuyện này khá quen thuộc.

Với mỗi yêu cầu bổ sung, hãy hỏi xem nó có cần thiết để đạt kết quả đã chọn không. Chủ đề màu mới và thanh điều hướng có thể để sau, nhưng ô tìm kiếm hiển thị rõ ràng thì cần có. Nếu bản ghi thiếu thông tin cần dùng để tìm kiếm, trước tiên hãy làm rõ phạm vi: có thể bổ sung dữ liệu trong giai đoạn hiện tại hoặc tách việc chuẩn bị dữ liệu thành một giai đoạn riêng có thể kiểm chứng. Không thể âm thầm hủy bỏ yêu cầu không thay đổi dữ liệu giữa chừng.

Yêu cầu làm rõ có thể ngắn gọn:

Lần này không thay đổi dữ liệu, giao diện hay thanh điều hướng,
hãy ghi chúng thành các mục riêng để làm sau.
Giữ lại chức năng tìm theo mã và ngôn ngữ: ô nhập, kết quả khớp và truy vấn trống.

Giai đoạn kết thúc khi đã có kết quả như thỏa thuận và hoàn tất việc kiểm tra. Nếu kiểm tra không đạt, trước tiên hãy xử lý giai đoạn hiện tại; chuyển sang giai đoạn tiếp theo chỉ làm tăng sự không chắc chắn.

Đôi khi một giai đoạn cứ loay hoay mãi: bạn chỉnh agent, agent làm lại nhưng kết quả vẫn không đúng. Những lần thử chưa thành công vẫn nằm trong cuộc trò chuyện, và lần thử kế tiếp đã phải dựa trên chúng. Tài liệu Claude Code đưa ra một mốc tham khảo đơn giản: nếu phải sửa cùng một việc hơn hai lần, hãy bắt đầu cuộc trò chuyện mới với yêu cầu có bổ sung mọi điều bạn đã tìm hiểu được. Ví dụ: "cách dùng một mảng riêng để tìm kiếm không phù hợp vì nó không khớp với dữ liệu gốc; hãy tìm trực tiếp trong mảng chính". Cách này thường hiệu quả hơn lần chỉnh sửa thứ ba liên tiếp. Nếu vẫn không giúp được, có lẽ giai đoạn quá lớn và nên chia nhỏ.

Lưu lại điểm tiếp tục

Nhánh bên trái quay lại bước chỉnh sửa cùng giai đoạn vì kết quả chưa được xác nhận. Nhánh bên phải dẫn đến việc ghi lại trạng thái rồi chuyển sang giai đoạn tiếp theo. Trong ghi chú, hãy lưu cả những bước kiểm tra đạt và những gì chưa được kiểm tra.

Đã kiểm tra kết quả thì hãy ghi lại trạng thái. Ghi chú không phải để báo cáo, mà để ngày mai hoặc trong cuộc trò chuyện khác, bạn không phải đào lại lịch sử từ hàng loạt tin nhắn.

Bạn có thể đặt tên tệp tùy ý hoặc dùng ghi chú công việc sẵn có. Hãy gọi nó là PROGRESS.md. Dưới đây là ví dụ mẫu sau khi kiểm tra M1; trong ghi chú của mình, chỉ ghi những việc bạn thực sự đã làm và quan sát được:

# Danh mục locale

## Đã làm
M1: trang hiển thị danh sách locale từ mảng trong app.js.

## Đã kiểm tra
Đã mở index.html trong trình duyệt: có 4 bản ghi, cả năm trường
ở mỗi hàng đều khớp với mảng ban đầu trong app.js.

## Chưa kiểm tra
Trang hiển thị gì khi bộ dữ liệu trống.
Kiểm tra này không nằm trong tiêu chí M1; hành vi với mảng trống hiện chưa rõ.

## Quyết định
Lưu dữ liệu dưới dạng mảng trong app.js, không tải dữ liệu riêng.
Giữ nguyên các bản ghi và giao diện khi thêm chức năng tìm kiếm.

## Đã loại bỏ
Tải dữ liệu từ tệp JSON riêng: không có server thì trình duyệt
không đọc được tệp đó, trong khi trang cần mở được như một tệp.

## Tệp
index.html, app.js

## Các giai đoạn còn lại
M2: tìm kiếm theo mã locale hoặc tên ngôn ngữ hoạt động.
Kiểm tra: de-DE và German tìm thấy bản ghi de-DE;
zzz không tìm thấy bản ghi nào; truy vấn trống trả về cả bốn.

M3: bộ lọc theo quốc gia hoạt động cùng chức năng tìm kiếm.
Kiểm tra: Canada + French chỉ còn fr-CA;
Canada + German trả về danh sách trống;
xóa cả hai điều kiện trả lại bốn bản ghi.

## Bước tiếp theo
Thực hiện M2. Chưa thêm bộ lọc theo quốc gia.

Phần quan trọng nhất ở đây là mục "Đã kiểm tra". Ghi "mọi thứ hoạt động" thì một tuần sau cũng chẳng nói lên điều gì, còn "đã mở trong trình duyệt, có 4 bản ghi, các trường đều khớp" thì có. Mục riêng cho phần chưa kiểm tra là cần thiết, vì ngày mai bạn có thể không còn nhớ sự khác biệt này.

Mục "Đã loại bỏ" dễ bị xem là thừa vì chỉ chứa những thứ không có trong dự án. Nhưng trong cuộc trò chuyện mới, agent không biết các lần thử trước và có thể đề xuất lại đúng phương án cũ. Một dòng giải thích lý do giúp tiết kiệm cả một vòng làm lại.

Bạn có thể nhờ agent viết ghi chú, nhưng hãy đối chiếu với các tệp hiện tại và kết quả kiểm tra. Agent có thể dựa vào lịch sử trò chuyện, nơi kế hoạch nằm cạnh những thao tác đã thực hiện. Với phần quan sát trong trình duyệt, hãy ghi rõ ai đã làm; đừng nói agent đã kiểm tra nếu nó chưa chạy bước đó.

Có hai giới hạn. Tiến độ tạm thời của nhiệm vụ không nên đưa vào CLAUDE.md - tệp đó chứa các quy tắc lâu dài của dự án chứ không phải việc bạn đang làm hôm nay. Ghi chú cũng không lưu phiên bản mã: nó ghi trạng thái, không phải bản sao các tệp.

Tiếp tục với thông tin cần thiết

Ranh giới giữa các giai đoạn là thời điểm thuận tiện để quyết định sẽ làm tiếp trong cuộc trò chuyện nào. Câu hỏi rất đơn giản: cuộc trò chuyện hiện tại giúp ích hay đang cản trở bước tiếp theo?

Nếu vẫn hữu ích, hãy tiếp tục trong đó, không cần làm gì đặc biệt. Không có quy tắc "xóa cuộc trò chuyện sau mỗi giai đoạn", cũng chẳng có ngưỡng phần trăm nào mà vượt qua thì phải bắt đầu lại.

Nếu chưa rõ lịch sử đã chiếm bao nhiêu dung lượng, hãy gọi /context và xem mức sử dụng cửa sổ ngữ cảnh. Đối chiếu con số đó với tiến độ công việc: bước tiếp theo còn cần những kết quả dài hay phần thảo luận nào? Lệnh này giúp ước lượng dung lượng, nhưng không quyết định thay bạn thông tin nào hữu ích.

Nếu cuộc trò chuyện tích tụ nhiều nội dung không liên quan và bạn quyết định bắt đầu cuộc trò chuyện mới, hãy lưu ghi chú trước. Lệnh /clear bắt đầu cuộc trò chuyện mới: lịch sử trước đó không được đưa vào ngữ cảnh làm việc mới, các tệp nguồn vẫn nằm trên đĩa và hướng dẫn của dự án vẫn được tải. Lệnh này không xóa vĩnh viễn cuộc trò chuyện cũ: bạn có thể quay lại cuộc trò chuyện đã lưu bằng /resume. Tuy nhiên, để tiếp tục trong phiên mới, tốt nhất là truyền đạt rõ các quyết định cần thiết.

Hai mũi tên gặp nhau trước khi tiếp tục công việc. Ghi chú lưu lại quyết định và kết quả kiểm tra, còn các tệp cho thấy mã hiện tại. Agent đọc cả hai nguồn rồi tóm tắt trạng thái; bạn đối chiếu câu trả lời trước khi giao M2.

Bắt đầu một cuộc trò chuyện mới cũng đơn giản:

Đọc @PROGRESS.md, @index.html và @app.js.
Hãy diễn đạt bằng lời của bạn phần nào đã hoàn thành và kiểm tra,
phần nào còn lại. Tạm thời đừng sửa tệp.

Hãy đọc kỹ câu trả lời. Nếu agent nói đã hoàn thành việc bạn chưa làm, hãy đối chiếu với ghi chú, các tệp và kết quả kiểm tra. Có thể do ghi chép chưa chính xác, mã đã lỗi thời hoặc agent mắc lỗi. Hãy xử lý điểm chưa khớp trước khi sửa tiếp: cuộc trò chuyện mới không tự sửa đặc tả sai và cũng không đảm bảo mọi thứ được hiểu đúng.

Thực hành toàn bộ ví dụ danh mục

Phần phân tích đến đây là xong, giờ hãy tự tay làm danh mục đó: từ thư mục trống đến M2 đã kiểm tra và có điểm để tiếp tục. Bốn bước theo đúng thứ tự của bài viết. Ở mỗi bước, trước hết hãy tự soạn prompt, sau đó xem ví dụ của chúng tôi như một ý kiến tham khảo: mục đích là tự quyết định agent cần thông tin nào chứ không phải sao chép nguyên văn.

Bước 1. Lập kế hoạch, chưa viết mã

Chưa có dự án, và điều đầu tiên bạn muốn làm có thể là yêu cầu "tạo danh mục đi". Khi đó, tệp sẽ xuất hiện trước cả khi ta quyết định cần làm gì. Bước này làm ngược lại: chỉ nhận kế hoạch, không tạo tệp nào. Trước khi nhập yêu cầu, hãy nghĩ đến bốn điều:

• làm thế nào để ngăn agent bắt đầu viết mã ngay;
• cung cấp thông tin gì thay cho các tệp chưa tồn tại;
• nêu những giới hạn kỹ thuật nào để tránh thêm công cụ không cần thiết;
• yêu cầu đầu ra nào khi hiện tại chưa cần tạo gì.

Ví dụ của chúng tôi:

Tôi muốn tạo một danh mục locale để thực hành: danh sách bản ghi,
chức năng tìm kiếm và lọc theo quốc gia. Hiện chưa có dự án.

Trang cần mở được trong trình duyệt như một tệp thông thường,
không cần server hay build: chỉ có index.html, styles.css và app.js.
Mỗi bản ghi có các trường: mã locale (en-US), ngôn ngữ,
quốc gia, tiền tệ và tên miền.

Trước tiên, hãy lập kế hoạch:
- nêu mục tiêu, phạm vi và cách kiểm tra toàn bộ nhiệm vụ;
- chia công việc thành ba giai đoạn;
- nêu kết quả của mỗi giai đoạn và điều tôi sẽ thấy khi kiểm tra;
- cho biết bạn cần tôi cung cấp thêm thông tin gì;
- liệt kê những tệp bạn sẽ tạo.

Tạm thời chưa tạo tệp.

Hãy đối chiếu các giai đoạn nhận được với bảng M1-M3 phía trên; thứ tự khác cũng không sao. Nếu agent chia việc thành "làm toàn bộ markup, rồi mới đến JS", hãy yêu cầu điều chỉnh sao cho sau mỗi giai đoạn, trang đều làm được một việc nào đó. Nếu giai đoạn chưa nêu hành vi có thể quan sát, hãy sửa yêu cầu ngay lúc này: trước khi có dòng mã đầu tiên, chỉ cần thêm một tin nhắn.

Bước 2. Chỉ làm M1 và dùng mẫu ngay

Phạm vi rất hẹp: trang hiển thị bốn bản ghi, chỉ vậy thôi. Chưa có tìm kiếm hay bộ lọc. Nhưng không thể để giao diện sang lần sau - đây là lần đầu tạo trang nên nó sẽ có một giao diện nào đó. Vì vậy, hãy gửi kèm mẫu: lưu mockup.html vào thư mục dự án, đây là markup tĩnh không có JavaScript, chỉ gồm màu sắc và tên lớp.

<style>
  body   { background:#0f172a; color:#e2e8f0; font-family:system-ui, sans-serif; padding:24px }
  .search{ width:100%; margin-bottom:12px; padding:10px 14px; border-radius:10px;
           background:#1e293b; color:#e2e8f0; border:1px solid #334155 }
  table  { width:100%; border-collapse:collapse }
  th, td { padding:10px 12px; text-align:left; border-bottom:1px solid #334155 }
  th     { color:#8b98b1; font-size:13px }
  .code  { font-family:ui-monospace, monospace; font-weight:700; color:#818cf8 }
</style>

<input class="search" placeholder="Search by code or language">
<table>
  <tr><th>Code</th><th>Language</th><th>Country</th><th>Currency</th><th>TLD</th></tr>
  <!-- bản ghi mẫu; app.js sẽ hiển thị các hàng thực tế -->
  <tr><td class="code">en-US</td><td>English</td><td>United States</td><td>USD</td><td>.us</td></tr>
</table>

Mẫu đã có ô tìm kiếm, nhưng ta chưa đưa nó lên trang ở M1: ô trống không làm gì cả thì khó kiểm tra. Kiểu của ô này nằm trong lớp .search, sẽ dùng ở M2.

Còn một chi tiết nữa: cần cung cấp dữ liệu rõ ràng cho agent. Nếu không, nó sẽ tự nghĩ ra một bộ dữ liệu và các bước kiểm tra trong bảng - bốn hàng, de-DE, Canada - sẽ không còn khớp. Giờ hãy nghĩ về prompt: cần nói gì để agent chỉ làm một giai đoạn, nên yêu cầu hiển thị gì trước khi sửa và bạn sẽ kiểm tra kết quả bằng cách nào?

Chỉ thực hiện M1: trang hiển thị danh sách locale
lấy từ mảng trong app.js. Lần này chưa có tìm kiếm hay bộ lọc,
đừng thêm ô tìm kiếm từ mẫu.

Dữ liệu là mảng gồm bốn bản ghi này, không thay đổi nội dung:
[chèn mảng từ bài viết]

Dùng giao diện từ @mockup.html: lấy màu sắc và tên lớp trong đó,
không tự nghĩ thêm.

Trước tiên, hãy cho tôi xem kế hoạch các tệp và nói bạn sẽ dừng ở đâu.
Chưa tạo tệp cho đến khi tôi xác nhận kế hoạch.
Sau khi chỉnh sửa, hãy nói tôi cần mở gì và đối chiếu với nội dung nào.

Dừng lại sau M1, không chuyển sang M2 nếu tôi chưa yêu cầu.

Kế hoạch phình to thì đừng xác nhận vội, hãy thu nhỏ giai đoạn để chỉ còn một kết quả có thể kiểm chứng. Kế hoạch ổn thì cho phép chỉnh sửa, sau đó mở trang và đối chiếu bốn hàng với mảng dữ liệu. Giao diện cơ bản đã được chốt từ đây: những thay đổi sau cần giữ nguyên nó, còn việc đổi chủ đề hoàn toàn để sang mục sau.

Bước 3. M2 và ghi chú trung thực

Prompt cho M2 đã được phân tích trong mục "Cung cấp ngữ cảnh cho giai đoạn hiện tại" - hãy quay lại đó và thay bằng đường dẫn của bạn. Trong ví dụ, ta đọc hai tệp; sau M1, dự án của bạn có ba tệp: ngoài index.html và app.js còn có styles.css, hãy nhắc đến cả tệp đó. Bổ sung thêm một câu: giao diện đã được xác định, giờ cần giữ nguyên chứ không phải tạo mới.

Giao diện đã được xác định ở M1 theo @mockup.html - hãy giữ nguyên,
định dạng ô tìm kiếm bằng lớp .search từ tệp đó.

Agent đã nêu đúng phạm vi thì cho phép sửa. Nếu nó động đến bộ lọc hoặc cấu trúc dữ liệu, hãy hỏi lại trước khi làm. Khi cả ba bước kiểm tra tìm kiếm đều đạt, hãy ghi lại trạng thái vào PROGRESS.md theo mẫu phía trên, nhưng lần này cập nhật sau M2 và liệt kê các tệp của bạn.

Hãy thử xem ghi chú của bạn có đủ chắc chắn không. Tưởng tượng mục "Đã kiểm tra" chỉ ghi "gần xong hết rồi, còn một chút". Một tuần sau, câu đó chẳng giúp ích gì. Hãy ghi đủ để tiếp tục: bạn đã mở gì và thấy gì, điều gì chưa được kiểm tra, bước tiếp theo là gì. Ví dụ: "M2: truy vấn de-DE và German tìm thấy de-DE, zzz không tìm thấy gì, truy vấn trống trả về bốn bản ghi", "chưa kiểm tra hành vi khi bộ dữ liệu trống", "bước tiếp theo - M3, lọc theo quốc gia".

Bước 4. Tiếp tục trong cuộc trò chuyện mới

Bước cuối không kiểm tra mã mà kiểm tra ghi chú. Hãy bắt đầu cuộc trò chuyện mới, yêu cầu tóm tắt trạng thái dựa trên PROGRESS.md và các tệp hiện tại - cả ba tệp, bao gồm styles.css - rồi so sánh phần tóm tắt với những gì bạn đã làm. Nếu agent nói một việc bạn chưa kiểm tra đã hoàn tất, có lẽ ghi chú quá chung chung; cần sửa ghi chú chứ không phải bắt đầu cuộc trò chuyện mới. Nhưng hãy đối chiếu cả các tệp: nguyên nhân cũng có thể nằm trong mã hoặc do chính agent mắc lỗi. Nếu mọi thứ khớp, bạn đã có M1 và M2 được kiểm tra cùng điểm bắt đầu cho M3.

Cách chuyển sang giai đoạn tiếp theo

Trình tự cuối cùng khá ngắn gọn:

1. chọn kết quả gần nhất có thể kiểm chứng;
2. cung cấp cho agent các nguồn cần thiết cho giai đoạn đó và nêu rõ phạm vi;
3. thực hiện giai đoạn hiện tại; ghi riêng các yêu cầu mới;
4. tiến hành bước kiểm tra đã thống nhất; trong ví dụ này, hãy kiểm tra hành vi của trang trong trình duyệt;
5. ghi lại trạng thái: đã làm, đã kiểm tra, chưa kiểm tra, đã bỏ việc gì và bước tiếp theo;
6. quyết định tiếp tục trong cuộc trò chuyện này hay bắt đầu cuộc trò chuyện mới.

Một giai đoạn không đồng nghĩa với một tin nhắn. Có thể cần ba tin, cũng có thể là mười lăm, chuyện đó bình thường. Số giai đoạn cũng không bằng số cuộc trò chuyện: vài giai đoạn liền nhau có thể dễ dàng nằm trong cùng một cuộc trò chuyện, còn một giai đoạn khó đôi khi chiếm đến hai cuộc trò chuyện.

Bù lại, ở bất kỳ bước nào, bạn cũng có thể trả lời điều gì đã hoạt động và đã kiểm tra bằng cách nào. Có lẽ đó là điều quan trọng nhất khi làm một nhiệm vụ lớn.