Anthropic xoá 80% system prompt: dọn context Claude Code với /doctor

Vì sao ít context hơn giúp Claude 5 làm tốt hơn, giữ gì trong CLAUDE.md và skill, audit setup bằng /doctor và đặt lịch audit định kỳ.

Đã duyệt độc lập · cập nhật 14/10/2026 · 12 min

1. Xoá hơn 80% system prompt mà không mất gì

Nate Herk mở video bằng một câu gây chú ý: các kỹ sư của Anthropic vừa "10x" Claude Code bằng cách xoá hơn 80% system prompt của nó. Nhưng theo anh, điều lớn hơn là họ cũng thay đổi mọi thứ chúng ta từng biết về cách viết prompt. Rất nhiều người trong chúng ta đã được dạy rằng cách tốt nhất để Claude cư xử đúng ý là đưa cho nó càng nhiều thông tin và context càng tốt. Với thay đổi này, theo cách Nate nói, gần như toàn bộ thông tin bạn nhồi vào thực ra đang làm Claude chậm lại, làm chậm cả tốc độ suy nghĩ của nó.

Vì thế, mục tiêu của video là chỉ cho người xem cách sửa project của chính mình theo cách tiếp cận kỹ thuật mà Anthropic vừa công bố. Phần còn lại đi theo thứ tự: bài viết gốc nói gì, vì sao "ít hơn" lại tốt hơn, các thử nghiệm của chính Nate, rồi một buổi audit thật trên setup của anh bằng lệnh /doctor, và cuối cùng là cách biến việc audit thành thói quen định kỳ.

Nate Herk trong khung video YouTube, dòng chữ Fix your projects using Anthropic's Engineering Approach
Lời hứa của video: sửa project của bạn theo cách tiếp cận kỹ thuật mà Anthropic dùng cho chính Claude Code.

2. Bài viết của Anthropic và lời khuyên "sáu tháng xoá skill một lần"

Nguồn gốc của câu chuyện là một bài viết của Thariq Shihipar, một kỹ sư ở Anthropic, tên là "The new rules of context engineering for Claude 5 generation models" (bài viết trên blog Claude). Nhóm của anh đã xoá hơn 80% system prompt của Claude Code dành cho các model như Opus 5, Fable 5, Fable 5.1 và các model tương lai, và họ báo cáo rằng không có mức sụt giảm nào đo được trên các bài evaluation của họ với những model này.

Nate giải thích system prompt là gì cho người chưa rõ: về cơ bản, đó là cuốn sách luật (rulebook) đi kèm Claude Code. Instruction của riêng bạn, cùng với bất kỳ context nào được load cho task, đều nằm ngay bên cạnh system prompt đó. Nên điều Anthropic đang nói là: họ có thể cắt phần lớn cuốn sách luật mà vẫn giữ được hiệu năng họ đã đo trước đó.

Trang blog Claude với tiêu đề The new rules of context engineering for Claude 5 generation models
Bài viết gốc trên blog Claude. Dòng mô tả ghi: họ đã xoá hơn 80% system prompt của Claude Code cho các model mạnh hơn, và bài hướng dẫn cách áp những bài học đó vào context engineering của chính bạn, trong Claude Code lẫn trong agent của bạn.

Trong setup của mình, Nate đã dùng chính hướng dẫn của bài viết này để rà lại những instruction anh tích luỹ theo thời gian, và dọn lại cách các skill của anh phối hợp với nhau. Anh nói điều này đi cùng hướng với một câu của Boris Cherny, người tạo ra Claude Code: đại ý là cứ mỗi sáu tháng, bạn nên xoá toàn bộ skill của mình.

Điều đó nghe ngược đời, vì lâu nay chúng ta được nói rằng skill là thứ làm Claude Code thông minh hơn và nhất quán hơn nhiều. Nhưng chính Anthropic mô tả rằng những rule họ từng cần cho các model cũ đã trở nên quá gò bó khi Claude ngày càng giỏi hơn.

3. Rule viết cho model cũ trở thành chiếc áo chật

Một ví dụ cụ thể trong bài viết là chuyện comment trong code. Trước đây, Anthropic đặt một giới hạn cứng cho lượng comment Claude được viết, dù có những project thực sự cần giải thích nhiều hơn. Bản thay thế bây giờ chỉ bảo Claude làm theo phong cách của phần code xung quanh.

Đoạn bài viết về guardrail cho comment ở model cũ và câu mới trong system prompt
Đoạn bài viết được gạch chân: không có các guardrail này, comment mà model cũ viết sẽ sai trong nhiều trường hợp, nên họ đành chấp nhận đánh đổi; model mới phán đoán tốt hơn và xử lý được mà không cần rule rõ ràng. System prompt mới ghi: "Write code that reads like the surrounding code: match its comment density, naming, and idiom."

Trên màn hình, Nate tóm gọn sự thay đổi thành hai dòng: bản cũ là "Don't write long comments", bản mới là "Use your judgement". Theo anh, rất dễ để chính setup của bạn rơi vào đúng vấn đề này.

Anh mô tả vòng lặp quen thuộc: Claude mắc một lỗi, bạn thêm một rule. Vài tháng sau, rule đó nằm trong file CLAUDE.md hoặc trong một skill, có khi còn một phiên bản hơi khác của nó nằm ở chỗ khác nữa. Thật ra bạn không còn cần rule đó, vì bạn liên tục nâng cấp model, nhưng instruction thì vẫn nằm lì ở đó. Và model bây giờ có thể không cần tới toàn bộ phần context thừa ấy nữa.

4. Định nghĩa "done" rồi tránh đường cho model

Nate nhắc lại một video gần đây của anh về cách prompt Fable 5.1. Trong video đó anh nói về ý tưởng định nghĩa cho model biết "done" trông như thế nào. Về cơ bản, bạn cần đưa cho nó ba thứ: kết quả (outcome) bạn muốn, lý do bạn làm việc này, và các ràng buộc (constraints) nó phải tôn trọng. Sau đó bạn chỉ cần tránh đường cho nó, chừa cho nó khoảng trống để thực sự làm việc.

Outcome"done" trông ra sao Lý dovì sao làm việc này Constraintsđiều phải tôn trọng Khoảng trốngmodel tự quyết cách làm Bạn đưa ba thứ, rồi tránh đường cho model Ví dụ của Nate: ý tưởng YouTube → script, chỉ ra file để anh tự kiểm
Hình 4.1Cách Nate tóm tắt việc prompt các model đời mới: nói rõ đích đến, lý do và ràng buộc, còn con đường thì để model tự chọn.

Với chính video này, anh đã yêu cầu Claude xem xét cách anh đi từ một ý tưởng YouTube tới một script anh có thể quay, hoặc một outline anh có thể quay theo. Anh muốn nó tìm ra một cải tiến nhỏ và chỉ cho anh đúng file, để anh có thể tự kiểm tra khuyến nghị đó. Phần demo này anh sẽ trình bày ở cuối video (mục 13 bên dưới).

5. Context tốt nhất là context nhỏ nhất, nhưng nhỏ không có nghĩa là ngắn

Đội Applied AI của Anthropic khuyên dùng lượng context nhỏ nhất mà vẫn cho ra kết quả bạn muốn (ý này cũng có trong bài Effective context engineering for AI agents). Nate biến nó thành câu nói của riêng mình: context tốt nhất là lượng context nhỏ nhất đem lại kết quả chất lượng cao nhất với chi phí rẻ nhất.

Đoạn bài viết của Anthropic được tô vàng câu về minimal set of information
Câu được tô vàng: bạn nên hướng tới tập thông tin tối thiểu mà vẫn mô tả đầy đủ hành vi mong muốn. Ngay sau đó bài viết ghi chú rằng tối thiểu không nhất thiết là ngắn, và nên bắt đầu bằng một prompt tối thiểu trên model tốt nhất, rồi mới thêm instruction và ví dụ dựa trên các lỗi thấy được khi test.

Anthropic cũng nói thẳng rằng tối thiểu (minimal) không nhất thiết có nghĩa là ngắn. Nếu model cần một chi tiết để làm được việc, thì hiển nhiên bạn phải giữ chi tiết đó lại. Vấn đề không nằm ở độ dài, mà ở chỗ mỗi phần context có thật sự cần thiết hay không.

6. Bằng chứng: input dài làm model kém đi, tool load khi cần thì điểm tăng

Nate dẫn ra nghiên cứu về chuyện điều gì xảy ra khi bạn thêm input. Một paper công bố năm 2025 ("Context Length Alone Hurts LLM Performance Despite Perfect Retrieval") đã thử năm model trên ba loại bài: toán, hỏi đáp và lập trình. Hiệu năng sụt giảm khi input dài ra, ngay cả khi model vẫn truy xuất được thông tin liên quan. Mức sụt được báo cáo nằm trong khoảng từ 13,9% tới 85%, tuỳ model và tuỳ task.

Anh nói rõ giới hạn của con số này: đó là những model khác, nghiên cứu đã cách đây hơn một năm rưỡi, và đó là các thí nghiệm có kiểm soát. Nên các tỉ lệ phần trăm đó không cho biết điều gì sẽ xảy ra khi bạn cắt gọt file CLAUDE.md của chính mình, chẳng hạn.

Nhưng Anthropic cũng đã thử đúng ý tưởng này: chỉ load định nghĩa các MCP tool khi cần (bài Advanced tool use về Tool Search Tool). Trong ví dụ của họ, lượng token dùng giảm 85%, và điểm MCP evaluation tăng từ 49 lên 74 với Opus 4, và từ 79 lên 88 với model thứ hai (trên màn hình ghi Opus 4.5, từ 79,5% lên 88,1%). Vậy là có kết quả đo được đứng sau chính ý tưởng này. Trong trường hợp đó, Claude vẫn có quyền dùng các tool, chỉ là nó không phải load toàn bộ instruction của chúng ngay từ đầu.

Biểu đồ Context Usage: Traditional vs. Tool Search Tool
Biểu đồ của Anthropic: cách truyền thống load sẵn mọi định nghĩa tool (khoảng 72K token cho hơn 50 MCP tool), dùng 77,2K trên 200K token và còn 61,4% chỗ trống; với Tool Search Tool chỉ dùng 8,7K token và còn 95,65% chỗ trống.

Với setup của chính bạn, Nate nói bạn có thể dùng lệnh /doctor. Lần gần nhất anh chạy, báo cáo của doctor cho anh một bản audit workflow với những instruction và những điểm bàn giao (handoff) cụ thể cần dọn. Anh hứa sẽ cho xem ngay sau đây.

7. Sponsor, rồi những thử nghiệm cực đoan với AI OS

Video có một đoạn quảng cáo cho Hyperagent, một nền tảng quản lý agent theo workspace riêng cho từng khách hàng.

Quay lại nội dung chính, Nate kể anh đã thử một số phiên bản khá cực đoan của ý tưởng "ít context hơn", chỉ để thử nghiệm với AI operating system (AI OS) của chính anh. Anh từng nhân bản toàn bộ setup, xoá file CLAUDE.md, xoá các skill, và thử đủ loại prompt khác nhau để xem chúng có làm được cùng một việc không.

Sơ đồ bốn thử nghiệm: Duplicated it, Removed claude.md, Removed skills, Tried many prompt
Bốn kiểu thử nghiệm Nate đã làm quanh một bản Claude: nhân bản setup, bỏ CLAUDE.md, bỏ skill, và thử nhiều prompt khác nhau cho cùng một việc.

8. Student resource guide: bản đẹp và bản có cấu trúc tốt hơn

Một ví dụ gần đây: Nate lấy một buổi phỏng vấn với Boris Cherny và muốn biến nó thành một student resource guide, tức tài liệu học cho học viên. Anh cho cả hai phiên bản cùng làm.

Bản AI OS đầy đủ mà anh quen chạy mỗi ngày cho ra tài liệu đẹp hơn: nó có branding của anh, có heading đúng chuẩn, có những link anh thường chèn, và có nhiều context cụ thể hơn về anh, đại loại những thứ như vậy. Bản "fresh" (không có setup) thì trông lộn xộn hơn một chút, không đẹp bằng.

Nhưng cấu trúc của bản fresh lại tốt hơn nhiều. Nó có chi tiết tốt hơn, nó sắp xếp buổi phỏng vấn theo từng ý tưởng, nó thêm mốc thời gian, và nó đơn giản là có cảm giác chuyên nghiệp hơn, giống một tài liệu tốt hơn để đưa cho học viên. Kết quả là anh có một tài liệu được trau chuốt từ phiên bản này, và một cấu trúc nội dung anh thích hơn từ phiên bản kia.

Sơ đồ: buổi phỏng vấn Boris Cherny thành student resource guide, nhánh AI OS ra Prettier document, nhánh Fresh ra Messier document
Cùng một yêu cầu, hai nhánh: AI OS cho ra tài liệu đẹp hơn (prettier document), bản fresh cho ra tài liệu lộn xộn hơn (messier document) nhưng cấu trúc nội dung tốt hơn.

Đương nhiên anh vẫn muốn giữ branding. Nên điều anh sẽ làm là build một skill mới từ đây, và trong đó nói: này, bạn nên dùng cái này làm header, cái này làm font, cái này làm footer, thêm những logo này, đại loại như vậy. Nhưng việc cấu trúc nội dung thì để model tự quyết theo cách nó thấy phù hợp, vì anh đã đưa cho nó ý định (intent) rồi: biến cái này thành một student resource guide.

Lý do: trong bản đẹp, bản đã có skill của anh, anh đặt quá nhiều guardrail và quá nhiều instruction đến mức về cơ bản đang nhốt model lại. Anh không để nó thật sự sáng tạo và đưa ra output mà nó cho là tốt nhất, vì nó đang đọc skill của anh và phải làm theo instruction của anh. Những instruction đó từng hữu ích hồi còn Opus 4, nhưng giờ đã có Fable 5.1, model có thể tự làm tốt hơn.

9. Đừng đưa checklist trẻ con cho một designer có kinh nghiệm

Nate dùng một phép so sánh: việc này giống như đưa cho một designer giàu kinh nghiệm cái checklist bạn vẫn đưa cho một đứa trẻ làm bài thuyết trình đầu tiên. Designer vẫn cần biết sản phẩm dành cho ai và bạn đang muốn đạt được gì. Nhưng nếu bạn quy định vị trí của từng ô, từng câu, trước cả khi họ nhìn thấy tư liệu, bạn có thể đang chặn họ nghĩ ra một thứ mà rốt cuộc bạn lại thích hơn.

Checklist cho người mớiBrief cho designer giỏi ô A đặt ở đâycâu B viết thế nàyfont, cỡ chữ, thứ tự...mọi thứ quy định trước cho ai, để đạt được gì(giọng, mục tiêu, khán giả) cách sắp xếp: để họ tự quyếtcó thể ra thứ bạn thích hơn
Hình 9.1Phép so sánh của Nate: giữ phần "cho ai, vì sao", bỏ phần quy định từng chi tiết trình bày.

Đó là cách anh nghĩ khi rà lại instruction. Anh muốn giữ những chi tiết giúp Claude hiểu công việc và những gì làm cho nó đặc thù với riêng anh, rồi thử xem nó có còn cần phần quy trình (procedure) anh đã viết bao quanh hay không.

Khi Nate nói về chữ "context" trong bộ bốn chữ C của một AI OS mà anh hay dùng, đây chính là loại thông tin anh muốn nói tới: giọng văn của anh, mục tiêu của anh, khán giả của anh, và cách việc kinh doanh của anh vận hành. Đó là những thứ Claude không thể tự suy ra hay tra trên mạng, nên đó là phần anh phải bổ sung cho nó.

Ngoài ra, việc giải thích vì sao bạn yêu cầu một thứ, tức ý định đằng sau nó, cũng rất quan trọng. Nếu anh đang làm một resource guide cho học viên, điều đó giúp Claude tự quyết chuyện dùng phép so sánh, giải thích đơn giản và đưa ví dụ. Phần context đó anh giữ lại khi dọn skill.

10. CLAUDE.md làm điểm xuất phát, và chạy /doctor

Ngược lại, một danh sách thư mục dài là thứ Claude có thể tự tra được. Nếu cùng một instruction bị lặp ở nhiều chỗ khác nhau, Nate sẽ kiểm xem mình có thật sự cần tất cả các bản sao đó không, hay có thể gom lại. Và nếu một quy trình chi tiết chỉ áp dụng khi anh đang dựng video, anh muốn load nó vào đúng lúc anh đang dựng video.

Tất cả là chuyện tránh đường cho model, nhưng điều đó vẫn có nghĩa là bạn phải nói rõ nó được phép làm gì. Nên anh giữ CLAUDE.md hữu ích như một điểm xuất phát: cho Claude biết project này dùng để làm gì, đưa cho nó những cái bẫy (gotchas) và những "bãi mìn" cần tránh, và chỉ đường tới những instruction sâu hơn. Nhờ vậy, toàn bộ quy trình dựng video của anh không cần nằm đó khi anh chỉ đang nhờ giúp viết script.

Bên trong Claude Code, bạn có thể chạy /doctor để xem qua rất nhiều thứ đang diễn ra ở local mà có lẽ bạn chẳng mấy khi nghĩ tới: settings, các file config, những thứ tẻ nhạt như vậy (xem trang Troubleshooting của Claude Code, nơi /doctor được mô tả là bước kiểm tra tự động cho installation và settings). Nate chạy /doctor trong một session mới, và nó kiểm tra skill, memory, plugin, settings và installation của anh.

Trong bảng kết quả, nó liệt kê từng skill, nơi skill được cài, số lần dùng được ghi nhận kể từ khi cài, và ước tính số token mà phần "listing" của skill chiếm. Nate giải thích: phần listing về cơ bản là YAML frontmatter. Claude Code dùng YAML frontmatter để tìm ra skill, khác với việc load toàn bộ instruction khi nó thật sự quyết định chạy skill và đọc hết nội dung. Ví dụ, skill agent-builder được ước tính 111 token, skill proveit 103 token, và cả hai đều có số lần dùng là 0.

Bảng Detail trong Doctor command liệt kê skill, scope, số lần dùng, token ước tính và verdict
Bảng Detail của /doctor: mỗi dòng là một skill với scope, số lần dùng từ khi cài, có được dùng trong khoảng quét không, số token thường trú ước tính và đề xuất. agent-builder (111 token) và proveit (103 token) đều 0 lần dùng, verdict "remove".

11. Trùng lặp và những nguồn memory bạn không để ý

Báo cáo đánh dấu 18 skill cũ không có lần dùng nào được ghi nhận, nhưng vẫn giữ những skill anh mới tạo vài ngày trước, nghĩa là nó có tính đến tuổi của skill. Nó cũng kiểm 50 session gần nhất của project này, và cho biết đã xem bộ đếm trọn đời (lifetime counters) qua 252 lần khởi động, cùng các lần gọi skill và plugin trên 223 session.

Nate vẫn sẽ tự rà danh sách đó trước khi quyết định tắt, dọn hay xoá bất cứ thứ gì, nhất là khi anh có dùng một skill qua một công cụ khác chẳng hạn. Đây là những số liệu sử dụng mà Claude Code có trong lần audit này, không hơn.

Tiếp theo, nó kiểm tra chuyện trùng lặp. Trong setup của Nate, file project map đang lặp lại những thứ đã có trong routing map. Ngoài ra còn các đoạn trùng về templates, references và cách lưu trữ file. Nó tìm ra khoảng 2.250 ký tự có thể cắt, tiết kiệm ước tính 563 token.

Báo cáo cũng tách riêng từng nơi memory thực sự được load từ đó: CLAUDE.md cấp project, instruction áp cho toàn bộ user, auto memory index, và file CLAUDE.local.md cho các instruction riêng của bản checkout trên máy anh. File local đó chỉ là một template rỗng, ước tính khoảng 35 token. Con số không lớn, nhưng điều Nate muốn nhấn mạnh là doctor sẽ soi qua rất nhiều thứ mà có lẽ bạn chưa bao giờ nghĩ tới.

Báo cáo Doctor command với dòng CLAUDE.local.md, Scan window và Proposed actions
Cuối bảng memory: CLAUDE.local.md, khoảng 35 token, đề xuất xoá vì chỉ là placeholder rỗng. Dòng Scan window ghi 50 session sửa gần nhất, cùng bộ đếm trọn đời qua 252 lần khởi động và 223 session. Bên dưới là phần Proposed actions, bắt đầu với Check 0, kiểm tra sức khoẻ setup.

Nó còn tìm ra một file CLAUDE.md từ một project video riêng nằm trong thư mục desktop của anh, file này được load vào project Herk-2, chiếm thêm khoảng 2.000 token theo ước tính của nó. Nghĩa là dù bạn đã dọn sạch file trong project của mình, vẫn có thể có instruction đến từ một nơi khác mà bạn không hề biết, và về mặt kỹ thuật bạn vẫn đang trả tiền cho nó.

12. Hai skill hỏng và các bước kiểm tra setup

Phần kiểm tra setup còn bắt được hai skill bị hỏng. Một skill bị đặt sai tên file. Skill kia có lỗi định dạng ở phần frontmatter, tức khối mô tả nhỏ ở đầu file như đã nói ở trên, nên Claude thật ra không nhìn thấy đúng phần description của nó. Cả hai file đã được sửa, vì ở cuối buổi audit, doctor hỏi: bạn có muốn tôi sửa hết những thứ này luôn không?

Proposed actions trong Doctor command: skill roast không load, skill storm-research lỗi frontmatter
Check 0 của doctor: installation sạch, năm file settings đều parse được, mười agent definition load không trùng tên. Hai skill hỏng: roast không bao giờ load vì file tên là SKILL (roast).md; storm-research có description là một YAML scalar không có dấu nháy chứa dấu hai chấm, nên mọi field bị bỏ qua và cách sửa là đặt giá trị trong dấu nháy.

Lệnh sửa tên file mà doctor đề xuất cho skill roast, đúng như trên màn hình:

mv ".claude/skills/roast/SKILL (roast).md" ".claude/skills/roast/SKILL.md"

Doctor cũng xem installation của bạn, xem chế độ tự động cập nhật, và kiểm các settings đứng sau auto mode, permissions và hooks của anh.

Nate chèn một lời mời ngắn tham gia cộng đồng miễn phí của anh về xây hệ thống AI và agent.

13. Audit workflow từ ý tưởng YouTube tới script

Sau khi chạy /doctor, Nate yêu cầu Claude Code xem cụ thể workflow YouTube của anh. Đây là prompt anh dùng:

Audit this repo and show me the smallest change that would make the path from a raw YouTube idea to a filming-ready script faster. Use the systems already here, cite the exact files you would reuse, and do not edit anything yet.

Claude vẽ ra các bước: từ tìm ý tưởng, qua research, tới outline, tới script, rồi tới file teleprompter mà anh có thể cắm vào và đọc trong lúc quay. Sau đó nó xem công việc được chuyển từ bước này sang bước kế tiếp như thế nào.

Khuyến nghị chính nằm ở khâu research. Skill outline của anh có thể thu thập dữ kiện, nhưng không bắt buộc lưu bằng chứng vào một file mà skill script biết cách kiểm. Còn skill script của anh lại có một rule cứng bảo nó kiểm chứng lại các dữ kiện từ đầu. Nate giải thích anh đặt rule đó vì anh muốn có bước kiểm chứng, muốn chắc rằng nó không bịa ra dữ kiện hay thông tin. Nhưng nếu đã tìm được nguồn gốc (primary source) và đã kiểm nó nói gì, anh muốn bước tiếp theo có sẵn phần việc đó trước mặt.

Bản audit đếm được 25 thư mục video có script, nhưng chỉ ba thư mục có một file tên đúng là sources.md. Điều đó không có nghĩa tất cả các video khác không hề được research, nhưng nó cho thấy cách bàn giao bằng chứng cụ thể này không nhất quán.

Kết quả YouTube script workflow audit với mục The smallest change gồm ba sửa đổi
Mục "The smallest change": ba sửa đổi trên hai file, không thêm skill hay script mới. (1) Skill outline ghi lại fact base đã thu thập vào sources.md cạnh outline, mỗi claim có URL gốc và câu trích nguyên văn. (2) Skill script chấp nhận claim đã có URL và trích dẫn, chỉ kiểm lại phần chưa có. (3) Sửa đường lưu outline để skill script không phải đoán nó nằm đâu.

Vậy là nó đề xuất ba chỉnh sửa trên hai skill sẵn có. Và một lần nữa, Nate chỉ cần nói: được, nghe ổn đấy, cứ làm ba thay đổi đó đi.

14. Đặt audit thành lịch: một AI OS tự dọn dẹp

Khi đã hiểu cách dùng Claude để audit setup của chính mình, Nate khuyên biến nó thành việc làm đều đặn. Có thể mỗi tháng một lần nếu bạn thêm nhiều skill và liên tục đổi workflow, hoặc mỗi quý một lần nếu setup khá ổn định.

Hình minh hoạ /audit schedule với hai lựa chọn Once a month và Once a quarter, mũi tên Stable chỉ vào Once a quarter
Hai nhịp audit Nate đề xuất: mỗi tháng nếu setup thay đổi nhiều, mỗi quý nếu setup ổn định.

Thật lòng mà nói, điều anh khuyên nhất là: mỗi khi có model mới ra và bạn chuyển sang dùng nó, bạn nên chạy kiểu audit này dù thế nào đi nữa, vì mỗi model sẽ hiểu settings, skill và các file instruction của bạn hơi khác nhau một chút.

Điều hay là khi đã làm vài lần và bắt đầu tin hơn vào doctor hay vào các prompt audit của mình, bạn có thể đặt những bước kiểm tra này thành lịch. Với kiểu kiểm tra setup ở local như thế này, bạn có thể dùng một scheduled task ở local, chạy trong app Claude desktop, nơi nó nhìn thấy đúng các file và settings đó. Bạn chỉ cần để app mở, rồi mỗi tháng một lần nó chạy doctor, chạy các bài audit khác nhau, và sáng ra bạn thức dậy với những khuyến nghị chỉ cần duyệt hoặc từ chối.

Nate nhắc rằng kênh của anh đã nói nhiều về AI OS hay "AI second brain", và một điểm đau lớn của chúng nằm ở con người. Sự nhất quán của con người mới là vấn đề: đôi khi ta quên cập nhật, ta thêm những mục trùng lặp, hay quên xoá những thứ cũ, đại loại vậy. Nếu AI OS có thể làm việc cùng bạn theo một nhịp đều đặn, tự động hoá và dọn dẹp những thứ này, bạn đang tạo ra một hệ điều hành AI tự cải thiện và tự dọn dẹp, rất mạnh.

Theo anh, điều đó có giá trị lớn, vì khi đã có AI OS cá nhân chạy ổn, bạn có thể bắt đầu tính chuyện làm sao để cả team đồng bộ với nhau, làm sao để mọi người cùng làm việc chung thay vì ai cũng làm trùng việc của nhau và tự xây AI OS riêng. Nate kết thúc video, cảm ơn người xem đã theo tới cuối và hẹn gặp lại ở video sau.

Nguồn và liên kết 9 nguồn

  1. Tên gốc: Anthropic Engineers Just 10x'd Everyone's Claude Code
  2. Sự kiện: YouTube
  3. Video gốc: https://www.youtube.com/watch?v=oz2CwrPV2Rg youtube.com
  4. Kênh YouTube Nate Herk | AI Automation (Nate Herk): youtube.com/channel/UC2ojq-nuP8ceeHqiroeKhBA youtube.com
  5. Bài viết "The new rules of context engineering for Claude 5 generation models" của Thariq Shihipar (Anthropic), nói về việc xoá hơn 80% system prompt của Claude Code và lệnh /doctor: claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models claude.com
  6. Anthropic, "Effective context engineering for AI agents" (tập token nhỏ nhất, minimal không có nghĩa là ngắn): anthropic.com/engineering/effective-context-engineering-for-ai-agents anthropic.com
  7. Anthropic, "Advanced tool use" (Tool Search Tool, giảm 85% token, điểm MCP eval của Opus 4 và Opus 4.5): anthropic.com/engineering/advanced-tool-use anthropic.com
  8. Paper "Context Length Alone Hurts LLM Performance Despite Perfect Retrieval" (năm model, toán, hỏi đáp, lập trình, sụt 13,9% tới 85%): arxiv.org/abs/2510.05381 arxiv.org
  9. Claude Code docs, Troubleshooting (lệnh /doctor): code.claude.com/docs/en/troubleshooting code.claude.com