Cứ sáu tháng một lần, hãy xóa file Claude.md của bạn, xóa kỹ năng của bạn, xóa các hooks của bạn.
Đây là lời khuyên từ 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 phát hành ngày 28/7 của YC mang tên “Boris Cherny: Chúng tôi đã cắt 80% Prompt của Claude Code”, Boris nhiệt thành kêu gọi tất cả những người làm sản phẩm AI nên dũng cảm nhấn nút xóa với sản phẩm mới của mình, quyết liệt xóa bỏ prompt hệ thống, công cụ, và mã harness.
△
“Bạn nên xóa toàn bộ prompt hệ thống, rồi từng dòng một thêm lại, xem mỗi dòng thực sự có ảnh hưởng gì.”
Khái niệm đằng sau quan điểm này là nghiên cứu cắt bỏ (ablation study), một khái niệm xuyên suốt cuộc phỏng vấn mới nhất của Boris Cherny, nhằm mục đích, trong điều kiện giữ các yếu tố khác không đổi, loại bỏ, thay thế hoặc tắt một module để so sánh sự thay đổi về hiệu suất, tính ổn định, hiệu quả hoặc chi phí.
Trong cuộc phỏng vấn, Boris tự hào tuyên bố: Thực tế đối với Opus 5, chúng tôi chân thành khuyên mọi người thử xóa hết những thứ này đi, vì mô hình đã không cần nó nữa.
Mặc dù những tranh cãi gần đây...... người dùng cũng có thể tuyên bố, “Thực tế đối với Claude, chân thành khuyên nên xóa nó đi, vì chúng tôi đã không cần nó nữa.” (x)
Ngoài việc “dũng cảm xóa bỏ”, Boris trong cuộc phỏng vấn còn tiết lộ thêm nhiều suy nghĩ có giá trị của mình về thiết kế sản phẩm, sử dụng mô hình và học lập trình –
Các quan điểm trong bài viết này xuất phát từ video phỏng vấn, trọng điểm đọc như sau: 1. Chiến lược lặp sản phẩm của Boris: Bớt dự đoán, nhiều thử nghiệm hơn 2. “Phần thừa sản phẩm”: Trong cùng một thời kỳ, năng lực mô hình luôn vượt quá biên giới sản phẩm 3. “Cởi trói”: Để mô hình làm nhiệm vụ khó hơn, làm việc độc lập lâu hơn 4. 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 sinh vật sống, nó có tính cách riêng”
“Ngày nay, mã trong harness của Claude Code gần như chỉ còn lại phần bảo mật, quyền hạn và phân tích tĩnh.”
Ngày 24/7, Anthropic đã phát hành quy tắc mới nhất về kỹ thuật ngữ cảnh của Claude 5, trong đó đối với các mô hình mới như Opus 5, Fable 5, system prompt của Claude Code đã được tinh giản đáng kể, xóa bỏ hơn 80% chỉ dẫn nguyên bản.
Cụ thể có thể tham khảo bài viết của Quantum Bit “Claude Code xóa điên cuồng 80% prompt, Opus 5 lật lại thêm vào”.
Liên quan đến sự thay đổi này, Boris trong cuộc phỏng vấn đã chia sẻ chiến lược lặp sản phẩm của mình: Bạn đừng đoán mô hình cần chỉ dẫn gì, vì bạn căn bản không đ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 chỗ mà mô hình liên tục bị kẹt.
“Bạn phải coi mô hình như một sinh vật 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 hơi khác một chút, bạn phải dành thời gian để hiểu nó, rồi điều chỉnh harness theo đó.”
△
Vì vậy đối với Boris, điều này thiên về “kinh nghiệm” hơn, cần được đối xử một cách khoa học: Thử nghiệm không có định kiến trước, xem xét kết quả, lặp lại, lặp lại.
Và trong một thế giới liên tục đập đi xây lại như vậy, Eval cũng chưa chắc có thể sử dụng ổn định. Mặc dù nó thực sự bền hơn harness và prompt, nhưng hiện nay mô hình tiến hóa quá nhanh, rất nhiều khi một bộ đánh giá sẽ nhanh chóng bị đánh giá đạt điểm tối đa. Vì vậy cần quan sát xem mô hình thực sự đang vật lộn ở đâu, rồi thiết kế Eval mới.
Một cách tư duy: Phần thừa, Cởi trói
Trong cuộc 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 suy nghĩ rất hữu ích cho việc làm sản phẩm của mình.
Overhang, nghĩa là gì? Phần thừa.
Mô hình lớn nhảy vọt với tốc độ không liên tục, trong khi tích hợp sản phẩm lại tiến triển theo nhịp độ tăng dần liên tục. Điều này dẫn đến năng lực mà mô hình sở hữu luôn vượt quá biên giới mà sản phẩm hiện có 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 toàn bộ mã file một lần. Nhưng các sản phẩm lập trình thời đó như Copilot, Cursor phiên bản đầu vẫn đang làm những việc nhỏ như bổ sung mã.
Claude Code với quyền truy cập terminal đầy đủ đã phần nào lấp đầy khoảng cách này. Đây cũng là khái niệm thứ hai Boris đề xuất “Unhobbling”, cởi trói, gỡ bỏ hạn chế.
△
Ông chia sẻ ví dụ nội bộ tại Anthropic: Có người thử kết nối Opus 5 với OpenCV (thư viện thị giác máy tính nguồn mở lớn nhất thế giới), kết quả phát hiện mô hình có thể tự vẽ chân dung, phong cảnh động vật, mà trước đó họ chưa từng huấn luyện mô hình để vẽ.
Đây chính là “khơi gợi mô hình” (model elicitation), trong điều kiện không thay đổi trọng số mô hình, thông qua thiết kế prompt, ngữ cảnh, công cụ hoặc hình thái sản phẩm, để mô hình biểu hiện những năng lực vốn đã có nhưng trước đó chưa được gọi ra.
Mặc dù ở đây có lẽ vẫn tồn tại nghi vấn: Làm sao quy nguyên nhân? Rốt cuộc là mô hình được khơi gợi ra năng lực vốn có, hay là mô hình vì thiết kế “giàn giáo” mà học được kỹ năng mới?
Nhưng điều này có lẽ không quan trọng, dù thế nào đi nữa, Boris hoàn toàn không nghi ngờ rằng ở đây tồn tại cơ hội thương mại khổng lồ:
Tôi không nói tất cả công ty khởi nghiệp đều có thể nắm bắt được. Nhưng tôi biết có người đang suy nghĩ những vấn đề này, ở đây thực sự có cơ hội khổng lồ, có thể khơi gợi từ mô hình những hành vi kinh ngạc, thú vị, và có giá trị thương mại.
Vì vậy, Boris đề xuất ba phương pháp “cởi trói” mô hình của chính ông.
Thứ nhất, giao cho mô hình nhiệm vụ khó hơn bạn tưởng tượng. Mô tả rõ mục tiêu, biên giới và điều kiện dừng, rồi buông tay.
Thứ hai, làm nhiều thí nghiệm hơn. Cho phép mô hình thử những việc không có mục đích thương mại rõ ràng nhưng vui vẻ, “tự cho mình tự do để chơi với mô hình, để làm những việc sáng tạo”.
Thứ ba, để mô hình tự xác minh kết quả. Trọng tâm ngày nay đã không còn là “prompt engineering” nữa, vấn đề là, “khi bạn giao cho Claude một nhiệm vụ rất khó khăn, làm sao để nó trong quá trình đó đi xác minh công việc mình làm?”
Boris cho rằng điểm thứ ba có lẽ là việc mọi người hiện nay làm không được tốt nhất. Bởi vì nếu mô hình không thể tự xác minh nhiệm vụ, nó sẽ không thể vận hành độc lập trong thời gian dài.
△
Ví dụ của chính ông có lẽ sẽ gợi cảm hứng cho mọi người:
Boris: “Được rồi, tôi muốn bạn làm – viết lại ứng dụng Electron thành Swift. Tôi muốn bạn chạy ứng dụng Electron trong máy ảo Mac, chụp màn hình, rồi so sánh từng pixel, so với phiên bản Swift, chưa xong thì đừng dừng.” Người dẫn: Đây là prompt của bạn? Boris: Đây là prompt của tôi. Người dẫn: Chạy bao lâu rồi? Boris: Vẫn đang chạy. Người dẫn: Bắt đầu từ khi nào? Boris: Đã chạy hơn hai tuần rồi, khoảng 14, 15 ngày… Claude còn quyết định làm livestream, việc nó làm là xây dựng một kênh Slack nội bộ, rồi cứ vài phút gửi một ảnh chụp tiến độ.
Lời khuyên thực tế của Boris cho người dùng AI và doanh nhân khởi nghiệp
Ở phần cuối cuộc phỏng vấn, người dẫn đặt câu hỏi:
Vậy, Boris, làm thế nào chúng tôi mới có thể sử dụng Claude tốt như ông?
Boris cho biết, quan trọng nhất là đừng nghe những người nổi tiếng trên LinkedIn nói, đừng lướt Twitter.
Về việc sử dụng AI, “mọi người đều đang tìm kiếm thứ ‘mánh khóe kỳ lạ’. Nhưng căn bản không tồn tại thứ đó. Không có thứ đó.”
Ông khuyên mọi người đối xử với mô hình theo cách kinh nghiệm chủ nghĩa, quên đi kinh nghiệm với mô hình cũ và lý thuyết khoa học máy tính học trên lớp, trực tiếp quan sát xem mô hình bị kẹt ở đâu, rồi điều chỉnh có mục tiêu.
Vì vậy nó đã không còn là một môn khoa học lý thuyết nữa, nó đã trở thành một môn khoa học kinh nghiệm. Tôi nghĩ những người đặc biệt giỏi trong việc buông bỏ tiên nghiệm của mình, buông bỏ những suy nghĩ “trước đây không được”, sẵn sàng thử lại một lần nữa – sẽ rất rất thành công.
Quan trọng hơn là giữ một tâm thái, đó là buông bỏ “tính kiểm soát” của mình đối với mô hình, đối xử với mô hình như đồng nghiệp, không chỉ định quá mức, không đưa ra yêu cầu quá cụ thể, không cố gắng để mô hình hoàn toàn làm nhiệm vụ theo cách bạn sẽ làm. Bởi vì “mô hình không hoạt động như vậy”.
Đối với những người vẫn đang học lập trình, Boris kêu gọi đừng chỉ học lý thuyết khoa học máy tính thuần túy, hãy học cách ứng dụng. Ví dụ, động lực ban đầu của chính ông học lập trình cũng là để gian lận trong kỳ thi toán.
Thường điều này liên quan đến khởi nghiệp, liên quan đến làm sản phẩm, liên quan đến bồi dưỡng cảm giác thiết kế, cảm giác kinh doanh của chính bạn, học cách làm khoa học dữ liệu, học cách trò chuyện với người dùng… Khi bạn kết hợp chúng với khoa học máy tính, kỹ thuật, thì mới trở nên thực sự có giá trị.
Tóm lại, “trước hết làm thứ mình muốn, rồi nâng cấp làm thứ người khác muốn”.
Bài viết này đến từ tài khoản WeChat công cộng “Quantum Bit” (ID: QbitAI), tác giả: Quan tâm công nghệ tiên phong
