วิธีทำงานร่วมกับ AI และเติบโตแบบทบต้นไปด้วยกัน

• คู่มือเชิงปฏิบัติที่สรุปหลักการ 5 ข้อสำหรับการทำงานร่วมกับ AI อย่างเป็นระบบ ได้แก่ การให้คอนเท็กซ์, การตั้งค่าความชอบ, การทำให้การตรวจสอบเป็นอัตโนมัติ, การขยายการมอบหมายงาน, และวงจรป้อนกลับ
• ผลลัพธ์จากงานทุกชิ้น (โค้ด, เอกสาร, การวิเคราะห์, การตัดสินใจ) จะถูก สะสมเป็นคอนเท็กซ์ สำหรับเซสชันถัดไป และสิ่งที่แก้ไขจะถูกสะท้อนกลับไปยังการตั้งค่า เพื่อลดข้อผิดพลาดในอนาคตแบบทบต้น
• นำเสนอวิธีที่เป็นรูปธรรมในการใช้ CLAUDE.md, ไฟล์สกิล, ไกด์ ฯลฯ เพื่อ จัดการพฤติกรรมของโมเดลและเวิร์กโฟลว์เหมือนจัดการโค้ด
• มีทั้งกลยุทธ์การมอบหมายงานเพื่อขยายปริมาณงาน เช่น การรันหลายเซสชันแบบขนาน การตรวจสอบไขว้ระหว่างโมเดล และ การควบคุมระยะไกล
• หลักการเหล่านี้ไม่ได้ใช้ได้เฉพาะกับ AI แต่ยังเป็นเฟรมเวิร์กทั่วไปที่ ใช้ได้เหมือนกันกับการทำงานร่วมกันในทีมมนุษย์

---

สร้างคอนเท็กซ์ให้เป็นโครงสร้างพื้นฐาน

• หากจัดเก็บโค้ดทั้งหมดไว้ใน ~/src และงานสายความรู้ไว้ใน ~/vault (projects/, notes/, kb/ ฯลฯ) โมเดลจะ ค้นหาคอนเท็กซ์ด้วย grep หรือ glob ได้ง่ายขึ้น
• สามารถเชื่อมคอนเท็กซ์ขององค์กร (Slack, Drive, Mail ฯลฯ) เข้ากับโมเดลผ่าน MCP (Model Context Protocol) ได้
  • ดูแล INDEX.md แยกตามโปรเจกต์ และบันทึก URL, ผู้รับผิดชอบ, คำอธิบายเนื้อหาเป็น คอมเมนต์ ในแต่ละรายการ
  • ถ้ามีแค่รายการ URL โมเดลจะต้องเปิดทุกลิงก์ดูเอง ดังนั้นการใส่คอมเมนต์จะช่วย ป้องกันการสิ้นเปลืองคอนเท็กซ์
• เนื่องจากในทุกเซสชันใหม่ โมเดลจะเริ่มจากสถานะว่างเปล่า จึงควรเขียน CLAUDE.md แยกตามโปรเจกต์ เหมือนเอกสาร onboarding สำหรับพนักงานใหม่
  • รวมพจนานุกรมคำย่อ, codename ของโปรเจกต์, วิธีแยกคนชื่อซ้ำ ฯลฯ
  • กำหนด ลำดับการอ่าน เป็น INDEX.md → TODOS.md → โน้ตหัวข้อเฉพาะ
• แยกการทำงานของเมมโมรีออกเป็นสองเลเยอร์
  • ~/vault: เก็บ ข้อมูลข้อเท็จจริง (facts) เช่น สถานะโปรเจกต์ ผลลัพธ์งาน และความรู้โดเมน
  • ~/.claude (CLAUDE.md, skills/, guides/): เก็บ การตั้งค่า (configuration) เช่น ความชอบ เวิร์กโฟลว์ และรสนิยมส่วนตัว

เข้ารหัสความชอบให้เป็นการตั้งค่า

• ใช้ ~/.claude/CLAUDE.md

  • ทำหน้าที่เป็น ข้อตกลงพฤติกรรม ที่ Claude จะอ่านทุกครั้งเมื่อเริ่มเซสชัน
  • รวม กฎพฤติกรรม เช่น พูดตรงไปตรงมา, โต้แย้งเมื่อไม่เห็นด้วย, ซื่อสัตย์เมื่อไม่แน่ใจ, หากล้มเหลวให้หาสาเหตุรากแล้วลองใหม่, ห้ามรีฟอร์แมตนอกขอบเขตงาน
  • ยังตั้งค่า ส่วนสอน (teaching) ได้ เพื่ออธิบายคำสำคัญของระบบหรือโดเมนใหม่ ๆ เป็น 1–2 ประโยคเมื่อมีการกล่าวถึง

• แยกขอบเขตตามไดเรกทอรี

  • Global (~/.claude/CLAUDE.md): การตั้งค่าที่ใช้ได้ทุกที่ เช่น พฤติกรรม เป้าหมายระยะยาว และความชอบด้านการเรียนรู้
  • Repo root: กฎเฉพาะรีโป เช่น linting, naming, PR convention
  • Project directory: คอนเท็กซ์เฉพาะโปรเจกต์ เช่น โครงสร้างไดเรกทอรีและความรู้โดเมน
  • เมื่อ Claude Code เริ่มจากไดเรกทอรีย่อย มันจะ ไล่ขึ้นตาม tree และโหลด CLAUDE.md แต่ละระดับ

• กลยุทธ์แยกไฟล์เมื่อ CLAUDE.md ยาวเกินไป

  • CLAUDE.md ที่ยาวจะกลายเป็น ภาษีคอนเท็กซ์ เพราะต้องโหลดทั้งหมดในทุกเซสชัน
  • แทนที่จะใช้ @import ให้ระบุแค่ พาธของไฟล์ไกด์ในลักษณะ “อ่านเมื่อเกี่ยวข้อง” ไว้ใน CLAUDE.md เพื่อทำ lazy loading
  • เช่น ตอนเขียนเอกสารให้อ่าน ~/.claude/guides/writing.md, ตอนประเมินผลให้อ่าน ~/.claude/guides/evals.md

• งานที่ทำซ้ำอย่างน้อยสัปดาห์ละครั้งควรแปลงเป็นสกิล

  • สกิลคือ ไฟล์เวิร์กโฟลว์แบบ Markdown ที่มีชื่อ ทริกเกอร์ และขั้นตอน
  • /polish: ดู diff ของ artifact, ถ้ามี metric ให้รัน eval, ถ้าเป็นการเรนเดอร์ในเบราว์เซอร์ให้ตรวจด้วย Chrome, ถ้าไม่ใช่ให้รันโค้ดแล้วตรวจ output/error → ทำซ้ำแล้ว เขียน draft PR
  • /write: สัมภาษณ์เพื่อทำ outline → สร้าง research sub-agent → เขียน draft → รับ feedback จากนักวิจารณ์สายตรงข้าม → ทำซ้ำ
  • /daily: อ่านปฏิทิน, Slack, PR, และล็อกของวันก่อน แล้ว เขียนลำดับความสำคัญของวันนี้
  • SKILL.md ควรโฟกัสที่เวิร์กโฟลว์และการ routing ส่วนความรู้เช่น template หรือ script ให้แยกไปไฟล์อื่นเพื่อ โหลดเมื่อจำเป็นเท่านั้น

• วิธี bootstrap สกิล

  • ทำงานนั้นแบบโต้ตอบหนึ่งครั้งก่อน แล้วขอให้โมเดล สร้างเป็นสกิลให้
  • รันสกิลกับงานเดิมหรือคล้ายกัน แล้วแก้ผลลัพธ์ ภายในเซสชันเดียวกัน
  • ขอให้โมเดลอัปเดตสกิลจากการแก้ไขและ feedback
  • ยังสามารถให้ ตัวอย่างผลลัพธ์ที่ต้องการ เพื่อให้มันดึงแพตเทิร์นออกมาได้ด้วย (เช่น โครงสร้างโค้ด โครงสร้างเอกสาร และโทนภาษา)

• ปรับปรุงสกิลผ่าน transcript

  • เวอร์ชันแรกจะ overfit กับเซสชันต้นฉบับเป็นเรื่องปกติ
  • อย่าแก้ SKILL.md โดยตรง แต่ให้แก้ในเซสชัน เพื่อให้ คู่ before-and-after สะสมอยู่ใน transcript
  • เมื่อผลลัพธ์น่าพอใจแล้ว ให้ขอให้โมเดลรวม feedback เข้าสกิล → ผ่านไปหลายรอบสกิลจะ ลู่เข้าหาแบบที่ต้องการ

• ไม่ใช่ทุกงานที่ต้องใช้คอนเท็กซ์ชุดนี้

  • สำหรับการ brainstorming การสำรวจ และการร่างเบื้องต้น ให้ใช้ simple mode (CLAUDE_CODE_SIMPLE=1 claude)
  • แม้ CLAUDE.md จะยังถูกโหลด แต่ agent harness (hook, skill, tool loop) จะถูกปิด ทำให้คิดร่วมกับโมเดลได้ใกล้ชิดขึ้น

การตรวจสอบเพื่อให้อัตโนมัติได้จริง

• เลื่อนการตรวจสอบไปไว้ด้านซ้าย (shift left)

  • จัดการตรวจสอบเป็น โครงแบบบันได: ชั้นล่างราคาถูกและตัดสินได้แน่นอน ชั้นบนต้นทุนสูงและต้องใช้วิจารณญาณ
  • ชั้นล่างสุด: post-edit hook ที่รัน ruff format, ruff check --fix กับไฟล์ที่โมเดลแก้ → ตัดสินได้แน่นอนและไม่มีต้นทุนโทเค็น
  • ชั้นที่สูงขึ้น: test, eval, LLM review ฯลฯ

• จัดระบบให้โมเดลตรวจงานตัวเองได้

  • ถ้าระบบสร้าง metric ได้ โมเดลก็สามารถ รัน eval เอง เพื่อทำ optimization ได้
  • ถ้า output เป็นการเรนเดอร์ในเบราว์เซอร์ ให้ตรวจผ่าน Claude in Chrome
  • เวลาสร้าง Docker image ให้อ่าน error แล้วแก้ Dockerfile ก่อน rebuild
  • เมื่อต้องทำ dashboard ให้ ตรวจใน Chrome ว่า tooltip แสดงผลถูกต้องหรือไม่, label ซ้อนกันหรือไม่, ตัวเลขสอดคล้องกับ narrative หรือไม่

• สำหรับงานยาว ให้ใช้โมเดลเฝ้าโมเดลอีกที

  • เซสชันยาว ๆ มักมีข้อผิดพลาดสะสมและเกิด drift ได้
  • ทางแก้คือรันเซสชันที่สองด้วยคอนเท็กซ์ใหม่ แล้วให้เปรียบเทียบสเปกต้นฉบับกับเทิร์นล่าสุดของเซสชันหลัก
  • ตั้งค่า tmux สองพาเนล: อันหนึ่งสำหรับพัฒนาหลัก อีกอันเป็น pair programmer
  • เพิ่มคำสั่งตั้งต้นและพรอมป์ต์ต่อเนื่องในไฟล์ที่แชร์ร่วมกัน เพื่อให้ pair programmer เข้ามาตรวจเป็นระยะ
  • Execution drift: โมเดลกำลังทำงานถูกต้องหรือไม่ — เช่น เมิน error, รายงาน metric ผิด, หลุดจากสเปก เป็น การตรวจเชิงยุทธวิธี → ควรตรวจบ่อย
  • Direction drift: โมเดลกำลังทำงานที่ถูกต้องหรือไม่ — เช่น เข้าใจเจตนาเดิมผิดแล้วสร้างสิ่งที่ผิด เป็น ปัญหาเชิงกลยุทธ์ → ตรวจเป็นครั้งคราว

ขยายผลผ่านการมอบหมายงาน

• มอบหมายงานเป็นหน่วยที่ใหญ่ขึ้นเรื่อย ๆ

  • รูปแบบ pair programming ที่เป็นงานสั้นและ feedback เร็ว เหมาะกับการวนซ้ำเร็ว การวิเคราะห์เชิงสำรวจ และการทำต้นแบบ
  • แต่สำหรับโมเดลที่ทรงพลังกว่า ควรอธิบายเจตนา ข้อจำกัด และ เกณฑ์ความสำเร็จ ล่วงหน้า แล้วมอบหมายให้มันทำแบบ end-to-end
  • สิ่งที่ตรวจสอบไม่ได้ก็ย่อมมอบหมายไม่ได้ ดังนั้นต้อง นิยามเกณฑ์ความสำเร็จและ metric ให้ชัดก่อน
  • ตัวอย่าง: “สร้าง isolated container แยกตาม eval suite และทำ smoke test → รันเต็มชุด → บันทึก metric และ transcript → ให้ sub-agent ตรวจความถูกต้อง → ทำซ้ำ n รอบเพื่อคำนวณ ช่วงความเชื่อมั่น → สร้างรายงานแล้วส่งผลไปยัง Slack”

• รันหลายเซสชันพร้อมกันและหา bottleneck

  • เมื่อมอบหมายงานใหญ่ขึ้น ก็สามารถรัน 3–6 เซสชันแบบขนาน ได้พร้อมกัน
  • bottleneck จะย้ายจาก “การลงมือทำงาน” ไปเป็น “การเขียนสเปกให้ชัดและรีวิวผลลัพธ์อย่างรวดเร็ว” ทำให้ช่วงกลางของกระบวนการค่อย ๆ หายไป
  • หากหลายเซสชันแชร์รีโปเดียวกัน ให้ใช้ git worktrees เพื่อให้แต่ละเซสชันมี checkout อิสระของตัวเอง

• ทำให้การสังเกตสถานะเซสชันง่ายขึ้น

  • stop hook: เล่นเสียงเมื่อเซสชันเสร็จ (บน macOS ใช้ afplay เล่น Glass.aiff)
  • tmux window title: ใส่อีโมจิสถานะ (⏳ กำลังทำงาน, 🟢 เสร็จแล้ว) พร้อมป้ายชื่อสั้น ๆ ที่ Haiku สร้างให้ เพื่อแยกแต่ละพาเนล
  • Claude Code status line: แสดงการใช้คอนเท็กซ์และโหมดปัจจุบัน

• เช็กอินได้แม้ตอนอยู่ห่างหน้าจอ

  • ผ่านฟีเจอร์ /remote-control ของ Claude Code สามารถเปิดดูสถานะการรันจากแท็บโค้ดในแอป Claude ระหว่างเดินทาง และใส่คอนเท็กซ์เพิ่มหรือคำสั่งใหม่ให้เซสชันที่ติดขัดได้
  • ช่วยป้องกันไม่ให้เซสชันถูกปล่อย idle ไว้หลายชั่วโมง แต่ควรใช้เฉพาะเวลาจำเป็นจริง ๆ

ปิดวงจรป้อนกลับให้ครบ

• ทำงานแบบเปิดเผยเพื่อให้คอนเท็กซ์สมบูรณ์

  • หากทำงานในเอกสาร รีโป และช่องทางสื่อสารที่แชร์ร่วมกัน สมาชิกทีม ทุกคนรวมถึงโมเดล จะใช้คอนเท็กซ์เหล่านั้นได้
  • แบบทดสอบง่าย ๆ คือ “พนักงานใหม่จะสามารถ ทำซ้ำงานของสัปดาห์ก่อน ได้ไหม โดยอาศัยเพียงคอนเท็กซ์ที่แชร์ไว้?” — ถ้าไม่ได้ แปลว่าคอนเท็กซ์สำคัญยังอยู่แค่ในหัวคน
  • สั่งไว้ใน CLAUDE.md ให้เมื่อทำงานจริงเสร็จ ระบบ โพสต์อัปเดตสั้น ๆ พร้อมลิงก์ artifact ลงช่อง worklog อัตโนมัติ

• ขุด transcript เพื่ออัปเดตการตั้งค่า

  • เมื่อให้โมเดลอ่าน transcript ของเซสชันเก่า มันจะ มองเห็นช่องว่าง ได้
  • จากการสแกน user turn เก่าราว 2,500 รายการ พบว่ามีสัดส่วนไม่น้อยที่มีข้อความอย่าง "can you also…", "did you check…", "still wrong"
  • สิ่งนี้บ่งชี้ว่าเป็นงานที่โมเดล ควรทำเองเชิงรุกอยู่แล้ว หรือไม่ก็ขั้นตอนตรวจสอบหายไป/ทำงานผิดพลาด
  • ควรแก้ไขภายในเซสชัน เพื่อใช้ transcript เป็น ข้อมูลนำเข้า สำหรับอัปเดต CLAUDE.md หรือสกิลในรอบถัดไป

• รีแฟกเตอร์และจัดระเบียบเป็นระยะ

  • เมื่อการตั้งค่าเพิ่มขึ้น ก็อาจ ซ้อนทับหรือขัดแย้งกัน ได้
  • หากโมเดลเมินกฎ อาจเป็นเพราะขัดกับกฎอื่น ดังนั้นควรรีแฟกเตอร์ให้กฎหรือความชอบแต่ละข้ออยู่ เพียงที่เดียวเท่านั้น (ยกเว้นคำสั่งสำคัญอาจย้ำซ้ำใน CLAUDE.md หลักได้)
  • รวม settings.json ที่กระจัดกระจายตามไดเรกทอรีต่าง ๆ มา จัดให้เป็นศูนย์กลางใน ~/.claude

บทสรุป

• แม้การตั้งค่าเชิงรูปธรรมอาจเปลี่ยนไปตามพัฒนาการของโมเดล แต่หลักการเรื่อง การให้คอนเท็กซ์ที่ดี การเข้ารหัสความชอบ การตรวจสอบต้นทุนต่ำ การมอบหมายให้มากขึ้น และการปิดวงจรป้อนกลับ ยังใช้ได้เสมอ
• โดยแก่นแล้ว กระบวนการนี้คือ การฝึกผู้ร่วมงานทีละหนึ่ง feedback และใช้ได้เหมือนกันกับการทำงานร่วมกับทีมมนุษย์
• หลักการเดียวกันนี้ไม่ได้จำกัดอยู่แค่เครื่องมือส่วนตัว แต่ยังนำไปใช้กับ การออกแบบ agent harness การตั้งบรรทัดฐานของทีม และการสร้างโครงสร้างพื้นฐานระดับองค์กร ได้

[xguru]

ประวัติของคนนี้น่าสนใจดีนะ
จากผู้เรียนจิตวิทยามาศึกษาผ่านคอร์ส Data Science ของ Coursera
เข้าไปร่วมงานกับ Lazada ตั้งแต่ช่วงแรก ๆ ตอนที่ยังถูกเรียกว่า Amazon แห่งเอเชียตะวันออกเฉียงใต้ และได้เลื่อนตำแหน่งจนถึง VP
Lazada ถูก Alibaba เข้าซื้อกิจการ
หลังจากนั้นก็ย้ายไป Amazon เป็นหัวหน้านักวิทยาศาสตร์ด้านระบบแนะนำ/LLM
ปัจจุบันเป็น Technical Staff ของ Anthropic