Spec Kit ของ GitHub - พัฒนาซอฟต์แวร์คุณภาพสูงได้เร็วขึ้น

• การพัฒนาแบบขับเคลื่อนด้วยสเปก (Spec-Driven Development): แนวทางที่ยกระดับ สเปก (Spec) ซึ่งเดิมเป็นเพียงเครื่องมือช่วยในกระบวนการพัฒนาแบบดั้งเดิม ให้กลายเป็น สเปกที่รันได้จริง เพื่อสร้าง การติดตั้งใช้งานที่ทำงานได้จริง จากสเปกโดยตรง
  • เปลี่ยนจากแนวปฏิบัติที่ให้โค้ดเป็นศูนย์กลาง ไปสู่การเน้น การพัฒนาที่ขับเคลื่อนด้วยเจตนา ซึ่งกำหนดก่อนว่า อะไร และ ทำไม แล้วจึงค่อยลงรายละเอียดว่า อย่างไร
  • แนวคิดหลักคือใช้สเปกเพื่อสร้างผลลัพธ์ที่สอดคล้องกัน และ ทำงานซ้ำ ๆ ให้เป็นอัตโนมัติ เพื่อให้นักพัฒนามุ่งเน้นกับปัญหาของผลิตภัณฑ์ได้มากขึ้น
• Spec Kit คือชุดเครื่องมือที่ช่วยแปลง สเปก ให้เป็น ผลลัพธ์ที่นำไปปฏิบัติได้จริง และช่วยทำให้การติดตั้งใช้งานเป็นอัตโนมัติ
• หลังติดตั้งแล้ว ใช้ /specify เพื่ออธิบาย อะไร/ทำไม, ใช้ /plan เพื่อประกาศ สแตก/สถาปัตยกรรม, และใช้ /tasks เพื่อสร้าง หน่วยงานงาน
• เป้าหมายคือช่วยให้องค์กรหลุดพ้นจากการเขียน โค้ดทั่วไปที่ไม่สร้างความแตกต่าง และหันไปโฟกัสที่ สถานการณ์ของผลิตภัณฑ์ มากขึ้น เป็นเฟรมเวิร์กเชิงทดลองที่ต้องการยกระดับทั้งคุณภาพและความเร็วผ่านแนวทางที่ขับเคลื่อนด้วยสเปก

ปรัชญาหลัก: Core philosophy

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

กระบวนการขับเคลื่อนด้วยสเปกด้วย Spec Kit

• Spec Kit ทำให้สเปกเป็นศูนย์กลางของกระบวนการวิศวกรรม โดยขับเคลื่อนการติดตั้งใช้งาน เช็กลิสต์ และการแตกงานย่อย ขณะที่นักพัฒนาทำหน้าที่หลักในการสั่งการ
  • เอเจนต์เขียนโค้ดเป็นผู้รับผิดชอบงานเขียนส่วนใหญ่
• กระบวนการประกอบด้วย 4 ขั้นตอน โดยแต่ละขั้นมีจุดตรวจสอบที่ชัดเจน และจะไม่ย้ายไปขั้นถัดไปจนกว่างานปัจจุบันจะได้รับการตรวจสอบครบถ้วน
• ขั้น Specify: เมื่อให้คำอธิบายระดับสูง เอเจนต์เขียนโค้ดจะสร้างสเปกแบบละเอียด ซึ่งเน้นที่เส้นทางของผู้ใช้ ประสบการณ์ และตัวชี้วัดความสำเร็จ มากกว่าสแตกเทคโนโลยี
  • ระบุว่าใครคือผู้ใช้ แก้ปัญหาอะไร มีรูปแบบการโต้ตอบอย่างไร และผลลัพธ์สำคัญคืออะไร
  • สิ่งนี้อยู่ในรูปของ อาร์ติแฟกต์ที่มีชีวิต ซึ่งพัฒนาไปตามการเรียนรู้เกี่ยวกับผู้ใช้
• ขั้น Plan: เมื่อระบุสแตก สถาปัตยกรรม และข้อจำกัดที่ต้องการ เอเจนต์เขียนโค้ดจะสร้างแผนทางเทคนิคแบบครอบคลุม
  • รวมถึงเทคโนโลยีมาตรฐานของบริษัท การเชื่อมต่อกับระบบเลกาซี การปฏิบัติตามข้อกำหนด และเป้าหมายด้านประสิทธิภาพ
  • สามารถขอแผนได้หลายแบบเพื่อเปรียบเทียบกัน และหากให้เอกสารภายใน ก็สามารถผสานแพตเทิร์นสถาปัตยกรรมได้โดยตรง
• ขั้น Tasks: จากสเปกและแผน เอเจนต์เขียนโค้ดจะแตกงานออกเป็นชิ้นเล็ก ๆ ที่สามารถตรวจทานได้
  • แต่ละงานสามารถติดตั้งใช้งานและทดสอบได้อย่างอิสระ และออกแบบมาให้ AI ตรวจสอบและติดตามงานได้
  • ตัวอย่างเช่น แทนที่จะเป็น "สร้างระบบยืนยันตัวตน" ก็จะเป็น "สร้างเอนด์พอยต์สมัครผู้ใช้ที่ตรวจสอบรูปแบบอีเมล" ที่เฉพาะเจาะจงกว่า
• ขั้น Implement: เอเจนต์เขียนโค้ดจะจัดการงานทีละงานหรือแบบขนาน โดยนักพัฒนาจะตรวจทานการเปลี่ยนแปลงที่มีขอบเขตชัดเจน
  • สเปกบอกว่าจะสร้าง อะไร, แผนบอกว่าจะสร้าง อย่างไร, และงานบอกว่าจะลงมือกับ อะไร
• ในแต่ละขั้น นักพัฒนาจะทำหน้าที่ ตรวจสอบ ด้วยการทบทวนและขัดเกลา ว่าสเปกจับเจตนาได้ถูกต้องหรือไม่ แผนคำนึงถึงข้อจำกัดจริงหรือไม่ และมีส่วนที่ขาดหรือกรณีขอบหรือไม่

วิธีใช้ Spec Kit ในเวิร์กโฟลว์แบบเอเจนต์

• Spec Kit ทำงานร่วมกับเอเจนต์เขียนโค้ดอย่าง GitHub Copilot, Claude Code, Gemini CLI โดยใช้ชุดคำสั่งสั้น ๆ เพื่อสั่งงานเอเจนต์และสร้างอาร์ติแฟกต์
  • สิ่งนี้ช่วยแปลงพรอมป์ต์ที่คลุมเครือให้กลายเป็นเจตนาที่ชัดเจนและนำไปปฏิบัติได้อย่างน่าเชื่อถือ
• หลังเริ่มต้นโปรเจ็กต์ หากให้พรอมป์ต์ระดับสูงด้วยคำสั่ง /specify เอเจนต์เขียนโค้ดจะสร้างสเปกทั้งชุด โดยเน้นที่ "อะไร" และ "ทำไม" ของโปรเจ็กต์
• ด้วยคำสั่ง /plan เมื่อให้ทิศทางทางเทคนิคระดับสูง เอเจนต์เขียนโค้ดจะสร้างแผนแบบละเอียดที่เคารพทั้งสถาปัตยกรรมและข้อจำกัด
• ด้วยคำสั่ง /tasks จะทำการแตกสเปกและแผนออกเป็นรายการงานที่ลงมือทำได้ และเอเจนต์เขียนโค้ดจะนำสิ่งเหล่านี้ไปใช้เพื่อทำให้ข้อกำหนดของโปรเจ็กต์เกิดขึ้นจริง

ขั้นตอนการพัฒนา: Development phases

• 0-to-1 (กรีนฟิลด์): รองรับลำดับการทำงานแบบ สร้างสเปก → วางแผน → สร้างแอประดับพร้อมใช้งานจริงในโปรดักชัน จากข้อกำหนดระดับสูง
• ขั้นสำรวจเชิงสร้างสรรค์: เน้นกระบวนการทดลอง สแตก/สถาปัตยกรรม และ แพตเทิร์น UX ที่หลากหลายผ่าน การติดตั้งใช้งานแบบขนาน
• ขั้นปรับปรุงแบบค่อยเป็นค่อยไป (บรাউনฟิลด์): การพัฒนาแบบวิวัฒนาการที่ทำซ้ำด้วย การเพิ่มฟีเจอร์, การทำระบบเลกาซีให้ทันสมัย, และ การปรับกระบวนการ

3 สถานการณ์ที่แนวทางนี้ทำงานได้ดี

• กรีนฟิลด์ (zero-to-one): เมื่อต้องเริ่มโปรเจ็กต์ใหม่ แทนที่จะลงมือเขียนโค้ดทันที จะสร้างสเปกและแผนไว้ก่อนเพื่อให้ AI สร้างสิ่งที่ตั้งใจจริง ๆ และให้ผลลัพธ์ที่ปรับให้เหมาะเฉพาะ แทนโซลูชันทั่วไปตามแพตเทิร์นมาตรฐาน
• งานฟีเจอร์บนระบบเดิม (N-to-N+1): เมื่อต้องเพิ่มฟีเจอร์ในโค้ดเบสที่ซับซ้อน ใช้สเปกเพื่ออธิบายปฏิสัมพันธ์ของฟีเจอร์ใหม่กับระบบเดิมให้ชัดเจน และใช้แผนเพื่อเข้ารหัสข้อจำกัดด้านสถาปัตยกรรม ทำให้ได้โค้ดที่ดูกลมกลืนเหมือนเป็นส่วนหนึ่งของระบบมาตั้งแต่ต้น
  • สิ่งนี้ทำให้การพัฒนาต่อเนื่องเร็วขึ้นและปลอดภัยขึ้น แต่อาจต้องใช้เทคนิค context engineering ขั้นสูง
• การทำระบบเลกาซีให้ทันสมัย: เมื่อสร้างระบบเลกาซีขึ้นใหม่ในกรณีที่เจตนาเดิมสูญหายไป กระบวนการของ Spec Kit จะช่วยจับตรรกะทางธุรกิจที่จำเป็นไว้ในสเปกสมัยใหม่ และวางแผนสถาปัตยกรรมใหม่ เพื่อให้ AI สร้างขึ้นใหม่โดยไม่มีหนี้ทางเทคนิค

Prerequisites

• ต้องใช้ Linux/macOS หรือ WSL2 บน Windows
• เลือก AI agent จาก Claude Code, GitHub Copilot, Gemini CLI, Cursor

[edunga1]

ทำให้นึกถึง copilot workspace เลยครับ

[cocofather]

ดูเหมือนว่านี่จะกลายเป็นรากฐานของการเขียนโปรแกรมด้วย AI บนภาษาธรรมชาติ

[tested]

ข้อดีของ Spec Kit ของ GitHub คือสามารถใช้ได้กับ GitHub Copilot ด้วย
เพราะสร้างโดย GitHub เอง ก็คงเป็นเรื่องธรรมดา? แต่ก่อนหน้านี้เครื่องมืออื่น ๆ หลายตัวมักอิงกับ Claude

[skageektp]

ทำให้นึกถึง Kiro IDE เลย

[kandk]

น่าสนใจดีนะ ฟังดูมีเหตุผลเหมือนกัน

[xguru]

ลิงก์แนะนำรายละเอียด SDD ตรงกลางบทความนี่เนื้อหาดีมากครับ ด้านล่างนี้คือสิ่งที่ลองสรุปด้วย AI มาให้ครับ

การพัฒนาแบบขับเคลื่อนด้วยสเปก (Specification-Driven Development, SDD)

The Power Inversion

• เป็นการกลับด้านจากแนวทางที่มีโค้ดเป็นศูนย์กลางและให้ PRD·เอกสารออกแบบเป็นตัวเสริม โดยให้ สเปกเป็นต้นฉบับ และโค้ดเป็น ผลลัพธ์ที่แสดงออก ซึ่งถูกนำไปพัฒนาบนภาษา·เฟรมเวิร์กเฉพาะ
  • เสนอการวินิจฉัยว่าช่องว่าง ถาวรระหว่างสเปกกับการพัฒนา นั้นยากจะปิดได้ด้วยการเพิ่มเอกสารหรือเพิ่มกระบวนการ
  • หาก สเปกที่รันได้ และ แผนการพัฒนา เป็นตัวสร้างโค้ด ช่องว่างนั้นก็จะหายไปและจะเหลือเพียง การแปลง เท่านั้น
• AI ทำให้การตีความสเปกที่ซับซ้อนและการวางแผนการพัฒนาเป็นไปได้ แต่ การสร้างแบบไร้โครงสร้างจะก่อให้เกิดความสับสน ดังนั้น SDD จึงใช้ โครงสร้างที่แม่นยำและราวกันตก เพื่อคุมคุณภาพ
• การบำรุงรักษาคือการทำให้สเปกวิวัฒน์ต่อไป โดยเจตนาของการพัฒนาถูกแสดงผ่าน ภาษาธรรมชาติ·ทรัพย์สินด้านดีไซน์·หลักการแกนกลาง และโค้ดอยู่ในตำแหน่งของ ไมล์สุดท้าย
• การดีบักให้ความสำคัญกับ การแก้สเปก·แผนการพัฒนา ก่อนการแก้โค้ดที่ผิด และรีแฟกเตอร์ถูกนิยามใหม่ให้หมายถึง การจัดโครงสร้างความชัดเจนขึ้นใหม่

The SDD Workflow in Practice

• กลั่นไอเดียให้เป็น PRD ผ่าน การโต้ตอบแบบสนทนากับ AI และ AI จะช่วยทำให้ คำถาม·เคสขอบเขต·เกณฑ์การยอมรับ ชัดเจนขึ้น
  • เปลี่ยนความต้องการและการออกแบบให้เป็น กิจกรรมต่อเนื่อง รองรับ การทำงานกับสเปกบนพื้นฐาน branch ระดับทีม พร้อมการรีวิวและการจัดเวอร์ชัน
• รีเสิร์ชเอเจนต์ จะสำรวจความเข้ากันได้ของไลบรารี ประสิทธิภาพ ความปลอดภัย และ ข้อจำกัดขององค์กร (มาตรฐาน DB·การยืนยันตัวตน·นโยบายการ deploy) แล้วสะท้อนเข้าไปในสเปกโดยอัตโนมัติ
• สร้าง แผนการพัฒนา จาก PRD เพื่อแมปความต้องการกับการตัดสินใจทางเทคนิคแบบ ตรวจสอบย้อนกลับได้ และให้ AI คอยตรวจสอบ ความขัดแย้ง·ความกำกวม·สิ่งที่ตกหล่น อย่างต่อเนื่อง
• เมื่อสเปกและแผนมีความเสถียรมากพอจึงเริ่ม สร้างโค้ด โดยในช่วงแรกจะใช้ การสร้างเชิงสำรวจ เพื่อตรวจสอบความเป็นไปได้
  • แนวคิดของโดเมนจะถูกแปลงเป็น โมเดลข้อมูล ยูสเซอร์สตอรีเป็น API endpoint และสถานการณ์การยอมรับเป็น เทสต์
• เมตริก·อินซิเดนต์ จากช่วงปฏิบัติการจะอัปเดตสเปกเพื่อสะท้อนในการสร้างรอบถัดไป โดยคอขวดด้านประสิทธิภาพจะถูกยกระดับเป็น ข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน และช่องโหว่จะถูกยกระดับเป็น ข้อจำกัดส่วนกลาง

Why SDD Matters Now

• จุดเปลี่ยนด้านความสามารถของ AI: ตอนนี้สามารถสร้าง โค้ดที่ทำงานได้ จากสเปกภาษาธรรมชาติอย่างน่าเชื่อถือ และการทำส่วนที่เป็น งานเชิงกลของการแปลไปสู่การพัฒนา ให้เป็นอัตโนมัติ ช่วยหนุน การสำรวจ·การเพิ่มพลังความคิดสร้างสรรค์
• ความซับซ้อนที่พุ่งสูง: เมื่อมีบริการ เฟรมเวิร์ก และ dependency จำนวนมาก การรักษา ความสอดคล้องระหว่างเจตนากับการพัฒนา จึงยากขึ้น ทำให้ต้องมี การจัดแนวแบบขับเคลื่อนด้วยสเปก ของ SDD
• การเปลี่ยนแปลงที่เร็วขึ้น: ในสถานการณ์ที่ pivot บ่อย SDD จัดการการเปลี่ยนแปลงด้วย การสร้างใหม่อย่างเป็นระบบ แทน การไล่แก้เอกสาร-ดีไซน์-โค้ดด้วยมือ
  • ตัวอย่างเช่น ทำให้ what-if simulation และการพัฒนาแบบขนานทำได้ จึงเพิ่ม ความคล่องตัวในการตัดสินใจ

Core Principles

• สเปก=ภาษากลางร่วมกัน: สเปกคือผลลัพธ์ระดับชั้นหนึ่ง โค้ดคือ การแสดงออก ของสแตกเฉพาะ และการบำรุงรักษาคือการ ทำให้สเปกวิวัฒน์
• สเปกที่รันได้: ใช้สเปกที่มีระดับ ถูกต้อง·ครบถ้วน·ไม่กำกวม เพื่อสร้าง ระบบที่ทำงานได้
• การขัดเกลาอย่างต่อเนื่อง: ไม่ใช่เกตแบบครั้งเดียวจบ แต่เป็น การตรวจสอบความสอดคล้องตลอดเวลา
• บริบทจากการวิจัย: รวบรวม ข้อมูลด้านประสิทธิภาพ ความปลอดภัย และข้อจำกัดขององค์กรอย่าง ต่อเนื่อง แล้วฉีดกลับเข้าไปในสเปก
• ฟีดแบ็กสองทาง: ความเป็นจริงในการปฏิบัติการจะกลายเป็น อินพุตสำหรับอัปเดตสเปก
• การแตก branch เพื่อการสำรวจ: รองรับการสร้าง หลายแนวทางการพัฒนา จากสเปกเดียวกันตามเป้าหมายการปรับให้เหมาะสม เช่น ประสิทธิภาพ·การบำรุงรักษา·UX·ต้นทุน

Implementation Approaches

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

Streamlining SDD with Commands

• /specify: แปลงคำอธิบายฟีเจอร์ให้เป็น สเปก แบบมีโครงสร้าง และทำ การใส่หมายเลขอัตโนมัติ, การสร้าง branch, การจัดโครง ไดเรกทอรีตามเทมเพลต โดยอัตโนมัติ
• /plan: วิเคราะห์สเปก → ตรวจ การปฏิบัติตามรัฐธรรมนูญ → แปลเป็นเทคนิค → จัดทำเอกสาร โมเดลข้อมูล·สัญญา API·สถานการณ์การทดสอบ → สร้าง การตรวจสอบ quickstart
• /tasks: อ่าน plan.md และดีไซน์ที่เกี่ยวข้องเพื่อสร้าง รายการงานที่นำไปปฏิบัติได้ พร้อม การระบุงานที่ทำขนานกันได้ และการจัดกลุ่มขนานที่ปลอดภัย
• ตัวอย่าง: ฟีเจอร์แชต
  • ยกตัวอย่างโฟลว์ที่ลดงานทำเอกสารราว ~12 ชั่วโมงของแนวทางดั้งเดิม ให้เหลือการจัดองค์ประกอบประมาณ 15 นาที ด้วยการทำ สเปก·แผน·งาน แบบอัตโนมัติ
  • ผลลัพธ์ประกอบด้วย สเปก, แผนการพัฒนาและเหตุผล, สัญญา API·โมเดลข้อมูล, สถานการณ์ quickstart, tasks.md ที่ถูก จัดการเวอร์ชันไว้ใน branch

The Power of Structured Automation

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

Template-Driven Quality

• ป้องกันการแทรกเข้ามาเร็วเกินไปของรายละเอียดการพัฒนา: รักษาระดับนามธรรมด้วยกฎที่เน้น WHAT/WHY และตัด HOW ออก
• บังคับการทำเครื่องหมายความไม่แน่นอน: ใช้ marker [NEEDS CLARIFICATION] เพื่อ ห้ามการเดา และกระตุ้นให้ ตั้งคำถามอย่างชัดเจน
• การตรวจทานตนเองด้วยเช็กลิสต์: ใช้การยืนยัน ความครบถ้วน·ความชัดเจน·เกณฑ์การยอมรับที่วัดได้ เป็น เกตคุณภาพ
• Constitution gate: ใช้การตรวจล่วงหน้าใน ขั้นก่อนหน้า (-1) เช่น เกตความเรียบง่าย (≤3 โปรเจ็กต์), เกตต่อต้าน abstraction (ใช้เฟรมเวิร์กโดยตรง), เกตให้ความสำคัญกับการอินทิเกรตก่อน (ทำสัญญา·contract test ก่อน)
• การจัดการรายละเอียดแบบแบ่งชั้น: แยกรายละเอียดหรือโค้ดที่มากเกินไปไปไว้ใน implementation-details/ เพื่อ รักษาความอ่านง่าย
• ความมาก่อนของการทดสอบ: รับประกัน ความสามารถในการตรวจสอบได้ ด้วยกฎ สร้างไฟล์และทดสอบก่อน ตามลำดับ contract→integration→E2E→unit
• ยับยั้งฟีเจอร์ที่เกิดจากสมมติฐาน·การคาดเดา: เสริมการควบคุมขอบเขตด้วย การห้ามฟีเจอร์เชิงคาดเดา และการระบุ เงื่อนไขล่วงหน้าในแต่ละขั้น

The Constitutional Foundation

• ใช้ รัฐธรรมนูญการพัฒนา ที่ทำให้ทุกการพัฒนา สม่ำเสมอ·เรียบง่าย·คุณภาพสูง ด้วยหลักการที่เปลี่ยนไม่ได้ใน memory/constitution.md
  • Article I: Library-First — ทุกฟีเจอร์เริ่มจาก ไลบรารีอิสระ เพื่อให้ได้ ความเป็นโมดูล
  • Article II: CLI Mandate — ทุกไลบรารีต้องเปิดเผย CLI interface ที่รองรับ อินพุต/เอาต์พุตแบบข้อความ·JSON เพื่อรับประกัน การสังเกตได้ และ ความง่ายต่อการทดสอบ
  • Article III: Test-First — ห้ามพัฒนา ก่อนการอนุมัติเทสต์และการยืนยันความล้มเหลว (red) โดยยึดหลัก นิยามพฤติกรรมก่อน
  • Articles VII & VIII: ความเรียบง่าย·ต่อต้าน abstraction — ลดจำนวนโปรเจ็กต์ให้ต่ำสุด และ เชื่อใจการใช้เฟรมเวิร์กโดยตรง เพื่อ ยับยั้ง over-engineering
  • Article IX: ทดสอบการอินทิเกรตก่อน — ให้ความสำคัญกับการทดสอบที่ ใกล้เคียงสภาพแวดล้อมจริง และบังคับให้ contract test มาก่อนการพัฒนา
• ใช้ Phase -1 gate ของเทมเพลตเพื่อทำเช็กลิสต์การปฏิบัติตามรัฐธรรมนูญ และหากมีข้อยกเว้นให้บันทึก เหตุผลอย่างชัดเจน ใน Complexity Tracking
• ผ่าน กระบวนการแก้ไขเพิ่มเติม วิธีการประยุกต์ใช้หลักการสามารถพัฒนาได้ แต่ ปรัชญาแกนกลาง ยังคงอยู่

The Transformation

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

[amoplan]

สรุปด้วย AI ตัวไหนหรือครับ?

[xguru]

ผมใช้ GPT-5 และใช้พรอมต์ที่ค่อนข้างยาวซึ่งผมจัดทำไว้สำหรับการสรุปครับ

[heycalmdown]

ผมเห็นด้วยกับแนวคิดนี้มาก เลยลองทดสอบกับโปรเจ็กต์ใหม่ในช่วงสุดสัปดาห์ดูบ้าง แต่ผลลัพธ์ก็ยังไม่ดีเท่าที่คิดครับ ดูเหมือนว่ายังต้องปรับปรุงอีกมาก อย่างแรก ลำดับการทำงานคร่าว ๆ ก็เป็นแบบที่มีการแนะนำกันมาหลายครั้งแล้วดังนี้:
เขียน constitution → เขียน spec → เขียน task → ลงมือ implement

ปัญหาคือ

• ไฟล์ constitution.md เป็นไกด์หลักเกี่ยวกับ "จะพัฒนาอย่างไร" แต่ไม่ได้บรรจุว่า "สุดท้ายแล้วแอปนี้จะเป็นอะไร"
• spec.md เป็นเอกสารที่อธิบายฟีเจอร์หนึ่งรายการ
• ไม่มีเอกสารแม่บทที่อธิบายว่า "แอปนี้คืออะไร"
• พอลองอ่านการถกเถียงที่เกิดขึ้นบน GitHub ก็ดูเหมือนว่า chain of specs จะกลายเป็น source of truth ในที่สุด — ฟังแล้วก็ยังแปลก ๆ แต่พอจะเข้าใจได้คร่าว ๆ
• มีการสร้างเอกสารจำนวนมากเป็นผลลัพธ์ผ่านคำสั่ง /specify และ /tasaks (ซึ่งก็เป็นผลลัพธ์ที่ต้องการ) แต่เพราะอย่างนั้นก็เลยกิน context เร็วมาก (ตอนนี้ใช้ Claude Code อยู่)
• พอเริ่มลงมือ implement จริง ก็จะห่างจาก Spec Kit ไปชั่วคราว แล้วสุดท้ายก็ปิดงาน implementation ผ่านการคุยกับ Claude Code แบบที่ทำกันตามปกติ
• พอใช้ context หมดแล้วทำ compaction หรือเริ่ม session ใหม่ ก็จะลืมการมีอยู่ของเอกสารที่ Spec Kit สร้างไว้
• พอทำงานตามที่กำหนดไว้ใน tasks.md ไปเรื่อย ๆ บางทีก็เขียนทับสิ่งที่ก่อนหน้านี้ทำไว้ดีแล้ว และในระหว่างแก้บั๊กก็อาจสร้างฟีเจอร์ใหม่เพิ่มขึ้นมา ทำให้ค่อย ๆ ห่างจาก tasks.md มากขึ้นเรื่อย ๆ ผมเลยไม่เข้าใจว่าการเก็บ tasks.md ไว้ถาวรมีความหมายอะไร

สรุปที่ผมได้ในตอนนี้มีดังนี้

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