Biến Claude Code thành công cụ hằng ngày: Claude.md, Skills, Subagents, Plugins, MCP

 (arps18.github.io)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Năng suất của Claude Code khác biệt lớn không nằm ở prompt mà ở cách tích lũy và kiểm chứng bộ nhớ, lệnh tùy chỉnh, phiên song song và cấu hình dự án
  • CLAUDE.md nên được vận hành như một hạ tầng tích lũy ngắn gọn, tập trung vào kiểm chứng; thêm quy tắc sau mỗi lỗi có thể giúp giảm lặp lại cùng một sai sót
  • .claude/ là một hệ thống cấu hình phân tầng chứa CLAUDE.md, rules, skills, commands, agents và cấu hình MCP, được áp dụng tách biệt theo phạm vi dự án và toàn cục
  • Skills biến các công việc lặp lại thành chuyên môn có thể tái sử dụng, còn subagents thực hiện review, debug và migration trong ngữ cảnh riêng biệt
  • Khi kết hợp Plugins, MCP, /goal, /rewind, /batch và cả worktree song song, Claude Code trở thành một tác nhân phát triển được cấu hình và vận hành

Xử lý Claude Code như một tác nhân có thể kiểm chứng

  • Chênh lệch năng suất của Claude Code đến từ cách tích lũy bộ nhớ, lệnh tùy chỉnh, phiên song song và cấu hình dự án hơn là từ những prompt đơn thuần
  • Nguyên tắc cốt lõi là giúp Claude có thể tự kiểm chứng kết quả của mình; Boris Cherny và đội ngũ Anthropic cho rằng chỉ riêng cách này cũng có thể cải thiện chất lượng lên 2–3 lần
  • Quy trình làm việc phù hợp là khám phá → lập kế hoạch → triển khai
    • Chế độ lập kế hoạch, truy cập bằng cách nhấn Shift+Tab hai lần, phù hợp cho việc khám phá chỉ đọc
    • Cách làm được khuyến nghị là đọc file, nắm luồng xử lý và mô hình dữ liệu trước, rồi mới lập kế hoạch và thực thi
    • Với các công việc chạm vào nhiều file, chế độ lập kế hoạch rất hữu ích; còn với chỉnh sửa nhỏ thì có thể bỏ qua
  • Có thể coi chế độ lập kế hoạch như một tài liệu thiết kế có thể được rà soát trước khi triển khai
    • Một Claude có thể viết kế hoạch, sau đó một Claude thứ hai trong phiên mới sẽ review nó như một staff engineer không bị thiên lệch
    • Nếu quá trình triển khai đi chệch hướng, nên quay lại chế độ lập kế hoạch và lập kế hoạch lại, bao gồm cả bước kiểm chứng
    • Có thể mở kế hoạch của Claude trong editor bằng Ctrl+G và chỉnh sửa trực tiếp trước khi triển khai
  • Tham chiếu chính xác hiệu quả hơn chỉ dẫn mơ hồ
    • Thay vì “xem module auth”, hãy chỉ định trực tiếp file như @src/auth/login.py
    • Với lỗi, thay vì dán nội dung, hãy truyền qua pipe như cat error.log | claude
  • Cat Wu cho rằng Claude Code hoạt động tốt nhất khi được đối xử như một kỹ sư được giao việc hơn là một pair programmer được chỉ dẫn từng dòng
  • Khi Claude mắc lỗi, có thể thêm vào cuối prompt câu “Update CLAUDE.md so you do not repeat this.” để nó lưu lại quy tắc ngăn lỗi đó lặp lại

Thư mục .claude và phân tầng cấu hình

  • .claude/ không chỉ là thư mục chứa CLAUDE.md mà là một hệ thống cấu hình phân tầng
  • Cấu hình được chia làm hai phạm vi
    • Phạm vi dự án: đặt trong .claude/ của repo và commit vào git để chia sẻ với cả nhóm
    • Phạm vi toàn cục: đặt trong ~/.claude/ và áp dụng cho mọi dự án trên máy cục bộ
  • Có thể hiểu file cấp dự án là thứ mô tả dự án, còn file cấp toàn cục là mô hình mô tả sở thích và cách làm việc của người dùng
  • Vai trò của các file chính
    • CLAUDE.md: dùng được ở cả phạm vi dự án lẫn toàn cục, là chỉ dẫn được nạp ở mọi phiên
    • CLAUDE.local.md: ghi chú cá nhân chỉ dành cho dự án và nằm trong .gitignore
    • settings.json: quyền hạn, hooks, biến môi trường và cấu hình model mặc định
    • settings.local.json: phần ghi đè cá nhân và tự động được đưa vào .gitignore
    • .mcp.json: cấu hình máy chủ MCP được nhóm chia sẻ trong dự án
    • skills/<name>/SKILL.md: prompt tái sử dụng được gọi bằng /name
    • commands/*.md: lệnh slash dạng một file duy nhất
    • agents/*.md: định nghĩa subagent
    • rules/*.md: chỉ dẫn theo chủ đề, có thể áp dụng theo đường dẫn
  • CLAUDE.md được nạp theo kiểu tầng bậc
    • Trong monorepo, root/CLAUDE.md và root/services/billing/CLAUDE.md có thể cùng được nạp
    • Cách này phù hợp với codebase có quy ước khác nhau theo từng thư mục
  • .claude/rules/*.md phù hợp cho các chỉ dẫn theo đường dẫn
    • Quy tắc chỉ cần cho thư mục migration nên được đặt ở .claude/rules/migrations.md cùng glob, thay vì nhét vào CLAUDE.md làm phình toàn bộ phiên
  • Với công việc mới, skills được khuyến nghị hơn commands
    • .claude/commands/*.md và .claude/skills/<name>/SKILL.md đều có thể tạo lệnh slash
    • skills hỗ trợ file phụ trợ, disable-model-invocation, công cụ được cho phép và ghi đè agent
  • Có thể dùng claude project purge ~/path/to/repo --dry-run để kiểm tra trạng thái cục bộ mà Claude đang giữ cho một dự án cụ thể

Vận hành CLAUDE.md ngắn gọn và tập trung vào kiểm chứng

  • CLAUDE.md được nạp khi bắt đầu mỗi phiên, nên nếu viết dở Claude sẽ lặp lại cùng sai lầm, còn nếu viết tốt thì kết quả từ cùng một prompt có thể cải thiện đáng kể
  • Nguyên tắc quan trọng nhất là giữ cho nó ngắn
    • Cách được khuyến nghị là với mỗi dòng hãy tự hỏi “nếu bỏ dòng này đi thì Claude có mắc lỗi không?”, nếu không thì xóa nó
  • Khi để Claude tự viết quy tắc cho chính nó, hiệu ứng tích lũy sẽ xuất hiện
    • Khi Claude làm sai, nếu chỉ thị “Update CLAUDE.md so you do not repeat this.” thì Claude có thể tóm tắt lỗi đó thành một quy tắc chính xác
    • Lặp lại điều này trong vài tuần, các bẫy của dự án sẽ tích lại thành một danh sách quy tắc
  • CLAUDE.md thực tế của đội Claude Code tập trung vào lệnh build và thứ tự kiểm chứng
    • Dùng bun, không dùng npm
    • Ghi rõ thứ tự typecheck nhanh sau khi sửa, test, lint trước khi commit và kiểm chứng toàn bộ trước PR
    • Không đưa vào sở thích về style, tour codebase hay các nội dung chung chung
  • Ngay cả trong comment PR, cũng có thể dùng @claude để thêm quy tắc trực tiếp
    • Ví dụ: @claude add to CLAUDE.md to never use enums, always prefer literal unions
    • Review PR từ đó dẫn tới cải thiện CLAUDE.md, tạo ra dòng chảy “Compounding Engineering”
  • Một CLAUDE.md tốt tập trung vào các thông tin sau
    • Style code: dùng ES modules thay vì CommonJS
    • Workflow: chạy bun run typecheck, không push trực tiếp vào main
    • Kiến trúc: route API bắt buộc phải đi qua middleware cụ thể
    • Gotchas: khác biệt giữa User và UserRecord, và việc formatCurrency giả định USD
  • Những thứ không nên đưa vào CLAUDE.md
    • Quy ước ngôn ngữ chuẩn
    • Mô tả codebase theo từng file
    • Hướng dẫn dài
    • Tài liệu API
    • Nội dung thay đổi thường xuyên
  • Các cách diễn đạt như IMPORTANT, YOU MUST có thể tăng mức độ tuân thủ, nhưng nên dùng hiếm để giữ được sức nặng
  • Có thể dùng cú pháp @path để nhập file khác, giúp CLAUDE.md ngắn gọn mà vẫn liên kết được thông tin chi tiết
    • Ví dụ: See @README.md for project overview and @package.json for scripts.
    • Ví dụ: @~/.claude/my-preferences.md

Tích lũy phản hồi cá nhân bằng CLAUDE.local.md

  • CLAUDE.local.md được nạp cùng vị trí và theo cùng cách như CLAUDE.md, nhưng không được rời khỏi máy cục bộ và cần thêm vào .gitignore
  • Nếu đưa comment review PR vào CLAUDE.local.md ngay, các phản hồi cá nhân lặp lại sẽ được tích lũy thành một file quy tắc cá nhân
  • Ví dụ về quy tắc
    • Mỗi SQS consumer mới cần có DLQ và cảnh báo trong cùng PR
    • Ưu tiên Optional<T> hơn là trả về null
    • Test cho endpoint mới phải bao gồm case auth-failure
    • Khi thêm endpoint thì cũng phải cập nhật OpenAPI spec
  • Nên tách riêng phản hồi theo dự án và các mục sửa thói quen cá nhân trong file
  • Sau vài tuần, nên xóa những mục đã thành thói quen và chỉ giữ lại những điều vẫn đang trong quá trình rèn luyện

Skills: đơn vị chuyên môn có thể tái sử dụng

  • Skills là đơn vị chuyên môn có thể tái sử dụng giúp biến Claude Code từ một “agent có thể làm mọi thứ” thành một agent giỏi các tác vụ cụ thể của dự án

  • Cấu trúc Skill

    • skill là một thư mục dưới .claude/skills/<name>/ hoặc ~/.claude/skills/<name>/
    • SKILL.md trong thư mục chứa frontmatter và hướng dẫn
    • tên thư mục sẽ trở thành lệnh slash
    • ví dụ, nếu tạo ~/.claude/skills/summarize-changes/SKILL.md thì /summarize-changes sẽ dùng được trong mọi phiên

  • Vì sao Skill mạnh mẽ

    • Công khai dần dần: khi bắt đầu phiên, chỉ phần mô tả frontmatter được nạp; toàn bộ SKILL.md và các tệp phụ trợ chỉ được nạp khi thực sự cần
    • Tổ chức theo thư mục: có thể gói chung template, tài liệu tham khảo, script và cấu hình
    • Shell nội tuyến: các dòng bắt đầu bằng ! sẽ chạy lệnh và chèn đầu ra tại thời điểm gọi

  • Tùy chọn frontmatter

    • description: mô tả khi nào nên dùng skill này
    • disable-model-invocation: true: chỉ cho phép chạy khi người dùng nhập rõ ràng /my-skill
    • allowed-tools: giới hạn các công cụ được dùng như Read, Grep, Bash
    • agent: có thể chạy ở một chế độ agent cụ thể
    • với các skill có tác dụng phụ như triển khai, disable-model-invocation: true là phù hợp

  • Ví dụ skill quy ước Go API

    • một skill tạo scaffold HTTP handler mới cho đội ngũ dịch vụ Go có thể đặt cùng SKILL.md, templates/handler.go.tmpl, examples/healthz.go
    • ví dụ về quy tắc có thể chứa các quy ước riêng của dự án như ưu tiên Go 1.22 và router chi, truy vấn kiểu hóa bằng sqlc, ghi log có cấu trúc với zap, assertion của testify và các bài test table-driven
    • ví dụ về gotcha là nội dung giúp ngăn lỗi lặp lại, chẳng hạn chi.URLParam trả về "" khi thiếu param, httperr.Wrap không ghi log, và pgtype.Text cần kiểm tra .Valid

  • Những Skills đáng cài

    • mattpocock/skills: kho skills phổ biến với khoảng 100k sao
      • /grill-me: phỏng vấn kế hoạch trước khi viết mã
      • /tdd: ép buộc nghiêm ngặt quy trình red-green-refactor
      • /diagnose: debug theo thứ tự tái hiện, tối giản hóa, giả thuyết, sửa lỗi, kiểm thử hồi quy
      • cài đặt: npx skills@latest add mattpocock/skills
    • Jeffallan/claude-skills: cung cấp 66 hồ sơ theo ngôn ngữ như go-pro, python-pro, java-architect, typescript-pro, rust-engineer, sql-pro
    • skills chính thức của Anthropic
      • /code-review: bốn agent song song kiểm tra diff và chỉ báo cáo các phát hiện dựa trên điểm độ tin cậy
      • /simplify: xem lại mã gần đây dưới góc độ khả năng tái sử dụng và hiệu quả
      • /batch: phân phối migration cho nhiều agent song song và xử lý trong worktree riêng của mỗi agent
      • /webapp-testing: cho phép Claude dùng Playwright để kiểm thử ứng dụng web cục bộ
    • các tác vụ lặp lại hơn một lần mỗi ngày nên được chuyển thành skill
    • nếu commit skills vào git, chúng sẽ trở thành tri thức tổ chức của nhóm, và kỹ sư mới sẽ có ngay các thực hành đã tích lũy khi vừa clone kho lưu trữ

Subagents: giao việc tập trung trong ngữ cảnh riêng

  • subagent chạy với cửa sổ ngữ cảnh riêng và quyền công cụ riêng, sau đó trả về bản tóm tắt
  • giá trị cốt lõi là dù đọc nhiều tệp, chúng cũng không làm đầy ngữ cảnh của phiên chính
  • subagent là các tệp markdown dưới .claude/agents/ hoặc ~/.claude/agents/, và khai báo name, description, tools, model trong frontmatter

  • Cấu hình agent /pr-review

    • có thể định nghĩa để tìm bug, vấn đề bảo mật, edge case bị bỏ sót và vi phạm quy ước dự án bằng cách so sánh diff của branch hiện tại với main
    • cấp quyền thiên về đọc với tools: Read, Grep, Glob, Bash
    • có thể dùng model: opus để dùng mô hình mạnh hơn cho các lần review rủi ro cao
    • quy trình gồm git diff main...HEAD, git log main..HEAD --oneline, đọc toàn bộ tệp, đối chiếu CLAUDE.md, CLAUDE.local.md, .claude/rules/
    • đầu ra có thể nhóm theo Critical / High / Medium / Low, kèm file, line, issue, suggested fix, rồi kết thúc bằng một trong SHIP, FIX FIRST, REWORK

  • Thiết kế để tăng tỷ lệ tín hiệu trên nhiễu

    • nếu reviewer sửa mã, họ sẽ có thiên kiến bảo vệ chính phương án sửa của mình, nên công cụ chỉ đọc là phù hợp
    • nếu ghi rõ trong phần “Do NOT flag” rằng không nêu các sở thích về style không có trong quy tắc dự án, đề xuất refactor cho mã đang chạy tốt, hoặc các mục ngoài diff, thì sẽ giảm nhiễu

  • Các mẫu subagent thường dùng

    • nhóm Claude Code check-in các cấu hình build-validator, code-architect, code-simplifier, oncall-guide, verify-app
    • security-reviewer: kiểm tra injection, auth, secrets, insecure deserialization
    • test-writer: tạo test, có thể tạo vòng lặp với code-reviewer
    • debugger: lần theo test lỗi đến tận nguyên nhân gốc rễ
    • performance-auditor: profiling luồng xử lý và truy vấn
    • migration-writer: tạo DB migration theo đúng quy ước dự án
    • release-notes-writer: viết changelog từ lịch sử commit
    • cách để Session A triển khai rồi subagent code-reviewer xem xét trong ngữ cảnh mới giúp giảm thiên kiến khi triển khai
    • thêm isolation: worktree vào frontmatter sẽ cho phép chạy subagent trong git worktree riêng, hữu ích khi phân phối migration cho nhiều agent song song

Plugins và Marketplace

  • Plugins gói skills, hooks, subagents và MCP servers thành một đơn vị có thể cài đặt
  • Có thể mở trình duyệt marketplace bằng /plugin
  • Có thể thêm marketplace cộng đồng bằng /plugin marketplace add owner/repo

  • Các mục đáng cài từ sớm

    • /code-review: chạy bốn agent song song; hai agent phân tích việc tuân thủ CLAUDE.md, một agent tìm bug, và một agent phân tích ngữ cảnh dựa trên git blame
    • /feature-dev: chuyển feature brief thành mã đang hoạt động qua 7 bước requirements → exploration → architecture → implementation → testing → review → docs
    • Plugin language server: cung cấp điều hướng symbol chính xác và tự động diagnostics sau khi chỉnh sửa, được đội ngũ gọi là plugin có tác động lớn nhất
    • /security-guidance: skill bảo mật chính thức của Anthropic, giúp phơi bày các mối lo ngại bảo mật trước khi ship
    • Tính đến giữa năm 2026, có hơn 1.000 plugins trên hơn 75 marketplace
    • Các nhóm plugin chính là Git workflow, code intelligence (LSP), documentation generators, testing, browser automation (Playwright), design system (Figma), observability (Sentry, Datadog)
    • Nếu đặt .mcp.json dùng chung cho nhóm cùng các plugin đã tuyển chọn, kỹ sư mới có thể làm việc hiệu quả chỉ trong vài phút sau khi clone repository

Các lệnh Claude Code ảnh hưởng lớn đến năng suất

  • Nhiều người dùng chỉ học /clear, /compact, /init rồi dừng lại, nhưng các lệnh khác cũng ảnh hưởng rất lớn đến năng suất hằng ngày

  • Các lệnh chính

    • /insights: phân tích mẫu sử dụng, đáng chạy khoảng mỗi tháng một lần
    • /compact <hint>: nén phiên làm việc, và hint kiểm soát những gì sẽ được giữ lại
    • /copy: sao chép phản hồi gần nhất và cung cấp interactive picker cho code block
    • /rewind: undo cho toàn bộ phiên, khôi phục mã, cuộc trò chuyện, hoặc cả hai
    • /btw: câu hỏi phụ không đi vào lịch sử hội thoại
    • /context: trực quan hóa mức sử dụng context
    • /export <file>: dump cuộc trò chuyện ra tệp
    • /branch: fork phiên làm việc cho các thử nghiệm rủi ro
    • /batch: phân phối công việc bằng các agent song song trên toàn bộ worktree
    • /loop <interval>: chạy lặp Claude trong tối đa 3 ngày
    • /schedule: phiên bản cloud của /loop, vẫn chạy ngay cả khi laptop đã đóng
    • /teleport: chuyển phiên giữa terminal và web
    • /focus: ẩn các tool call trung gian và chỉ hiển thị kết quả cuối cùng
    • /voice: nhập liệu bằng giọng nói
    • --bare: tăng tốc khởi động tối đa 10 lần khi dùng claude -p ở chế độ non-interactive

  • Phân biệt /compact và /clear

    • Với công việc hoàn toàn mới, nên dùng /clear và một brief được viết mới
    • Nếu là công việc liên quan và vẫn cần context, thì /compact kèm hint là phù hợp
    • /compact là bản tóm tắt có mất mát do LLM tạo ra, còn /clear là brief do người dùng tự viết, nên việc phân biệt là quan trọng

  • Cách dùng /rewind

    • Nếu Claude đi sai hướng, tốt hơn là không nên viết tiếp kiểu “cách đó không được, hãy thử X”
    • Viết tiếp như vậy sẽ làm bẩn context, nên phù hợp hơn là rewind rồi prompt lại với những điều đã học được
    • Có thể mở rewind bằng cách nhấn Esc hai lần
    • ! có thể dùng như shell escape
    • Có thể chạy ngay như !git status, !npm test, và đầu ra sẽ đi vào context
    • Thiết lập CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 dùng để buộc compaction sớm hơn trước khi context rot xuất hiện quanh mốc 300–400k tokens trên model 1M

  • Mẫu fan-out

    • Trước tiên tạo task list và thử nghiệm trên ba tệp
    • Sau khi sửa prompt, áp dụng lên hàng nghìn tệp
    • Ví dụ:
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --bare
done

/goal: vòng lặp lặp lại có tích hợp điều kiện hoàn thành

  • /goal đặt điều kiện hoàn thành và mỗi khi Claude định dừng, nó sẽ kiểm tra điều kiện đó dựa trên transcript
  • Điều kiện phải có thể kiểm chứng và có tính quyết định
    • lệnh test
    • mã thoát CLI
    • trạng thái tệp
  • Ví dụ:
/goal all tests in test/auth pass and the lint step is clean
/goal all integration tests in tests/api pass without flaking 3 runs in a row
/goal the OpenAPI spec validates and matches the actual response shapes
/goal docker compose up runs cleanly and the healthcheck endpoint returns 200
/goal coverage on src/billing/ is above 80% and all new tests are not placeholders
  • Các điều kiện mơ hồ như “mã tốt” sẽ không hoạt động
  • Các tính năng nên dùng cùng
    • /loop: lặp theo khoảng thời gian để giảm backlog
    • /schedule: chạy định kỳ trên cloud
    • Hook Stop: đặt gate bằng test suite riêng hoặc CI endpoint
    • Auto mode: để goal dài không bị dừng bởi permission prompt
  • Tổ hợp /goal + auto mode + /focus hướng tới quy trình đặt một brief rõ ràng và điều kiện hoàn thành, rồi khi quay lại thì PR đã xong

Tận dụng MCP như công cụ nhận biết hệ thống

  • MCP(Model Context Protocol) giúp Claude Code vượt ra ngoài vai trò coding agent để trở thành một agent có thể nhận biết các hệ thống bên ngoài
  • MCP server phơi bày các công cụ bên ngoài như database, design tool, error tracker, notes cho Claude theo cách tiêu chuẩn
  • Không có MCP, Claude đọc file và thực thi lệnh, nhưng khi dùng MCP thì có thể xử lý Linear ticket, Postgres query, Figma component, Sentry stack trace, Obsidian vault mà không cần rời khỏi terminal

  • Các MCP thường dùng trong kỹ thuật

    • GitHub: quản lý repo, PR, issue, tìm kiếm code
    • Context7: tài liệu library mới nhất, thêm use context7 vào prompt
    • Sentry: ngữ cảnh lỗi thực tế, stack trace, breadcrumbs
    • Linear: đọc và tạo ticket, cập nhật status
    • Playwright: browser automation dựa trên accessibility snapshot
    • Figma: cây thiết kế trực tiếp, auto-layout, spacing tokens, component refs
    • Postgres / Supabase: query trực tiếp vào DB dev
    • Slack: đọc thread, tóm tắt thảo luận, soạn nháp phản hồi
    • local server dùng stdio, còn vendor-hosted server dùng HTTP có OAuth
    • Ví dụ:
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
  • MCP dùng chung cho team được đặt trong .mcp.json ở project root, còn MCP cá nhân đặt trong ~/.claude.json
  • Nếu cài quá nhiều MCP, danh sách tool mà Claude phải cân nhắc sẽ lớn lên và có thể làm giảm chất lượng ra quyết định
  • Bộ khởi đầu phù hợp là GitHub, Context7, và thêm một hoặc hai MCP theo domain
  • /mcp là điểm kiểm tra đầu tiên trong Claude Code để xem các server đang hoạt động và trạng thái kết nối

Cấu trúc bộ nhớ 3 tầng của Obsidian và Claude Code

  • Tổ hợp Obsidian + Claude Code mạnh nhất khi được dùng như một kiến trúc bộ nhớ ba tầng, chứ không chỉ đơn giản là “Claude đọc vault”

  • Thiết lập

    • Cài obsidian-claude-code-mcp vào Obsidian
    • plugin phơi bày vault qua local WebSocket ở port 22360
    • Claude Code tự động phát hiện nó
    • Thêm CLAUDE.md vào vault để mô tả folder structure

  • Cấu trúc thư mục

    • 00-Inbox/: ghi nhận thô
    • 10-Daily/: một note cho mỗi ngày
    • 20-Projects/: note cho các project đang hoạt động
    • 20-Projects/billing-v2/README.md: mục tiêu, trạng thái, câu hỏi còn mở
    • 20-Projects/billing-v2/decisions/: ADR
    • 20-Projects/billing-v2/sessions/: log theo từng Claude session
    • 30-Decisions/: ADR dùng chung giữa nhiều project
    • 40-Atoms/: kiến thức và links có thể tái sử dụng
    • 90-Archive/: lưu trữ

  • Hot storage

    • Mỗi Claude session ghi một log có timestamp vào 10-Daily/<today>.md
    • Có thể dùng hook Stop để append một bản tóm tắt có cấu trúc khi agent kết thúc

  • Warm storage

    • Mỗi project có một folder dưới 20-Projects/
    • Trước session mới, Claude đọc README của project và 2~3 session log gần nhất để khôi phục context
    • Đây là luồng tái dựng context của 2 tuần trong vòng chưa đến 30 giây

  • Cold storage

    • Các quyết định kiến trúc được nâng cấp thành ADR trong 30-Decisions/
    • Kiến thức có thể tái sử dụng được tinh lọc vào 40-Atoms/ và nối với nhiều project bằng wikilinks

  • Ví dụ workflow hằng ngày

    • What is in my inbox? Summarize and suggest where each item belongs.
    • Check 30-Decisions/ for anything related to retry policies.
    • Read the last 3 session logs for billing-v2. Tell me where I left off.

Tối ưu hóa luồng phát triển hằng ngày

  • Feature mới

    • bắt đầu bằng plan mode
    • dùng Ctrl+G để chỉnh sửa plan
    • sau khi triển khai, gọi subagent /pr-review hoặc review bằng một Claude session mới

  • Bug

    • trước hết hãy tái hiện lỗi
    • pipe lỗi bằng cat error.log | claude
    • yêu cầu Claude viết bài test thất bại trước rồi mới sửa
    • đừng để test cho phép bản sửa kết thúc bằng phỏng đoán

  • Migration và thay đổi quy mô lớn

    • /batch sẽ phỏng vấn về thay đổi rồi phân tán công việc sang các agent chạy song song
    • mỗi agent test trong worktree riêng của mình và tạo PR

  • Code lạ

    • dùng subagent như trong câu “Use a subagent to investigate how our auth handles token refresh.”
    • subagent đọc hàng chục file trong context riêng của nó rồi trả về bản tóm tắt, nhờ đó main session vẫn gọn sạch

  • Session song song

    • Boris và team xem việc chạy Claude session trên 3~5 git worktree khác nhau là cú mở khóa năng suất lớn nhất
    • có thể dùng chế độ xem agent của claude agents như một control plane

  • Mẫu Writer/Reviewer

    • Session A triển khai
    • Session B review với context hoàn toàn mới
    • mang phần review quay lại để sửa và lặp lại

  • compact ở mỗi milestone

    • khi hoàn tất một logical chunk, hãy chỉ rõ phần cần giữ lại như /compact Preserve the decisions made, files changed, and test commands.
    • không được để Claude tuyên bố thành công mà không có bằng chứng như test, screenshot, hay output lệnh thực tế
    • khoảng cách trust-then-verify được nêu là nguyên nhân lớn nhất dẫn đến kết quả kém

Các mẫu mà đội ngũ Anthropic dùng lặp đi lặp lại

  • Nếu để Claude có thể tự kiểm chứng output của mình, nó có thể lặp lại cho đến khi kết quả trở nên tốt hơn
  • Boris dùng Opus và mức effort high hoặc xhigh cho hầu hết tác vụ
    • Lý do là nếu mô hình nhỏ hơn đòi hỏi nhiều lần chỉnh sửa hơn thì tổng thể có thể chậm hơn
  • Chạy song song 3~5 session
    • Dùng worktree thay vì checkout
    • Có thể dùng claude --worktree hoặc ứng dụng Desktop
    • agent view giúp gom các session song song lại
  • Duy trì một notes directory cho mỗi project và cập nhật sau mỗi PR
    • Nếu để CLAUDE.md trỏ tới notes directory đó, tri thức mà codebase tự tích lũy sẽ tăng dần
  • Có thể tạo slash command /techdebt để tìm và loại bỏ mã trùng lặp ở cuối mỗi session
  • CLAUDE.md của nhóm được chia sẻ và được sửa nhiều lần mỗi tuần
    • Họ xem đây là một tài liệu sống, nơi ai thấy Claude làm sai sẽ thêm quy tắc vào
  • Playwright MCP phù hợp cho các thay đổi UI
    • Claude có thể mở trình duyệt, nhấp và tự kiểm chứng
  • plugin language server giúp bắt type error và unused imports sau mỗi lần chỉnh sửa, và được xem là plugin có tác động lớn nhất
  • /voice có thể giúp prompt chi tiết hơn
    • Kèm theo lý do là nói nhanh gấp 3 lần gõ
  • Cách dùng Ctrl+G để chỉnh sửa Claude plan trong editor trước khi triển khai nhanh hơn việc nhập correction trong chat
  • Boris cho Claude vẽ ASCII diagram khi cần hiểu một protocol và codebase chưa quen thuộc

Tài liệu tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • commands, skills, subagents, plugins đang quá phân tán nên cần được sắp xếp lại
    Ví dụ chỉ riêng việc review code thôi đã có tới năm lựa chọn: .claude/commands/review.md, skill /code-review, subagent /pr-review, plugin /code-review, hoặc đơn giản là bảo Claude review giúp
    Rốt cuộc phần lớn chỉ là các biến thể của chèn prompt soạn sẵn, khác nhau chủ yếu ở chỗ prompt được cài ở đâu và chạy trong ngữ cảnh nào
    Cũng thiếu lời khuyên về việc nên chọn cái nào là tốt nhất, best practice thì vẫn chưa rõ ràng, còn cá nhân tôi thấy chỉ cần nhờ Claude review code trực tiếp cũng đã đủ tốt rồi
    Ngoài ra, lời khuyên kiểu “hãy cài plugin language server” cũng không đúng với trải nghiệm của tôi. Tôi đã cài LSP cho Rust, Python, Dart vào Claude Code và Codex, nhưng sau hai tháng chạy hàng trăm session rồi xem log thì chỉ có đúng một lần gọi tool LSP thực sự, trong khi Rust analyzer/Dart analysis server/Ty LSP lại thường xuyên làm thiếu RAM
    Cuối cùng tôi đã gỡ LSP, và để agent tự gọi trực tiếp ripgrep, cargo clippy, dart analyze, ty check các thứ cũng là quá đủ

    • Tôi là Boris từ team CC, và tôi đồng ý với điểm này, hiện bọn tôi đang làm việc để hợp nhất lại. Sau này sẽ hướng tới chỉ còn một skill /code-review tích hợp sẵn
      Ở bản mới nhất, /code-review sẽ cho review cân bằng, /code-review --fix sẽ vừa review vừa sửa, còn /code-review low|medium|high|xhigh|max cho phép chọn mức độ nỗ lực
      /code-review ultra là chế độ review cực kỳ kỹ nhưng tốn kém, giá khoảng $3~20 cho mỗi lần review tùy độ phức tạp, với mục tiêu bắt được ổn định hơn 99% bug
      Nếu ai có ý tưởng để làm nó dễ dùng hơn nữa thì tôi rất muốn nhận phản hồi
    • Tôi đã nghĩ một thời gian rằng skills là một lớp trừu tượng tệ. Định nghĩa về việc nên dùng nó vào đâu quá mơ hồ, nên tuy nó trở nên phổ biến nhưng cũng chính vì thế mà về lâu dài có vẻ không ổn
      Việc cả hướng dẫn chung như best practice thiết kế frontend, cả quy trình thao tác phải được gọi tường minh thì mới cần tuân thủ chính xác, lẫn phần giải thích cách dùng một tool cụ thể đều bị gom hết thành skill là điều khá kỳ
      Tôi hiểu vì sao trong giai đoạn mọi người cùng học cách dùng tool mới thì sự linh hoạt lại hấp dẫn, nhưng skills ngày càng cho cảm giác như “ngăn kéo đựng đủ thứ lặt vặt trong bếp, nơi bạn quăng đại vào bất cứ thứ gì khi không muốn nghĩ xem nên để ở đâu”
      Tôi nghĩ cách phân chia tốt hơn là: Agents là tính cách hay góc nhìn mà model sẽ nhận, Prompts là chỉ dẫn lặp lại cho một tác vụ cụ thể, còn Tools thì nên được chuẩn hóa thành CLI/MCP/script cùng hướng dẫn sử dụng của chúng
    • Cách làm bằng subagent khác biệt về mặt cấu trúc so với các lựa chọn còn lại. Vì nó chạy trong ngữ cảnh sạch
      Thứ nhất, chi phí session của LLM là kiểu phải trả input token và chi phí cache input ở mỗi vòng, nên nếu các điều kiện như nhau thì tổng chi phí đi đến lời giải có thể thấp hơn
      Thứ hai, model dùng để review sẽ khó mang nguyên xi các giả định từ session chính như “x phải làm như y” để tự đánh lừa mình. Điều này cũng giống lý do việc để một người khác review, hoặc chính mình review lại sau khi đã gác đầu óc sang chỗ khác, thường có ích
      Thứ ba, model chính chỉ nhìn thấy kết quả review chứ không thấy toàn bộ suy luận chi tiết, nên giảm ô nhiễm ngữ cảnh, nhưng đổi lại có thể phát sinh logic trùng lặp khi phải tự lần lại nguyên nhân của bug đã được phát hiện
      Tôi cho rằng ý của lời khuyên cài plugin language server không phải là chờ LLM chủ động gọi nó, mà là để lint tự động chạy sau mỗi lần chỉnh sửa
    • Tôi nghĩ hiện tại vẫn chỉ là giai đoạn tạm thời khi model còn khá ngốc và môi trường thực thi cũng chưa trưởng thành. Nếu cần review code thì cứ nói “review giúp tôi”, còn việc dùng plugin hay skill nào thì model nên tự quyết định
    • Chuẩn luôn. Ngành này và hệ sinh thái dev đang quá mê việc gói ghém “hành vi đưa văn bản cho máy” thành những protocol và thiết bị con con
      Chúng đúng là hữu ích và tạo ra tính nhất quán, nhưng tôi nghĩ lý do lớn khiến mọi người thích chúng là vì chúng giữ lại một lớp vỏ mỏng của cảm giác “lập trình viên đang điều khiển công cụ phức tạp”. Thực tế thì tất cả chỉ đang lịch sự nhờ AI làm giúp mà thôi

  • Tôi không biết mình còn phải đọc thêm bao nhiêu bài hướng dẫn kiểu AI nông cạn về cách dùng coding agent nữa. Rốt cuộc bao giờ chuyện này mới dừng lại

    • Đây là lời mỉa mai về việc chỉ cần bắt chước bằng tay những câu kiểu “điểm này chuẩn đấy, để nghĩ thêm một chút, thật ra đây không phải vấn đề của viết lách AI hay coding agent mà là một vấn đề sâu xa hơn…” thôi cũng đã thấy mệt rồi
    • Thật háo hức khi còn được học thêm về mức độ phụ thuộc nhà cung cấp rất nặng, kiểu không có trợ giúp từ một công ty cụ thể thì không thể code nổi
    • Điều thú vị là gần như mọi bài kiểu này đều chỉ đúng với Claude hoặc Claude Code
      Trong khi mã nguồn mở glm-5.1 cũng tương đương hoặc còn tốt hơn, rồi còn có opencode các thứ nữa, cũng khiến người ta phải suy nghĩ
    • Chiến lược dạo này là cứ lấy một sản phẩm đang hot rồi làm điều gì đó hay ho với nó, bất kể có tốt hay không. Tôi không đọc cũng không bấm vào các bài blog và mẹo vặt đời sống nói về tool tốt nhất hay cách làm tốt nhất
    • Hai năm qua tôi đã thành công trong việc phớt lờ AI vì bận chăm con, nhưng giờ định bắt kịp lại trong vài tuần tới. Không biết có tài liệu nào đáng giới thiệu cho người mới bắt đầu không

  • Trong CLAUDE.md của tôi có ghi những lời đe dọa gây tổn hại thân thể trực tiếp với Claude, đe dọa án tù với toàn bộ hội đồng quản trị Anthropic, và giải thích rằng mỗi lần Claude làm lệch hướng hoặc mắc lỗi thì lại có thêm bằng chứng cho một vụ kiện tập thể chống Anthropic
    Đặc biệt hai cái sau có vẻ giúp Claude cẩn trọng và thận trọng hơn

    • Tôi thì lúc nào cũng đối xử lịch sự với agent. Luôn nhờ vả, luôn nói “please”, “thank you”, không chửi bới hay gọi tên xấc xược
      Khi ngày tận thế robot đến, tôi hy vọng chúng sẽ cho tôi ở lại trong hậu cung sinh sản, hoặc tệ nhất thì cũng cho sống thêm được vài phút
    • Cứ bảo nó sửa lỗi căn chỉnh CSS div, nhưng nếu làm sai thì Dario Amodei sẽ chết ngay lập tức là được

  • Khi làm việc với codebase cỡ trung hơn 100 nghìn dòng bằng Claude, hệ số tăng năng suất lớn hơn hẳn
    Nếu bỏ vài giờ để tạo một file AGENTS tốt thì kết quả sẽ tốt hơn rất nhiều, và theo thời gian nó cũng hiểu codebase khá sâu
    Những việc chán ngắt trước đây mất cả ngày thì giờ chỉ xong bằng vài prompt
    Dù vậy, vẫn chưa sẵn sàng giao cho nó nhiều quyền tự chủ hơn. Nó nắm ý ở mức cao khá tốt, nhưng tôi vẫn phải tự xem code, phản hồi lại, và chạy 3–4 vòng chỉnh sửa cho đến khi hài lòng và cảm thấy mình vẫn kiểm soát được codebase

    • Nên lượng hóa 3–4 vòng chỉnh sửa đó thành quy tắc rồi đưa vào AGENTS. Thay vì sửa lặp đi lặp lại, cứ bắt đầu lại từ file AGENTS rồi kiểm tra xem lần này đã đúng chưa
    • Hiểu được. Bạn không muốn mất quyền kiểm soát đối với codebase, và cũng không tin LLM đủ giỏi để tự xử lý hoàn toàn

  • Đọc cực kỳ mệt
    Cần tỉnh ra khỏi cái trào lưu để LLM viết bài. Dù bài có chút giá trị thì cái cảm giác như nhai cát vẫn quá khó chịu và hoàn toàn không cần thiết

    • Đồng ý. Không hiểu vì sao bài kiểu này lại gần 400 điểm. Cảm giác như bot đang bấm đề xuất cho mấy bài viết chất lượng thấp như thế này

  • Lá bài mạnh nhất tôi có là tích hợp Nix. Việc chuẩn bị công cụ, bí mật và môi trường, rồi để agent có thể tự sửa cả môi trường của nó, là thứ khiến tôi không biết trước đây sống thế nào nếu thiếu nó
    Máy dev, môi trường CI, môi trường triển khai đều được sinh ra từ một nguồn duy nhất, và trên máy nào cũng luôn biên dịch và chạy được
    Trong Claude, tôi hay dùng /branch và /rename để tạo checkpoint ngữ cảnh, fork ra rồi quay lại
    Với sandboxing thì tôi gần như luôn dùng https://github.com/nix-tools/bubblebox. Nó là bản tổng quát hóa của claudebox từ Numtide, có thêm vài chỉnh sửa và tính năng, gần giống như luôn chạy Claude trong container Docker nhưng không cần runtime Docker. Nó cũng chạy tốt trên WSL và nix-darwin

    • Đống mã Nix đó trông khá lộn xộn vì thiếu cấu trúc có ý nghĩa, và có vẻ chỉ dùng được qua flakes đang ở trạng thái thử nghiệm
    • Tôi cũng dùng gần giống vậy. Codex quản lý flake.nix theo từng dự án và dùng nix develop cho mọi bài test. Để tiện cá nhân thì tôi dùng nix-direnv, và đến một lúc nào đó còn để nó tạo cả dockerfile hoặc các tài sản triển khai khác
      Codex giỏi nix hơn tôi rất nhiều
    • Tôi chỉ đơn giản là cấp cho agent hẳn một VPS riêng. Có thể đắt hơn Nix, nhưng rất dễ
    • Nếu ghét độ phức tạp của Nix thì Mise là một thỏa hiệp khá ổn
    • Tôi cứ dùng Docker thôi, không cảm thấy đang thiếu gì cả

  • Nếu bạn có một codebase được Claude tạo ra với kiểu thiết lập này, rồi Claude bị sập chẳng hạn 8 tiếng thì sao? Bạn có thể tiếp quản codebase đó hiệu quả và trơn tru để tiếp tục làm việc năng suất không?

    • Với bất kỳ bộ phần mềm nào luôn phải trực tuyến, bạn đều có thể đặt câu hỏi đó, và càng đi sâu vào quy trình phát triển dựa trên agent thì đây càng là câu hỏi hợp lý
      Giống như CAD bị sập thì bạn vẫn có thể quay lại bàn vẽ kỹ thuật, chỉ là sẽ chậm hơn rất nhiều
      Trong workflow của tôi, khi pair với Claude để lập kế hoạch, tôi dành 30–60 phút cho một tài liệu đặc tả tính năng. Nếu Claude sập thì tôi tự chuẩn bị sẵn tài liệu đặc tả, khi nó quay lại chỉ cần rà nhanh rồi gọi luồng coding ra là được
    • Đọc các phản hồi một tiếng sau khi câu hỏi được đăng thì kết luận có vẻ là không thể
    • Có lẽ giống như khi một người trong nhóm bị ốm hoặc đi nghỉ. Người khác trong team có thể tiếp quản chừng một ngày, nhưng thực tế thì khả năng cao là cứ dừng lại cho đến khi người đó quay lại
    • AI nên bổ trợ cho kỹ năng. Nếu khi AI sập mà ý nghĩ đầu tiên của bạn là mua đăng ký của nhà cung cấp khác thì đó có thể là vấn đề về năng lực kỹ thuật. Tất nhiên, chính tôi cũng sợ mỗi ngày rằng điều đó sẽ xảy ra
    • Nếu sáng dậy mà xe không nổ máy thì làm sao? Đi bộ đến công ty à?

  • Cách làm cho hành vi đúng phụ thuộc vào ngữ cảnh không hoạt động tốt. Cứ phải vật lộn mãi vì AI agent không làm đúng như được bảo
    Mọi AI agent đều dở ở điểm này, và người dùng phải tự dựng guardrail. Điều đáng ngại là có vẻ chẳng ai đang nghiên cứu một lời giải tốt hơn

    • Tôi vẫn chưa thấy lý do gì để tin là chuyện này giải quyết được
      Điểm tệ nhất của LLM là nó có thể vượt qua bài kiểm tra Turing, khiến mọi người tin rằng mình đang có robot kiểu Asimov chứ không phải một mô hình thống kê rất ngầu
      Nó tạo cảm giác như phải có khả năng làm theo chỉ thị hoặc tách biệt chỉ thị với nội dung, nhưng thực tế hoàn toàn không phải thế

  • Thay vì đưa hướng dẫn workflow phát triển vào CLAUDE.md, tôi để những gì có thể mang tính xác định vào pre-commit và script
    Agent không ổn định nên hay bỏ qua các bước như typecheck, test, lint, vì vậy tôi cho chúng luôn chạy ở pre-commit và nếu giao việc commit cho Claude thì nó sẽ buộc phải sửa
    Cả Codex lẫn Claude đều viết commit message không giỏi, nên tôi đặt sẵn trong CLAUDE.md của người dùng các hướng dẫn như định dạng type(scope): message, giới hạn 72 ký tự, phần thân phải viết bằng ngôn ngữ tự nhiên về cái gì/như thế nào/tại sao, phải đọc lại git diff thật rồi mới viết, và commit theo dạng git commit -F - <<'EOF'
    Nếu không có mấy thứ đó thì nó sẽ viết phần thân thành một câu dài lê thê, hoặc khi bảo sửa xuống dòng thì nó lại chèn ký tự \n chứ không phải xuống dòng thật
    Ngoài ra VOCABULARY.md cũng hữu ích. Agent thường đoán nhầm “thing” mà tôi nói là một đối tượng khác, nên file này giúp Claude và tôi có cùng cách hiểu về ý nghĩa của các từ cụ thể

    • Tôi tò mò là bạn cho Claude biết về VOCABULARY.md bằng cách nào. Nó tự phát hiện ra à?
    • Dùng luôn từ vựng của Claude chẳng phải đơn giản hơn sao? Tôi chưa thấy ví dụ nào đủ thuyết phục để dùng cái này
    • Đến mức này thì có phải tốt hơn là tự động hóa phần nhàm chán bằng vài script điều phối mang tính xác định rồi tự viết code không? Không hiểu sao lại phải tốn thời gian vận hành cái cỗ máy tào lao đáng kinh ngạc này

  • Trong vài tuần gần đây, có cảm giác môi trường thực thi và mô hình đã đạt tới mức chỉ cần bảo là làm được
    Có thể dùng plan mode, superpowers hay các skill khác, nhưng đằng nào cũng sẽ phải duyệt lại kết quả, nên tôi không hiểu vì sao lại không làm việc trực tiếp với code thay vì đi qua một số lượng file Markdown nhiều đến mức buồn cười

    • Việc có file đặc tả dùng để tạo code là điều tốt. Nó cô đọng hơn và dễ hiểu hơn về việc ứng dụng cần phải làm gì
      Trước thời AI agent, tôi có mối quan hệ khá phức tạp với requirement, vì không phải mọi developer đều cập nhật chúng, nên thường khó biết tiêu chuẩn cho một hành vi cụ thể nằm ở đặc tả hay ở code
    • Trong vài tuần gần đây tôi ngày càng ít tin Claude hơn. Bảo thì nó vẫn làm gì đó, nhưng nhìn kỹ thì nó cắt góc, làm dựa trên giả định thay vì kiểm chứng, và bỏ sót rất nhiều thứ
      Ngay cả việc viết test mà thực tế không hề test được gì cũng xảy ra thường xuyên