สำหรับคนที่ไม่ได้เขียนโค้ด

สั่งงานพัฒนาโดยไม่ต้องเขียนโค้ด

คุยกับ AI จนได้หน้าจอที่กดได้จริง แก้เองได้จนพอใจ แล้วส่งต่อให้นักพัฒนาทำเฉพาะส่วนที่มองไม่เห็น ทั้งหมดนี้ใช้แค่ 4 คำสั่ง

/app-briefคุย จนได้โจทย์ที่ชัด
/app-showเห็นหน้าจอ สั่งแก้ได้
/app-runลองใช้จริงเอง (ไม่บังคับ)
/app-sendแพ็คส่งนักพัฒนา

และมีอีกหนึ่งตัวที่อยู่คนละสาย — /app-sale สำหรับทำหน้าขายของให้คนนอกอ่าน

ภาพรวม

เส้นแบ่งที่ทั้งระบบยืนอยู่บนมัน

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

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

ทำไมต้องมี 4 คำสั่ง ไม่ใช่คำสั่งเดียว

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

คำสั่งตกลงเรื่องอะไรได้อะไรกลับมา
/app-briefจะทำอะไร แก้ปัญหาอะไรจริงๆ แค่ไหนถือว่าเสร็จBRIEF.md
/app-showหน้าตาเป็นยังไง อะไรอยู่ตรงไหน กดแล้วเกิดอะไรหน้าจอที่เปิดดูและกดได้จริง
/app-runอยากลองใช้เองก่อนไหมแอปจริงบนเครื่องคุณ มีล็อกอิน เก็บข้อมูลจริง
/app-sendอะไรที่นักพัฒนาต้องทำ อะไรที่ยังไม่ได้ข้อสรุปไฟล์ zip หนึ่งไฟล์ ส่งให้นักพัฒนาได้เลย
หน้าที่ของคุณคือตอบ ไม่ใช่เขียน ทุกคำสั่งออกแบบมาให้ AI เป็นฝ่ายถาม คุณไม่ต้องเขียนสเปก ไม่ต้องบรรยายหน้าจอ ไม่ต้องสรุปอะไรทั้งนั้น ตอบไม่ได้ก็บอกว่าไม่รู้ AI จะเสนอค่าเริ่มต้นให้แล้วเดินต่อ
เริ่มต้น

ติดตั้ง

เลือกวิธีตามเครื่องมือที่ใช้อยู่ ทำครั้งเดียวจบ

ใช้อะไรอยู่ทำยังไง
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
ขั้นที่ 1

/app-brief — คุยจนได้โจทย์ที่ชัด

เปลี่ยนความคิดที่ยังเป็นก้อนๆ ให้กลายเป็นโจทย์ที่คนอื่นอ่านแล้วเข้าใจตรงกัน

/app-briefใช้เมื่อเริ่มเรื่องใหม่ — เป็นประตูทางเข้าของทุกงาน

มันทำอะไร ถามคุณทีละเรื่อง ประมาณ 5 ถึง 8 คำถาม แล้วเขียนสรุปออกมาเป็นไฟล์เดียว

ได้ไฟล์อะไร BRIEF.md — ไอเดีย ปัญหาจริง ขอบเขต เกณฑ์ว่าแค่ไหนถือว่าเสร็จ และข้อมูลที่ระบบต้องจำ

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

วิธีใช้

01

พิมพ์คำสั่ง แล้วบอกไอเดียสั้นๆ

ไม่ต้องเรียบเรียง ไม่ต้องยาว บอกเท่าที่นึกออกก็พอ

/app-brief อยากได้ระบบนัดคนไข้ ตอนนี้จดใส่สมุด ลืมบ่อย
02

ตอบคำถามทีละข้อ

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

03

อ่านสรุปแล้วบอกว่าตรงไหม

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

ตัวอย่างบทสนทนาจริง

คุณ
อยากได้ระบบนัดคนไข้ ตอนนี้จดใส่สมุด ลืมบ่อย
AI

ตอนนี้ที่เจ็บที่สุดคืออะไรคะ

1. ลืมว่าใครนัดวันไหน ต้องเปิดสมุดหา
2. นัดชนกัน คนไข้มารอ
3. คนไข้โทรมาถามว่านัดวันไหน แต่หาไม่เจอ
4. อย่างอื่น เล่ามาได้เลย

คุณ
2 กับ 3
AI

ตอนนี้มีหมอกี่คนคะ และหนึ่งวันรับนัดประมาณกี่คน

คุณ
หมอ 2 คน วันละประมาณ 20 คน
AI

เขียนสรุปไว้ที่ BRIEF.md แล้วค่ะ

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

ตรงไหมคะ มีอะไรจะเพิ่มไหม

1. ตรงแล้ว ไปต่อเลย จะได้เห็นหน้าจอจริง
2. ขอแก้ตรงนี้ก่อน

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

/app-show — เห็นหน้าจอจริง แล้วสั่งแก้

สร้างหน้าจอที่เปิดดูได้จริง โตทีละระดับ คุณอนุมัติทุกระดับก่อนไปต่อ

/app-showใช้ทั้งตอนสร้างใหม่และตอนสั่งแก้ของเดิม

มันทำอะไร เปลี่ยน BRIEF.md เป็นหน้าจอ HTML ที่เปิดในเบราว์เซอร์แล้วกดได้จริง

ได้อะไร โฟลเดอร์ {ชื่องาน}-prototype/ มีหน้าจอแยกไฟล์ เปิดดูรวมกันได้ผ่านตัวเปิด

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

โตทีละ 4 ระดับ

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

ระดับได้อะไรยังไม่มีอะไรดูอะไรตอนตรวจ
1โครงหน้าจอ ทุกอย่างเป็นสีเทากดไม่ได้ ยังไม่มีสีอะไรอยู่ตรงไหน ขาดหน้าไหนไปไหม
2กดได้จริง ใส่สีแล้วข้อมูลยังฝังอยู่ในหน้าจอกดแล้วไปถูกที่ไหม สีอ่านง่ายไหม
3ข้อมูลแยกออกมาเป็นไฟล์ที่คุณแก้เองได้ยังไม่ได้เก็บถาวร ปิดแล้วหายไม่มีข้อมูล ค้นไม่เจอ โหลดพัง แสดงถูกไหม
4เดินใช้งานจริงครบ ถ่ายภาพหน้าจอทั้งมือถือและคอมยังเป็นต้นแบบ ไม่ใช่ระบบจริงไล่เทียบเกณฑ์ใน BRIEF.md ทีละข้อ
มันจะไม่ข้ามระดับเอง จบแต่ละระดับมันจะหยุดแล้วรอคุณบอกว่าผ่าน ถ้ายังไม่บอก มันจะไม่ทำระดับถัดไป และมันห้ามเขียนว่า "อนุมัติแล้ว" แทนคุณเด็ดขาด

คำถามเรื่องแบรนด์ ถามครั้งเดียวตอนจะขึ้นระดับ 2

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

AI

ขอถามคำถามเดียวสั้นๆ ก่อนใส่สี

มีโลโก้หรือสีประจำองค์กรที่ต้องใช้ไหมคะ และอยากให้ชื่อระบบเรียกว่าอะไร

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

คุณ
ไม่มีโลโก้ ขอให้อ่านง่าย ชื่อเรียกว่า ตารางหมอ ก็ได้

คำตอบเดียวได้ทั้งชื่อจริงและทิศทางสี ไม่ต้องถามซ้ำอีก

สั่งแก้ยังไง

พิมพ์เป็นภาษาคนได้เลย ไม่ต้องรู้ศัพท์เทคนิค ทั้งหมดนี้ใช้ /app-show ตัวเดิม

แก้ได้เอง

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

มันจะบอกว่าทำเองไม่ได้

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

พวกนี้จะถูกจดไว้ใน TODO-DEV.md พร้อมเหตุผล แล้วส่งต่อให้นักพัฒนา

สั่งหลายอย่างในข้อความเดียวได้

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

เปิดดูยังไง

ดับเบิลคลิก  เปิดดู.command
ห้ามดับเบิลคลิก index.html ตรงๆ จะขึ้นจอว่าง เพราะเบราว์เซอร์ไม่ยอมให้ไฟล์โหลดไฟล์อื่นเวลาเปิดแบบนั้น ให้ใช้ เปิดดู.command เสมอ

ถ้ามีหลายหน้าจอ จะมีตัวเปิดที่สลับหน้าได้ ดูสลับมือถือกับคอมได้ในหน้าเดียว ไฟล์งานจริงอยู่ใน screens/ ส่วน index.html เป็นแค่ตัวเปิด

สิ่งที่เก็บไว้ให้ระหว่างทาง

ไฟล์คืออะไร
LEVEL.mdตอนนี้อยู่ระดับไหน อนุมัติหรือยัง มีอะไรค้างไว้บ้าง
HISTORY.mdทุกครั้งที่แก้ ใครสั่งอะไร ทำอะไรไป เปลี่ยนไฟล์ไหน
.snapshots/สำเนาย้อนกลับก่อนขึ้นระดับ เก็บ 10 ชุดล่าสุด
data/mock-data.jsonข้อมูลตัวอย่าง แก้ไฟล์นี้ได้เองโดยไม่ต้องแตะโค้ด (มีตั้งแต่ระดับ 3)
screenshots/ภาพหน้าจอตอนตรวจระดับ 4 ทั้งขนาดมือถือและคอม
ขั้นที่ 3 — ทางเลือก ก

/app-run — ลองใช้จริงเองก่อน

เปลี่ยนต้นแบบเป็นแอปจริงบนเครื่องคุณ มีล็อกอินจริง เก็บข้อมูลจริง ปิดเครื่องแล้วข้อมูลยังอยู่

/app-runไม่บังคับ — ข้ามไป /app-send เลยก็ได้

ใช้เมื่อไหร่ อยากใช้จริงสักพักก่อนตัดสินใจจ้างนักพัฒนา หรืออยากลองบนหลายเบราว์เซอร์ก่อน

เงื่อนไข ต้องผ่านระดับ 4 ของ /app-show และคุณอนุมัติแล้ว

จบแล้วยังไงต่อ ก็ยังจบที่ /app-send อยู่ดี แค่นักพัฒนาได้รับแอปจริงแทนต้นแบบ

มันจะถามอะไร

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

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

เรื่องบัญชีและรหัสผ่าน

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

ชื่อผู้ใช้รหัสผ่านสิทธิ์
ownerK7p2-xR9m-Lq4t-Zw8nadmin เห็นทุกส่วน
  • รหัสสุ่มให้ คนละอัน อย่างน้อย 16 ตัว
  • ปรากฏในแชทที่เดียว ไม่ถูกเขียนลงไฟล์ไหนทั้งนั้น
  • ล็อกอินครั้งแรกจะถูกบังคับให้เปลี่ยนรหัสทันที
  • ก่อนบอกรหัสมา มันต้องเอาไปลองล็อกอินจริงก่อน และต้องพิสูจน์ว่ารหัสผิดเข้าไม่ได้
รหัสที่ยังไม่เคยเอาไปลอง ไม่ใช่รหัสผ่าน มันคือการเดา ถ้ามันบอกว่า "ทดสอบแล้ว" ลอยๆ ให้ถามกลับว่าทดสอบยังไง ควรตอบได้ว่าลองล็อกอินกี่บัญชี และลองรหัสผิดแล้วโดนปฏิเสธจริง

ระบบใช้อะไรบ้าง

ล็อกไว้ตายตัว ไม่ได้เลือกตามใจ เพราะเป็นชุดเดียวกับที่ทีมพัฒนาใช้จริง นักพัฒนาจะได้ต่อยอดไม่ใช่รื้อทำใหม่

ส่วนใช้อะไร
หน้าบ้านReact 19 · Vite 7 · TypeScript · Tailwind 4 · TanStack Query · React Router
หลังบ้านFastify 5 · Prisma 7 · bcrypt · cookie session
ฐานข้อมูลSQLite ไฟล์เดียว

เลือก SQLite เพราะเป็นไฟล์เดียว สำรองด้วยการคัดลอกไฟล์ ไม่ต้องลงอะไรเพิ่ม และเพราะมี Prisma คั่นไว้ นักพัฒนาเปลี่ยนไปใช้ฐานข้อมูลตัวใหญ่ทีหลังได้โดยไม่ต้องเขียนใหม่

ยังไม่พร้อมรับข้อมูลคนจริง ขั้นนี้รันบนเครื่องคุณเครื่องเดียว คนอื่นเข้าไม่ได้ ยังไม่มีการเข้ารหัสระหว่างทาง ไม่มีระบบสำรองอัตโนมัติ ไม่มีการเฝ้าระวัง และไม่มีบันทึกว่าใครแก้อะไร ถ้าจะเอาไปใช้กับข้อมูลลูกค้าจริง ต้องให้นักพัฒนารัน /security-review ก่อน
ขั้นที่ 3 — ทางเลือก ข

/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

ทำงานยังไง

01

ถามเรื่องสินค้า 2 รอบสั้นๆ

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

คำถามที่ลูกค้าถามบ่อยสำคัญที่สุด เพราะมันกลายเป็นหัวข้อคำถามพบบ่อยที่เขียนด้วยคำของลูกค้าเอง

02

เขียนข้อความให้อ่านก่อน ยังไม่ทำหน้า

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

ผ่านแล้วเก็บไว้ที่ COPY.md ครั้งหน้าจะแก้ก็เริ่มจากคำ ไม่ต้องไปงมในโค้ด

03

สร้างหน้า แล้วเปิดดูจริง

ดู 375 ก่อน แล้วค่อย 1280 กลับด้านกับหน้าจอในระบบ เพราะคนส่วนใหญ่กดมาจากลิงก์ในไลน์

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

เส้นที่มันจะไม่ข้ามให้

ไม่แต่งรีวิว ไม่แต่งตัวเลข ไม่สร้างรูปสินค้า

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

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

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

เรื่องปุ่มทักไลน์

  • ปุ่มเดียว ข้อความเดียวกัน อย่างน้อย 3 จุด — ตอนต้น กลางหน้าหลังหลักฐาน และตอนจบ
  • ใส่ข้อความตั้งต้นให้เลย เช่น "สนใจ {ชื่อสินค้า} ครับ" คนกดแล้วเจอห้องแชทว่างมักไม่พิมพ์อะไรแล้วหายไป
  • บอกว่ากดแล้วเกิดอะไร เช่น "ตอบกลับภายในเวลาทำการ" ใต้ปุ่ม ลดความลังเล
  • ปุ่มบอกผล ไม่ใช่บอกวิธี — "ทักไลน์สอบถาม" ดีกว่า "ติดต่อเรา" ดีกว่า "คลิกที่นี่"
ถ้าต้องเก็บข้อมูลคนที่สนใจ เช่น เก็บชื่อเบอร์ หรือรับเงินผ่านหน้าเว็บ อันนั้นข้ามเส้นไปเป็นงานหลังบ้านแล้ว ต้องใช้ /app-send ส่งให้นักพัฒนา
อ้างอิง

ตัวอย่างเต็มเรื่อง — ระบบนัดคนไข้

จากประโยคเดียว ถึงซองงานที่ส่งนักพัฒนาได้ ภายในวันเดียว

01

คุย

/app-brief ถาม 6 คำถาม ได้ BRIEF.md

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

02

ระดับ 1 — โครงเทา

ได้ 2 หน้าจอ คือ "ตารางนัดวันนี้" กับ "บันทึกนัดใหม่" ปุ่มยังกดไม่ได้

ตรวจแล้วขาดหน้า "ค้นหาคนไข้" บอกให้เพิ่ม แล้วค่อยบอกว่าผ่าน

03

ระดับ 2 — กดได้ ใส่สี

ตอบคำถามแบรนด์ครั้งเดียว ได้ทั้งชื่อระบบและทิศทางสี

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

04

ระดับ 3 — ข้อมูลแยกไฟล์

นัด 24 รายย้ายไป data/mock-data.json มากพอจนต้องแบ่งหน้า ซึ่งเป็นเรื่องที่ไม่มีตอนระดับ 1

ลองใส่ ?demo=empty ท้าย URL เพื่อดูว่าตอนไม่มีข้อมูลเลยหน้าตาเป็นยังไง

05

ระดับ 4 — ทดสอบจริง

เดินใช้งานครบทุกหน้า ถ่ายภาพทั้งมือถือและคอม ไล่เทียบเกณฑ์ใน BRIEF.md ทีละข้อ

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

06

ส่ง

/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 ใช้ตัดสินว่าจะหยิบคำสั่งไหน ต้องเขียนให้ครอบคลุมคำที่คนพูดจริง
  • ต้องทำงานได้แม้ในแชทเว็บที่ไม่มีเครื่องมืออะไรเลย ส่วนที่ต้องใช้เครื่องมือให้แยกไว้ท้ายไฟล์
  • เนื้อคำสั่งเขียนเป็นอังกฤษ แต่บังคับให้ตอบผู้ใช้เป็นไทย
  • เพดานจำนวนคำถามไม่ใช่โควตา ต้องเขียนให้ชัดว่าค่าเริ่มต้นคือไม่ถามเลย