5 Claude Code skills I use every single day
สรุปย่อ
ประเด็นสำคัญจากวิดีโอ
> **ต้นฉบับ:** [5 Claude Code skills I use every single day](https://www.youtube.com/watch?v=EJyuu6zlQCg) · **ช่อง:** Matt Pocock · **เผยแพร่:** 16 มีนาคม 2026 · **ความยาว:** ~16 นาที 43 วินาที
# สรุปภาษาไทย — 5 Claude Code skills I use every single day > **ต้นฉบับ:** [5 Claude Code skills I use every single day](https://www.youtube.com/watch?v=EJyuu6zlQCg) · **ช่อง:** Matt Pocock · **เผยแพร่:** 16 มีนาคม 2026 · **ความยาว:** ~16 นาที 43 วินาที ## ใจความสำคัญ Matt Pocock (นักพัฒนาและครีเอเตอร์สาย TypeScript) แชร์ **5 สกิล Claude Code** ที่เขาใช้ทุกวัน เพื่อ "เข้ารหัสกระบวนการทำงาน" ของตัวเองให้ AI เดินตามเส้นทางที่เคร่งครัดชัดเจนทุกครั้ง แก่นของวิดีโอคือ **AI agent ไม่มีหน่วยความจำ** — จึงต้องมีกระบวนการที่นิยามชัดเจนมากเพื่อให้ AI ทำงานที่มีประโยชน์ได้จริง และเมื่อทำเช่นนั้น คุณภาพโค้ดที่ AI ผลิตจะสูงขึ้นอย่างก้าวกระโดด ## 5 สกิลหลัก ### 1. Grill Me — สัมภาษณ์ไอเดียอย่างไม่ลดละ (ยาวแค่ 3 ประโยค) - บังคับให้ LLM **สัมภาษณ์เรา** เกี่ยวกับทุกแง่มุมของแผน จนกว่าจะ "เข้าใจตรงกัน" ก่อนลงมือเขียนโค้ด - เดินลงทุกกิ่งของ **design tree** (แนวคิดจากหนังสือ *The Design of Design* ของ Frederick P. Brooks) แก้ความสัมพันธ์เชิงพึ่งพาระหว่างการตัดสินใจทีละอย่าง - ถ้าตอบได้ด้วยการสำรวจโค้ดเบส ให้สำรวจโค้ดเบสแทน - ตัวอย่างจริง: Claude ถามคำถาม **16 ข้อ** เกี่ยวกับฟีเจอร์เดียว (และบางเซสชันอาจถึง 30–50 ข้อ) - **ข้อคิด:** สกิลไม่ต้องยาวถึงจะมีผล — แค่เลือกคำให้ถูกจังหวะ ### 2. Write a PRD — เปลี่ยนไอเดียเป็นเอกสาร - เรียกใช้เมื่อเข้าใจไอเดียครบถ้วนแล้ว ขั้นตอน: ถามคำอธิบายละเอียด → สำรวจ repo ยืนยันข้อเท็จจริง → สัมภาษณ์ผู้ใช้ซ้ำ (เหมือน Grill Me) → ร่างโมดูลหลัก → เขียน PRD ตามเทมเพลต - PRD ถูกส่งเป็น **GitHub issue** แล้วแตกเป็นงานย่อย ๆ (Ralph loop วน implement ทีละ issue) - PRD อธิบาย **จุดหมายปลายทาง** ไม่ใช่เส้นทางเดินทาง ### 3. PRD to Issues — เปลี่ยนปลายทางเป็นแผนงาน - เปลี่ยน PRD เป็น **Kanban board** ของ GitHub issues ที่แต่ละอันหยิบไปทำได้อิสระ - เน้น **vertical slices** (ชิ้นแนวตั้งตัดทะลุทุกชั้น) ไม่ใช่ชิ้นแนวนอนของชั้นเดียว — อุปมาแบบ **tracer bullet** - จัดลำดับงานที่ "flush out unknown unknowns" (เผยสิ่งที่เราไม่รู้ว่าไม่รู้) ให้เร็วที่สุด เช่น งาน integrate บริการใหม่ - สร้างความสัมพันธ์แบบ **blocking** ระหว่างงาน → รันเอเจนต์ขนานกันได้ (เช่น background tasks) - ตัวอย่างจริง: PRD ซับซ้อนถูกแบ่งเป็น 4 slices → issue ถูก implement ปิดจบโดยอัตโนมัติ พร้อมคอมเมนต์สรุป ### 4. TDD (Test-Driven Development) — เขียนเทสต์ก่อนเสมอ - บังคับ/สนับสนุนเอเจนต์ให้ทำวงจร **red-green-refactor** (เขียนเทสต์ที่ล้มเหลวก่อน → เขียนโค้ดให้ผ่าน → หาโอกาส refactor) - เน้นย้ำเรื่อง **interface changes**: ให้ AI เข้าใจว่าการเปลี่ยน interface คือการตัดสินใจสำคัญ - โค้ดเบสที่โครงสร้างดี (โมดูลใหญ่ + interface บาง ๆ) เทสต์ง่ายกว่าโค้ดเบสที่เต็มไปด้วยโมดูลเล็ก ๆ แยกแยะไม่ออก - ข้อสังเกต: LLM **ไม่ค่อยเต็มใจ refactor โค้ดของตัวเอง** เพราะโค้ดอยู่ใน context window ของมัน — การล้าง context ทำให้มัน "ไม่หวง" โค้ดที่เขียนเอง ### 5. Improved Code Base Architecture — ปรับโครงสร้างโค้ดเบสให้ลึก - สำรวจโค้ดเบสแบบธรรมชาติ หาจุดที่ AI สับสน (ต้องเด้งไปมาระหว่างไฟล์เล็ก ๆ หลายไฟล์ / pure functions ที่แยกมาแค่ให้เทสต์ได้ / โมดูลผูกกันแน่น) - นำเสนอ **deepening opportunities** (โอกาสทำให้โมดูลตื้นเป็นโมดูลลึก) → ผู้ใช้เลือก → **สปอนต์ subagents 3 ตัวขนานกัน** ออกแบบ interface ที่ต่างกันสุดขั้ว → เปรียบเทียบและเสนอตัวที่ดีที่สุดหรือแบบลูกผสม - ไม่ต้องเชี่ยวชาญ interface design ก็ใช้ได้ และไม่ผูกกับภาษา/เทคโนโลยีใด - สร้าง **refactor RFC** เป็น GitHub issue → ต่อด้วยสกิล PRD to Issues เพื่อวางแผนเดินทาง - คำเตือน: ทำทีละอันเพราะต้องใช้ "รสนิยม" และ human-in-the-loop - คำคมสำคัญ: **"ถ้าคุณมีโค้ดเบสที่แย่ AI ก็จะผลิตของแย่ ๆ ออกมา"** (garbage in, garbage out) ## ข้อคิดปิดท้าย - วิธีที่ดีที่สุดในการเพิ่มคุณภาพโค้ดจาก AI คือ **ปฏิบัติต่อมันเหมือนมนุษย์** — มนุษย์ที่ไม่มีหน่วยความจำและถูกโคลนออกมาจากฝัก - ถ้าเอาสกิลเหล่านี้ไปรวมกัน ก็เหมือน "หนังสือ markdown เล็ก ๆ เกี่ยวกับกระบวนการทำงานสำหรับมนุษย์" ไม่ผิดที่ใด - ปิดท้ายด้วยการโปรโมตคอร์ส **Claude Code for Real Engineers** (คอร์ส 2 สัปดาห์ เริ่ม 30 มีนาคม ลด 40% อีก 7 วัน) — เนื้อหาคอร์สเน้นข้อจำกัดของ LLM, การ steering, tracer bullets, feedback loops และการเชื่อมต่อกับ autonomous agents
คำแปลเต็ม
แปลตามบทสนทนาต้นฉบับ ปรับเป็นภาษาไทยธรรมชาติ
## บทนำ — ทำไม process ถึงสำคัญกับ AI agent
**[00:00:00]** ผมเป็นวิศวกรมาเกือบสิบปี และในเวลาทั้งหมดนั้น ตอนนี้แหละที่ process (กระบวนการทำงาน) สำคัญที่สุดเท่าที่เคยเป็นมา ในมือคุณตอนนี้มีวิศวกรระดับกลางถึงดีเป็นกองทัพที่พร้อมจะใช้งานได้ทุกเมื่อ
**[00:00:08]** แต่เรื่องแปลกของวิศวกรเหล่านี้คือ พวกเขาไม่มีหน่วยความจำ พวกเขาจำสิ่งที่เคยทำมาก่อนไม่ได้ ดังนั้นคุณจึงต้องมีกระบวนการที่เคร่งครัดและนิยามไว้ชัดเจนมาก เพื่อให้เอเจนต์เหล่านี้ทำงานที่มีประโยชน์ได้จริง
**[00:00:16]** นั่นหมายความว่า ในฐานะนักพัฒนา คุณต้องมองหาวิธีควบคุมเอเจนต์ของคุณตลอดเวลา เพื่อให้พวกเขาอยู่ในเส้นทางที่ถูกต้อง
**[00:00:25]** และสำหรับผม สิ่งนั้นส่งผลให้เกิดการสร้างสกิลขึ้นมามากมาย นี่คือ repo รวมสกิลทั้งหมดที่ผมใช้อยู่ตอนนี้ ซึ่งแต่ละอันผมออกแบบและปรับปรุงด้วยตัวเอง
**[00:00:32]** บางอันผมใช้นานๆ ครั้ง แต่บางอันผมใช้ทุกวัน
**[00:00:35]** และสกิลเหล่านี้ช่วยให้ผมเข้ารหัสกระบวนการทำงานของผมไว้ เพื่อให้ AI มีเส้นทางที่เคร่งครัดชัดเจนที่มันสามารถเดินตามได้ทุกครั้ง
**[00:00:42]** และผลจากการใช้สกิลทั้งหมดนี้ ทำให้คุณภาพโค้ดที่ AI ผลิตออกมาสูงขึ้นอย่างก้าวกระโดด
**[00:00:51]** ทีนี้ ถ้าคุณคิดว่า process สำคัญ และทักษะวิศวกรรมจริงจังสำคัญล่ะก็ ผมมีคอร์สสำหรับคุณโดยเฉพาะ
**[00:00:59]** คอร์สนี้ชื่อว่า Claude Code for Real Engineers เป็นคอร์สแบบ cohort (เรียนพร้อมกันเป็นรุ่น) ระยะเวลา 2 สัปดาห์ เริ่ม 30 มีนาคม
**[00:01:07]** และอีก 7 วันนี้ ลดราคา 40% ถ้ารู้สึกว่าตามหลังคนอื่นเรื่อง Claude Code อยู่ และอยากนำหน้าแบบก้าวกระโดดภายใน 2 สัปดาห์
**[00:01:15]** แล้วล่ะก็ นี่คือที่สำหรับคุณ เอาล่ะ มาพูดถึงสกิลของเรากันดีกว่า เริ่มจากสกิลแรก ซึ่งอาจเป็นสกิลโปรดของผม นี่คือ
## สกิลที่ 1: Grill Me — สัมภาษณ์ไอเดียอย่างไม่ลดละ
**[00:01:24]** สกิล Grill Me (ย่างผมซะ) สกิลนี้ ใช่แล้ว มันยาวแค่สามประโยคเอง และขออ่านทั้งหมดให้ฟังเพื่ออธิบายว่ามันทำอะไรบ้าง
**[00:01:32]** "สัมภาษณ์ฉันอย่างไม่ลดละเกี่ยวกับทุกแง่มุมของแผนนี้ จนกว่าเราจะเข้าใจตรงกัน "เดินลงไปตามกิ่งก้านแต่ละกิ่งของ design tree (ต้นไม้การออกแบบ) แก้ความสัมพันธ์เชิงพึ่งพาระหว่างการตัดสินใจทีละอย่าง
**[00:01:39]** และสุดท้าย ถ้าคำถามใดตอบได้ด้วยการสำรวจโค้ดเบส ก็ให้สำรวจโค้ดเบสแทน"
**[00:01:44]** แนวคิดเรื่อง design tree มาจากหนังสือเล่มนี้ของ Frederick P. Brooks ชื่อ The Design of Design จริงๆ ผมไม่แน่ใจว่ามันมาจากหนังสือเล่มนี้หรือเปล่า
**[00:01:51]** แต่หนังสือเล่มนี้คือที่แรกที่ผมเห็นแนวคิดนี้
**[00:01:53]** design tree คือแนวคิดที่ว่า ขณะที่คุณกำลังเข้าหาการออกแบบ คุณต้องเดินลงไปตามกิ่งก้านทั้งหมดของต้นไม้การออกแบบ ตัวอย่างเช่น คุณอาจกำลัง
**[00:02:00]** ออกแบบหน้า search (ค้นหา) และต้องตัดสินใจว่าต้องการ search แบบขั้นสูง หรือแค่กล่องพิมพ์ข้อความ ถ้าเลือก search แบบขั้นสูง คุณก็ต้องคิดให้ออกว่า
**[00:02:07]** ต้องมี filter (ตัวกรอง) อะไรบ้าง และวิธีเรียงลำดับแบบไหนบ้างบน search แบบขั้นสูง แล้วคุณก็เดินลงต้นไม้ต่อไปเรื่อยๆ จนกว่าจะคิดการออกแบบ
**[00:02:14]** ของคุณออกมาได้อย่างครบถ้วน หรือเท่าที่ทำได้เต็มที่ ก่อนที่จะลงมือเขียนโค้ดจริง
**[00:02:18]** สกิล Grill Me นี้ ผมจะเรียกใช้มันเมื่อต้องการให้เกิดความเข้าใจตรงกันกับ LLM ผมเพิ่งค้นพบว่าเมื่อไม่นานมานี้ Claude Code
**[00:02:27]** มักจะพ่นแผนออกมาซะก่อนเร็วเกินไป เมื่อผมเข้าโหมด plan (วางแผน) และมันมักจะสร้างเอกสารขึ้นมาก่อนที่ผมจะรู้สึกว่าเราเข้าใจตรงกัน
**[00:02:35]** กับ LLM แล้ว แต่สกิล Grill Me บังคับให้เกิดบทสนทนานั้นขึ้น มันบังคับให้ LLM สัมภาษณ์ผมเกี่ยวกับทุกส่วน นี่คือบทสนทนาที่ผมคุยกับ
**[00:02:43]** Claude เมื่อไม่นานนี้ เกี่ยวกับการเพิ่มฟีเจอร์ให้โค้ดเบสตัวแก้ไขวิดีโอคอร์สของผม ผมให้งานวิจัยที่ผมทำไว้ในไฟล์ markdown แล้วพูดว่า "Grill me" ผมอยาก
**[00:02:51]** ลองคิดเรื่องการเพิ่มสิ่งนี้ลงในหน้าขวา มันโหลดสกิลขึ้นมา และสิ่งที่ผมอยากให้คุณเห็นคือ มันถามคำถามผมเยอะแค่ไหน
**[00:02:59]** สิ่งแรกที่มันทำคือสำรวจส่วนที่เกี่ยวข้องในโค้ดเบส ซึ่งถือว่าดี แล้วเราก็ซูมลงไป จะเห็นว่ามันถามคำถามข้อหนึ่ง "เอกสารอยู่ที่ไหน?"
**[00:03:05]** คำถามข้อสอง "UI layout (เค้าโครงหน้าจอ) เป็นยังไง?" คำถามข้อสาม "โหมดไหนบ้างที่ได้แผงเอกสาร?" คำถามข้อสี่ "วงจรชีวิตของเอกสาร"
**[00:03:11]** คำถามข้อห้า "เครื่องมือเอกสารด้านขวาหน้าตาเป็นยังไง?" คำถามข้อหก "รูปร่างของเครื่องมือแก้ไข" คำถามข้อเจ็ด แล้วก็ถามต่อลงไปเรื่อยๆ จนถึงคำถาม
**[00:03:19]** ข้อเก้า ข้อสิบ ข้อสิบเอ็ด ข้อสิบสอง ลงไปจนถึงคำถามข้อสิบหกสุดบ้าตรงนี้ และนี่คือเซสชันการ Grill ที่ค่อนข้างสั้นในความเห็นของผม
**[00:03:27]** ผมเคยมีเซสชันที่นั่งอยู่เกือบครึ่งชั่วโมง 45 นาที กับ AI ที่ตอบคำถามเกี่ยวกับฟีเจอร์ที่ซับซ้อนมากๆ คุณรู้ไหม
**[00:03:34]** นั่นอาจเป็นคำถาม 30, 40, 50 ข้อ จากสกิลเล็กๆ จิ๋วๆ อันนี้ นั่นคือสิ่งหนึ่งที่ผมอยากให้คุณเก็บไปจากวิดีโอนี้
**[00:03:42]** สกิลไม่จำเป็นต้องยาวเพื่อให้มีผลกระทบ คุณแค่ต้องเลือกคำพูดที่ถูกต้องให้ LLM ในเวลาที่ถูกต้อง และการแก้ความสัมพันธ์เชิงพึ่งพาด้วย design tree นี้
**[00:03:50]** มันยอดเยี่ยมมากสำหรับผม ยังไงก็ตาม ถ้าอยากได้สกิลเหล่านี้ มันจะอยู่ในลิงก์ด้านล่าง เมื่อผมเข้าใจตรงกัน
**[00:03:57]** กับ LLM แล้ว เมื่อผมย่างความคิดของผมจนเข้าใจผลพวงทั้งหมดของมันแล้ว ถ้าผมตัดสินใจว่าอยากลงมือทำจริง ผมก็
## สกิลที่ 2: Write a PRD — เปลี่ยนไอเดียเป็นเอกสาร
**[00:04:05]** เรียกใช้สกิลถัดไป ซึ่งก็คือสกิล Write a PRD (เขียน PRD) จริงๆ แล้วผมทำสิ่งนี้ในบทสนทนาที่เราดูกันเมื่อกี้ มันเลยพูดว่า "มีอะไรที่ฉันพลาดหรือทำผิด
**[00:04:11]** ไหม?" แล้วผมก็พูดว่า "Write a PRD" ผมเติมท้ายด้วยคำว่า user เพราะบางสกิลของผมอยู่ในโปรเจกต์ นั่นคือเหตุผลที่ผมทำแบบนั้น
**[00:04:19]** นี่คือหน้าตาของสกิลนี้ จะถูกเรียกใช้เมื่อผู้ใช้ต้องการสร้าง PRD คุณอาจข้ามขั้นตอนได้ถ้าเห็นว่าไม่จำเป็น ตัวอย่างเช่น
**[00:04:25]** ในบทสนทนาก่อนหน้านี้ มันพูดว่า "เราได้สัมภาษณ์เชิงลึกไปแล้ว ไปขั้นตอนที่สี่กันเถอะ" ขั้นตอนที่หนึ่งคือถามผู้ใช้ให้คำอธิบายที่ยาว
**[00:04:31]** ละเอียด แล้วขั้นตอนที่สองคือสำรวจ repo เพื่อยืนยันข้อความอ้างของผู้ใช้ ขั้นตอนที่สามคือการสัมภาษณ์ผู้ใช้อย่างไม่ลดละ ซึ่งก็
**[00:04:38]** เป็นแค่สำเนาของสกิล Grill Me อีกที
**[00:04:40]** ต่อไป เราร่างโมดูลหลักที่คุณต้องสร้างหรือแก้ไขเพื่อทำให้การ implement (นำไปปฏิบัติ) เสร็จสมบูรณ์ เราจะกลับมาดูตรงนี้ทีหลัง เพราะมันเชื่อมโยง
**[00:04:47]** กับสกิลที่ผมจะโชว์ให้ดูในวิดีโอนี้ สุดท้าย เมื่อคุณเข้าใจปัญหาและวิธีแก้อย่างครบถ้วนแล้ว ให้ใช้เทมเพลตด้านล่าง
**[00:04:53]** เพื่อเขียน PRD และ PRD ควรถูกส่งเป็น GitHub issue (ปัญหา/งานใน GitHub) วิธีที่เวิร์กโฟลว์การพัฒนาของผมทำงานคือ ผมนำ PRD เหล่านี้ใน GitHub ไปเปลี่ยนเป็น
**[00:05:02]** GitHub issue อีกหลายอันที่อ้างอิงถึง PRD หลัก แล้วผมก็มี Ralph loop ที่วนลูปไปตามแต่ละ issue จนกว่าจะเสร็จ ถ้ากลับไปที่บทสนทนา
**[00:05:10]** ก่อนหน้านี้ เราจะเห็นว่ามันสร้าง PRD นี้ขึ้นมา นี่คือสี่วันที่แล้ว อย่างที่เห็น เรามี problem statement (คำอธิบายปัญหา) หน้าสำหรับ
**[00:05:18]** เขียนบทความปัจจุบันสร้างเอกสารใหม่ทั้งฉบับทุกครั้งที่มีการโต้ตอบกับ AI และวิธีแก้คือเพิ่มประสบการณ์การแก้ไขเอกสารแบบ split pane (แบ่งจอสองแผง)
**[00:05:24]** ให้กับตัวเขียนบทความ แชทอยู่ฝั่งซ้าย และแผงเอกสารใหม่อยู่ฝั่งขวา บลาๆ นี่คือฟีเจอร์ใหญ่ เรากำลังเพิ่มการแก้ไขเอกสารให้กับฟีเจอร์
**[00:05:31]** แชท AI สิ่งสำคัญตรงนี้คือ user stories (เรื่องราวผู้ใช้) มี user stories มากมายเป็นส่วนหนึ่งของสิ่งนี้ และสิ่งนี้มาจากระเบียบวิธี Agile
**[00:05:38]** และโดยพื้นฐานแล้วเราพยายามอธิบายพฤติกรรมที่ต้องการของระบบด้วยภาษาธรรมชาติ ซึ่งไม่ใช่เรื่องง่ายเลย ผมยังไม่ได้
**[00:05:46]** ตกลงใจกับรูปแบบที่ถูกต้องสำหรับสิ่งเหล่านี้ได้จริงๆ
**[00:05:47]** นี่เป็นแค่สิ่งที่ผมพอใจ แต่คุณสามารถใช้ภาษาแบบ Cucumber หรืออะไรก็ตามที่คุณคุ้นเคยกับการทำงานด้วยก็ได้
**[00:05:54]** จากนั้นเราก็ซูมลงมาด้านล่าง แล้วก็ใส่การตัดสินใจเชิง implementation (การนำไปปฏิบัติ) เข้าไป การตัดสินใจเชิง implementation ตรงนี้ เราไม่อยาก
**[00:06:03]** ระบุเจาะจงมากเกินไป เพราะเราอยากให้มันคงทน เพราะถ้าโค้ดเริ่มล้าสมัยไม่ตรงกับ PRD เราก็จะมีปัญหาเมื่อ
**[00:06:10]** เราจะลงมือ implement จริง แต่คุณเห็นทฤษฎีตรงนี้ นี่คือคำอธิบายที่ดีมากของจุดหมายปลายทางที่เรากำลังจะไป แต่
**[00:06:18]** สิ่งที่ PRD ไม่ได้ให้เราคือเส้นทางการเดินทางจริง หนทางที่เราจะไปถึงจุดหมายนี้ และถ้าเรากลับไปที่บทสนทนานั้น
## สกิลที่ 3: PRD to Issues — เปลี่ยนจุดหมายปลายทางเป็นแผนงาน
**[00:06:26]** นี่คือจุดที่ผมใช้สกิลถัดไปของผม ซึ่งก็คือ PRD to Issues (จาก PRD ไปสู่ Issues) สิ่งที่มันทำคือนำ PRD ซึ่งคือจุดหมายปลายทาง ไปเปลี่ยนเป็นบอร์ด Kanban ของ
**[00:06:35]** issue ต่างๆ ที่แต่ละอันสามารถหยิบไปทำได้อิสระ ขั้นแรกในนี้คือมันหา PRD เจอ ถ้า PRD ยังไม่อยู่ใน context window ของคุณ ให้ไปดึงมันมา
**[00:06:42]** ด้วยคำสั่งนี้ สำรวจโค้ดเบสถ้าจำเป็น แล้วก็ เดี๋ยวก่อนๆ ร่าง vertical slices (ชิ้นงานแนวตั้ง) การแบ่ง PRD
**[00:06:53]** ออกเป็นงานย่อยแต่ละอันนั้นไม่ชัดเจนเสมอไป นี่คือสิ่งที่นักพัฒนาทำกันมานานมากแล้ว ใช่ไหม? และเราพัฒนาสัญชาตญาณในการทำมันขึ้นมา ในความเห็นของ
**[00:07:00]** ผม วิธีที่ดีที่สุดคือการแบ่งมันเป็นงานที่ทำให้ unknown unknowns (สิ่งที่เราไม่รู้ว่าเราไม่รู้) ปรากฏออกมาเร็วมาก ตัวอย่างเช่น ถ้าคุณกำลัง integrate กับ
**[00:07:07]** บริการชนิดใหม่ หรือเชื่อมสองสิ่งที่ไม่เคยเชื่อมกันมาก่อน คุณควรทำงานนั้นก่อน เพราะมันจะให้ข้อมูลป้อนกลับ
**[00:07:14]** ว่าวิธีการของคุณใช้ได้จริงหรือไม่ คำอุปมาที่ถูกต้องตรงนี้คือ tracer bullet (กระสุนส่องวิถี) ผมจะไม่ลงรายละเอียดว่ามันหมายถึงอะไร แต่โดยพื้นฐานแล้วแต่ละ
**[00:07:21]** issue คือชิ้นแนวตั้งบางๆ ที่ตัดทะลุทุกชั้นของการ integration ไม่ใช่ชิ้นแนวนอนของชั้นใดชั้นหนึ่ง ในบทสนทนา มันแบ่ง
**[00:07:29]** PRD ที่ซับซ้อนมากนั้นออกเป็นแค่สี่ชิ้น
**[00:07:32]** มันสร้างเอนจินขึ้นมาก่อน พร้อมกับเทสต์บางอย่างที่ใช้กับมัน นี่ถือเป็น vertical slice ที่ดีมากจริงๆ เพราะนี่คือเอนจินที่
**[00:07:39]** จะขับเคลื่อนส่วนที่เหลือของโครงสร้าง ถ้าเอนจินนี้ไม่ทำงานไม่ว่าด้วยเหตุผลใด หรือมันไม่สามารถทำได้ เราก็ต้องค้นพบ
**[00:07:46]** สิ่งนั้นให้เร็ว และนี่คือสิ่งที่การแบ่งแบบนี้ทำ PRD to Issues ยังสร้างความสัมพันธ์แบบ blocking (การบล็อก/กีดขวาง) ระหว่างงานต่างๆ ตัวอย่างเช่น งาน
**[00:07:54]** หมายเลขสองตรงนี้ไม่ได้ถูกบล็อกโดยอะไรเลย ดังนั้นมันสามารถถูกหยิบไปทำได้อิสระจากงานหนึ่ง นี่มีประโยชน์มากถ้าคุณมีระบบเอเจนต์แบบขนาน
**[00:08:02]** ที่คุณสามารถยิงเอเจนต์สองตัวไปทำงานพร้อมกันได้ เช่นใน background tasks (งานเบื้องหลัง) และมันยังหมายความว่าในอนาคตคุณสามารถเพิ่ม
**[00:08:10]** issue อื่นๆ เข้าไปได้ เช่น issue ด้าน QA (ประกันคุณภาพ) ที่คุณพบ หรือสิ่งที่ต้องปรับปรุง แล้วคุณก็สร้างความสัมพันธ์แบบ blocking ระหว่างมันกับ
**[00:08:17]** สิ่งอื่นๆ ทั้งหมด เราจะเห็นว่างานหมายเลขสามถูกบล็อกโดยงานหนึ่ง (เอนจินการแก้ไข) และงานหมายเลขสี่ (การสลับ Monaco editor) ถูกบล็อกโดย
**[00:08:25]** งานหมายเลขสอง ผมเลยตอบรับทั้งหมด แล้วมันก็สร้าง GitHub issues เหล่านี้ทั้งหมดขึ้นมา issue เหล่านี้อ้างอิงถึง PRD หลัก เพื่อให้
**[00:08:33]** local agent (เอเจนต์ในเครื่อง) สามารถไปดึงมันมาดูได้ และมันก็แยกย่อยว่าต้องสร้างอะไรบ้าง และที่สำคัญคือ มันอ้างอิง user stories ก่อนหน้าใน PRD เราสามารถ
**[00:08:41]** เห็นคอมเมนต์จาก Claude Code ที่ลงมือ implement สิ่งนี้จริงๆ เขาพูดว่า "เอนจินแก้ไขเอกสารแบบ pure function (ฟังก์ชันบริสุทธิ์) พร้อมเทสต์ 28 ตัวครอบคลุม
**[00:08:48]** เกณฑ์การยอมรับทั้งหมด" แล้วเราก็สามารถดูคอมมิตที่อ้างอิงถึง issue นี้ได้ นี่คือ Ralph Loop ของผมที่เข้ามาแล้ว
**[00:08:54]** implement สิ่งนี้ตาม issue คอมเมนต์ ปิด issue และจากนั้น issue ถัดไปก็ถูกปลดบล็อก เท่าที่ผ่านมา สกิล Grill Me ช่วยให้คุณ
**[00:09:02]** ขัดเกลาไอเดียให้สมบูรณ์ สกิล Write a PRD ช่วยให้คุณนำไอเดียไปเปลี่ยนเป็นเอกสาร แล้วสกิล PRD to Issues ก็ช่วยให้คุณเปลี่ยน
**[00:09:12]** เอกสารจุดหมายปลายทางนั้นให้เป็นเส้นทางการเดินทางจริง แต่แล้ว คุณจะลงมือ execute (ปฏิบัติ) กับสกิลนั้นได้ยังไง? จะทำให้
## สกิลที่ 4: TDD — เขียนเทสต์ก่อนเสมอ
**[00:09:21]** การ implement แข็งแรงจริงจังและเพิ่มคุณภาพโค้ดที่ผลิตออกมาได้ยังไง? เรามีสกิล TDD TDD ย่อมาจาก test-driven development (การพัฒนาที่ขับเคลื่อนด้วยเทสต์)
**[00:09:30]** และเมื่อคุณเรียกใช้สกิลนี้ มันจะบังคับให้เอเจนต์ หรือพูดให้ถูกคือสนับสนุนให้เอเจนต์ ทำตามวงจร red-green-refactor (แดง-เขียว-รีแฟกเตอร์)
**[00:09:40]** ผิดปกติสำหรับสกิลของผม ตรงนี้มีเนื้อหาเยอะมากจริงๆ มันไม่ใช่แค่ตัวสกิล แต่ยังรวมถึงแนวคิดเรื่องการ refactor (ปรับโครงสร้างโค้ด) การ mocking (การจำลอง)
**[00:09:46]** และ deep modules (โมดูลลึก) คืออะไร การทำ TDD ที่ดีจริงๆ เป็นวิธีที่สม่ำเสมอที่สุดที่ผมใช้ปรับปรุงผลลัพธ์ของเอเจนต์ มาดูกันว่าข้างในมีอะไรบ้าง
**[00:09:54]** สิ่งที่เราเห็นได้คือ ผมจะข้ามเนื้อหาปรัชญาไปก่อน ให้คุณไปอ่านเอาเอง เราจะดูที่เวิร์กโฟลว์นี้เป็นหลัก ใช่แล้ว อันแรกตรงนี้
**[00:10:01]** สำคัญมาก "ยืนยันกับผู้ใช้ว่าต้องเปลี่ยน interface (ส่วนติดต่อ) อะไรบ้าง"
**[00:10:06]** ผมเพิ่งทำวิดีโอเรื่อง interfaces และ implementations เมื่อไม่นานนี้ แต่ขอสรุปสั้นๆ ให้ฟัง เมื่อ AI มองดูโค้ดเบสที่ไม่ดี มันจะมอง
**[00:10:13]** หรือมันจะเห็นอะไรแบบนี้ ที่มีโมดูลเล็กๆ มากมายตรงนี้ที่แยกแยะไม่ออก
**[00:10:20]** มันไม่ได้ถูกจัดกลุ่มเข้าด้วยกันจริงๆ มันไม่ค่อยเข้าใจว่าสิ่งเหล่านี้สัมพันธ์กันยังไง และมันก็ต้องทำงานเยอะเพื่อคิดให้ออกว่า โอเค
**[00:10:26]** อะไรรับผิดชอบอะไร? ความสัมพันธ์เชิงพึ่งพาคืออะไร? โค้ดเบสนี้ทำงานยังไงกันแน่?
**[00:10:31]** ในขณะที่ ถ้าคุณปรับโครงสร้างมันเป็นโมดูลใหญ่ๆ หลายตัว โดยมี interface บางๆ วางอยู่ด้านบน interface คือฟังก์ชันที่
**[00:10:40]** ถูก export ออกมาจากโมดูล สิ่งที่ผู้เรียกใช้ (callers) เรียกจริงๆ แล้วมันจะง่ายกว่ามากสำหรับ AI ในการนำทางโค้ดเบสนี้ และง่ายกว่ามากในการคิดออก
**[00:10:48]** ว่าจะเทสต์โมดูลเหล่านี้ยังไง เพราะคุณแค่เทสต์มันที่ interfaces คุณเทสต์มันที่ขอบเขต คุณสามารถดูวิดีโอเต็มเกี่ยวกับเรื่องนี้ได้ที่ด้านล่าง
**[00:10:55]** สิ่งที่สกิล TDD นี้พยายามส่งเสริมตรงนี้ก็คือ ทำให้การเปลี่ยน interface เหล่านี้เป็นเรื่องที่ AI ให้ความสำคัญสูงสุด เพื่อให้มันเข้าใจว่า
**[00:11:04]** เมื่อมันเปลี่ยน interface นั่นคือการตัดสินใจสำคัญที่มันต้องใช้เวลาคิด คุณยืนยันกับผู้ใช้ว่าจะเทสต์พฤติกรรมใดบ้าง คุณออกแบบ
**[00:11:11]** interfaces เพื่อให้เทสต์ได้ง่าย เชื่อมโยงกับเอกสาร แล้วเราก็มีเนื้อหาเพิ่มเติมเกี่ยวกับการวางแผนตรงนี้ จากนั้นมันเข้าสู่วงจรที่สวยงาม โดยมันเขียนเทสต์ทีละ
**[00:11:20]** อัน และมันเขียนเทสต์ก่อน
**[00:11:22]** ผมเคยพูดถึง red-green-refactor มาก่อน ดังนั้นจะแปะลิงก์วิดีโอไว้ด้านล่างถ้าสนใจ แต่ผมพบว่า red-green-refactor กับเอเจนต์
**[00:11:29]** นั้นเหลือเชื่อมาก และโดยพื้นฐานแล้วมันทำวงจรนี้จนกว่าจะเสร็จ มันแค่เขียนเทสต์ที่ล้มเหลว จากนั้นเขียนโค้ดเพื่อทำให้เทสต์นั้นผ่าน แล้วสุดท้าย มัน
**[00:11:37]** ก็ไล่ดูหาโอกาสในการ refactor ผมยังไม่พบว่าอันนี้จะดีเลิศ มันยังไม่เก่งนัก เพราะบ่อยครั้ง LLM ค่อนข้าง
**[00:11:46]** คุณรู้ไหม พวกมันค่อนข้างไม่เต็มใจที่จะ refactor โค้ดของตัวเอง ถ้าคุณล้าง context ของ LLM มันก็จะลบความทรงจำของตัวเอง
**[00:11:53]** และมันจะไม่หวงแหนโค้ดที่มันเพิ่งเขียนไปมากนัก
**[00:11:56]** แต่ในขณะที่โค้ดของมันเองยังอยู่ใน context window ของมัน มันก็ค่อนข้างไม่เต็มใจที่จะเปลี่ยนมัน ดังนั้นสกิล TDD นี้คือสิ่งที่ผมใช้เป็นพรอมต์ให้ Ralph loops ของผม
**[00:12:03]** เพื่อให้พวกมันทำ red-green-refactor ทีนี้ TDD ต้องการอะไรจากคุณมาก หรือพูดให้ถูกคือมันต้องการจากโค้ดเบสของคุณมาก TDD ทำได้ยากมากในโค้ดเบสที่
**[00:12:13]** โครงสร้างไม่ดี เพราะขอบเขตการเทสต์ของมันไม่ชัดเจนเลย มันควรเทสต์โมดูลเหล่านี้แยกกันไหม? มันควรเทสต์โมดูลเหล่านี้
**[00:12:21]** แยกกันไหม? ขอบเขตตรงนี้คืออะไร?
**[00:12:22]** ในขณะที่เมื่อโค้ดเบสของคุณหน้าตาแบบนี้ มันก็ง่ายกว่ามากที่จะเทสต์ เพราะขอบเขตของโมดูลชัดเจนมาก แล้วมันจะไม่ดีเหรอ
## สกิลที่ 5: Improved Code Base Architecture — ปรับโครงสร้างโค้ดเบสให้ลึก
**[00:12:29]** ถ้ามีอะไรที่ทำให้โค้ดเบสของคุณหน้าตาแบบนี้ล่ะ? ดีไหมล่ะ เรามีสกิล improved code base architecture (ปรับปรุงสถาปัตยกรรมโค้ดเบส)
**[00:12:36]** กระบวนการของสกิลนี้คือ เราสำรวจโค้ดเบส และสำรวจแบบธรรมชาติเหมือนที่เอเจนต์ทั่วไปทำ เราพยายามหาจุดที่ทำให้สับสน
**[00:12:44]** เราไม่ได้แบบว่า เราพยายามเผยสิ่งที่ AI พบว่าสับสนโดยธรรมชาติ เพื่อที่มันจะได้ช่วยเหลือมันได้ทีหลัง โค้ดตรงไหนที่
**[00:12:53]** การเข้าใจแนวคิดหนึ่งต้องเด้งไปมาระหว่างไฟล์เล็กๆ หลายไฟล์? ตรงไหนที่มีการแยก pure functions ออกมาแค่เพื่อให้เทสต์ได้ แต่
**[00:12:59]** บั๊กจริงๆ ซ่อนอยู่ในวิธีการเรียกใช้มัน?
**[00:13:01]** ตรงไหนที่โมดูลที่ผูกกันแน่น (tightly coupled) สร้างความเสี่ยงในการ integration ตรงรอยต่อระหว่างมัน? ทั้งหมดนี้คือคำถามที่วิศวกรอาวุโสจะถามเกี่ยวกับ
**[00:13:09]** โค้ดเบสของคุณ ขั้นตอนที่สองคือคุณนำเสนอตัวเลือก คุณนำเสนอรายการตัวเลขของ deepening opportunities (โอกาสในการทำให้ลึกขึ้น) พูดอีกอย่างคือโอกาสในการทำให้โมดูลตื้น
**[00:13:18]** ในโค้ดเบสของคุณลึกขึ้น ผู้ใช้เลือกตัวเลือกหนึ่ง แล้วคุณก็ออกแบบ interfaces หลายแบบ มันบอกว่าให้สร้าง subagents สามตัว
**[00:13:27]** ทำงานแบบขนาน โดยแต่ละตัวต้องผลิต interface ที่แตกต่างกันอย่างสิ้นเชิงสำหรับโมดูลที่จะทำให้ลึก พูดอีกอย่างคือ เรากำลังแยกโค้ดนั้นออกมาและออกแบบ
**[00:13:35]** ความเป็นไปได้ว่ามันจะหน้าตาแบบไหนในอนาคต การออกแบบมันหลายๆ แบบที่แตกต่างกัน เป็นวิธีที่ดีมากที่ทำให้คุณตัดสินใจเลือก
**[00:13:42]** ไอเดียที่ถูกต้องได้ ผมเคยเห็นเอเจนต์นี้สร้าง subagents ห้าตัวสำหรับการ refactor ครั้งใหญ่ สิ่งที่เจ๋งที่สุดคือคุณไม่จำเป็นต้องรู้มาก
**[00:13:49]** เกี่ยวกับการออกแบบ interface เพื่อให้สิ่งนี้ทำงาน หลังจากเปรียบเทียบแล้ว ให้คำแนะนำของคุณว่าคุณคิดว่าการออกแบบแบบไหนแข็งแกร่งที่สุดและเพราะอะไร และถ้าองค์ประกอบ
**[00:13:56]** จากการออกแบบต่างกันเข้ากันได้ดี ก็เสนอแบบลูกผสม (hybrid) สังเกตว่าผมทำให้สกิลนี้ไม่ผูกกับภาษาใดภาษาโดยเฉพาะ
**[00:14:04]** ไม่ผูกกับอะไรเลยจริงๆ คุณสามารถรันมันในโค้ดเบสใดก็ได้ แล้วได้คำตอบที่ดีว่ามันจะปรับปรุงได้ยังไง
**[00:14:09]** อาจมีตัวเลือกสี่ห้าตัวที่ควรปรับปรุงจริงๆ แต่ผมคิดว่าคุณควรทำทีละอันเท่านั้น เพราะ
**[00:14:17]** มันค่อนข้างยากที่จะทำความเข้าใจ และมันต้องมีมนุษย์อยู่ในวงจร (human in the loop) นั่งอยู่กับมันเพื่อปรับปรุงโค้ดเบส เพราะการตัดสินใจเหล่านี้
**[00:14:25]** ต้องใช้รสนิยม สุดท้าย มันสร้าง GitHub issue มันสร้าง refactor RFC เป็น GitHub issue โดยใช้ GH issue create โดยปกติ เมื่อเสร็จสิ้น ผม
**[00:14:34]** จะใช้สกิล PRD to Issues ของผม อ้างอิง GitHub issue ที่เพิ่งถูกสร้างขึ้น และให้มัน คุณรู้ไหม นี่อธิบาย
**[00:14:41]** จุดหมายปลายทาง เราจึงต้องมีเส้นทางเพื่อไปให้ถึง ดังนั้น แค่ทำแบบนี้เป็นครั้งคราวในโค้ดเบส สัปดาห์ละครั้งเพื่อหาโอกาส หรือ
**[00:14:49]** ถ้าคุณมีการพัฒนาที่พุ่งพรวดขึ้นมา และคุณสร้างฟีเจอร์เพิ่มอีกปีกใหญ่ สกิลนี้จะมีประโยชน์มากจริงๆ ในการทำให้แน่ใจว่ามัน
**[00:14:59]** สอดคล้องกับโค้ดเบสที่เหลือ ทำให้แน่ใจว่ามันไม่ได้เละเทะเกินไป
**[00:15:03]** และเมื่อคุณรันมันต่อไปเรื่อยๆ เมื่อคุณปรับปรุงโค้ดเบสของคุณอย่างต่อเนื่อง คุณจะสังเกตว่าคุณภาพของผลลัพธ์ของเอเจนต์สูงขึ้น เพราะคำพูดเก่าๆ
**[00:15:10]** นั้นใช้ได้จริง ถ้าคุณมีโค้ดเบสที่แย่ AI ก็จะผลิตของแย่ๆ ออกมาในโค้ดเบสนั้น
## บทสรุป — ปฏิบัติต่อ AI เหมือนมนุษย์ และคอร์ส Claude Code for Real Engineers
**[00:15:15]** เพราะพูดตามตรง ถ้าคุณเอาสกิลทั้งหมดนี้มาแล้วพูดว่า "โอเค นี่เหมือนหนังสือ markdown เล็กๆ เกี่ยวกับกระบวนการสำหรับมนุษย์" มันก็
**[00:15:24]** ไม่ดูแปลกที่ใด ผมพบว่าวิธีที่ประสบความสำเร็จที่สุดในการเพิ่มคุณภาพโค้ดจากเอเจนต์คือปฏิบัติต่อพวกมันเหมือนมนุษย์ มนุษย์ที่มีข้อจำกัดแปลกๆ
**[00:15:32]** แน่นอน มนุษย์ที่ไม่มีหน่วยความจำและถูกโคลน ออกมาจากฝักให้กำเนิดแล้วไปทำงานทันที แต่ถ้าคุณคิดเหมือนผมว่า
**[00:15:39]** ทักษะวิศวกรรมจริงจังเหล่านี้สำคัญมาก คอร์สนี้เหมาะสำหรับคุณอย่างแน่นอน
**[00:15:44]** สิ่งที่ผมสังเกตเห็นระหว่างสร้างคอร์สคือ ผมไม่ได้สอน Claude Code มากขนาดนั้นจริงๆ ผมสอนเกี่ยวกับ sub agents ของเรา ผมพูดถึง
**[00:15:50]** ข้อจำกัดของ LLM เรื่องโซนฉลาด-โซนโง่แปลกๆ กับ context window เราพูดถึงการบังคับทิศทาง (steering) ซึ่งโดยพื้นฐานแล้ว
**[00:15:58]** ก็เป็นวิธีการจัดเก็บเอกสารภายในโค้ดเบสของคุณ วิธีจัดการงานใหญ่โต การเข้าใจ tracer bullets และสร้างมันเข้าไปในสกิลของเรา
**[00:16:06]** การเข้าใจวิธีสร้าง feedback loops (วงจรข้อมูลป้อนกลับ) ที่ดีจริงๆ และทำแบบฝึกหัดกับมัน และที่สำคัญคือวิธีเชื่อมต่อสิ่งเหล่านี้เข้ากับเอเจนต์อัตโนมัติ ทุกส่วนของ
**[00:16:13]** คอร์สนี้เชื่อมโยงไปยังส่วนถัดไป และผมมีความสุขมากกับผลลัพธ์ ดังนั้น ในช่วง 2 สัปดาห์ คุณจะได้ทำงานผ่าน
**[00:16:21]** เนื้อหาที่เรียนด้วยตัวเองนี้ โดยมีผมเป็นไกด์ใน Discord และใน office hours (ชั่วโมงปรึกษา) สด และถ้าฟังดูสนุกสำหรับคุณ ลิงก์อยู่ด้านล่าง ขอบคุณที่
**[00:16:28]** รับชมครับทุกคน ผมจะกลับมาพร้อมเนื้อหาอีกมากในสัปดาห์นี้ อยากให้ผมทำอะไรต่อไป? ผมพบว่าจุดตัดระหว่าง
**[00:16:34]** วิศวกรรมจริงจังกับ AI นี้เป็นจุดที่ยอดเยี่ยมมากในการทำคอนเทนต์ แต่ยังไงก็ตาม ขอบคุณที่รับชม แล้วเจอกันในวิดีโอหน้า
หมายเหตุการแปล
ความโปร่งใสเกี่ยวกับความไม่แน่นอนในต้นฉบับ
- 6. **ไม่พบส่วนที่ฟังไม่ชัด** — ไม่จำเป็นต้องใช้เครื่องหมาย `[ฟังไม่ชัด]`
อภิธานศัพท์เทคนิค
คำศัพท์และชื่อผลิตภัณฑ์ที่คงรูปภาษาอังกฤษ
| ศัพท์ | คำแปล / คำอธิบาย |
|---|---|
| --- | --- (---) |
| agent | เอเจนต์ (AI ที่ทำงานอัตโนมัติตามคำสั่ง) |
| subagent | ซับเอเจนต์ (เอเจนต์ย่อยที่ถูกสร้างขึ้นเพื่อทำงานเฉพาะ) |
| process | กระบวนการทำงาน (ขั้นตอนที่นิยามไว้ชัดเจน) |
| skill | สกิล (ไฟล์คำสั่ง/พรอมต์ที่เข้ารหัสกระบวนการทำงานให้ AI) |
| Claude Code | Claude Code (เครื่องมือ AI coding ของ Anthropic (คงรูป)) |
| LLM | LLM (Large Language Model) (โมเดลภาษาขนาดใหญ่) |
| context window | context window (หน้าต่างบริบท/พื้นที่ความจำของโมเดล) |
| plan mode | โหมด plan (วางแผน) (โหมดวางแผนของ Claude Code) |
| design tree | design tree (ต้นไม้การออกแบบ) (แนวคิดจากหนังสือ The Design of Design ของ Frederick P. Brooks — การเดินไล่ทุกกิ่งก้านของการตัดสินใจออกแบบ) |
| shared understanding | ความเข้าใจตรงกัน (เป้าหมายของการสัมภาษณ์ไอเดียก่อนลงมือ) |
| codebase | โค้ดเบส (ชุดซอร์สโค้ดทั้งหมดของโปรเจกต์) |
| PRD (Product Requirements Document) | PRD — เอกสารข้อกำหนดผลิตภัณฑ์ (เอกสารอธิบายจุดหมายปลายทางของงาน) |
| GitHub issue | GitHub issue (ปัญหา/งานใน GitHub) (รายการงาน/ปัญหาที่ติดตามใน GitHub) |
| Kanban board | บอร์ด Kanban (บอร์ดจัดการงานแบบการ์ด) |
| vertical slice | vertical slice (ชิ้นงานแนวตั้ง) (ชิ้นงานที่ตัดทะลุทุกชั้นของระบบ) |
| horizontal slice | ชิ้นแนวนอน (ชิ้นงานที่ครอบคลุมเพียงชั้นเดียว) |
| tracer bullet | tracer bullet (กระสุนส่องวิถี) (การทำชิ้นงานบาง ๆ ผ่านทุกชั้นเพื่อทดสอบแนวทางเร็ว ๆ) |
| unknown unknowns | สิ่งที่เราไม่รู้ว่าเราไม่รู้ (ความเสี่ยงที่ยังมองไม่เห็น) |
| blocking relationship | ความสัมพันธ์แบบ blocking (งานหนึ่งถูกกีดขวางโดยอีกงานหนึ่ง) |
| Ralph loop | Ralph loop (วนลูปทำงานอัตโนมัติทีละ issue (ชื่อเรียกของ Matt Pocock)) |
| background tasks | งานเบื้องหลัง (background tasks) (งานที่รันแบบขนานเบื้องหลัง) |
| TDD (Test-Driven Development) | TDD — การพัฒนาที่ขับเคลื่อนด้วยเทสต์ (เขียนเทสต์ก่อนแล้วค่อยเขียนโค้ด) |
| red-green-refactor | red-green-refactor (แดง-เขียว-รีแฟกเตอร์) (เขียนเทสต์ที่ล้มเหลว (แดง) → ทำให้ผ่าน (เขียว) → ปรับโครงสร้าง (refactor)) |
| refactor | refactor — ปรับโครงสร้างโค้ด (ปรับปรุงโครงสร้างโดยไม่เปลี่ยนพฤติกรรม) |
| mocking | mocking — การจำลอง (สร้างของจำลองสำหรับเทสต์) |
| deep module | deep module (โมดูลลึก) (โมดูลที่มี interface เล็กแต่ความสามารถลึกซึ้ง) |
| shallow module | โมดูลตื้น (โมดูลที่ interface ใหญ่แต่ทำอะไรได้น้อย) |
| interface | interface (ส่วนติดต่อ) (ฟังก์ชันที่ถูก export ให้ผู้เรียกใช้) |
| implementation | implementation — การนำไปปฏิบัติ (การลงมือเขียนโค้ดจริง) |
| pure function | pure function (ฟังก์ชันบริสุทธิ์) (ฟังก์ชันที่ผลลัพธ์ขึ้นกับอินพุตเท่านั้น ไม่มีผลข้างเคียง) |
| tightly coupled | ผูกกันแน่น (tightly coupled) (โมดูลพึ่งพากันสูง สร้างความเสี่ยงการรวมระบบ) |
| integration | integration — การรวมระบบ/เชื่อมต่อ (การเชื่อมต่อส่วนต่าง ๆ เข้าด้วยกัน) |
| deepening opportunities | โอกาสในการทำให้ลึกขึ้น (โอกาสปรับโมดูลตื้นให้เป็นโมดูลลึก) |
| refactor RFC | refactor RFC (เอกสารเสนอการปรับโครงสร้าง (เปิดเป็น GitHub issue)) |
| GH issue create | GH issue create (คำสั่ง CLI ของ GitHub สำหรับสร้าง issue) |
| user story | user story (เรื่องราวผู้ใช้) (คำอธิบายพฤติกรรมที่ต้องการของระบบ จากระเบียบวิธี Agile) |
| Agile methodology | ระเบียบวิธี Agile (กระบวนการพัฒนาซอฟต์แวร์แบบว่องไว) |
| Cucumber | Cucumber (เครื่องมือ/ภาษาเขียนเทสต์พฤติกรรม (คงรูป)) |
| Monaco editor | Monaco editor (ตัวแก้ไขโค้ดของ VS Code (คงรูป)) |
| split pane | split pane (แบ่งจอสองแผง) (การแบ่งหน้าจอเป็นสองส่วน) |
| problem statement | problem statement (คำอธิบายปัญหา) (การระบุปัญหาที่จะแก้) |
| acceptance criteria | เกณฑ์การยอมรับ (เงื่อนไขที่ต้องผ่านจึงถือว่างานสำเร็จ) |
| QA (Quality Assurance) | QA — ประกันคุณภาพ (งานตรวจสอบคุณภาพ) |
| steering | การบังคับทิศทาง (steering) (วิธีควบคุม/นำทางเอเจนต์) |
| feedback loop | feedback loop — วงจรข้อมูลป้อนกลับ (วงจรรับผลแล้วปรับปรุง) |
| human in the loop | human in the loop (มีมนุษย์อยู่ในวงจรการทำงาน) |
| autonomous agent | เอเจนต์อัตโนมัติ (เอเจนต์ที่ทำงานได้เองโดยไม่ต้องคุมทุกขั้นตอน) |
| office hours | office hours (ชั่วโมงปรึกษา) (ช่วงเวลาสดสำหรับถามตอบ) |
| cohort | cohort (เรียนพร้อมกันเป็นรุ่น) (กลุ่มผู้เรียนรุ่นเดียวกัน) |
| markdown | markdown (รูปแบบไฟล์ข้อความมาร์กอัป) |
| repo | repo (repository) (ที่เก็บโค้ด/ไฟล์ของโปรเจกต์) |
| commit | คอมมิต (การบันทึกการเปลี่ยนแปลงโค้ดใน git) |
| engine | เอนจิน (โมดูลแกนกลางที่ขับเคลื่อนระบบ) |
| GitHub | GitHub (แพลตฟอร์มเก็บโค้ด (คงรูป)) |
| Discord | Discord (แพลตฟอร์มแชท (คงรูป)) |
| TypeScript | TypeScript (ภาษาโปรแกรม (คงรูป — ไม่ปรากฏตรง ๆ แต่เป็นสาขาหลักของ Matt Pocock)) |
ซับไตเติ้ลภาษาไทย
ดาวน์โหลดหรือดูซับทั้งหมด
1 00:00:00,000 --> 00:00:08,120 ผมเป็นวิศวกรมาเกือบสิบปี และในเวลาทั้งหมดนั้น ตอนนี้แหละที่ process (กระบวนการทำงาน) สำคัญที่สุดเท่าที่เคยเป็นมา ในมือคุณตอนนี้มีวิศวกรระดับกลางถึงดีเป็นกองทัพที่พร้อมจะใช้งานได้ทุกเมื่อ 2 00:00:08,120 --> 00:00:16,680 แต่เรื่องแปลกของวิศวกรเหล่านี้คือ พวกเขาไม่มีหน่วยความจำ พวกเขาจำสิ่งที่เคยทำมาก่อนไม่ได้ ดังนั้นคุณจึงต้องมีกระบวนการที่เคร่งครัดและนิยามไว้ชัดเจนมาก เพื่อให้เอเจนต์เหล่านี้ทำงานที่มีประโยชน์ได้จริง 3 00:00:16,680 --> 00:00:25,600 นั่นหมายความว่า ในฐานะนักพัฒนา คุณต้องมองหาวิธีควบคุมเอเจนต์ของคุณตลอดเวลา เพื่อให้พวกเขาอยู่ในเส้นทางที่ถูกต้อง 4 00:00:25,600 --> 00:00:32,920 และสำหรับผม สิ่งนั้นส่งผลให้เกิดการสร้างสกิลขึ้นมามากมาย นี่คือ repo รวมสกิลทั้งหมดที่ผมใช้อยู่ตอนนี้ ซึ่งแต่ละอันผมออกแบบและปรับปรุงด้วยตัวเอง
เปิดดูซับไตเติ้ลทั้งหมด (140 segments)
1 00:00:00,000 --> 00:00:08,120 ผมเป็นวิศวกรมาเกือบสิบปี และในเวลาทั้งหมดนั้น ตอนนี้แหละที่ process (กระบวนการทำงาน) สำคัญที่สุดเท่าที่เคยเป็นมา ในมือคุณตอนนี้มีวิศวกรระดับกลางถึงดีเป็นกองทัพที่พร้อมจะใช้งานได้ทุกเมื่อ 2 00:00:08,120 --> 00:00:16,680 แต่เรื่องแปลกของวิศวกรเหล่านี้คือ พวกเขาไม่มีหน่วยความจำ พวกเขาจำสิ่งที่เคยทำมาก่อนไม่ได้ ดังนั้นคุณจึงต้องมีกระบวนการที่เคร่งครัดและนิยามไว้ชัดเจนมาก เพื่อให้เอเจนต์เหล่านี้ทำงานที่มีประโยชน์ได้จริง 3 00:00:16,680 --> 00:00:25,600 นั่นหมายความว่า ในฐานะนักพัฒนา คุณต้องมองหาวิธีควบคุมเอเจนต์ของคุณตลอดเวลา เพื่อให้พวกเขาอยู่ในเส้นทางที่ถูกต้อง 4 00:00:25,600 --> 00:00:32,920 และสำหรับผม สิ่งนั้นส่งผลให้เกิดการสร้างสกิลขึ้นมามากมาย นี่คือ repo รวมสกิลทั้งหมดที่ผมใช้อยู่ตอนนี้ ซึ่งแต่ละอันผมออกแบบและปรับปรุงด้วยตัวเอง 5 00:00:32,920 --> 00:00:35,280 บางอันผมใช้นานๆ ครั้ง แต่บางอันผมใช้ทุกวัน 6 00:00:35,280 --> 00:00:42,280 และสกิลเหล่านี้ช่วยให้ผมเข้ารหัสกระบวนการทำงานของผมไว้ เพื่อให้ AI มีเส้นทางที่เคร่งครัดชัดเจนที่มันสามารถเดินตามได้ทุกครั้ง 7 00:00:42,280 --> 00:00:51,280 และผลจากการใช้สกิลทั้งหมดนี้ ทำให้คุณภาพโค้ดที่ AI ผลิตออกมาสูงขึ้นอย่างก้าวกระโดด 8 00:00:51,280 --> 00:00:59,280 ทีนี้ ถ้าคุณคิดว่า process สำคัญ และทักษะวิศวกรรมจริงจังสำคัญล่ะก็ ผมมีคอร์สสำหรับคุณโดยเฉพาะ 9 00:00:59,280 --> 00:01:07,480 คอร์สนี้ชื่อว่า Claude Code for Real Engineers เป็นคอร์สแบบ cohort (เรียนพร้อมกันเป็นรุ่น) ระยะเวลา 2 สัปดาห์ เริ่ม 30 มีนาคม 10 00:01:07,480 --> 00:01:15,840 และอีก 7 วันนี้ ลดราคา 40% ถ้ารู้สึกว่าตามหลังคนอื่นเรื่อง Claude Code อยู่ และอยากนำหน้าแบบก้าวกระโดดภายใน 2 สัปดาห์ 11 00:01:15,840 --> 00:01:24,080 แล้วล่ะก็ นี่คือที่สำหรับคุณ เอาล่ะ มาพูดถึงสกิลของเรากันดีกว่า เริ่มจากสกิลแรก ซึ่งอาจเป็นสกิลโปรดของผม นี่คือ 12 00:01:24,080 --> 00:01:32,040 สกิล Grill Me (ย่างผมซะ) สกิลนี้ ใช่แล้ว มันยาวแค่สามประโยคเอง และขออ่านทั้งหมดให้ฟังเพื่ออธิบายว่ามันทำอะไรบ้าง 13 00:01:32,040 --> 00:01:39,240 "สัมภาษณ์ฉันอย่างไม่ลดละเกี่ยวกับทุกแง่มุมของแผนนี้ จนกว่าเราจะเข้าใจตรงกัน "เดินลงไปตามกิ่งก้านแต่ละกิ่งของ design tree (ต้นไม้การออกแบบ) แก้ความสัมพันธ์เชิงพึ่งพาระหว่างการตัดสินใจทีละอย่าง 14 00:01:39,240 --> 00:01:44,640 และสุดท้าย ถ้าคำถามใดตอบได้ด้วยการสำรวจโค้ดเบส ก็ให้สำรวจโค้ดเบสแทน" 15 00:01:44,640 --> 00:01:51,600 แนวคิดเรื่อง design tree มาจากหนังสือเล่มนี้ของ Frederick P. Brooks ชื่อ The Design of Design จริงๆ ผมไม่แน่ใจว่ามันมาจากหนังสือเล่มนี้หรือเปล่า 16 00:01:51,600 --> 00:01:53,280 แต่หนังสือเล่มนี้คือที่แรกที่ผมเห็นแนวคิดนี้ 17 00:01:53,280 --> 00:02:00,920 design tree คือแนวคิดที่ว่า ขณะที่คุณกำลังเข้าหาการออกแบบ คุณต้องเดินลงไปตามกิ่งก้านทั้งหมดของต้นไม้การออกแบบ ตัวอย่างเช่น คุณอาจกำลัง 18 00:02:00,920 --> 00:02:07,360 ออกแบบหน้า search (ค้นหา) และต้องตัดสินใจว่าต้องการ search แบบขั้นสูง หรือแค่กล่องพิมพ์ข้อความ ถ้าเลือก search แบบขั้นสูง คุณก็ต้องคิดให้ออกว่า 19 00:02:07,360 --> 00:02:14,120 ต้องมี filter (ตัวกรอง) อะไรบ้าง และวิธีเรียงลำดับแบบไหนบ้างบน search แบบขั้นสูง แล้วคุณก็เดินลงต้นไม้ต่อไปเรื่อยๆ จนกว่าจะคิดการออกแบบ 20 00:02:14,120 --> 00:02:18,720 ของคุณออกมาได้อย่างครบถ้วน หรือเท่าที่ทำได้เต็มที่ ก่อนที่จะลงมือเขียนโค้ดจริง 21 00:02:18,720 --> 00:02:27,400 สกิล Grill Me นี้ ผมจะเรียกใช้มันเมื่อต้องการให้เกิดความเข้าใจตรงกันกับ LLM ผมเพิ่งค้นพบว่าเมื่อไม่นานมานี้ Claude Code 22 00:02:27,400 --> 00:02:35,800 มักจะพ่นแผนออกมาซะก่อนเร็วเกินไป เมื่อผมเข้าโหมด plan (วางแผน) และมันมักจะสร้างเอกสารขึ้นมาก่อนที่ผมจะรู้สึกว่าเราเข้าใจตรงกัน 23 00:02:35,800 --> 00:02:43,560 กับ LLM แล้ว แต่สกิล Grill Me บังคับให้เกิดบทสนทนานั้นขึ้น มันบังคับให้ LLM สัมภาษณ์ผมเกี่ยวกับทุกส่วน นี่คือบทสนทนาที่ผมคุยกับ 24 00:02:43,560 --> 00:02:51,560 Claude เมื่อไม่นานนี้ เกี่ยวกับการเพิ่มฟีเจอร์ให้โค้ดเบสตัวแก้ไขวิดีโอคอร์สของผม ผมให้งานวิจัยที่ผมทำไว้ในไฟล์ markdown แล้วพูดว่า "Grill me" ผมอยาก 25 00:02:51,560 --> 00:02:59,000 ลองคิดเรื่องการเพิ่มสิ่งนี้ลงในหน้าขวา มันโหลดสกิลขึ้นมา และสิ่งที่ผมอยากให้คุณเห็นคือ มันถามคำถามผมเยอะแค่ไหน 26 00:02:59,000 --> 00:03:05,160 สิ่งแรกที่มันทำคือสำรวจส่วนที่เกี่ยวข้องในโค้ดเบส ซึ่งถือว่าดี แล้วเราก็ซูมลงไป จะเห็นว่ามันถามคำถามข้อหนึ่ง "เอกสารอยู่ที่ไหน?" 27 00:03:05,160 --> 00:03:11,760 คำถามข้อสอง "UI layout (เค้าโครงหน้าจอ) เป็นยังไง?" คำถามข้อสาม "โหมดไหนบ้างที่ได้แผงเอกสาร?" คำถามข้อสี่ "วงจรชีวิตของเอกสาร" 28 00:03:11,760 --> 00:03:19,080 คำถามข้อห้า "เครื่องมือเอกสารด้านขวาหน้าตาเป็นยังไง?" คำถามข้อหก "รูปร่างของเครื่องมือแก้ไข" คำถามข้อเจ็ด แล้วก็ถามต่อลงไปเรื่อยๆ จนถึงคำถาม 29 00:03:19,080 --> 00:03:27,880 ข้อเก้า ข้อสิบ ข้อสิบเอ็ด ข้อสิบสอง ลงไปจนถึงคำถามข้อสิบหกสุดบ้าตรงนี้ และนี่คือเซสชันการ Grill ที่ค่อนข้างสั้นในความเห็นของผม 30 00:03:27,880 --> 00:03:34,959 ผมเคยมีเซสชันที่นั่งอยู่เกือบครึ่งชั่วโมง 45 นาที กับ AI ที่ตอบคำถามเกี่ยวกับฟีเจอร์ที่ซับซ้อนมากๆ คุณรู้ไหม 31 00:03:34,959 --> 00:03:42,920 นั่นอาจเป็นคำถาม 30, 40, 50 ข้อ จากสกิลเล็กๆ จิ๋วๆ อันนี้ นั่นคือสิ่งหนึ่งที่ผมอยากให้คุณเก็บไปจากวิดีโอนี้ 32 00:03:42,920 --> 00:03:50,040 สกิลไม่จำเป็นต้องยาวเพื่อให้มีผลกระทบ คุณแค่ต้องเลือกคำพูดที่ถูกต้องให้ LLM ในเวลาที่ถูกต้อง และการแก้ความสัมพันธ์เชิงพึ่งพาด้วย design tree นี้ 33 00:03:50,040 --> 00:03:57,040 มันยอดเยี่ยมมากสำหรับผม ยังไงก็ตาม ถ้าอยากได้สกิลเหล่านี้ มันจะอยู่ในลิงก์ด้านล่าง เมื่อผมเข้าใจตรงกัน 34 00:03:57,040 --> 00:04:05,480 กับ LLM แล้ว เมื่อผมย่างความคิดของผมจนเข้าใจผลพวงทั้งหมดของมันแล้ว ถ้าผมตัดสินใจว่าอยากลงมือทำจริง ผมก็ 35 00:04:05,480 --> 00:04:11,959 เรียกใช้สกิลถัดไป ซึ่งก็คือสกิล Write a PRD (เขียน PRD) จริงๆ แล้วผมทำสิ่งนี้ในบทสนทนาที่เราดูกันเมื่อกี้ มันเลยพูดว่า "มีอะไรที่ฉันพลาดหรือทำผิด 36 00:04:11,959 --> 00:04:19,519 ไหม?" แล้วผมก็พูดว่า "Write a PRD" ผมเติมท้ายด้วยคำว่า user เพราะบางสกิลของผมอยู่ในโปรเจกต์ นั่นคือเหตุผลที่ผมทำแบบนั้น 37 00:04:19,519 --> 00:04:25,480 นี่คือหน้าตาของสกิลนี้ จะถูกเรียกใช้เมื่อผู้ใช้ต้องการสร้าง PRD คุณอาจข้ามขั้นตอนได้ถ้าเห็นว่าไม่จำเป็น ตัวอย่างเช่น 38 00:04:25,480 --> 00:04:31,280 ในบทสนทนาก่อนหน้านี้ มันพูดว่า "เราได้สัมภาษณ์เชิงลึกไปแล้ว ไปขั้นตอนที่สี่กันเถอะ" ขั้นตอนที่หนึ่งคือถามผู้ใช้ให้คำอธิบายที่ยาว 39 00:04:31,280 --> 00:04:38,480 ละเอียด แล้วขั้นตอนที่สองคือสำรวจ repo เพื่อยืนยันข้อความอ้างของผู้ใช้ ขั้นตอนที่สามคือการสัมภาษณ์ผู้ใช้อย่างไม่ลดละ ซึ่งก็ 40 00:04:38,480 --> 00:04:40,160 เป็นแค่สำเนาของสกิล Grill Me อีกที 41 00:04:40,160 --> 00:04:47,400 ต่อไป เราร่างโมดูลหลักที่คุณต้องสร้างหรือแก้ไขเพื่อทำให้การ implement (นำไปปฏิบัติ) เสร็จสมบูรณ์ เราจะกลับมาดูตรงนี้ทีหลัง เพราะมันเชื่อมโยง 42 00:04:47,400 --> 00:04:53,880 กับสกิลที่ผมจะโชว์ให้ดูในวิดีโอนี้ สุดท้าย เมื่อคุณเข้าใจปัญหาและวิธีแก้อย่างครบถ้วนแล้ว ให้ใช้เทมเพลตด้านล่าง 43 00:04:53,880 --> 00:05:02,360 เพื่อเขียน PRD และ PRD ควรถูกส่งเป็น GitHub issue (ปัญหา/งานใน GitHub) วิธีที่เวิร์กโฟลว์การพัฒนาของผมทำงานคือ ผมนำ PRD เหล่านี้ใน GitHub ไปเปลี่ยนเป็น 44 00:05:02,360 --> 00:05:10,560 GitHub issue อีกหลายอันที่อ้างอิงถึง PRD หลัก แล้วผมก็มี Ralph loop ที่วนลูปไปตามแต่ละ issue จนกว่าจะเสร็จ ถ้ากลับไปที่บทสนทนา 45 00:05:10,560 --> 00:05:18,040 ก่อนหน้านี้ เราจะเห็นว่ามันสร้าง PRD นี้ขึ้นมา นี่คือสี่วันที่แล้ว อย่างที่เห็น เรามี problem statement (คำอธิบายปัญหา) หน้าสำหรับ 46 00:05:18,040 --> 00:05:24,320 เขียนบทความปัจจุบันสร้างเอกสารใหม่ทั้งฉบับทุกครั้งที่มีการโต้ตอบกับ AI และวิธีแก้คือเพิ่มประสบการณ์การแก้ไขเอกสารแบบ split pane (แบ่งจอสองแผง) 47 00:05:24,320 --> 00:05:31,160 ให้กับตัวเขียนบทความ แชทอยู่ฝั่งซ้าย และแผงเอกสารใหม่อยู่ฝั่งขวา บลาๆ นี่คือฟีเจอร์ใหญ่ เรากำลังเพิ่มการแก้ไขเอกสารให้กับฟีเจอร์ 48 00:05:31,160 --> 00:05:38,160 แชท AI สิ่งสำคัญตรงนี้คือ user stories (เรื่องราวผู้ใช้) มี user stories มากมายเป็นส่วนหนึ่งของสิ่งนี้ และสิ่งนี้มาจากระเบียบวิธี Agile 49 00:05:38,160 --> 00:05:46,240 และโดยพื้นฐานแล้วเราพยายามอธิบายพฤติกรรมที่ต้องการของระบบด้วยภาษาธรรมชาติ ซึ่งไม่ใช่เรื่องง่ายเลย ผมยังไม่ได้ 50 00:05:46,240 --> 00:05:47,960 ตกลงใจกับรูปแบบที่ถูกต้องสำหรับสิ่งเหล่านี้ได้จริงๆ 51 00:05:47,960 --> 00:05:54,960 นี่เป็นแค่สิ่งที่ผมพอใจ แต่คุณสามารถใช้ภาษาแบบ Cucumber หรืออะไรก็ตามที่คุณคุ้นเคยกับการทำงานด้วยก็ได้ 52 00:05:54,960 --> 00:06:03,440 จากนั้นเราก็ซูมลงมาด้านล่าง แล้วก็ใส่การตัดสินใจเชิง implementation (การนำไปปฏิบัติ) เข้าไป การตัดสินใจเชิง implementation ตรงนี้ เราไม่อยาก 53 00:06:03,440 --> 00:06:10,560 ระบุเจาะจงมากเกินไป เพราะเราอยากให้มันคงทน เพราะถ้าโค้ดเริ่มล้าสมัยไม่ตรงกับ PRD เราก็จะมีปัญหาเมื่อ 54 00:06:10,560 --> 00:06:18,200 เราจะลงมือ implement จริง แต่คุณเห็นทฤษฎีตรงนี้ นี่คือคำอธิบายที่ดีมากของจุดหมายปลายทางที่เรากำลังจะไป แต่ 55 00:06:18,200 --> 00:06:26,080 สิ่งที่ PRD ไม่ได้ให้เราคือเส้นทางการเดินทางจริง หนทางที่เราจะไปถึงจุดหมายนี้ และถ้าเรากลับไปที่บทสนทนานั้น 56 00:06:26,080 --> 00:06:35,840 นี่คือจุดที่ผมใช้สกิลถัดไปของผม ซึ่งก็คือ PRD to Issues (จาก PRD ไปสู่ Issues) สิ่งที่มันทำคือนำ PRD ซึ่งคือจุดหมายปลายทาง ไปเปลี่ยนเป็นบอร์ด Kanban ของ 57 00:06:35,840 --> 00:06:42,880 issue ต่างๆ ที่แต่ละอันสามารถหยิบไปทำได้อิสระ ขั้นแรกในนี้คือมันหา PRD เจอ ถ้า PRD ยังไม่อยู่ใน context window ของคุณ ให้ไปดึงมันมา 58 00:06:42,880 --> 00:06:53,320 ด้วยคำสั่งนี้ สำรวจโค้ดเบสถ้าจำเป็น แล้วก็ เดี๋ยวก่อนๆ ร่าง vertical slices (ชิ้นงานแนวตั้ง) การแบ่ง PRD 59 00:06:53,320 --> 00:07:00,400 ออกเป็นงานย่อยแต่ละอันนั้นไม่ชัดเจนเสมอไป นี่คือสิ่งที่นักพัฒนาทำกันมานานมากแล้ว ใช่ไหม? และเราพัฒนาสัญชาตญาณในการทำมันขึ้นมา ในความเห็นของ 60 00:07:00,400 --> 00:07:07,400 ผม วิธีที่ดีที่สุดคือการแบ่งมันเป็นงานที่ทำให้ unknown unknowns (สิ่งที่เราไม่รู้ว่าเราไม่รู้) ปรากฏออกมาเร็วมาก ตัวอย่างเช่น ถ้าคุณกำลัง integrate กับ 61 00:07:07,400 --> 00:07:14,600 บริการชนิดใหม่ หรือเชื่อมสองสิ่งที่ไม่เคยเชื่อมกันมาก่อน คุณควรทำงานนั้นก่อน เพราะมันจะให้ข้อมูลป้อนกลับ 62 00:07:14,600 --> 00:07:21,440 ว่าวิธีการของคุณใช้ได้จริงหรือไม่ คำอุปมาที่ถูกต้องตรงนี้คือ tracer bullet (กระสุนส่องวิถี) ผมจะไม่ลงรายละเอียดว่ามันหมายถึงอะไร แต่โดยพื้นฐานแล้วแต่ละ 63 00:07:21,440 --> 00:07:29,680 issue คือชิ้นแนวตั้งบางๆ ที่ตัดทะลุทุกชั้นของการ integration ไม่ใช่ชิ้นแนวนอนของชั้นใดชั้นหนึ่ง ในบทสนทนา มันแบ่ง 64 00:07:29,680 --> 00:07:32,320 PRD ที่ซับซ้อนมากนั้นออกเป็นแค่สี่ชิ้น 65 00:07:32,320 --> 00:07:39,000 มันสร้างเอนจินขึ้นมาก่อน พร้อมกับเทสต์บางอย่างที่ใช้กับมัน นี่ถือเป็น vertical slice ที่ดีมากจริงๆ เพราะนี่คือเอนจินที่ 66 00:07:39,000 --> 00:07:46,440 จะขับเคลื่อนส่วนที่เหลือของโครงสร้าง ถ้าเอนจินนี้ไม่ทำงานไม่ว่าด้วยเหตุผลใด หรือมันไม่สามารถทำได้ เราก็ต้องค้นพบ 67 00:07:46,440 --> 00:07:54,880 สิ่งนั้นให้เร็ว และนี่คือสิ่งที่การแบ่งแบบนี้ทำ PRD to Issues ยังสร้างความสัมพันธ์แบบ blocking (การบล็อก/กีดขวาง) ระหว่างงานต่างๆ ตัวอย่างเช่น งาน 68 00:07:54,880 --> 00:08:02,440 หมายเลขสองตรงนี้ไม่ได้ถูกบล็อกโดยอะไรเลย ดังนั้นมันสามารถถูกหยิบไปทำได้อิสระจากงานหนึ่ง นี่มีประโยชน์มากถ้าคุณมีระบบเอเจนต์แบบขนาน 69 00:08:02,440 --> 00:08:10,040 ที่คุณสามารถยิงเอเจนต์สองตัวไปทำงานพร้อมกันได้ เช่นใน background tasks (งานเบื้องหลัง) และมันยังหมายความว่าในอนาคตคุณสามารถเพิ่ม 70 00:08:10,040 --> 00:08:17,200 issue อื่นๆ เข้าไปได้ เช่น issue ด้าน QA (ประกันคุณภาพ) ที่คุณพบ หรือสิ่งที่ต้องปรับปรุง แล้วคุณก็สร้างความสัมพันธ์แบบ blocking ระหว่างมันกับ 71 00:08:17,200 --> 00:08:25,040 สิ่งอื่นๆ ทั้งหมด เราจะเห็นว่างานหมายเลขสามถูกบล็อกโดยงานหนึ่ง (เอนจินการแก้ไข) และงานหมายเลขสี่ (การสลับ Monaco editor) ถูกบล็อกโดย 72 00:08:25,040 --> 00:08:33,039 งานหมายเลขสอง ผมเลยตอบรับทั้งหมด แล้วมันก็สร้าง GitHub issues เหล่านี้ทั้งหมดขึ้นมา issue เหล่านี้อ้างอิงถึง PRD หลัก เพื่อให้ 73 00:08:33,039 --> 00:08:41,560 local agent (เอเจนต์ในเครื่อง) สามารถไปดึงมันมาดูได้ และมันก็แยกย่อยว่าต้องสร้างอะไรบ้าง และที่สำคัญคือ มันอ้างอิง user stories ก่อนหน้าใน PRD เราสามารถ 74 00:08:41,560 --> 00:08:48,960 เห็นคอมเมนต์จาก Claude Code ที่ลงมือ implement สิ่งนี้จริงๆ เขาพูดว่า "เอนจินแก้ไขเอกสารแบบ pure function (ฟังก์ชันบริสุทธิ์) พร้อมเทสต์ 28 ตัวครอบคลุม 75 00:08:48,960 --> 00:08:54,960 เกณฑ์การยอมรับทั้งหมด" แล้วเราก็สามารถดูคอมมิตที่อ้างอิงถึง issue นี้ได้ นี่คือ Ralph Loop ของผมที่เข้ามาแล้ว 76 00:08:54,960 --> 00:09:02,920 implement สิ่งนี้ตาม issue คอมเมนต์ ปิด issue และจากนั้น issue ถัดไปก็ถูกปลดบล็อก เท่าที่ผ่านมา สกิล Grill Me ช่วยให้คุณ 77 00:09:02,920 --> 00:09:12,880 ขัดเกลาไอเดียให้สมบูรณ์ สกิล Write a PRD ช่วยให้คุณนำไอเดียไปเปลี่ยนเป็นเอกสาร แล้วสกิล PRD to Issues ก็ช่วยให้คุณเปลี่ยน 78 00:09:12,880 --> 00:09:21,120 เอกสารจุดหมายปลายทางนั้นให้เป็นเส้นทางการเดินทางจริง แต่แล้ว คุณจะลงมือ execute (ปฏิบัติ) กับสกิลนั้นได้ยังไง? จะทำให้ 79 00:09:21,120 --> 00:09:30,520 การ implement แข็งแรงจริงจังและเพิ่มคุณภาพโค้ดที่ผลิตออกมาได้ยังไง? เรามีสกิล TDD TDD ย่อมาจาก test-driven development (การพัฒนาที่ขับเคลื่อนด้วยเทสต์) 80 00:09:30,520 --> 00:09:40,240 และเมื่อคุณเรียกใช้สกิลนี้ มันจะบังคับให้เอเจนต์ หรือพูดให้ถูกคือสนับสนุนให้เอเจนต์ ทำตามวงจร red-green-refactor (แดง-เขียว-รีแฟกเตอร์) 81 00:09:40,240 --> 00:09:46,680 ผิดปกติสำหรับสกิลของผม ตรงนี้มีเนื้อหาเยอะมากจริงๆ มันไม่ใช่แค่ตัวสกิล แต่ยังรวมถึงแนวคิดเรื่องการ refactor (ปรับโครงสร้างโค้ด) การ mocking (การจำลอง) 82 00:09:46,680 --> 00:09:54,560 และ deep modules (โมดูลลึก) คืออะไร การทำ TDD ที่ดีจริงๆ เป็นวิธีที่สม่ำเสมอที่สุดที่ผมใช้ปรับปรุงผลลัพธ์ของเอเจนต์ มาดูกันว่าข้างในมีอะไรบ้าง 83 00:09:54,560 --> 00:10:01,480 สิ่งที่เราเห็นได้คือ ผมจะข้ามเนื้อหาปรัชญาไปก่อน ให้คุณไปอ่านเอาเอง เราจะดูที่เวิร์กโฟลว์นี้เป็นหลัก ใช่แล้ว อันแรกตรงนี้ 84 00:10:01,480 --> 00:10:06,280 สำคัญมาก "ยืนยันกับผู้ใช้ว่าต้องเปลี่ยน interface (ส่วนติดต่อ) อะไรบ้าง" 85 00:10:06,280 --> 00:10:13,360 ผมเพิ่งทำวิดีโอเรื่อง interfaces และ implementations เมื่อไม่นานนี้ แต่ขอสรุปสั้นๆ ให้ฟัง เมื่อ AI มองดูโค้ดเบสที่ไม่ดี มันจะมอง 86 00:10:13,360 --> 00:10:20,080 หรือมันจะเห็นอะไรแบบนี้ ที่มีโมดูลเล็กๆ มากมายตรงนี้ที่แยกแยะไม่ออก 87 00:10:20,080 --> 00:10:26,600 มันไม่ได้ถูกจัดกลุ่มเข้าด้วยกันจริงๆ มันไม่ค่อยเข้าใจว่าสิ่งเหล่านี้สัมพันธ์กันยังไง และมันก็ต้องทำงานเยอะเพื่อคิดให้ออกว่า โอเค 88 00:10:26,600 --> 00:10:31,600 อะไรรับผิดชอบอะไร? ความสัมพันธ์เชิงพึ่งพาคืออะไร? โค้ดเบสนี้ทำงานยังไงกันแน่? 89 00:10:31,600 --> 00:10:40,320 ในขณะที่ ถ้าคุณปรับโครงสร้างมันเป็นโมดูลใหญ่ๆ หลายตัว โดยมี interface บางๆ วางอยู่ด้านบน interface คือฟังก์ชันที่ 90 00:10:40,320 --> 00:10:48,560 ถูก export ออกมาจากโมดูล สิ่งที่ผู้เรียกใช้ (callers) เรียกจริงๆ แล้วมันจะง่ายกว่ามากสำหรับ AI ในการนำทางโค้ดเบสนี้ และง่ายกว่ามากในการคิดออก 91 00:10:48,560 --> 00:10:55,320 ว่าจะเทสต์โมดูลเหล่านี้ยังไง เพราะคุณแค่เทสต์มันที่ interfaces คุณเทสต์มันที่ขอบเขต คุณสามารถดูวิดีโอเต็มเกี่ยวกับเรื่องนี้ได้ที่ด้านล่าง 92 00:10:55,320 --> 00:11:04,480 สิ่งที่สกิล TDD นี้พยายามส่งเสริมตรงนี้ก็คือ ทำให้การเปลี่ยน interface เหล่านี้เป็นเรื่องที่ AI ให้ความสำคัญสูงสุด เพื่อให้มันเข้าใจว่า 93 00:11:04,480 --> 00:11:11,800 เมื่อมันเปลี่ยน interface นั่นคือการตัดสินใจสำคัญที่มันต้องใช้เวลาคิด คุณยืนยันกับผู้ใช้ว่าจะเทสต์พฤติกรรมใดบ้าง คุณออกแบบ 94 00:11:11,800 --> 00:11:20,040 interfaces เพื่อให้เทสต์ได้ง่าย เชื่อมโยงกับเอกสาร แล้วเราก็มีเนื้อหาเพิ่มเติมเกี่ยวกับการวางแผนตรงนี้ จากนั้นมันเข้าสู่วงจรที่สวยงาม โดยมันเขียนเทสต์ทีละ 95 00:11:20,040 --> 00:11:22,720 อัน และมันเขียนเทสต์ก่อน 96 00:11:22,720 --> 00:11:29,440 ผมเคยพูดถึง red-green-refactor มาก่อน ดังนั้นจะแปะลิงก์วิดีโอไว้ด้านล่างถ้าสนใจ แต่ผมพบว่า red-green-refactor กับเอเจนต์ 97 00:11:29,440 --> 00:11:37,160 นั้นเหลือเชื่อมาก และโดยพื้นฐานแล้วมันทำวงจรนี้จนกว่าจะเสร็จ มันแค่เขียนเทสต์ที่ล้มเหลว จากนั้นเขียนโค้ดเพื่อทำให้เทสต์นั้นผ่าน แล้วสุดท้าย มัน 98 00:11:37,160 --> 00:11:46,440 ก็ไล่ดูหาโอกาสในการ refactor ผมยังไม่พบว่าอันนี้จะดีเลิศ มันยังไม่เก่งนัก เพราะบ่อยครั้ง LLM ค่อนข้าง 99 00:11:46,440 --> 00:11:53,200 คุณรู้ไหม พวกมันค่อนข้างไม่เต็มใจที่จะ refactor โค้ดของตัวเอง ถ้าคุณล้าง context ของ LLM มันก็จะลบความทรงจำของตัวเอง 100 00:11:53,200 --> 00:11:56,000 และมันจะไม่หวงแหนโค้ดที่มันเพิ่งเขียนไปมากนัก 101 00:11:56,000 --> 00:12:03,960 แต่ในขณะที่โค้ดของมันเองยังอยู่ใน context window ของมัน มันก็ค่อนข้างไม่เต็มใจที่จะเปลี่ยนมัน ดังนั้นสกิล TDD นี้คือสิ่งที่ผมใช้เป็นพรอมต์ให้ Ralph loops ของผม 102 00:12:03,960 --> 00:12:13,480 เพื่อให้พวกมันทำ red-green-refactor ทีนี้ TDD ต้องการอะไรจากคุณมาก หรือพูดให้ถูกคือมันต้องการจากโค้ดเบสของคุณมาก TDD ทำได้ยากมากในโค้ดเบสที่ 103 00:12:13,480 --> 00:12:21,000 โครงสร้างไม่ดี เพราะขอบเขตการเทสต์ของมันไม่ชัดเจนเลย มันควรเทสต์โมดูลเหล่านี้แยกกันไหม? มันควรเทสต์โมดูลเหล่านี้ 104 00:12:21,000 --> 00:12:22,960 แยกกันไหม? ขอบเขตตรงนี้คืออะไร? 105 00:12:22,960 --> 00:12:29,440 ในขณะที่เมื่อโค้ดเบสของคุณหน้าตาแบบนี้ มันก็ง่ายกว่ามากที่จะเทสต์ เพราะขอบเขตของโมดูลชัดเจนมาก แล้วมันจะไม่ดีเหรอ 106 00:12:29,440 --> 00:12:36,440 ถ้ามีอะไรที่ทำให้โค้ดเบสของคุณหน้าตาแบบนี้ล่ะ? ดีไหมล่ะ เรามีสกิล improved code base architecture (ปรับปรุงสถาปัตยกรรมโค้ดเบส) 107 00:12:36,440 --> 00:12:44,600 กระบวนการของสกิลนี้คือ เราสำรวจโค้ดเบส และสำรวจแบบธรรมชาติเหมือนที่เอเจนต์ทั่วไปทำ เราพยายามหาจุดที่ทำให้สับสน 108 00:12:44,600 --> 00:12:53,000 เราไม่ได้แบบว่า เราพยายามเผยสิ่งที่ AI พบว่าสับสนโดยธรรมชาติ เพื่อที่มันจะได้ช่วยเหลือมันได้ทีหลัง โค้ดตรงไหนที่ 109 00:12:53,000 --> 00:12:59,960 การเข้าใจแนวคิดหนึ่งต้องเด้งไปมาระหว่างไฟล์เล็กๆ หลายไฟล์? ตรงไหนที่มีการแยก pure functions ออกมาแค่เพื่อให้เทสต์ได้ แต่ 110 00:12:59,960 --> 00:13:01,880 บั๊กจริงๆ ซ่อนอยู่ในวิธีการเรียกใช้มัน? 111 00:13:01,880 --> 00:13:09,360 ตรงไหนที่โมดูลที่ผูกกันแน่น (tightly coupled) สร้างความเสี่ยงในการ integration ตรงรอยต่อระหว่างมัน? ทั้งหมดนี้คือคำถามที่วิศวกรอาวุโสจะถามเกี่ยวกับ 112 00:13:09,360 --> 00:13:18,440 โค้ดเบสของคุณ ขั้นตอนที่สองคือคุณนำเสนอตัวเลือก คุณนำเสนอรายการตัวเลขของ deepening opportunities (โอกาสในการทำให้ลึกขึ้น) พูดอีกอย่างคือโอกาสในการทำให้โมดูลตื้น 113 00:13:18,440 --> 00:13:27,800 ในโค้ดเบสของคุณลึกขึ้น ผู้ใช้เลือกตัวเลือกหนึ่ง แล้วคุณก็ออกแบบ interfaces หลายแบบ มันบอกว่าให้สร้าง subagents สามตัว 114 00:13:27,800 --> 00:13:35,600 ทำงานแบบขนาน โดยแต่ละตัวต้องผลิต interface ที่แตกต่างกันอย่างสิ้นเชิงสำหรับโมดูลที่จะทำให้ลึก พูดอีกอย่างคือ เรากำลังแยกโค้ดนั้นออกมาและออกแบบ 115 00:13:35,600 --> 00:13:42,520 ความเป็นไปได้ว่ามันจะหน้าตาแบบไหนในอนาคต การออกแบบมันหลายๆ แบบที่แตกต่างกัน เป็นวิธีที่ดีมากที่ทำให้คุณตัดสินใจเลือก 116 00:13:42,520 --> 00:13:49,000 ไอเดียที่ถูกต้องได้ ผมเคยเห็นเอเจนต์นี้สร้าง subagents ห้าตัวสำหรับการ refactor ครั้งใหญ่ สิ่งที่เจ๋งที่สุดคือคุณไม่จำเป็นต้องรู้มาก 117 00:13:49,000 --> 00:13:56,440 เกี่ยวกับการออกแบบ interface เพื่อให้สิ่งนี้ทำงาน หลังจากเปรียบเทียบแล้ว ให้คำแนะนำของคุณว่าคุณคิดว่าการออกแบบแบบไหนแข็งแกร่งที่สุดและเพราะอะไร และถ้าองค์ประกอบ 118 00:13:56,440 --> 00:14:04,400 จากการออกแบบต่างกันเข้ากันได้ดี ก็เสนอแบบลูกผสม (hybrid) สังเกตว่าผมทำให้สกิลนี้ไม่ผูกกับภาษาใดภาษาโดยเฉพาะ 119 00:14:04,400 --> 00:14:09,840 ไม่ผูกกับอะไรเลยจริงๆ คุณสามารถรันมันในโค้ดเบสใดก็ได้ แล้วได้คำตอบที่ดีว่ามันจะปรับปรุงได้ยังไง 120 00:14:09,840 --> 00:14:17,520 อาจมีตัวเลือกสี่ห้าตัวที่ควรปรับปรุงจริงๆ แต่ผมคิดว่าคุณควรทำทีละอันเท่านั้น เพราะ 121 00:14:17,520 --> 00:14:25,800 มันค่อนข้างยากที่จะทำความเข้าใจ และมันต้องมีมนุษย์อยู่ในวงจร (human in the loop) นั่งอยู่กับมันเพื่อปรับปรุงโค้ดเบส เพราะการตัดสินใจเหล่านี้ 122 00:14:25,800 --> 00:14:34,640 ต้องใช้รสนิยม สุดท้าย มันสร้าง GitHub issue มันสร้าง refactor RFC เป็น GitHub issue โดยใช้ GH issue create โดยปกติ เมื่อเสร็จสิ้น ผม 123 00:14:34,640 --> 00:14:41,880 จะใช้สกิล PRD to Issues ของผม อ้างอิง GitHub issue ที่เพิ่งถูกสร้างขึ้น และให้มัน คุณรู้ไหม นี่อธิบาย 124 00:14:41,880 --> 00:14:49,839 จุดหมายปลายทาง เราจึงต้องมีเส้นทางเพื่อไปให้ถึง ดังนั้น แค่ทำแบบนี้เป็นครั้งคราวในโค้ดเบส สัปดาห์ละครั้งเพื่อหาโอกาส หรือ 125 00:14:49,839 --> 00:14:59,200 ถ้าคุณมีการพัฒนาที่พุ่งพรวดขึ้นมา และคุณสร้างฟีเจอร์เพิ่มอีกปีกใหญ่ สกิลนี้จะมีประโยชน์มากจริงๆ ในการทำให้แน่ใจว่ามัน 126 00:14:59,200 --> 00:15:03,600 สอดคล้องกับโค้ดเบสที่เหลือ ทำให้แน่ใจว่ามันไม่ได้เละเทะเกินไป 127 00:15:03,600 --> 00:15:10,200 และเมื่อคุณรันมันต่อไปเรื่อยๆ เมื่อคุณปรับปรุงโค้ดเบสของคุณอย่างต่อเนื่อง คุณจะสังเกตว่าคุณภาพของผลลัพธ์ของเอเจนต์สูงขึ้น เพราะคำพูดเก่าๆ 128 00:15:10,200 --> 00:15:15,839 นั้นใช้ได้จริง ถ้าคุณมีโค้ดเบสที่แย่ AI ก็จะผลิตของแย่ๆ ออกมาในโค้ดเบสนั้น 129 00:15:15,839 --> 00:15:24,040 เพราะพูดตามตรง ถ้าคุณเอาสกิลทั้งหมดนี้มาแล้วพูดว่า "โอเค นี่เหมือนหนังสือ markdown เล็กๆ เกี่ยวกับกระบวนการสำหรับมนุษย์" มันก็ 130 00:15:24,040 --> 00:15:32,200 ไม่ดูแปลกที่ใด ผมพบว่าวิธีที่ประสบความสำเร็จที่สุดในการเพิ่มคุณภาพโค้ดจากเอเจนต์คือปฏิบัติต่อพวกมันเหมือนมนุษย์ มนุษย์ที่มีข้อจำกัดแปลกๆ 131 00:15:32,200 --> 00:15:39,760 แน่นอน มนุษย์ที่ไม่มีหน่วยความจำและถูกโคลน ออกมาจากฝักให้กำเนิดแล้วไปทำงานทันที แต่ถ้าคุณคิดเหมือนผมว่า 132 00:15:39,760 --> 00:15:44,080 ทักษะวิศวกรรมจริงจังเหล่านี้สำคัญมาก คอร์สนี้เหมาะสำหรับคุณอย่างแน่นอน 133 00:15:44,080 --> 00:15:50,920 สิ่งที่ผมสังเกตเห็นระหว่างสร้างคอร์สคือ ผมไม่ได้สอน Claude Code มากขนาดนั้นจริงๆ ผมสอนเกี่ยวกับ sub agents ของเรา ผมพูดถึง 134 00:15:50,920 --> 00:15:58,200 ข้อจำกัดของ LLM เรื่องโซนฉลาด-โซนโง่แปลกๆ กับ context window เราพูดถึงการบังคับทิศทาง (steering) ซึ่งโดยพื้นฐานแล้ว 135 00:15:58,200 --> 00:16:06,520 ก็เป็นวิธีการจัดเก็บเอกสารภายในโค้ดเบสของคุณ วิธีจัดการงานใหญ่โต การเข้าใจ tracer bullets และสร้างมันเข้าไปในสกิลของเรา 136 00:16:06,520 --> 00:16:13,920 การเข้าใจวิธีสร้าง feedback loops (วงจรข้อมูลป้อนกลับ) ที่ดีจริงๆ และทำแบบฝึกหัดกับมัน และที่สำคัญคือวิธีเชื่อมต่อสิ่งเหล่านี้เข้ากับเอเจนต์อัตโนมัติ ทุกส่วนของ 137 00:16:13,920 --> 00:16:21,440 คอร์สนี้เชื่อมโยงไปยังส่วนถัดไป และผมมีความสุขมากกับผลลัพธ์ ดังนั้น ในช่วง 2 สัปดาห์ คุณจะได้ทำงานผ่าน 138 00:16:21,440 --> 00:16:28,640 เนื้อหาที่เรียนด้วยตัวเองนี้ โดยมีผมเป็นไกด์ใน Discord และใน office hours (ชั่วโมงปรึกษา) สด และถ้าฟังดูสนุกสำหรับคุณ ลิงก์อยู่ด้านล่าง ขอบคุณที่ 139 00:16:28,640 --> 00:16:34,400 รับชมครับทุกคน ผมจะกลับมาพร้อมเนื้อหาอีกมากในสัปดาห์นี้ อยากให้ผมทำอะไรต่อไป? ผมพบว่าจุดตัดระหว่าง 140 00:16:34,400 --> 00:16:43,240 วิศวกรรมจริงจังกับ AI นี้เป็นจุดที่ยอดเยี่ยมมากในการทำคอนเทนต์ แต่ยังไงก็ตาม ขอบคุณที่รับชม แล้วเจอกันในวิดีโอหน้า