0github - โปรแกรมดู Diff แบบฮีตแมปสำหรับการรีวิวโค้ด

 (0github.com)
6 คะแนน โดย GN⁺ 2025-11-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือที่แยกสี แต่ละบรรทัดและโทเคน ภายในโค้ดที่เปลี่ยนแปลง (diff) เพื่อแสดงให้เห็นว่าควรตรวจทานมากน้อยเพียงใด
  • ออกแบบมาเพื่อเน้น ‘ส่วนที่ควรกลับไปดูอีกครั้ง’ แทนการตรวจหาบั๊กแบบง่าย ๆ
  • ใช้งานได้ทันทีด้วยการเปลี่ยน github.com ใน URL ของ GitHub Pull Request เป็น 0github.com
  • ภายในระบบจะ โคลนรีโพสิตอรีไปยัง VM และรัน gpt-5-codex เพื่อสร้างผลการวิเคราะห์ในรูปแบบโครงสร้าง JSON

ภาพรวม

  • เครื่องมือนี้จะแสดงแต่ละส่วนของโค้ดที่เปลี่ยนแปลงระหว่างการรีวิวโค้ดในรูปแบบฮีตแมป ว่า ควรได้รับการตรวจอย่างละเอียดมากน้อยแค่ไหน
  • สีถูกกำหนดตาม ระดับความจำเป็นที่มนุษย์ต้องใส่ใจ ซึ่งเป็นแนวทางที่ต่างจากการตรวจหาข้อผิดพลาดแบบตรงไปตรงมา

วิธีการทำงาน

  • ผู้ใช้เข้าถึงได้โดยเปลี่ยนโดเมนใน URL ของ GitHub Pull Request จาก github.com เป็น 0github.com
  • ระบบจะโคลนรีโพสิตอรีดังกล่าวไปยัง เครื่องเสมือน (VM) และรัน โมเดล gpt-5-codex กับแต่ละ diff
  • จากนั้นจะพาร์ส โครงสร้างข้อมูล JSON ที่โมเดลสร้างขึ้น แล้วแปลงเป็นฮีตแมปสี

เกณฑ์การวิเคราะห์

  • ไม่ได้ดูแค่ว่า “มีบั๊กหรือไม่” แต่จะเน้นส่วนที่มนุษย์ควรกลับไปตรวจอีกครั้ง เช่น ค่าลับที่ฮาร์ดโค้ดไว้, โหมดการเข้ารหัสที่ผิดปกติ, ลอจิกที่ซับซ้อน เป็นต้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-11-01
ความคิดเห็นจาก Hacker News

  • ถ้าเป็นโค้ดเบสที่คุ้นเคย ก็จะคิดว่า “ขอบคุณนะ LLM แต่ฉันรู้ดีกว่าเลยไม่จำเป็น”
    แต่ถ้าเป็นโค้ดที่ไม่คุ้นเคย ตั้งแต่แรกฉันก็จะไม่อนุมัติรีวิวหรือ merge อยู่แล้ว
    ถึงอย่างนั้นการนำ LLM มาใช้แบบ สร้างสรรค์ ก็น่าสนใจดี

    • ลองทดสอบเองแล้ว เลือก Laravel PR #57499 แบบสุ่ม ที่การตั้งค่า 60% เน้นเฉพาะโค้ดทดสอบและพลาดการเปลี่ยนแปลงสำคัญไป
      โค้ดที่ถูกลบก็ไม่แสดงเลย และกลับไฮไลต์เฉพาะบรรทัดที่ไม่ได้เปลี่ยน
      เป็นความพยายามที่จริงใจ แต่ผลลัพธ์น่าผิดหวัง

  • สงสัยว่าทำไมถึงต้องขอสิทธิ์ให้ทำงานแทนฉันบน GitHub ด้วย
    cmux-agent ขอสิทธิ์เข้าถึงทั้งบัญชี GitHub
    พยายามจะเปิด issue แต่ในรีโปปิดฟังก์ชัน issue ไว้ เลยให้ความรู้สึก น่าสงสัยนิด ๆ

    • ถ้าเป็นรีโปสาธารณะ ก็ควรเข้าถึงได้โดยไม่ต้องล็อกอิน
      ลองทดสอบ PR ตัวอย่าง, stack-auth, tinygrad, datasette ในโหมดไม่ระบุตัวตนแล้ว ใช้งานได้ปกติ
      ไม่รู้มาก่อนว่า issue ถูกปิดไว้ และตอนนี้ หน้า issue ก็กลับมาใช้งานได้แล้ว
    • นี่เป็นปัญหาเชิงโครงสร้างของ GitHub เอง ถ้าดู การสนทนาที่เกี่ยวข้อง จะเห็นว่าโมเดลสิทธิ์ของ OAuth App กับ GitHub App ต่างกัน
      GitHub App ติดตั้งได้เฉพาะบางรีโป แต่ก็ยังมีสิทธิ์ “ทำงานแทนผู้ใช้” รวมอยู่ด้วย
      เลยเกิดป๊อปอัปที่ดูน่ากลัวแบบนั้น
      แอปของฉัน codeinput.com ใช้ OAuth App เลยขอแค่อีเมล แต่หลังล็อกอินก็ต้องผ่านขั้นตอนติดตั้งอีกที ทำให้ flow การยืนยันตัวตน ซับซ้อน
    • แอปบังคับให้ล็อกอิน GitHub ตั้งแต่ตอนรันครั้งแรก ก่อนหน้านั้นจะดูอะไรไม่ได้เลย

  • ทิศทางน่าสนใจ แต่ ความคุ้มค่าเมื่อเทียบกับต้นทุน ยังไม่ชัด
    ตอนนี้ LLM ยังเข้าใจบริบทของโปรเจกต์จากแค่ PR diff เดียวได้ยาก
    กลับกัน heatmap แบบอิงข้อมูล ที่ดูจากบั๊กในอดีตหรือความถี่ของการเปลี่ยนแปลงน่าจะเชื่อถือได้มากกว่า

    • ถ้าใช้คีย์ฟรีของ Gemini จำนวนรีเควสต์ต่อวันก็เพียงพอ ดังนั้นสำหรับทีมเล็ก ๆ (10~20 PR/วัน) ค่าใช้จ่ายไม่ได้มากนัก
      ถ้ารันด้วยคีย์ส่วนตัวได้ก็น่าจะดีกว่า
    • สงสัยว่ามีเครื่องมือคล้ายกันที่วิเคราะห์ entropy ของ diff ไหม
    • เมื่อก่อนเราก็เคยทดลอง clone รีโปลง VM แล้วให้ Codex เข้าไปสำรวจ แต่หยุดไปเพราะปัญหา latency และต้นทุน
      คิดว่าการทำ distillation อาจช่วยลดต้นทุนได้ แต่ยังอยู่ระหว่างทดลอง
      และก็กำลังคิดด้วยว่าจะคำนวณความสัมพันธ์กับบั๊กในอดีตโดยไม่ใช้ LLM ได้ไหม
    • ตอนรีวิวโค้ดก็มักจะพูดถึงบรรทัดที่ไม่ได้อยู่ใน diff บ่อย ๆ
      เครื่องมือแบบนี้สุดท้ายก็แก้ได้แค่ ส่วนหนึ่งของปัญหา
    • ส่วนที่มีการเปลี่ยนโค้ดบ่อยก็อาจไม่ได้แปลว่ามีบั๊กเยอะเสมอไป
      ตรงกันข้าม อาจเป็นบริเวณที่คนระวังกันมากกว่า
      ถ้าเอาข้อมูลโอเพนซอร์สมาพิสูจน์ก็น่าจะน่าสนใจ

  • ดีใจที่ PR ของฉัน ขึ้น HN
    อยากให้ตั้ง threshold เป็น 0% แล้วปรับ ไล่เฉดสี ได้หลากหลายกว่านี้
    สงสัยด้วยว่าจะใช้เครื่องมือนี้รีวิวโค้ดที่ AI สร้างก่อนเปิด PR ได้ไหม

    • มีแผนจะทำให้สีและการไล่ระดับปรับตั้งค่าได้
      อยากถามความเห็นว่าถ้าทำเป็นคำสั่งสำหรับ render diff ผ่าน CLI หรือ HTML จะโอเคไหม
    • ใช้เครื่องมือแบบนี้ไป ๆ มา ๆ สุดท้ายอาจ ใช้เวลามากกว่านั่งเขียนโค้ดเอง

  • ชื่อโดเมน 0github.com ดูเหมือนจะใช้ยาว ๆ ได้ยาก น่าจะรีบหาโดเมนอื่นดีกว่า

    • อยากรู้ว่าเพราะอะไร

  • น่าจะมีประโยชน์มากโดยเฉพาะกับ PR ขนาดใหญ่
    แทนที่จะใช้ slider ถ้าคลิกตามสีแล้วเห็นความหมายได้ทันทีน่าจะดีกว่า
    ตอนนี้ยังดูเข้าใจยากในแวบแรก แต่ถ้าใช้บ่อยก็น่าจะชิน

    • ตอนนี้ถ้าเอาเมาส์ไปวางบนคำที่ถูกไฮไลต์ จะมี tooltip แสดงขึ้นมา
      วางแผนจะปรับให้แสดงบนมือถือได้ด้วย ถ้ามีวิธีแสดงแบบอื่นที่ดีกว่าก็อยากรู้

  • ลองใช้กับ Rust PR แบบง่าย ๆ แล้วทำงานได้ค่อนข้างดี
    แต่อยากให้ปรับตำแหน่งการไฮไลต์ได้ละเอียดกว่านี้หน่อย
    ที่น่าประทับใจคือมันจับ typo ที่แทบมองไม่เห็นใน PR ของเพื่อนได้
    ลิงก์ PR ที่ทดสอบ
    โค้ดที่ถูกลบบางส่วนมีการแสดงผล แต่ส่วนใหญ่ถูกมองข้าม
    เลยสงสัยว่าใช้วิธีคำนวณ ระยะห่างระหว่างโทเค็น หรือเปล่า

    • implementation อยู่ใน ไฟล์นี้
      ตอนนี้ยังเป็นแบบ prompt ของ LLM อย่างง่าย
      ต่อไปอาจพัฒนาไปเป็นวิธีตรวจจับ hallucinated token ได้ กำลังจะไปหางานวิจัยที่เกี่ยวข้องดู

  • ช่วงนี้มี PR ขนาดใหญ่ที่ AI สร้างเยอะขึ้น เลยรู้สึกว่าต้องการเครื่องมือแบบนี้
    ถ้าเรียนรู้ สไตล์ของผู้รีวิว แล้วให้รีวิวแบบปรับตามแต่ละคนได้ก็น่าจะดี
    กำลังตรวจอยู่ว่า commit นี้ ใช่หรือเปล่า

    • logic หลักอยู่ใน ไฟล์นี้
      กำลังทดลองทำรีวิวอัตโนมัติที่ปรับตาม ความชอบของผู้รีวิว ด้วยระบบ DSPy

  • ที่จริงสิ่งสำคัญกว่าคือการทำ PR ที่มีขนาดพอดี จนไม่ต้องพึ่งเครื่องมือแบบนี้
    ทุกวันนี้ต้องรีวิว PR ที่ AI เขียน และถึงขั้นมี AI มาตอบคอมเมนต์ของฉันอีก
    สุดท้ายก็ดูเหมือนว่าเรากำลังจะเข้าสู่ยุคที่ผู้รีวิวเองก็ถูกแทนที่ด้วย AI

  • คลิก PR ตัวอย่างแล้วมีแต่โหลดค้าง ดูเหมือนต้องมี caching

    • น่าจะมี cache อยู่แล้ว กำลังตรวจสอบ
    • แก้เสร็จแล้ว ตอนนี้ใช้งานได้ปกติ