按實際工作選擇 SDD 工具：兩週檢查清單與常見失敗陷阱

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

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

ก่อนจะเลือก ต้องตอบให้ได้ว่าปัญหาคืออะไร

สี่ตอนที่ผ่านมาผมไล่ดูเครื่องมือสามกลุ่ม ตั้งแต่ CLI ที่เปิดโค้ด ไปจนถึง framework ที่จัดทีม agent

ตอนนี้คือตอนที่ผมคิดว่าสำคัญที่สุด เพราะคำถามไม่ใช่ "ตัวไหนดีที่สุด" แต่เป็น "ทีมคุณเจ็บเรื่องอะไร"

ถ้าตอบข้อนี้ไม่ได้ เครื่องมือไหนก็แก้ไม่ถูกจุด และคุณจะเสียสองสัปดาห์ไปกับการตั้งค่า

อาการสี่แบบที่พบได้บ่อย

ลองดูว่าข้อไหนตรงกับคุณมากที่สุด

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

สี่อาการนี้ต้องการเครื่องมือคนละกลุ่ม ซึ่งเป็นเหตุผลที่ผมไม่เชื่อคำแนะนำแบบ "ใช้ตัวนี้แล้วจบ"

จับคู่อาการกับเครื่องมือ

อาการแรก เริ่มจาก Spec Kit หรือ OpenSpec ในตอนที่ 2 เพราะทั้งคู่บังคับให้ข้อกำหนดชัดก่อนลงมือ [1][4]
อาการที่สอง เลือก Agent OS เพราะมันสกัดมาตรฐานจากโค้ดเดิมแล้วฉีดให้ agent [5]
อาการที่สาม เลือก Spec Kitty หรือ Conductor เพราะแยก worktree และมีประตูอนุมัติ [1]
อาการที่สี่ เลือก OpenSpec เพราะแยกข้อเสนอการเปลี่ยนแปลงออกจาก spec ที่รับแล้ว [4]

ส่วน Allium เหมาะกับทีมที่ต้องการให้เครื่องตรวจ spec ได้จริง ไม่ใช่ให้คนอ่านอย่างเดียว [2]

สามโปรไฟล์ทีม และคำตอบที่ต่างกัน

คนเดียวที่ทำโปรเจกต์ส่วนตัว

ไม่ต้องใช้เครื่องมือหนัก ขอแค่ CLAUDE.md ที่บอกบริบท และ plan mode ก่อนลงมือ

ถ้าอยากเพิ่ม ให้เริ่มจาก Spec Kit เพราะลำดับขั้นช่วยไม่ให้ข้ามการคิด

ทีมเล็กสองถึงห้าคนที่โค้ดเดินมาระยะหนึ่ง

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

ถ้าทีมเจ็บเรื่อง agent เขียนไม่เหมือนกัน ให้เพิ่ม Agent OS เข้าไปสกัดมาตรฐาน

องค์กรที่มีข้อกำหนดด้านการตรวจสอบ

Spec Kitty ให้ร่องรอยครบกว่าอีกสองตัวในตอนที่ 4 แต่ต้องมีคนรับผิดชอบ issue ที่ค้าง [1]

อีกทางคือ Kiro ในฐานะผลิตภัณฑ์ที่รองรับองค์กร แต่ต้องยอมรับ lock-in และค่าเครดิตที่ผันตามการใช้

แผนทดลองสองสัปดาห์ที่ผมแนะนำ

อย่าเริ่มด้วยการติดตั้งทุกอย่าง ให้เริ่มด้วยการวัดของเดิมก่อน

สัปดาห์แรก: วัด baseline

เลือกงานหนึ่งชิ้นที่ขนาดกำลังดี คือประมาณสองถึงห้าวัน

จากนั้นจดตัวเลขสี่อย่าง

เวลาตั้งแต่เริ่มจน merge
จำนวนรอบที่ต้องกลับไปแก้ เพราะเข้าใจผิด
จำนวนครั้งที่ต้องอธิบายบริบทซ้ำ
จำนวนความคิดเห็นในรีวิวที่เกี่ยวกับ "ไม่ตรงกับที่ตกลง"

ตัวเลขชุดนี้คือเส้นฐานของคุณ ถ้าไม่จดไว้ คุณจะเถียงกันด้วยความรู้สึกตอนจบ

สัปดาห์ที่สอง: ลองเครื่องมือเดียว

เลือกเครื่องมือเดียวตามอาการที่ตรงที่สุด แล้วทำงานขนาดใกล้เคียงกันหนึ่งชิ้น

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

วิธีตัดสิน

ผมใช้เกณฑ์ง่าย ๆ สี่ข้อ

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

ถ้าข้อสองตอบว่าแค่เซ็นผ่าน ให้หยุดและทบทวน เพราะนั่นคือสัญญาณว่าเครื่องมือกลายเป็นพิธีกรรม

Checklist ก่อนตัดสินใจ

ห้าข้อนี้ใช้ได้กับทุกเครื่องมือในซีรีส์

เปิด repo ดูสถานะ archived และวัน push ล่าสุด
เปิดไฟล์ LICENSE อ่านข้อความจริงในไฟล์ ไม่ใช่เชื่อป้ายที่หน้าแรก
ตรวจว่าไฟล์ spec อยู่ใน repo ของคุณ หรืออยู่ในระบบของเขา
หาคนหนึ่งคนที่จะเป็นเจ้าของเครื่องมือนี้ในทีม
ลองในงานจริงหนึ่งชิ้นก่อนเซ็นสัญญารายปี

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

กับดักที่ทำให้โครงการ SDD ล้ม

เขียน spec เพื่อให้ครบ ไม่ใช่เพื่อให้ใช้: เอกสารหนาแต่ไม่มีใครอ่าน
ปล่อยให้ agent อนุมัติเอง: ประตู human in the loop ต้องมีคนจริง ไม่ใช่ชื่อในไฟล์
เริ่มจาก framework: ทีมยังไม่เคยเขียน spec แต่ต้องเรียนวิธีทำงานใหม่ทั้งระบบ
เปลี่ยนเครื่องมือก่อนวัดผล: ไม่มีเส้นฐาน จึงไม่มีทางรู้ว่าดีขึ้นจริง
ลืมค่าใช้จ่ายโทเคน: งาน SDD อ่านบริบทมากกว่าการเขียนโค้ด ทำให้ค่าใช้จ่ายสูงกว่าที่คาด

ข้อสุดท้ายนี้เห็นได้ชัดในผลิตภัณฑ์ที่คิดเงินเป็นเครดิต อย่างที่ผมเขียนไว้ในตอนที่ 3 [3]

เมื่อไรควรตอบว่า "ยังไม่ต้องใช้"

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

นี่คือเหตุผลที่ผมเริ่มซีรีส์ด้วยการบอกว่าเครื่องมือไม่ได้ช่วยถ้าปัญหาอยู่ที่การสื่อสาร

การรู้ว่าเมื่อไรไม่ต้องใช้เครื่องมือ เป็นทักษะที่มีค่าพอ ๆ กับการเลือกให้ถูก

สรุปทั้งซีรีส์ในหนึ่งหน้า

ตอนที่ 1 SDD มีสามระดับวุฒิภาวะ คือ spec นำแล้วจบ ถูกกระทบยอด และเป็นต้นทาง
ตอนที่ 2 สายเปิดที่คุ้มที่สุดสำหรับคนส่วนใหญ่ คือ Spec Kit สำหรับงานใหม่ และ OpenSpec สำหรับโค้ดเดิม
ตอนที่ 3 สายปิดให้ประสบการณ์สำเร็จรูป แต่มี lock-in และค่าใช้จ่ายผันตามการใช้
ตอนที่ 4 framework ช่วยเรื่องกระบวนการ แต่เพิ่มภาระและความเสี่ยงเรื่องคนดูแล
ตอนที่ 5 เริ่มจากอาการ ไม่ใช่จากเครื่องมือ และวัดผลด้วยตัวเลขของตัวเอง

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

คำถามที่ผมอยากฝากไว้

หลังอ่านครบห้าตอน คุณยังคิดว่าเครื่องมือคือคำตอบแรกอยู่ไหม

ถ้าคำตอบคือไม่ นั่นคือสัญญาณดี เพราะแปลว่าคุณเริ่มมองที่กระบวนการก่อนผลิตภัณฑ์

ถ้าอยากให้ผมลองเครื่องมือตัวไหนในงานจริงแล้วรายงานผลด้วยตัวเลข บอกได้เลยครับ ผมจะทำเป็นตอนพิเศษให้

เทมเพลตจดผลการทดลอง

ถ้าอยากเริ่มพรุ่งนี้ นี่คือสิ่งที่ผมใช้จด

งานที่เลือก:
เวลาที่ใช้จน merge (ชิ้นฐาน):
จำนวนรอบที่ต้องแก้เพราะเข้าใจผิด:
จำนวนครั้งที่ต้องอธิบายบริบทซ้ำ:
หมายเหตุอื่น:

จดของเดิมก่อนหนึ่งชิ้นให้ครบ แล้วค่อยลองเครื่องมือใหม่กับงานชิ้นถัดไป

ถ้าคุณทำตามแล้วอยากให้ผมช่วยอ่านผล บอกได้เลยครับ ผมยินดีช่วยดูว่าตัวเลขบอกอะไร

REF

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

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

[3] Kiro, "Pricing", สืบค้น 24 ต.ค. 2026 (รูปแบบเครดิตและค่าใช้จ่ายต่อแผน). https://kiro.dev/pricing/

[4] Fission-AI, "OpenSpec README", สืบค้น 24 ต.ค. 2026 (การแยกข้อเสนอการเปลี่ยนแปลงออกจาก spec หลัก). https://github.com/Fission-AI/OpenSpec

[5] buildermethods, "Agent OS README", สืบค้น 24 ต.ค. 2026 (การสกัดและฉีดมาตรฐานโค้ดให้ agent). https://github.com/buildermethods/agent-os