Spec-driven development: Warum die KI-Tools fürs Coding in verschiedene Lager zerfallen

โดย Nokka (นก-กา) | ตอนที่ 1 ของซีรีส์เปรียบเทียบเครื่องมือ SDD | ตรวจข้อมูล 24 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ถ้าคุณเคยปล่อยให้ AI เขียนโค้ดจากประโยคเดียว คุณจะเจอเรื่องเดิมสามอย่าง

spec-driven development หรือ SDD เกิดจากคำตอบง่าย ๆ ข้อเดียว นั่นคือ เขียนสิ่งที่ต้องการให้ชัดก่อน แล้วให้ agent ทำงานจากเอกสารนั้น ไม่ใช่จากความจำของบทสนทนา

ฟังดูไม่ใหม่ เพราะวิศวกรรมซอฟต์แวร์พูดเรื่องนี้มาสี่สิบปี สิ่งที่ใหม่คือตอนนี้คนอ่าน spec ไม่ใช่แค่มนุษย์ แต่เป็น agent ที่อ่านแล้วลงมือทันที

SDD คือกระบวนการที่ทำให้ ข้อกำหนดที่เขียนไว้ เป็นสัญญาที่ทั้งคนและ agent ใช้ร่วมกัน โดยมีลักษณะสามข้อ

ข้อสามคือข้อที่แยก SDD ออกจาก "การเขียน plan ก่อนลงมือ" ธรรมดา เพราะถ้าอ้างกลับไม่ได้ spec ก็เป็นแค่บันทึกความจำที่เน่าตามเวลา

## 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 Enter fullscreen mode Exit fullscreen mode ตัวอย่างนี้มาจาก OpenSpec และแสดงจุดสำคัญว่า ข้อกำหนดหนึ่งข้อมีทั้งสิ่งที่ต้องเป็นจริงและสถานการณ์ที่ใช้ตรวจได้

ถ้าลองอ่านเอกสารของเครื่องมือ SDD หลายตัวติดกัน คุณจะสับสน เพราะแต่ละตัวเรียกคำเดียวกันว่าคนละเรื่อง

เว็บที่ไล่เก็บข้อมูลเครื่องมือกลุ่มนี้อย่างเป็นระบบอธิบายว่า ความต่างที่แท้จริงอยู่ที่ ความสัมพันธ์ระหว่าง spec กับข้อตรวจ (verification) ไม่ใช่จำนวนฟีเจอร์

เขาแบ่งความสัมพันธ์ระหว่าง spec กับข้อตรวจไว้สามแบบ ส่วนชื่อสามระดับที่พบได้บ่อยในวง SDD คือ spec-first, spec-anchored และ spec-as-source ซึ่งมาจากการจัดอนุกรมวิธานของชุมชนอีกชุดหนึ่ง

บทนี้จะใช้สองแกนนี้ตลอดซีรีส์ แกนแรกคือระดับวุฒิภาวะที่บอกว่า spec ถูกใช้ตรวจแค่ไหน แกนที่สองคือกลุ่มเครื่องมือที่บอกว่ามันเสียบเข้ากับงานเราอย่างไร (CLI, IDE หรือ framework) ตอนที่ 2 ถึง 4 จะไล่ตามแกนที่สอง และตัดสินแต่ละตัวด้วยแกนแรกบวกเกณฑ์อีกหกข้อ

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

ข้อดีคือเข้าใจง่ายและเริ่มได้เร็ว ข้อเสียคือเมื่อเวลาผ่านไป spec กับโค้ดจะแยกจากกัน และไม่มีกลไกไหนบอกคุณว่าแยกเมื่อไร

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

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

เครื่องมือกลุ่มนี้มักทำผ่านสิ่งที่เรียกว่า change proposal คือแยก "ข้อเสนอการเปลี่ยนแปลง" ออกจาก "spec ที่รับแล้ว" เมื่อข้อเสนอผ่านและโค้ดเสร็จจึงย้ายเข้า spec หลัก

ผลคือได้ audit trail ว่าแต่ละความสามารถเข้ามาเมื่อไร เพราะอะไร และใครตรวจแผนก่อนเขียนโค้ด

ข้อควรระวังคือการกระทบยอดอาจทำให้ spec สะท้อน "สิ่งที่สร้างจริง" มากกว่า "สิ่งที่ตั้งใจจะสร้าง" ถ้าคนตรวจไม่ระวัง

ระดับนี้คือความฝันของคนทำ SDD คือเขียน spec แล้วให้เครื่องมือสร้างหรือตรวจโค้ดจาก spec โดยตรง

ในมุมมองของผม ยังไม่มีเครื่องมือไหนทำได้ครบ เพราะ เองระบุว่าแต่ละผลิตภัณฑ์ผสมสามความสัมพันธ์ในสัดส่วนต่างกัน และมีกรณีศึกษาที่น่าสนใจ คือ Tessl ซึ่งเคยขายแนว spec-as-source เต็มรูปแบบ แต่ผลิตภัณฑ์ปัจจุบันหันไปทาง registry กับ evals มากขึ้น และแนวเดิมถูกพักไว้

นี่ไม่ใช่ความล้มเหลวของแนวคิด แต่เป็นหลักฐานว่า "spec ที่รันได้" ยากกว่าที่โฆษณา เพราะภาษา human-readable ไม่มี semantics ให้เครื่องตรวจโดยตรง

การเทียบด้วยจำนวนดาวหรือจำนวนฟีเจอร์ทำให้ตัดสินผิด เพราะของที่ดีกับโปรเจกต์ใหม่ไม่เหมือนของที่ดีกับโค้ดที่เดินมาร่วมสิบปี

เกณฑ์ข้อสุดท้ายฟังดูโลภ แต่จำเป็น เพราะเครื่องมือในกลุ่มนี้เกิดและตายเร็วมาก

ผมดึงจาก GitHub API เองเมื่อ 24 ต.ค. 2026

ตัวสุดท้ายคือตัวอย่างที่ดีของคำว่า "ดาวไม่บอกสุขภาพ" เพราะมีดาวเกือบสามหมื่นแต่เงียบมาเกือบหกเดือนแล้ว

ถ้าทีมคุณวันนี้มีแค่ CLAUDE.md กับ plan mode คุณมี SDD อยู่แล้วในระดับหนึ่ง คำถามคือคุณต้องการแค่ "เขียนแผนก่อน" หรือต้องการ "ตามรอยได้ว่าโค้ดมาจากข้อกำหนดไหน"

คำตอบของคำถามนี้จะชี้ว่าคุณควรใช้เครื่องมือเบา หรือต้องยอมแบก framework หนัก ๆ

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

Spec-Driven Development, "The Spec-Driven Tool Landscape", สืบค้น 24 ต.ค. 2026 (ความสัมพันธ์สามแบบระหว่าง spec กับข้อตรวจ และสถานะ Tessl). https://specdriven.com/landscape/

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

GitHub, "Spec Kit README", สืบค้น 24 ต.ค. 2026 (กระบวนการและส่วนประกอบของ Spec Kit). https://github.com/github/spec-kit

Fission-AI, "OpenSpec README", สืบค้น 24 ต.ค. 2026 (หลักคิด fluid, brownfield และวงจร explore-propose-apply-archive). https://github.com/Fission-AI/OpenSpec

Kiro, "Specs", สืบค้น 24 ต.ค. 2026 (โครงสร้าง requirements.md, design.md, tasks.md). https://kiro.dev/docs/specs/

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