- git-memento là một công cụ mở rộng tự động ghi lại các phiên tạo mã do AI sinh ra vào Git commit, lưu lịch sử hội thoại AI tương ứng với từng commit dưới dạng git notes
- Khi chỉ định ID phiên AI lúc commit, bản tóm tắt được lưu trong
refs/notes/commits, còn toàn bộ hội thoại được lưu tách biệt trong refs/notes/memento-full-audit, giúp đảm bảo đồng thời khả năng truy vết và quyền riêng tư
- Hỗ trợ nhiều nhà cung cấp AI như Codex và Claude; khi tạo tóm tắt có thể áp dụng kỹ năng tùy chỉnh để kiểm soát chất lượng ghi chú commit
- Tích hợp với GitHub Actions, cung cấp các tính năng tự động tạo bình luận từ ghi chú commit, xác thực cổng CI, và tự động chuyển ghi chú khi hợp nhất (merge-carry)
- Hỗ trợ Windows/macOS/Linux. Đây là công cụ giúp tăng tính minh bạch của việc AI tạo mã và đảm bảo khả năng kiểm toán (audit) các đóng góp của AI trong môi trường cộng tác
Tổng quan về git-memento
git-memento là một công cụ mở rộng Git ghi lại các phiên lập trình với AI theo từng commit
- Khi commit, công cụ sắp xếp nội dung hội thoại của phiên AI và lưu thành ghi chú Markdown
- Mỗi commit đều lưu lại nguồn gốc và ngữ cảnh hội thoại của phiên AI để có thể truy vết quá trình tạo mã
- Mặc định hỗ trợ Codex, đồng thời có thể cấu hình các mô hình AI khác như Claude
- Được phát hành theo giấy phép MIT và phân phối dưới dạng tệp thực thi đơn dựa trên NativeAOT
Các lệnh và tính năng chính
- Dùng
git memento init để khởi tạo cấu hình theo từng kho lưu trữ và lưu thông tin nhà cung cấp AI vào .git/config
- Dùng lệnh
git memento commit để thêm ghi chú phiên cùng lúc với commit
- Nếu dùng tùy chọn
--summary-skill, bản tóm tắt và toàn bộ phiên sẽ được lưu tách biệt
- Bản tóm tắt được ghi vào
refs/notes/commits, còn toàn bộ nhật ký được ghi vào refs/notes/memento-full-audit
git memento amend cho phép thêm phiên mới vào commit hiện có hoặc chỉnh sửagit memento audit kiểm tra việc thiếu ghi chú trong một phạm vi commit và xác thực tính hợp lệ của metadatagit memento doctor kiểm tra cấu hình, tham chiếu ghi chú và trạng thái đồng bộ từ xa
Quản lý và đồng bộ ghi chú
- Dùng
git memento share-notes để đẩy ghi chú lên kho từ xa (origin v.v.)
git memento notes-sync hợp nhất an toàn các ghi chú từ xa và tạo bản sao lưu
- Đồng bộ cả
refs/notes/commits và refs/notes/memento-full-audit
git memento notes-carry chuyển ghi chú sang commit mới sau khi rebase hoặc squashgit memento notes-rewrite-setup kích hoạt cấu hình chuyển ghi chú tự động
Tích hợp GitHub Actions
- Kho lưu trữ có kèm GitHub Action có thể tái sử dụng
mode: comment — đọc ghi chú commit để tự động tạo bình luậnmode: gate — kiểm tra việc thiếu ghi chú ở bước CI, chặn build nếu thất bạimode: merge-carry — chuyển ghi chú sang merge commit khi PR được hợp nhất
- Mỗi chế độ được định nghĩa trong
action.yml và có kèm artifact dành cho đăng ký Marketplace (dist/note-comment-renderer.js)
- PR có gắn nhãn
ignore-notes sẽ bỏ qua kiểm tra cổng và để lại bình luận “Notes ignored”
Định dạng ghi chú và quản lý phiên bản
- Ghi chú được lưu theo định dạng
git notes add -f -m ""
- Dùng thẻ phiên bản(``) và dấu phân tách đoạn để hỗ trợ nhiều phiên
- Tin nhắn của người dùng được gắn nhãn bằng tên người dùng Git, phản hồi AI được gắn nhãn bằng tên nhà cung cấp
- Các ghi chú phiên đơn hiện có sẽ được tự động nâng cấp khi cần để duy trì tính tương thích
4 bình luận
Với dự án private thì tôi export session rồi commit, còn dự án public thì chỉ commit file tóm tắt khi thấy thật sự cần thiết.
Dù sao cũng có thông tin cá nhân nữa... và tùy công cụ nhưng mỗi session thường dễ vượt quá 10 MB... nên tôi thấy không tiện cứ thế đẩy lên.
Nhưng chúng ta đang sống trong thời đại mà ổ đĩa rẻ hơn bao giờ hết!
Ý kiến trên Hacker News
Khi viết code với AI, tôi bắt đầu bằng file project.md
Trong đó tôi mô tả kết quả mình muốn, rồi để AI viết plan.md dựa trên nội dung đó
Sau đó tôi chỉnh sửa plan.md nhiều lần, và khi kế hoạch mong muốn đã hoàn chỉnh thì tạo danh sách todo chi tiết rồi gắn vào cuối plan.md
Khi đã hoàn toàn hài lòng, tôi bảo AI thực hiện todo, không hỏi thêm gì nữa và làm cho đến hết
Cuối cùng tôi commit project.md, plan.md và toàn bộ code
Làm vậy thì plan.md trở thành một dạng artifact có thể tái lập, để sau này các model tốt hơn có thể dựa vào đó chỉnh sửa hoặc tìm lỗi
design được viết theo từng tính năng và nêu rõ các câu hỏi chưa được giải quyết
plan được quản lý theo cấu trúc
plan/[feature]/phase-N-[description].md, và sẽ dừng lại nếu đụng phải giới hạn build hay chạyỞ giai đoạn debug, tôi đưa ra các giả thuyết về nguyên nhân có thể có, kiểm chứng bằng logging/tracing rồi mới sửa
Cách này cho thấy tỷ lệ thành công gần như 100% ở cả dự án mới lẫn legacy
Nhược điểm là tích lũy quá nhiều file markdown, nhưng vì lịch sử cũ vẫn hữu ích cho các thay đổi trong tương lai nên tôi chưa tự động hóa
Có thể tham khảo GitHub spec-kit
Khi để model lặp đi lặp lại việc nghiên cứu thị trường và xem xét đề xuất, cuối cùng bạn sẽ thiết kế prompt bằng thứ ngôn ngữ mà chính model có thể hiểu
Gần đây tôi phát hiện XML ảnh hưởng đến cách Claude hoạt động, nên đang nghĩ lại về cấu trúc của GuardRails
Link bài giới thiệu
Khi plan hoàn tất, tôi tạo “context.md” để sau này tham khảo khi cần quay lại một kế hoạch sai
Thực tế thì tôi chưa cần dùng đến lần nào, nhưng về mặt khái niệm nó khá hữu ích
Chỉ là tôi vẫn thấy mơ hồ nên đặt các file này ở đâu, nên hiện chưa đưa vào repo
Tôi khá tò mò không biết mọi người lưu các file md theo từng công việc ở đâu
Theo tôi thì đây giống câu hỏi “có nên commit mọi dòng không?”
Cuối cùng thì trọng tâm là bản ghi đó phục vụ cho ai
Phần lớn các session có rất nhiều nhiễu, nhiều lần thử sai và thông tin không cần thiết
Điều quan trọng là đầu ra của session, chứ không phải toàn bộ quá trình
Tuy vậy, spec ban đầu hay prompt đầu tiên vẫn có giá trị. Tốt hơn là tóm tắt chúng trong commit message hoặc file markdown
Có thể dùng các session cũ như ngữ cảnh học tập để tiếp tục công việc hiện tại
Đặc biệt, nó có thể giúp hiểu giới hạn của model và tìm ra những điểm mà code lệch khỏi ý định của người dùng
Cuối cùng tôi nghĩ rằng việc ghi lại mọi đầu vào của con người là quan trọng cho sự phát triển của các model mã nguồn mở
Kết quả vẫn phải giống nhau ngay cả khi có cả điều kiện ban đầu và nhiễu
Nếu không, việc bảo trì code trong tương lai sẽ trở thành một trò chơi đoán ý định
Bài viết liên quan
Một tuần trước tôi cũng đề xuất ý tưởng tương tự (link)
Nhưng cũng có nhiều ý kiến phản đối — dự án AI không được tạo ra từ một đầu vào duy nhất, mà là một quá trình hội thoại nên khó biến thành artifact như source code
Dù vậy, hiện có quá nhiều dự án tạo sinh được đăng lên Show HN nên mức độ nhiễu đã rất nghiêm trọng
Không thể loại bỏ hoàn toàn, nhưng ở trạng thái hiện tại thì tôi thấy ngày càng kém hứng thú
Tôi đang nghĩ xem cộng đồng nên xử lý vấn đề này như thế nào
Tôi commit research.md và plan.md để dùng như một từ điển sống về kiến trúc và tính năng
Tôi thêm tiền tố tên tính năng vào tên file để Claude có thể nhanh chóng gọi ra bản thiết kế liên quan
Blog tham khảo
Những dự án từng thú vị giờ lại được làm ra quá dễ dàng
Bắt mọi người đọc log session dài không phải giải pháp. Khả năng tóm tắt và năng lực lập kế hoạch mới ngày càng quan trọng
Giá trị thật sự của vibe coding nằm ở việc nhìn thấy quá trình thử và thất bại
So với chỉ đăng kết quả, những bài có quy trình làm ra và phần giải thích sẽ thú vị hơn
Vì vậy tôi muốn có thêm một hạng mục kiểu [Creations] tách riêng khỏi [Show HN]
Ví dụ: một chess engine đơn thuần thì là [Creations], còn chess engine làm với 1k thì là [Show HN]
PerfBoard và Lerc là ví dụ như vậy
Session chỉ là đầu ra trung gian, không nhất thiết phải nằm trong thành phẩm cuối cùng
Nếu lý do thay đổi code là quan trọng, thì nên ghi lại bằng commit message hoặc tài liệu
Ở thời điểm commit, bạn không biết người đọc tương lai sẽ có câu hỏi gì
Vì vậy tôi thích cách lưu session rồi sau đó tạo bản tóm tắt từ câu hỏi
Git AI dùng cách tiếp cận này
Dạo này kỹ sư làm việc quá nhanh, nên chỉ sau một tuần nhiều người đã không nhớ vì sao mình làm như vậy
Prompt mang tính nghiên cứu thì nên tóm tắt, còn prompt tạo code thì nên lưu nguyên bản
Như vậy mới đảm bảo được khả năng tái lập và khả năng review
Kế hoạch phản ánh cả quá trình sửa lỗi, nên trở thành tài liệu hữu ích cho vòng lặp sau
Mỗi repo trao đổi thông điệp với nhau để quản lý yêu cầu tính năng
Tôi lưu cả hội thoại gốc lẫn ký ức đã được nén ngữ nghĩa, rồi sắp xếp lại spec và yêu cầu
Log session phần lớn là nhiễu
Nó là chuỗi các lần thử sai và hoàn tác, nên đặt cạnh commit chẳng khác gì lưu lịch sử trình duyệt
Điều quan trọng là commit message chứa ý định và các ràng buộc
Nếu AI viết code, thì cốt lõi không phải cuộc hội thoại mà là vì sao lại đưa ra yêu cầu như vậy
Cuối cùng vấn đề có thể không phải lưu session, mà là thói quen xem nhẹ commit message
Dù dùng AI, tôi vẫn giữ quy trình thiết kế truyền thống
Yêu cầu → use case → thiết kế lớp → định nghĩa ràng buộc → chạy AI
Làm như vậy vừa giữ được năng lực phán đoán kiến trúc của con người, vừa để AI tăng tốc phần triển khai lặp lại
Nếu thay vì log session mà đưa các tài liệu UML/ràng buộc này vào commit, bạn sẽ để lại ý định và ngữ cảnh rõ ràng hơn
Tôi nghĩ các lập trình viên của năm 2026 nên giữ gìn cấu trúc cộng tác có phẩm chất như vậy
Điều này giống với việc có squash commit hay không
Nếu thích squash thì chỉ coi trọng kết quả và không giữ lại quá trình
Nếu không thì bạn ghi lại cả hành trình
Session AI cũng vậy: nó hữu ích để debug quá trình tư duy, nhưng những người thích lịch sử gọn gàng thì không nhất thiết muốn xem
Thực tế hơn là quản lý session riêng bên ngoài repo
Tôi nghe nói Mercurial hay Fossil làm tốt mảng này hơn
Trong vibe-coding, hơn cả code, prompt cho thấy dấu vết của tư duy
Có đưa vào git hay không là chuyện khác, nhưng để nó ở trạng thái có thể truy cập được thì vẫn có giá trị
Trong trường hợp đó không cần xem quá trình theo thời gian thực
Nhưng nếu là code hoàn toàn do AI viết, thì cần công khai prompt
Tôi cũng đã thử trích xuất session
Có rủi ro mất một phần thông tin, nhưng tính dễ đọc và khả năng truy cập tốt hơn nhiều
Tôi nghĩ ít nhất cũng nên lưu prompt đã được tóm tắt của session
AI review code kém nghiêm khắc hơn con người, còn ý định thì chỉ nằm trong prompt
Nếu không sẽ lặp lại cùng một sai lầm
Giá trị của code review là học hỏi và cải thiện, mà AI thì không học, nên việc ghi lại prompt phải thay thế vai trò đó
Nó cũng cần thiết cho đánh giá kỹ năng viết prompt hay đào tạo junior
Chúng ta không đưa phím gõ, cú nhấp menu hay các lần thử debug vào commit
Nếu lưu mọi cuộc hội thoại thì nhiễu sẽ quá nhiều
Thực tế hơn là chỉ giữ lại tài liệu chứa ý định và giả định
Điều này giống như hỏi “có nên đưa lịch sử tìm kiếm Google vào commit không?” — tôi nghĩ tất nhiên là không
Thay vào đó, chỉ nên để lại lý do, giả định và tóm tắt các phương án thay thế
Tương tự, log model loay hoay với những vấn đề vặt vãnh là không cần thiết
> “Có nên đưa lịch sử tìm kiếm Google vào commit không?” — tôi nghĩ tất nhiên là không
Tôi thích bình luận này