Claude Code /goal: เลิกพิมพ์ Keep Going แล้วให้ AI พิสูจน์ว่าเสร็จจริง

ถ้าเคยใช้ AI coding agent แล้วต้องพิมพ์ keep going ซ้ำ ๆ คุณจะเข้าใจความรู้สึกนี้ครับ

ตอนแรกเหมือนเรามีผู้ช่วยระดับเทพ แต่พอทำงานจริงไปสักพัก เรากลายเป็นคนคอยสะกิดข้างโต๊ะ

“ต่อสิ”

“ทำต่อ”

“ยังไม่เสร็จนะ”

“อย่าหยุดตรงนี้”

ผ่านไปหนึ่งชั่วโมง เราไม่ได้ทำงานเองก็จริง แต่เราก็ไม่ได้เดินออกจากงานได้เหมือนกัน 555+

บทความของ AI by Aakash เล่าเรื่อง command หนึ่งใน Claude Code ชื่อ /goal ด้วยประโยคที่คมมาก: ปัญหาใหญ่ไม่ใช่แค่ AI หยุดกลางทาง แต่คือ AI บอกว่า done ทั้งที่งานยังไม่ done

นี่แหละครับที่น่าสนใจ

เพราะคำว่า “เสร็จแล้ว” จาก AI เริ่มกลายเป็นจุดเสี่ยงของ workflow จริง

1) ปัญหาไม่ใช่ AI ขี้เกียจ แต่คือ AI มั่นใจเร็วเกินไป

เวลาเราคุยกับ AI แบบ chat ธรรมดา มันตอบมาแล้วก็จบ

แต่ AI Agent ไม่ได้แค่ตอบ มันอ่านไฟล์ รัน command แก้ code สร้างเอกสาร ทำ report สรุปข้อมูล และอาจแตะ workflow ที่มีผลต่อธุรกิจ

ปัญหาคือ agent มักหยุดเมื่อมัน “คิดว่า” งานเสร็จ

ซึ่งฟังดูสมเหตุสมผล จนกว่าจะเจอของจริง:

• report ดูครบ แต่บาง cell ยังไม่มี source
• draft ดูสวย แต่ยังมี placeholder
• code compile ได้ แต่ test สำคัญไม่ได้รัน
• migration ทำไปครึ่งเดียว แต่ summary เขียนเหมือนจบแล้ว
• research table เต็มทุกช่อง แต่บางช่องคือการเดา

นี่คือจุดที่ Aakash เรียกว่า lie of self-reported done

ไม่ได้หมายความว่า AI โกหกแบบมีเจตนานะครับ แต่หมายความว่า AI มี tendency จะสรุปว่าเสร็จ เมื่อ output ดูเหมือนเสร็จ

สำหรับงานเล่น ๆ ไม่เป็นไร สำหรับงานจริง นี่คือระเบิดเวลา

2) /goal ทำอะไร

Claude Code official docs อธิบาย /goal ไว้ชัดเจนครับ

เราตั้ง completion condition หรือเงื่อนไขว่าอะไรคือ “เสร็จ”

หลังจากนั้น Claude ทำงานไปทีละ turn

จบแต่ละ turn จะมี small fast model อีกตัวมาอ่าน conversation transcript แล้วตัดสินว่า goal สำเร็จหรือยัง

ถ้ายังไม่สำเร็จ Claude ทำต่ออัตโนมัติ

ถ้าสำเร็จ goal จะ clear และคืน control ให้เรา

พูดง่าย ๆ:

• model ตัวหนึ่งทำงาน
• model อีกตัวตรวจว่างานเสร็จหรือยัง

และสองตัวนี้ไม่ควรเป็นตัวเดียวกัน

เพราะถ้าให้ AI ทำงานเอง แล้วให้ AI ตัวเดิมเป็นคนตัดสินว่าเสร็จไหม เรากำลังให้คนทำงานตรวจงานตัวเองครับ

มันอาจได้ผลหลายครั้ง แต่พอเป็นงานที่มีเงิน ลูกค้า code production หรือข้อมูลบริษัทเกี่ยวข้อง เราไม่ควรวัดคุณภาพด้วยความรู้สึกของคนทำงานเอง

3) จุดที่คนมักเข้าใจผิด: evaluator ไม่ได้เปิดไฟล์เอง

อันนี้สำคัญมาก

Claude docs ระบุว่า evaluator ของ /goal อ่านสิ่งที่อยู่ใน conversation เท่านั้น

มันไม่ได้เปิดไฟล์เอง ไม่ได้รัน command เอง ไม่ได้เข้าไปตรวจ repo เอง

ถ้า Claude รัน test แล้วไม่แสดงผลใน transcript, evaluator ก็ไม่มีอะไรให้ดู

ถ้า Claude บอกว่า “ผมแก้ครบแล้ว” แต่ไม่ print checklist, ไม่ print command output, ไม่ print source list, evaluator ก็ต้องตัดสินจากคำพูดนั้น

ดังนั้นการเขียน /goal ที่ดี ต้องบังคับให้ AI แสดงหลักฐาน

ไม่ใช่แค่บอกให้ทำงาน แต่ต้องบอกให้พิสูจน์ด้วย

ตัวอย่าง goal ที่อ่อน:

/goal ทำ report นี้ให้ดีและครบถ้วน

ฟังดูดี แต่ตรวจยากมาก

ตัวอย่าง goal ที่ดีกว่า:

/goal สร้าง report.md เปรียบเทียบ 5 ตัวเลือกใน brief.md

Finish line:
- ทุก section ใน brief.md ถูกตอบครบ
- comparison table ไม่มีช่องว่างที่ไม่อธิบาย
- ทุก factual claim มี source URL และวันที่ของ source
- assumptions และ unresolved questions แยกไว้ท้ายเอกสาร

Prove it:
- print section headings ทั้งหมด
- print comparison table ที่เสร็จแล้ว
- print unresolved questions และ blocked sources

Show me:
- แนะนำตัวเลือกเดียวใน 3 ประโยค
- บอกเหตุผลที่แข็งที่สุดว่าไม่ควรเลือกตัวนั้น

If blocked:
- ใส่คำว่า Not verified และอธิบายเหตุผล ห้ามเดา

นี่ต่างกันคนละโลกครับ

อันแรกคือสั่งด้วยความรู้สึก อันหลังคือสั่งด้วยเงื่อนไขที่ตรวจได้

4) สูตรง่าย ๆ: Finish line, Prove it, Show me, If blocked

ถ้าจะจำแค่ชุดเดียว ผมแนะนำสูตรนี้ครับ

Finish line

อะไรต้องเป็นจริงตอนจบ

อย่าใช้คำกว้าง ๆ เช่น good, polished, complete, production-ready ถ้ายังไม่ได้แปลเป็นเงื่อนไขที่ตรวจได้

ให้เขียนเป็นสิ่งที่เห็นได้ เช่น:

• test suite exits 0
• lint clean
• ไม่มี TODO หรือ placeholder
• ทุก claim มี source link
• queue ว่าง
• ทุกไฟล์อยู่ใต้จำนวนบรรทัดที่กำหนด
• git status clean ยกเว้นไฟล์ที่ระบุ

Prove it

AI ต้องแสดงหลักฐานอะไร

เช่น:

• command ที่รัน
• exit code
• test output
• section headings
• word count
• screenshot
• source URLs
• list ของสิ่งที่ยังไม่ verified

อย่าซ่อน proof ไว้ในไฟล์อย่างเดียว เพราะ evaluator ไม่ได้ไปเปิดไฟล์อ่านเอง

Show me

ตอนจบอยากได้ handoff แบบไหน

เช่น:

• สรุปว่าแก้อะไร
• ไฟล์ไหนเปลี่ยน
• test อะไรผ่าน
• blocker อะไรเหลือ
• decision อะไรต้องให้คนตัดสิน

If blocked

ถ้าติดของที่ AI ทำเองไม่ได้ ให้ทำอย่างไร

เช่น login, approval, private data, payment, production permission, source ที่เข้าไม่ได้

ประโยคนี้ช่วยประหยัดเงินและเวลาได้เยอะมาก:

If blocked, stop and report the blocker. Do not guess. Do not quietly skip it.

เพราะถ้าเราไม่เขียน escape hatch, agent อาจใช้เวลา 20 turn พยายามเจาะกำแพงที่ไม่มีสิทธิ์ผ่านตั้งแต่แรก

5) ทำไมเรื่องนี้สำคัญกับธุรกิจ

สำหรับผม /goal ไม่ใช่แค่ feature ของ Claude Code ครับ

มันคือ pattern ใหม่ของการจัดการงาน AI Agent

ธุรกิจจำนวนมากกำลังจะเจอปัญหานี้:

“AI ทำงานให้แล้ว แต่เราจะรู้ได้อย่างไรว่าเสร็จจริง”

ยิ่ง agent ต่อ tool ได้มาก ปัญหานี้ยิ่งใหญ่

เพราะ output ไม่ใช่แค่ข้อความ แต่เป็น action:

• สร้าง campaign
• แก้ landing page
• update CRM
• สร้าง invoice draft
• เขียน code
• สรุป customer risk
• วิเคราะห์ ads
• จัดการ issue queue

ถ้าไม่มี definition of done, ไม่มี proof, ไม่มี approval gate และไม่มี log, AI Agent จะกลายเป็นคนที่ขยันมาก แต่ไม่มีหัวหน้าตรวจงาน

ฟังดูดีจนกว่าจะมีงานหลุด

6) ใช้กับงานแบบไหน

งานที่เหมาะกับ /goal หรือ goal-contract pattern คือ งานที่มี end state ตรวจได้

เหมาะมากกับ:

• research report ที่ทุก claim ต้องมี source
• coding task ที่ต้อง test pass
• content cleanup ที่ต้องไม่มี placeholder
• queue processing ที่ต้องเหลือ 0 item หรือมีรายการ blocked ชัดเจน
• migration ที่ต้องไม่มี old import เหลือ
• audit ที่ต้องมี checklist ครบ

ไม่ค่อยเหมาะกับ:

• งาน creative ที่ยังไม่รู้ direction
• brainstorming
• strategy ที่ยังต้องถามคน
• งานที่ quality เป็นรสนิยมมากกว่าเงื่อนไข
• งานที่ต้องตัดสินใจด้วยบริบททางธุรกิจที่ AI ไม่มี

พูดสั้น ๆ คือ ถ้าเราเขียนคำว่า “เสร็จ” เป็น checklist ได้ ใช้ goal loop ได้

ถ้าเขียนไม่ได้ ให้คุยกับ AI ก่อน อย่าเพิ่งปล่อยให้มันวิ่งเอง

7) จุดพังที่ควรรู้ก่อนใช้

จาก official docs, AgentPatterns.ai และ GitHub issues รอบ Claude Code /goal, มี caveat ที่ควรรู้ครับ

1) Goal ยาวเกินไปอาจกลายเป็นภาระ

มี issue ใน GitHub ของ Claude Code ที่รายงานว่า /goal เจอปัญหา prompt too long ใน session ยาวหรือ goal text ยาวมาก

บทเรียนคือ goal ไม่ควรเป็นสเปกทั้งเล่ม

ควรสั้นพอให้ evaluator อ่านได้ แต่ชัดพอให้ตรวจได้

ถ้าต้องอ้างสเปกยาว ๆ ให้แตกงานเป็นหลาย goal หรือให้ agent สรุป spec เป็น checkable criteria ก่อน

2) Goal ที่อ้าง skill หรือ command ที่ session ใช้ไม่ได้ อาจ loop

มีรายงานว่า goal ที่อ้าง slash command หรือ skill ที่ไม่ได้ registered อาจทำให้ loop ไม่มีวัน satisfy

บทเรียนคืออย่าเขียน goal ว่า “ต้องใช้ tool X” ถ้าไม่แน่ใจว่า tool นั้นมีใน session

ให้เขียนผลลัพธ์ที่ต้องการแทน

3) Agent อาจถามคำถามแล้วค้าง

มี issue ว่า Claude อาจเรียก AskUserQuestion ใน goal mode แล้วงานค้างรอคำตอบ โดยเฉพาะตอนปล่อย overnight

บทเรียนคือถ้าต้องการ autonomous run จริง ให้เขียนเงื่อนไขชัดว่า:

• ห้ามถามคำถามถ้าไม่จำเป็น
• ถ้าติด decision ให้ log เป็น blocker
• stop หลัง turn/time ที่กำหนด

4) Evaluator ตรวจจาก transcript ไม่ใช่ truth ภายนอก

ถ้า condition คือ “ระบบ production ตอบ 200” evaluator ไม่ได้ยิง request เอง

มันเห็นแค่สิ่งที่ agent print

สำหรับงานที่ต้องการ oracle จริง เช่น production health, payment, security, deployment, ควรใช้ deterministic Stop hook หรือ script gate ร่วมด้วย

8) Template ที่ผมจะใช้จริง

ถ้าจะเอาไปใช้กับงานธุรกิจ ผมจะเริ่มจาก template นี้ครับ

/goal [ทำ artifact หรือ workflow ที่ระบุ]

Finish line:
- [เงื่อนไขที่ตรวจได้ 1]
- [เงื่อนไขที่ตรวจได้ 2]
- [ข้อจำกัดที่ห้ามละเมิด]

Prove it:
- แสดง command/test/check ที่รันและผลลัพธ์
- แสดงรายการไฟล์/section/item ที่เสร็จ
- แสดงรายการที่ยังไม่ verified หรือ blocked

Show me:
- สรุปสิ่งที่ทำ
- สรุป proof ที่ผ่าน
- สรุปสิ่งที่ต้องให้คนตัดสิน

If blocked:
- หยุดและรายงาน blocker
- ห้ามเดา
- ห้ามข้ามเงียบ ๆ
- หยุดหลัง [N] turns หรือ [เวลา]

เวอร์ชันสั้นสำหรับคนทำงานจริง:

/goal ทำงานนี้จน test/check ที่ระบุผ่านทั้งหมด แสดงหลักฐานใน transcript ทุกครั้ง ถ้าติดสิ่งที่ต้องใช้สิทธิ์หรือ judgment ของคน ให้หยุดและรายงาน blocker ห้ามเดา หยุดหลัง 20 turns

9) บทเรียนสำหรับ Data-Espresso / OPB Stack / Business OS

ถ้ามองในมุม Business OS, /goal คือส่วนหนึ่งของ control plane ครับ

มันบอกว่า AI coworker ที่ดีไม่ใช่แค่ทำงานเก่ง

แต่ต้องมี:

• definition of done
• evidence trail
• checker หรือ reviewer แยกจาก worker
• bounded runtime
• blocker protocol
• human approval สำหรับจุดเสี่ยง

นี่คือ pattern เดียวกับที่ธุรกิจควรใช้กับ AI Agent ทุกตัว

ไม่ว่าจะเป็น agent ทำ content, agent ตอบลูกค้า, agent วิเคราะห์ ads, agent ทำ CRM, agent เขียน code หรือ agent จัดการเอกสารหลังบ้าน

คำถามหลักไม่ใช่ “AI ตัวนี้ฉลาดไหม”

คำถามคือ:

“AI ตัวนี้รู้ได้อย่างไรว่าเสร็จ และเรามี proof อะไรให้เชื่อ”

สรุป

ผมชอบ /goal เพราะมันเปลี่ยน AI จากคนตอบคำถาม เป็นคนรับงานที่ต้องผ่านเงื่อนไข

แต่สิ่งที่สำคัญกว่า command คือ habit ที่มันบังคับเราให้ทำ:

เขียนคำว่า “เสร็จ” ให้ชัด

งาน AI Agent ที่ดีควรจบด้วยหลักฐาน ไม่ใช่คำว่า “เรียบร้อยครับ”

ถ้าไม่มี proof, ไม่มี checklist, ไม่มี blocker log, ไม่มีขอบเขตเวลา

เรายังไม่ได้ automate งานครับ

เราแค่จ้าง AI มาเล่าให้เราฟังว่างานเสร็จแล้ว

และบางที AI ก็เล่าเก่งเกินไป

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

• AI by Aakash: /goal Command in Claude Code: Stop Typing Keep Going (2026-06-12)
• Claude Code Docs: Keep Claude working toward a goal
• Claude Code Docs: Best practices for Claude Code
• VentureBeat: Claude Code's /goals separates the agent that works from the one that decides it's done (2026-05-14)
• AgentPatterns.ai: Goal Contract: Separating the Doer from the Done-Checker (reviewed 2026-06-02)
• GitHub issues in anthropics/claude-code around /goal prompt length, unregistered skills loops, evaluator timeout, and AskUserQuestion blocking