ผมกำลังคอมมิตสเปกภาษาเกาหลีแทนโค้ด — แอป PWA + เซิร์ฟเวอร์ด้วยสเปก 3 หน้า

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

ดังนั้นผมจึงลองกลับทิศทางดู โดยคอมมิตสเปกที่บรรจุเจตนาไว้ใน git และถือว่าโค้ดเป็น build artifact เพื่อทดสอบแนวคิดนี้ ผมทำแอปเล็ก ๆ หนึ่งตัวจนเสร็จและเปิดให้ใช้งานแล้ว

มันเป็น PWA ชื่อ Rimlog สำหรับบันทึกการอ่านและการเรียนรู้ โดย AI จะช่วยเชื่อมโยงโน้ตก่อนหน้าให้ ไม่มีเซิร์ฟเวอร์ ไม่ต้องสมัครสมาชิก และข้อมูลอยู่เฉพาะในเบราว์เซอร์เท่านั้น

ตัวแอปเองธรรมดา สิ่งที่อยากแชร์คือวิธีที่ใช้สร้างมัน

วิธีการ

ในโฟลเดอร์ eux/ ของ repo มีสเปกภาษาเกาหลีอยู่ 3 หน้า โครงแอปทั้งหมด 40 บรรทัด วิดเจ็ตการ์ด AI 25 บรรทัด และเซิร์ฟเวอร์ insight อีกหนึ่งหน้า เขียนเป็นประโยคประมาณนี้

saveCapture : บันทึกฟอร์ม capture (ชื่อแหล่งที่มา·คำอ้างอิง·ความคิดของฉัน·แท็ก) — แทรกไว้หน้าสุดของ captures + สะท้อนไปยัง local storage + toast “บันทึกแล้ว” + สลับไปแท็บประวัติ

เมื่อนำไฟล์นี้ใส่ในเครื่องมือชื่อ EstreUX ก็จะได้โค้ดออกมา (เรียกว่า brew) ในโค้ดที่สร้างขึ้นจะฝัง hash ของสเปกไว้ และถ้าแก้เฉพาะสเปกหรือแก้เฉพาะโค้ด pre-commit จะบล็อกการคอมมิตไว้ เป็นการใช้ gate ป้องกันปัญหาที่ว่าสเปกกลายเป็นคำโกหกทันทีเมื่อมันล้าสมัย

ผมลองวัดตัวเลขด้วย โดยทดสอบจริงในลักษณะย้อน keypad ตัวเลข 152 บรรทัดที่มีอยู่เดิมในเฟรมเวิร์กให้กลับมาเป็นสเปก 28 บรรทัด พบว่าจำนวนบรรทัดที่มนุษย์ต้องดูแลลดลง 60–82% ตัวโค้ดที่สร้างขึ้นเองบางครั้งยาวกว่าต้นฉบับด้วยซ้ำ สิ่งที่ลดลงคือฝั่งที่มนุษย์ต้องอ่านและแก้ไข บันทึกการวัด อยู่ใน repo

เซิร์ฟเวอร์ก็เป็นสเปกหนึ่งหน้าเช่นกัน

เดโมบน Pages เป็น serverless ดังนั้น AI จึงทำงานได้แค่ fallback ด้วยแท็กที่ซ้อนทับกัน เพื่อให้ทำงานได้จริงจัง ผมจึงใส่เซิร์ฟเวอร์แบบ self-hosted เข้าไป ซึ่งตัวนี้ก็เป็นไฟล์ node ไฟล์เดียวแบบไม่มี dependency ที่ brew มาจากสเปกหนึ่งหน้าเช่นกัน สามารถเลือก backend ใช้ได้

• nvidia (ค่าเริ่มต้น): เป็น API ฟรีของ build.nvidia.com ให้ key โดยไม่ต้องลงทะเบียนบัตร รองรับ OpenAI-compatible และได้ราว 40 ครั้งต่อนาที จึงเหลือเฟือสำหรับไดอารีส่วนตัว
• claude-cli / codex-cli: เรียก claude -p / codex exec เป็น child process ต่อคำขอ เป็นเส้นทางสำหรับนำ subscription Claude/ChatGPT ที่จ่ายอยู่แล้วมาใช้ซ้ำโดยไม่ต้องใช้ API key
• openai / google: เป็นเพียง key proxy

key และการยืนยันตัวตนอยู่เฉพาะบนเซิร์ฟเวอร์ ไม่ถูกส่งออกไปยังเบราว์เซอร์

สิ่งที่ยังไม่มั่นใจ

ตอนนี้กำลังขยายการตัดสินความสอดคล้องระหว่างสเปก↔โค้ด จาก static diff ไปเป็นการตรวจแบบ dynamic โดยอิง property แต่การ calibration น้ำหนักยังไม่เสร็จ และยังพบกลุ่ม false positive ที่ framework render ในสภาพแวดล้อม headless DOM ทำงานต่างจากเบราว์เซอร์จริง จึงเป็นการบ้านอีกอย่างที่ต้องยกระดับสภาพแวดล้อมการตรวจสอบไปเป็นเบราว์เซอร์จริง ถ้าดูประวัติ commit ตั้งแต่แรก จะเห็นกระบวนการ scaffold→สเปก→generate→ขัดเกลา เรียงตามลำดับอยู่

• ไลฟ์: https://soliestre.github.io/Rimlog/
• repo: https://github.com/SoliEstre/Rimlog
• บันทึกการ build (ละเอียด): https://estreui.tistory.com/5

ผมอยากถามสองเรื่องครับ คุณมองว่ากับดักของวิธีที่ให้สเปกเป็น SSoT คืออะไร โดยเฉพาะอยากรู้ว่าคุณเคยเจอจุดที่พลังการแสดงออกของสเปกตามโค้ดไม่ทันตรงไหนบ้าง และเส้นทางนำ subscription กลับมาใช้ซ้ำโดยใช้ claude -p เป็น backend ของแอป มีอะไรที่น่าจะติดขัดในการใช้งานจริงไหม (ในแง่ rate, เงื่อนไขการใช้งาน, latency)