# วิธีตั้งค่า Spec Kit ใน Claude Code ในปี 2026: ใช้ข้อกำหนดแทนพรอมป์ต์

> วิธีตั้งค่า GitHub Spec Kit ใน Claude Code: 4 ขั้นตอน—Specify, Plan, Tasks, Implement และการตรวจสอบขั้นสุดท้าย นี่คือแนวทางที่มาแทนการด้นสดแบบ vibe coding

Source: https://ailoot.ai/blog/th/spec-kit-claude-code-spec-driven-development/
Canonical: https://ailoot.ai/blog/th/spec-kit-claude-code-spec-driven-development/
Language: th
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-219
Revision: sha256-9ebe72ed5ccd8e23182d37c897009d6ec85a61f10a0c0fcb0bb332c91b897b3b


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

Spec Kit เป็นเครื่องมือจาก GitHub ที่ช่วยให้คุณเขียนข้อกำหนดงานด้วยภาษาธรรมชาติ จากนั้น Claude Code จะจัดทำแผน แบ่งงานออกเป็นงานย่อย และเขียนโค้ด นี่ไม่ใช่ทฤษฎีลอย ๆ: มีดาวบน GitHub 107,000 ดวงใน 8 เดือน AWS ใช้วิธีนี้สร้างโครงการค้นพบยาภายใน 3 สัปดาห์แทนที่จะใช้เวลาหลายเดือน และนี่คือคู่มือการติดตั้ง เทมเพลต 4 ขั้นตอนของเวิร์กโฟลว์พร้อมการตรวจสอบขั้นสุดท้าย และวิธีเชื่อมต่อกับ CLAUDE.md ของคุณ

</div>

<div class="aside" data-semantic="editorial-reference" role="note" aria-label="Ailoot Documentation">

[เอกสาร Ailoot](https://ailoot.ai/docs/) — เอกสารอ้างอิงเกี่ยวกับการใช้บริการ

</div>

## เกิดอะไรขึ้นกับ vibe coding ในเดือนพฤษภาคม 2026?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

ในช่วง 8 เดือน GitHub Spec Kit ได้ 107,000 ดาว และ AWS เผยแพร่กรณีศึกษาที่รายงานว่าประหยัดเวลาได้ 80+ ชั่วโมงสำหรับฟีเจอร์หนึ่งรายการ แนวโน้มประจำสัปดาห์ในเดือนพฤษภาคมคือการใช้ข้อกำหนดแทนการด้นสด

</div>

ในช่วงปีถัดมา “vibe coding” กลายเป็นคำพ้องความหมายกับการทำงานแบบไร้โครงสร้างกับเอเจนต์ AI

หนึ่งปีต่อมา ในวันที่ 4 กุมภาพันธ์ 2026 เขาเผยแพร่เธรดย้อนทบทวน:



ในการบรรยายที่ Sequoia Ascent 2026 เขาอธิบายได้แม่นยำยิ่งขึ้นว่า “Vibe coding ยกระดับขั้นต่ำ—เพิ่มสิ่งที่ทุกคนทำได้ในงานซอฟต์แวร์ ส่วน agentic engineering รักษาระดับสูงสุด—มาตรฐานคุณภาพของการพัฒนาซอฟต์แวร์ระดับมืออาชีพ” บนเวทีเดียวกัน เขากล่าวประโยคที่กลายเป็นคำติดปากในอุตสาหกรรมว่า “คุณจะสร้างช่องโหว่เพราะ vibe coding ไม่ได้ คุณยังคงรับผิดชอบต่อซอฟต์แวร์ของคุณเหมือนเดิม”

สองสิ่งเกิดขึ้นพร้อมกัน ในเดือนกันยายน 2025 GitHub เผยแพร่เครื่องมือ [Spec Kit](https://github.com/github/spec-kit)—ซึ่งได้ 107,000 ดาวใน 8 เดือน ในเดือนกุมภาพันธ์ 2026 AWS เผยแพร่ [กรณีศึกษาการค้นพบยาฉบับละเอียด](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) โดยรายงานว่า “สร้างตรรกะทางธุรกิจจากข้อกำหนดได้ 95% และประหยัดเวลาได้ 80+ ชั่วโมง”

ภายในสิ้นเดือนพฤษภาคม 2026 วงการข้อมูลภาษาอังกฤษเริ่มเห็นพ้องกันว่า vibe coding ในฐานะวิธีทำงานเป็นระดับเริ่มต้น ขั้นถัดไปคือ Spec-Driven Development คู่มือนี้อธิบายวิธีติดตั้งและนำแนวทางนี้ไปใช้

## Spec Kit และ Spec-Driven Development คืออะไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

Spec-Driven Development (SDD) พลิกวิธีการทำงานกับเอเจนต์ AI แบบเดิม จากเดิมที่โค้ดเป็นแหล่งข้อมูลหลักและข้อกำหนดเป็นเอกสารประกอบ ตอนนี้ข้อกำหนดเป็นแหล่งข้อมูลหลัก ส่วนโค้ดกลายเป็นขั้นตอนสุดท้าย—การนำข้อกำหนดไปใช้งานจริง Spec Kit เป็นเครื่องมือ CLI จาก GitHub ที่แปลง 4 ขั้นตอน (Specify, Plan, Tasks, Implement) และการตรวจสอบ Converge ขั้นสุดท้ายให้เป็นคำสั่งพร้อมใช้งานใน Claude Code, Cursor, Copilot และเอเจนต์อื่น ๆ อีก 30+

</div>

แนวคิดหลักของวิธีการนี้สรุปได้ในประโยคเดียวจากเอกสารทางการของ GitHub:

<figure>
<blockquote>
<p>Spec-Driven Development เปลี่ยนลำดับชั้น: ข้อกำหนดไม่ได้รับใช้โค้ด—โค้ดต่างหากที่รับใช้ข้อกำหนด ข้อกำหนดกลายเป็นชิ้นงานหลัก ส่วนโค้ดคือการแสดงออกของข้อกำหนดนั้นในภาษาและเฟรมเวิร์กเฉพาะ</p>
</blockquote>
<figcaption>— เอกสาร GitHub Spec Kit, https://github.com/github/spec-kit/blob/main/spec-driven.md</figcaption>
</figure>

ในทางปฏิบัติ กระบวนการนี้มี 4 ขั้นตอน (Spec Kit เพิ่มอีกหนึ่งขั้นตอน เป็นขั้นศูนย์—constitution ซึ่งจะอธิบายด้านล่าง):

1. **Specify** - เขียนข้อกำหนดว่าต้องการอะไรด้วยภาษาธรรมชาติ ว่าจะทำอะไรและทำไปทำไม ไม่ใช่ทำอย่างไร
2. **Plan** - เอเจนต์นำข้อกำหนดไปจัดทำแผนทางเทคนิค: จะใช้เทคโนโลยีใด สถาปัตยกรรมเป็นอย่างไร และมีองค์ประกอบใดบ้าง
3. **Tasks** - เอเจนต์แบ่งแผนออกเป็นงานเฉพาะที่ตรวจสอบได้ พร้อมระบุการพึ่งพากัน
4. **Implement** - เอเจนต์ (หรือเอเจนต์ย่อย) ทำงานตามรายการและเขียนโค้ด

หลัง Implement แล้ว Spec Kit เวอร์ชันปัจจุบันมีขั้นตอนตรวจสอบชื่อ **Converge**: เอเจนต์เปรียบเทียบโค้ดที่เสร็จแล้วกับข้อกำหนด แผน และงาน จากนั้นเพิ่มสิ่งที่ตกหล่นลงใน `tasks.md` ให้รัน Implement และ Converge วนซ้ำจนกว่า Converge จะตอบว่า “Converged”

แต่ละขั้นตอนเป็นไฟล์ Markdown แยกกันใน repo และเป็นคำสั่ง slash แยกกันใน Claude Code: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement` ส่วนคำสั่งตรวจสอบคือ `/speckit-converge` เอกสาร Spec Kit เขียนคำสั่งชุดเดียวกันโดยใช้จุด (`/speckit.specify`) แต่ใน Claude Code Spec Kit ติดตั้งคำสั่งเหล่านี้เป็น skills และเรียกใช้ด้วยขีดกลาง หากมีสิ่งใดผิดพลาดในขั้นใด ให้แก้ไขไฟล์ Markdown แล้วเรียกขั้นตอนถัดไปอีกครั้ง

Spec Kit เป็นการนำ SDD ไปใช้รูปแบบหนึ่ง ในเดือนพฤษภาคม 2026 มีการผสานรวมกับเอเจนต์ AI ต่าง ๆ มากกว่า 30 ราย ภายใน repo เดียวกัน Spec Kit ทำงานในลักษณะเดียวกันกับ Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose และเครื่องมืออื่น ๆ อีกนับสิบ

| ขั้นตอน Spec Kit | คำสั่ง slash | ชิ้นงานใน repo |
|----|----|----|
| Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` |
| Specify | `/speckit-specify` | `specs/###-feature/spec.md` |
| Clarify (ไม่บังคับ) | `/speckit-clarify` | แก้ไขใน `spec.md` |
| Plan | `/speckit-plan` | `specs/###-feature/plan.md` |
| Checklist (ไม่บังคับ) | `/speckit-checklist` | เช็กลิสต์ตรวจคุณภาพข้อกำหนด |
| Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` |
| Analyze (ไม่บังคับ) | `/speckit-analyze` | รายงานการตรวจ spec, plan และ tasks |
| Implement | `/speckit-implement` | โค้ดในโปรเจกต์ |
| Converge | `/speckit-converge` | ผลการตรวจ “Converged” หรือเพิ่มงานใหม่ใน `tasks.md` |

ดังนั้น หลังจากรันแล้ว repo ของคุณจะมีทั้งโค้ด ข้อกำหนด แผน และงานต่าง ๆ อีกหนึ่งเดือนต่อมา คุณกลับมาที่โปรเจกต์ อ่าน `spec.md` และเข้าใจได้ว่าทำอะไรไปและทำไม นี่ไม่ใช่ “vibe coding ที่ลืมไปว่ามีโค้ดอยู่” อีกต่อไป แต่มันคือหน่วยความจำสำหรับการทำงานของโปรเจกต์

## ทำไมคนที่ใช้ vibe coding และไม่เขียนโค้ดจึงต้องใช้สิ่งนี้?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

ปัญหาหลักของคนที่ใช้ vibe coding คือความคาดเดาไม่ได้ วันนี้เอเจนต์สร้างฟีเจอร์ที่ใช้งานได้ให้คุณภายใน 20 นาที พรุ่งนี้เมื่อเจองานคล้ายกันกลับสร้างโค้ดสปาเกตตี Spec Kit กำจัดต้นตอของความคาดเดาไม่ได้นี้—งานที่เขียนคลุมเครือ เมื่อคุณเขียนข้อกำหนดโดยใช้เทมเพลต เอเจนต์จะทำงานอย่างสม่ำเสมอ เพราะมีแหล่งข้อมูลหลักที่ไม่กำกวม นอกจากนี้คุณยังได้ชิ้นงานถาวรใน repo ซึ่งกลับมาอ่านได้อีกหนึ่งเดือนต่อมา

</div>





Spec Kit แบ่งการวางแผนออกเป็นขั้นตอนต่างหากด้วยคำสั่ง slash 4 คำสั่ง ตรรกะคือแยก “คิดให้รอบคอบ” ออกจาก “ลงมือทำ” เพื่อให้แต่ละขั้นเริ่มใน context window ที่สะอาด ไม่รกด้วยเนื้อหาจากขั้นก่อนหน้า

ประโยชน์ที่ชัดเจนสามข้อสำหรับคนที่ใช้ vibe coding:

- **คาดการณ์ได้** เมื่อคุณบอกเอเจนต์ว่า “ทำฟอร์มลงทะเบียนพร้อมยืนยันอีเมล” เอเจนต์จะเดารายละเอียด 10 อย่างเอง—และเดาผิดจากสิ่งที่คุณคิดไว้ 3 อย่าง แต่เมื่อมี `spec.md` ที่ประกอบด้วย User Stories, Acceptance Scenarios และเครื่องหมาย `[NEEDS CLARIFICATION]` ในทุกจุดที่ยังไม่แน่ชัด ก็ไม่มีอะไรให้เดา
- **ความทรงจำของโปรเจกต์** อีกหนึ่งเดือนต่อมา คุณจะจำไม่ได้ว่าคุยอะไรกับเอเจนต์ในแชต แต่ `spec.md`, `plan.md` และ `tasks.md` อยู่ใน repo ในโฟลเดอร์ `specs/###-feature/` ข้าง ๆ โค้ด ไฟล์เหล่านี้บอกทั้งสิ่งที่ทำและเหตุผล
- **รองรับงานขนาดใหญ่** สำหรับฟีเจอร์ที่เกี่ยวข้องกับ 1-2 ไฟล์ ความแตกต่างแทบสังเกตไม่ออก แต่สำหรับฟีเจอร์ที่มี 20 ไฟล์และเอนทิตีข้อมูล 5 รายการ ความแตกต่างคือระหว่าง “เขียนใหม่ทั้งหมดหลังผ่านไป 4 ชั่วโมง” กับ “ทุกอย่างเข้ามาอยู่ใน main branch หลังผ่านไป 4 ชั่วโมง” AWS Kiro แสดงให้เห็นการทำงานอัตโนมัติ 95% ของตรรกะทางธุรกิจจากข้อกำหนดในโปรเจกต์ TargetID

ภาพลวงตาหลักของ vibe coding คือดูเหมือนจะเร็วกว่าในตอนเริ่มต้น ผ่านไปครึ่งชั่วโมงก็มีต้นแบบแล้ว แต่เมื่อครบหนึ่งสัปดาห์ ต้นแบบก็พัง และการทิ้งแล้วเริ่มใหม่ง่ายกว่า Spec-Driven Development ใช้เวลาตอนเริ่มต้นนานขึ้นเล็กน้อย (หนึ่งชั่วโมงแทนครึ่งชั่วโมง) แต่หนึ่งสัปดาห์ต่อมา คุณยังทำงานอยู่ใน repo เดิม

## วิธีติดตั้ง Spec Kit ใน Claude Code (4 ขั้นตอน)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

ติดตั้ง Spec Kit ผ่าน uv ซึ่งเป็นตัวจัดการแพ็กเกจ Python จาก Astral ตัวคำสั่งมีเพียงบรรทัดเดียว หลังติดตั้ง ให้ไปที่ repo ของคุณ รัน `specify init` พร้อมแฟล็ก `--integration claude` (หรือเลือก Claude Code จากรายชื่อเอเจนต์) จากนั้นจะได้โครงสร้างพร้อมใช้งานที่มีเทมเพลต constitution, spec, plan และ tasks พร้อมชุดคำสั่ง `/speckit-*` ใน Claude Code โดยตรง การติดตั้งใช้เวลา 5 นาทีหากมี uv อยู่แล้ว และ 10 นาทีหากต้องติดตั้งใหม่ตั้งแต่ต้น

</div>

**ขั้นตอนที่ 1. ติดตั้ง uv** ทำเพียงครั้งเดียว แล้วจะอยู่ในระบบของคุณต่อไป

```bash
# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
```

ตรวจสอบว่า uv ติดตั้งแล้ว:

```bash
uv --version
```

**ขั้นตอนที่ 2. ติดตั้ง Spec Kit** ใช้คำสั่งเดียว:

```bash
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
```

ตรวจสอบ:

```bash
specify --version
```

**ขั้นตอนที่ 3. เริ่มต้น repo** ไปยังโฟลเดอร์โปรเจกต์ (หรือสร้างโฟลเดอร์ใหม่) แล้วรัน:

```bash
specify init --here --integration claude
```

แฟล็ก `--integration claude` เลือก Claude Code โดยตรง หากไม่ใส่ Spec Kit จะขอให้คุณเลือกเอเจนต์จากรายการแบบโต้ตอบ และอาจถามประเภทสคริปต์ด้วย (สำหรับ macOS และ Linux ให้คงเป็น `sh`) หากโฟลเดอร์ไม่ว่าง Spec Kit จะเตือนว่าจะรวมไฟล์เข้ากับไฟล์ที่มีอยู่ ให้ commit งานของคุณก่อน แล้วจึงรันคำสั่งอีกครั้งพร้อมแฟล็ก `--force`

หลังจากนั้น ไฟล์ต่อไปนี้จะปรากฏใน repo:

```
.specify/
  memory/
    constitution.md        # กฎของโปรเจกต์ เติมข้อมูลด้วย /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md
```

**ขั้นตอนที่ 4. เปิด Claude Code และตรวจสอบคำสั่ง slash** รันคำสั่งนี้ในโฟลเดอร์เดิม:

```bash
claude
```

ในเซสชัน ให้พิมพ์ `/speckit`—คำสั่ง `speckit-*` ควรปรากฏในรายการแนะนำ หากไม่ปรากฏ ให้เริ่ม Claude Code ใหม่เพื่อให้อ่าน `.claude/skills/` อีกครั้ง หากมี `CLAUDE.md` ที่ root ของโปรเจกต์อยู่แล้ว Spec Kit จะปล่อยไว้ตามเดิม โดยทำงานควบคู่กันผ่าน `.specify/memory/constitution.md`

Spec Kit ใช้งานได้โดยไม่ต้องมี Claude Code (รองรับเอเจนต์ 30+ ราย) แต่คู่มือนี้อธิบายการตั้งค่าโดยเฉพาะสำหรับ Claude หากต้องการติดตั้งเครื่องมือสองอย่างทันที ดูคู่มือแยกเรื่อง [การตั้งค่า CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/) และ [Plan Mode ใน Claude Code](https://ailoot.ai/blog/th/claude-code-plan-mode/)

Spec Kit เป็นองค์ประกอบแรกของ “สัญญาจ้างงานเอเจนต์” การตั้งค่าครบชุดประกอบด้วยทั้งสามส่วน: โคลน AI (วิธีการของคุณในรูปแบบ Skills และเอเจนต์ย่อย), Second Brain (โครงสร้าง `business/` ที่เอเจนต์กลับไปหาในแต่ละครั้ง) และวิศวกรรมบริบท (Spec Kit, Plan Mode, /compact) นี่คือเสาหลักสามต้นที่ AI จะเกิดภาพหลอนหากขาดไป

## วิธีเขียนข้อกำหนดแรกของคุณ (Specify)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

Spec Kit ขอให้คุณอธิบายฟีเจอร์แบบอิสระ จากนั้นขยายคำอธิบายนั้นเป็นไฟล์ `spec.md` โดยใช้เทมเพลต ซึ่งประกอบด้วย User Stories ที่มีลำดับความสำคัญ P1/P2/P3, Acceptance Scenarios ในรูปแบบ Given/When/Then, Functional Requirements (FR-001, FR-002 ฯลฯ) และ Success Criteria ที่มีผลลัพธ์วัดได้ ในจุดที่เอเจนต์ไม่แน่ใจ เอเจนต์จะใส่เครื่องหมาย `[NEEDS CLARIFICATION: ...]`—คุณต้องตอบคำถามเหล่านี้ก่อนจะไปยัง Plan

</div>

ใน Claude Code ให้พิมพ์:

```
/speckit-specify
```

จากนั้นเอเจนต์จะถามให้คุณอธิบายฟีเจอร์ ในขั้นนี้ให้ใช้ภาษาธรรมดา ไม่ต้องใช้ศัพท์เทคนิค:

```
ฉันต้องการฟอร์มลงทะเบียนในแอปของฉัน ผู้ใช้กรอกอีเมล
และรหัสผ่าน ได้รับอีเมลยืนยัน และหลังจากยืนยันแล้ว
จะไปยังแดชบอร์ด การยืนยันหมดอายุเมื่อครบ 48 ชั่วโมง หาก
ยังไม่ยืนยันอีเมล ให้ลบบัญชีภายใน 5 นาทีหลังเส้นตายนั้น
ห้ามลบบัญชีที่ยืนยันแล้ว
```

ในตัวอย่างนี้ชี้แจงช่วงยอมล่าช้าลบเป็น 5 นาทีหลังครบ 48 ชั่วโมง ผลิตภัณฑ์จริงต้องยืนยันช่วงนี้ก่อน Plan หากต้องตรง 48 ชั่วโมงพอดี ต้องออกแบบและทดสอบให้บังคับข้อกำหนดที่เข้มกว่านั้น เอเจนต์จะจัดทำ `specs/001-registration/spec.md` เปิดแล้วจะเห็นโครงสร้างประมาณนี้:

```markdown
# ข้อกำหนดฟีเจอร์: การลงทะเบียนผู้ใช้

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "ฉันต้องการฟอร์มลงทะเบียน..."

## สถานการณ์ผู้ใช้และการทดสอบ *(ต้องมี)*

### เรื่องราวหลักของผู้ใช้
ในฐานะผู้ใช้ใหม่ ฉันต้องการลงทะเบียนบัญชีพร้อมการยืนยันอีเมล
เพื่อให้เข้าถึงแดชบอร์ดด้วยตัวตนที่ผ่านการยืนยันแล้วได้

### สถานการณ์การยอมรับ
1. **Given** ฉันอยู่บนหน้าลงทะเบียน
   **When** ฉันส่งอีเมลและรหัสผ่านที่ถูกต้อง
   **Then** ฉันได้รับอีเมลยืนยันภายใน 1 นาที
2. **Given** ฉันคลิกลิงก์ยืนยันภายใน 48 ชั่วโมง
   **When** ฉันไปถึงแดชบอร์ด
   **Then** ฉันเห็นว่าอีเมลได้รับการยืนยันแล้วในโปรไฟล์
3. **Given** ฉันยังไม่ยืนยันเมื่อครบเส้นตาย 48 ชั่วโมง
   **When** cleanup รันภายใน 5 นาทีถัดไป
   **Then** บัญชีถูกลบและอีเมลใช้ลงทะเบียนใหม่ได้
4. **Given** บัญชียังไม่ครบ 48 ชั่วโมงหรือยืนยันแล้ว
   **When** cleanup รัน
   **Then** บัญชีไม่ถูกลบ

## ข้อกำหนด *(ต้องมี)*

### ข้อกำหนดเชิงฟังก์ชัน
- **FR-001**: ระบบ MUST รับการลงทะเบียนด้วย [NEEDS CLARIFICATION:
  อีเมล/รหัสผ่านเท่านั้น หรือมี SSO/OAuth ด้วย?]
- **FR-002**: ระบบ MUST ส่งอีเมลยืนยันภายใน 60 วินาที
- **FR-003**: การยืนยัน MUST หมดอายุที่ 48 ชั่วโมง ระบบ MUST
  ลบบัญชียังไม่ยืนยันภายในไม่เกิน 5 นาทีหลังเส้นตาย และ
  MUST NOT ลบบัญชีที่ยืนยันแล้ว
- **FR-004**: ระบบ MUST บันทึกความพยายามลงทะเบียนทั้งหมดเป็นเวลา [NEEDS
  CLARIFICATION: เราจะเก็บ log นานเท่าไร - 30 วัน, 90 วัน, ตลอดไป?]

### เอนทิตีหลัก
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## เกณฑ์ความสำเร็จ *(ต้องมี)*
- **SC-001**: ส่งอีเมลยืนยันได้ภายใน 60 วินาที (p95) อย่างน้อย 95%
- **SC-002**: การลบบัญชีที่ยืนยันแล้วโดยผิดพลาด 0 ครั้ง
- **SC-004**: ไม่ลบก่อน 48 ชั่วโมง ทุกบัญชียังไม่ยืนยันที่เข้าเกณฑ์
  ถูกลบเมื่ออายุไม่เกิน 48 ชั่วโมง 5 นาทีภายใต้โหลดที่ทดสอบ
- **SC-003**: อัตราการลงทะเบียนสำเร็จ > 60% (ตั้งแต่เปิดฟอร์มจนถึงแดชบอร์ด)
```

โปรดสังเกตเครื่องหมาย `[NEEDS CLARIFICATION: ...]` Spec Kit ใส่เครื่องหมายเหล่านี้โดยตั้งใจในทุกจุดที่เอเจนต์ไม่ได้รับคำตอบที่ชัดเจนจากข้อความของคุณ ก่อนจะไปยังขั้นตอน Plan คุณต้องตอบคำถามเหล่านี้ใน `spec.md` ด้วยตนเอง หรือรัน `/speckit-clarify` แล้วเอเจนต์จะไล่ตรวจประเด็นที่ยังไม่ชัดเจนและถามคุณในบทสนทนา





ใน Spec Kit คำสั่ง `/speckit-clarify` ที่มีมาให้ใช้แทนคำพูดว่า “ถามคำถามผม” ผลลัพธ์เหมือนกัน: อย่าไปต่อยัง Plan จนกว่าเครื่องหมาย `[NEEDS CLARIFICATION]` จะหมดไปจาก `spec.md`

ไม่ควรใส่เทคโนโลยีลงใน `spec.md` ห้ามกล่าวถึง React, Postgres, Prisma หรือ Redis ข้อกำหนดอธิบายว่าระบบทำอะไรจากมุมมองของผู้ใช้และธุรกิจ ส่วนเทคโนโลยีที่จะใช้จะอยู่ในขั้นตอนถัดไป

## Claude ทำอะไรในขั้น Plan?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

คำสั่ง `/speckit-plan` รับข้อกำหนดที่เสร็จสมบูรณ์แล้วมาจัดทำเป็นแผนทางเทคนิค: จะใช้เทคโนโลยีใด มีสถาปัตยกรรมแบบไหน ต้องใช้โมดูล เอนทิตีข้อมูล และสัญญา API ใดบ้าง แผนจะเขียนลงใน `specs/###-feature/plan.md` สัญญาจะส่งออกไปยังโฟลเดอร์ `contracts/` แยกต่างหาก และโมเดลข้อมูลจะอยู่ใน `data-model.md` ในขั้นนี้ Claude รู้เทคโนโลยีที่คุณใช้จาก CLAUDE.md และ constitution แล้ว แผนจึงเหมาะกับโปรเจกต์เดิมแทนที่จะเสนอว่า “มาเขียนทุกอย่างใหม่ด้วย Rust กันเถอะ”

</div>

เมื่อ `spec.md` พร้อมแล้ว ให้รัน:

```
/speckit-plan
```

คุณจะส่งคำใบ้เกี่ยวกับเทคโนโลยีไปในคำสั่งโดยตรงก็ได้:

```
/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email
```

Claude อ่านข้อมูลจากสามแหล่ง: `spec.md`, `CLAUDE.md` (หรือ `memory/constitution.md`) และโค้ดที่มีอยู่ใน repo ผลลัพธ์คือ `plan.md` ที่มีโครงสร้างประมาณนี้:

```markdown
# แผนการนำไปใช้: การลงทะเบียนผู้ใช้

## บริบททางเทคนิค
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider

## การตัดสินใจด้านสถาปัตยกรรม

### 1. การจัดเก็บโทเคน
จัดเก็บโทเคนใน DB (ตาราง ConfirmationToken) ไม่ใช่ใน JWT
เหตุผล: ต้องเพิกถอนโทเคนฝั่งเซิร์ฟเวอร์ได้เมื่อมีการลงทะเบียนอีเมลใหม่

### 2. การส่งอีเมล
ส่งแบบอะซิงโครนัสผ่าน cron `/api/cron/send-confirmation` ซึ่งทำงานทันที
หลังลงทะเบียน Resend จัดการการลองใหม่

### 3. cron ลบอัตโนมัติ
รัน `/api/cron/cleanup-unconfirmed` ทุกนาที ลบเฉพาะแถวที่
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
ตัวอย่างที่ชี้แจงแล้วอนุญาตให้ลบล่าช้าสูงสุด 5 นาที
ตรวจ scheduler lag กับเวลาจบรันเทียบเพดานนี้ หากเกินต้องรายงาน
ว่าล้มเหลว ไม่ใช่ว่า cleanup รายวันสำเร็จ

## โมเดลข้อมูล
ดู data-model.md

## สัญญา API
ดู contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## ระยะการนำไปใช้
1. การย้ายฐานข้อมูล (สคีมา Prisma + ไฟล์ migration)
2. เส้นทาง API (3 endpoints)
3. UI: ฟอร์มลงทะเบียน + หน้ายืนยันสำเร็จ
4. งาน cron (ส่ง + ล้างข้อมูล)
5. เทมเพลตอีเมล
6. การทดสอบ integration
```

`data-model.md` จะอธิบายเอนทิตีและความสัมพันธ์ระหว่างกัน ส่วน `contracts/` จะมีโครงร่างสัญญา API (อาจเป็น OpenAPI YAML หรือชนิด request/response ของ TypeScript) นี่ไม่ใช่โค้ด แต่เป็นสิ่งที่ตั้งใจให้ Claude แปลงเป็น route จริงในภายหลัง

ข้อดีหลักของขั้น Plan คือการมีบริบทที่สะอาด Claude ไม่พยายามจำทั้งข้อกำหนดและการนำไปใช้พร้อมกัน แต่มันจะคิดให้รอบคอบก่อน บันทึกการตัดสินใจลงในไฟล์ แล้วจึงไปต่อ

ถัดไปคือคำสั่ง `/speckit-analyze` ซึ่งเป็นตัวเลือก โดยจะรันหลังขั้น Tasks และก่อน Implement: คำสั่งนี้ตรวจชุด `spec.md + plan.md + tasks.md` เพื่อหาความขัดแย้ง และตรวจว่าข้อกำหนดทุกข้อมีแผนและงานรองรับหรือไม่ คำสั่งนี้ไม่แก้ไขไฟล์ แต่สร้างรายงานเท่านั้น โดยพื้นฐานแล้วนี่คือการตรวจความสมเหตุสมผลอย่างเป็นทางการก่อนเริ่มลงมือ

## วิธีแบ่งงานเป็นงานย่อย (Tasks)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

คำสั่ง `/speckit-tasks` แบ่งแผนออกเป็นงานที่ทำได้จริง แต่ละงานมีการพึ่งพากัน การประมาณเวลา และเครื่องหมายระบุว่า “ทำงานพร้อมกันได้” หรือ “ต้องทำตามลำดับเท่านั้น” ผลลัพธ์คือ `tasks.md` ซึ่งแสดงงานในรูปแบบเช็กลิสต์ `[ ] T-001: ...` จากนั้นคุณสามารถส่งงานเหล่านี้ไปให้ทำผ่าน `/speckit-implement` หรือแปลงเป็น GitHub Issues ด้วย `/speckit-taskstoissues`—แล้วแบ่งกระจายให้ทีม หรือเปิด Claude Code หลายเซสชันทำงานพร้อมกันได้

</div>

เมื่อมี `spec.md` และ `plan.md` แล้ว ให้รัน:

```
/speckit-tasks
```

Claude จะขยายแผนเป็น `tasks.md`:

```markdown
# งาน: การลงทะเบียนผู้ใช้

## ระยะที่ 1: ฐานข้อมูล (ไม่มีการพึ่งพา)
- [ ] T-001: เพิ่มโมเดล User ใน prisma/schema.prisma (ทำงานพร้อมกันได้อย่างปลอดภัย)
- [ ] T-002: เพิ่มโมเดล ConfirmationToken ใน prisma/schema.prisma (หลัง T-001)
- [ ] T-003: สร้าง migration `add-user-registration` (หลัง T-002)

## ระยะที่ 2: สัญญา API (ไม่มีการพึ่งพา)
- [ ] T-004: สร้าง Zod schemas ใน shared/validation/auth.ts
- [ ] T-005: กำหนด TypeScript types ใน shared/types/auth.ts (หลัง T-004)

## ระยะที่ 3: Routes (ขึ้นกับระยะ 1+2)
- [ ] T-006: ทำ POST /api/auth/register
- [ ] T-007: ทำ POST /api/auth/confirm
- [ ] T-008: ทำ GET /api/auth/resend-confirmation

## ระยะที่ 4: UI (ทำพร้อมกับระยะ 3 ได้)
- [ ] T-009: สร้างหน้า /register พร้อมฟอร์ม
- [ ] T-010: สร้างหน้า /register/confirm/[token]
- [ ] T-011: สร้างหน้า /register/success

## ระยะที่ 5: cron + integration (ขึ้นกับระยะ 3+4)
- [ ] T-012: cron /api/cron/send-confirmation
- [ ] T-013: cron /api/cron/cleanup-unconfirmed
- [ ] T-014: เทมเพลตอีเมล registration-confirmation.tsx
- [ ] T-015: การทดสอบ integration (Playwright) รวม cleanup ก่อนครบ
  48h พอดีที่ 48h ลบภายใน 48h 5m งานล่าช้าที่ต้องล้มเหลว
  และการป้องกันบัญชีที่ยืนยันแล้ว

## หมายเหตุ
- T-001, T-004, T-009-T-011 ทำงานพร้อมกันได้อย่างปลอดภัย (ไฟล์คนละไฟล์)
- T-002 ขัดแย้งกับ T-001 (ไฟล์เดียวกัน: schema.prisma) - ให้ทำตามลำดับ
- T-006 ต้องใช้ T-003 (นำ migration ไปใช้แล้ว) และ T-005 (types)
```

สังเกตเครื่องหมาย `parallel-safe` และ `after T-NNN` นี่คือกราฟการพึ่งพาที่ช่วยให้รันหลายขั้นตอนไปพร้อมกันได้ในภายหลัง แนวทางเร่งงานทั้งหมดของ Spec Kit อาศัยกลไกนี้: งานบางอย่างส่งให้ Claude Code ห้าเซสชันที่ต่างกันทำพร้อมกันได้ แต่งานอื่นต้องทำตามลำดับอย่างเคร่งครัด





Spec Kit ทำสิ่งนี้ให้อัตโนมัติด้วยคำสั่งเดียว ตั้งแต่เริ่มใช้งาน

คำสั่ง `/speckit-taskstoissues` ซึ่งเป็นตัวเลือก จะรับ `tasks.md` แล้วสร้าง GitHub Issues จากรายการ แต่ละ issue มีลิงก์กลับไปยัง `spec.md` เหมาะสำหรับทำงานเป็นทีมหรือติดตามความคืบหน้าผ่าน GitHub Projects

## วิธีนำไปใช้ด้วยเอเจนต์ย่อย (Implement)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

ขั้นตอนสุดท้าย `/speckit-implement` จะเริ่มการนำไปใช้ Claude ทำงานตาม `tasks.md` จากบนลงล่าง และทำเครื่องหมาย `[x]` เมื่องานเสร็จ คุณเปิด Claude Code หลายเซสชันให้ทำงานพร้อมกันได้—หนึ่งระยะต่อหนึ่งเซสชัน ในแต่ละเซสชัน Claude จะเรียกเอเจนต์ย่อยให้ทำงานคนละประเภท: ผู้ตรวจโค้ด ผู้ทดสอบ และผู้เขียนเอกสาร README นี่คือ “เอเจนต์ย่อย 1000 ตัวทำงานพร้อมกัน” ที่ Anthropic เขียนถึงตอนเปิดตัว Opus 4.8—ใน Spec Kit นี่เป็นเพียงรูปแบบการทำงาน ไม่ใช่ผลิตภัณฑ์แยกต่างหาก

</div>

```
/speckit-implement
```

Claude เริ่มจากงานแรกใน `tasks.md` แต่ละงานผ่านวงจรสั้น ๆ: อ่านไฟล์ที่เกี่ยวข้อง เขียน diff รันการทดสอบ แล้วทำเครื่องหมาย `[x]` ระบบจะเรียกเอเจนต์ย่อยโดยอัตโนมัติเมื่อจำเป็น: ตัวหนึ่งแยกสำหรับตรวจโค้ด อีกตัวรัน linter และอีกตัวตรวจ regression





และกล่าวถึงกฎแยกต่างหากว่า:



ใน Spec Kit วงจรนี้เป็นระบบ คุณมี `spec.md` เป็นแหล่งข้อมูลหลัก, `plan.md` สำหรับการตัดสินใจทางเทคนิค และ `tasks.md` เป็นเช็กลิสต์ หาก Claude ออกนอกเส้นทางในขั้นใด ให้กลับไปที่ข้อกำหนดแล้วบอกว่า “สิ่งนี้ไม่ตรงกับ FR-003 ทำใหม่” ไม่ต้องเขียนพรอมป์ต์ยาว ๆ ว่า “จำสิ่งที่เราคุยกัน...” เพราะประวัติทั้งหมดอยู่ในไฟล์

ถ้าคุณเชื่อมต่อ [Dynamic Workflows ใน Opus 4.8](https://ailoot.ai/blog/th/claude-code-dynamic-workflows/) ก็สามารถให้ Spec Kit ทำงานอัตโนมัติเต็มรูปแบบได้: ใช้คำสั่ง `/speckit-implement` เพียงครั้งเดียว แล้ว Claude จะกระจายงานไปทำพร้อมกัน รวมผลลัพธ์ และตรวจสอบงาน ขีดจำกัดคือเอเจนต์ย่อยพร้อมกัน 1000 ตัว ฟีเจอร์ส่วนใหญ่ใช้ 10-30 ตัวก็เพียงพอ

เมื่อทำเครื่องหมาย `[x]` ครบทุกช่อง และการตรวจสอบในส่วนถัดไปตอบว่า “Converged” ให้ตรวจ PR (หรือชุด PR หากมีหลายงาน) แล้ว merge ชิ้นงาน—`spec.md`, `plan.md`, `tasks.md`—ยังคงอยู่ใน repo เป็นเอกสารประกอบฟีเจอร์ อีกหนึ่งปีต่อมา คุณจะไม่ต้องย้อนแกะตรรกะจากโค้ด

## วิธีตรวจว่าเอเจนต์ไม่ได้พลาดอะไร (Converge)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

หลัง Implement แล้ว Spec Kit เวอร์ชันปัจจุบันมีขั้นตอนตรวจสอบชื่อ `/speckit-converge` เอเจนต์เปรียบเทียบโค้ดที่เสร็จแล้วกับ `spec.md`, `plan.md` และ `tasks.md` หากทุกอย่างตรงกันก็จะตอบว่า “Converged” และไม่แตะต้องไฟล์ หากพบสิ่งที่ตกหล่น เอเจนต์จะเพิ่มสิ่งเหล่านั้นเป็นงานใหม่ท้าย `tasks.md` จากนั้นรัน `/speckit-implement` อีกครั้ง แล้วตามด้วย `/speckit-converge` อีกครั้ง จนกว่าจะได้คำตอบ “Converged”

</div>

```
/speckit-converge
```

ก่อนอื่นเอเจนต์จะสรุปสิ่งที่พบพร้อมระดับความรุนแรง จากนั้นจะมีผลลัพธ์หนึ่งในสองแบบ “Converged” หมายความว่าไม่มีสิ่งตกหล่น `tasks.md` ไม่เปลี่ยนแปลงแม้แต่ไบต์เดียว และคุณไปตรวจสอบต่อได้ “Tasks appended” หมายความว่าพบสิ่งที่ตกหล่นและเพิ่มไว้ในส่วน Convergence ของ `tasks.md` พร้อมแจ้งจำนวนรายการ

Converge ไม่แก้ไขหรือลบโค้ด การเขียนเพียงอย่างเดียวคือเพิ่มงานใหม่ลงใน `tasks.md` ดังนั้นรันได้โดยไม่ต้องกังวล แต่ต้องรันหลังจาก `/speckit-implement` ทำงานผ่าน `tasks.md` ฉบับปัจจุบันแล้วเท่านั้น การตรวจแต่ละรอบจะพบสิ่งตกหล่นน้อยลง

## Spec Kit แตกต่างจาก CLAUDE.md และ Plan Mode อย่างไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

นี่เป็นคำถามที่พบบ่อยเมื่อเปรียบเทียบเครื่องมือเหล่านี้ คำตอบสั้น ๆ คือ CLAUDE.md เป็น “สัญญาจ้างงาน” ของเอเจนต์ เป็นแหล่งข้อมูลหลักเพียงแห่งเดียวสำหรับทั้งโปรเจกต์ Plan Mode คือการวางแผนครั้งเดียวก่อนทำคำขอเฉพาะ ส่วน Spec Kit คือวงจรชีวิตเต็มรูปแบบของฟีเจอร์หนึ่งรายการ ตั้งแต่คำอธิบายจนถึงการนำไปใช้ พร้อมชิ้นงานใน repo ทั้งสามอย่างไม่ได้มาแทนที่กัน แต่ทำงานร่วมกันเป็นระบบสามชั้น: บริบทระดับสากล (CLAUDE.md) → บริบทระดับโปรเจกต์ (constitution ของ Spec Kit) → บริบทระดับฟีเจอร์ (spec.md + plan.md + tasks.md)

</div>

เปรียบเทียบทั้งสองกับ Spec Kit ตามคุณลักษณะ 5 ข้อ:

| คุณลักษณะ | CLAUDE.md | Plan Mode | Spec Kit |
|----|----|----|----|
| ทำงานเมื่อใด | ทุกเซสชัน | ตามคำขอ (Shift+Tab หรือ /plan) | ใช้คำสั่ง slash /speckit-\* |
| ระยะเวลาใช้งาน | ทั้งโปรเจกต์ | หนึ่งเซสชัน | หนึ่งฟีเจอร์ |
| อยู่ที่ไหน | root ของ repo | ในบริบทของ Claude | `specs/###-feature/*` |
| จัดเก็บอะไร | สแต็ก กฎ อภิธานศัพท์ | แผนปัจจุบัน + ข้อสังเกต | spec + plan + tasks + contracts |
| เทมเพลต | อิสระ (กฎของ repo) | ไม่มี | Markdown แบบมีโครงสร้าง |
| บทบาทที่เหมาะที่สุด | กฎและสแต็กของโปรเจกต์ | ตรวจทานก่อนการเปลี่ยนแปลงครั้งใหญ่ | วงจรฟีเจอร์ครบตั้งแต่ WHAT ถึง CODE |





ในคำศัพท์ของ Spec Kit สิ่งนี้คือ `.specify/memory/constitution.md` ระหว่างการเริ่มต้น Spec Kit จะใช้ CLAUDE.md ที่มีอยู่เป็นพื้นฐานของ constitution หรือสร้างไฟล์แยกไว้ข้าง ๆ ก็ได้ ปกติฉันคง CLAUDE.md ไว้เป็น “สัญญา” ระดับสากล (สแต็ก อภิธานศัพท์ โปรโตคอลการ deploy) และใช้ constitution ของ Spec Kit สำหรับกฎเฉพาะเวิร์กโฟลว์นี้ เช่น “ตรวจสอบฟอร์มทั้งหมดผ่าน Zod; ห้ามตรวจสอบด้วยตนเอง”

การเชื่อมต่อกับ Plan Mode ง่ายกว่า Plan Mode เป็นโหมด “วางแผนก่อนเขียนโค้ด” แบบรวดเร็วภายในเซสชันเดียว เหมาะกับการเปลี่ยนแปลงเล็ก ๆ (แก้บั๊ก ปรับโครงสร้างฟังก์ชัน) แต่สำหรับฟีเจอร์ใหญ่ Plan Mode ทำได้ไม่ดีเท่า เพราะ context window ของเซสชันเดียวเล็กเกินไปสำหรับแผนยาว 3000 บรรทัด—อย่างที่ฉันอธิบายตรง ๆ ในเซสชันสด:



Spec Kit เป็นเครื่องมือวิศวกรรมบริบทที่จับต้องได้ โดยย้าย “ผ้าปูโต๊ะของสถาปัตยกรรม” จากแชตไปไว้ในไฟล์ Spec.md อยู่ใน repo และ Claude ทุกเซสชันใหม่จะอ่านไฟล์นี้อีกครั้ง—คุณไม่ต้องพูดซ้ำ

การตั้งค่าสำหรับโปรเจกต์ขนาดใหญ่:

1. **CLAUDE.md** - สแต็ก อภิธานศัพท์ และสิ่งที่ห้ามทำ อยู่ที่ root
2. **.specify/memory/constitution.md** สำหรับ Spec Kit—กฎเฉพาะของเวิร์กโฟลว์นี้
3. **specs/001-feature-A/spec.md, plan.md, tasks.md** - ฟีเจอร์แรก
4. **specs/002-feature-B/spec.md, plan.md, tasks.md** - ฟีเจอร์ที่สอง
5. สำหรับงานประจำวัน ใช้ `/speckit-implement` (สำหรับงานที่เตรียมไว้แล้ว) หรือ `/plan` (ตรวจทานอย่างรวดเร็วก่อนเปลี่ยนแปลง)

## กรณีใช้งานจริงใดบ้างที่ได้ผล?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

แนวทาง Spec Kit และ SDD ให้ผลลัพธ์ที่วัดได้แล้วในบริษัทขนาดใหญ่ AWS ในโครงการค้นพบยา: สร้างตรรกะทางธุรกิจจากข้อกำหนดได้ 95% ประหยัดเวลา 80+ ชั่วโมงสำหรับฟีเจอร์หนึ่งรายการ Rackspace Technology: ย่นงาน 52 สัปดาห์ให้เหลือ 3 สัปดาห์ ประสิทธิภาพเพิ่มขึ้น +90% ส่วน Spec Kit เองได้ 107,000 ดาวบน GitHub ใน 8 เดือน

</div>

กรณีที่เจาะจง:

- **AWS Kiro - เอเจนต์ค้นพบยา** ใน[โพสต์บล็อก AWS Industries](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) ลงวันที่ 18 กุมภาพันธ์ 2026 ทีมงานอธิบายโครงการ TargetID นักพัฒนาสามคน สามสัปดาห์ และเอเจนต์ค้นพบยา ตัวเลขในบทความ: Kiro สร้างโค้ดตรรกะทางธุรกิจมากกว่า 95% และประหยัดเวลาพัฒนาได้มากกว่า 80 ชั่วโมง นอกจากนี้ยังระบุว่า “เอกสาร README ที่ Kiro เขียนช่วยประหยัดเวลาได้ประมาณ 8 ชั่วโมง” และ “ลดรอบพรอมป์ต์แล้วแก้ซ้ำลง 40%”
- **Rackspace Technology** ในบล็อก AWS เดียวกัน Rackspace รายงานว่า “ทำงานที่ประเมินไว้ 52 สัปดาห์เสร็จในเวลาเพียง 3 สัปดาห์” และ “ประสิทธิภาพเพิ่มขึ้น 90%” นี่ไม่ใช่ฟีเจอร์ขนาดเล็กอีกต่อไป แต่เป็นโปรเจกต์ Enterprise เต็มรูปแบบ
- **การเติบโตของ GitHub Spec Kit** ณ วันที่ 7 พฤษภาคม 2026 repo มี 93,000 ดาว; ภายในวันที่ 31 พฤษภาคม มี 107,000 ดาว นั่นคือเพิ่มขึ้น +14,000 ดาวในสามสัปดาห์ อัตราการเติบโตนี้เป็นสัญญาณชัดเจนว่าแนวทางดังกล่าวกำลังมีส่วนแบ่งตลาดเพิ่มขึ้น

สำหรับผู้อ่าน นี่หมายความว่าแนวทางนี้ไม่ใช่แค่ทฤษฎี ทีมจริงจังนำไปใช้ในระบบ production แล้ว

## เมื่อใดที่ Spec Kit ไม่เหมาะ?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

Spec Kit ไม่เหมาะกับทุกสถานการณ์ มีสามกรณีที่ไม่เหมาะอย่างชัดเจน: การแก้ไขเล็ก ๆ (แก้บั๊ก เปลี่ยนชื่อตัวแปร), การทดลองและต้นแบบ (เมื่อการยังไม่รู้ว่าต้องการอะไรคือหัวใจของ vibe coding) และโค้ดเก่าที่มีสถานะซับซ้อน (เมื่อข้อกำหนดล้าสมัยเร็วกว่าที่คุณจะเขียนเสร็จ) มีข้อวิจารณ์กรณีเหล่านี้อย่างจริงจัง ควรรู้เหตุผลของข้อวิจารณ์ เพื่อไม่ให้เสียเวลากับข้อกำหนดในจุดที่ไม่ช่วยอะไร

</div>

**ไม่เหมาะ #1 - การแก้ไขเล็ก ๆ** หากงานคือ “เปลี่ยนชื่อตัวแปร” “แก้คำพิมพ์ผิดในข้อความ” หรือ “เพิ่ม log” การผ่าน Specify → Plan → Tasks จะใช้เวลามากกว่าการแก้เอง สำหรับการแก้เล็ก ๆ Plan Mode หรือพรอมป์ต์ตรง ๆ ใน Claude Code เร็วกว่า

**ไม่เหมาะ #2 - การทดลองแบบสด** เมื่อคุณยังไม่รู้ว่าต้องการอะไร และต้อง “ลองเล่น” กับอินเทอร์เฟซหรือประกอบต้นแบบอย่างรวดเร็วเพื่อดูว่า “เข้าท่าหรือเปล่า” การเขียนข้อกำหนดก็ไม่มีประโยชน์ คุณค่าของงานอยู่ที่การด้นสดนั่นเอง ในระดับของการ “ลองเล่นกับไอเดีย” vibe คือสิ่งที่ใช้ได้ผล ไม่ใช่ข้อกำหนด

**ไม่เหมาะ #3 - โค้ดเก่าที่มีสถานะซับซ้อน** ความเป็นจริงเปลี่ยนแปลงเร็วกว่าข้อกำหนด ลองพิจารณาการเรียกเก็บเงินค่าสมาชิก: ทีมอธิบายรอบบิลและกฎภาษี จากนั้นหนึ่งสัปดาห์ต่อมา ฝ่ายการเงินขอเพิ่ม VAT สำหรับยุโรป—ข้อกำหนดก็ล้าสมัยก่อนปล่อยใช้งาน เมื่อกฎธุรกิจเปลี่ยนเร็ว การดูแลข้อกำหนดกลายเป็นภาระ

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

นักวิเคราะห์ในอุตสาหกรรมเตือนถึง waterfall: การเขียนข้อกำหนดขนาดใหญ่ก่อนเริ่มเขียนโค้ดเป็นเส้นทางที่เคยทำให้อุตสาหกรรมล้มเหลวมาแล้วครั้งหนึ่ง ในยุคที่มีข้อกำหนดยาว 200 หน้า วิศวกรระมัดระวังแนวทางนี้เรื่อยมา และความระมัดระวังนั้นก็มีเหตุผล

**ควรทำอย่างไร** ฉันขอเสนอกฎง่าย ๆ: เปรียบเทียบขนาดฟีเจอร์กับเวลาที่ใช้เขียนข้อกำหนด หากใช้เวลาน้อยกว่า 2 ชั่วโมงในการทำฟีเจอร์ อย่าเขียน spec—Plan Mode เร็วกว่า หากฟีเจอร์ใช้เวลาหนึ่งสัปดาห์ ให้ใช้ Spec Kit อย่างแน่นอน เวลาที่ประหยัดได้จะชดเชยเวลาหนึ่งชั่วโมงที่ใช้เขียนข้อกำหนดได้ถึงห้าเท่า หากอยู่ระหว่าง 2 ชั่วโมงกับหนึ่งสัปดาห์ ให้ใช้วิจารณญาณของคุณ แม้โดยส่วนตัวฉันเขียน spec แม้แต่ฟีเจอร์ที่ใช้เวลาครึ่งวัน เพราะชิ้นงานใน repo มีค่ามากกว่าเวลาครึ่งชั่วโมงที่ประหยัดได้

## ต่อไปทำอะไร: จะผสาน Spec Kit เข้ากับโปรเจกต์อย่างไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

ประเด็นสำคัญ

ขั้นตอนแรกที่ง่ายที่สุดคือทดลอง Spec Kit กับฟีเจอร์เล็ก ๆ ที่สร้างใหม่ แทนที่จะเริ่มจากโปรเจกต์เดิมทั้งโปรเจกต์ ติดตั้ง เริ่มต้นใช้งานใน repo รัน `/speckit-specify` กับฟีเจอร์หนึ่งรายการ แล้วดูชิ้นงานที่ได้ ในหนึ่งหรือสองสัปดาห์ คุณจะเริ่มรู้ว่าเมื่อใดควรเปลี่ยนมาใช้ และเมื่อใดควรใช้พรอมป์ต์สั้น ๆ ต่อไป วิธีการครบชุดประกอบด้วย CLAUDE.md + Spec Kit + Skills + เอเจนต์ย่อย

</div>

แผนที่ทำได้จริงสำหรับ 7 วันข้างหน้า:

- **วันที่ 1** ติดตั้ง uv และ Spec Kit (5-10 นาที) ตรวจสอบว่าคำสั่ง `/speckit-*` ปรากฏใน Claude Code แล้ว อย่าลองใช้กับโปรเจกต์เดิม—เริ่มจากโปรเจกต์ใหม่
- **วันที่ 2** เลือกฟีเจอร์จริงที่คุณวางแผนจะสร้าง รัน `/speckit-specify` พร้อมคำอธิบายแบบอิสระ เปิด `spec.md` อ่าน แล้วตอบ `[NEEDS CLARIFICATION]` ให้ครบ อย่ารีบไป Plan
- **วันที่ 3** รัน `/speckit-plan` พร้อมคำใบ้เกี่ยวกับสแต็กของคุณ อ่าน `plan.md` โดยเฉพาะส่วน Architecture Decisions หากมีอะไรไม่เหมาะ ให้แก้ไขด้วยตนเอง
- **วันที่ 4-5** รัน `/speckit-tasks` แล้วรัน `/speckit-analyze` เพื่อตรวจชุด spec, plan และ tasks อีกครั้ง จากนั้นรัน `/speckit-implement` ดูว่า Claude ทำเครื่องหมาย `[x]` ใน `tasks.md` อย่างไร บางจุดอาจติดขัด—เป็นเรื่องปกติ กลับไปที่ `spec.md` ชี้แจงข้อกำหนด แล้วเริ่ม `/speckit-implement` ใหม่โดยระบุงานเฉพาะ เมื่อปิดงานครบแล้ว ให้รัน `/speckit-converge` และทำซ้ำขั้นตอน Implement กับ Converge จนกว่าจะได้คำตอบ “Converged”
- **วันที่ 6-7** ตรวจ PR (หรือชุด PR) แล้ว merge อ่าน `spec.md` และ `plan.md`—นี่คือเอกสารฟีเจอร์ของคุณสำหรับปีที่จะมาถึง

สิ่งที่แนะนำให้อ่านควบคู่กัน:

- [วิธีตั้งค่า CLAUDE.md ในปี 2026](https://ailoot.ai/blog/th/claude-md-template/) - พื้นฐานสำหรับ constitution ของ Spec Kit
- [Plan Mode ใน Claude Code](https://ailoot.ai/blog/th/claude-code-plan-mode/) - ทางเลือกด่วนสำหรับงานเล็ก ๆ
- [วิศวกรรมบริบทในปี 2026](https://ailoot.ai/blog/th/context-engineering/) - เหตุผลที่ Spec Kit ใช้ได้ผล
- [Skills, Subagents, MCP หรือ Plugins](https://ailoot.ai/blog/th/skills-subagents-mcp-plugins-claude-code/) - สิ่งที่เพิ่มให้ Spec Kit เพื่อปรับเวิร์กโฟลว์ของคุณได้
- [Dynamic Workflows ใน Claude Code](https://ailoot.ai/blog/th/claude-code-dynamic-workflows/) - วิธีเปิดเอเจนต์ย่อยหลายตัวพร้อมกันในขั้น Implement

<div class="section" role="doc-bibliography" aria-label="Sources">

### แหล่งที่มา

- [GitHub Spec Kit - repo](https://github.com/github/spec-kit)
- [GitHub Spec Kit - เอกสารทางการ](https://github.github.com/spec-kit/)
- [Spec-Driven Development - ข้อความวิธีการอย่างเป็นทางการ](https://github.com/github/spec-kit/blob/main/spec-driven.md)
- [เทมเพลต spec - GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md)
- [บล็อก AWS Industries - จากข้อกำหนดสู่ production: เอเจนต์ค้นพบยา Kiro (18 กุมภาพันธ์ 2026)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/)
- [เอกสาร Claude Code - เอเจนต์ย่อย](https://code.claude.com/docs/en/sub-agents)
- [เอกสาร Claude Code - Skills](https://code.claude.com/docs/en/skills)
- [เอกสาร Claude Code - คำสั่ง](https://code.claude.com/docs/en/commands)

</div>

เวิร์กโฟลว์บริบทครบชุด: โคลน AI + Second Brain + วิศวกรรมบริบท



อ่านเนื้อหาเพิ่มเติมได้ที่ [Ailoot](https://ailoot.ai/).

## คำถามที่พบบ่อย

### ทำไม cleanup รายวันไม่พอกับข้อกำหนดลบ 48 ชั่วโมง?

บัญชีที่ครบเส้นตายหลังรอบรายวันอาจรอเกือบอีกวัน ต้องชี้แจงเวลาล่าช้าที่ยอมใน spec เลือกตารางให้ตรง และทดสอบทั้งเกณฑ์ 48 ชั่วโมงกับความล่าช้าสูงสุด

### plan.md ขัด spec.md ควรทำอย่างไร?

กลับไปข้อกำหนดและแก้ความไม่ตรงก่อนพัฒนา อัปเดต specification แผน งาน และเกณฑ์ยอมรับร่วมกัน แล้วใช้ Analyze กับการตรวจ implementation ยืนยันพฤติกรรมที่ตกลงเดียวกัน


## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท

Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง

บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน.

Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ