1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Kỹ năng dành cho Claude Code và Codex giúp vừa làm agentic coding vừa phát triển chuyên môn của người dùng, không chỉ riêng dự án
  • Sau khi hoàn thành các công việc kiến trúc như tạo tệp mới, thay đổi schema, hoặc refactor, Claude sẽ gợi ý một bài luyện tập học tập dạng tùy chọn kéo dài 10–15 phút
  • Bài luyện tập sử dụng các kỹ thuật khoa học học tập như dự đoán, tạo sinh, luyện tập truy hồi, lặp lại ngắt quãng, đồng thời tạo ra các ví dụ đã giải dở dựa trên chính công việc thực tế trong dự án của người dùng
  • Được thiết kế để giảm các vấn đề mà công cụ lập trình AI có thể gây ra như chấp nhận mã được sinh sẵn, ảo giác về độ thành thạo, làm việc dồn dập quá lâu, thiếu siêu nhận thức và giảm tự kiểm tra
  • Claude sẽ hỏi theo kiểu như “Bạn có muốn thử một bài luyện tập ngắn về chủ đề này không? Mất khoảng 10–15 phút” và nếu người dùng chấp nhận thì sẽ bắt đầu bài luyện tập tương tác
  • Nguyên tắc thiết kế cốt lõi là Claude không tự trả lời câu hỏi của chính mình mà chờ người dùng nhập, nhằm tạo ra một chế độ phản tư và khám phá khác với agentic coding tốc độ cao
  • Các kiểu bài luyện tập gồm dự đoán→quan sát→phản tư, tạo sinh→so sánh, lần theo đường đi khi thực thi, dự đoán gỡ lỗi, giải thích cho lập trình viên mới và kiểm tra truy hồi nội dung từ các phiên trước
  • Điều kiện hạn chế được đề xuất hiện tại là không gợi ý lại cơ hội học tập trong cùng một phiên nếu người dùng đã từ chối bài luyện tập hoặc đã hoàn thành 2 bài trong phiên đó
  • Trên Codex, có thể thêm vào marketplace bằng codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git, bao gồm learning-opportunities, learning-opportunities-auto, và orient
  • Trên Claude Code, thêm qua Claude Code plugin marketplace, sau đó cài đặt /plugin install learning-opportunities@learning-opportunities và khởi động lại để kích hoạt
  • learning-opportunities-auto là hook tùy chọn để Claude cân nhắc gợi ý bài luyện tập sau mỗi lần git commit trên Linux và macOS; Windows cũng dùng được với thiết lập bổ sung
  • Kỹ năng orient tạo orientation.md khi học một repository mới và cung cấp các bài học được khuyến nghị dựa trên nghiên cứu về hiểu chương trình và khám phá codebase
  • Dùng cùng Learning-Goal sẽ phù hợp hơn; kỹ năng đó được giới thiệu là hỗ trợ đặt mục tiêu học tập tương tác bán cấu trúc bằng kỹ thuật MCII
  • Với thử nghiệm trong nhóm, có thể dùng kèm MEASURE-THIS.md; tài liệu này cung cấp các câu hỏi khảo sát đã được kiểm chứng, hướng dẫn diễn giải kết quả, mẫu “team boast” để chia sẻ với lãnh đạo và các nhắc nhở về độ nghiêm ngặt thống kê cho Claude.md
  • Được cấp phép theo Creative Commons Attribution 4.0 International License

1 bình luận

 
Ý kiến trên Hacker News
  • Tôi không rõ lắm về Skills, nhưng nhìn vào kho lưu trữ thì nó có vẻ có quá nhiều mã và văn bản mang tính trang trí so với một prompt ngắn trong script bash chạy sau khi commit
    Cốt lõi dường như là: người dùng vừa commit xong, nên nếu có file mới, thay đổi schema, quyết định kiến trúc, refactor, hoặc mẫu lạ, thì hãy đề xuất một bài luyện tập học tập 10–15 phút

    • Skills hữu ích để mô tả chuẩn hóa các quy trình công việc có thể lặp lại, tiết kiệm ngữ cảnh bằng cách tiết lộ dần, chia sẻ prompt, và gói các phần ít dùng nhưng không tất định thành những quy trình tất định như script
      Về mặt khái niệm, nên xem nó là phần mềm được nuôi lớn dần lên, chứ không phải phép màu do người khác tạo ra đem về dùng https://alexhans.github.io/posts/series/evals/building-agent...
      Trong các coding harness thường có skill tác tử SkillBuilder nên khá dễ tạo và có thể tiếp tục phát triển
      Tôi khuyên nên tự làm theo đúng khó khăn của mình, và cũng có ví dụ đơn giản cho thấy có thể đẩy độ chính xác của tự động hóa lên đủ cao thông qua đánh giá https://alexhans.github.io/posts/series/evals/sketch-to-text...
    • Phần lớn các công cụ kiểu này rốt cuộc chỉ là một file Markdown khác được nhét vào prompt, và với cách các mô hình ngôn ngữ lớn hoạt động thì đó là cấu trúc hoàn toàn bình thường
      Vì vậy tôi muốn khuyên mọi người tự tạo công cụ tương tự cho riêng mình bằng Claude. Ban đầu sẽ tốn token, nhưng về sau công cụ tự xây có thể giảm mạnh số token và số lần gọi cần cho công việc có ý nghĩa
      Bạn cũng có thể khóa việc gọi công cụ an toàn hơn, làm cho công việc của tác tử có thể retry, và giảm các kiểu lỗi. Điều này cũng tránh được tình huống laptop tắt giữa chừng rồi phải đốt rất nhiều token để tác tử khôi phục xem nó đã làm tới đâu
  • Tôi ngạc nhiên vì có những Skills thậm chí không viết quy trình chính xác hay việc cần làm, mà chỉ dừng ở mức priming như một bài diễn thuyết tạo động lực để mô hình cho ra văn bản tốt hơn trong một số tác vụ nhất định
    frontend design skill mà Claude dùng cũng gần như chỉ là yêu cầu chọn phông chữ đẹp và giữ thiết kế nhất quán, chứ không có chi tiết cụ thể như dùng phông nào hay tạo bảng màu và bố cục ra sao
    https://github.com/anthropics/claude-code/blob/main/plugins/...

  • Các tác tử viết mã có thể tạo ra khoản nợ lặp lại. Nếu cứ chấp nhận kết quả từ trợ lý lập trình mà không kiểm tra xem có đúng không, bạn sẽ mất dần hiểu biết về chính codebase của mình
    Các file ngữ cảnh như CLAUDE.md, giao thức migration, giao thức xác thực chỉ hoạt động tốt khi bạn hiểu chúng đủ sâu để cập nhật chúng một cách đúng đắn
    Tôi từng mù quáng chấp nhận code do tác tử tạo ra suốt hai tiếng, rồi quên mất codebase hoạt động thế nào đến mức không thể tạo file ngữ cảnh mới. Khoản nợ kỹ năng kiểu này không hiện ra trong diff, mà chỉ lộ ra khi đến lúc bạn phải dẫn dắt tác tử

    • Có lẽ không phải lặp lại mà là đệ quy thì đúng hơn
      Khi thực hiện thay đổi tính năng lớn, tốt hơn hết là trước khi để tác tử viết code, hãy thống nhất trong chat về vấn đề miền nghiệp vụ mà bạn đang cố giải quyết. Cảm giác giống như ngồi với người phụ trách từ công ty outsource để chốt lại điều mình muốn
      Sau đó cùng tác tử viết tài liệu thiết kế bằng bullet phân cấp thành file .md thật sự, để tác tử tạo và sửa phần lớn nội dung, nhưng phải xem xét kỹ các vấn đề và các quyết định mơ hồ để chốt xong các quyết định ở cấp độ thiết kế ngay tại đây
      Tiếp theo, yêu cầu nó biến đặc tả thiết kế thành bộ khung kiểm thử đặc tả BDD, rồi điền dần trong quá trình triển khai
      Ở giai đoạn triển khai, có thể thêm, sửa, xóa unit test và integration test, nhưng file đặc tả thiết kế và cấu trúc kiểm thử BDD được suy ra từ đó thì phải giữ cố định. Trước khi hoàn tất, các bài test BDD phải được điền bằng logic đúng với nhãn và đều phải pass
      Nếu dự án rất lớn, bạn có thể chạy các sprint lặp lại quy trình như định nghĩa yêu cầu nghiệp vụ mới, chỉnh sửa thiết kế, thêm bộ BDD mới. Hoặc giữa bước 2 và 3 có thể chia thiết kế thành các milestone, rồi chỉ tạo và giải quyết các mục BDD cho milestone hiện tại
      Nói cho cùng là dùng mô hình thác nước với LLM. Nếu toàn bộ quá trình kết thúc trong vòng một tiếng thì waterfall cũng khá dễ chịu
      Điểm cốt lõi là sau khi dự án hoặc milestone kết thúc, hãy để tác tử giải thích đoạn code nó viết trong chat, nhưng giới hạn không cho nó giải thích những gì đã lộ rõ trong thiết kế
      Khi đó bạn có thể biến các phần giải thích gây bất ngờ thành chú thích trong code, và kết quả sẽ là những chú thích trông như con người thực sự viết chứ không phải rác hình thức
  • Không có benchmark và đánh giá, làm sao biết nó cho kết quả tốt hơn /create-skill? Những bài test ngây thơ không tạo được niềm tin

    • Tôi nghĩ ở đây đang nói về phát triển kỹ năng của con người. Đây là tính năng cung cấp cơ hội học tập cho người dùng
      Có mô tả rằng khi bạn hoàn thành công việc kiến trúc, Claude sẽ đề xuất các bài luyện tập tùy chọn 10–15 phút dựa trên khoa học học tập có bằng chứng. Nó dùng các kỹ thuật như dự đoán, tạo sinh, luyện nhớ lại, lặp lại ngắt quãng, và cung cấp các ví dụ dở dang ngay trên công việc của chính dự án bạn
      Cái tên này hơi gây nhầm lẫn
    • Có vẻ bạn đã bị LLM ngấm quá sâu đến mức cứ nghe thuật ngữ liên quan là phản xạ kiểu Pavlov bật ra ngay
    • Việc nhắc đến đánh giá là hợp lý, nhưng giờ tôi muốn biết đang dùng gì hoặc đang tìm gì. Họ đang tự làm hay cũng dùng framework đánh giá có sẵn?
  • Nói cho những ai chưa bước vào cái hang thỏ này: Skills là các file Markdown có cấu trúc mô tả cách xử lý một tác vụ phạm vi hẹp
    Ví dụ nếu bạn viết API endpoint theo một cách cụ thể, bạn sẽ ghi quy trình đó vào skill. Sau này khi tác tử thấy skill đó và nhận định rằng nó liên quan đến ngữ cảnh chat hiện tại, nó sẽ nạp vào và làm theo chỉ dẫn
    Nó giống gọi công cụ, nhưng không phải là hàm có thể gọi mà là chỉ dẫn về cách thực hiện “kỹ năng” đó
    Ít nhất trong Cline mà tôi dùng, có thể định nghĩa Skills ở mức toàn cục hoặc cục bộ theo dự án

    • Skills cũng có phần header gọi là frontmatter, và một phần trong đó được chia sẻ ở đầu ngữ cảnh giống như file CLAUDE.md
      Theo những gì tôi nghe thì việc nạp skill có thể ảnh hưởng riêng tới ngữ cảnh, chẳng hạn vẫn còn tồn tại sau khi nén ngữ cảnh
      Nếu nạp nhiều skill, chúng thậm chí có thể ở trạng thái được nạp vĩnh viễn trong phiên
      Tôi thấy nó hợp với subagent. Subagent nạp skill, hoàn thành công việc rồi chỉ đưa ra kết quả, còn tác tử điều phối thì không cần biết chi tiết đó
  • Tôi không rõ chính xác adaptive dynamic textbook approach là gì. Tôi cần ví dụ
    Câu chuyện rằng nếu cứ nhận code được sinh ra và tự mình viết code ít đi thì bạn sẽ bỏ qua quá trình xử lý chủ động để xây dựng hiểu biết là hoàn toàn đúng

  • Tôi không hiểu vì sao người ta chịu khó nghĩ ra những ý tưởng hay thế này mà lại không chèn link demo hoặc đầu ra mẫu. Đây là kiểu mẫu tôi thấy mỗi ngày trên HN
    Muốn xem skill này thực sự trông ra sao thì chỉ còn cách tự tải về rồi chạy à? Tôi không muốn làm vậy

    • Hiện tại việc dùng skill vẫn cho cảm giác kém ổn định hơn nhiều so với chỉ dẫn rõ ràng trong AGENTS.md
      Tôi hiểu ý tưởng tránh phình ngữ cảnh bằng cách không thêm skill khi không liên quan, nhưng nếu AGENTS.md không có chỉ dẫn tường minh thì không có gì đảm bảo tác tử sẽ dùng skill. Khi đó nó gần như chẳng khác gì một file Markdown được tham chiếu ở đâu đó
      Khi làm https://www.agentkanban.io, một bảng công việc tích hợp GitHub Copilot, tôi đã thử nghiệm rất nhiều về chỗ đặt chỉ dẫn
      Cấu trúc thấp hơn một bậc so với AGENTS.md hoạt động khá tốt. Vì cần để tác tử lấy ID theo từng công việc một cách ổn định, tôi đã chốt ở cách đặt INSTRUCTION.md bên trong file do công cụ quản lý, và cũng giảm được việc làm bẩn AGENTS.md
      Tôi cũng thử Skills nhưng chúng bị bỏ qua quá thường xuyên, nên khó làm cho công cụ chạy ổn định như cách hiện tại
    • Vì có ngay SKILL.md ở đó nên cứ đọc là biết nó làm gì
  • Tôi thật sự thích ý tưởng này. Tôi từng bảo Claude dùng giáo trình và tài liệu mã nguồn mở để tự tạo giáo trình ngay tại chỗ
    Tôi tò mò liệu có thể mở rộng skill này sang lĩnh vực học tập và ứng dụng tổng quát hơn hay không, hay nó chỉ chuyên cho code

  • Phản ứng ở đây khá thú vị, nhưng có vẻ đa số đang bỏ lỡ điểm chính
    Với tôi, bài học quan trọng là học bằng cách quan sát người khác dùng Skills thế nào. Hôm qua tôi xem khóa học về dùng tác tử của Matt Pocock, trong đó ông ấy trình bày Skills theo kiểu dùng skill “grill-me” để phát triển tài liệu yêu cầu sản phẩm
    Tôi sẽ không làm y nguyên như ông ấy, nhưng điều đó đã cho tôi ý tưởng về cách tạo yêu cầu và triển khai
    Theo cách diễn đạt của các kỹ sư Anthropic, Claude giống một kỹ sư có năng khiếu nhưng thiếu chuyên môn sâu. Skills là các thư mục và file để xây dựng chuyên môn đó
    Một điều nữa tôi học được từ Pocock là ngữ cảnh hay kích thước token càng dài thì phản hồi càng có xu hướng ngớ ngẩn hơn. Vì vậy Skills là một cách khác để trình bày vấn đề cho LLM ở dạng nén và nhận lại phản hồi được tối ưu hơn
    Claude cũng có đặc tính hành vi riêng. Nếu ai đó lặp đi lặp lại việc tạo skill thì có thể chúng sẽ không chuyển giao tốt sang người dùng khác, vì mỗi người nói chuyện với Claude theo cách khác nhau
    Vì vậy tôi còn do dự trong việc chia sẻ thư mục skill của mình cho đồng nghiệp. Thay vào đó tôi định demo những gì mình đã làm để họ thấy những gì có thể làm được, rồi tự tìm ra quy trình riêng
    Giá trị nằm ở việc nhìn cách người khác tạo bằng Claude rồi bắt chước theo cách của riêng mình. Nó giống như khi mới học lập trình, ta chép lại code trong sách C của Kernighan và Ritchie, sửa thử để hiểu cách nó chạy, rồi sau này chỉnh cho hợp mục đích
    Một lý do khác tôi nhắc đến đặc tính hành vi là vì tác giả là nhà tâm lý học, nên thật thú vị khi cách họ tương tác với Claude có thể khá khác với lập trình viên
    Liên quan đến đó, nghe nói tác giả và nhiều chuyên gia ở nhiều lĩnh vực đã rời Twitter từ lâu, nên tôi định cài bsky hoặc Mastodon để theo dõi họ. Tôi nghĩ việc quan sát cách các chuyên gia không phải lập trình viên dùng LLM là rất quan trọng

  • Ý tưởng hay nên sáng nay tôi cũng thử tìm hiểu vài thứ
    Khi dùng AI quá nhiều, tôi có cảm giác rất rõ như bị rò rỉ chất xám, và dù đây không phải giải pháp hoàn hảo, tôi nghĩ chỉ cần làm vài bài luyện tập mỗi ngày cũng đã có thể giúp được khá nhiều