9 款工具如何組成 AI 軟件開發流程，從需求到自動化測試是否完整？

9 เครื่องมือประกอบไปป์ไลน์ AI เขียนซอฟต์แวร์: จาก requirement ถึงเทสต์อัตโนมัติ ครบหรือยัง?

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI และระบบเปิด | ตรวจสอบข้อมูล ณ 23 ต.ค. 2026

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

เริ่มจากคำถามที่ผมเจอบ่อย

คนส่วนใหญ่ที่อยากให้ AI เขียนซอฟต์แวร์ให้ มักเริ่มด้วยการเลือก agent หนึ่งตัว แล้วพบว่ามันแก้โค้ดได้ แต่ไม่รู้ว่าจะเอาไปผูกกับงานจริงตรงไหน

ผมลองวางไปป์ไลน์นี้บนกระดาษหลายรอบจนเหลือเก้าอย่างที่ขาดแล้วทำไม่ครบ

เก้าอย่างนี้ไม่ใช่ลิสต์เครื่องมือยอดนิยม แต่เป็นการจับคู่ช่องว่างทีละช่องว่าใครรับงานต่อจากใคร และวางเป็นไปป์ไลน์ที่ครบวงจร

สรุปสั้น

• spec-kit ทำหน้าที่แปลง requirement เป็น spec, plan และ task list ที่ agent ใช้ทำงานต่อ
• Claude Code หรือ Codex เป็นคนเขียนโค้ดจริง คุณเลือกอย่างใดอย่างหนึ่งเป็นตัวหลัก
• OpenHands ใช้ตอนที่งานต้องรันหลายคำสั่งใน Docker sandbox เพื่อไม่ให้ agent แตะเครื่องจริงของคุณ
• Qodo Cover เขียนเทสต์เพิ่มในส่วนที่ coverage ยังขาด
• git กับ GitHub เป็นที่เก็บประวัติและจุดตัดสินว่าจะ merge อะไร
• pytest-cov เป็นตัวออกรายงาน coverage ที่ Qodo Cover ต้องใช้
• GitHub Actions เป็นที่รันทุกด่านอัตโนมัติเมื่อมี pull request
• Docker ทำให้สภาพแวดล้อมเหมือนกันทุกเครื่อง
• secrets management กันคีย์ของทั้งสี่บริการหลุดเข้า repo

1. spec-kit: ชั้นที่แปลงความต้องการเป็นงาน

spec-kit เป็นเครื่องมือของ GitHub ที่วางกระบวนการ spec-driven development

ติดตั้งด้วยสองคำสั่งนี้

uv tool install specify-cli
specify init my-project --integration copilot

เงื่อนไขขั้นต่ำคือ Python 3.11 ขึ้นไป, uv และ coding agent หนึ่งตัวที่รองรับ [1]

คำสั่ง --integration คือจุดที่คุณเลือกว่า agent ตัวไหนจะทำงานในโปรเจกต์นี้ ตัวอย่างใน README ใช้ copilot แต่มีตัวเลือกอื่นให้เลือกตาม agent ที่คุณมี

เมื่อรันงานต่อเนื่อง มันจะสร้างโฟลเดอร์ต่อฟีเจอร์ เช่น specs/003-chat-system/ ที่มี spec.md, plan.md, research.md, data-model.md, quickstart.md และ tasks.md [2]

มีไฟล์ memory/constitution.md ทำหน้าที่เป็นหลักการที่ผูกทุกฟีเจอร์ไว้ด้วยกัน เอกสารของโปรเจกต์เรียกมันว่าเป็น DNA ทางสถาปัตยกรรมของระบบ [2]

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

จุดที่ต้องระวังคือ spec ที่กำกวมจะถูกขยายเป็นแผนที่กำกวมกว่าเดิม เพราะ agent ไม่มีทางรู้ว่าคุณหมายถึงอะไรถ้าคุณไม่ได้เขียนไว้

2. Claude Code หรือ Codex: คนเขียนโค้ด

spec-kit ไม่มีโมเดลในตัว มันสั่งงานผ่าน agent ที่ติดตั้งในเครื่อง

Claude Code ต้องมีแผน Pro, Max, Team หรือ Enterprise โดย Pro เริ่มที่ 20 ดอลลาร์ต่อเดือน และ Max เริ่มที่ 100 ดอลลาร์ [3]

Codex มี action สำหรับ GitHub เช่นกัน [5]

ถ้าอยากให้ agent ทำงานเองเมื่อมี pull request หรือ issue ต้องเพิ่ม action เข้าไปใน repo

• anthropics/claude-code-action สัญญาอนุญาต MIT 9,611 ดาว อัปเดต 22 ต.ค. 2026 [4]
• openai/codex-action สัญญาอนุญาต Apache-2.0 1,277 ดาว อัปเดต 20 ต.ค. 2026 [5]

ถ้าไม่ตั้ง action ใน CI คุณจะต้องสั่ง agent เองทุกครั้ง ซึ่งไม่ต่างจากการจ้างคนเขียนโค้ดที่ต้องนั่งเฝ้า

คำแนะนำจากประสบการณ์วางระบบ: เลือกตัวหนึ่งเป็นผู้เขียนหลัก แล้วประกาศให้ชัดใน README ของโปรเจกต์

ในมุมมองของผม ถ้าใช้ทั้งคู่โดยไม่แบ่งบทบาท คุณจะเจอ diff ที่ขัดกันและรีวิวไม่ตรงประเด็น

3. OpenHands: agent ที่เลือกได้ว่าจะอยู่ใน sandbox หรือไม่

OpenHands มี 91,600 ดาว สัญญาอนุญาต MIT และอัปเดตล่าสุด 23 ต.ค. 2026 [6]

README ของโปรเจกต์วางทางติดตั้งไว้หลายทาง และความต่างสำคัญอยู่ที่ว่ามันมี sandbox หรือไม่

ทางที่หนึ่ง ไม่มี sandbox รันบนเครื่องคุณโดยตรง

npm install -g @openhands/agent-canvas
agent-canvas

README เตือนเองว่าทางนี้ agent จะเข้าถึงไฟล์ในเครื่องได้ทั้งหมด [6]

ทางที่สอง มี Docker sandbox agent ทำงานใน container

export PROJECTS_PATH="$HOME/projects"
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"
docker run -it --rm -p 127.0.0.1:8000:8000 -e AGENT_CANVAS_ALLOW_LAN_SESSION_KEY=true -v "$HOME/.openhands:/home/openhands/.openhands" -v "$PROJECTS_PATH:/projects" ghcr.io/openhands/agent-canvas:1.32.0

ยังมีทางที่สามที่ใช้ Docker หลายตัว และทางที่สี่คือ build จากซอร์ส [6]

ถ้าคุณต้องการ sandbox จริง ต้องเลือกทาง Docker เท่านั้น

ในมุมมองของผม OpenHands ที่รันใน Docker sandbox เหมาะกับงานที่ต้องรันคำสั่งซ้ำหลายรอบ เช่น ติดตั้ง dependency แล้วรันเทสต์วนจนผ่าน เพราะล้มแล้วทิ้ง container ได้

ส่วน Claude Code เหมาะกับงานที่คุณนั่งดูอยู่และอยากอนุมัติทีละขั้น

ข้อเปรียบเทียบนี้เป็นการตีความของผมจากสถาปัตยกรรมของทั้งสองตัว ไม่ใช่ถ้อยจากเอกสารของโปรเจกต์

4. Qodo Cover: ตัวเขียนเทสต์

Qodo Cover มี 5,668 ดาว สัญญาอนุญาต AGPL-3.0 อัปเดตล่าสุด 5 เม.ย. 2026 [7]

มันทำงานเดียวคือเพิ่ม coverage โดยสร้างเทสต์ใหม่ในส่วนที่ยังไม่มีใครทดสอบ

ก่อนใช้ต้องเตรียมสองอย่างตาม README

1. ตัวแปรสภาพแวดล้อม OPENAI_API_KEY
2. รายงาน coverage แบบ Cobertura XML ที่มีอยู่แล้ว

ตัวอย่างการออกรายงานฝั่ง Python

pytest --cov=src --cov-report=xml

ถ้าไม่มีไฟล์ XML นี้ Qodo Cover ไม่มีทางรู้ว่าส่วนไหนขาด จึงเริ่มงานไม่ได้

กับดักที่สำคัญที่สุด: coverage ที่เพิ่มขึ้นไม่ได้แปลว่าเทสต์จับบั๊กได้

เทสต์ที่เขียนเพื่อให้บรรทัดถูกเรียกใช้ แต่ไม่ตรวจผลลัพธ์ ก็ทำให้ตัวเลขสวยได้เหมือนกัน

ทางแก้คือใช้ mutation testing อย่าง mutmut [12] หรือ Stryker [13] ซึ่งจงใจทำโค้ดพังแล้วดูว่าเทสต์จับได้ไหม

5. git กับ GitHub: ที่เก็บและจุดตัดสิน

ส่วนนี้ฟังดูธรรมดา แต่เป็นที่ที่คนพลาดมากที่สุด

ถ้าไม่มี branch protection ที่บังคับให้เช็กผ่านก่อน merge ไปป์ไลน์ทั้งหมดจะกลายเป็นคำแนะนำที่ไม่มีใครบังคับใช้ [8]

สิ่งที่ต้องตั้งจริงมีสามอย่าง

• บังคับให้ CI ผ่านก่อน merge
• บังคับให้มีคนอนุมัติอย่างน้อยหนึ่งคน
• ห้าม push ตรงเข้า main

6. pytest-cov: ตัวเลขที่ใช้ตัดสิน

pytest-cov ไม่ได้แค่รายงาน มันตั้งเกณฑ์ขั้นต่ำได้

pytest --cov=src --cov-report=xml --cov-fail-under=80

บรรทัดนี้ทำให้ CI ล้มเมื่อ coverage ต่ำกว่า 80 เปอร์เซ็นต์ ตัวเลือกทั้งสองมาจากเอกสารของ pytest-cov ตรง ๆ [9]

ถ้าไม่มีเกณฑ์ ตัวเลขจะกลายเป็นกราฟสวยที่ไม่มีใครดู

7. GitHub Actions: ที่รันทุกอย่าง

นี่คือชิ้นที่ทำให้ทั้งเก้าอย่างต่อกันเป็นระบบ

ตัวอย่าง workflow ที่ผมจะเริ่มใช้

name: ai-pipeline
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt pytest pytest-cov ruff
      - run: ruff check .
      - run: pytest --cov=src --cov-report=xml --cov-fail-under=80

ถ้าต้องการให้ agent ทำงานใน CI ด้วย ให้เพิ่ม step ที่เรียก claude-code-action หรือ codex-action ต่อจากขั้นทดสอบ

ข้อควรระวังด้านความปลอดภัย: workflow ที่รันจาก pull request ของคนนอกจะได้สิทธิ์จำกัด และห้ามให้สิทธิ์เขียน repo กับ workflow นั้นเด็ดขาด [10]

8. Docker: ความเหมือนที่ทำให้ผลลัพธ์เชื่อถือได้

ถ้าคุณรัน OpenHands แบบ Docker sandbox agent อยู่ใน container อยู่แล้ว แต่กับโปรเจกต์ของคุณเองคุณยังต้องทำ Docker Compose ให้ตรงกับ CI

เหตุผลคือ agent ทำงานได้ดีแค่ในสภาพแวดล้อมที่มันทดสอบได้จริง ถ้าเครื่องคุณมี Python 3.12 แต่ CI ใช้ 3.10 เทสต์ที่ผ่านในเครื่องอาจพังบน CI

Docker Compose หนึ่งไฟล์ที่ระบุเวอร์ชันให้ตรงกับ CI แก้ปัญหานี้ได้ทั้งเรื่อง

9. Secrets: ที่ที่คนมักทำพลาดเงียบ ๆ

คุณมีคีย์อย่างน้อยสี่ชุดในไปป์ไลน์นี้

• Anthropic สำหรับ Claude Code
• OpenAI สำหรับ Qodo Cover
• คีย์โมเดลสำหรับ OpenHands
• โทเคนสำหรับ GitHub Action

ทั้งหมดต้องอยู่ใน GitHub Actions secrets หรือ password manager [11]

ห้ามอยู่ในไฟล์ .env ที่ commit ขึ้น repo และควรเปิด secret scanning ของ GitHub ไว้ [14]

ถ้าคีย์หลุดไปแล้ว การลบ commit ไม่ช่วย เพราะมันอยู่ในประวัติและอาจถูก fork ไปแล้ว

ลำดับติดตั้งที่ผมแนะนำ

1. uv tool install specify-cli
2. specify init my-project --integration <agent ที่คุณใช้>
3. ตั้ง repo, branch protection, secrets
4. เพิ่ม pytest + pytest-cov แล้วทำให้ coverage XML ทำงาน
5. เพิ่ม ruff และ GitHub Actions
6. เพิ่ม Qodo Cover เมื่อข้อ 4 ทำงานแล้ว
7. เพิ่ม OpenHands เมื่อต้องการ sandbox (เลือกทาง Docker ถ้าต้องการให้ agent อยู่ใน container)
8. เตรียม secrets ให้ครบก่อนเปิด action ใด ๆ

ข้อ 6 ต้องมาหลังข้อ 4 เสมอ เพราะมันกินรายงานที่ข้อ 4 สร้าง

ไปป์ไลน์ที่ต่อกันแล้ว

Issue (requirement)
  -> spec-kit: spec.md -> plan.md -> tasks.md
  -> Claude Code หรือ Codex เขียนโค้ด (หรือ OpenHands ใน Docker sandbox)
  -> Pull Request
  -> GitHub Actions: ruff -> pytest -> coverage gate
  -> Qodo Cover เพิ่มเทสต์ในส่วนที่ขาด
  -> คนรีวิวและอนุมัติ
  -> merge

secrets: เก็บคีย์ทั้งหมดใน GitHub Actions secrets
Docker: ใช้เมื่อต้องการสภาพแวดล้อมตรงกับ CI หรือรัน OpenHands แบบ sandbox

ห้าข้อที่ผมอยากเตือนก่อนคุณเริ่ม

หนึ่ง coverage ไม่ใช่คุณภาพ ใช้ mutation testing ช่วยตรวจ

สอง อย่าให้ agent แก้เทสต์เพื่อให้ผ่าน เพราะนั่นคือการย้ายเสาเข็ม

สาม ตั้งเพดานค่าใช้จ่ายต่อวันก่อนเปิด agent ทำงานอัตโนมัติ

สี่ requirement ที่มาจาก issue ภายนอกเป็นช่องทาง prompt injection ได้ ต้องมีคนอ่านก่อน agent อ่าน

ห้า สัญญาอนุญาต AGPL ของ Qodo Cover อาจไม่เหมาะกับงานที่คุณต้องแจกจ่ายต่อ

ถ้าจะเริ่มในหนึ่งสัปดาห์

วันแรก ติดตั้ง spec-kit และเขียน spec ของฟีเจอร์เล็ก ๆ หนึ่งอย่าง

วันที่สอง ต่อ Claude Code หรือ Codex ให้ implement งานนั้นจนจบ

วันที่สาม ตั้ง pytest-cov และ GitHub Actions

วันที่สี่ เพิ่ม Qodo Cover และดูว่าเทสต์ที่มันเขียนมีคุณภาพแค่ไหน

วันที่ห้า เพิ่ม branch protection และให้คนอื่นรีวิว

ห้าวันนี้ยังไม่ต้องใช้ Docker, OpenHands และ secrets ของ agent สามอย่างนี้รอตอนที่คุณต้องการ sandbox และงานอัตโนมัติ

เครื่องมือที่เหลือรอไว้ตอนที่คุณต้องการทำงานอัตโนมัติมากขึ้น

แหล่งอ้างอิง

[1] GitHub, "github/spec-kit" README, สืบค้น 23 ต.ค. 2026 (Python 3.11+, uv, คำสั่ง uv tool install specify-cli และ specify init). https://github.com/github/spec-kit
[2] GitHub, "spec-driven.md" ใน github/spec-kit, สืบค้น 23 ต.ค. 2026 (ไฟล์ต่อฟีเจอร์ spec.md, plan.md, research.md, data-model.md, quickstart.md, tasks.md และ memory/constitution.md). https://github.com/github/spec-kit/blob/main/spec-driven.md
[3] Anthropic, หน้าราคา Claude, สืบค้น 23 ต.ค. 2026 (Pro 20 ดอลลาร์ต่อเดือน, Max เริ่ม 100 ดอลลาร์). https://www.claude.com/pricing
[4] GitHub, "anthropics/claude-code-action", สืบค้น 23 ต.ค. 2026 (MIT, 9,611 ดาว, อัปเดต 22 ต.ค. 2026). https://github.com/anthropics/claude-code-action
[5] GitHub, "openai/codex-action", สืบค้น 23 ต.ค. 2026 (Apache-2.0, 1,277 ดาว, อัปเดต 20 ต.ค. 2026). https://github.com/openai/codex-action
[6] GitHub, "OpenHands/OpenHands" README, สืบค้น 23 ต.ค. 2026 (MIT, 91,600 ดาว, สถานะ beta, คำสั่ง docker run ghcr.io/openhands/agent-canvas:1.32.0 และ npm install -g @openhands/agent-canvas ซึ่งต้องใช้ Node 24 กับ uv). https://github.com/OpenHands/OpenHands
[7] GitHub, "qodo-ai/qodo-cover" README, สืบค้น 23 ต.ค. 2026 (AGPL-3.0, 5,668 ดาว, ต้องมี OPENAI_API_KEY และรายงาน Cobertura XML, ติดตั้งผ่าน pip หรือไบนารี). https://github.com/qodo-ai/qodo-cover
[8] GitHub Docs, "About protected branches", สืบค้น 23 ต.ค. 2026 (การบังคับให้เช็กผ่านก่อน merge และการห้าม push ตรงเข้า main). https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
[9] pytest-cov, "pytest-cov documentation", สืบค้น 23 ต.ค. 2026 (ตัวเลือก --cov-report=xml และ --cov-fail-under). https://pytest-cov.readthedocs.io/en/latest/
[10] GitHub Docs, "Security hardening for GitHub Actions", สืบค้น 23 ต.ค. 2026 (ข้อจำกัดสิทธิ์ของ workflow ที่รันจาก pull request และแนวปฏิบัติเรื่อง secrets). https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions
[11] GitHub Docs, "Using secrets in GitHub Actions", สืบค้น 23 ต.ค. 2026 (การเก็บค่า-sensitive ใน repository secrets และข้อจำกัดการเข้าถึง). https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions
[12] GitHub, "boxed/mutmut", สืบค้น 23 ต.ค. 2026 (BSD-3-Clause, 1,501 ดาว, อัปเดต 19 ต.ค. 2026 · mutation testing สำหรับ Python). https://github.com/boxed/mutmut
[13] GitHub, "stryker-mutator/stryker-js", สืบค้น 23 ต.ค. 2026 (Apache-2.0, 3,268 ดาว, อัปเดต 10 ต.ค. 2026 · mutation testing สำหรับ JavaScript). https://github.com/stryker-mutator/stryker-js
[14] GitHub Docs, "About secret scanning", สืบค้น 23 ต.ค. 2026 (การตรวจจับข้อมูลลับที่ถูก commit เข้า repository). https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning