Name: เร่งงานจริงด้วย IDE Agent อย่างมีวินัย · หลักสูตร AI Coding อย่างมืออาชีพ
Author: จักริน นพรุจนธาดา

2.1

โมดูล 2.1

เจาะลึก Cursor, Copilot, Claude Code

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

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

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

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ใช้ฟีเจอร์หลัก ๆ ของ Cursor เป็น (Tab, Agent, Plan Mode, Background Agents)
เข้าใจโหมดที่ AI ลงมือทำเอง (agent mode) และตัวช่วยเขียนโค้ดบนคลาวด์ (cloud coding agent) ของ GitHub Copilot
เข้าใจผู้ช่วยย่อย (subagents), หน้าจอคุมงาน (Agent view), ไฟล์ความจำ CLAUDE.md ของ Claude Code และวิธีคิดเงินแบบเครดิต/ตามการใช้งาน

เนื้อหา

มาดูสามเครื่องมือหลักที่นักพัฒนาใช้กันแบบเจาะลึกทีละตัว เริ่มที่ Cursor ก่อน ตัวนี้มี Tab (คอยเดาว่า "จุดต่อไปที่เราน่าจะแก้" อยู่ตรงไหน ไม่ใช่แค่เดาคำถัดไป), Agent mode (โหมดที่ AI แก้ให้หลายไฟล์เองแบบอัตโนมัติ), Background/Cloud Agents (รันงานอยู่บนเครื่องข้างนอก ไม่กินเครื่องเรา), Plan Mode และยังต่อเข้ากับ MCP, rules, hooks ได้ ราคามีให้เลือกตั้งแต่ Hobby (ฟรี), Pro ($20), Pro+ ($60), Ultra ($200), Teams ($40/คน) พอถึง มิ.ย. 2025 เขาเปลี่ยนจากระบบ "500 fast requests" มาเป็นระบบเครดิตรวม (credit pool) ที่เท่ากับมูลค่าแพ็กเกจ โดยโหมด "Auto" ใช้ฟรีไม่กินเครดิต แต่ถ้าเราไปเลือกโมเดลตัวแพงเอง เครดิตก็จะโดนหักลง ต่อมาคือ GitHub Copilot ตัวนี้มีทั้งเติมโค้ดให้อัตโนมัติ, แชตถามตอบ, Agent mode (แก้ไฟล์ รันคำสั่งอย่าง npm install หรือ pytest แล้ววนแก้เองจนเสร็จ) และ cloud coding agent ที่เปิด PR ให้เองได้ ตอนนี้ Agent mode เปิดใช้เต็มรูปแบบ (GA) แล้วทั้งบน VS Code และ JetBrains ส่วนการคิดเงินจะคิดตามปริมาณที่ใช้จริงผ่าน GitHub AI Credits นับกันเป็น token สุดท้ายคือ Claude Code ตัวนี้เน้นสั่งงานผ่านหน้าจอพิมพ์คำสั่ง มีผู้ช่วยย่อย (subagents — ตั้งค่าในไฟล์ YAML แถมมี prompt กับเครื่องมือของตัวเองแยกกัน), สั่งให้ทำงานพร้อมกันหลายตัวได้, หน้าจอคุมงานที่รันอยู่เบื้องหลัง (Agent view), MCP, skills และไฟล์ความจำ CLAUDE.md เข้าถึงได้ผ่านแพ็กเกจ Pro ($20), Max ($100/$200), Team Premium หรือจะจ่ายตามจำนวน token ที่ใช้ก็ได้

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Agent modeโหมดที่ให้ AI ลงมือแก้โค้ดหลายไฟล์ให้เองอัตโนมัติ เหมือนสั่งงานแล้วมันไปทำมาให้เสร็จ ไม่ต้องเราแก้ทีละบรรทัด

next-edit vs next-tokennext-token คือการเดาตัวอักษรหรือคำถัดไป ส่วน next-edit คือการเดาว่า "จุดต่อไปที่เราจะแก้" อยู่ตรงไหนในไฟล์ ซึ่งฉลาดกว่าเพราะมันมองภาพรวมของการแก้ทั้งหมด

Background/Cloud Agentsการให้ AI รันงานอยู่บนเซิร์ฟเวอร์ข้างนอก ไม่กินเครื่องเรา เหมือนจ้างคนไปทำงานที่ออฟฟิศอื่นแทนที่จะนั่งทำบนโต๊ะเรา

Plan Modeโหมดที่ AI วางแผนให้ดูก่อนว่าจะทำอะไรบ้าง แล้วเราค่อยกดอนุมัติ ก่อนมันลงมือจริง

MCPมาตรฐานกลางที่ช่วยให้ AI ต่อเข้ากับเครื่องมือ ฐานข้อมูล หรือบริการอื่น ๆ ได้ เปรียบเหมือนปลั๊กพ่วงสากลที่เสียบต่ออะไรก็ได้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตั้ง subagent ใน Claude Code (YAML)

--- name: test-writer description: เขียน unit test สำหรับฟังก์ชันที่ระบุ รันแล้วต้องผ่าน tools: [read_file, edit_file, run_command] --- คุณเป็น subagent เขียนเทสต์ เมื่อได้รับชื่อไฟล์และฟังก์ชัน ให้เขียน unit test ครอบ edge case สำคัญ รัน test ด้วยคำสั่งของโปรเจกต์ แล้วแสดง output จริงเป็นหลักฐาน ห้ามอ้างว่าผ่านโดยไม่มี output

✅ ผลลัพธ์ที่ได้

Claude Code จะโหลดผู้ช่วยย่อยชื่อ "test-writer" ตัวนี้ขึ้นมา ซึ่งเรียกใช้ซ้ำได้เรื่อย ๆ ให้เครื่องมือมันแค่เท่าที่จำเป็น มี prompt เฉพาะทางของตัวเอง และมีพื้นที่ความจำ (context window) แยกเป็นของตัวเอง

💡 จุดสอน

ผู้ช่วยย่อยก็คือชุดตั้งค่าที่ใช้ซ้ำได้ ช่วยแยกงานเฉพาะทางออกมาเป็นบทบาทที่ชัดเจน แต่ต้องจำไว้ว่าผู้ช่วยย่อยแต่ละตัวกิน token เต็มอัตราและมีพื้นที่ความจำแยกกัน (เดี๋ยวเราจะโยงเรื่องนี้ไปที่โมดูลเรื่องต้นทุน)

แบบฝึกหัดท้ายโมดูล

ลงเครื่องมือสักตัวจากสามตัวนี้ แล้วลองใช้ทั้งสามโหมด (เติมโค้ด/แชต/agent) กับ repo ตัวอย่างดู จดไว้ด้วยว่าโหมดไหนเหมาะกับงานแบบไหน
ลองอธิบายด้วยคำพูดของตัวเองว่า ระบบเครดิตรวม (credit pool) ของ Cursor กับ GitHub AI Credits ของ Copilot ต่างจากวิธีคิดเงินแบบเดิมยังไง และทำไมคนใช้ถึงมักสับสนกัน

2.2

โมดูล 2.2

Context Engineering และไฟล์ AGENTS.md/CLAUDE.md

ทักษะที่เปลี่ยนไป: เน้นดูแลข้อมูลรอบตัว AI มากกว่าการเล่นคำสั่ง (prompt)

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนจ้างพนักงานใหม่มาทำงาน สิ่งที่สำคัญกว่าการสั่งเป็นประโยคเป๊ะๆ คือการเตรียมคู่มือ เอกสาร และข้อมูลรอบตัวให้เขาครบ เขาจะทำงานถูกเองโดยไม่ต้องจ้ำจี้

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เข้าใจว่าการจัดข้อมูลรอบตัวให้ AI (context engineering) สำคัญกว่าการนั่งเล่นคำสั่ง (prompt)
เขียนไฟล์ AGENTS.md/CLAUDE.md ด้วยมือเองให้กระชับ ตามหลัก WHAT/WHY/HOW (คืออะไร/ทำไม/ทำยังไง)
รู้ว่าทำไมไฟล์ที่ปล่อยให้ AI (LLM) เขียนเองถึงได้ผลแย่กว่าไฟล์ที่คนเขียนเอง

เนื้อหา

เรื่องที่เปลี่ยนไปมากที่สุดในทางปฏิบัติก็คือ ทักษะที่สำคัญจริง ๆ ตอนนี้ไม่ใช่การนั่งหาคำสั่ง (prompt) ที่เป๊ะ แต่เป็นการจัดข้อมูลรอบตัวให้ AI (context engineering) พูดง่าย ๆ คือการดูแลข้อมูลทุกอย่างรอบตัว agent ให้ครบ ทั้งไฟล์กฎ เอกสาร และข้อกำหนดต่าง ๆ โดยเราจะเก็บคำสั่งประจำของโปรเจกต์ไว้ในไฟล์ AGENTS.md (ตอนนี้กำลังกลายเป็นมาตรฐานกลางที่ใช้ข้ามเครื่องมือกันได้) หรือ CLAUDE.md (สำหรับ Claude Code) หลักสำคัญคือ "เขียนให้สั้นกระชับ" เพราะของจริงพบว่าคำสั่งประจำที่ AI ยังเชื่อถือได้มีเพดานอยู่ราว ๆ 150-200 บรรทัด ถ้าเกินกว่านั้นมันจะเริ่มไม่ค่อยทำตาม วิธีที่ดีคือวางโครงเป็น WHAT/WHY/HOW แล้วค่อย ๆ เผยรายละเอียดตอนที่ต้องใช้จริง และที่สำคัญคือต้อง "เขียนด้วยมือเอง" เพราะมีงานวิจัยชี้ว่าไฟล์ที่ปล่อยให้ AI เขียนเองกลับทำให้งานสำเร็จน้อยลงราว 0.5-2% แถมยังเพิ่มค่าประมวลผลกว่า 20% ในขณะที่ไฟล์ที่คนคัดสรรเขียนเองกลับให้ผลดีขึ้นราว 4 จุด

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Context Engineeringการจัดเตรียมและดูแลข้อมูลรอบตัวที่ AI เอาไปใช้ทำงาน (ทั้งไฟล์ กฎ เอกสาร) ให้ครบและเป็นระเบียบ

AGENTS.mdไฟล์ที่เก็บคำสั่งประจำโปรเจกต์เอาไว้ให้ AI อ่าน ตอนนี้กำลังกลายเป็นมาตรฐานกลางที่เครื่องมือหลายตัวใช้ร่วมกันได้

CLAUDE.mdไฟล์คำสั่งประจำโปรเจกต์แบบเดียวกัน แต่เป็นเวอร์ชันเฉพาะของ Claude

promptคำสั่งหรือคำถามที่เราพิมพ์บอก AI เหมือนโจทย์ที่เราสั่งงานให้มันทำ

agentตัว AI ที่ลงมือทำงานให้เราได้เอง ไม่ใช่แค่ตอบคำถาม แต่ทำได้หลายขั้นตอนจนจบงาน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

โครง AGENTS.md ที่เขียนด้วยมือ (ลีน)

# AGENTS.md ## Stack (WHAT) - Next.js 15 (App Router), TypeScript strict, Postgres via Prisma, Tailwind ## Conventions (HOW) - ทุก API route ต้อง validate input ด้วย zod ก่อนแตะ DB - ห้าม hardcode secret; ใช้ process.env เท่านั้น - test ด้วย vitest วางไฟล์ *.test.ts ข้างไฟล์ต้นทาง ## Do NOT (WHY) - ห้าม auto-run migration บน production DB - ห้ามเพิ่ม dependency ใหม่โดยไม่ยืนยันว่ามีอยู่จริงใน npm ก่อน

✅ ผลลัพธ์ที่ได้

agent จะอ่านไฟล์นี้ตอนเริ่มงาน แล้วทำตามทั้งเรื่อง stack, แนวทางเขียนโค้ด และข้อห้ามต่าง ๆ เพราะไฟล์สั้นพอที่ทุกบรรทัดยังได้รับความสำคัญ

💡 จุดสอน

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

แบบฝึกหัดท้ายโมดูล

เขียนไฟล์ AGENTS.md ด้วยมือเองสำหรับ repo จริงของคุณ ให้ไม่เกินราว 150 บรรทัด จัดตามโครง WHAT/WHY/HOW
ลองให้ AI สร้าง AGENTS.md ให้ แล้วเอามาเทียบกับฉบับที่คุณเขียนเอง ดูว่าฉบับที่ AI เขียนมันยาวเกินหรือคลุมเครือตรงไหนบ้าง

2.3

โมดูล 2.3

Spec-Driven Development (SDD)

Specify → Plan → Tasks → Implement โดยมีจุดพักให้คนตรวจ (human checkpoint)

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

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

🎯

ทำไมต้องรู้: เพราะพอเรามีแบบ (spec) ที่ชัดและตรวจทีละขั้น งานจะออกมาตรงใจ แก้ทีหลังน้อยลง และเราคุมทิศทางได้ตลอดแทนที่จะปล่อย AI ทำมั่วแล้วมารื้อ

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ทำงานแบบ SDD ครบสี่ขั้น โดยมีจุดพักให้คนตรวจในทุกขั้น
เขียนแบบ (spec) ที่ระบุครบทั้งเป้าหมาย (goals), ข้อจำกัด (constraints) และเงื่อนไขที่ถือว่างานผ่าน (acceptance criteria)
ใช้เครื่องมือ SDD จริง ๆ เป็น เช่น GitHub Spec Kit, Cursor Plan Mode, Kiro

เนื้อหา

SDD คือการเปลี่ยนวิธีทำงานครั้งใหญ่ที่สุด แนวคิดของมันคือ "แบบหรือข้อกำหนด (spec) ต่างหากที่เป็นของจริงที่เราให้ความสำคัญ ส่วนโค้ดเป็นแค่ผลลัพธ์ที่สร้างขึ้นตามแบบนั้น" (บางคนถึงกับเรียกว่าเป็นการทำงานแบบวางแผนเป็นขั้น ๆ (waterfall) แต่บีบให้จบใน 15 นาที) ขั้นตอนการทำงานมีสี่ขั้นคือ Specify → Plan → Tasks → Implement โดยแต่ละขั้นจะมีจุดพักให้เราเข้าไปตรวจและอนุมัติก่อนที่มันจะไปต่อ ส่วนเครื่องมือจริง ๆ ที่ใช้กันก็มี GitHub Spec Kit (เป็นโอเพนซอร์ส ใช้ได้กับทุกโมเดล), AWS Kiro, Cursor Plan Mode, OpenSpec, BMAD-METHOD, Tessl และ skills ของ Claude Code หลักปฏิบัติที่ต้องทำควบคู่กันไปคือ เขียนแบบ (spec) ให้สั้นแต่มีโครงที่ชัด ระบุทั้งเป้าหมาย ข้อจำกัด และที่สำคัญที่สุดคือเงื่อนไขที่ถือว่างานผ่าน (acceptance criteria) ให้ครบก่อนปล่อยให้ agent ลงมือ แล้วเก็บแบบระดับตัวสินค้านี้ให้อัปเดตอยู่เสมอ เพื่อให้ agent อ่านทุกครั้งที่เริ่มงาน

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Spec-Driven Development (SDD)วิธีทำงานที่เริ่มจากเขียน "แบบหรือข้อกำหนด" ให้ชัดก่อน แล้วค่อยให้สร้างโค้ดตามแบบนั้น

specเอกสารข้อกำหนดที่บอกว่างานต้องทำอะไร หน้าตาเป็นแบบไหน เปรียบเหมือนแบบแปลนบ้าน

artifactผลงานชิ้นจริงที่เราให้ความสำคัญ ในที่นี้แบบ (spec) คือของจริง ส่วนโค้ดเป็นแค่ผลลัพธ์ที่ตามมา

human checkpointจุดพักให้เราเข้ามาตรวจและอนุมัติก่อนที่ AI จะทำขั้นต่อไป

GitHub Spec Kitชุดเครื่องมือจริงที่ช่วยทำงานแบบ SDD ตามขั้นตอน Specify → Plan → Tasks → Implement

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ใช้ Cursor Plan Mode สร้าง spec แล้วอนุมัติ

@Plan เพิ่มฟีเจอร์ export รายการคำสั่งซื้อเป็น CSV Goals: ผู้ใช้กดปุ่ม Export แล้วได้ไฟล์ CSV ของคำสั่งซื้อตามช่วงวันที่ที่กรองไว้ Constraints: ต้อง stream ไฟล์ ไม่โหลดทั้งหมดเข้า memory; รองรับสูงสุด 100k แถว Acceptance: (1) CSV มี header ถูกต้อง (2) วันที่เป็น ISO 8601 (3) มี unit test ครอบกรณีไม่มีข้อมูล

✅ ผลลัพธ์ที่ได้

Plan Mode จะคืนแบบ (spec) พร้อมรายการงานย่อยกลับมาให้เราตรวจ เราก็แก้หรืออนุมัติที่จุดพัก (checkpoint) ก่อน แล้วค่อยสั่งให้ลงมือทำ (implement) ทีละงาน

💡 จุดสอน

เงื่อนไขที่ถือว่างานผ่าน (acceptance criteria) คือหัวใจเลย เพราะมันคือนิยามคำว่า "เสร็จ" ที่วัดได้ ทำให้ agent มีเป้าไว้ตรวจตัวเองและเราก็ตรวจมันได้ ส่วนจุดพักตรงนี้ช่วยกันไม่ให้ agent ไปไกลผิดทางก่อนที่เราจะทันเห็น

แบบฝึกหัดท้ายโมดูล

ใช้ Spec Kit หรือ Cursor Plan Mode เขียนแบบ (spec) ครบสี่ขั้นสำหรับฟีเจอร์จริงสักหนึ่งอัน แล้วจดไว้ว่าคุณแก้อะไรที่จุดพักของแต่ละขั้นบ้าง
เขียนเงื่อนไขที่ถือว่างานผ่าน (acceptance criteria) แบบที่วัดผลได้อย่างน้อย 3 ข้อสำหรับฟีเจอร์นั้น แล้วอธิบายว่าจะให้ agent พิสูจน์แต่ละข้อยังไง

2.4

โมดูล 2.4

Agent Mode บน Codebase จริง

ทำทีละงาน บังคับให้โชว์หลักฐาน และคุม token ไม่ให้บานปลาย

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

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

🎯

ทำไมต้องรู้: เพราะ AI จะทำงานพลาดเมื่อข้อมูลเยอะเกินไป การให้ทำทีละงานเล็กๆ พร้อมบังคับให้แสดงผลทดสอบ ทำให้งานเชื่อถือได้และคุมค่าใช้จ่ายไม่ให้บานปลาย

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

สั่ง agent ให้ทำทีละงาน พร้อมรันทดสอบ (test) มาเป็นหลักฐาน
เลี่ยงการสั่งงานก้อนใหญ่ทีเดียว และเลี่ยงอาการที่ AI คุณภาพตกเมื่อข้อมูลเยอะเกินไป (context rot)
ตั้งเพดานค่าใช้จ่าย (spend limit) และเข้าใจว่าการใช้ AI หลายตัวหรือผู้ช่วยย่อยหลายตัวมีต้นทุนเท่าไหร่

เนื้อหา

โมดูลนี้รวมวิธีใช้ agent ที่ได้ผลจริงเอาไว้ ข้อแรกคือจำกัดขอบเขตงานให้เล็ก แล้วทำวนซ้ำ ป้อนงานให้ทีละฟังก์ชัน ทีละบั๊ก หรือทีละฟีเจอร์ ไม่ใช่โยนทั้งโปรเจกต์เข้าไปทีเดียว เพราะ AI จะคุณภาพตกเมื่อป้อนข้อมูลเกินราว 100-120k tokens (นี่คืออาการ context rot) วิธีที่ดีคือให้ agent ลงมือทีละงานพร้อมรันทดสอบ (test) ไปด้วยระหว่างทาง และต้อง "เรียกดูหลักฐาน" คือบังคับให้มันรัน test แล้วโชว์ผลจริงมาให้ดู ไม่ใช่แค่พูดลอย ๆ ว่าเสร็จแล้ว อีกเรื่องที่สำคัญมากคือค่าใช้จ่าย และมีเคสจริงให้เห็น เช่น การให้ผู้ช่วยย่อย (subagent) ทำงานพร้อมกันหลายตัว แต่ละตัวเผา token เต็มอัตราและมีพื้นที่ข้อมูลแยกกัน, MCP server แต่ละตัวก็เพิ่ม token ได้ถึงราว 18k ต่อรอบ เคยมีบิลเดี่ยวพุ่งไปถึง $8k-$15k และมีทีมหนึ่งโดนไป $47k ภายใน 3 วัน เพราะปล่อย subagent ทิ้งไว้ถึง 23 ตัว บทเรียนก็คือ "ตั้งเพดานค่าใช้จ่ายไว้เสมอ" และอย่าปล่อยให้ agent ทำงานพร้อมกันหลายตัวโดยไม่คอยดู

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

scope เล็กการจำกัดขอบเขตงานให้เล็ก ทำทีละฟังก์ชันหรือทีละบั๊ก ไม่เหมาทั้งโปรเจกต์ในครั้งเดียว

tokenหน่วยที่ใช้นับข้อความที่ AI ประมวลผล ยิ่งใช้เยอะยิ่งเสียเงินเยอะ และถ้าเกินขีดมันก็ทำงานแย่ลง

context rotอาการที่ AI คุณภาพตกเมื่อป้อนข้อมูลเยอะเกินไป (ราว 100-120k tokens) มันจะเริ่มลืม เริ่มมั่ว

testโค้ดที่รันเพื่อตรวจสอบว่างานทำถูกจริงไหม เปรียบเหมือนการชิมอาหารก่อนเสิร์ฟ

เรียกหลักฐานการบังคับให้ AI รันทดสอบแล้วโชว์ผลลัพธ์จริง ๆ ออกมา แทนที่จะไปเชื่อมันที่พูดลอย ๆ ว่า "ทำเสร็จแล้ว"

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

สั่ง agent ทำ 1 task แล้วบังคับหลักฐาน

อ่าน AGENTS.md และ spec ก่อน แล้วทำเฉพาะ task นี้: แก้บั๊กที่ endpoint /orders คืนค่าซ้ำเมื่อ page=1 (มี repro ใน tests/orders.repro.test.ts) เมื่อแก้เสร็จ ให้รัน `npm test -- orders` แล้ววาง output จริงมาให้ดู อย่าทำ task อื่น อย่าเพิ่ม dependency

✅ ผลลัพธ์ที่ได้

agent จะแก้เฉพาะจุด รัน test ที่เราระบุ แล้วแปะผลลัพธ์ (output) ที่ผ่านจริงกลับมาให้ดู โดยไม่ลามไปแตะไฟล์อื่นหรือเพิ่ม package เข้ามา

💡 จุดสอน

การจำกัดขอบเขต (scope) ให้เล็กบวกกับบังคับให้โชว์ผลทดสอบ ทำให้เราตรวจสอบได้และกันงานไม่ให้ลามออกไป คำสั่งอย่าง "อย่าทำงานอื่น/อย่าเพิ่ม dependency" ก็คือรั้วกันพลาด (guardrail) ที่ช่วยลดทั้งความเสี่ยงและ token

แบบฝึกหัดท้ายโมดูล

ตั้งเพดานค่าใช้จ่าย (spend limit) ในเครื่องมือของคุณ แล้วสั่ง agent ทำงานจริงสักหนึ่งงาน โดยบังคับให้โชว์ผลทดสอบจนกว่าจะผ่าน
ลองสั่งงานแบบก้อนเดียวรวด ("ทำฟีเจอร์นี้ทั้งหมดให้เสร็จเลย") เทียบกับแบบสั่งทีละงาน แล้วจดไว้ว่าคุณภาพผลลัพธ์และ token ที่ใช้ต่างกันแค่ไหน

2.5

โมดูล 2.5

ต่อ MCP เข้ากับ Coding Agent

เชื่อมเครื่องมือ ฐานข้อมูล และ API โดยเข้าใจทั้งต้นทุนและความปลอดภัย

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนปลั๊กพ่วงสากลที่เสียบต่อได้กับเครื่องใช้ไฟฟ้าทุกยี่ห้อ MCP ทำให้ AI ต่อเข้ากับฐานข้อมูล เครื่องมือ และบริการต่างๆ ได้โดยไม่ต้องต่อสายพิเศษทุกครั้ง

🎯

ทำไมต้องรู้: เพราะพอต่อ MCP ได้ AI จะหยิบข้อมูลจริงมาใช้และสั่งงานระบบอื่นได้เอง งานที่เคยต้องทำมือหลายขั้นก็จบในที่เดียว แต่ต้องระวังเรื่องต้นทุนและความปลอดภัยด้วย

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เข้าใจส่วนประกอบพื้นฐานของ MCP: Tools, Resources, Prompts และช่องทางเชื่อมต่อแบบ stdio กับ HTTP
ต่อ MCP server เข้ากับ agent เป็น และตรวจแก้ปัญหา (debug) ด้วย MCP Inspector ได้
เข้าใจว่า MCP กิน token เท่าไหร่ และรู้ถึงความเสี่ยงจากคำอธิบายเครื่องมือ (tool description) ที่ไม่น่าเชื่อถือ

เนื้อหา

MCP (Model Context Protocol) เป็นมาตรฐานที่ทุกคนใช้ตามกันจนกลายเป็นบรรทัดฐานไปแล้ว หน้าที่ของมันคือเชื่อม agent เข้ากับเครื่องมือ ฐานข้อมูล และ API ต่าง ๆ ตอนนี้มี server ให้เลือกกว่า 5,000 ตัว และเครื่องมือ coding หลัก ๆ ก็รองรับกันหมด ส่วนประกอบหลักมีอยู่สามอย่างคือ Tools (ฟังก์ชันเอาไว้เรียกใช้), Resources (ข้อมูลเอาไว้อ่าน) และ Prompts (เทมเพลตคำสั่งสำเร็จรูป) ส่วนช่องทางเชื่อมต่อมีทั้งแบบ stdio (ใช้ในเครื่องหรือ IDE) และ SSE/HTTP (เชื่อมผ่านอินเทอร์เน็ต) เรื่อง token เป็นเรื่องที่ต้องใส่ใจ เพราะทุก server ที่ต่อเข้ามาจะโหลดรายละเอียดเครื่องมือเข้ามาทุกรอบที่คุย แนวทางที่ Anthropic แนะนำคือแบบ "code execution with MCP" คือโหลดเครื่องมือเท่าที่จำเป็นต้องใช้ และกรองข้อมูลก่อนส่งถึงโมเดล สามารถตรวจแก้ปัญหาได้ด้วย MCP Inspector และสร้าง server เองได้ด้วย fastmcp (บน Python) ส่วนเรื่องความปลอดภัยต้องระวังให้มาก เพราะคำอธิบายเครื่องมือที่มาจาก server ที่ไม่น่าเชื่อถืออาจเป็นอันตรายได้ (ดูเผิน ๆ เหมือนไม่มีพิษภัย แต่จริง ๆ ทำงานไม่ปลอดภัย) ดังนั้นต้องขออนุญาตจากผู้ใช้ให้ชัดเจน และเชื่อเฉพาะ server ที่เราคุมเองหรือตรวจสอบเองแล้วเท่านั้น

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

MCP (Model Context Protocol)มาตรฐานกลางสำหรับเชื่อม AI เข้ากับเครื่องมือ ฐานข้อมูล และ API ต่าง ๆ

Tools / Resources / Promptsสามส่วนของ MCP คือ Tools (ฟังก์ชันไว้เรียกใช้), Resources (ข้อมูลไว้อ่าน) และ Prompts (เทมเพลตคำสั่งสำเร็จรูป)

server (MCP server)ตัวกลางที่เปิดให้ AI เชื่อมเข้าไปใช้เครื่องมือหรือข้อมูลอย่างใดอย่างหนึ่ง ตอนนี้มีให้เลือกกว่า 5,000 ตัว

transport (stdio / SSE / HTTP)ช่องทางที่ AI คุยกับ server โดย stdio ใช้ในเครื่องตัวเอง ส่วน SSE/HTTP ใช้เชื่อมผ่านอินเทอร์เน็ต

de facto standardมาตรฐานที่ทุกคนใช้ตามกันจนกลายเป็นบรรทัดฐานจริง ๆ ทั้งที่ไม่มีใครประกาศบังคับ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตั้งค่า MCP server แบบ stdio ใน agent

{ "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"], "transport": "stdio" } } }

✅ ผลลัพธ์ที่ได้

agent จะมองเห็นเครื่องมือของ Postgres server ทำให้มัน query ทั้งโครงสร้างและข้อมูลได้ แต่รายละเอียดเครื่องมือ (tool definitions) จะถูกโหลดเข้ามาทุกรอบที่คุย ซึ่งก็ทำให้กิน token เพิ่มขึ้น

💡 จุดสอน

ให้ต่อ MCP เท่าที่จำเป็นจริง ๆ เพราะยิ่งต่อหลาย server ก็ยิ่งกิน token และยิ่งเปิดช่องให้ถูกโจมตีมากขึ้น ต่อเฉพาะ server ที่คุณตรวจสอบเองแล้ว และลองใช้แบบ code-execution ดู เพื่อช่วยลดค่าใช้จ่ายด้านข้อมูล

แบบฝึกหัดท้ายโมดูล

ต่อ MCP server สักหนึ่งตัว (เช่น filesystem หรือ postgres) เข้ากับ agent แล้ววัดดูว่า token ที่ใช้เปลี่ยนไปแค่ไหนเมื่อเปิดกับปิด server ตัวนั้น
ใช้ MCP Inspector ตรวจรายละเอียดเครื่องมือ (tool definitions) ของ server สักตัว แล้วลองเขียนว่าคุณจะประเมินความน่าเชื่อถือของ server ที่ไม่รู้จักได้ยังไง

2.6

โมดูล 2.6

AI Code Review เป็นด่านแรก

ให้ AI ตรวจรอบแรก แล้วคนตรวจต่อ ก่อนที่ระบบ CI จะกั้นเป็นด่านสุดท้าย

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนโรงงานที่มีด่านตรวจคุณภาพหลายชั้น ด่านแรกให้เครื่องสแกนอัตโนมัติคัดของเสียออก แล้วค่อยให้คนตรวจซ้ำ ก่อนปิดท้ายด้วยเครื่องตรวจสุดท้ายก่อนส่งออก

🎯

ทำไมต้องรู้: เพราะ AI มั่นใจแม้ตอนเขียนผิด บั๊กเลยชอบซ่อนในโค้ดที่ดูดี การมีด่านตรวจหลายชั้นช่วยจับข้อผิดพลาดก่อนถึงมือผู้ใช้จริง งานจึงปลอดภัยและน่าเชื่อถือ

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

วางตัวตรวจโค้ด AI (AI reviewer) ให้เป็นด่านแรก (เช่น CodeRabbit, Qodo, Bugbot, Sourcery)
เข้าใจว่า AI มัก "มั่นใจแม้ตอนที่ตอบผิด" และบั๊กชอบซ่อนอยู่ในโค้ดที่ดูสมเหตุสมผล
ประกอบสายพานการตรวจ (pipeline): AI ตรวจ → คนตรวจ → CI/CD บวกกับ smoke test

เนื้อหา

หลักการทองของเรื่องนี้คือ "ตรวจให้หมดทุกอย่าง เพราะ AI มันมั่นใจแม้ตอนที่ตอบผิด" บั๊กแนบเนียน ๆ มักซ่อนอยู่ในโค้ดที่ดูน่าเชื่อถือนี่แหละ วิธีที่ได้ผลคือใช้ตัวตรวจโค้ด AI (AI reviewer) เป็นด่านตรวจรอบแรกไปก่อน (เช่น CodeRabbit, Qodo, Bugbot, Sourcery) แล้วค่อยให้คนตรวจต่อ และปิดท้ายด้วย CI/CD บวก smoke test เป็นด่านสุดท้าย ตัวทดสอบ (test) ก็เหมือนตาข่ายกันพลาด จะให้ AI ช่วยเขียนก็ได้ แต่ห้ามไปเชื่อคำว่า "ดูดีแล้ว" เด็ดขาด ต้องอาศัย CI จริง ๆ เป็นด่านกั้น และต้องบังคับให้ agent แสดงหลักฐาน (คือรัน test แล้วโชว์ผลจริง) ไม่ใช่แค่ประกาศลอย ๆ ว่าเสร็จ พูดอีกอย่างคือ วินัยวิศวกรรมแบบดั้งเดิม (ออกแบบ → เขียน test → คุมเวอร์ชัน → ทำตามมาตรฐาน) ยิ่งสำคัญขึ้นไปอีก ไม่ได้ลดลงเลย เมื่อ AI มาช่วยเขียนโค้ดให้ตั้งครึ่ง

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Code Reviewการตรวจทานโค้ดว่าเขียนถูกต้อง ปลอดภัย ไม่มีบั๊ก ก่อนเอาไปใช้จริง

first-pass reviewerตัวตรวจรอบแรก ในที่นี้ให้ AI (เช่น CodeRabbit, Bugbot) กวาดหาปัญหาก่อน แล้วคนค่อยตรวจต่อ

CI/CDระบบอัตโนมัติที่คอยประกอบและทดสอบโค้ดให้ทุกครั้งที่มีการแก้ ทำหน้าที่เป็นด่านตรวจสุดท้าย

smoke testการทดสอบเร็ว ๆ ว่าระบบยังทำงานพื้นฐานได้ไหม เปรียบเหมือนสตาร์ทรถดูว่าติดไหมก่อนขับจริง

gateด่านกั้นที่โค้ดต้องผ่านก่อนถึงจะไปต่อได้ ถ้าไม่ผ่านก็โดนบล็อกไว้ก่อน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

CodeRabbit review PR ที่ agent เปิด

บน PR ที่ Copilot cloud agent เปิดให้ ใส่คำสั่งใน comment: '@coderabbitai review — เน้นเรื่อง security (injection, XSS, hardcoded secret) และ null-check ที่ขาด'

✅ ผลลัพธ์ที่ได้

CodeRabbit จะวิเคราะห์ diff แล้วชี้จุดเสี่ยงให้ เช่น SQL ที่ต่อ string ตรง ๆ, innerHTML ที่ไม่ได้ sanitize, หรือการเดาชนิดข้อมูล (type) ที่พลาด ซึ่งเป็นการตรวจรอบแรกก่อนที่คนจะเข้ามาอ่าน

💡 จุดสอน

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

แบบฝึกหัดท้ายโมดูล

ตั้งตัวตรวจโค้ด AI สักหนึ่งตัวกับ repo แล้วให้มันรีวิว PR ที่ agent สร้างขึ้น จดไว้ว่ามันเจอบั๊กหรือช่องโหว่ที่คุณเองมองข้ามไปหรือเปล่า
ลองออกแบบสายพานการตรวจ (pipeline) ของทีมคุณเป็นแผนผัง: AI ตรวจ → คนตรวจ → CI/CD บวก smoke test พร้อมระบุว่าใครหรืออะไรทำหน้าที่เป็นด่านกั้นตรงไหนบ้าง

🎯 Mini-Project: เพิ่มฟีเจอร์บน Codebase จริงแบบ SDD

เลือก repo จริงสักตัว (ของคุณเองหรือ open-source ก็ได้) แล้วเขียนไฟล์ AGENTS.md ด้วยมือเองไม่เกินราว 150 บรรทัด
ทำงานแบบ SDD ครบสี่ขั้น (Specify → Plan → Tasks → Implement) ด้วย Spec Kit หรือ Cursor Plan Mode โดยอนุมัติที่ทุกจุดพัก และมีเงื่อนไขที่ถือว่างานผ่าน (acceptance criteria) แบบที่วัดได้
สั่ง agent ให้ลงมือทำทีละงาน บังคับให้โชว์ผลทดสอบเป็นหลักฐาน และตั้งเพดานค่าใช้จ่ายไว้ก่อนเริ่ม
ถ้าต้องใช้ข้อมูลจากภายนอก ให้ต่อ MCP server อย่างน้อยหนึ่งตัวที่คุณตรวจสอบเองแล้ว พร้อมอธิบายว่ามันมีผลต่อ token ยังไง
วางสายพานการตรวจ: ให้ตัวตรวจโค้ด AI เป็นด่านแรก → คนตรวจต่อ → CI/CD บวก smoke test แล้วรันจริงกับ PR ของคุณ
ส่งมอบงาน: PR ที่ merge เข้าไปแล้ว + ไฟล์ AGENTS.md + แบบ (spec) ทั้งสี่ขั้น + สรุป token และค่าใช้จ่ายที่ใช้ไป พร้อมสิ่งที่ตัวตรวจโค้ด AI จับได้

ก้าวต่อไป

Agentic Engineering ระดับทีม: ความปลอดภัย ต้นทุน และการวัดผล

ไปต่อ →