Tiêu đề gốc: Thin Harness, Fat Skills
Tác giả gốc: Garry Tan
Biên dịch: Peggy, BlockBeats

Biên giả chú ý: Khi 'mô hình mạnh hơn' trở thành câu trả lời mặc định trong ngành, bài viết này đưa ra một phán đoán khác: điều thực sự tạo ra sự khác biệt về năng suất gấp 10, gấp 100 thậm chí gấp 1000 không phải là chính mô hình, mà là một bộ thiết kế hệ thống hoàn chỉnh xung quanh mô hình.

Tác giả bài viết này là Garry Tan, hiện là Tổng thống và CEO của Y Combinator, đã lâu tập trung vào AI và hệ sinh thái khởi nghiệp sớm. Ông đã đề xuất khung 'fat skills + thin harness', phân tích ứng dụng AI thành các thành phần chính như kỹ năng, khung hoạt động, đị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 đơn vị thực thi trong hệ thống; điều thực sự quyết định chất lượng đầu ra là cách bạn tổ chức bối cảnh, tinh chỉnh quy trình và xác định rõ ràng ranh giới giữa "phán đoán" và "tính toán".

Quan trọng hơn, phương pháp này không chỉ mang tính lý thuyết mà còn đã được kiểm chứng trong các tình huống thực tế: khi đối mặt với các nhiệm vụ xử lý và đối sánh dữ liệu từ hàng ngàn doanh nhân, hệ thống đạt được khả năng phân tích gần như con người thông qua chu trình "đọc-sắp xếp-đánh giá-ghi lại" và liên tục tự tối ưu hóa 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ụ đơn lẻ thành một cơ sở hạ tầng với hiệu quả tích lũy.

Như vậy, thông điệp cốt lõi của bài viết trở nên rõ ràng: trong kỷ nguyên AI, khoảng cách về hiệu quả không còn phụ thuộc vào việc bạn có sử dụng các mô hình tiên tiến nhất hay không, mà phụ thuộc vào việc bạn đã xây dựng được một hệ thống có khả năng liên tục tích lũy năng lực và tự động phát triển hay chưa.

Sau đây là văn bản gốc:

Steve Yegge cho biết những người sử dụng các tác nhân lập trình AI "hiệu quả hơn từ 10 đến 100 lần so với các kỹ sư chỉ sử dụng Cursor và các công cụ trò chuyện để viết mã, và hiệu quả hơn khoảng 1.000 lần so với các kỹ sư của Google năm 2005."

Lưu ý: Steve Yegge là một kỹ sư phần mềm có tầm ảnh hưởng, blogger công nghệ và nhà bình luận về văn hóa kỹ thuật tại Thung lũng Silicon, nổi tiếng với những bài viết kỹ thuật sắc bén, dài dòng và mang đậm tính cá nhân. Ông từng là kỹ sư cấp cao tại các công ty như Amazon và Google; sau đó gia nhập Salesforce; và tiếp tục làm việc tại các công ty khởi nghiệp và trong các lĩnh vực liên quan đến trí tuệ nhân tạo; ông cũng là một trong những người tiên phong ủng hộ dự án Dart.

Đây không phải là lời nói quá. Tôi đã tận mắt chứng kiến ​​và trải nghiệm điều đó. Nhưng khi mọi người nghe về khoảng cách này, họ thường quy cho những nguyên nhân sai lầm: một mô hình mạnh hơn, một Claude thông minh hơn, nhiều thông số hơn.

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

Harness (khung thời gian chạy) chính là sản phẩm đó.

Vào ngày 31 tháng 3 năm 2026, Anthropic vô tình phát tán toàn bộ mã nguồn của Claude Code lên npm—tổng cộng 512.000 dòng. Tôi đã đọc hết. Điều này xác nhận những gì tôi đã nói tại Y Combinator: bí mật thực sự không nằm ở mô hình, mà nằm ở "lớp bao bọc mô hình".

Ngữ cảnh kho mã thời gian thực, bộ nhớ đệm nhắc lệnh, các công cụ dành riêng cho tác vụ, giảm thiểu ngữ cảnh dư thừa, bộ nhớ phiên có cấu trúc và các tác nhân con chạy song song—những điều này không làm cho mô hình thông minh hơn. Nhưng chúng cung cấp cho mô hình "ngữ cảnh phù hợp" vào "đúng thời điểm", đồng thời ngăn chặn nó bị quá tải bởi thông tin không liên quan.

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

Câu hỏi này thực ra có một câu trả lời rất cụ thể — mà tôi gọi là: dây đai mỏng, kỹ năng dày.

Năm định nghĩa

Điểm nghẽn chưa bao giờ nằm ​​ở trí thông minh của mô hình. Mô hình luôn biết cách suy luận, tổng hợp thông tin và viết mã.

Họ thất bại vì họ không hiểu dữ liệu của bạn—lược đồ, quy ước và hình dạng cụ thể của vấn đề bạn đang gặp phải. Năm định nghĩa sau đây được thiết kế chính xác để giải quyết vấn đề này.

1. Hồ sơ kỹ năng

Tài liệu kỹ năng là một tài liệu Markdown có thể tái sử dụng, hướng dẫn mô hình "cách làm một việc gì đó". Lưu ý rằng nó không hướng dẫn "phải làm gì" - điều đó do người dùng cung cấp. Tài liệu kỹ năng cung cấp quy trình.

Điểm quan trọng mà hầu hết mọi người thường bỏ qua là tệp kỹ năng về cơ bản giống như một lời gọi phương thức. Nó có thể chấp nhận các 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 có thể thể hiện các khả năng khác nhau đáng kể tùy thuộc vào các tham số được truyền vào.

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 dòng thời gian, ghi nhật ký từng tài liệu, tổng hợp và tóm tắt, lập luận từ cả hai phía và trích dẫn nguồn. Nó chấp nhận ba tham số: `TARGET`, `QUESTION` và `DATASET`.

Nếu bạn giao việc này cho một nhà khoa học an ninh và 2,1 triệu email pháp y, nó sẽ trở thành một nhà phân tích nghiên cứu y học đang xác định xem liệu người tố giác có bị đàn áp hay không.

Nếu bạn hướng nó đến một công ty ma và các hồ sơ gửi lên Ủy ban Bầu cử Liên bang (FEC), nó sẽ trở thành một công cụ điều tra pháp y theo dõi các khoản quyên góp chính trị được phối hợp.

Đó vẫn là cùng một kỹ năng. Cùng bảy bước. Cùng một tệp markdown. Mô tả kỹ năng là một quy trình ra quyết định, nhưng điều thực sự biến nó thành hiện thực chính là các tham số được truyền vào trong quá trình gọi hàm.

Đây không phải là kỹ thuật lập trình tức thời, mà là thiết kế phần mềm: chỉ khác là ở đây chúng ta sử dụng Markdown làm ngôn ngữ lập trình và phán đoán của con người làm môi trường thực thi. Trên thực tế, Markdown thậm chí còn phù hợp hơn để đóng gói các khả năng so với mã nguồn cứng nhắc vì nó mô tả các quy trình, phán đoán và ngữ cảnh—chính xác là những ngôn ngữ mà mô hình "hiểu" tốt nhất.

2. Harness (Khung thời gian chạy)

Harness là lớp điều khiển giúp LLM hoạt động. Nó chỉ thực hiện bốn việc: chạy mô hình trong một vòng lặp, đọc và ghi các tập tin của bạn, quản lý ngữ cảnh và thực thi các ràng buộc bảo mật.

Vậy thôi. Đây chính là ý nghĩa của từ "mỏng".

Ngược lại là: trang bị cồng kềnh, kỹ năng kém.

Chắc hẳn bạn đã từng thấy những trường hợp tương tự: hơn 40 định nghĩa công cụ, chỉ riêng phần mô tả đã chiếm đến nửa cửa sổ ngữ cảnh; một công cụ "thần thánh" toàn năng mất từ ​​2 đến 5 giây để thực hiện một chu trình khứ hồi trong MCP; hoặc việc gói gọn mỗi điểm cuối của API REST vào một công cụ riêng biệt. Kết quả là mức sử dụng token tăng gấp ba, độ trễ tăng gấp ba và tỷ lệ lỗi tăng gấp ba.

Cách tiếp cận lý tưởng nhất là sử dụng các công cụ được thiết kế cho một mục đích cụ thể, có tốc độ nhanh và chức năng hạn chế.

Ví dụ, một Playwright CLI chỉ mất 100 mili giây cho mỗi thao tác trên trình duyệt, trong khi Chrome MCP mất 15 giây để thực hiện thao tác chụp màn hình → tìm kiếm → nhấp chuột → chờ → đọc. Như vậy, Playwright nhanh hơn 75 lần.

Phần mềm hiện đại không còn cần phải "được trau chuốt quá mức đến nỗi trở nên cồng kềnh". Điều bạn nên làm là: chỉ xây dựng những gì bạn thực sự cần, và không hơn.

3. Bộ giải quyết

Về cơ bản, resolver là một bảng định tuyến ngữ cảnh. Khi loại tác vụ X xảy ra, tài liệu Y sẽ được tải trước. Kỹ năng (Skills) cho mô hình biết "cách thực hiện"; resolver cho mô hình biết "khi nào cần tải cái gì".

Ví dụ, một nhà phát triển sửa đổi một lời nhắc. Nếu không có bộ giải quyết (resolver), họ có thể phát hành bản cập nhật ngay sau khi thực hiện các thay đổi. Với bộ giải quyết, mô hình trước tiên sẽ đọc tài liệu docs/EVALS.md. Tài liệu này nêu rõ: trước tiên hãy chạy bộ kiểm thử đánh giá và so sánh điểm số trước và sau; nếu độ chính xác giảm hơn 2%, hãy hoàn tác và điều tra nguyên nhân. Nhà phát triển này thậm chí có thể không biết về bộ kiểm thử đánh giá. Bộ giải quyết, vào đúng thời điểm, sẽ tải ngữ cảnh chính xác.

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

Thành thật mà nói, tập tin CLAUDE.md cũ của tôi dài đến tận 20.000 dòng. Nó nhồi nhét tất cả những thói quen, những khuôn mẫu và tất cả những bài học tôi đã học được. Nó hoàn toàn vô lý. Chất lượng chú ý của mô hình giảm sút rõ rệt. Tôi thậm chí còn quyết định xóa bỏ hoàn toàn "Mã Claude".

Giải pháp cuối cùng chỉ bao gồm khoảng 200 dòng mã—chỉ giữ lại một vài con trỏ tài liệu. Trình phân giải sẽ chỉ tải tài liệu cần thiết vào thời điểm quan trọng. Bằng cách này, 20.000 dòng kiến ​​thức vẫn có thể được truy cập dễ dàng mà không làm rối cửa sổ ngữ cảnh.

4. Tiềm ẩn và mang tính quyết định (Không gian tiềm ẩn và thuyết quyết định)

Trong hệ thống của bạn, mỗi bước đều thuộc về một trong hai loại. Nhầm lẫn giữa hai loại này là lỗi phổ biến nhất trong thiết kế tác nhân.

Không gian tiềm ẩn là nơi trí tuệ cư ngụ. Tại đây, mô hình đọc, hiểu, đánh giá và đưa ra quyết định. Nó xử lý các phán đoán, tổng hợp thông tin và nhận diện các mẫu.

• Tính xác định là nền tảng của độ tin cậy. Cùng một đầu vào sẽ luôn tạo ra cùng một đầu ra. Các truy vấn SQL, mã biên dịch và các phép toán số học đều thuộc loại này.

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

Những hệ thống tệ nhất luôn phân bổ nhiệm vụ sai lệch ở hai phía của ranh giới phân định này. Ngược lại, những hệ thống tốt nhất vạch ra ranh giới rõ ràng một cách dứt khoát và quyết đoán.

5. Ghi nhật ký (Tổ chức tài liệu / Phân tích chủ đề)

Bước ghi nhật ký là chìa khóa để thực sự giúp AI tạo ra giá trị cho công việc tri thức thực tiễn.

Điều đó có nghĩa là mô hình sẽ đọc tất cả các tài liệu liên quan đến một chủ đề và sau đó viết ra một hồ sơ có cấu trúc. Nó tóm tắt các nhận định từ hàng chục hoặc thậm chí hàng trăm tài liệu vào một trang duy nhất.

Đây không phải là thứ mà các truy vấn SQL có thể tạo ra. Cũng không phải là thứ mà các pipeline RAG có thể tạo ra. Mô hình phải thực sự đọc, ghi nhớ thông tin mâu thuẫn cùng một lúc, nhận biết những gì đã thay đổi và khi nào nó thay đổi, sau đó tổng hợp tất cả những điều này thành trí tuệ có cấu trúc.

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

Kiến trúc này

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

• Ở lớp trên cùng là các kỹ năng chuyên sâu: các quy trình được viết bằng Markdown, bao gồm các đánh giá, phương pháp luận và kiến ​​thức chuyên môn. 90% giá trị nằm ở lớp này.
Ở giữa là một bộ công cụ giao diện dòng lệnh (CLI) đơn giản: khoảng 200 dòng mã, nhận đầu vào là JSON, xuất ra văn bản và mặc định là chỉ đọc.
Ở tầng thấp nhất là hệ thống ứng dụng của bạn: QueryDB, ReadDoc, Search, Timeline — đây là các cơ sở hạ tầng mang tính xác định.

Nguyên tắc cốt lõi mang tính định hướng: đẩy "trí tuệ" lên trên thành kỹ năng; đẩy "khả năng thực thi" xuống dưới thành các công cụ mang tính quyết định; và giữ cho hệ thống gọn nhẹ.

Kết quả là, bất cứ khi nào khả năng của mô hình được cải thiện, tất cả các kỹ năng sẽ tự động trở nên mạnh mẽ hơn; trong khi hệ thống xác định cơ bản vẫn ổn định và đáng tin cậy.

Một hệ thống học tập

Dưới đây, tôi sẽ sử dụng một hệ thống thực tế 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 Khởi nghiệp (Startup School) có 6.000 nhà sáng lập tham gia. Mỗi người đều có hồ sơ đăng ký được cấu trúc bài bản, câu trả lời bảng câu hỏi, bản ghi chép các cuộc trò chuyện trực tiếp với người hướng dẫn và các hồ sơ công khai: bài đăng trên X, lịch sử cam kết trên GitHub và việc sử dụng Claude Code (thể hiện tốc độ phát triển của họ).

Phương pháp truyền thống là một nhóm dự án gồm 15 người sẽ đọc từng đơn xin việc, đưa ra đánh giá trực quan, rồi cập nhật biểu mẫu.

Phương pháp này hiệu quả với 200 người, nhưng hoàn toàn thất bại với 6.000 người. Không một người nào có thể ghi nhớ quá nhiều thông tin như vậy cùng một lúc và nhận ra rằng ba ứng viên tốt nhất cho cơ sở hạ tầng tác nhân AI là người sáng lập một công cụ phát triển ở Lagos, một doanh nhân về tuân thủ quy định ở Singapore và một nhà phát triển công cụ dòng lệnh (CLI) ở Brooklyn — và họ đã mô tả cùng một vấn đề theo những cách hoàn toàn khác nhau trong các cuộc trò chuyện trực tiếp khác nhau.

Mô hình này có thể làm được điều đó. Phương pháp như sau:

Làm giàu thông tin (Tăng cường thông tin)

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

Hệ thống xác định ngầm định xử lý: các truy vấn SQL, dữ liệu GitHub, kiểm thử trình duyệt các URL demo, thu thập tín hiệu mạng xã hội, truy vấn CrustData, v.v. Một tác vụ theo lịch trình chạy mỗi ngày một lần. Hồ sơ của 6000 nhà sáng lập luôn được cập nhật liên tục.

Kết quả của quá trình phân tách giọng nói có thể thu thập thông tin mà các tìm kiếm bằng từ khóa hoàn toàn không thể tìm thấy:

Người sáng lập: Maria Santos Công ty: Contrail (contrail.dev) Tự mô tả: "Datadog của các tác nhân AI" Công việc thực tế: 80% mã nguồn được tập trung vào mô-đun thanh toán → Về cơ bản, đó là việc xây dựng một công cụ FinOps được ngụy trang dưới dạng công cụ giám sát.

Sự khác biệt giữa "tuyên bố và hành vi thực tế" này đòi hỏi phải đồng thời đọc lịch sử commit trên GitHub, tài liệu ứng dụng và nhật ký hội thoại, rồi tích hợp chúng vào mô hình. Không có phương pháp tìm kiếm tương đồng nhúng nào có thể làm được điều này, cũng như việc lọc từ khóa. Mô hình phải đọc toàn bộ tài liệu và sau đó đưa ra phán đoán. (Đây chính xác là loại nhiệm vụ nên được đặt trong không gian tiềm ẩn!)

Ghép nối

Đây là lúc "kỹ năng = lời gọi phương thức" trở nên hữu ích.

Việc sử dụng cùng một kỹ năng ghép nố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, được phân nhóm theo lĩnh vực, với 30 người trong mỗi nhóm (nhúng + phân bổ xác định)

/match-lunch: Xử lý 600 người, "ghép cặp ngẫu nhiên" đa lĩnh vực, 8 người một bàn không trùng lặp - chủ đề được tạo ra trước tiên bởi LLM, sau đó chỗ ngồi được sắp xếp bằng thuật toán xác định.

/match-live: Xử lý người tham gia theo thời gian thực, dựa trên thuật toán tìm kiếm lân cận gần nhất, hoàn thành việc ghép cặp một-một trong vòng 200ms và loại trừ những người đã được nhìn thấy.

Hơn nữa, mô hình này có thể đưa ra những nhận định mà các thuật toán phân cụm truyền thống không thể làm được:

"Santos và Oram đều là các nền tảng cơ sở hạ tầng trí tuệ nhân tạo, nhưng chúng không phải là đối thủ cạnh tranh — Santos chuyên về phân bổ chi phí, còn Oram chuyên về điều phối. Chúng nên được xếp vào cùng một nhóm."
"Kim đã nộp đơn xin việc liên quan đến các công cụ dành cho nhà phát triển, nhưng cuộc trò chuyện trực tiếp cho thấy anh ấy đang làm việc về tự động hóa tuân thủ SOC2. Anh ấy nên được phân loại lại là chuyên gia FinTech/RegTech."

Việc phân loại lại này là điều mà phương pháp nhúng hình ảnh không thể nắm bắt được. Mô hình phải đọc toàn bộ hình ảnh.

Vòng lặp học tập

Sau khi sự kiện kết thúc, một người có kỹ năng /cải thiện sẽ đọc kết quả khảo sát NPS, ghi lại những phản hồi "ổn" - không phải những đánh giá tiêu cực, mà là những phản hồi "gần như hoàn hảo" - và trích xuất các mẫu phản hồi.

Sau đó, hệ thống sẽ đề xuất các quy tắc mới và ghi chúng trở lại vào kỹ năng ghép trận:

Khi người tham gia đề cập đến "cơ sở hạ tầng AI", nhưng hơn 80% mã của họ lại dành cho các mô-đun thanh toán:
→ Được phân loại là FinTech, không phải cơ sở hạ tầng AI

Khi hai người trong cùng một nhóm đã quen biết nhau:
→ Giảm trọng lượng khớp
Ưu tiên việc xây dựng các mối quan hệ mới.

Những 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 vào lần chạy kỹ năng tiếp theo. Kỹ năng có khả năng "tự ghi đè". Trong sự kiện tháng 7, tỷ lệ đánh giá "ổn" là 12%; trong sự kiện tiếp theo, tỷ lệ này sẽ giảm xuống còn 4%.

Tệp kỹ năng đã học được ý nghĩa của từ "ổn", và 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 áp dụng cho bất kỳ lĩnh vực nào:

Tìm kiếm → Đọc → Ghi nhật ký → Đếm → Tổng hợp

Sau đó: Nghiên cứu → Điều tra → Ghi nhật ký → Viết lại kỹ năng

Nếu bạn được hỏi chu kỳ nào có giá trị nhất năm 2026, thì đó chính là chu kỳ này. Nó có thể áp dụng cho hầu hết mọi tình huống công việc dựa trên tri thức.

Kỹ năng có thể được nâng cấp vĩnh viễn.

Gần đây tôi đã gửi một lệnh đến OpenClaw trên hệ điều hành X, và phản hồi nhận được còn vượt quá mong đợi:

Yêu cầu: Bạn không được phép thực hiện các nhiệm vụ chỉ một lần. Nếu tôi yêu cầu bạn làm điều gì đó sẽ lặp lại trong tương lai, bạn phải: Đầu tiên, xử lý thủ công từ 3 đến 10 mẫu và cho tôi xem kết quả; Nếu tôi chấp thuận, hãy ghi lại vào tệp kỹ năng; Nếu cần chạy tự động, hãy thêm nó vào tác vụ theo lịch trình. Tiêu chí là: nếu tôi cần yêu cầu bạn lần thứ hai, điều đó có nghĩa là bạn đã thất bại.

Bài đăng này đã nhận được hàng nghìn lượt thích và hơn hai nghìn lượt lưu. Nhiều người cho rằng đó là một kỹ thuật từ Prompt Engineering.

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

Đây là nguồn gốc cho tuyên bố của Yegge về hiệu quả gấp 100 lần.

Vấn đề không nằm ở những mô hình thông minh hơn, mà là: Nền tảng vững chắc, kỹ năng vượt trội và kỷ luật để biến mọi thứ thành năng lực thực thụ.

Hệ thống sẽ phát triển nhờ lãi kép. Xây dựng một lần, vận hành lâu dài.

[Liên kết gốc]