รับแอปรับแอป

เขียน README ให้โหดก่อน แล้วค่อยให้ AI เขียนโค้ด: เล่าประสบการณ์ทำ Kaiten Share Calculator แบบงูๆ ปลาๆ แต่โคตรเวิร์ก

ปกรณ์ พูนผล01-29

เปิดก่อน: จากเว็บคิดเงินซูชิ สู่การเล่นกับ Context Engineering

ผมเริ่มลองทำเว็บ คิดราคาซูชิสายพาน (Kaiten Share Calculator) ด้วยการใช้ AI ช่วยเขียนโค้ด ปรากฏว่ามีเพื่อนๆ เข้ามาลองใช้กันเยอะพอสมควร เลยถือโอกาสมานั่งเล่าวิธีคิดและวิธีทำแบบบ้านๆ ให้ฟัง

โปรเจกต์นี้ผมไม่ได้เริ่มจากการสั่ง AI เขียนโค้ดตรงๆ แต่ลองใช้แนวคิดที่มารู้ทีหลังว่าเรียกว่า Context Engineering

พูดง่ายๆ คือ เขียน README.md ก่อน แล้วค่อยให้ AI อ่านแล้วเขียนโค้ดทีเดียวตามสเปก

ผลลัพธ์คือ ตัวระบบที่ได้มาทำงานถูกต้องและแสดงผลอย่างที่อยากได้ประมาณ 95% ที่เหลืออีก 5% เป็นเรื่อง UX/UI กับบั๊กเล็กๆ เรื่องการคำนวณที่ต้องมานั่งแก้มือเอง

แต่แค่นี้ก็ถือว่า AI กลายเป็น Junior Programmer ให้เราได้แล้ว ไม่ใช่แค่ Co-pilot หรือ Code Assistant เฉยๆ

โพสต์นี้เลยอยากสรุปแนวทางแบบง่ายๆ เผื่อใครอยากลองทำตามด้วยตัวเอง

เริ่มจากการออกแบบ Requirement และ Structure ให้ AI ก่อน

ตอนแรกผมยังไม่รู้จักคำว่า Context Engineering ชัดๆ ด้วยซ้ำ แค่ลองทำตามสัญชาตญาณ และดูจากโครงสร้างไฟล์อย่าง `CLAUDE.md` กับ `README.md` ที่ Claude Code สร้างออกมา

สรุปเลยออกมาเป็นโครงแบบนี้ ที่ผมใช้เขียนสเปกให้ AI อ่าน:

  • ชื่อโปรแกรม
    ตั้งชื่อให้ชัด เช่น `Kaiten Share Calculator`

  • Summary หรือ Goal
    เขียนสั้นๆ ว่าโปรแกรมนี้เอาไว้ทำอะไร เช่น
    🍣 Conveyor Belt Sushi/Mala Bill Calculator – Web App for Thailand

  • Feature List
    แยกเป็น bullet ใหญ่ๆ เป็นฟีเจอร์หรือโมดูล แล้วในแต่ละอันใส่ Business Condition / รายละเอียดการทำงาน ลงไปให้ครบ ว่าต้องทำอะไร ยังไง

  • Technology Stack
    บอกให้ชัดว่าอยากใช้เทคโนโลยีอะไร เช่น Frontend / Backend / Database / Test หรือ Architecture / Library ที่อยากเจาะจง เช่น
    `HTML5 / CSS3 / TailwindCSS / Responsive / LocalStorage / Modular Design`

  • User Journey
    เล่าให้ AI ฟังว่าผู้ใช้จะเดินเรื่องยังไงในแต่ละฟีเจอร์ หรือแต่ละโมดูล กดตรงไหน เห็นอะไร ทำอะไรต่อ

  • JSON Config
    วางโครงข้อมูลไว้ก่อนเลยว่าอยากเก็บอะไร ฟิลด์ไหนชื่ออะไร ใช้ยังไง
    ผมสังเกตว่า AI ฉลาดพอจะเอา JSON Config พวกนี้ไปใช้เป็นฐานออกแบบโปรแกรมต่อได้เลย

  • UI (ถ้ามี)
    ใน Kaiten Share Calculator ผมไม่ได้บังคับ UI มาก ปล่อยให้สร้างตาม Journey ที่กำหนด แต่ในอีกโปรเจกต์หนึ่งอย่าง `Google Map Point` ผมลองเอาไฟล์ UI แบบ SVG ใส่ในโฟลเดอร์ให้ AI อ่านด้วย มันก็เอาไปอ้างอิงตอนเขียนโค้ดให้

  • Test Case
    ถ้าทำได้ แนะนำให้เขียนไว้ตั้งแต่แรก แต่ผมไปเขียนตามทีหลัง เพื่อใช้เป็นฐานให้ AI ช่วยเขียน Unit Test ทดสอบระบบต่อให้

ทั้งหมดนี้ ผมร่าง Requirement แบบภาษาไทยง่ายๆ แล้วค่อยให้ ChatGPT ช่วยจัดระเบียบบท ความ แยกหัวข้อให้ชัด แล้วแปลเป็นภาษาอังกฤษอีกที จากนั้นค่อยเอาไปใส่เป็น `README.md` ให้ AI ตัวอื่นอ่านต่อ

แล้วพอได้ไฟล์สเปกชัดๆ แล้ว ค่อยสั่ง Claude Code ให้อ่าน README.md แล้ว ลงมือเขียนโค้ดจริงให้ในรอบเดียว

ทำไมแบบนี้ถึงเวิร์กถึง 95%

จากที่ลองมา การเขียน README ให้ละเอียดก่อนแล้วค่อยให้ AI ลงมือโค้ด ทำให้

  • โค้ดที่ได้ ตรงสเปก ตั้งแต่แรก ไม่ต้องมานั่งแก้ไปกลับเยอะ

  • ภาพรวมโปรเจกต์ชัดทั้งฝั่งเราและฝั่ง AI เพราะเราบังคับให้ตัวเองคิด Requirement ให้ครบก่อน

  • AI สามารถมองเห็นเป็น ทั้งระบบ ตั้งแต่ Business Flow, Data, Journey, Tech Stack แทนที่จะถูก feed เป็นคำสั่งสั้นๆ ทีละชิ้น

ส่วน 5% ที่ยังไม่เป๊ะ ส่วนใหญ่คือ

  • เรื่อง UX/UI ที่ต้องอาศัยเซนส์ของคนอยู่ดี

  • บั๊กเล็กๆ เรื่องการคำนวณเงินและภาษี ที่ต้องเทสต์เองและไล่แก้เพิ่ม

แต่ในมุมมองผม แค่ให้ AI เขียนโค้ดระดับใช้งานได้ 95% แล้วเรามาเกลาอีกนิด ก็ถือว่า ประหยัดแรงแบบสุดๆ

ถ้าอยากให้ AI ทำงานได้ดีขึ้นอีก ลองใส่ Requirement พวกนี้เพิ่ม

พอทดลองแล้วรู้สึกว่า ถ้าเพิ่มสเปกให้ละเอียดขึ้นอีกนิด ผลลัพธ์จะยิ่งนิ่งและตรงใจมากขึ้น โดยเฉพาะถ้าระบบเริ่มใหญ่ขึ้น

แนะนำให้เพิ่มอีก 3 ส่วนนี้เข้าไป:

  • Database Schema
    คล้ายกับ JSON Config แต่ลงรายละเอียดเชิงโครงสร้างให้ชัดขึ้น เช่น
    ตารางไหนเก็บอะไร ฟิลด์ชื่ออะไร ชนิดข้อมูลอะไร แต่ละฟิลด์หมายถึงอะไร มีความสัมพันธ์กันยังไง

  • API Spec
    เขียนเลยว่า API แต่ละตัวทำอะไร รับ Input แบบไหน ส่ง Output อะไรกลับมา สรุป Flow การทำงานคร่าวๆ ให้ครบ

  • Project File Structure
    กำหนดโครงสร้างไฟล์ไว้ล่วงหน้า เช่น แยกโฟลเดอร์ `src`, `components`, `services`, `tests` ยังไง
    ถ้าบอกชัดๆ AI ก็จะจัดโค้ดตามนั้น ทำให้โปรเจกต์ดูเป็นระเบียบตั้งแต่แรก

ยิ่งเราคิดสเปกละเอียดเท่าไร AI ก็ยิ่งเขียนโค้ดได้มีคุณภาพเท่านั้น

เช็กว่า AI เข้าใจเราจริงไหม ด้วยคำสั่งเดียว

สำหรับคนที่ใช้ Claude Code อยู่ มีทริกเล็กๆ ในการเช็กว่า AI เข้าใจโปรเจกต์เราถูกแค่ไหน คือให้มันสรุปเองเลยว่ามันเห็นอะไรในโฟลเดอร์บ้าง

ลองรันคำสั่งนี้ในโปรเจกต์:

`# claude /init`

แล้ว Claude AI จะไปอ่านโฟลเดอร์โปรเจกต์ทั้งหมด จากนั้นสรุปออกมาเป็นไฟล์ `CLAUDE.md`

เราแค่เข้าไปอ่านไฟล์นั้นดูก็จะรู้ทันทีว่า

  • มันเข้าใจโครงสร้างโปรเจกต์ยังไง

  • มอง Requirement เราแบบไหน

  • มีอะไรตกหล่นไปไหม

ถ้าเราแก้ Requirement หรือเพิ่มสเปกทีหลัง ก็อย่าลืม สั่งให้มันอัปเดต `CLAUDE.md` ตามด้วย จะได้ไม่หลุดบริบท

ตัวอย่างแนวทางเขียน Requirement ในโปรเจกต์จริง

ถ้าอยากดูตัวอย่างของจริงว่าหน้าตา Requirement, README, โครงโปรเจกต์เป็นยังไง สามารถดูโปรเจกต์ใน Git ได้ เช่น

  • โปรเจกต์ที่ เขียนสเปกก่อน แล้วค่อยให้ AI ทำโค้ด
    `kaiten-share-calculator`

  • โปรเจกต์ที่ เขียนโค้ดก่อน แล้วค่อยให้ AI เขียนสเปกตาม
    `google-map-point`

ทั้งสองแบบให้ฟีลคนละอย่าง ลองเล่นทั้งคู่แล้วจะเห็นภาพว่า ถ้าเราคุม Requirement ดีตั้งแต่ต้น AI จะทำงานให้เราได้สบายมือกว่ามาก

ก้าวต่อไป: แตกงานใหญ่ด้วย MCP และ Task Master

หลังจากลองกับโปรเจกต์เล็กๆ อย่าง Kaiten Share Calculator แล้ว ขั้นต่อไปที่อยากลองคือ

  • ทำระบบที่ใหญ่ขึ้น

  • ใช้เครื่องมืออย่าง MCP และ Task Master มาช่วยแตกงานเป็น Task ย่อยๆ

เป้าหมายคืออยากลองดูว่า ถ้าโปรเจกต์ซับซ้อนมากขึ้น แล้วเราวาง Requirement + Task Breakdown ดีๆ
AI จะสามารถช่วยเราตั้งแต่ระดับออกแบบ จนถึงระดับลงมือเขียนและเทสต์ได้แค่ไหน

ไว้มีเวลาได้ลองจริง เดี๋ยวจะเอามาเล่าต่อว่าเวิร์กไม่เวิร์ก ติดตรงไหน และต้องปรับวิธีคุยกับ AI ยังไงบ้าง

สรุปคือ ถ้าอยากให้ AI เขียนโค้ดได้ดีขึ้นแบบสัมผัสได้ ลองเปลี่ยนจากการถามสั้นๆ แบบ Prompt ทีละบรรทัด มาเป็นการ เขียน README/Requirement ให้ละเอียดก่อน แล้วค่อยโยนให้ AI อ่านทีเดียว

แค่ขยับมาคิดเป็นระบบขึ้นนิดนึง คุณจะได้ AI ที่ทำงานใกล้เคียง Junior Dev ประจำทีม มากกว่าผู้ช่วยตอบแชทธรรมดาเยอะเลย