ผมใช้ AI มาพักใหญ่ๆ แล้วเริ่มรู้สึกว่ามีเรื่องหนึ่งที่ตอนแรกดูเหมือนเล็ก แต่พอใช้งานจริงไปเรื่อยๆ กลับสำคัญมาก คือการมี Working Agreement กับ AI หรือข้อตกลงวิธีทำงานร่วมกันระหว่างเรากับ AI
ช่วงแรกๆ ผมก็สั่งเป็นรอบๆ ไปเหมือนกันครับ วันนี้ให้ช่วยแก้ bug พรุ่งนี้ให้ช่วย refactor อีกวันให้ช่วยเขียน test แต่พอใช้ไปนานๆ จะเริ่มเห็น pattern ว่า หลายเรื่องเราสั่งซ้ำๆ อยู่ตลอด เช่น ก่อน push ต้อง test ก่อน, ถ้าตกลง plan แล้วให้ create task เป็น issue, ห้าม merge dev เอง ต้องขอ approve ก่อน
จนวันหนึ่งผมสังเกตน้องในทีมใช้งาน AI แล้วไม่ได้คุยเรื่องข้อตกลงกันก่อน ผลคือ AI ทำบ้างไม่ทำบ้าง บางรอบจำได้ บางรอบลืม พอปิด session ก็เหมือนต้องเริ่มใหม่ ทั้งที่ขั้นตอนส่วนใหญ่เป็นเรื่องเดิมๆ นั่นแหละครับ
หมายเหตุ: บทความนี้เป็นงานเขียนร่วมกันระหว่างผมกับ AI agent โดยอิงจากประสบการณ์ใช้งานจริงของผมเอง ส่วนข้อมูลเชิงอ้างอิงนำมาประกอบจากเอกสารและแหล่งที่มาที่ลิงก์ไว้ท้ายบทความ
Working Agreement กับ AI คืออะไร
ถ้าแปลตรงตัว Working Agreement คือข้อตกลงในการทำงานร่วมกัน ในทีมคน เราอาจตกลงกันว่า pull request ต้องมี review, ต้องเขียน test, ห้าม push เข้า main ตรงๆ หรือถ้างานใหญ่ต้องแตก task ก่อนทำ
พอมาเป็น AI coding agent แนวคิดเดียวกันก็ใช้ได้ครับ เพียงแต่คู่สนทนาของเราเป็น AI ที่อ่าน instruction แล้วพยายามทำตาม ถ้าเราไม่เขียนกติกาไว้ให้ชัด มันก็จะใช้ default behavior ของตัวเอง หรือเดาจาก prompt รอบนั้นๆ
Working Agreement กับ AI คือการเปลี่ยนสิ่งที่เราต้องสั่งซ้ำทุกวัน ให้กลายเป็นกติกาประจำโปรเจกต์
สำหรับผม มันไม่ใช่เรื่องสวยหรูหรือ process หนักๆ แต่เป็น trick เล็กๆ ที่ช่วยลดการหลุด ลดการลืม และทำให้ AI ทำงานใกล้เคียงกับวิธีที่ทีมต้องการมากขึ้น
ทำไมสั่งเป็นรอบๆ แล้ว AI ถึงหลุดง่าย
AI เก่งขึ้นมากก็จริง แต่การคุยแบบ chat มีข้อจำกัดตามธรรมชาติอยู่ครับ เช่น context ยาวขึ้นเรื่อยๆ, session ถูกปิด, prompt รอบใหม่ไม่เหมือนรอบเดิม หรือบางคำสั่งถูกกลืนไปกับรายละเอียดอื่น
ถ้าเราบอกแค่รอบนี้ว่า “ช่วยแก้ให้แล้ว test ด้วยนะ” AI ก็อาจทำตามในรอบนี้ แต่ไม่ได้แปลว่ารอบหน้ามันจะจำได้ว่า project นี้ต้อง test ก่อน push เสมอ หรือห้าม merge เองทุกครั้ง
เอกสารของ Claude Code มีแนวคิดเรื่อง memory files เช่น CLAUDE.md ที่ใช้เก็บ project instructions และบอกด้วยว่าสามารถใช้คำสั่ง /init เพื่อสร้างไฟล์เริ่มต้นจาก project ได้ ส่วน OpenAI Codex ก็มีแนวทางใช้ AGENTS.md เพื่อให้ coding agent รู้กติกา repo เช่น setup, test และ convention ของโปรเจกต์
พอผมเห็นแนวทางนี้แล้ว มันทำให้คิดง่ายขึ้นว่า เราไม่ควรเอากติกาประจำโปรเจกต์ไปซ่อนอยู่ใน chat ชั่วคราว แต่ควรยกมันขึ้นมาเป็นไฟล์หรือ instruction ที่ AI อ่านซ้ำได้ทุกครั้ง
เริ่มง่ายสุด: init project แล้วเขียนกติกาไว้
วิธีที่ง่ายที่สุดสำหรับคนใช้ Claude Code คือเริ่มจาก /init เพื่อให้ Claude อ่าน repo แล้วสร้าง CLAUDE.md เป็น project memory ตั้งต้นก่อน จากนั้นค่อยเติม Working Agreement ของทีมลงไป
/initสำหรับเครื่องมืออื่น แนวคิดเหมือนกันครับ เช่น Codex ใช้ AGENTS.md, บางทีมใช้ .cursorrules, บางทีมใช้ project instructions หรือ docs เฉพาะของตัวเอง ชื่อไฟล์อาจต่างกัน แต่หน้าที่คล้ายกัน คือบอก AI ว่า “โปรเจกต์นี้ทำงานกันแบบนี้นะ”
อย่าปล่อยให้ rule สำคัญอยู่ในหัวคน หรืออยู่ใน chat รอบเดียว ถ้ามันเป็นกติกาซ้ำๆ ให้เขียนลง project instruction
ควรเขียน Working Agreement อะไรไว้บ้าง
จากที่ผมใช้มา กติกาที่ควรเขียนไว้ไม่จำเป็นต้องเยอะมาก แต่ควรครอบคลุมจุดที่ถ้า AI หลุดแล้วจะกระทบ workflow หรือทำให้ทีมเสียเวลา
| หมวด | ตัวอย่างข้อตกลง | ทำไมสำคัญ |
|---|---|---|
| Safety | ห้าม merge dev/main อัตโนมัติ ต้องขอ approve ก่อน | กัน side effect ที่กระทบ repo จริง |
| Testing | ก่อน push ต้องรัน test ที่เกี่ยวข้อง และรายงานผลจริง | ลด bug จาก patch ที่ยังไม่ verify |
| Task management | หลังตกลง plan แล้วให้ create issue/task เสมอ | กันงานหายและทำให้ทีมตามต่อได้ |
| Code change | แก้แบบ minimal diff ไม่ rewrite ทั้งไฟล์ถ้าไม่จำเป็น | ลด regression และลด review cost |
| Communication | ถ้า scope ไม่ชัด ให้ถามก่อนแก้ส่วนที่เสี่ยง | กัน AI เดาแล้วแตะผิดจุด |
| Verification | ทุก final response ต้องบอกไฟล์ที่แก้และ command ที่รัน | ทำให้ตรวจสอบย้อนหลังได้ |
ตัวอย่าง CLAUDE.md / AGENTS.md แบบสั้น
ตัวอย่างนี้เป็นแนวทางที่ผมคิดว่าเริ่มใช้ได้ทันที แล้วค่อยปรับตามทีมครับ
# AI Working Agreement
## Goal
ช่วยพัฒนา project นี้แบบปลอดภัย ตรวจสอบได้ และไม่ทำ side effect โดยไม่ขออนุญาต
## Before coding
- ถ้างานเกิน 1 ไฟล์ ให้เสนอ plan สั้นๆ ก่อนแก้
- ถ้า scope ไม่ชัด ให้ถามก่อน ไม่เดาเองในจุดเสี่ยง
- หลังตกลง plan แล้ว ให้สร้างหรืออัปเดต issue/task เสมอ
## Coding rules
- แก้แบบ minimal diff
- ห้าม rewrite ทั้งไฟล์ถ้าไม่จำเป็น
- ทำตาม style เดิมของ repo
- ถ้าเปลี่ยน behavior ต้องเพิ่มหรือแก้ test ที่เกี่ยวข้อง
## Verification
- ก่อนเสนอว่าเสร็จ ต้องรัน targeted test ที่เกี่ยวข้อง
- ถ้าแก้หลายส่วน ให้รัน lint/typecheck ตามที่เหมาะสม
- final response ต้องบอก command ที่รันและผลจริง
## Git safety
- ห้าม merge dev/main/master อัตโนมัติ
- ห้าม push โดยไม่ขอ approve
- ห้ามลบไฟล์หรือ migration สำคัญโดยไม่ถามก่อน
## Output
- สรุป changed files
- สรุป tests ที่รัน
- บอก risk หรือสิ่งที่ยังไม่ได้ verifyแค่นี้ก็ช่วยได้เยอะแล้วครับ เพราะมันเปลี่ยนจากการสั่งซ้ำทุกครั้ง เป็นข้อตกลงที่ AI อ่านก่อนเริ่มงาน
Working Agreement ไม่ใช่ prompt ยาวๆ แต่คือ guardrail
จุดที่ต้องระวังคืออย่าเขียน instruction ยาวจนกลายเป็น manual ที่ไม่มีใครอ่าน ทั้งคนและ AI ควรเขียนให้สั้น ชัด และ actionable
- เขียนเป็น bullet
- แยกหมวดชัดเจน
- ระบุ command ที่ต้องใช้จริง
- แยกสิ่งที่ทำได้เอง กับสิ่งที่ต้องขอ approve
- มี verification rule ทุกงาน
ผมชอบคิดว่ามันคือ guardrail ไม่ใช่ prompt สวยๆ หน้าที่ของมันคือกันไม่ให้ AI หลุดออกจากวิธีทำงานที่ทีมตกลงกันไว้
แยกกติกาเป็น 3 ระดับ
ถ้าใช้จริงในทีม ผมแนะนำให้แยก rule เป็น 3 ระดับ จะดูแลง่ายกว่าเขียนทุกอย่างกองไว้ที่เดียว
| ระดับ | ตัวอย่าง | ควรอยู่ที่ไหน |
|---|---|---|
| Team rule | ห้าม merge เอง, ต้องขอ approve ก่อน push | global/team instruction |
| Project rule | วิธีรัน test, build, lint, naming convention | CLAUDE.md / AGENTS.md ใน repo |
| Task rule | งานนี้แก้เฉพาะ payment flow ห้ามแตะ auth | prompt หรือ issue ของงานนั้น |
การแยกแบบนี้ช่วยให้ rule ที่ถาวรไม่ปนกับรายละเอียดงานชั่วคราว และช่วยลดโอกาสที่ AI จะเอา instruction เฉพาะ task ไปใช้ผิดบริบทในงานอื่น
ตัวอย่าง rule ที่ผมว่าน่าใส่แทบทุก repo
ถ้าจะเริ่มแบบ practical ผมว่าสามารถ copy แนวนี้ไปปรับได้เลยครับ
- ต้อง search ก่อนอ่านไฟล์เยอะๆ เพื่อประหยัด token และลด noise
- ต้องอ่านไฟล์ที่เกี่ยวข้องจริงก่อน patch ห้ามเดา code จากชื่อไฟล์อย่างเดียว
- ต้องเสนอ plan ก่อนงานใหญ่ โดยเฉพาะงานที่แตะหลาย module
- ต้องทำ minimal diff ถ้าไม่ได้สั่ง refactor ใหญ่
- ต้องรัน test ก่อนบอกว่าเสร็จ และรายงาน output จริง
- ห้าม push/merge/delete/migrate โดยไม่ขอ approve
- ถ้า command fail ต้องรายงานตรงๆ ห้ามบอกว่าสำเร็จจากการเดา
- ถ้าเจอ requirement ใหม่ ให้บันทึกเป็น issue/task ไม่ปล่อยหายใน chat
AI ที่เก่งแต่ไม่มี working agreement จะทำงานเร็ว แต่ทีมอาจต้องเสียเวลาตามเก็บทีหลัง
ควรทบทวนกติกานี้เมื่อไร
Working Agreement ไม่ควรเขียนครั้งเดียวแล้วจบครับ เพราะวิธีทำงานของทีมเปลี่ยนได้ตลอด เครื่องมือ AI ก็เปลี่ยนเร็วมากเหมือนกัน
ผมคิดว่าน่าทบทวนเมื่อมีเหตุการณ์พวกนี้
- AI หลุด rule เดิมซ้ำๆ
- ทีมเริ่มใช้ AI agent หลายตัวพร้อมกัน
- มี incident จากการแก้ code โดยไม่ได้ verify
- เปลี่ยน test command หรือ build pipeline
- มีคนใหม่เข้าทีมแล้วใช้ AI ไม่เหมือนคนอื่น
- เริ่มใช้เครื่องมือใหม่ เช่น Claude Code, Codex, Cursor หรือ Gemini CLI
พูดง่ายๆ คือถ้าเป็นบทเรียนที่ไม่อยากให้เกิดซ้ำ ให้ย้ายมันเข้า Working Agreement ครับ
ข้อควรระวัง: อย่าเชื่อว่าเขียน rule แล้ว AI จะไม่พลาดอีกเลย
การมี Working Agreement ช่วยได้มาก แต่ไม่ได้ทำให้ AI กลายเป็นระบบ deterministic 100% ครับ เรายังต้องมี verification, test, review และ approval gate อยู่ดี
โดยเฉพาะ rule ที่มีผลกับ production หรือ source control เช่น merge, push, deploy, migration, delete data อันนี้ไม่ควรปล่อยให้ AI ตัดสินใจเองจาก prompt อย่างเดียว ต้องมี human approval หรือ branch protection ช่วยล็อกอีกชั้น
ผมมองว่า Working Agreement เป็นชั้นแรกที่ช่วยให้ AI ทำถูกทางมากขึ้น ส่วน test, CI, review และ approval เป็นชั้นถัดมาที่ช่วยจับความผิดพลาดก่อนกระทบของจริง
สรุป
หลังจากใช้ AI มาพักใหญ่ ผมเริ่มรู้สึกว่าเราไม่ควรมอง AI เป็นแค่ chatbot ที่สั่งทีละรอบ แต่ควรมองเป็นผู้ช่วยทำงานที่ต้องมี working agreement เหมือนสมาชิกทีมคนหนึ่ง
ถ้ามีเรื่องที่เราต้องสั่งซ้ำๆ เช่น test ก่อน push, create issue หลังตกลง plan, ห้าม merge dev เอง หรือรายงานผล verify ทุกครั้ง ก็ไม่ควรปล่อยให้มันอยู่ในความทรงจำชั่วคราวของ session ครับ เขียนมันลง project instruction ไปเลย
เริ่มจากเล็กๆ ก็พอ เช่นใช้ /init ใน Claude Code เพื่อสร้าง CLAUDE.md แล้วเติมกติกาของทีมลงไป หรือถ้าใช้ Codex ก็ทำ AGENTS.md ใน repo ให้ชัด แค่นี้ก็ช่วยลดการหลุด ลดการสั่งซ้ำ และทำให้ AI ทำงานเข้ากับทีมได้ดีขึ้นมากแล้วครับ
