Claude Code từ zero đến thành thạo · Phần 23 — Làm việc với Opus 5.5

Phần lõi của series đã khép lại ở phần 22, nhưng có một thứ thay đổi nhanh hơn docs: model chạy bên dưới Claude Code. Mỗi thế hệ model mới đổi một ít cách bạn nên giao việc. Có thói quen trước đây giúp ích thì nay thành thừa, có thứ trước đây không làm được thì nay làm được.

Bài này dựa trên bài Getting the most out of Opus 5.5 của Addy Osmani (22/9/2026). Mình sắp lại nội dung theo góc nhìn của người dùng Claude Code và nối từng mẹo về phần tương ứng trong series, để bạn thấy nó chạm vào cơ chế nào.

Opus 5.5 khác các bản trước ở ba điểm: tự làm được task dài hơn mà không cần bạn đỡ từng bước, giải thích rõ hơn nó đã làm gì, và tự nghĩ trước mỗi câu trả lời. Gần như mọi mẹo dưới đây đều là hệ quả của ba điểm đó.

Ba việc làm ngay hôm nay

Nếu chỉ đọc một đoạn, hãy đọc đoạn này:

1. Giao trọn task và nói rõ thế nào là xong, rồi để nó chạy.
2. Xoá các câu kiểu “think carefully” khỏi prompt và khỏi CLAUDE.md. Model tự nghĩ rồi.
3. Khi một lượt chạy dài kết thúc, đọc trước phần nó cần bạn quyết, sau đó mới đọc phần còn lại.

Phần còn lại của bài giải thích vì sao và cách áp dụng.

---

1. Cách giao việc

Nói rõ “xong” trông như thế nào, rồi để nó chạy

Với model trước, bạn hay chia task thành từng mẩu nhỏ vì sợ nó lạc hướng giữa chừng. Opus 5.5 bám việc nhiều bước tốt hơn hẳn, nhất là kiểu việc sửa xuyên nhiều file trong repo lớn cho tới khi test pass. Chia nhỏ quá thì bạn lại thành cái nút thắt.

Cách làm là dồn toàn bộ task vào một tin nhắn kèm vạch đích kiểm được:

Chuyển các endpoint thanh toán từ client cũ sang client mới.
Xong nghĩa là: mọi endpoint đều dùng client mới, client cũ đã bị xoá,
và test suite pass. Chỉ dừng lại hỏi tôi nếu có test fail mà bạn
không giải thích được nguyên nhân.

Prompt trên có ba phần, và cả ba đều cần:

Phần	Trong ví dụ	Vì sao cần
Việc cần làm	Chuyển endpoint sang client mới	Phạm vi
Định nghĩa “xong”	Hết client cũ, test pass	Cho model một tín hiệu pass/fail để tự kiểm
Điều kiện được dừng	Chỉ hỏi khi test fail không rõ nguyên nhân	Không có dòng này thì model tự đoán lúc nào nên làm phiền

Đây chính là nguyên tắc số một ở phần 10: cho Claude một thứ nó tự kiểm chứng được. Model càng tự chủ lâu thì vạch đích càng quan trọng. Nếu muốn điều kiện đó được kiểm suốt phiên thay vì chỉ trong một prompt, dùng /goal hoặc Stop hook (phần 10, phần 13).

Đừng bảo nó “think hard” nữa

Opus 5.5 tự nghĩ trước mỗi câu trả lời. Theo bài gốc, cách này giúp trả lời nhanh hơn mà chất lượng không giảm. Vì vậy các câu như “think carefully” hay “think step by step” giờ chỉ là nhiễu. Hãy dọn chúng khỏi prompt, và quan trọng hơn là khỏi các chỉ dẫn đã lưu: CLAUDE.md, skill, output style, system prompt của subagent.

• Câu hỏi đơn giản mà muốn nhận câu trả lời ngay: viết “trả lời thẳng”.
• Muốn chỉnh độ sâu suy nghĩ trong Claude Code: dùng effort level (/effort, cờ --effort, hoặc field effort trong skill và subagent), đừng dùng câu chữ trong prompt. Bảng các mức và giá trị mặc định nằm ở phần 21.

Nhớ lưu ý về cache ở phần 3: mỗi effort level có cache riêng. Chọn effort ở đầu phiên, đừng đổi qua lại giữa một task.

Tìm nhanh các cụm từ cần dọn trong chỉ dẫn đã lưu:

rg -n -i "think (hard|carefully|step by step)" CLAUDE.md .claude/ ~/.claude/CLAUDE.md

Gửi thêm yêu cầu khi nó đang chạy

Lượt chạy dài hơn thì dừng lại làm lại từ đầu cũng đắt hơn. Nếu nhớ ra một yêu cầu phụ, cứ gõ vào trong lúc nó đang làm, ví dụ “giữ luôn tên endpoint cũ làm alias”. Claude Code xếp hàng tin nhắn đó và chuyển cho Claude ngay khi các tool call đang chạy xong, trong cùng lượt, không bỏ phần việc đã làm (phần 5, mục xếp hàng tin nhắn).

Việc thiết kế: liệt kê cụ thể style bạn không muốn

Mẹo này đi ngược trực giác. Nói chung chung kiểu “đừng làm trông generic” thường chỉ đổi một style mặc định sang một style mặc định khác. Cách hiệu quả hơn là gọi tên từng pattern cụ thể bạn muốn tránh:

Dựng một trang cá nhân với nội dung placeholder. Không dùng nền kem hay
trắng ngà, không in nghiêng từ nhấn trong heading, không đánh số section
kiểu "01 / 02 / 03", không dùng label monospace, không dùng nút bo tròn
hình viên thuốc.

Danh sách càng cụ thể thì kết quả càng khác xa “giao diện AI mặc định”.

---

2. Lái một lượt chạy dài trong Claude Code

Viết luật dừng vào CLAUDE.md

Khi model tự làm được lâu, câu hỏi chính không còn là “nó có làm được không” mà là “lúc nào nó nên dừng lại hỏi tôi”. Đừng để nó tự đoán. Viết thẳng vào CLAUDE.md (phần 4):

## Khi nào dừng lại hỏi

- Bước nào không cần tôi quyết thì làm tiếp, đừng dừng.
- Ghi chú trạng thái đặt chung tin nhắn với hành động tiếp theo,
  không tách thành tin nhắn riêng rồi chờ.
- Chỉ dừng khi không thể đi tiếp nếu thiếu tôi, hoặc TRƯỚC mọi việc
  phá huỷ: xoá dữ liệu, force-push, hay động vào bất cứ thứ gì
  nằm ngoài repo này.

Luật “cứ làm tiếp” không thay được permission. CLAUDE.md chỉ là lời đề nghị, còn permission rule mới là cưỡng chế (bài học rút ra từ phần 11). Vẫn phải giữ permission prompt cho các lệnh phá huỷ, bằng ask hoặc deny rule như ở phần 7. Khi model hiểu sai luật dừng, permission là lớp chặn cuối cùng.

Nếu bạn đang pair programming thay vì giao việc rồi đi làm việc khác, hãy đảo luật lại: yêu cầu một dòng plan trước khi bắt đầu và một đoạn tóm tắt ngắn khi xong. Hai kiểu làm việc này cần hai bộ luật khác nhau. Một cách mình hay dùng là tách chúng thành hai output style, hoặc hai skill gọi lúc cần, thay vì nhồi cả hai vào CLAUDE.md.

Chia việc lớn cho subagent

Với các việc audit, migration, hay review toàn codebase, hãy bảo model chia việc cho subagent và kiểm bằng chứng của từng subagent trước khi chấp nhận kết quả:

Audit mọi service trong services/ xem có dính bug retry trong issue
đính kèm không. Mỗi service giao cho một subagent riêng. Khi subagent
báo về, kiểm bằng chứng của nó trước khi chấp nhận. Kết thúc bằng một
bảng duy nhất: service, có bị ảnh hưởng không, bằng chứng.

Prompt này có ba ý, khớp với ba bài trong chặng nhiều agent:

• Mỗi đơn vị một subagent: context của từng service nằm trong subagent của nó, không dồn vào phiên chính (phần 16).
• Kiểm bằng chứng trước khi chấp nhận: model đang điều phối không tin mù quáng vào báo cáo con. Đây cũng là tinh thần “model đang làm không phải model chấm điểm” ở phần 10.
• Một bảng tổng hợp: định dạng đầu ra được chốt từ trước, nên bạn đọc kết quả rất nhanh.

Khi số đơn vị lên tới vài chục, đó là lúc dùng dynamic workflow thay vì gọi subagent thủ công (phần 18).

Giữ task list trong file

Lượt chạy dài sẽ làm đầy context window và kích hoạt compaction (phần 3). Một checklist chỉ nằm trong hội thoại có thể bị tóm tắt mất chi tiết. Checklist nằm trong file thì giữ nguyên sau compaction, và bạn chỉ cần mở file là biết việc đang tới đâu:

Giữ checklist trong TASKS.md. Làm xong mục nào thì tick mục đó,
phát hiện việc mới thì thêm vào.

Đây cũng là lý do workflow spec-driven (requirement → plan → tasks) chạy tốt với agent: tasks.md là bộ nhớ ngoài không bị compact.

---

3. Kiểm kết quả

Đọc phần “cần bạn” trước

Opus 5.5 báo kết quả minh bạch hơn Opus 5. Nó tách rõ việc đã làm, những gì phát hiện ra, và những gì cần bạn quyết. Vì vậy, khi một lượt chạy dài kết thúc, tìm trước các quyết định hoặc phê duyệt đang chờ bạn, vì đó là thứ đang chặn tiến độ. Diff và tóm tắt đọc sau.

Bạn có thể chốt luôn định dạng báo cáo trong CLAUDE.md:

## Báo cáo cuối lượt

Kết thúc mỗi lượt chạy bằng đúng ba heading:

- **Đang chờ tôi**: quyết định hoặc phê duyệt cần tôi làm
- **Đã thay đổi**: file và hành vi đã đổi
- **Phát hiện**: vấn đề thấy được nhưng chưa xử lý

Nhờ nó review code trước khi người review

Theo thử nghiệm được dẫn trong bài gốc, Opus 5.5 ở mức effort thấp nhất bắt được nhiều bug hơn Opus 5 ở effort high, và ít báo nhầm hơn. Nghĩa là một lượt tự review trước khi đẩy cho đồng nghiệp gần như luôn đáng làm:

Review diff của branch này so với main. Chỉ liệt kê vấn đề đủ nặng để
bạn chặn merge. Với mỗi vấn đề: file và dòng, vì sao sai, và cách
chứng minh nó fail.

Chú ý ý cuối, “cách chứng minh nó fail”. Nó biến mỗi finding thành thứ kiểm được, không còn là ý kiến. Muốn review có cấu trúc hơn và chạy cả trong CI thì xem /code-review và các cách chạy review ở phần 20. Phần giải thích trong review cũng dùng lại được để viết mô tả PR.

Bảo nó đánh dấu những gì chưa xác minh được

Với việc research hay phân tích (tìm nguyên nhân gốc, so sánh thư viện, đọc log), thêm một câu vào cuối prompt:

Đánh dấu những gì bạn chưa xác minh được, và nói rõ bạn đã tìm ở đâu.

Câu này tách điều đã kiểm khỏi điều suy luận, và cho bạn biết phải tự kiểm lại chỗ nào.

---

4. Trong Claude app

Series này nói về Claude Code, nhưng phần lớn người dùng Claude Code cũng dùng Claude app. Bài gốc có năm mẹo cho app, tóm tắt nhanh:

Mẹo	Cách làm
Kiểm model picker	Chắc chắn đang chọn Opus 5.5 trước khi bắt đầu
Đính kèm ảnh, đừng gõ lại	Opus 5.5 đọc chart, diagram, screenshot chính xác hơn Opus 5, kể cả quan hệ không gian: mũi tên nối hộp nào, lịch trùng giờ ra sao, hai bản diagram khác nhau ở đâu
Nhờ soát tài liệu dài	Đưa plan, report hay deck và bảo nó tìm chỗ tự mâu thuẫn về số liệu, ngày tháng, tên. Yêu cầu trích nguyên văn chỗ sai và chỉ vị trí
Xin file hoàn chỉnh	Xin luôn spreadsheet hoặc document chia sẻ được, không xin dàn ý. Bài gốc nói output của Opus 5.5 cần sửa ít hơn trước khi gửi
Trong Project, chốt câu đã trả lời	Xem đoạn dưới

Mẹo cuối cần giải thích thêm. Trong hội thoại dài, Opus 5.5 đôi khi quay lại xem lại câu trả lời cũ khi bạn chỉ hỏi thêm một câu ngắn, và việc đó làm phản hồi chậm đi. Có thể thêm vào instruction của Project một đoạn đại ý: “Câu đã trả lời rồi thì coi như đã chốt. Tập trung vào câu tôi đang hỏi, chỉ quay lại câu cũ khi tôi hỏi tới hoặc chỉ ra nó sai.”

Đừng thêm đoạn này vào Project làm phân tích dài, tức là những Project mà việc làm sau có thể lộ ra lỗi ở phần làm trước. Ở đó, việc model tự xem lại câu trả lời cũ là điều bạn muốn.

---

5. Khi một tin nhắn bị flag

Opus 5.5 ra mắt kèm lớp bảo vệ về an toàn sinh học và an ninh mạng ngang cấp Fable. Tin nhắn bị flag thường được chuyển sang một model cũ hơn để bạn làm tiếp, không bị chặn đứng. Research bảo mật chính đáng và câu hỏi sức khoẻ mang tính giáo dục vẫn chạy bình thường. Lớp bảo vệ đôi khi flag nhầm, và theo bài gốc thì phía Anthropic vẫn đang tinh chỉnh.

	Claude app	Claude Code
Dấu hiệu	Thông báo “Switched to” kèm tên model cũ	Thông báo ghi tên model cũ, phiên chạy tiếp trên model đó
Quay lại Opus 5.5	Chọn lại trong model picker. Nếu tin nhắn cũ dễ bị flag lại thì mở chat mới	Chạy /model
Sửa và thử lại	—	Bấm Esc hai lần khi ô nhập rỗng để mở rewind, sửa tin nhắn cuối rồi thử lại (phần 8)
Không muốn tự chuyển	Settings → Capabilities → tắt “Switch models when a message is flagged”. Khi đó app hiện thẻ “paused” để bạn tự chọn cách xử lý	/config → đổi “Switch models when a message is flagged”
Flag nhầm	—	/feedback

Một chi tiết dễ bỏ sót: flag xét trên toàn bộ nội dung hội thoại, gồm cả file đính kèm và kết quả tìm kiếm. Vì vậy thứ gây flag có thể là thứ bạn đưa vào từ nhiều lượt trước, không phải tin nhắn vừa gửi. Trong Claude Code, đó có thể là output của một lệnh, một file log, hoặc kết quả trả về từ một MCP tool.

Đừng bắt nó chép lại quá trình suy nghĩ vào câu trả lời

Yêu cầu model tái hiện phần suy nghĩ nội bộ vào câu trả lời có thể chạm vào một nhóm flag và bị từ chối. Nếu bạn có dòng kiểu này trong CLAUDE.md hay output style, hãy bỏ nó đi. Muốn hiểu vì sao model chọn một cách làm thì hỏi lời giải thích, đừng hỏi bản chép suy nghĩ:

Giải thích trong ba câu vì sao bạn chọn cách này.

---

6. Tốc độ: fast mode khi bạn ngồi chờ từng câu trả lời

Nếu bạn đang làm kiểu tương tác, đọc từng câu trả lời rồi mới gõ câu tiếp, thì độ trễ là thứ bạn cảm thấy rõ nhất. Đó là lúc bật fast mode bằng /fast. Theo bài gốc, fast mode cho Opus 5.5 lúc ra mắt là research preview: vẫn là model đó nhưng chữ hiện ra nhanh hơn.

Hai điều kiện đã nói ở phần 21 vẫn áp dụng:

• Cần bật usage credit, và giá mỗi token cao hơn standard mode.
• Bật từ đầu hội thoại thì rẻ hơn, vì lần bật đầu tiên phải trả giá input fast mode chưa cache cho toàn bộ context đang có.

Với lượt chạy dài tự chủ theo kiểu ở mục 2, bạn không ngồi chờ từng câu trả lời, nên standard mode hợp lý hơn.

---

Ghép lại: một CLAUDE.md cho lượt chạy dài

Gom các mẹo ở mục 2 và 3 vào một chỗ, bạn có một khối dán thẳng được vào CLAUDE.md của project:

## Làm việc tự chủ

- Bước nào không cần tôi quyết thì làm tiếp. Ghi chú trạng thái đặt chung
  tin nhắn với hành động tiếp theo.
- Chỉ dừng khi không thể đi tiếp nếu thiếu tôi, hoặc TRƯỚC việc phá huỷ:
  xoá dữ liệu, force-push, động vào thứ nằm ngoài repo này.
- Task có từ 3 bước trở lên: giữ checklist trong TASKS.md, tick khi xong,
  thêm việc mới phát hiện.
- Research hoặc phân tích: đánh dấu điều chưa xác minh được và nói đã tìm ở đâu.

## Báo cáo cuối lượt

Kết thúc bằng ba heading: **Đang chờ tôi**, **Đã thay đổi**, **Phát hiện**.

Đi kèm là permission rule cho các lệnh phá huỷ trong .claude/settings.json. CLAUDE.md nói với model điều bạn muốn, còn permission rule mới là thứ đảm bảo điều đó được thực thi:

{
  "permissions": {
    "ask": ["Bash(git push --force *)", "Bash(rm -rf *)"]
  }
}

Hai rule trên chỉ là ví dụ tối thiểu. Hãy thay bằng các lệnh phá huỷ thật của project bạn, và nhớ thứ tự xét deny → ask → allow ở phần 7. Cần logic chặn phức tạp hơn một pattern thì dùng hook PreToolUse (phần 13).

Checklist cho Opus 5.5

Khi giao việc

• Task nói rõ thế nào là “xong”
• Không còn “think hard” trong prompt và trong chỉ dẫn đã lưu
• Việc thiết kế có liệt kê cụ thể các style cần tránh
• Chart và screenshot được đính kèm, không gõ lại

Lượt chạy dài trong Claude Code

• CLAUDE.md có luật: khi nào làm tiếp, khi nào dừng, và việc phá huỷ luôn phải hỏi
• Permission prompt cho lệnh phá huỷ vẫn bật
• Audit và migration lớn được chia cho subagent
• Task list nằm trong file

Khi kiểm kết quả

• Đọc phần “đang chờ tôi” trước
• Có một lượt review code trước khi đẩy cho người review
• Câu trả lời research có đánh dấu điều chưa xác minh

Khi bị flag

• Biết cách quay lại model: model picker hoặc /model
• Đã chỉnh “Switch models when a message is flagged” theo ý mình

Một nhận xét để khép bài

Nhìn lại, phần lớn mẹo trong bài không mới. “Cho nó thứ để tự kiểm chứng”, “giữ state ngoài context window”, “tách lời đề nghị khỏi cưỡng chế” đều đã có ở phần 3, 10 và 11. Cái đổi là điểm cân bằng. Model càng tự làm được lâu thì phần việc của bạn càng dịch từ chỉ từng bước sang đặt vạch đích, đặt luật dừng, và kiểm bằng chứng. Những gì bạn đã đầu tư suốt series (CLAUDE.md, permission, subagent, workflow) chính là công cụ cho phần việc đó.

Nguồn

• Getting the most out of Opus 5.5 — Addy Osmani, 22/9/2026

Bài gốc cập nhật theo model; khi có mâu thuẫn, tin bản tiếng Anh.