การพัฒนาโดยยึด Spec เป็นหลัก
เขียน Spec ก่อนสั่งงาน AI Coding Agent
Spec Kit เป็นโปรเจกต์โอเพนซอร์สของ GitHub เอง คู่มือนี้จัดทำอย่างอิสระ ไม่ได้เกี่ยวข้องหรือได้รับการรับรองจาก GitHub
ความหงุดหงิดส่วนใหญ่เวลาใช้ AI coding agent มักมาจากต้นเหตุเดียวกัน คือคำสั่งที่คลุมเครือให้ผลลัพธ์ที่คลุมเครือ และเรามารู้ว่าตัวเองต้องการอะไรจริงๆ ก็ตอนอ่านโค้ดที่ไม่ตรงกับที่คิดไว้ Spec ช่วยจัดลำดับขั้นตอนใหม่ ก่อนส่งพรอมต์แรก ให้เขียนสามอย่างสั้นๆ ด้วยภาษาธรรมดา ได้แก่ สิ่งนี้ควรทำอะไร ทำให้ใคร และเกณฑ์ตรวจเฉพาะเจาะจงที่บอกว่างานเสร็จแล้ว ทั้งหมดนี้ไม่ต้องเขียนโค้ดเป็น Spec Kit ของ GitHub ซึ่งเป็นชุดเครื่องมือโอเพนซอร์สที่ดูแลอยู่ใน repository ของ GitHub เอง สร้างกระบวนการที่เป็นระบบและทำซ้ำได้ให้ coding agent โดยยึดนิสัยนี้เป็นแกน มีเครื่องมือบรรทัดคำสั่งของตัวเอง และมีลำดับขั้นตอนที่ตั้งชื่อไว้ ตั้งแต่หลักการของโปรเจกต์ไปจนถึงงานที่ใช้ได้จริง คู่มือนี้อธิบาย spec สามส่วนที่เขียนเองได้ใน 5 นาที วิธีที่เวิร์กโฟลว์ของ Spec Kit แยกแนวคิดเดียวกันออกเป็นคำสั่งต่างๆ และจังหวะที่ควรติดตั้งชุดเครื่องมือเต็มรูปแบบ เทียบกับการเขียน spec เองเฉยๆ
Spec คือบันทึกสั้นๆ ด้วยภาษาธรรมดาที่เขียนก่อนขอให้ coding agent สร้างอะไรสักอย่าง ประกอบด้วย สิ่งนั้นทำอะไร ทำให้ใคร และเกณฑ์ตรวจว่าเสร็จที่พิสูจน์ได้ว่างานเสร็จแล้ว Spec Kit ของ GitHub ซึ่งเป็นชุดเครื่องมือโอเพนซอร์สที่สร้างใน repository ของ GitHub เอง ทำให้นิสัยนี้กลายเป็นเวิร์กโฟลว์ที่ทำซ้ำได้ มีคำสั่งสำหรับกำหนดหลักการ เขียน spec วางแผน แตกแผนเป็นงานย่อย ลงมือสร้าง และตรวจการลู่เข้า (converge) และเอกสารของโปรเจกต์ระบุชื่อ agent ที่เชื่อมต่อได้ รวมถึง Claude Code ของ Anthropic และ GitHub Copilot คุณไม่จำเป็นต้องใช้ชุดเครื่องมือนี้ก็ได้ประโยชน์ เพียงพิมพ์บันทึกสามส่วนเดียวกันเป็นข้อความแรกก็ใช้ได้กับ coding agent ตัวไหนที่คุณใช้อยู่
เผยแพร่เมื่อ
บทเรียนฟรี · ไม่ต้องมีบัญชีรู้จักกับ Claudeทำไมต้อง Claude?6 นาทีเริ่มบทเรียนฟรีสรุปประเด็นสำคัญ
- Spec คือสามอย่างที่เขียนก่อนพรอมต์แรก ได้แก่ สิ่งที่ agent ควรสร้าง สร้างให้ใคร และเกณฑ์ตรวจว่าเสร็จที่พิสูจน์ได้ว่างานเสร็จแล้ว
- Spec Kit ของ GitHub เป็นชุดเครื่องมือโอเพนซอร์สที่ใช้ได้ฟรี ภายใต้สัญญาอนุญาต MIT ตาม repository ของตัวเอง ทำให้นิสัยนี้เป็นหกคำสั่งที่ตั้งชื่อไว้ ได้แก่ constitution, spec, แผน, รายการงาน, การลงมือสร้าง และการลู่เข้า
- ไม่ต้องใช้ Spec Kit ก็ได้ประโยชน์จาก spec เพียงพิมพ์บันทึกสามส่วนเดียวกันเป็นข้อความแรกก็ใช้ได้ใน Claude Code, Codex ของ OpenAI, Copilot, Cursor ของ Anysphere หรือ coding agent ตัวอื่นๆ
- เอกสารการติดตั้งของ Spec Kit ระบุชื่อ coding agent ที่เชื่อมต่อได้ผ่านคีย์การเชื่อมต่อ (integration key) รวมถึง Claude Code และ GitHub Copilot และมีแนวทางสำหรับเพิ่ม agent อื่น
- การข้ามเกณฑ์ตรวจว่าเสร็จคือสาเหตุที่พบบ่อยที่สุดที่ทำให้ spec พังแบบเงียบๆ เพราะถ้าไม่มี ทั้งคุณและ agent ก็บอกไม่ได้ว่างานเสร็จจริงหรือยัง
คัดลอกไปใช้ได้เลย
พรอมต์ที่ใช้ได้ทันทีวันนี้
Spec สามส่วนสำหรับเปิดแชตแรก
นี่คือ spec ของสิ่งที่ฉันอยากให้คุณสร้าง ทำอะไร: สคริปต์ที่จัดเรียงไฟล์ในโฟลเดอร์ Downloads ของฉันเข้าโฟลเดอร์ย่อยที่ระบุวันที่ แยกตามประเภทไฟล์ ทำให้ใคร: ฉันคนเดียว รันเองด้วยมือจากเทอร์มินัล ไม่มีผู้ใช้อื่น เสร็จเมื่อ: เมื่อรันกับโฟลเดอร์ทดสอบที่มีไฟล์ตัวอย่าง 20 ไฟล์ ทุกไฟล์ถูกจัดเข้าโฟลเดอร์ย่อยที่ถูกต้อง ไม่มีอะไรนอกโฟลเดอร์นั้นถูกแตะต้อง และฉันย้อนกลับการรันทั้งหมดได้ด้วยคำสั่งเดียว ถ้ามีอะไรที่ต้องรู้ก่อนเริ่มสร้าง ถามฉันได้เลย
วางข้อความนี้เป็นข้อความแรกสุด ก่อนจะคุยโต้ตอบกันว่าควรทำงานอย่างไร
ให้ agent ช่วยเปลี่ยนไอเดียที่ยังคลุมเครือเป็น spec
ฉันอยากสร้างบางอย่าง แต่ไอเดียยังคลุมเครืออยู่ ภาพคร่าวๆ ที่ฉันนึกไว้คือ: อธิบายไอเดียคร่าวๆ ของคุณหนึ่งหรือสองประโยคตรงนี้ ก่อนเขียนโค้ดใดๆ ให้ถามฉันไปเรื่อยๆ จนกว่าคุณจะสรุปกลับมาให้ฉันได้เป็นสามส่วนสั้นๆ ว่าสิ่งนี้ทำอะไร ทำให้ใคร และเราสองคนจะรู้ได้อย่างไรว่าเสร็จแล้ว อย่าเริ่มสร้างจนกว่าฉันจะยืนยันครบทั้งสามส่วน
ใช้ได้ดีเมื่อคุณรู้ว่าปัญหาหน้าตาเป็นอย่างไร แต่ยังไม่ได้ลงรายละเอียด
ตรวจเกณฑ์ตรวจว่าเสร็จก่อนอนุมัติให้สร้าง
ก่อนเริ่มลงมือสร้าง ให้ลิสต์รายการตรวจเฉพาะเจาะจงที่คุณจะรันเพื่อพิสูจน์ว่างานเสร็จ ได้แก่ สิ่งที่จะทดสอบ ผลลัพธ์ที่คาดไว้ของแต่ละข้อ และอะไรที่นับว่าไม่ผ่าน ถ้ามีรายการตรวจข้อไหนที่คุณตรวจสอบเองจากภายในเซสชันนี้ไม่ได้ ให้บอกฉันตอนนี้ อย่าสมมติเอาว่าจะใช้ได้ทีหลัง
Agent ที่ดีควรตอบเรื่องนี้ได้อย่างละเอียดก่อนเขียนโค้ดแม้แต่บรรทัดเดียว
นิสัยหลัก
ทำไมต้องเขียน Spec ก่อนพรอมต์
การพิมพ์คำขอตรงเข้าไปใน coding agent รู้สึกเร็วกว่าการเขียนอะไรลงกระดาษก่อน และสำหรับงานเล็กจิ๋วจริงๆ ก็มักเร็วกว่าจริง ปัญหาเริ่มตอนงานนั้นตีความได้มากกว่าหนึ่งแบบอย่างสมเหตุสมผล agent เลือกแบบหนึ่ง สร้างตามนั้น และคุณมารู้ว่ามันเลือกผิดก็ตอนอ่านโค้ดที่เสร็จแล้ว ทุกรอบที่ต้องแก้หลังจากนั้นเสียเวลามากกว่าไม่กี่นาทีที่ใช้เขียน spec
Spec จัดลำดับขั้นตอนใหม่ ก่อนจะมีโค้ดใดๆ คุณเขียนสามอย่างด้วยภาษาธรรมดา ได้แก่ สิ่งนี้ควรทำอะไร ทำให้ใคร และเกณฑ์ตรวจว่าเสร็จที่พิสูจน์ได้ว่าใช้งานได้ ทั้งหมดนี้ไม่ใช่เอกสารเทคนิค ใกล้เคียงกับโน้ตที่คุณจะทิ้งไว้ให้ผู้ช่วยที่เก่งแต่ไม่เคยรู้จักคุณมาก่อน ละเอียดพอที่เขาจะไม่ต้องเดาในส่วนที่สำคัญ
ที่ได้ผลก็เพราะเหตุผลง่ายๆ agent เลิกเติมช่องว่างในคำขอของคุณด้วยข้อสันนิษฐานของตัวเอง เพราะช่องว่างเหลือน้อยลง และคุณก็เลิกต้องมาค้นพบว่าตัวเองต้องการอะไรจากการอ่านผลลัพธ์ของ agent ทีหลัง เพราะคุณเขียนมันลงไปแล้วก่อนจะขออะไรเลย
เรื่องนี้ไม่ได้เฉพาะกับเครื่องมือใดเครื่องมือหนึ่ง Claude Code, Codex, Copilot, Cursor และ coding agent ตัวอื่นๆ ล้วนทำงานด้วยหลักการพื้นฐานเดียวกัน คือรับคำสั่งภาษาธรรมดาเข้าไป แล้วให้โค้ดและคำสั่งออกมา Spec เปลี่ยนสิ่งที่ใส่เข้าไป ซึ่งเปลี่ยนสิ่งที่ได้กลับมา ไม่ว่าคุณจะคุยกับตัวไหน
Spec สามส่วน
สิ่งที่อยู่ใน Spec ที่เขียนได้ใน 5 นาที
สี่ส่วนสั้นๆ ด้วยภาษาธรรมดา ไม่ต้องเขียนโค้ดเป็นเลย
ทำอะไร
หนึ่งหรือสองประโยคที่อธิบายพฤติกรรม ไม่ใช่วิธีสร้าง เช่น “จัดไฟล์ตามประเภทเข้าโฟลเดอร์ที่ระบุวันที่” ไม่ใช่คำอธิบายว่าจะใช้ฟังก์ชันหรือไลบรารีอะไร
ทำให้ใคร
แค่คุณเอง รันด้วยมือใช่ไหม หรือเพื่อนร่วมงานที่ไม่เคยเห็นโปรเจกต์นี้มาก่อน คำตอบนี้เปลี่ยนสิ่งที่ต้องสร้างจริงๆ ได้มากกว่าคำอธิบายฟีเจอร์เสียอีก
เกณฑ์ตรวจว่าเสร็จ
เงื่อนไขเฉพาะเจาะจงที่ทดสอบได้ ซึ่งพิสูจน์ว่างานเสร็จแล้ว ส่วนนี้คือส่วนที่คนส่วนใหญ่ข้าม และเป็นส่วนที่สำคัญที่สุดเมื่อมีอะไรผิดพลาด
ข้อห้าม
ไม่บังคับ แต่ควรเพิ่มเมื่อเดิมพันสูงจริง คือสิ่งที่ agent ห้ามทำเด็ดขาด เช่น แตะไฟล์นอกโฟลเดอร์เดียว หรือส่งอะไรออกไปโดยอัตโนมัติ
โครงสร้างโอเพนซอร์สสำหรับเรื่องนี้
Spec Kit ของ GitHub เปลี่ยน Spec ให้เป็นเวิร์กโฟลว์อย่างไร
Spec Kit ของ GitHub เป็นชุดเครื่องมือโอเพนซอร์ส ดูแลอยู่ใน repository ของ GitHub เอง ภายใต้สัญญาอนุญาต MIT สร้างมาเพื่อให้ AI coding agent มีกระบวนการที่เป็นระบบ มีเทมเพลตที่นำกลับมาใช้ได้ และมีผลลัพธ์ที่บันทึกไว้ แทนที่จะเป็นบทสนทนาครั้งเดียวจบ ติดตั้งผ่านเครื่องมือบรรทัดคำสั่งของตัวเอง และ README ของโปรเจกต์อธิบายว่าเป็นชุดเครื่องมือสำหรับเริ่มต้นการพัฒนาโดยยึด spec เป็นหลัก หรือกระบวนการแบบมีโครงสร้างอื่นใดที่คุณอยากให้ agent ทำตาม
เวิร์กโฟลว์หลักแบบ spec-driven ตามเอกสารของโปรเจกต์เอง เดินผ่านลำดับหกคำสั่งที่ตั้งชื่อไว้ คำสั่งหนึ่งกำหนดหลักการของโปรเจกต์ อีกคำสั่งเขียนตัว spec เอง อีกคำสั่งเปลี่ยน spec เป็นแผนทางเทคนิค อีกคำสั่งแตกแผนเป็นรายการงานที่เรียงลำดับ อีกคำสั่งลงมือทำตามงานเหล่านั้นและเขียนโค้ดจริง และคำสั่งสุดท้ายตรวจว่าผลลัพธ์ลู่เข้าหา spec ได้ใกล้เคียงแค่ไหน แนวทางของโปรเจกต์คือให้รันทีละคำสั่ง ตรวจผลแต่ละขั้นก่อนไปต่อ และทำขั้นลงมือสร้างกับขั้นตรวจการลู่เข้าซ้ำจนกว่าจะรายงานว่างานลู่เข้าแล้ว แทนที่จะโยนงานทั้งหมดให้ agent ในครั้งเดียว
ชุดเครื่องมือนี้ยังมีส่วนขยายแยกต่างหากให้เพิ่มบนเวิร์กโฟลว์หลัก ตามเอกสารของตัวเองเช่นกัน ชุดหนึ่งเป็นคำสั่งที่สร้างขึ้นเพื่อประเมินและแก้บั๊กเฉพาะเรื่อง และอีกชุดสร้างขึ้นเพื่อพาไอเดียคร่าวๆ ผ่านการค้นคว้าและการกำหนดขอบเขต ก่อนตัดสินใจว่าจะสร้างจริงหรือไม่
ส่วน agent ที่เชื่อมต่อได้ เอกสารการติดตั้งของ Spec Kit ระบุหลายตัวด้วยคีย์การเชื่อมต่อที่ใส่ตอนติดตั้ง รวมถึง Claude Code และ GitHub Copilot และชี้ไปยังเอกสารแยกของตัวเองสำหรับเชื่อมต่อ agent อื่นนอกเหนือจากที่ระบุชื่อไว้โดยตรง ให้ถือว่ารายชื่อ agent ใดๆ รวมถึงรายชื่อนี้ เป็นภาพ ณ เวลาหนึ่งเท่านั้น ควรเปิดดูเอกสารล่าสุดของ Spec Kit ก่อนสรุปว่าเครื่องมือใดรองรับหรือไม่รองรับในปัจจุบัน
เวิร์กโฟลว์ทีละคำสั่ง
หกคำสั่งหลักของ Spec Kit
ตาม README ของโปรเจกต์เอง เวิร์กโฟลว์แบบ spec-driven เดินผ่านหกขั้นนี้ตามลำดับ โดยทำสองขั้นสุดท้ายซ้ำจนกว่าผลลัพธ์จะลู่เข้า
ตั้ง Constitution
คำสั่งที่บันทึกหลักการระดับโปรเจกต์ที่ agent ควรยึดถือในทุกอย่างที่ตามมา เขียนครั้งเดียวแล้วใช้ซ้ำในงานต่อๆ ไป
เขียน Spec
คำสั่งที่สร้างเอกสาร spec ขึ้นมาจริงๆ เป็นบันทึกภาษาธรรมดาแบบเดียวกับที่อธิบายไว้ข้างต้น แต่เก็บเป็นไฟล์ที่ใช้ซ้ำได้ แทนข้อความครั้งเดียวทิ้ง
วางแผนแนวทาง
คำสั่งที่เปลี่ยน spec เป็นแผนทางเทคนิค เลือกแนวทางก่อนจะมีโค้ดใดๆ เพื่อไม่ให้การตัดสินใจเรื่องการออกแบบไปซ่อนอยู่ในขั้นลงมือสร้าง
แตกเป็นงานย่อย
คำสั่งที่แยกแผนออกเป็นรายการงานที่เป็นรูปธรรมและเรียงลำดับ แต่ละงานเล็กพอจะตรวจแยกกันได้
ลงมือสร้าง
คำสั่งที่ทำตามรายการงานและเขียนโค้ด โดยใช้ทุกอย่างจากขั้นก่อนหน้าเป็นแนวทาง แทนการเริ่มจากศูนย์
ตรวจการลู่เข้า (Converge)
คำสั่งที่ตรวจว่าผลลัพธ์ตรงกับ spec ใกล้เคียงแค่ไหน ตามแนวทางของโปรเจกต์ ให้ทำขั้นลงมือสร้างกับขั้นตรวจการลู่เข้าซ้ำด้วยกันจนกว่าจะรายงานว่างานลู่เข้าแล้ว
โดยไม่ต้องติดตั้งอะไร
เขียน Spec ด้วยมือ ไม่ต้องใช้ชุดเครื่องมือ
สำหรับคนที่ไม่ใช่นักพัฒนาและกำลังสร้างของเล็กๆ ชิ้นเดียว การรันเวิร์กโฟลว์เต็มของ Spec Kit อาจมีพิธีรีตองมากกว่าที่งานต้องการ Spec สามส่วนเดี่ยวๆ ที่พิมพ์เป็นข้อความแรกถึง agent ตัวที่คุณใช้อยู่แล้ว ก็ทำงานส่วนใหญ่ได้ด้วยตัวเอง โดยไม่ต้องติดตั้งอะไร
วาง spec แล้วให้ agent ถามคำถามเพื่อความชัดเจนก่อนจะเขียนอะไร agent ที่เก่งจะถามเมื่อมีจุดไม่ชัด และ spec ให้สิ่งที่เป็นรูปธรรมแก่มันไว้ถาม แทนที่จะเดาเงียบๆ แล้วสร้างสิ่งที่ผิดด้วยความมั่นใจ
นิสัยแบบเรียบง่ายนี้พกพาไปได้ทุกที่ บันทึกสามส่วนเดียวกันใช้ได้ไม่ว่าคุณจะคุยกับ Claude Code, Codex, Copilot, Cursor หรือ coding agent ตัวอื่น เพราะไม่มีส่วนไหนพึ่งฟีเจอร์เฉพาะของเครื่องมือใดเครื่องมือหนึ่ง มันคือนิสัยที่คุณสร้างขึ้น ไม่ใช่ปลั๊กอินที่ติดตั้ง
จุดที่มักพลาด
ข้อผิดพลาดที่ทำให้ Spec ไร้ผล
การเขียน spec ช่วยได้น้อยกว่าที่ควรเมื่อมีข้อใดข้อหนึ่งเหล่านี้แทรกเข้ามา
ไม่มีเกณฑ์ตรวจว่าเสร็จ
Spec ที่ไม่มีวิธีตรวจว่าเสร็จ เพียงย้ายการเดาจากขั้นพรอมต์ไปอยู่ในขั้นรีวิว ซึ่งจับได้ยากกว่า
ใส่รายละเอียดการสร้างเข้าไป
การระบุภาษาโปรแกรมหรืออัลกอริทึมเฉพาะก่อนจะตัดสินใจว่าต้องการฟีเจอร์นั้นหรือไม่ ทำให้ spec กลายเป็นการออกแบบก่อนเวลาอันควร
เขียนหลังสร้างเสร็จ
Spec ที่ร่างให้ตรงกับโค้ดที่มีอยู่แล้ว เป็นเพียงการบันทึกสิ่งที่ถูกสร้างขึ้น มันจับปัญหาที่ถูกเขียนให้สอดคล้องกันไว้แล้วไม่ได้
หนึ่ง Spec หลายงาน
Spec ที่ครอบคลุมมากกว่าหนึ่งงานจริง จะกลบงานที่สำคัญจริงๆ ไว้ ควรให้แต่ละ spec ครอบคลุมงานเดียวที่ตรวจสอบได้
เมื่อไรควรใช้ชุดเครื่องมือ
Spec ธรรมดาหรือ Spec Kit เต็มรูปแบบ: เลือกอย่างไร
สำหรับงานเล็กชิ้นเดียว spec สามส่วนธรรมดาที่พิมพ์ลงแชตตรงๆ ก็เพียงพอ และเร็วกว่าการติดตั้งอะไรทั้งนั้น ตัวอย่างส่วนใหญ่ในคู่มือนี้เขียนมาสำหรับกรณีนั้นโดยเฉพาะ
Spec Kit เริ่มคุ้มกับค่าใช้จ่ายในการตั้งค่าเมื่อคุณทำแบบนี้ซ้ำในโปรเจกต์เดิม อยากให้หลักการของโปรเจกต์ถูกบังคับใช้อัตโนมัติกับทุกฟีเจอร์ใหม่ หรืออยากใช้โครงสร้างของส่วนขยายสำหรับแก้บั๊กหรือประเมินไอเดีย แทนการคิดโครงสร้างของตัวเองใหม่ทุกครั้ง
ไม่ว่าทางไหน ทักษะจริงๆ ก็เหมือนกัน คือบอกให้ได้ว่าสิ่งนี้ทำอะไร ทำให้ใคร และจะรู้ได้อย่างไรว่าเสร็จ ก่อนจะมีโค้ดแม้แต่บรรทัดเดียว ชุดเครื่องมือเพียงแค่ทำให้การจดสิ่งเหล่านี้เป็นไปอย่างสม่ำเสมอโดยอัตโนมัติ เมื่อนิสัยนี้เป็นสิ่งที่คุณหยิบมาใช้บ่อยพอจนคุ้มกับการทำให้เป็นอัตโนมัติ
ฝึกเขียน Spec ก่อนสร้างงาน
การเขียน spec ที่ชัดเจน และการให้คำสั่งประจำโปรเจกต์แก่ AI coding agent เป็นทักษะที่ใช้ได้กับทุกเครื่องมือในคู่มือนี้ บทเรียนฟรีของ Nightschool AI เรื่องไฟล์คำสั่งของโปรเจกต์พาทำเรื่องนี้โดยตรง โดยใช้ Claude Code เป็นตัวอย่าง
คำถามที่พบบ่อย
ในบริบทนี้ Spec คืออะไรกันแน่
บันทึกสั้นๆ ด้วยภาษาธรรมดาที่เขียนก่อนขอให้ coding agent สร้างอะไรสักอย่าง อย่างน้อยต้องครอบคลุมว่าสิ่งนั้นควรทำอะไร ทำให้ใคร และเกณฑ์ตรวจว่าเสร็จที่พิสูจน์ได้ว่างานเสร็จแล้ว ไม่ใช่เอกสารเทคนิค และไม่ต้องเขียนโค้ดเป็น
ต้องเขียนโค้ดเป็นไหมถึงจะเขียน Spec ได้
ไม่ต้อง Spec อธิบายพฤติกรรมและผลลัพธ์ด้วยภาษาธรรมดา ไม่ใช่วิธีสร้าง การอธิบายว่าเครื่องมือควรทำอะไรและจะรู้ได้อย่างไรว่าใช้งานได้ ไม่ต้องใช้ความรู้ด้านการเขียนโปรแกรม แม้ agent ที่สร้างจะเป็นฝ่ายเขียนโค้ดจริงก็ตาม
Spec Kit ของ GitHub คืออะไร
ชุดเครื่องมือโอเพนซอร์สภายใต้สัญญาอนุญาต MIT ที่ดูแลอยู่ใน repository ของ GitHub เอง ให้กระบวนการที่เป็นระบบและทำซ้ำได้แก่ AI coding agent โดยยึดการพัฒนาแบบ spec-driven เป็นแกน มีเครื่องมือบรรทัดคำสั่งของตัวเอง และมีลำดับหกคำสั่งที่ตั้งชื่อไว้ ตั้งแต่หลักการของโปรเจกต์ไปจนถึงการลงมือสร้างและการลู่เข้า
Spec Kit ใช้ได้กับ coding agent ตัวไหนบ้าง
ตามเอกสารการติดตั้งของตัวเอง คุณเชื่อมต่อ agent ตอนติดตั้งด้วยคีย์การเชื่อมต่อ เอกสารระบุชื่อ agent หลายตัวด้วยวิธีนี้ รวมถึง Claude Code และ GitHub Copilot และมีลิงก์ไปยังเอกสารของตัวเองสำหรับเชื่อมต่อตัวอื่น ควรเปิดดูเอกสารล่าสุดของ Spec Kit เพื่อดูรายชื่อที่ครบถ้วนและเป็นปัจจุบัน ก่อนสรุปว่าเครื่องมือใดรองรับ
คู่มือนี้เกี่ยวข้องกับ GitHub หรือไม่
ไม่เกี่ยวข้อง คู่มือนี้เป็นคู่มือการเรียนรู้ที่จัดทำอย่างอิสระ ไม่ได้เผยแพร่หรือรับรองโดย GitHub Spec Kit และ GitHub เป็นโปรเจกต์และเครื่องหมายการค้าของ GitHub เอง และกล่าวถึงในที่นี้เพื่ออธิบายอย่างถูกต้องเท่านั้น
Spec ต่างจากพรอมต์ที่ยาวขึ้นอย่างไร
พรอมต์ที่ยาวขึ้นก็ยังเป็นข้อความเดียวที่อธิบายงาน ส่วน spec เป็นบันทึกที่มีโครงสร้างสามส่วนเฉพาะ คือ ทำอะไร ทำให้ใคร และเกณฑ์ตรวจว่าเสร็จ ออกแบบมาให้อ่าน ยืนยัน และนำกลับมาใช้ซ้ำ ไม่ใช่พิมพ์ครั้งเดียวแล้วลืม
“เกณฑ์ตรวจว่าเสร็จ” (done-when) คืออะไรกันแน่
เงื่อนไขที่ทดสอบได้ซึ่งพิสูจน์ว่างานสร้างเสร็จแล้ว ได้แก่ สิ่งที่คุณจะตรวจ ผลลัพธ์ที่คาดไว้ของแต่ละข้อ และอะไรที่นับว่าไม่ผ่าน ถ้าไม่มีสิ่งเหล่านี้ ก็ไม่มีวิธีที่ตกลงร่วมกันได้ว่า agent ทำงานเสร็จจริงหรือเพียงแค่หยุดไป
ต้องติดตั้ง Spec Kit ถึงจะได้ประโยชน์จากนิสัยนี้ไหม
ไม่ต้อง เพียงพิมพ์ spec สามส่วนเดียวกันเป็นข้อความแรกถึง coding agent ตัวใดก็ได้ ไม่ว่า Claude Code, Codex, Copilot, Cursor หรือตัวอื่น ก็ได้ประโยชน์ส่วนใหญ่แล้วโดยไม่ต้องติดตั้งอะไร Spec Kit เป็นโครงสร้างที่ทำซ้ำได้สำหรับคนที่ทำเรื่องนี้บ่อย ไม่ใช่ข้อบังคับสำหรับการทำเลย
Spec Kit ใช้ฟรีไหม
ใช้ฟรี เป็นโปรเจกต์โอเพนซอร์สที่เผยแพร่ภายใต้สัญญาอนุญาต MIT ตาม repository ของตัวเอง และติดตั้งผ่านเครื่องมือบรรทัดคำสั่งของตัวเองที่ใช้ได้ฟรี
คำสั่งเขียน spec ของ Spec Kit สร้างอะไรออกมาจริงๆ
ตามเอกสารของโปรเจกต์เอง คำสั่งนี้สร้างเอกสาร spec ขึ้นมา ซึ่งเป็นบันทึกภาษาธรรมดาแบบเดียวกับที่อธิบายตลอดคู่มือนี้ บันทึกเป็นไฟล์ที่ใช้ซ้ำได้ในโปรเจกต์ของคุณ แทนที่จะพิมพ์ใหม่ลงแชตทุกครั้ง
เปลี่ยน Spec ให้เป็น AI Agent ตัวแรกของคุณ
บอกให้ได้ว่าสิ่งนี้ทำอะไร ทำให้ใคร และจะรู้ได้อย่างไรว่าเสร็จ แล้วค่อยสร้าง