Knowledge Hub

AI Harness: ออกแบบทีม AI ให้สร้างเว็บจากไอเดียถึง Deploy

เรียนรู้วิธีออกแบบ Harness ที่คุม AI ให้ทำงานเป็นขั้นตอน Research → Spec → Build → Verify → Deploy → Domain → Final Checks พร้อมสิทธิ์ เงื่อนไขหยุด และการตรวจผลจากระบบจริง

AI Engineeringอ่าน 13 นาทีเผยแพร่ 15 ตุลาคม 2569

🎯 แก่นของเรื่อง

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

ทำไมจึงได้ผล (กลไกเหตุ-ผล)

กลไก เหตุ ผล
แบ่งเป็นบทบาท แต่ละขั้นมีเป้าหมายและเกณฑ์ผ่านของตัวเอง ลดการข้ามขั้นหรือเดาเอง
ตรวจก่อนไปต่อ Lint, Type Check, Unit Test, Browser Test เป็นผลที่ตรวจซ้ำได้ จับความผิดพลาดก่อน Deploy
จำกัดสิทธิ์ AI ทำได้เฉพาะที่อนุญาต ความเสียหายจากความผิดพลาดมีขอบเขต
เงื่อนไขหยุด ขั้นที่เสี่ยงต้องรอมนุษย์ยืนยัน ไม่เกิดการซื้อหรือเผยแพร่โดยไม่ตั้งใจ
Self-repair มีขอบเขต หาสาเหตุ แก้ แล้วทดสอบซ้ำ ถ้าแก้ไม่ได้ให้สรุปและหยุด ไม่วนลูปไม่รู้จบและไม่ปิดบังความล้มเหลว

20% ที่สำคัญที่สุดในทางปฏิบัติ

  1. Gate ระหว่างขั้น: ทุกขั้นต้องมีผลลัพธ์ที่ตรวจได้ก่อนเข้าขั้นถัดไป
  2. สิทธิ์และการยืนยัน: สิ่งที่ย้อนกลับยาก (ซื้อโดเมน, เผยแพร่จริง) ต้องรอคนยืนยัน
  3. ตรวจจากระบบจริง: ผลการ Deploy ต้องดูจาก Build Logs และหน้าเว็บจริง ไม่ใช่จากคำบอกเล่าของ AI

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

✅ ช่วยให้ดีขึ้นอย่างไร

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

สถานการณ์ ถ้าไม่มี Harness ถ้ามี Harness วัดอย่างไร หลักฐาน
ส่งมอบงาน ได้โค้ดหรือแผน ต้องต่อเองทุกขั้น AI พาไปจนถึง Preview Deployment จำนวนขั้นที่คนต้องทำเอง ตีความ
คุณภาพโค้ด รู้ว่าพังเมื่อเปิดใช้ ถูก Lint, Type Check, Test ดักก่อน จำนวน error ที่ถูกจับก่อน Deploy ตีความ
ความเสี่ยงการเงิน AI อาจซื้อหรือตั้งค่าเอง ต้องรอการยืนยันก่อนซื้อโดเมน จำนวนการซื้อที่ไม่ได้อนุมัติ (เป้าหมาย 0) ตีความ
เมื่อ build ล้มเหลว คนไล่หาสาเหตุเอง AI อ่าน log แก้ และทดสอบซ้ำ เวลาจนกว่า build ผ่าน ยังไม่ทดสอบ
เวลารวม ขึ้นกับคน อาจเร็วขึ้นหรือช้าลงจากการตรวจเพิ่ม เวลาจากไอเดียถึง URL ยังไม่ทดสอบ

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

🧭 ภาพรวม Workflow

Workflow หลักมี 7 ขั้น

flowchart LR
  A[Research] --> B[Spec]
  B --> C[Build]
  C --> D[Verify]
  D -->|ผ่าน| E[Deploy]
  D -->|ไม่ผ่าน| F[Self-repair]
  F --> D
  E --> G[Domain]
  G --> H[Final Checks]
ขั้น บทบาท ผลที่ต้องส่งมอบ Gate ก่อนไปต่อ
Research นักวิจัย ตลาด คู่แข่ง กลุ่มเป้าหมาย โอกาส พร้อมแหล่งอ้างอิง ทุกข้ออ้างมีแหล่งที่มา
Spec นักออกแบบผลิตภัณฑ์ MVP, ฟีเจอร์หลัก, User Flow, เทคโนโลยี, เกณฑ์วัดความสำเร็จ เกณฑ์วัดตรวจได้จริง
Build วิศวกรซอฟต์แวร์ Frontend, Backend, การจัดการ Environment, เอกสาร โปรเจกต์ build ได้
Verify ผู้ทดสอบ ผล Lint, Type Check, Unit Test, Browser Test ผ่านทุกรายการ
Deploy ผู้ดูแล Deploy Preview Deployment และ Build Logs ที่ตรวจแล้ว build สำเร็จ หน้าเปิดได้
Domain ผู้ดูแล Deploy รายการโดเมนที่ว่าง ราคา และข้อแนะนำ มนุษย์ยืนยันก่อนซื้อ
Final Checks ผู้ทดสอบ ตรวจหน้าเว็บจริงและสรุปสถานะ ตรวจจากระบบจริง ไม่ใช่คำบอกเล่า

🔬 แนวคิดและเทคนิคแต่ละส่วน

Market Research

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

Product Specification

  • คืออะไร: เอกสารที่กำหนด MVP ฟีเจอร์หลัก User Flow เทคโนโลยี และเกณฑ์วัดความสำเร็จ
  • ทำไม: เป็นสัญญาระหว่างขั้น Research กับ Build และเป็นเกณฑ์ที่ขั้น Verify ใช้ตรวจ
  • ทำอย่างไร: เขียนเกณฑ์วัดให้ตรวจได้ เช่น "ผู้ใช้สมัครและเห็นหน้าแดชบอร์ดภายใน 3 คลิก" ไม่ใช่ "ใช้งานง่าย"

Full-stack Development

  • พัฒนา Frontend และ Backend พร้อมจัดการ Environment และเอกสารประกอบ
  • ความลับ (key, token) ควรอยู่ใน Environment Variables ไม่ฝังในโค้ด (ข้อนี้เป็นแนวปฏิบัติทั่วไป ไม่ได้มาจากเนื้อหาต้นทาง)

Verification

การตรวจ จับอะไรได้ จับอะไรไม่ได้
Linting สไตล์และข้อผิดพลาดที่พบบ่อย ตรรกะที่ผิด
Type Checking ชนิดข้อมูลไม่ตรงกัน พฤติกรรมตอนรันที่ผิด
Unit Tests ตรรกะของหน่วยย่อย การทำงานร่วมกันทั้งระบบ
Browser Test การใช้งานจริงผ่านหน้าเว็บ กรณีที่ไม่ได้เขียน test ไว้

Deployment

  • เชื่อมต่อ Vercel สร้าง Preview Deployment ตรวจ Build Logs แล้วเตรียมเผยแพร่
  • Preview ให้ทดลองก่อนเผยแพร่จริง เป็นจุดตรวจที่คนเข้าไปดูได้

Custom Domain

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

Self-repair

  1. ค้นหาสาเหตุจาก log
  2. แก้ไข
  3. ทดสอบซ้ำ
  4. ถ้าแก้ไม่ได้ ให้สรุปว่าติดอะไรและหยุด

Warning ควรกำหนดจำนวนรอบสูงสุดของ Self-repair เอง เนื้อหาต้นทางไม่ได้ระบุตัวเลข ถ้าไม่จำกัด AI อาจแก้วนซ้ำหรือแก้ด้วยวิธีที่ซ่อนปัญหา เช่น ปิด test ที่ล้มเหลว

🧱 AI Harness คืออะไร

Harness คือกรอบที่ครอบ AI ให้ทำงานเป็นขั้น ไม่ใช่ตัว AI เอง

องค์ประกอบ หน้าที่ ตัวอย่างการกำหนด
ลำดับขั้นตอน บังคับว่าอะไรก่อนอะไร ห้าม Deploy ก่อน Verify ผ่าน
การตรวจผลลัพธ์ ยืนยันว่าแต่ละขั้นเสร็จจริง ต้องแนบผล test ที่รันจริง
สิทธิ์การทำงาน กำหนดสิ่งที่ทำได้และห้าม อ่าน/เขียน repo ได้ ห้ามลบ branch หลัก
เงื่อนไขหยุด หยุดและรายงานเมื่อมีปัญหาหรือความเสี่ยง หยุดก่อนซื้อโดเมน หยุดเมื่อ repair ครบจำนวนรอบ

⚠️ ข้อจำกัดที่ต้องรู้

Prompt อย่างเดียวไม่ทำให้ AI เชื่อมต่อเครื่องมือได้ การทำงานจริงขึ้นกับสิ่งเหล่านี้

ปัจจัย ถ้าขาดจะเกิดอะไร ตรวจก่อนเริ่ม
สิทธิ์ Repository push หรือสร้าง branch ไม่ได้ ทดสอบสร้าง branch ว่าง
Environment Variables build หรือรันไม่ผ่าน เทียบรายการตัวแปรที่ต้องใช้กับที่ตั้งไว้
API และ token เรียก Vercel หรือบริการอื่นไม่ได้ เรียกคำสั่งอ่านอย่างเดียวทดสอบ
เครื่องมือที่ตั้งค่าไว้ ไม่มีเครื่องมือ Browser Test หรือ Lint รันแต่ละคำสั่งด้วยมือหนึ่งครั้ง
การตรวจจากระบบจริง เชื่อรายงานที่ AI เล่าเอง เปิด Build Logs และ URL เอง

แยกข้อเท็จจริง การตีความ และข้อเสนอ

ประเภท เนื้อหา
ข้อเท็จจริง (ตามที่อธิบายไว้) Workflow 7 ขั้น, ความสามารถ 7 ด้าน
ข้อเท็จจริง (ตามที่อธิบายไว้) ต้องยืนยันก่อนซื้อโดเมน, ผลขึ้นกับสิทธิ์และการตั้งค่า
ความเห็นหรือการมองแนวโน้ม AI Engineering กำลังเปลี่ยนจากสั่งทีละส่วนเป็นออกแบบระบบหลายขั้น
ยังไม่มีหลักฐาน ว่า prompt แบบนี้ให้ผลดีกว่าการสั่งทีละส่วนในเชิงตัวเลข
ข้อจำกัดด้านที่มา เป็นการดัดแปลงแนวคิดจากเครื่องมือและประกาศสาธารณะ
ข้อจำกัดด้านที่มา ไม่ใช่ prompt ที่มีผู้ใดรับรองหรือเผยแพร่อย่างเป็นทางการ
ข้อจำกัดด้านที่มา จึงไม่ควรอ้างว่ามีผู้รับรอง

🛠️ ลองใช้

ตัวอย่างประกอบ (ตัวเลขเป็นของสมมติ)

เป้าหมาย: เว็บจองคิวร้านตัดผมขนาดเล็ก ใช้ gate ต่อไปนี้

ขั้น เกณฑ์ผ่านที่ตั้งก่อนเริ่ม ผลที่สมมติได้
Spec MVP มี 3 ฟีเจอร์: ดูคิวว่าง, จอง, ยกเลิก 3 จาก 3
Verify: Unit Test ผ่านอย่างน้อย 95% 38 จาก 40 = 95% ผ่าน
Verify: Browser ทำ flow จองจบใน 3 คลิก จบใน 4 คลิก ไม่ผ่าน
Self-repair รอบ 1 แก้แล้วทดสอบซ้ำ จบใน 3 คลิก ผ่าน

คำนวณซ้ำ: 38 / 40 = 0.95 = 95% ตรงเกณฑ์พอดี ส่วน Browser ไม่ผ่านรอบแรกจึงต้องเข้า Self-repair ก่อนไป Deploy

เมื่อไรควรใช้

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

ข้อกำหนดเบื้องต้น: สิทธิ์ repo, ตัวแปร Environment, token ของบริการ Deploy, คำสั่ง lint/type/test/browser ที่รันได้

ก้าวแรกที่เล็กที่สุด

รันเฉพาะ Spec → Build → Verify บนโปรเจกต์เล็ก หยุดก่อน Deploy ดูว่า gate ทำงานตามที่ตั้งไว้ไหม แล้วค่อยเพิ่ม Deploy และ Domain

ทดสอบว่าช่วยได้จริง

รายการ ค่า
ตัวชี้วัด จำนวนขั้นที่คนต้องแก้หรือทำเองต่อโปรเจกต์ และจำนวน error ที่เจอหลัง Deploy
Baseline ทำโปรเจกต์เดียวกันแบบสั่ง AI ทีละส่วน บันทึกตัวชี้วัดทั้งสอง
เงื่อนไขผ่าน (ตั้งก่อนรัน) ทั้งสองตัวชี้วัดต่ำกว่า baseline และไม่มีการซื้อหรือเผยแพร่ที่ไม่ได้อนุมัติ
ข้อควรระวัง ทำซ้ำอย่างน้อย 3 โปรเจกต์ เพราะโปรเจกต์เดียวเทียบกันไม่ได้

Checklist ก่อนปล่อยให้ AI ทำงาน

รายการ สถานะ
กำหนดบทบาทและ gate ของทุกขั้น ⚪
ตั้งสิทธิ์ขั้นต่ำที่ต้องใช้ ⚪
ระบุสิ่งที่ต้องรอยืนยัน (ซื้อ, เผยแพร่จริง) ⚪
กำหนดจำนวนรอบ Self-repair สูงสุด ⚪
ทดสอบว่าทุกเครื่องมือรันได้ด้วยมือ ⚪
เตรียมวิธีตรวจ Build Logs และ URL ด้วยตัวเอง ⚪

🚧 Risks

Warning ความเสี่ยงหลักคือเชื่อรายงานของ AI โดยไม่ตรวจจากระบบจริง

ความเสี่ยง ตัวอย่าง วิธีลด
รายงานเกินจริง บอกว่า test ผ่านทั้งที่ไม่ได้รัน ขอ output จริงและรันซ้ำเอง
แก้ปัญหาด้วยการซ่อน ลบหรือข้าม test ที่ล้มเหลว ห้ามแก้ไฟล์ test ใน Self-repair โดยไม่แจ้ง
ข้อมูลตลาดไม่มีที่มา ตัวเลขที่ไม่มีแหล่ง ต้องมีแหล่งอ้างอิงและสุ่มตรวจ
รั่วของความลับ token ถูกเขียนลงโค้ดหรือ log เก็บใน Environment Variables และตรวจก่อน commit
ค่าใช้จ่ายไม่ตั้งใจ ซื้อโดเมนหรือเปิดบริการเสียเงิน เงื่อนไขหยุดก่อนซื้อ
ข้อจำกัดของ Preview Preview ผ่านแต่ production ต่างกัน ตรวจ Final Checks บน production

ความเข้าใจผิดที่พบบ่อย

ความเข้าใจผิด ความจริง
Prompt ดี = เชื่อมทุกเครื่องมือได้เอง ต้องมีสิทธิ์ การตั้งค่า และ token จริง
AI รายงานว่า Deploy แล้ว = Deploy สำเร็จ ต้องดู Build Logs และเปิดเว็บจริง
ยิ่งอัตโนมัติ ยิ่งดี ขั้นที่ย้อนกลับยากควรมีคนยืนยัน
Harness คือ prompt ยาว ๆ Harness คือโครงสร้าง ขั้นตอน สิทธิ์ และตัวตรวจ

📌 Decision / next steps

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

  1. เขียนเกณฑ์ผ่านของแต่ละขั้นก่อนเขียน prompt
  2. ตั้งสิทธิ์ขั้นต่ำและรายการที่ต้องรอยืนยัน
  3. รัน 3 ขั้นแรกและตรวจผลเอง
  4. เพิ่ม Deploy แบบ Preview แล้วดู Build Logs
  5. เพิ่ม Domain เมื่อมั่นใจเงื่อนไขหยุดแล้ว

🧪 ทดสอบความเข้าใจ

คำถาม คำตอบ คำตอบที่มักผิด
AI รายงานว่า test ผ่านทั้งหมด ควรไปขั้น Deploy ได้เลยไหม ยัง ต้องมีหลักฐานว่ารันจริง (output, log) หรือรันซ้ำเองก่อน "ได้ เพราะ AI ยืนยันแล้ว"
ทำไมการซื้อโดเมนต้องมีการยืนยัน ทั้งที่ AI เลือกได้ดี เพราะใช้เงินจริง ย้อนกลับยาก ความเสี่ยงไม่ขึ้นกับว่าเลือกเก่งแค่ไหน "เพราะ AI เลือกโดเมนไม่เก่ง"
Build ล้มเหลว 5 รอบติดกัน Harness ควรทำอย่างไร หยุด สรุปสาเหตุที่พบและสิ่งที่ลองแล้ว ส่งให้คน "ลองต่อจนกว่าจะผ่าน"
ได้ prompt เดียวกัน แต่ทีมหนึ่งใช้ได้ อีกทีมใช้ไม่ได้ เพราะอะไรได้บ้าง สิทธิ์ repo, Environment Variables, API และเครื่องมือที่ตั้งไว้ต่างกัน "prompt คัดลอกมาไม่ครบ"
Self-repair ทำให้ test ผ่านด้วยการลบ test ที่ล้ม นับว่าสำเร็จไหม ไม่ เป็นการซ่อนปัญหา ต้องมีกฎห้ามแก้ test เงียบ ๆ "สำเร็จ เพราะทุก test ผ่าน"
ถ้าเทียบแล้ว Harness ใช้เวลานานกว่าสั่งทีละส่วน แปลว่าล้มเหลวหรือไม่ ไม่จำเป็น ต้องเทียบ error หลัง Deploy และงานที่คนต้องแก้ด้วย "ช้ากว่า = ใช้ไม่ได้"

📖 ศัพท์เพิ่มเติม

ศัพท์ ความหมาย
Harness กรอบควบคุมที่กำหนดขั้นตอน ตัวตรวจ สิทธิ์ และเงื่อนไขหยุดให้ AI
Zero-to-Launch แนวคิดทำตั้งแต่ไม่มีอะไรจนถึงเผยแพร่ใน workflow เดียว
Preview Deployment การ Deploy ชั่วคราวเพื่อทดลองก่อนเผยแพร่จริง
Build Logs บันทึกการ build ที่ใช้หาสาเหตุเมื่อล้มเหลว
Self-repair วงจรหาสาเหตุ แก้ ทดสอบซ้ำ และหยุดเมื่อแก้ไม่ได้
User Flow ลำดับที่ผู้ใช้ทำเพื่อบรรลุเป้าหมายในระบบ
Environment Variables ค่าตั้งของระบบที่อยู่นอกโค้ด เช่น token

ตัวย่อที่ใช้ในหน้านี้

ตัวย่อ ชื่อเต็ม คืออะไร อ่านค่าอย่างไร
AI Artificial Intelligence ระบบที่ทำงานคล้ายการคิดของมนุษย์ ในที่นี้คือโมเดลที่เขียนและรันงาน ไม่ใช่ตัวเลข
MVP Minimum Viable Product ผลิตภัณฑ์เวอร์ชันเล็กสุดที่ใช้ทดสอบคุณค่าได้ "MVP 3 ฟีเจอร์" = ทำแค่ 3 ฟีเจอร์ในรอบแรก
API Application Programming Interface ช่องทางให้โปรแกรมเรียกใช้บริการอื่น "ต้องมีสิทธิ์ API" = ต้องมี key ที่เรียกได้
URL Uniform Resource Locator ที่อยู่ของหน้าเว็บ ใช้เปิดตรวจ Preview หรือเว็บจริง

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

Summary

  • ใจความคือการออกแบบ Harness ให้ AI ทำงานเป็นขั้น ไม่ใช่การเขียนคำสั่งเดียวให้ยาวขึ้น
  • Workflow: Research → Spec → Build → Verify → Deploy → Domain → Final Checks
  • สามอย่างที่ต้องมี: gate ต่อขั้น, สิทธิ์และการยืนยันสำหรับสิ่งที่ย้อนกลับยาก, การตรวจผลจากระบบจริง
  • Prompt ไม่ทำให้เครื่องมือเชื่อมต่อได้เอง ต้องมีสิทธิ์ repo, Environment Variables, API และเครื่องมือที่ตั้งค่าไว้
  • ผลดีที่อ้างถึงยังไม่มีตัวเลขวัดรองรับ ควรทดสอบตามแผนก่อนนำไปใช้กับงานจริง
Facebook