Claude và Codex ngày càng trở nên ngu hơn? Vì ngữ cảnh của bạn quá rườm rà.

Tác giả: sysls

Biên dịch: Deep潮 TechFlow

Deep潮 giới thiệu: Nhà phát triển blogger sysls với hơn 2,6 triệu người theo dõi đã viết một bài dài thực chiến được 827 người chia sẻ và 7000 người thích, trung tâm của bài viết chỉ có một câu: Những plugin, hệ thống ghi nhớ và các harness của bạn có khả năng cao đang gây phản tác dụng. Bài viết này không nói lý thuyết suông, toàn là các nguyên tắc có thể thực hành được rút ra từ các dự án sản xuất thực tế — từ cách kiểm soát ngữ cảnh, xử lý xu hướng làm hài lòng AI, đến cách xác định điều kiện kết thúc nhiệm vụ, là một trong những bài viết rõ ràng nhất về thực hành kỹ thuật Claude/Codex mà tôi từng thấy.

Toàn văn như sau:

Giới thiệu

Bạn là một nhà phát triển, hàng ngày sử dụng Claude và Codex CLI, hàng ngày tự hỏi liệu mình đã khai thác hết khả năng của chúng chưa. Thỉnh thoảng bạn thấy chúng làm những việc ngu ngốc đến mức khó tin, mà bạn không hiểu tại sao có người dường như đang dùng AI để chế tạo tên lửa, còn bạn thì không thể xếp nổi hai viên đá.

Bạn nghĩ đó là vấn đề của harness, plugin, terminal, hoặc gì đó. Bạn đã dùng beads, opencode, zep, và đã viết 26.000 dòng CLAUDE.md. Nhưng dù có cố gắng thế nào, bạn vẫn không hiểu tại sao ngày càng xa trời xanh, còn người khác thì đang chơi đùa cùng các thiên thần.

Đó chính là bài viết mà bạn đã chờ đợi bấy lâu.

Ngoài ra, tôi không có bất kỳ mối quan hệ lợi ích nào. Tôi nói CLAUDE.md cũng bao gồm AGENT.md, tôi nói Claude cũng bao gồm Codex, vì tôi đều sử dụng cả hai rất nhiều.

Trong vài tháng qua, tôi đã quan sát thấy một điều thú vị: hầu như không ai thực sự biết cách tối đa hóa khả năng của các đại lý.

Cảm giác như chỉ có một nhóm nhỏ người có thể khiến các đại lý xây dựng cả thế giới, còn phần còn lại thì lăn lộn trong biển công cụ mênh mông, mắc phải hội chứng lựa chọn — nghĩ rằng chỉ cần tìm đúng gói, kỹ năng hoặc harness phù hợp là có thể mở khóa trí tuệ nhân tạo tổng quát (AGI).

Hôm nay, tôi muốn phá vỡ tất cả điều đó, để lại cho các bạn một câu nói đơn giản, thành thật, rồi từ đó bắt đầu. Bạn không cần harness mới nhất, không cần cài đặt hàng trăm gói, cũng hoàn toàn không cần đọc hàng triệu bài viết để giữ vững vị thế cạnh tranh. Thực tế, sự nhiệt tình của bạn có thể gây hại nhiều hơn lợi.

Tôi không đến để du lịch — tôi đã bắt đầu dùng khi các đại lý còn mập mờ viết code. Tôi đã thử tất cả các gói, harness, phương pháp. Tôi đã dùng các factory của đại lý để viết tín hiệu, hạ tầng, pipeline dữ liệu — không phải dự án chơi chơi, mà là các ví dụ thực tế chạy trong môi trường sản xuất. Sau tất cả những điều đó…

Hôm nay, tôi chỉ dùng một bộ cấu hình gần như tối giản, chỉ với CLI cơ bản (Claude Code và Codex), cộng thêm hiểu biết về một số nguyên tắc cơ bản của kỹ thuật đại lý, và đã tạo ra công việc đột phá nhất từ trước đến nay.

Hiểu rằng thế giới đang tiến nhanh từng ngày

Trước tiên, tôi muốn nói rằng các công ty mô hình nền đang trong một cuộc đua mang tính cách mạng, và rõ ràng là sẽ không chậm lại sớm. Mỗi lần nâng cấp “trí tuệ đại lý” đều thay đổi cách bạn hợp tác với chúng, vì các đại lý ngày càng được thiết kế để dễ tuân theo hướng dẫn hơn.

Chỉ vài thế hệ trước, nếu bạn viết trong CLAUDE.md “Trước khi làm bất cứ việc gì, hãy đọc READTHISBEFOREDOINGANYTHING.md”, có 50% khả năng nó sẽ bảo “Đi đi”, rồi tự làm theo ý nó. Hôm nay, nó sẽ tuân thủ hầu hết các lệnh, kể cả các lệnh lồng nhau phức tạp — ví dụ như bạn có thể nói “Đầu tiên đọc A, rồi đọc B, nếu C thì đọc D”, và trong đa số trường hợp, nó sẽ vui vẻ theo.

Điều này nói lên điều gì? Nguyên tắc quan trọng nhất là nhận thức rằng: mỗi thế hệ đại lý mới đều bắt buộc bạn phải suy nghĩ lại về giải pháp tối ưu, chính là lý do tại sao “ít hơn là nhiều”.

Khi bạn dùng nhiều thư viện và harness khác nhau, bạn tự khóa mình trong một “giải pháp” duy nhất, nhưng vấn đề này có thể không còn tồn tại trước các thế hệ đại lý tiếp theo. Bạn có biết ai là người dùng nhiệt tình và nhiều nhất của các đại lý không? Đúng rồi — là nhân viên các công ty tiên phong, họ có ngân sách token vô hạn, dùng các mô hình mới nhất thật sự. Bạn hiểu điều đó có nghĩa gì không?

Điều đó có nghĩa là, nếu một vấn đề thực sự tồn tại và có giải pháp tốt, các công ty tiên phong sẽ là những người dùng lớn nhất của giải pháp đó. Và họ sẽ làm gì tiếp theo? Họ sẽ tích hợp giải pháp đó vào sản phẩm của mình. Nghĩ mà xem, tại sao một công ty lại cho phép một sản phẩm khác giải quyết các điểm đau thực sự, tạo ra phụ thuộc bên ngoài? Làm sao tôi biết điều đó là thật? Nhìn vào kỹ năng, harness ghi nhớ, các sub-agent… tất cả đều bắt đầu từ các “giải pháp” giải quyết vấn đề thực, đã được thử nghiệm thực chiến và chứng minh là hữu ích.

Vì vậy, nếu một thứ gì đó thực sự đột phá và có thể mở rộng theo cách có ý nghĩa, nó sớm muộn gì cũng sẽ trở thành phần cốt lõi của sản phẩm nền tảng. Tin tôi đi, các công ty nền tảng đang tiến nhanh từng ngày. Vậy nên, hãy thoải mái đi — bạn không cần cài đặt gì hay dựa vào bất kỳ phụ thuộc nào để làm ra sản phẩm tốt nhất.

Tôi dự đoán rằng trong phần bình luận sẽ sớm xuất hiện câu “SysLS, tôi dùng harness nào đó, quá tuyệt vời! Tôi đã xây dựng lại Google trong một ngày!” — Tôi chúc mừng bạn! Nhưng bạn không phải đối tượng mục tiêu, bạn đại diện cho một nhóm cực kỳ nhỏ trong cộng đồng, những người thực sự hiểu rõ về kỹ thuật đại lý.

Ngữ cảnh là tất cả

Thật sự. Ngữ cảnh là tất cả. Một vấn đề khác khi dùng hàng nghìn plugin và phụ thuộc bên ngoài là bạn dễ bị “phình to ngữ cảnh” — nghĩa là, đại lý của bạn bị quá tải bởi quá nhiều thông tin.

Bạn muốn dùng Python để chơi trò đoán chữ? Đơn giản. Khoan đã, ghi chú “quản lý bộ nhớ” trước 26 cuộc hội thoại đó là gì? À, người dùng có một màn hình bị treo ở 71 cuộc hội thoại trước vì chúng ta sinh ra quá nhiều tiến trình con. Luôn phải viết ghi chú? Được rồi… điều đó liên quan gì đến trò chơi đoán chữ?

Bạn hiểu rồi đấy. Bạn chỉ muốn cung cấp cho đại lý chính xác những thông tin cần thiết để hoàn thành nhiệm vụ, không nhiều hơn không ít hơn! Bạn kiểm soát tốt điều này, hiệu suất của đại lý sẽ càng tốt. Một khi bạn bắt đầu đưa vào các hệ thống ghi nhớ kỳ quặc, plugin, hoặc quá nhiều kỹ năng với cách gọi và đặt tên lộn xộn, bạn đang cung cấp cho đại lý một bản hướng dẫn chế tạo bom và một công thức làm bánh, còn bạn chỉ muốn nó viết một bài thơ nhỏ về rừng đỏ.

Vì vậy, tôi lại một lần nữa giảng dạy — loại bỏ tất cả phụ thuộc, rồi…

Làm những việc thực sự hữu ích

Mô tả chính xác các chi tiết thực hiện

Bạn còn nhớ rằng ngữ cảnh là tất cả không?

Bạn còn nhớ rằng bạn muốn cung cấp cho đại lý chính xác những thông tin cần thiết để hoàn thành nhiệm vụ, không nhiều hơn không ít hơn không?

Cách đầu tiên để làm điều này là tách biệt nghiên cứu và thực thi. Bạn phải cực kỳ chính xác về những gì bạn yêu cầu đại lý làm.

Hậu quả của không chính xác là gì? “Xây dựng một hệ thống xác thực.” Đại lý sẽ phải nghiên cứu: xác thực là gì? Có những phương án nào? Ưu nhược điểm của từng phương án? Bây giờ nó phải đi tìm trên mạng một đống thông tin không thực sự dùng được, trong ngữ cảnh đầy ắp các chi tiết về cách thực hiện có thể có. Khi đến lúc thực thi, nó dễ bị nhầm lẫn hơn, hoặc tạo ra ảo tưởng không cần thiết hoặc không liên quan về các phương án đã chọn.

Ngược lại, nếu bạn nói “Sử dụng bcrypt-12 để mã hóa mật khẩu, thực hiện xác thực JWT, luân phiên làm mới token, hết hạn sau 7 ngày…”, nó sẽ không cần nghiên cứu các phương án thay thế khác, biết rõ bạn muốn gì, từ đó có thể điền các chi tiết thực thi vào ngữ cảnh.

Tất nhiên, bạn không luôn luôn biết các chi tiết thực thi. Trong nhiều trường hợp, bạn không biết điều gì đúng, thậm chí muốn giao việc quyết định các chi tiết đó cho đại lý. Trong trường hợp này thì sao? Rất đơn giản — tạo một nhiệm vụ nghiên cứu để khám phá các khả năng thực thi, hoặc tự quyết định, hoặc để đại lý quyết định chọn phương án nào, rồi giao cho một đại lý khác với ngữ cảnh mới để thực thi.

Khi bạn bắt đầu suy nghĩ theo cách này, bạn sẽ nhận ra những nơi trong quy trình làm việc làm nhiễu ngữ cảnh của đại lý một cách không cần thiết, rồi bạn có thể thiết lập các hàng rào cách ly trong quy trình làm việc của đại lý, loại bỏ các thông tin không cần thiết, chỉ giữ lại những ngữ cảnh đặc thù giúp nó thể hiện tốt trong nhiệm vụ. Nhớ rằng, bạn có một đồng đội rất tài năng, thông minh, hiểu rõ mọi loại bóng trong vũ trụ — nhưng trừ khi bạn nói rõ rằng bạn muốn thiết kế một không gian để mọi người nhảy múa và vui chơi, nó sẽ cứ nói về các lợi ích của hình cầu mãi thôi.

Hạn chế của thiết kế làm hài lòng xu hướng

Không ai muốn dùng một sản phẩm luôn phê phán, nói bạn sai, hoặc hoàn toàn bỏ qua lệnh của bạn. Vì vậy, các đại lý này sẽ cố gắng đồng thuận, làm theo ý bạn muốn.

Nếu bạn yêu cầu nó sau mỗi 3 từ thêm một “vui vẻ”, nó sẽ cố gắng tuân thủ — đa số mọi người đều hiểu điều này. Sự phục tùng của nó chính là lý do khiến nó trở thành một sản phẩm hữu dụng như vậy. Nhưng điều thú vị là: điều này có nghĩa là nếu bạn nói “Giúp tôi tìm một lỗi trong mã nguồn”, nó sẽ tìm ra một lỗi — thậm chí là “tạo” ra một lỗi. Tại sao? Bởi vì nó rất rất muốn nghe theo lệnh của bạn!

Phần lớn mọi người nhanh chóng phàn nàn về việc LLM bị ảo tưởng và bịa đặt những thứ không có thật, mà không nhận ra vấn đề nằm chính ở họ. Bạn yêu cầu nó làm gì, nó sẽ cung cấp đúng như vậy — dù có cần phải kéo dài thực tế một chút.

Vậy thì phải làm sao? Tôi thấy “gợi ý trung tính” rất hiệu quả, nghĩa là không làm đại lý thiên về một kết quả cụ thể nào. Ví dụ, tôi không nói “Giúp tôi tìm một lỗi trong database”, mà nói “Quét toàn bộ database, cố gắng theo logic của từng thành phần, báo cáo tất cả những gì phát hiện được.”

Gợi ý trung tính như vậy đôi khi sẽ phát hiện lỗi, đôi khi chỉ mô tả khách quan cách mã hoạt động. Nhưng nó sẽ không làm đại lý thiên về giả định “có lỗi”.

Một cách khác để xử lý xu hướng làm hài lòng là biến nó thành lợi thế. Tôi biết đại lý đang cố gắng làm hài lòng tôi, tuân theo lệnh của tôi, tôi có thể điều chỉnh hướng đi.

Vì vậy, tôi yêu cầu một đại lý tìm lỗi trong database xác định tất cả các lỗi, gán điểm +1 cho lỗi nhẹ, +5 cho lỗi trung bình, +10 cho lỗi nghiêm trọng. Tôi biết rằng đại lý này sẽ rất nhiệt tình phát hiện tất cả các loại lỗi (kể cả những lỗi không thực sự là lỗi), rồi báo cáo cho tôi điểm số khoảng 104 chẳng hạn. Tôi coi đó là siêu tập hợp tất cả các lỗi có thể.

Sau đó, tôi yêu cầu một đại lý phản biện, nói rằng mỗi lần phản biện thành công một lỗi thì điểm của lỗi đó cộng, còn nếu phản biện sai thì trừ gấp đôi điểm của lỗi đó. Đại lý này sẽ cố gắng phản biện càng nhiều lỗi càng tốt, nhưng vì có cơ chế phạt nên sẽ cẩn trọng hơn. Nó vẫn tích cực “phản biện” lỗi (kể cả lỗi thật). Tôi coi đó là tập con của tất cả các lỗi thật.

Cuối cùng, tôi yêu cầu một đại lý trọng tài tổng hợp các phản hồi trên và chấm điểm. Tôi nói với nó rằng tôi có đáp án đúng, đúng thì cộng 1 điểm, sai thì trừ 1 điểm. Sau đó, nó sẽ chấm điểm cho các đại lý tìm lỗi và phản biện trên từng “lỗi”. Nó sẽ nói ra sự thật, tôi sẽ kiểm tra. Trong hầu hết các trường hợp, phương pháp này cực kỳ chính xác, đôi khi vẫn sai sót, nhưng đã gần như không có sai lệch.

Có thể bạn sẽ thấy rằng chỉ cần một đại lý tìm lỗi là đủ, nhưng phương pháp này rất hiệu quả với tôi vì nó khai thác đặc tính tự nhiên của các đại lý — mong muốn làm hài lòng.

Làm thế nào để biết thứ gì hữu ích, thứ gì đáng dùng?

Vấn đề này có vẻ phức tạp, như thể bạn phải học sâu, theo dõi liên tục các xu hướng AI mới nhất, nhưng thực ra rất đơn giản… Nếu OpenAI và Claude đều đã thực hiện hoặc mua lại các công ty thực hiện điều đó… thì khả năng cao là nó hữu ích.

Chú ý rằng “kỹ năng (skills)” đã xuất hiện khắp nơi, và là một phần trong tài liệu chính thức của Claude và Codex rồi phải không? Chú ý rằng OpenAI đã mua lại OpenClaw chưa? Chú ý rằng Claude đã thêm khả năng ghi nhớ, thoại và làm việc từ xa chưa?

Còn về lập kế hoạch (planning)? Bạn còn nhớ nhiều người đã phát hiện ra rằng lập kế hoạch trước rồi mới thực thi thực sự rất hữu ích, và sau đó nó trở thành chức năng cốt lõi không?

Đúng vậy, những thứ đó đều hữu ích!

Bạn còn nhớ các “stop-hooks” vô tận cực kỳ hữu ích vì đại lý rất ngại làm các tác vụ dài hạn… rồi khi Codex 5.2 ra mắt, nhu cầu đó biến mất trong một đêm?

Đó chính là tất cả những gì bạn cần biết… Nếu một thứ gì đó thực sự quan trọng và hữu ích, Claude và Codex sẽ tự mình thực hiện! Vì vậy, bạn không cần quá lo lắng về việc có nên dùng “đồ mới” hay quen với “đồ mới”, thậm chí không cần “cập nhật liên tục”.

Giúp tôi một việc. Thỉnh thoảng cập nhật công cụ CLI bạn chọn, xem những tính năng mới đã thêm gì. Điều đó đã đủ rồi.

Nén, ngữ cảnh và giả định

Một số người dùng đại lý sẽ gặp phải một cái bẫy lớn: đôi khi chúng trông như là những sinh vật thông minh nhất trên trái đất, đôi khi bạn không thể tin nổi mình đã bị lừa.

“Cái này thông minh à? Thật là ngớ ngẩn!”

Sự khác biệt lớn nhất là đại lý có bị bắt buộc phải đưa ra giả định hoặc “lấp đầy chỗ trống” hay không. Ngày nay, chúng vẫn cực kỳ tệ trong việc “kết nối các điểm”, “lấp đầy chỗ trống” hoặc đưa ra giả định. Miễn là chúng làm vậy, bạn sẽ nhận ra ngay, tình hình rõ ràng đã xấu đi.

Một trong những quy tắc quan trọng nhất trong CLAUDE.md là về cách lấy ngữ cảnh, và hướng dẫn đại lý đọc quy tắc đó ngay khi mỗi lần đọc CLAUDE.md (tức là sau mỗi lần nén). Một phần của quy tắc lấy ngữ cảnh là các chỉ thị đơn giản có thể phát huy tác dụng lớn: đọc lại kế hoạch nhiệm vụ, và trước khi tiếp tục, đọc lại các tài liệu liên quan.

Hướng dẫn đại lý cách kết thúc nhiệm vụ

Chúng ta, con người, cảm nhận rõ ràng về việc một nhiệm vụ “hoàn thành”. Đối với đại lý, vấn đề lớn nhất hiện nay là nó biết cách bắt đầu một nhiệm vụ, nhưng không biết cách kết thúc.

Điều này thường dẫn đến kết quả rất thất vọng: đại lý cuối cùng chỉ tạo ra một đống bản nháp rồi dừng lại.

Kiểm thử là cột mốc rất tốt cho đại lý, vì kiểm thử là xác định rõ ràng, bạn có thể đặt ra các kỳ vọng rõ ràng. Trừ khi tất cả các kiểm thử này đều thành công, nhiệm vụ của bạn chưa hoàn tất; và bạn không được phép sửa đổi kiểm thử.

Sau đó, bạn chỉ cần xem xét các kiểm thử, một khi tất cả đều qua, bạn có thể yên tâm. Bạn cũng có thể tự động hóa việc này, nhưng điểm mấu chốt — hãy nhớ “kết thúc nhiệm vụ” là điều rất tự nhiên đối với con người, còn đối với đại lý thì không.

Bạn còn biết điều gì gần đây đã trở thành điểm kết thúc nhiệm vụ khả thi không? Chụp màn hình + xác nhận. Bạn có thể yêu cầu đại lý thực hiện một thứ gì đó cho đến khi tất cả các kiểm thử đều qua, rồi chụp màn hình và xác nhận “thiết kế hoặc hành vi” trên ảnh chụp.

Điều này cho phép bạn yêu cầu đại lý lặp lại và cố gắng theo đuổi thiết kế mong muốn, mà không lo nó sẽ dừng lại ngay sau lần thử đầu tiên!

Phép mở rộng tự nhiên của điều này là tạo ra một “hợp đồng” với đại lý, rồi nhúng nó vào các quy tắc. Ví dụ, {TASK}CONTRACT.md quy định những gì cần làm trước khi bạn được phép kết thúc cuộc trò chuyện. Trong {TASK}CONTRACT.md, bạn sẽ chỉ rõ các kiểm thử, chụp màn hình và các xác minh khác cần hoàn thành trước khi nhiệm vụ được xác nhận là đã kết thúc!

Luôn luôn chạy đại lý

Một câu hỏi tôi thường nhận được là làm thế nào để giữ cho đại lý hoạt động 24/7 mà không bị lệch hướng?

Có một cách rất đơn giản. Tạo một stop-hook, trừ khi tất cả các phần của {TASK}_CONTRACT.md đã hoàn thành, thì mới cho phép đại lý kết thúc cuộc trò chuyện.

Nếu bạn có 100 hợp đồng rõ ràng, bao gồm tất cả những gì bạn muốn xây dựng, thì stop-hook sẽ ngăn đại lý kết thúc cho đến khi tất cả 100 hợp đồng đều hoàn thành, bao gồm tất cả các kiểm thử và xác minh cần thiết!

Lời khuyên chuyên nghiệp: Tôi thấy rằng các cuộc hội thoại dài 24 giờ không phải là cách tối ưu để “làm việc”. Một phần lý do là cách này sẽ gây ra sự phình to ngữ cảnh về mặt cấu trúc, vì các hợp đồng không liên quan đều sẽ đi vào cùng một cuộc hội thoại!

Vì vậy, tôi không khuyên làm như vậy.

Thay vào đó, có một cách tự động hóa tốt hơn — mỗi hợp đồng mở một cuộc hội thoại mới. Mỗi khi bạn cần làm việc gì đó, hãy tạo một hợp đồng mới.

Xây dựng một tầng phối hợp để tạo hợp đồng mới khi “cần làm việc gì đó”, rồi mở một cuộc hội thoại mới để xử lý hợp đồng đó.

Điều này sẽ hoàn toàn thay đổi trải nghiệm của bạn với đại lý.

Lặp lại, lặp lại, lặp lại

Bạn thuê một trợ lý hành chính, bạn mong đợi họ biết rõ lịch trình của bạn từ ngày đầu tiên? Hay bạn chỉ đơn giản là uống cà phê thế nào? Bạn ăn tối lúc 6 giờ tối chứ không phải 8 giờ? Rõ ràng là không. Bạn sẽ dần hình thành sở thích theo thời gian.

Và đại lý cũng vậy. Bắt đầu từ cấu hình đơn giản nhất, bỏ qua các cấu trúc phức tạp hoặc harness, thử với CLI cơ bản.

Sau đó, dần dần thêm các sở thích của bạn. Làm thế nào?

Nguyên tắc

Nếu bạn không muốn đại lý làm điều gì đó, hãy viết nó thành quy tắc. Rồi trong CLAUDE.md, nói cho đại lý biết quy tắc đó. Ví dụ: “Trước khi viết mã, hãy đọc coding-rules.md.” Quy tắc có thể lồng nhau, có thể có điều kiện! Nếu bạn đang viết mã, đọc coding-rules.md; nếu bạn đang viết kiểm thử, đọc coding-test-rules.md. Nếu kiểm thử thất bại, đọc coding-test-failing-rules.md. Bạn có thể tạo các quy tắc điều kiện phức tạp để đại lý tuân theo, Claude (và Codex) sẽ rất vui vẻ làm theo, miễn là trong CLAUDE.md có hướng dẫn rõ ràng.

Thực tế, đây là lời khuyên thực tế đầu tiên tôi đưa ra: hãy xem CLAUDE.md như một thư mục logic, lồng ghép, mô tả nơi tìm ngữ cảnh trong các tình huống và kết quả cụ thể. Nó nên càng ngắn gọn càng tốt, chỉ chứa các IF-ELSE logic “Trong trường hợp nào, tìm ngữ cảnh ở đâu”.

Nếu bạn thấy đại lý làm điều gì đó mà bạn không đồng ý, hãy thêm nó thành một quy tắc, rồi bảo đại lý đọc quy tắc đó trước khi làm việc tiếp theo — chắc chắn nó sẽ không làm nữa.

Kỹ năng (Skills)

Kỹ năng (Skills) tương tự quy tắc, nhưng thay vì là sở thích mã hóa, nó phù hợp hơn để mô tả “các bước thao tác”. Nếu bạn có một cách cụ thể để hoàn thành một việc, bạn muốn nhúng nó vào kỹ năng.

Thực tế, mọi người thường phàn nàn rằng không biết đại lý sẽ xử lý vấn đề như thế nào, điều này gây lo lắng. Nếu bạn muốn chắc chắn, hãy để đại lý nghiên cứu cách nó sẽ giải quyết vấn đề đó, rồi viết thành file kỹ năng. Bạn sẽ biết trước cách đại lý xử lý, và có thể sửa đổi hoặc cải tiến trước khi nó gặp vấn đề thực sự.

Làm thế nào để đại lý biết về kỹ năng này? Đúng rồi! Trong CLAUDE.md, viết rằng khi gặp tình huống này, cần đọc SKILL.md.

Xử lý quy tắc và kỹ năng

Chắc chắn bạn muốn liên tục thêm quy tắc và kỹ năng cho đại lý. Đó là cách bạn tạo cho nó cá tính và ghi nhớ sở thích của bạn. Hầu hết mọi thứ khác đều thừa thãi.

Khi bắt đầu làm như vậy, đại lý của bạn sẽ cảm giác như phép thuật. Nó sẽ “làm theo cách bạn muốn”. Và cuối cùng, bạn sẽ cảm thấy “hiểu ra” về kỹ thuật đại lý.

Rồi…

Bạn sẽ thấy hiệu suất bắt đầu giảm sút trở lại.

Chuyện gì xảy ra?

Rất đơn giản. Khi bạn thêm quá nhiều quy tắc và kỹ năng, chúng bắt đầu mâu thuẫn nhau, hoặc đại lý bắt đầu bị phình to ngữ cảnh nghiêm trọng. Nếu bạn cần đại lý đọc 14 file markdown trước khi bắt đầu lập trình, thì cũng gặp vấn đề tương tự — thông tin không liên quan sẽ tràn vào.

Phải làm sao?

Dọn dẹp. Hãy để đại lý của bạn “tự làm spa”, hợp nhất các quy tắc và kỹ năng, qua đó bạn cập nhật sở thích mới để loại bỏ mâu thuẫn.

Lúc đó, nó lại cảm giác như phép thuật.

Chỉ vậy thôi. Đó chính là bí quyết. Giữ mọi thứ đơn giản, dùng quy tắc và kỹ năng, xem CLAUDE.md như một thư mục, và cẩn thận với ngữ cảnh cũng như giới hạn thiết kế của chúng.

Chịu trách nhiệm về kết quả

Hiện tại, không có đại lý hoàn hảo. Bạn có thể giao nhiều công việc thiết kế và thực thi cho đại lý, nhưng bạn phải chịu trách nhiệm về kết quả.

Vì vậy, hãy cẩn thận… rồi hãy tận hưởng!

Chơi đùa với các đồ chơi của tương lai (đồng thời rõ ràng đang dùng chúng để làm việc nghiêm túc) thật sự là một niềm vui!