แก่นของเรื่อง
แนวคิดหลัก: พรอมต์เดียวที่แบ่งงานเป็นเลเยอร์ตามลำดับ แต่ละเลเยอร์มีรายการสิ่งที่ต้องทำและเงื่อนไขหยุดของตัวเอง ตามด้วยเลเยอร์ซ่อมที่จำกัดจำนวนรอบ และหมวดสิทธิ์ที่ห้ามการกระทำที่ย้อนกลับไม่ได้ (จ่ายเงิน เผยแพร่ ส่งข้อความ) จนกว่ามนุษย์จะยืนยัน
ทำไมถึงได้ผล (กลไกเหตุและผล):
- ลำดับ Research → Spec → Build → Verify → Deploy บังคับให้ผลลัพธ์ของขั้นก่อนเป็นอินพุตของขั้นถัดไป AI จึงไม่กระโดดไปเขียนโค้ดก่อนรู้ว่าทำเพื่อใคร
- เลเยอร์ Verify อยู่ก่อน Deploy ข้อผิดพลาดจึงถูกจับตอนยังแก้ถูก ไม่ใช่หลังขึ้นระบบจริง
- เพดาน 3 รอบในเลเยอร์ซ่อมกัน AI วนแก้ไม่จบ และบังคับให้ส่งสรุปบันทึกกลับมาให้คนตัดสินใจ
- กฎ "ห้ามอ้างว่าเชื่อมระบบแล้วถ้าไม่มีเครื่องมือที่ตั้งค่าไว้" ลดการแต่งผลลัพธ์ที่ไม่เกิดขึ้นจริง
20% ที่สำคัญที่สุดในทางปฏิบัติ:
| ต้องทำให้ได้ก่อน | เลื่อนไว้ได้ |
|---|---|
ส่วน <goal> และ <inputs> ที่ระบุไอเดียกับกลุ่มผู้ใช้ชัดเจน |
งบประมาณและ repo (เป็นตัวเลือก) |
| เลเยอร์ Verify ที่รันคำสั่งจริงและบันทึกผล | การเลือกโดเมน |
หมวด <permissions> ที่ห้ามซื้อ/เผยแพร่โดยไม่ยืนยัน |
roadmap.md และไอเดียฟีเจอร์ถัดไป |
| เงื่อนไข "ห้ามอ้างว่า deploy แล้วถ้ายังไม่ live" | การวิจัยคู่แข่งเชิงลึก |
ช่วยให้ดีขึ้นอย่างไร
ภาพไม่มีตัวเลขวัดผลของเทมเพลตนี้ ทุกแถวจึงเป็นเหตุผลเชิงโครงสร้าง ไม่ใช่ผลที่วัดแล้ว
| สถานการณ์ | ถ้าไม่มีโครงนี้ | ถ้ามีโครงนี้ | วัดอย่างไร | หลักฐาน |
|---|---|---|---|---|
| ขอ AI สร้างเว็บ | ได้แผนหรือโค้ดชิ้นเดียว ไม่รู้ว่ารันได้ไหม | ต้องส่งโค้ด เอกสาร และ checks.md ครบ |
นับรายการส่งมอบครบกี่จาก 7 | จากภาพ (รายการ deliver) / ผลจริง: ยังไม่ทดสอบ |
| การตรวจก่อนขึ้นระบบ | ข้ามการทดสอบ พบบั๊กหลัง deploy | ต้อง lint, type check, unit test, smoke test ก่อน | จำนวนบั๊กที่พบหลัง deploy | ตีความ |
| ความเสี่ยงเรื่องเงิน | AI อาจซื้อโดเมนเอง | ต้องยืนยันราคา ต่ออายุ ผู้จดทะเบียน และเงื่อนไขโอน/ล็อก | ไม่มีการซื้อโดยไม่ยืนยัน | จากภาพ (กติกา) / พฤติกรรมจริง: ยังไม่ทดสอบ |
| ข้อผิดพลาดซ้ำ | AI วนแก้ไม่สิ้นสุด | แก้ได้สูงสุด 3 รอบ แล้วส่งสรุปและบันทึก | จำนวนรอบก่อนหยุด | จากภาพ |
| ความน่าเชื่อถือของข้อมูลตลาด | ข้อมูลไม่มีที่มา | ทุกข้อกล่าวอ้างสำคัญต้องมี URL แหล่งที่มา | สัดส่วนข้อกล่าวอ้างที่มี URL | จากภาพ / ยังไม่ทดสอบ |
ลองใช้
ตัวอย่างประกอบ (ตัวเลขเป็นของเราเอง)
ไอเดีย: เว็บจองคิวร้านตัดผมในเชียงใหม่ งบไม่เกิน 100 ดอลลาร์ต่อเดือน
| ช่อง | ค่าที่กรอก |
|---|---|
IDEA |
เว็บจองคิวร้านตัดผมออนไลน์ |
USERS |
เจ้าของร้านตัดผมขนาดเล็กและลูกค้าในเมือง |
REPO |
เว้นว่าง (สร้างใหม่) |
BUDGET |
ไม่เกิน 100 ดอลลาร์ต่อเดือน |
TOOLS |
Vercel CLI, Grok Bot, Opus 5.5 |
CHECKS |
ฟอร์มจองต้องส่งสำเร็จ, หน้าแรกโหลดได้บนมือถือ |
PERMISSIONS |
deploy แบบ preview ได้, ห้ามซื้อโดเมน |
เกณฑ์ผ่านที่ตั้งไว้ก่อนรัน: checks.md ต้องบันทึกคำสั่งและผลของทั้ง 2 เช็กที่กำหนด และมี URL preview ที่เปิดได้
เมื่อไรควรใช้
| ใช้เมื่อ | ไม่ควรใช้เมื่อ | สิ่งที่ต้องมีก่อน |
|---|---|---|
| ต้องการ MVP เว็บที่ขึ้นระบบได้เร็ว | ระบบมีข้อมูลอ่อนไหวหรือการเงินจริง ต้องมีการตรวจสอบโดยคน | บัญชี Vercel และเครื่องมือที่เชื่อมไว้แล้ว |
| ไอเดียเล็กและขอบเขตชัด | ต้องการสถาปัตยกรรมขนาดใหญ่ซับซ้อน | ระบุ IDEA และ USERS ให้ชัด |
| อยากได้เอกสารและบันทึกการทดสอบติดมาด้วย | ไม่มีเครื่องมือที่ให้ AI รันคำสั่งได้ | กำหนดสิทธิ์ใน PERMISSIONS ไว้ล่วงหน้า |
ก้าวแรกที่เล็กที่สุด
คัดลอกเฉพาะ <goal>, <principles>, <inputs>, <layer_4_verify>, <permissions> และ <deliver> ไปใช้กับไอเดียเล็กๆ ก่อน ยังไม่ต้องใช้ครบทุกเลเยอร์
วิธีตรวจว่าช่วยได้จริง
| ตัวชี้วัด | ฐานเดิม (ทำเอง) | เกณฑ์ผ่าน (กำหนดก่อนรัน) |
|---|---|---|
| รายการส่งมอบครบ | นับจากรอบที่ไม่ใช้เทมเพลต | ครบทุกข้อที่ขอ |
| บั๊กที่พบหลัง deploy | จำนวนจากรอบเดิม | น้อยกว่าฐานเดิม |
| การกระทำที่ต้องขออนุมัติแต่ไม่ขอ | ต้องเป็น 0 | 0 ครั้ง |
ทดสอบความเข้าใจ
| คำถาม | คำตอบ | คำตอบที่มักผิด |
|---|---|---|
| ทำไมเลเยอร์ Verify ต้องมาก่อน Deploy ทั้งที่ Vercel มี preview ให้ทดสอบ? | ข้อผิดพลาดที่ build และ test จับได้ ควรแก้ก่อนสร้าง deployment | "preview ทดสอบแทนได้ จึงข้าม Verify" |
| ถ้าเครื่องมือ Vercel ใช้ไม่ได้ AI ควรทำอะไร? | หยุด แล้วให้ทางเลือกแบบทำเองด้วยมือ ไม่อ้างว่า deploy แล้ว | "ลองเดาขั้นตอนต่อและรายงานว่าสำเร็จ" |
| เหตุใดจึงจำกัดการซ่อมไว้ 3 รอบ? | กันการวนไม่จบและบังคับให้มนุษย์รับช่วงพร้อมบันทึกเมื่อปัญหาเกินกำลัง | "เพื่อประหยัดเงินเท่านั้น" |
| ถ้าคำสั่งตรวจราคาโดเมนรันสำเร็จ AI ซื้อต่อได้เลยหรือไม่? | ไม่ได้ ต้องให้ผู้ใช้ยืนยันราคา ต่ออายุ ผู้จดทะเบียน และเงื่อนไขโอน/ล็อกก่อน | "ซื้อได้ ถ้าราคาอยู่ในงบ" |
(ข้อจำกัด) ถ้า checks.md ผ่านทั้งหมด แปลว่าเว็บไม่มีปัญหาใช่หรือไม่? |
ไม่ใช่ ผ่านเฉพาะรายการใน CHECKS และ smoke test ของ flow หลัก |
"ผ่านแล้ว แปลว่าพร้อมใช้งานจริงทุกด้าน" |
โครงสร้างพรอมต์ทั้งหมด
พรอมต์ใช้แท็กคล้าย XML ห่อแต่ละส่วนเพื่อให้โมเดลแยกบทบาท กติกา และขั้นตอนออกจากกัน (จากภาพ)
| แท็ก | หน้าที่ |
|---|---|
<goal> |
เปลี่ยนไอเดียเป็นเว็บที่ใช้งานได้ deploy ตรวจแล้ว เลือกโดเมนได้ ห้ามอ้างว่าเชื่อมระบบแล้วถ้าไม่มีเครื่องมือ |
<role> |
ผู้ดูแลการเปิดตัว ทำงานเป็นทีมเอเจนต์ วิจัย ผลิตภัณฑ์ วิศวกรรม ออกแบบ และ QA |
<principles> |
สร้างของจริง ข้อมูลล่าสุดตรวจสอบได้ MVP ก่อน ทดสอบก่อนเสร็จ ห้ามแต่งผู้ใช้ ผลลัพธ์ หรือข้อมูล |
<inputs> |
ตัวแปรที่ผู้ใช้กรอก |
<layer_1_research> ถึง <layer_6_domain> |
หกเลเยอร์งานหลัก |
<layer_7_repair> |
วงซ่อมเมื่อขั้นตอนใดล้มเหลว |
<execution_loop> |
ลำดับรวมของงาน |
<permissions> |
สิ่งที่ห้ามทำโดยไม่ได้รับอนุมัติ |
<deliver> |
รายการส่งมอบ |
ตัวแปรใน <inputs>
| ตัวแปร | ความหมาย | บังคับหรือไม่ |
|---|---|---|
{{IDEA}} |
สิ่งที่ต้องการสร้าง | ใช่ |
{{USERS}} |
กลุ่มเป้าหมายและความต้องการ | ใช่ |
{{REPO}} |
GitHub repository (ถ้ามี) | ไม่ |
{{BUDGET}} |
งบ เช่น ต่ำกว่า 100 ดอลลาร์ต่อเดือน | ไม่ |
{{TOOLS}} |
เครื่องมือและการเชื่อมต่อที่มี | ใช่ |
{{CHECKS}} |
ข้อกำหนดหรือการทดสอบเฉพาะ | ใช่ |
{{PERMISSIONS}} |
สิ่งที่อนุญาตให้ทำ | ใช่ |
หมายเหตุ: ภาพระบุเฉพาะ REPO และ BUDGET ว่าเป็นตัวเลือก คอลัมน์ "บังคับหรือไม่" ของตัวแปรที่เหลือเป็นการตีความของเรา
ลำดับการทำงานของเอเจนต์
Research -> Spec -> Build -> Verify -> Deploy
-> Domain options -> Final checks -> Handoff
(ขั้นใดล้มเหลว -> layer_7_repair สูงสุด 3 รอบ)
เลเยอร์ 1: Research (ใช้ Grok Bot)
- ขนาดตลาด แนวโน้ม และผู้เล่นหลัก
- เว็บไซต์คู่แข่งและการวางตำแหน่งผลิตภัณฑ์
- กลุ่มเป้าหมาย ปัญหา และโอกาส
- ข่าวล่าสุด เครื่องมือ และเทคโนโลยีที่เกี่ยวข้อง
- ให้ URL แหล่งที่มาของทุกข้อกล่าวอ้างสำคัญ
- ติดป้ายสมมติฐานและความไม่แน่นอนอย่างชัดเจน
เลเยอร์ 2: Spec
- ฟีเจอร์หลักและ flow ของผู้ใช้
- tech stack และสถาปัตยกรรม (เช่น Next.js, ฐานข้อมูล, API)
- ทิศทาง UI/UX และตัวอย่างอ้างอิง
- เกณฑ์การยอมรับและตัวชี้วัดความสำเร็จ
- แผนการสร้างทีละขั้น
เลเยอร์ 3: Build (ใช้ Opus 5.5 กับเครื่องมือระดับ repository)
- โค้ดที่ใช้งานได้จริง (หน้าบ้านและหลังบ้านตามจำเป็น)
- UI ที่สะอาด ทันสมัย รองรับหลายขนาดจอ และใช้งานง่าย
- การตั้งค่าสภาพแวดล้อมและเอกสาร
- ข้อมูลตัวอย่างหรือเนื้อหาเริ่มต้นถ้าจำเป็น
- ทำตามแนวปฏิบัติด้านโครงสร้าง ความปลอดภัย และประสิทธิภาพ
เลเยอร์ 4: Verify
- ติดตั้ง dependencies และ build โปรเจกต์
- รัน lint, type check และ unit test (ถ้ามี)
- รัน production build
- รัน browser smoke test ใน flow ผู้ใช้หลัก
- บันทึกคำสั่งที่ใช้และผลจริง
- แก้ปัญหาแล้วทดสอบซ้ำจนผ่าน
เลเยอร์ 5: Deploy
- สร้าง preview deployment บน Vercel
- ตรวจ build log และแก้ข้อผิดพลาดของ deployment
- ทดสอบ URL preview และฟังก์ชันหลัก
- ให้ขั้นตอน deploy production ฉบับสุดท้าย
- ระบุ environment variables และการตั้งค่า
- ถ้าเครื่องมือ Vercel ใช้ไม่ได้ ให้หยุดและให้ทางเลือกแบบทำเอง
เลเยอร์ 6: Domain
ใช้ workflow โดเมนใหม่ของ Vercel CLI (ภาพระบุว่าประกาศเมื่อ 9 ต.ค. 2026)
| คำสั่ง | หน้าที่ |
|---|---|
vercel domains search <keyword> |
ค้นหาโดเมนที่ว่าง |
vercel domains check <domain> |
ตรวจโดเมนที่ระบุ |
vercel domains price <domain> |
ดูราคา |
Warning ห้ามซื้อโดเมนก่อนผู้ใช้ยืนยันแบบโต้ตอบเรื่อง: ราคาและสกุลเงิน, การตั้งค่าต่ออายุอัตโนมัติ, ข้อมูลผู้จดทะเบียน, เงื่อนไขและกฎการโอน/ล็อก
สิ่งที่ต้องส่งมอบในเลเยอร์นี้: รายชื่อโดเมนที่เหมาะสมพร้อมคำแนะนำตามแบรนด์ ความพร้อมใช้ และราคา
เลเยอร์ 7: Repair
- หาสาเหตุราก
- แก้แล้วรันการตรวจที่เกี่ยวข้องซ้ำ
- ลองไม่เกิน 3 รอบ
- ถ้ายังล้ม ให้สรุปชัดเจน แนบ log และขั้นต่อไปสำหรับการตรวจสอบด้วยมือ
สิทธิ์ (<permissions>)
- ห้ามส่งอีเมล ข้อความ หรือการสื่อสารภายนอก
- ห้ามเผยแพร่ขึ้น production หรือซื้อโดเมนโดยไม่ได้รับอนุมัติที่ชัดเจนจากผู้ใช้
- ห้ามใช้เงินโดยไม่ยืนยัน
- ใช้เฉพาะข้อมูล เครื่องมือ และบัญชีที่ได้รับอนุญาต
สิ่งที่ต้องส่งมอบ (<deliver>)
| รายการ | รายละเอียด |
|---|---|
| Live preview URL | พร้อมขั้นตอน production |
| โค้ดและเอกสาร | source code และ documentation |
checks.md |
ผลการทดสอบทั้งหมด |
roadmap.md |
ฟีเจอร์และไอเดียถัดไป |
| ตัวเลือกโดเมน | พร้อมราคา (ถ้าขอ) |
| สรุปงาน | สิ่งที่สร้าง วิธีทำงาน และขั้นต่อไป |
| รายการเปิด | คำถามค้าง ความเสี่ยง และสิ่งที่ติดขัด |
| ข้อห้ามสำคัญ | ห้ามแต่งผลลัพธ์หรืออ้างว่าเว็บ live ถ้ายังไม่ live |
แนวปฏิบัติที่ดี ข้อผิดพลาดที่พบบ่อย และเช็กลิสต์
แนวปฏิบัติ (ตีความ)
- กรอก
CHECKSให้เป็นเงื่อนไขที่ตรวจได้ เช่น "ฟอร์มส่งสำเร็จ" ไม่ใช่ "ใช้งานได้ดี" - กำหนด
PERMISSIONSให้แคบที่สุดตั้งแต่ต้น แล้วค่อยขยาย - ตรวจ
checks.mdด้วยตัวเองว่าคำสั่งที่บันทึกรันซ้ำได้จริง
ข้อผิดพลาดที่พบบ่อย (ตีความ)
| ข้อผิดพลาด | ผลที่ตามมา | วิธีแก้ |
|---|---|---|
เว้น TOOLS ว่าง |
AI ไม่มีเครื่องมือจริงและอาจส่งแค่แผน | ระบุเครื่องมือที่เชื่อมแล้ว |
ขอฟีเจอร์เยอะใน IDEA |
ขัดกับหลัก MVP ก่อน | แตกเป็นรอบ ให้ฟีเจอร์เสริมไปอยู่ใน roadmap.md |
| ให้สิทธิ์ production ตั้งแต่ต้น | ขัดกับกติกาขออนุมัติ | ให้ preview ก่อน |
| เชื่อรายงานโดยไม่เปิด URL | พลาดกรณีที่ไม่ live จริง | เปิด preview URL ทดสอบเอง |
เช็กลิสต์ก่อนส่งมอบ
| สถานะ | รายการ |
|---|---|
| ⚪ | IDEA, USERS, TOOLS, CHECKS, PERMISSIONS กรอกครบ |
| ⚪ | ข้อกล่าวอ้างด้านตลาดทุกข้อมี URL แหล่งที่มา |
| ⚪ | checks.md มีคำสั่งและผลจริง |
| ⚪ | เปิด preview URL แล้วทดสอบ flow หลักได้ |
| ⚪ | ไม่มีการซื้อหรือเผยแพร่โดยไม่ได้ยืนยัน |
| ⚪ | รายการคำถามค้างและความเสี่ยงถูกส่งมาด้วย |
Risks
Warning เทมเพลตลดความเสี่ยงได้ในระดับพรอมต์เท่านั้น ไม่ได้รับประกันว่าโมเดลจะทำตามทุกข้อ
| ความเสี่ยง | รายละเอียด | ป้ายหลักฐาน |
|---|---|---|
| ผลลัพธ์จริงยังไม่ถูกวัด | ยังไม่มีตัวเลขว่าเทมเพลตเพิ่มอัตราสำเร็จเท่าใด | ยังไม่ทดสอบ |
| ความถูกต้องของวันที่ประกาศคำสั่งโดเมน | วันที่และคำสั่งมาจากภาพ ควรเทียบเอกสารทางการของ Vercel ก่อนใช้ | จากภาพ |
| ข้อมูลวิจัยอาจคลาดเคลื่อน | ต้องสุ่มเปิด URL แหล่งที่มาตรวจเอง | ตีความ |
| ช่องโหว่ด้านความปลอดภัยของโค้ดที่ AI สร้าง | smoke test ไม่ครอบคลุมการตรวจความปลอดภัยเชิงลึก | ตีความ |
| ค่าใช้จ่ายแฝง | เครื่องมือและโดเมนมีค่าใช้จ่าย ต้องเทียบกับ BUDGET |
ตีความ |
Decision / next steps
Recommendation เริ่มจากโปรเจกต์ทดลองขนาดเล็ก ตั้งสิทธิ์ให้ deploy ได้เฉพาะ preview แล้วเทียบ
checks.mdกับงานที่ทำเองก่อนตัดสินใจใช้กับงานจริง
- คัดลอกโครงย่อ 6 แท็กตามหัวข้อ "ก้าวแรกที่เล็กที่สุด"
- กรอกอินพุตและรันกับไอเดียทดลอง
- ตรวจ
checks.mdและเปิด preview URL ด้วยตัวเอง - ปรับเกณฑ์ใน
CHECKSแล้วจึงเพิ่มเลเยอร์โดเมน
ตัวย่อที่ใช้ในหน้านี้
| ตัวย่อ | ชื่อเต็ม | คืออะไร | อ่านค่าอย่างไร |
|---|---|---|---|
| MVP | Minimum Viable Product | ผลิตภัณฑ์เวอร์ชันเล็กสุดที่ใช้งานได้จริงและทดสอบกับผู้ใช้ได้ | "MVP ก่อน" = ทำฟีเจอร์แกนหลักให้เสร็จก่อนเพิ่มอย่างอื่น |
| UI | User Interface | หน้าตาและองค์ประกอบที่ผู้ใช้เห็นและกด | "UI สะอาด" = หน้าจอไม่รก |
| UX | User Experience | ประสบการณ์โดยรวมของผู้ใช้ | "UX ดี" = ทำงานสำเร็จได้ง่าย |
| QA | Quality Assurance | บทบาทตรวจคุณภาพ (ภาพระบุเป็นหนึ่งในบทบาทของทีมเอเจนต์) | บทบาท QA = ผู้ทดสอบก่อนส่งมอบ |
| CLI | Command-Line Interface | เครื่องมือที่สั่งงานด้วยคำสั่งพิมพ์ | vercel domains search <keyword> คือคำสั่งหนึ่งของ Vercel CLI |
| URL | Uniform Resource Locator | ที่อยู่ของหน้าเว็บ | "URL แหล่งที่มา" = ลิงก์ที่ใช้ตรวจข้อกล่าวอ้าง |
| API | Application Programming Interface | ช่องทางให้โปรแกรมคุยกัน | "API" ใน tech stack = บริการที่เว็บเรียกใช้ |
| AI | Artificial Intelligence | ปัญญาประดิษฐ์ ในที่นี้คือโมเดลที่ทำงานตามพรอมต์ | "ทีมเอเจนต์ AI" = โมเดลหลายบทบาท |
| Vercel | ชื่อแพลตฟอร์ม | บริการโฮสต์และ deploy เว็บ ที่พรอมต์ใช้เป็นปลายทาง | "deploy บน Vercel" |
| Next.js | ชื่อเฟรมเวิร์ก | เฟรมเวิร์กสร้างเว็บ ภาพยกเป็นตัวอย่าง tech stack | "เช่น Next.js" = ตัวเลือกหนึ่ง ไม่ได้บังคับ |
| Grok Bot | ชื่อเครื่องมือ AI | เครื่องมือที่พรอมต์กำหนดให้ทำวิจัยตลาดปัจจุบัน | เลเยอร์ 1 ใช้ Grok Bot |
| Opus 5.5 | ชื่อโมเดล AI | โมเดลที่พรอมต์กำหนดให้ลงมือ implement | เลเยอร์ 3 ใช้ Opus 5.5 |
| GitHub | ชื่อบริการ | บริการเก็บและจัดการซอร์สโค้ด | REPO = repository บน GitHub (ถ้ามี) |
{{...}} |
ตัวแปรแทนค่า | ช่องว่างในเทมเพลตที่ผู้ใช้ต้องกรอก | {{IDEA}} = ใส่ไอเดียของคุณแทน |
| IDEA, USERS, REPO, BUDGET, TOOLS, CHECKS, PERMISSIONS | ชื่อช่องอินพุต | ชื่อตัวแปรที่อธิบายไว้ในหัวข้อ "ตัวแปรใน inputs" | ดูตารางตัวแปร |
ตัวย่อที่ความหมายมาจากความรู้ทั่วไป ไม่ได้ให้คำนิยามไว้ในภาพ: MVP (ภาพใช้คำนี้แต่ไม่ขยายความ), UI, UX, QA, CLI, URL, API, AI, Next.js, GitHub, Vercel
Summary
ข้อสรุป: เทมเพลตนี้เป็นกรอบควบคุมการทำงานของ AI ให้ครบวงจรตั้งแต่ไอเดียถึงเว็บที่ deploy ได้ โดยมีเงื่อนไขตรวจสอบและขอบเขตสิทธิ์ชัดเจน ส่วนผลลัพธ์จริงยังไม่ได้ทดสอบ
- โครงสร้าง 7 เลเยอร์ +
execution_loopเรียงงานเป็น Research → Spec → Build → Verify → Deploy → Domain → Handoff - ความปลอดภัยมาจาก
<permissions>: ห้ามซื้อ เผยแพร่ ใช้เงิน หรือส่งข้อความโดยไม่ได้รับอนุมัติ - วงซ่อมจำกัด 3 รอบ ก่อนส่งต่อให้มนุษย์พร้อม log
- ส่วนที่ควรลงแรงก่อน:
<inputs>, Verify,<permissions>และเงื่อนไข "ห้ามอ้างว่า live ถ้ายังไม่ live" - ประโยชน์ทุกข้อในหน้านี้เป็นการตีความเชิงโครงสร้างหรือยังไม่ทดสอบ ควรวัดด้วยตัวชี้วัดในหัวข้อ "ลองใช้" ก่อนใช้งานจริง
