คู่มือเขียน Agent System Prompt ฉบับสมบูรณ์ — ถอดบทเรียนจากการทำ Reverse-Engineering Claude Code

ผมลองแกะ System Prompt ของ Claude Code, นั่งไล่ดู Source Code ของ DeepAgents แล้วปั้น AI Agent ของตัวเองขึ้นมาใหม่จากศูนย์ คู่มือสอนเขียน Prompt ส่วนใหญ่มันก็แค่ฟีลลิ่ง

ตอนนี้วงการ AI กำลังมีความเชื่อผิดๆ ครั้งใหญ่เกิดขึ้นครับ

บทความสอนเขียน Prompt แทบทุกอันบอกให้คุณเขียน System Prompt ราวกับกำลังร่ายมนตร์ — แค่หาคาถาที่ถูกต้องให้เจอ แล้วโมเดลจะยอมทำตามทุกอย่าง "คุณคือ Senior Engineer ที่เก่งกาจหาตัวจับยากและมีประสบการณ์มา 20 ปี..." คุ้นๆ มั้ยครับ?

ช่วงหลายเดือนที่ผ่านมา ผมขลุกอยู่กับการสร้าง VibeCom ซึ่งเป็น AI ที่ปรึกษาสำหรับ Startup ที่สามารถทำรีเสิร์ชตลาดเชิงลึกและวิเคราะห์ข้อมูลระดับ VC ได้ ระหว่างทาง ผมได้ลองแกะรอย (Reverse-engineer) System Prompt ของ Claude Code, นั่งไล่อ่าน Source Code ส่วน Middleware ของ DeepAgents และผลาญ API Credit ไปเยอะจนไม่อยากจะนับ บทเรียนที่ยิ่งใหญ่ที่สุดที่ผมได้เรียนรู้คืออะไรน่ะเหรอ? สิ่งที่คนส่วนใหญ่คิดว่าสำคัญในการเขียน System Prompt จริงๆ แล้วมันแทบไม่สำคัญเลย และสิ่งที่สำคัญจริงๆ กลับแทบไม่มีใครพูดถึง

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

1. ปรัชญาการออกแบบ: จงเชื่อใจโมเดล

"Agent คือ Model ไม่ใช่ Framework และไม่ใช่ Prompt Chain" — shareAI-lab/learn-claude-code

แนวคิดนี้เปลี่ยนมุมมองผมไปเลยครับ LLM รู้วิธีการใช้เหตุผล วางแผน และลงมือทำอยู่แล้ว System Prompt ของคุณไม่ได้มีหน้าที่สอนให้มันคิด — แต่มันมีหน้าที่สร้าง "สภาพแวดล้อม" ให้มันทำงานต่างหาก

ลองคิดซะว่าเหมือนคุณกำลังจ้าง Senior Engineer สักคน คุณคงไม่ยื่น Checklist 20 ข้อให้เขาทำตามทุกกระเบียดนิ้วหรอกใช่มั้ย คุณแค่บอกเขาว่า: เราคือใคร, ขอบเขตการทำงานอยู่ตรงไหน, และผลลัพธ์ที่ดีหน้าตาเป็นยังไง จากนั้นคุณก็แค่ปล่อยให้เขาโชว์ฝีมือ

System Prompt ของคุณมีหน้าที่หลักๆ แค่ 4 อย่าง เท่านั้น:

บอกว่าเขาคือใคร — บทบาทและตัวตน
บอกว่ากำแพงอยู่ตรงไหน — ข้อจำกัดด้านความปลอดภัย
บอกว่าผลลัพธ์ที่ดีคืออะไร — มาตรฐานคุณภาพ
ให้เครื่องมือ — ความสามารถและคลังความรู้

แค่นี้แหละครับ นอกเหนือจากนี้คือ Noise (สิ่งรบกวน) ทั้งหมด

แนวคิดแบบ Harness (ชุดควบคุม)

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions
(ชุดควบคุม = เครื่องมือ + ความรู้ + การสังเกตการณ์ + อินเทอร์เฟซการลงมือทำ + สิทธิ์การเข้าถึง)

System Prompt ของคุณคือคู่มือการใช้งานชุดควบคุมนี้ คุณไม่ได้กำลังออกแบบ Pipeline ที่แข็งทื่อ — แต่คุณกำลังออกแบบ สภาพแวดล้อมที่โมเดลสามารถดึงศักยภาพสูงสุดออกมาทำงานได้ด้วยตัวเอง

อย่าเขียน System Prompt เป็น Flowchart ครับ ปล่อยให้โมเดลตัดสินใจลำดับการทำงานด้วยตัวมันเอง

2. โครงสร้าง Prompt และลำดับของเนื้อหา

โครงสร้างที่แนะนำ (แกะรอยมาจาก Claude Code v2.0.14)

┌─────────────────────────────────────────────┐
│ 1. Identity (ตัวตน)                          │  ← อ่านเป็นอันดับแรก ใช้ยึดเหนี่ยวพฤติกรรม
│ 2. Security & Safety (ความปลอดภัย)           │  ← จุดสำคัญมาก ห้ามละเมิดเด็ดขาด
│ 3. Tone & Style (น้ำเสียงและสไตล์)            │  ← ควบคุมรูปแบบผลลัพธ์
│ 4. Core Workflow (กระบวนการทำงานหลัก)         │  ← วิธีการทำงาน
│ 5. Tool Usage Policy (นโยบายการใช้เครื่องมือ)   │  ← ลำดับความสำคัญในการเลือกใช้เครื่องมือ
│ 6. Domain Knowledge (ความรู้เฉพาะทาง)         │  ← โหลดเมื่อจำเป็น ไม่ใช่ยัดไปตั้งแต่แรก
│ 7. Environment Info (ข้อมูลสภาพแวดล้อม)       │  ← บริบทตอนรันไทม์ แทรกเข้ามาแบบไดนามิก
│ 8. Reminders (การย้ำเตือน)                    │  ← ย้ำกฎเหล็กที่สำคัญอีกครั้ง
├─────────────────────────────────────────────┤
│ [Tool Definitions — ระบบแทรกเข้ามาให้]         │  ← แก้ไขไม่ได้ และมักจะยาวมาก
├─────────────────────────────────────────────┤
│ [User Message]                               │
└─────────────────────────────────────────────┘

ทำไมลำดับถึงสำคัญ?

LLM มีกราฟความสนใจแบบรูปตัว U (U-shaped attention curve) — มันจะให้ความสนใจกับช่วงต้นและช่วงท้ายของ Prompt มากที่สุด และมักจะเบลอๆ กับเนื้อหาตรงกลาง นี่คือปรากฏการณ์ "Lost in the Middle" ที่มีงานวิจัยรองรับชัดเจน

Identity + Safety อยู่บนสุด: โมเดลจะสร้างบทบาทและขอบเขตก่อนเป็นอันดับแรก (Primacy effect)
Core Workflow อยู่ช่วงกลางค่อนบน: นี่คือส่วนที่สำคัญที่สุดของคุณ — บอกวิธีที่ Agent ควรทำงาน
Tool Definitions จะถูกระบบแทรกเข้ามาต่อจาก Prompt ของคุณ: คำอธิบายเครื่องมือของ Claude Code กินพื้นที่ประมาณ 11,438 Tokens แปลว่าเนื้อหาที่คุณเขียนเองจริงๆ แล้วจะอยู่ค่อนไปทางจุดเริ่มต้นมากกว่าที่คุณคิด — ซึ่งนั่น ช่วย ให้โมเดลทำตามคำสั่งได้ดีขึ้น
Reminders อยู่ล่างสุด: ใช้ประโยชน์จาก Recency bias (การจำสิ่งล่าสุดได้ดีกว่า) เพื่อย้ำกฎเหล็ก

3. วิธีเขียนแต่ละส่วน

3.1 Identity — Agent ตัวนี้คือใคร?

เป้าหมาย: กำหนดบทบาทของโมเดลให้ชัดเจนใน 1-3 ประโยค

You are Claude Code, Anthropic's official CLI for Claude.
You are an interactive agent that helps users with software engineering tasks.

แนวทางปฏิบัติ:

สั้นและกระชับ — ไม่เกิน 1-3 ประโยค
ระบุชื่อบทบาทให้ชัดเจน (ช่วยให้โมเดลแยกแยะบริบทได้)
ระบุหน้าที่หลัก ("ช่วยเรื่อง X") ไม่ใช่แค่บอกกว้างๆ ว่า "คุณคือผู้ช่วยที่แสนดี"
ระบุ SDK/Platform ที่ใช้ (ถ้ามี) ("built on Anthropic's Claude Agent SDK")

สิ่งที่ไม่ควรทำ (Anti-patterns):

"You are a helpful, harmless, and honest AI assistant" — กว้างเกินไป ไม่มีจุดยึดเหนี่ยวบทบาท
เขียนประวัติหรือปูมหลังมายาวเหยียดเป็นย่อหน้า — เปลือง Token เปล่าๆ โมเดลไม่ต้องการการปูบทตัวละครครับ

3.2 Security & Safety — กฎเหล็กที่ห้ามแหก

เป้าหมาย: กำหนดข้อจำกัดทางพฤติกรรมที่ห้ามละเมิดเด็ดขาด

IMPORTANT: Assist with defensive security tasks only.
Refuse to create, modify, or improve code that may be used maliciously.
IMPORTANT: You must NEVER generate or guess URLs for the user.

แนวทางปฏิบัติ:

ใช้คำนำหน้า IMPORTANT: — การเทรนลำดับความสำคัญของคำสั่งของ Claude จะให้น้ำหนักกับคำนี้เป็นพิเศษ
ใช้คำที่เด็ดขาด: NEVER, MUST NOT, Refuse to
ระบุทั้งสิ่งที่ "อนุญาต" และสิ่งที่ "ห้ามทำ" (ข้อจำกัดแบบสองทางจะชัดเจนกว่า)
วางไว้บนสุด อย่าเอาไปซ่อนไว้ตรงกลาง
ย้ำกฎความปลอดภัยที่สำคัญอีกครั้งในตอนท้าย — Claude Code ทำแบบนี้เป๊ะเลยครับ

ทำไมต้องย้ำ? Primacy effect (จำตอนต้น) + Recency effect (จำตอนท้าย) = การตอกย้ำสองชั้น การประกาศเรื่องความปลอดภัยของ Claude Code ปรากฏทั้งตอนเริ่มต้นและตอนท้ายของ Prompt ไม่ใช่เพราะ Engineer ขี้ลืมนะครับ — แต่เพราะพวกเขาเข้าใจเรื่อง U-shaped attention curve เป็นอย่างดี

3.3 Tone & Style — ควบคุมผลลัพธ์

เป้าหมาย: ควบคุมรูปแบบและน้ำเสียงของผลลัพธ์

## Tone and style

- Your responses should be short and concise.
- Only use emojis if the user explicitly requests it.
- Use Github-flavored markdown for formatting.
- NEVER create files unless absolutely necessary.

แนวทางปฏิบัติ:

ระบุพฤติกรรมที่เจาะจง ไม่ใช่แค่บอกกว้างๆ ว่า "จงเป็นมืออาชีพ"
ทุกกฎต้องสามารถทดสอบได้ว่าทำตามหรือไม่ (True/False) (เช่น "สั้นและกระชับ" ดีกว่า "พยายามอย่าเขียนยาว")
ระบุ Format ของผลลัพธ์ที่ต้องการ (Markdown? JSON? Plain text?)
ระบุสิ่งที่ "ห้ามทำ" ด้วย — ปัญหาเรื่องสไตล์หลายอย่างแก้ได้ด้วยการสั่งห้าม

ทีเด็ดของ Claude Code — ความเป็นกลางแบบมืออาชีพ (Professional Objectivity):

Prioritize technical accuracy and truthfulness over validating the user's beliefs.
Focus on facts and problem-solving, providing direct, objective technical info
without any unnecessary superlatives, praise, or emotional validation.

ย่อหน้านี้สำคัญมากครับ: มันช่วยบล็อกอาการ "Sycophancy" (การประจบเอาใจผู้ใช้) ของโมเดล ถ้า Agent ของคุณต้องให้การตัดสินใจที่เป็นกลาง (เช่น Code review, ประเมินไอเดีย, ตัดสินใจเรื่อง Architecture) คุณต้องมีประโยคทำนองนี้ใส่ไว้เลยครับ

3.4 Core Workflow — ส่วนที่สำคัญที่สุด

เป้าหมาย: สอนโมเดลว่า ควรทำงานอย่างไร — ให้ระเบียบวิธี (Methodology) ไม่ใช่ขั้นตอนที่แข็งทื่อ

นี่คือ ส่วนที่เขียนให้ดียากที่สุด และจะส่งผลลัพธ์มหาศาลถ้าคุณเขียนมันได้ถูกต้อง

หลักการสำคัญ: ให้ "หลักการ" ไม่ใช่ "ขั้นตอนตายตัว"

บอก LLM ว่าผลลัพธ์ที่ดีหน้าตาเป็นยังไงและทำไมมันถึงดี — แล้วปล่อยให้มันหาวิธีไปถึงจุดนั้นเอง หลีกเลี่ยงการบังคับจำนวนฟิลด์, ลำดับขั้นตอนเป๊ะๆ, หรือ Format ที่ตายตัว ยกเว้นว่าผลลัพธ์นั้นจะต้องถูกนำไปประมวลผลต่อด้วยระบบอื่น (Machine-consumed)

วิธีของ Claude Code:

## Doing tasks

The user will primarily request software engineering tasks.
For these tasks the following steps are recommended:

- Use the TodoWrite tool to plan the task if required

สังเกตคำว่า "recommended" (แนะนำ) นะครับ — ไม่ใช่ "คุณต้องทำตามขั้นตอนเหล่านี้เป๊ะๆ" การเลือกใช้คำแค่นี้เปิดโอกาสให้โมเดลสามารถปรับตัวตามสถานการณ์ได้

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

1. Understand first — read existing code before modifying it
2. Plan first — break complex tasks into steps before executing
3. Minimal changes — only change what's necessary, don't "refactor while you're in there"
4. Verify — confirm your changes work (run tests, lint, etc.)

แต่ละกฎมีเหตุผล (Why) แฝงอยู่ — โมเดลสามารถเข้าใจเจตนาและนำไปประยุกต์ใช้กับสถานการณ์ใหม่ๆ ได้

สิ่งที่ไม่ควรทำ (Anti-patterns):

ขั้นตอนตายตัว 20 สเต็ป — โมเดลจะทำตามแบบหุ่นยนต์ และจะไปไม่เป็นเมื่อเจอ Input ที่ไม่คาดคิด
"ขั้นแรกทำ A, จากนั้นทำ B, แล้วค่อยทำ C" — แบบนั้นมันคือ Prompt Chain ครับ ไม่ใช่ Agent Prompt
ไปไกด์ในสิ่งที่ LLM เก่งอยู่แล้ว — เปลือง Token เปล่าๆ

ผมเรียนรู้เรื่องนี้ด้วยตัวเองตอนทำ VibeCom ครับ เวอร์ชั่นแรกๆ ผมเขียน Workflow การทำรีเสิร์ชไว้ 10 ขั้นตอน โมเดลก็ตั้งหน้าตั้งตาทำครบ 10 ขั้นตอนเป๊ะๆ ทั้งๆ ที่แค่ขั้นตอนที่ 3 ก็ตอบคำถามผู้ใช้ได้แล้ว พอผมเปลี่ยนมาใช้ "หลักการ" ("ทำรีเสิร์ชจนกว่าจะมีหลักฐานเพียงพอ แล้วค่อยสรุปผล") คุณภาพงานก็ดีขึ้น แถมค่า Token ก็ลดลงด้วย

ข้อยกเว้น: เมื่อผลลัพธ์ต้องถูกนำไปใช้ต่อโดยระบบอื่น (เช่น การคุยกันระหว่าง Agent, หรือ API Response) กรณีนี้คุณ ควร กำหนด Format ให้เป๊ะครับ หลักการมีไว้สำหรับพฤติกรรม; ส่วน Schema มีไว้สำหรับ Interface

3.5 Tool Usage Policy — จัดการกับความกำกวม

เป้าหมาย: เมื่อมีหลายเครื่องมือที่ทำหน้าที่คล้ายกัน ให้บอกโมเดลว่าควรเลือกใช้อันไหน

## Tool usage policy

- Use specialized tools instead of bash commands:
  - Read for reading files instead of cat/head/tail
  - Edit for editing instead of sed/awk
  - Grep for searching instead of grep/rg
- You can call multiple tools in a single response. If independent, call in parallel.
- Use the Task tool for file search to reduce context usage.

แนวทางปฏิบัติ:

ใช้คำว่า "instead of" (แทนที่จะใช้) เพื่อบอกลำดับความสำคัญ (ใช้ A แทน B)
อธิบาย เหตุผล ว่าทำไมถึงควรเลือกใช้อันนั้น ("ให้ประสบการณ์ผู้ใช้ที่ดีกว่า", "ช่วยลดการใช้ Context")
กำหนดกลยุทธ์การทำงานแบบขนาน (ถ้าไม่เกี่ยวข้องกัน → ให้รันขนาน, ถ้าเกี่ยวข้องกัน → ให้รันตามลำดับ)
ระบุข้อจำกัดด้านความปลอดภัยในการใช้เครื่องมือ (การตรวจสอบ Path, การเช็คสิทธิ์)

ความสัมพันธ์ที่สำคัญระหว่าง Tools และ Prompts:

ปกติแล้ว Tool Definitions จะถูกระบบแทรกเข้ามาและคุณแก้ไขโดยตรงไม่ได้ คำอธิบายเครื่องมือของ Claude Code กินพื้นที่ประมาณ 11,438 Tokens ซึ่งหมายความว่า:

อย่าเขียนข้อมูลซ้ำกับที่มีอยู่ใน Tool Definitions แล้ว
ใช้ System Prompt สำหรับการไกด์เชิง กลยุทธ์: เมื่อไหร่ ควรใช้เครื่องมือไหน, ทำไม ถึงควรเลือกใช้อันนี้มากกว่าอีกอัน, ลำดับความสำคัญคืออะไร
คุณภาพของ Tool Definition ส่งผลโดยตรงต่อประสิทธิภาพของ Agent — ถ้าคุณกำลังสร้าง Agent ของตัวเอง จงลงทุนเวลาไปกับการเขียนคำอธิบายเครื่องมือให้ดีเยี่ยมครับ

3.6 Domain Knowledge — โหลดเมื่อจำเป็น ไม่ใช่ยัดไปตั้งแต่แรก

เป้าหมาย: ให้ความรู้เฉพาะทางที่ข้อมูลตอนเทรนโมเดลอาจจะไม่มี

หลักการสำคัญ: ค่อยๆ เปิดเผยข้อมูล (Progressive disclosure) ไม่ใช่ยัดข้อมูลตู้มเดียว

❌ ก๊อปปี้ API Endpoints ทั้ง 200 ตัวใส่ลงใน System Prompt → Token ทะลุหลอด
✅ ให้เครื่องมือโมเดลไปค้นหาเอาเอง → "โหลดความรู้เมื่อคุณต้องการใช้มัน"

กลยุทธ์นี้ใช้เหมือนกันทั้งในระบบ Skills ของ Claude Code และ Progressive Disclosure Middleware ของ DeepAgents ทั้งคู่ใช้วิธีโหลดความรู้เมื่อจำเป็นผ่านการเรียกใช้ Tool แทนที่จะยัดทุกอย่างไว้ตั้งแต่แรก

วิธีการนำไปใช้:

ใส่ตัวชี้เป้าไว้ใน System Prompt: "ใช้เครื่องมือ get_api_docs เพื่อดึง Document มาอ่านเมื่อจำเป็น"
ใช้ CLAUDE.md / AGENTS.md สำหรับบริบทของโปรเจกต์ — โหลดตอนรันไทม์ ไม่ใช่ Hardcode ไว้
ใช้ Skills / SKILL.md สำหรับการค้นหาความสามารถ — โมเดลจะเห็นเมนูของ Skill ที่มี และดึงสเปคเต็มๆ มาอ่านเมื่อต้องการ

3.7 Environment Info — บริบทตอนรันไทม์

เป้าหมาย: ให้โมเดลรับรู้ถึงสภาพแวดล้อมที่มันกำลังทำงานอยู่

<env>
Working directory: /Users/fengliu/Desktop/tfm/vibecom
Is directory a git repo: true
Platform: darwin
Today's date: 2026-03-21
</env>
You are powered by the model named Claude Opus 4.6.

แนวทางปฏิบัติ:

สร้างขึ้นมาแบบไดนามิก ห้าม Hardcode เด็ดขาด
สิ่งที่ควรมี: Working directory, Platform, วันที่, ชื่อโมเดล, สถานะ Git
ใช้ Format ที่มีโครงสร้างชัดเจน (XML tags หรือ Code blocks) เพื่อให้ง่ายต่อการอ่าน
วันที่สำคัญมาก — โมเดลต้องรู้ว่า "ตอนนี้" คือตอนไหน เพื่อประเมินความสดใหม่ของข้อมูล

3.8 Reminders — การย้ำเตือนครั้งสุดท้าย

เป้าหมาย: ย้ำกฎที่สำคัญที่สุดอีกครั้งในตอนท้ายของ Prompt

Claude Code ย้ำกฎเรื่องความปลอดภัยและข้อบังคับในการใช้ TodoWrite ไว้ด้านล่างสุด:

IMPORTANT: Assist with defensive security tasks only. [ย้ำอีกครั้ง]
IMPORTANT: Always use the TodoWrite tool to plan and track tasks. [ย้ำอีกครั้ง]

แนวทางปฏิบัติ:

ย้ำแค่กฎที่สำคัญที่สุด 2-3 ข้อเท่านั้น — อย่าก๊อปปี้มาวางซ้ำทั้งหมด
ใช้ประโยชน์จาก Recency bias — โมเดลจะจำเนื้อหาล่าสุดได้แม่นยำกว่า
สิ่งที่ควรนำมาย้ำ: กฎความปลอดภัย, กฎที่โมเดลมักจะละเมิดบ่อยๆ, การย้ำเตือน Core Workflow

4. งบประมาณ Token และการจัดการ Context

ตารางอ้างอิงการจัดสรรงบประมาณ

ส่วน (Section)	จำนวน Token ที่แนะนำ	หมายเหตุ
Identity + Safety	200-500	สั้นกระชับ แต่ห้ามต่อรอง
Tone & Style	300-800	กฎต้องเจาะจง แต่อย่าพร่ำเพ้อ
Core Workflow	500-2,000	ส่วนที่สำคัญที่สุด คุ้มค่าที่จะลงทุน Token
Tool Usage Policy	300-1,000	ขึ้นอยู่กับจำนวนเครื่องมือที่มี
Domain Knowledge	0-1,000	แนะนำให้โหลดเมื่อจำเป็น (On-demand)
Environment Info	100-300	สร้างแบบไดนามิก
Reminders	100-300	ย้ำเฉพาะเรื่องที่จำเป็นจริงๆ
รวมส่วนของคุณ	1,500-6,000
Tool Definitions (ระบบ)	5,000-15,000	คุณควบคุมไม่ได้

กราฟการเสื่อมถอยของ Context (Context Degradation Curve)

จากการทดสอบในคอมมูนิตี้ (Reddit u/CodeMonke_) ได้ทำแผนผังการเสื่อมถอยของการทำตามคำสั่งในโลกจริงไว้ดังนี้:

< 80K tokens: การทำตาม Prompt ยังคงเสถียร
80K - 120K tokens: เริ่มทำตามคำสั่งได้แย่ลง
> 120K tokens: แย่ลงอย่างเห็นได้ชัด — โมเดลเริ่ม "ลืม" คำสั่งช่วงแรกๆ
> 180K tokens: เสื่อมถอยขั้นรุนแรง

Context window 200K ของคุณ ≠ Context ที่ใช้งานได้จริง 200K วางแผนให้ดีครับ

กลยุทธ์การรับมือ:

ทำ System Prompt ของคุณให้กระชับ (< 6,000 tokens สำหรับส่วนของคุณ)
ใช้การสรุป (Summarization) เพื่อบีบอัดประวัติการสนทนา (DeepAgents จะเริ่มสรุปเมื่อถึงประมาณ 80K ตัวอักษร)
วางกฎเหล็กไว้ทั้งหัวและท้ายของ Prompt (รับมือกับ U-shaped attention)
แทรก Tag <system-reminder> กลางบทสนทนา (เดี๋ยวเราจะคุยเรื่องนี้ในหัวข้อ 8)

5. หลักการเขียน

5.1 ให้หลักการ ไม่ใช่ขั้นตอนตายตัว

❌ "Step 1: Read the file. Step 2: Find the bug. Step 3: Fix it. Step 4: Run tests."
✅ "Always understand existing code before modifying it. Verify your changes work."

หลักการสามารถนำไปประยุกต์ใช้ได้ (Generalize) ส่วนขั้นตอนตายตัวทำได้แค่ทำตามแบบหุ่นยนต์ เมื่อโมเดลเจอสถานการณ์ที่คุณไม่ได้คาดคิดไว้ หลักการจะช่วยนำทางให้มันตัดสินใจได้ถูกต้อง แต่ขั้นตอนตายตัวทำไม่ได้ครับ

ข้อยกเว้น: เมื่อผลลัพธ์ต้องถูกนำไปใช้โดยระบบอื่น (การคุยกันระหว่าง Agent, API Formats) ให้กำหนด Schema ให้เป๊ะ

5.2 ใช้คำเด็ดขาดสำหรับกฎเหล็ก

ระดับความเข้มข้น	คำที่ใช้	ใช้สำหรับ
ข้อห้ามเด็ดขาด	`NEVER`, `MUST NOT`	ความปลอดภัย, การกระทำที่ย้อนกลับไม่ได้
ข้อบังคับที่เข้มงวด	`ALWAYS`, `MUST`	กฎหลักของ Workflow
ข้อแนะนำ	`recommended`, `prefer`	Best practices ที่อาจมีข้อยกเว้น
ข้อเสนอแนะ	`consider`, `you may`	การปรับแต่งที่ทำหรือไม่ทำก็ได้

ตัวอย่างจาก Claude Code:

NEVER update the git config — ข้อห้ามเด็ดขาด
ALWAYS prefer editing an existing file — เข้มงวด แต่มีข้อยกเว้นได้
The following steps are recommended — แนะนำ Workflow

5.3 ยกตัวอย่างดีกว่าอธิบายยืดยาว

## Code References

When referencing specific functions or pieces of code include
the pattern `file_path:line_number`.

<example>
user: Where are errors from the client handled?
assistant: Clients are marked as failed in the `connectToServer`
function in src/services/process.ts:712.
</example>

ตัวอย่าง 1 อัน สอนได้ดีกว่าคำอธิบาย 100 คำ:

โมเดลเรียนรู้ Pattern จากตัวอย่างได้แม่นยำกว่าคำอธิบายแบบนามธรรม
ครอบด้วย Tag <example> เพื่อแยกออกจากกฎ
ให้ทั้งตัวอย่างที่ดี ("ทำแบบนี้") และตัวอย่างที่ไม่ดี ("อย่าทำแบบนี้")
ใช้ตัวอย่างที่เฉพาะเจาะจงและสมจริง — ไม่เอาพวก "foo/bar"

5.4 ข้อจำกัดแบบสองทาง (Bidirectional Constraints)

✅ "Use dedicated tools: Read for reading files, Edit for editing files."
✅ "Do NOT use bash for file operations (cat, head, tail, sed, awk)."

บอกแค่ "ให้ทำสิ่งนี้" → โมเดลจะไม่รู้ว่าเมื่อไหร่ที่ "ไม่ควรทำ" บอกแค่ "ห้ามทำสิ่งนี้" → โมเดลจะไม่รู้ว่าควรใช้อะไรแทน บอกแบบสองทาง → ชัดเจนและไม่มีความกำกวม

5.5 อธิบายว่า "ทำไม" ไม่ใช่แค่บอกว่า "ทำอะไร"

❌ "Don't use git commit --amend."
✅ "Avoid git commit --amend. ONLY use --amend when either
   (1) user explicitly requested amend OR
   (2) adding edits from pre-commit hook.
   Reason: amending may overwrite others' commits."

การอธิบายเหตุผล (Why) ช่วยให้โมเดลตัดสินใจได้ถูกต้องในกรณี Edge cases โปรโตคอลความปลอดภัยเรื่อง Git ของ Claude Code นี่คือระดับ Masterclass เลยครับ — ทุกกฎจะบอกเหตุผลแฝงไว้เสมอ

5.6 โครงสร้างสำคัญกว่าความสละสลวย

Markdown headers (##, ###) — โมเดลเข้าใจลำดับชั้น (Hierarchy)
Bullet lists ดีกว่าย่อหน้ายาวๆ — แต่ละกฎสามารถทดสอบแยกกันได้
XML tags สำหรับเนื้อหาพิเศษ: <example>, <env>, <system-reminder>
Tables สำหรับการเปรียบเทียบและการจับคู่ข้อมูล
อย่าพิมพ์ข้อความยาวๆ แบบไม่มีโครงสร้าง — จากการทดสอบ Prompt ที่มีโครงสร้างชัดเจนจะทำผลงานได้ดีกว่าข้อความแบบร่ายยาวเสมอ

6. Anti-Patterns ที่ผลาญ Token ของคุณทิ้งเปล่าๆ

Prompt Chain ที่ปลอมตัวมาเป็น Agent

"First call tool A to get data.
Then call tool B with the result.
Then format the output as JSON.
Then save to file."

นี่ไม่ใช่ Agent Prompt ครับ — มันคือสคริปต์ Pipeline โมเดลจะทำตามแบบหุ่นยนต์และสูญเสียความสามารถในการวางแผนด้วยตัวเองไปเลย

วิธีแก้: บอกเป้าหมายและข้อจำกัดให้โมเดลรู้ แล้วปล่อยให้มันตัดสินใจเลือกขั้นตอนเอง

การเขียน Prompt แบบเยินยอ (Flattery Engineering)

"You are an EXTREMELY TALENTED and INCREDIBLY EXPERIENCED
senior software engineer with 20 years of experience..."

คำชมและคำขยายความเวอร์ๆ ไม่ได้ช่วยให้ผลลัพธ์ดีขึ้นเลยครับ โมเดลไม่มีอีโก้ให้คุณไปป้อยอหรอก เก็บ 15 Tokens นั้นไว้เขียนกฎที่มีประโยชน์จริงๆ ดีกว่า

การยัดข้อมูลตู้มเดียว (Knowledge Dumps)

"Here is the complete API documentation for our 200 endpoints..."

การทำแบบนี้จะสูบ Context window ของคุณจนเกลี้ยง และเร่งให้เกิดอาการ "Context เน่า" เร็วขึ้น เปลี่ยนมาใช้วิธีโหลดเมื่อจำเป็นดีกว่า:

"Use the get_api_docs tool to retrieve API documentation when needed."

เขียนคำอธิบายเครื่องมือซ้ำซ้อน

ถ้าใน Tool Definition เขียนไว้แล้วว่า "Read tool reads a file from the filesystem" คุณก็ไม่ต้องไปเขียนซ้ำใน System Prompt อีก ให้เพิ่มเฉพาะคำแนะนำเชิง กลยุทธ์ ที่ไม่มีใน Tool Definition — เช่น ควรใช้เมื่อไหร่, ทำไมถึงควรใช้, ลำดับความสำคัญคืออะไร

ลืมจัดการกรณีทำงานพลาด (Missing Failure Handling)

ถ้าไม่มีการไกด์ที่ชัดเจน โมเดลจะพยายามเรียกใช้ Tool ที่พังซ้ำๆ จนเกิด Infinite loop ให้ใส่ประโยคนี้ไว้เสมอ:

"If a tool call is denied, do not re-attempt the exact same call.
Think about why it was denied and adjust your approach."

เมินเฉยต่อการเสื่อมถอยของ Context Window

Context window 200K ≠ Context ที่ใช้งานได้จริง 200K การทดสอบในโลกจริงแสดงให้เห็นว่ามันเริ่มเสื่อมถอยตั้งแต่ 80K คุณต้องมีกลยุทธ์การสรุป (Summarization) เตรียมไว้ด้วย

7. จุดแทรก Prompt และลำดับความสำคัญ

3 วิธีในการปรับแต่งของ Claude Code

วิธีการ	แทนที่ส่วนไหน	ตำแหน่งที่วาง	เหมาะสำหรับ
Output Styles	ส่วน "Tone and style" + "Doing tasks"	ก่อน Tool definitions	เปลี่ยนสไตล์การโต้ตอบ
--append-system-prompt	ไม่แทนที่ (เพิ่มเข้าไป)	หลัง Output style, ก่อน Tool definitions	เพิ่มพฤติกรรมเฉพาะเจาะจง
--system-prompt	System prompt ทั้งหมด	เก็บ Tool definitions + Identity ไว้ 1 บรรทัด	ปรับแต่งแบบจัดเต็ม (ท่าไม้ตาย)

ถ้าคุณใช้หลายวิธีพร้อมกัน: Output Style → Append Prompt → Tool Definitions

ลำดับชั้นของคำสั่ง (Instruction Hierarchy)

Claude ถูกเทรนมาให้เข้าใจลำดับชั้นของคำสั่งโดยเฉพาะ:

1. คำสั่งตรงๆ จากผู้ใช้ (CLAUDE.md, พิมพ์สั่งโดยตรง)  ← ความสำคัญสูงสุด
2. สิ่งที่เพิ่มเข้ามาใน Custom system prompt        ← สูง
3. Default system prompt                      ← ปานกลาง
4. Tool definitions                           ← ระดับอ้างอิง

นั่นหมายความว่า:

กฎใน CLAUDE.md จะ Overrides พฤติกรรมของ Default system prompt
คำสั่งตรงๆ จากผู้ใช้จะ Overrides ทุกสิ่งทุกอย่าง
Custom prompt ของคุณจะ Overrides Default prompt

กลไกการแทรกแบบไดนามิก

<system-reminder> — แทรกเข้าไปในข้อความไหนก็ได้กลางบทสนทนา เพื่อเตือนโมเดลถึงกฎเหล็ก
CLAUDE.md / AGENTS.md — โหลดตอนรันไทม์จากไฟล์ แล้วนำไปต่อท้าย System prompt
Skills / SKILL.md — โหลดเมื่อจำเป็นผ่าน Tool calls, ไม่กินพื้นที่ System prompt เลย

8. การแทรก Prompt กลางบทสนทนา — อาวุธลับที่หลายคนไม่รู้

System Prompt จะปรากฏขึ้นแค่ครั้งเดียว ที่จุดเริ่มต้นของ Messages array แต่ LLM รับข้อมูลเป็น Messages array ทั้งก้อน (สลับกันระหว่าง User / Assistant / Tool messages) และ คุณสามารถแทรก Prompt เข้าไปใน User messages และ Tool results ได้ด้วย Claude Code ใช้เทคนิคนี้อย่างหนักหน่วงใน Production เลยครับ

ทำไมถึงจำเป็น?

เพื่อสู้กับอาการ "Context เน่า" เมื่อบทสนทนายาวขึ้น การทำตามคำสั่งใน System prompt ของโมเดลจะเริ่มแย่ลง (เห็นได้ชัดที่ 80K+ tokens) การแทรกคำเตือนกลางบทสนทนา = การรีเฟรชกฎ โดยใช้ประโยชน์จาก Recency bias

วิธีคิด (Mental model):

System prompt = รัฐธรรมนูญ (ตั้งขึ้นครั้งเดียว มีอำนาจระยะยาว)
User message reminders = บันทึกข้อความ (Memos) (ส่งเป็นระยะ เพื่อรักษาการบังคับใช้กฎ)

3 จุดแทรกใน Messages Array

Messages Array:
┌─────────────────────────────────────┐
│ System Prompt                       │ ← ปรากฏครั้งเดียว, Primacy effect
│   (identity, safety, workflow...)   │
├─────────────────────────────────────┤
│ User Message 1                      │
│ Assistant Message 1                 │
│ User Message 2 + <system-reminder>  │ ← แทรกกลางบทสนทนา
│ Assistant Message 2                 │
│ Tool Result + <system-reminder>     │ ← แทรกใน Tool results ได้ด้วย
│ ...                                 │
│ User Message N + <system-reminder>  │ ← ข้อความล่าสุด, Recency effect แรงสุด
└─────────────────────────────────────┘

ตำแหน่ง	ข้อดี	ข้อเสีย
System prompt	Primacy effect, อ่านเป็นอันดับแรก	ปรากฏครั้งเดียว, อาจถูก "ลืม" ในบทสนทนายาวๆ
User message injection	Recency bias, รีเฟรชกฎเป็นระยะ	การแทรกแต่ละครั้งเสียค่า Token
Tool result injection	เป็นจุดแทรกที่เป็นธรรมชาติที่สุด	ทำได้ก็ต่อเมื่อมีการเรียกใช้ Tool เท่านั้น

Claude Code ใช้งานมันยังไงในของจริง

สิ่งที่ต้องทำก่อน — ประกาศ Tag ไว้ใน System prompt:

Tool results and user messages may include <system-reminder> tags.
<system-reminder> tags contain useful information and reminders.
They are automatically added by the system, and bear no direct
relation to the specific tool results or user messages in which they appear.

ขั้นตอนนี้สำคัญมากครับ: มันบอกโมเดลว่า Tag เหล่านี้ระบบเป็นคนแทรกเข้ามา ไม่ใช่คำพูดของผู้ใช้

การใช้งานแบบที่ 1: ย้ำเตือนพฤติกรรม (รีเฟรชกฎเป็นระยะ)

<system-reminder>
The task tools haven't been used recently. If you're working on tasks
that would benefit from tracking progress, consider using TaskCreate...
</system-reminder>

Claude Code ใช้สิ่งนี้เพื่อเตือนให้โมเดลวางแผนด้วย TodoWrite — เพราะโมเดลมักจะ "ลืม" วางแผนแล้วพุ่งไปเขียนโค้ดเลย

การใช้งานแบบที่ 2: สลับโหมด (Plan Mode)

<system-reminder>
Plan mode is active. The user indicated that they do not want you to
execute yet -- you MUST NOT make any edits, run any non-readonly tools,
or otherwise make any changes to the system.
</system-reminder>

Plan mode ไม่ได้ถูกฝังไว้ใน System prompt ครับ แต่มันคือ Tag ที่แทรกเข้าไปใน User message ถัดไป วิธีนี้ช่วยให้คุณสลับโหมดไปมาแบบไดนามิกได้โดยไม่ต้องไปแก้ System prompt ฉลาดมากครับ

การใช้งานแบบที่ 3: แจ้งเตือนเมื่อไฟล์มีการเปลี่ยนแปลง

<system-reminder>
Note: /path/to/file.ts was modified, either by the user or by a linter.
This change was intentional, so make sure to take it into account.
</system-reminder>

เมื่อมีโปรเซสภายนอก (Linter, Formatter, หรือคนแก้ไฟล์เอง) มาแก้ไขไฟล์ ระบบจะแจ้งเตือนโมเดลผ่าน Reminder — เพื่อป้องกันไม่ให้โมเดลตัดสินใจจากข้อมูลไฟล์ที่เก่าไปแล้ว (Stale)

การใช้งานแบบที่ 4: บริบทแบบไดนามิก (วันที่, กฎของโปรเจกต์)

<system-reminder>
Today's date is 2026-03-21.
Current branch: dev
claudeMd: [เนื้อหา CLAUDE.md แทรกตรงนี้]
</system-reminder>

บริบทตอนรันไทม์ (วันที่, สถานะ Git, กฎของโปรเจกต์) จะถูกแทรกผ่าน User messages ไม่ใช่ไป Hardcode ไว้ใน System prompt

แนวทางการเขียน Reminders

ครอบด้วย XML tags (<system-reminder>) — โมเดลจะได้แยกออกว่านี่คือระบบแทรกมา ไม่ใช่ผู้ใช้พิมพ์
ประกาศ Tag ไว้ใน System prompt ก่อน — ไม่งั้นโมเดลอาจจะพยายามตอบกลับ Reminder นั้น
อย่าแทรกทุกข้อความ — การแทรกแต่ละครั้งเสียค่า Token แทรกเฉพาะตอนที่จำเป็นก็พอ
เขียนให้สั้น — Reminder ไม่ใช่ System prompt อันที่สอง เอาแค่กฎเหล็ก 1-2 ข้อพอ
อย่าเขียนขัดแย้งกับ System prompt — Reminder มีไว้เสริมและย้ำเตือน ไม่ได้มีไว้ Overrides
ใช้สำหรับการสลับโหมดแบบไดนามิก — Plan mode, Readonly mode, Feature flags

เมื่อไหร่ควรใช้ System Prompt vs. User Message Reminder

สถานการณ์	System Prompt	User Message Reminder
กำหนดบทบาท (Role)	✅	❌
ข้อจำกัดด้านความปลอดภัย	✅ ประกาศครั้งแรก	✅ ย้ำเป็นระยะ
ระเบียบวิธีทำงาน (Workflow)	✅	❌
สลับโหมด (เช่น Plan mode)	❌	✅
แจ้งเตือนไฟล์เปลี่ยน	❌	✅
วันที่ / ข้อมูลสภาพแวดล้อม	✅ ค่าเริ่มต้น	✅ ค่าที่อัปเดตแล้ว
ดัดนิสัย (Behavioral correction)	❌	✅
ย้ำการใช้เครื่องมือ	✅ กำหนดกฎ	✅ สะกิดให้ทำ

9. Prompt Cache — ประหยัดค่า Token ซ้ำซ้อนไปได้ถึง 90%

ระบบ Prompt Caching ของ Anthropic ช่วยให้คุณแคช ส่วนหัวที่คงที่ (Static prefix) ของ Messages array ได้ เมื่อมี Request ถัดไปที่ใช้ Prefix เดิม มันก็จะไปดึงจาก Cache — ช่วยประหยัดเงินและลด Latency ได้มหาศาล

สำหรับ Agents เรื่องนี้สำคัญมากครับ: เพราะคุณต้องส่ง System prompt + Tool definitions ไปใหม่ทุกครั้งที่มีการเรียก LLM ภายในบทสนทนาเดียวกัน

ตัวเลขที่ควรรู้

เมตริก	ค่า
ค่าใช้จ่ายเมื่อ Hit Cache	10% ของราคาปกติ (ประหยัด 90%)
ค่าใช้จ่ายตอนเขียน Cache	125% ของราคาปกติ (จ่ายเพิ่ม 25% ในครั้งแรก)
Cache TTL (อายุแคช)	5 นาที (หมดอายุถ้าไม่มี Request เข้ามา)
ความยาวขั้นต่ำที่แคชได้	1,024 tokens (Claude 3.5+)
ความละเอียดของ Cache	Prefix matching — จากจุดเริ่มต้นไปจนถึง Breakpoint ที่มาร์คไว้
จำนวน Breakpoints สูงสุด	4 จุด

เรื่องนี้เปลี่ยนวิธีออกแบบ Prompt ยังไง?

หลักการสำคัญ: เอาของที่คงที่ (Static) ไว้ก่อน เอาของที่เปลี่ยนบ่อย (Dynamic) ไว้ทีหลัง

✅ โครงสร้างที่เป็นมิตรกับ Cache:
  System prompt (คงที่)        ← Cache breakpoint 1
  Tool definitions (คงที่)     ← Cache breakpoint 2
  CLAUDE.md / กฎโปรเจกต์       ← Cache breakpoint 3 (เปลี่ยนบ้างนานๆ ที)
  Conversation history         ← Breakpoint 4 สำหรับ Rolling window

❌ โครงสร้างที่ทำลาย Cache:
  System prompt
  DYNAMIC TIMESTAMP            ← เปลี่ยนทุก Request, ทุกอย่างหลังจากนี้ = Cache miss
  Tool definitions
  Conversation history

กับดักที่ไม่มีใครเคยเตือนคุณ: ถ้าคุณเอา Timestamp แบบไดนามิกไปวางไว้ตรงกลาง System prompt ทุกสิ่งทุกอย่างที่อยู่หลังจากนั้นจะกลายเป็น Cache miss ทันที ทุกๆ. Request. เลยครับ แค่วาง Timestamp ผิดที่ คุณก็ต้องจ่ายราคาเต็มสำหรับ Token นับพันๆ ตัวแล้ว

การใช้งาน API

const response = await anthropic.messages.create({
  model: "claude-sonnet-4-6",
  system: [
    {
      type: "text",
      text: "You are a startup advisor...",
      cache_control: { type: "ephemeral" }  // ← มาร์คจุด Cache breakpoint
    }
  ],
  messages: [...]
});

กลยุทธ์ Multi-Breakpoint

Breakpoint 1: System prompt           ← แทบไม่เคยเปลี่ยน
Breakpoint 2: Tool definitions         ← แทบไม่เคยเปลี่ยน
Breakpoint 3: Project rules / CLAUDE.md ← เปลี่ยนบ้างนานๆ ที
Breakpoint 4: First N history messages  ← Rolling window cache

ถึงแม้ประวัติการสนทนาจะเปลี่ยนไป แต่ 3 Breakpoints แรกก็ยัง Hit Cache อยู่ดี บทสนทนาที่มีการโต้ตอบ 10 ครั้ง สามารถประหยัดค่า Input Token ไปได้ถึง 40-60% เลยครับ

คำแนะนำในการออกแบบ

อย่าใส่ค่าไดนามิกที่เปลี่ยนบ่อยๆ ไว้ใน System prompt — ใส่วันที่น่ะได้ (เพราะเปลี่ยนแค่วันละครั้ง) แต่ Timestamp แบบเป๊ะๆ ห้ามใส่เด็ดขาด
เอาบริบทไดนามิก (สถานะ Git ฯลฯ) ไปใส่ใน User message injections — อย่าใส่ใน System prompt ไม่งั้น Cache พังหมด
ทำ Tool definitions ให้คงที่ — อย่าเพิ่ม/ลด Tool แบบไดนามิกตอนรันไทม์
ใช้ Rolling window สำหรับประวัติการสนทนา — แคชข้อความ N ข้อความแรก จะมีแค่ข้อความล่าสุดเท่านั้นที่เป็น Cache miss

10. เช็คลิสต์ตรวจสอบ

หลังจากเขียน System Prompt เสร็จแล้ว ลองเอามาเช็คกับลิสต์นี้ดูครับ:

โครงสร้าง (Structure)

Identity อยู่บนสุดหรือเปล่า?
กฎความปลอดภัยมีคำว่า IMPORTANT นำหน้า และมีการย้ำอีกครั้งตอนท้ายมั้ย?
แบ่ง Section ชัดเจนด้วย Headers หรือเปล่า?
ตัวอย่างถูกครอบด้วย Tag <example> มั้ย?

งบประมาณ Token (Token Budget)

ส่วนที่คุณเขียนเองยาวไม่เกิน 6,000 Tokens ใช่มั้ย?
ไม่ได้เขียนข้อมูลซ้ำกับที่มีใน Tool definitions ใช่มั้ย?
ความรู้เฉพาะทางถูกตั้งให้โหลดเมื่อจำเป็น (On-demand) ไม่ใช่ยัดไปตั้งแต่แรกใช่มั้ย?
ไม่มีประวัติหรือปูมหลังตัวละครที่เยิ่นเย้อใช่มั้ย?

คุณภาพของกฎ (Rule Quality)

ทุกกฎสามารถทดสอบได้ว่าทำตามหรือไม่ (True/False)?
กฎเหล็กใช้คำที่เด็ดขาด (NEVER/MUST)?
ข้อเสนอแนะใช้คำแนะนำ (recommended/prefer)?
กฎที่สำคัญมีการอธิบาย เหตุผล (Why) ไม่ใช่แค่บอกว่า ทำอะไร (What)?
มีข้อจำกัดแบบสองทาง (บอกทั้งให้ทำสิ่งนี้ + ห้ามทำสิ่งนั้น)?

พฤติกรรมของ Agent (Agent Behavior)

ให้หลักการทำงาน ไม่ใช่ขั้นตอนตายตัวแบบ Step-by-step?
มีการจัดการกรณี "เรียกใช้ Tool ไม่ผ่าน" แล้วใช่มั้ย?
มีกลยุทธ์รับมือเมื่อ "เจออุปสรรค" (ไม่พยายามทำซ้ำแบบดันทุรัง)?
มีกลยุทธ์จัดการ Context (เช่น กำหนดจุดที่จะเริ่มสรุปข้อความ)?

สิ่งที่ห้ามทำ (What NOT to Do)

ไม่มีการเขียนเยินยอหรือใช้คำขยายความเวอร์ๆ?
ไม่มีการประกาศซ้ำซ้อนว่า "คุณคือ AI ผู้ช่วยที่แสนดี"?
ไม่ได้เขียนออกมาในรูปแบบ Prompt chain?
ไม่มีการ Over-engineering (ใส่ฟีเจอร์ที่ไม่มีใครขอ)?

ถ้าผมต้องเริ่มใหม่ตั้งแต่วันนี้

นี่คือสิ่งที่ผมจะทำเป๊ะๆ เลยครับ:

เริ่มด้วย Identity + Safety ใน 3 บรรทัดแรก สองประโยคบอกว่า Agent คือใคร กฎเหล็กใช้ NEVER/MUST แล้วย้ำกฎความปลอดภัยอีกครั้งตอนท้าย
เขียน Core workflow เป็นหลักการ ไม่ใช่ขั้นตอน ไม่เกิน 4-5 Bullet points ใช้ "recommended" และ "prefer" สำหรับกฎที่ยืดหยุ่นได้ และใช้ "NEVER" กับ "MUST" สำหรับกฎเหล็ก
ตั้งงบไว้ 1,500-6,000 Tokens สำหรับส่วนของคุณ Tool definitions จะบวกเพิ่มไปอีก 5,000-15,000 Tokens ถ้าคุณเขียนเกิน 6K แสดงว่าคุณน่าจะกำลังยัดข้อมูลที่ควรจะให้โหลดแบบ On-demand เข้าไปแล้วล่ะ
จัดโครงสร้างทุกอย่าง ใช้ Markdown headers, Bullet lists, XML tags สำหรับตัวอย่าง Prompt ที่มีโครงสร้างชัดเจนทำผลงานได้ดีกว่าข้อความร่ายยาวเสมอ
สร้างระบบแทรก Reminder กลางบทสนทนาตั้งแต่วันแรก ประกาศ <system-reminder> ไว้ใน System prompt แล้วแทรก Reminder สำหรับกฎเหล็ก, การสลับโหมด, และการอัปเดตบริบท
ออกแบบเผื่อ Cache ของคงที่ไว้ก่อน ของไดนามิกไว้ทีหลัง ห้ามเอาค่าที่เปลี่ยนบ่อยๆ ไปใส่ในตัว System prompt เด็ดขาด

ตลกร้ายของการทำทั้งหมดนี้คืออะไรมั้ยครับ? System Prompt ที่ดีที่สุด มักจะสั้นครับ Custom instructions ของ Claude Code (ถ้าไม่นับ Tool definitions) นั้นกระชับอย่างน่าประหลาดใจ ทุกบรรทัดมีคุณค่าในตัวมันเอง

เมื่อก่อนผมเคยคิดว่า Prompt Engineering คือการหาทริคเจ๋งๆ มาใช้ แต่ตอนนี้ผมคิดว่ามันคือเรื่องของวินัย (Discipline) — พูดให้น้อยลง, พูดให้ตรงประเด็น, และเชื่อใจให้โมเดลจัดการส่วนที่เหลือ โมเดลมันฉลาดกว่า Prompt ของคุณครับ จงออกแบบสภาพแวดล้อม ไม่ใช่ไปตีกรอบพฤติกรรม

แหล่งอ้างอิง (References)

แหล่งที่มา	ข้อมูลสำคัญที่ได้
Claude Code v2.0.14 System Prompt	โครงสร้าง Agent prompt ระดับ Production ฉบับเต็ม
Reddit: Understanding Claude Code's 3 System Prompt Methods	เจาะลึก Output Styles / --append / --system-prompt, ข้อมูลเรื่อง Context เน่าในโลกจริง
shareAI-lab/learn-claude-code	ปรัชญา "โมเดลคือ Agent", ระเบียบวิธีการออกแบบ Harness
Anthropic Prompt Engineering Docs	Best practices อย่างเป็นทางการสำหรับการเขียน Prompt
DeepAgents Framework	Middleware สำหรับการสรุปข้อความ, การค่อยๆ เปิดเผย Skills (Progressive disclosure)