Từ “nhắc lại cho AI” đến đóng gói năng lực vận hành — cách doanh nghiệp biến kinh nghiệm rời rạc thành tài sản có thể gọi đúng lúc, dùng đúng việc và kiểm soát được
Sáng thứ Hai, đội sản phẩm yêu cầu AI viết tài liệu API. Người phụ trách dành vài phút nhắc lại chuẩn OpenAPI, quy ước mã lỗi, cấu trúc ví dụ và yêu cầu song ngữ. Chiều cùng ngày, đội tài chính dùng chính trợ lý ấy để phân tích biên lợi nhuận — rồi lại phải giải thích công thức, nguồn dữ liệu và mẫu báo cáo từ đầu.
Kịch bản này lặp lại ở nhiều doanh nghiệp: AI đủ thông minh để làm việc, nhưng tổ chức chưa có một kiến trúc tri thức đủ tốt để AI làm việc nhất quán.
Vấn đề không nằm ở việc thiếu thêm một prompt hay. Vấn đề là kinh nghiệm đang sống trong trí nhớ cá nhân, lịch sử chat và những tệp hướng dẫn khó tìm. Mỗi phiên làm việc mới giống như tuyển một cộng sự giỏi nhưng mất trí nhớ ngắn hạn: phải onboarding lại, kiểm tra lại và sửa lại những lỗi vốn đã từng được sửa.
Một Skill giải bài toán đó bằng cách đóng gói cách làm việc thành một đơn vị tái sử dụng. Nó không chỉ nói cho AI biết phải trả lời gì, mà còn chỉ rõ khi nào cần kích hoạt, phải đọc kiến thức nào, được dùng công cụ nào, thực hiện theo quy trình nào và kết quả phải có hình dạng ra sao.
Đó là bước chuyển quan trọng: từ sử dụng AI như một hộp thoại sang vận hành AI như một hệ thống.
Nếu doanh nghiệp đã từng gặp tình trạng mô hình rất mạnh nhưng đầu ra vẫn thiếu nhất quán, bài AI giỏi nhưng vẫn làm sai: Doanh nghiệp đang thiếu một thứ không nằm trong model là phần nền hữu ích để nhìn rõ vai trò của “bộ nhớ tổ chức”.
Hai loại tri thức doanh nghiệp thường bị trộn lẫn
Trong một hệ thống AI Agent, không phải mọi tri thức đều nên được nạp thường trực.
Loại thứ nhất là nguyên tắc nền: ngôn ngữ lập trình chính, quy ước bảo mật, cách đặt tên, giọng điệu thương hiệu hay tiêu chuẩn phê duyệt. Chúng giống “nội quy chung” của doanh nghiệp — áp dụng gần như mọi lúc.
Loại thứ hai là quy trình chuyên môn theo ngữ cảnh: cách review code, lập báo cáo tài chính, xử lý khiếu nại, chuẩn bị hồ sơ thầu hay tạo tài liệu API. Chúng giống SOP của từng phòng ban — chỉ cần khi đúng công việc xuất hiện.
Nếu nhồi toàn bộ SOP vào một tệp hướng dẫn chung, doanh nghiệp phải trả ba loại chi phí:
Chi phí ngữ cảnh: thông tin không liên quan vẫn chiếm không gian xử lý.
Chi phí chú ý: quy tắc quan trọng bị chìm giữa hàng nghìn dòng hướng dẫn.
Chi phí bảo trì: một thay đổi nhỏ trong nghiệp vụ có thể làm tệp chung ngày càng khó hiểu và khó kiểm soát.
Ngược lại, nếu giữ mọi thứ trong prompt cá nhân, tri thức không thể lan tỏa. Người giỏi vẫn phải lặp lại cùng một chỉ dẫn; người mới phải tự học lại; kết quả phụ thuộc vào ai là người đặt câu hỏi.
Kiến trúc hợp lý là tách ba lớp:
Lớp
Vai trò
Câu hỏi được giải quyết
Nguyên tắc chung
Giữ các quy tắc luôn có hiệu lực
“Ở đây chúng ta làm việc theo chuẩn nào?”
Skill chuyên môn
Đóng gói kiến thức và quy trình theo tình huống
“Với loại việc này, cách làm chuẩn là gì?”
Agent thực thi
Lập kế hoạch, dùng công cụ và tạo đầu ra
“Ai sẽ làm, làm theo thứ tự nào?”
Sự phân lớp này có ý nghĩa với lãnh đạo hơn là một lựa chọn kỹ thuật. Nó quyết định doanh nghiệp có thể biến tri thức ngầm thành năng lực tổ chức hay tiếp tục phụ thuộc vào một vài cá nhân.
Một Skill tốt có bốn lớp, không phải một đoạn prompt dài
Hãy hình dung một Skill như một “gói năng lực” gồm bốn thành phần.
1. Lớp điều phối: tệp chỉ dẫn chính
Tệp SKILL.md là cửa vào. Nó nên ngắn gọn, nêu mục tiêu, điều kiện sử dụng, quy trình cốt lõi và dẫn đường tới các tài nguyên chuyên sâu.
Sai lầm phổ biến là biến tệp này thành kho tài liệu khổng lồ. Khi đó, AI lại phải đọc mọi thứ dù chỉ cần một phần nhỏ. Tư duy đúng là: tệp chính đóng vai trò router, không phải repository.
2. Lớp kiến thức: tài liệu tham chiếu
Các tệp reference/ chứa công thức, chuẩn ngành, danh mục mã lỗi, chính sách và ví dụ. Chúng chỉ được đọc khi nhiệm vụ thực sự cần.
Ví dụ, một Skill phân tích tài chính có thể tách revenue.md, costs.md và profitability.md. Khi người dùng hỏi về biên lợi nhuận gộp, Agent không cần nạp toàn bộ kiến thức doanh thu và phân bổ chi phí.
3. Lớp chuẩn hóa: mẫu đầu ra
Thư mục templates/ định nghĩa báo cáo cuối cùng phải trông như thế nào. Đây là thành phần thường bị xem nhẹ, dù nó tạo ra giá trị vận hành rất lớn: kết quả nhất quán hơn, dễ so sánh giữa các kỳ và thuận lợi cho bước xử lý tự động tiếp theo.
4. Lớp thực thi: script và công cụ
Các phép tính xác định, thao tác chuyển đổi dữ liệu hoặc kiểm tra định dạng nên được giao cho scripts/, thay vì kỳ vọng mô hình “suy luận” ra một kết quả vốn có thể tính chính xác.
Một nguyên tắc thực dụng: nếu đang viết một chuỗi công thức dài để AI tự tính, hãy cân nhắc chuyển nó thành script. Mô hình phù hợp để hiểu ý định và diễn giải kết quả; chương trình phù hợp để tính toán lặp lại, chính xác và kiểm thử được.
Cấu trúc tối thiểu có thể như sau:
text
financial-analysis/
├── SKILL.md
├── reference/
│ ├── revenue.md
│ ├── costs.md
│ └── profitability.md
├── templates/
│ └── analysis-report.md
└── scripts/
└── calculate-ratios.py
Khi bốn lớp này rõ ràng, doanh nghiệp có thể nâng cấp công thức, thay mẫu báo cáo hoặc đổi script mà không phải viết lại “giao diện” của Skill. Đây chính là tư duy mô-đun quen thuộc của kỹ nghệ phần mềm, được đưa vào quản trị tri thức cho AI.
Progressive disclosure: nạp đúng tri thức vào đúng thời điểm
Giá trị kiến trúc lớn nhất của Skill là progressive disclosure — tiết lộ dần thông tin theo nhu cầu.
Quá trình thường có ba nấc:
Hệ thống chỉ nhìn thấy phần mô tả ngắn để biết Skill tồn tại và khi nào nên dùng.
Khi ý định phù hợp, nội dung chính của
SKILL.mdmới được nạp.Trong lúc thực thi, Agent chỉ mở đúng tài liệu, template hoặc script mà quy trình yêu cầu.
Cơ chế này tương tự lazy loading trong phần mềm: không tải cả kho tri thức ngay khi khởi động, mà lấy đúng tài nguyên tại thời điểm cần dùng.
Lợi ích không chỉ là tiết kiệm token. Một ngữ cảnh gọn giúp tín hiệu quan trọng nổi bật hơn, giảm xung đột chỉ dẫn và khiến hành vi dễ dự đoán hơn. Nói cách khác, đây vừa là tối ưu chi phí, vừa là tối ưu chất lượng.
Đây cũng là một lớp mở rộng của tư duy trong bài Prompt hay chưa đủ: Muốn AI làm việc đáng tin, hãy thiết kế “bàn làm việc” cho nó: chất lượng không chỉ đến từ câu lệnh, mà từ toàn bộ môi trường làm việc bao quanh mô hình.
Tuy nhiên, progressive disclosure chỉ hiệu quả khi mô tả kích hoạt đủ tốt. Một mô tả kiểu “hỗ trợ phân tích dữ liệu” quá mơ hồ: nó có thể kích hoạt sai ở mọi bảng tính hoặc không kích hoạt khi người dùng dùng từ khác.
Mô tả tốt nên trả lời ba ý:
Skill làm được việc gì?
Khi nào nên dùng?
Những tín hiệu ngôn ngữ hoặc ngữ cảnh nào cho thấy nhu cầu đó?
Có thể xem phần mô tả như “vân tay ngữ nghĩa” của một năng lực. Viết mô tả không phải việc hành chính; đó là thiết kế cơ chế định tuyến.
allowed-tools: nơi tri thức gặp quản trị rủi ro
Một SOP dành cho con người thường giả định người thực hiện biết đâu là giới hạn. AI Agent cần giới hạn ấy được biểu diễn rõ ràng.
Trường allowed-tools giúp thiết lập nguyên tắc đặc quyền tối thiểu:
Skill kiểm toán chỉ cần đọc và tìm kiếm, không cần quyền sửa.
Skill tạo báo cáo có thể ghi tệp mới, nhưng không nhất thiết được sửa dữ liệu nguồn.
Skill tính toán có thể chạy một script cụ thể, thay vì được phép gọi mọi lệnh shell.
Skill triển khai hệ thống có tác động lớn nên yêu cầu người dùng chủ động kích hoạt, không tự khởi chạy chỉ vì nhận thấy vài từ khóa có liên quan.
Điểm cốt lõi là không hỏi “cấp bao nhiêu quyền thì tiện?”, mà hỏi “quyền tối thiểu nào đủ để hoàn thành trách nhiệm?”.
Khi tri thức và quyền hành động nằm trong cùng một gói, doanh nghiệp có thể audit không chỉ AI biết gì, mà cả AI được phép làm gì với điều nó biết. Đây là nền móng để chuyển từ thử nghiệm cá nhân sang triển khai cấp tổ chức.
Ở cấp production, cùng nguyên tắc này được mở rộng thành các lớp kiểm soát đầu vào, công cụ và đầu ra như phân tích trong Đưa LLM vào production: Đừng chỉ gọi mô hình, hãy xây một hệ thống kiểm soát.
Bốn mẫu thiết kế có thể áp dụng ngay
Không cần bắt đầu bằng một thư viện Skill đồ sộ. Hãy chọn mẫu theo bản chất công việc.
Mẫu 1 — Dẫn dắt bằng template
Phù hợp với báo cáo tuần, biên bản sự cố, tài liệu API, hồ sơ đánh giá và các đầu ra cần đồng nhất. Template là hợp đồng đầu ra; AI đảm nhiệm việc điền nội dung và lý giải.
Mẫu 2 — Tăng cường bằng script
Phù hợp với tính tỷ lệ tài chính, kiểm tra dữ liệu, chuyển đổi định dạng hay quét cấu trúc mã nguồn. Script xử lý phần xác định; AI xử lý phần ngữ nghĩa.
Mẫu 3 — Phân tầng kiến thức
Đưa kiến thức thường dùng vào tệp chính; để tài liệu chuyên sâu trong reference/. Đây là cách tránh cả hai cực đoan: tệp chính quá dài hoặc hệ thống phải mở quá nhiều tệp cho một nhiệm vụ đơn giản.
Mẫu 4 — Cô lập công cụ
Thiết kế Skill quanh phạm vi hành động an toàn. Skill review không được viết; Skill xuất bản không được thay đổi mã nguồn; Skill tạo commit chỉ được dùng đúng các lệnh Git cần thiết.
Bốn mẫu này có thể kết hợp. Chẳng hạn, một Skill phân tích tài chính tốt thường vừa phân tầng kiến thức, vừa dùng template, vừa gọi script tính toán, đồng thời giới hạn quyền đọc đúng nguồn dữ liệu được duyệt.
Lộ trình sáu bước: từ một thao tác lặp lại đến tài sản tổ chức
Bước 1: Tìm “nỗi đau lặp lại”
Đừng bắt đầu từ câu hỏi “chúng ta có thể tạo Skill gì?”. Hãy tìm công việc mà nhân sự phải liên tục nhắc AI cùng một chuẩn, sửa cùng một lỗi hoặc dựng lại cùng một cấu trúc đầu ra.
Nếu một chỉ dẫn đã được lặp lại ba lần và ít thay đổi, đó là ứng viên tốt để đóng gói.
Bước 2: Xác định hợp đồng
Viết rõ đầu vào, đầu ra, điều kiện hoàn thành và ranh giới trách nhiệm. Một Skill “viết báo cáo tốt hơn” không có hợp đồng. Một Skill “đọc dữ liệu doanh thu đã duyệt, tính ba chỉ số bằng script và xuất báo cáo theo template” thì có.
Bước 3: Tách kiến thức khỏi quy trình
Quy trình ổn định nằm ở tệp chính. Chuẩn, ví dụ, bảng tra và nội dung thay đổi theo thời gian nằm ở tài liệu tham chiếu. Đầu ra lặp lại nằm ở template. Logic xác định nằm ở script.
Bước 4: Giới hạn công cụ
Liệt kê từng quyền cần thiết và loại bỏ phần còn lại. Với thao tác gây tác động như commit, triển khai hay gửi thông báo, nên thiết kế điểm xác nhận rõ ràng.
Bước 5: Kiểm thử cả “gọi đúng” lẫn “làm đúng”
Nhiều đội chỉ kiểm tra chất lượng đầu ra mà quên kiểm tra cơ chế kích hoạt. Tối thiểu cần ba nhóm thử nghiệm:
Câu hỏi nên kích hoạt Skill.
Câu hỏi không nên kích hoạt Skill.
Tình huống biên, thiếu dữ liệu hoặc có chỉ dẫn xung đột.
Sau đó mới đánh giá đầu ra: có đúng cấu trúc, đủ checklist, dùng đúng nguồn và xử lý ngoại lệ không.
Bước 6: Đo và cải tiến
Theo dõi số lần người dùng phải sửa, thời gian hoàn thành, mức tiêu thụ ngữ cảnh và lỗi tái diễn. Mỗi phản hồi lặp lại là một tín hiệu để cập nhật Skill.
Chu trình này giống phát triển phần mềm: phát hiện lỗi → xác định nguyên nhân → sửa tài sản dùng chung → kiểm thử hồi quy. Khác biệt là “mã nguồn” ở đây bao gồm cả chỉ dẫn, tri thức và hợp đồng hành vi.
Ba câu hỏi lãnh đạo nên đặt ra trước khi mở rộng
Một, ai sở hữu Skill?
Mỗi Skill cần một chủ sở hữu nghiệp vụ, không chỉ một người biết kỹ thuật. Khi chính sách hoặc chuẩn ngành thay đổi, phải có người chịu trách nhiệm cập nhật.
Hai, phiên bản nào đang được dùng?
Skill cần được quản lý phiên bản, review thay đổi và có khả năng quay lại bản ổn định. Nếu không, doanh nghiệp sẽ không biết một quyết định được tạo ra dưới bộ quy tắc nào.
Ba, thành công được đo bằng gì?
Số lượng Skill không phải KPI tốt. Các chỉ số đáng quan tâm hơn là tỷ lệ kích hoạt đúng, mức giảm chỉnh sửa thủ công, thời gian tới đầu ra đạt chuẩn và tỷ lệ tác vụ hoàn thành trong ranh giới quyền hạn.
Đây cũng là cách tiếp cận phù hợp với chuyển đổi số: bắt đầu từ thay đổi cách vận hành, rồi mới lựa chọn và đóng gói công nghệ hỗ trợ. Nếu chỉ tạo thêm công cụ mà không chuẩn hóa tri thức, tổ chức sẽ số hóa sự lộn xộn hiện có.
Từ prompt cá nhân đến năng lực có thể nhân rộng
Prompt giỏi vẫn hữu ích. Nhưng prompt thường giải quyết một lần tương tác; Skill giải quyết một lớp công việc.
Một prompt nói: “Hãy review đoạn code này theo các tiêu chí sau.”
Một Skill nói: “Khi có yêu cầu review, hãy kích hoạt quy trình này, đọc chuẩn bảo mật tương ứng, chỉ dùng quyền đọc, phân loại mức độ, kiểm tra đủ checklist và xuất kết quả theo mẫu.”
Khác biệt nằm ở khả năng tái sử dụng, kiểm soát và cải tiến có hệ thống.
Khi được thiết kế đúng, Skill trở thành một đơn vị tri thức có thể kiểm thử như phần mềm, phân phối như một gói nội bộ và nâng cấp như một quy trình vận hành. Nó giúp doanh nghiệp thôi “dạy lại AI mỗi sáng” và bắt đầu tích lũy năng lực qua từng lần làm việc.
Trong kiến trúc giải pháp AI doanh nghiệp, mô hình mạnh nhất không phải mô hình biết mọi thứ ngay từ đầu. Đó là mô hình biết khi nào cần gọi đúng năng lực, lấy đúng tri thức và hành động trong đúng giới hạn. Bài Claude Code không phải chatbot: Bản thiết kế 4 tầng để biến AI thành một hệ thống làm việc cung cấp một góc nhìn kiến trúc bổ sung cho cách tổ chức các lớp năng lực này.
Và đó cũng là cách một tổ chức trưởng thành với AI: không chạy theo những câu trả lời ấn tượng nhất, mà xây được một hệ thống tạo ra kết quả tốt một cách lặp lại.