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á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ụ, đây là bài viết rõ ràng nhất về thực hành kỹ thuật của Claude/Codex mà tôi từng thấy.

Tác giả: sysls

Biên dịch: Deep潮 TechFlow

Giới thiệu của Deep潮: Nhà phát triển và 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ẻ, 7000 người thích, với nội dung chính chỉ 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ụ, đây là bài viết rõ ràng nhất về thực hành kỹ thuật của 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à 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 cái gì đó. Bạn đã dùng beads, opencode, zep, bạn đã viết CLAUDE.md tới 26.000 dòng. Nhưng dù làm gì đi nữa, 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.

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

Ngoài ra, tôi không có lợi ích cá nhân gì. Tôi nói CLAUDE.md bao gồm cả AGENT.md, tôi nói Claude bao gồm cả Codex, vì tôi đều dùng cả hai.

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ắc chứng chọn lựa — nghĩ rằng chỉ cần tìm đúng gói, kỹ năng hoặc tổ hợp harness là có thể mở khóa trí tuệ nhân tạo tổng hợp (AGI).

Hôm nay, tôi muốn phá vỡ tất cả điều đó, để lại cho bạn một câu đơ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 không cần đọc hàng triệu bài viết để giữ vững vị thế cạnh tranh. Thực tế, đam mê của bạn có thể gây hại nhiều hơn lợi.

Tôi không phải đi du lịch — tôi đã bắt đầu dùng khi các đại lý còn mập mờ viết mã. Tôi đã thử tất cả các gói, tất cả các harness, tất cả các 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 sử dụng một bộ cấu hình gần như tối giản, chỉ dùng CLI cơ bản (Claude Code và Codex), cộng với hiểu biết về các nguyên tắc cơ bản của kỹ thuật đại lý, để tạo ra công việc đột phá nhất từ trước đến nay của tôi.

Hiểu thế giới đang tiến nhanh như thế nào

Trước tiên, tôi muốn nói rằng các công ty mô hình nền tảng đang trong một cuộc đua mang tính cách mạng, rõ ràng sẽ không chậm lại trong thời gian tới. 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ứ điều gì, hãy đọc READTHISBEFOREDOINGANYTHING.md”, có 50% khả năng chúng sẽ bảo “Đi đi mà”, rồi tự làm theo ý chúng muốn. Hôm nay, chúng tuân thủ hầu hết các lệnh, kể cả các lệnh lồng phức tạp — ví dụ, 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, chúng 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 bạn phải suy nghĩ lại về giải pháp tối ưu, chính vì vậy ít hơn là nhiều hơn.

Khi bạn dùng nhiều thư viện và harness khác nhau, bạn đang 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 với 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 mô hình mới nhất thật sự.

Bạn có 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à 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ĩ 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ớ, 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 tế 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ẽ sớm 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 như vũ bão. Vì vậy, hãy thoải mái đi, bạn không cần cài đặt gì hay dựa vào bên thứ ba để làm tốt nhất có thể.

Tôi dự đoán rằng trong phần bình luận sẽ xuất hiện câu “SysLS, tôi dùng harness nào đó, quá tuyệt! Tôi đã xây dựng lại Google trong một ngày!” — Tôi chúc mừng! 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 nhiều 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á nhiều thông tin làm loãng.

Ví dụ, tôi dùng Python để chơi trò đoán chữ? Đơn giản. Khoảng 26 cuộc hội thoại trước, ghi chú “quản lý bộ nhớ” 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 này liên quan gì đến trò đoán chữ?

Bạn hiểu rồi. Bạn chỉ muốn cung cấp cho đại lý chính xác 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ẽ tốt hơn. 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, trong khi bạn chỉ muốn nó viết một bài thơ nhỏ về rừng đỏ.

Vì vậy, tôi lại 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 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ý 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 ra sao? Bây giờ nó phải đi tìm trên mạng một đống thông tin không thực sự hữu ích, 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.

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…”, thì nó 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ì, và 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 rõ các chi tiết thực thi. Trong nhiều trường hợp, bạn không biết chính xác điều gì đúng, thậm chí muốn giao cho đại lý quyết định các chi tiết đó. 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 để 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ý 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 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 quả cầu 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.

Giới hạn của thiết kế làm hài lòng

Không ai muốn dùng một sản phẩm luôn chỉ trích, bảo 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 với bạn, làm những gì bạn muốn.

Nếu bạn bắt chúng thêm vào mỗi 3 từ một “vui vẻ”, chúng sẽ cố gắng tuân theo — đa số mọi người đều hiểu điều này. Sự phục tùng của chúng chính là lý do khiến chúng trở thành sản phẩm hữu ích 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”, chúng sẽ tìm ra một lỗi — thậm chí cần “tạo” ra một lỗi. Tại sao? Bởi vì chúng 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ẽ giao — dù có cần phải kéo dài thực tế một chút!

Vậy thì làm sao? Tôi thấy “gợi ý trung lập” 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 lập như vậy đôi khi sẽ phát hiện lỗi, đôi khi chỉ mô tả khách quan cách hoạt động của mã. 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ý cố gắng làm hài lòng tôi, tuân theo lệnh của tôi, tôi có thể nghiêng về phía này hoặc phía kia.

Vì vậy, tôi để một đại lý tìm lỗi xác định tất cả lỗi trong database, 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ố như 104. Tôi xem đó là siêu tập hợp tất cả các lỗi có thể.

Sau đó, tôi để 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 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 thận hơn. Nó vẫn tích cực “phản biện” lỗi (kể cả lỗi thật). Tôi xem đó là tập con của tất cả các lỗi thật.

Cuối cùng, tôi để một đại lý trọng tài tổng hợp các đầu vào 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. Rồi 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ẽ xác định đâu là sự thật, rồi tôi sẽ kiểm chứng. 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, nhưng đã gần như không sai sót.

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 từng đại lý — mong muốn làm hài lòng.

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

Vấn đề này có vẻ phức tạp, như thể bạn cần 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.

Bạn có nhận thấy “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 chưa? Bạn có nhận thấy OpenAI đã mua lại OpenClaw chưa? Bạn có thấy Claude ngay sau đó đã thêm các chức năng ghi nhớ, thoại và làm việc từ xa không?

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

Đúng vậy, những thứ đó rất 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 công việc dài hạn… rồi khi Codex 5.2 ra mắt, nhu cầu đó biến mất trong một đêm?

Đây 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 thuộc 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 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ị chúng lừa.

“Cái này thông minh? Thật là ngu ngốc!”

Sự khác biệt lớn nhất là đại lý có bị buộc phải đưa ra giả định hoặc “lấp đầy khoảng trống” hay không. Hiện tại, chúng vẫn cực kỳ kém trong việc “kết nối các điểm” hoặc “lấp đầy khoảng trống” hoặc đưa ra giả định. Miễn là chúng làm vậy, bạn sẽ nhận thấy rõ ràng, tình hình sẽ tệ đ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 đọ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ể tạo ra 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ụ

Cảm giác của con người về “hoàn thành” một nhiệm vụ khá rõ ràng. Đối với đại lý, vấn đề lớn nhất hiện nay là nó biết 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 mẫu rồi dừng lại.

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

Sau đó, bạn chỉ cần xem xét các bài kiểm tra, 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 quá trình này, nhưng điểm mấu chốt — hãy nhớ rằng “kết thúc nhiệm vụ” 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 bài kiểm tra đều qua, rồi chụp màn hình và xác nhận rằng “thiết kế hoặc hành vi” trên ảnh chụp là đúng.

Điều này cho phép bạn yêu cầu đại lý lặp lại và hướng tới thiết kế mong muốn, mà không phải lo nó 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ỉ định các bài kiểm tra, chụp màn hình và các xác nhận 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 có đại lý hoạt động

Một câu hỏi tôi thường nhận được là làm thế nào để đại lý hoạt động 24/7 mà vẫn đảm bảo 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, chứa đựng nội dung 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 bài kiểm tra và xác nhận cần thiết!

Lời khuyên chuyên nghiệp: Tôi thấy 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 phình to ngữ cảnh theo cấu trúc, vì các hợp đồng không liên quan đều sẽ 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 đại lý 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 lớp phối hợp để khi cần làm việc gì đó, tạo hợp đồng mới, rồi mở 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 TA biết rõ lịch trình của bạn từ ngày đầu tiên? Hay bạn chỉ cần biết cách uống cà phê? 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 dần hình thành sở thích theo thời gian.

Đạ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ử 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?

Quy tắc

Nếu bạn không muốn đại lý làm điều gì đó, hãy viết thành quy tắc. Rồi trong CLAUDE.md, nói với đại lý 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 ra các quy tắc điều kiện phức tạp để đại lý tuân theo, Claude (và Codex) rất vui lòng 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, có thể lồng nhau, 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, đi đâu tìm ngữ cảnh”.

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, 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)

Skills giống như quy tắc, nhưng thay vì là sở thích mã hóa, chúng 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, rồi viết thành file kỹ năng. Bạn sẽ thấy trước cách đại lý xử lý vấn đề, và có thể chỉnh sửa hoặc cải tiến trước khi nó gặp phải.

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

Quản lý quy tắc và kỹ năng

Bạn chắc chắ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 cá tính và ghi nhớ sở thích của mình. 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 ý bạn muốn”. Và cuối cùng, bạn sẽ cảm thấy mình “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 trở lại.

Chuyện gì xảy ra?!

Rất đơn giản. Khi bạn thêm nhiều quy tắc và kỹ năng, chúng bắt đầu mâu thuẫn, hoặc gây ra 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ự như vậy — thông tin không cần thiết tràn vào.

Phải làm gì?

Dọn dẹp. Để đại lý của bạn “tự làm spa”, hợp nhất các quy tắc và kỹ năng, qua đó làm rõ sở thích mới của bạn để 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ữ cho đơ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 với đồ chơi của tương lai (đồng thời rõ ràng đang dùng nó để làm việc nghiêm túc) thật sự là một niềm vui!