Claude Code ในปี 2026: 11 เคล็ดลับ ปุ่มลัด และคำสั่ง

หากต้องการคำแนะนำเพิ่มเติมเกี่ยวกับการใช้งาน Ailoot โปรดดูเอกสารประกอบ

เคล็ดลับทั้ง 11 ข้อนี้ทำอะไร และทำไมคุณจึงต้องใช้กลยุทธ์เชิงปฏิบัติแทนทฤษฎี?#

เมื่อใช้ vibe coding คำถามไม่ใช่ “Claude Code ใช้งานได้ไหม?” อีกต่อไป แต่เป็น “จะทำงานกับมันอย่างไรไม่ให้ใช้โควตาจนหมดหรือหลอนข้อมูล?” คู่มือก่อนหน้า 9 เล่มของฉันครอบคลุมแนวคิดต่าง ๆ ได้แก่ CLAUDE.md, Plan Mode, context engineering, Skills, Subagents, MCP, /rewind, โควตา, second brain บทความนี้รวบรวมกลยุทธ์เชิงปฏิบัติเพื่อใช้ร่วมกัน

แต่ละเคล็ดลับแก้ปัญหาหนึ่งอย่าง คุณอ่านตามลำดับหรือข้ามไปยังเรื่องที่เร่งด่วนที่สุดก็ได้: ถ้าต้องการปุ่มลัด ให้ไปที่เคล็ดลับ 1; ถ้าต้องการประหยัดโทเคน ให้ดูเคล็ดลับ 4 และ 5; ถ้าต้องการทำงานแบบขนาน ให้ดูเคล็ดลับ 6; ส่วนเทคนิคของผู้เขียนอยู่ในเคล็ดลับ 8-11

บทความนี้เขียนสำหรับผู้ที่ติดตั้ง Claude Code แล้ว และใช้งานมาอย่างน้อยหนึ่งสัปดาห์ หากเพิ่งติดตั้ง ให้เริ่มจากคู่มือ CLAUDE.md แล้วค่อยกลับมาอ่านบทความนี้

วิธีสลับโหมด Claude Code: ปุ่มลัด Shift+Tab#

ข้อผิดพลาดที่มือใหม่ทำกันบ่อยที่สุดคืออยู่ใน default ตลอดทั้งวันและอนุมัติทุกการเปลี่ยนแปลงด้วยตนเอง พอผ่านไปหนึ่งชั่วโมงก็เหนื่อย และอาจอยากใช้ --dangerously-skip-permissions (ดูรายละเอียดเพิ่มเติมท้ายเคล็ดลับนี้) Shift+Tab เป็นทางสายกลาง: คุณเลือกได้ว่าจะใช้ acceptEdits หรือ plan เมื่อใด

นี่คือกฎเฉพาะที่ฉันใช้เมื่อสลับโหมด:

1. เริ่มงานซับซ้อน - ใช้ Shift+Tab จนตัวบอกโหมดเป็น plan Claude จะคิดวางแผนและร่างแผน โดยจะไม่เขียนโค้ดจนกว่าฉันจะอนุมัติ
2. อนุมัติแผนแล้วและเริ่มลงมือทำ - วนจนตัวบอกโหมดเป็น acceptEdits Claude จะแก้ไขไฟล์โดยไม่ขออนุมัติ แต่ยังถามก่อนเรียกใช้คำสั่ง Bash
3. แก้ไขงานประจำ (เปลี่ยนชื่อ ปรับโครงสร้างโค้ดเล็กน้อย) - ไปที่ acceptEdits ได้เลย ไม่ต้องวางแผน
4. ช่วงเสี่ยง (migration ฐานข้อมูล การลบไฟล์) - กด Shift+Tab เพื่อกลับไปที่ default

# Common permission modes (check the active label, not a fixed press count):
# default        - standard permission prompts
# acceptEdits    - file edits are accepted; other tool permissions still apply
# plan           - investigate and plan before implementation
# Additional modes depend on your version, settings, and organization policy.

หาก Shift+Tab ใช้ไม่ได้ใน Claude Code เวอร์ชันของคุณ (claude --version) ให้ตรวจสอบว่าคุณใช้เวอร์ชันล่าสุดแล้ว คำสั่ง /doctor จะแสดงรายละเอียดทั้งหมดเกี่ยวกับการติดตั้ง

วิธีย้อนการกระทำล่าสุดโดยไม่เสียบริบท: Esc Esc#

Esc กับ Esc Esc ทำงานต่างกัน จึงทำให้หลายคนสับสน:

• Esc หนึ่งครั้ง - ขัดจังหวะ Claude ขณะกำลังทำงาน สิ่งที่ทำไปแล้วจะยังคงอยู่ ใช้ได้เมื่อ Claude ทำผิดทางและคุณต้องการชี้นำใหม่
• Esc สองครั้ง - ถ้าช่องป้อนข้อมูลว่าง จะเปิดเมนู checkpoint (กู้คืนโค้ด กู้คืนบทสนทนา หรือทั้งสองอย่าง หรือสรุป) ถ้ามีข้อความในช่อง ข้อความจะถูกลบออกจากช่องและใส่ไว้ในประวัติ (กดลูกศรขึ้นเพื่อนำกลับมา)

# From the Esc Esc menu with an empty field:
# 1. Restore code only            - restore the files, leave the conversation
# 2. Restore conversation only    - restore the conversation, leave the files
# 3. Restore code and conversation - restore both (the most common choice)
# 4. Summarize from here          - summarize the conversation from this point
# 5. Summarize up to here         - summarize up to this point

ระบบสร้าง checkpoint อัตโนมัติทุกครั้งที่คุณส่ง prompt ไม่ต้องจำอะไร และย้อนกลับไปได้เสมอ ดูรายละเอียดทั้งหมดได้ในคู่มือ /rewind ซึ่งอธิบายวิธีใช้ร่วมกับ git เพื่อย้อนกลับครั้งใหญ่ด้วย

Esc Esc เป็นหนึ่งในเทคนิคแรก ๆ ที่มือใหม่ควรเรียนรู้ เมื่อเลิกกลัวว่า “จะทำพังแล้วแก้กลับไม่ได้” พวกเขาก็เริ่มทดลองอย่างกล้าหาญขึ้น และผลลัพธ์ก็ดีขึ้นหลายเท่า

ควรใช้ /compact แทน /clear เมื่อใด?#

ภายใน /compact ทำงานดังนี้: Claude นำประวัติข้อความทั้งหมดมาประมวลผล แล้วส่งสรุปสั้น ๆ ที่เก็บรายละเอียดสำคัญที่สุดไว้ เคล็ดลับที่มีประโยชน์คือใส่ hint ให้มัน: /compact keep the coding principles and current plan, discard the CSS discussion การบีบอัดก็จะตรงจุดมากขึ้น

# When to use what:
/clear                              # finished a feature, moving to a new one
/compact                            # long session, context is >50% full
/compact keep the architecture and plan  # targeted compression with a focus

สัญญาณว่าถึงเวลารัน /compact คือคำสั่ง /cost หรือแถบสถานะแสดงว่าใช้หน้าต่างบริบทไปแล้ว 70%+ ทั้งที่เซสชันเพิ่งผ่านไปครึ่งเดียว หากไม่สนใจ Claude จะเริ่ม “ลืม” ช่วงต้นของบทสนทนา และคุณจะเสียเวลาอธิบายซ้ำ

ดูทฤษฎีเกี่ยวกับหน้าต่างบริบททั้งหมดได้ในคู่มือ context engineering ซึ่งอธิบายด้วยว่าทำไมบริบทจึงเป็นทรัพยากรที่มีจำกัดและให้ผลตอบแทนลดลงเมื่อใช้มากขึ้น

วิธีติดตามโทเคนแบบเรียลไทม์: คำสั่ง /cost#

ความกังวลว่า “ใช้หมดในวันเดียว” เป็นหนึ่งในข้อกังวลหลักของคนทำ vibe coding วิธีหลักในการจัดการความกังวลนี้คือทำให้ค่าใช้จ่าย มองเห็นได้

/cost          # shows current session spending (tokens + $)
/statusline    # configures the status bar: model + directory + context % + cost

กฎง่าย ๆ: ตรวจ /cost ทุก 30-60 นาที ถ้าใช้เงินไม่ถึงสองสามดอลลาร์ในหนึ่งชั่วโมงก็ถือว่าปกติ ถ้ามากกว่านั้น แสดงว่ามีบางอย่างผิดปกติ: อาจลืมใช้ /compact จนบริบทโตขึ้น อาจเลือกโมเดลผิด (ดูต่อในเคล็ดลับถัดไป) หรือ Claude อาจอ่านไฟล์ขนาดใหญ่ซ้ำถึง 10 ครั้ง

คู่มือฉบับเต็มเรื่องการประหยัดโควตาคือ “วิธีไม่ใช้โควตา Claude Code จนหมดในวันเดียว” ซึ่งมีกฎ 8 ข้อ ส่วนกลยุทธ์ในบทความนี้คือทำให้ค่าใช้จ่ายมองเห็นได้ด้วย /cost และ /statusline

ควรเลือกโมเดล Claude รุ่นใดสำหรับงาน: Haiku, Sonnet หรือ Opus?#

claude --model haiku   # ~3× cheaper than sonnet, for routine work
claude --model sonnet  # default, balance of price and quality
claude --model opus    # ~1.7× more expensive than sonnet, for complex tasks

ตามราคาสาธารณะของ Anthropic ในเดือนพฤษภาคม 2026: Haiku ราคา $1/$5 ต่อ 1M input/output, Sonnet ราคา $3/$15 และ Opus ราคา $5/$25 นั่นหมายความว่า Haiku ถูกกว่า Sonnet 3 เท่า ส่วน Opus แพงกว่า Sonnet 1.7 เท่า

วิธีที่ฉันเลือกใช้ในแต่ละวัน:

ประเด็นที่ถกเถียงกันได้คือควรใช้ Sonnet กับ Haiku หรือไม่ หากโดยเฉลี่ย Opus ทำได้ “ตั้งแต่ครั้งแรก” คำตอบของฉันคือ สำหรับผู้ประกอบการที่ไม่ใช่โปรแกรมเมอร์ Haiku และ Sonnet คุ้มค่าสำหรับงาน 70% ส่วน Opus ควรเก็บไว้ใช้กับงาน 30% ที่ยากจริง ๆ

วิธีรันงาน 3-5 งานพร้อมกัน: /resume + git worktrees#

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

# Start a named session for a specific task:
claude --resume "auth-refactor"
claude --resume "homepage-redesign"
claude --resume "db-migration"

# Use a worktree to keep git from overlapping:
git worktree add ../my-project-auth feature/auth
cd ../my-project-auth
claude --resume "auth-refactor"

ถ้าจำไม่ได้ว่าแต่ละหน้าต่างทำอะไรอยู่ ให้รัน claude --resume โดยไม่ใส่อาร์กิวเมนต์เพื่อดูรายการเซสชันล่าสุดพร้อมชื่อและเวลา ภายในเซสชันที่กำลังทำงาน /agents ใช้ตรวจสอบ subagents ที่กำลังทำงานอยู่

เมื่อทำงานกับฟีเจอร์ที่มีวงจรการพัฒนายาว ฉันมักทำดังนี้:

1. หน้าต่าง 1 - วางแผนไว้ใน plans/YYYY-MM-DD-feature.md สนทนาอย่างเดียว ไม่มีโค้ด
2. หน้าต่าง 2 (ทำตามแผน) - ลงมือทำเฟส 1 เมื่อจบเฟส ให้อัปเดตแผน ([x])
3. หน้าต่าง 3 - ทำเฟส 2 ไปพร้อมกับหน้าต่าง 2 หากทั้งสองเฟสไม่ทับซ้อนกัน
4. หน้าต่าง 4 - synthesis agent ตรวจสอบผลลัพธ์จากทั้งสองหน้าต่าง
5. หน้าต่าง 5 - ตรวจสอบความปลอดภัยหลัง merge (ดูเคล็ดลับ 8)

ไม่ควรใช้ worktrees เมื่อใด: ถ้าคุณดูแล 1-2 โปรเจกต์ต่อวัน เวลาที่เสียไปกับการสลับไดเรกทอรี worktree จะกลบประโยชน์ที่ได้รับ Worktrees เริ่มคุ้มค่าเมื่อทำงานพร้อมกัน 3+ งานต่อวัน

วิธีหลีกเลี่ยงการหลอน: อ้างอิงไฟล์ด้วย @file#

การเติมชื่อไฟล์อัตโนมัติเริ่มต้นด้วยสัญลักษณ์ @ เริ่มพิมพ์ path แล้ว Claude จะแสดงคำแนะนำ คุณอ้างอิงไฟล์หลายไฟล์พร้อมกันได้: @src/lib/auth.ts @src/lib/session.ts @prisma/schema.prisma

# Prompt without exact paths (bad):
> Look at the auth logic and fix the session bug

# Prompt with @ references (right):
> @src/lib/auth.ts @src/lib/session.ts - fix the bug: after logout the cookie isn't cleared

เคล็ดลับที่สองในกลุ่มเดียวกันคือ shell mode ที่ใช้ !:

> !git status                # runs without calling Claude, output goes into context
> !npm test                  # same
> !cat /var/log/app.log | tail -50  # same

เหตุผลคือ คุณไม่ต้องเสียโทเคนกับการบอกว่า “Claude ดู git status ให้หน่อย” - Claude ก็ได้คำตอบเดียวกันจากเครื่องมืออยู่แล้ว ! สั้นกว่าและถูกกว่า

เรื่องนี้เกี่ยวข้องกับ CLAUDE.md: ไฟล์หลักควรมีไม่เกิน 200 บรรทัดของกฎโปรเจกต์ ส่วนกฎที่เฉพาะเจาะจงกว่า (เช่น ข้อกำหนด API) ให้ใส่ไว้ใน .claude/rules/api-design.md พร้อม YAML frontmatter paths: ["src/api/**/*.ts"] กฎเหล่านี้จะโหลดเฉพาะเมื่อ Claude แก้ไขไฟล์ใน src/api/ ดูรายละเอียดทั้งหมดได้ในคู่มือ CLAUDE.md

วิธีไม่ให้ความคืบหน้าหายไปเมื่องานใช้เวลานาน: วางแผนเป็นเฟสด้วย [ ] / [x]#

นี่คือเทมเพลตไฟล์แผนที่ฉันใช้ในทุกโปรเจกต์:

# Plan: [feature name]
Creation date: 2026-05-22
Goal: [one sentence on what we want to achieve]

## Phase 1: [short name]
- [ ] Step 1.1: [specific action]
- [ ] Step 1.2: [specific action]
- [ ] Step 1.3: [specific action]

## Phase 2: [short name]
- [ ] Step 2.1
- [ ] Step 2.2

## Outcome
Fill in at the end: fully or partially implemented, and what remains.

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

เมื่อแผนอยู่ในไฟล์ ไม่ใช่ในหัวของคุณ:

• หน้าต่างที่ทำงานพร้อมกัน (ดูเคล็ดลับ 6) รับช่วงคนละเฟสได้
• หากงานยืดเยื้อ 3 วัน เมื่อกลับมาหลังจากผ่านไป 2 วัน คุณจะเห็นได้ทันทีว่าค้างไว้ตรงไหน
• ตรวจผลลัพธ์จริงขั้นสุดท้ายได้ง่าย (grep -c "\[ \]" ในไฟล์ = จำนวนรายการที่ยังเปิดอยู่)

ไม่ควรใช้วิธีนี้กับ hotfix 5 นาที การแก้ไขเล็กน้อยในไฟล์เดียว หรือการอ่านและสรุป log ไม่ใช่ทุกการกระทำที่ต้องมีแผน

เทคนิคนี้เป็นส่วนหนึ่งของแนวคิด Second Brain ดูรายละเอียดทั้งหมดเกี่ยวกับโฟลเดอร์ business/, plans/, ai-clone/ ได้ในคู่มือ Second Brain

วิธีสังเกตล่วงหน้าว่า Claude จะพลาดตรงไหน: วิจารณ์ตนเองด้วย 10 เหตุผล#

นี่คือกรอบ prompt ที่ฉันใช้ตามต้นฉบับทุกคำ:

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

หลังจากบอก 10 เหตุผลแล้ว ให้ทำรอบที่สอง: โต้แย้งแต่ละเหตุผลโดยใช้ข้อโต้แย้งของฉัน จุดไหนที่ฉันอ่อนที่สุด?

รอบที่สาม: เขียนแผนว่าควรทำอะไรเพื่อไม่ให้ปัญหาเหล่านี้เกิดขึ้น

ฉันใช้วิธีนี้ในสามช่วง:

1. ตอนเริ่มคิดไอเดีย “ทุกอย่างยอดเยี่ยม” - ตอนที่ฉันมั่นใจ การวิจารณ์ตนเองช่วยหั่นไอเดียลง 30-50%
2. กลางทางของแผน - ตอนที่ฉันลงลึกกับงานไปมากแล้วและเริ่มมองไม่เห็นปัญหา
3. ก่อนเปิดตัว - ตัวกรองขั้นสุดท้าย

Claude ท้าทายคุณจริง ๆ ในโหมดตั้งคำถามแบบตรงไปตรงมา ส่วน GPT-5 ในสถานการณ์เดียวกันจะชมไอเดียก่อน แล้วค่อย “พยายามหาจุดปรับปรุง” ฉันสังเกตความแตกต่างนี้หลังจากทดลองมาหนึ่งปี:

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

อย่าใช้วิธีนี้กับการปรับ UI และงานเขียนข้อความเชิงบวก โหมดตั้งคำถามแบบตรงไปตรงมาไม่เหมาะกับงานเหล่านั้น เพราะจะฆ่าความคิดสร้างสรรค์

เทคนิคนี้เรียกว่า project premortem ฉันปรับมาใช้กับการทำงานร่วมกับ AI agent: แทนที่จะทำ premortem กับทีมคน คุณทำกับ Claude ไม่มีใครกลัวที่จะพูดว่า “หัวหน้า โปรเจกต์นี้จะล้มเหลว” จุดบอดจึงปรากฏขึ้นภายในไม่กี่นาที

วิธีทำวิจัยจาก 5 แหล่งในเวลาที่ปกติใช้ทำแหล่งเดียว: subagents แบบขนาน#

นี่คือกรอบ prompt:

คุณมีบริบททั้งหมดแล้ว จงค้นหาและทำวิจัยเชิงลึก เปิดใช้ subagents 5 ตัวพร้อมกัน

Subagent 1: สำรวจเครือข่ายมืออาชีพ - ใครกำลังแก้ปัญหานี้?
Subagent 2: โซลูชันโอเพนซอร์สบน GitHub - อะไรได้รับความนิยม?
Subagent 3: startup accelerators - ใครกำลังดึงดูด
            การลงทุนใน niche นี้?
Subagent 4: เว็บไซต์ของคู่แข่งโดยตรง - พวกเขาสัญญาอะไรและ
            ราคาเท่าไร?
Subagent 5: การเปรียบเทียบและรีวิว - ผู้ใช้พูดถึงอะไร
            ในรีวิว?

เมื่อทุกตัวกลับมาแล้ว ให้เปิดใช้ synthesis agent
เพื่อเทียบรายงานทั้ง 5 ฉบับและทำโครงร่าง
สำหรับโฟลเดอร์ second-brain ของฉัน

สิ่งที่เปลี่ยนไปจากการวิจัยทั่วไป:

• เวลา: 5 สายงานพร้อมกันแทนที่จะทำทีละสาย ใช้เวลาทำงานหนึ่งชั่วโมงเหลือ 15 นาที
• ความลึก: agent แต่ละตัวเชี่ยวชาญคนละด้าน confirmation bias ของ agent ตัวหนึ่งจึงไม่ปนเปื้อนอีกตัว
• บริบท: subagent แต่ละตัวมีบริบทของตัวเอง แยกจากบริบทหลักของคุณ

ดูคู่มือ subagents ฉบับเต็มได้ที่ “Claude Code Subagents ในปี 2026” ซึ่งอธิบายความแตกต่างระหว่าง Skills กับ MCP และควรใช้สิ่งใดเมื่อใดด้วย

ไม่ควรใช้วิธีนี้กับการแก้ไขด้านความสวยงาม การแก้บั๊ก หรืองานเทคนิคเล็ก ๆ การวิจัยเป็นงานเกินจำเป็นสำหรับสิ่งที่เล็กกว่า “ฟีเจอร์ใหม่ที่ใช้เวลาทำงาน 1+ วัน”

วิธีสั่งงาน Claude จากโทรศัพท์: Telegram bot ในกระเป๋าคุณ#

วิธีตั้งค่า (4 ขั้นตอน):

1. คอมพิวเตอร์ที่เปิดทำงานต่อเนื่อง - ฉันปิดโหมด sleep ในการตั้งค่าระบบ (macOS: Energy Saver → Prevent computer from sleeping)
2. เปิด Claude Code ใน terminal และเชื่อมต่อกับโฟลเดอร์โปรเจกต์
3. Telegram plugin ทางการ - เพิ่ม marketplace ด้วย /plugin marketplace add anthropics/claude-plugins-official จากนั้นติดตั้ง /plugin install telegram@claude-plugins-official (ขั้นตอนที่แน่นอนมีการปรับปรุงอยู่เสมอ - คำแนะนำล่าสุดอยู่ในคลังปลั๊กอินทางการ)
4. bot ผูกกับหนึ่งเซสชัน - นี่เป็นข้อจำกัดในปัจจุบัน: หนึ่ง bot = หนึ่งโปรเจกต์ = หนึ่งเซสชัน หากต้องการอีกตัว ให้ตั้งค่า bot ตัวที่สอง

สิ่งที่ฉันทำกับ bot ทุกวัน:

• ฉันออกไปเดินเล่นแล้วนึกไอเดียได้ - ส่งข้อความให้ bot ทันทีเพื่อไม่ให้ลืม bot จะเพิ่มไอเดียลงใน inbox.md เพื่อจัดการภายหลัง
• คุยกับลูกค้าที่มีโอกาสจะซื้อ - หลังจบสาย ฉันถาม bot ว่า “จาก transcript ของสายล่าสุด บอก pain points หลัก 3 ข้อที่เป็นประโยชน์กับเรา” อีกหนึ่งนาทีต่อมา ฉันก็มีบทวิเคราะห์ครบถ้วนในแชต
• ตอนเช้าที่คาเฟ่ - “แสดงงานที่ยังค้างอยู่จากรายการของฉัน” ไม่ต้องเปิดแล็ปท็อป

⚠️ ข้อจำกัด: ตอนนี้ยังสั่ง /clear หรือ /compact จาก bot ไม่ได้ เพราะเซสชันของ bot เป็นเซสชันเดียวกับ terminal และบริบทก็เพิ่มขึ้นเรื่อย ๆ วิธีเริ่มใหม่ทำได้ด้วยตนเองผ่าน terminal เท่านั้น

สำหรับฉัน นี่คือส่วนขยาย Claude Code ที่มีประโยชน์ที่สุดในช่วงสองสัปดาห์ที่ผ่านมา มันเปลี่ยนจาก “ฉันทำงานกับ Claude ตอนนั่งอยู่ที่โต๊ะ” เป็น “ฉันทำงานกับ Claude ทุกครั้งที่มีความคิด”

ควรเริ่มนำอะไรไปใช้ก่อน: แผน 7 วัน#

การผสมผสานเทคนิคสำคัญกว่าเทคนิคใดเทคนิคหนึ่งเพียงอย่างเดียว Shift+Tab โดยไม่มี Esc Esc ทำให้การทดลองน่ากลัว /compact โดยไม่มี /cost ทำให้ไม่รู้ว่าควรบีบอัดเมื่อใด ส่วนแผนในไฟล์ที่ไม่มีหน้าต่างทำงานแบบขนานก็กลายเป็นความยุ่งยากที่ไม่ให้ผลตอบแทน

หากต้องการทำงานกับโมเดลต่อ ไปที่ Ailoot