ผมไปอ่านบทความของ Jaroslaw Wasowski เรื่อง How to write specs for AI แล้วรู้สึกว่าตรงกับสิ่งที่ผมทำอยู่ แต่ก็มีบางข้อน่าสนใจที่ผมต้องปรับเพิ่ม โดยเขาพูดตรงๆ ว่า หลายครั้งปัญหาไม่ได้อยู่ที่ model อย่างเดียว แต่อยู่ที่ spec ที่เราเขียนให้มันต่างหาก

เพราะ AI ไม่ได้อ่านใจเราออก ดังนั้นถ้าเราเขียน requirement แบบคลุมเครือ มันก็ไม่ได้หยุดแล้วถามเหมือน senior developer ที่นั่งข้างๆ แต่มันจะเดาต่อจาก pattern ที่มันเคยเห็นมาใน training data แล้วบางทีเดาได้เนียนมาก เนียนจนสรุปออกมา หรือ code ดูเหมือนจะถูกต้อง แต่การใช้งานผิด (เป็นเหตุผลว่าผมต้องมี skill ให้มันตั้งคำถามผมไปเรื่อยๆ นอกจากช่วยคิดแล้ว ผมใช้เพื่อคอยเช็กความเข้าใจของมัน)

หมายเหตุ: บทความนี้อ้างอิงจากประสบการณ์ฟิวส์กับเอเจ้นชมพู เพื่อเรียบเรียงและแปลจากต้นฉบับของ Jaroslaw Wasowski เรื่อง How to write specs for AI: 7 rules and a checklist for better code

ปัญหาไม่ใช่แค่ AI เขียนโค้ดผิด แต่คือมันไม่รู้ว่าอะไรห้ามเดา

ตั้งแต่ปีก่อนที่ vibe code มาใหม่ๆ จนถึงปัจจุบัน เรามักใส่ความต้องการของเราว่าอยากได้อะไร แต่ไม่ได้ใส่ว่ามันห้ามทำอะไร

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

สิ่งที่ไม่อยู่ spec เราในตอนแรก แต่จู่ๆ มันก็โผล่มา เพราะ AI จะเอา pattern จาก training data มาเติมแทนเจตนาของเรา (ซึ่งอาจจะผิด)

นี่แหละครับที่น่ากลัว เพราะ code ที่ออกมาอาจ compile ผ่าน, test ผ่าน หน้าตาดูดี แต่จริงๆ มันกำลังทำระบบที่มีการใช้งานหรือ behavior คนละแบบกับที่เราต้องการ

เหมือนเราจ้างช่างมาทำบ้าน แล้วบอกแค่ว่า “ทำครัวให้ดีๆ หน่อย” ถ้าช่างทำครัวสวยมาก แต่ไม่มีปลั๊ก ไม่มีที่วางเตา หรือเปิดประตูตู้แล้วชนผนัง ปัญหาไม่ได้อยู่ที่ช่างไม่ขยันอย่างเดียว แต่อยู่ที่แบบบ้านของเราก็ไม่ได้บอกอะไรเขาเลย (อยากได้ครัวฝรั่งเตาไฟฟ้า แต่เอไอตั้งเตาอั่งโล่มาให้เพราะสเปกบอกว่ามีเตา 555)

Spec ที่ดีต้องปิด 5 เรื่อง ที่ AI ชอบเดาเอง

บทความนี้สรุป 5 เรื่องหลักๆ ซึ่งผมว่าตรงนี้เอาไปใช้กับ Jira ticket, GitHub/GitLab issue, Markdown spec หรือ prompt ตรงๆ ได้เลย

1. Outcome ต้องชัดว่าอยากได้พฤติกรรมอะไร

เริ่มจากบอกผลลัพธ์ที่ต้องการ ไม่ใช่บอกให้มันไปเขียน code แบบกว้างๆ เช่น แทนที่จะบอกว่า “ทำ endpoint export users เป็น CSV” ให้บอกว่า “endpoint นี้ต้องคืน active users เป็นไฟล์ CSV ที่ download ได้” และต้องมีเงื่อนไขความสำเร็จอะไรบ้าง (ภาษาเทคนิคจะเรียกว่า Acceptance Criteria)

จุดนี้ช่วยแยก what ออกจาก how ได้ดีมาก เพราะ AI จะได้ไม่รีบเลือก implementation pattern ที่มันคุ้น แต่เริ่มจาก behavior ที่เราต้องการก่อน

2. Scope กับ non-goals ต้องเขียนคู่กัน

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

เช่น ถ้าให้ AI ทำ export users ก็ควรบอกไปเลยว่า export เฉพาะ active users เท่านั้น ไม่ export deleted accounts ไม่ export billing data และไม่แก้ database schema

เพราะถ้าไม่บอก มันอาจ “ใจดี” เพิ่ม feature ให้เอง ซึ่งฟังดูดี แต่ทำให้ diff บวม และบางทีไปแตะของที่ไม่ควรแตะ

จากประสบการณ์ผมเองที่สังเกต โมเดลฉลาดๆ อย่าง Claude Opus 4.8+ / ChatGPT 5.5+ มักจะบอกเลยว่า ผมจะทำสิ่งนี้ แต่ไม่ทำสิ่งนี้เพราะจะกระทบอะไรก็ว่าไป ซึ่งมันไม่เป็นกับบางโมเดลอื่นๆ ตรงนี้เราโดนพวก Frontier Model สปอยจนมองข้ามไป ฮ่าๆ

3. Constraints คือรั้วกัน AI หลุดโลก

AI ไม่ได้รู้จัดโค้ดทั้ง repo ของเราจริงๆ ถ้าเราไม่ได้ให้ context มันแต่แรก, มันไม่รู้ว่าใช้ framework เวอร์ชันไหน มี convention อะไร library ไหนห้ามใช้ response format ต้องเป็นแบบไหน หรือ performance limit คือเท่าไร (แต่ก็ได้ยินบ่อยจากคนรอบข้าง (ระดับมหาราชา/มหาราชินี) คือให้ AI อ่านโค้ดทั้ง repo ก่อนเลย)

ดังนั้น constraints ควรมีของพวกนี้:

• stack และ version ที่ใช้
• repo convention ที่ต้องตาม
• library ที่ใช้ได้หรือห้ามใช้
• output format เช่น UTF-8, JSON shape, CSV delimiter
• security หรือ performance limit
• integration boundary เช่นห้ามแก้ schema หรือห้ามกระทบ API เดิม

คือถ้าไม่มีสิ่งเหล่านี้ เราจะตรวจสอบได้ยากมากว่า AI ทำอะไรไป เพราะไฟล์อาจจะเยอะมาก รวมถึงถ้าต้องแก้ บางเรื่องอาจต้องรื้อทั้งโครงสร้างเลย เสียเวลา เสียโทเค็นไปเปล่าๆ

4. Acceptance criteria ต้องพิสูจน์ได้ ไม่ใช่แค่ฟังดูดี

คำว่า “ใช้งานได้ดี” หรือ “make it work nicely” เป็นประโยคที่น่ากลัวมากสำหรับ AI เพราะมันไม่มีทางรู้ว่า nicely ของเราคืออะไร ดังนั้นเราต้องบอกมันว่า เงื่อนไขการรับงาน (Acceptance criteria) ของเราคืออะไร

ซึ่ง Acceptance criteria ที่ดีควรเป็นแบบตรวจสอบได้ เช่น:

• ถ้ามี active users 3 คน ต้องได้ CSV 3 data rows และ header 1 แถว
• ถ้าไม่มี users ต้องได้ header อย่างเดียวและ status 200
• ถ้า user ไม่มี admin role ต้องได้ 403 และไม่ส่ง CSV body
• ถ้ามีข้อมูล 50,000 records ต้องใช้ streaming และ response ไม่เกินเวลาที่กำหนด

ถ้าไม่มีเกณฑ์ตรวจสอบได้ (ไม่ว่าจะมนุษย์ไม่เขียน หรือเอไอไม่ทำให้) ยังถือว่าเป็น Draft Requirement ไม่ใช่ Requirement จริง

เพราะการที่ Spec มี acceptance criteria มันจะเปลี่ยนจากคำอธิบายสวยๆ ให้กลายเป็น Goal ที่ AI ทำให้สำเร็จ และระบบเราจะใช้งานได้ตามที่ต้องการ

5. Edge case กับ failure path ต้องมีตั้งแต่ก่อนเขียน code

Happy path เป็นแค่ส่วนหนึ่งของ production เท่านั้น แต่ spec จำนวนมากเขียนเหมือนโลกมีแต่ happy path ฮาาา

อย่างน้อย spec ที่ส่งให้ AI ควรมี:

• error path 1 กรณี
• edge case 1 กรณี
• empty state หรือ permission case 1 กรณี

เพราะถ้าเราไม่เขียน มันจะเดาวิธี handle error จาก pattern ที่มันเห็นบ่อย ซึ่งอาจไม่ตรงกับระบบเราเลย

Checklist ก่อนโยนงานให้ AI coding agent

ผมลองเอาแนวคิดในบทความมาจัดเป็น checklist table แบบที่น่าจะใช้จริงกับงานประจำวันได้ประมาณนี้ครับ

checklist นี้ไม่ได้บอกให้เขียน spec ยาวเสมอไป แต่มันบอกให้ AI เขียน spec แบบเดาน้อยลง

Spec ไม่ได้ต้องยาว แต่ต้องมี signal พอ

บทความต้นฉบับใช้คำว่า signal redundancy matched to complexity ซึ่งผมแปลแบบบ้านๆ ว่า รายละเอียดต้องพอดีกับความเสี่ยงของงาน

ถ้าแค่แก้ margin หรือเปลี่ยน text เล็กๆ จะเขียน spec ยาว 3 หน้า ก็อาจเกินไป แต่ถ้างานแตะ authorization, payment, data integrity, migration, report export หรือ performance ตรงนี้ผมว่าไม่ควรประหยัด spec

เพราะงานพวกนี้ถ้าพลาด ไม่ใช่แค่ UI เพี้ยน แต่มันอาจกระทบข้อมูล สิทธิ์ผู้ใช้ หรือ logic สำคัญของระบบ

Workflow ที่ผมคิดว่าเอาไปใช้ได้ทันที

ถ้าจะเอาเรื่องนี้ไปใช้กับทีม software จริงๆ ผมคิดว่าไม่ต้องเริ่มจาก process ใหญ่โต แต่เริ่มจากงานหนึ่งชิ้นก่อนก็พอ

1. เลือก feature หรือ change ที่มีขอบเขตงานและโค้ดชัดเจน (boundary)
2. เขียน spec ให้มี 5 เรื่องหลัก: outcome, scope, constraints, acceptance criteria, edge cases
3. review spec ก่อนให้ AI ลงมือ
4. ให้ AI implement พร้อม test
5. ถ้า test fail หรือ reviewer ต้องถามเพิ่ม ให้กลับไปแก้ spec ก่อน ไม่ใช่แค่สั่ง AI แก้ code ไปเรื่อยๆ

จุดนี้ผมว่ามันต่อกับแนวคิด Spec-Driven Development มาก คือ spec ไม่ใช่เอกสารประกอบงาน แต่เป็น contract ของงาน ถ้า code กับ spec ขัดกัน ต้องถามก่อนว่า spec ยังถูกไหม ไม่ใช่ปล่อยให้ code ที่ AI generate มาเป็นความจริงใหม่ของระบบ

ข้อสุดท้ายสำคัญมาก และทำให้ Spec มีการอัพเดทตลอดเวลา (หรือที่เรียกว่า Living documentation)

เรื่องที่ต้องระวัง อย่าเอา checklist ไปทำให้ทีมเหนื่อยกว่าเดิม

ถึงผมจะชอบ checklist นี้มาก แต่ก็ไม่คิดว่าต้องใช้เต็มรูปแบบกับทุกงานนะครับ

ถ้าเป็น bug fix เล็กๆ ที่ test เดียวพิสูจน์ได้ หรือ prototype ที่ตั้งใจ throw away อยู่แล้ว การเขียน spec ยาวอาจไม่คุ้ม

อีกอย่างคือ spec ที่ดีไม่ได้แก้ทุกปัญหา AI ยังพลาดได้จาก model limitation, context retrieval ไม่ครบ, repo ใหญ่เกินไป หรือระบบเดิมซับซ้อนจน spec อธิบายไม่หมด

ดังนั้นอย่าใช้ checklist นี้เป็นพิธีกรรมใหม่ของทีม แต่ใช้เป็นเครื่องมือถามตัวเองว่า “งานนี้มีอะไรที่ AI ไม่ควรเดาเองบ้าง”

สรุปแบบฟิวส์ๆ

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

เมื่อก่อนถ้า requirement คลุมเครือ senior developer อาจถามกลับ หรืออย่างน้อยก็รู้จาก context ของระบบว่าอะไรควรทำไม่ควรทำ แต่ AI coding agent ไม่ทำแบบนั้น ถ้าเราไม่บอก มันจะเดา

และบางครั้งมันเดาแบบมั่นใจมากด้วยว่าจะถูก!

ยิ่ง AI เขียน code เร็วเท่าไร เราก็ยิ่งต้องเขียนให้ชัดขึ้นเท่านั้นครับ

แหล่งอ้างอิง

• How to write specs for AI: 7 rules and a checklist for better code โดย Jaroslaw Wasowski, Level Up Coding

สำหรับโพสต์นี้ เอาใจสาย 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 จะลงมือเขียนโค้ด

ผมชอบตรงที่มันไม่ได้ถามแค่ว่า “อยากได้ 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

ถ้าเอามาแปลงเป็นภาษาคนทำงานจริง ผมจะสรุปแบบนี้ครับ

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