- DevPit คืออะไร
- DevPit กับ Claude Code เกี่ยวข้องกันอย่างไร
- ลำดับงานเริ่มต้น
- เริ่มต้นใช้งาน
- กิจกรรมทดลอง: เพิ่ม Health Check ให้ API
- ประเมินว่าช่วยงานได้จริงอย่างไร
- ชื่อเดียวกัน แต่อีกโครงการทำคนละหน้าที่
- แหล่งอ้างอิงและขอบเขตการตรวจสอบ
ตรวจสอบข้อมูล: 17 ตุลาคม 2026
บทความนี้หมายถึง colbymchenry/devpit ซึ่งใช้คำสั่ง
dpโดยผู้ใช้ยังไม่ได้ระบุ URL ของโครงการ
#DevPit คืออะไร

DevPit เป็นเครื่องมือจัดลำดับการทำงานของ AI coding agents โดยเปิดแต่ละขั้นใน tmux session ของตัวเอง แล้วส่งผลจากขั้นก่อนหน้าให้ขั้นถัดไป Claude Code เป็น runtime เริ่มต้นของโครงการ [1]
คิดเป็นการแบ่งงานหนึ่งชิ้นให้หลายบทบาท เช่น วางแผน เขียนโค้ด ทดสอบ และตรวจทาน คนกำหนดเป้าหมาย ส่วน DevPit จัดลำดับการส่งต่องาน การแยกบทบาทมีประโยชน์เมื่อเราต้องการเห็นว่าแผนถูกนำไปทำอย่างไร และหลักฐานการทดสอบรองรับข้อสรุปหรือไม่
#DevPit กับ Claude Code เกี่ยวข้องกันอย่างไร
| ส่วนประกอบ | หน้าที่ |
|---|---|
| Claude Code | อ่านโครงการ ใช้เครื่องมือ และทำงานตามคำสั่งของแต่ละบทบาท |
| DevPit | จัดลำดับขั้น ส่งต่อบริบท และควบคุมการวนกลับ |
| tmux | แยก terminal session เพื่อดูการทำงานของแต่ละขั้น |
| ผู้พัฒนา | ระบุข้อกำหนด ตรวจผล และตัดสินใจรับการเปลี่ยนแปลง |
Claude Code มีระบบ subagents ของตัวเองด้วย โดย subagent มีบริบทและข้อกำหนดเครื่องมือแยกกัน ส่วน DevPit ใช้การจัดลำดับ session จากภายนอก [1][2]
#ลำดับงานเริ่มต้น
README ระบุบทบาทหลักเป็น Architect → Coder → Tester → Reviewer → Design QA และมีเส้นทางย้อนกลับไปแก้ไขจากการทดสอบหรือการตรวจ UI ตาม workflow [1]
| บทบาท | ตัวอย่างผลส่งมอบที่ควรขอในการอบรม |
|---|---|
| Architect | แผนแก้ไข รายชื่อไฟล์ และเงื่อนไขที่ต้องทดสอบ |
| Coder | การเปลี่ยนแปลงที่สอดคล้องกับแผน |
| Tester | คำสั่งที่รัน ผลจริง และกรณีที่ยังไม่ผ่าน |
| Reviewer | ข้อค้นพบพร้อมตำแหน่งและแนวทางแก้ |
| Design QA | หลักฐานตรวจหน้าจอที่เกี่ยวข้องกับงาน |
ตัวอย่างผลส่งมอบในตารางเป็นข้อเสนอสำหรับการสอน ไม่ใช่การรับประกันว่าเครื่องมือจะสร้างผลครบทุกข้อโดยอัตโนมัติ งาน API อาจไม่ต้องตรวจ UI จึงควรปรับ workflow ให้เหมาะกับโครงการ
#เริ่มต้นใช้งาน
เตรียม Claude Code ที่ใช้งานได้แล้ว และ tmux รุ่น 3.0 ขึ้นไป หากติดตั้งผ่าน npm ต้องมี Node.js/npm ด้วย สำหรับ Windows ที่ต้องการใช้สภาพแวดล้อม Linux ในตัวอย่างนี้ สามารถเตรียมเครื่องมือภายใน WSL ได้ [1][3]
ตรวจเครื่องมือใน terminal:
claude --version
tmux -V
node --version
npm --version
ติดตั้งและเริ่มจากโฟลเดอร์โครงการทดลอง:
npm install -g devpit
cd /path/to/your/project
dp create --default
dp pipeline "Add a health check endpoint"
/path/to/your/project เป็นตำแหน่งตัวอย่าง ต้องเปลี่ยนให้ตรงกับเครื่องของตนเอง คำสั่งสร้าง workflow จะสร้างนิยาม agent ใน .claude/agents/ และ workflow ใน .claude/workflows/ ควรเปิดอ่านไฟล์ที่ได้ก่อนเริ่มงานจริง [1]
#กิจกรรมทดลอง: เพิ่ม Health Check ให้ API
กิจกรรมต่อไปนี้ผู้เขียนออกแบบขึ้นสำหรับโครงการ API ที่มีอยู่แล้ว ใช้ภาษาและ test framework เดิมของโครงการ เพื่อให้ผู้เรียนวัดผลจากสิ่งที่ตรวจได้จริง
ก่อนเริ่ม ให้บันทึกสถานะงานปัจจุบันและใช้ branch ทดลอง:
git status
git switch -c workshop/devpit-health-check
กำหนดโจทย์ให้ชัดเจนก่อนส่งให้ pipeline:
เพิ่ม GET /health ให้กับ API นี้
ข้อกำหนด:
- ตอบ HTTP 200 พร้อม JSON {"status":"ok"}
- endpoint นี้ไม่เรียกฐานข้อมูลหรือบริการภายนอก
- ใช้รูปแบบโค้ดและ test framework เดิมของโครงการ
- เพิ่ม automated test ของ status code และ response body
- รันชุดทดสอบเดิม และรายงานคำสั่งพร้อมผลจริง
- ห้าม commit, push หรือ deploy
ส่งโจทย์ฉบับย่อ:
dp pipeline 'Add GET /health returning HTTP 200 and JSON {"status":"ok"}. Use existing conventions and tests. Do not call external services. Run tests and report actual results. Do not commit, push, or deploy.'
หลังทำงาน ให้ผู้เรียนตรวจทั้งผลลัพธ์และหลักฐาน:
git diff --stat
git diff
จากนั้นรันคำสั่งทดสอบของโครงการเองอีกครั้ง และทดลองเรียก API หลังเปิดเซิร์ฟเวอร์ หากโครงการใช้พอร์ตอื่น ให้เปลี่ยน URL:
curl -i http://localhost:3000/health
เกณฑ์ผ่านกิจกรรมคือ endpoint ตรงตามโจทย์ มี test ตรวจ response ชัดเจน และพฤติกรรมเดิมยังผ่านชุดทดสอบ ผลสรุปของ agent อย่างเดียวไม่เพียงพอสำหรับให้คะแนน
#ประเมินว่าช่วยงานได้จริงอย่างไร
ตารางนี้เป็นข้อเสนอการทดลอง ไม่ใช่ผล benchmark ของ DevPit:
| ตัวชี้วัด | วิธีเก็บหลักฐาน |
|---|---|
| ความถูกต้องตามโจทย์ | ตรวจด้วย acceptance tests ชุดเดียวกัน |
| งานแก้ไขของคน | นับจุดที่คนต้องแก้หลัง pipeline จบ |
| เวลา | วัดตั้งแต่เริ่มจนผ่านเกณฑ์รับงาน |
| การใช้โมเดล | เก็บ usage จากระบบที่ใช้จริง |
| การส่งต่อบริบท | ตรวจว่าข้อกำหนดตกหล่นในขั้นใด |
หากเปรียบเทียบกับการใช้ Claude Code โดยตรง ควรใช้โครงการเริ่มต้น งาน และเกณฑ์ตรวจเดียวกัน การมีหลายบทบาทอาจเพิ่มเวลาและการใช้โมเดล จึงควรตัดสินจากคุณภาพงานที่ตรวจได้ร่วมกับต้นทุน
#ชื่อเดียวกัน แต่อีกโครงการทำคนละหน้าที่
ยังมี Devpit ของ zubyr.dev ซึ่งช่วยเลือกบัญชี Claude Code ตามโฟลเดอร์บน Windows ผ่าน CLAUDE_CONFIG_DIR และใช้คำสั่ง devpit เอกสารระบุข้อจำกัดว่าการสลับนี้ใช้กับ CLI และไม่ได้สลับการเข้าสู่ระบบของส่วนขยาย editor หรือ desktop app ครบทุกส่วน [4]
| โครงการ | ใช้ทำอะไร | คำสั่งหลัก |
|---|---|---|
colbymchenry/devpit |
จัด pipeline ของ coding agents | dp |
devpit.zubyr.dev |
จัดบัญชีเครื่องมือให้ตรงกับโฟลเดอร์ | devpit |