โพสต์ก่อน ผมเขียนถึง คู่มือการเขียน Prompt ที่ดี ให้ได้ผลตรงใจ จากคำแนะนำของ Google ซึ่งเบสิกเลยคือการระบุ Role/Task/Context/Output Format
สำหรับโพสต์นี้ เอาใจสาย Spec Driven Development หน่อย คือผมไปเจออีกวิธีที่น่าสนใจดี ที่ใช้ในการทำ Spec ค่อนข้างละเอียดเลย แต่พอนึกดีๆ แล้ว หลายครั้งผมก็เขียนแบบนี้โดยไม่รู้ตัว
เพราะความไม่ต้องการให้ AI เดาเอง และไม่อยากอารมณ์เสียเมื่อรอมันรันนานแต่ผลลัพธ์ที่ไได้ไม่ตรงใจ ผมจึงมักจะระบุว่าใคร ทำอะไร อย่างไร ที่ไหน เมื่อไร อะไรควรทำ ไม่ควรทำ
ซึ่งเครื่องมือในโพสต์นี้เป็นประมาณนั้นเลยครับ เผื่อใครจะเอาไปเป็นไอเดียเสริมสไตล์การเขียน Prompt/Spec ให้กับผู้อ่านได้
หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและแปลจากต้นฉบับของ Vishal Mysore เรื่อง ZeeSpec- Spec Driven Development for Greenfield vs Brownfield Projects
AI มันไม่กลัว requirement ที่ไม่ชัด แต่มันจะเดาแทนเราเลย
บทความต้นฉบับพูดถึงเครื่องมือชื่อ ZeeSpec ซึ่งเป็นแนวคิดการทำ spec แบบบังคับให้เราตอบคำถามให้ครบก่อนเริ่มให้ AI สร้างระบบ
คำสำคัญของ ZeeSpec คือ มันไม่ได้เป็น documentation เฉยๆ แต่มันเป็น constraint system หรือระบบกรอบข้อจำกัดที่บอก AI ว่าอะไรทำได้ อะไรทำไม่ได้ อะไรห้ามเดา
ถ้าเราไม่ตอบ AI จะตอบแทนเรา และคำตอบนั้นอาจดูดีมากจนเราไม่ทันระวัง
ฟังดูเหมือนเรื่องเล็กนะครับ แต่คนทำ software น่าจะเคยเจออาการนี้กันบ่อยมาก เช่น บอกให้เพิ่ม feature นิดเดียว แต่ AI ดัน refactor service เดิมให้ด้วย หรือบอกให้เพิ่ม field ในตาราง แต่มัน generate migration ที่กระทบข้อมูลเดิมแบบชวนเสียวหลัง
พออ่านบทความนี้แล้วผมนึกถึงการสร้างบ้านเลย ถ้าเราไม่บอกว่าเสาไหนห้ามแตะ ผนังไหนรับน้ำหนัก ท่อประปาเดินตรงไหน ช่างที่ขยันมากอาจทำบ้านใหม่ให้สวยกว่าเดิม แต่พังโครงเดิมไปด้วย
ZeeSpec ใช้ 5W1H มาบีบให้เราคิดครบ
ZeeSpec วางอยู่บนแนวคิด Zachman Framework ซึ่งเป็นกรอบคิดด้าน enterprise architecture และโมเดล 5W1H ที่ประกอบด้วย What, Where, When, Who, Why, How
ในบทความบอกว่า ZeeSpec มีคำถาม 60 ข้อ แบ่งเป็น 6 มิติ มิติละ 10 ข้อ เป้าหมายไม่ได้อยู่ที่การเขียนเอกสารให้ยาว แต่อยู่ที่การบังคับให้ decision สำคัญถูกพูดออกมาก่อน AI จะลงมือเขียนโค้ด
| มิติ | คำถามหลัก | ตัวอย่างสิ่งที่ต้องระบุ |
|---|---|---|
| WHAT | ระบบคืออะไร | entity, state, boundary, สิ่งที่ห้ามมี |
| WHERE | ข้อมูลและการทำงานอยู่ที่ไหน | storage, infrastructure, integration, data flow |
| WHEN | อะไรเกิดขึ้นตอนไหน | trigger, expiry, schedule, blocking condition |
| WHO | ใครทำอะไรได้ | role, permission, ownership, approval |
| WHY | ทำไม rule นี้มีอยู่ | business intent, validation, policy |
| HOW | ระบบทำงานและพังอย่างไร | error handling, recovery, consistency, rollback |
ผมชอบตรงที่มันไม่ได้ถามแค่ว่า “อยากได้ feature อะไร” แต่มันถามด้วยว่า “อะไรห้ามเกิดขึ้น” ซึ่งปกติเราไม่ค่อยเขียนลง requirement กัน ทั้งที่ในโลกจริง สิ่งที่ห้ามเกิดขึ้นนี่สำคัญมาก
Greenfield คือพื้นที่ว่างที่อันตรายกว่าที่คิด
Greenfield project คือโปรเจกต์ที่เริ่มใหม่แทบทั้งหมด ไม่มี schema เดิม ไม่มี API เดิม ไม่มี legacy ให้ต้องเกรงใจ
ข้อดีคือเราออกแบบใหม่ได้เต็มที่ แต่ข้อเสียคือไม่มีอะไรคอยขัด AI เลย ถ้าเรา spec ไม่ครบ มันจะเติมโลกทั้งใบให้เราเอง
Greenfield ไม่ได้เสี่ยงเพราะไม่มีของเดิม แต่มันเสี่ยงเพราะไม่มีแรงต้านเวลา AI เดา
ในบทความเสนอว่า สำหรับ greenfield ต้องตอบให้ครบทุกมิติ โดยเฉพาะคำถามที่คนมักข้าม เช่น
- ระบบนี้ทำอะไร และไม่ทำอะไร
- entity ไหนมีจริง entity ไหนห้ามมี
- ข้อมูลอะไรห้ามเก็บเด็ดขาด เช่น PII, payment data, secret
- ใครเห็นข้อมูลอะไรได้บ้าง
- เมื่อเกิด error ระบบควร fail แบบไหน
- ถ้าเจอข้อมูลไม่ครบ ระบบควรหยุดหรือเดา
ถ้าเขียนแบบนี้ก่อนให้ AI ทำงาน โอกาสที่มันจะสร้าง table ประหลาดๆ หรือ flow ที่ดูสมเหตุสมผลแต่ผิด business rule จะน้อยลงมาก
Brownfield ต้องล็อกของเดิมก่อนค่อยสั่งของใหม่
Brownfield project คือระบบที่มีอยู่แล้ว อาจมี database จริง มี user ใช้งานจริง มี API consumer ภายนอก มี technical debt ที่ทุกคนรู้ว่าไม่สวย แต่แตะมั่วไม่ได้
ตรงนี้บทความให้แนวคิดที่ผมว่าโดนมาก คือ brownfield ไม่ควร spec ทั้งระบบใหม่ แต่ควร spec เฉพาะ delta หรือส่วนที่เปลี่ยน
Greenfield คือเติมทุกมิติ ส่วน brownfield คือ lock สิ่งที่มีอยู่ แล้วระบุเฉพาะสิ่งที่จะเปลี่ยน
นี่เป็นจุดที่หลายทีมพลาด รวมถึงผมเองก็เคยพลาดครับ เวลาใช้ AI กับระบบเดิม เรามักคิดว่าให้ context เยอะๆ แล้วมันจะเข้าใจ แต่ถ้าเราไม่บอกว่า “ห้ามแตะอะไร” มันอาจช่วยเกินหน้าที่
ตัวอย่างง่ายๆ เช่น เราขอเพิ่ม endpoint ใหม่สำหรับ export report แต่ถ้าไม่ได้ lock authentication pattern เดิมไว้ AI อาจ generate middleware แบบใหม่ หรือแก้ permission model ให้ดูสะอาดขึ้น ซึ่งดูดีใน diff แต่พังกับระบบจริง
ก่อน spec ระบบเก่า ต้องป้อน context ของระบบเก่าก่อน
สำหรับ brownfield บทความแนะนำให้เริ่มด้วย Step 0 คือป้อน context ของระบบเดิมก่อนตอบ ZeeSpec
- schema ปัจจุบัน แม้จะเป็น version ย่อก็ยังดีกว่าไม่มี
- API pattern ที่ใช้อยู่ เช่น naming, response shape, error format
- tech stack และ infrastructure ที่เปลี่ยนไม่ได้
- constraint ที่เป็น non-negotiable เช่น ต้องใช้ PostgreSQL 14 หรือห้าม breaking change กับ client เดิม
ผมว่าข้อนี้ practical มาก เพราะ AI ที่ไม่เห็น schema จะออกแบบรอบ schema ไม่ได้ มันจะออกแบบ schema ใหม่ให้เราแทน ซึ่งใน brownfield นี่คือความเจ็บปวดล้วนๆ
วิธีคิดต่างกันระหว่าง greenfield กับ brownfield
ถ้าเอามาแปลงเป็นภาษาคนทำงานจริง ผมจะสรุปแบบนี้ครับ
| เรื่อง | Greenfield | Brownfield |
|---|---|---|
| จุดเริ่มต้น | เริ่มจากศูนย์ | เริ่มจากระบบที่มีข้อจำกัดอยู่แล้ว |
| ความเสี่ยงหลัก | AI invent สิ่งที่เราไม่ได้สั่ง | AI overwrite หรือ refactor สิ่งที่ยังทำงานอยู่ |
| กลยุทธ์ | ตอบให้ครบทุกมิติ | ล็อกของเดิม แล้วระบุเฉพาะ delta |
| สิ่งที่ควรเน้น | domain model, boundary, rule, failure behavior | compatibility, migration, rollback, non-breaking change |
| ประโยคเตือนใจ | อย่าให้ AI เดาโลกใหม่เอง | อย่าให้ AI ทำความสะอาดบ้านจนโยนของสำคัญทิ้ง |
Conflict ใน spec ไม่ใช่ edge case แต่มันคือ bug ตั้งแต่ยังไม่เขียนโค้ด
อีกประเด็นที่ผมชอบคือ เวลาคำตอบใน spec ขัดกัน ZeeSpec ไม่ควรปล่อยผ่าน
เช่น ในมิติ WHO เราบอกว่าเฉพาะ Admin เท่านั้นที่ลบ user ได้ แต่ในมิติ WHEN เราบอกว่า unverified account จะถูกลบอัตโนมัติหลัง 30 วัน แบบนี้มันมี conflict อยู่แล้ว
ถ้าเราไม่ resolve ตอน spec AI อาจ resolve ให้เองแบบเงียบๆ และเราอาจไม่รู้ด้วยว่ามันเลือกทางไหน
Spec ที่ขัดกัน คือ bug ที่ยังไม่ได้ compile
ผมชอบประโยคนี้มาก เพราะมันทำให้เราเปลี่ยนมุมมองจาก “เดี๋ยวค่อยดูตอน implementation” เป็น “ต้องเคลียร์ก่อนให้ AI ลงมือ”
เอาไปใช้กับงานจริงได้ยังไง
ถ้าจะเอาแนวคิดนี้ไปใช้กับทีม software development ผมคิดว่าไม่จำเป็นต้องเริ่มด้วย 60 ข้อแบบเต็มทันที เพราะเดี๋ยวทีมจะรู้สึกว่าเอกสารกลับมาฆ่าเราอีกแล้ว 555
เริ่มแบบเบากว่านั้นก็ได้ เช่น ก่อนให้ AI ทำ feature ใดๆ ให้ตอบ 6 ช่องนี้ให้ได้ก่อน
- WHAT จะเพิ่มหรือเปลี่ยนอะไร และอะไรไม่อยู่ใน scope
- WHERE ต้องแตะ file, service, database, integration ไหนบ้าง และอะไรห้ามแตะ
- WHEN flow ใหม่เกิดตอนไหน กระทบ trigger เดิมไหม
- WHO role ไหนใช้ได้ role ไหนห้ามใช้
- WHY business rule สำคัญคืออะไร ทำไมต้องเป็นแบบนี้
- HOW migration, rollback, error, test ต้องเป็นอย่างไร
สำหรับ greenfield ให้ช่องพวกนี้เป็นการออกแบบระบบ สำหรับ brownfield ให้ช่องพวกนี้เป็นรั้วกัน AI ไม่ให้ไปช่วยแก้สิ่งที่ไม่ควรแก้
Prompt แบบย่อสำหรับ greenfield
อันนี้ผมเรียบเรียงเป็น template สั้นๆ เอาไว้ใช้ได้เลย
System: [ชื่อระบบ]
Assumption: เริ่มใหม่ ไม่มี infrastructure เดิม
WHAT: entity, relationship, boundary, สิ่งที่ห้ามมี, ข้อมูลที่ห้ามเก็บ
WHERE: infrastructure, data flow, integration, system boundary
WHEN: trigger ของ create/update/delete, expiry, blocking condition
WHO: role, permission, visibility, approval
WHY: business rule, intent, validation, เหตุผลของข้อจำกัด
HOW: error handling, recovery, consistency, idempotency, test
Generate a system spec with no unstated assumptions. If information is missing, ask before generating code.Prompt แบบย่อสำหรับ brownfield
ส่วน brownfield ผมจะเน้นคำว่า unchanged และ delta ให้ชัด เพราะนี่คือหัวใจของระบบเดิม
Existing system context: [paste schema / API pattern / tech stack / non-negotiable constraints]
New feature: [ชื่อ feature]
WHAT: delta only, new entity, changed field, สิ่งที่ exclude ชัดเจน
WHERE: existing infrastructure unchanged, list what must not change
WHEN: new trigger, conflict with existing trigger, blocking rule เดิมที่ยังต้องใช้ WHO: permission ใหม่อิง role เดิม, role ที่ห้าม access
WHY: เหตุผลของ feature และเหตุผลที่ constraint เดิมยัง valid
HOW: migration path, backward compatibility, rollback, tests Generate only the delta.
Do not refactor existing components unless explicitly requested.สิ่งที่ผมได้จากบทความนี้
ผมว่าประเด็นของ ZeeSpec ไม่ใช่แค่ “เขียน spec ให้ละเอียดขึ้น” แต่คือ “เปลี่ยนหน้าที่ของ spec”
เมื่อก่อน spec มักเป็นเอกสารอธิบายให้คนอ่าน แต่ในยุค AI coding spec กลายเป็นรั้วกั้นพฤติกรรมของเครื่องมือ ถ้ารั้วหลวม AI ก็เดินออกนอกเขต ถ้ารั้วไม่บอกตำแหน่งท่อ มันก็อาจขุดโดนท่อ
ฟังดูเหมือนกลับไปยุคเขียนเอกสารเยอะๆ แต่ผมว่าไม่ใช่ครับ จุดต่างคือ spec แบบนี้ไม่ได้เขียนเพื่อความสวยงามหรือ compliance อย่างเดียว แต่มันเขียนเพื่อควบคุมสิ่งที่จะถูก generate ออกมาจริง จะได้ไม่ต้องเสียเวลา เสียโทเค็น แล้วได้ผลลัพธ์ผิดๆ แบบที่ทำให้อารมณ์เสีย
และยิ่ง AI เขียนโค้ดได้เร็วขึ้นเท่าไร spec ยิ่งสำคัญขึ้นเท่านั้น
เพราะความเร็วไม่ได้ช่วยอะไร ถ้าเอไอลากเราวิ่งหลงทาง ผ่าม!
แหล่งที่มา
- ZeeSpec- Spec Driven Development for Greenfield vs Brownfield Projects โดย Vishal Mysore
- Spec Driven Development with ZeeSpec : greenfield vs brownfield บน DEV Community
