คู่มือการใช้งาน Effective Token · V1.0

1.1 หากคุณไม่รู้ว่าอะไรแพง คุณก็ไม่รู้ว่าจะประหยัดอะไร

1.2 โปรไฟล์ Token ของหนึ่งคำขอ

หากต้องการเข้าใจว่าเงินถูกใช้ไปที่ใด คุณต้องเข้าใจองค์ประกอบ Token ของหนึ่งคำขอเสียก่อน

The developer looks only at total cost, not its composition:

- Output has a high share, so they assume the model is too verbose;
- In reality, the Prompt does not constrain the output format, so the model responds freely;
- The optimization effort targets the wrong problem.

After every critical task, the developer routinely checks `/cost`:

- They notice that the proportion of cache-read tokens remains below 20% for a certain task type;
- They check whether the prefix changes frequently or a Skill is reloaded every time;
- After adjustment, the Cache hit rate remains above 70%;
- Input cost for the same task falls to one-third of its previous level.

1.3 เมตริกสำคัญและค่าเป้าหมาย

จากทั้งห้าฟิลด์ข้างต้น เรากำหนดชุดของ SLI ที่ทีมต้องติดตามอย่างต่อเนื่อง

The team looks only at total monthly cost and does not track the metrics above:

- Cache hit rate remains around 30%;
- The Output/Input ratio reaches 5;
- Nobody notices because total cost is still within budget;
- By the time the budget becomes tight, substantial structural waste has accumulated.

The team reviews three metrics in every weekly meeting:

- Cache hit rate: 78%
- Output/Input ratio: 1.2
- Average tokens per task: p50 = 45K, p95 = 180K

Outliers, such as a Skill that suddenly raises p95, receive focused remediation.
Within six months, token cost falls by 55% for the same workload.

1.4 การระบุแหล่งที่มาของค่าใช้จ่ายระดับทีม

ยอดรวมแบบเหมารวมนั้นไม่เพียงพออย่างยิ่ง ต้นทุนต้องถูกระบุแหล่งที่มาหลายมิติ

2.1 คำขอของคุณมักเป็นส่วนที่ถูกที่สุด

A one-line request: "Build a login feature." "Fix bug."

Result:

- The model misunderstands and enters multiple rounds of clarification;
- The number of tool calls doubles;
- Output grows and retries increase;
- Total cost rises instead.

**Root cause**: saving money in the wrong place.

"Please fix this bug. The reproduction steps are..."

- Compress 20K of Skill instructions to 8K by removing filler and merging duplicate rules;
- Limit the number of lines returned by tools (`head -n 100`);
- Reference the exact file with `@path/to/file` instead of making the model search blindly.

2.2 "มันจำได้" เป็นภาพลวงตา

LLM ไม่มีความจำ

เมื่อดูเหมือนว่าโมเดลจำได้ สิ่งที่เกิดขึ้นจริงคือ เนื้อหาก่อนหน้าทั้งหมดถูกส่งไปอีกครั้ง

User request
   ↓
Model decision
   ↓
Tool call
   ↓
Tool result (large!)
   ↓
Model processing
   ↓
Next tool call...

2.3 ต้นทุนห้าประเภท

นอกจาก Input และ Output แล้ว ยังมีต้นทุนอีกสามประเภทที่มักถูกประเมินต่ำเกินไป

2.4 Prompt Cache: รากฐานของการปรับปรุง

Prompt Cache แคชการคำนวณของ prefix ไม่ใช่คำตอบ

2.5 การเสื่อมถอยของคุณภาพใน Context ยาว — ไม่เพียงแพงขึ้น แต่ยังมีประสิทธิภาพน้อยลง

Context ที่ยาวเกินไปทำให้เกิดบทลงโทษสามประการ:

Has the current session exceeded 20 turns?
├─ No  → Is Context usage above 50%?
│        ├─ No  → Continue
│        └─ Yes → Run /compact
└─ Yes → Can you still locate the critical information clearly?
         ├─ Yes → Run /compact
         └─ No  → Start a new session

2.6 โมเดลการกำกับดูแลต้นทุนห้าชั้น

3.1 การแยก Session

[บังคับ] แต่ละ session ต้องรับใช้วัตถุประสงค์ที่ชัดเจนหนึ่งอย่าง อย่าผสมงานที่แตกต่างกันโดยพื้นฐานไว้ใน session เดียวกัน

ความยาวของ session เติบโตไปตามประวัติการสนทนา ดังนั้นทุกคำขอในลำดับถัดไปจึงแพงขึ้น ให้สร้าง session แยกต่างหากสำหรับงานแต่ละประเภท

ตัวอย่างที่ถูกต้อง 1 — เปิดหลาย CodeBuddy session

# Session 1: Fix a nil-pointer dereference in the order module
# Session 2: Refactor the authentication logic in the user service
# Session 3: Add unit tests for the auth module

ตัวอย่างที่ถูกต้อง 2 — รัน /clear หลังจากทำงานเสร็จ

User: Fix bug: http://github.com/project/issues/xxx
AI:   [Bug fix completed]
User: /clear
User: Create an implementation plan for the new requirement at http://github.com/project/issues/xxx

ตัวอย่างที่ไม่ถูกต้อง

# In the same session:
# Fix a nil-pointer dereference in the order module → review an auth-module PR → write a technical
# plan for a new requirement → add unit tests
# Task types are mixed and the history context keeps growing

3.2 บีบอัดประวัติที่ยาว

[บังคับ] เมื่อ session เกิน 20 รอบ หรือเมื่อ Context ประวัติเติบโตขึ้นอย่างมีนัยสำคัญและการใช้งาน Context เกิน 50% ให้รัน /compact หรือสร้าง session ใหม่

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

ตัวอย่างที่ถูกต้อง

AI:   [Completes one phase]
User: /compact
User: Continue with the second phase

ตัวอย่างที่ไม่ถูกต้อง

# Dozens of failed attempts remain in the history during debugging
# After the bug is fixed, unrelated work continues in the same session
# Every subsequent request carries the irrelevant debugging history

3.3 นำข้อมูลออกไปเก็บภายนอก

[แนะนำ] เก็บข้อมูลที่มีอายุยาวนานไว้ในระบบไฟล์ แทนที่จะพึ่งพาความจำของ session

จัดเก็บข้อมูลที่มีอายุยาวนานในตำแหน่งที่เหมาะสม:

• เอกสารของโปรเจกต์ เช่น README และ CONTRIBUTING
• ไฟล์ Memory เช่น CODEBUDDY.md / CLAUDE.md
• ไฟล์สรุป / บันทึกการตัดสินใจ
• รายการงาน / Issues

session ควรพกพาเฉพาะสถานะการทำงานปัจจุบัน ไม่ใช่ประวัติทั้งหมดของโปรเจกต์

ตัวอย่างที่ถูกต้อง

# Record the database selection decision in docs/decisions/001-database-selection.md
# Record the team's API naming conventions in CODEBUDDY.md / CLAUDE.md
# Discuss only the interface currently being changed in the session

ตัวอย่างที่ไม่ถูกต้อง

# Discuss database selection, API conventions, and exception-handling strategy
# in detail within the session
# Depend on the Agent to reference these discussions automatically later
# The session keeps growing, and other team members cannot easily find the decisions

3.4 การจัดการ Skill

[บังคับ] ยึดหลักการ "จำกัด Skill ที่โหลดตลอดเวลาให้น้อยที่สุด; โหลด Skill ที่ใช้ไม่บ่อยในระดับโปรเจกต์" อย่าติดตั้ง Skill จำนวนมากไว้ที่ระดับผู้ใช้โดยไม่เลือก

ทุก Skill ประกอบด้วย Description, Instructions, Examples และตรรกะการ trigger หากข้อมูลนี้ยังคงประจำอยู่ใน Context มันจะส่งผลต่อการใช้ Token ในทุกคำขอ

ตัวอย่างที่ถูกต้อง

# User-level resident Skills: frequently used general-purpose Skills such as
# commit, code-review, and unit-test
# Project-level Skills: framework-specific workflows such as gRPC code generation,
# or tool-specific workflows such as database migration scripts
# Periodic cleanup: remove Skills that have not been used for more than two weeks

ตัวอย่างที่ไม่ถูกต้อง

# Install 30+ user-level Skills at once, covering Python, Go, Rust, frontend,
# operations, and other technology stacks
# Only commit, code-review, and unit-test are used in day-to-day work
# Definitions for all other Skills remain in the context and continuously consume tokens

3.5 การจัดการ MCP

[บังคับ] จำกัดชุดเครื่องมือ MCP ให้เหลือเท่าที่จำเป็นที่สุด การเพิ่ม MCP server ทุกตัวหมายถึงการเพิ่ม Tool Definition อีกชุดและเพิ่มภาระในการเลือกเครื่องมือ

เครื่องมือที่มากเกินไปไม่ได้เพิ่มเพียงปริมาณข้อความนิยามเท่านั้น แต่ยัง:

• ขยายพื้นที่การเลือกและเพิ่ม latency ในการตัดสินใจ
• เพิ่มความน่าจะเป็นของการเรียกเครื่องมือผิด
• เพิ่ม payload นิยามที่ทุกคำขอต้องแบกรับ

ตัวอย่างที่ถูกต้อง

# User-level resident tool: Headroom context compression
# Project level: no more than five MCP servers for the current project's core business
# Disable or remove: infrequently used MCP servers unrelated to the current project

ตัวอย่างที่ไม่ถูกต้อง

# Install GitHub, Notion, TAPD, Gongfeng, Browser, Kubernetes, Docker, and multiple
# internal-system MCP servers at the user level
# The nominal feature set is comprehensive, but only Filesystem and Git are used frequently

3.6 การเลือกใช้ระหว่าง CLI กับ MCP

[บังคับ] ใช้ MCP เป็นค่าเริ่มต้น ให้กลับไปใช้ CLI ก็ต่อเมื่อ CLI นั้นปรากฏอย่างแพร่หลายในข้อมูลฝึกอบรมของ AI ดังเช่นกรณีของเครื่องมือหลักๆ เช่น git, gh, kubectl, docker, npm และ pip

การแลกเปลี่ยนที่เป็นศูนย์กลางคือ: CLI หลีกเลี่ยงต้นทุนในการโหลด Tool Definition ซึ่งลด Token ต่อรอบ อย่างไรก็ตาม เมื่อ AI ขาดความรู้พื้นฐานที่เชื่อถือได้เกี่ยวกับ CLI นั้น มันอาจสะกด flag ผิด ใช้ subcommand ผิด หรือคิดค้นอาร์กิวเมนต์ขึ้นมาเองได้ง่าย ซึ่งจะกระตุ้นให้เกิดการลองใหม่ ดังที่อธิบายไว้ในบทที่ 2 การลองใหม่หนึ่งครั้งมีต้นทุนประมาณหนึ่งคำขอที่สมบูรณ์ (⭐⭐⭐⭐⭐) ซึ่งมักมากกว่า Tool Definition ที่ประหยัดไปมาก MCP ใช้ Token นิยามจำนวนเล็กน้อยในแต่ละรอบเพื่อแลกกับสคีมาพารามิเตอร์ที่เป็นมาตรฐาน คำอธิบายที่ชัดเจนกว่า และการเรียกผิดและการลองใหม่ที่น้อยลง

แนวทางการเลือก

วิธีประเมินว่า AI รู้จัก CLI หรือไม่

"เป็นเครื่องมือหลักและ AI คุ้นเคย" ไม่ใช่มาตรฐานที่แน่นอน แต่เกณฑ์ด้านล่างสามารถช่วยได้ หากไม่แน่ใจ ให้ใช้ MCP เป็นค่าเริ่มต้น ต้นทุนของความผิดพลาดไม่สมมาตร: การปฏิบัติต่อ CLI ที่ไม่เป็นที่รู้จักเสมือนเป็นเครื่องมือหลักอาจกระตุ้นการลองใหม่ที่มีต้นทุน ⭐⭐⭐⭐⭐ ในขณะที่การปฏิบัติต่อ CLI หลักเสมือนว่าไม่เป็นที่รู้จักแล้วใช้ MCP จะเพิ่มเพียง Tool Definition ไม่กี่กิโลไบต์

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

ตัวอย่างที่ถูกต้อง — CLI ชนะ

# Inspect Git changes; the AI is highly familiar with git
git diff --stat
git log --oneline -10

# Create a PR; gh is extensively represented in training data
gh pr create --title "feat: add batch query for UserService" --body "..."

ตัวอย่างที่ถูกต้อง — MCP ชนะ

# The AI has no prior knowledge of a proprietary internal release-system CLI
# and can easily misspell a flag and trigger a retry
# Wrap it as an MCP Tool with a standardized schema describing its parameters and behavior

# The AI must make a structured decision based on the previous result
# Example: query inventory → decide whether to scale based on the structured result
# → call the scaling API
# MCP's structured return value avoids cascading retries caused by CLI-output parsing failures

ตัวอย่างที่ไม่ถูกต้อง

# Mature CLIs such as gh and kubectl are already highly familiar to the AI,
# yet GitHub and Kubernetes MCP servers are installed as well
# The context gains several kilobytes of Tool Definitions without improving call accuracy

# A proprietary internal CLI is called directly without an MCP wrapper
# Every call becomes a gambling loop: guess arguments → receive an error
# → interpret the error → guess again; retry cost becomes uncontrolled

3.7 อ้างอิงไฟล์ด้วยพาธแบบเต็ม (@path)

[บังคับ] เมื่ออ้างอิงไฟล์ ให้ใช้ @ ตามด้วยพาธแบบเต็มหรือแบบสัมพัทธ์ อย่าให้เพียงชื่อไฟล์แล้วปล่อยให้ Agent ไปค้นหาเอง

การให้เพียงชื่อไฟล์จะกระตุ้น workflow แบบ "ค้นหา → อาจต้องยืนยันหลายครั้ง → อ่าน" ในขณะที่พาธแบบเต็มทำให้สามารถระบุตำแหน่งและอ่านไฟล์ได้โดยตรง โปรเจกต์ยิ่งใหญ่ การค้นหาก็ยิ่งแพง

ตัวอย่างที่ถูกต้อง

Review the transaction-handling logic in CreateOrder at @src/order/service.go
Modify the token-validation logic in @internal/auth/middleware.go

ตัวอย่างที่ไม่ถูกต้อง

Review the transaction-handling logic in service.go
Modify the token-validation logic in middleware.go
# The Agent must traverse the project tree, find files with the same name,
# confirm the intended target, and then read it

3.8 ระบุความต้องการทั้งหมดให้ครบถ้วน

[บังคับ] ระบุวัตถุประสงค์ของงาน บริบท และเกณฑ์การยอมรับให้ครบถ้วนในข้อความเดียว หลีกเลี่ยงการขอทีละเล็กทีละน้อยแบบไป-กลับ

ทุกการโต้ตอบใช้ Token ไปกับการประกอบ Context ใหม่ การโหลดประวัติซ้ำ และการยืนยันสถานะใหม่ การขอที่ครบถ้วนในข้อความเดียวมีประสิทธิภาพสูงกว่าการยืนยันแบบเพิ่มทีละส่วนหลายรอบอย่างมีนัยสำคัญ

ตัวอย่างที่ถูกต้อง

Review the CreateOrder function in @src/order/service.go, identify potential defects,
fix them, and write unit tests for the corrected function.

ตัวอย่างที่ไม่ถูกต้อง

User: Take a look at the CreateOrder function
AI:   What aspects should I check?
User: See whether it has any bugs
AI:   Inventory deduction is not protected by a transaction. Should I fix it?
User: Fix it
AI:   The fix is complete. Should I add tests?
User: Yes, add them

3.9 เลือกใช้เครื่องมือมากกว่าการให้เหตุผลของ LLM

[บังคับ] เลือกวิธีการดำเนินการตามลำดับนี้: ใช้เครื่องมือเฉพาะทางที่มีอยู่แล้ว > เขียนสคริปต์ > พึ่งพาการให้เหตุผลของ LLM

คุณค่าหลักของ LLM คือการจัดการกับความไม่แน่นอน — งานที่ต้องการความเข้าใจบริบท การให้เหตุผล การตัดสินใจ และการแลกเปลี่ยน สำหรับการดำเนินการเชิงกลที่มี workflow แบบกำหนดได้และมีกฎที่ชัดเจน ให้เลือกเครื่องมือเฉพาะทางหรือสคริปต์

ตัวอย่างที่ถูกต้อง

# Existing specialized tool: code linting
golangci-lint run ./...

# Existing specialized tool: code formatting
gofmt -w ./src

# Existing specialized tool: database migration
alembic upgrade head

ตัวอย่างที่ไม่ถูกต้อง

User: Check whether this Go code has formatting problems
AI:   Reads every file → analyzes indentation, naming, and import order line by line
      → outputs modification suggestions
# golangci-lint can do this with one command; Agent reasoning is both inefficient
# and vulnerable to misjudgment

User: I need the number of paid machines over the past 30 days, every day
AI:   Re-reads the table schema and sample data every day → estimates the count
# Instead, have the AI generate a fixed script and execute it to obtain the result

3.10 โหลดเครื่องมือแบบ Lazy-Load

[แนะนำ] กำหนดค่าเครื่องมือที่ไม่ได้ใช้บ่อยให้โหลดแบบรอได้ (deferred) ด้วย Defer เพื่อไม่ให้นิยามของมันประจำอยู่ใน Context

ตามค่าเริ่มต้น นิยามของเครื่องมือที่ลงทะเบียนไว้ทั้งหมดจะถูกแทรกเข้าไปใน Context ของทุกคำขอ เครื่องมือยิ่งมาก ต้นทุน Token ที่ประจำอยู่ก็ยิ่งมาก CodeBuddy รองรับตัวปรับแต่ง (modifier) Defer(...) สำหรับทำเครื่องหมายเครื่องมือที่ไม่จำเป็นให้โหลดแบบ lazy นิยามของมันจะไม่ปรากฏในรายการเครื่องมือของโมเดล และจะถูกโหลดและเรียกใช้ก็ต่อเมื่อโมเดลค้นพบมันด้วยตนเองผ่าน ToolSearch

ตัวอย่างที่ถูกต้อง — Agent

# .codebuddy/agents/code-reviewer.md
---
name: code-reviewer
description: Code review agent
tools:
  - Read
  - Grep
  - Bash
  - Defer(Glob)          # Lazy-loaded: discovered through ToolSearch only when file search is needed
  - Defer(WebFetch)      # Lazy-loaded: triggered only when online documentation is needed
---

ตัวอย่างที่ถูกต้อง — CodeBuddy

# Specify lazy-loaded tools when starting the CLI
codebuddy --tools "Read,Edit,Bash,Defer(Glob),Defer(Grep),Defer(WebFetch)"

ตัวอย่างที่ถูกต้อง — MCP

{
  "mcpServers": {
    "mcp-server-tapd": {
      "command": "uvx",
      "args": ["mcp-server-tapd"],
      "defer_loading": true
    }
  }
}

ตัวอย่างที่ไม่ถูกต้อง

---
name: research-agent
description: Conduct research through multiple web search engines
# Omitting a tools declaration enables many built-in CodeBuddy tools by default
---
XXX content

4.1 จับคู่กับงานก่อน อย่าเพียงเลือกโมเดลที่ถูกที่สุด

Model routing ไม่ได้หมายถึง "ใช้โมเดลที่ถูกที่สุดเสมอ" แต่หมายถึงการจัดประเภทงานให้ถูกต้องเสียก่อน:

• งานที่ซับซ้อน → โมเดลที่ทรงพลัง
• งานที่เรียบง่าย → โมเดลราคาประหยัด
• งานที่ทำซ้ำ → โมเดลที่มีความเสถียร

การออกแบบสถาปัตยกรรมต้องอาศัยการให้เหตุผลหลายขั้นตอน ดังนั้นจงใช้โมเดลราคาแพงเมื่อจำเป็น โมเดลราคาประหยัดก็เพียงพอโดยสมบูรณ์สำหรับการเขียน unit test การเพิ่มคอมเมนต์ หรือการสร้าง commit message ส่วนการจัดหมวดหมู่และการสรุปขนาดใหญ่เหมาะกับโมเดลต้นทุนต่ำหรือการประมวลผลแบบ batch แบบออฟไลน์มากกว่า

4.2 การจับคู่งานกับโมเดล

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

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

4.3 ผูกโมเดลเข้ากับ Skills / Agents / Commands

Model routing ไม่ควรมีอยู่เพียงเป็นกฎในหัวของการสนทนาหลัก แต่ควรถูกนำไปใช้ในหน่วยปฏิบัติการ

ผูกโมเดลเข้ากับ Skills: ผูกโมเดลราคาประหยัดเข้ากับ Skill อย่างชัดเจน สำหรับการเขียน unit test การสร้าง commit การแก้รูปแบบ และการสร้างโค้ดแบบ boilerplate

ใน CodeBuddy เป็นต้น frontmatter ของไฟล์ SKILL.md สามารถประกาศโมเดลและกลยุทธ์ Context ได้โดยตรง:

---
name: XXX
description: XXXX
context: fork
model: deepseek-v4-pro
---

ฟิลด์ model ระบุโมเดลที่ Skill ใช้ context: fork รัน workflow ที่ตายตัวนี้ใน Context การปฏิบัติงานแบบแยกส่วน ซึ่งเหมาะสมกับ Skill ที่มีขอบเขตชัดเจนและสามารถทำงานให้สำเร็จได้ด้วยตนเอง สิ่งนี้ทำให้ Skill ที่มีความซับซ้อนต่ำใช้โมเดลราคาประหยัดโดยอัตโนมัติโดยไม่ต้องแบกประวัติทั้งหมดของ session หลัก

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

Planner  → Mid-to-high tier
Coder    → Mid tier
UnitTest → Inexpensive
Reviewer → Powerful

หมายเหตุ: ใน CodeBuddy คีย์เวิร์ด lite หมายถึงโมเดลราคาประหยัดหรือน้ำหนักเบา โดยจะเลือกโมเดลคู่ที่ต้นทุนต่ำกว่าของโมเดลที่ผู้ใช้เลือกโดยอัตโนมัติ เช่น หากผู้ใช้เลือก deepseek-v4-pro โมเดล lite จะเป็น deepseek-v4-flash ผู้ใช้ยังสามารถตั้งค่าตัวแปรสภาพแวดล้อม CODEBUDDY_SMALL_FAST_MODEL="hy3-ioa" เพื่อระบุโมเดลที่เจาะจงซึ่ง lite แทนได้

frontmatter ต่อไปนี้นิยาม Agent ที่ใช้โมเดลน้ำหนักเบา:

---
name: AgentName
description: XXXX
model: lite
tools: Read, Grep, Glob, Bash
---

ผูกโมเดลเข้ากับ Commands: Command หลายตัว เช่น /commit และ /check-ci-status เป็นไปตามเทมเพลตที่ตายตัว และเหมาะสมอย่างยิ่งกับการใช้โมเดลราคาประหยัดที่ตั้งไว้ล่วงหน้า

เมื่อการออกแบบนี้ถูกเข้ารหัสไว้ การกำกับดูแลต้นทุนจะเปลี่ยนจาก "ต้องจำว่าต้องสลับโมเดล" ไปเป็น "ระบบมีความคุ้มทุนเป็นค่าเริ่มต้น" ต่อไปนี้คือตัวอย่างของ Command frontmatter:

---
description: "XXX"
argument-hint: "[message]"
allowed-tools: Bash(git:*)
model: lite
---

5.1 CLAUDE.md ของ Karpathy: การตัดแต่งอัตโนมัติและจุดยึดเหนี่ยวต้านภาพหลอน

[แนะนำ] หากทีมยังไม่มีข้อตกลงทางเลือกอื่น พิจารณานำ Andrej Karpathy's CLAUDE.md มาใช้ตามความเหมาะสมกับโปรเจกต์

ตำแหน่ง: เทมเพลต CLAUDE.md คุณภาพสูงที่พัฒนาโดยชุมชน ผ่านชุดกฎที่กำหนดไว้ล่วงหน้า มันกำหนดให้โมเดลตัดแต่ง Context ลดคำฟุ่มเฟือย ระงับภาพหลอน และบังคับใช้ข้อตกลงทางวิศวกรรม

CLAUDE.md ของ Andrej Karpathy มุ่งแก้ปัญหาว่าโมเดลควรคิดอย่างไร มันฝังโปรโตคอลการให้เหตุผลที่มีประสิทธิภาพไว้ที่ชั้น System Prompt เพื่อลดการสร้าง Token ที่ไม่จำเป็นตั้งแต่ต้นทาง

---
# Global response strategy
- Minimalism: Unless an explanation is requested, output only code blocks. Do not
  include pleasantries such as "Okay" or "Let me help you."
- Determinism: If the Read tool returns empty or no results, stop and report an
  error immediately. Do not guess the file contents.
- Tools first: When a task concerns file content, code definitions, or Git status,
  call a tool. Never guess based on memory.

# Context management
- Search before reading: In an unfamiliar codebase, use Grep/Glob before deciding
  what to Read.
- Line limits: When reading a file, specify `offset` and `limit`; read no more than
  200 lines by default.
- Focus changes: After modifying code, show only the relevant diff. Do not repeat
  the entire file.

# Output format
- Present information with Markdown lists and tables.
- Include necessary comments in code snippets, but remove redundant sample output.
---

# Project-specific rules: insert the project's architecture, technology stack,
# and special conventions here

5.2 RTK — Rust Token Killer

[แนะนำ] ลดปริมาณ output ของเครื่องมือและการใช้ Token อย่างรวดเร็ว

ตำแหน่ง: สกัดกั้น output ของคำสั่ง shell และบีบอัดก่อนที่ Agent จะเห็น มันบีบอัดเฉพาะ output ของ CLI ไม่ใช่ Prompt หรือโค้ด

# 1. Install the internal fork; Rust must already be installed
git clone https://git.woa.com/godwinchen/rtk.git
cd rtk && cargo install --path .

rtk init --global --agent codebuddy   # Install the hook to intercept all commands transparently
rtk gain                              # Confirm that savings data is available

Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 10 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 2.34 KiB | 2.34 MiB/s, done.
Total 8 (delta 5), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (5/5), completed with 3 local objects.
To github.com:org/repo.git
   abc1234..def5678  main -> main

ok main

PASS src/utils.test.ts
PASS src/config.test.ts
...
PASS src/chain.test.ts
FAIL src/order.test.ts > should handle empty cart
  AssertionError: expected 400 got 500
    at Object.<anonymous> (src/order.test.ts:42:17)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Promise (src/order.test.ts:38:3)
    at async Context.<anonymous> (src/order.test.ts:35:5)
FAIL src/auth.test.ts > expired token
  Error: timeout of 2000ms exceeded
    at Object.<anonymous> (src/auth.test.ts:18:12)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Promise (src/auth.test.ts:14:3)

Test Suites: 2 failed, 43 passed, 45 total
Tests:       2 failed, 178 passed, 180 total
Snapshots:   0 total, 0 failed
Time:        12.345 s
Ran all test suites.

FAIL 2/45 tests
  src/order.test.ts > should handle empty cart → expected 400 got 500
  src/auth.test.ts > expired token → timeout

5.3 Caveman

Caveman เป็นปลั๊กอินบีบอัด output สำหรับ AI coding Agent กฎใน Prompt ทำให้โมเดลตอบกลับแบบ "มนุษย์ถ้ำอัจฉริยะ": ตัดคำฟุ่มเฟือยและมารยาททางสังคมออกไป ในขณะที่ยังคงรักษาข้อเท็จจริงทางเทคนิคไว้

# macOS · Linux · WSL · Git Bash
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

# Windows · PowerShell 5.1+
irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex

/plugin marketplace add https://github.com/studyzy/caveman

# Select the caveman plugin after running the command. The system returns:
#  ⎿ ✓ Added marketplace: caveman
#  ⎿ ✓ Installed caveman. Restart CodeBuddy Code to load new plugins.

Hook SessionStart
  CAVEMAN MODE ACTIVE — level: full
  Respond terse like smart caveman. All technical substance stay. Only fluff die.
……

5.4 Ponytail

แก่นของ Ponytail ไม่ใช่ "วิธีเขียนโค้ด" แต่เป็นสิ่งที่ต้องพิจารณาก่อนเขียนโค้ด มันนิยามลำดับการตัดสินใจที่เข้มงวด:

Level 1: Does this really need to be built? (YAGNI)
Level 2: Does the codebase already contain it? Reuse it
Level 3: Can the standard library do it? Use it
Level 4: Does the browser / operating system provide it natively? Use it
Level 5: Is it available in an already-installed dependency? Use it
Level 6: Can it be done in one line? Write one line
Level 7: Only if none of the above works, write the minimum amount of new code

แต่ละระดับคือด่านตรวจ การไปถึงระดับ 7 หมายถึงการเริ่มเขียนโค้ดจริงๆ แต่ความต้องการส่วนมากจะถูกหยุดไว้ที่ระดับก่อนหน้า วิศวกรที่มีประสบการณ์จะไม่สร้างไฟล์ใหม่ทันที — พวกเขาจะ grep หาวิธีแก้ที่มีอยู่แล้วใน codebase ก่อน

/plugin marketplace add https://github.com/studyzy/ponytail

# After adding the marketplace, select the ponytail plugin.
# If you did not select it, run:
/plugin install ponytail@ponytail

5.5 การเปรียบเทียบเครื่องมือทั้งสี่

สรุปเครื่องมือละหนึ่งประโยค:

• Karpathy's CLAUDE.md ทำให้ Agent คิดให้ชัดก่อนลงมือทำ
• RTK บีบอัดสิ่งที่ Agent เห็น
• Caveman บีบอัดสิ่งที่ Agent พูด
• Ponytail บีบอัดโค้ดที่ Agent เขียน

เครื่องมือทั้งสี่ครอบคลุมมิติของการบีบอัดที่ต่างกัน และสามารถนำมารวมกันเป็น pipeline ที่สมบูรณ์ได้:

Agent calls a command
    ↓
RTK (first stage: compress CLI command output)
    ↓
LLM receives clean input
    ↓
Ponytail (controls what to write: do not write unnecessary code)
    +
Caveman (controls how to say it: remove unnecessary prose)
    ↓
Compressed output is returned to the user

6.1 เหตุใด Agent เดี่ยวจึงแพงขึ้นเมื่อเวลาผ่านไป

สาเหตุหลัก: Transformer ไม่มีความจำ

สถาปัตยกรรม Transformer ที่ LLM ใช้งานไม่มีความจำข้ามรอบ ในทุกๆ รอบ จะต้องส่ง "System Prompt + ประวัติการสนทนา + input ปัจจุบัน" ที่สมบูรณ์ไปยังโมเดลอีกครั้ง ซึ่งหมายความว่า:

Turn 1: Context = System Prompt
Turn 2: Context = System Prompt + turn 1
Turn 3: Context = System Prompt + turn 1 + turn 2
...
Turn N: Context = System Prompt + all previous N-1 turns

การเพิ่มข้อมูลที่ไม่เกี่ยวข้องมากเกินไปยังลดคุณภาพของการตอบกลับด้วย งานวิจัยได้แสดงให้เห็นซ้ำๆ ผ่านปรากฏการณ์ "Lost in the Middle": โมเดลให้ความสนใจกับข้อมูลที่อยู่ตรงกลางของ Context น้อยที่สุด Context Engineering ที่ดีไม่ใช่การแทรกข้อมูลให้มากที่สุดเท่าที่จะทำได้ แต่คือการเลือกข้อมูลที่จำเป็นในขณะนี้อย่างระมัดระวัง

6.2 Subagents: รูปแบบการแยกงานที่มีต้นทุนต่ำที่สุด

เหตุใด Subagents จึงประหยัด Token?

กลไกหลัก: Subagent มี Context แบบแยกส่วนและใช้ครั้งเดียว การเติบโตแบบกำลังสองถูกจำกัดไว้ภายใน Subagent ในขณะที่ประวัติของ Agent หลักเติบโตเชิงเส้น

API ของ LLM เป็นแบบ stateless และทุกการเรียกเครื่องมือจะส่งประวัติที่สมบูรณ์กลับไปใหม่ ดังนั้นวิธีที่ประวัติสะสมจึงเป็นตัวกำหนดว่าการใช้ Token จะเติบโตแบบเชิงเส้นหรือแบบกำลังสอง

Main Agent: Poll N×K times → read entire large files → process intermediate artifacts
            Every message resends all preceding history
            ⇒ Main history is O(N×K), and every turn resends it in full
            ⇒ Total tokens ≈ O((N×K)²), quadratic growth

Subagent: Poll N×K times → read entire large files → process intermediate artifacts
          This remains in the Subagent's one-time context and does not enter main history

Main Agent: Receive only a concise result for each task, with no intermediate artifacts
            ⇒ Main history is O(N), adding only one result per task
            ⇒ Total tokens ≈ O(N), linear growth

7.1 ขีดจำกัดสูงสุดของการปรับปรุงระดับบุคคล

เทคนิคการปรับปรุงการใช้ Token ที่บุคคลหนึ่งทำได้นั้นค่อนข้างสมบูรณ์แล้ว:

เทคนิคเหล่านี้ให้ผลตอบแทนเชิงเส้น แต่ละคนสำรวจ Prompt ที่ดีที่สุดด้วยตนเอง พบกับหลุมพรางเดียวกัน และสั่งสมความรู้เดียวกัน ในทีมสิบคน หลุมพรางเดียวกันอาจถูกพบถึงสิบครั้ง และแนวปฏิบัติที่ดีที่สุดเดียวกันอาจถูกค้นพบใหม่โดยอิสระถึงสิบครั้ง

สูตรการทวีคูณสำหรับการทำงานร่วมกันของทีม:

Team savings = one-time optimization investment × number of users × average daily usage frequency

หากการขัดเกลา Skill หนึ่งตัวใช้เวลาสองชั่วโมง และมีสิบคนใช้งานคนละสามครั้งต่อวัน การลงทุนสองชั่วโมงนั้นจะส่งมอบคุณค่าผ่านการใช้งาน 30 ครั้งในทุกๆ วัน

7.2 สร้างและแบ่งปันทรัพยากรของทีม

Team member A contributes a Skill
       ↓ push (creates a PR, merged after review)
   Team Repo (Git repository)
       ↓ pull (triggered automatically at CodeBuddy SessionStart)
AI tools used by team members B/C/D... automatically receive the Skill

8.1 หลักการ 5 ข้อ

1. วัดผลก่อน แล้วจึงปรับปรุง
2. อย่าแก้ปัญหาซ้ำในสิ่งที่สามารถบันทึกเป็นทรัพยากรได้
3. prefix ที่เสถียรเป็นสิ่งจำเป็นต่อการแคชที่มีประสิทธิภาพ
4. คุณภาพของ Context สำคัญกว่าปริมาณของ Context
5. ความสอดคล้องของทีมสำคัญกว่าความสมบูรณ์แบบของบุคคล

8.2 สูตรหลักที่ปรับปรุงใหม่

Lower cost =
    less repeated context
  + more appropriate model routing
  + more precise code retrieval
  + clearer Agent responsibilities
  + measurable, continuous optimization
  + organization-wide asset reuse

8.3 ข้อแนะนำระยะยาวสามประการ

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