# Plan Mode ใน Claude Code: คู่มือทีละขั้นตอนและ 4 ขั้นตอนในปี 2026 > Plan Mode ใน Claude Code คืออะไร เปิดใช้งานด้วย Shift+Tab อย่างไร 4 ขั้นตอนของ Anthropic เทมเพลตพรอมป์ต์พร้อมใช้ และคำสั่ง /goal สำหรับงานอัตโนมัติข้ามคืน Source: https://ailoot.ai/blog/th/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/th/claude-code-plan-mode/ Language: th Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-0e806777df4efd6dc096383fe5febf7372e5d7248f181775097a81520ed1bba6 ดูคำแนะนำเพิ่มเติมได้ใน[เอกสารของ Ailoot](https://ailoot.ai/docs/) ## Plan Mode คืออะไร และทำไมใช้เพียงอย่างเดียวจึงยังไม่พอ?
ประเด็นสำคัญ Plan Mode ใน Claude Code คือโหมดที่ AI อ่านไฟล์ วิเคราะห์โค้ด และเสนอแผนการเปลี่ยนแปลง แต่จะไม่เขียนอะไรจนกว่าคุณจะอนุมัติ เปิดใช้งานโดยกด Shift+Tab สองครั้ง หรือใช้แฟล็ก `--permission-mode plan` เหมาะเมื่อแนวทางไม่ชัด โค้ดไม่คุ้น หรือการแก้มีความเสี่ยงข้ามไฟล์หรือการปฏิบัติงานที่มีนัยสำคัญ การแก้คำผิดที่ชัดและเสี่ยงต่ำมักไม่ต้องแยกขั้นวางแผน
ในโหมดปกติ Claude Code เขียนโค้ดทันที และหากคุณไม่ได้คอยติดตาม ก็อาจได้ diff ที่ครอบคลุมหลายไฟล์โผล่มาโดยไม่ทันตั้งตัว Plan Mode สลับลำดับขั้นตอน: วิจัยและวางแผนก่อน จากนั้นอนุมัติ แล้วจึงค่อยเปลี่ยนแปลง Anthropic อธิบาย Plan Mode ไว้ในเอกสารทางการดังนี้:

Plan mode สั่งให้ Claude วิจัยและเสนอการเปลี่ยนแปลงโดยไม่ลงมือทำ Claude อ่านไฟล์ รันคำสั่ง shell เพื่อสำรวจ และเขียนแผน แต่จะไม่แก้ไขโค้ดของคุณ

— Anthropic Docs, https://code.claude.com/docs/en/permission-modes
ฟังดูเรียบง่าย แต่มีการเปลี่ยนแปลงสำคัญซ่อนอยู่ 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 ตัวถัดไปก็สามารถรับช่วงต่อได้ นี่คือวิธีทำงานของ[วิศวกรรมบริบท](https://ailoot.ai/blog/th/context-engineering/)—จัดการบริบทก่อนพรอมป์ต์ ไม่ใช่ระหว่างพรอมป์ต์ ## เปิดใช้ Plan Mode ใน Claude Code อย่างไร?
ประเด็นสำคัญ มีสี่วิธีอย่างเป็นทางการในการเปิดใช้ Plan Mode ระหว่างเซสชัน ให้กด Shift+Tab สองครั้ง หรือใส่คำนำหน้า `/plan` ก่อนพรอมป์ต์ ตอนเริ่มต้นใช้งาน ให้ใช้แฟล็ก `claude --permission-mode plan` หากต้องการตั้งเป็นค่าเริ่มต้น ให้กำหนดฟิลด์ `defaultMode` ใน `.claude/settings.json` ตัวบ่งชี้โหมดที่กำลังทำงานคือ `⏸ plan mode on` ที่ด้านล่างของเทอร์มินัล
วิธีที่เร็วที่สุดระหว่างเซสชันคือใช้แป้นพิมพ์: ``` 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 กับคำขอเดียว แล้วทำงานต่อเหมือนเดิม วิธีที่สามคือกำหนดตอนเริ่มเซสชัน: ```bash claude --permission-mode plan ``` ใช้วิธีนี้เมื่อรู้ล่วงหน้าว่างานต้องมีการวางแผน เช่น ก่อนการปรับโครงสร้างครั้งใหญ่หรือการย้ายระบบ วิธีที่สี่คือกำหนดค่าเริ่มต้นใน `.claude/settings.json` ของโปรเจกต์: ```json { "permissions": { "defaultMode": "plan" } } ``` วิธีนี้มีประโยชน์เมื่อใด? เมื่อทีมทำงานกับระบบซับซ้อนที่การเปลี่ยนแปลงใด ๆ อาจกระทบโมดูลข้างเคียง การตั้ง Plan Mode เป็นค่าเริ่มต้นจะช่วยปกป้องทุกคนจากการเปลี่ยนแปลงโดยไม่ตั้งใจ เคล็ดลับข้อที่ห้าที่มักถูกมองข้าม: `Ctrl+G` เปิดแผนในโปรแกรมแก้ไขข้อความ ใช้เมื่อแผนเกือบถูกต้องแล้ว แต่ต้องปรับถ้อยคำ 2-3 จุดหรือเพิ่มข้อจำกัด แก้ไขด้วยตนเอง บันทึก แล้ว Claude จะทำงานต่อด้วยเวอร์ชันของคุณ ## 4 ขั้นตอนมาตรฐานของ Anthropic ใน Plan Mode ได้แก่ Explore, Plan, Implement และ Commit อย่างไร?
ประเด็นสำคัญ ในแนวปฏิบัติที่ดีที่สุด Anthropic ระบุเวิร์กโฟลว์มาตรฐานไว้สี่ขั้นตอน: Explore (อ่านไฟล์และสำรวจบริบท), Plan (สร้างแผนการเปลี่ยนแปลงโดยไม่แก้ไข), Implement (สลับไปโหมดปกติและดำเนินการตามแผน), Commit (สร้าง commit พร้อมข้อความอธิบายและ PR) แต่ละขั้นตอนมีข้อจำกัดการใช้เครื่องมือของตนเอง
คู่มือหลายฉบับอธิบายสามขั้นตอน (Explore-Plan-Execute) หรือเพียงสองขั้นตอน (Plan-Implement) ซึ่งเป็นการย่อ ใน[คู่มือแนวปฏิบัติที่ดีที่สุดอย่างเป็นทางการ](https://www.anthropic.com/engineering/claude-code-best-practices) Anthropic อธิบายไว้ครบทั้ง 4 ขั้นตอน ความแตกต่างนี้สำคัญ: การแยก Commit เป็นขั้นตอนต่างหากทำให้คุณบันทึกผลลัพธ์ แทนที่จะปล่อยค้างไว้ที่ “ฉันปรับอีกนิดหน่อย ไว้ค่อย commit ทีหลัง”—ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดของงานสูญหาย ยิ่งแผนแม่นยำมากเท่าใด การทำงานจริงก็ยิ่งต้องแก้ซ้ำน้อยลง หากใช้เวลา 10 นาทีวางแผน การทำงานจริงจะใช้พรอมป์ต์เดียว หากร่างแผนในหนึ่งนาที การทำงานจริงจะใช้เวลาหนึ่งชั่วโมงไปกับการแก้ไข ตัวอย่าง 4 ขั้นตอนสำหรับการเพิ่ม Google OAuth (ตัวอย่างจาก Anthropic Docs): | ขั้นตอน | Claude ทำอะไร | คุณทำอะไร | โหมด | |----|----|----|----| | **Explore** | อ่าน `/src/auth` และตรวจสอบวิธีจัดการเซสชันและตัวแปรสภาพแวดล้อม | กำหนดขอบเขตการสำรวจ | Plan Mode | | **Plan** | สร้างแผน: ไฟล์ใดต้องเปลี่ยน ไฟล์ใหม่ใดต้องสร้าง และมีความเสี่ยงอะไรบ้าง | อ่านแผน แก้ไขด้วย Ctrl+G แล้วอนุมัติ | Plan Mode | | **Implement** | ดำเนินการตามแผน เขียนโค้ด OAuth flow การทดสอบ และ callback | ติดตามการเปลี่ยนแปลงแต่ละรายการขณะนำไปใช้ | Default หรือ acceptEdits | | **Commit** | สร้าง commit พร้อมคำอธิบายและเปิด Pull Request | ตรวจสอบข้อความและรีวิว PR | Default | พรอมป์ต์ในแต่ละขั้นตอนก็แตกต่างกันด้วย ใน 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 จะมีรายการไฟล์ที่เฉพาะเจาะจงและการเปลี่ยนแปลงที่จะทำ ลำดับขั้นตอนที่ชัดเจน ความเสี่ยงที่ระบุไว้ และเกณฑ์ความสำเร็จ แผนที่ไม่ดีใช้ถ้อยคำกว้าง ๆ เช่น “ฉันจะอัปเดตโมดูล auth” โดยไม่มีรายละเอียด ใช้สัญญาณ 7 ข้อด้านล่างเพื่อตัดสินใจว่าจะอนุมัติหรือไม่ ปรับแผนด้วยคำติชมหรือแก้ไขโดยตรงด้วย Ctrl+G
เมื่อ 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 เพียงอย่างเดียวทำงานได้เฉพาะในการสนทนาปัจจุบัน ปิดหน้าต่างแล้วแผนก็หายไป โฟลเดอร์ `plans/YYYY-MM-DD-feature.md` ใน repository เปลี่ยนแผนให้เป็นสิ่งที่เก็บรักษาได้: ไฟล์ที่มีขั้นตอน ช่องทำเครื่องหมาย และสถานะ ซึ่ง agent ตัวถัดไปสามารถรับช่วงต่อได้ นี่คือการเปลี่ยนจาก “แผนในความทรงจำ” เป็น “แผนในโค้ด”
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`) ก็สามารถรับช่วงต่อจากแผนได้ เปรียบเทียบแนวทาง: | คุณสมบัติ | Plan Mode อย่างเดียว | Plan Mode + โฟลเดอร์ `plans/` | |----|----|----| | ความคงทน | อยู่เฉพาะในแชตปัจจุบัน | อยู่ใน repository ตลอดไป | | ส่งต่องานให้ agent ตัวอื่น | ทำไม่ได้ | `cat plans/file.md` | | เวอร์ชันและประวัติ | ไม่มี | ผ่าน git diff | | รองรับ subagent | เฉพาะในเซสชันปัจจุบัน | แต่ละขั้นตอน → subagent ของตัวเอง | | ช่องทำเครื่องหมายและสถานะ | ข้อความเท่านั้น | ช่องทำเครื่องหมาย Markdown `[ ]` / `[x]` | | ขนาดแผน | จำกัดด้วยหน้าต่าง | ได้ทุกขนาด | แต่ละฟีเจอร์มีไฟล์แผนของตัวเอง เมื่อเวลาผ่านไปสามเดือนแล้วต้องการจำว่าเหตุใดจึงเลือกผู้ให้บริการชำระเงินรายหนึ่งแทนตัวเลือกอื่น คุณก็เปิดแผนที่เกี่ยวข้องและอ่านประวัติการตัดสินใจได้: มีการพูดคุยอะไรบ้าง พิจารณาตัวเลือกใดบ้าง และเหตุใดจึงเลือกแนวทางนี้ นี่คือแผนงานที่มีชีวิต ส่วนเอกสารแบบคงที่ล้าสมัยภายในเวลาไม่กี่เดือน ## ให้ Claude ทำงานขณะที่คุณหลับด้วย Plan Mode และ /goal ได้อย่างไร?
ประเด็นสำคัญ `/goal` คือลูปอัตโนมัติที่ Anthropic พูดถึงมาเป็นเวลาหนึ่งปี คำสั่ง `/goal` เปิดตัวใน Claude Code v2.1.139 (11 พฤษภาคม 2026) คำสั่งนี้กำหนดเงื่อนไขการเสร็จสิ้น และ Claude จะทำงานต่อโดยไม่มีมนุษย์เข้ามาเกี่ยวข้องจนกว่าเงื่อนไขจะครบ โมเดลประเมินผลขนาดเล็กจะตรวจสอบหลังทุกเทิร์นว่าเงื่อนไขครบแล้วหรือยัง
ข้อจำกัดหลักของเซสชัน AI ที่ยาวนานไม่ได้อยู่ที่ตัวโมเดล แต่อยู่ที่คนที่กด Enter ทุกครั้งที่ Claude ทำงานจบหนึ่งเทิร์น ก็จะรอคำตอบจากคุณ `/goal` ช่วยเอาการรอนั้นออกไป ไวยากรณ์นั้นเรียบง่าย: ```bash /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 20 turns'

— Anthropic Docs, https://code.claude.com/docs/en/goal
หากเปิด `/goal` โดยไม่มี `or stop after` งบประมาณของคุณอาจหมดไปในชั่วข้ามคืน ## วงจร 4 ขั้นตอนแบบใดเปลี่ยน Plan Mode ให้เป็นกระบวนการทางวิศวกรรม?
ประเด็นสำคัญ Plan Mode ที่ไม่มีโครงสร้างให้ผลลัพธ์ระดับกลาง เวิร์กโฟลว์ที่แข็งแกร่งทำตาม 4 ขั้นตอนในหน้าต่างเดียว: ตรวจสอบข้อเท็จจริงโดยไม่เสนอทางแก้ พัฒนาทางเลือกโดยอ้างอิงแนวทางจากอินเทอร์เน็ต สร้างแผนละเอียดพร้อมความเสี่ยงล่วงหน้า 2-3 ขั้นตอน และบังคับให้ตรวจสอบแผนด้วยตนเองเพื่อหาข้อสมมติที่คิดขึ้นเอง ลำดับนี้ช่วยหยุด AI ที่คอยเอาใจ
ความผิดพลาดที่พบบ่อยคือถามว่า “จะแก้อย่างไร?” 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?
ประเด็นสำคัญ พรอมป์ต์พร้อมใช้ช่วยประหยัดเวลา 10-15 นาทีต่องานและปรับปรุงคุณภาพแผน มีเทมเพลตทั่วไป 5 แบบสำหรับการปรับโครงสร้างโมดูล การย้ายฐานข้อมูล การเพิ่มฟีเจอร์ใหม่ การเขียนการทดสอบ และการดีบักข้อผิดพลาดซับซ้อน แต่ละแบบสร้างขึ้นบนวงจร 4 ขั้นตอนและเชื่อมโยงกับโฟลเดอร์ `plans/`
**เทมเพลต 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 เทียบกับโหมดปกติ: ควรเลือกแบบใด?
ประเด็นสำคัญ ใช้ Plan Mode เมื่อแนวทางไม่แน่นอน โค้ดไม่คุ้น ต้องตัดสินสถาปัตยกรรม ย้ายระบบ หรือเปลี่ยนที่มีผลข้างเคียงสำคัญ จำนวนไฟล์เป็นสัญญาณให้ดู dependencies ไม่ใช่กฎตายตัว diff เล็กที่เข้าใจและเสี่ยงต่ำทำตรงได้ แต่คำอธิบายประโยคเดียวไม่ทำให้งานยืนยันตัวตนหรือย้ายระบบปลอดภัย
Anthropic ระบุไว้โดยตรงในเอกสาร:

Plan mode มีประโยชน์ แต่ก็เพิ่มภาระงาน สำหรับงานที่มีขอบเขตชัดเจนและการเปลี่ยนแปลงเล็กน้อย (คำผิด บรรทัด log การเปลี่ยนชื่อตัวแปร) ให้ขอ Claude ทำทันที การวางแผนมีประโยชน์ที่สุดเมื่อคุณไม่แน่ใจว่าจะใช้แนวทางใด เมื่อการเปลี่ยนแปลงกระทบหลายไฟล์ หรือเมื่อไม่คุ้นเคยกับโค้ด หากอธิบาย diff ได้ในหนึ่งวลี ให้ข้ามแผน

— Anthropic Docs, https://www.anthropic.com/engineering/claude-code-best-practices
ข้ามแผนแยกเฉพาะเมื่อ diff จริงเล็ก เข้าใจ และเสี่ยงต่ำ ใช้วางแผนเมื่อต้องค้นแนวทางหรือประสานการเปลี่ยนเสี่ยงข้ามส่วน การรู้ชื่อไฟล์หรือสรุปเป้าหมายในประโยคเดียวไม่ลบความเสี่ยง migration, authentication หรือความสมบูรณ์ข้อมูล ตารางตัดสินใจ: | งาน | โหมด | เหตุผล | |----|----|----| | คำผิดใน README | Default | ไฟล์เดียว เปลี่ยนแปลงเดียว diff ชัดเจน | | เปลี่ยนชื่อตัวแปรในไฟล์เดียว | Default | ขอบเขตชัดและตรวจ references ได้ แต่ต้องประเมินผลข้างเคียง | | เพิ่มบรรทัดบันทึก log | Default | เปลี่ยนแปลงบรรทัดเดียว ไม่กระทบตรรกะ | | เพิ่มปุ่มใหม่ในหน้าเว็บ | Default | หากมีปุ่มเดียวและรู้ว่าจะวางตรงไหน ก็ไม่ต้องวางแผน | | ปรับโครงสร้างโมดูล | Plan Mode | 5+ ไฟล์ มีความเสี่ยงจากผลข้างเคียง | | ย้ายฐานข้อมูล | Plan Mode + `/goal` | กระบวนการหลายขั้นตอน ต้องมีแผนย้อนกลับ | | เพิ่มระบบยืนยันตัวตน | Plan Mode | กระทบ 10+ ไฟล์ ความปลอดภัยเป็นเรื่องสำคัญ | | เขียนการทดสอบให้โมดูล | Plan Mode | ต้องกำหนดว่าจะทดสอบอะไร | | ดีบักบั๊กที่ไม่ชัดเจน | Plan Mode + วงจร 4 ขั้นตอน | หากไม่วินิจฉัยก่อน ทางแก้จะไม่ตรงจุด | | ย้าย framework ทั้งระบบ | Plan Mode + `plans/` + `/goal` ข้ามคืน | งานระยะยาวที่ต้องมีขั้นตอนและลูปอัตโนมัติ | ก่อนเลือกโหมดให้ถามว่าเข้าใจแนวทาง ผลข้างเคียง และการตรวจหรือยัง ทำตรงเมื่อการแก้เล็ก เฉพาะจุด เสี่ยงต่ำ และมีวิธีตรวจชัด วางแผนก่อนเมื่อมีความไม่แน่นอน โค้ดไม่คุ้น migration, authentication หรือการประสานข้ามส่วน แม้ระบุไฟล์ที่กระทบทั้ง 3–5 ไฟล์ได้แล้ว ## ผสาน Plan Mode + CLAUDE.md + subagents เพื่อให้ทำงานได้อย่างน่าเชื่อถืออย่างไร?
ประเด็นสำคัญ Plan Mode มีประสิทธิภาพเพิ่มขึ้น 10 เท่าเมื่อใช้ร่วมกับ [CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/) ที่กำหนดค่าอย่างเหมาะสมและ [subagents](https://ailoot.ai/blog/th/claude-code-subagents/) CLAUDE.md กำหนดกฎที่ Claude ใช้สร้างแผน ส่วน subagents ช่วยกระจายขั้นตอนของแผนไปยัง agent ที่ทำงานพร้อมกัน หากไม่มีองค์ประกอบเหล่านี้ Plan Mode ก็ยังเป็นเพียงเครื่องมือใช้ครั้งเดียว
CLAUDE.md เป็นไฟล์ที่ Claude อ่านเมื่อเริ่มทุกเซสชัน รวมถึง Plan Mode หาก CLAUDE.md ระบุว่า “อย่าฝังวันที่ไว้ในโค้ด ให้ดึงจากฐานข้อมูลเสมอ” แผนก็จะไม่เสนอให้ฝังวันที่ไว้ในโค้ด หากไม่มีกฎดังกล่าว แผนก็อาจเสนออะไรก็ได้ การผสานทำงานดังนี้: **ชั้นที่ 1 CLAUDE.md กำหนดกฎ** ไฟล์นี้ระบุ tech stack ของโปรเจกต์ หลักการด้านสถาปัตยกรรม ข้อห้าม (“อย่าใช้ API ที่เลิกใช้แล้ว”) และข้อกำหนด (“อีเมลทั้งหมดต้องใช้เลย์เอาต์ร่วมกัน”) คู่มือโดยละเอียด: [วิธีกำหนดค่า CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/) **ชั้นที่ 2 Plan Mode นำกฎไปใช้กับงาน** เมื่อคุณเปิด Plan Mode และขอว่า “add OAuth” Claude จะอ่าน CLAUDE.md เห็นกฎ (“เก็บ tokens ไว้ใน Redis ไม่ใช่ฐานข้อมูล”) และนำไปคิดในแผนทันที แผนจึงสอดคล้องกับสถาปัตยกรรมของโปรเจกต์ **ชั้นที่ 3 subagents แบ่งงานกันทำ** หากแบ่งแผนออกเป็นขั้นตอน ก็สามารถมอบหมายแต่ละขั้นตอนให้ [subagent](https://ailoot.ai/blog/th/claude-code-subagents/) แยกกันได้ แต่ละ subagent ทำงานในหน้าต่างบริบทของตนเองโดยไม่ทำให้หน้าต่างหลักรก แผนใน `plans/` ยังคงเป็นแหล่งข้อมูลหลัก: subagents อ่านแผน ทำขั้นตอนของตน และอัปเดตช่องทำเครื่องหมาย ## ข้อผิดพลาด 7 ข้อใดทำให้ Plan Mode ใช้การไม่ได้?
ประเด็นสำคัญ Plan Mode มักใช้การไม่ได้เพราะข้อผิดพลาดในการใช้งานทั่วไป ไม่ใช่เพราะเครื่องมืออ่อนแอ ข้อผิดพลาดหลัก 7 ข้อ ได้แก่ เก็บแผนไว้ในความจำแทนที่จะบันทึกในไฟล์ ใส่ทุกงานไว้ในแชตเดียว ทำแผนโดยไม่มีขั้นตอน ข้ามการค้นคว้าเชิงลึก ปล่อยให้ AI ที่คอยเอาใจเสนอทางแก้โดยไม่มีการวินิจฉัย ข้ามการตรวจสอบด้วยตนเอง และใช้เงื่อนไขคลุมเครือใน `/goal`
**ข้อผิดพลาด 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 ครั้งแรกแล้วควรทำอะไรต่อ?
ประเด็นสำคัญ การลองใช้ Plan Mode ครั้งแรกคือจุดเริ่มต้น ขั้นต่อไป: ตั้งค่า [CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/) หากยังไม่มี (หากไม่มี แผนก็ลอยคว้าง) สร้างโฟลเดอร์ `plans/` ใน repository เพื่อใช้เป็นระเบียบวิธีทำงาน และลองใช้ `/goal` กับงานอัตโนมัติหนึ่งงานก่อนเข้านอน การผสานทั้งสามอย่าง—Plan Mode, CLAUDE.md และ `plans/`—คือระบบที่ใช้งานได้จริง
มีสามขั้นตอนที่ทำได้จริง เรียงตามระดับความยาก: **ขั้นตอนที่ 1 ตั้งค่า CLAUDE.md หากยังไม่มี** หากไม่มี CLAUDE.md, Plan Mode จะทำงาน “ในสุญญากาศ”—Claude ไม่รู้กฎของโปรเจกต์และเสนอแผนที่ทำลายสถาปัตยกรรม คู่มือฉบับเต็ม: [วิธีกำหนดค่า CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/) 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` ข้ามคืนหลังจากหนึ่งเดือน
### แหล่งที่มา - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering - Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal) - [Anthropic Docs - Changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
เมื่อพร้อมแล้ว มาทำความรู้จักกับ [Ailoot](https://ailoot.ai/) ## คำถามที่พบบ่อย ### รู้ไฟล์ที่จะเปลี่ยนแล้วข้ามวางแผนได้หรือไม่? ยังไม่ได้ ชื่อไฟล์ชัดไม่ลบความไม่แน่นอนเรื่องผลข้างเคียงหรือการตรวจ ต้องวางแผน migration การแก้ authentication และการเปลี่ยนร่วมข้ามส่วน แม้รายชื่อไฟล์ชัดแล้ว ### เมื่อไรไม่จำเป็นต้องแยกขั้น Plan Mode? diff เล็กที่เข้าใจ เสี่ยงต่ำ และตรวจง่าย เช่น คำผิดเฉพาะจุด ทำตรงได้ ใช้วางแผนเมื่อแนวทางไม่ชัด โค้ดไม่คุ้น หรือมีความเสี่ยงการปฏิบัติงานกับข้ามไฟล์ที่ต้องคิดให้ครบ ## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน. Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ