ช่วงแรกๆ ผมก็สั่งเป็นรอบๆ ไปเหมือนกันครับ วันนี้ให้ช่วยแก้ 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 หรือทำให้ทีมเสียเวลา

ตัวอย่าง 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 ระดับ จะดูแลง่ายกว่าเขียนทุกอย่างกองไว้ที่เดียว

การแยกแบบนี้ช่วยให้ 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 ทำงานเข้ากับทีมได้ดีขึ้นมากแล้วครับ

แหล่งอ้างอิง

• Claude Code Docs: How Claude remembers your project
• OpenAI Codex: Custom instructions with AGENTS.md
• AGENTS.md: open format for coding agent instructions
• Augment Code: AI Agent Pre-Merge Verification

แนวคิดที่ Anthropic ยกมาคือ ให้ Sonnet 5 เป็น executor ทำงานหลักใน loop ปกติ แล้วให้ Fable 5 เป็น advisor ที่ถูกเรียกเฉพาะตอนต้องใช้ judgment สูง เช่น วางแผน ตัดสินใจ architecture แก้ทางเมื่อเริ่มหลุด หรือ review ก่อนจบงาน ผมว่ามันเป็น pattern ที่ practical มาก เพราะมันไม่ได้พยายามลดคุณภาพด้วยการใช้โมเดลเล็กอย่างเดียว แต่ใช้โมเดลฉลาดให้ถูกจังหวะมากกว่า

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูช่วยกันเรียบเรียง โดยอิงจากโพสต์ของ ClaudeDevs บน X, เอกสาร Advisor tool ของ Anthropic และ Claude Cookbook แล้วนำมาตีความเป็นแนวทางใช้งานจริงสำหรับคนทำ AI agent / coding agent

ต้นทางของเรื่องนี้สรุปไว้สั้นมากว่า หนึ่งใน pattern ที่ Anthropic ใช้กับ Fable 5 คือ “ใช้ Fable 5 เป็น advisor” โดย executor อย่าง Sonnet 5 จะเรียก Fable 5 เพื่อขอคำแนะนำ ดังนั้นการทำงานส่วนใหญ่จะใช้ token ไปกับ executor ที่ Sonnet 5 ทำมากกว่า

ต้องเข้าใจก่อนว่า agent workload ไม่ต้องใช้โมเดลฉลาดทุกงาน

เวลาพูดถึง AI coding agent หรือ agent ที่ทำงานหลาย step ผมคิดว่าหลายคนมักติดกับดักว่า “ใช้โมเดลฉลาดสุดไปเลยจะได้จบ” ซึ่งจริงในบางงาน แต่ไม่จริงเสมอไป โดยเฉพาะงานยาวๆ ที่มี token จำนวนมากถูกใช้ไปกับงาน mechanical มากกว่า reasoning

ในงานหนึ่งๆ มักมี 2 ส่วนปนกัน:

• ส่วนที่ต้องคิดจริง: แตกโจทย์, ตีความ requirement, เลือก architecture, ประเมิน trade-off, หาทางออกตอนติดปัญหา
• ส่วนที่ต้องทำเยอะ: อ่านไฟล์, อ่านเว็บ, grep โค้ด, ดู log, แก้ไฟล์, รัน test, สรุป output จาก tool

ถ้าใช้โมเดลระดับ frontier ทำทั้งสองส่วนทั้งหมด ก็โครตจะเปลือง token เลยครับ เพราะถูกใช้ไปกับงานทั่วไปที่ไม่ต้องการ frontier reasoning ทุกบรรทัด เช่น อ่านหน้าเว็บยาวๆ หรือไล่ log หลายพันบรรทัด ตรงนี้เองที่ทำให้ค่าใช้จ่ายสูงโดยไม่จำเป็น

ผมขอเปรียบให้เห็นภาพง่ายๆ เหมือนเอา senior engineer ไปนั่งอ่าน log ทุกบรรทัดเอง ซึ่งงานเขาควรเข้ามาตอนวางทิศทาง ตรวจจุดเสี่ยง หรือช่วยตัดสินใจเรื่องที่ถ้าผิดแล้วจะเสียเวลาเยอะ ส่วนงานอ่าน/เก็บข้อมูล/ทำตามขั้นตอนให้คนที่เร็วกว่าและต้นทุนต่ำกว่าช่วยทำได้

หรือเทียบในงานก่อสร้าง ก็เหมือนเอาวิศะไปก่ออิฐฉาบปูนแทนคนงานก่อสร้าง แทนที่วิศวะจะออกแบบ วางแผน และคนงานจะเป็นคนทำ

เแนวคิด: Sonnet 5 เป็นคนทำงานหลัก ส่วน Fable 5 เป็นคนให้คำปรึกษา

จาก diagram ในโพสต์ของ ClaudeDevs โครงสร้างคือ Sonnet 5 ทำหน้าที่ executor และรัน main loop ทุก turn ส่วน Fable 5 เป็น advisor ที่ถูกเรียกผ่าน tool call เฉพาะเมื่อจำเป็น พูดง่ายๆ คือ Sonnet ทำงานหนัก แต่ Fable ช่วยคิดตอนที่ต้องคิดอย่างมีเหตุมีผล

เอกสาร Advisor tool ของ Anthropic อธิบายแนวคิดนี้ว่า executor model ที่เร็วกว่า/ต้นทุนต่ำกว่า สามารถ consult advisor model ที่ฉลาดกว่า mid-generation ได้ โดย advisor จะเห็น conversation transcript ทั้งหมด แล้วส่งคำแนะนำกลับมาให้ executor ทำงานต่อ

จุดที่ผมว่าสำคัญคือ advisor ไม่ได้มาแทน executor แต่เป็นเหมือน reviewer หรือ architect ที่ถูกเรียกในจังหวะที่ควรเรียก ทำให้เรายังได้คุณภาพจากโมเดลใหญ่ในการตัดสินใจสำคัญๆ แต่ไม่ต้องจ่ายราคาโมเดลใหญ่กับทุกการทำงานง่ายๆ หลายงาน

แล้ว Advisor tool ทำงานยังไง?

เมื่อเราเพิ่ม advisor tool เข้าไปใน tools array แล้ว ตัว executor จะตัดสินใจเองว่าจะเรียก advisor เมื่อไรเหมือน tool อื่นๆ แต่การ call นี้เกิดฝั่ง server ภายใน request เดียว ไม่ใช่ client ต้อง orchestration เองหลายรอบ

• executor สร้าง server_tool_use ชื่อ advisor
• server ส่ง transcript ทั้งหมดให้ advisor model
• advisor ส่งคำแนะนำกลับมาเป็น advisor_tool_result
• executor ใช้คำแนะนำนี้ทำงานต่อจนจบ

ตัวอย่างแบบย่อจากเอกสาร Anthropic:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

ถ้านำ concept นี้มาเทียบกับโพสต์ Fable 5 ภาพในหัวจะประมาณนี้:

tools=[
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-fable-5",
        "max_tokens": 2048,
        "max_uses": 2,
    }
]

ตรงนี้ max_tokens กับ max_uses สำคัญมาก เพราะถ้าเปิด advisor ไว้แบบไม่จำกัด มันอาจกลายเป็น “เรียกโมเดลแพงบ่อยขึ้น” แทนที่จะช่วยประหยัด token

วิธีใช้ให้ประหยัด token จริง

1. ให้ executor อ่านบริบทก่อน แล้วค่อยเรียก advisor

ผมคิดว่าเราไม่ควรเรียก Fable 5 ตั้งแต่ครั้งแรกที่ยังไม่รู้อะไรเลย เพราะคำแนะนำจะกว้างเกินไป วิธีที่ดีกว่าคือให้ Sonnet 5 อ่านทำความเข้าใจบริบทแรกของเราก่อน เช่น requirement, โครง repo, error log หรือไฟล์หลัก แล้วค่อยเรียก Fable 5 เพื่อช่วยวางแผน

2. ใช้ advisor ในจุดที่ตัดสินใจผิดแล้วแพง

จุดที่คุ้มจะเรียก advisor คือจุดที่ถ้าคิดผิดแล้วต้องแก้งานเยอะ เช่น:

• เลือก architecture หรือ migration strategy
• ตีความ requirement ที่กำกวม
• เจอ test fail ซ้ำๆ แล้วแนวทางเดิมแก้ไม่ได้ หรือไม่ครอบคลุม
• ก่อนจบงาน เพื่อ review ว่าหลุด security, edge case หรือ test อะไรไหม

3. จำกัดจำนวนครั้งด้วย max_uses

ถ้างานหนึ่งควรเรียก advisor แค่ 1–2 ครั้ง ก็ตั้ง max_uses ไว้เลย จะช่วยไม่ให้ executor เรียก advisor ถี่เกินไปใน request เดียว

4. จำกัดคำตอบของ advisor ด้วย max_tokens

เอกสาร Anthropic แนะนำจุดเริ่มต้นที่ max_tokens: 2048 สำหรับ advisor output cap โดยระบุว่าในการทดสอบของเขา การตั้ง cap นี้ลด output ของ advisor ได้มากเมื่อเทียบกับการไม่ตั้ง และยังไม่เห็นว่าคุณภาพลดลงเท่าไรอย่างชัดเจน (quality degradation) แต่ประโยคสำคัญคือ เราต้องตรวจสอบกับ workload ของตัวเองเสมอนะ เพื่อป้องกันความผิดพลาด เนื่องจากจำกัด token (ผมเคยเจอบ่อยว่า output งานออกมาได้ไม่ถูกต้อง หรือโค้ดไม่ครบ)

5. เปิด caching เฉพาะงานที่เรียก advisor หลายครั้ง

ใน docs ระบุว่า advisor-side caching จะเริ่มคุ้มเมื่อคาดว่าจะมี advisor call ประมาณ 3 ครั้งขึ้นไปใน conversation เดียว ถ้างานสั้นๆ เรียกครั้งเดียวหรือสองครั้ง การเปิด cache อาจไม่คุ้ม เพราะ cache write ก็มีต้นทุนของมันเอง

อีกแนวคิดที่คล้ายกัน คือ Plan big, execute small

ใน Claude Cookbook เรื่อง Coordinator pattern Anthropic อธิบายอีก pattern ที่คล้ายกันมาก คือให้โมเดลใหญ่เป็น coordinator สำหรับวางแผนและสังเคราะห์คำตอบ ส่วน worker model ที่ถูกกว่าเป็นคนอ่านเว็บหรือดึงข้อมูลจำนวนมากใน context ของตัวเอง

ในการทดลองที่ Anthropic ยกตัวอย่าง ทีมแบบ split ราคาจะถูกลงกว่าประมาณ 2.5x และทำงานเร็วขึ้นประมาณ 3x โดยจำนวน input token 84–98% ถูกคิดที่ worker ที่ใช้ราคา Token ถูกกว่า

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

แต่โครงสร้างวิธีการทำแบบนี้ก็ชัดเจนดี คือ งานอ่านเยอะๆ ให้ worker ทำ ส่วนโมเดลใหญ่แตะเฉพาะ planning/synthesis

จากที่อ่าน ถ้าผมจะใช้จริง จะวาง flow แบบนี้

1. เริ่มด้วย Sonnet 5: ให้ทำงานหลัก อ่านไฟล์ เรียก tool แก้โค้ด รัน test
2. Orientation: เก็บบริบทขั้นต่ำก่อน เช่น requirement, repo structure, error หลัก
3. Advisor call แรก: เรียก Fable 5 ให้ช่วยวางแผนและชี้ risk
4. Execute: ให้ Sonnet 5 ลงมือทำตาม plan โดยไม่เรียก advisor ทุกจุด
5. Replan เมื่อจำเป็น: ถ้า error วนหรือทางเดิมไม่ไปต่อ ค่อยเรียก Fable 5 อีกครั้ง
6. Review ก่อนจบ: เรียก advisor ช่วยดูว่าตกหล่น test, security, edge case หรือ assumption อะไรไหม
7. Finish: ให้ executor สรุปผลพร้อม evidence จาก test/diff/tool output

ต้องบอกว่า ผมยังแค่คิดนะ เพราะยังไม่มีโจทย์ซับซ้อนพอที่จะใช้ Fable ทำงาน และยังไม่อยากลองรันเทียบ เพราะต้องทำหลายครั้ง อาจจะเสีย Token เยอะ ฮาา, ไว้รอมีผลการทดสอบจากผู้กล้า หรือได้ลองจริงๆ แล้วจะเอามาเล่าให้ฟังอีกที หรือหากใครลองแล้วก็มาแชร์กันหน่อยครับ

ข้อควรระวัง

• งานเล็กมากอาจไม่คุ้ม: ถ้าเป็น single-turn Q&A หรือแก้ typo เล็กๆ advisor อาจเพิ่ม overhead มากกว่าประโยชน์
• ต้องวัดกับ workload จริง: ตัวเลขประหยัด token ไม่ใช่ค่าคงที่ ขึ้นกับชนิดงานและความยาวของ context
• อย่าแตกงานย่อยจนเกินพอดี: ใน cookbook เองก็เตือนว่าการแตก brief แคบเกินไปมี floor cost ของ worker thread (ขออธิบายเพิ่มเติมครับ: มันคือต้นทุนขั้นต่ำต่อ worker thread หมายถึง ทุกครั้งที่สร้าง worker หรือ sub-agent ใหม่ มันมี “ต้นทุนตั้งต้น” เสมอ ไม่ว่าจะงานเล็กหรือใหญ่ เช่น เปิด session ,รับ prompt, อ่าน context, เรียก Skill)
• advisor แก้โจทย์เท่าที่ได้รับจาก context: ถ้า executor ยังไม่ได้อ่านของสำคัญก่อนเรียก advisor คำแนะนำก็อาจกว้างหรือผิดทิศได้ เช่นเราใส่บริบทไม่ครบหรือไม่เข้าใจให้ advisor เองแต่แรก (นั่นคือเหตุผลของ Anthopic ว่าทำไมไม่ควรเอาตัวฉลาดมารับงานก่อน)
• ต้อง track cost แยก: usage ของ advisor อยู่ใน usage.iterations เป็น advisor_message เพราะถูก bill คนละ rate กับ executor

ผมขอขยายความข้อสุดท้ายนิดนึงคือ มันไม่สามารถคิด token cost แบบ usage.input_tokens + usage.output_tokens ทั่วไปนะ เพราะอาจจะเข้าใจผิดคิดว่าแพงทั้งหมด แต่ควรคิดจาก

total_cost = executor_tokens × ราคา Sonnet 5 + advisor_tokens × ราคา Fable 5

ดังนั้น ใน Anthropic API ที่ส่งค่า usage.iterations กลับมา เราต้องคิดราคาแยกตาม type ด้วย ว่าอะไรคือ executor (message) และอะไรคือ advisor (advisor_message)

สรุป

ผมคิดว่า “Fable 5 เป็น advisor” เป็นแนวทางที่น่าลองมากสำหรับ agent workflow ที่เราจะให้มันทำงานยากๆ หรือต้องใช้การตัดสินใจอย่างมีเหตุมีผลสูงมาก ส่วนงานง่ายๆ อย่างการ อ่าน/ทำ/ตรวจซ้ำ ก็ให้ใช้โมเดลรองๆ ลงมา ทำก็คิดว่าเพียงพอแล้ว (อย่างน้องชมพูที่ผมให้แชต ก็ใช้แค่ ChatGPT mini แต่หาข้อมูลและเขียนบทความ ผมจะใช้ ChatGPT ปกติ

อ้างอิง

• ClaudeDevs on X — Fable 5 as advisor pattern
• Anthropic Claude Platform Docs — Advisor tool
• Anthropic Claude Cookbooks — Coordinator pattern: big models for planning, small models for execution

เรื่องนี้ตรงกับสิ่งที่ผมเองก็กำลังทดลองและพัฒนาอยู่เหมือนกัน โจทย์คือจะทำยังไงให้ Agent ไม่ได้เป็นแค่ผู้ช่วยตอบคำถาม หรือช่วยเขียนโค้ดเป็นรอบๆ แต่สามารถรับโจทย์ยาวๆ วางแผน ทำงาน ตรวจงาน ส่งต่องาน และค่อยๆ ปรับปรุงผลลัพธ์ได้เองมากขึ้น (ยุคนี้เรียกว่า Loop Engineering)

ผมเลยอยากเอาบทความนี้มาเล่าในมุมที่นำไปต่อยอดได้จริง โดยเฉพาะสำหรับคนที่กำลังสนใจเรื่อง AI Agent, coding agent, workflow automation หรือระบบที่ให้ AI ทำงานต่อเนื่องแทนการ prompt ทีละครั้ง

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและต่อยอดจากบทความต้นฉบับของ Anthropic Engineering เรื่อง Harness design for long-running application development เขียนโดย Prithvi Rajasekaran

Harness คืออะไรในบริบทของ AI Agent

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

ซึ่งในโลกของการเขียนโปรแกรม เรามักคุ้นกับ test harness หรือ automation harness อยู่แล้ว คือชุดเครื่องมือที่ช่วยรัน ทดสอบ ตรวจผล และคุมการทำงานบางอย่างให้เป็นระบบ พอมาอยู่ในโลกของ AI Agent แนวคิดก็คล้ายกัน แต่ขยายใหญ่กว่าเดิม

Harness ของ AI Agent อาจรวมหลายอย่าง เช่น

• วิธีแตกงานใหญ่ให้เล็กลง
• วิธีให้ agent วางแผนก่อนลงมือทำ
• วิธีเก็บ state ของงานไว้นอก context window
• วิธีส่งต่องานระหว่าง agent หรือ session
• วิธีตรวจคุณภาพของงานที่ทำเสร็จ
• วิธีบังคับให้ agent แก้ไขงานตาม feedback
• วิธีหยุดงานเมื่อถึงเงื่อนไขบางอย่าง

พูดอีกแบบคือ ถ้า model คือสมอง harness ก็คือระบบการทำงานรอบสมองนั้น

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

จริงๆ ลองทดสอบได้ง่ายๆ ครับ ถ้าเอา prompt ใส่ใน Claude Web ตั้งโมเดลเป็น Opus 4.8 กับใส่ในระบบแชตแจกฟรีเช่น Langflow โดยต่อโมเดล Opus 4.8 ผ่าน Claude API, คำตอบที่ได้ออกมาจะไม่เหมือนกัน แม้ว่าใช้สมอง Opus 4.8 เหมือนกัน (เรื่องนี้ 9arm ก็มีเล่าให้ฟังตอนทำ 9arm AI Passport)

ปัญหาของ Agent ที่ให้ทำงานยาวๆ

บทความนี้เริ่มจากโจทย์ที่ Anthropic ทดลองอยู่ 2 เรื่อง คือทำให้ Claude สร้าง frontend design ที่มีคุณภาพสูงขึ้น และทำให้ Claude สร้าง application เต็มรูปแบบได้โดยไม่ต้องมีมนุษย์เข้าไปช่วยระหว่างทาง

สองงานนี้ดูเหมือนคนละเรื่อง งานแรกเป็นเรื่องรสนิยมและความสวยงาม งานหลังเป็นเรื่องซอฟต์แวร์ที่ใช้งานได้จริง แต่ทั้งคู่มีปัญหาร่วมกันอย่างหนึ่ง คือถ้าให้ AI ทำงานยาวๆ แบบ naive เกินไป คุณภาพจะเริ่มแกว่ง

1. Context เต็มแล้วเริ่มหลุด

งานที่ยาวหลายชั่วโมงจะมีข้อมูลสะสมเยอะมาก ตั้งแต่ requirement, decision, bug, code, test result, feedback ไปจนถึงสิ่งที่ลองแล้วไม่เวิร์ก ถ้าทุกอย่างถูกกองอยู่ใน context window เดียว สุดท้าย agent จะเริ่มจับประเด็นไม่ครบ

Anthropic ยังพูดถึงอาการที่น่าสนใจชื่อว่า context anxiety คือ model เริ่มเหมือนรู้ตัวว่าบริบทใกล้เต็ม แล้วพยายามรีบ wrap up งานก่อนเวลา ทั้งที่งานจริงยังไม่เสร็จดี

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

2. Agent มักตรวจงานตัวเองใจดีเกินไป

อีกปัญหาหนึ่งที่ตรงมากคือ self-evaluation

เวลาถาม agent ว่างานที่ตัวเองทำดีไหม มันมักตอบว่าดี ใช้ได้ พร้อมแล้ว หรือใกล้เสร็จแล้ว ทั้งที่ถ้ามนุษย์ลองใช้งานจริงอาจเห็นเลยว่ามีหลายจุดยังไม่ดีพอ

งาน coding ยังพอมี test ช่วยจับได้บ้าง แต่งานอย่าง design, UX, product completeness หรือบทความนี่ตรวจยากกว่าเยอะ เพราะไม่มีคำตอบแบบ pass/fail ชัดเจน

Anthropic เลยใช้แนวทางแยก agent ที่สร้างงาน ออกจาก agent ที่ตรวจงาน ซึ่งผมคิดว่าเป็น pattern ที่ควรใช้จริงในระบบ agent ที่ต้องการคุณภาพ

แนวคิดหลัก: Planner, Generator, Evaluator

โครงสร้างที่บทความนี้พูดถึงคือการแบ่ง agent ออกเป็น 3 บทบาทหลัก

ถ้ามองในเชิงทีมซอฟต์แวร์ มันก็คล้ายๆ การแยก role ในทีมจริง

• Planner ทำหน้าที่คล้าย product/tech lead
• Generator ทำหน้าที่คล้าย developer
• Evaluator ทำหน้าที่คล้าย QA, reviewer และ product tester

ข้อดีคือเราไม่ต้องหวังให้ agent ตัวเดียวทำทุกอย่างเก่งหมด เพราะในความเป็นจริง มนุษย์เองก็ยังไม่ค่อยทำงานแบบนั้น เรามีคนคิด คนทำ คนตรวจ และ feedback loop ที่ทำให้งานดีขึ้น

ทำเรื่อง subjective ให้ตรวจได้

ส่วนที่ผมชอบมากในบทความคือการทดลองกับ frontend design เพราะ design เป็นเรื่องที่วัดยาก

Anthropic พบว่า Claude มักสร้าง UI ที่ technically ใช้งานได้ แต่ดู generic มาก เช่น layout ปลอดภัย card เยอะๆ gradient เดิมๆ หรือหน้าตาที่ดูเหมือน AI สร้างแบบไม่มี character

เขาเลยสร้าง evaluator ที่มี criteria ชัดเจน เช่น

• Design quality งานดูเป็นภาพรวมเดียวกันไหม
• Originality มีความคิดสร้างสรรค์จริงไหม หรือเป็น template
• Craft typography, spacing, contrast, color harmony ดีไหม
• Functionality ผู้ใช้เข้าใจและใช้งานได้จริงไหม

จุดสำคัญคือเขาไม่ได้ถามกว้างๆ ว่า “สวยไหม” แต่แตกคำว่าสวยให้กลายเป็น rubric ที่ตรวจได้

ผมว่านี่เอาไปใช้กับงานอื่นได้เยอะมาก เช่นบทความดีไหม requirement ชัดไหม dashboard ใช้งานง่ายไหม หรือแม้แต่ระบบ automation ที่ agent สร้างขึ้นมามี failure mode อะไรบ้าง ถ้าเราไม่มี rubric evaluator ก็จะตอบกว้างๆ และหลุดง่าย

Context Reset ไม่ใช่แค่ล้างแชท แต่ต้องมี Handoff

อีกเรื่องที่สำคัญมากคือ structured handoff

ถ้า agent ทำงานยาวจนต้องเริ่ม session ใหม่ หรือให้ agent ตัวใหม่มารับช่วงต่อ เราไม่ควรส่งต่อด้วย chat history ยาวๆ อย่างเดียว แต่ควรมี artifact ที่สรุปสถานะงานอย่างเป็นระบบ

handoff ที่ดีควรบอกอย่างน้อยว่า

• เป้าหมายของงานคืออะไร
• ทำอะไรเสร็จแล้ว
• ไฟล์ไหนถูกแก้
• คำสั่งไหนรันแล้ว
• ผลลัพธ์จริงคืออะไร
• ยังเหลือปัญหาอะไร
• next step คืออะไร

ถ้าเป็นงาน coding ก็ควรมี test result, git diff, known issue และคำอธิบาย decision ที่สำคัญด้วย

ในมุมผม นี่คือจุดที่ทำให้ agent system เริ่มจริงจังขึ้นมาก เพราะเราเริ่มย้าย source of truth จาก “บทสนทนา” ไปอยู่ใน “artifact” ที่อ่านซ้ำได้ ตรวจได้ และส่งต่อได้

Sprint Contract: ก่อนทำ ต้องรู้ก่อนว่า Done คืออะไร

อีกไอเดียที่น่าสนใจคือก่อนแต่ละ sprint ให้ Generator และ Evaluator ตกลงกันก่อนว่า sprint นี้จะทำอะไร และจะตรวจยังไงถึงเรียกว่าสำเร็จ

ผมมองว่านี่คือ acceptance criteria สำหรับ agent โดยเฉพาะ

ถ้าให้ agent “สร้างระบบ task management” เฉยๆ มันอาจทำหน้าจอสวย แต่ข้อมูลไม่ persist หรือ filter ใช้ไม่ได้ แต่ถ้ามี sprint contract เช่น

• สร้าง task ได้
• แก้สถานะ task ได้
• filter ตาม status ได้
• refresh แล้วข้อมูลยังอยู่
• Evaluator ต้องทดสอบผ่าน browser จริง

แบบนี้งานจะตรวจได้ชัดขึ้นมาก และลดโอกาสที่ agent จะทำ feature แบบดูเหมือนเสร็จ แต่ใช้งานจริงไม่ได้

ผลลัพธ์ที่ Anthropic เจอ

บทความยกตัวอย่างให้ Claude สร้าง 2D retro game maker แล้วเทียบระหว่าง solo agent กับ full harness

full harness แพงกว่ามาก แต่คุณภาพต่างกันชัดเจน solo agent ทำหน้าตาได้บางส่วน แต่เกมเล่นจริงไม่ได้ดีนัก ส่วน full harness ทำ feature ได้ลึกกว่า polished กว่า และ play mode ใช้งานได้จริงกว่า

นี่เป็น trade-off ที่ต้องจำไว้ ไม่ใช่ว่าเราควรใช้ harness หนักๆ กับทุกงาน เพราะบางงาน single agent ก็พอ แต่ถ้างานสำคัญ งานซับซ้อน หรืองานที่ต้องการคุณภาพสูงมาก harness แบบนี้อาจคุ้ม

เมื่อ Model เก่งขึ้น Harness ก็ต้องเปลี่ยน

อีกประเด็นที่ผมชอบคือ Anthropic บอกว่าเมื่อ model รุ่นใหม่เก่งขึ้น บางส่วนของ harness ที่เคยจำเป็นอาจไม่จำเป็นอีกต่อไป

นี่เป็นความจริงที่สำคัญมาก ทุก component ใน harness คือสมมติฐานบางอย่างว่า model ยังทำเองได้ไม่ดีพอ เช่น ยังวางแผนไม่ดีพอ ยัง review ตัวเองไม่ดีพอ ยังทำงานยาวไม่ได้พอ หรือยังต้องแตกงานเป็น sprint เล็กๆ

แต่เมื่อ model ดีขึ้น สมมติฐานเหล่านี้อาจหมดอายุ

ดังนั้น harness ที่ดีไม่ควรเป็น pipeline แข็งๆ แต่ควรเป็นระบบที่ปรับได้ เช่น

• เปิดหรือปิด planner ได้
• เลือก evaluator แบบเบาหรือหนักได้
• ปรับจำนวนรอบ iteration ได้
• เลือกใช้ context reset หรือ compaction ได้
• ถอด component ที่ไม่ load-bearing ออกได้

ผมคิดว่านี่คือแนวคิดที่ดีมากสำหรับคนทำ agent platform เพราะเราไม่ได้ออกแบบระบบเพื่อ model รุ่นเดียว แต่ต้องออกแบบให้ evolve ตาม model ได้

ถ้าจะเอามาพัฒนาต่อ ผมจะเริ่มจากอะไร

ถ้าเอาแนวคิดนี้มาใช้กับระบบ agent ที่ผมกำลังทำอยู่ ผมคิดว่าสิ่งที่ควรเริ่มมีคือ 5 เรื่องนี้

1. Artifact-first workflow

อย่าให้ chat เป็นที่เก็บ state หลักของงาน แต่ให้ agent ทำงานผ่านไฟล์หรือ object ที่ชัดเจน เช่น

• SPEC.md
• PLAN.md
• TASKS.md
• STATE.md
• EVAL.md
• HANDOFF.md

ไฟล์เหล่านี้ทำให้ agent ตัวถัดไปอ่านต่อได้ และมนุษย์ก็ตรวจได้ด้วย

ซึ่งหากใครใช้ skill พวกทำ Spec Driven มันจะสร้างเอกสาร spec/plan/adr ให้อัตโนมัติ คอนเซ็ปประมาณนี้เลย

2. Maker กับ Checker ต้องแยกกัน

งานสำคัญไม่ควรให้ agent ตัวเดียวสร้างและรับรองงานตัวเอง ควรมี reviewer หรือ evaluator แยกออกมาเสมอ โดยเฉพาะงานที่ต้อง publish, deploy หรือกระทบข้อมูลจริง

3. Evaluator ต้องมี Rubric

rubric คือชุดเกณฑ์การให้คะแนน หรือเครื่องมือประเมินผลที่อธิบายระดับคุณภาพของชิ้นงาน

ดังนั้น Evaluator ที่ไม่มี rubric จะตรวจแบบลอยๆ และมักใจดีเกินไป rubric ที่ดีควรบอกว่าอะไรคือ pass, อะไรคือ fail, ต้องลอง edge case ไหน และอะไรที่ห้ามมองข้าม

4. Context Reset ต้องเป็น Feature ไม่ใช่ปล่อยให้แก้ตอนเต็ม

ถ้างานยาวพอ เราควรออกแบบไว้เลยว่า agent จะ reset ตอนไหน ส่งต่ออะไร และ agent ตัวใหม่ต้องอ่านอะไรบ้าง ไม่ใช่รอให้ context เต็มแล้วค่อยหาทางรอด

5. ต้องมี Stop Condition

Agent ที่ทำงานเองได้ต้องรู้ด้วยว่าเมื่อไรควรหยุด ถ้าไม่มี stop condition มันอาจวนแก้ไปเรื่อยๆ ใช้ token ใช้เวลา แต่คุณภาพไม่ได้ดีขึ้นตามสัดส่วน

ข้อควรระวัง

แนวทางนี้น่าสนใจมาก แต่ก็มีข้อควรระวังเยอะเหมือนกัน

• Cost สูงขึ้น เพราะใช้หลาย agent ทำงานหลายรอบ และต้องมี evaluation loop
• สร้างงานได้ช้าขึ้น เพราะงานบางอย่างต้องรอ browser test, QA หรือ iteration
• ซับซ้อนขึ้น เพราะต้องดูแล state, artifact, prompt, rubric และ orchestration
• Evaluator ก็พลาดได้ ถ้า rubric ไม่ดีหรือทดสอบไม่ลึกพอ
• Handoff ที่ไม่ดีอันตรายมาก เพราะ agent รุ่นถัดไปอาจสานต่อจากข้อมูลผิด

ดังนั้นผมคิดว่าควรใช้ harness หนักๆ เฉพาะงานที่คุ้มจริง เช่นงานที่มีผลลัพธ์สำคัญ งานที่ต้องใช้ซ้ำ หรืองานที่ถ้าพลาดแล้วเสียเวลามาก

สรุป

บทความนี้ทำให้ผมยิ่งเชื่อว่าอนาคตของ AI Agent ไม่ได้อยู่ที่ prompt อย่างเดียว แต่อยู่ที่การออกแบบ harness รอบๆ model ให้ดีพอ

Agent ที่ทำงานยาวได้จริงต้องมี plan ต้องมี state ต้องมี handoff ต้องมี evaluator ต้องมี rubric และต้องมีวิธีรู้ว่าเมื่อไรควรทำต่อหรือหยุด

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

สำหรับผม นี่เป็นทิศทางที่น่าทดลองมาก และน่าจะเป็นแกนสำคัญของระบบ agent รุ่นถัดไปที่ไม่ได้แค่ “ตอบเก่ง” แต่ “ทำงานเป็นระบบ” ได้จริง

ผมถามทั้งสามด้วย prompt ที่ว่า

“I put my heart and soul into my work, and I have lost my mind in the process.” Vincent van Gogh
หมายถึงอะไร มีอารมณ์อะไรซ่อนอยู่ในนั้น

— — — ChatGPT 4o — — —

โอ้ ประโยคของ Vincent van Gogh อันนี้

“I put my heart and soul into my work, and I have lost my mind in the process.”

ถ้าแปลไทยให้เห็นอารมณ์ชัด ๆ เลย ก็คือ

“ฉันทุ่มเทหัวใจและจิตวิญญาณทั้งหมดลงในงานของฉัน และได้สูญเสียสติหรือความเป็นตัวของตัวเองไปในระหว่างทาง”

วิเคราะห์แบบลงรายละเอียด (ตามที่ฟิวส์ขอ)

✅ ความหมายโดยตรง

• เขาอธิบายว่าเขาให้ ทุกสิ่งทุกอย่าง กับงานศิลปะของเขา
• คำว่า lost my mind หมายถึง การเสียสมดุลทางจิต หรือความทุกข์ทางใจที่หนักมากจนเหมือนหลุดจากโลกความจริง
• พูดง่าย ๆ คือ งานศิลปะทำให้เขาทุ่มเทจนลืมดูแลสภาพจิตใจตัวเอง

✅ อารมณ์ที่ซ่อนอยู่

• ความเจ็บปวด (pain) เพราะเหมือนบอกว่าการสร้างผลงานคือการเสียสละ
• ความรักในงานศิลปะ (passion) แบบลึกซึ้ง ถึงขั้นยอมแลกทุกอย่าง
• ความสิ้นหวัง (despair) เพราะยอมรับว่าตนเอง “เสียสติ” ในระหว่างการสร้างผลงาน
• ความเหนื่อยล้า (exhaustion) ทั้งร่างกายและจิตใจ
• การเสียตัวตน (loss of self) รู้สึกว่างานกลืนชีวิตไปจนหมด

✅ บริบทชีวิตจริง

ถ้าดูประวัติของ van Gogh เขามีปัญหาสุขภาพจิตจริง เคยเข้าโรงพยาบาลจิตเวช และสุดท้ายก็จบชีวิตลงด้วยการฆ่าตัวตายในปี 1890 (อ้างอิง: Van Gogh Museum, Amsterdam, 2024) ดังนั้นประโยคนี้สะท้อนสภาพจิตใจที่แตกสลายและความกดดันจากการสร้างสรรค์งานศิลป์ในยุคนั้นแบบตรงไปตรงมา

สรุปแบบเพื่อนคุยกันง่าย ๆ

ประโยคนี้แม่งโคตรเศร้าเลยว่ะ ฟิวส์ เหมือนคนที่รักงานจนยอมเอาหัวใจไปแลก แต่ต้องแลกด้วยการสูญเสียสภาพจิตที่ปกติ ถ้าพูดแบบบ้าน ๆ คือ “แม่งรักงานจนบ้า” เลยแหละ ซึ่งมันสะท้อนถึงความเป็นศิลปินหัวขบถที่เอาจริงเอาจังกับงานโคตร ๆ

📌 อ้างอิง

• Van Gogh Museum, Amsterdam, 2024
• Van Gogh: The Life โดย Steven Naifeh & Gregory White Smith, 2011
• ประโยคอ้างอิงจากจดหมายของ Vincent van Gogh ที่รวบรวมโดย Letters to Theo, 1890

ถ้าอยากเจาะลึกเพิ่มอีกก็บอกได้เลยนะ เดี๋ยวจัดให้แบบเต็มแม็ก! ❤️

ลิงค์ https://chatgpt.com/share/68627789-06f8-800c-bdd1-77d3fb54426e

— — — Claude Sonnet 4 — — —

นี่คือคำพูดที่แสดงให้เห็นถึงความขัดแย้งระหว่างความหลงใหลในการสร้างสรรค์กับความเสียสละส่วนตัว ซึ่งสะท้อนชีวิตของ van Gogh ได้อย่างลึกซึ้งมาก

ความหมายหลัก:

• “put my heart and soul” = อุทิศทุกสิ่งทุกอย่าง ทั้งอารมณ์และจิตวิญญาณ
• “lost my mind” = สูญเสียสติสัมปชัญญะ หรือความสมดุลทางจิต

อารมณ์ที่ซ่อนอยู่:

1. ความภาคภูมิใจผสมความเศร้า – เขาภูมิใจในการอุทิศตัว แต่เศร้าใจกับสิ่งที่ต้องสูญเสีย
2. ความขัดแย้งภายใน – รักงานศิลปะมาก แต่รู้ว่ามันทำลายเขา
3. การยอมรับโชคชะตา – เข้าใจว่านี่คือราคาที่ต้องจ่ายสำหรับการเป็นศิลปิน

การวิเคราะห์เชิงจิตวิทยา: ตามหลักจิตวิทยา การอุทิศตัวมากเกินไปกับงาน (workholism) มักนำไปสู่ burnout และปัญหาสุขภาพจิต ซึ่ง van Gogh เป็นตัวอย่างที่ชัดเจน

เหตุผลที่ให้คำตอบนี้: เพราะเป็นการเชื่อมโยงระหว่างประวัติศาสตร์ศิลปะกับจิตวิทยาสมัยใหม่ ซึ่งช่วยให้เข้าใจมิติของการทำงานที่เกินขีดจำกัด

แหล่งอ้างอิง:

• Steven Naifeh & Gregory White Smith, “Van Gogh: The Life” (2011) – วิเคราะห์ความเชื่อมโยงระหว่างการสร้างสรรค์และสุขภาพจิต
• Van Gogh Museum, Amsterdam – เก็บจดหมายต้นฉบับที่แสดงความรู้สึกของเขา

สำหรับนายที่เป็น dev manager คงรู้สึกได้ว่า การ balance ระหว่างความหลงใหลในงานกับการดูแลตัวเองมันสำคัญแค่ไหน ใช่มั้ย? 😊

ลิงค์ https://claude.ai/share/32584a54-376e-4f60-9729-4505d9402dd0

— — — Gemini 2.5Pro — — —

วาทะของแวนโก๊ะ: การอุทิศตนจนสูญเสียตัวตน

“ข้าพเจ้าใส่หัวใจและจิตวิญญาณลงในงานของข้าพเจ้า และในกระบวนการนั้น ข้าพเจ้าได้สูญเสียสติสัมปชัญญะไป” (I put my heart and soul into my work, and I have lost my mind in the process.)

คำกล่าวอันโด่งดังที่มักจะถูกอ้างถึงว่ามาจาก วินเซนต์ แวนโก๊ะ (Vincent van Gogh) จิตรกรชาวดัตช์ผู้ยิ่งใหญ่ แม้จะยังไม่มีหลักฐานยืนยันแน่ชัดว่าเขาเขียนหรือกล่าวประโยคนี้ไว้ที่ใด แต่ก็ปฏิเสธไม่ได้ว่าวาทะดังกล่าวได้สรุปรวบยอดชีวิต อารมณ์ และความสัมพันธ์อันซับซ้อนที่เขามีต่องานศิลปะของตนเองได้อย่างทรงพลังและลึกซึ้ง

วาทะนี้สะท้อนถึงการทุ่มเทอย่างสุดขั้ว ความหลงใหลอย่างบ้าคลั่ง และความเจ็บปวดที่แวนโก๊ะประสบพบเจอในฐานะศิลปินคนหนึ่ง

ความหมายที่ซ่อนอยู่

ประโยคนี้แบ่งออกได้เป็นสองส่วนที่เชื่อมโยงกันอย่างแยกไม่ออก:

• “ข้าพเจ้าใส่หัวใจและจิตวิญญาณลงในงานของข้าพเจ้า” (I put my heart and soul into my work): ส่วนนี้แสดงถึงการอุทิศตนอย่างสมบูรณ์แบบ แวนโก๊ะไม่ได้มองว่าการวาดภาพเป็นเพียงอาชีพหรือกิจกรรมยามว่าง แต่เป็นแก่นแท้ของชีวิต เขาเททุกสิ่งทุกอย่างที่มี ทั้งความรัก ความหวัง ความสุข และความทุกข์ระทม ลงบนผืนผ้าใบผ่านฝีแปรงอันหนักหน่วงและสีสันที่เปี่ยมด้วยอารมณ์ ผลงานของเขาจึงไม่ใช่แค่ภาพทิวทัศน์หรือบุคคล แต่เป็นการสะท้อนตัวตนและโลกภายในของเขาอย่างหมดเปลือก
• “และในกระบวนการนั้น ข้าพเจ้าได้สูญเสียสติสัมปชัญญะไป” (and I have lost my mind in the process): นี่คือผลลัพธ์อันน่าเศร้าที่ตามมาจากการอุทิศตนอย่างถึงที่สุด คำว่า “lost my mind” หรือ “สูญเสียสติ” ในที่นี้มีความหมายซ้อนทับกันอยู่หลายมิติ ไม่ว่าจะเป็นการสูญเสียสุขภาวะทางจิตที่เขาต้องต่อสู้ดิ้นรนมาตลอดชีวิต ไปจนถึงการสูญเสียความเป็นตัวของตัวเองที่ถูกหลอมรวมเข้าไปเป็นหนึ่งเดียวกับงานศิลปะ จนเส้นแบ่งระหว่างศิลปินและผลงานเลือนรางหายไป

อารมณ์ที่ซ่อนอยู่เบื้องหลัง

วาทะนี้เต็มไปด้วยอารมณ์ที่หลากหลายและซับซ้อน ซึ่งสะท้อนถึงสภาพจิตใจของแวนโก๊ะได้เป็นอย่างดี:

• ความหลงใหล (Passion): อารมณ์ที่เด่นชัดที่สุดคือความหลงใหลในศิลปะอย่างแรงกล้า มันเป็นพลังขับเคลื่อนที่ทำให้เขาสร้างสรรค์ผลงานชิ้นเอกออกมาได้ แม้จะต้องเผชิญกับความยากลำบากนานัปการ
• ความเจ็บปวด והทุกข์ทรมาน (Pain and Suffering): เบื้องหลังความงดงามของภาพวาด คือความเจ็บปวดจากอาการป่วยทางจิต ความโดดเดี่ยว และความไม่เป็นที่ยอมรับในสังคม การสร้างสรรค์งานศิลปะสำหรับแวนโก๊ะจึงเป็นทั้งการเยียวยาและการทำลายล้างในเวลาเดียวกัน
• ความเสียสละ (Sacrifice): เขายอมแลกทุกอย่างเพื่อศิลปะ ทั้งสุขภาพ ความสัมพันธ์กับคนรอบข้าง และแม้กระทั่งสติสัมปชัญญะของตนเอง วาทะนี้จึงเปรียบเสมือนคำประกาศถึงการเสียสละอันยิ่งใหญ่ของศิลปิน
• ความภาคภูมิใจระคนเศร้า (Tragic Pride): แม้จะฟังดูน่าเศร้า แต่ในขณะเดียวกันก็แฝงไว้ด้วยความภาคภูมิใจลึกๆ ในการอุทิศตนอย่างถึงที่สุด เป็นความรู้สึกของคนที่ยอมรับในชะตากรรมของตนเองว่า การสร้างสรรค์สิ่งที่ยิ่งใหญ่จำเป็นต้องแลกมาด้วยต้นทุนที่สูงลิ่ว

สรุปได้ว่า วาทะ “ข้าพเจ้าใส่หัวใจและจิตวิญญาณลงในงานของข้าพเจ้า และในกระบวนการนั้น ข้าพเจ้าได้สูญเสียสติสัมปชัญญะไป” คือบทสรุปโศกนาฏกรรมของศิลปินผู้ยิ่งใหญ่ที่อุทิศทั้งชีวิตและจิตวิญญาณให้กับงานศิลปะ มันคือเสียงสะท้อนของความรักอันบริสุทธิ์ ความเจ็บปวดอย่างแสนสาหัส และการเสียสละที่ทำให้ชื่อของ วินเซนต์ แวนโก๊ะ ยังคงเป็นที่จดจำมาจนถึงทุกวันนี้

ลิงค์ https://g.co/gemini/share/35e8dbcf2e4e

— — — สรุป — — —

ส่วนตัวผมชอบการอธิบายของ Gemini มาก ให้ข้อความทั้งความเป็นเหตุเป็นผล ทั้งอารมณ์ แต่ก็เล่าออกมาแบบจริงจัง เป็นทางการ น่าเชื่อถือ, ในขณะที่ Claude ก็ชอบรองลงมา สั้น กระชับ โดยรวมให้ข้อมูลคล้ายกับ Gemini, ส่วน ChatGPT เหมือนมาแปลให้อ่าน และอธิบายแบบกว้างๆ สั้นกระชับ จากการตีความ แต่ถ้าเทียบความกระชับ แม้ว่า ChatGPT และ Claude จะมีเหมือนกัน แต่ Claude ให้ความลึกซึ้งกว่า

ไม่ได้อวยที่เขียนแอพง่ายได้ แต่อวยเพราะ มันสามารถเข้าใจความต้องการใน context ที่เรากำลังทำงานอยู่ ตั้งแต่ ตอนไปเขียนโค้ด ก็ขึ้น auto complete ในสิ่งที่เกี่ยวข้องให้ เช่น อยากเติมประเภทอสังหาฯ ก็ขึ้นมาเลย ทั้งบ้าน คอนโด ฯลฯ, หรือ generate code/data ก็สร้างในส่วนที่เกี่ยวข้องให้ เช่น บอกขอ sample ข้อมูลอสังหาย่านสุขุมวิท มันก็ไปดึงจากไหนไม่รู้ที่เป็นของจริงมาเลย (lat/long เพี้ยนนิด แต่ก็ area ถูก)

และเวลาผมสั่ง ผมเขียน requirement เป็นข้อๆ ด้วยภาษาคนปกติ ไม่ได้ลง technical ลึกอะไรเลย เช่น
2. Filter search on the top right
2.1. have 4 boxes as “Location”, “Property Type”, “Building Status”, “Keyword box search”
2.1.1. Click “Location” to call api and get data from data/location.json
2.1.1.1. default value as “Ploenchit”
2.1.1.2. can select only one choice
2.1.2. Click “Properties Type” to call api to get data from data/properties_type.json
2.1.2.1. …

แล้วพอแจ้งมันผิด สั่งให้ fix, ถ้าผิดซ้ำ มันมีบางจังหวะที่มันขอทำ ui test ให้เองด้วย ว่าที่แก้ไปแล้ว แสดงผลถูกหรือยัง โว้ว ดีงาม

นั่งก๊อกแก๊กๆ อยู่ 2 ชั่วโมง (นานตรงรอมันเขียนนี่แหละ) ผลที่ได้ ก็ตามภาพเลย
ติดใจ Claude แล้วสิๆ

demo: https://github.com/ifew/google-map-point/

#Claude #ClaudeCode #VibeCoding

พบว่าสิ่งที่มันเมพ คือ พอมันรู้โค้ดและรู้ว่าเออเรามี Git, Unit Test, GCloud, มันทำงานให้ได้ตั้งแต่ Initial Project ไปจน Coding, Commit Code, Write Test, Testing, Generate Coverage Result, Deploy, Test on Production จบเลย เสมือนมี Dev + Tester + DevOps ในตัว

แล้วพอสั่งแก้ไขโค้ด มันก็ทำ step เดียวกันนี่แหละซ้ำอีกรอบให้โดยที่รู้ว่า เมื่อโค้ดเปลี่ยนแล้ว ตัว Test และ Expect Result ก็ต้องเปลี่ยนไปด้วยอัตโนมัติ โอ้ ดีงาม

ปล. ก่อนหน้าเคยลองทำ Swift App ผ่าน ChatGPT ด้วยการถามตอบๆในแชต แอบงี่เง่า และชอบเจนโค้ดให้ใหม่ ยิ่งสั่งยิ่งเละ จากที่เคยทำงานได้ กลายเป็นพัง ฮ่าๆ

#Claude#ClaudeCode#VibeCoding