Effort trong Claude Code và Codex — Khi nào nên tăng, khi nào cần đổi cách giao việc?

AI sửa sai một lần, ta tăng effort. Sửa sai lần nữa, ta đẩy lên max. Chờ lâu hơn, dùng nhiều tài nguyên hơn, cuối cùng nhận về một lời giải thích rất kỹ cho thứ mình không cần.

Tình huống này đặt ra một câu hỏi: AI đang thiếu năng lực, thiếu thông tin, hay đang giải nhầm bài toán?

Trong Claude Code và Codex, chọn model — mô hình AI — và chọn effort — mức nỗ lực suy luận — là hai quyết định khác nhau. Nhưng nói “effort không làm AI thông minh hơn” cũng dễ khiến người đọc hiểu sai. Cùng một model, tăng effort có thể cải thiện khả năng giải bài, phát hiện lỗi và kiểm tra kết quả. Điều nó không làm là biến model đó thành một model khác.

Muốn dùng đúng, ta cần nhìn cả công việc được giao, chứ không chỉ nhìn thanh chọn low, high hay max.

1. Model là năng lực nền; effort là cách huy động năng lực ấy

Anthropic giải thích: trọng số của model đã được xác lập qua huấn luyện và không thay đổi chỉ vì ta gửi một câu lệnh. Đổi model là đổi hệ trọng số xử lý yêu cầu. Effort hướng model dành nhiều hay ít công sức cho lượt làm việc, gồm suy nghĩ, đọc tệp và kiểm tra. Tài liệu Anthropic.

Ví von một chuyên gia có năm phút với một người làm tổng quát có cả buổi chiều khá dễ hiểu. Tuy nhiên, đó là ví von, không phải bảng quy đổi thời gian hay cam kết rằng model này luôn thắng model kia.

Cũng cần sửa cách nói “model quyết định AI biết bao nhiêu”. Kiến thức trong trọng số tương đối cố định trong một lượt sử dụng, nhưng AI vẫn có thể đọc tài liệu mới trong ngữ cảnh rồi vận dụng chúng. Đưa đúng tài liệu vào không huấn luyện lại model; nó giúp model có thêm thông tin để xử lý công việc hiện tại.

OpenAI mô tả reasoning.effort là tham số hướng dẫn lượng suy luận. Mức thấp ưu tiên tốc độ và mức sử dụng token; mức cao dành thêm công sức cho vấn đề phức tạp. Token là đơn vị dữ liệu mà model xử lý. Các mức hỗ trợ phụ thuộc model, và model vẫn có thể điều chỉnh lượng suy luận theo độ khó. Reasoning models.

Vì vậy, effort không phải đồng hồ bấm giờ, không ấn định chính xác số tệp phải đọc, cũng không bảo đảm chạy một số lượng test nhất định.

2. Có bốn thứ cần tách riêng trước khi chỉnh effort

Một cách thực hành hữu ích là xem mỗi nhiệm vụ có bốn phần:

• Năng lực: model có đủ khả năng xử lý kiểu vấn đề này không?
• Ngữ cảnh: nó có đúng yêu cầu, tài liệu, dữ liệu và trạng thái dự án không?
• Mức nỗ lực: nó đã dành đủ công sức để phân tích và kiểm tra chưa?
• Điều kiện thực thi: nó có công cụ, môi trường chạy và quyền cần thiết không?

Đây là khung chẩn đoán, không phải công thức tính điểm chất lượng.

Ví dụ, AI được giao sửa lỗi đăng nhập nhưng không có log tái hiện lỗi. Tăng effort có thể khiến nó đọc thêm nhiều tệp, song vẫn phải đoán điều đã xảy ra. Nếu môi trường thiếu cơ sở dữ liệu thử nghiệm, đổi sang model đắt hơn cũng chưa làm bài kiểm tra tích hợp chạy được.

Một nhầm lẫn khác là coi effort cao như quyền tự chủ cao. Trong Codex, quyền truy cập và yêu cầu phê duyệt được quản lý bằng cơ chế riêng. Model muốn làm tiếp không đồng nghĩa hệ thống cho phép nó làm tiếp. Agent approvals & security.

Bởi vậy, khi một phiên tự động dừng chờ, hãy đọc lý do dừng: thiếu dữ kiện, yêu cầu người dùng quyết định, hết giới hạn, hay thiếu quyền thực thi. Mỗi loại cần một cách sửa khác nhau.

3. Bốn kiểu sai và thứ nên chỉnh trước

Chạy đúng kỹ thuật, nhưng sai điều mình muốn

Giả sử ta yêu cầu: “Làm báo cáo khách hàng tốt nhất tháng này.” AI có thể chọn khách mua nhiều nhất, trong khi người quản lý muốn khách có biên lợi nhuận cao nhất. Báo cáo tính đúng mà quyết định kinh doanh vẫn sai.

Việc cần làm đầu tiên là xác định “tốt nhất” bằng tiêu chí cụ thể, kèm ví dụ. Với phần còn mơ hồ có thể thay đổi kết quả, yêu cầu AI hỏi trước khi triển khai. Với những lựa chọn nhỏ không ảnh hưởng mục tiêu, cho phép nó tự quyết trong phạm vi đã giao.

Đừng dùng thêm công sức để bù cho một định nghĩa còn thiếu. Nhưng cũng không cần đặt luật tuyệt đối “đề mơ hồ thì không bao giờ tăng effort”: nếu nhiệm vụ chính là phân tích sự mơ hồ và đề xuất phương án, suy luận sâu hơn vẫn có thể hữu ích. Quan trọng là AI đang được giao làm rõ bài toán hay tự chọn đáp án thay mình.

Hiểu đúng, nhưng bỏ sót bước kiểm tra

AI sửa đúng hàm gây lỗi nhưng quên nơi khác đang gọi hàm đó. Hoặc nó làm xong giao diện mà chưa thử trạng thái dữ liệu rỗng.

Đây là lúc đáng thử tăng effort, đồng thời bổ sung một cách kiểm chứng cụ thể. Thay vì “kiểm tra kỹ”, hãy yêu cầu kiểm tra tác động đến các nơi sử dụng, chạy các test liên quan và báo phần chưa kiểm tra được.

Anthropic khuyến nghị cho agent một phép kiểm có thể thực hiện: test, lệnh build, dữ liệu mẫu hoặc ảnh đối chiếu. Nhờ tín hiệu đó, agent có cơ sở sửa tiếp thay vì chỉ nhận định rằng công việc trông có vẻ đã xong. Best practices for Claude Code.

Tăng effort giúp khai thác vòng kiểm chứng. Nó không thay thế việc xây vòng kiểm chứng.

Có dữ liệu, làm nhiều lần, nhưng cách giải vẫn sai

Chẳng hạn, AI cứ vá triệu chứng của lỗi đồng thời mà chưa hiểu cơ chế khóa; mỗi bản vá sửa một tình huống rồi làm hỏng tình huống khác.

Lúc này, thử một model có năng lực phù hợp hơn là hợp lý. Đồng thời, yêu cầu nó giải thích nguyên nhân, đối chiếu với một trường hợp tái hiện tối thiểu và chỉ ra bằng chứng bác bỏ cách giải cũ.

Tuy nhiên, “đã làm rất kỹ” là điều cần chứng minh bằng dấu vết công việc, không phải số đoạn văn trong câu trả lời. Một phiên chạy lâu có thể chỉ đang lặp lại giả định sai. Trước khi kết luận model đã chạm trần năng lực, cần loại trừ test sai, dữ liệu thiếu và môi trường lỗi.

Việc nhỏ mà lần nào cũng cần effort cao

Nếu chỉ đổi một trường trong biểu mẫu mà AI phải dò cả dự án, có thể vấn đề nằm ở cách tổ chức thông tin: không biết tệp nào chịu trách nhiệm, quy ước nằm rải rác, lệnh chạy đã cũ hoặc yêu cầu lẫn nhiều việc.

Hãy bổ sung hướng dẫn ngắn trong AGENTS.md với Codex, hoặc CLAUDE.md với Claude Code: vị trí thành phần chính, lệnh kiểm tra, quy ước cần giữ và ranh giới thao tác.

Đừng biến tệp hướng dẫn thành cuốn sách bắt AI đọc trước mọi thay đổi. OpenAI khuyên rà lại các chỉ dẫn cũ, tránh bắt model nạp cả loạt tài liệu cho một việc nhỏ; chỉ dẫn nên gắn với đúng tình huống. Rethinking skills and prompts.

4. Những con số về effort thực sự nói gì?

Trong bài của Thariq Shihipar ngày 25/9/2026, biểu đồ B ghi 370 lượt chạy cho mỗi mức của Fable 5.1:

• Low: 140 lượt đạt; max: 214 lượt đạt.
• Nhóm lỗi do test của model bỏ sót bug giảm từ 40 xuống 14.
• Nhóm chọn sai cách hiểu tăng từ 25 lên 47.

Phân loại lỗi do một model chấm và chỉ mang tính xấp xỉ. Đây không phải 370 bài toán độc lập, cũng không chứng minh effort cao luôn làm AI hiểu sai ý người dùng.

Ở bài html-js-filter, Fable 5.1 đạt 1/5 lần tại low và 5/5 tại xhigh. Mẫu nhỏ này minh họa lợi ích khi cần rà nhiều trường hợp biên; nó không bảo đảm mọi bộ lọc HTML do AI viết đều an toàn. Thí nghiệm gốc, biểu đồ B và mục về trường hợp biên.

Điều đáng học là cách đọc bằng chứng: luôn hỏi model nào, tác vụ nào, bao nhiêu lượt chạy, tiêu chí nào và trong điều kiện nào. Một kết quả tốt trên bài kiểm tra cụ thể không nên biến thành lời hứa cho mọi dự án.

5. High, max và ultra không phải một chiếc thang chung

Tên mức effort giống nhau không có nghĩa công sức, thời gian hoặc chất lượng tương đương giữa các model. Tài liệu Claude Code nói rõ thang effort được hiệu chỉnh theo từng model. Khi đổi model hoặc phiên bản, nên đo lại thay vì bê nguyên cấu hình cũ. Model configuration.

Với OpenAI, tài liệu hiện tại liệt kê GPT-6 Astra và GPT-6.1 Sol hỗ trợ từ low đến max. Hướng dẫn triển khai khuyến nghị chỉ dùng xhigh hoặc max khi đánh giá trên tác vụ đại diện cho thấy chất lượng tăng đủ để bù độ trễ và chi phí. API deployment checklist.

Riêng ultra cần hiểu thêm một tầng: tài liệu OpenAI mô tả chế độ này trong Codex qua sự tương đồng với điều phối nhiều agent con. Đây là cách tổ chức công việc, không đơn thuần là bắt một model suy nghĩ lâu hơn. Các nhánh độc lập có thể chạy song song rồi tổng hợp. Hướng dẫn GPT-5.6, mục Multi-agent.

Ví dụ, ba nhánh kiểm tra độc lập về tài liệu, tương thích và test có thể hữu ích. Nhưng nếu ba agent cùng sửa một tệp, kết quả của nhánh sau phụ thuộc hoàn toàn nhánh trước, hoặc nhiệm vụ chỉ là sửa một nhãn nút bấm, lợi ích song song không còn rõ. Ta còn phải trả công sức phối hợp và kiểm tra mâu thuẫn.

Đừng chọn mức cao nhất để khỏi phải suy nghĩ về cách giao việc.

6. Một quy trình dùng được ngay

Phần dưới là đề xuất thực hành để áp dụng các nguyên tắc trên, không phải cấu hình mặc định của hãng.

Bước một: viết điều kiện hoàn thành. Kết quả nào sẽ khiến mình chấp nhận công việc? Với báo cáo, đó có thể là đối soát được tổng số. Với phần mềm, đó là hành vi đúng và không phá những chức năng đang dùng.

Bước hai: đưa đúng đầu vào. Cung cấp tệp liên quan, phiên bản thư viện, log lỗi hoặc ví dụ mong muốn. Không cần nạp mọi thứ; cần chỉ rõ nguồn chuẩn và cách tìm phần còn thiếu.

Bước ba: bắt đầu từ mặc định của model. Việc nhỏ, dễ xem lại có thể thử mức thấp hơn. Việc nhiều ràng buộc hoặc khó phát hiện sai cần dành thêm công sức kiểm tra.

Bước bốn: đổi một yếu tố mỗi lần. Nếu cùng lúc đổi model, effort, đề bài và bộ test, ta có thể nhận kết quả tốt hơn mà không biết vì sao. Muốn xây quy trình dùng lâu dài, cần giữ các điều kiện so sánh đủ ổn định.

Bước năm: nghiệm thu bằng bằng chứng. Xem lệnh đã chạy, kết quả đối chiếu, thay đổi cụ thể và giới hạn còn lại. Câu “đã kiểm tra đầy đủ” tự nó chưa phải bằng chứng.

Có thể giao một việc như sau:

Sửa lỗi xuất báo cáo doanh thu bị tính trùng khi một đơn có nhiều dòng sản phẩm. Quy tắc: tổng doanh thu tính theo giá trị đơn sau chiết khấu; đơn hủy không được tính. Đọc phần truy vấn báo cáo và test hiện có. Trước khi sửa, tái hiện lỗi bằng dữ liệu tối thiểu. Sau khi sửa, kiểm tra đơn một dòng, nhiều dòng, đơn hủy và kỳ không có đơn. Không đổi quy tắc ghi nhận doanh thu. Nếu thiếu quy tắc nghiệp vụ ảnh hưởng kết quả, hỏi trước. Báo tệp đã sửa, kiểm tra đã chạy và phần còn thiếu.

Đây là ví dụ minh họa, không phải hướng dẫn thay thế quy định kế toán của một doanh nghiệp. Điểm quan trọng là cách giao việc đã có mục tiêu, nguồn cần đọc, trường hợp phải kiểm tra và ranh giới được quyết định.

Nếu test cần quyền truy cập dữ liệu thật, ta vẫn phải xử lý quyền đó riêng. Không dùng câu “cứ làm hết” để xóa đi mọi ranh giới.

7. Đo chi phí hoàn thành, không chỉ chi phí một lượt

Một cấu hình phản hồi nhanh nhưng cần con người sửa đi sửa lại có thể đắt hơn cấu hình chậm hơn mà hoàn thành ngay. Ngược lại, bật max cho mọi chỉnh sửa nhỏ có thể làm cả đội chờ mà không thêm giá trị.

Để chọn cho công việc của mình, có thể lấy một nhóm tác vụ quen thuộc: sửa lỗi nhỏ, thêm tính năng, phân tích dữ liệu và rà soát thay đổi. Với từng nhóm, ghi lại:

• Tỷ lệ đạt tiêu chí nghiệm thu.
• Thời gian từ giao việc đến kết quả được chấp nhận.
• Chi phí sử dụng hoặc lượng tài nguyên đã tiêu thụ.
• Thời gian con người phải đọc, sửa và hướng dẫn lại.
• Những lỗi nghiêm trọng mà quy trình chưa phát hiện được.

Nên chạy lặp với các bài quan trọng vì một lần thành công hoặc thất bại chưa đủ đại diện. Giữ cùng đầu vào và môi trường khi so sánh; dùng thêm trường hợp kiểm tra mà AI chưa thấy trước để tránh chỉ khớp ví dụ.

Bộ test do chính AI viết cũng có thể mang cùng hiểu nhầm với phần triển khai. Vì vậy, tiêu chí nghiệp vụ và những ví dụ nghiệm thu quan trọng cần được đối chiếu độc lập. Chạy nhiều test sai không tạo ra một kết quả đúng.

Chọn đúng thứ cần sửa

Khi AI trả kết quả chưa đạt, câu hỏi hữu ích hơn “có nên bật max không?” là:

Nó đang làm chưa đủ kỹ, hay mình đang để nó giải một bài toán chưa đủ rõ?

Sai mục tiêu thì sửa yêu cầu. Thiếu dữ liệu thì bổ sung ngữ cảnh. Thiếu kiểm chứng thì xây phép kiểm và cân nhắc tăng effort. Khi đã loại trừ những thiếu sót ấy mà cách giải vẫn không đạt, hãy thử model phù hợp hơn.

Effort cao là một khoản đầu tư vào công sức giải quyết vấn đề. Nó đáng tiền khi công sức thêm ấy tạo ra bằng chứng và kết quả tốt hơn.

Nguồn

Anthropic, OpenAI

• Claude Code effort level and model selection — phân biệt model, effort và ngữ cảnh.
• Using Claude Code: Spending your effort — thí nghiệm của Thariq Shihipar, 25/9/2026; biểu đồ B và bài html-js-filter.
• Claude Code: Model configuration — thang effort theo model; Best practices — kiểm chứng kết quả.
• OpenAI: Reasoning models; API deployment checklist — chọn effort và đánh giá chất lượng, độ trễ, chi phí.
• OpenAI: Using GPT-6, phần GPT-5.6 — multi-agent và ultra; Rethinking skills and prompts — ngữ cảnh và chỉ dẫn.
• Agent approvals & security — quyền thực thi và phê duyệt.

Tài liệu được tham khảo ngày 11/10/2026.