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

วิธีทำงานนี้เรียกว่า Spec-Driven Development โดยให้ความสำคัญกับสเปกก่อนโค้ด

สเปกที่เคยเป็นเอกสารทิ้ง กลับมาเป็นตัวสั่งงาน

หน้าโปรเจกต์อธิบายไว้ตรงๆ ว่าตลอดหลายสิบปีที่ผ่านมา งานพัฒนาซอฟต์แวร์ให้ความสำคัญกับโค้ดเป็นหลัก ส่วนสเปกเป็นเพียงเอกสารชั่วคราวที่มักถูกทิ้งเมื่อเริ่มเขียนโค้ดจริง

Spec-Driven Development เปลี่ยนสเปกจากเอกสารอ้างอิงให้กลายเป็นคำสั่งที่ AI ใช้สร้างโค้ดซึ่งทำงานได้จริง โดยใช้ AI coding agent ตัวใดก็ได้ที่มีอยู่ ส่วน Spec Kit ทำหน้าที่กำหนดกระบวนการและเตรียมเทมเพลตสำหรับทุกขั้นตอน

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

ห้าคำสั่งที่เป็นแกนของทั้งกระบวนการ

หลังเปิด AI coding agent ในโฟลเดอร์โปรเจกต์แล้ว ให้ใช้คำสั่งทั้งห้านี้ตามลำดับ

หน้าโปรเจกต์ยกตัวอย่างเป็นแอปจัดรูปภาพ ตอนสั่ง /speckit.specify ผู้ใช้พิมพ์โจทย์ด้วยภาษาทั่วไปว่า ให้สร้างแอปที่จัดรูปเป็นอัลบั้มแยกกัน จัดกลุ่มอัลบั้มตามวันที่ และลากสลับตำแหน่งอัลบั้มบนหน้าหลักได้ ห้ามมีอัลบั้มอยู่ภายในอัลบั้มอื่น ส่วนรูปในแต่ละอัลบั้มให้แสดงเป็นตารางแบบไทล์

ส่วนเทคโนโลยีจะระบุในขั้น /speckit.plan ว่าให้ใช้ Vite และเขียนด้วย HTML CSS และ JavaScript ล้วนให้มากที่สุด ไม่อัปโหลดรูปไปเก็บไว้ที่ใด และเก็บข้อมูลกำกับรูปหรือ metadata ไว้ในฐานข้อมูล SQLite บนเครื่อง

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

คำสั่งเสริมที่เอาไว้อุดรูรั่วก่อนโค้ดจะออกมา

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

• /speckit.clarify ถามเพิ่มในจุดที่สเปกยังมีรายละเอียดไม่พอ แนะนำให้รันก่อน /speckit.plan ชื่อเดิมของคำสั่งนี้คือ /quizme
• /speckit.analyze ตรวจว่าเอกสารทุกไฟล์ยังสอดคล้องกันและมีเนื้อหาครบถ้วน รันหลัง /speckit.tasks และก่อน /speckit.implement
• /speckit.checklist สร้างเช็กลิสต์คุณภาพเพื่อตรวจว่าความต้องการเขียนไว้ครบ ชัด และไม่ขัดกันเองหรือยัง หน้าโปรเจกต์อธิบายว่าเหมือน "unit tests for English"
• /speckit.taskstoissues แปลงรายการงานที่ได้ออกมาเป็น issue สำหรับใช้ติดตามงาน
• /speckit.converge ประเมินโค้ดที่มีอยู่เทียบกับสเปก แผน และรายการงาน แล้วเพิ่มงานที่ยังเหลืออยู่เข้าไปในรายการ

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

ติดตั้งและเปิดโปรเจกต์แรก

ก่อนเริ่มใช้งาน ต้องมีคอมพิวเตอร์ที่ใช้ Linux macOS หรือ Windows พร้อม AI coding agent ที่รองรับ และต้องติดตั้ง Python เวอร์ชัน 3.11 ขึ้นไปกับ Git ส่วนตัวจัดการแพ็กเกจแนะนำให้ใช้ uv หรือใช้ pipx หากต้องการติดตั้งไว้ใช้งานระยะยาว

ติดตั้งเครื่องมือบรรทัดคำสั่ง specify-cli ได้สองทาง ทางแรกใช้ git โดยระบุ release tag ที่ต้องการ

uv tool install specify-cli --from git+https://github.com/github/[email protected]

ให้เปลี่ยน vX.Y.Z เป็น tag ของรุ่นที่ต้องการ โดยต้องคง v ด้านหน้าไว้เสมอ อีกทางคือติดตั้งจาก PyPI โดยตรง ซึ่งใช้คำสั่งสั้นกว่า แต่ไม่ได้ล็อกรุ่นไว้

uv tool install specify-cli

เมื่อติดตั้งคำสั่ง specify แล้ว สร้างโปรเจกต์ใหม่ได้ด้วยคำสั่งสองบรรทัด บรรทัดแรกจะสร้างโฟลเดอร์พร้อมไฟล์ที่ Spec Kit ต้องใช้ และเลือก AI coding agent ที่จะเชื่อมต่อผ่าน --integration

specify init my-project --integration copilot
cd my-project

จากนั้นเปิด AI coding agent ขึ้นมาในโฟลเดอร์นี้ แล้วเริ่มจาก /speckit.constitution ได้เลย

การดูแล CLI ใช้คำสั่งอีกชุดหนึ่ง

specify self check
specify self upgrade --dry-run
specify self upgrade
specify self upgrade --tag vX.Y.Z[suffix]

specify self check ใช้ตรวจว่ามีรุ่นใหม่หรือไม่ โดยไม่เปลี่ยนแปลงอะไรในเครื่อง ส่วน specify self upgrade --dry-run จะแสดงให้ดูก่อนว่าหากอัปเกรดจริงจะเกิดอะไรขึ้น ขณะที่ specify self upgrade จะอัปเกรดทันทีโดยไม่ถามยืนยัน และตรวจเองว่าตอนติดตั้งใช้ uv tool หรือ pipx หากต้องการล็อกไว้ที่รุ่นใดรุ่นหนึ่ง ให้ต่อท้ายด้วย --tag และ tag ที่ต้องการ ถ้าการติดตั้งใช้เวลานานเกินไป สามารถใช้ตัวแปรสภาพแวดล้อม SPECIFY_UPGRADE_TIMEOUT_SECS เพื่อกำหนดเวลาสูงสุดได้ ค่าเริ่มต้นคือไม่จำกัดเวลา และกด Ctrl+C เพื่อหยุดได้

ใช้กับ AI coding agent ตัวไหนได้บ้าง

Spec Kit ทำงานร่วมกับ AI coding agent ได้มากกว่า 30 ตัว ทั้งแบบที่รันบนบรรทัดคำสั่งและแบบที่อยู่ใน IDE ใช้ specify integration list เพื่อตรวจดูว่า Spec Kit รุ่นที่ติดตั้งอยู่รองรับ agent ใดบ้าง

รูปแบบการเรียกคำสั่งต่างกันเล็กน้อยในแต่ละ agent ตามเอกสารของโปรเจกต์ agent ส่วนใหญ่แสดงคำสั่งของ Spec Kit เป็น slash command ในรูปแบบ /speckit.* ส่วน Codex CLI ที่รันในโหมด skills จะใช้ $speckit-* แทน สำหรับ GitHub Copilot CLI ให้พิมพ์ /agents เพื่อเลือก agent หรือสั่งโดยตรงในพรอมป์ก็ได้

สำหรับ agent ที่รองรับโหมด skills หากเติม --integration <agent> --integration-options="--skills" ตอนสั่ง specify init ระบบจะติดตั้ง agent skill แทนไฟล์พรอมป์แบบ slash command จึงอาจเห็นคำสั่งเดียวกันในสองรูปแบบ

ปรับ Spec Kit ให้เข้ากับวิธีทำงานของทีม

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

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

extension ใช้เพิ่มคำสั่งและเทมเพลตใหม่ ตัวอย่างที่ยกไว้มีทั้งการเชื่อมต่อกับ Jira การรีวิวโค้ดหลังเขียนเสร็จ การติดตามความเชื่อมโยงของการทดสอบตามแนวทาง V-Model และการตรวจสุขภาพโปรเจกต์ ค้นหาและติดตั้งได้ด้วย specify extension search แล้วตามด้วย specify extension add <extension-name>

preset ใช้เปลี่ยนวิธีทำงานของ Spec Kit โดยไม่เพิ่มความสามารถใหม่ แต่จะเขียนทับเทมเพลตและคำสั่งที่มีอยู่ ตัวอย่างเช่น เปลี่ยนรูปแบบสเปกให้เหมาะกับงานด้านการกำกับดูแล เปลี่ยนคำศัพท์ให้ตรงกับขอบเขตงาน ปรับกระบวนการให้เข้ากับวิธีทำงานแบบ Agile Kanban Waterfall jobs-to-be-done หรือ domain-driven design เพิ่มขั้นรีวิวความปลอดภัยไว้ในแผน เรียงงานโดยให้เขียนเทสต์ก่อน หรือแปลทั้งเวิร์กโฟลว์เป็นภาษาอื่น คำสั่งที่ใช้คือ specify preset search และ specify preset add <preset-name> นอกจากนี้ยังใช้ preset หลายตัวพร้อมกันได้โดยกำหนดลำดับความสำคัญไว้

ยกทั้งบทบาทมาลงทีเดียวด้วย bundle

bundle รวม extension preset ขั้นตอน และเวิร์กโฟลว์ที่คัดเลือกไว้เป็นชุดเดียว มีเลขเวอร์ชันกำกับ และเชื่อมโยงกับบทบาทในทีม เช่น product manager, business analyst, security researcher หรือ developer จึงติดตั้งทุกอย่างที่จำเป็นสำหรับบทบาทนั้นได้ด้วยคำสั่งเดียว

รายละเอียดของแต่ละ bundle อยู่ในไฟล์ manifest ชื่อ bundle.yml ซึ่งผู้สร้าง bundle เป็นผู้เขียน หาก bundle ไม่ได้ระบุ integration ไว้ ระบบจะไม่ผูกกับ agent ตัวใดตัวหนึ่ง แต่จะใช้ integration ที่โปรเจกต์ตั้งไว้แล้วแทน

คำสั่งสำหรับจัดการ bundle มีตั้งแต่ค้นหาจนถึงถอนออก

specify bundle search [<query>]
specify bundle info <bundle-id>
specify bundle install <bundle-id>
specify bundle list
specify bundle update <bundle-id>
specify bundle remove <bundle-id>

bundle ที่นำมาใช้ได้มาจากแคตตาล็อกหลายแหล่งซึ่งเรียงลำดับไว้ เริ่มจากแคตตาล็อกของโปรเจกต์ ตามด้วยของผู้ใช้และของที่มากับเครื่องมือ แต่ละแหล่งกำหนดได้สองแบบ คือ install-allowed ที่อนุญาตให้ติดตั้ง หรือ discovery-only ที่แสดงในผลค้นหาและหน้าข้อมูลเท่านั้น แต่ติดตั้งไม่ได้

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

หากต้องการดูตัวอย่างก่อนใช้งาน ในรีโปมีไฟล์ manifest ตัวอย่างสี่ไฟล์อยู่ที่ examples/bundles/ ครบทั้งสี่บทบาทข้างต้น

งานใหม่ งานเก่า และของที่ต้องแยกกันอัปเดต

กระบวนการนี้รองรับงานสามแบบ แบบแรกคือเริ่มงานจากศูนย์หรือที่เรียกว่างานกรีนฟิลด์ แบบที่สองคือลองหลายทางเลือกพร้อมกัน โดยสร้างระบบตามแต่ละแนวทาง (implementation) ควบคู่กันแล้วนำมาเปรียบเทียบ และแบบที่สามคือต่อยอดของเดิมทีละรอบ ซึ่งรวมถึงการยกเครื่องระบบเก่าด้วย

สำหรับโปรเจกต์ที่มีงานเดิมอยู่แล้ว ควรแยกการอัปเดตเครื่องมือออกจากการแก้เอกสารของฟีเจอร์ เพื่อไม่ให้สองเรื่องปะปนกัน เมื่ออัปเกรด Spec Kit ให้รีเฟรชเฉพาะไฟล์ที่เครื่องมือดูแล ส่วนไฟล์ใน specs/ ให้แก้เมื่อสิ่งที่ต้องการให้ระบบทำเปลี่ยนไปจริงๆ เมื่อตรวจย้อนหลังจึงแยกได้ว่าไฟล์ใดเปลี่ยนเพราะเครื่องมือ และไฟล์ใดเปลี่ยนเพราะความต้องการเปลี่ยนไป

Spec Kit ปล่อยออกมาภายใต้สัญญาอนุญาตแบบ MIT และในหน้าโปรเจกต์ระบุไว้ว่างานชิ้นนี้ได้รับอิทธิพลจากผลงานและงานวิจัยของ John Lam และเป็นการต่อยอดจากงานเหล่านั้น

ที่มา: โปรเจกต์ github/spec-kit บน GitHub