Spec Kit 與 OpenSpec 有何不同？五款可配合多種 Agent 的開源 SDD 工具比較

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

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

สายนี้คืออะไร และต่างจากอีกสองสายอย่างไร

ในตอนที่ 1 ผมแยกเครื่องมือ SDD เป็นสองแกน คือระดับวุฒิภาวะของ spec กับกลุ่มของเครื่องมือ

ตอนนี้เราลงมาที่กลุ่มแรก คือ เครื่องมือแบบ CLI และมาตรฐานเปิด ซึ่งมีจุดร่วมกันสามข้อ

ทำงานในเทอร์มินัลหรือในโปรเจกต์ ไม่ผูกกับหน้าตา IDE
ใช้ได้กับ agent หลายตัว เช่น Claude Code, Codex, Cursor หรือ Gemini CLI
ไฟล์ spec อยู่ใน repo ของคุณ ไม่ได้อยู่บนเซิร์ฟเวอร์ของบริษัทไหน

จุดร่วมข้อสุดท้ายสำคัญ เพราะหมายความว่าใครอ่านโค้ดก็เห็นข้อกำหนด และย้ายเครื่องมือได้โดยไม่ต้องย้ายประวัติ

ห้าตัวที่ผมจะเทียบในตอนนี้

เรียงตามจำนวนดาว ณ วันที่ 24 ตุลาคม 2026 ซึ่งผมดึงจาก GitHub API เอง [1]

GitHub Spec Kit · 142,616 ดาว · MIT · push ล่าสุด 23 ต.ค. 2026
OpenSpec · 72,868 ดาว · MIT · push ล่าสุด 24 ต.ค. 2026
Agent OS · 5,537 ดาว · MIT · push ล่าสุด 7 ต.ค. 2026
cc-sdd · 3,737 ดาว · MIT · push ล่าสุด 22 ต.ค. 2026
Allium · 520 ดาว · MIT · push ล่าสุด 27 ก.ย. 2026

ตัวเลขดาวบอกความนิยม แต่ไม่ได้บอกว่าตัวไหนเหมาะกับงานคุณ ซึ่งเป็นเหตุผลที่ตอนที่ 1 ผมวางเกณฑ์หกข้อไว้

GitHub Spec Kit: มาตรฐานที่คนพูดถึงมากที่สุด

Spec Kit เป็นเครื่องมือที่ทำให้คำว่า spec-driven development กลับมาเป็นที่พูดถึงอีกครั้ง เพราะออกมาจากทีม GitHub เอง และติดตั้งง่ายจนคนทั่วไปลองได้ [2]

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

สิ่งที่ได้หลังติดตั้ง

Spec Kit จะสร้างโฟลเดอร์ .specify/ ซึ่งเก็บแม่แบบเอกสาร สคริปต์ช่วยงาน และการตั้งค่าของโปรเจกต์ พร้อมติดตั้งชุดสกิลให้ agent ที่คุณเลือกใช้ [2]

เอกสารการติดตั้งของ Spec Kit ระบุพาธหลักที่โปรเจกต์จะได้ดังนี้ [7]

.specify/
  memory/constitution.md   หลักการที่โปรเจกต์ยึดถือ [9]
  scripts/bash|powershell|python/   สคริปต์ตาม shell ที่เลือก
  feature.json             สถานะของฟีเจอร์ที่กำลังทำ [8]
.claude/                   คำสั่งหรือสกิลที่ติดตั้งตาม integration

แม่แบบเอกสารและ workflow อยู่ใน repo ของ Spec Kit เอง ไม่ได้คัดลอกมาทั้งหมดในโฟลเดอร์ .specify เสมอไป ซึ่งเป็นรายละเอียดที่บทความหลายชิ้นเขียนคลาดเคลื่อน (ซึ่งเป็นจุดที่บทความจำนวนหนึ่งอธิบายคลาดเคลื่อน)

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

สิ่งที่ผมชอบ

ลำดับขั้นชัด ตั้งแต่ข้อกำหนดถึงงานที่ลงมือได้
เอกสารเยอะ และมีคนใช้เยอะ จึงหาคำตอบได้ง่าย
ทำงานร่วมกับ agent หลายตัว ไม่ผูกขาด

สิ่งที่ต้องระวัง

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

OpenSpec: repo เปิดก่อน และออกแบบมาเพื่อโค้ดเดิม

จุดที่น่าสนใจคือ repo ของ OpenSpec ถูกสร้างก่อน Spec Kit 16 วัน (5 ส.ค. 2025 เทียบกับ 21 ส.ค. 2025) [1] ซึ่งเป็นเรื่องของลำดับ repo ไม่ใช่หลักฐานว่าแนวคิดเกิดก่อน และไม่ควรใช้ตัวเลขนี้สรุปว่าใครลอกใคร

แนวคิดหลักของมันคือ แยกข้อเสนอการเปลี่ยนแปลงออกจาก spec ที่รับแล้ว ซึ่งต่างจากเครื่องมือที่บังคับให้เขียน spec ใหม่ทั้งก้อน [3]

วงจรการทำงานมีสี่ขั้น

explore คือสำรวจว่าอยากได้อะไร
propose คือเขียนข้อเสนอเป็นโฟลเดอร์แยก พร้อมเหตุผลและงานที่ต้องทำ
apply คือลงมือทำตามข้อเสนอนั้น
archive คือเก็บข้อเสนอที่เสร็จแล้วเข้า spec หลัก

ผลลัพธ์คือคุณได้ประวัติว่าแต่ละความสามารถเข้ามาเมื่อไร เพราะอะไร และใครรีวิวแผนก่อนโค้ดถูกเขียน [3]

สิ่งที่ผมชอบ

เหมาะกับโค้ดเดิมมาก เพราะไม่ต้องรื้อ spec ทั้งระบบ
ข้อเสนอหนึ่งใบมีทั้งเหตุผลและงาน ทำให้ตรวจย้อนได้
ติดตั้งผ่าน openspec init แล้ว agent กว่า 30 ตัวเรียกใช้ผ่านคำสั่ง slash ชุดเดียวกัน [3]

สิ่งที่ต้องระวัง

ถ้าทีมมีข้อเสนอค้างเยอะ จะกลายเป็นงานเอกสารที่ไม่มีใครเก็บ
การย้ายข้อเสนอเข้า spec หลักต้องมีคนตรวจ ไม่ใช่ปล่อยให้ agent ทำเองทุกครั้ง

cc-sdd: สายเบาที่เน้นงานยาว

cc-sdd มาจากทีม gotalab และประกาศตัวว่าได้รับแรงบันดาลใจจาก Kiro คือจัดลำดับข้อกำหนด แล้วปล่อยให้ agent ทำงานยาวแบบอัตโนมัติ [4]

จุดที่ต่างจากสองตัวแรกคือมันเน้น การทำงานยาว มากกว่าการสร้างเอกสาร

มีจุดเริ่มที่เรียกว่า discovery เพื่อตัดสินว่าควรขยาย spec เดิม ทำ spec ใหม่ หรือแยกเป็นหลาย spec
เขียนไฟล์ brief และ roadmap เพื่อให้กลับมาทำต่อได้โดยไม่ต้องอธิบายบริบทใหม่
ถ้า agent ที่ใช้มี subagent จะแยกคนเขียนกับคนรีวิว และรันทดสอบแบบเขียนเทสต์ก่อน

มันรองรับ agent แปดตัวด้วยชุดสกิลเดียวกัน และบอกว่า spec ที่ทำใน Kiro ยังย้ายมาใช้ได้ในทางเนื้อหา แม้ชื่อคำสั่งจะต่างกัน [4]

ใครเหมาะ

ทีมเล็กที่อยากได้ระบบ แต่ไม่ต้องการพิธีกรรมหนัก ๆ แบบ Spec Kit

ข้อควรระวัง

จำนวนดาวน้อยกว่าสองตัวแรกมาก แปลว่าชุมชนเล็ก คำถามยาก ๆ อาจไม่มีใครตอบ
การพึ่ง subagent ทำให้คุณภาพขึ้นกับ agent ที่เลือกใช้ ไม่ใช่แค่ตัวเครื่องมือ

Agent OS: มาตรฐานของโค้ดเบสมาก่อน spec

Agent OS มาจากทีม Builder Methods และวางตำแหน่งต่างจากตัวอื่นชัดเจน คือมันเริ่มจาก มาตรฐานของโค้ดที่ทีมเขียนอยู่แล้ว [5]

ความสามารถหลักมีสี่ข้อ

discover มาตรฐาน คือสกัดรูปแบบและธรรมเนียมจากโค้ดเดิมออกมาเป็นเอกสาร
deploy มาตรฐาน คือหยิบมาตรฐานที่เกี่ยวข้องมาฉีดให้ agent ตอนทำงาน
shape spec คือช่วยทำให้แผนดีขึ้นก่อนลงมือ
index มาตรฐาน คือจัดระเบียบเอกสารให้ค้นได้

แนวคิดนี้ตอบปัญหาที่คนทำ SDD มักเจอ คือ spec เขียนสวยแต่ไม่ตรงกับสไตล์โค้ดจริงของทีม

ใครเหมาะ

ทีมที่โค้ดเดิมมีอยู่แล้ว และเจ็บที่ agent เขียนโค้ดไม่เหมือนคนในทีม

ข้อควรระวัง

ต้องลงทุนสกัดมาตรฐานครั้งแรก ซึ่งใช้เวลามากกว่าการเขียน spec หนึ่งใบ
ถ้ามาตรฐานเก่าและไม่มีใครอัปเดต agent จะทำตามของเก่าอย่างมั่นใจ

Allium: เมื่อ markdown ไม่พอ

ทั้งสี่ตัวข้างบนใช้ markdown เป็นภาษากลาง ซึ่งมนุษย์อ่านง่าย แต่เครื่องตรวจไม่ได้

Allium เลือกทางตรงข้าม คือสร้างภาษาสำหรับอธิบายพฤติกรรมของระบบโดยเฉพาะ [6]

ไฟล์ .allium เก็บสิ่งที่ระบบต้องทำ ไม่ใช่วิธีทำ
มี CLI ตรวจไวยากรณ์และอนุมานความหมาย เช่น ไล่เส้นทางข้อมูล หรือตรวจว่าวงจรชีวิตของ entity จบได้จริง
สร้างเทสต์จากพฤติกรรมที่เขียนไว้ได้
ทำงานย้อนกลับได้ คือชี้ไปที่โค้ดเดิมแล้วสกัด spec ออกมา

จุดนี้คือคำตอบของข้อจำกัดที่ผมเขียนไว้ในตอนที่ 1 ว่า markdown ไม่มี semantics ให้เครื่องบังคับใช้

ข้อควรระวัง

ต้องเรียนภาษใหม่ ซึ่งเป็นภาระจริงสำหรับทีม
จำนวนดาวน้อยที่สุดในกลุ่มนี้ และ push ล่าสุด 27 ก.ย. 2026 ไม่ใช่สัปดาห์นี้
ไม่ได้แทนที่การคุยกับคน แต่ทำให้การคุยมีของให้ตรวจ

ตัวที่ควรรู้ไว้เป็นกรณีศึกษา

ระหว่างค้นข้อมูล ผมเจอ repo ชื่อ get-shit-done มีดาว 64,236 ดวง สูงเป็นอันดับต้นของกลุ่มนี้ [1]

แต่สถานะของมันคือ archived คือเจ้าของหยุดพัฒนาแล้ว และ push ล่าสุด 31 พ.ค. 2026 [1]

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

เทียบกันแบบเร็ว

ถ้าต้องเลือกวันนี้ ผมสรุปแบบนี้

งานใหม่ที่อยากมีวินัยครบวงจร: Spec Kit
โค้ดเดิมที่ต้องเปลี่ยนทีละส่วน: OpenSpec
อยากได้งานยาวอัตโนมัติโดยไม่ต้องตั้งระบบเยอะ: cc-sdd
ปัญหาคือ agent เขียนโค้ดไม่เหมือนทีม: Agent OS
ต้องการให้เครื่องตรวจ spec ได้จริง: Allium

ทั้งหมดนี้อยู่บนสมมติฐานว่าคุณใช้ agent ที่รองรับสกิลหรือ CLI ส่วนคนที่ทำงานใน IDE แบบปิดจะมีทางเลือกแคบกว่า ซึ่งผมจะลงรายละเอียดในตอนที่ 3

ข้อผิดพลาดที่เจอบ่อยในสายนี้

ติดตั้งแล้วไม่เคยอ่าน .specify/memory/constitution.md ทำให้ agent ทำงานโดยไม่รู้หลักของโปรเจกต์
เขียน spec ยาวเกินจนไม่มีใครอ่าน แล้วก็กลับไปสั่งงานด้วยประโยคเดียวเหมือนเดิม
ใช้เครื่องมือสองตัวพร้อมกันโดยไม่กำหนดว่าตัวไหนเป็นแหล่งความจริง
ลืมว่า spec ที่ไม่มีคนตรวจจะเน่าเร็วกว่าโค้ด

คำถามที่ควรตอบก่อนเลือก

ลองตอบสามข้อนี้ก่อนติดตั้งอะไร

งานที่ทำอยู่เป็นงานใหม่หรือแก้ของเดิม
ทีมยอมรับภาระเขียนเอกสารเพิ่มได้แค่ไหนต่อสัปดาห์
ถ้าเครื่องมือนี้หยุดพัฒนาในหกเดือน คุณยังใช้งานต่อได้ไหม

คำตอบข้อสามสำคัญ เพราะตลาดนี้เปลี่ยนเร็วมากจนการเลือกเครื่องมือที่ดีที่สุด ณ วันนี้อาจกลายเป็นภาระในอีกปี

REF

[1] GitHub REST API, ข้อมูล repository ของ github/spec-kit, Fission-AI/OpenSpec, buildermethods/agent-os, gotalab/cc-sdd, juxt/allium, gsd-build/get-shit-done, สืบค้น 24 ต.ค. 2026. https://api.github.com/repos/github/spec-kit

[2] GitHub, "Spec Kit README", สืบค้น 24 ต.ค. 2026 (ภาพรวม คำสั่ง และแนวคิด). https://github.com/github/spec-kit

[3] Fission-AI, "OpenSpec README", สืบค้น 24 ต.ค. 2026 (วงจร explore, propose, apply, archive และการรีวิวแผนก่อนเขียนโค้ด). https://github.com/Fission-AI/OpenSpec

[4] gotalab, "cc-sdd README v3.0", สืบค้น 24 ต.ค. 2026 (discovery, brief, roadmap, subagent และการรองรับ agent แปดตัว). https://github.com/gotalab/cc-sdd

[5] buildermethods, "Agent OS README", สืบค้น 24 ต.ค. 2026 (discover, deploy, shape และ index standards). https://github.com/buildermethods/agent-os

[6] juxt, "Allium README", สืบค้น 24 ต.ค. 2026 (ภาษา ไฟล์ .allium และ CLI ตรวจไวยากรณ์). https://github.com/juxt/allium

[7] GitHub, "Spec Kit, docs/installation.md", สืบค้น 24 ต.ค. 2026 (พาธ .specify/memory/constitution.md, scripts/, feature.json และตัวเลือก integration). https://github.com/github/spec-kit/blob/main/docs/installation.md

[8] GitHub, "Spec Kit, docs/quickstart.md", สืบค้น 24 ต.ค. 2026 (พาธ .specify/feature.json และลำดับคำสั่ง). https://github.com/github/spec-kit/blob/main/docs/quickstart.md

[9] GitHub, "Spec Kit, docs/upgrade.md", สืบค้น 24 ต.ค. 2026 (พาธ .specify/memory/constitution.md และการอัปเกรดโปรเจกต์). https://github.com/github/spec-kit/blob/main/docs/upgrade.md