โดย Nokka (นก-กา) | ตอนที่ 4 ของซีรีส์เปรียบเทียบเครื่องมือ SDD | ตรวจข้อมูล 24 ต.ค. 2026
บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)
framework ต่างจากเครื่องมือสองตอนก่อนอย่างไร
ตอนที่ 2 คือเครื่องมือที่ให้โครงเอกสารและคำสั่ง ส่วนตอนที่ 3 คือผลิตภัณฑ์ที่ขายประสบการณ์สำเร็จรูป
ตอนนี้คือของกลางทาง คือ ชุดวิธีทำงานที่ติดตั้งเป็นสกิลให้ agent แล้วบังคับให้มันทำงานเป็นขั้นตอน คล้ายมีหัวหน้าทีมคอยสั่ง
ความต่างที่สำคัญคือมันไม่ได้ให้แค่แม่แบบ spec แต่กำหนดว่าใครทำอะไร เมื่อไร และรีวิวกันแบบไหน
ผลคือถ้าทีมคุณยังไม่มีกระบวนการ framework จะกลายเป็นกระบวนการแทนคุณ ซึ่งดีหรือไม่ดีขึ้นกับขนาดงาน
Superpowers: วิธีทำงานทั้งชุดในรูปสกิล
Superpowers เป็นโครงการที่โตที่สุดในกลุ่มนี้ 304,296 ดาว ใบอนุญาต MIT และ push ล่าสุด 23 ต.ค. 2026 [1]
แนวคิดคือแทนที่จะให้ agent ลงมือเขียนโค้ดทันที มันจะถามกลับก่อนว่าคุณกำลังทำอะไรจริง ๆ แล้วค่อย ๆ สกัดข้อกำหนดออกมาเป็นท่อนสั้นพอให้อ่านไหว [2]
จากนั้นจึงสร้างแผนงานที่ละเอียดพอให้วิศวกรจูเนียร์ที่ไม่มีบริบทของโปรเจกต์ทำตามได้ และแบ่งงานให้ subagent ทำงานแบบเขียนเทสต์ก่อน แล้วมีคนรีวิว [2]
จุดที่ผมประทับใจคือมันรองรับ host เยอะมาก ตั้งแต่ Claude Code, Codex, Cursor, Gemini CLI ไปจนถึง Hermes Agent และ Kimi Code [2]
สิ่งที่ต้องแลกมา
- ต้องตอบคำถามเยอะในตอนเริ่ม ซึ่งช้าสำหรับงานเล็ก
- มี issue ค้างราว 354 รายการ [1] แปลว่าชุมชนใหญ่จนคำขอฟีเจอร์ วิ่งเร็วกว่าคนดูแล
- ถ้าทีมมีกระบวนการอยู่แล้ว การเอา framework เข้ามาทับจะทำให้เกิดสองระบบที่ขัดกัน
BMAD: องค์กรจำลองในกล่อง
BMAD Method หรือชื่อเต็มคือ BMad Method วางตัวเป็นวิธีทำ agile ที่ขับด้วย AI โดยแบ่งงานเป็นวงจร Clarify, Plan, Build and verify แล้วย้อนกลับมา Learn and adjust [3]
จุดขายคือมันปรับขนาดตามงาน งานเล็กเข้า Build ตรง ๆ งานใหญ่ได้ความลึกตามที่ต้องการ และมีบทบาทสมมติอย่างนักวิเคราะห์ผลิตภัณฑ์ สถาปนิก และผู้ตรวจสอบคุณภาพ
เวอร์ชันที่หน้า repo ระบุคือ v6.12 เป็นรุ่นเสถียร ส่วน v7 อยู่ระหว่างพรีวิวและประกาศกรอบเวลาไว้ว่าประมาณ 16 ต.ค. 2026 [3] ซึ่ง ณ วันที่ผมเขียน บล็อกนั้นยังไม่ปรากฏรุ่น v7 ในหน้า release จึงควรถือว่ายังไม่พร้อมใช้
เรื่องใบอนุญาตที่ต้องระวัง
README ของ BMAD ติดป้ายว่า MIT แต่ GitHub API รายงานใบอนุญาตเป็น NOASSERTION [1] ซึ่งหมายถึงระบบตรวจไม่พบไฟล์ใบอนุญาตที่ตรงมาตรฐาน
ผมเปิดไฟล์ LICENSE ใน repo แล้วพบว่าข้อความข้างในเป็น MIT License ของ BMad Code, LLC [3] แปลว่า NOASSERTION น่าจะมาจากระบบตรวจที่ไม่รู้จักรูปแบบไฟล์ ไม่ใช่การละเมิดสัญญาอนุญาต
ถึงอย่างนั้นถ้าจะใช้ในองค์กร ก็ควรให้ฝ่ายกฎหมายเปิดอ่านเองอีกรอบ เพราะความรับผิดชอบอยู่ที่ผู้นำไปใช้ ไม่ใช่ที่ป้ายบนหน้า repo
ใครเหมาะ
ทีมที่มีคนอยากได้บทบาทชัดเจน และยอมให้ framework กำหนดลำดับงาน
ข้อควรระวัง
- ต้องติดตั้ง uv และสคริปต์ Python เพิ่ม [3]
- บทบาทสมมติหลายบททำให้มีเอกสารหลายชั้น ซึ่งทีมเล็กอาจรู้สึกหนักเกินงาน
- การอยู่ในช่วงเปลี่ยนรุ่นใหญ่ ทำให้เอกสารสองชุดปนกันได้ง่าย
Spec Kitty: โรงงานที่มีประตูอนุมัติ
Spec Kitty นิยามตัวเองว่าเป็น CLI สำหรับสร้างโรงงานซอฟต์แวร์ คือมีลำดับ spec, plan, tasks, next, review, accept, merge และเก็บสถานะทั้งหมดไว้ใน repo [4]
จุดเด่นคือ worktree แยกต่อหนึ่งงาน ทำให้ agent หลายตัวทำงานขนานได้โดยไม่ชนกันใน branch เดียว และมีประตูอนุมัติให้คนตัดสินก่อน merge [4]
รองรับ agent หลายค่าย ทั้ง Claude Code, Codex, Cursor, Gemini, GitHub Copilot, Windsurf และ OpenCode [4]
ตัวเลขที่ต้องอ่านให้ดี
1,700 ดาว และมี issue เปิดค้าง 1,030 รายการ [1] ซึ่งเป็นอัตราส่วนที่สูงมาก
ตัวเลขนี้ไม่ได้แปลว่าเครื่องมือไม่ดี แต่มันบอกว่าคำถามและข้อบกพร่องเข้ามาเร็วกว่ากำลังคนดูแล และรุ่น 4.0 ยังเป็น release candidate [4]
ถ้าทีมคุณไม่มีคนรับผิดชอบเรื่องเครื่องมือโดยเฉพาะ การเจอ issue ที่ยังไม่มีคำตอบจะเป็นประสบการณ์ปกติ ไม่ใช่ข้อยกเว้น
กรณีศึกษาที่ควรจำ: ดาวหกหมื่นกับ repo ที่ถูกเก็บเข้ากรุ
ในตอนที่ 2 ผมพูดถึง get-shit-done ซึ่งมี 64,236 ดาวแต่ถูก archive ไปแล้ว [1]
ผมยกมาซ้ำเพราะมันเป็นภาพที่คนทำ SDD ควรเห็นบ่อย ๆ คือเครื่องมือที่ดูยิ่งใหญ่ที่สุดอาจหยุดพัฒนาไปแล้ว โดยที่บทความและวิดีโอเก่ายังแนะนำอยู่
ก่อนติดตั้งอะไรทุกครั้ง ให้เปิดหน้านั้นดูสามอย่าง คือ archived หรือไม่ push ล่าสุดเมื่อไร และ issue ค้างเท่าไร [1]
เทียบกับเกณฑ์หกข้อจากตอนที่ 1
- จุดเริ่มที่ถนัด: Superpowers ถนัดงานใหม่ที่ยังไม่มีข้อกำหนด · BMAD ครอบทั้งงานเล็กและใหญ่ · Spec Kitty ถนัดงานที่ต้องรันขนานหลายชิ้น
- สิ่งที่ถูกบังคับใช้จริง: ทั้งสามบังคับผ่านสกิลและประตูอนุมัติ แต่ Spec Kitty บังคับถึงระดับ merge
- การเชื่อมกับ agent: Superpowers กว้างที่สุด · BMAD และ Spec Kitty รองรับหลายตัวแต่เน้น Claude Code
- ร่องรอยตรวจสอบ: Spec Kitty เก็บสถานะครบที่สุด เพราะออกแบบมาเพื่อ audit
- ภาระที่เพิ่มให้ทีม: สูงทั้งสามตัว บทความนี้จึงไม่แนะนำให้เริ่มจากที่นี่ถ้าทีมยังไม่เคยเขียน spec
- สุขภาพของโครงการ: Superpowers แข็งแรงที่สุด · BMAD กำลังเปลี่ยนรุ่นใหญ่ · Spec Kitty มี issue ค้างมาก
ลำดับที่ผมแนะนำให้ลอง
สำหรับทีมที่ยังไม่เคยทำ SDD ผมไม่แนะนำให้เริ่มจาก framework เพราะคุณจะสับสนว่าปัญหาอยู่ที่กระบวนการหรือที่เครื่องมือ
ลำดับที่ผมคิดว่าได้ผลกว่าคือ เขียน spec ด้วยเครื่องมือเบาจากตอนที่ 2 สองถึงสามสัปดาห์ แล้วค่อยถามว่าอะไรที่ยังเจ็บ
- ถ้าเจ็บที่ agent ไม่ทำตามแผน → framework ช่วยได้
- ถ้าเจ็บที่งานขนานชนกัน → Spec Kitty หรือ Conductor
- ถ้าเจ็บที่ข้อกำหนดไม่ชัด → ปัญหาอยู่ที่การเขียน ไม่ใช่เครื่องมือ
คำถามที่ควรถามก่อนเลือก framework
- ทีมมีคนรับผิดชอบดูแลเครื่องมือนี้หรือยัง
- งานส่วนใหญ่เป็นงานเดี่ยวหรือขนานกันหลายสาย
- ถ้า framework กำหนดบทบาทของทีมใหม่ คุณยอมเปลี่ยนวิธีทำงานหรือไม่
ถ้าข้อสามตอบว่าไม่ คุ้มกว่าที่จะหยิบแค่บางสกิลมาใช้ ไม่ต้องยกทั้งชุด
ภาพที่ผมเห็นในหัว
ยกตัวอย่างให้เห็นภาพ คือทีมช่างห้าคนที่ทำงานในโรงงานเดียวกัน ถ้าไม่มีใครกำหนดว่าใครทำอะไร ทั้งห้าคนจะหยิบเครื่องมือเดียวกันพร้อมกัน และชนกันที่โต๊ะตัวเดียว
framework คือคนที่กำหนดว่าใครยืนตรงไหนและส่งงานต่อให้ใคร แต่ถ้าโรงงานของคุณมีงานชิ้นเดียว การจ้างคนมาคุมห้าคนจะกลายเป็นต้นทุนที่ไม่ได้ช่วยอะไร เหมือนซื้อระบบจัดการคลังสินค้าสำหรับของสามชิ้น
ตอนต่อไป
ตอนที่ 5 คือตอนที่ผมรวบทุกอย่างมาเป็นแผนตัดสินใจ พร้อม checklist สองสัปดาห์และกับดักที่ทำให้โครงการ SDD ล้ม ซึ่งเป็นส่วนที่ผมคิดว่ามีค่าที่สุดในซีรีส์นี้
REF
[1] GitHub REST API, ข้อมูล repository ของ obra/superpowers, bmad-code-org/BMAD-METHOD, spec-kitty/spec-kitty, gsd-build/get-shit-done, สืบค้น 24 ต.ค. 2026 (ดาว ใบอนุญาต วันที่ push และจำนวน issue). https://api.github.com/repos/obra/superpowers
[2] obra, "Superpowers README", สืบค้น 24 ต.ค. 2026 (วิธีทำงาน ตั้งแต่ถามความต้องการจนถึง subagent และรายชื่อ host ที่รองรับ). https://github.com/obra/superpowers
[3] bmad-code-org, "BMAD-METHOD README", สืบค้น 24 ต.ค. 2026 (วงจร Clarify, Plan, Build, Learn · v6.12 · v7 preview · ต้องใช้ uv). https://github.com/bmad-code-org/BMAD-METHOD
[4] spec-kitty, "Spec Kitty README", สืบค้น 24 ต.ค. 2026 (ลำดับ spec ถึง merge · worktree แยกต่องาน · รายชื่อ agent ที่รองรับ · สถานะ 4.0 RC). https://github.com/spec-kitty/spec-kitty
Top comments (0)