- Agent Skills là một bộ scaffolding buộc các tác nhân lập trình AI phải tuân theo quy trình kỹ thuật cấp senior dưới dạng workflow, để chúng không thể bỏ qua các bước như viết đặc tả, kiểm thử, tạo PR có thể review và rà soát ranh giới tin cậy
- Skill là các tệp Markdown có frontmatter, và gần với workflow hơn là tài liệu tham khảo, vì chúng có thứ tự các bước, bằng chứng tại các checkpoint và tiêu chí hoàn tất
- 20 skill trong kho lưu trữ được tổ chức theo 6 giai đoạn vòng đời: Define, Plan, Build, Verify, Review, Ship, cùng 7 slash command:
/spec, /plan, /build, /test, /review, /ship, /code-simplify
- Các nguyên tắc cốt lõi là ưu tiên quy trình hơn văn xuôi, bảng chống hợp lý hóa, xem xác minh là tiêu chí hoàn tất, công bố dần dần và kỷ luật phạm vi;
using-agent-skills chỉ kích hoạt những skill phù hợp với tác vụ
- Có thể dùng qua cài đặt Claude Code marketplace, đưa Markdown vào Cursor
.cursor/rules/, Gemini CLI, Codex, Aider, Windsurf, OpenCode và các công cụ tương tự; dự án được phát hành theo giấy phép MIT
Mục đích và vấn đề đặt ra
- Agent Skills là một bộ scaffolding nhằm buộc các tác nhân lập trình AI phải đi qua quy trình kỹ thuật cấp senior mà chúng thường mặc định bỏ qua, bằng cách biến chúng thành workflow bắt buộc
- Khi được yêu cầu làm một tính năng, tác nhân lập trình AI thường hoàn thành theo con đường ngắn nhất, và mặc định không thực hiện các bước như viết đặc tả, kiểm thử trước, rà soát ranh giới tin cậy hay tổ chức PR sao cho có thể review
- Công việc của kỹ sư senior có nhiều phần không thể hiện ra trong diff
- Làm rõ các giả định
- Viết đặc tả
- Chia công việc thành các đơn vị có thể review
- Chọn thiết kế nhàm chán nhưng an toàn
- Để lại bằng chứng rằng kết quả là đúng
- Giới hạn thay đổi ở mức con người thực sự có thể review
- Lý do tác nhân bỏ qua các bước này cũng giống kỹ sư junior: tín hiệu phần thưởng của chúng được căn theo “hoàn thành công việc”, chứ không phải “hoàn thành công việc kèm cả tài liệu đặc tả”
- Kho Agent Skills đã vượt 26K stars, và không chỉ dừng ở README mà còn giải thích lý do của các lựa chọn thiết kế, cách chúng tương ứng với SDLC chuẩn và thực hành kỹ thuật công khai của Google, cũng như các mẫu có thể áp dụng ngay cả khi không cài đặt
Skill thực sự có nghĩa là gì
- Skill là một tệp Markdown có frontmatter được đưa vào ngữ cảnh của tác nhân tùy theo tình huống, ở đâu đó giữa một mảnh system prompt và một runbook
- Skill không phải tài liệu tham khảo, cũng không phải tập hợp kiến thức kiểu “mọi thứ bạn cần biết về kiểm thử”
- Skill hữu ích là một workflow mà tác nhân phải làm theo
- Có thứ tự các bước
- Tạo ra bằng chứng tại các checkpoint
- Kết thúc bằng tiêu chí hoàn tất rõ ràng
- Nếu đưa vào ngữ cảnh một bài luận 2.000 từ về thực hành tốt trong kiểm thử, tác nhân có thể sinh ra những câu nghe hợp lý rồi bỏ qua việc kiểm thử thực sự
- Ngược lại, nếu đưa vào một workflow yêu cầu viết kiểm thử thất bại trước, chạy để xác nhận thất bại, viết phần triển khai tối thiểu để làm nó vượt qua, xác nhận đã vượt qua rồi mới refactor, thì tác nhân sẽ có việc cụ thể phải làm và con người có thể kiểm chứng
- Phân biệt cốt lõi ở đây là ưu tiên quy trình hơn văn xuôi, workflow hơn tài liệu tham khảo, và các bước có tiêu chí hoàn tất hơn là một bài luận không có điều kiện kết thúc
- Nhiều kho “AI rules” không tạo ra hiệu quả thực tế vì các rule đó chỉ dừng ở mức bài luận thay vì workflow
Cấu trúc SDLC và slash command
- 20 skill trong kho lưu trữ được chia theo 6 giai đoạn vòng đời, và phía trên là 7 slash command
-
Giai đoạn và lệnh
/spec: giai đoạn Define để quyết định sẽ xây cái gì/plan: giai đoạn Plan để phân rã công việc/build: giai đoạn Build để triển khai theo các vertical slice/test: giai đoạn Verify để chứng minh hành vi/review: giai đoạn Review để bắt các vấn đề còn lọt/ship: giai đoạn Ship để đưa tới người dùng một cách an toàn/code-simplify: lệnh đơn giản hóa áp dụng xuyên suốt toàn bộ luồng- Cấu trúc này phản ánh luồng SDLC của một tổ chức kỹ thuật vận hành tốt, chỉ khác nhau về thuật ngữ giữa các tổ chức
- Ở Google, nó xuất hiện dưới dạng luồng design doc → review → implementation → readability review → launch checklist; ở Amazon là working-backwards memo và các cơ chế như bar raiser
- Vấn đề mới với tác nhân lập trình AI là phần lớn tác nhân mặc định bỏ qua hầu hết các giai đoạn này
- Khi yêu cầu một tính năng, bạn chỉ nhận được phần triển khai; đặc tả, kế hoạch, kiểm thử, review và checklist phát hành thì không được thực hiện
- Skill buộc tác nhân cũng phải đi qua các bước mà kỹ sư senior tự áp đặt cho mình; nếu triển khai code mà không có các quy trình đó thì rất dễ dẫn tới sự cố
- Với tính năng phức tạp, 11 skill có thể được kích hoạt tuần tự; với sửa lỗi nhỏ, có thể chỉ dùng 3 skill
- Bộ định tuyến
using-agent-skills quyết định skill nào áp dụng cho tác vụ hiện tại, và workflow sẽ mở rộng theo phạm vi thực tế chứ không theo phạm vi giả định
Các nguyên tắc giữ cho nó hoạt động
-
1. Ưu tiên quy trình hơn văn xuôi
- Workflow là thứ tác nhân có thể biến thành hành động, còn bài luận thì không
- Nguyên lý này cũng áp dụng cho đội ngũ con người
- Nếu handbook của nhóm dài 200 trang thì sẽ không ai đọc trong tình huống áp lực, nhưng nếu là một workflow nhỏ có checkpoint thì khả năng được thực thi thực sự sẽ cao hơn nhiều
-
2. Bảng chống hợp lý hóa
- Lựa chọn thiết kế độc đáo nhất trong Agent Skills mà các nhóm khác nên mang về là bảng chống hợp lý hóa
- Mỗi skill đều chứa những cái cớ phổ biến mà tác nhân hoặc kỹ sư đang mệt có thể dùng để bỏ qua workflow, cùng với phản bác được viết sẵn
- Ví dụ:
- “Việc này quá đơn giản nên không cần đặc tả” → tiêu chí chấp nhận vẫn phải có. 5 dòng thì được, nhưng 0 dòng thì không
- “Tôi sẽ viết test sau” → “sau” chính là vấn đề cốt lõi. Không có “sau”. Phải viết test thất bại trước
- “Test đã pass rồi, triển khai thôi” → test pass là bằng chứng, không phải chứng minh. Cần kiểm tra xem đã xác nhận runtime chưa, đã xác minh hành vi hiển thị với người dùng chưa, và đã có người đọc diff chưa
- LLM rất giỏi hợp lý hóa, và có thể tạo ra những đoạn văn nghe hợp lý để biện minh rằng tác vụ này không cần đặc tả hoặc thay đổi kia có thể merge mà không cần review
- Bảng chống hợp lý hóa là phản bác viết sẵn cho những lời dối trá mà tác nhân còn chưa kịp nói ra
- Mẫu này cũng có hiệu lực với các nhóm con người
- Sự xuống cấp về chất lượng kỹ thuật thường không xảy ra vì ai đó cố tình làm điều tệ, mà vì họ chấp nhận một lý do nghe hợp lý để bỏ qua quy trình mà mình không muốn làm
-
3. Xác minh là thứ không thể thương lượng
- Mọi skill đều kết thúc bằng bằng chứng cụ thể
- Test pass, đầu ra build sạch, runtime trace cho thấy hành vi mong đợi, hoặc reviewer phê duyệt đều có thể là tiêu chí hoàn tất
- “Trông có vẻ đúng” là không đủ
- Đây cũng là nguyên lý giúp harness của Anthropic phục hồi từ lỗi, việc tách planner/worker/judge của Cursor thực sự bắt được bug, và long-running agent trở nên có thể phục hồi
- Vì tác nhân là bộ máy sinh nội dung, cần có một tín hiệu riêng để quyết định khi nào công việc đã hoàn tất, và skill nhúng tín hiệu đó vào từng workflow
-
4. Công bố dần dần
- Khi bắt đầu phiên làm việc, không đưa cả 20 skill vào ngữ cảnh cùng lúc
- Chỉ kích hoạt các skill cần thiết theo giai đoạn hiện tại
- Một meta-skill nhỏ là
using-agent-skills đóng vai trò bộ định tuyến, quyết định skill nào phù hợp với tác vụ hiện tại
- Đây là cách áp dụng bài học từ harness engineering ở cấp độ skill
- Mọi token được nạp vào ngữ cảnh đều làm giảm hiệu năng ở đâu đó, nên chỉ nên nạp thứ liên quan và để phần còn lại trên đĩa
- Công bố dần dần là cách nhét thư viện 20 skill vào một khe 5K token mà không làm nhiễm bẩn toàn bộ ngữ cảnh
-
5. Kỷ luật phạm vi
- Meta-skill mã hóa nguyên tắc không thể thương lượng là “chỉ chạm vào những gì được yêu cầu”
- Không refactor các hệ thống lân cận, không xóa code mà chưa hiểu đầy đủ, và không nên nhìn thấy TODO rồi quyết định viết lại cả tệp
- Tác nhân có thể bắt đầu từ việc sửa một bug rồi muốn hiện đại hóa thêm 3 tệp không liên quan
- Kỷ luật phạm vi là yếu tố quyết định lớn nhất xem PR của tác nhân có thể merge được hay phải hoàn tác
- Điều này cũng rất phù hợp với chuẩn code review của Google, nơi reviewer có thể chặn một PR nếu nó làm nhiều hơn một việc
Liên hệ với thực hành kỹ thuật của Google
- Agent Skills phản ánh nhiều thực hành từ Software Engineering at Google và văn hóa kỹ thuật công khai của Google
- Nhiều yếu tố giúp phần mềm ở quy mô Google vận hành được đã được công khai tài liệu hóa, và đó chính là phần mà tác nhân thường bỏ qua nhiều nhất
-
Tương ứng giữa skill và thực hành
api-and-interface-design: phản ánh Hyrum’s Law. Mọi hành vi có thể quan sát được của API cuối cùng sẽ có người phụ thuộc vào, nên phải thiết kế với điều đó trong đầutest-driven-development: phản ánh test pyramid ~80/15/5 và Beyoncé Rule. Nếu thực sự quan tâm thì lẽ ra phải gắn test; bug được bắt bởi test chứ không phải bởi thay đổi hạ tầng- DAMP over DRY trong test: triết lý kiểm thử của Google cho rằng code test nên đọc như đặc tả, ngay cả khi phải chấp nhận một ít trùng lặp. Test bị trừu tượng hóa quá mức là một anti-pattern đã biết
code-review-and-quality: phản ánh kích thước PR ~100-line PR và các nhãn mức độ nghiêm trọng Critical / Nit / Optional / FYI. PR lớn thường không được review thật sự và dễ bị phê duyệt kiểu đóng dấu cao sucode-simplification: phản ánh Chesterton’s Fence. Không nên gỡ bỏ thứ gì đó trước khi hiểu vì sao nó được đặt ở đógit-workflow-and-versioning: phản ánh trunk-based development và atomic commitsci-cd-and-automation: phản ánh Shift Left và feature flags. Cần bắt vấn đề càng sớm càng tốt, đồng thời tách deployment khỏi releasedeprecation-and-migration: phản ánh code-as-liability. Mỗi dòng code được giữ lại sẽ phải bảo trì mãi mãi, nên nên ưu tiên bề mặt nhỏ hơn- Những khái niệm này không mới, nhưng không được cài sẵn trong tác nhân
- Dù frontier model có thể đã đọc cụm “Hyrum’s Law” trong dữ liệu huấn luyện, điều đó không có nghĩa là nó sẽ tự động áp dụng khi thiết kế API lúc 3 giờ sáng
- Skill khiến các thực hành này được tác nhân áp dụng trong công việc thực tế
Cách dùng trong thực tế
Các mẫu có thể mang về dù không cài đặt
-
Biến chống hợp lý hóa thành thực hành của nhóm
- Nhóm cần viết ra những lời dối trá mà họ thường nói với chính mình
- Ví dụ như “sau khi phát hành rồi sẽ sửa test”, “thay đổi này nhỏ quá nên không cần tài liệu thiết kế”, “đã có monitoring nên ổn rồi”
- Gắn phản bác cho từng câu và đưa vào
AGENTS.md hoặc wiki kỹ thuật sẽ giúp giảm tranh cãi và chặn các lối tắt vì mệt mỏi vào chiều thứ Sáu
-
Viết tài liệu nội bộ theo quy trình thay vì văn xuôi
- Nếu bạn đang viết một tài liệu 2.000 từ kiểu “chúng ta tiếp cận X như thế nào”, thì bạn đang viết tài liệu tham khảo
- Nếu chuyển nó thành workflow có checkpoint, tài liệu có thể rút xuống còn 400 từ và khả năng được thực thi thực sự sẽ cao hơn nhiều
- Nguyên tắc này áp dụng cho hướng dẫn onboarding, runbook và cả agent skill
-
Lấy xác minh làm tiêu chí hoàn tất cứng
- Bước cuối cùng của mọi công việc nên là “tạo bằng chứng”
- Điều này áp dụng cho tác nhân, kỹ sư và cả công việc cá nhân
- Bằng chứng có thể là một lần chạy test màu xanh, ảnh chụp màn hình, log hoặc phê duyệt review—bất cứ thứ gì chứng minh công việc đã xong
- Nếu không có bằng chứng thì công việc chưa kết thúc, và “trông có vẻ đúng” không thể khép lại vòng lặp
-
Áp dụng công bố dần dần cho mọi bộ quy tắc
- Đừng viết handbook dài 50 trang; hãy viết một bộ định tuyến nhỏ dẫn tới các chương ngắn phù hợp với tình huống
- Điều này áp dụng cho
AGENTS.md, runbook, playbook ứng phó sự cố và mọi tài liệu cần phải đọc trong điều kiện áp lực
-
5 nguyên tắc không thể thương lượng để đưa vào AGENTS.md
- Phải làm rõ giả định trước khi xây. Giả định sai nhưng bị giữ im lặng là một trong những chế độ lỗi phổ biến nhất
- Nếu yêu cầu mâu thuẫn thì phải dừng lại và hỏi. Không được đoán
- Khi cần thì phải phản biện. Tác nhân hay kỹ sư đều không phải yes-man
- Nên ưu tiên lời giải nhàm chán nhưng rõ ràng. Sự thông minh quá mức rất đắt đỏ
- Chỉ được chạm vào những gì được yêu cầu
Vị trí của nó trong harness
- Xét ở góc nhìn lớn hơn, skill là một lớp trong agent harness engineering
- Harness bao gồm mô hình và mọi thứ được xây xung quanh nó; còn skill là các mảnh workflow có thể tái sử dụng, được công bố dần dần vào system prompt
- Skill đứng song song với
AGENTS.md, hooks, tools và session log
AGENTS.md: đóng vai trò bộ quy tắc được cập nhật liên tục- hooks: lớp cưỡng chế mang tính quyết định
- tools: các hành động mà tác nhân có thể thực hiện
- session log: bộ nhớ bền vững
- skills: chịu trách nhiệm cho quy trình kỹ thuật cấp senior
- Skill còn quan trọng hơn với long-running agents so với tác nhân kiểu trò chuyện
- Thời gian chạy dài sẽ khuếch đại mọi lối tắt
- Một tác nhân bỏ qua test trong phiên 10 phút có thể tạo ra một bug
- Một tác nhân bỏ qua test trong phiên 30 giờ có thể kết thúc bằng một cuộc khai quật khảo cổ gỡ lỗi, nơi không ai còn nhớ ý định ban đầu là gì
- Thời gian chạy càng dài thì scaffolding kỹ thuật cấp senior càng phải được áp dụng như sự cưỡng chế, chứ không phải gợi ý
- Tính di động của định dạng skill cũng quan trọng
- Cùng một tệp
SKILL.md có thể dùng trong Claude Code, Cursor dùng rules, Gemini CLI, Codex và các harness khác có thể nhận nội dung system prompt
- Viết workflow một lần rồi để runtime cưỡng chế nó, đó chính là lợi thế của định dạng Markdown kèm frontmatter so với bespoke prompt engineering
Kết luận
- Tác nhân lập trình AI hành xử như một kỹ sư junior cực kỳ giỏi nhưng không có bản năng cho những công việc không thể hiện trong diff
- Những việc kỹ thuật cấp senior như làm rõ giả định, điều chỉnh kích thước thay đổi, viết đặc tả, để lại bằng chứng hay từ chối merge các thay đổi không thể review rất dễ bị tác nhân bỏ qua nếu không bị buộc phải làm
- Điều ngày càng quan trọng là mã hóa kỷ luật này theo cách khiến tác nhân không thể tự dùng lời nói để lách khỏi nó
- Skill là một hình thức như vậy; cốt lõi nằm ở bảng chống hợp lý hóa, công bố dần dần, ưu tiên quy trình hơn văn xuôi, xác minh như tiêu chí hoàn tất và cấu trúc mang tính di động của các thực hành Google vốn đã chứng minh hiệu quả
- Kho Agent Skills được phát hành theo giấy phép MIT, và góc nhìn scaffolding rộng hơn được tiếp nối trong Agent Harness Engineering và Long-running Agents
1 bình luận
Ý kiến trên Hacker News
Gần như là một thuốc chữa bách bệnh lừa đảo. Đáng đọc và trông có vẻ hợp lý, nhưng rốt cuộc vẫn là thuốc chữa bách bệnh lừa đảo
Lý do là các mô hình kiểu máy đánh bạc có thể bỏ sót các yêu cầu bắt buộc được ghi trong
AGENTS.md,memory.mdvà hàng chục file Markdown kỹ năng bất cứ lúc nào, và chuyện đó thực tế gần như là chắc chắnCách tiếp cận kiểu harness này giả vờ như LLM có thể tuân thủ quy tắc một cách nghiêm ngặt và hoàn hảo, và vấn đề chỉ là chúng ta chưa viết đủ nhiều quy tắc đủ rõ ràng. Đó là một ngộ nhận căn bản về cách LLM hoạt động
Cuối cùng, thứ duy nhất không thể tin cậy nhưng vẫn tương đối đáng tin hơn là sự rà soát và giám sát của con người, tốt nhất là làm liên tiếp hai lần nếu có thể
Còn lại đều là thuốc chữa bách bệnh lừa đảo, và đến lúc đó bạn sẽ nhận ra cả lời hứa tăng năng suất cũng vậy. Vì việc đọc code và xây dựng mô hình trong đầu khó hơn rất nhiều so với chuyển mô hình đã có sẵn trong đầu thành code
Việc đọc code còn tùy loại code, nhưng giống như các kỹ năng khác, luyện tập thì sẽ dễ hơn. Đây là chuyện rất thường gặp trong những tình huống bạn phải đọc nhiều hơn viết, như khi xử lý những codebase lớn và phức tạp đã tồn tại từ lâu
Nó còn dễ hơn khi bạn đã có mô hình trong đầu về code thông qua tài liệu, kinh nghiệm trước đó hoặc hỏi đồng nghiệp
Với agent cũng làm được như vậy. Thường thì trước khi đưa prompt cho AI, bạn đã hiểu khá rõ cấu trúc code rồi, và nếu chia nhỏ công việc cẩn thận thì việc review code được sinh ra sẽ rất dễ. Cảm giác như đọc lại một cuốn sách đã đọc rồi; hiếm khi có gì sai thì cũng đập vào mắt ngay nên thường bắt được từ sớm. Dù theo cách nào thì tốc độ vẫn tăng rất nhiều
Nhưng vài tháng qua tôi đã dùng spec-kit, tức kiểu dùng AI theo cách này, và trên thực tế nó tốt đến ngạc nhiên. Tôi đang làm ra những thứ rất tốt, và các vấn đề được nêu như giả định thì tôi vẫn chưa gặp. Có thể một ngày nào đó sẽ xảy ra nên tôi vẫn cẩn thận
Dù vậy, sau khi trực tiếp dùng đủ lâu, tôi không thể đơn giản gạt nó đi như một thứ thuốc chữa bách bệnh lừa đảo. Tôi đã làm lập trình viên hơn 30 năm và cảm thấy mình đánh giá khá tốt điều gì hiệu quả và điều gì không
Về sau tôi muốn thấy những harness không còn là yêu cầu mà là bắt buộc. Ví dụ bảo agent ở chế độ lập kế hoạch mà nó không theo đúng quy trình kế hoạch đã định thì cho dừng luôn. Dù không hoàn hảo, nó vẫn phải tốt hơn cách hiện tại có con người chen vào
Họ nói “skill là file Markdown có frontmatter được tiêm vào ngữ cảnh của agent khi phù hợp”, nhưng việc quyết định đó có phải là tình huống phù hợp hay không lại là LLM
Họ cũng nói “đó là một chuỗi các bước mà agent làm theo, kết thúc bằng checkpoint tạo ra bằng chứng và tiêu chí dừng rõ ràng”, nhưng thứ quyết định có làm theo các bước đó hay không cũng là LLM
$my-skill, và lúc đó skill đó thực sự được tiêm vào ngữ cảnh. Sau đó LLM sẽ tuân theo skill đó ở mức độ nó tuân theo prompt, chỉ dẫn và các phần ngữ cảnh khácTôi mong đến ngày mọi người nhận ra họ đã dành hơn một năm mày mò agent và chỉ trải nghiệm cảm giác năng suất giả tạo
Điều đó hoàn toàn không khớp với trải nghiệm thực tế của tôi. Tôi muốn biết trải nghiệm nào khiến bạn tin chắc vào sự sụp đổ tất yếu của lập trình với AI. Đó là một niềm tin triết học rằng AI là sai trái về mặt đạo đức, hay là bạn đã thực sự xây thứ gì đó với AI, khám phá đủ sâu rồi mới đi đến kết luận mạnh như vậy
Tôi đã viết code hằng ngày hơn 30 năm và làm nghề này hơn 20 năm. Tôi đã thấy các trào lưu đến rồi đi, cũng như nhiều tiến bộ thực sự thay đổi cách làm việc. Càng xây nhiều dự án với AI, tôi càng tin rằng đây là một thay đổi bền vững và căn bản trong cách tạo phần mềm và sử dụng máy tính
Tôi thấy AI đang tốt hơn lên, và cũng thấy bản thân mình ngày càng giỏi hơn trong việc hoàn thành công việc thực tế với nó. Những công việc đó đã được kiểm chứng dưới tải production ngoài đời thật. Bạn có thể không thích những gì đang diễn ra và không thích cảm giác làm việc với AI, nhưng điều đó không có nghĩa là nó không mang lại giá trị thật cho con người và không làm công việc thật
Bọn tôi đã chuyển sang Claude Code toàn diện từ khoảng tháng 9 và đã theo dõi được các cải thiện thành công. Chúng tôi đang triển khai các tính năng thực sự được dùng trong production. Từ phía hạ tầng, triển khai business logic, đến cả frontend lẫn backend đều vậy
Tôi không nghĩ mọi người đang lãng phí thời gian đến thế. Dù vậy tôi đồng ý rằng phần lớn các bài kiểu này là nói nhảm, bài này cũng vậy. Nhưng phát triển bằng AI đã và đang diễn ra ở rất nhiều công ty trên toàn thế giới
Tôi không nghĩ workflow kiểu agent đã đạt tới mức đó, nhưng các triển khai skill dùng khi gọi thủ công và làm việc song song với AI thì rõ ràng là ổn. Công ty tôi gần đây tập trung nhiều vào sandboxing và các skill an toàn
Tôi chưa thấy nó nắm được phát triển tính năng cho lắm, nhưng các skill review và skill Grafana mà chúng tôi viết ra thì khá chắc chắn
Trước đây tôi từng dùng một bộ skill agent lớn hơn, nhưng nó cố làm quá nhiều thứ nên cảm giác như lãng phí thời gian. Giống như Vim, nhiều khi dùng skill theo kiểu chọn từ cộng đồng sẽ tốt hơn là cài cả bộ như một IDE
Skill khác nhau giữa từng lập trình viên và từng đội nên nó quá mang tính cá nhân. Thay vì cài hàng loạt cấu hình của người khác, tốt hơn là xem chúng như tài liệu tham khảo để tự xây cấu hình của mình
Xét theo góc độ tối ưu hóa tìm kiếm hay tối ưu hóa cho LLM, có vẻ khả năng được tìm thấy của các skill này sẽ khó nếu không đổi tên: https://agentskills.io/
Nếu Addy có đọc, tôi muốn biết ông ấy sẽ giải thích nó khác hay hơn Superpowers thế nào: https://github.com/obra/superpowers
Tôi đã ở mảng phát triển agent từ trước cả superpowers, và tôi lo rằng hơn 50% quy trình do tự mình xây giờ đã được superpowers bao phủ
Tôi không còn tin GitHub star nữa. Mong ai đó cho tôi biết. superpowers giờ thực sự đã được chấp nhận rộng rãi chưa? Nếu nó thật sự có giá trị thì tại sao Boris vẫn chưa tích hợp khái niệm đó?
“Nếu bạn nghĩ có dù chỉ 1% khả năng một skill áp dụng được cho việc đang làm, thì bạn phải gọi skill đó”
Tôi không hiểu sao ai cũng hào hứng thế với việc tự xóa bỏ công việc của mình
Dù mấy thứ này hay một “skill” nào đó có lẽ sẽ không thực sự làm được vậy, nhưng xét về nguyên tắc thì đúng là thế. Nó giống như sự tha hóa khỏi lao động đang diễn ra trên quy mô lớn
Từ khi còn có thể lần theo dấu vết, loài người luôn tìm cách giảm bớt lao động cần thiết để tạo ra một mức sản lượng nhất định, và đó chính là văn minh. Chúng ta có nên quay lại thời dùng cuốc canh tác thủ công để tối đa hóa lao động bỏ ra không? Có nên quay lại thời thắp từng cột đèn đường một không?
Những xã hội tụt hậu trong tự động hóa sẽ nghèo đi và cuối cùng lụi tàn. Vì ngay cả những người sinh ra ở đó cũng sẽ rời đi sang nơi có năng suất cao hơn. Điều đó đã xảy ra ở Đông Âu, với người Amish, và ở bất cứ xã hội nghèo nào có di cư. Làm được nhiều hơn với ít hơn luôn là điều thú vị
Tôi tự hỏi liệu bạn có cảm thấy như vậy với mọi loại tự động hóa mình tạo ra không. Trước đây có những quản trị hệ thống kiểu cũ nhìn sự phát triển của tự động hóa hạ tầng theo cách này, và họ không thích việc script và hệ thống thay thế những gì xưa kia phải làm bằng tay
Ở một công việc trước, đội của tôi đã xây một hệ thống vá lỗi tự động chạy trên 30 nghìn máy chủ, đồng thời tự động đưa hệ thống ra khỏi rồi đưa trở lại production. Toàn bộ quy trình trở nên không cần động tay, trong khi trước đó có cả một đội chuyên trách chạy quy trình ấy thủ công. Tự động hóa có cướp việc của họ không?
Theo một nghĩa nào đó thì có, nhưng vẫn còn việc khác phải làm và giờ họ có thể làm những việc đó
Lý do tôi thích lập trình, máy tính và công nghệ chính là vì chúng làm việc thay cho chúng ta. Utopia của tôi là một thế giới nơi robot làm hết công việc nặng nhọc để con người có thể làm điều mình muốn. AI đang giúp chúng ta tiến thêm một bước theo hướng đó. Thay vì cố giữ lại đủ việc để con người bận rộn với những thứ họ thậm chí không muốn làm, tôi muốn tập trung vào cách để lợi ích khi robot lấy đi việc làm không chỉ thuộc về những chủ sở hữu giàu có mà là cho cả thế giới
Hiện tại vẫn chưa rõ mọi thứ đang tiến hóa theo hướng nào, nên người ta đang thử giao dữ liệu của mình cho các agent ngẫu nhiên, tìm cách lưu và truy cập ngữ cảnh, tái sử dụng prompt, và đủ kiểu thử nghiệm để xử lý công nghệ này
Phần lớn những thứ đó có thể một năm nữa sẽ thành vô dụng vì đã được tích hợp sâu vào thế hệ mô hình tiếp theo. Dù vậy, việc theo kịp tiến bộ luôn là một phần thú vị của công việc trong lĩnh vực này
Tôi nghĩ cả phe ủng hộ lẫn phản đối đều sẽ hơi ngạc nhiên nếu dữ liệu dài hạn cho thấy rằng mức tăng năng suất trung bình là hạn chế, và rằng ngay cả khi có sự hỗ trợ từ các mô hình cao cấp hiện đại nhất, để tạo ra phần mềm chất lượng cao vẫn cần sự tỉ mỉ và chú ý của con người
Vẫn là cùng một công việc, chỉ khác là bạn có máy khoan điện thay vì tua vít thôi. Có người sẽ xây được ngôi nhà đứng vững hàng trăm năm, có người thì không
Dạo này tôi cứ nghe đi nghe lại cùng một điều. Những thứ tốt cho việc quản lý một đội phát triển cũng tốt cho quản lý LLM
Ví dụ như test case tốt, tài liệu rõ ràng và ngắn gọn, CI/CD, best practice và tài liệu onboarding
Việc quản lý LLM ngày càng giống quản lý một đội ngũ con người
Tôi tò mò không biết thứ này tốt hơn hay khác spec-kit ở điểm nào. Triết lý có vẻ rất giống nhau, và tôi cũng tự hỏi liệu có thể dùng cùng nhau không. Hay chỉ là trùng lặp thôi?
https://github.com/github/spec-kit
Tôi ngạc nhiên vì vài skill dài đến mức này. Trải ra nhiều trang với bảng, danh sách checkbox, ví dụ code các kiểu
Tôi tự hỏi mức độ phổ biến của chuyện đó ra sao. Chỉ vài cái như vậy thôi cũng có vẻ sẽ lấp khá nhiều ngữ cảnh
Có một thí nghiệm vui. Chỉ cần bảo LLM dùng thứ gì đó nó quen mơ hồ thôi. Ví dụ nếu yêu cầu “write a fib”, gần như mọi LLM vì đã được tinh chỉnh cho code sẽ trả lời bằng thuật toán dãy Fibonacci, dù với người không phải lập trình viên, nó có thể có nghĩa là “hãy nói dối một chút”
Tức là có sự nén diễn ra. Không cần giải thích chi tiết chính xác dãy Fibonacci là gì, chỉ với ba token mơ hồ cũng có thể biểu đạt kết quả
Vì thế bạn sẽ thấy độ dài prompt không quan trọng. Điều quan trọng là đúng từ, đúng tần suất và đúng thứ tự. Một prompt dài hai trang và một prompt hai câu có thể cho cùng một kết quả
Cho tới giờ tôi thành công với các skill ngắn và tập trung. Tôi coi chúng như những mảnh ngữ cảnh có thể tái sử dụng, nhưng giữ chúng nhỏ. Ví dụ vài đoạn nói về cách dùng Python trong dự án của tôi và cách chạy unit test
Tôi cũng có vài skill “info” ngắn chỉ chứa thông tin ngữ cảnh hữu ích để agent kéo lên khi cần, chứ không đưa chỉ thị cho nó
Quá nhiều skill cũng có thể thành vấn đề. Vì đến một lúc nào đó, danh sách tên skill và mô tả của chúng cuối cùng cũng sẽ đi vào ngữ cảnh
Ngay cả với ngữ cảnh LLM nhỏ 128k thì cũng chỉ khoảng 10%, còn với cửa sổ ngữ cảnh 1M của các mô hình lớn thì gần như chẳng đáng kể
Có lẽ ở đây tôi đang quá bảo thủ cũng nên. Vẫn còn nhiều thứ để khám phá
“Phần lớn công việc của một kỹ sư senior là những thứ không hiện ra trong diff”
Agent Skills là nỗ lực của Addy nhằm loại bỏ cả phần việc đó nữa. Xin nâng ly, Addy :P