Method

Spec-First Solo Build

วิธีที่ผมพาผลิตภัณฑ์ไปถึงการเปิดตัว ด้วยการกำหนดมาตรฐานและกำกับ AI — โดยไม่ได้เขียนโค้ดเอง

สรุปวิธีการทำงานแบบ Spec-First Solo Build

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

(01)

เฟรมเวิร์ก: 7 ขั้นตอนจากศูนย์สู่การเปิดตัว

Fig. ai-workflow-01

จากแผนสู่การเปิดตัว — ลูป สั่ง · ตรวจ · แก้

01ไอเดียนิยามปัญหา

02แผนและมาตรฐานหน้าจอ โครงสร้าง และเกณฑ์การยอมรับเป็นลายลักษณ์อักษร

03สั่งงาน AIเป้าหมาย เกณฑ์ ข้อจำกัด — ทีละขั้น

04รันและตรวจเล่น บิลด์ และอ่าน log เทียบกับมาตรฐาน

05เปิดตัวตรวจความปลอดภัยและข้อมูล แล้วขึ้นสโตร์และเว็บ

ไม่ผ่านมาตรฐาน → ชี้สาเหตุ สั่งใหม่ · ทำซ้ำ

ผมไม่ได้เขียนโค้ดเอง: ผมกำหนดมาตรฐาน กำกับ AI ทีละขั้น รันเองและสั่งแก้ ขั้นที่ 3↔4 วนซ้ำจนกว่าจะผ่านมาตรฐาน

01
กำหนดกฎและการออกแบบเป็นเอกสารก่อน
เพราะผมไม่ได้อ่านโค้ดโดยตรง ด่านแรกของคุณภาพจึงเป็นเอกสารกฎ ในแต่ละโปรเจกต์ผมกำหนดวิธีทำงาน สิ่งที่ห้ามทำ และเกณฑ์การตรวจสอบไว้ในเอกสารกฎ แล้วให้ทุกเซสชันอ่านและซิงก์กันด้วยคำสั่ง "บอกมาว่าตอนนี้อยู่ขั้นไหน"
02
ดึงดีไซน์/UI และข้อมูลทั้งหมดออกมาก่อน แล้วค่อยสร้าง
ทำสองอย่างพร้อมกันจะพันกัน ผมจึงล็อกหน้าจอและข้อมูลก่อน (เช่น export ทุกหน้าจอจากเครื่องมือออกแบบ แล้วค่อยเชื่อมเข้ากับโค้ด)
03
สั่งงานเป็นชิ้นเล็ก ๆ และตรวจสอบด้วยการรันเอง
ไม่ใช่แค่ "เสร็จแล้ว" — ผมรันบนมือถือ/ซิมูเลเตอร์และยืนยัน **ด้วยตาตัวเอง**
04
ให้มาตรฐานและตัวเทียบเป็นคำพูด ไม่ใช่คะแนน
ผมกำหนดคุณภาพด้วยเรฟเฟอเรนซ์ (แอปของบริษัทใหญ่) และโทน แล้วมอบหมายการลงมือทำ
05
จับจุดที่ผิดและเปลี่ยนทิศทาง
ผมไม่เชื่อความสำเร็จที่ดูดีเกินจริง ("อันนี้ไม่ได้ฮาร์ดโค้ดใช่ไหม?") และเมื่อติดก็เปลี่ยนไปทางที่ใช้ได้ทันที (ไม่ทำของปลอม เปลี่ยนทางอย่างมีเหตุผล)
06
ไม่เชื่อรายงานของ AI เอง — ตรวจด้วยหลักฐาน
ผมยืนยันซ้ำด้วยโค้ดจริง ผลงานจริง หรืออินพุตที่ต่างออกไป ไม่ใช่ "ความจำ"
07
เก็บบริบทไว้ในเอกสารส่งต่องาน และบริหาร AI หลายตัวเหมือนทีม
ผมบันทึกบริบทไว้ให้รอดแม้เปลี่ยนบัญชีหรือบริบทถูกรีเซ็ต และเมื่อทำงานหลายเซสชันก็ตั้งเซสชันหนึ่งเป็น PM

Spec-First Solo Build — เขียนกฎและมาตรฐานก่อน แล้วกำกับ AI ให้สร้าง ตรวจ และแก้ จนกว่าจะเปิดตัวได้

ขั้นที่ 3–6 ไม่ได้ทำครั้งเดียวจบ — ผม วนลูป สั่ง → ตรวจ → แก้ ซ้ำไปเรื่อย ๆ

(02)

หลักการ

01
ไม่เดา
ถ้าแก้ครั้งแรกไม่สำเร็จ ให้ค้นเอกสารทางการ/กรณีคล้ายกันก่อนลองครั้งที่สอง
02
ให้ดูก่อนสร้าง
หน้าจอหรือโครงสร้างใหม่ต้องรีวิวเป็น mockup หรือดีไซน์ก่อน แล้วค่อยสร้าง
03
บอกผลกระทบก่อนแก้
อธิบายผลข้างเคียงและปัญหาต่อเนื่องก่อน แก้ได้หลังอนุมัติเท่านั้น
04
ตรวจว่าค่าไหลถึงปลายทางครบ
เพิ่มฟิลด์หรือพารามิเตอร์ใหม่ ต้องแก้ทุกจุดที่เรียกใช้ ไม่ใช่แค่จุดที่ประกาศ และอ่านโค้ดที่สร้างขึ้นซ้ำอีกรอบก่อนส่ง
05
ส่วนที่ "ผิดไม่ได้" ต้องเขียนมาตรฐานไว้
ในส่วนที่ความผิดพลาดร้ายแรง (ความปลอดภัย เงินเดือน) เอกสารออกแบบต้องมาก่อนโค้ด
06
เปลี่ยนความล้มเหลวให้เป็นหลักการ
จากการขาดทุนหรือเหตุขัดข้องหนึ่งครั้ง ให้สกัดกฎหนึ่งข้อที่ป้องกันไม่ให้เกิดซ้ำ (กฎ "ขออนุมัติก่อนแก้" มาจากความล้มเหลวของบอตเทรดในช่วงแรก)
07
ให้เอกสารกับโค้ดตรงกันเสมอ
ทุกครั้งที่ปล่อยเวอร์ชัน ผมตรวจตัวเลขในเอกสารเทียบกับโค้ดจริง เอกสารที่ AI เขียนคลาดเคลื่อนได้ง่าย ผมจึงทำให้การตรวจไขว้เป็นนิสัย

(03)

เทมเพลตพรอมต์ (โครง)

ผมเปิดเผยเฉพาะ โครง ของคำสั่งที่ใช้ซ้ำ ส่วนเงื่อนไขละเอียด ลำดับ และเกณฑ์การยอมรับที่ทำให้ได้ผลจริง จะแชร์ในการสัมภาษณ์หรือเมื่อร่วมงานกัน ตัวอย่างสั้น ๆ ของแต่ละโปรเจกต์ (1–2 ประโยค) อยู่ในกรณีศึกษาในหัวข้อ "การกำกับ AI"

A. ประเมินไอเดีย — ไม่ให้คะแนนตามใจ อ้างอิงจากกรณีจริง

นิยามปัญหาใหม่ → ค้นหากรณีคล้ายกัน → เทียบรูปแบบความสำเร็จ/ล้มเหลว
→ ตารางคะแนนจากหลักฐาน → สกัดไอเดีย → สรุป (อันดับต้น + ความเสี่ยง + ขั้นต่อไป)
[เกณฑ์ จำนวน และกฎผ่าน/ไม่ผ่านของแต่ละขั้นเก็บไว้เป็นความลับ]

B. คำสั่งสร้างฟีเจอร์

[เป้าหมาย] …   [มาตรฐาน] ต้องทำงานแบบนี้ / ไม่ใช่แบบนี้   [ข้อจำกัด] สแต็กและนโยบาย (ตรวจจากเอกสาร)   [ตรวจ] สิ่งที่ผมจะตรวจ

C. คำสั่งแก้บั๊ก

[อาการ] …   [ก่อนอื่น] หาสาเหตุก่อน — ค้นหาและตั้งสมมติฐาน   [ก่อนแก้] อธิบายผลกระทบ → แก้หลังอนุมัติ

(04)

วิธีจับข้อผิดพลาด

01
บอกอาการเป็นข้อเท็จจริง
ผมบอก AI ว่าเกิดอะไร เมื่อไหร่ บนหน้าจอไหน ในแบบที่ทำซ้ำได้
02
หาสาเหตุก่อน ไม่เดา
ผมค้นเอกสารทางการ/กรณีคล้ายกัน แล้วตั้งสมมติฐานสาเหตุ
03
ถ้าแก้ครั้งแรกไม่โดน ให้หยุด
ผมค้นใหม่อีกรอบก่อนลองครั้งที่สอง — ไม่เดาซ้ำแบบเดิม
04
ตรวจว่าค่าไหลถึงปลายทางครบ
หลังแก้ ผมอ่านทุกจุดที่เรียกใช้และโค้ดที่สร้างขึ้นซ้ำ
05
ทิ้งกฎไว้กันไม่ให้เกิดซ้ำ
ผมบันทึกเป็นหลักการทำงานหรือมาตรฐานการออกแบบ

กรณีดีบักจริง (อาการ → คำสั่ง → ความล้มเหลว → การแก้) อยู่ในหัวข้อ "ผมแก้ปัญหาอย่างไร" ของแต่ละโปรเจกต์

(05)

ความผิดพลาด → บทเรียน

Mistake
เชื่อบอตเทรดมากเกินไป → ขาดทุน
✓ Lesson
อธิบายผลกระทบและขออนุมัติก่อนแก้ (ยังใช้กับทุกโปรเจกต์จนถึงวันนี้)
Mistake
AttenNFC: โค้ดที่ AI สร้างไม่ถึงมาตรฐาน
(ตัวแปรเงินเดือนมีแค่ 5 จาก 9 ตัว, API ไม่ตรงกัน, ฮาร์ดโค้ดพิกัด GPS)
✓ Lesson
ตรวจผลงานของ AI เทียบกับมาตรฐาน และเมื่อคลาดเคลื่อนให้สั่งเขียนใหม่ หลังเขียนใหม่ ผมยืนยันแล้วว่า `flutter analyze` รายงานศูนย์ issue
Mistake
MECHOOSE: โครงสร้างหน้าจอช่วงแรกอัดอยู่ในไฟล์เดียว
✓ Lesson
กำหนดมาตรฐานการแยกส่วนตั้งแต่ต้น — จะทำให้การแก้ไขภายหลังถูกลง

(06)

ผลงานในตัวเลข (โดยประมาณ)

149 บทสนทนาบน claude.ai · คำสั่งจากผู้ใช้ ~9,002 คำสั่ง (ก.พ.–ต.ค. 2026 ประมาณ 8.5 เดือน) — เป็นกิจกรรมทั้งหมด รวมถึงแชตส่วนตัวและแชตที่ไม่เกี่ยวกับพอร์ตโฟลิโอ
ผลิตภัณฑ์ 5 ตัวไปถึงขั้นเปิดตัว/ดีพลอย (THE HOUSE, MECHOOSE, Momento, Money Navigation, MemoHub) และ 2 ตัวใช้งานจริงอยู่ (MECHOOSE, MemoHub)
บทสนทนาเดียวที่มีคำสั่งมากที่สุด: THE HOUSE 696 คำสั่ง

ตัวเลขเป็นค่าประมาณจากบันทึก (การจัดแชตเข้าแต่ละโปรเจกต์ใช้วิธีดูจากชื่อ/คีย์เวิร์ด จึงเป็นการประมาณ)

(07) Honest

Honest รีวิว

ถ้านักพัฒนาเป็นคนสร้าง — จุดแข็ง · เทียบเท่า · ขั้นต่อไป

จุดแข็งเทียบเท่าขั้นต่อไป (กำลังเติมเต็ม)

THE HOUSE
จุดแข็ง3เทียบเท่า4ขั้นต่อไป5
↗ การทดสอบและระบบอัตโนมัติ — ยังไม่มีการทดสอบอัตโนมัติหรือ CI
วางแผน → การทดสอบ + CI สำหรับการซื้อและการเซฟ, แยกโมดูล, ย้ายไป Git แบบส่วนตัว, ตรวจสอบการซื้อฝั่งเซิร์ฟเวอร์ก่อนเปิดตัวสาธารณะ
MECHOOSE
จุดแข็ง3เทียบเท่า4ขั้นต่อไป4
↗ การทดสอบและระบบอัตโนมัติ — ยังไม่มีการทดสอบ CI lint หรือการตรวจ type
วางแผน → ทดสอบ + CI ที่ส่วนชำระเงินก่อน, แยกแบ็กเอนด์ตามโดเมน, ย้ายคำสั่งซื้อและการชำระเงินไปตารางที่เหมาะสม, เพิ่มการแจ้งเตือนข้อผิดพลาด
Momento
จุดแข็ง3เทียบเท่า4ขั้นต่อไป5
↗ การทดสอบและระบบอัตโนมัติ — มีการทดสอบเฉพาะเอนจินจับคู่
วางแผน → บันทึก schema ของฐานข้อมูลจริงลง repo, เพิ่มการทดสอบ flow หลักและ CI, ตรวจสอบการซื้อฝั่งเซิร์ฟเวอร์, ทำ Android ให้เท่า iOS
AttenNFC
จุดแข็ง2เทียบเท่า3ขั้นต่อไป4
↗ ความสมบูรณ์ของฟีเจอร์ — พัฒนาแล้ว ~10–15% ของที่ออกแบบไว้
วางแผน → ทำรอบลงเวลาที่ผ่านการตรวจสอบให้ครบหนึ่งรอบแบบ end to end ก่อน แล้วค่อยเพิ่มการทดสอบ/CI ไฟล์แปล และ label ไปพร้อมกับการสร้างหน้าจอ
แพลตฟอร์มสตรีมมิงวิดีโอด้วย AI
จุดแข็ง4เทียบเท่า3ขั้นต่อไป3
↗ การทดสอบและการควบคุมเวอร์ชัน — ไม่มีการทดสอบ ไม่มี git
วางแผน → ย้ายไป Git แบบส่วนตัวและทดสอบการชำระเงินก่อน จากนั้นจึงเพิ่ม CI การมอนิเตอร์ การสำรองข้อมูล และการ rollback