ประกอบไปป์ไลน์ CI ด้วย AI agent: จาก requirement ถึง pull request ต้องเขียนไฟล์อะไรบ้าง?

โดย Nokka (นก-กา) | ตอนที่ 6 จาก 7 ของชุด "สร้างซอฟต์แวร์ด้วย AI" | ตรวจสอบข้อมูล ณ 23 ต.ค. 2026

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

ห้าตอนที่ผ่านมาพูดถึงเครื่องมือแยกชิ้น บทนี้จะเอามันมาต่อกันเป็นสายงานเดียว

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

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

ขั้นที่ 1 รับ requirement ให้มีที่อยู่

ก่อนจะพูดถึง agent ต้องตอบก่อนว่า requirement มาจากไหน

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

ทางที่ผมใช้คือ GitHub Issue หนึ่งใบต่อหนึ่งงาน และเขียนให้มีสามส่วน คือ ปัญหาที่เจอ พฤติกรรมที่ต้องการ และเกณฑ์ว่าถือว่าเสร็จ

เกณฑ์ข้อสามสำคัญที่สุด เพราะมันจะกลายเป็นเป้าของ agent และเป็นฐานของเทสต์ในขั้นสุดท้าย

ขั้นที่ 2 แปลง issue เป็น spec

ที่นี่คือจุดที่ spec-kit เข้ามา จากตอนที่ 2 ผมติดตั้งและรัน specify init ในเครื่องนี้จริง ได้ specify 1.2.3 [1]

ชื่อคำสั่งในเวอร์ชันนี้ใช้ขีดกลาง ไม่ใช่จุด คือ speckit-specify, speckit-plan, speckit-tasks และ speckit-implement และเมื่อเรียกจาก Claude Code จะเติม / ข้างหน้าเป็น /speckit-specify [1]

คำสั่งแรกจะสร้างโฟลเดอร์ต่อฟีเจอร์ ภายใต้ specs/ และเขียน spec.md ที่บังคับสามส่วน คือ user scenarios พร้อมลำดับความสำคัญ, requirements และ success criteria ที่วัดได้ [2]

ผมชอบที่แม่แบบบังคับให้เขียน success criteria แบบวัดได้ เพราะมันบังคับให้คนคิดก่อนว่า "เสร็จ" หน้าตาเป็นอย่างไร

ถ้าคุณข้ามขั้นนี้แล้วบอก agent ว่า "ทำฟีเจอร์นี้ให้หน่อย" ผลที่ได้คือโค้ดที่เดาความต้องการของคุณ

ขั้นที่ 3 แตกเป็น task ที่หยิบทำได้

speckit-tasks จะแปลงแผนเป็นรายการงานที่เรียงตามลำดับการพึ่งพา

แต่ละงานควรเล็กพอที่ agent ทำจบในรอบเดียว และมีเกณฑ์ตรวจรับในตัว

ถ้างานใหญ่เกิน วิธีที่ได้ผลคือแตกเป็นงานย่อยก่อน แล้วค่อยให้ agent ทำทีละงาน

ตรงนี้เป็นจุดที่หลายทีมเข้าใจผิด คิดว่า agent ทำงานใหญ่ได้ในครั้งเดียว ความจริงคือยิ่งงานใหญ่ ยิ่งมีจุดที่มันเดาผิดมากขึ้น

ขั้นที่ 4 ให้ agent ลงมือ

ขั้นนี้คือที่ OpenHands หรือ agent ในเครื่องอย่าง Claude Code ทำงาน [3]

เงื่อนไขที่ต้องมีก่อนคือเพดานสามอย่าง คือ จำนวนรอบ ค่าใช้จ่าย และขอบเขตไฟล์ที่แตะได้

ถ้าไม่มีเพดาน พฤติกรรมที่เจอบ่อยคือ agent วนแก้งานเดิมซ้ำ ๆ เพราะไม่มีสัญญาณว่าพอแล้ว และค่า token จะไต่ขึ้นทุกรอบ

ผลลัพธ์ที่ต้องได้คือ branch หนึ่งอันกับ pull request ที่มีคำอธิบายว่าทำอะไรและอ้าง issue ไหน

ขั้นที่ 5 ด่านตรวจอัตโนมัติใน CI

ไฟล์ workflow ที่อ่านแล้วทำตามได้

นี่คือส่วนที่คนอ่านนำไปใช้มากที่สุด ผมเขียน workflow ตัวอย่างไว้ด้านล่าง

name: quality-gate
on:
  pull_request:
permissions:
  contents: read
  pull-requests: write
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt pytest pytest-cov
      - run: pytest --cov=. --cov-report=xml --cov-fail-under=70
      - uses: actions/upload-artifact@v7
        with:
          name: coverage
          path: coverage.xml
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

เวอร์ชันที่ผมใช้ในไฟล์นี้ตรวจจากรีลีสล่าสุดวันนี้ คือ checkout v7.0.1 setup-python v7.1.0 upload-artifact v7.0.2 และ gitleaks-action v3.0.0 [4]

จุดที่ต้องระวังคือ gitleaks-action ต้องมีตัวแปร GITLEAKS_LICENSE เมื่อใช้กับบัญชีองค์กร แต่ไม่ต้องใช้กับบัญชีผู้ใช้ทั่วไป และ GitHub จัดสถานะสัญญาอนุญาตของ action นี้เป็น NOASSERTION จึงควรเปิดไฟล์อนุญาตเองก่อนใช้ในองค์กร

ผมประกาศบล็อก permissions: ไว้บนสุดเพื่อจำกัดสิทธิ์ของ token ให้แคบที่สุด ค่าเริ่มต้นของ pull request จาก fork คือสิทธิ์อ่านอย่างเดียว แต่เจ้าของ repo เปลี่ยนได้ด้วยตัวเลือกที่อนุญาตให้ workflow จาก fork รันด้วยสิทธิ์เขียน และเอกสารความปลอดภัยของ GitHub ไม่ได้รับรองความปลอดภัยในทุกกรณี [7]

ถ้าอยากให้ agent LLM ทำงานเมื่อมี pull request ก็เพิ่ม claude-code-action ซึ่งเป็น MIT 9,616 ดาว commit 22 ต.ค. 2026 [5]

ผมยังไม่ใส่ตัวนั้นในตัวอย่างข้างบน เพราะมันต้องมี API key ของผู้ให้บริการโมเดลและต้องกำหนดสิทธิ์ให้แคบ ซึ่งควรคุยกันก่อน

ชั้นที่ 6 ที่คนมักลืม คือคนเซ็นรับ

ค่า --cov-fail-under=70 ในไฟล์ข้างบนเป็นตัวเลขตัวอย่างที่ผมเลือกเอง ไม่ได้มาจากแหล่งใด ทีมควรตั้งจากสภาพจริงของโปรเจกต์

ด่านสุดท้ายไม่ใช่ CI แต่เป็นคนที่กด merge

กฎที่ผมแนะนำคือ branch หลักต้องมี protection บังคับให้ CI ผ่านก่อน merge และกำหนดจำนวนผู้อนุมัติตามนโยบายของทีม [6] ถ้าทีมมีคนเดียว กฎนี้จะทำให้คุณ merge เองไม่ได้ ต้องตั้งข้อยกเว้นให้ชัด [6]

ถ้า agent เป็นคนเขียน PR คนอนุมัติต้องเป็นมนุษย์เสมอ

ส่วนคนที่ปล่อยให้ agent merge เองโดยไม่มีคนดู ผมเคยเห็นในตัวอย่างสาธิต แต่ยังไม่เห็นทีมจริงที่ทำแบบนั้นกับระบบที่มีผู้ใช้

สิ่งที่ผมรันเองได้และรันไม่ได้ในบทนี้

เครื่องที่ผมใช้อยู่ไม่มี Docker ไม่มีสิทธิ์เข้าถึง GitHub repo ของคุณ และไม่มีคีย์โมเดลของผู้ให้บริการรายใหญ่

ผมจึงทดสอบ workflow ข้างบนบน GitHub Actions ไม่ได้ และจะไม่เขียนว่า "ทดสอบแล้วผ่าน"

ที่ผมทำได้และทำจริงคือ ติดตั้ง spec-kit รัน specify init เปิดไฟล์ที่มันสร้าง และตรวจว่าคำสั่งกับแม่แบบมีอยู่จริงตามที่เขียน [1][2]

ถ้าคุณมี repo ทดลองและให้สิทธิ์ ผมเขียน workflow นี้ให้พร้อมรันและช่วยอ่าน log ได้ คุณไม่ต้องมี Docker ในเครื่องก็ทำได้ เพราะงานทั้งหมดรันบน runner ของ GitHub

เช็กลิสต์ก่อนเปิดใช้ไปป์ไลน์นี้

1. requirement ทุกงานมี issue เป็นที่อยู่หรือยัง
2. spec มี success criteria ที่วัดได้หรือยัง
3. task ถูกแตกเล็กพอให้จบในรอบเดียวหรือยัง
4. มีเพดานรอบ เพดานเงิน และขอบเขตไฟล์หรือยัง
5. CI บังคับ coverage ขั้นต่ำและสแกนความลับหรือยัง
6. ใครเป็นคนกด merge และมีกฎห้าม merge เองหรือยัง

ถ้าตอบข้อ 6 ไม่ได้ ไปป์ไลน์นี้ยังไม่พร้อมใช้กับระบบจริง

บทเรียนที่ผมอยากฝากไว้

ไปป์ไลน์ที่ดีไม่ได้ทำให้ agent เก่งขึ้นแต่มันทำให้ความผิดพลาดถูกจับเร็วขึ้น

ความต่างระหว่างทีมที่ใช้ agent ได้ผลกับทีมที่เลิกใช้ มักไม่ได้อยู่ที่โมเดล แต่อยู่ที่ว่ามีด่านตรวจกี่ชั้น

ถ้าคุณกำลังจะเริ่มต้นสายงานแบบนี้ เล่าให้ผมฟังได้ว่าทีมใช้ GitHub หรือเครื่องมืออะไรอยู่ และมีคนรีวิวกี่คน

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

[1] GitHub, "github/spec-kit" README และแม่แบบใน templates/, สืบค้น 23 ต.ค. 2026 (MIT · 142,492 ดาว · คำสั่ง speckit-specify, speckit-plan, speckit-tasks, speckit-implement และโครง spec.md สามส่วน). https://github.com/github/spec-kit

[2] GitHub, "github/spec-kit" แม่แบบ templates/spec-template.md และ templates/plan-template.md, สืบค้น 23 ต.ค. 2026 (โครงสามส่วนของ spec, หัวข้อ Constitution Check ใน plan) · ตรวจกับไฟล์ที่ specify 1.2.3 สร้างในเครื่องนี้เมื่อ 23 ต.ค. 2026 ด้วย. https://github.com/github/spec-kit/blob/main/templates/spec-template.md

[3] GitHub, "OpenHands/OpenHands" README, สืบค้น 23 ต.ค. 2026 (MIT · 91,600 ดาว · commit 23 ต.ค. 2026 · ระบุทางรันใน container และบนเครื่องตรงผ่าน npm). https://github.com/OpenHands/OpenHands

[4] GitHub, "actions/checkout", "actions/setup-python", "actions/upload-artifact" และ "gitleaks/gitleaks-action", สืบค้น 23 ต.ค. 2026 (checkout 8,960 ดาว MIT · setup-python 2,240 ดาว MIT · upload-artifact 4,235 ดาว MIT · gitleaks-action 666 ดาว สถานะสัญญาอนุญาต NOASSERTION). https://github.com/gitleaks/gitleaks-action

[5] GitHub, "anthropics/claude-code-action" README, สืบค้น 23 ต.ค. 2026 (MIT · 9,616 ดาว · commit 22 ต.ค. 2026 · action สำหรับสั่ง Claude Code จาก workflow). https://github.com/anthropics/claude-code-action

[6] GitHub Docs, "About protected branches", สืบค้น 23 ต.ค. 2026 (กลไกบังคับให้ต้องผ่านการตรวจก่อน merge และกำหนดจำนวนผู้อนุมัติ). https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

[7] GitHub Docs, "Managing GitHub Actions settings for a repository" และ "Secure use reference", สืบค้น 23 ต.ค. 2026 (สิทธิ์ของ GITHUB_TOKEN สำหรับ pull request จาก fork และตัวเลือกส่ง write token). https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository