Claude Code cho thông điệp commit và changelog dễ đọc

Tại sao diff không đủ\n\nMột diff cho thấy gì đã thay đổi, chứ không cho biết tại sao thay đổi. Nó có thể nói rằng một hàm đã đổi tên, một cờ được thêm vào, hoặc một truy vấn được viết lại. Hiếm khi nó cho biết ý định, tác động với người dùng, hoặc các đánh đổi phía sau thay đổi đó.\n\nDiff cũng phân mảnh câu chuyện ra nhiều file. Một chỉnh sửa nhỏ ở chỗ này có thể dẫn đến thay đổi hành vi lớn ở chỗ khác, và người review phải đoán: đây là sửa lỗi hay thay đổi hành vi? Có an toàn để backport không? Có cần migration hay feature flag không?\n\nĐó là lý do tồn tại của thông điệp commit và changelog. Chúng biến những sửa đổi thô thành quyết định mà người khác có thể tin tưởng sau này, dù đó là đồng đội trong code review, một kỹ sư đang debug sự cố sau vài tháng, hoặc chính bạn cố gắng hiểu vì sao một release gây ra hồi quy.\n\nMột diff thường không thể trả lời những câu hỏi đó một mình:\n\n- Vấn đề đã được giải quyết là gì (và triệu chứng trông như thế nào)\n- Ai bị ảnh hưởng (người dùng, admin, client API, công cụ nội bộ)\n- Rủi ro và kế hoạch rollback (có thể hỏng gì, cách hoàn tác)\n- Các bước migration (thay đổi dữ liệu, cập nhật config, tăng version)\n- Cách đã được kiểm thử (hoặc gì còn cần kiểm thử)\n\nCác công cụ như Claude Code có thể đọc diff và soạn thảo văn bản rõ ràng, nhưng chúng vẫn cần ngữ cảnh của bạn. Một diff nói “xoá một trường” có thể là dọn dẹp an toàn, hoặc có thể phá vỡ một tích hợp được dùng rộng rãi. Thông điệp đúng tuỳ thuộc vào thông tin nằm ngoài mã.\n\nMục tiêu là biến diff thành những thông điệp nắm bắt được tác động, rủi ro và các bước migration, với các mẫu prompt bạn có thể tái sử dụng cho commit hàng ngày và cho ghi chú phát hành.\n\n## "Tốt" trông như thế nào cho commit và release notes\n\nMột thông điệp commit tốt nên cho người đọc hiểu thay đổi mà không cần đọc lại diff. Nó nên nói cái gì thay đổi, tại sao thay đổi, và ý nghĩa thực tế của nó.\n\nHầu hết thông điệp mạnh thường bao gồm ba điều:\n\n- Cái gì thay đổi (một câu rõ ràng khớp với diff)\n- Tại sao thay đổi (vấn đề, bug, hoặc mục tiêu)\n- Tác động (hành vi người dùng, hiệu năng, dữ liệu, hoặc API)\n\nChi tiết triển khai ổn, nhưng chỉ khi nó giúp review hoặc debug. “Chuyển sang truy vấn tham số để ngăn SQL injection” hữu ích. “Tái cấu trúc services” thì không.\n\nRelease notes khác. Chúng dành cho người dùng sản phẩm, không phải người viết mã. Mục đích là giúp ai đó quyết định: tôi có nên cập nhật không, sẽ có gì khác, và tôi cần làm gì?\n\nRelease notes tốt nhóm các thay đổi theo kết quả (fixes, improvements, breaking changes). Chúng tránh các thuật ngữ nội bộ như “refactored”, “đổi tên file”, hay “di chuyển handler”, trừ khi điều đó ảnh hưởng trực tiếp tới người dùng.\n\nRủi ro và migration phù hợp cả trong commit lẫn release notes, nhưng chỉ khi chúng quan trọng. Trong commit, một ghi chú rủi ro ngắn giúp reviewer chú ý. Trong release notes, cùng rủi ro nên được giải thích bằng ngôn ngữ đơn giản với hành động rõ ràng.\n\nChi tiết migration hữu ích nhất khi giữ ở mức thực tế:\n\n- Ai bị ảnh hưởng\n- Họ cần thay đổi gì\n- Khi nào có hiệu lực\n- Cách rollback hoặc khôi phục (nếu có phương án an toàn)\n\nClaude Code có thể soạn nhanh khi nó thấy bằng chứng trong diff. Bạn vẫn quyết định ai sẽ nhận ra thay đổi và điều gì có thể hỏng.\n\n## Claude Code giúp ở đâu, và khi nào bạn vẫn cần phán đoán\n\nClaude Code giỏi biến diff thô thành văn bản dễ đọc. Với một tập thay đổi tập trung và chút ngữ cảnh, nó có thể tóm tắt những gì thay đổi, cảnh báo tác động khả dĩ với người dùng, và soạn thảo commit hoặc release notes tự nhiên.\n\nNó thường mạnh ở:\n\n- Gom các sửa đổi rải rác thành một câu chuyện\n- Dịch thuật ngữ mã sang ngôn ngữ người dùng\n- Gợi ý các ghi chú rủi ro (thay đổi config, dữ liệu, hành vi)\n- Soạn các bước migration khi thấy endpoint đổi tên, flag bị xoá, hoặc thay đổi schema\n\nNhững gì nó không biết là những thứ không có trong diff: ý định sản phẩm, kế hoạch rollout (flags, staged releases, canary), hoặc các ràng buộc ẩn (cam kết hỗ trợ, yêu cầu pháp lý, hành vi dành cho khách hàng cụ thể). Nếu một thay đổi “an toàn” chỉ vì thứ gì đó ngoài mã, nó sẽ không thấy điều đó.\n\nTrước khi phát hành, con người vẫn cần xác minh:\n\n- Độ chính xác: tóm tắt có khớp với hành vi thực tế của mã không?\n- Phạm vi: có tác dụng phụ bên ngoài file thay đổi không (cache, job nền, quyền)?\n- Bảo mật và riêng tư: có gì thay đổi liên quan auth, logging, hoặc lộ dữ liệu không?\n- Cách diễn đạt: lời văn có phù hợp với đối tượng (người dùng vs nhà phát triển) và tránh hứa hẹn quá mức không?\n\nVí dụ đơn giản: diff xoá một cột database và thêm một enum mới. Claude Code có thể soạn “Remove legacy column; add status value,” nhưng chỉ bạn mới biết liệu đó có phải breaking change, cách backfill hàng tồn, và liệu rollout cần hai bước deploy hay không.\n\n## Chuẩn bị diff và ngữ cảnh trước khi prompt\n\nMột diff thô cho thấy gì đã thay đổi, nhưng hiếm khi giải thích tại sao, người dùng sẽ nhận thấy gì, hoặc điều gì có thể hỏng. Dành hai phút gom ngữ cảnh trước và thông điệp commit/ghi chú phát hành sẽ rõ ràng hơn.\n\nTập hợp vài thông tin trả lời: vấn đề là gì, hành vi mới ra sao, và bạn đã kiểm tra như thế nào. Đối xử prompt như một giao nhận ngắn cho đồng đội không làm thay đổi.\n\nNhững input thường quan trọng nhất:\n\n- Diff (hoặc file/hunk cụ thể quan trọng)\n- Mô tả PR hoặc tóm tắt ý định (dù sơ lược)\n- Ghi chú ticket: tiêu chí chấp nhận, trường hợp biên, ảnh chụp màn hình, log lỗi\n- Hành vi mong đợi trước vs sau (một hoặc hai câu)\n- Ghi chú rủi ro: flags, migration, thay đổi config, kế hoạch rollout\n\nRồi quyết định bạn muốn nhận lại gì. Một thông điệp commit đơn là tốt cho thay đổi nhỏ tập trung. Nhiều commit có ý nghĩa nếu diff trộn refactor, thay đổi hành vi, và test. Release notes thì khác: tập trung vào tác động người dùng, tác động admin, và bất cứ điều gì ai đó phải làm sau khi nâng cấp.\n\nĐặt ranh giới trước khi dán nội dung. Loại bỏ bí mật và mọi thứ bạn không muốn xuất hiện trong repo công khai: API keys, token riêng, tên khách hàng, dữ liệu cá nhân, host nội bộ, và chi tiết sự cố nhạy cảm. Nếu không thể chia sẻ đầy đủ ngữ cảnh, tóm tắt nó an toàn.\n\nVí dụ: một diff thêm trường bắt buộc mới vào bảng PostgreSQL và cập nhật handler Go. Bao gồm file migration, thay đổi handler, và một câu như: “Old clients that omit the field will get a 400. We will roll out clients first, then run the migration.” Câu đó thường là khác biệt giữa một thông điệp an toàn và một thông điệp gây hiểu lầm.\n\n## Mẫu prompt tạo thông điệp commit rõ ràng\n\nChất lượng bạn nhận được phụ thuộc vào cách bạn hỏi. Một prompt tốt khiến model xem diff như bằng chứng, và giữ thông điệp gắn với tác động và rủi ro.\n\n### Mẫu prompt thực tế\n\nDán diff (hoặc trích đoạn ngắn), sau đó thêm một khối ngữ cảnh nhỏ mà diff không thể hiện. Giữ ngắn nhưng cụ thể:\n\n- Scope: component hoặc area (auth, billing, mobile, API)\n- Intent: vấn đề được giải quyết hoặc hành vi thay đổi\n- Constraints: tương thích, deadline, hoặc “không thay đổi schema”\n- Audience: ai đọc (tương lai bạn, reviewer, on-call)\n- Output rules: độ dài, giọng điệu, định dạng commit (ví dụ Conventional Commits)\n\nYêu cầu đầu ra có cấu trúc để bạn quét nhanh và bắt lỗi trước khi dán vào Git.\n\n### Yêu cầu các lựa chọn, không chỉ “một” thông điệp\n\nMột diff có thể hỗ trợ nhiều thông điệp khác nhau tuỳ bạn muốn nhấn mạnh gì. Yêu cầu 2–3 phiên bản để bạn chọn phù hợp.\n\nVí dụ:\n\n- Conservative: tối thiểu, chính xác, không thêm khẳng định\n- User-facing: nêu thay đổi người dùng nhận thấy\n- Engineering-focused: nêu refactor, hiệu năng, và follow-up\n\nTín hiệu tốt là xem tóm tắt có khớp với diff thật không. Nếu bất kỳ phiên bản nào đề cập tới tính năng hoặc sửa lỗi bạn không thể chỉ ra trong mã, loại nó ra.\n\n### Bắt buộc các mục rõ ràng (và cho phép “Unknown”)\n\nMột mẫu đáng tin là yêu cầu các đầu mục và cho phép “Unknown” khi diff không chứng minh được điều gì.\n\nThử: “Trả về thông điệp commit cuối cùng với các phần: Summary, Motivation, Impact, Risk, Tests. Nếu tests không thấy, ghi ‘Tests: not shown’ và gợi ý những gì cần chạy.”\n\nNó giữ thông điệp trung thực và làm review nhanh hơn, nhất là khi thay đổi cần migration hoặc rollout cẩn thận.\n\n## Mẫu prompt cho changelogs và release notes\n\nRelease notes thất bại khi đọc như git log. Nếu bạn muốn ghi chú hữu ích từ nhiều commit hoặc một diff lớn, hỏi về người đọc trước, rồi thêm chi tiết kỹ thuật chỉ khi nó thay đổi hành động của họ.\n\n### Mẫu: “Release notes từ một lô thay đổi”\n\nCho ngữ cảnh sản phẩm ngắn (ai dùng, khu vực app), sau đó dán diffs hoặc tóm tắt commit. Yêu cầu đầu ra có cấu trúc tách rõ thay đổi người dùng và thay đổi kỹ thuật.\n\ntext\nYou are writing release notes for [product/app]. Audience: [end users/admins/developers].\nInput: the following diffs/commit summaries.\n\nWrite release notes with these sections:\n1) User-visible changes (what’s new or different)\n2) Fixes (symptoms users had, now resolved)\n3) Breaking changes (if none, say “None”)\n4) Migration steps (numbered, short, actionable)\n5) Deprecations (what, when it will be removed, replacement)\n6) Risk and rollout notes (what could go wrong, how to verify)\n\nRules: do not list internal refactors unless they affect behavior. Use plain language.\n\n\nCách này tạo một tách sạch giữa tác động người dùng và dọn dẹp nội bộ, vậy một đổi tên sẽ không lấn át thay đổi hành vi thực sự.\n\n### Mẫu: “Gọi rõ migration và breaking changes”\n\nNgay cả các model cẩn thận cũng bỏ sót migration nếu bạn không hỏi. Thêm các câu hỏi rõ ràng:\n\n- Có thay đổi API responses, key config, env var, hoặc schema không?\n- Người dùng hiện tại sẽ bị hỏng như thế nào sau khi nâng cấp, và họ sẽ nhận ra bằng cách nào?\n- Những bước chính xác để sửa, theo thứ tự?\n- QA nên xác minh gì để đảm bảo release an toàn?\n\nThói quen giống nhau: luôn yêu cầu “tại sao quan trọng” và “phải làm gì tiếp theo”, không chỉ “cái gì thay đổi”.\n\n## Bước-by-step: biến diff thành thông điệp cuối cùng\n\nĐọc diff như reviewer, không phải người viết thay đổi. Công việc của bạn là biến thay đổi mã thành thứ ai đó có thể tin tưởng sau này: cái gì thay đổi, tại sao, và ý nghĩa.\n\n1. Viết tóm tắt một dòng trước. Dùng động từ rõ ràng và nêu bề mặt ảnh hưởng. “Fix crash when saving draft on iOS” tốt hơn “Update save logic.”\n2. Sắp xếp thay đổi theo cấu trúc ổn định. Thứ tự đơn giản hiệu quả cho hầu hết commit: What, Why, Impact, Risk, Migration. Nếu một phần không có, ghi “None” để người đọc khỏi nghĩ bạn quên.\n3. Thêm bước xác minh. Bao gồm một “How to verify” ngắn để người khác có thể theo dõi. Nối nó với hành vi quan sát được, không phải plumbing nội bộ.\n4. Viết ghi chú rollout khi rủi ro. Ghi rõ feature flags, phased rollout, monitoring, và trigger rollback. Nếu có edge case đã biết, nêu ra.\n5. Tinh chỉnh theo đối tượng. Commit messages có thể có một chút ngữ cảnh nội bộ. Release notes nên dùng ngôn ngữ đơn giản.\n\nNếu bạn dùng Claude Code, dán diff cộng 2–3 câu ngữ cảnh (ai bị ảnh hưởng, gì bị hỏng, bạn đã kiểm tra gì) và yêu cầu đầu ra theo cấu trúc đó. Rồi chỉnh sửa giống như bạn chỉnh văn bản do người viết viết.\n\nMột lần chỉnh ngôn từ nhanh giúp dễ đọc:\n\n- Dùng “Người dùng có thể…” hoặc “Admin phải…” thay vì “Chúng tôi refactored…”\n- Thay từ mơ hồ như “improve” bằng kết quả cụ thể\n- Nếu có migration, nói chính xác phải làm gì và khi nào (trước hay sau deploy)\n\nMột thông điệp chắc chắn trả lời: Cái gì thay đổi? Tại sao bây giờ? Có thể hỏng gì? Làm sao biết nó hoạt động? Ai phải làm gì để áp dụng an toàn?\n\n## Ví dụ thực tế: từ diff đến commit và release note\n\nGiả sử một diff nhỏ có vẻ vô hại nhưng có thể phá vỡ client.\n\ndiff\n- type UserResponse struct {\n- FullName string `json:\"fullName\"`\n- }\n+ type UserResponse struct {\n+ Name string `json:\"name\"`\n+ }\n\n+ if req.Name == \"\" {\n+ return errors.New(\"name is required\")\n+ }\n\n\nHai việc đã xảy ra: một field response đổi tên (fullName thành name), và validation được thêm (name bắt buộc). Tốt nhất là bạn yêu cầu tác động, rủi ro, và bước tiếp theo.\n\nĐây là một bản nháp commit message với ngữ cảnh chính mà diff không cho biết:\n\ntext\nRename user response field to `name` and require `name` on create\n\nWhy:\n- Align API with updated domain naming\n\nImpact:\n- Breaking change: clients reading `fullName` must switch to `name`\n- Requests without `name` now fail validation\n\nTests:\n- Updated API tests for response payload\n- Added validation test for missing name\n\n\nVà một mục release note viết cho người dùng, không phải cho code:\n\ntext\nBreaking: User API field rename and stricter validation\n\n- Response field `fullName` is now `name`\n- Create/update requests now require `name`\n\nMigration:\n- Update JSON parsing to read `name`\n- If you send `fullName`, map it to `name` before calling the API\n\n\nTinh gọn câu chữ bằng cách bỏ dự đoán. “Align API with updated domain naming” mơ hồ. Nếu bạn không biết lý do, nói những gì bạn biết: “Chuẩn hoá tên trên các endpoint.” Cũng tránh khẳng định test bạn chưa chạy. Thay “Updated API tests” bằng tên suite, hoặc bằng một ghi chú trung thực như “Manual check: created user via API and verified response payload.”\n\n## Sai lầm phổ biến và bẫy\n\nCách nhanh nhất để mất niềm tin vào commit do AI viết là để thông điệp hứa nhiều hơn diff thể hiện. Claude Code có thể biến thay đổi nội bộ thành văn bản rõ ràng, nhưng nó cũng có thể suy luận “cải thiện trải nghiệm người dùng” từ một refactor nếu bạn không giữ nó sát thực tế.\n\nMột sai lầm thường gặp là thổi phồng tác động. Đổi tên, helper mới, hoặc di chuyển logic giữa file có thể đọc như một tính năng khi thực ra là plumbing. Nếu release notes tuyên bố “cải thiện hiệu năng” mà không có đo lường, người dùng sẽ nhận ra.\n\nSai lầm khác là bỏ sót breaking changes và migration. Diff giấu chúng ở chỗ nhỏ: mặc định config đổi, env var đổi tên, cột DB thành NOT NULL, hoặc field response bị xoá. Nếu commit và changelog không nói rõ ai phải làm gì sau khi cập nhật, bản “sạch” của bạn biến thành ticket hỗ trợ.\n\nNgôn từ mơ hồ cũng rủi ro. “Cải tiến nhỏ” và “nhiều sửa lỗi” che giấu rủi ro thay vì truyền đạt nó.\n\nBẫy khi dán diff vào prompt:\n\n- Biến refactor nội bộ thành tuyên bố về người dùng\n- Bỏ qua ghi chú breaking-change và migration\n- Che giấu rủi ro bằng ngôn ngữ chung chung\n- Bịa lý do không có trong diff hoặc ngữ cảnh\n- Phớt lờ định dạng commit và changelog của dự án bạn\n\nMột sửa tốt là ép chế độ “bằng chứng”. Nếu diff đổi tên field API, release note phải nói client nào cần đổi tên và liệu client cũ có bị lỗi hay không.\n\nTrước khi chấp nhận đầu ra, yêu cầu một lần chạy lại để:\n\n- Tách tác động người dùng khỏi thay đổi nội bộ\n- Liệt kê breaking changes với hành động di chuyển cụ thể\n- Ghi rõ rủi ro (và mức không chắc chắn) bằng ngôn ngữ đơn giản\n- Khớp với quy tắc phong cách commit của bạn\n\n## Checklist nhanh trước khi merge hoặc ship\n\nTrước khi merge, đọc thông điệp commit như bạn không viết mã. Nếu nó không giải thích thay đổi bằng ngôn ngữ đơn giản, nó sẽ không giúp bạn khi cần hotfix. Nếu bạn dùng Claude Code, rà soát nhanh để xác nhận nó khớp với thay đổi thực tế.\n\n### Kiểm tra nhanh thông điệp commit\n\n- Cái gì thay đổi và ở đâu: nêu tính năng/khu vực, không chỉ “refactor”.\n- Tại sao thay đổi: lý do nên gói gọn trong một câu.\n- Tác động: ai hoặc cái gì bị ảnh hưởng.\n- Bằng chứng: đề cập test bạn đã chạy (hoặc ghi “not tested” và lý do).\n- Phạm vi: thông điệp có khớp với kích thước diff và thay đổi hành vi không?\n\nNếu thông điệp có chi tiết không nằm trong diff hoặc ticket, loại bỏ chúng. Một “tại sao” rõ ràng tốt hơn một câu chuyện dài.\n\n### Kiểm tra nhanh release notes\n\nRelease notes dành cho người chưa thấy PR.\n\n- Hướng tới người dùng: mô tả kết quả, không phải triển khai.\n- Rủi ro rõ ràng: có thể hỏng gì và cách nhận biết.\n- Có migration: thay đổi config, env var, backfill dữ liệu, hoặc bước một lần.\n- Ghi chú rollback: nếu revert, cần cleanup gì không.\n\n### Danh sách cấm\n\nTrước khi phát hành, xoá hoặc viết lại:\n\n- Bí mật hoặc dữ liệu riêng tư (token, key, thông tin khách hàng).\n- Dự đoán (“sẽ cải thiện hiệu năng”) không có đo lường.\n- Ngôn ngữ đổ lỗi (“ops broke”, “frontend messed up”).\n\nNếu bạn không thể giải thích thay đổi mà không đoán, dừng lại và bổ sung ngữ cảnh thiếu.\n\n## Bước tiếp theo: biến nó thành thói quen trong workflow\n\nTính nhất quán hơn hoàn hảo. Chọn một định dạng ngắn cả đội có thể dùng cho mỗi thay đổi, ngay cả khi bận. Khi mọi người viết cùng một cấu trúc, review nhanh hơn và release notes ngừng giống như công việc thám tử.\n\nMột định dạng nhẹ nhưng hiệu quả:\n\n- What changed (user impact): một câu bằng ngôn ngữ đơn giản\n- Why: lý do hoặc bug được sửa\n- Risk: có thể hỏng gì, và bạn giảm rủi ro như thế nào\n- Migration: các bước cần (nếu có)\n\nDùng Claude Code để soạn thảo, rồi làm một lượt kiểm tra con người để xác thực và thêm ngữ cảnh. Nó mạnh nhất khi bạn cho diff cộng 2–3 câu ý định: ai thay đổi này dành cho, bạn muốn cải thiện gì, và bạn cố tình không thay đổi điều gì.\n\nĐể mở rộng mà không cần thêm họp, nhúng nó vào nơi bạn đã dùng: một template commit hoặc PR ngắn với các trường đó, một checkbox cho migration và rủi ro, và comment review tập trung vào tác động còn thiếu thay vì phong cách viết.\n\nNếu bạn build trong Koder.ai (koder.ai), cùng cấu trúc đó phù hợp tự nhiên trong planning mode. Viết ý định trước (tác động, rủi ro, migration), rồi triển khai theo kế hoạch để “tại sao” không bị mất khi mã bắt đầu thay đổi.