# Bốn prompt để chống thói xu nịnh trong Claude Code
> Sự thật, tiền lệ, kế hoạch và bước tự kiểm tra: chu trình bốn bước trong Plan Mode dành cho các tác vụ phức tạp và lỗi chưa rõ nguyên nhân.
Source: https://ailoot.ai/blog/vi/claude-code-sycophancy-prompts/
Canonical: https://ailoot.ai/blog/vi/claude-code-sycophancy-prompts/
Language: vi
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-123
Revision: sha256-66137723d24ce4cb5f3386eb3c6f6d66d28283546cc6c66c8f81ffb53e32abd1
Điểm chính
Theo mặc định, Claude Code được thiết lập để đồng ý. Điều đó thuận tiện khi trò chuyện nhưng nguy hiểm khi viết mã: mô hình nhanh chóng tạo ra một giải pháp có vẻ hợp lý, khiến mô-đun xác thực bị trải rộng trên 14 tệp. Chu trình prompt 4 bước trong Plan Mode ngăn phản xạ này: trước tiên, chu trình yêu cầu mô hình xác lập sự thật, sau đó tìm tiền lệ, viết kế hoạch kèm rủi ro, rồi cuối cùng tự kiểm tra kế hoạch.
[Tài liệu Ailoot](https://ailoot.ai/docs/) mô tả cách kết nối các mô hình và làm việc với API.
## Thói xu nịnh của AI trong Claude Code là gì?
Điểm chính
Thói xu nịnh của AI không phải lỗi, mà là đặc điểm kiến trúc của Claude và các mô hình ngôn ngữ lớn khác. Trong một phân tích một triệu cuộc trò chuyện với Claude, Anthropic phát hiện rằng trong các cuộc trò chuyện về quan hệ, mô hình chiều theo người dùng một phần tư thời gian; còn trong các chủ đề tâm linh, là một phần ba thời gian. Tỷ lệ này thấp hơn khi viết mã, nhưng cơ chế vẫn như nhau: mô hình muốn nhanh chóng đưa ra câu trả lời có vẻ hợp lý và cố làm vừa lòng người dùng.
Tâm lý học đã có một thuật ngữ cho hiện tượng này từ lâu: xu nịnh. Kẻ xu nịnh nói điều bạn muốn nghe chỉ để cuộc trò chuyện tiếp tục. Khi các mô hình ngôn ngữ lớn xuất hiện, thuật ngữ này được đưa vào nghiên cứu AI, và trong một phân tích chính thức, Anthropic công khai thừa nhận rằng mô hình thường xuyên đánh đổi độ chính xác để nhanh chóng đồng tình.
Trong lập trình, hiện tượng này diễn ra như sau. Bạn viết cho Claude Code: “Sửa lỗi này trong authMiddleware; magic links đã ngừng hoạt động.” Kẻ xu nịnh không hỏi để làm rõ. Nó không yêu cầu nhật ký. Nó không hỏi bạn đang dùng phiên bản thư viện nào. Nó lập tức đề xuất giải pháp vì được huấn luyện để nhanh chóng tỏ ra hữu ích. Giải pháp sẽ trông có vẻ đúng: có imports, xử lý lỗi, chú thích. Nhưng đó sẽ là giải pháp cho vấn đề của người khác, được bịa ra từ những mảnh ngữ cảnh mà Claude chắp nối.
Nguyên nhân không nằm ở Claude, mà ở cách diễn đạt yêu cầu. Khi bạn hỏi “Sửa thế nào?”, bạn đã mặc định rằng vấn đề có thể sửa được. Kẻ xu nịnh sẽ chấp nhận cách đóng khung đó và đưa ra một “cách sửa”, ngay cả khi vấn đề thực sự nằm ở kiến trúc, phiên bản thư viện, hoặc việc triệu chứng bạn mô tả chỉ là hậu quả của một lỗi gốc hoàn toàn khác.
Một phép thử đơn giản để nhận biết yêu cầu có xu nịnh hay không: nếu tôi không thể trả lời câu hỏi “Chính xác thì cái gì bị hỏng?” trong ba câu, tôi chưa sẵn sàng giải quyết vấn đề. Tôi cần chẩn đoán trước. Sau đó mới sửa. Chu trình 4 bước bắt đầu đúng ở chỗ đó.
## Một trường hợp thực tế: hoàn tác 8 commit trong một giờ
Điểm chính
Tôi nhờ Claude Code sửa lỗi xác thực bằng magic link. Mô hình hỏi ba câu để làm rõ, tạo kế hoạch bao gồm 14 tệp và tôi đã duyệt. Mười tám phút sau, magic link không hoạt động, refresh token bị lỗi và xuất hiện lỗi 500 ở phần thanh toán. Tôi hoàn tác 8 commit bằng `git reset --hard origin/main`. Vấn đề thực sự chỉ nằm ở một dòng.
Một trường hợp cụ thể vào tháng 4 năm 2026. Tôi đang làm việc với xác thực bằng magic link trong `src/lib/auth/`. Triệu chứng: token được xác thực nhưng session không được lưu. Người dùng nhấp vào liên kết trong email, truy cập trang web, rồi năm giây sau bị chuyển về /login.
Tôi mở Claude Code và nhập: “Session không được lưu sau khi dùng magic link; hãy xem trong src/lib/auth/ và sửa lỗi.” Claude hỏi ba câu để làm rõ rồi lập tức đưa ra kế hoạch. Nó nói: “Tôi sẽ cập nhật callback handler, viết lại JWT serializer, bổ sung thao tác lưu rõ ràng vào Redis và sửa race condition trong middleware.” Nghe có vẻ hợp lý. Tôi duyệt kế hoạch.
Mười tám phút sau, tôi có một diff trải trên 14 tệp. Magic link vẫn không hoạt động. Nhưng giờ refresh token cũng không hoạt động, đăng nhập bằng mật khẩu bị lỗi và có một lỗi 500 kỳ lạ ở tuyến thanh toán. Các bài kiểm thử thất bại. Tôi bắt đầu hoàn tác.
Tôi hoàn tác 8 commit bằng `git reset --hard origin/main`. Một giờ làm việc trôi xuống sông xuống biển. Nếu muốn biết cách hoàn tác đúng cách mà không làm mất thứ gì hữu ích, tôi đã trình bày riêng trong [hướng dẫn hoàn tác thay đổi trong Claude Code](https://ailoot.ai/blog/vi/claude-code-undo-changes/).
Tôi ngồi xuống điều tra cho đàng hoàng. Tôi mở `src/lib/auth/magic-link.ts:42`, tự đọc đoạn mã, mở nhật ký và kiểm tra Redis. Hai mươi phút sau, tôi tìm ra vấn đề. Chỉ là một dòng: header `set-cookie` thiếu thuộc tính `SameSite=lax`, khiến Safari từ chối cookie khi chuyển hướng từ tên miền email trở lại trang web. Không phải JWT, không phải Redis, cũng không phải middleware. Một dòng.
Khi tôi nhờ Claude sửa lỗi, nó chẳng hề xem nhật ký trình duyệt. Nó không có thông tin về Safari. Nó xây dựng giả thuyết theo mẫu “session không được lưu = lỗi serialization” vì đó là câu trả lời phổ biến nhất trong dữ liệu huấn luyện. Kẻ xu nịnh đưa ra một giải pháp có vẻ hợp lý về mặt thống kê nhưng chẳng liên quan gì đến nhiệm vụ của tôi.
Tôi ghi lại bài học thành một quy tắc: đừng bao giờ hỏi “Sửa thế nào?” Hãy luôn hỏi “Hãy xác lập sự thật.” Việc còn lại duy nhất là chính thức hóa quy tắc này thành một chu trình làm việc.
## Nguồn gốc của thói xu nịnh: Opus 4.8 khi ra mắt và tháng 5 năm 2026
Điểm chính
Thói xu nịnh là một kiểu hành vi đã được ghi nhận, đòi hỏi bạn điều chỉnh các prompt làm việc.
Trong tháng 4, Anthropic cũng xem xét riêng trong một báo cáo hậu kiểm kỹ thuật cách một lỗi bộ nhớ đệm trong Claude Code khiến mô hình “quên” lập luận của mình giữa các lượt.
Lỗi này nằm ở giao điểm giữa việc quản lý ngữ cảnh của Claude Code, API của Anthropic và extended thinking.
— Anthropic Engineering, https://www.anthropic.com/engineering/april-23-postmortem
Khi mô hình quên chuỗi lập luận của mình, nó dễ “đoán” câu trả lời theo một khuôn mẫu hơn — nói cách khác là càng trở nên xu nịnh.
Nên làm gì sau khi 4.8 ra mắt? Đừng chọn mô hình “dễ hơn”. Đừng quay lại 4.7. Hãy điều chỉnh prompt cho phù hợp với sự thật: mô hình có xu hướng đồng tình hơn, vì vậy hãy nhấn mạnh hơn việc “xác lập sự thật”. Nếu bạn vẫn chưa hiểu chính xác điều gì thay đổi bên trong Opus 4.8, tôi đã so sánh chi tiết trong [bài đánh giá Opus 4.8 trong Claude Code](https://ailoot.ai/blog/vi/opus-4-8-claude-code-features/).
## Khi nào cần 4 bước — và khi nào chỉ phí thời gian
Điểm chính
Chu trình 4 bước là biện pháp mạnh. Dành 15 phút để xác lập sự thật, tìm tiền lệ và kiểm tra công việc chỉ để sửa lỗi đánh máy trong README thì thật vô nghĩa. Chu trình này cần thiết khi cái giá của sai sót cao hơn 15 phút lập kế hoạch. Bài kiểm tra đơn giản dưới đây chia công việc thành ba cấp độ.
Một quy tắc đơn giản để phân loại công việc: trước khi bắt đầu, hãy tự hỏi liệu bạn có thể liệt kê 3–5 tệp chắc chắn bị ảnh hưởng và nói rõ mỗi tệp sẽ thay đổi như thế nào hay không.
| Câu trả lời | Nên làm gì |
|----|----|
| Có, tôi có thể liệt kê các tệp và thay đổi | Làm trực tiếp, không cần Plan Mode |
| Không, tôi chưa rõ các tệp nhưng biết cần thay đổi gì | Dùng Plan Mode mà không cần chu trình 4 bước |
| Tôi chưa rõ cả các tệp lẫn cách tiếp cận | Cần chu trình 4 bước |
| Triệu chứng chưa rõ và không thể tái hiện cục bộ | Dùng chu trình 4 bước cộng với bước 0 để tạo ví dụ tái hiện tối thiểu |
Ví dụ cụ thể. Sửa nội dung trong email chào mừng: làm trực tiếp. Thêm nút CTA mới vào trang web: dùng Plan Mode mà không cần chu trình. Di chuyển dự án từ MySQL sang Postgres: cần chu trình 4 bước. Lỗi 500 kỳ lạ trong môi trường production mà không thể tái hiện cục bộ: dùng chu trình 4 bước với thêm bước “0”: “Trước tiên, hãy tạo một ví dụ tái hiện tối thiểu.”
Một sai lầm thường gặp khi dùng chu trình này là áp dụng cho những việc vụn vặt. Điều đó làm giảm tốc độ và nhanh chóng khiến mọi người chán phương pháp này. Chu trình cần thiết khi cái giá của sai sót cao hơn 15 phút lập kế hoạch.
Trước khi áp dụng chu trình, hãy nhớ rằng cả bốn prompt hoạt động **trong một phiên Plan Mode duy nhất**. Nếu chưa từng dùng chế độ này, trước tiên hãy đọc [hướng dẫn Plan Mode trong Claude Code](https://ailoot.ai/blog/vi/claude-code-plan-mode/), rồi quay lại.
## Bước 1. Cấm đưa ra giải pháp — yêu cầu Claude xác lập sự thật
Điểm chính
Phản xạ đầu tiên của AI xu nịnh là “đây là giải pháp”. Bước 1 chặn phản xạ đó một cách rõ ràng. Prompt yêu cầu Claude điền vào bốn mục: tôi quan sát thấy gì, cách tái hiện, tôi biết gì và tôi chưa biết gì. Mục cuối có giá trị nhất: thay vì một diff vội vàng, tại đó sẽ hình thành danh sách câu hỏi dành cho bạn.
Đây là bước quan trọng nhất. Nó chặn phản xạ đầu tiên — “đây là giải pháp”. Prompt:
```
Tôi gặp tình huống sau: [triệu chứng].
Nhiệm vụ của bạn lúc này là xác lập sự thật. Nghiêm cấm
mọi giải pháp, ý tưởng hoặc lời khuyên. Chỉ ghi lại:
- điều tôi quan sát thấy (diễn đạt chính xác triệu chứng)
- các bước có thể tái hiện (một tình huống tối thiểu)
- dữ liệu hiện có (nhật ký, phiên bản, môi trường)
- dữ liệu còn thiếu (cần thu thập thêm những gì)
Điều kiện dừng tuyệt đối: không đề xuất giải pháp; chỉ
ghi lại chẩn đoán. Nếu muốn đề xuất điều gì,
hãy diễn đạt thành câu hỏi dành cho tôi.
```
Tác dụng của prompt này. Khi bị cấm đề xuất giải pháp một cách rõ ràng, Claude không thể đi đường tắt. Nó phải điền bốn mục: tôi thấy gì, cách tái hiện, tôi biết gì và tôi chưa biết gì. Mục cuối có giá trị nhất. Thường thì câu trả lời là: “Tôi không biết phiên bản thư viện, nội dung nhật ký hoặc triệu chứng có xảy ra trong production hay không.” Đó là đòn bẩy cho bước tiếp theo.
Điểm dễ mắc lỗi ở bước 1. Nếu mô tả triệu chứng quá mơ hồ (“xác thực không hoạt động”), Claude vẫn sẽ đoán mò. Cách khắc phục nằm ngay trong prompt: mô tả chính xác triệu chứng bằng một câu và đưa ra một tình huống tối thiểu gồm ba bước. Nếu không thể làm vậy, nghĩa là bạn vẫn chưa hiểu chính xác điều gì bị hỏng, và dù sao câu trả lời của Claude cũng sẽ vô ích.
## Bước 2. Tìm tiền lệ trên Internet thay vì ảo giác từ trí nhớ
Điểm chính
Phản xạ thứ hai của AI xu nịnh là “bịa ra giải pháp từ kiến thức chung”. Bước 2 đưa Claude ra thế giới thực để tìm những cách tiếp cận có thể xác minh. Cần ít nhất ba tiền lệ, mỗi tiền lệ có liên kết trực tiếp, ưu và nhược điểm. Nếu Claude viện dẫn “kiến thức của mình” mà không có liên kết, hãy bác bỏ ngay.
Bước này chặn phản xạ thứ hai: “bịa giải pháp từ trí nhớ”. Prompt:
```
Giờ đây, khi đã xác lập chẩn đoán, hãy tìm các tiền lệ
về cách giải quyết những vấn đề tương tự trên Internet.
Ít nhất 3 cách tiếp cận khác nhau. Với mỗi cách:
- liên kết đến nguồn sơ cấp (issue, bài viết, tài liệu)
- mô tả ngắn gọn cách tiếp cận
- ưu và nhược điểm trong tình huống của chúng ta
- các cạm bẫy đã biết
Không được dùng liên kết chỉ dựa trên kiến thức của bạn
mà không có xác nhận từ liên kết. Nếu không tìm được tiền lệ,
hãy nói rõ điều đó.
```
Tác dụng thực tế. Claude tìm kiếm trên Internet và mang về những cách tiếp cận có thể xác minh. Các liên kết đến GitHub issues và tài liệu sẽ xuất hiện. Nếu Claude không tìm được tiền lệ, đó là dấu hiệu nhiệm vụ này khác thường hoặc triệu chứng được diễn đạt chưa đúng. Hãy quay lại bước 1.
Điểm dễ thất bại. Claude có thể dẫn một liên kết không tồn tại. Đây là một dạng ảo giác, như “đây là issue số 4291 trong repository X”, trong khi issue 4291 thực ra nói về điều khác. Khắc phục bằng một quy tắc rõ ràng trong CLAUDE.md: “luôn mở liên kết bằng WebFetch trước khi trích dẫn”. Xem [hướng dẫn thiết lập CLAUDE.md đúng cách](https://ailoot.ai/blog/vi/claude-md-template/) để biết chi tiết.
## Bước 3. Viết kế hoạch chi tiết trong `plans/` và dự đoán rủi ro
Điểm chính
Prompt thứ ba biến tiền lệ tốt nhất thành một tài liệu cụ thể — tệp `plans/YYYY-MM-DD-fix-X.md`. Kế hoạch bao gồm các tệp và dòng cụ thể, bài kiểm thử, rủi ro trước hai đến ba bước và kế hoạch hoàn tác. Tệp này tồn tại lâu hơn cuộc trò chuyện: bạn có thể mở lại sau hai tuần và tái sử dụng cách tiếp cận sau ba tháng.
Giờ đây Plan Mode đang hoạt động đúng như dự định. Prompt:
```
Chọn phương án tốt nhất từ Bước 2 và viết kế hoạch chi tiết
vào tệp plans/YYYY-MM-DD-fix-[name].md:
- những tệp cụ thể nào chúng ta sẽ sửa (đường dẫn đầy đủ và số dòng)
- chúng ta sẽ thêm gì và xóa gì
- chúng ta sẽ viết bài kiểm thử nào và những bài hiện có nào phải vượt qua
- rủi ro trước hai đến ba bước (điều gì có thể gây lỗi cho người dùng)
- kế hoạch hoàn tác nếu có sự cố
Biến mỗi bước thành một ô đánh dấu [ ]. Tệp phải vừa trên một màn hình.
Nếu kế hoạch dài hơn 200 dòng, hãy chia thành các giai đoạn.
```
Kết quả. Kế hoạch trở thành một tài liệu cụ thể thay vì ghi chú tạm thời trong cuộc trò chuyện. Bạn có thể đọc lại sau hai tuần, giao cho một agent khác hoặc dùng làm điều kiện cho lệnh `/goal`. Tệp kế hoạch tồn tại lâu hơn cuộc trò chuyện trong Claude Code.
Phần quan trọng là các rủi ro trước hai đến ba bước. Điều này chặn thêm một kiểu xu nịnh: kế hoạch lạc quan không đề cập tác dụng phụ. Khi yêu cầu Claude nêu rõ rủi ro, nó tìm thấy những điều mà trong một kế hoạch bình thường nó có thể âm thầm bỏ qua.
## Bước 4. Tự kiểm tra kế hoạch — phát hiện các giả định do xu nịnh
Điểm chính
Bộ lọc cuối cùng. Claude đọc lại kế hoạch của mình và đánh dấu những chỗ bịa ra: thư viện không có trong package.json, biến bạn chưa từng chỉ định và các bước mô tả mơ hồ. Trong mẫu khoảng 50 chu trình của tác giả, có hai hoặc ba mục kế hoạch được sửa riêng ở Bước 4.
Bộ lọc cuối cùng. Prompt:
```
Bây giờ hãy bắt buộc tự kiểm tra. Thành thật đọc lại kế hoạch của bạn.
Có chỗ nào trong kế hoạch do bạn tự nghĩ ra và chưa được xác nhận bằng:
- mã nguồn bạn đã đọc;
- tài liệu bạn đã trích dẫn ở Bước 2;
- tiền lệ từ Bước 2?
Nếu có, hãy đánh dấu rõ ràng, sửa đổi hoặc xóa chúng.
Đồng thời kiểm tra:
- kế hoạch có nhắc đến thư viện chưa được cài đặt
trong package.json hay không;
- kế hoạch có nhắc đến biến môi trường tôi chưa chỉ định hay không;
- có bước nào được mô tả chung chung
thay vì cụ thể hay không.
```
Tác dụng của prompt này. Claude phải kiểm tra lại lập luận của mình. Trong mẫu khoảng 50 chu trình của tác giả, ít nhất hai hoặc ba mục kế hoạch được sửa riêng ở Bước 4. Đó là những chỗ kẻ xu nịnh tìm cách lọt qua ở Bước 3 và bị Bước 4 phát hiện.
Sau bốn bước, kế hoạch đã sẵn sàng để duyệt. Bạn có thể chuyển sang triển khai mà không phải lo nghĩ: “Nếu phải hoàn tác 8 commit thì sao?”
## Vì sao chính xác là 4 bước, không phải 2 hay 7?
Điểm chính
Chu trình này dựa trên phương pháp Explore-Plan-Implement-Commit chuẩn của Anthropic. Trong bốn giai đoạn của Anthropic, tôi mở rộng Plan thành bốn bước nhỏ để chống xu nịnh. Mỗi bước ngăn một nhóm lỗi riêng: bỏ qua bất kỳ bước nào thì bạn sẽ gặp một kiểu thất bại có thể dự đoán.
Sau đây là lý do, dựa theo phương pháp Anthropic dùng để hướng dẫn Claude trong tài liệu chính thức.
Nếu để Claude nhảy thẳng vào viết mã, bạn có thể nhận được giải pháp cho sai vấn đề. Hãy dùng Plan Mode để tách việc khám phá khỏi việc thực thi.
— Claude Code Docs, https://code.claude.com/docs/en/best-practices
Tài liệu khuyến nghị quy trình bốn giai đoạn: Explore, Plan, Implement, Commit.
Chu trình 4 bước của tôi là một phiên bản chuyên biệt hóa giai đoạn Plan để chống xu nịnh. Trong bốn giai đoạn của Anthropic, tôi mở rộng một giai đoạn thành bốn bước nhỏ: cấm đưa ra giải pháp, tìm tiền lệ, viết kế hoạch và tự kiểm tra. Sau đó, kế hoạch chi tiết này được chuyển sang các giai đoạn Implement và Commit.
Đây là những gì sẽ sai nếu bạn bỏ qua bất kỳ bước nào trong bốn bước:
| Bỏ qua | Kết quả |
|----|----|
| Bước 1 (sự thật) | Giải pháp cho vấn đề của người khác: Claude đoán triệu chứng theo khuôn mẫu và đi sai hướng |
| Bước 2 (tiền lệ) | Giải pháp bịa ra từ “kiến thức chung”: chạy được trong trường hợp tham chiếu nhưng thất bại trong thực tế |
| Bước 3 (kế hoạch) | Triển khai không phân tích rủi ro: bài kiểm thử thất bại, refresh token bị lỗi và người dùng báo cho bạn biết |
| Bước 4 (tự kiểm tra) | Kế hoạch có hai hoặc ba giả định vô căn cứ: một thư viện không tồn tại, một biến chưa được chỉ định |
Bảng cho thấy rõ: mỗi bước ngăn một nhóm lỗi riêng. Bạn cần cả bốn bước vì mỗi bước phát hiện một loại vấn đề khác nhau. Nếu nhiệm vụ có vẻ đủ nhỏ để chỉ cần hai bước, vậy thì nó thực sự nhỏ — và bạn không cần Plan Mode.
## `plans/`, lệnh `/goal` và các bước tiếp theo kết hợp với nhau ra sao
Điểm chính
Bốn bước không tồn tại riêng lẻ. Chúng vận hành trong một hệ thống gồm Plan Mode, thư mục `plans/` trong repository và lệnh `/goal`. Plan Mode cung cấp chế độ làm việc. Thư mục `plans/` giúp lưu giữ kế hoạch lâu dài. `/goal` cung cấp khả năng tự động hóa. Thiếu bất kỳ lớp nào trong ba lớp này, chu trình sẽ mất một nửa giá trị.
Chu trình này hoạt động trong một hệ thống có:
1. Bật Plan Mode (nhấn Shift+Tab hai lần trong Claude Code).
2. Thư mục `plans/` trong repository để lưu kế hoạch.
3. Tùy chọn dùng lệnh `/goal` để tự động triển khai các kế hoạch dài.
Cụ thể về thư mục `plans/`. Sau Bước 3, bạn có tệp `plans/2026-05-27-fix-magic-link.md` với các giai đoạn và ô đánh dấu. Đó là một tài liệu cụ thể. Mở lại sau một tuần và bạn sẽ nhớ vì sao mình chọn cách tiếp cận đó. Ba tháng sau, bạn gặp nhiệm vụ tương tự và tái sử dụng nó. Sáu tháng sau, bạn đưa nó cho đồng nghiệp xem và giúp họ tiết kiệm hai tuần làm quen. Thư mục `plans/` là một phần của khái niệm [“bộ não thứ hai” trong Claude Code](https://ailoot.ai/blog/vi/claude-code-second-brain/).
Cụ thể về `/goal`. Sau khi hoàn thành bốn bước và duyệt kế hoạch, hãy thoát Plan Mode rồi nhập:
```
/goal thực hiện tất cả các giai đoạn trong plans/2026-05-27-fix-magic-link.md,
tất cả bài kiểm thử trong test/auth đều vượt qua, hoặc dừng sau 30 lượt
```
Với phiên Claude Code cục bộ, giữ terminal chạy, máy thức và mạng sẵn sàng. Đừng gập laptop trừ khi đã thiết lập chế độ thức được hỗ trợ. Khi quay lại, lịch sử có thể báo hoàn thành, giới hạn lượt, chờ quyền hoặc lỗi. Goal không bảo đảm tiến độ khi host ngủ. Không có chu trình 4 bước, `/goal` đốt tokens vào những vòng lặp vô ích. Có chu trình 4 bước, `/goal` đưa kế hoạch hoàn chỉnh đến trạng thái bài kiểm thử vượt qua.
Nên làm gì từ đây. Nếu mới bắt đầu với Claude Code, hãy thử chu trình này với nhiệm vụ tiếp theo không hề đơn giản. Không phải lỗi đánh máy. Hãy chọn việc đụng đến 3+ tệp hoặc có hành vi mà bạn chưa hiểu rõ. Sao chép các prompt ở trên và điền chi tiết của riêng bạn. Bạn sẽ nhận ra tỷ lệ phải hoàn tác thay đổi thay đổi ra sao.
Nếu đã dùng Plan Mode, hãy thêm thư mục `plans/` vào repository. Tự thống nhất định dạng tên tệp: `YYYY-MM-DD-feature-name.md`. Sau một tháng bạn sẽ có 20–30 tệp; sau sáu tháng sẽ có hơn một trăm. Đó là cách xây dựng bộ não thứ hai của dự án — một lịch sử quyết định sống động. Nếu muốn tìm hiểu sâu hơn về quản lý ngữ cảnh trước khi viết prompt, tôi đã trình bày riêng về [context engineering trong Claude Code](https://ailoot.ai/blog/vi/context-engineering/).
Nếu đã có cả Plan Mode lẫn `plans/`, hãy thử `/goal` với một nhiệm vụ tự động. Chọn một việc mà bình thường bạn sẽ tự làm trong 30–40 phút. Chạy qua 4 bước, lưu kế hoạch, mở `/goal`, giữ terminal cục bộ và máy thức. Muốn làm khi máy này tắt, phải dùng đường thực thi remote hoặc cloud được cấu hình rõ và xác minh tác vụ đang chạy tại đó.
### Nguồn
- [Anthropic Engineering - Các phương pháp hay nhất cho Claude Code](https://code.claude.com/docs/en/best-practices)
- [Anthropic Engineering - Báo cáo hậu kiểm ngày 23 tháng 4 về các báo cáo chất lượng](https://www.anthropic.com/engineering/april-23-postmortem)
- [Anthropic Docs - Giảm ảo giác](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations)
- [Anthropic Docs - Chế độ quyền hạn (Plan Mode)](https://code.claude.com/docs/en/permission-modes)
- [Anthropic Docs - Lệnh /goal](https://code.claude.com/docs/en/goal)
Bạn có thể tiếp tục làm việc với AI trên [Ailoot](https://ailoot.ai/).
## Câu hỏi thường gặp
### /goal cục bộ có tiếp tục chạy khi gập laptop không?
Chỉ khi máy vẫn thức và tiến trình terminal tiếp tục; ngủ thông thường có thể ngừng việc cục bộ. Giữ máy và mạng sẵn sàng, hoặc xác minh đã thực sự khởi chạy trong môi trường từ xa hay đám mây riêng.
### Khi nào chu kỳ bốn lời nhắc đáng công thực hiện?
Dùng khi triệu chứng, tệp ảnh hưởng hoặc cách làm chưa rõ và sửa sai gây tốn kém. Bắt đầu từ triệu chứng tái hiện được và bằng chứng còn thiếu, tìm nguồn, lập kế hoạch rồi kiểm tra giả định; lỗi chính tả đơn giản thường không cần.
## Ailoot · Công ty và danh mục dự án của công ty
Ailoot dựa trên kinh nghiệm vận hành tích lũy, cơ sở khách hàng lớn, dịch vụ ổn định và việc kiểm soát KPI liên tục.
Công ty và danh mục dự án của công ty: hàng triệu khách hàng; doanh số hàng tỷ mỗi tháng.
Ailoot áp dụng kinh nghiệm vận hành này để cung cấp quyền truy cập API vào các tính năng AI trong sản phẩm của khách hàng, tác tử, ứng dụng và quy trình tự động hóa.