วิธีทำงานโปรเจกต์ Laravel ร่วมกับ AI agent แบบที่ผมใช้ทุกวัน (ปี 2569)

ปกติเรามักเริ่มใช้ AI กับงานโค้ดจากการถาม ChatGPT หรือ Claude ในแชท แล้ว copy โค้ดมาวางในโปรเจกต์ ผมก็เริ่มแบบนั้น ช่วงแรกเขียนบน Windows ผ่าน WSL2 ก่อนจะย้ายมาเขียนบน Mac ทั้งหมด

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

agent ต่างจากแชทตรงที่เห็นโปรเจกต์ทั้งหมด#

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

AI agent อย่าง Claude Code, Codex หรือโหมด agent ของ Cursor ทำงานในโฟลเดอร์ของโปรเจกต์ อ่านไฟล์ได้เอง รันคำสั่งได้ รัน test แล้วแก้ต่อจากผลได้ งานเลยเปลี่ยนจาก "ถามแล้วเอาไปวาง" เป็น "บอกว่าอยากได้อะไร แล้วดูผล"

ผมใช้ Claude Code เป็นหลัก ใช้ได้ตั้งแต่แพ็กเกจ Pro เดือนละ 20 ดอลลาร์ ถ้าใช้ทั้งวันจะชนโควตาเร็ว ต้องขยับไปแพ็กเกจ Max ที่เริ่มเดือนละ 100 ดอลลาร์

ร่องรอยที่เก่าที่สุดที่ยังเหลือในโปรเจกต์ของผมคือไฟล์ตั้งค่า MCP ที่ commit ไว้ช่วงธันวาคม 2568 เดือนถัดมา Laravel Boost สร้าง CLAUDE.md ให้โปรเจกต์ แล้วผมก็เริ่มเขียนสรุปโครงสร้างโปรเจกต์ให้ agent อ่านเอง จากตรงนั้นทุกอย่างค่อย ๆ โตขึ้น

Claude Desktop ใช้แทน IDE ได้เกือบหมด#

ช่วงที่ยังเขียนบน WSL2 ผมใช้ Claude Code ใน terminal ซึ่งตอนนั้นแสดงภาษาไทยเพี้ยนจนอ่านไม่ออก เลยต้องให้ agent ตอบเป็นภาษาอังกฤษ หลัง ๆ แอป Claude Desktop พัฒนาขึ้นมาก คุยภาษาไทยได้ปกติ เห็น diff ไฟล์ และ terminal ในหน้าต่างเดียว จนตอนนี้ผมแทบไม่ได้เปิด IDE แล้ว

ส่วนที่ยังคิดถึงจาก IDE ผมทำเครื่องมือเล็ก ๆ ใน terminal มาแทน

• g เปิดหน้าต่าง branch แบบของ PHPStorm สลับ branch, commit, merge, push และดู diff ทีละไฟล์ได้จากกล่องเดียว (git-prompt)
• rh เข้าเซิร์ฟเวอร์ ดูไฟล์ และอัปโหลด แบบหน้าต่าง Deployment ของ PHPStorm (remote-prompt)
• lwt ตั้งโปรเจกต์ Laravel ใน git worktree ให้รันได้ในคำสั่งเดียว (worktree-prompt)
• cc alias ที่ stage ไฟล์ทั้งหมด ให้ Claude อ่าน diff แล้วเขียน commit message เป็นภาษาไทย แล้ว commit ให้ ส่วน ccp push ต่อให้ด้วย

workflow ของผมโตขึ้นเป็นสี่ชั้น#

agent อยู่ตรงกลาง แต่ละชั้นแก้ปัญหาที่เจอเมื่อให้ agent ทำงานจริงไปสักพัก

• ความรู้ของโปรเจกต์ agent เริ่มทุก session จากศูนย์ ไม่จำว่าเมื่อวานคุยอะไรกัน ข้อตกลงของโปรเจกต์ เหตุผลของการออกแบบ และขั้นตอนที่ทำซ้ำบ่อยจึงต้องเขียนไว้ในไฟล์ที่ agent อ่านได้
• วงจรงาน งานชิ้นเล็กสั่งประโยคเดียวก็จบ งานที่ยาวข้ามหลาย session ต้องมีที่จดว่าตกลงอะไรไว้และทำถึงไหนแล้ว
• รั้ว guideline เป็นแค่คำแนะนำ agent ทำตามเกือบทุกครั้ง แต่ไม่ทุกครั้ง เรื่องที่พลาดแล้วเสียหายต้องกันด้วย test, hook, CI และสิทธิ์ที่ให้ไม่ถึง
• งานที่ไม่ใช่โค้ด เอกสารของระบบ คู่มือแอดมิน สรุปเหตุการณ์ให้ลูกค้า และบทความในเว็บนี้ ก็ใช้วิธีเดียวกัน

วิธีทำงานก็เก็บใน git เหมือนโค้ด#

ขั้นตอนที่ต้องสั่ง agent ซ้ำ ๆ ผมเขียนเป็น skill คือไฟล์ markdown ที่บอกว่างานแบบนี้ทำยังไง agent เปิดอ่านเองเมื่องานตรงกับคำอธิบายของ skill เช่น skill task สำหรับจดงานและวางแผน หรือ skill testing ที่บอกว่าโปรเจกต์ของผมจัดฐานข้อมูลสำหรับ test แบบไหน

skill ทั่วไปที่ใช้ทุกโปรเจกต์อยู่ใน repo ของผมเองที่ sync ไปทุกเครื่อง ส่วน skill ที่ผูกกับโปรเจกต์ไหนก็ commit ไว้ในโปรเจกต์นั้น repo แรกเริ่มเมื่อ 15 กุมภาพันธ์ 2569 มีอยู่สามสี่ skill ตอนนี้มีราว 25 skill และแก้มาแล้ว 277 ครั้ง

เก็บใน git แล้วได้สองอย่าง อย่างแรกคือย้อนดูได้ว่าเปลี่ยนอะไรเพราะอะไร อย่างที่สองคือ agent แก้ skill เองได้ เวลาเจอบทเรียนใหม่ระหว่างทำงาน ผมให้ agent เขียนกลับเข้า skill ทันที รอบหน้าจะได้ไม่พลาดซ้ำ

การตัดสินใจยังเป็นงานของผม#

งานส่วนใหญ่ตอนนี้ agent เขียนทั้งโค้ดและ test ส่วนที่ผมทำคือ

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

ผมไม่ได้อ่านโค้ดทุกบรรทัดที่ agent เขียน ส่วนที่ทำให้วางใจได้คือรั้วที่ตั้งไว้กับการลองใช้งานจริง แนวนี้ใกล้กับที่ Jason McCreary เล่าไว้ในสี่ขั้นที่เขาค่อย ๆ ปล่อยงานให้ AI agent

workflow ที่คนอื่นใช้ก็มีหลายอย่างคล้ายกัน#

ถ้าค้นเรื่องนี้ จะเจอชุด skill ที่คนนิยมใช้อยู่สองชุด ทั้งสองชุดมีดาวบน GitHub มากกว่าสามแสน

• Superpowers ของ Jesse Vincent ให้ agent ถามจนได้ spec ก่อน แล้วเขียนแผนที่ละเอียดพอให้คนไม่รู้จักโปรเจกต์ทำตามได้ จากนั้นแบ่งงานให้ subagent ทำทีละชิ้นแบบ TDD
• Skills For Real Engineers ของ Matt Pocock จาก AI Hero เป็น skill เล็ก ๆ หยิบใช้ทีละตัว ตัวที่คนใช้มากที่สุดคือ /grill-me ที่ให้ agent ซักเราก่อนเริ่มงาน

workflow ของผมโตมาจากงานที่ทำ ไม่ได้ทำตามชุดไหน แต่หลายอย่างลงเอยคล้ายกัน ทั้งให้ agent ถามก่อนวางแผน เขียนแผนลงไฟล์ ทำทีละชิ้นที่ตรวจได้ และแยก session ให้ทำงานคู่ขนาน ส่วนที่ต่างคือของผมผูกกับ Laravel และวิธีที่ผมดูแลเซิร์ฟเวอร์เอง

Matt Pocock เองก็เขียนไว้ว่าเครื่องมือที่ครอบกระบวนการทั้งหมดไว้มักทำให้เราคุมงานไม่ได้ ถ้าเพิ่งเริ่ม ผมว่าลองชุดของคนอื่นเพื่อดู pattern ก่อนก็ดี แล้วค่อยเก็บเฉพาะส่วนที่เข้ากับงานของเราไว้

สิ่งที่ผมลองแล้วเลิก#

workflow หดลงบ่อยพอ ๆ กับที่โตขึ้น ตัวอย่างที่ลบออกไปแล้ว

• กฎให้ agent ตอบเป็นภาษาอังกฤษ ตั้งไว้ตอนที่ terminal บน WSL2 แสดงภาษาไทยไม่ได้ พอย้ายมาคุยใน Claude Desktop ที่ใช้ภาษาไทยได้ปกติ กฎนี้ก็หมดหน้าที่ ลบออกพร้อมข้อยกเว้นที่ไปโผล่ใน skill อื่นอีกหกตัว
• ขั้นวางแผนที่แบ่งละเอียดเกินไป ช่วงหนึ่งผมแยก brainstorm, spec, plan, implement และ review เป็นคนละ skill แล้วค่อย ๆ ยุบจนเหลือ plan กับ implement ผมตัดขั้น review แยกทิ้ง เพราะ test กับการที่ผมลองใช้เองทำหน้าที่นั้นอยู่แล้ว
• skill ต่อ IDE ผ่าน MCP ยาวเกือบ 400 บรรทัด พอแทบไม่ได้เปิด IDE แล้ว skill นี้ก็ไม่มีงานให้ทำ
• ทาง WSL2 ใน skill ติดตั้งโปรเจกต์ พอย้ายมา Mac ทั้งหมด การลบทาง Windows ทิ้งทำให้ skill หายไปกว่า 600 บรรทัด

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