Tiêu đề ban đầu: Dây Đai Mảnh Mà Đa Tài Năng
Tác giả ban đầu: Garry Tan
Dịch thuật: Peggy, BlockBeats

Chú thích biên tập: Khi "mô hình mạnh mẽ hơn" trở thành câu trả lời mặc định của ngành, bài viết này đưa ra một quan điểm khác: Điều thực sự tạo ra khoảng cách năng suất 10 lần, 100 lần hoặc thậm chí 1000 lần không phải là mô hình chính nó, mà là toàn bộ hệ thống thiết kế xung quanh mô hình.

Tác giả bài viết này là Garry Tan, hiện đang là Chủ tịch kiêm CEO của Y Combinator, lâu nay đã chuyên sâu trong sinh thái AI và khởi nghiệp sớm. Anh đã đưa ra khung "kỹ năng mập + dây đai mảnh mà" để phân tích ứng dụng AI thành các thành phần chính như kỹ năng, framework chạy, định tuyến ngữ cảnh, phân công nhiệm vụ và nén kiến thức.

Trong hệ thống này, mô hình không còn là toàn bộ khả năng, mà chỉ là một bộ phận thực thi trong hệ thống; thực sự quyết định chất lượng đầu ra là cách bạn tổ chức ngữ cảnh, ổn định quy trình và làm thế nào để phân định ranh giới giữa "phán đoán" và "tính toán".

Hơn nữa, phương pháp này không chỉ dừng lại ở mức khái niệm mà đã được kiểm chứng trong các tình huống thực tế: Đối diện với hàng nghìn nhiệm vụ xử lý dữ liệu và kết hợp từ khóa của các nhà khởi nghiệp, hệ thống thông qua chu trình "đọc - tóm lược - phán đoán - ghi ngược lại", đã đạt được khả năng gần như của một nhà phân tích con người và tiếp tục tối ưu hóa tự động mà không cần viết lại mã. Hệ thống "học tập" này đã biến AI từ một công cụ một lần thành cơ sở hạ tầng có hiệu quả cộng hưởng.

Do đó, lời nhắc chính của bài viết trở nên rõ ràng: Trong kỷ nguyên AI, khoảng cách năng suất không còn phụ thuộc vào việc bạn có sử dụng mô hình tiên tiến nhất hay không, mà là việc bạn đã xây dựng một hệ thống có khả năng tích luỹ liên tục, tự tiến hóa.

Dưới đây là bản gốc của bài viết:

Steve Yegge nói rằng người sử dụng AI để lập trình đại lý, "Năng suất của họ so với kỹ sư chỉ sử dụng Con trỏ và công cụ trò chuyện để viết mã là 10 lần đến 100 lần, xấp xỉ 1000 lần so với kỹ sư của Google vào năm 2005."

Chú thích: Steve Yegge là một kỹ sư phần mềm, blogger công nghệ và phê bình văn hóa kỹ thuật có ảnh hưởng lớn ở Thung lũng Silicon, nổi tiếng với những bài viết công nghệ sắc bén, dài và mang phong cách cá nhân mạnh mẽ. Anh đã làm việc tại Amazon, Google và các công ty khác nhau; sau đó tham gia Salesforce, rồi tới các công ty mới nổi và lĩnh vực liên quan đến AI; đồng thời là một trong những người đẩy mạnh dự án Dart từ sớm.

Điều này không phải là sự phóng đại. Tôi đã nhìn thấy bằng mắt mình, và trải qua trực tiếp. Nhưng khi mọi người nghe về khoảng cách như vậy, họ thường đổ lỗi vào hướng sai: mô hình mạnh mẽ hơn, Claude thông minh hơn, nhiều tham số hơn.

Trên thực tế, người có hiệu suất gấp đôi và người có hiệu suất gấp 100 lần đều sử dụng cùng một bộ mô hình. Sự khác biệt không nằm ở "trí tuệ", mà ở "kiến trúc", và kiểu kiến trúc này đơn giản đến mức có thể ghi trên một tờ thẻ.

Harness (Framework Thực Thi) mới chính là sản phẩm.

Vào ngày 31 tháng 3 năm 2026, Anthropic vô tình đã phát hành toàn bộ mã nguồn của Claude Code lên npm - tổng cộng 51.2 nghìn dòng. Tôi đã đọc qua từ đầu đến cuối. Điều này đã xác minh điều tôi luôn nói tại YC (Y Combinator): Bí mật thực sự không nằm trong mô hình, mà ở "lớp bọc mô hình đó".

Ngữ cảnh kho lưu trữ mã nguồn thời gian thực, Bộ nhớ đệm Prompt, Công cụ được thiết kế cho nhiệm vụ cụ thể, Cố gắng nén ngữ cảnh trùng lặp càng nhiều càng tốt, Kiến thức về phiên, ngữ cảnh chạy song song của các đại lý con - những điều này không làm mô hình trở nên thông minh hơn. Nhưng chúng có thể cung cấp "ngữ cảnh đúng" cho mô hình "đúng thời điểm", đồng thời tránh bị ngập trong thông tin không liên quan.

Lớp "bọc" này được gọi là harness (framework thực thi). Và câu hỏi mà tất cả những người xây dựng AI thực sự nên đặt ra là: Điều gì nên đặt vào harness, điều gì nên giữ bên ngoài?

Câu hỏi này thực ra có một câu trả lời cụ thể rất rõ ràng - tôi gọi nó là: harness mỏng, kỹ năng mập.

Năm Định Nghĩa

Chân bottleneck không bao giờ ở trí tuệ của mô hình. Mô hình thực sự đã biết cách suy luận, tổng hợp thông tin, viết mã.

Lý do họ thất bại là vì họ không hiểu dữ liệu của bạn - schema của bạn, quy ước của bạn, dạng bài toán cụ thể của bạn. Và năm định nghĩa dưới đây chính là giải pháp cho vấn đề này.

1. Tệp Kỹ Năng

Tệp kỹ năng là một tài liệu markdown có thể tái sử dụng, dùng để dạy mô hình "làm sao để thực hiện một công việc". Lưu ý, không phải là cho mô hình biết "phải làm gì" - phần đó do người dùng cung cấp. Tệp kỹ năng cung cấp quy trình.

Điểm quan trọng mà hầu hết mọi người bỏ qua là: Tệp kỹ năng thực sự giống như một cuộc gọi phương pháp. Nó có thể nhận tham số. Bạn có thể gọi nó với các tham số khác nhau. Cùng một quy trình, nhưng vì tham số đầu vào khác nhau, nó có thể thể hiện ra khả năng hoàn toàn khác nhau.

Ví dụ, có một kỹ năng gọi là /investigate. Nó bao gồm bảy bước: Xác định Phạm vi dữ liệu, Xây dựng Timeline, Điều chỉnh Diarize cho mỗi tài liệu, Tổng hợp, Lập luận từ cả hai phía, Trích dẫn nguồn. Nó nhận ba tham số: MỤC TIÊU, CÂU HỎI và BỘ DỮ LIỆU.

Nếu bạn chỉ đối tượng này với một nhà khoa học an toàn và 2,1 triệu email điều tra, nó sẽ biến thành một nhà phân tích nghiên cứu y học, đi xác định xem một người báo cáo có bị áp đặt không.

Nếu bạn chỉ đối tượng này với một công ty vỏ và các tài liệu báo cáo từ Ủy ban Bầu cử Liên bang Mỹ (FEC), nó sẽ trở thành một nhà điều tra pháp lý lập luận, đi theo dõi việc đóng góp chính trị hợp tác.

Vẫn là cùng một kỹ năng. Vẫn là cùng bảy bước. Vẫn là cùng một tệp markdown. Mô tả kỹ năng là một quy trình đánh giá, nhưng cái thực sự đưa nó vào thế giới thực, là thông số truyền vào khi gọi hàm.

Điều này không phải là kỹ thuật đúng như mẫu, mà là thiết kế phần mềm: chỉ khác là ở đây chúng ta sử dụng markdown như ngôn ngữ lập trình, và sử dụng tư duy con người như môi trường thực thi. Thực tế, markdown thậm chí còn thích hợp hơn ngôn ngữ mã nguồn cứng cố định, vì nó mô tả quy trình, đánh giá và ngữ cảnh, đây chính là ngôn ngữ mà mô hình hiểu "được" nhất.

2、Harness（Khung Chạy）

Harness, chính là tầng chương trình thúc đẩy LLM chạy. Nó chỉ thực hiện bốn việc: Giúp mô hình chạy trong vòng lặp, Đọc / Viết file của bạn, Quản lý ngữ cảnh và Thực thi ràng buộc bảo mật.

Chỉ vậy thôi. Chỉ là "mỏng" thôi.

Mẫu phản nghịch là: hạt harness, kỹ năng mảnh.

Bạn chắc chắn đã gặp qua điều này: Hơn 40 định nghĩa công cụ, mà chỉ mô tả đã chiếm nửa cửa sổ ngữ cảnh; Một công cụ phục vụ tất cả, chạy MCP mất từ 2 đến 5 giây mỗi lần; hoặc, gói từng endpoint của REST API thành các công cụ riêng lẻ. Kết quả là, lượng mã token tăng gấp ba, độ trễ tăng gấp ba, tỷ lệ thất bại cũng tăng gấp ba.

Phương pháp lý tưởng thực sự, là sử dụng các công cụ được sinh ra cho một mục đích cụ thể, nhanh chóng và có hiệu suất.

Ví dụ một CLI Playwright, mỗi hoạt động trên trình duyệt mất chỉ 100 miligiây; thay vì một Chrome MCP, mất 15 giây để chụp màn hình → tìm → nhấp → chờ → đọc. Thời gian thực hiện của trước kia nhanh hơn 75 lần.

Phần mềm hiện đại không cần phải \"tinh chỉnh đến tận trọng\" nữa. Điều bạn cần phải làm là: chỉ xây dựng những gì thực sự cần thiết và chỉ vậy thôi.

3、Giải quyết (Resolver)

Resolver, về bản chất, chỉ là một bảng định tuyến ngữ cảnh. Khi loại công việc X xuất hiện, tài liệu Y được tải ưu tiên. Kỹ năng cho mô hình \"làm thế nào\"; resolver cho mô hình \"khi nào nên tải cái gì\".

Ví dụ, một nhà phát triển đã thay đổi một lệnh nhất định. Khi không có resolver, anh ta có thể chỉnh sửa xong là phát hành ngay. Khi có resolver, mô hình sẽ trước tiên đọc docs/EVALS.md. Và tài liệu này viết rằng: trước tiên chạy bộ kiểm định, so sánh điểm số trước và sau; nếu độ chính xác giảm hơn 2%, hãy quay lại phiên bản trước và điều tra nguyên nhân. Nhà phát triển này thậm chí không biết đến sự tồn tại của bộ kiểm định. Resolver đã tải ngữ cảnh đúng đắn vào đúng thời điểm.

Claude Code tích hợp sẵn một resolver. Mỗi kỹ năng đều có một trường mô tả, mô hình sẽ tự động phù hợp ý định của người dùng với mô tả của kỹ năng. Bạn hoàn toàn không cần nhớ liệu /ship kỹ năng có tồn tại hay không—mô tả chính là resolver.

Thành thật mà nói: CLAUDE.md của tôi trước đây đã lên tới 20.000 dòng. Tất cả những thói quen kỳ lạ, mọi mẫu mã, mọi bài học kinh nghiệm mà tôi đã gặp phải, tất cả đều được nhồi vào đó. Hoàn toàn ngớ ngẩn. Chất lượng tập trung của mô hình rõ ràng giảm sút. Claude Code thậm chí yêu cầu tôi xóa nó đi.

Giải pháp sửa đổi cuối cùng, có lẽ chỉ có 200 dòng—chỉ giữ lại vài con trỏ tài liệu. Chỉ tải tài liệu cần thiết vào thời điểm quan trọng bằng resolver. Như vậy, tri thức 20.000 dòng vẫn có thể sử dụng linh hoạt, nhưng không làm bẩn bối cảnh.

4、Không rõ với xác định (Latent và Deterministic)

Trong hệ thống của bạn, mỗi bước thuộc về loại này hoặc loại kia. Và việc lẫn lộn hai loại này là lỗi phổ biến nhất trong thiết kế agent.

· Không rõ (Latent space) là địa điểm của sự thông minh. Mô hình ở đây đọc, hiểu, đánh giá, ra quyết định. Đây là nơi xử lý: đánh giá, tổng hợp, nhận diện mẫu.

· Xác định (Deterministic) là nơi của độ tin cậy. Cùng một đầu vào, luôn nhận cùng một đầu ra. Truy vấn SQL, mã lệnh biên dịch, phép toán số học, đều thuộc loại này.

Một LLM có thể giúp bạn sắp xếp chỗ ngồi cho 8 người trong bữa tối, đồng thời xem xét tính cách và mối quan hệ xã hội của mỗi người. Nhưng nếu bạn muốn nó sắp xếp chỗ cho 800 người, nó sẽ một cách nghiêm túc tạo ra một bảng chỗ ngồi "trông có vẻ hợp lý nhưng thực sự hoàn toàn sai lầm". Bởi vì đó không còn là vấn đề mà không gian tiềm năng cần xử lý, mà là một vấn đề xác định đã bị ép vào không gian tiềm latent — vấn đề tối ưu hóa tổ hợp.

Hệ thống tồi nhất luôn đặt công việc ở sai vị trí giữa đường ranh giới này. Hệ thống tốt nhất, sẽ vô cùng lạnh lùng định rõ biên giới đó.

5. Diarization (Tổ chức tài liệu / Hình ảnh chủ đề)

Bước diarization mới thực sự là yếu tố quan trọng đem lại giá trị cho công việc AI hiểu biết thế giới thực.

Ý nghĩa của nó là: mô hình đọc tất cả tài liệu liên quan đến một chủ đề, sau đó tạo ra một hình ảnh cấu trúc hóa. Sử dụng một tờ giấy, tóm tắt lược đồ từ hàng chục đến cả trăm tài liệu thành kết quả.

Điều này không phải là điều mà truy vấn SQL có thể sản sinh. Điều này cũng không phải là điều mà đường ống RAG có thể sản sinh. Mô hình thực sự phải đọc, đồng thời đưa thông tin mâu thuẫn vào tâm trí, chú ý những thay đổi, khi nào xảy ra thay đổi, sau đó tổng hợp thông tin đó thành một thông tin cấu trúc hóa.

Đây chính là sự khác biệt giữa truy vấn cơ sở dữ liệu và báo cáo của nhà phân tích.

Cấu trúc này

Năm khái niệm này có thể kết hợp thành một cấu trúc ba tầng rất đơn giản.

· Tầng cao nhất là Kỹ năng mập mờ (fat skills): Quy trình được viết bằng markdown, chứa đựng đánh giá, phương pháp论 và kiến thức lĩnh vực. 90% giá trị nằm ở tầng này.
· Tầng giữa là bộ giằng chỉ dòng lệnh mỏng manh: Khoảng 200 dòng mã, đầu vào là JSON, đầu ra là văn bản, mặc định chỉ đọc.
· Tầng dưới cùng là hệ thống ứng dụng của bạn: Tra cứu cơ sở dữ liệu, Đọc tài liệu, Tìm kiếm, Dòng thời gian — đây là cơ sở xác định.

Nguyên tắc cốt lõi là có hướng: Đẩy "trí tuệ" càng cao lên tầng kỹ năng càng nhiều; Đẩy "thực hiện" càng thấp xuống công cụ cố định; Đảm bảo bộ giằng chỉ luôn giữ mình mảnh mai.

Kết quả của việc này là: Mỗi khi khả năng của mô hình được nâng cao, tất cả các kỹ năng sẽ tự động mạnh mẽ hơn; trong khi hệ thống xác định ở tầng dưới, luôn giữ vững tính ổn định và đáng tin cậy.

Hệ thống Học

Dưới đây là một ví dụ về hệ thống thực sự mà chúng tôi đang xây dựng tại YC để minh họa cách năm định nghĩa này hoạt động cùng nhau.

Tháng 7 năm 2026, Trung tâm Chase. Trường Startup có 6000 nhà sáng lập tham gia. Mỗi người đều có tài liệu đăng ký cấu trúc, câu trả lời phiên điều tra, transcribe cuộc trò chuyện 1:1 với mentor, và các tín hiệu công khai: bài đăng trên X, lịch sử commit trên GitHub, lịch sử sử dụng code của Claude (có thể thấy tốc độ phát triển của họ).

Cách tiếp cận truyền thống là: từng nhóm dự án 15 người từng cái đọc đơn xếp hồ sơ, đánh giá bằng cảm tính, sau đó cập nhật một bảng tính.

Phương pháp này vẫn hoạt động ở quy mô 200 người, nhưng khi lên đến 6000 người thì hoàn toàn bất lực. Không có con người nào có thể đồng thời chứa được nhiều hình ảnh nhân vật như vậy trong đầu, và nhận ra rằng: AI agent hướng dẫn cơ sở hạ tầng ba ứng cử viên xuất sắc nhất, lưu ý là người sáng lập công cụ phát triển từ Lagos, doanh nhân tuân thủ pháp lý từ Singapore và nhà phát triển công cụ CLI từ Brooklyn — mà họ trong ba cuộc trò chuyện 1:1 khác nhau, mô tả cùng một vấn đề đau khổ hoàn toàn bằng cách diễn đạt khác nhau.

Model có thể thực hiện được. Phương pháp như sau:

Enrichment (Bổ sung Thông tin)

Có một kỹ năng gọi là /enrich-founder, nó sẽ trích xuất từ tất cả nguồn dữ liệu, thực hiện bổ sung thông tin, diarization và đánh dấu sự khác biệt giữa "những gì người sáng lập nói" và "những gì họ thực sự đang làm".

Hệ thống xác định ở cấp độ dưới cung cấp: truy vấn SQL, dữ liệu GitHub, kiểm thử URL Demo, trích xuất tín hiệu xã hội, truy vấn CrustData và những việc khác. Một công việc định kỳ chạy mỗi ngày. 6000 hồ sơ nhà sáng lập luôn được cập nhật mới nhất.

Kết quả diarization có thể nắm bắt thông tin mà tìm kiếm bằng từ khóa hoàn toàn không thể phát hiện:

Nhà sáng lập: Maria Santos Công ty: Contrail (contrail.dev) Tự tường thuật: "Datadog của AI agent" Thực sự đang làm: 80% các commit code tập trung vào mô-đun tính phí → Về bản chất đang xây dựng một công cụ FinOps che phủ một lớp bên ngoài có thể quan sát được

Sự khác biệt giữa "những gì được nói" và "những gì được thực hiện" này cần phải đọc đồng thời lịch sử commit trên GitHub, tài liệu đăng ký và ghi chú cuộc trò chuyện, sau đó tích hợp trong đầu. Không có tìm kiếm độ tương tự nhúng nên làm được điều này, cũng không phải lọc từ khóa. Model phải đọc hoàn toàn, sau đó đưa ra nhận định. (Đây chính là nhiệm vụ nên đặt vào không gian ẩn!)

Phù hợp (Matching)

Đây là nơi mà 「kỹ năng = gọi phương thức」 hiệu quả.

Cùng một kỹ năng phù hợp, được gọi ba lần, có thể tạo ra các chiến lược hoàn toàn khác nhau:

/match-breakout: Xử lý 1200 người, phân cụm theo lĩnh vực, mỗi nhóm 30 người (embedding + phân công xác định)

/match-lunch: Xử lý 600 người, kết hợp ngẫu nhiên qua các lĩnh vực, mỗi bàn 8 người và không lặp lại — LLM tạo chủ đề trước, sau đó thuật toán xác định sắp xếp chỗ ngồi

/match-live: Xử lý người tham gia trực tiếp tại chỗ, dựa trên embedding gần nhất, hoàn thành cặp 1:1 trong 200ms và loại bỏ những người đã gặp trước đó

Và mô hình còn có thể đưa ra nhận định mà các thuật toán phân cụm truyền thống không thể thực hiện:

「Santos và Oram đều thuộc cơ sở hạ tầng AI, nhưng không phải là mối quan hệ đối thủ — Santos thực hiện phân biệt chi phí, Oram thực hiện sắp xếp. Phải đặt trong cùng một nhóm.」
「Kim đã ghi trong đơn ứng tuyển rằng đang phát triển công cụ cho nhà phát triển, nhưng trong cuộc trò chuyện 1:1, anh ấy đề cập đến việc tự động hóa tuân thủ SOC2. Nên phân loại lại vào FinTech / RegTech.」

Việc phân loại lại như vậy không thể bắt được hoàn toàn bởi embedding. Mô hình phải đọc toàn bộ bức tranh.

Vòng học tập (Learning Loop)

Sau khi hoạt động kết thúc, một kỹ năng /improve sẽ đọc kết quả khảo sát NPS, tách biệt nhận xét của những người nói 「tạm được」 — không phải đánh giá tiêu cực, mà là những người nói 「thiếu một chút để tốt hơn」 — và trích xuất mẫu.

Sau đó, nó sẽ đề xuất các quy tắc mới và ghi lại vào kỹ năng phù hợp:

Khi người tham gia nói 「cơ sở hạ tầng AI」, nhưng mã nguồn của họ có hơn 80% là mô-đun tính tiền:
→ Phân loại là FinTech, chứ không phải AI Infra

Khi hai người trong cùng một nhóm đã quen biết:
→ Giảm trọng số phù hợp
Ưu tiên giới thiệu mối quan hệ mới

Các quy tắc này sẽ được ghi lại vào tệp kỹ năng. Chúng sẽ tự động có hiệu lực trong lần chạy tiếp theo. Kỹ năng đang 「tự cải thiện bản thân」. Đánh giá 「tạm được」 chiếm 12% trong sự kiện tháng 7; giảm xuống còn 4% trong sự kiện tiếp theo.

Kỹ năng của tệp học được ý nghĩa của "tốt" là gì, trong khi hệ thống trở nên tốt hơn mà không cần ai viết lại mã.

Mô hình này có thể được di chuyển sang bất kỳ lĩnh vực nào:

Tìm → Đọc → ghi nhận → Đếm → Tổng hợp

Và sau đó: Nghiên cứu → Khảo sát → ghi nhận → Viết lại kỹ năng

Nếu bạn hỏi vòng lặp có giá trị nhất vào năm 2026 là gì, đó chính là tập này. Nó có thể áp dụng vào hầu hết các tình huống làm việc có liên quan đến kiến thức.

Kỹ năng là sự nâng cấp vĩnh viễn

Gần đây, tôi đã đăng một hướng dẫn cho OpenClaw trên X, hồi đáp lớn hơn so với dự kiến:

Hướng dẫn: Bạn không được phép làm công việc một lần. Nếu tôi yêu cầu bạn thực hiện một công việc mà sẽ lặp lại trong tương lai, bạn phải: Trước hết, thủ công xử lý 3 đến 10 mẫu, cho tôi xem kết quả; Nếu tôi chấp nhận, hãy ghi nó xuống thành một tệp kỹ năng; Nếu nó cần chạy tự động, hãy thêm vào công việc định kỳ. Tiêu chí đánh giá là: Nếu tôi cần hỏi lần thứ hai, điều đó có nghĩa bạn thất bại.

Nội dung này đã nhận được hàng nghìn lượt thích và hơn hai nghìn lượt lưu trữ. Nhiều người nghĩ rằng đó là kỹ thuật của kỹ năng gợi ý.

Thực ra không phải, đó chính là bộ khung của tập này đã nói. Mỗi kỹ năng bạn viết ra, đều là sự nâng cấp vĩnh viễn đối với hệ thống. Nó sẽ không suy giảm, không quên. Nó sẽ tự động chạy vào lúc ba giờ sáng. Và khi thế hệ tiếp theo của mô hình được phát hành, tất cả các kỹ năng sẽ mạnh mẽ ngay tức thì—khả năng phán đoán của phần ẩn tăng lên, trong khi phần xác định vẫn ổn định và đáng tin cậy.

Đó chính là nguồn gốc của hiệu quả 100 lần mà Yegge đã nói.

Không phải là mô hình thông minh hơn, mà là: Kỹ năng dày, khung mảnh (Thin Harness, Fat Skills), và sự kỷ luật biến mọi thứ thành khả năng.

Hệ thống sẽ tăng trưởng theo lãi kép. Xây dựng một lần, chạy dài hạn.

[Liên kết bài gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia