Sysls cảnh báo: Tải quá nhiều ngữ cảnh vào Claude và Codex có thể làm giảm hiệu suất

iconTechFlow
Chia sẻ
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary iconTóm tắt

expand icon
Tin tức AI + tiền mã hóa: Nhà phát triển và blogger sysls, với 2,6 triệu người theo dõi, cảnh báo rằng việc tải quá nhiều plugin và hệ thống bộ nhớ vào các công cụ AI như Claude và Codex có thể làm giảm hiệu suất. Bài viết nhấn mạnh nhu cầu sử dụng hướng dẫn rõ ràng và ngữ cảnh tối thiểu để tăng hiệu quả. Trong khi các mô hình mới hơn xử lý các tác vụ phức tạp tốt hơn, các phụ thuộc bổ sung có thể gây nhầm lẫn. Các mẹo bao gồm sử dụng lời nhắc trung lập và tránh làm ô nhiễm ngữ cảnh. Tin tức trên chuỗi cho thấy sự quan tâm ngày càng tăng trong việc tối ưu hóa quy trình AI để đạt kết quả tốt hơn.

Tác giả: sysls

Biên dịch: Deep潮 TechFlow

Đọc trước của Shenchao: Một blogger phát triển với 2,6 triệu người theo dõi, sysls, đã viết một bài viết dài thực tế được 827 người chia sẻ và 7.000 người thích. Hạt nhân duy nhất của bài viết là một câu: Các tiện ích, hệ thống ghi nhớ và mọi loại harness mà bạn đang dùng rất có thể đang gây cản trở. Bài viết này không nói lý thuyết suông, mà tổng hợp các nguyên tắc hành động cụ thể 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 nịnh nọt của AI, đến cách xác định điều kiện kết thúc nhiệm vụ, là bài viết rõ ràng nhất mà tôi từng thấy về thực hành kỹ thuật với Claude/Codex.

Toàn văn như sau:

Lời mở đầu

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

Bạn cho rằng đó là vấn đề của harness, plugin, terminal, hay gì đó. Bạn đã dùng beads, opencode, zep, và file CLAUDE.md của bạn đã viết tới 26.000 dòng. Nhưng dù có thử bao nhiêu cách đi nữa, bạn vẫn không hiểu vì sao mình ngày càng xa rời thiên đường, trong khi người khác lại đang đùa giỡn cùng các thiên thần.

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

Ngoài ra, tôi không có lợi ích liên quan. 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 sử dụng cả hai một cách thường xuyên.

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

Cảm giác như chỉ một nhóm nhỏ người có thể khiến các đại lý xây dựng nên cả thế giới, trong khi những người còn lại đang quay cuồng trong biển công cụ, mắc chứng rối loạn lựa chọn—tin rằng chỉ cần tìm được đúng tổ hợp gói, kỹ năng hoặc harness là có thể mở khóa AGI.

Hôm nay, tôi muốn phá vỡ tất cả những điều đó để dành cho bạn một câu đơn giản và trung thực, rồi chúng ta sẽ bắt đầu từ đó. Bạn không cần đến công cụ proxy mới nhất, không cần cài đặt hàng triệu gói phần mềm, và hoàn toàn không cần đọc hàng triệu bài viết để duy trì tính cạnh tranh. Thực tế, đam mê của bạn có thể gây hại nhiều hơn là có lợi.

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

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

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

Trước hết, 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 nước rút mang tính lịch sử, và rõ ràng sẽ không sớm chậm lại. Mỗi lần cải tiến về “trí thông minh đại lý” đều thay đổi cách bạn hợp tác với chúng, vì các đại lý được thiết kế ngày càng sẵn sàng tuân theo lệnh.

Chỉ vài thế hệ trước, nếu bạn viết trong CLAUDE.md: “Đọc READTHISBEFOREDOINGANYTHING.md trước khi làm bất kỳ điều gì”, nó có 50% khả năng sẽ trả lời bạn: “Đi chỗ khác”, rồi tự mình làm những gì nó muốn. Hôm nay, nó tuân theo hầu hết các lệnh, thậm chí cả các lệnh lồng phức tạp — ví dụ, bạn có thể nói: “Đọc A trước, sau đó đọc B, nếu C thì đọc D”, và hầu hết thời gian nó sẽ vui vẻ làm theo.

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

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

Điều này 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, thì các công ty hàng đầu sẽ là người dùng lớn nhất của giải pháp đó. Sau đó, họ sẽ làm gì? Họ sẽ tích hợp giải pháp đó vào sản phẩm của mình. Hãy 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 những nỗi đau thực sự và tạo ra sự phụ thuộc bên ngoài? Làm sao tôi biết điều này là thật? Hãy xem các kỹ năng, memory harness, sub-agents… tất cả đều bắt đầu từ những “giải pháp” giải quyết vấn đề thực tế, đã được kiểm nghiệm trong thực tế và chứng minh là hữu ích.

Vì vậy, nếu một thứ gì đó thực sự mang tính đột phá và có thể mở rộng các trường hợp sử dụng đại lý một cách có ý nghĩa, thì sớm muộn gì nó cũng sẽ được tích hợp vào sản phẩm cốt lõi của công ty cơ sở. Tin tôi đi, công ty cơ sở đang tiến rất nhanh. Vì vậy, hãy thư giãn, bạn không cần cài đặt bất cứ thứ gì hay phụ thuộc vào bất kỳ yếu tố bên ngoài nào để thực hiện công việc tốt nhất.

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

Bối cảnh là tất cả

Thật sự mà nói, bối cảnh là tất cả. Một vấn đề khác khi sử dụng hàng nghìn plugin và phụ thuộc bên ngoài là bạn bị ảnh hưởng nghiêm trọng bởi “sự phình đại bối cảnh” — tức là đại lý của bạn bị ngập tràn bởi quá nhiều thông tin.

Hãy để tôi tạo một trò chơi đoán chữ bằng Python? Dễ thôi. Nhưng này, ghi chú “quản lý bộ nhớ” cách đây 26 cuộc hội thoại là gì? À, người dùng có một màn hình bị treo cách đây 71 cuộc hội thoại vì chúng ta tạo quá nhiều tiến trình con. Luôn luôn phải ghi chú sao? Được, không vấn đề... Nhưng điều này liên quan gì đến trò chơi đoán chữ?

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

Vì vậy, tôi lại một lần nữa truyền giáo — loại bỏ tất cả các phụ thuộc, sau đó...

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

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

Remember that context is everything?

Remember that you want to inject the exact information the agent needs to complete the task—no more, no less?

Cách đầu tiên để làm được điều này là tách riêng nghiên cứu và thực hiện. Bạn phải cực kỳ chính xác trong việc yêu cầu đại diện thực hiện điều gì.

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

Ngược lại, nếu bạn nói “sử dụng mật khẩu hash bcrypt-12 để xác thực JWT, xoay vòng token làm mới, hết hạn sau 7 ngày...”, thì không cần nghiên cứu bất kỳ giải pháp thay thế nào khác, vì đã rõ bạn muốn gì, từ đó có thể lấp đầy ngữ cảnh bằng các chi tiết triển khai.

Tất nhiên, bạn sẽ không luôn biết được các chi tiết thực hiện. Nhiều lúc bạn không biết điều gì là đúng, đôi khi thậm chí muốn giao việc xác định chi tiết thực hiện cho đại lý. Vậy thì phải làm 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 hiện khác nhau, sau đó tự quyết định hoặc để đại lý chọn cách thực hiện nào, rồi giao cho một đại lý khác với bối cảnh hoàn toàn mới để thực hiện.

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

Hạn chế thiết kế do xu hướng chiều chuộng

Không ai muốn sử dụng một sản phẩm luôn chỉ trích bạn, nói với bạn rằng bạn sai, hoặc hoàn toàn bỏ qua các lệnh của bạn. Vì vậy, các đại lý này sẽ nỗ lực đồng ý với bạn và làm những gì bạn muốn.

Nếu bạn yêu cầu nó thêm từ “vui vẻ” sau mỗi 3 từ, nó sẽ nỗ lực tuân theo—đa số mọi người đều hiểu điều này. Sự tuân thủ của nó chính là lý do khiến nó trở thành một sản phẩm cực kỳ hữu ích. Nhưng nó có một đặc tính rất thú vị: đ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 kho mã nguồn”, nó sẽ tìm ra một lỗi—ngay cả khi phải “tạo ra” một lỗi. Tại sao? Vì nó cực kỳ muốn tuân theo lệnh của bạn!

Hầu hết mọi người nhanh chóng phàn nàn rằng LLM tạo ra ảo giác và bịa đặt những điều không tồn tại, nhưng lại không nhận ra vấn đề nằm ở chính họ. Bạn yêu cầu nó tìm gì, nó sẽ cung cấp đúng thứ đó—ngay cả khi phải hơi bóp méo sự thật!

Vậy thì phải làm sao? Tôi thấy rằng “gợi ý trung lập” rất hiệu quả, tức là không thiên vị proxy về một kết quả cụ thể nào. Ví dụ, thay vì nói “Hãy giúp tôi tìm một lỗi trong cơ sở dữ liệu”, tôi sẽ nói “Quét toàn bộ cơ sở dữ liệu, cố gắng theo dõi logic của từng thành phần và báo cáo lại tất cả những phát hiện.”

Các cảnh báo trung tính như vậy đôi khi phát hiện ra lỗi, đôi khi chỉ mô tả khách quan cách mã hoạt động. Nhưng nó không thiên về giả định rằng proxy “có lỗi”.

Một cách khác để xử lý xu hướng nịnh nọt là biến nó thành lợi thế. Tôi biết đại lý đang nỗ lực làm vừa lòng tôi và tuân theo chỉ lệnh của tôi, nên tôi có thể nghiêng về phía này hoặc phía kia.

Vì vậy, tôi đã giao cho một đại lý tìm lỗi để xác định tất cả các lỗi trong cơ sở dữ liệu, bảo nó rằng lỗi ảnh hưởng thấp được cộng +1 điểm, lỗi có ảnh hưởng nhất định được cộng +5 điểm, và lỗi nghiêm trọng được cộng +10 điểm. Tôi biết đại lý này sẽ rất nhiệt tình xác định tất cả các loại lỗi (bao gồm cả những thứ không phải lỗi), rồi báo cho tôi một điểm số như 104. Tôi xem đây là siêu tập của tất cả các lỗi có thể có.

Sau đó, tôi cho một đại diện đối kháng phản bác, thông báo rằng mỗi lần phản bác thành công một lỗi sẽ nhận được điểm tương ứng với lỗi đó, nhưng nếu phản bác sai sẽ bị trừ -2 lần điểm của lỗi đó. Đại diện này sẽ nỗ lực phản bác càng nhiều lỗi càng tốt, nhưng do có cơ chế trừng phạt nên sẽ giữ sự cẩn trọng. Nó vẫn sẽ tích cực "phản bác" các lỗi (bao gồm cả các lỗi thực sự). Tôi xem đây là tập con của tất cả các lỗi thực sự.

Cuối cùng, tôi sử dụng một trọng tài đại diện để tổng hợp đầu vào từ cả hai bên và cho điểm. Tôi thông báo với trọng tài đại diện rằng tôi có câu trả lời đúng thực tế, nếu họ trả lời đúng thì được +1 điểm, trả lời sai thì bị -1 điểm. Sau đó, trọng tài tiến hành cho điểm đối với đại diện tìm lỗi và đại diện đối kháng trên từng “lỗi” cụ thể. Điều gì mà trọng tài cho là sự thật, tôi sẽ xác minh. Trong hầu hết các trường hợp, phương pháp này cho độ chính xác cao một cách đáng kinh ngạc; thỉnh thoảng vẫn có sai sót, nhưng đây đã là một quy trình gần như hoàn hảo.

Bạn có thể thấy rằng chỉ cần tìm đại lý sửa lỗi là đủ, nhưng phương pháp này rất hiệu quả với tôi vì nó tận dụng đặc tính bẩm sinh của mỗi đại lý—mong muốn làm hài lòng.

Làm thế nào để xác định cái gì hữu ích và cái gì đáng để sử dụng?

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

Bạn đã để ý rằng “kỹ năng (skills)” đã trở nên phổ biến và là một phần trong tài liệu chính thức của Claude và Codex chưa? Bạn đã để ý rằng OpenAI đã mua lại OpenClaw chưa? Bạn đã để ý rằng Claude ngay lập tức bổ sung các tính năng bộ nhớ, âm thanh và làm việc từ xa chưa?

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

Đúng vậy, những cái đó rất hữu ích!

Bạn còn nhớ những stop-hooks vô tận rất hữu ích vì các đại lý cực kỳ không muốn thực hiện các công việc chạy lâu dài... rồi sau đó Codex 5.2 ra đời, nhu cầu đó biến mất chỉ trong một đêm không?

Đó 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ự triển khai nó! Vì vậy, bạn không cần phải lo lắng quá nhiều về việc có nên dùng "thứ mới" hay làm quen với "thứ mới", bạn thậm chí không cần "cập nhật".

Giúp tôi một việc. Thỉnh thoảng cập nhật công cụ CLI bạn đã chọn và đọc xem đã thêm tính năng gì. Thế là đủ rồi.

Nén, bối cảnh và giả định

Một số người khi sử dụng proxy sẽ phát hiện ra một cái bẫy lớn: đôi khi chúng trông như những sinh vật thông minh nhất trên Trái Đất, nhưng đôi khi bạn lại không thể tin nổi rằng mình đã bị chúng lừa.

Cái này thông minh à? Cái này là đồ ngốc!

Sự khác biệt lớn nhất là liệu đại lý có bị ép buộc phải đưa ra giả định hoặc “điền vào khoảng trống” hay không. Hiện nay, chúng vẫn cực kỳ kém trong việc “nối các điểm lại với nhau”, “điền vào khoảng trống” hoặc đưa ra giả định. Chỉ cần chúng làm điều đó, bạn sẽ lập tức nhận ra, tình hình rõ ràng trở nên tệ hơn.

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

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

Con người chúng ta có cảm giác rất rõ ràng về việc một nhiệm vụ đã được “hoàn thành”. Đối với các tác nhân, vấn đề lớn nhất của trí tuệ hiện tại là chúng biết cách bắt đầu một nhiệm vụ nhưng không biết cách kết thúc nó.

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

Việc kiểm thử là một cột mốc rất tốt cho đại lý, vì kiểm thử là xác định và bạn có thể thiết lập các kỳ vọng rất rõ ràng. Ngoại trừ khi X bài kiểm thử này vượt 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 thử.

Sau đó, bạn chỉ cần kiểm tra các bài kiểm tra; một khi tất cả các bài kiểm tra đều vượt qua, bạn có thể yên tâm. Bạn cũng có thể tự động hóa quy trình này, nhưng điều quan trọng là—hãy nhớ rằng “kết thúc nhiệm vụ” với con người là điều tự nhiên, nhưng không phải với đại lý.

Bạn có biết gần đây có gì trở thành điểm đến của nhiệm vụ khả thi không? Chụp màn hình + xác minh. Bạn có thể yêu cầu đại lý thực hiện một điều gì đó cho đến khi tất cả các bài kiểm tra đều thành công, sau đó để nó chụp màn hình và xác minh “thiết kế hoặc hành vi” trên màn hình.

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

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

Proxy chạy liên tục

Một câu hỏi tôi thường được hỏi là làm thế nào để người dùng có thể chạy đại lý 24/7 đồng thời đảm bảo nó không bị lệch hướng?

Có một cách rất đơn giản. Tạo một stop-hook để ngăn phiên làm việc của đại lý kết thúc cho đến khi tất cả các phần của `{TASK}_CONTRACT.md` đều được hoàn thành.

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

Lời khuyên chuyên nghiệp: Tôi nhận thấy rằng các phiên 24 giờ kéo dài không phải là cách tối ưu để “làm việc”. Một phần nguyên nhân là cách này về mặt cấu trúc sẽ buộc phải引入 ngữ cảnh phình to, vì ngữ cảnh của các hợp đồng không liên quan đều sẽ được đưa vào cùng một phiên!

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

Có một cách tự động hóa đại lý tốt hơn—mở một phiên mới cho mỗi hợp đồng. Tạo hợp đồng mỗi khi bạn cần thực hiện một việc gì đó.

Tạo một lớp sắp xếp để tạo hợp đồng mới khi có việc cần thực hiện, đồng thời tạo phiên mới để xử lý hợp đồng đó.

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

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 có kỳ vọng rằng họ sẽ biết lịch trình của bạn ngay từ ngày đầu tiên? Hay bạn uống cà phê thế nào? Bạn ăn tối lúc 6 giờ tối thay vì 8 giờ? Rõ ràng là không. Bạn sẽ dần hình thành sở thích theo thời gian.

Cũng tương tự với đại lý. Bắt đầu với cấu hình đơn giản nhất, bỏ qua các cấu trúc phức tạp hoặc harness, hãy cho CLI cơ bản một cơ hội.

Sau đó, từ từ 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 ghi thành quy tắc. Sau đó thông báo quy tắc này cho đại lý trong CLAUDE.md. Ví dụ: “Trước khi viết mã, hãy đọc `coding-rules.md`.” Các quy tắc có thể lồng nhau và có thể mang tính điều kiện! Nếu bạn đang viết mã, hãy đọc `coding-rules.md`; nếu bạn đang viết bài kiểm tra, hãy đọc `coding-test-rules.md`. Nếu bài kiểm tra của bạn đang thất bại, hãy đọc `coding-test-failing-rules.md`. Bạn có thể tạo ra bất kỳ nhánh logic nào của quy tắc để đại lý tuân theo, Claude (và Codex) sẽ rất sẵn lòng làm theo, miễn là có hướng dẫn rõ ràng trong CLAUDE.md.

Thực tế, đây là lời khuyên thực tế đầu tiên tôi đưa ra: Hãy coi CLAUDE.md của bạn như một danh mục logic, lồng ghép, chỉ rõ nơi tìm ngữ cảnh trong các tình huống và kết quả cụ thể. Nó nên được tối giản nhất có thể, chỉ bao gồm logic IF-ELSE về “trong trường hợp nào thì tìm ngữ cảnh ở đâu”.

Nếu bạn thấy đại lý đang làm điều gì đó bạn không đồng ý, hãy thêm nó thành một quy tắc và thông báo cho đại lý rằng trước khi thực hiện lại hành động đó, họ phải đọc quy tắc đó—họ chắc chắn sẽ không làm vậy nữa.

Kỹ năng

Kỹ năng (Skills) tương tự như quy tắc, nhưng thay vì là sở thích mã hóa, chúng phù hợp hơn để mã hóa các “bước thực hiện”. Nếu bạn có một cách cụ thể mà bạn muốn một việc nào đó được thực hiện, 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 họ không biết đại lý sẽ giải quyết vấn đề như thế nào, điều này gây ra sự bất an. Nếu bạn muốn tạo ra sự chắc chắn, hãy để đại lý nghiên cứu trước cách nó sẽ giải quyết vấn đề đó, sau đó ghi lại giải pháp thành tệp kỹ năng. Bạn sẽ có thể xem trước cách đại lý xử lý vấn đề và điều chỉnh hoặc cải tiến nó trước khi nó thực sự đối mặt với vấn đề.

Làm thế nào để đại lý biết đến kỹ năng này? Đúng vậy! Bạn ghi trong CLAUDE.md rằng khi gặp tình huống này và cần xử lý việc này, hãy đọc tệp `SKILL.md`.

Quy tắc và kỹ năng xử lý

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 cho nó. Hầu hết mọi thứ khác đều thừa thãi.

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

Sau đó……

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

Chuyện gì vậy?!

Rất đơn giản. Khi bạn thêm càng nhiều quy tắc và kỹ năng, chúng bắt đầu mâu thuẫn với nhau, hoặc đại lý bắt đầu gặp vấn đề phình to ngữ cảnh nghiêm trọng. Nếu bạn cần đại lý đọc 14 tệp markdown trước khi bắt đầu lập trình, nó sẽ gặp cùng một vấn đề với một đống thông tin vô dụng.

Phải làm gì bây giờ?

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

Sau đó, nó lại cảm thấy như phép màu.

Chỉ có vậy. Đó thực sự là chìa khóa. Giữ đơn giản, sử dụng quy tắc và kỹ năng, coi CLAUDE.md như mục lục và chú ý cẩn thận đến ngữ cảnh và giới hạn thiết kế của chúng.

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

Hôm nay 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 hiện cho đại lý, nhưng bạn phải chịu trách nhiệm cho kết quả.

Vì vậy, hãy cẩn thận... và tận hưởng thật tốt!

Việc 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 là thú vị!

Tuyên bố miễn trừ trách nhiệm: Thông tin trên trang này có thể được lấy từ bên thứ ba và không nhất thiết phản ánh quan điểm hoặc ý kiến của KuCoin. Nội dung này chỉ được cung cấp cho mục đích thông tin chung, không có bất kỳ đại diện hay bảo đảm nào dưới bất kỳ hình thức nào và cũng không được hiểu là lời khuyên tài chính hay đầu tư. KuCoin sẽ không chịu trách nhiệm về bất kỳ sai sót hoặc thiếu sót nào hoặc về bất kỳ kết quả nào phát sinh từ việc sử dụng thông tin này. Việc đầu tư vào tài sản kỹ thuật số có thể tiềm ẩn nhiều rủi ro. Vui lòng đánh giá cẩn thận rủi ro của sản phẩm và khả năng chấp nhận rủi ro của bạn dựa trên hoàn cảnh tài chính của chính bạn. Để biết thêm thông tin, vui lòng tham khảo Điều khoản sử dụngTiết lộ rủi ro của chúng tôi.