สั่งงานพัฒนาโดยไม่ต้องเขียนโค้ด
คุยกับ AI จนได้หน้าจอที่กดได้จริง แก้เองได้จนพอใจ แล้วส่งต่อให้นักพัฒนาทำเฉพาะส่วนที่มองไม่เห็น ทั้งหมดนี้ใช้แค่ 4 คำสั่ง
และมีอีกหนึ่งตัวที่อยู่คนละสาย — /app-sale สำหรับทำหน้าขายของให้คนนอกอ่าน
เส้นแบ่งที่ทั้งระบบยืนอยู่บนมัน
เจ้าของงานแก้ได้ทุกอย่างที่ มองเห็น — ข้อความ ปุ่ม สี ลำดับ ช่องกรอก คอลัมน์ในตาราง นักพัฒนารับผิดชอบทุกอย่างที่ มองไม่เห็น — ฐานข้อมูล ความปลอดภัย การเชื่อมระบบ การขึ้นเซิร์ฟเวอร์
เส้นนี้สำคัญเพราะมันตัดปัญหาที่แพงที่สุดออก คือการที่เจ้าของงานอธิบายไม่ถูกว่าอยากได้อะไร แล้วนักพัฒนาทำมาผิด แก้กันไปมาหลายรอบ วิธีนี้เจ้าของงานทำเองจนเห็นภาพก่อน นักพัฒนาจึงได้รับของที่ตกลงแล้ว ไม่ต้องเดา
ทำไมต้องมี 4 คำสั่ง ไม่ใช่คำสั่งเดียว
เพราะแต่ละขั้นมีสิ่งที่ต้องตกลงกันคนละแบบ ถ้ารวบเป็นครั้งเดียว AI จะเดาแทนคุณ แล้วคุณจะได้ของที่ดูดีแต่ไม่ใช่สิ่งที่ต้องการ
| คำสั่ง | ตกลงเรื่องอะไร | ได้อะไรกลับมา |
|---|---|---|
/app-brief | จะทำอะไร แก้ปัญหาอะไรจริงๆ แค่ไหนถือว่าเสร็จ | BRIEF.md |
/app-show | หน้าตาเป็นยังไง อะไรอยู่ตรงไหน กดแล้วเกิดอะไร | หน้าจอที่เปิดดูและกดได้จริง |
/app-run | อยากลองใช้เองก่อนไหม | แอปจริงบนเครื่องคุณ มีล็อกอิน เก็บข้อมูลจริง |
/app-send | อะไรที่นักพัฒนาต้องทำ อะไรที่ยังไม่ได้ข้อสรุป | ไฟล์ zip หนึ่งไฟล์ ส่งให้นักพัฒนาได้เลย |
ติดตั้ง
เลือกวิธีตามเครื่องมือที่ใช้อยู่ ทำครั้งเดียวจบ
| ใช้อะไรอยู่ | ทำยังไง |
|---|---|
| Claude Code บน Mac | ดับเบิลคลิก ติดตั้ง.command ในซอง |
| Claude Code วิธีอื่น | คัดลอกทุกโฟลเดอร์ใน skills/ ไปไว้ที่ ~/.claude/skills/ |
| claude.ai หรือ Claude Desktop | ตอนสร้าง skill ให้อัปโหลดไฟล์ใน zip/ ทีละตัว |
| ChatGPT / Gemini / แชทอื่น | วาง portable/00-มาตรฐาน.md เป็นข้อความแรก แล้ววาง portable/app-brief.md ตาม |
| Codex / Cursor / Zcode | วาง bundle/owner.md ที่รากโปรเจกต์ ตั้งชื่อตามที่เครื่องมือนั้นอ่าน |
เช็คว่าติดตั้งสำเร็จ
พิมพ์ /app-brief ถ้าขึ้นมาแปลว่าใช้ได้แล้ว ถ้าไม่ขึ้น ลองปิดเปิดเครื่องมือใหม่หนึ่งครั้ง
/refresh-skills
/app-brief — คุยจนได้โจทย์ที่ชัด
เปลี่ยนความคิดที่ยังเป็นก้อนๆ ให้กลายเป็นโจทย์ที่คนอื่นอ่านแล้วเข้าใจตรงกัน
/app-briefใช้เมื่อเริ่มเรื่องใหม่ — เป็นประตูทางเข้าของทุกงานมันทำอะไร ถามคุณทีละเรื่อง ประมาณ 5 ถึง 8 คำถาม แล้วเขียนสรุปออกมาเป็นไฟล์เดียว
ได้ไฟล์อะไร BRIEF.md — ไอเดีย ปัญหาจริง ขอบเขต เกณฑ์ว่าแค่ไหนถือว่าเสร็จ และข้อมูลที่ระบบต้องจำ
ทำไมต้องมี ไฟล์นี้เป็นตัวอ้างอิงของทุกขั้นถัดไป ตอนตรวจงานรอบสุดท้ายจะเอาเกณฑ์ในไฟล์นี้มาไล่ทีละข้อ
วิธีใช้
พิมพ์คำสั่ง แล้วบอกไอเดียสั้นๆ
ไม่ต้องเรียบเรียง ไม่ต้องยาว บอกเท่าที่นึกออกก็พอ
/app-brief อยากได้ระบบนัดคนไข้ ตอนนี้จดใส่สมุด ลืมบ่อย
ตอบคำถามทีละข้อ
มันจะถามทีละเรื่อง ไม่ถามรวดเดียวหลายข้อ ถ้ามีตัวเลือกจะให้เป็นเลข 1 2 3 4 ตอบเป็นตัวเลขได้เลย ตอบไม่ได้ก็พิมพ์ว่าไม่รู้ มันจะเสนอค่าเริ่มต้นให้
อ่านสรุปแล้วบอกว่าตรงไหม
พอข้อมูลพอ มันจะหยุดถามแล้วเขียนสรุปให้ดู ตรงไหนไม่ตรงบอกได้เลย แก้เสร็จมันจะถามว่าไปต่อไหม ตอบว่าไปต่อ จะได้เข้าขั้นที่ 2
ตัวอย่างบทสนทนาจริง
ตอนนี้ที่เจ็บที่สุดคืออะไรคะ
1. ลืมว่าใครนัดวันไหน ต้องเปิดสมุดหา
2. นัดชนกัน คนไข้มารอ
3. คนไข้โทรมาถามว่านัดวันไหน แต่หาไม่เจอ
4. อย่างอื่น เล่ามาได้เลย
ตอนนี้มีหมอกี่คนคะ และหนึ่งวันรับนัดประมาณกี่คน
เขียนสรุปไว้ที่ BRIEF.md แล้วค่ะ
ปัญหาจริง นัดชนกันเพราะไม่มีที่กลางให้ดูคิวหมอทั้งสองคนพร้อมกัน
เกณฑ์ว่าเสร็จ จองนัดแล้วถ้าชนต้องเตือนทันที · ค้นชื่อคนไข้แล้วเห็นนัดทั้งหมดของเขาได้
ยังไม่ยืนยัน คนไข้จองเองได้ไหม ยังไม่ได้คุยกัน
ตรงไหมคะ มีอะไรจะเพิ่มไหม
1. ตรงแล้ว ไปต่อเลย จะได้เห็นหน้าจอจริง
2. ขอแก้ตรงนี้ก่อน
/app-show — เห็นหน้าจอจริง แล้วสั่งแก้
สร้างหน้าจอที่เปิดดูได้จริง โตทีละระดับ คุณอนุมัติทุกระดับก่อนไปต่อ
/app-showใช้ทั้งตอนสร้างใหม่และตอนสั่งแก้ของเดิมมันทำอะไร เปลี่ยน BRIEF.md เป็นหน้าจอ HTML ที่เปิดในเบราว์เซอร์แล้วกดได้จริง
ได้อะไร โฟลเดอร์ {ชื่องาน}-prototype/ มีหน้าจอแยกไฟล์ เปิดดูรวมกันได้ผ่านตัวเปิด
ไม่ต้องบอกว่าสร้างใหม่หรือแก้ของเดิม มันอ่านเองว่ามีของอยู่แล้วหรือยัง และอยู่ระดับไหน
โตทีละ 4 ระดับ
ที่ต้องแบ่งระดับ เพราะถ้าใส่ทุกอย่างมาพร้อมกันตั้งแต่แรก บทสนทนาจะไหลไปเรื่องสีทั้งที่ยังไม่ตกลงกันเลยว่าอะไรควรอยู่ตรงไหน
| ระดับ | ได้อะไร | ยังไม่มีอะไร | ดูอะไรตอนตรวจ |
|---|---|---|---|
| 1 | โครงหน้าจอ ทุกอย่างเป็นสีเทา | กดไม่ได้ ยังไม่มีสี | อะไรอยู่ตรงไหน ขาดหน้าไหนไปไหม |
| 2 | กดได้จริง ใส่สีแล้ว | ข้อมูลยังฝังอยู่ในหน้าจอ | กดแล้วไปถูกที่ไหม สีอ่านง่ายไหม |
| 3 | ข้อมูลแยกออกมาเป็นไฟล์ที่คุณแก้เองได้ | ยังไม่ได้เก็บถาวร ปิดแล้วหาย | ไม่มีข้อมูล ค้นไม่เจอ โหลดพัง แสดงถูกไหม |
| 4 | เดินใช้งานจริงครบ ถ่ายภาพหน้าจอทั้งมือถือและคอม | ยังเป็นต้นแบบ ไม่ใช่ระบบจริง | ไล่เทียบเกณฑ์ใน BRIEF.md ทีละข้อ |
คำถามเรื่องแบรนด์ ถามครั้งเดียวตอนจะขึ้นระดับ 2
ไม่ถามตั้งแต่แรกเพราะคนสั่งงานบอกรสนิยมเป็นนามธรรมไม่ถูก แต่พอเห็นของจริงแล้วติได้ทันที เลยย้ายมาถามตอนที่ต้องใช้จริงๆ
ขอถามคำถามเดียวสั้นๆ ก่อนใส่สี
มีโลโก้หรือสีประจำองค์กรที่ต้องใช้ไหมคะ และอยากให้ชื่อระบบเรียกว่าอะไร
ถ้ายังไม่มีก็บอกได้ จะใช้แบบสะอาดๆ กับชื่อชั่วคราวไปก่อน ตอบเสร็จทำต่อทันที
คำตอบเดียวได้ทั้งชื่อจริงและทิศทางสี ไม่ต้องถามซ้ำอีก
สั่งแก้ยังไง
พิมพ์เป็นภาษาคนได้เลย ไม่ต้องรู้ศัพท์เทคนิค ทั้งหมดนี้ใช้ /app-show ตัวเดิม
แก้ได้เอง
- ย้ายปุ่มนี้ไปอยู่ข้างบน
- เปลี่ยนคำว่า "ส่ง" เป็น "บันทึกนัด"
- เพิ่มคอลัมน์เบอร์โทรในตาราง
- สลับลำดับให้เรียงตามวันที่ล่าสุดก่อน
- ตัวหนังสือเล็กไป ขอใหญ่กว่านี้
- เพิ่มหน้าสรุปยอดนัดรายสัปดาห์
มันจะบอกว่าทำเองไม่ได้
- ให้เก็บข้อมูลไว้จริง ปิดแล้วไม่หาย
- ให้ล็อกอินก่อนใช้
- ส่ง SMS เตือนคนไข้
- ต่อกับระบบบัญชีที่มีอยู่
- ให้หลายคนใช้พร้อมกันคนละเครื่อง
พวกนี้จะถูกจดไว้ใน TODO-DEV.md พร้อมเหตุผล แล้วส่งต่อให้นักพัฒนา
สั่งหลายอย่างในข้อความเดียวได้
ถ้าพิมพ์ว่า "ผ่านแล้ว ไปต่อได้ แต่ขอแก้ข้อความหัวตารางด้วย" มันจะรับทราบทั้งสองอย่างออกมาให้เห็น ทำอันที่ตรงขั้นตอนก่อน ส่วนที่เหลือจดไว้แล้วยกกลับมาถามตอนจบระดับถัดไป ไม่หายไปเฉยๆ
เปิดดูยังไง
ดับเบิลคลิก เปิดดู.command
เปิดดู.command เสมอ
ถ้ามีหลายหน้าจอ จะมีตัวเปิดที่สลับหน้าได้ ดูสลับมือถือกับคอมได้ในหน้าเดียว
ไฟล์งานจริงอยู่ใน screens/ ส่วน index.html เป็นแค่ตัวเปิด
สิ่งที่เก็บไว้ให้ระหว่างทาง
| ไฟล์ | คืออะไร |
|---|---|
LEVEL.md | ตอนนี้อยู่ระดับไหน อนุมัติหรือยัง มีอะไรค้างไว้บ้าง |
HISTORY.md | ทุกครั้งที่แก้ ใครสั่งอะไร ทำอะไรไป เปลี่ยนไฟล์ไหน |
.snapshots/ | สำเนาย้อนกลับก่อนขึ้นระดับ เก็บ 10 ชุดล่าสุด |
data/mock-data.json | ข้อมูลตัวอย่าง แก้ไฟล์นี้ได้เองโดยไม่ต้องแตะโค้ด (มีตั้งแต่ระดับ 3) |
screenshots/ | ภาพหน้าจอตอนตรวจระดับ 4 ทั้งขนาดมือถือและคอม |
/app-run — ลองใช้จริงเองก่อน
เปลี่ยนต้นแบบเป็นแอปจริงบนเครื่องคุณ มีล็อกอินจริง เก็บข้อมูลจริง ปิดเครื่องแล้วข้อมูลยังอยู่
/app-runไม่บังคับ — ข้ามไป /app-send เลยก็ได้ใช้เมื่อไหร่ อยากใช้จริงสักพักก่อนตัดสินใจจ้างนักพัฒนา หรืออยากลองบนหลายเบราว์เซอร์ก่อน
เงื่อนไข ต้องผ่านระดับ 4 ของ /app-show และคุณอนุมัติแล้ว
จบแล้วยังไงต่อ ก็ยังจบที่ /app-send อยู่ดี แค่นักพัฒนาได้รับแอปจริงแทนต้นแบบ
มันจะถามอะไร
ห้าข้อ ครั้งเดียว ทุกข้อมีค่าเริ่มต้น ตอบข้ามได้ ถ้าเคยตอบไปแล้วมันจะไม่ถามซ้ำ
| ถาม | ถ้าไม่ตอบจะใช้ |
|---|---|
| ชื่อจริงของแอป | ชื่อชั่วคราวที่ตั้งไว้ตอนทำต้นแบบ |
| ชื่อบริษัทหรือร้าน | ใช้ชื่อแอปแทน |
| โลโก้ | ไอคอนคู่กับชื่อ |
| ใครล็อกอินได้บ้าง ใครเห็นได้แค่บางส่วน | คุณคนเดียว เห็นทุกส่วน |
| จะกรอกข้อมูลคนจริงไหม | ยังไม่ใช่ ใช้ทดลองก่อน |
เรื่องบัญชีและรหัสผ่าน
ทุกบัญชีถูกสร้างให้เสร็จตอนสร้างแอป ไม่มีหน้าตั้งค่าให้คุณทำเอง แล้วมันจะบอกรหัสมาเป็นตารางในแชทครั้งเดียว
| ชื่อผู้ใช้ | รหัสผ่าน | สิทธิ์ |
|---|---|---|
owner | K7p2-xR9m-Lq4t-Zw8n | admin เห็นทุกส่วน |
- รหัสสุ่มให้ คนละอัน อย่างน้อย 16 ตัว
- ปรากฏในแชทที่เดียว ไม่ถูกเขียนลงไฟล์ไหนทั้งนั้น
- ล็อกอินครั้งแรกจะถูกบังคับให้เปลี่ยนรหัสทันที
- ก่อนบอกรหัสมา มันต้องเอาไปลองล็อกอินจริงก่อน และต้องพิสูจน์ว่ารหัสผิดเข้าไม่ได้
ระบบใช้อะไรบ้าง
ล็อกไว้ตายตัว ไม่ได้เลือกตามใจ เพราะเป็นชุดเดียวกับที่ทีมพัฒนาใช้จริง นักพัฒนาจะได้ต่อยอดไม่ใช่รื้อทำใหม่
| ส่วน | ใช้อะไร |
|---|---|
| หน้าบ้าน | React 19 · Vite 7 · TypeScript · Tailwind 4 · TanStack Query · React Router |
| หลังบ้าน | Fastify 5 · Prisma 7 · bcrypt · cookie session |
| ฐานข้อมูล | SQLite ไฟล์เดียว |
เลือก SQLite เพราะเป็นไฟล์เดียว สำรองด้วยการคัดลอกไฟล์ ไม่ต้องลงอะไรเพิ่ม และเพราะมี Prisma คั่นไว้ นักพัฒนาเปลี่ยนไปใช้ฐานข้อมูลตัวใหญ่ทีหลังได้โดยไม่ต้องเขียนใหม่
/security-review ก่อน
/app-send — แพ็คส่งนักพัฒนา
พิมพ์คำสั่งเดียว ไม่มีคำถาม ได้ไฟล์ zip หนึ่งไฟล์ที่นักพัฒนาเปิดแล้วเริ่มงานได้เลย
/app-sendทางปกติ — คนส่วนใหญ่มาจบที่นี่ไม่ถามอะไรเลย ชื่อซองงานเอามาจากชื่อโปรเจกต์เอง ที่เหลือหยิบจากที่คุยกันไว้แล้วทั้งหมด
ตรวจเองว่าคุณผ่าน /app-run มาหรือยัง ถ้าผ่านมาแล้วจะแพ็คโค้ดแอปจริงไปด้วย ไม่ต้องบอก
อยากเปลี่ยนชื่อซอง บอกทีหลังได้ แพ็คใหม่ใช้เวลาไม่กี่วินาที
4 ด่านที่ต้องผ่านก่อนถึงจะแพ็ค
| ด่าน | เช็คอะไร | ถ้าไม่ผ่าน |
|---|---|---|
| 1 | ระดับ 4 และคุณอนุมัติแล้วจริง | ส่งกลับไป /app-show ให้บอกว่าผ่านก่อน |
| 2 | มีภาพหน้าจอขนาดมือถือครบทุกหน้า และไฟล์ไม่ว่าง | บอกว่าหน้าไหนขาด ให้กลับไปตรวจมือถือก่อน |
| 3 | ไม่มีข้อมูลจริงหลุดปน — เบอร์โทรจริง อีเมลจริง รหัสผ่าน กุญแจระบบ | บอกว่าเจอที่ไฟล์ไหนบรรทัดไหน ให้เปลี่ยนเป็นข้อมูลสมมติก่อน |
| 4 | เฉพาะกรณีผ่าน /app-run มา — โค้ดต้องคอมไพล์ผ่าน | แสดงข้อผิดพลาด แก้ก่อนถึงจะแพ็คได้ |
ในซองมีอะไร
handoff-{ชื่องาน}-{วันที่}.zip
├── README-สำหรับนักพัฒนา.md อ่านอะไรก่อนอะไรหลัง
├── SPEC.md ต้องการอะไร ขอบเขตแค่ไหน
├── DATA.md ข้อมูลแต่ละช่อง ชนิดอะไร ตัวอย่าง
├── RULES.md กฎธุรกิจที่ต้องคุมในโค้ด
├── TODO-DEV.md งานหลังบ้าน พร้อมเหตุผลว่าทำไมเจ้าของงานทำเองไม่ได้
├── OPEN-QUESTIONS.md คำถามที่ยังไม่มีคำตอบ ห้ามเดาเอง
├── HISTORY.md ประวัติการตัดสินใจทั้งหมด
├── prototype/ หน้าจอที่ตกลงกันแล้ว พร้อมภาพหน้าจอ
└── app/ โค้ดแอปจริง (เฉพาะถ้าผ่าน /app-run มา)
ของที่จงใจไม่ใส่
| ไม่ใส่ | เพราะ |
|---|---|
| ไฟล์ฐานข้อมูล | ข้อมูลที่คุณกรอกเองอยู่ในนั้น ไม่ใช่ของนักพัฒนา |
| ไฟล์ตั้งค่าที่มีความลับ | ใส่ไฟล์ตัวอย่างที่ไม่มีค่าจริงแทน |
| ไฟล์ไลบรารีและผลการคอมไพล์ | นักพัฒนาสร้างเองได้ ใส่ไปมีแต่ทำให้ไฟล์ใหญ่ |
.snapshots/ | ไฟล์ย้อนกลับของฝั่งคุณ |
ทำไมต้องมี HISTORY.md ในซอง
เพราะนักพัฒนาที่เห็นแต่ผลลัพธ์ จะไม่รู้ว่าทำไมบางอย่างถึงเป็นแบบนั้น แล้วอาจ "แก้ให้ดีขึ้น" ทับสิ่งที่คุณตั้งใจไว้ ไฟล์นี้บอกว่าใครตัดสินใจอะไรตอนไหน เพราะอะไร
/app-sale — หน้าขายของ
หน้าเดียว ให้คนที่ไม่รู้จักคุณเลยอ่านแล้วตัดสินใจทัก ไม่ใช่ระบบ ไม่ต้องล็อกอิน ไม่ต้องส่งนักพัฒนา
/app-saleแยกจาก 4 ตัวข้างบน ใช้ตัวเดียวจบใช้เมื่อไหร่ คนอ่านคือคนแปลกหน้าที่กำลังตัดสินใจว่าจะซื้อไหม ไม่ใช่คนในทีมที่กำลังทำงาน
ได้อะไร ไฟล์ HTML ไฟล์เดียว เปิดได้ทุกที่ เอาขึ้นเว็บได้เลย
ต่างจาก /app-show ตรงไหน คนละชนิดกันเลย ดูตารางข้างล่าง
ทำไมต้องแยกเป็นคนละตัว
เพราะกฎเกือบครึ่งของหน้าจอในระบบ ใช้กับหน้าขายไม่ได้ ถ้าเอามาปนกันจะได้หน้าขายที่หน้าตาเหมือนหน้าจอแอดมิน
| เรื่อง | หน้าจอในระบบ | หน้าขาย |
|---|---|---|
| การเลื่อน | เลื่อนเฉพาะเนื้อหา แถบบนอยู่นิ่ง | เลื่อนทั้งหน้า การเลื่อนคือตัวเล่าเรื่อง |
| เมนู | ต้องมี ใช้เดินไปมา | ไม่มี ทุกลิงก์คือทางออก |
| สถานะหน้าจอ | ต้องครบ 5 สถานะ | ไม่มีเลย ไม่มีข้อมูลให้โหลด |
| วัดว่าดีจาก | ทำงานตามเกณฑ์ได้ | คนอ่านแล้วกดจริง |
ส่วนที่ยังใช้ร่วมกัน — ห้าม emoji · มุมเหลี่ยม · ฟอนต์ · กันงานหน้าตา AI · มือถือ 375
ทำงานยังไง
ถามเรื่องสินค้า 2 รอบสั้นๆ
รอบแรกถามเรื่องสินค้า ราคา คนซื้อ และคำถามที่ลูกค้าถามบ่อยที่สุดก่อนตัดสินใจ รอบสองถามเรื่องหลักฐาน รูปจริง รีวิวจริง และลิงก์ไลน์
คำถามที่ลูกค้าถามบ่อยสำคัญที่สุด เพราะมันกลายเป็นหัวข้อคำถามพบบ่อยที่เขียนด้วยคำของลูกค้าเอง
เขียนข้อความให้อ่านก่อน ยังไม่ทำหน้า
คำพูดคือตัวสินค้า หน้าตาเป็นแค่ตัวพา เลยต้องตกลงคำก่อน ตอนที่ยังตัดสินได้โดยไม่ถูกหน้าตาดึงความสนใจ
ผ่านแล้วเก็บไว้ที่ COPY.md ครั้งหน้าจะแก้ก็เริ่มจากคำ ไม่ต้องไปงมในโค้ด
สร้างหน้า แล้วเปิดดูจริง
ดู 375 ก่อน แล้วค่อย 1280 กลับด้านกับหน้าจอในระบบ เพราะคนส่วนใหญ่กดมาจากลิงก์ในไลน์
แล้วดูอีกรอบแบบปิดรูปทั้งหมด ถ้าหน้ายังขายได้ แปลว่าคำพูดแบกไหว ถ้าไม่ได้ ต้องแก้คำ ไม่ใช่แก้รูป
เส้นที่มันจะไม่ข้ามให้
ถ้าไม่มีรีวิวจริง หน้าจะไม่มีหัวข้อรีวิว ไม่ใช่แต่งขึ้นมา · ถ้าไม่มีรูปจริง จะเป็นกล่องเทาที่บอกชัดว่ายังไม่มี พร้อมบอกว่าต้องถ่ายรูปอะไรบ้าง
เหตุผลไม่ใช่แค่เรื่องดูดี — รีวิวที่แต่งขึ้นคือคำกล่าวอ้างที่เจ้าของร้านต้องรับผิดชอบเอง และรูปสินค้าที่ไม่ตรงของจริง ลูกค้ารู้ทันทีตอนของถึงมือ
และมี 2 อย่างที่ยังเอาขึ้นเว็บไม่ได้ถ้าไม่มี คือรูปสินค้าจริง กับลิงก์ไลน์จริง — สร้างหน้าให้ดูก่อนได้ แต่จะบอกตรงๆ ว่ายังปล่อยไม่ได้ ไม่ใช่ปล่อยไปแล้วค่อยแก้
เรื่องปุ่มทักไลน์
- ปุ่มเดียว ข้อความเดียวกัน อย่างน้อย 3 จุด — ตอนต้น กลางหน้าหลังหลักฐาน และตอนจบ
- ใส่ข้อความตั้งต้นให้เลย เช่น "สนใจ {ชื่อสินค้า} ครับ" คนกดแล้วเจอห้องแชทว่างมักไม่พิมพ์อะไรแล้วหายไป
- บอกว่ากดแล้วเกิดอะไร เช่น "ตอบกลับภายในเวลาทำการ" ใต้ปุ่ม ลดความลังเล
- ปุ่มบอกผล ไม่ใช่บอกวิธี — "ทักไลน์สอบถาม" ดีกว่า "ติดต่อเรา" ดีกว่า "คลิกที่นี่"
/app-send ส่งให้นักพัฒนา
ตัวอย่างเต็มเรื่อง — ระบบนัดคนไข้
จากประโยคเดียว ถึงซองงานที่ส่งนักพัฒนาได้ ภายในวันเดียว
คุย
/app-brief ถาม 6 คำถาม ได้ BRIEF.md
ปัญหาจริงที่โผล่มาระหว่างคุย ไม่ใช่ "ลืมนัด" อย่างที่บอกตอนแรก แต่คือ "ไม่มีที่กลางให้ดูคิวหมอสองคนพร้อมกัน" ซึ่งเปลี่ยนหน้าตาของระบบไปเลย
ระดับ 1 — โครงเทา
ได้ 2 หน้าจอ คือ "ตารางนัดวันนี้" กับ "บันทึกนัดใหม่" ปุ่มยังกดไม่ได้
ตรวจแล้วขาดหน้า "ค้นหาคนไข้" บอกให้เพิ่ม แล้วค่อยบอกว่าผ่าน
ระดับ 2 — กดได้ ใส่สี
ตอบคำถามแบรนด์ครั้งเดียว ได้ทั้งชื่อระบบและทิศทางสี
เจอว่ากดบันทึกแล้วไม่มีอะไรบอกว่าสำเร็จ สั่งให้เพิ่มข้อความแจ้ง
ระดับ 3 — ข้อมูลแยกไฟล์
นัด 24 รายย้ายไป data/mock-data.json มากพอจนต้องแบ่งหน้า ซึ่งเป็นเรื่องที่ไม่มีตอนระดับ 1
ลองใส่ ?demo=empty ท้าย URL เพื่อดูว่าตอนไม่มีข้อมูลเลยหน้าตาเป็นยังไง
ระดับ 4 — ทดสอบจริง
เดินใช้งานครบทุกหน้า ถ่ายภาพทั้งมือถือและคอม ไล่เทียบเกณฑ์ใน BRIEF.md ทีละข้อ
ข้อที่ทำไม่ได้ในขั้นต้นแบบ เช่น "เก็บข้อมูลไว้ดูย้อนหลัง" จะถูกยกไปเป็นงานของนักพัฒนา พร้อมเหตุผลว่าทำไมต้นแบบทำไม่ได้
ส่ง
/app-send ผ่านทั้ง 4 ด่าน ได้ zip ไฟล์เดียว
นักพัฒนาเปิดแล้วรัน /scaffold-project ต่อได้เลย ไม่ต้องถามอะไรเพิ่ม
เมื่อนักพัฒนาส่งกลับมา
นักพัฒนาจะรัน /handback-to-owner ซึ่งแพ็คของกลับมาเป็นซองที่คุณเปิดแล้วใช้ได้ทันที
พร้อมรายงานที่แปลเป็นภาษาคนแล้ว ไม่มีศัพท์เทคนิคค้าง
ของที่คุณยังแก้เองได้ต่อ จะมีป้ายกำกับว่า แก้ได้: ส่วนที่ห้ามแตะจะเขียนว่า ห้ามแก้:
แก้เสร็จส่งกลับไปอีกรอบได้ ไม่จำกัดจำนวนรอบ
กฎที่ทุกงานใช้ร่วมกัน
กฎพวกนี้อยู่ในไฟล์กลางที่แก้ที่เดียวแล้วมีผลทุกที่ ไม่ว่าใครสั่งงาน ไม่ว่าเครื่องมือไหน ผลลัพธ์จะออกมาแนวเดียวกัน
หน้าตา
| กฎ | เหตุผล |
|---|---|
| ห้ามใช้ emoji ทุกที่ รวมถึงในแชท | เอกสารที่ส่งต่อให้คนอื่นต้องอ่านเป็นทางการได้ |
| มุมเหลี่ยม ไม่ใช้มุมโค้ง | ตัดสินไปแล้วครั้งเดียว ไม่ต้องมาเถียงกันทุกโปรเจกต์ |
| เลื่อนได้เฉพาะเนื้อหา แถบบนกับแถบล่างอยู่นิ่ง | เลื่อนแล้วเมนูหายไปด้วย คือเลย์เอาต์ที่ผิด |
| กล่องยืนยันขนาดตายตัว ปุ่มต้องเห็นเสมอ | กล่องที่ยืดตามเนื้อหาจะดันปุ่มตกจอ |
| งานที่ลบของจริง ต้องติ๊กยืนยันหรือพิมพ์ชื่อให้ตรง | กันกดพลาด |
| ตารางต้องมีค้นหา กรอง เรียง | ตารางที่ทำสามอย่างนี้ไม่ได้ ใช้จริงไม่ได้ |
| ทุกหน้าจอต้องมี 5 สถานะ | กำลังโหลด · มีข้อมูล · ไม่มีเลย · ค้นไม่เจอ · โหลดพัง |
| ต้องใช้ได้บนจอกว้าง 375 จุด | ขนาดมือถือจริง ถ้าล้นขอบถือว่ายังไม่เสร็จ |
การคุย
| กฎ | เหตุผล |
|---|---|
| ตอบเป็นไทยสั้นๆ ง่ายๆ | คนสั่งงานไม่ใช่นักพัฒนา |
| ถามทีละเรื่อง ไม่ถามรวดเดียวหลายข้อ | เจอห้าคำถามพร้อมกันแล้วจะตอบไม่ดีสักข้อ |
| ตัวเลือกเป็นเลข 1 2 3 4 บรรทัดละข้อ | ตอบเป็นตัวเลขได้ ไม่ต้องสลับแป้นพิมพ์ |
| ห้ามถามสิ่งที่มีคำตอบอยู่ในไฟล์แล้ว | ถามซ้ำคือทำให้งานที่เสร็จแล้ววนอีกรอบ |
| ห้ามถามคำถามน้ำ เช่น "มีอะไรจะเพิ่มอีกไหม" | ไม่มีคำตอบผิด แปลว่าไม่ได้ข้อมูลอะไร |
| ทุกคำสั่งต้องจบด้วยการเสนอขั้นถัดไป | จบด้วยคำว่า "เสร็จแล้ว" เฉยๆ ทำให้ไม่รู้ว่าต้องทำอะไรต่อ |
ความซื่อตรง
| กฎ | เหตุผล |
|---|---|
| อะไรที่คุณไม่ได้บอก ห้ามเติมให้เอง | ให้เขียนว่า "ยังไม่ยืนยัน" แล้วยกไปถาม |
| ห้ามเขียนว่าคุณอนุมัติแล้ว ถ้าคุณยังไม่ได้บอก | "งานเสร็จ" กับ "เจ้าของงานอนุมัติ" เป็นคนละเรื่อง |
| ทดสอบไม่ได้ ให้บอกว่ายังไม่เสร็จ | ห้ามเขียนว่าทดสอบแล้วทั้งที่ยังไม่ได้ทดสอบ และห้ามโยนให้คุณเช็คเอง |
| สั่งหลายอย่างพร้อมกัน ต้องรับทราบครบทุกอย่าง | หยิบไปทำแค่อันที่สะดวก แล้วเงียบเรื่องที่เหลือ คือสิ่งที่ห้าม |
| งาน UI ต้องเปิดดูจริงก่อนบอกว่าเสร็จ | อ่านโค้ดแล้วเชื่อว่าถูก จับเลย์เอาต์เพี้ยนไม่ได้ |
คำสั่งฝั่งนักพัฒนา
ส่วนนี้เจ้าของงานไม่ต้องใช้ แต่รู้ไว้จะได้เข้าใจว่านักพัฒนากำลังทำอะไร และตอบได้ว่าซองที่ส่งไปถูกเอาไปทำอะไรต่อ
1 — สร้าง (6 คำสั่ง)
| คำสั่ง | ทำอะไร |
|---|---|
/scaffold-project | รับซองจากเจ้าของงาน แตกออกมาวางเป็นโครงโปรเจกต์จริง — ตัวแรกที่ต้องรัน |
/database-design | เปลี่ยน DATA.md เป็นตารางฐานข้อมูลจริง พร้อมดัชนีและการย้ายโครง |
/backend-api | สร้างช่องทางให้หน้าบ้านดึงข้อมูล ตรวจข้อมูลเข้าทุกช่อง เช็คสิทธิ์ทุกครั้ง |
/integration | ต่อระบบภายนอก LINE ระบบจ่ายเงิน webhook พร้อมแผนรับมือตอนปลายทางล่ม |
/ai-feature | ใส่ความสามารถ AI พร้อมคุมค่าใช้จ่าย ความเร็ว และการมั่วคำตอบ |
/mcp-server | เปิดให้ AI เรียกใช้ฟังก์ชันในระบบเราได้ |
2 — ตรวจ (5 คำสั่ง)
| คำสั่ง | ทำอะไร |
|---|---|
/structure-check | ตรวจว่าโครงไฟล์ตรงมาตรฐาน ไม่มีไฟล์เกิน 250 บรรทัด ไม่มีชื่อ -v2 -copy — ด่านแรก |
/security-review | หาความลับหลุดในโค้ด ช่องโหว่ และรูสิทธิ์ — เจอข้อร้ายแรงคือหยุดทุกอย่าง |
/bug-hunt | หาบั๊กจริง ไม่ใช่ติสไตล์โค้ด เน้นเคสสุดขอบ วันที่ เวลา การปัดเศษเงิน |
/test-plan | ตัดสินว่าอะไรควรมีเทส แล้วเขียนเทสที่รันได้จริง |
/review-report | รวมผลตรวจทั้งหมดเป็นรายงานที่เจ้าของงานอ่านรู้เรื่อง เรียงว่าอะไรต้องแก้ก่อน |
ลำดับสำคัญ — โครงสร้างก่อน แล้วค่อยความปลอดภัย แล้วค่อยบั๊ก
3 — ขึ้นระบบ (2 คำสั่ง)
| คำสั่ง | ทำอะไร |
|---|---|
/migration | เปลี่ยนโครงฐานข้อมูลของจริงโดยไม่ทำข้อมูลหาย สำรองก่อน พิสูจน์ว่ากู้คืนได้ นับแถวหลังย้าย |
/ship-it | ขึ้นระบบจริง มีขั้นตอนตรวจก่อนปล่อย พิสูจน์หลังปล่อยว่าใช้ได้จริง และแผนถอยที่ตัดสินไว้ล่วงหน้า |
4 — ดูแลหลังขึ้นระบบ (2 คำสั่ง)
| คำสั่ง | ทำอะไร |
|---|---|
/monitor-and-alert | ตั้งการเฝ้าระวัง ให้รู้ว่าระบบพังก่อนที่ลูกค้าจะโทรมาบอก |
/handover-docs | เขียนคู่มือส่งมอบให้คนใหม่รับช่วงต่อได้จริง |
5 — ส่งคืน (1 คำสั่ง)
| คำสั่ง | ทำอะไร |
|---|---|
/handback-to-owner | แพ็คของกลับให้เจ้าของงานเปิดใช้ได้ทันที และแก้ส่วนที่มองเห็นเองได้ต่อ — จะปฏิเสธถ้ายังมีข้อร้ายแรงจากการตรวจความปลอดภัยค้างอยู่ |
ใช้ได้ทั้งสองฝั่ง (1 คำสั่ง)
| คำสั่ง | ทำอะไร |
|---|---|
/refresh-skills | เช็คว่าคำสั่งที่ใช้อยู่เป็นเวอร์ชันล่าสุดไหม แล้วอัปเดตให้ |
ใช้เมื่อผลลัพธ์ไม่เหมือนในคู่มือ หรือเพื่อนได้ผลไม่เหมือนกัน — สงสัยเรื่องเวอร์ชันไม่ตรงกันก่อนเสมอ
ปัญหาที่พบบ่อย
เปิดหน้าจอแล้วขึ้นจอว่าง
เกือบทุกครั้งมาจากการดับเบิลคลิก index.html ตรงๆ ให้ใช้ เปิดดู.command แทน
สาเหตุคือเบราว์เซอร์ไม่ยอมให้ไฟล์ที่เปิดแบบนั้นไปโหลดไฟล์ข้อมูลอื่น
สั่งไปแล้วมันไม่ทำ แล้วก็ไม่บอกด้วย
มักเกิดตอนส่งหลายคำสั่งในข้อความเดียว เช่น "ผ่านแล้ว แต่ขอแก้ข้อความหัวตารางด้วย" แล้วมันหยิบไปแค่คำว่าผ่าน
ตั้งแต่เวอร์ชัน 1.1.0 มีกลไกกันไว้แล้ว — ต้องรับทราบทุกคำสั่งออกมาให้เห็น และยกเรื่องที่ยังไม่ได้ทำกลับมาถามตอนจบระดับ
ถ้ายังเจอ ให้ทวงตรงๆ ว่าสั่งอะไรไว้ และเช็คว่าใช้เวอร์ชันล่าสุดหรือยังด้วย /refresh-skills
มันถามซ้ำในสิ่งที่ตอบไปแล้ว
บอกไปตรงๆ ว่าตอบไปแล้วในข้อความไหน ทุกคำสั่งมีกฎห้ามถามสิ่งที่มีคำตอบอยู่ในไฟล์แล้ว
ถ้าเกิดบ่อย มักแปลว่ายังใช้เวอร์ชันเก่าอยู่ หรือแชทนี้เปิดค้างมาตั้งแต่ก่อนอัปเดต — เปิดแชทใหม่
มันบอกว่าทำเองไม่ได้ ต้องให้นักพัฒนาทำ
ไม่ใช่ข้อจำกัดของ AI แต่เป็นเส้นแบ่งที่ตั้งใจไว้ ของที่มองไม่เห็น เช่น ฐานข้อมูลจริง ความปลอดภัย การขึ้นเซิร์ฟเวอร์ ทำผิดแล้วเสียหายจริง และแก้ยากกว่าหน้าจอมาก
ถ้าอยากลองใช้เองก่อนโดยไม่ต้องจ้างใคร ใช้ /app-run ได้ — มีล็อกอินจริงและเก็บข้อมูลจริง
แต่ยังไม่พร้อมรับข้อมูลลูกค้าจริง
อยากย้อนกลับไปเวอร์ชันก่อนหน้า
ในโฟลเดอร์งานมี .snapshots/ เก็บสำเนาก่อนขึ้นแต่ละระดับไว้ 10 ชุดล่าสุด
บอกได้เลยว่าอยากย้อนกลับไปตอนไหน แล้วดูใน HISTORY.md ว่าตอนนั้นเปลี่ยนอะไรไป
มันปฏิเสธไม่ยอมแพ็คส่งให้
แปลว่าติดด่านใดด่านหนึ่ง มันจะบอกว่าติดด่านไหนและต้องทำอะไร ที่เจอบ่อยที่สุดคือ
- ยังไม่ได้บอกว่าระดับ 4 ผ่าน
- ยังไม่เคยตรวจบนขนาดมือถือ
- มีเบอร์โทรหรืออีเมลจริงปนอยู่ในข้อมูลตัวอย่าง
ด่านพวกนี้ขอผ่านไม่ได้ ต้องแก้จริงถึงจะไปต่อ
เพื่อนใช้แล้วได้ผลไม่เหมือนกัน
เกือบแน่นอนว่าเวอร์ชันไม่ตรงกัน ให้ทั้งคู่พิมพ์ /refresh-skills แล้วเทียบเลขเวอร์ชัน
ดูแลคลังนี้
แก้มาตรฐานให้เข้ากับทีมตัวเอง
กฎหน้าตา ชื่อไฟล์ และรูปแบบซองงาน อยู่ในโฟลเดอร์ standards/ แก้ได้
แต่ต้องติดตั้งใหม่หลังแก้ เพราะแต่ละคำสั่งพกสำเนามาตรฐานติดตัวไปด้วย
| ไฟล์ | คุมเรื่องอะไร |
|---|---|
DESIGN-SYSTEM.md | หน้าตา UI ทั้งหมด สี ระยะ ตัวหนังสือ สถานะหน้าจอ |
PROJECT-STRUCTURE.md | โครงไฟล์ การตั้งชื่อ ระดับของต้นแบบ การเก็บบันทึก |
HANDOFF-PROTOCOL.md | เส้นแบ่งงาน และรูปแบบซองที่ส่งไปมา |
APP-STACK.md | เทคโนโลยีที่ /app-run ใช้ และกฎเขียนโค้ด |
CONVENTIONS.md | กติกาสำหรับคนที่จะเขียนคำสั่งใหม่เพิ่ม |
เวอร์ชัน
แก้อะไรที่เปลี่ยนพฤติกรรม ให้ขยับเลขเวอร์ชันด้วย ไม่งั้นคนที่ติดตั้งไปแล้วจะไม่รู้ว่ามีของใหม่ และเพิ่มบรรทัดในตารางบันทึกการเปลี่ยนแปลงเสมอ พร้อมเหตุผลว่าทำไมถึงแก้
เขียนคำสั่งใหม่เพิ่ม
อ่าน CONVENTIONS.md ก่อน ข้อที่พลาดกันบ่อยที่สุด
- คำอธิบายของคำสั่งคือทั้งหมดที่ AI ใช้ตัดสินว่าจะหยิบคำสั่งไหน ต้องเขียนให้ครอบคลุมคำที่คนพูดจริง
- ต้องทำงานได้แม้ในแชทเว็บที่ไม่มีเครื่องมืออะไรเลย ส่วนที่ต้องใช้เครื่องมือให้แยกไว้ท้ายไฟล์
- เนื้อคำสั่งเขียนเป็นอังกฤษ แต่บังคับให้ตอบผู้ใช้เป็นไทย
- เพดานจำนวนคำถามไม่ใช่โควตา ต้องเขียนให้ชัดว่าค่าเริ่มต้นคือไม่ถามเลย