3 điểm bởi weedroot 28 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp

Mình đã thử làm một công cụ nhỏ tên là ConfigDeck (https://configdeck.dev/ko).
Trình tạo tệp cấu hình vốn là một chủ đề khá phổ biến, nhưng cách mình làm có phần hơi mang tính thử nghiệm nên muốn chia sẻ lại trải nghiệm này.

Đây là gì

Mỗi khi bắt đầu một dự án, việc phải copy-paste các tệp cấu hình như .eslintrc, prettier.config, tsconfig từ dự án cũ luôn khá phiền, nên mình đã làm nó theo dạng chọn tùy chọn rồi tải xuống.

  • Hỗ trợ 9 loại tệp cấu hình: ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
    .gitignore, .editorconfig, .env.example
  • Preset theo stack: React+Vite, Next.js, Astro, Node.js... để tạo nhiều tệp cùng lúc
  • Di trú .eslintrceslint.config.mjs (chuyển đổi Flat Config)
  • Hỗ trợ tiếng Hàn / tiếng Anh
  • Trang tĩnh 100% (Cloudflare Pages, trang nội dung JS 0KB)
  • Dữ liệu đầu vào chỉ được xử lý trong trình duyệt, không gửi ra ngoài

Stack kỹ thuật: Astro 6 + Svelte 5 (Runes) + Tailwind 4 + TypeScript strict

Cách mình xây dựng — giao khá nhiều cho AI

Lần này, mình thử dùng Claude Code để sắp xếp lại chính quy trình phát triển.
Phần con người làm chủ yếu là định hướng kế hoạch và kiểm tra giữa chừng, còn phần triển khai thì mình cố gắng giao cho AI nhiều nhất có thể. Có phần làm tốt, cũng có không ít thử-sai, nhưng mình nghĩ nếu công khai quá trình thì sẽ hữu ích cho những ai đang thử các cách làm tương tự, nên đã ghi lại như sau.

Mình đã công khai toàn bộ cấu hình đã dùng trong thư mục .claude/ của kho mã nguồn:
https://github.com/jsg3121/configDeck/tree/main/.claude

  • Tài liệu harness (CLAUDE.md, conventions, ADR, v.v.)
  • Agent theo từng domain (config-maker, ui-publisher, ux-designer,
    qa-agent, seo-specialist, v.v.)
  • Slash skill (/lint-check, /code-review, /seo-audit, /research, v.v.)
  • Ghi lại quyết định kỹ thuật bằng ADR
  • Hook tự động hóa (định dạng sau PostToolUse, kiểm tra build/lint khi Stop)

Điều mình chú ý khi viết chủ yếu là “Why-First”. Thay vì chỉ ghi quy tắc, mình ghi luôn cả lý do vì sao, và mình có cảm giác AI đưa ra phán đoán nhất quán hơn ở các edge case.

Mình tổ chức để các agent cộng tác theo luồng đại khái như sau:

product-plannerux-designerui-publisherqa-agent
(lập kế hoạch) (thiết kế) (triển khai) (kiểm chứng)

Ở phần QA, mình đặt các sub-agent unit-tester / e2e-tester / static-analyzer, rồi để qa-agent tổng hợp kết quả và tạo báo cáo.

Thử-sai

Điểm tốt

  • Vì lưu lại các quyết định bằng ADR, nên dù thời gian trôi qua vẫn dễ lần lại câu hỏi “vì sao lại viết như thế này?”.
  • Khi viết conventions trong harness, kết quả đầu ra có vẻ nhất quán hơn tương đối, ngay cả khi đổi session.
  • Khi chia agent theo từng domain, phần kế hoạch và phần triển khai không bị trộn vào cùng một context nên dễ theo dõi hơn.

Điểm khó

  • Lúc đầu chưa có harness nên style của kết quả thay đổi mỗi lần, và mình đã phải chỉnh sửa lại nhiều lần mới gom được thành dạng hiện tại.
  • Chi phí token cao hơn mình nghĩ, nên mình đang dùng riêng một bộ hướng dẫn để chọn giữa hội thoại chính / skill / agent tùy theo quy mô công việc.
  • Có lúc AI báo cáo như thể mọi thứ đã ổn, nên việc dùng Stop hook để tự động xác minh build / lint đã giúp ích khá nhiều.

Mình vẫn khó có thể nói là đã tìm ra đáp án đúng, và có lẽ vẫn còn những cách tốt hơn.

Liên kết

1 bình luận

 
heycalmdown 27 ngày trước

Ý tưởng này thú vị đấy. Không phải lúc nào cũng chỉ làm các dự án greenfield, nên ngược lại, nếu đưa vào một file config hiện có đã trở nên lộn xộn, rồi nó có thể giải thích đó là những tùy chọn gì và cho phép bật tắt chúng thì cũng sẽ rất hay.