เขียน Spec ที่ AI เอาไปสร้างได้ | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand
$ cat 05-writing-specs.md บทที่ 5
เขียน Spec ที่ AI เอาไปสร้างได้ แก่นของบทนี้
ไอเดียที่ดีไม่พอสำหรับให้ AI สร้าง software
คุณต้องแปลงไอเดียให้เป็น spec
Spec คือเอกสารสั้น ๆ ที่บอกว่า:
เราจะสร้างอะไร สร้างให้ใคร version แรกทำอะไรได้บ้าง อะไรยังไม่ทำ user ต้องไหลจากจุดไหนไปจุดไหน เสร็จแล้วต้องตรวจยังไง คัดลอก สำหรับ non-coder spec ไม่ต้องเป็นเอกสารหนา ๆ แบบบริษัทใหญ่
แต่ต้องชัดพอให้ Claude Code ไม่ต้องเดาเรื่องสำคัญ
ถ้า CLAUDE.md คือ context ระยะยาวของ project
ทำไม “ช่วยทำแอปให้หน่อย” ถึงไม่พอ
Spec ที่ดีช่วยให้ AI ไม่ต้องเดา เมื่อ spec ตัดสินใจเรื่องสำคัญแล้ว AI จะเดาน้อยลง และคุณตรวจงานง่ายขึ้น
คำสั่งแบบนี้กว้างเกินไป:
ช่วยทำเว็บจองคิวให้หน่อย คัดลอก Claude Code อาจต้องเดาหลายเรื่อง:
จองคิวอะไร
ใครเป็นคนจอง
ต้อง login ไหม
ต้องมี admin ไหม
ต้องส่ง email ไหม
ต้องกันเวลาซ้ำไหม
ต้องรับเงินไหม
ต้องเก็บข้อมูลอะไร
ใช้ database อะไร
เสร็จแปลว่าอะไร
คัดลอก
ยิ่ง AI เดามาก คุณยิ่งเสีย control มาก
Spec ทำให้คำถามพวกนี้ถูกตอบก่อนเริ่ม build
ไม่ใช่ตอบทีหลังตอน project พังหรือบวมเกินไป
Spec ที่ดีต้องสั้นและตัดสินใจได้ Anatomy ของ spec ที่ AI เอาไป build ได้ spec ที่ดีไม่ต้องยาว แต่ควรมี goal, user, scope, out of scope, flow, data, acceptance และ risks
Spec สำหรับเล่มนี้ควรยาวประมาณ 1–3 หน้า
ไม่ต้องเขียนทุกอย่างในหัว
Spec ที่ดีควรตอบ 7 เรื่อง:
Goal — ทำไปเพื่ออะไร
User — ใครใช้
Scope — version แรกมีอะไร
Non-goals — อะไรยังไม่ทำ
User flow — user เดินทางยังไง
Data — ต้องเก็บ/แสดงข้อมูลอะไร
Acceptance criteria — แบบไหนเรียกว่าเสร็จ
ถ้าขาด acceptance criteria Claude อาจสร้างของที่ “ดูเสร็จ” แต่คุณตรวจไม่ได้
Claude Code best practices เน้นเรื่องการให้ verification หรือ success criteria เพราะถ้าไม่มี criteria ที่ชัด งานอาจดูถูกแต่ใช้งานจริงไม่ได้
ถ้าคุณบอกไม่ได้ว่าเสร็จคืออะไร AI ก็เดาแทนคุณว่าเสร็จคืออะไร
Template Spec สำหรับ non-coder ใช้ template นี้ได้เกือบทุก project
# Spec: [ชื่อ feature/project] ## 1. Goal เราต้องการสร้าง [ สิ่งที่จะสร้าง ] เพื่อ [ ผลลัพธ์ที่ต้องการ ] ## 2. Target user ผู้ใช้หลักคือ [ ใคร ] เขามีปัญหา/ความต้องการคือ [ อะไร ] ## 3. Version 1 scope Version แรกต้องมี: - [feature 1] - [feature 2] - [feature 3] ## 4. Out of scope ยังไม่ทำใน version แรก: - [ สิ่งที่ยังไม่ทำ ] - [ สิ่งที่ยังไม่ทำ ] ## 5. User flow 1. User เข้าไปที่ [ หน้า/จุดเริ่ม ] 2. User เห็น [ ข้อมูล/CTA ] 3. User ทำ [ action ] 4. ระบบแสดง [ ผลลัพธ์ ] ## 6. Data ต้องเก็บ/ใช้ข้อมูล: - [field 1] - [field 2] ข้อมูลที่ไม่ควรเก็บ: - [field ที่เสี่ยง/ไม่จำเป็น] ## 7. Acceptance criteria งานนี้ถือว่าเสร็จเมื่อ: - [เงื่อนไขตรวจได้ 1] - [เงื่อนไขตรวจได้ 2] - [เงื่อนไขตรวจได้ 3] ## 8. Risks / questions - [ ความเสี่ยงหรือคำถามที่ยังไม่แน่ใจ ] คัดลอก ถ้า project ยังเล็กมาก ใช้แค่หัวข้อ 1–7 ก็พอ
อย่าใช้ spec เพื่อทำให้ project ดูใหญ่
ใช้ spec เพื่อทำให้ project เล็กและชัด
ตัวอย่าง: จากไอเดียกว้าง ๆ เป็น spec อยากทำเว็บเก็บ lead สำหรับบริการ consult AI คัดลอก # Spec: AI Workflow Audit Landing Page ## 1. Goal สร้าง landing page สำหรับบริการ AI Workflow Audit เพื่อให้เจ้าของธุรกิจกรอกฟอร์มนัด consult 30 นาที ## 2. Target user เจ้าของธุรกิจ SME ที่อยากใช้ AI ลดงานซ้ำ แต่ไม่รู้จะเริ่มจากตรงไหน ## 3. Version 1 scope Version แรกต้องมี: - Hero section อธิบายบริการแบบสั้น - Benefits 3 ข้อ - Process 3 ขั้นตอน - FAQ 4 ข้อ - Contact/waitlist form - Thank you message หลังส่งฟอร์ม ## 4. Out of scope ยังไม่ทำ: - Login - Payment - Calendar booking integration - CRM integration - Admin dashboard ## 5. User flow 1. User เปิด landing page 2. อ่านว่า service ช่วยอะไร 3. กด CTA หรือเลื่อนไปที่ form 4. กรอกชื่อ อีเมล บริษัท และปัญหาที่อยากแก้ 5. กด submit 6. เห็น thank you message ## 6. Data ต้องเก็บ: - name - email - company - main_problem ไม่เก็บ: - phone number - payment information - sensitive business documents ## 7. Acceptance criteria งานนี้ถือว่าเสร็จเมื่อ: - หน้าเว็บเปิดได้บน desktop และ mobile - CTA พาไปที่ form ได้ - Form validate email เบื้องต้น - Submit แล้วแสดง thank you message - ไม่มี login/payment/database dashboard ใน version แรก - Claude สรุปไฟล์ที่แก้และ manual test steps ให้ตรวจ คัดลอก แต่ชัดพอให้ Claude Code ไม่สร้างเกินจำเป็น
Out of scope สำคัญมาก มือใหม่มักเขียนแต่สิ่งที่อยากได้
แต่ไม่เขียนสิ่งที่ยังไม่ทำ
เช่น คุณขอ waitlist form แล้ว AI อาจเพิ่ม:
login admin dashboard email automation analytics payment role permission คัดลอก บางอย่างอาจดูดี แต่ทำให้ project บวม
- No login in version 1 - No payment in version 1 - No admin dashboard in version 1 - No new third-party services unless approved - No database schema changes without asking คัดลอก การบอกว่า “ยังไม่ทำอะไร” สำคัญพอ ๆ กับการบอกว่า “จะทำอะไร”
Acceptance criteria ต้องตรวจได้ Acceptance criteria ต้อง test ได้จริง acceptance criteria ที่ดีต้องเปลี่ยนเป็น checklist ที่คนอ่านกด test เองได้
Acceptance criteria คือเงื่อนไขว่า “งานนี้เสร็จแล้วจริง”
เว็บต้องดูดี ฟอร์มต้องใช้ง่าย ระบบต้องเร็ว คัดลอก หน้าแรกโหลดได้โดยไม่มี error CTA button scroll ไปที่ form ถ้า email ไม่มี @ ให้แสดง error ถ้าส่งฟอร์มสำเร็จ ให้แสดง thank you message บนมือถือ form ไม่ล้นจอ Claude ต้องรัน build หรือบอกเหตุผลว่าทำไมรันไม่ได้ คัดลอก Acceptance criteria ที่ดีมี 3 ลักษณะ:
ตรวจได้
ไม่คลุมเครือ
ผูกกับ user flow จริง
ถ้าคุณเขียน criteria ดี Claude Code จะช่วย test และ verify งานได้ดีขึ้น
Edge case คืออะไร Edge case คือกรณีที่ไม่ใช่ flow ปกติ แต่เกิดขึ้นได้
กรอกข้อมูลครบ → กด submit → สำเร็จ คัดลอก ไม่กรอก email email ผิดรูปแบบ กด submit ซ้ำ เน็ตหลุด database error ข้อความยาวเกินไป เปิดบนมือถือจอเล็ก คัดลอก non-coder ไม่ต้องคิด edge case ครบทุกอย่าง
แต่ควรถาม Claude ให้ช่วยคิดก่อน build:
จาก spec นี้ ช่วย list edge cases ที่ควรตรวจสำหรับ version แรก แยกเป็น required, optional, และยังไม่ต้องทำ คัดลอก คำว่า “ยังไม่ต้องทำ” สำคัญ
เพราะ edge case มีไม่สิ้นสุด
เราแค่ต้องเลือกสิ่งที่เหมาะกับ version แรก
ให้ Claude interview คุณก่อนเขียน spec ถ้าคุณยังอธิบาย project ไม่ชัด อย่าเริ่ม build
ฉันอยากสร้าง [ไอเดีย] แต่ยังอธิบายไม่ชัด ช่วย interview ฉันทีละคำถามเพื่อทำ spec สำหรับ version แรก กติกา: - ถามทีละ 1–3 คำถาม - ใช้ภาษาที่ non-coder เข้าใจ - ช่วยลด scope ไม่ใช่เพิ่ม scope - ถ้ามีคำตอบที่เสี่ยง ให้เตือน - เมื่อข้อมูลพอแล้ว สรุปเป็น spec 1–3 หน้า คัดลอก วิธีนี้ดีมากสำหรับ non-coder
เพราะคุณไม่ต้องรู้ตั้งแต่แรกว่าต้องเขียน spec ยังไง
ให้ Claude ช่วยถาม แต่คุณยังเป็นคนตัดสินใจ
Prompt: ให้ Claude แปลงไอเดียเป็น spec ใช้ prompt นี้เมื่อคุณมีไอเดียแล้ว
ช่วยแปลงไอเดียนี้เป็น spec สำหรับ Claude Code ไอเดีย: [อธิบายไอเดีย] บริบท: - target user: - goal: - deadline: - ข้อมูลที่อาจต้องเก็บ: - สิ่งที่กังวล: กติกา: - ทำ version แรกให้เล็กที่สุดแต่ยังมีประโยชน์ - แยก scope กับ out of scope ให้ชัด - ห้ามใส่ login/payment/admin dashboard ถ้าไม่จำเป็น - ถ้ามีเรื่อง data/security/payment ให้ใส่ใน risk section - ใช้ภาษาที่ non-coder เข้าใจ Output: 1. Goal 2. Target user 3. Version 1 scope 4. Out of scope 5. User flow 6. Data fields 7. Acceptance criteria 8. Edge cases 9. Questions before build คัดลอก หลังได้ spec แล้ว ให้ถามต่อ:
ช่วย critique spec นี้ มีอะไรยังคลุมเครือ เกิน scope หรือเสี่ยงเกินไปสำหรับ version แรกไหม คัดลอก อย่าให้ AI เขียน spec แล้ว build ต่อทันที
Prompt: ให้ Claude วางแผนจาก spec โดยยังไม่แก้ไฟล์ เมื่อ spec พร้อมแล้ว ค่อยให้ Claude ดู project
นี่คือ spec สำหรับงานนี้: [paste spec] ช่วยอ่าน project นี้และเสนอ implementation plan กติกา: - อย่าเพิ่งแก้ไฟล์ - บอกว่าไฟล์ไหนน่าจะต้องแก้ - บอกว่ามีอะไรใน spec ที่ยังไม่ชัด - บอก risk ที่ควรระวัง - บอก manual test steps หลังทำเสร็จ - ถ้า scope ใหญ่เกินไป ให้เสนอ version ที่เล็กกว่า คัดลอก นี่คือจังหวะที่ใช้ Plan mode ได้ดีมาก
เพราะคุณให้ Claude เชื่อม spec กับ codebase จริงก่อนลงมือ
Checklist: Spec พร้อม build หรือยัง ก่อนให้ Claude Code แก้ไฟล์ ให้เช็ก 12 ข้อนี้
ถ้าติ๊กไม่ครบ โดยเฉพาะ scope/out of scope/acceptance criteria ให้กลับไปแก้ spec ก่อน
สิ่งที่ควรเก็บเป็นไฟล์ สำหรับงานที่ใหญ่กว่า 1 prompt ให้เก็บ spec เป็นไฟล์
docs/spec-waitlist-v1.md คัดลอก
กลับมาอ่านซ้ำได้
ให้ Claude อ้างอิงได้
review ก่อน build ได้
ใช้เป็น checklist ตอน test ได้
ส่งให้ developer ช่วยดูได้
ถ้า spec อยู่แค่ใน chat พอ session ยาวขึ้น context อาจรก
ไฟล์ spec ทำให้ project เป็นระบบกว่า
สรุป Spec คือสะพานระหว่างไอเดียกับการลงมือ build
สำหรับ non-coder spec ไม่ต้องยาว แต่ต้องตัดสินใจแทน AI ในเรื่องสำคัญ
อย่าเริ่มจาก “ทำแอปให้หน่อย”
เขียน scope และ out of scope เสมอ
Acceptance criteria ต้องตรวจได้
ให้ Claude interview คุณได้ แต่คุณต้องตัดสินใจ
ให้ Claude วางแผนจาก spec ก่อนแก้ไฟล์
บทต่อไป เราจะใช้ spec แบบนี้ไปสร้าง project แรก: landing page ที่ publish ได้ โดยยังคุม scope ให้เล็กและตรวจเองได้
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย