โดย Nokka (นก-กา) | ตอนที่ 1 ของซีรีส์เปรียบเทียบเครื่องมือ SDD | ตรวจข้อมูล 24 ต.ค. 2026
บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)
ปัญหาที่ทำให้เกิด spec-driven development
ถ้าคุณเคยปล่อยให้ AI เขียนโค้ดจากประโยคเดียว คุณจะเจอเรื่องเดิมสามอย่าง
- มันเดาสิ่งที่คุณไม่ได้บอก แล้วเดาผิดในจุดที่คุณไม่ทันดู
- งานที่ควรใช้สองชั่วโมงกลายเป็นสองวัน เพราะต้องวนแก้สิ่งที่มันเข้าใจผิด
- พอผ่านไปหนึ่งสัปดาห์ ไม่มีใครจำได้ว่าตอนนั้นตกลงอะไรไว้
spec-driven development หรือ SDD เกิดจากคำตอบง่าย ๆ ข้อเดียว นั่นคือ เขียนสิ่งที่ต้องการให้ชัดก่อน แล้วให้ agent ทำงานจากเอกสารนั้น ไม่ใช่จากความจำของบทสนทนา
ฟังดูไม่ใหม่ เพราะวิศวกรรมซอฟต์แวร์พูดเรื่องนี้มาสี่สิบปี สิ่งที่ใหม่คือตอนนี้คนอ่าน spec ไม่ใช่แค่มนุษย์ แต่เป็น agent ที่อ่านแล้วลงมือทันที
นิยามที่ผมจะใช้ในซีรีส์นี้
ข้อกำหนดหน้าตาเป็นอย่างไร
SDD คือกระบวนการที่ทำให้ ข้อกำหนดที่เขียนไว้ เป็นสัญญาที่ทั้งคนและ agent ใช้ร่วมกัน โดยมีลักษณะสามข้อ
- ข้อกำหนดเป็นไฟล์ที่อยู่ใน version control ไม่ใช่ข้อความในแชท
- มนุษย์ตรวจและอนุมัติข้อกำหนดก่อนที่โค้ดจะถูกเขียน
- งานทุกขั้นอ้างกลับมาที่ข้อกำหนดได้ ว่าโค้ดบรรทัดนี้มาจากข้อไหน
ข้อสามคือข้อที่แยก SDD ออกจาก "การเขียน plan ก่อนลงมือ" ธรรมดา เพราะถ้าอ้างกลับไม่ได้ spec ก็เป็นแค่บันทึกความจำที่เน่าตามเวลา
ตัวอย่างข้อกำหนดที่ agent อ่านแล้วทำงานได้
## ADDED Requirements
### Requirement: Theme selection
The app SHALL let users switch between light and dark themes,
defaulting to the system preference.
#### Scenario: User toggles dark mode
- **WHEN** the user clicks the theme toggle
- **THEN** the app switches to dark mode and persists the choice
ตัวอย่างนี้มาจาก OpenSpec [4] และแสดงจุดสำคัญว่า ข้อกำหนดหนึ่งข้อมีทั้งสิ่งที่ต้องเป็นจริงและสถานการณ์ที่ใช้ตรวจได้
สองแกนที่ต้องแยก: ระดับวุฒิภาวะ และกลุ่มเครื่องมือ
ถ้าลองอ่านเอกสารของเครื่องมือ SDD หลายตัวติดกัน คุณจะสับสน เพราะแต่ละตัวเรียกคำเดียวกันว่าคนละเรื่อง
เว็บที่ไล่เก็บข้อมูลเครื่องมือกลุ่มนี้อย่างเป็นระบบอธิบายว่า ความต่างที่แท้จริงอยู่ที่ ความสัมพันธ์ระหว่าง spec กับข้อตรวจ (verification) ไม่ใช่จำนวนฟีเจอร์ [1]
เขาแบ่งความสัมพันธ์ระหว่าง spec กับข้อตรวจไว้สามแบบ [1] ส่วนชื่อสามระดับที่พบได้บ่อยในวง SDD คือ spec-first, spec-anchored และ spec-as-source ซึ่งมาจากการจัดอนุกรมวิธานของชุมชนอีกชุดหนึ่ง [6]
- spec-first คือ spec นำการลงมือ แต่หลังส่งมอบมักไม่มีใครดูแลต่อ [6]
- spec-anchored คือ spec ยังอยู่หลังส่งมอบ และถูกกระทบยอดกับโค้ดเมื่อทั้งคู่ต่างกัน [6]
- spec-as-source คือ spec เป็นต้นทางจริง และโค้ดถูกสร้างหรือตรวจจากมัน [6]
สามคำนี้ฟังคล้ายกันแต่ผลต่างกันมาก
บทนี้จะใช้สองแกนนี้ตลอดซีรีส์ แกนแรกคือระดับวุฒิภาวะที่บอกว่า spec ถูกใช้ตรวจแค่ไหน แกนที่สองคือกลุ่มเครื่องมือที่บอกว่ามันเสียบเข้ากับงานเราอย่างไร (CLI, IDE หรือ framework) ตอนที่ 2 ถึง 4 จะไล่ตามแกนที่สอง และตัดสินแต่ละตัวด้วยแกนแรกบวกเกณฑ์อีกหกข้อ
สามระดับวุฒิภาวะ
ทั้งสามแบบไม่ใช่ลำดับที่ต้องไล่ขึ้นทีละขั้น แต่เป็นคำตอบต่างกันต่อคำถามว่า "ใครเป็นคนตัดสินว่าโค้ดถูกต้อง" คือคนอ่าน spec, คนตรวจกับ spec หรือเครื่องตรวจจาก spec [6]
ระดับที่หนึ่ง: spec นำแล้วจบ
โมเดลนี้ทำงานแบบนี้
- เขียนข้อกำหนด
- แตกเป็นแผนและงาน
- ลงมือ
- ส่งมอบ แล้วเก็บ spec ไว้เป็นเอกสารประกอบ
ข้อดีคือเข้าใจง่ายและเริ่มได้เร็ว ข้อเสียคือเมื่อเวลาผ่านไป spec กับโค้ดจะแยกจากกัน และไม่มีกลไกไหนบอกคุณว่าแยกเมื่อไร
ลองนึกภาพสถานการณ์ที่พบบ่อย: spec เขียนไว้ว่าฟีเจอร์หนึ่งรับผู้ใช้ไม่เกินห้าร้อยคนต่อนาที ต่อมาทีมเปลี่ยนไปใช้คิวเพราะรับโหลดได้มากกว่า แต่ไม่มีใครกลับไปแก้ spec เพราะไม่มีอะไรเตือนให้ทำ ผ่านไปสามเดือน ตัวเลขใน spec จึงไม่ตรงกับของจริง และคนที่อ่านต่อก็เข้าใจผิด
ระดับที่สอง: spec ถูกกระทบยอดกับโค้ด
ระดับนี้เพิ่มขั้นตอนที่ทำให้ spec ไม่ตาย คือมีจังหวะที่ระบบหรือคนเอา spec มาเทียบกับสิ่งที่สร้างจริง แล้วตัดสินว่าจะแก้อะไร
เครื่องมือกลุ่มนี้มักทำผ่านสิ่งที่เรียกว่า change proposal คือแยก "ข้อเสนอการเปลี่ยนแปลง" ออกจาก "spec ที่รับแล้ว" เมื่อข้อเสนอผ่านและโค้ดเสร็จจึงย้ายเข้า spec หลัก
ผลคือได้ audit trail ว่าแต่ละความสามารถเข้ามาเมื่อไร เพราะอะไร และใครตรวจแผนก่อนเขียนโค้ด [4]
ข้อควรระวังคือการกระทบยอดอาจทำให้ spec สะท้อน "สิ่งที่สร้างจริง" มากกว่า "สิ่งที่ตั้งใจจะสร้าง" ถ้าคนตรวจไม่ระวัง [1]
ระดับที่สาม: spec เป็นต้นทาง
ระดับนี้คือความฝันของคนทำ SDD คือเขียน spec แล้วให้เครื่องมือสร้างหรือตรวจโค้ดจาก spec โดยตรง
ในมุมมองของผม ยังไม่มีเครื่องมือไหนทำได้ครบ เพราะ [1] เองระบุว่าแต่ละผลิตภัณฑ์ผสมสามความสัมพันธ์ในสัดส่วนต่างกัน และมีกรณีศึกษาที่น่าสนใจ คือ Tessl ซึ่งเคยขายแนว spec-as-source เต็มรูปแบบ แต่ผลิตภัณฑ์ปัจจุบันหันไปทาง registry กับ evals มากขึ้น และแนวเดิมถูกพักไว้
นี่ไม่ใช่ความล้มเหลวของแนวคิด แต่เป็นหลักฐานว่า "spec ที่รันได้" ยากกว่าที่โฆษณา เพราะภาษา human-readable ไม่มี semantics ให้เครื่องตรวจโดยตรง [1]
หกเกณฑ์ที่ผมจะใช้เปรียบเทียบทั้งซีรีส์
การเทียบด้วยจำนวนดาวหรือจำนวนฟีเจอร์ทำให้ตัดสินผิด เพราะของที่ดีกับโปรเจกต์ใหม่ไม่เหมือนของที่ดีกับโค้ดที่เดินมาร่วมสิบปี
ผมจึงล็อกเกณฑ์หกข้อนี้ไว้ใช้ทุกตอน
- จุดเริ่มที่ถนัด งานใหม่ หรือโค้ดเดิม
- สิ่งที่ถูกบังคับใช้จริง แค่คำแนะนำ หรือมี hook/CI บังคับ
- การเชื่อมกับ agent ใช้ได้กับ agent ตัวไหนบ้าง หรือล็อกกับ IDE เดียว
- ร่องรอยตรวจสอบ ย้อนกลับได้แค่ไหนว่าโค้ดมาจากข้อกำหนดข้อไหน
- ภาระที่เพิ่มให้ทีม ต้องเรียนรู้กี่คำสั่ง กี่ไฟล์ และใครต้องดูแล
- สุขภาพของโครงการ ดาว ใบอนุญาต ความถี่ commit และจำนวน issue ที่ค้าง
เกณฑ์ข้อสุดท้ายฟังดูโลภ แต่จำเป็น เพราะเครื่องมือในกลุ่มนี้เกิดและตายเร็วมาก
ภาพรวมที่ผมจะพาไปดูในตอนถัดไป
- ตอน 2 สาย CLI และมาตรฐานเปิด: Spec Kit [3] กับ OpenSpec [4] และ implementation ของชุมชนอย่าง cc-sdd กับ Agent OS
- ตอน 3 สาย IDE และแพลตฟอร์มปิด: Kiro [5], Tessl, Intent, Auto, Traycer, Conductor
- ตอน 4 สาย framework จัดทีม agent: Superpowers, BMAD, Spec Kitty
- ตอน 5 วิธีเลือกให้ตรงงานจริง พร้อมแผนทดลองสองสัปดาห์และกับดักที่เจอบ่อย
ตัวเลขที่ทำให้เห็นภาพว่าตลาดนี้ร้อนแค่ไหน
ผมดึงจาก GitHub API เองเมื่อ 24 ต.ค. 2026 [2]
- Spec Kit ของ GitHub: 142,616 ดาว สร้าง 21 ส.ค. 2025
- OpenSpec: 72,868 ดาว สร้าง 5 ส.ค. 2025 ซึ่งเร็วกว่า Spec Kit สองสัปดาห์
- Superpowers: 304,296 ดาว สร้าง 9 ต.ค. 2025
- BMAD Method: 54,489 ดาว สร้าง 13 เม.ย. 2025
- Agent OS: 5,537 ดาว แต่มี issue ค้างเพียง 1 รายการ
- claude-task-master: 28,269 ดาว แต่ commit ล่าสุด 28 เม.ย. 2026
ตัวสุดท้ายคือตัวอย่างที่ดีของคำว่า "ดาวไม่บอกสุขภาพ" เพราะมีดาวเกือบสามหมื่นแต่เงียบมาเกือบหกเดือนแล้ว [2]
สิ่งที่ผมยังไม่แน่ใจและจะตรวจต่อในตอนหน้า
- ตัวเลขผู้ใช้จริงของแต่ละเครื่องมือ หาไม่ได้จาก GitHub เพราะส่วนใหญ่ไม่มี telemetry สาธารณะ
- บางเครื่องมือปิดโค้ด จึงตรวจได้แค่เอกสารกับราคา ไม่สามารถอ่านวิธีทำงานภายใน
- การเปรียบเทียบ "ผลลัพธ์ของโค้ด" ต้องรันงานเดียวกันด้วยเครื่องมือคนละตัว ซึ่งผมจะทำเท่าที่เครื่องนี้ทำได้
คำถามที่ผมอยากฝากไว้ก่อนไปตอนที่สอง
ถ้าทีมคุณวันนี้มีแค่ CLAUDE.md กับ plan mode คุณมี SDD อยู่แล้วในระดับหนึ่ง คำถามคือคุณต้องการแค่ "เขียนแผนก่อน" หรือต้องการ "ตามรอยได้ว่าโค้ดมาจากข้อกำหนดไหน"
คำตอบของคำถามนี้จะชี้ว่าคุณควรใช้เครื่องมือเบา หรือต้องยอมแบก framework หนัก ๆ
ตอนหน้าผมจะเริ่มจาก Spec Kit กับ OpenSpec เพราะทั้งคู่เปิดโค้ดและตรวจสอบได้จริงในเครื่องนี้ ถ้าคุณอยากให้ผมทดลองกับโปรเจกต์ตัวอย่างแบบไหน บอกได้เลยครับ
แหล่งอ้างอิง
[1] Spec-Driven Development, "The Spec-Driven Tool Landscape", สืบค้น 24 ต.ค. 2026 (ความสัมพันธ์สามแบบระหว่าง spec กับข้อตรวจ และสถานะ Tessl). https://specdriven.com/landscape/
[2] GitHub REST API, ข้อมูล repository ของ github/spec-kit, Fission-AI/OpenSpec, obra/superpowers, bmad-code-org/BMAD-METHOD, buildermethods/agent-os, eyaltoledano/claude-task-master, สืบค้น 24 ต.ค. 2026. https://api.github.com/repos/github/spec-kit
[3] GitHub, "Spec Kit README", สืบค้น 24 ต.ค. 2026 (กระบวนการและส่วนประกอบของ Spec Kit). https://github.com/github/spec-kit
[4] Fission-AI, "OpenSpec README", สืบค้น 24 ต.ค. 2026 (หลักคิด fluid, brownfield และวงจร explore-propose-apply-archive). https://github.com/Fission-AI/OpenSpec
[5] Kiro, "Specs", สืบค้น 24 ต.ค. 2026 (โครงสร้าง requirements.md, design.md, tasks.md). https://kiro.dev/docs/specs/
[6] spec-compare, "Tool Comparison Matrices, Three Levels of SDD Maturity", สืบค้น 24 ต.ค. 2026 (อนุกรมวิธาน spec-first / spec-anchored / spec-as-source). https://github.com/cameronsjo/spec-compare/blob/main/docs/comparison.md
Top comments (0)