Plan Mode ใน Claude Code: คู่มือทีละขั้นตอนและ 4 ขั้นตอนในปี 2026

ดูคำแนะนำเพิ่มเติมได้ในเอกสารของ Ailoot

Plan Mode คืออะไร และทำไมใช้เพียงอย่างเดียวจึงยังไม่พอ?#

ในโหมดปกติ Claude Code เขียนโค้ดทันที และหากคุณไม่ได้คอยติดตาม ก็อาจได้ diff ที่ครอบคลุมหลายไฟล์โผล่มาโดยไม่ทันตั้งตัว Plan Mode สลับลำดับขั้นตอน: วิจัยและวางแผนก่อน จากนั้นอนุมัติ แล้วจึงค่อยเปลี่ยนแปลง

Anthropic อธิบาย Plan Mode ไว้ในเอกสารทางการดังนี้:

ฟังดูเรียบง่าย แต่มีการเปลี่ยนแปลงสำคัญซ่อนอยู่ Plan Mode เปลี่ยนจังหวะการทำงาน: ตกลงกันก่อน แล้วค่อยลงมือ เป็นการเปลี่ยนโหมด ไม่ใช่แค่ปรับแต่งเล็กน้อย ปัญหาของนักพัฒนาสาย vibe coding คือ AI agent มักรีบร้อน หากคุณขอว่า “Add Google authentication” ในโหมดปกติ Claude จะเขียนโค้ดเสร็จในหนึ่งนาที แต่ไฟล์ครึ่งหนึ่งจะเป็นไฟล์ผิด ใน Plan Mode คำขอเดียวกันจะกลายเป็นแผนข้อความที่คุณอ่านได้ภายในสองนาทีและแก้ไขก่อนแตะต้องโค้ด

นี่คือกับดักที่แทบไม่มีใครเขียนถึงในคู่มือภาษาต่างประเทศ Plan Mode เพียงอย่างเดียวเป็นเครื่องมือที่อ่อนแอ: แผนมีอยู่แค่ในการสนทนาปัจจุบัน ปิดหน้าต่างแล้วแผนก็หายไป คุณส่งต่องานให้ agent ตัวอื่นไม่ได้ ไม่มีเวอร์ชันหรือประวัติ หากงานใหญ่ (ปรับโครงสร้างโมดูล 30 ไฟล์ หรือย้ายไปฐานข้อมูลใหม่) แผนจะชนเพดานหน้าต่างบริบทอย่างรวดเร็วและเริ่มเสื่อมคุณภาพ

นี่จึงเป็นเหตุผลที่ Plan Mode ทำงานได้ดีเมื่อใช้คู่กับโฟลเดอร์ plans/ ใน repository แผนจะถูกบันทึกเป็น plans/2026-05-21-google-oauth.md และแบ่งเป็นขั้นตอนพร้อมช่องทำเครื่องหมาย agent ตัวถัดไปก็สามารถรับช่วงต่อได้ นี่คือวิธีทำงานของวิศวกรรมบริบท—จัดการบริบทก่อนพรอมป์ต์ ไม่ใช่ระหว่างพรอมป์ต์

เปิดใช้ Plan Mode ใน Claude Code อย่างไร?#

วิธีที่เร็วที่สุดระหว่างเซสชันคือใช้แป้นพิมพ์:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

หลังจากกดสองครั้ง ตัวบ่งชี้ ⏸ plan mode on จะปรากฏที่ด้านล่างของเทอร์มินัล กดครั้งที่สามเพื่อกลับสู่โหมดปกติ วิธีนี้สะดวกที่สุด—คุณสลับโหมดได้ทันทีเมื่อเห็นว่างานเริ่มขยายใหญ่ขึ้น

วิธีที่สองคือเพิ่มคำนำหน้าก่อนพรอมป์ต์เดียว:

/plan write a plan to migrate the database from MySQL to Postgres

วิธีนี้มีประโยชน์เมื่อคุณใช้โหมด auto-accept และไม่ต้องการเปลี่ยนโหมดตลอดทั้งเซสชัน ใช้ Plan Mode กับคำขอเดียว แล้วทำงานต่อเหมือนเดิม

วิธีที่สามคือกำหนดตอนเริ่มเซสชัน:

claude --permission-mode plan

ใช้วิธีนี้เมื่อรู้ล่วงหน้าว่างานต้องมีการวางแผน เช่น ก่อนการปรับโครงสร้างครั้งใหญ่หรือการย้ายระบบ

วิธีที่สี่คือกำหนดค่าเริ่มต้นใน .claude/settings.json ของโปรเจกต์:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

วิธีนี้มีประโยชน์เมื่อใด? เมื่อทีมทำงานกับระบบซับซ้อนที่การเปลี่ยนแปลงใด ๆ อาจกระทบโมดูลข้างเคียง การตั้ง Plan Mode เป็นค่าเริ่มต้นจะช่วยปกป้องทุกคนจากการเปลี่ยนแปลงโดยไม่ตั้งใจ

เคล็ดลับข้อที่ห้าที่มักถูกมองข้าม: Ctrl+G เปิดแผนในโปรแกรมแก้ไขข้อความ ใช้เมื่อแผนเกือบถูกต้องแล้ว แต่ต้องปรับถ้อยคำ 2-3 จุดหรือเพิ่มข้อจำกัด แก้ไขด้วยตนเอง บันทึก แล้ว Claude จะทำงานต่อด้วยเวอร์ชันของคุณ

4 ขั้นตอนมาตรฐานของ Anthropic ใน Plan Mode ได้แก่ Explore, Plan, Implement และ Commit อย่างไร?#

คู่มือหลายฉบับอธิบายสามขั้นตอน (Explore-Plan-Execute) หรือเพียงสองขั้นตอน (Plan-Implement) ซึ่งเป็นการย่อ ในคู่มือแนวปฏิบัติที่ดีที่สุดอย่างเป็นทางการ Anthropic อธิบายไว้ครบทั้ง 4 ขั้นตอน ความแตกต่างนี้สำคัญ: การแยก Commit เป็นขั้นตอนต่างหากทำให้คุณบันทึกผลลัพธ์ แทนที่จะปล่อยค้างไว้ที่ “ฉันปรับอีกนิดหน่อย ไว้ค่อย commit ทีหลัง”—ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดของงานสูญหาย

ยิ่งแผนแม่นยำมากเท่าใด การทำงานจริงก็ยิ่งต้องแก้ซ้ำน้อยลง หากใช้เวลา 10 นาทีวางแผน การทำงานจริงจะใช้พรอมป์ต์เดียว หากร่างแผนในหนึ่งนาที การทำงานจริงจะใช้เวลาหนึ่งชั่วโมงไปกับการแก้ไข

ตัวอย่าง 4 ขั้นตอนสำหรับการเพิ่ม Google OAuth (ตัวอย่างจาก Anthropic Docs):

พรอมป์ต์ในแต่ละขั้นตอนก็แตกต่างกันด้วย ใน Explore: “read /src/auth and understand how we handle sessions and login”. ใน Plan: “I want to add Google OAuth. What files need to change? Create a plan”. ใน Implement: “implement the OAuth flow from your plan, write tests, run the suite and fix failures”. ใน Commit: “commit with a descriptive message and open a PR”.

ข้อควรรู้สำคัญ: Plan Mode ไม่ได้ห้าม Claude รันคำสั่งเพื่อการวิจัย อนุญาตให้ใช้ Read, LS, Glob, Grep, web fetch และคำสั่ง shell เพื่อสำรวจได้ ห้ามใช้เฉพาะ Edit, Write และการดำเนินการกับระบบไฟล์ที่เปลี่ยนแปลงข้อมูลเท่านั้น นั่นหมายความว่า Claude อ่านโครงสร้างโปรเจกต์ รัน git log และดูการทดสอบได้—แต่จะเปลี่ยนแปลงอะไรโดยไม่ตั้งใจไม่ได้

อ่านแผนของ Claude และตัดสินใจอนุมัติอย่างไร?#

เมื่อ Claude สร้างแผนเสร็จ จะแสดงตัวเลือกสำหรับขั้นต่อไป:

• อนุมัติและเริ่มในโหมดอัตโนมัติ
• อนุมัติและยอมรับการแก้ไข
• อนุมัติและตรวจสอบการแก้ไขแต่ละรายการด้วยตนเอง
• วางแผนต่อพร้อมให้คำติชม
• ปรับปรุงด้วย Ultraplan (รีวิวในเบราว์เซอร์)

การรู้ว่าควรอนุมัติแผนหรือไม่คือทักษะสำคัญใน Plan Mode การกด “Approve” โดยอัตโนมัติแล้วต้องย้อนกลับ commits ในภายหลังเกิดขึ้นได้ง่าย AI ที่คอยเอาใจอยากตอบให้เร็ว ส่วนคุณก็อยากไปถึงขั้นเขียนโค้ดให้เร็วขึ้น ทั้งคู่คิดผิด

แผนที่ดีมีคุณสมบัติ 7 ข้อ:

1. ชื่อไฟล์เฉพาะเจาะจง ไม่ใช่ “ฉันจะอัปเดต auth” แต่เป็น “ฉันจะแก้ src/auth/login.ts:42-58 สร้าง src/auth/oauth-callback.ts และอัปเดต src/auth/session.ts:103”
2. ระบุลำดับขั้นตอน แผนแบ่งออกเป็นช่วงหรือขั้นตอน แทนที่จะบอกว่า “ฉันจะทำทั้งหมดนี่สักทาง”
3. ระบุการพึ่งพาภายนอก หากต้องใช้ไลบรารีใหม่ ให้ระบุไว้ หากต้องใช้ตัวแปรสภาพแวดล้อม ก็ต้องระบุไว้เช่นกัน
4. ระบุความเสี่ยง แผนที่ดีบอกว่า “การย้ายข้อมูลอาจทำให้เซสชันที่มีอยู่ใช้งานไม่ได้ ต้องตรวจสอบ X” ส่วนแผนที่ไม่ดีไม่กล่าวถึงผลข้างเคียง
5. มีเกณฑ์ความสำเร็จ “การทดสอบ test/auth ผ่าน, linter ไม่มีปัญหา และเซิร์ฟเวอร์ dev เริ่มทำงานได้โดยไม่มีข้อผิดพลาด”
6. ไม่มีข้อสมมติที่คิดขึ้นเอง หาก Claude พูดว่า “ฉันจะใช้ไลบรารี Z” ให้ตรวจสอบว่าได้ติดตั้งในโปรเจกต์แล้วหรือยัง หาก AI คิดขึ้นมาเอง คุณจะเห็นว่าไม่มีไลบรารีนี้ใน package.json
7. แผนอ่านจบได้ภายในหน้าจอ หากแผนสำหรับฟีเจอร์ง่าย ๆ ยาวถึง 200 บรรทัด งานนั้นอาจใหญ่เกินกว่าจะใช้แผนเดียว แบ่งออกเป็นส่วน ๆ

หากแผนไม่ผ่านเกณฑ์ มีสามทางเลือก:

• วางแผนต่อพร้อมให้คำติชม—แสดงความคิดเห็นเฉพาะเจาะจงกับ Claude ว่าไม่ชอบตรงไหน แล้ว Claude จะเขียนแผนใหม่
• Ctrl+G—เปิดแผนใน editor แก้ไขด้วยตนเอง แล้วบันทึก Claude จะทำงานต่อด้วยเวอร์ชันของคุณ
• ปรับปรุงด้วย Ultraplan—แผนจะไปอยู่ในโหมดเบราว์เซอร์ของ Claude Code บนเว็บ คุณจะรีวิวแต่ละส่วนและแสดงความคิดเห็น จากนั้นจึงรันในเครื่องหรือบนคลาวด์

หากมีอะไรผิดพลาดกลางคันระหว่างการทำงาน อย่าฝืนทำต่อ กลับไปที่ Plan Mode แล้วเขียนแผนใหม่ วิธีนี้ถูกกว่าการย้อนกลับ 40 commits ในภายหลังถึง 10 เท่า

Plan Mode + โฟลเดอร์ plans/: การผสมผสานเพื่อทำงานกับบริบทยาว#

Plan Mode เป็นโหมดของ Claude Code ส่วนโฟลเดอร์ plans/ คือระเบียบวิธีที่สร้างขึ้นบนโหมดนี้ หากใช้ Plan Mode โดยไม่มีโฟลเดอร์ คุณจะชนเพดานหลังทำงานไปหนึ่งชั่วโมง

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

ทางแก้คือกฎทอง: หนึ่งงาน—หนึ่งบทสนทนา

ทำตามนี้:

1. บทสนทนา 1—จัดทำแผน เปิด Plan Mode อธิบายงาน แล้ว Claude จะสร้างแผน บันทึกแผนไว้ที่ plans/2026-05-21-feature-name.md จากนั้นปิดหน้าต่าง
2. บทสนทนา 2—แบ่งเป็นขั้นตอน เปิดแชตใหม่ ขอว่า “take plans/2026-05-21-feature-name.md and divide it into phases.” บันทึกไฟล์ที่อัปเดตแล้ว
3. บทสนทนา 3—ดำเนินการขั้นที่ 1 เปิดแชตใหม่ ขอว่า “implement Phase 1 from plans/2026-05-21-feature-name.md, and check off items as you complete them.” จากนั้นปิดหน้าต่าง
4. บทสนทนา 4—ดำเนินการขั้นที่ 2 ทำแบบเดียวกัน

วิธีนี้ช่วยอะไร? หน้าต่างบริบทของแต่ละบทสนทนายังคงสดใหม่ Claude ในขั้นที่ 3 ไม่รู้รายละเอียดของขั้นที่ 1 แต่รู้จักแผนเพราะไฟล์ plans/ อยู่ใน repository agent ตัวถัดไป (ไม่ว่าจะเป็น subagent เซสชันใหม่ หรือการรันผ่าน /goal) ก็สามารถรับช่วงต่อจากแผนได้

เปรียบเทียบแนวทาง:

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

นี่คือแผนงานที่มีชีวิต ส่วนเอกสารแบบคงที่ล้าสมัยภายในเวลาไม่กี่เดือน

ให้ Claude ทำงานขณะที่คุณหลับด้วย Plan Mode และ /goal ได้อย่างไร?#

ข้อจำกัดหลักของเซสชัน AI ที่ยาวนานไม่ได้อยู่ที่ตัวโมเดล แต่อยู่ที่คนที่กด Enter ทุกครั้งที่ Claude ทำงานจบหนึ่งเทิร์น ก็จะรอคำตอบจากคุณ /goal ช่วยเอาการรอนั้นออกไป

ไวยากรณ์นั้นเรียบง่าย:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

เงื่อนไขมีได้สูงสุด 4000 อักขระ หนึ่ง goal ต่อหนึ่งเซสชัน หลังแต่ละเทิร์น โมเดล Haiku ขนาดเล็กจะดู transcript แล้วตัดสินใจว่า “เงื่อนไขครบแล้ว—จบ” หรือ “ยังไม่ครบ—ไปเทิร์นถัดไป” evaluator ไม่เรียกใช้เครื่องมือ แค่อ่านเท่านั้น

alias สำหรับล้างค่า: /goal stop, /goal off, /goal reset, /goal none, /goal cancel

การใช้ร่วมกับ Plan Mode มีลักษณะดังนี้:

1. เปิด Plan Mode (กด Shift+Tab สองครั้ง)
2. ขอว่า “create a plan to migrate the database from MySQL to Postgres, save it to plans/2026-05-21-postgres-migration.md with phases and criteria.”
3. ตรวจทานแผน แก้ไข และอนุมัติ
4. ออกจาก Plan Mode (กด Shift+Tab อีกครั้ง)
5. ตั้ง goal: “complete all phases in plans/2026-05-21-postgres-migration.md, check off the boxes, all tests pass, or stop after 50 turns.”
6. ปิดแล็ปท็อปแล้วเข้านอน

ตอนเช้า ตรวจสอบผลลัพธ์: อาจเป็น “✓ goal completed” หรือ “◎ stopped after 50 turns” พร้อมประวัติของสิ่งที่ทำไป

มีกฎสำคัญสามข้อสำหรับ /goal มิฉะนั้นคุณจะเปลือง tokens:

กฎ 1: สถานะสุดท้ายที่วัดผลได้ “Make it look nice” เป็นเงื่อนไขที่ไม่ดี ส่วน “npm test ส่งคืนค่า 0, npm run lint ส่งคืนค่า 0 และมีการเพิ่มรายการใน CHANGELOG.md” เป็นเงื่อนไขที่ดี

กฎ 2: ตรวจสอบได้อย่างชัดเจน เงื่อนไขควรอ้างถึงสิ่งที่ตรวจสอบได้ เช่น คำสั่ง ไฟล์ หรือ endpoint ไม่ใช่ “ทุกอย่างใช้งานได้” แต่เป็น “curl localhost:3000/api/users returns 200”

กฎ 3: จำกัดจำนวนเทิร์น เพิ่ม or stop after N turns เสมอ Anthropic แนะนำไว้อย่างชัดเจนในเอกสาร:

หากเปิด /goal โดยไม่มี or stop after งบประมาณของคุณอาจหมดไปในชั่วข้ามคืน

วงจร 4 ขั้นตอนแบบใดเปลี่ยน Plan Mode ให้เป็นกระบวนการทางวิศวกรรม?#

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

วงจร 4 ขั้นตอนช่วยหยุดพฤติกรรมนี้ ใช้ตามลำดับภายในเซสชัน Plan Mode เดียว:

ขั้นตอนที่ 1 ตรวจสอบข้อเท็จจริงโดยไม่เสนอทางแก้

พรอมป์ต์: “ฉันกำลังพบสิ่งต่อไปนี้: [คำอธิบายอาการ] งานของคุณตอนนี้คือการตรวจสอบข้อเท็จจริง ห้ามเสนอทางแก้ ความคิด หรือคำแนะนำใด ๆ มีเพียง: สิ่งที่ฉันสังเกตเห็น ขั้นตอนที่ทำซ้ำได้ ข้อมูลที่มี และข้อมูลที่ขาด เงื่อนไขหยุดที่เด็ดขาด: ห้ามเสนอทางแก้ ให้บันทึกเฉพาะการวินิจฉัยเท่านั้น”

วิธีนี้หยุดแรงกระตุ้นแรกของ AI: “นี่คือทางแก้” Claude ต้องหยุดอยู่ที่ “รู้อะไรแล้วบ้าง และอะไรยังไม่รู้”

ขั้นตอนที่ 2 พัฒนาทางเลือกโดยอ้างอิงแนวทางที่ผ่านมา

พรอมป์ต์: “เมื่อวินิจฉัยปัญหาแล้ว ให้ค้นหาแนวทางจากกรณีก่อนหน้าในการแก้ปัญหาคล้ายกันทางออนไลน์ อย่างน้อย 3 วิธีที่แตกต่างกัน สำหรับแต่ละวิธี: ลิงก์ไปยังแหล่งข้อมูลหลัก คำอธิบายสั้น ๆ และข้อดีข้อเสียสำหรับสถานการณ์ของเรา”

วิธีนี้หยุดแรงกระตุ้นที่สองของ AI: “คิดวิธีแก้ขึ้นมาเองทันที” เราให้มันออกไปค้นคว้าแล้วกลับมาพร้อมแนวทางที่ตรวจสอบได้

ขั้นตอนที่ 3 วางแผนอย่างละเอียดพร้อมความเสี่ยง

พรอมป์ต์: “เลือกทางเลือกที่ดีที่สุดจากขั้นตอนที่ 2 แล้วร่างแผนอย่างละเอียด: ต้องแก้ไฟล์ใดโดยเฉพาะ เพิ่มอะไร ลบอะไร เขียนการทดสอบอะไร อะไรอาจพัง และมีความเสี่ยงอะไรในอีก 2-3 ขั้นตอนข้างหน้า”

นี่คือขั้น Plan ที่คุ้นเคย แต่มีข้อแตกต่างหนึ่งอย่าง: แผนนี้อ้างอิงทางเลือกที่ตรวจสอบแล้วจากขั้นตอนที่ 2 ไม่ใช่การคาดเดาของ Claude

ขั้นตอนที่ 4 ตรวจสอบแผนด้วยตนเอง

พรอมป์ต์: “ตอนนี้ให้ตรวจสอบด้วยตนเองอย่างเคร่งครัด ตรวจทานแผนอย่างตรงไปตรงมาอีกครั้ง: มีส่วนใดที่คุณคิดขึ้นเองโดยไม่ได้ตรวจสอบกับโค้ด เอกสาร หรือแนวทางที่พบในขั้นตอนที่ 2 หรือไม่? หากมี ให้ทำเครื่องหมายและแก้ไขแผน”

นี่คือตัวกรองขั้นสุดท้าย Claude ต้องตรวจสอบเหตุผลของตัวเองและยอมรับจุดที่หลอนข้อมูล โดยปกติจะมีการปรับรายการในแผนอย่างน้อย 2 รายการในขั้นตอนนี้

เมื่อทำครบทั้ง 4 ขั้นตอน แผนก็พร้อมสำหรับการอนุมัติ คุณเริ่มลงมือได้อย่างมั่นใจว่าเข้าใจงานแล้ว พิจารณาทางเลือกแล้ว และคิดถึงความเสี่ยงแล้ว

วิธีนี้มีไว้สำหรับวินิจฉัยบั๊กยาก ๆ และตัดสินใจด้านสถาปัตยกรรม—งานที่ความผิดพลาดมีต้นทุนสูง เมื่อนำมาใช้กับ Plan Mode ก็ช่วยขจัดปัญหาหลักของนักพัฒนาสาย vibe coding: “AI ให้ทางแก้มา ฉันเอาไปใช้ แล้วทุกอย่างก็พัง”

พรอมป์ต์พร้อมใช้ 5 แบบใดเหมาะกับงานทั่วไปใน Plan Mode?#

เทมเพลต 1 การปรับโครงสร้างโมดูล

ฉันกำลังเปิดใช้ Plan Mode งาน: ปรับโครงสร้างโมดูล {module-name}

ขั้นตอนที่ 1: ศึกษาโครงสร้างปัจจุบันของโมดูล {module-path} อธิบาย:
- ไฟล์ใดบ้างที่เป็นส่วนหนึ่งของโมดูล
- มีการพึ่งพาภายนอกอะไรบ้าง
- ส่วนใดซ้ำกัน
- ฟังก์ชันใดซับซ้อนเกินไป

ขั้นตอนที่ 2: ค้นหาตัวอย่างการปรับโครงสร้างโมดูลลักษณะคล้ายกันทางออนไลน์ 2-3 ตัวอย่าง
แหล่งข้อมูลอย่างน้อย 1 แห่งต้องเป็นเอกสารทางการของ Anthropic หรือเอกสารของ framework ที่เกี่ยวข้อง

ขั้นตอนที่ 3: สร้างแผนปรับโครงสร้างใน plans/YYYY-MM-DD-refactor-{module}.md:
- ไฟล์ใดที่ต้องเปลี่ยนชื่อ
- ฟังก์ชันใดที่ต้องแยกไปเป็นโมดูลต่างหาก
- การทดสอบใดที่ควรเก็บไว้และการทดสอบใดที่ต้องเขียนใหม่
- ความเสี่ยง: อะไรอาจพังสำหรับผู้ใช้

ขั้นตอนที่ 4: ตรวจสอบด้วยตนเอง มีข้อสมมติใดในแผนที่คิดขึ้นเองหรือไม่?
เขียนใหม่หรือลบออก

เทมเพลต 2 การย้ายฐานข้อมูล

ฉันกำลังเปิดใช้ Plan Mode งาน: ย้ายฐานข้อมูลจาก {old} ไปยัง {new}

ขั้นตอนที่ 1: ศึกษาสคีมาฐานข้อมูลปัจจุบันโดยใช้ {schema-reading-command} อธิบาย:
- มีตารางใดบ้างและมีขนาดเท่าใด
- มีความสัมพันธ์ ดัชนี และข้อจำกัดใดบ้าง
- เก็บ migrations ไว้ที่ไหน
- ข้อมูลใดสำคัญ

ขั้นตอนที่ 2: ค้นหาแนวทางการย้าย {old → new} ในโปรเจกต์ production
อย่างน้อย 3 วิธีที่แตกต่างกัน: pg_dump, dual-write, blue-green
ระบุข้อดีและความเสี่ยงของแต่ละวิธีสำหรับปริมาณข้อมูลของเรา

ขั้นตอนที่ 3: สร้างแผนการย้ายใน plans/YYYY-MM-DD-db-migration.md:
- ขั้นตอนต่าง ๆ (สำรองข้อมูล, ย้ายข้อมูล, ตรวจสอบ, สลับระบบ)
- เกณฑ์ความสำเร็จของแต่ละขั้นตอน
- แผนย้อนกลับหากเกิดปัญหา
- ต้องหยุดระบบหรือไม่

ขั้นตอนที่ 4: ตรวจสอบด้วยตนเอง ตัวเลขทั้งหมดมีเอกสารรองรับหรือไม่?
ได้ตรวจสอบทุกขั้นตอนเทียบกับสภาพแวดล้อม dev ในใจแล้วหรือยัง?

เทมเพลต 3 การเพิ่มฟีเจอร์ใหม่

ฉันกำลังเปิดใช้ Plan Mode งาน: เพิ่มฟีเจอร์ {description} ให้กับโปรเจกต์

ขั้นตอนที่ 1: ศึกษาวิธีทำงานของฟีเจอร์ลักษณะคล้ายกันในโปรเจกต์ปัจจุบัน
ดูสิ่งเหล่านี้โดยเฉพาะ:
- {file-1}
- {file-2}
- รูปแบบสถาปัตยกรรมที่ใช้
- การทดสอบที่เขียนสำหรับฟีเจอร์ลักษณะคล้ายกัน

ขั้นตอนที่ 2: ค้นหาวิธีนำฟีเจอร์นี้ไปใช้ในโปรเจกต์โอเพนซอร์ส
ที่มีสถาปัตยกรรมคล้ายกัน อย่างน้อย 2 วิธีที่แตกต่างกัน

ขั้นตอนที่ 3: สร้างแผนใน plans/YYYY-MM-DD-feature-{name}.md:
- รายการไฟล์ใหม่
- รายการไฟล์ที่เปลี่ยนแปลงพร้อมบรรทัดที่ระบุชัดเจน
- ลำดับการดำเนินการ
- การทดสอบที่ต้องเพิ่ม
- สิ่งที่ต้องเพิ่มลงใน CLAUDE.md เป็นกฎสำหรับเซสชันในอนาคต

ขั้นตอนที่ 4: ตรวจสอบด้วยตนเอง แผนนี้สอดคล้องกับสถาปัตยกรรมของโปรเจกต์หรือไม่?
แผนตั้งสมมติฐานเกี่ยวกับไลบรารีที่ยังไม่ได้ติดตั้งหรือไม่?

เทมเพลต 4 การเขียนการทดสอบ

ฉันกำลังเปิดใช้ Plan Mode งาน: เขียนการทดสอบให้ครอบคลุมโมดูล {name}

ขั้นตอนที่ 1: ศึกษาโมดูล {path} ระบุ:
- ฟังก์ชันสาธารณะและ signatures ของฟังก์ชัน
- ฟังก์ชันภายในที่เราจะไม่ทดสอบ (รายละเอียดการทำงานภายใน)
- กรณีขอบ: อินพุตว่าง ข้อผิดพลาด การเข้าถึงพร้อมกัน

ขั้นตอนที่ 2: ค้นหาตัวอย่างการทดสอบสำหรับงานประเภทคล้ายกัน
ในโปรเจกต์โอเพนซอร์สยอดนิยมที่ใช้ framework เดียวกัน

ขั้นตอนที่ 3: สร้างแผนการทดสอบใน plans/YYYY-MM-DD-tests-{module}.md:
- รายการทดสอบสำหรับฟังก์ชันสาธารณะแต่ละตัว
- ต้องใช้ mocks ใดบ้าง
- ต้องใช้ fixtures ใดบ้าง
- วิธีตรวจสอบแบบใด (รูปแบบ assertion)

ขั้นตอนที่ 4: ตรวจสอบด้วยตนเอง การทดสอบทุกข้อเช็กพฤติกรรมแทนที่จะเช็กรายละเอียดการทำงานภายในหรือไม่?
ครอบคลุมกรณีขอบแล้วหรือยัง?

เทมเพลต 5 การดีบักข้อผิดพลาดซับซ้อน

ฉันกำลังเปิดใช้ Plan Mode งาน: ทำความเข้าใจสาเหตุของข้อผิดพลาด {symptom-description}

ขั้นตอนที่ 1: ตรวจสอบข้อเท็จจริง ห้ามเสนอทางแก้หรือความคิด มีเพียง:
- สิ่งที่ฉันสังเกตเห็น (ข้อความข้อผิดพลาดที่แน่นอน)
- ขั้นตอนที่ทำซ้ำได้
- ข้อมูลที่มี (logs, traces, เวอร์ชันไลบรารี)
- ข้อมูลที่ขาด (สิ่งที่ต้องเก็บเพิ่ม)

ขั้นตอนที่ 2: ค้นหาแนวทางที่ผ่านมาเกี่ยวกับข้อผิดพลาดนี้
อย่างน้อย 3 แหล่ง: GitHub issues, เอกสาร และแหล่งข้อมูลที่เชื่อถือได้อื่น ๆ
ระบุลิงก์และสรุปวิธีแก้สั้น ๆ สำหรับแต่ละแหล่ง

ขั้นตอนที่ 3: สร้างแผนวินิจฉัยใน plans/YYYY-MM-DD-bug-{name}.md:
- สมมติฐานที่ต้องตรวจสอบ (เรียงตามความน่าจะเป็น)
- คำสั่ง/scripts ที่ต้องรันเพื่อตรวจสอบแต่ละข้อ
- ผลลัพธ์ที่คาดว่าจะได้จากการตรวจสอบแต่ละครั้ง

ขั้นตอนที่ 4: ตรวจสอบด้วยตนเอง มีสมมติฐานใดในแผนที่คิดขึ้นเองหรือไม่?
สมมติฐานทั้งหมดเชื่อมโยงกับข้อเท็จจริงจากขั้นตอนที่ 1 หรือไม่?

คัดลอกเทมเพลตแต่ละแบบ แทนที่ {parameters} ด้วยข้อมูลของคุณ แล้ววางลงใน Claude Code ใน Plan Mode ผลลัพธ์คือแผนทำงานใน plans/ ที่คุณอนุมัติและนำไปใช้ดำเนินการได้

Plan Mode เทียบกับโหมดปกติ: ควรเลือกแบบใด?#

Anthropic ระบุไว้โดยตรงในเอกสาร:

ข้ามแผนแยกเฉพาะเมื่อ diff จริงเล็ก เข้าใจ และเสี่ยงต่ำ ใช้วางแผนเมื่อต้องค้นแนวทางหรือประสานการเปลี่ยนเสี่ยงข้ามส่วน การรู้ชื่อไฟล์หรือสรุปเป้าหมายในประโยคเดียวไม่ลบความเสี่ยง migration, authentication หรือความสมบูรณ์ข้อมูล

ตารางตัดสินใจ:

ก่อนเลือกโหมดให้ถามว่าเข้าใจแนวทาง ผลข้างเคียง และการตรวจหรือยัง ทำตรงเมื่อการแก้เล็ก เฉพาะจุด เสี่ยงต่ำ และมีวิธีตรวจชัด วางแผนก่อนเมื่อมีความไม่แน่นอน โค้ดไม่คุ้น migration, authentication หรือการประสานข้ามส่วน แม้ระบุไฟล์ที่กระทบทั้ง 3–5 ไฟล์ได้แล้ว

ผสาน Plan Mode + CLAUDE.md + subagents เพื่อให้ทำงานได้อย่างน่าเชื่อถืออย่างไร?#

CLAUDE.md เป็นไฟล์ที่ Claude อ่านเมื่อเริ่มทุกเซสชัน รวมถึง Plan Mode หาก CLAUDE.md ระบุว่า “อย่าฝังวันที่ไว้ในโค้ด ให้ดึงจากฐานข้อมูลเสมอ” แผนก็จะไม่เสนอให้ฝังวันที่ไว้ในโค้ด หากไม่มีกฎดังกล่าว แผนก็อาจเสนออะไรก็ได้

การผสานทำงานดังนี้:

ชั้นที่ 1 CLAUDE.md กำหนดกฎ

ไฟล์นี้ระบุ tech stack ของโปรเจกต์ หลักการด้านสถาปัตยกรรม ข้อห้าม (“อย่าใช้ API ที่เลิกใช้แล้ว”) และข้อกำหนด (“อีเมลทั้งหมดต้องใช้เลย์เอาต์ร่วมกัน”) คู่มือโดยละเอียด: วิธีกำหนดค่า CLAUDE.md

ชั้นที่ 2 Plan Mode นำกฎไปใช้กับงาน

เมื่อคุณเปิด Plan Mode และขอว่า “add OAuth” Claude จะอ่าน CLAUDE.md เห็นกฎ (“เก็บ tokens ไว้ใน Redis ไม่ใช่ฐานข้อมูล”) และนำไปคิดในแผนทันที แผนจึงสอดคล้องกับสถาปัตยกรรมของโปรเจกต์

ชั้นที่ 3 subagents แบ่งงานกันทำ

หากแบ่งแผนออกเป็นขั้นตอน ก็สามารถมอบหมายแต่ละขั้นตอนให้ subagent แยกกันได้ แต่ละ subagent ทำงานในหน้าต่างบริบทของตนเองโดยไม่ทำให้หน้าต่างหลักรก แผนใน plans/ ยังคงเป็นแหล่งข้อมูลหลัก: subagents อ่านแผน ทำขั้นตอนของตน และอัปเดตช่องทำเครื่องหมาย

ข้อผิดพลาด 7 ข้อใดทำให้ Plan Mode ใช้การไม่ได้?#

ข้อผิดพลาด 1 แผนมีอยู่แค่ในแชต

อาการ: คุณเขียนแผน ปิดหน้าต่าง แล้วต้องกลับมาทำต่อวันถัดไป—แต่ไม่มีอะไรอยู่ตรงนั้น บริบทหายไปแล้ว วิธีแก้: บันทึกแผนไว้ใน plans/YYYY-MM-DD-feature-name.md ใน repository เสมอ แชตคือโต๊ะทำงาน ส่วนไฟล์คือคลังเก็บ

ข้อผิดพลาด 2 ทุกงานอยู่ในแชตเดียวกัน

อาการ: ในเซสชันเดียว คุณคุยเรื่อง auth แล้วต่อด้วยการย้ายระบบ ออกแบบ UI แล้วก็คุยเรื่องบั๊ก หน้าต่างบริบท “พองตัว” และ Claude ลืมเรื่องก่อนหน้า วิธีแก้: หนึ่งงาน—หนึ่งบทสนทนา ทำแผนเสร็จแล้ว? ปิดหน้าต่าง เริ่มทำงานจริงแล้ว? เปิดหน้าต่างใหม่

ข้อผิดพลาด 3 แผนยาว 3000 บรรทัดโดยไม่มีขั้นตอน

อาการ: มีแผน แต่ไม่มีช่องทำเครื่องหมายหรือการแบ่งส่วน แยกไม่ออกว่าอะไรเสร็จแล้วและอะไรยังไม่เสร็จ มอบหมายงานต่อไม่ได้ วิธีแก้: แบ่งแต่ละแผนเป็น 3-7 ขั้นตอน แต่ละขั้นตอนเป็นรายการช่องทำเครื่องหมายที่ระบุการกระทำอย่างชัดเจน

ข้อผิดพลาด 4 ไม่ค้นคว้าเชิงลึกก่อนวางแผน

อาการ: Claude เสนอทางแก้ขึ้นมาเองเพราะคุณไม่ได้ขอให้ค้นหาแนวทางจากกรณีก่อนหน้า หนึ่งสัปดาห์ต่อมาคุณพบว่าในโอเพนซอร์สมีแนวทางที่ดีกว่ามานานแล้ว วิธีแก้: ทำขั้นตอนที่ 2 ของวงจร 4 ขั้นตอน—ให้ Claude ค้นหาแนวทาง 2-3 แบบทางออนไลน์ก่อนสร้างแผน

ข้อผิดพลาด 5 AI ที่คอยเอาใจเสนอทางแก้โดยไม่มีการวินิจฉัย

อาการ: คุณถามว่า “how do I fix error X?” Claude เสนอทางแก้ คุณนำไปใช้ แล้วไม่มีอะไรดีขึ้นหรือสถานการณ์แย่ลง วิธีแก้: เริ่มด้วย “ตรวจสอบข้อเท็จจริง ห้ามเสนอทางแก้” เสมอ หลังวินิจฉัยแล้วค่อยไปดูทางเลือก

ข้อผิดพลาด 6 ข้ามการตรวจสอบด้วยตนเอง

อาการ: แผนดูสมเหตุสมผล แต่มีข้อสมมติ 2-3 ข้อที่คิดขึ้นเอง (ไลบรารีที่ไม่มีอยู่จริง API ที่ไม่มีอยู่ หรือเวอร์ชันผิด) การทำงานจริงล้มเหลวตรงจุดเหล่านั้น วิธีแก้: ใช้ขั้นตอนที่ 4 ของวงจร 4 ขั้นตอน—ให้ Claude ตรวจทานแผนของตัวเองอย่างตรงไปตรงมาและระบุข้อสมมติ

ข้อผิดพลาด 7 เงื่อนไขคลุมเครือใน /goal

อาการ: ตั้ง /goal make it look nice ปล่อยไว้ข้ามคืน แล้วตื่นมาพบว่าโควตา $200 ถูกใช้ไป วิธีแก้: ใช้เฉพาะเงื่อนไขที่วัดผลได้ มีคำสั่งตรวจสอบ และมี or stop after N turns ที่บังคับใช้ ห้ามใช้ “make it good” หรือ “polish it up”

ข้อผิดพลาดข้อที่แปดซึ่งนักพัฒนาสาย vibe coding มักทำมากที่สุด คือมองข้ามแนวคิดของโฟลเดอร์ plans/ ไปเลย Plan Mode ที่ไม่มีโฟลเดอร์ plans/ ไม่ใช่ระเบียบวิธี แต่เป็นของเล่น หากใช้ Plan Mode แต่ไม่สร้างไฟล์ คุณจะได้ความสามารถเพียง 10% เท่านั้น

หลังจากลองใช้ Plan Mode ครั้งแรกแล้วควรทำอะไรต่อ?#

มีสามขั้นตอนที่ทำได้จริง เรียงตามระดับความยาก:

ขั้นตอนที่ 1 ตั้งค่า CLAUDE.md หากยังไม่มี

หากไม่มี CLAUDE.md, Plan Mode จะทำงาน “ในสุญญากาศ”—Claude ไม่รู้กฎของโปรเจกต์และเสนอแผนที่ทำลายสถาปัตยกรรม คู่มือฉบับเต็ม: วิธีกำหนดค่า CLAUDE.md CLAUDE.md ขั้นต่ำมี 50-80 บรรทัดที่อธิบาย tech stack กฎ และข้อห้าม ความยาวเป็นเรื่องรอง สิ่งสำคัญคือความเฉพาะเจาะจง

ขั้นตอนที่ 2 สร้างโฟลเดอร์ plans/ ใน repository

เพิ่มโฟลเดอร์ plans/ ไว้ที่รูทของโปรเจกต์ ตกลงกันเรื่องรูปแบบการตั้งชื่อ: YYYY-MM-DD-feature-name.md แต่ละแผนมีไฟล์ของตัวเอง ผ่านไปหนึ่งเดือนจะมี 20-30 ไฟล์ และผ่านไปหกเดือนจะมี 100+ ไฟล์ นี่คือประวัติการตัดสินใจของโปรเจกต์ที่มีชีวิต

ขั้นตอนที่ 3 ลองใช้ /goal กับงานหนึ่งงาน

เลือกงานที่ปกติคุณใช้เวลาทำเอง 30-40 นาที เปิด Plan Mode สร้างแผนและบันทึกไว้ใน plans/ ออกจาก Plan Mode ตั้ง /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns ปิดแล็ปท็อปไว้หนึ่งชั่วโมงแล้วไปทำอย่างอื่น กลับมาตรวจสอบผลลัพธ์

สามขั้นตอนนี้เป็นเพียงขั้นต่ำ สิ่งนี้ค่อย ๆ สร้างขึ้น อย่าพยายามรวมทุกอย่างให้เสร็จภายในคืนเดียว เริ่มจาก CLAUDE.md เพิ่ม plans/ หลังจากหนึ่งสัปดาห์ แล้วลองใช้ /goal ข้ามคืนหลังจากหนึ่งเดือน

เมื่อพร้อมแล้ว มาทำความรู้จักกับ Ailoot