บริษัทอัตโนมัติ · THEAUTOMATION.BIZ

หลักการ Vibe Coding ด้วย
Development Loop

Development Loop คือวงจรห้าขั้นของชุด skill Superpowers ที่พาไอเดียในหัว ไปถึงระบบที่พนักงานใช้จริง
สำหรับคนที่ไม่เขียนโค้ด แต่กำลังจะสร้าง micro-ERP ของบริษัทเอง

สารบัญ · กดที่หัวข้อเพื่อข้ามไปบทนั้น

เนื้อหาทั้งหมด แบ่งเป็นสี่บท

บทที่ 1

ทำไมต้องมีวงจร

AI ทำตามที่คุณพิมพ์ ไม่ได้ทำตามที่คุณคิด ช่องว่างตรงนั้นคือที่มาของงานที่ต้องรื้อ วงจรนี้มีไว้ปิดช่องว่างก่อนเสียเวลา

ปัญหาของการสั่งรวดเดียว ภาพรวมห้าขั้น skill คืออะไร ติดตั้งครั้งแรก

พิมพ์สั่งรวดเดียว
ได้ของที่ไม่ตรงเสมอ

"ทำระบบสต็อกให้หน่อย" เป็นประโยคที่สั้นเกินกว่าจะตีความได้ทางเดียว AI จึงเดา แล้วเดินยาวไปบนสิ่งที่เดาผิด

1คุณรู้เรื่องธุรกิจ AI รู้เรื่องโค้ด ความรู้สองก้อนนี้ไม่เคยมาเจอกัน ถ้าไม่มีใครบังคับให้ถาม

2งานใหญ่ก้อนเดียวตรวจไม่ได้ พอเสร็จมาทั้งระบบ คุณไม่รู้จะเริ่มตรวจตรงไหน เลยกดผ่านทั้งหมด

3คุยยาวเกินไป AI จะเริ่มลืม บทสนทนายิ่งยาว ความแม่นยำยิ่งตก ข้อตกลงหน้าแรกหายไปตอนหน้าท้าย

4ไม่มีใครตรวจก่อนบันทึก โค้ดที่ทำงานได้ กับโค้ดที่ถูกต้องและปลอดภัย ไม่ใช่เรื่องเดียวกัน

วงจรนี้แก้ด้วยการบังคับลำดับแต่ละขั้นมีของที่ต้องได้ออกมาเป็นชิ้นเป็นอัน และขั้นถัดไปเริ่มไม่ได้ถ้าของชิ้นนั้นยังไม่มี ความคืบหน้าจึงวัดได้แม้คุณอ่านโค้ดไม่ออก

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

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

skill คืออะไร

skill คือคู่มือการทำงานที่เขียนไว้ล่วงหน้า ให้ AI อ่านก่อนลงมือ ไม่ใช่โปรแกรมใหม่ และไม่ใช่ AI ตัวใหม่

1เรียกด้วยขีดเฉียงนำหน้า พิมพ์ /superpowers:brainstorming แล้ว AI จะเปิดคู่มือเล่มนั้นขึ้นมาอ่าน แล้วทำตามขั้นตอนในนั้นแทนที่จะเดาเอง

2ต่างจากการพิมพ์สั่งเองตรงความสม่ำเสมอ คุณสั่งเรื่องเดิมสิบครั้งอาจได้สิบแบบ แต่ skill เดิมให้ขั้นตอนเดิมทุกครั้ง ไม่ว่าใครเป็นคนสั่ง

3เป็นไฟล์ข้อความธรรมดา เปิดอ่านได้ แก้ได้ ไม่ใช่กล่องดำ ทุกเล่มอยู่ในโฟลเดอร์ skills/ ของชุดนี้ ถ้าวันหนึ่งขั้นตอนไหนไม่เข้ากับบริษัทคุณ ก็แก้เล่มนั้นได้

ห้าคำสั่งในเด็คนี้มาจากชุด skill ชื่อ Superpowers ชื่อเต็มขึ้นต้นด้วย /superpowers: เสมอ ติดตั้งครั้งเดียวแล้วใช้ได้ทุกโปรเจ็คบนเครื่องคุณ ไม่ต้องติดตั้งใหม่ต่อโปรเจ็ค

# ติดตั้งชุด skill · ทำครั้งเดียว
/plugin install \
  superpowers@claude-plugins-official

# ลืมว่ามีอะไรบ้าง ให้ถามแผนที่
/superpowers:using-superpowers

# ชื่อยาว แต่พิมพ์แค่สองสามตัวอักษร
# แล้วกด Tab ให้มันเติมให้
/sup⇥

จำแค่ห้าคำก็พอในชุดนี้มี skill เกือบยี่สิบตัว แต่ห้าตัวที่จะเล่าในบทถัดไปครอบคลุมงานเก้าสิบเปอร์เซ็นต์ที่คุณจะเจอ ที่เหลือค่อยเปิดดูตอนต้องใช้

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

ห้าขั้น จากไอเดียถึงของที่ใช้ได้

อ่านจากซ้ายไปขวา แต่ละกล่องคือคำสั่งหนึ่งคำ และของที่ต้องได้ออกมาหนึ่งชิ้น ขั้นที่สามกับสี่วนซ้ำจนครบทุกงานในแผน

ทุกคำสั่งขึ้นต้นด้วย /superpowers: เหมือนกันหมด จำแค่ห้าชื่อท้าย บทถัดไปลงรายละเอียดทีละขั้นว่าคุณต้องทำอะไร และ AI จะส่งอะไรกลับมา

บทที่ 2

ห้าขั้นตอนหลัก

ทีละขั้น ว่าคุณต้องพิมพ์อะไร AI จะทำอะไร และของที่ได้ออกมาหน้าตาเป็นยังไง ถ้าของชิ้นนั้นยังไม่มี แปลว่ายังข้ามไปขั้นต่อไปไม่ได้ ทุกชื่อข้างล่างนี้เติม /superpowers: ข้างหน้าเสมอ

brainstorming writing-plans executing-plans requesting-code-review finishing-a-development-branch

ขั้น 01 · คุยให้ตกผลึก

คุณเป็นฝ่ายถูกสัมภาษณ์ ไม่ใช่ฝ่ายสั่ง มันยิงคำถามทีละข้อจนไม่เหลือจุดที่ต้องเดา แล้วปิดท้ายด้วยการเขียนสเปกให้เอง

1ถามทีละข้อ ไม่ยิงรัว ตอบสั้น ๆ ได้ ตอบว่า "ยังไม่รู้" ก็ได้ แต่ห้ามตอบกำกวม เพราะความกำกวมจะกลายเป็นโค้ดที่ผิด

2ข้อเท็จจริงเป็นหน้าที่ AI การตัดสินใจเป็นหน้าที่เจ้าของกระบวนการ มันไปหาข้อมูลเองได้ แต่ห้ามตัดสินใจแทนว่าธุรกิจควรทำงานยังไง

3มันเสนอสองสามทางเลือกให้ตัดสิน พร้อมข้อดีข้อเสียและทางที่มันแนะนำ เจ้าของกระบวนการเลือก แล้วมันค่อยเดินต่อ

ของที่ต้องได้ออกมา ไฟล์สเปกใน docs/specs/ ที่ถูก commit ไว้แล้ว ถ้ายังไม่มีไฟล์นี้ แปลว่ายังคุยไม่จบ

# เปิดในโฟลเดอร์โปรเจ็ค แล้วพิมพ์
/superpowers:brainstorming

"อยากทำระบบเบิกของจากคลัง
 ให้พนักงานหน้างานกดเบิกเองได้"

# จากนั้นมันจะเริ่มถามกลับ เช่น
# ใครอนุมัติการเบิก
# เบิกเกินสต็อกได้ไหม
# ของที่เบิกแล้วคืนได้หรือเปล่า

ช่วงนี้คือช่วงที่คุณมีค่าที่สุดคำถามที่ตอบยาก มักเป็นคำถามที่ถ้าไม่ตอบวันนี้ จะกลายเป็นงานรื้อในเดือนหน้า อย่ารีบข้าม

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

ขั้น 01 มีสามเส้นทาง มันจะบอกก่อนว่าเลือกทางไหน

ประโยคแรกที่มันตอบกลับคือชื่อเส้นทาง ฟังให้ดี เพราะถ้าเลือกผิด คุณแก้คำเดียวจบ ปล่อยไว้คืองานรื้อ

Spike · แค่อยากรู้ว่าทำได้ไหม"ต่อกับระบบบัญชีเก่าได้หรือเปล่า" ไม่เขียนสเปก ไม่เก็บโค้ด ได้คำตอบแล้วทิ้ง แล้วค่อยเริ่มเส้นทางจริง

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

Architectural · ของใหม่ทั้งก้อนโมดูลใหม่ ระบบใหม่ หรืออะไรที่ไปเปลี่ยนวิธีที่ส่วนอื่นทำงาน เส้นทางนี้เท่านั้นที่ได้ไฟล์สเปกออกมา งาน micro-ERP ส่วนใหญ่อยู่ตรงนี้

ถ้ามันบอกว่า Bounded แต่คุณกำลังทำโมดูลใหม่ ให้ค้าน พิมพ์ไปตรง ๆ ว่า "อันนี้เป็น architectural นะ" เพราะกติกาของมันคือถ้าลังเลระหว่างสองทาง ให้เลือกทางที่หนักกว่าเสมอ

# เส้นทาง architectural จะได้ไฟล์นี้
docs/specs/
  2026-09-22-คลังสินค้า-design.md

# มันจะขอให้คุณอ่านก่อนไปต่อ
"อ่านสเปกแล้วบอกได้เลยว่า
 อยากแก้ตรงไหนก่อนเริ่มทำแผน"

ในไฟล์สเปกมีสี่อย่างนี้

ปัญหาและทางแก้ เล่าจากมุมคนใช้งาน ไม่ใช่มุมเทคนิค

โครงระบบแบ่งเป็นก้อน ๆ แต่ละก้อนทำหน้าที่เดียว ทดสอบแยกกันได้

ข้อมูลไหลยังไง พังแล้วทำยังไง รวมถึงกรณีที่คนกรอกผิด

จะตรวจยังไงว่าเสร็จ เกณฑ์วัดที่เขียนไว้ล่วงหน้า ไม่ใช่มาเถียงกันตอนส่งงาน

ขั้น 02 · แตกสเปกเป็นแผน

สเปกหนึ่งใบใหญ่เกินกว่าจะทำรวดเดียว ขั้นนี้ซอยออกเป็นงานย่อย แต่ซอยแบบ "กระสุนส่องวิถี" ไม่ใช่ซอยตามชั้นของระบบ

ซอยผิด · ตามชั้นงานที่ 1 ทำฐานข้อมูลทั้งระบบ งานที่ 2 ทำหน้าจอทั้งระบบ ผลคือกดดูอะไรไม่ได้เลยจนกว่าจะครบทุกงาน

ซอยถูก · ตามเส้นทางงานที่ 1 เพิ่มสินค้าหนึ่งชิ้นแล้วเห็นในตาราง ครบตั้งแต่ฐานข้อมูลถึงหน้าจอ กดดูได้จริงตั้งแต่งานแรก

แผนต้องละเอียดพอให้คนที่ไม่เคยฟังบทสนทนานี้ทำตามได้ เพราะขั้นต่อไปเริ่มจากบทสนทนาใหม่ ถ้าแผนเขียนว่า "ทำตามที่คุยกันไว้" แปลว่าแผนใช้ไม่ได้ ให้สั่งเขียนใหม่ และทุกงานต้องมีเกณฑ์ว่าเสร็จแล้วดูตรงไหน

# ยังอยู่ในบทสนทนาเดิม ห้ามล้าง
/superpowers:writing-plans
# ตัวอย่างแผนที่ได้
1. ตารางสินค้า + หน้าเพิ่มสินค้า
2. หน้ารายการสินค้า + ค้นหา
   ต้องทำหลัง: 1
3. บันทึกรับเข้า · ตัดสต็อก
   ต้องทำหลัง: 1
4. รายงานยอดคงเหลือ
   ต้องทำหลัง: 2, 3

"ต้องทำหลัง" อ่านว่าอะไรงานที่ 1 ไม่ต้องรอใคร หยิบทำได้ทันที ส่วนงานที่ 4 ต้องรอ 2 กับ 3 ก่อน

คุณตอบแค่สามอย่างงานใหญ่ไปหรือเล็กไป ลำดับถูกไหม ควรรวมหรือแยกงานไหน ตอบครบมันจึงบันทึกแผนลงไฟล์

ขั้น 03 · ลงมือตามแผน

ตรงนี้คือจุดที่ต้อง ล้างบทสนทนาแล้วเริ่มใหม่ เพราะแผนเล่าเรื่องตัวเองครบอยู่แล้ว AI ที่เพิ่งเริ่มต้นจะคิดได้คมกว่า AI ที่คุยมาสามชั่วโมง

1มันเดินทีละข้อในแผน ไม่ข้าม จบข้อไหนก็หยุดให้เจ้าของกระบวนการตรวจก่อน ไม่ใช่ลุยยาวจนจบแล้วค่อยมาโชว์

2เขียนเกณฑ์วัดก่อนเขียนโค้ด ข้างในมันเรียกคู่มือทำงานแบบเทสต์นำ ให้เห็นว่าเทสต์แดงก่อน แล้วค่อยเขียนโค้ดให้เขียว

3ทำงานบนสำเนาของโปรเจ็ค มันแยก branch ให้ก่อนเริ่ม ของที่ใช้อยู่จึงไม่พังระหว่างทาง

คุณไม่ต้องเขียนเทสต์เป็น แต่ต้องอ่านผลออกสองอย่าง ผ่านกี่ตัว ตกกี่ตัว ถ้ายังมีตัวแดง แปลว่างานยังไม่เสร็จ ไม่ว่า AI จะบอกว่าอะไร

# ล้างบทสนทนาก่อน
/clear

# แล้วชี้ไฟล์แผนให้มัน
/superpowers:executing-plans
"docs/superpowers/plans/
 2026-09-22-คลังสินค้า.md"

# รอบแรก ต้องแดงก่อน
✗ เพิ่มสินค้าซ้ำรหัสเดิมไม่ได้
  Expected 409, received 201

# เขียนโค้ดแล้วรันใหม่
Tests:  6 passed, 0 failed

ทำไมต้องเห็นแดงก่อนถ้าเทสต์เขียวตั้งแต่ยังไม่เขียนโค้ด แปลว่าเทสต์นั้นไม่ได้ตรวจอะไรเลย เป็นกับดักที่ AI ตกบ่อยที่สุด

ขั้น 04 · ตรวจงานสองแกน

ขั้นสามเรียกให้เองเป็นระยะ แต่คุณสั่งเองได้ทุกเมื่อ เช่นตอนอยากตรวจงานทั้ง branch ก่อนปิดโมดูล

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

คนตรวจเป็น AI คนละตัวที่ไม่เคยฟังบทสนทนานี้ มันจึงไม่เผลอเชื่อเหตุผลที่ตัวเองเพิ่งให้ไปเมื่อกี้ อ่านจากโค้ดกับสเปกอย่างเดียว

# ตรวจงานเทียบกับจุดเริ่มต้น
/superpowers:requesting-code-review

# ได้รายงานมาแล้วอยากให้แก้ต่อ
/superpowers:receiving-code-review

รายงานยาวไม่ใช่เรื่องแย่รายงานที่เจอปัญหาเยอะแปลว่าระบบตรวจทำงานถูกต้อง ที่น่ากลัวกว่าคือไม่มีใครตรวจเลย

ของพังหรือมีช่องโหว่ สั่งแก้ก่อนเสมอ ห้ามไปงานถัดไป

ทำงานได้แต่จะมีปัญหาทีหลัง สั่งแก้ ถ้าไม่ได้รีบส่งงานวันนี้

เรื่องความเรียบร้อยของโค้ด ข้ามได้ ไม่ต้องแก้ทุกข้อ

ขั้น 05 · ปิดงานให้จบจริง

งานที่เขียวแล้วแต่ยังค้างอยู่บนสำเนา ยังไม่นับว่าเสร็จ ขั้นนี้คือเอาของกลับเข้าตัวจริง แล้วเก็บกวาดให้รอบหน้าเริ่มจากที่สะอาด

1มันทวนให้ก่อนว่าพร้อมปิดไหม เทสต์เขียวครบ รายงานตรวจไม่เหลือข้อที่บอกว่าของพัง ถ้ายังไม่ครบ มันจะไม่ยอมปิดให้

2คนคุมภาพรวมเลือกว่าจะรวมเข้าตัวจริงยังไง รวมเลย หรือเปิดใบขอรวมไว้ให้คนอื่นดูก่อน มันเสนอทางให้ คนคุมภาพรวมเป็นคนตัดสิน

3เก็บกวาดสำเนาที่ไม่ใช้แล้ว รอบหน้าจะได้ไม่มี branch ค้างเป็นสิบอันจนไม่รู้ว่าอันไหนคือของจริง

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

# ปิดงานเมื่อทุกอย่างเขียวแล้ว
/superpowers:finishing-a-development-branch

# มันจะถามกลับก่อนรวมของ
# รวมเข้าตัวจริงเลย
# หรือเปิดใบขอรวมให้คนดูก่อน

เส้นแบ่งของคำว่า "เสร็จ" อยู่ตรงนี้ก่อนหน้านี้คือของที่ทำอยู่ หลังจากนี้คือของที่พนักงานใช้ได้ ถ้ายังไม่ข้ามเส้นนี้ อย่าเพิ่งไปบอกใครว่าโมดูลเสร็จแล้ว

จบแล้วกลับไปขั้น 01โมดูลถัดไปเริ่มนับหนึ่งใหม่ที่ brainstorming เหมือนเดิม โดยมีสเปกของโมดูลก่อนหน้านอนอยู่ในโปรเจ็คให้มันอ่าน

บทที่ 3

ทีมกับหน้าที่

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

สี่บทบาท ใครชี้ขาดในแต่ละขั้น เจ้าของที่รอยต่อ ช่องที่เติมผิดบ่อย

สี่บทบาทในวงจร

ทีมข้ามแผนกไม่ได้แปลว่าทุกคนตัดสินใจเท่ากัน หนึ่งงานมีคนให้ความเห็นได้หลายคน แต่คนชี้ขาดต้องมีคนเดียวเสมอ สี่ช่องนี้คือสิ่งที่ต้องเติมชื่อคนให้ครบก่อนเริ่มโมดูลแรก

ลงมือ Rคนที่นั่งพิมพ์คุยกับ AI จริง ทั้งโมดูลมีคนเดียว ไม่ใช่ทั้งทีมผลัดกันพิมพ์ เพราะบริบทที่คุยค้างไว้จะขาดทันทีที่เปลี่ยนคน

ชี้ขาด Aคนที่พูดว่าไปต่อได้ หนึ่งขั้นมีคนเดียวเท่านั้น ถ้าเขียนได้สองชื่อ แปลว่าห้องยังไม่ได้ตกลงกันจริง ไม่ใช่ว่าช่วยกันดู

ให้ข้อมูล Cแผนกที่รับผลจากเอกสารนี้ต่อ ถูกถามก่อนตัดสินเสมอ ทักได้ เสนอได้ แต่ไม่ใช่คนเคาะ

แค่รับรู้ Iคนที่ต้องรู้ว่าของเปลี่ยนแล้ว แต่ไม่ต้องตอบอะไรกลับ ส่งให้อ่านอย่างเดียวพอ

ใครเคยเห็น RACI มาก่อน สี่ช่องนี้คือตัวเดียวกัน ที่เรียกเป็นไทยเพราะคนที่ต้องเติมคือคนหน้างานของแต่ละแผนก ไม่ใช่ทีมบริหารโครงการ

บทบาทไหนอยู่ขั้นไหน

ตารางนี้อ่านทีละแถว แถวละหนึ่งขั้นของวงจร สังเกตว่าคอลัมน์ "ลงมือ" ไม่เปลี่ยนเลยทั้งโครงการ แต่คอลัมน์ "ชี้ขาด" ย้ายคนไปมา นั่นคือจุดที่ทีมมักเข้าใจผิด

ขั้น	สิ่งที่เกิดขึ้น	ลงมือ `R`	ชี้ขาด `A`	ให้ข้อมูล `C`
01	คุยให้ตกผลึก ได้ไฟล์สเปก	คนรันงานกับ AI	เจ้าของกระบวนการของโมดูลนี้	แผนกที่รับเอกสารต่อ
02	แตกสเปกเป็นแผน	คนรันงานกับ AI	เจ้าของกระบวนการ คนเดิมกับขั้น 01	ไม่ต้องมี
03	ลงมือ หยุดให้ตรวจทุกข้อ	คนรันงานกับ AI	เจ้าของกระบวนการ กดใช้จริงทุกข้อ	ไม่ต้องมี
04	ตรวจงานสองแกน	คนรันงานกับ AI	คนคุมภาพรวมโครงการ	แผนกปลายน้ำ ทักได้ตรงนี้
05	ปิดงาน รวมเข้าตัวจริง	คนรันงานกับ AI	คนคุมภาพรวมโครงการ	ทุกแผนกที่ใช้ข้อมูลชุดนี้

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

โมดูลคาบเกี่ยวสองแผนก ใครเป็นเจ้าของ

ใบขอซื้อออกที่จัดซื้อ ของเข้าที่คลัง เงินออกที่บัญชี สามแผนกอ้างความเป็นเจ้าของได้หมด นี่คือที่ที่ ERP พังบ่อยที่สุด สามกฎนี้ตัดจบ

1เอกสารเกิดที่มือใคร คนนั้นเป็นเจ้าของ ใบขอซื้อเกิดที่จัดซื้อ เจ้าของสเปกคือจัดซื้อ ถึงแม้คลังกับบัญชีจะรับผลต่อทั้งคู่

2แผนกปลายน้ำอยู่ช่องให้ข้อมูล และทักได้ตอนขั้น 04 ก่อนหน้านั้นตอบคำถามได้ เสนอได้ แต่บล็อกขั้น 01 ไม่ได้ ไม่งั้นสเปกจะไม่มีวันจบสักโมดูล

3ถ้าเถียงไม่จบจริง ๆ คนคุมภาพรวมเคาะ แล้วจดเหตุผลลง AGENTS.md ตัดสินผิดแล้วแก้ทีหลังยังถูกกว่าค้างไว้ เพราะอย่างน้อยมีที่มาให้ย้อนดูว่าทำไมถึงเลือกแบบนั้น

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

ทุกช่องใส่ชื่อคน ไม่ใช่ชื่อตำแหน่งเขียนว่า "ฝ่ายคลัง" ไม่ใช่คำตอบ เพราะพอถึงเวลาจริงจะไม่มีใครรู้สึกว่าเป็นของตัวเอง

คนเดียวถือได้หลายบทบาททีมเล็กเป็นแบบนี้ปกติ แต่ห้ามคนเดียวเป็นทั้งคนลงมือและคนชี้ขาดในขั้นเดียวกัน นั่นแปลว่าไม่มีการตรวจเลย

บทที่ 4

ตอนติดปัญหา
และเคสจริง

ของจริงไม่ได้เดินตรงเสมอ และไม่ได้มีโมดูลเดียว บทนี้รวมอาการติดที่เจอบ่อยที่สุด วิธีต่อโมดูล ERP เข้าหากันโดยไม่ให้ข้อมูลชนกัน วิธีต่อคลังความรู้ของบริษัทเข้ามาใช้ และวิธีทำให้วงจรเดินต่อได้เรื่อย ๆ

พังทำไง มันบอกว่าเสร็จแล้วจริงไหม ได้รายงานตรวจมาแล้วทำไง ต่อโมดูลยังไง ต่อคลังความรู้ วงรอบไม่จบ

สามอาการติดที่เจอบ่อยที่สุด

ทั้งสามอันนี้ไม่ได้แทนวงจรหลัก แต่เป็นทางอ้อมสั้น ๆ ที่พาคุณกลับเข้าวงจรเดิม

ของพัง · systematic-debuggingใช้กับบั๊กที่ไม่เห็นสาเหตุ หรือพังเป็นบางครั้ง มันจะไม่เดาจนกว่าจะทำให้พังซ้ำได้ก่อน

อ้างว่าเสร็จ · verification-before-completionใช้ตอนรู้สึกว่ามันตอบเร็วเกินไป มันจะถูกบังคับให้รันคำสั่งตรวจจริงแล้วเอาผลมาแปะ ก่อนพูดคำว่าเสร็จ

ได้รายงานตรวจมา · receiving-code-reviewกันสองอาการ รับทุกข้อมาแก้ทั้งที่บางข้อผิด กับปัดทิ้งทั้งที่ควรแก้ มันไล่ตรวจทีละข้อก่อนลงมือ

อีกสามอันที่ได้ยินชื่อบ่อย แต่ยังไม่ต้องใช้ในโมดูลแรก

using-git-worktreesแยกสำเนาโปรเจ็คไว้ทำหลายเรื่องพร้อมกัน โมดูลแรกยังไม่ต้องใช้

subagent-driven-developmentให้ AI หลายตัวเดินตามแผนคนละข้อ เร็วขึ้นแต่ตรวจยากขึ้น

writing-skillsเขียนคู่มือของบริษัทเองเพิ่มในชุด ใช้ตอนเจอเรื่องเดิมครั้งที่สาม

ติดแล้วให้กลับเข้าวงจรเดิมเสมอ สามอันบนไม่ได้จบงานให้ มันแค่ตอบคำถามที่ค้างอยู่ พอได้คำตอบแล้วต้องเอากลับไปใส่สเปกหรือแผน

โมดูล ERP ไม่ได้อยู่เดี่ยว ๆ มันส่งเอกสารต่อกัน

คนมักคิดเป็นแผนก จัดซื้อ คลัง ขาย บัญชี แต่ละแผนกคือหนึ่งโมดูล และแต่ละใบงานเกิดจากใบก่อนหน้าเสมอ เริ่มจากซ้ายสุดแล้วไล่ไปขวา

จัดซื้อ · ทำโมดูลแรกเป็นต้นทางของของทุกชิ้นในระบบ ถ้าไม่มีใบสั่งซื้อ คลังก็ไม่มีอะไรให้รับเข้า ทำโมดูลนี้ก่อนแล้วคุณจะมีข้อมูลจริงไว้ทดสอบโมดูลถัดไป

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

บัญชี · ทำท้ายสุดไม่ใช่โมดูลที่ทำก่อน แต่เป็นปลายทางที่รับใบจากสามโมดูลบน ทำตอนที่เอกสารต้นทางนิ่งแล้ว ไม่งั้นต้องรื้อตามทุกครั้งที่ต้นทางเปลี่ยน

สามกฎ ตอนต่อโมดูลใหม่เข้ากับของเดิม

ตรงนี้คือจุดที่ระบบทำเองพังบ่อยที่สุด ไม่ใช่เพราะโค้ดผิด แต่เพราะโมดูลใหม่ไม่รู้จักของที่โมดูลเก่าทำไว้

1ข้อมูลหลักมีชุดเดียว สินค้า ลูกค้า ผู้ขาย พนักงาน ต้องอยู่ที่เดียวทั้งระบบ โมดูลใหม่ต้องอ้างของเดิม ถ้าเห็น AI สร้างตารางชื่อคล้ายของที่มีอยู่แล้ว ให้หยุดแล้วสั่งให้ใช้ของเดิม

2เอกสารต้องอ้างใบก่อนหน้า ใบรับของต้องรู้ว่ามาจากใบสั่งซื้อใบไหน ใบส่งของต้องรู้ว่าตัดสต็อกล็อตไหน ถ้าใบไหนลอยเดี่ยว ๆ แปลว่าตามของหายไม่ได้ในวันที่ของหายจริง

3ของเก่าต้องไม่พัง พอโมดูลใหม่เขียว ให้สั่งตรวจทั้ง branch อีกรอบ ไม่ใช่ตรวจแค่งานล่าสุด เพราะโมดูลใหม่ไปแตะข้อมูลที่โมดูลเก่าใช้อยู่

# เริ่มโมดูลถัดไป บอกของเดิมให้ครบ
/superpowers:brainstorming
"โมดูลขาย ต่อจากคลังที่ทำไว้แล้ว
 ใช้สินค้าและสต็อกชุดเดิม"
# ตรวจทั้ง branch หลังโมดูลใหม่เขียว
/superpowers:requesting-code-review

กฎตัดสต็อกเป็นของเจ้าของกระบวนการ ไม่ใช่ของ AI ตัดตอนกดยืนยันคำสั่งซื้อ หรือตอนของออกจากคลังจริง สองแบบนี้ให้ตัวเลขไม่เท่ากันและแก้ทีหลังยากมาก ต้องตอบตั้งแต่ขั้น 01 อย่าปล่อยให้มันเดาแทน

สัญญาณว่าต่อไม่ติดมีคำเดียวกันสองชื่อ เช่น รหัสสินค้า กับ รหัสของ · ต้องกรอกลูกค้าซ้ำในสองหน้าจอ · ตัวเลขสต็อกในสองหน้าไม่ตรงกัน เจออันใดอันหนึ่ง แปลว่ารวมโมดูลไม่สำเร็จ

ทำยังไงให้วงจรเดินต่อได้เรื่อย ๆ

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

AGENTS.md · ศัพท์กลางหนึ่งใบต่อโปรเจ็ค เก็บคำที่บริษัทคุณใช้จริง ว่า ของเสีย ล็อต เบิก แปลว่าอะไรแน่ ไฟล์นี้ถูกอ่านทุกครั้งที่เปิดคุยใหม่ ทุกโมดูลถัดไปจึงใช้คำชุดเดียวกัน

docs/specs/ · บันทึกการตัดสินใจหนึ่งไฟล์ต่อหนึ่งโมดูล ขั้น 01 เขียนให้เองและ commit ไว้ เช่นว่าตัดสต็อกตอนของออกจริง และเหตุผล รอบหน้าจะได้ไม่ถูกถามซ้ำ

สองที่นี้คือความจำของระบบ โมดูลที่สามจะรู้จักกฎที่ตกลงกันตอนโมดูลแรกได้ ก็เพราะมันถูกเขียนไว้ในโปรเจ็ค ไม่ใช่เพราะ AI จำได้

# ตกลงศัพท์หรือกฎใหม่เมื่อไหร่
"จดกฎนี้ลง AGENTS.md ให้หน่อย"

# รอบถัดไปเริ่มจากศูนย์ได้เลย
/clear
/superpowers:brainstorming "โมดูลถัดไป"

วงจรไม่ได้จบที่รายงานพอมีคนใช้จริง จะมีของเสีย คำขอใหม่ กฎที่เปลี่ยน ทั้งหมดนั้นไม่ใช่งานนอกวงจร มันคือวัตถุดิบของรอบถัดไป เข้าขั้นแรกใหม่เหมือนเดิม

คำขอเยอะจนเลือกไม่ถูกพอคำขอเริ่มมาจากเพื่อนร่วมงานหลายคน อย่ายัดเข้าไปรอบเดียว เปิด brainstorming รอบสั้น ๆ เพื่อจัดลำดับก่อน แล้วค่อยหยิบอันแรกเข้าวงจรห้าขั้นเดิม

คลังความรู้ของบริษัท ต่อเข้าวงจรได้

skill คือคู่มือว่าจะทำงานยังไง ส่วน MCP คือสายที่ต่อ AI ไปหาของที่บริษัทเก็บไว้อยู่แล้ว เช่น SOP ของแต่ละแผนกใน Gemini Notebook คนละหน้าที่กัน และใช้พร้อมกันได้

1ต่อครั้งเดียว ค้างไว้ทุกโปรเจ็ค พอต่อแล้ว AI เปิดอ่านคลังได้เองระหว่างคุย คุณไม่ต้องก๊อปข้อความจาก SOP มาวางในแชตทีละรอบ

2มันอ่านอย่างเดียว ไม่ได้ย้ายคลังมาไว้ในโปรเจ็ค SOP ยังอยู่ที่เดิม คนดูแลคลังก็ยังแก้ที่เดิม ไม่เกิดสำเนาชุดที่สองที่ต้องตามอัปเดต

3สิ่งที่ดึงมาได้ ต้องลงไฟล์ในโปรเจ็คเสมอ คำตอบจากคลังให้สรุปลง AGENTS.md หรือไฟล์สเปกใน docs/specs/ ไม่งั้นรอบหน้าต้องไปถามใหม่ และอาจได้คำตอบไม่เหมือนเดิม

SOP เป็นวัตถุดิบ ไม่ใช่คำตัดสิน บางใบเขียนไว้นานแล้ว บางใบขัดกันเอง บางใบเขียนว่าควรทำอย่างหนึ่ง แต่หน้างานทำอีกอย่าง ให้ AI ดึงมาเสนอได้ แต่คนต้องเป็นคนชี้ว่าใช้ฉบับไหน

# ดูว่าในคลังมีเล่มอะไรบ้าง
"ลิสต์ notebook ทั้งหมดที่ต่ออยู่"

# ถามคลังตรง ๆ ก่อนเริ่มโมดูล
"เปิด SOP คลังสินค้า แล้วสรุปว่า
 ขั้นตอนรับของมีกี่ขั้น ใครเซ็นบ้าง"

# ถ้ามันบอกว่าเข้าคลังไม่ได้
nlm login

ของที่มีอยู่แล้ว มีค่ากว่าที่คิดงานหนักที่สุดในขั้น 01 คืออธิบายว่าบริษัททำงานยังไง ซึ่งส่วนใหญ่เขียนไว้ใน SOP อยู่แล้ว การต่อคลังเข้ามา คือการไม่ต้องเล่าใหม่ด้วยปากทุกครั้ง

ยังไม่มีคลัง ก็เริ่มได้วงจรห้าขั้นไม่ได้รอคลังความรู้ ถ้ายังไม่มี SOP ในระบบ ตอบคำถามเองไปก่อน แล้วค่อยต่อคลังในรอบถัดไป

ใช้ตอนไหน · ขั้น 01 เป็นหลัก ขั้น 04 เป็นตัวทวน

เปิดเฉพาะเล่มของแผนกที่กำลังทำโมดูลอยู่ แล้วใช้สองจังหวะนี้

1ขั้น 01 · ให้คลังตอบคำถามที่มันตอบแทนคุณได้ พอ AI ถามว่าใครอนุมัติการเบิก ให้มันไปเปิด SOP คลังสินค้าแล้วเอาคำตอบมาเสนอ เจ้าของกระบวนการแค่ชี้ว่าใช่หรือไม่ใช่ เร็วกว่าพิมพ์เล่าเองมาก

2SOP ตอบได้คือกอง A ตอบไม่ได้คือกอง B กอง A ปล่อยให้มันอ่านเอง กอง B เช่น ตัดสต็อกตอนกดยืนยันหรือตอนของออกจริง เป็นการตัดสินใจของคน ห้ามให้มันเดาแทน

3ขั้น 04 · ทวนกับ SOP อีกรอบ หลังตรวจโค้ดแล้ว ถามต่อว่าของที่ทำเสร็จ ตรงกับขั้นตอนใน SOP ไหม ตรงไหนไม่ตรง ให้ตอบว่าตั้งใจให้ต่างหรือทำหลุด

สัญญาณว่าดึงมาแล้วเชื่อไม่ได้สรุปมาโดยไม่บอกว่ามาจากเล่มไหน · สองเล่มไม่ตรงกันแต่มันเลือกให้เล่มเดียว · คำตอบกว้างจนเขียนสเปกไม่ได้ เจอแบบนี้ให้ถามกลับว่าอ้างจากหน้าไหน

# ขั้น 01 · บอกไปเลยว่าให้ใช้เล่มไหน
/superpowers:brainstorming
"โมดูลคลัง ใช้ SOP คลังสินค้า
 ใน notebook เป็นข้อมูลตั้งต้น
 ข้อไหนใน SOP ไม่ชัด
 ให้ถามผมทีละข้อ"

# ขั้น 04 · ทวนหลังตรวจโค้ดเสร็จ
/superpowers:requesting-code-review
"เทียบกับ SOP คลังสินค้าด้วย
 ตรงไหนที่ของจริงไม่ตรงกับ SOP"

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

ของลับไม่ต้องเข้าโปรเจ็ค SOP บางเล่มมีราคาทุน เงินเดือน หรือข้อมูลลูกค้า สิ่งที่ต้องเอาลงไฟล์คือกฎการทำงาน ไม่ใช่ตัวเลขในนั้น

ข้างในหนึ่งโมดูล ทำสี่ชั้นนี้ตามลำดับ

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

ชั้น	คำถามที่ตอบ	ตัวอย่างในโมดูลคลัง	ถ้าข้ามไปทำทีหลัง
1	ใครทำอะไรได้บ้าง	หัวหน้าคลังแก้ยอดได้ พนักงานหน้างานบันทึกรับของได้อย่างเดียว	ต้องรื้อทุกหน้าจอทีหลังเพื่อยัดสิทธิ์เข้าไป แพงกว่าทำตั้งแต่แรกหลายเท่า
2	จะนับอะไร	รายชื่อสินค้า หน่วยนับ ที่เก็บ แค่เพิ่ม แก้ ค้นหาได้ ยังไม่มีตรรกะอะไร	หน้ารับของไม่มีสินค้าให้เลือก ทำต่อไม่ได้เลย
3	ของเข้าออกยังไง	รับเข้า เบิกออก โอนย้าย นี่คือหัวใจ และเป็นที่อยู่ของกฎธุรกิจคุณ	ข้ามไม่ได้อยู่แล้ว แต่ถ้ารีบทำก่อนชั้น 2 จะได้ใบที่อ้างสินค้าที่ยังไม่มีจริง
4	สรุปให้ใครดู	ยอดคงเหลือ ของใกล้หมด ของค้างนาน	ทำก่อนก็ไม่มีข้อมูลให้อ่าน ได้หน้าจอเปล่ามาหนึ่งหน้า

สี่ชั้นนี้อยู่ในโมดูลเดียว ไม่ใช่สี่โมดูล พอครบสี่ชั้น ถือว่าโมดูลคลังเสร็จและใช้งานได้จริง แล้วค่อยเริ่มโมดูลขายใหม่ตั้งแต่ชั้น 1 ของมันเอง

ทำโมดูลหนึ่งตัว ต้องทำอะไรบ้าง

สี่ชั้นในหน้าที่แล้วคือสิ่งที่ต้องได้ หน้านี้คือสิ่งที่ต้องทำ แบ่งตามเวลาสามช่วง

1ตอนเริ่ม · ทำครั้งเดียว brainstorming ตอบคำถามให้ตรง แล้วอ่านสเปกที่มันเขียนให้หนึ่งรอบก่อนอนุมัติ ปิดช่วงนี้ด้วย writing-plans ในบทสนทนาเดิม จบแล้วจะได้แผนมาหนึ่งชุด เรียงลำดับไว้แล้ว

2ระหว่างทาง · ทำยาวจนหมดแผน /clear เพื่อล้างบทสนทนาเก่า แล้ว executing-plans ชี้ไฟล์แผนให้มัน มันจะเดินทีละข้อและหยุดให้เจ้าของกระบวนการตรวจทุกข้อ ตรงไหนไม่ใช่ให้บอกตรงนั้น

3ตอนจบ · ทำครั้งเดียว requesting-code-review ตรวจทั้งโมดูล สั่งแก้ข้อที่บอกว่าของพังให้หมด แล้วปิดด้วย finishing-a-development-branch ค่อยเริ่มโมดูลถัดไปที่ช่วงตอนเริ่ม

อย่าเปิดโมดูลใหม่ทั้งที่ของเดิมยังไม่ปิดทำค้างสามโมดูล แล้วใช้จริงไม่ได้สักตัว สู้โมดูลเดียวที่พนักงานใช้ได้แล้วไม่ได้

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

โมดูลนี้ถือว่าเสร็จเมื่อครบสามข้อนี้ ไม่ใช่เมื่อ AI บอกว่าเสร็จ

เจ้าของกระบวนการกดใช้เองได้ครบทั้งสี่ชั้น จากหน้าจอจริง ไม่ใช่ดูจากโค้ดหรือฟังคำอธิบาย

ผลตรวจไม่เหลือข้อที่บอกว่าของพัง และปิด branch แล้ว ข้อที่เป็นแค่ความเรียบร้อยของโค้ด ปล่อยไว้ได้

มีคนกรอกข้อมูลจริงไปแล้วหนึ่งวัน ข้อมูลจริงเจอปัญหาที่ข้อมูลทดลองไม่เคยเจอ

คุณไม่ต้องเขียนโค้ดเป็น
แต่ต้องรู้ว่าตอนนี้
อยู่ขั้นไหนของวงจร

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