- git-memento เป็นเครื่องมือขยายที่ บันทึกเซสชันโค้ดที่ AI สร้างลงใน Git commit โดยอัตโนมัติ โดยเก็บประวัติการสนทนา AI ที่สอดคล้องกับแต่ละคอมมิตไว้ใน git notes
- เมื่อระบุ AI session ID ตอนคอมมิต ระบบจะเก็บ สรุปไว้ที่
refs/notes/commits และเก็บบทสนทนาทั้งหมดไว้ที่ refs/notes/memento-full-audit แยกกัน เพื่อให้ได้ทั้ง การติดตามย้อนหลังและความเป็นส่วนตัว
- รองรับผู้ให้บริการ AI หลายราย เช่น Codex และ Claude และสามารถใช้ ทักษะที่ผู้ใช้กำหนดเอง ตอนสร้างสรุป เพื่อควบคุมคุณภาพของ commit note ได้
- ทำงานร่วมกับ GitHub Actions โดยมีฟีเจอร์ คอมเมนต์ commit note อัตโนมัติ, การตรวจสอบ CI gate, และ การย้ายโน้ตอัตโนมัติเมื่อ merge (merge-carry)
- รองรับ Windows/macOS/Linux เป็นเครื่องมือที่ช่วยเพิ่มความโปร่งใสของการสร้างโค้ดด้วย AI และทำให้สามารถ ตรวจสอบย้อนหลัง (audit) การมีส่วนร่วมของ AI ในสภาพแวดล้อมการทำงานร่วมกันได้
ภาพรวมของ git-memento
git-memento เป็นส่วนขยายของ Git สำหรับ บันทึก AI coding session ในระดับคอมมิต
- ระหว่างคอมมิตจะสรุปบทสนทนาของ AI แล้วบันทึกเป็น Markdown note
- ช่วยเก็บ ที่มาและบริบทของบทสนทนา ของ AI ไว้กับแต่ละคอมมิต ทำให้ติดตามกระบวนการสร้างโค้ดได้
- รองรับ Codex เป็นค่าเริ่มต้น และสามารถตั้งค่า AI รุ่นอื่น เช่น Claude ได้
- เผยแพร่ภายใต้สัญญาอนุญาต MIT และแจกจ่ายเป็น ไฟล์รันเดี่ยวแบบ NativeAOT
คำสั่งและความสามารถหลัก
- ใช้
git memento init เพื่อเริ่มต้นการตั้งค่าระดับรีโพซิทอรี และบันทึกข้อมูลผู้ให้บริการ AI ลงใน .git/config
- ใช้คำสั่ง
git memento commit เพื่อเพิ่ม session note ไปพร้อมกับการคอมมิต
- หากใช้ตัวเลือก
--summary-skill จะสามารถแยกเก็บสรุปและเซสชันเต็มออกจากกันได้
- สรุปจะถูกบันทึกไว้ที่
refs/notes/commits และล็อกทั้งหมดจะถูกบันทึกไว้ที่ refs/notes/memento-full-audit
git memento amend ใช้เพิ่มหรือแก้ไขเซสชันใหม่ในคอมมิตเดิมได้git memento audit ใช้ตรวจสอบว่ามีโน้ตตกหล่นในช่วงคอมมิตหรือไม่ และตรวจสอบความถูกต้องของเมทาดาทาgit memento doctor ใช้ตรวจสอบการตั้งค่า การอ้างอิงโน้ต และสถานะการซิงก์กับรีโมต
การจัดการโน้ตและการซิงก์
- ใช้
git memento share-notes เพื่อพุชโน้ตไปยังรีโมตรีโพซิทอรี (origin เป็นต้น)
git memento notes-sync ใช้รวมโน้ตรีโมตอย่างปลอดภัยและสร้างข้อมูลสำรอง
- ซิงก์ทั้ง
refs/notes/commits และ refs/notes/memento-full-audit
git memento notes-carry ใช้ย้ายโน้ตไปยังคอมมิตใหม่หลังการ rebase หรือ squashgit memento notes-rewrite-setup ใช้เปิดการตั้งค่าสำหรับการย้ายโน้ตอัตโนมัติ
การทำงานร่วมกับ GitHub Actions
- ในรีโพซิทอรีมี GitHub Action แบบนำกลับใช้ซ้ำได้ รวมอยู่ด้วย
mode: comment — อ่าน commit note เพื่อ เขียนคอมเมนต์อัตโนมัติmode: gate — ตรวจสอบการขาดหายของโน้ตในขั้นตอน CI และบล็อกบิลด์เมื่อไม่ผ่านmode: merge-carry — ย้ายโน้ตไปยัง merge commit เมื่อ PR ถูก merge
- แต่ละโหมดถูกกำหนดไว้ใน
action.yml และมี อาร์ติแฟกต์สำหรับลงทะเบียนใน Marketplace (dist/note-comment-renderer.js) รวมอยู่ด้วย
- PR ที่ติดป้าย
ignore-notes จะข้ามการตรวจสอบของ gate และทิ้งคอมเมนต์ว่า “Notes ignored”
รูปแบบของโน้ตและการจัดการเวอร์ชัน
- โน้ตถูกบันทึกในรูปแบบ
git notes add -f -m ""
- รองรับหลายเซสชันโดยใช้แท็กเวอร์ชัน(``) และตัวคั่นช่วง
- ข้อความของผู้ใช้จะติดป้ายด้วยชื่อผู้ใช้ Git ส่วนคำตอบของ AI จะติดป้ายด้วยชื่อผู้ให้บริการ
- โน้ตแบบเซสชันเดี่ยวเดิมสามารถอัปเกรดอัตโนมัติได้เมื่อจำเป็น เพื่อคงความเข้ากันได้
4 ความคิดเห็น
สำหรับโปรเจ็กต์ส่วนตัว ผมจะ export เซสชันแล้วคอมมิตไว้ ส่วนโปรเจ็กต์สาธารณะจะคอมมิตไฟล์สรุปก็ต่อเมื่อเห็นว่าจำเป็นจริง ๆ
ยังไงก็มีข้อมูลส่วนบุคคลอยู่ด้วย.. แล้วแต่เครื่องมือด้วย แต่ต่อหนึ่งเซสชันก็มักจะเกิน 10MB แบบสบาย ๆ.. เลยรู้สึกว่าอัปขึ้นไปตรง ๆ คงไม่ค่อยเหมาะเท่าไร
แต่พวกเรากำลังมีชีวิตอยู่ในยุคที่ดิสก์มีราคาถูกกว่าที่เคยไม่ใช่เหรอ!
ความคิดเห็นจาก Hacker News
ตอนที่ฉันเขียนโค้ดกับ AI ฉันจะเริ่มจากไฟล์ project.md
ในนั้นฉันจะอธิบายผลลัพธ์ที่ต้องการ แล้วให้ AI เขียน plan.md จากเนื้อหานั้น
หลังจากนั้นก็แก้ไข plan.md หลายรอบ พอได้แผนที่ต้องการแล้วก็สร้าง todo list แบบละเอียดแล้วต่อไว้ท้าย plan.md
เมื่อพอใจเต็มที่แล้วก็สั่งให้ AI ลงมือทำตาม todo และทำต่อไปจนเสร็จโดยไม่ต้องถามเพิ่ม
สุดท้ายฉัน commit ทั้ง project.md, plan.md และโค้ดทั้งหมด
แบบนี้ทำให้ plan.md กลายเป็น artifact ที่ทำซ้ำได้ อย่างหนึ่ง ซึ่งภายหลังโมเดลที่เก่งขึ้นสามารถใช้มันเพื่อแก้ไขหรือหาข้อผิดพลาดต่อได้
design จะเขียนแยกตามฟีเจอร์ และระบุคำถามที่ยังค้างไว้ให้ชัดเจน
plan จะจัดการในโครงสร้าง
plan/[feature]/phase-N-[description].mdและจะหยุดเมื่อชนข้อจำกัดด้านการ build หรือการรันในขั้น debug จะตั้งสมมติฐานถึงสาเหตุที่เป็นไปได้ แล้วตรวจสอบด้วย logging/tracing ก่อนค่อยแก้
วิธีนี้ให้ผลสำเร็จเกือบ 100% ทั้งกับโปรเจกต์ใหม่และระบบ legacy
ข้อเสียคือมีไฟล์ markdown สะสมเยอะมาก แต่เพราะบันทึกเก่าเป็นประโยชน์ต่อการเปลี่ยนแปลงในอนาคต ฉันเลยยังไม่ทำให้เป็นอัตโนมัติ
ลองดู GitHub spec-kit ได้
พอให้โมเดลทำ market research และทบทวนข้อเสนอแบบวนซ้ำไปเรื่อยๆ มันก็จะเกิด การออกแบบพรอมป์ต์ ด้วยภาษาที่โมเดลเข้าใจได้เอง
ไม่นานมานี้ฉันเพิ่งรู้ว่า XML ส่งผลต่อพฤติกรรมของ Claude เลยกำลังกลับมาคิดโครงสร้างของ GuardRails ใหม่
ลิงก์บทความแนะนำ
พอ plan เสร็จแล้วก็จะสร้าง “context.md” ไว้ใช้อ้างอิงเวลาต้องย้อนแผนที่ผิดในภายหลัง
ยังไม่เคยต้องใช้จริง แต่ในเชิงแนวคิดมันมีประโยชน์
แค่ยังไม่แน่ใจว่าจะเก็บไฟล์พวกนี้ไว้ตรงไหนดี เลยยังไม่ได้รวมไว้ใน repo
เลยอยากรู้ว่าปกติพวกคุณ เก็บไฟล์ md รายงานแยกตามงาน กันไว้ที่ไหน
สำหรับฉัน มันก็เหมือนคำถามว่า “จำเป็นต้อง commit ทุกบรรทัดไหม?”
สุดท้ายแล้วประเด็นคือ บันทึกนี้ทำไว้เพื่อใคร
session ส่วนใหญ่มี noise เยอะ เต็มไปด้วยการลองผิดและข้อมูลที่ไม่จำเป็น
สิ่งสำคัญคือผลลัพธ์ที่ได้จาก session ไม่ใช่กระบวนการทั้งหมด
แต่ spec ตั้งต้นหรือพรอมป์ต์แรกๆ ยังมีคุณค่า ควรสรุปเก็บไว้ในข้อความ commit หรือไฟล์ markdown
เราอาจใช้ session เก่าเป็นบริบทการเรียนรู้เพื่อให้มันสานงานปัจจุบันต่อได้
โดยเฉพาะในการเข้าใจข้อจำกัดของโมเดล และหาจุดที่โค้ดเบี่ยงออกจากเจตนาของผู้ใช้
ท้ายที่สุดฉันคิดว่าการ บันทึก input จากมนุษย์ทั้งหมด สำคัญต่อการพัฒนาโมเดลโอเพนซอร์ส
ผลลัพธ์ควรออกมาเหมือนเดิมแม้รวมเงื่อนไขตั้งต้นและ noise เข้าไปด้วย
ไม่อย่างนั้นการบำรุงรักษาโค้ดในอนาคตจะกลายเป็น เกมเดาเจตนา
บทความที่เกี่ยวข้อง
ฉันเสนอไอเดียคล้ายกันเมื่อสัปดาห์ก่อน (ลิงก์)
แต่ก็มีคนคัดค้านเยอะ — โปรเจกต์ AI ไม่ได้ถูกสร้างจาก input เดียว แต่เป็นกระบวนการแบบโต้ตอบ จึง ทำให้เป็น artifact แบบซอร์สโค้ดยาก
ถึงอย่างนั้นตอนนี้โปรเจกต์ที่สร้างขึ้นแล้วไปลง Show HN มีมากเกินไปจน noise หนักมาก
จะตัดทิ้งทั้งหมดก็คงไม่ได้ แต่ในสภาพตอนนี้มันชวนให้สนใจน้อยลง
ฉันกำลังคิดว่าชุมชนควรจัดการปัญหานี้อย่างไร
โดย commit ไฟล์ research.md และ plan.md เพื่อใช้เป็น พจนานุกรมที่มีชีวิต ของสถาปัตยกรรมและฟีเจอร์
ฉันใส่ชื่อฟีเจอร์เป็นคำนำหน้าชื่อไฟล์ เพื่อให้ Claude ดึงแบบออกแบบที่เกี่ยวข้องขึ้นมาได้เร็ว
บล็อกอ้างอิง
โปรเจกต์ที่เมื่อก่อนน่าสนใจ เดี๋ยวนี้ทำได้ง่ายเกินไป
การบังคับให้คนอ่าน session log ยาวๆ ไม่ใช่คำตอบ ตอนนี้ ความสามารถในการสรุปและการวางแผน สำคัญกว่า
คุณค่าที่แท้จริงของ vibe coding อยู่ที่การได้เห็น กระบวนการลองและล้มเหลว
เพราะสิ่งที่น่าสนใจกว่าการโพสต์แค่ผลลัพธ์ คือการมี กระบวนการสร้างและคำอธิบายประกอบ
เลยอยากให้มีหมวดอย่าง [Creations] แยกจาก [Show HN]
ตัวอย่าง: chess engine ธรรมดาอยู่ [Creations], แต่ chess engine ที่ทำด้วยเงิน 1k อยู่ [Show HN]
PerfBoard และ Lerc เป็นตัวอย่างของแบบนั้น
session เป็นแค่ ผลลัพธ์ระหว่างทาง ไม่จำเป็นต้องรวมอยู่ในผลลัพธ์สุดท้าย
ถ้าเหตุผลของการเปลี่ยนโค้ดสำคัญ ก็ควรสรุปไว้ใน ข้อความ commit หรือเอกสาร
ตอน commit เราไม่รู้ว่าผู้อ่านในอนาคตจะมีคำถามอะไร
เพราะงั้นฉันชอบเก็บ session ไว้ก่อน แล้วค่อย สร้างสรุปจากคำถาม ในภายหลัง
Git AI ใช้แนวทางนี้
เดี๋ยวนี้วิศวกรทำงานกันเร็วมาก แค่ผ่านไปอาทิตย์เดียวก็มักจำไม่ได้แล้วว่าทำไมถึงทำแบบนั้น
พรอมป์ต์เชิงวิจัยควรสรุป ส่วนพรอมป์ต์สร้างโค้ดควรเก็บไว้ตามเดิม
แบบนั้นถึงจะได้ทั้ง การทำซ้ำได้และการรีวิวได้
เพราะแผนจะสะท้อนแม้กระทั่งกระบวนการแก้ error และกลายเป็นเอกสารที่มีประโยชน์ต่อรอบถัดไป
แต่ละ repo ส่งข้อความหากันเพื่อจัดการคำขอฟีเจอร์
ฉันเก็บทั้งบทสนทนาต้นฉบับและ ความทรงจำที่ถูกบีบอัดเชิงความหมาย เพื่อจัดระเบียบ spec และ requirement ใหม่
session log ส่วนใหญ่คือ noise
มันเป็นแค่ชุดของการลองผิดกับการย้อนกลับไปมา ดังนั้นการวางไว้ข้างๆ commit ก็ไม่ต่างจากการเก็บประวัติเบราว์เซอร์
สิ่งสำคัญคือข้อความ commit ที่บอก เจตนาและข้อจำกัด
ถ้า AI เป็นคนเขียนโค้ด แก่นสำคัญไม่ใช่บทสนทนา แต่คือ ทำไมถึงสั่งแบบนั้น
สุดท้ายปัญหาอาจไม่ใช่การเก็บ session แต่เป็น นิสัยที่ละเลยข้อความ commit มากกว่า
ต่อให้ใช้ AI ฉันก็ยังคง กระบวนการออกแบบแบบดั้งเดิม ไว้
requirement → use case → class design → define constraints → รัน AI
วิธีนี้ทำให้มนุษย์ยังคง วิจารณญาณด้านสถาปัตยกรรม ไว้ได้ ขณะที่ AI ช่วยเร่งงาน implement ที่ซ้ำๆ
ถ้าแทน session log ด้วยการใส่เอกสาร UML/constraints แบบนี้ไว้ใน commit ก็จะเก็บ เจตนาและบริบท ได้ชัดเจนกว่า
ฉันคิดว่านักพัฒนาในปี 2026 ควรรักษา โครงสร้างการทำงานร่วมกันที่มีชั้นเชิง แบบนี้ไว้
มันคล้ายกับคำถามว่าจะ squash commit หรือไม่
ถ้าชอบ squash ก็แปลว่าสนใจแค่ผลลัพธ์ ไม่ได้อยากเก็บกระบวนการ
ถ้าไม่ใช่ก็อยากบันทึกการเดินทางทั้งหมด
session ของ AI ก็เหมือนกัน มันมีประโยชน์ต่อ การดีบักกระบวนการคิด แต่คนที่ชอบ history สะอาดๆ ก็ไม่จำเป็นต้องดู
ในทางปฏิบัติควรแยกจัดการ session ไว้นอก repo มากกว่า
ได้ยินมาว่า Mercurial กับ Fossil ทำเรื่องนี้ได้ดีกว่า
ใน vibe-coding นั้น พรอมป์ต์ต่างหากที่แสดงร่องรอยความคิด มากกว่าตัวโค้ด
จะใส่ไว้ใน git หรือไม่เป็นอีกเรื่องหนึ่ง แต่การทำให้เข้าถึงได้มีคุณค่าแน่
ในกรณีนั้นไม่จำเป็นต้องเห็นกระบวนการแบบเรียลไทม์
แต่ถ้าเป็นโค้ดที่ AI เขียนทั้งหมด ก็ควร เปิดเผยพรอมป์ต์
ฉันก็เคยลองดึง session ออกมาแล้ว
ถึงจะมีความเสี่ยงเรื่องข้อมูลหายไปบ้าง แต่ ความอ่านง่ายและการเข้าถึง ดีขึ้นมาก
อย่างน้อยฉันคิดว่าควรเก็บ พรอมป์ต์ฉบับสรุป ของ session ไว้
การรีวิวโค้ดด้วย AI เข้มงวดน้อยกว่ามนุษย์ และเจตนาก็อยู่ในพรอมป์ต์เท่านั้น
ไม่อย่างนั้นเราจะทำผิดซ้ำแบบเดิม
คุณค่าของ code review คือการเรียนรู้และการพัฒนา แต่ AI ไม่ได้เรียนรู้ ดังนั้น การบันทึกพรอมป์ต์ ต้องมาทำหน้าที่นั้นแทน
อีกทั้งยังจำเป็นต่อ การประเมินทักษะการเขียนพรอมป์ต์ หรือการสอนจูเนียร์ด้วย
เราไม่ได้ใส่การกดคีย์ เมนูที่คลิก หรือความพยายามในการดีบักลงไปใน commit
ถ้าเก็บทุกบทสนทนาไว้ noise จะเยอะเกินไป
ทางที่เป็นจริงกว่าคือเก็บแค่เอกสารที่บันทึกเจตนาและสมมติฐาน
มันก็เหมือนถามว่า “ควรใส่ประวัติการค้นหา Google ลงใน commit ไหม?” — ฉันคิดว่าไม่แน่นอน
ทางที่ดีกว่าคือเก็บแค่ เหตุผล สมมติฐาน และสรุปทางเลือก
ในทำนองเดียวกัน log ที่โมเดลงมกับปัญหาเล็กน้อยก็ไม่จำเป็น
> “ถ้าจะรวมประวัติการค้นหาของ Google ไว้ในคอมมิตด้วยไหม?” ก็เป็นคำถามทำนองเดียวกัน — ผมคิดว่าแน่นอนว่าไม่ควร
ชอบคอมเมนต์นี้นะ