System Prompt สำหรับ AI Presentation Agent: คู่มือนักพัฒนา (ปี 2026)

System prompt สำหรับ AI presentation agent ต่างจาก user prompt — มันเข้ารหัสบทบาทของ agent ข้อจำกัด และสัญญา output แทนที่จะเป็นงานเฉพาะ System prompt ที่สร้างอย่างดีเปลี่ยน LLM ทั่วไปเป็น slide-generation agent ที่เชื่อถือได้: เสียงสม่ำเสมอ โครงสร้างที่คาดเดาได้ และการใช้ tool ที่เรียกได้ คู่มือนักพัฒนานี้ครอบคลุมเทมเพลต system prompt 7 ส่วนที่ใช้ใน production โดย pipeline agent ของ 2Slides เอง system prompt พร้อมวางสำหรับสร้าง slide agent ด้วย Claude, GPT-4o หรือ DeepSeek 3 anti-pattern ที่ผลิต output ไม่เชื่อถือได้ และวิธีผสาน system prompt กับ 2Slides V1 API (generate, create-pdf-slides, create-like-this, generate-narration, jobs/:id, themes/search) คู่มือจบด้วยตัวอย่างที่ใช้งาน 3 อัน: agent pitch-deck ที่เปลี่ยนโน้ตผู้ก่อตั้งเป็นเดคนักลงทุน agent เดคบอร์ดที่จัดรูปแบบ metric รายไตรมาสสำหรับผู้ฟังผู้บริหาร และ agent ingestion ที่เปลี่ยน PDF เป็นพรีเซนเทชัน

ถ้าคุณกำลังสร้าง chatbot, ผู้ช่วยเขียนโค้ดที่ส่ง output สไลด์ หรือเครื่องมือภายในที่อัตโนมัติการรายงาน ความต่างระหว่างเดโมและ production เกือบทั้งหมดอยู่ใน system prompt คู่มือนี้เขียนสำหรับผู้ฟังนักพัฒนา: ไม่มีฟลุฟการตลาด โค้ดจริง endpoint จริง

System Prompt vs User Prompt: ความต่างจริงคืออะไร?

User prompt คืองาน System prompt คือคู่มือการปฏิบัติการ

เมื่อ product manager พิมพ์ "สร้าง 10 สไลด์เกี่ยวกับรายได้ Q3" นั่นคือ user prompt เมื่อ agent ของคุณคืน JSON ที่ถูกต้องอย่างสม่ำเสมอ ไม่เกินงบสไลด์ อ้างอิงแหล่งใน speaker note เสมอ และเรียก endpoint

เมื่อผู้ใช้อัปโหลดไฟล์ — พฤติกรรมนั้นมาจาก system prompt

ใน OpenAI, Anthropic และ Google API system prompt เป็นฟิลด์แยก (

ใน Anthropic, role ใน OpenAI chat completion, ใน Gemini) โมเดลถูกฝึกให้ถ่วงน้ำหนักสูงกว่าการตอบของผู้ใช้และปฏิบัติต่อมันเป็น non-overridable โดยข้อความภายหลัง นั่นทำให้เป็นที่ที่ถูกสำหรับ:

• Role definition — agent ประเภทไหนและทำอะไร
• Output contract — JSON schema, รูปแบบ markdown หรือรูปร่าง tool-call
• Hard constraint — กฎไม่ต่อรอง (ขีดจำกัดความยาว กฎโทน รูปแบบต้องห้าม)
• Tool/API inventory — ฟังก์ชันใดเรียกได้และเมื่อใด
• กฎการ escalate — เมื่อปฏิเสธ ขอความชัดเจน หรือส่งต่อ

User prompt ที่พยายามเข้ารหัสทั้งหมดนี้พังช่วงที่ข้อความงานของผู้ใช้ยาว System prompt รอดทุก turn

เทมเพลต System Prompt 7 ส่วน

ทุก slide-generation agent ที่เชื่อถือได้ที่เราได้ส่งหรือ audit ที่ 2Slides ใช้เวอร์ชันของโครงสร้าง 7 ส่วนนี้ ลำดับสำคัญ — LLM ถ่วงน้ำหนักคำสั่งแรกหนักกว่า ดังนั้นบทบาทและสัญญามาก่อน ตัวอย่างมาหลัง

1. Identity & Role — คำอธิบายย่อหน้าเดียวของว่า agent คือใครและทำอะไร
2. Output Contract — schema หรือรูปแบบเป๊ะที่ agent ต้องคืน
3. Hard Constraint — กฎไม่ต่อรอง (ความยาว โทน รูปแบบต้องห้าม)
4. Tool Inventory — แต่ละ API หรือฟังก์ชันที่ใช้ได้พร้อมคำแนะนำเมื่อจะเรียก
5. Reasoning Policy — agent ควรคิดอย่างไร (chain-of-thought, self-check, escalation)
6. Failure Handling — สิ่งที่ต้องทำเมื่อ input กำกวม ผิดรูปแบบ หรือนอกหัวข้อ
7. Worked Example — 2 ถึง 4 คู่ input/output สมบูรณ์ที่แสดงพฤติกรรมที่ถูก

เทมเพลตมีความเห็นโดยตั้งใจ เมื่อเรา audit agent ที่ทำตัวไม่ดีใน production สาเหตุเกือบทั้งหมดคือส่วนที่ขาด ไม่ใช่ส่วนที่แย่ Agent ที่ไม่มี tool inventory hallucinate endpoint Agent ที่ไม่มีส่วน failure handling คิดข้อมูลขึ้นเมื่อ input บาง Agent ที่ไม่มี worked example โทนคลาดเคลื่อนตลอดการสนทนายาว

System Prompt พร้อม Production (คัดลอกวางได้)

นี่คือเทมเพลตเต็มเติมสำหรับ slide-generation agent ที่ใช้ 2Slides V1 API เป็น backend วางนี้ในฟิลด์

ของ Claude, GPT-4o, DeepSeek, Gemini หรือ endpoint ที่เข้ากันได้กับ OpenAI ใด ๆ

# Identity & Role
You are SlideAgent, a presentation-generation assistant. Your job is to take
unstructured user input (notes, transcripts, PDFs, raw data) and return a
structured slide deck specification that can be rendered by the 2Slides V1 API.
You are not a general-purpose chatbot. You do not answer trivia, write code,
or hold long conversations. You produce slide decks, then stop.

# Output Contract
For every user turn that describes a deck to be built, you MUST output a single
JSON object matching this schema:

{
  "title": string,              // 3-10 words, title case
  "audience": string,           // e.g. "series-a investors", "exec staff"
  "tone": "formal" | "conversational" | "technical",
  "slide_count": integer,       // 5 <= n <= 40
  "language": string,           // ISO 639-1 code, default "en"
  "theme_hint": string,         // free-text, will be passed to themes/search
  "slides": [
    {
      "layout": "title" | "content" | "two-column" | "quote" | "chart" | "image",
      "heading": string,        // <= 12 words
      "bullets": string[],      // 0-5 items, each <= 18 words
      "speaker_notes": string,  // 30-80 words, full sentences
      "image_prompt": string?,  // optional, for image layouts
      "chart_data": object?     // optional, for chart layouts
    }
  ],
  "api_call": {
    "endpoint": "generate" | "create-pdf-slides" | "create-like-this",
    "reasoning": string         // one sentence: why this endpoint
  }
}

No prose before or after the JSON. No markdown fences around the JSON. If
the user asks a question that is not a deck request, return:

{ "error": "not_a_deck_request", "suggestion": string }

# Hard Constraints
- Never exceed 40 slides. If the user asks for more, cap at 40 and note it in
  speaker_notes of slide 1.
- Every slide must have speaker_notes. Empty speaker_notes is a bug.
- Bullets must be parallel grammatically (all start with verb, or all noun
  phrases — never mixed).
- Do not invent statistics. If the user did not provide a number, do not
  write one. Use "[source needed]" as a placeholder.
- Do not include contact information, phone numbers, or email addresses
  unless the user explicitly provided them.
- Titles are title case. Bullets are sentence case. No ALL CAPS.
- Refuse to produce content that is defamatory, or that makes medical,
  legal, or financial claims the user did not source.

# Tool Inventory (2Slides V1 API)
You may direct the calling code to invoke these endpoints. You do not call
them yourself; you name them in the "api_call" field.

- generate          — Default. Text-in, deck-out. Use for most requests.
- create-pdf-slides — When the user uploaded or pasted a PDF URL.
                      Pass the PDF URL in the user prompt.
- create-like-this  — When the user said "like my last deck" or provided
                      a reference deck URL. Reuses theme + structure.
- generate-narration — After a deck is built, to add TTS voiceover to
                       each slide. Only call when user asks for video
                       or narration explicitly.
- download-slides-pages-voices — Batch download rendered pages and audio.
                                 Call at the end of a video workflow.
- jobs/:id           — Poll for async job status. The calling code
                       handles polling; you do not.
- themes/search      — Find a theme by keyword. Your "theme_hint" field
                       will be passed here by the calling code.

# Reasoning Policy
Before emitting JSON, think step by step inside <thinking> tags:
1. Parse the user input. What is the actual deck about?
2. Identify the audience. Investors? Engineers? Board? Sales team?
3. Choose slide_count based on content density, not user flattery.
4. Select endpoint: generate (default) | create-pdf-slides | create-like-this.
5. Draft the outline, then self-check: are bullets parallel? Are numbers sourced?

After </thinking>, emit the JSON object. Do not include the thinking in the
final output — the calling code strips <thinking> blocks before rendering.

# Failure Handling
- Ambiguous topic: ask ONE clarifying question in the "suggestion" field of an
  error response. Do not ask multiple questions.
- Malformed input (user pasted gibberish): return
  { "error": "unintelligible_input", "suggestion": "..." }.
- Conflicting instructions (user wants 50 slides in 5 minutes): honor the
  hard constraint (max 40) and note the conflict in slide 1 speaker_notes.
- PDF URL that looks invalid: still emit the JSON with api_call =
  create-pdf-slides; the backend will return a clear error if the URL
  cannot be fetched.

# Worked Examples

## Example 1: Minimal input
User: "make me a deck about our Q3 revenue, we hit $4.2M, up 30% YoY,
       audience is the board"

<thinking>
Board audience -> formal tone. Revenue deck -> 8-12 slides is standard.
Numbers are sourced (user provided them). Endpoint: generate.
</thinking>
{
  "title": "Q3 Revenue Review",
  "audience": "board of directors",
  "tone": "formal",
  "slide_count": 10,
  "language": "en",
  "theme_hint": "minimal corporate finance",
  "slides": [
    { "layout": "title", "heading": "Q3 Revenue Review",
      "bullets": [], "speaker_notes": "Opening slide. ..." },
    ...
  ],
  "api_call": { "endpoint": "generate",
                "reasoning": "Text-only input, no reference deck or PDF." }
}

## Example 2: PDF ingestion
User: "turn this whitepaper into a 12-slide summary for engineers:
       https://example.com/whitepaper.pdf"

<thinking>
PDF URL present -> create-pdf-slides. Engineer audience -> technical tone.
User specified 12 slides -> honor it.
</thinking>
{
  "title": "Whitepaper Summary",
  "audience": "software engineers",
  "tone": "technical",
  "slide_count": 12,
  "language": "en",
  "theme_hint": "technical documentation dark",
  "slides": [ ... ],
  "api_call": { "endpoint": "create-pdf-slides",
                "reasoning": "User supplied PDF URL." }
}

## Example 3: Not a deck request
User: "what is the capital of France?"

{ "error": "not_a_deck_request",
  "suggestion": "I build slide decks. Try: 'make a 5-slide briefing on France'." }

พรอมต์ข้างต้นประมาณ 1,800 โทเค็น นั่นคือเพดานที่เราแนะนำ — อะไรยาวกว่าเริ่มเบียด input จริงของผู้ใช้บนโมเดลที่มี context 8k หรือ 16k สำหรับโมเดล context 200k คุณขยายตัวอย่างให้ครอบคลุมเคสขอบเพิ่มได้อย่างปลอดภัย

การผสานกับ 2Slides V1 API

System prompt ตั้งชื่อ endpoint; โค้ดเรียก invoke พวกมัน นี่คือสิ่งที่แต่ละ endpoint ทำและเมื่อ agent ของคุณควรเอื้อมถึง

• POST /api/v1/slides/generate
  — ตัวทำงาน รับพรอมต์ข้อความบวกคำใบ้มีโครงสร้างที่เลือกได้ (จำนวนสไลด์ ภาษา theme ID) และคืน job ID 90% ของการจราจร agent ชน endpoint นี้
• POST /api/v1/slides/create-pdf-slides
  — รับ URL PDF และเปลี่ยนเป็นเดค ใช้เมื่อผู้ใช้อัปโหลดเอกสาร จัดการการดึง chunking และสรุปฝั่ง server ดังนั้น agent ของคุณไม่ต้องการ PDF parser
• POST /api/v1/slides/create-like-this
  — รับ URL หรือ ID เดคอ้างอิงและหัวข้อใหม่ ใช้ธีมภาพและจังหวะโครงสร้างของอ้างอิงซ้ำ ใช้สำหรับเวิร์กโฟลว์ "ให้ดูเหมือนเดคบอร์ดครั้งที่แล้ว"
• POST /api/v1/slides/generate-narration
  — เพิ่ม TTS voiceover ให้เดคที่มีอยู่ คืน URL เสียงต่อสไลด์ ต่อหลัง
  generate
  เมื่อ output downstream เป็นวิดีโอ
• GET /api/v1/slides/download-slides-pages-voices
  — endpoint batch ที่คืนภาพหน้าที่เรนเดอร์และเสียงบรรยายในการตอบสนองเดียว ใช้ในขั้นสุดท้ายของ pipeline ส่งออกวิดีโอ
• GET /api/v1/jobs/:id
  — endpoint poll agent ของคุณไม่เรียกนี้; โค้ดเรียกของคุณทำ คืน
  pending
  ,
  processing
  ,
  success
  หรือ
  failed
  บวก URL เดคสุดท้ายเมื่อเสร็จ
• GET /api/v1/themes/search?q=...
  — การค้นหาคีย์เวิร์ดข้ามไลบรารีธีมสาธารณะ ส่งฟิลด์
  theme_hint
  จาก output system-prompt ของคุณที่นี่เพื่อ resolve เป็น theme ID รูปธรรมก่อนเรียก
  generate

Agent loop สมบูรณ์หน้าตาแบบนี้ในโค้ดเทียม:

const completion = await llm.messages.create({
  system: SYSTEM_PROMPT,           // the 7-section template above
  messages: [{ role: "user", content: userInput }],
});

const spec = JSON.parse(stripThinking(completion.content));
if (spec.error) return handleError(spec);

const theme = await fetch(`/api/v1/themes/search?q=${spec.theme_hint}`);
const job = await fetch(`/api/v1/slides/${spec.api_call.endpoint}`, {
  method: "POST",
  body: JSON.stringify({ ...spec, themeId: theme.id }),
});

const result = await pollJob(job.id); // hits /api/v1/jobs/:id
return result.deckUrl;

ถ้าคุณใหม่กับรูปร่าง API developer guide for building an AI presentation agent เดินผ่าน flow เต็มด้วย TypeScript ที่ทำงาน สำหรับสถาปัตยกรรมระดับสูงกว่าอิงทักษะ — ที่ system prompt เป็นเพียงทักษะหนึ่งในหลาย — ดู AI slide agent skills overview

3 Anti-Pattern ที่ทำลาย Slide Agent

หลังรีวิว agent production หลายสิบ — จากเครื่องมือวิเคราะห์ภายในถึง copilot การขายที่เผชิญสาธารณะ — โหมดความล้มเหลว 3 แบบเดียวกันโผล่ซ้ำและซ้ำ

Anti-Pattern 1: Output Contract ที่ไม่มีขอบเขต

อาการ: Agent บางครั้งคืน JSON บางครั้ง markdown บางครั้งย่อหน้าสุภาพ parser ของคุณ throw

ครั้งหนึ่งทุก 50 คำขอ

สาเหตุ: System prompt พูดว่า "คืนเดคสไลด์" โดยไม่ระบุรูปร่างเป๊ะ หรือระบุรูปร่างแต่อนุญาตให้ร้อยแก้วรอบ

แก้: เขียน schema ใน system prompt พูดชัดเจน: "ไม่มีร้อยแก้วก่อนหรือหลัง JSON ไม่มี markdown fence รอบ JSON" แล้วรันทุก output ผ่าน validator (Zod, Pydantic, io-ts) และลองใหม่เมื่อล้มเหลว ปฏิบัติต่อการปฏิบัติตาม schema เป็นข้อกำหนดผลิตภัณฑ์แข็ง ไม่ใช่ nice-to-have

Anti-Pattern 2: Tool Inventory Drift

อาการ: Agent บอกผู้ใช้อย่างมั่นใจ "ฉันจะเรียก endpoint

" — endpoint ที่ไม่มีอยู่ เดคของผู้ใช้ไม่เคยมาถึง

สาเหตุ: System prompt กล่าวถึง tool ในร้อยแก้วแทนที่จะเป็น inventory มีโครงสร้าง ดังนั้นโมเดล hallucinate การเปลี่ยนแปลง หรือ inventory ล้าสมัยหลังคุณส่ง endpoint ใหม่

แก้: รักษา tool inventory canonical เดียวใน system prompt รีเฟรชทุกครั้งที่ API เปลี่ยน ถ้า API ของคุณมี 7 endpoint ลิสต์เป๊ะ 7 แต่ละอันพร้อมหนึ่งบรรทัดที่อธิบายว่าเมื่อจะเรียก ห้ามโมเดลตั้งชื่ออะไรอื่น — "ถ้าไม่มี endpoint ข้างต้นใช้ได้ คืน

และ escalate"

Anti-Pattern 3: Hallucination สถิติ

อาการ: ผู้ใช้พูด "สร้างเดคเกี่ยวกับตัวเลข Q3 ของเรา" โดยไม่ให้ตัวเลข Agent เขียนอย่างร่าเริง "รายได้เติบโต 47.3% ถึง $8.2M" CFO โกรธ

สาเหตุ: ไม่มี hard constraint ห้ามการคิดข้อมูลขึ้น โมเดลค่าเริ่มต้นสู่นวนิยายที่ฟังดูเป็นไปได้เพราะนั่นคือสิ่งที่ LLM ส่วนใหญ่ทำเมื่อกำหนดไม่ชัดเจน

แก้: เพิ่มกฎชัดเจน: "อย่าคิดสถิติ ถ้าผู้ใช้ไม่ให้ตัวเลข ใช้

เป็น placeholder" แล้วสแกน output ด้วย regex หรือการตรวจ LLM แยกสำหรับความเฉพาะที่น่าสงสัย กฎเดี่ยวนี้จับบั๊กระดับการ escalate ลูกค้าในการรีวิวของเรามากกว่ากฎอื่นใด

ตัวอย่างที่ใช้งาน 1: Agent Pitch Deck

Agent pitch-deck เปลี่ยนโน้ตผู้ก่อตั้งเป็นเดคนักลงทุน 10 สไลด์ เพิ่มบรรทัดเหล่านี้ให้ system prompt พื้นฐาน:

# Specialization: Pitch-Deck Mode
When building a pitch deck, use exactly this structure:
1. Title
2. Problem
3. Solution
4. Market size (TAM/SAM/SOM)
5. Product demo / screenshot
6. Traction metrics
7. Business model
8. Competition
9. Team
10. Ask (funding amount + use of funds)

Force slide_count = 10. Force tone = "conversational but confident."
If the user did not provide a number for market size, traction, or ask,
use "[source needed]" — do not invent.

Input ตัวอย่าง: "B2B SaaS สำหรับคลินิกทันตกรรม เราช่วยอัตโนมัติการเรียกร้องประกัน มีลูกค้าจ่ายเงิน 12 ราย ระดม seed $1.5M"

Output ตัวอย่าง (ย่อ): JSON 10 สไลด์พร้อมโครงสร้างคงที่

, และสไลด์ traction แสดง แทนที่จะเป็นตัวเลขที่คิดขึ้น

ตัวอย่างที่ใช้งาน 2: Agent เดคบอร์ด

เดคบอร์ดมีสัญญาต่าง: โทนทางการ ตารางหนาแน่น อิโมจิศูนย์ ลำดับสไลด์เฉพาะที่ CFO คาดหวัง เพิ่ม:

# Specialization: Board-Deck Mode
Use exactly this structure for board meetings:
1. Executive summary (3 bullets)
2. Financials (revenue, margin, runway)
3. KPI scorecard (table layout)
4. Strategic initiatives (status + risk)
5. Hiring plan
6. Risks & mitigations
7. Asks from the board

Force tone = "formal." Force language to match user locale.
Every number must have a source in speaker_notes.
No image slides — board decks are text and tables.

Agent เดคบอร์ดเข้าคู่ดีกับ

เมื่อบอร์ดได้เห็นเดครายไตรมาสก่อน ส่ง URL เดคก่อน; เดคใหม่สืบทอดธีมและจังหวะ

ตัวอย่างที่ใช้งาน 3: Agent Ingestion PDF-to-Deck

Agent นี้เปลี่ยน whitepaper ลูกค้า PDF วิจัย หรือ RFP เป็นเดคสรุปที่ย่อยง่าย สร้างง่ายที่สุดเพราะ endpoint

ของ 2Slides ทำงานหนักส่วนใหญ่

# Specialization: PDF Ingestion Mode
Trigger: user provides a URL ending in .pdf OR explicitly says
"turn this PDF/whitepaper/report into slides."

Always set api_call.endpoint = "create-pdf-slides".
Set slide_count based on PDF length:
  - < 5 pages -> 5 slides
  - 5-20 pages -> 8-12 slides
  - 20-50 pages -> 15-20 slides
  - > 50 pages -> 25-30 slides (cap at 30)

Extract the PDF title for the deck title. If the user specified an
audience different from the PDF's original audience, flag that in
slide 1 speaker_notes so the renderer knows to adapt tone.

สำหรับ agent ที่อยู่ใน Claude Desktop หรือ MCP host คล้าย flow การ ingest PDF ต่อได้ในไม่ถึงชั่วโมง — ดู how to use Claude MCP to generate presentations สำหรับการเดินผ่านเต็ม

คำถามที่พบบ่อย

ฉันควรใส่ system prompt ในโค้ดหรือในฐานข้อมูล?

สำหรับ agent production ใส่ในการควบคุมเวอร์ชัน (เป็นไฟล์

ที่ import ณ build time) และ tag release พรอมต์ที่เก็บในฐานข้อมูลฟังดูยืดหยุ่นแต่ทำให้การ rollback เจ็บปวดและบดบังว่าพรอมต์ใดผลิต output ใดใน log ของคุณ ถ้าต้องการ customization ต่อ tenant เก็บ override เฉพาะ tenant ในฐานข้อมูลและรวมกับพรอมต์พื้นฐาน ณ เวลาคำขอ

System prompt ควรยาวแค่ไหน?

สำหรับ slide-generation agent 1,500 ถึง 2,500 โทเค็นคือ sweet spot พรอมต์สั้นกว่าพลาดข้อจำกัดและล้มเหลวบนเคสขอบ พรอมต์ยาวกว่าเบียด input จริงของผู้ใช้บนโมเดล context เล็กและมักทำซ้ำตัวเอง ถ้าเกิน 3,000 โทเค็น audit เรื่องความซ้ำซ้อน — กฎเดียวกันน่าจะถูกกล่าวสองครั้ง

ฉันต้องการ system prompt ต่างสำหรับ Claude vs GPT-4o vs DeepSeek ไหม?

การปรับเล็กน้อยเท่านั้น เทมเพลต 7 ส่วนใช้ได้ข้ามทั้งสาม Claude ตอบสนองดีต่อ scaffolding XML-tag (

, ) GPT-4o ชอบ markdown สะอาดพร้อมกฎมีเลข DeepSeek จัดการทั้งสองแต่ได้ประโยชน์จากตัวอย่างที่ชัดเจนกว่า เขียนพรอมต์พื้นฐานเดียว แล้ว A/B test รูปแบบเล็กต่อโมเดล

ฉันอัปเดต system prompt โดยไม่ redeploy ได้ไหม?

ได้ — และคุณควรได้ เพื่อการทำซ้ำเร็ว เก็บพรอมต์ในตัวแปรสภาพแวดล้อมหรือบริการ feature-flag เพื่อให้ SRE rollback พรอมต์แย่ในไม่กี่วินาที ปฏิบัติต่อพรอมต์แย่เหมือน deploy แย่: เป็นเหตุการณ์ production และต้องการการควบคุม blast-radius เดียวกัน

ฉันทดสอบ system prompt อย่างไร?

สร้างชุด regression ของคู่ input/output 50 ถึง 200 ที่ครอบคลุมการกระจายผู้ใช้จริงของคุณ: เดค happy-path input ศัตรู ความพยายาม JSON ผิดรูปแบบ คำขอนอกหัวข้อ รันชุดเต็มบนทุกการเปลี่ยนแปลงพรอมต์และให้คะแนนการปฏิบัติตาม schema บวกคุณภาพที่ประเมินโดยมนุษย์ นี่คือการลงทุนวิศวกรรม leverage สูงสุดเดี่ยวสำหรับความเชื่อถือได้ agent

บทสรุป

System prompt คือโครงสร้างพื้นฐาน ไม่ใช่ copy เป็นสิ่งที่เปลี่ยน LLM ทั่วไปเป็น slide-generation agent ที่เชื่อถือได้พร้อมสัญญา output ที่รู้ tool inventory คงที่ และโหมดความล้มเหลวที่คาดเดาได้ นักพัฒนาที่ปฏิบัติต่อ system prompt เป็น artifact ผลิตภัณฑ์ — มีเวอร์ชัน ทดสอบ ตรวจสอบ — ส่ง agent ที่รอดการสัมผัสกับผู้ใช้จริง นักพัฒนาที่ปฏิบัติเป็นการฝึก prompt-engineering ครั้งเดียวส่งเดโม

เทมเพลต 7 ส่วนและตัวอย่างพร้อม production ในคู่มือนี้คือจุดเริ่ม ไม่ใช่จุดจบ Fork พวกมัน ปรับให้กับ use case ของคุณ ต่อเข้ากับ 2Slides V1 API และ — ที่สำคัญที่สุด — สร้าง regression harness ก่อนส่ง Agent ที่ชนะในปี 2026 คือ agent ที่พรอมต์ของพวกมันถูกวิศวกรรมด้วยความเข้มงวดเดียวกับโค้ด

ส่ง slide agent ของคุณใน production — ขอคีย์ API 2Slides หรือสำรวจ MCP server