Cha đẻ Claude Code: Đừng kìm hãm AI, hãy để chúng tự do phát triển

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">

2026-07-30 16:57:55 Nguồn: QbitAI

Cha đẻ của Claude Code: Các mô hình ngôn ngữ lớn là thực thể hữu cơ, trong phát triển sản phẩm AI, "khơi thông" quan trọng hơn "ngăn chặn"

Cứ mỗi sáu tháng, hãy xóa Claude.md của bạn, xóa các skills và xóa các hooks của bạn đi.

Đây là lời khuyên mà Boris Cherny – cha đẻ của Claude Code – dành cho những người sử dụng sản phẩm.

Trong video phỏng vấn mới được YC đăng tải vào ngày 28 tháng 7 với tiêu đề "Boris Cherny: We Cut 80% of Claude Code’s Prompt", Boris đã nhiệt tình kêu gọi tất cả những người làm sản phẩm AI hãy dũng cảm nhấn nút xóa trên chính sản phẩm mới của mình, mạnh dạn loại bỏ các system prompt, công cụ và mã nguồn harness của hệ thống.

"Bạn nên xóa sạch toàn bộ system prompt, sau đó thêm lại từng dòng một để xem mỗi dòng thực sự có ảnh hưởng như thế nào."

Khái niệm đằng sau quan điểm này là "ablation study" (nghiên cứu cắt bỏ), một khái niệm xuyên suốt bài phỏng vấn mới nhất của Boris Cherny, nhằm mục đích kiểm soát các điều kiện khác không đổi để loại bỏ, thay thế hoặc tắt một mô-đun, từ đó so sánh sự thay đổi về hiệu suất, độ ổn định, hiệu quả hoặc chi phí.

Trong bài phỏng vấn, Boris không giấu nổi niềm tự hào khi khẳng định: Thực tế đối với Opus 5, chúng tôi thực sự khuyên mọi người hãy thử xóa sạch những thứ này đi, vì mô hình không còn cần đến chúng nữa.

Mặc dù có những làn sóng tranh cãi gần đây... người dùng cũng có thể tuyên bố rằng: "Thực tế đối với Claude, tôi thực sự khuyên bạn nên xóa nó đi, vì chúng ta không còn cần đến nó nữa." (x)

Ngoài việc "mạnh dạn xóa bỏ", Boris còn tiết lộ thêm nhiều suy nghĩ giá trị về thiết kế sản phẩm, cách sử dụng mô hình và học lập trình trong bài phỏng vấn –

Quan điểm trong bài viết này được trích từ video phỏng vấn, với các trọng tâm sau: 1. Chiến lược lặp sản phẩm của Boris: Ít dự đoán, nhiều thử nghiệm; 2. "Product Overhang" (Sự dư thừa sản phẩm): Trong cùng một thời điểm, năng lực mô hình luôn vượt quá giới hạn của sản phẩm; 3. "Unhobbling" (Giải phóng): Để mô hình thực hiện các tác vụ khó hơn và làm việc độc lập trong thời gian dài hơn; 4. Những người dùng Claude hàng đầu sử dụng AI như thế nào?; 5. 3 lời khuyên cho người học lập trình.

"Mô hình là một thực thể sống, nó có tính cách riêng của mình."

"Ngày nay, mã nguồn trong harness của Claude Code gần như chỉ còn lại các phần về bảo mật, quyền hạn và phân tích tĩnh."

Ngày 24 tháng 7, Anthropic đã công bố các quy tắc mới nhất về kỹ thuật ngữ cảnh (context engineering) cho Claude 5. Trong đó, đối với các mô hình mới như Opus 5 và Fable 5, system prompt của Claude Code đã được tinh giản đáng kể, loại bỏ hơn 80% các chỉ dẫn cũ.

Chi tiết có thể tham khảo bài viết của QbitAI: "Claude Code cắt giảm 80% prompt, Opus 5 phản đòn thêm lại".

Trước sự thay đổi này, Boris đã chia sẻ chiến lược lặp sản phẩm của mình: Bạn đừng cố đoán xem mô hình cần chỉ dẫn gì, vì bạn hoàn toàn không thể đoán đúng. Điều bạn có thể làm là xóa từng dòng, thử nghiệm, rồi tìm ra những điểm mà mô hình liên tục bị mắc kẹt.

"Bạn phải coi mô hình như một thực thể sống, một thứ gì đó hữu cơ hơn. Hành vi của mỗi thế hệ mô hình đều khác nhau, tính cách cũng hơi khác biệt, bạn phải dành thời gian để tìm hiểu nó, rồi từ đó điều chỉnh harness cho phù hợp."

Vì vậy, đối với Boris, điều này thiên về tính "kinh nghiệm" hơn và cần được tiếp cận một cách khoa học: thử nghiệm không định kiến, xem kết quả, lặp lại và tiếp tục.

Và trong một thế giới không ngừng thay đổi này, Eval (đánh giá) cũng chưa chắc đã sử dụng ổn định. Mặc dù nó bền bỉ hơn harness và prompt, nhưng hiện tại mô hình tiến hóa quá nhanh, nhiều khi một bộ đánh giá sẽ sớm đạt điểm tối đa. Do đó, cần quan sát xem mô hình đang thực sự chật vật ở đâu, rồi từ đó thiết kế các Eval mới.

Một tư duy: Product Overhang, Unhobbling

Trong bài phỏng vấn, Boris đã chia sẻ một khái niệm gọi là "Product Overhang", ông cho rằng đây là một cách tư duy rất hữu ích cho việc làm sản phẩm của mình.

Overhang, nghĩa là gì? Là sự dư thừa, phần nhô ra.

Các mô hình ngôn ngữ lớn nhảy vọt với tốc độ không liên tục, trong khi việc tích hợp sản phẩm lại tiến triển theo nhịp độ tăng dần đều. Điều này dẫn đến việc năng lực mà mô hình sở hữu luôn vượt ra ngoài giới hạn mà sản phẩm hiện tại có thể giải phóng.

Boris đưa ra một ví dụ: Cuối năm 2024, khi Sonnet 3.5 vừa ra mắt, mô hình này đã có thể viết mã cho toàn bộ tệp tin cùng một lúc. Nhưng các sản phẩm lập trình thời bấy giờ như Copilot hay các phiên bản đầu của Cursor vẫn chỉ đang làm những việc nhỏ như gợi ý hoàn thiện mã.

Claude Code với quyền truy cập terminal đầy đủ đã phần nào bù đắp được khoảng cách này. Đây cũng là khái niệm thứ hai mà Boris đề xuất: "Unhobbling" – giải phóng, tháo bỏ các hạn chế.

Ông chia sẻ trường hợp nội bộ tại Anthropic: Có người đã thử kết nối OpenCV (thư viện thị giác máy tính mã nguồn mở lớn nhất thế giới) vào Opus 5, kết quả là mô hình có thể tự vẽ chân dung nhân vật, động vật và phong cảnh, trong khi trước đó họ chưa từng huấn luyện mô hình vẽ tranh.

Đây chính là "model elicitation" (khơi gợi mô hình), không cần thay đổi trọng số của mô hình mà thông qua thiết kế prompt, ngữ cảnh, công cụ hoặc hình thái sản phẩm để khiến mô hình thể hiện ra những năng lực mà nó vốn đã có nhưng trước đó chưa được kích hoạt.

Mặc dù ở đây vẫn còn tồn tại những nghi vấn: Làm sao để quy kết? Liệu có phải mô hình được khơi gợi những năng lực vốn có, hay mô hình đã học được kỹ năng mới nhờ thiết kế "giàn giáo" (scaffolding)?

Tuy nhiên, điều này có lẽ không quan trọng. Dù thế nào đi nữa, Boris không hề nghi ngờ rằng ở đây đang tồn tại những cơ hội kinh doanh khổng lồ:

Tôi không nói rằng tất cả các công ty khởi nghiệp đều có thể nắm bắt được. Nhưng tôi biết có những người đang suy nghĩ về các vấn đề này, ở đây thực sự có cơ hội lớn để khơi gợi từ mô hình những hành vi đáng kinh ngạc, thú vị và có giá trị thương mại.

Vì vậy, Boris đã đề xuất ba phương pháp "giải phóng" mô hình của riêng mình.

Thứ nhất, hãy giao cho mô hình những tác vụ khó hơn bạn tưởng tượng. Mô tả rõ mục tiêu, giới hạn và điều kiện thoát, sau đó hãy buông tay để nó tự làm.

Thứ hai, hãy thực hiện nhiều thử nghiệm hơn. Cho phép mô hình thực hiện một số thử nghiệm không có mục đích thương mại rõ ràng nhưng thú vị, "hãy cho phép bản thân được chơi đùa với mô hình và làm những việc sáng tạo".

Thứ ba, hãy để mô hình tự xác thực kết quả. Trọng tâm ngày nay không còn là "prompt engineering" nữa, vấn đề nằm ở chỗ: "Khi bạn giao cho Claude một tác vụ cực kỳ khó, làm thế nào để nó tự xác thực công việc mình làm ngay trong quá trình thực hiện?"

Boris cho rằng điểm thứ ba có lẽ là điều mà mọi người hiện nay đang làm chưa được như ý nhất. Bởi vì nếu mô hình không thể tự xác thực tác vụ, nó sẽ không thể vận hành độc lập trong thời gian dài.