จาก "ช่วยคิด" สู่ "ลงมือทำ": เอา AI ไปทำงานจริงในองค์กรด้วย Claude — ตั้งแต่แนวคิดถึงสเกล

1) ห้องที่ทุกคนใช้ AI ทุกวัน แต่ยังกลัวตกรถ

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

2) สองโจทย์จริงจากหน้างาน

ผู้เข้าร่วมโยนสองโจทย์ที่เป็นตัวแทนของหลายองค์กร (1) "ทำยังไงให้ AI ตอบถูกและคงเส้นคงวาทุกครั้ง" — วิทยากรตอบแบบวิศวกรว่า การบังคับให้ LLM ตอบ เหมือนเดิมเป๊ะแบบ deterministic ทำไม่ได้ ในระดับใช้งานทั่วไป (2) "อยากได้ผู้ช่วยที่รู้เรื่องในองค์กร" ตอบคำถามซ้ำ ๆ แทนคนเก่งคนเดิม โดยไม่ "ตอบออกทะเล" ทั้งสองโจทย์จริง ๆ คือเรื่อง governance (ความน่าเชื่อถือ + ตรวจสอบย้อนได้) มากกว่าการเลือกโมเดล — และคำตอบของทั้งคู่อยู่ที่เรื่องเดียวกัน คือ การจัดการบริบท (context) และคลังความรู้

3) AI ไม่ได้มีแค่ "ภาษา" — และมันถูกฝึกมายังไง

วิทยากรย้อนไปปี 2016 ที่ AlphaGo ของ Google DeepMind เอาชนะ Lee Sedol แชมป์โกะโลก 4–1 ด้วย deep learning + reinforcement learning (Wikipedia) จุดที่อยากให้เห็นคือ LLM ที่เราใช้ทุกวันเป็นแค่เสี้ยวเดียวของ AI ทั้งหมด วิธีฝึกมี 3 แบบหลัก: Supervised (ติดป้ายบอกตรง ๆ ว่าอะไรคืออะไร), Unsupervised (ให้หาแพตเทิร์นเอง), Reinforcement (ให้คุณให้โทษ) และเขาทิ้งประเด็นเตือนว่า ทุกครั้งที่เรา "หยุดเมื่อพอใจคำตอบ" คือสัญญาณรางวัลที่ระบบอาจนำไปปรับต่อ — จึง ระวังข้อมูลส่วนบุคคล เวลาใช้ AI สาธารณะ

4) Vibe coding คืออะไร — และทำไมพูดถึงในปี 2026

คำว่า vibe coding มาจาก Andrej Karpathy (ผู้ร่วมก่อตั้ง OpenAI, อดีต Director of AI ที่ Tesla, ล่าสุดมีรายงานว่าเข้าทีม pretraining ของ Anthropic กลางพฤษภาคม 2026) (CNBC) เขานิยามไว้ในทวีต ก.พ. 2025 ว่า "ยอมจำนนต่อ vibe ไปเลย... ลืมไปได้ว่ายังมี code อยู่" (Simon Willison) วิทยากรย่อยเป็น 3 ลักษณะ: Intent-first (บอกผลลัพธ์ที่ต้องการ ไม่ใช่วิธีเขียน), Iterate by feel (รันดูผล ไม่ใช่ debug code แต่ debug คำอธิบายของตัวเอง), AI คือ developer · คุณคือ PM (คุณตัดสิน "ใช่/ยังไม่ใช่" Claude เป็นคนเขียน-รัน-ทดสอบ-แก้)

5) ทำไมเป็น "วินัย" ไม่ใช่แค่ meme — AI Engineering

วิทยากรอ้างหนังสือ Chip Huyen, AI Engineering (O'Reilly, 2025) ว่าการสร้างแอปด้วย foundation model ต่างจาก ML แบบเดิม 3 ข้อ: (1) ปรับโมเดล ไม่ใช่สร้างโมเดล (จาก training → adaptation), (2) โมเดลใหญ่ขึ้น compute หนักขึ้น (inference optimization สำคัญตั้งแต่วันแรก), (3) output เปิด → evaluation ยาก (ไม่มี ground truth คำตอบเดียว) (Chip Huyen / O'Reilly) และ workflow กลับด้าน: เดิม Data → Model → Product แต่ AI Engineering คือ Product → Data → Model — สร้างของก่อน เก็บข้อมูลจากการใช้จริง แล้วค่อยลงทุนในโมเดลเฉพาะที่พิสูจน์ traction แล้ว ("AI Engineering มอบรางวัลให้ทีมที่ iterate เร็ว" — Shawn Wang, 2023)

6) ลูป 4 ขั้นของ Vibe Coding

แทนลูปเดิม "เขียน → debug → แก้ code" ลูปใหม่คือ Describe → Generate → Run → Refine: บรรยาย context+intent+รูปแบบ output → ปล่อยให้ Claude สร้าง (ใน Claude.ai เป็น Artifact preview ทันที / ใน Claude Code เขียนไฟล์ลง project) → รันดูผล 3 จุด (ทำงานไหม/ตรงไหม/edge case) → แก้ที่ prompt ไม่ใช่แก้ code วนจนพอใจ หนึ่งรอบ 30 วินาที–2 นาที, 10 รอบ ≈ แอปใช้งานได้ใน 20–30 นาที · กฎสำคัญ: ถ้าวน 3 รอบยังไม่ดีขึ้น ให้เริ่มใหม่ด้วย prompt ที่ละเอียดกว่าเดิม (อย่าฝืนแก้ต่อ เพราะ context จะเต็มไปด้วยความพยายามที่พัง)

7) Claude ปี 2026 — อะไรเปลี่ยน

วิทยากรสรุป 3 การเปลี่ยนสำคัญ: Chat → Agent (Claude วางแผน เรียก tool ทำซ้ำ ตรวจผลเองได้ — หน่วยงานเปลี่ยนจาก "1 คำตอบ" เป็น "1 งานเสร็จ"), Prompt → Skill (ความรู้ที่ใช้ซ้ำถูกแพ็กเป็น Skill/Plugin/MCP — prompt ที่ดีกลายเป็นสินทรัพย์องค์กร), Sandbox → System (เชื่อมไฟล์/ปฏิทิน/CRM/ERP ผ่าน MCP) สามความสามารถที่ต้องรู้: Skills (คำสั่งสำเร็จรูปสำหรับงานมีแพตเทิร์น), MCP Connectors (ดึง/เขียนข้อมูลในเครื่องมือที่ใช้อยู่), Sub-agents/Plans (งานใหญ่กว่า 1 prompt แบ่งทีมทำขนาน) เสริมด้วย 6 prompt patterns ที่ใช้ซ้ำได้: chain-of-thought, few-shot, output schema (JSON), role framing, self-critique loop, negative constraints

8) BPMN — ภาษากลางของ automation

ก่อน automate ให้ วาดกระบวนการก่อน ด้วย BPMN — มี 4 สัญลักษณ์หลัก: Event (เหตุการณ์ตั้งต้น), Task (งานที่ทำ โดยคน/Claude/ระบบ), Gateway (จุดตัดสินใจ เช่น "ยอดเกิน 5K ส่ง Finance Director"), Flow (ทิศทางงาน) ทำไมสำคัญในยุค AI: มันกำหนดขอบเขตว่างานไหน Claude รับผิดชอบ-งานไหนคนตัดสิน, ระบุข้อมูลที่ต้องใช้ (ลูกศร = payload), และเป็น หลักฐาน audit เมื่อประกอบกับ run log · ที่สำคัญ BPMN เป็นมาตรฐาน ISO/IEC 19510 (ตั้งแต่ 2013) — โมเดล AI เปลี่ยนทุก 6 เดือน แต่ BPMN ที่วาดวันนี้จะยังใช้ได้ในปี 2030

9) เลือกเครื่องมือก่อนเริ่ม

Vibe coding ไม่ผูกกับ tool เดียว เวิร์กช็อปนี้ใช้ 2 ตัวหลัก คือ Claude.ai Artifacts (ทำงานบน browser ไม่ต้องติดตั้ง พิมพ์ prompt → ได้ Artifact preview ทันที แชร์ผ่าน URL ได้ — เหมาะกับต้นแบบ/เดโม/ทดสอบไอเดียใน 10 นาที) และ Claude Code (ทำงานบน terminal เข้าถึง repo จริง อ่าน/เขียนไฟล์ รัน git — เหมาะกับ codebase ที่มีอยู่แล้ว) ส่วนเครื่องมือเสริมที่ "รู้ไว้เลือกใช้": v0.dev (Next.js + UI สวย, deploy Vercel), Bolt.new (full-stack บน browser), และ Cursor (VS Code ที่ฝัง AI — เหมาะถ้าคุ้นเคย IDE อยู่แล้ว) เดโม 1–3 วันนี้ใช้ Claude.ai Artifacts เป็นหลัก

10) เดโม 1 (Beginner) — Feedback Classifier

โจทย์: vibe-code สร้าง "web app หน้าเดียว" ที่ผู้ใช้ paste/upload CSV ของ feedback ลูกค้า แล้วจัดหมวด positive/neutral/negative พร้อม summary — เสร็จใน ~20 นาที 3 รอบ รอบแรกบอกให้สร้าง React + Tailwind, parse CSV ใน browser, classify ด้วย keyword heuristic (ไม่ต้องเรียก API), แสดงเป็น table + summary card · รอบ 2 เพิ่ม category filter + ทำให้สวยแบบ Stripe/Linear · รอบ 3 เพิ่มปุ่ม export CSV + จัดการ CSV พัง + empty state · จุดสอน: เราไม่ได้ให้ Claude "จัดหมวดให้ครั้งเดียว" แต่สร้างแอปจัดหมวดที่คนอื่นหยิบไปใช้ต่อได้ — เริ่ม simple ก่อน เพิ่มความซับซ้อนเมื่อจำเป็น

11) เดโม 2 (Intermediate) — PR Triage Dashboard

ยกระดับเป็น "เครื่องมือใช้ภายใน": Finance Officer upload CSV คำขอซื้อ (PR) + paste นโยบายเป็น markdown → ได้ table แสดงผู้อนุมัติ/SLA/flags + ร่างอีเมล 3 ฉบับ โดยมี 2 gateway (ตามยอดเงิน + ตาม flag ยกเว้น เช่น vendor ยังไม่ verify VAT → NEEDS_LEGAL) จุดเด็ดคือ policy ≡ UI: นโยบายอยู่ใน textarea ที่แก้ได้ทันที (debounce 300ms) แล้ว table อัปเดตเรียลไทม์ พร้อม "policy version" counter ไว้ audit · บทเรียน: แยก rule (เปลี่ยนบ่อย) ออกจาก code (เปลี่ยนไม่บ่อย) ให้ business owner แก้ policy เองได้โดยไม่ต้องผ่าน developer งานที่เคยจ้างทีม dev 2–3 สัปดาห์ ทำได้ใน ~35 นาที

12) เดโม 3 (Advanced) — SME Morning Brief mini-app

โจทย์จริงของผู้บริหาร: ทุกเช้าต้องเช็ก 4 ด้าน (ยอดขายเมื่อวาน, สต็อกใกล้หมด, คิว support, ลูกค้าสำคัญ) เดโมสร้าง Morning Briefing จาก prompt เดียวที่สั่ง Claude รัน 4 การตรวจ ขนานกันเป็น sub-agent A/B/C/D (อ่านคนละ CSV) แล้ว agent หลักรวบเป็น brief เดียว: Top 3 action วันนี้ (มี owner + เหตุผล 1 บรรทัด) + ความเสี่ยงสัปดาห์นี้ + ร่างตอบ ticket ที่ค้างนานสุด · เหตุที่เป็น "Advanced": อ่านหลายแหล่ง + sub-agent ขนาน + ตั้ง schedule รันทุก 06:00 ได้ → mini-app ตัวแรกถือกำเนิด (ทำไมต้องแยก sub-agent? เพราะ context isolation, ขนานเร็วกว่า serial, และแก้ A ไม่กระทบ B/C/D — นี่คือรากฐานของ harness)

13) เมื่อคุณติด — 6 failure modes + prompt แก้

vibe coding ไม่ราบรื่นเสมอ 6 รูปแบบนี้ครอบคลุม ~80% ของปัญหาจริง และส่วนใหญ่แก้ด้วยการ "ปรับ prompt" ไม่ใช่ "เปลี่ยน tool":

1. ผลไม่ตรง intent ("ดูเหมือนถูกแต่ไม่ใช่") → ขอให้มันโชว์ตัวอย่าง input→output 3 ชุดก่อนเขียนจริง ให้เรายืนยัน
2. Output ยาวเกิน/ถูกตัด → "แสดงเฉพาะ section ที่เปลี่ยน · ใช้ diff format"
3. แก้ bug หนึ่งเกิด bug ใหม่ (วนไม่จบ) → "หยุด · เริ่มใหม่ · ช่วยเขียน prompt ใหม่ให้ผมตามที่ควรได้ตั้งแต่แรก"
4. Claude ปฏิเสธ/ถามไม่จบ → "ลองทำเต็มที่ก่อน · ใช้ assumption ที่ดีที่สุด · ระบุ assumption ไว้ด้านบน เดี๋ยวผมแก้เองถ้าผิด"
5. เรียก library/API ที่ไม่มีจริง (hallucination) → "ใช้เฉพาะ standard browser API · ถ้าต้อง install ให้บอกชื่อ+version+คำสั่งก่อน · error: <paste>"
6. ทำงานได้แต่หน้าตายังไม่โปร → "ทำให้เหมือน product ของ Stripe/Linear/Vercel · spacing มากขึ้น, accent 1 สี, hover state"

14) ปรับโมเดล + เลือกโมเดล + ต้นทุน

เมื่อ prompt อย่างเดียวไม่พอ มี บันได 3 ขั้น (อ้างอิง Chip Huyen): Prompt Engineering (ไม่แตะ weight, ใช้ 0–10 ตัวอย่าง — เริ่มที่นี่เสมอ) → RAG (เชื่อม knowledge base ดึงข้อมูลเข้า prompt — เหมาะกับเอกสาร/นโยบายภายใน) → Finetuning (เปลี่ยน weight ใช้ data หลักร้อย–หมื่น — พิจารณาเมื่อ prompt+RAG ยังไม่ถึง quality bar) สำหรับเลือกโมเดลและประมาณการต้นทุน เด็คให้ตารางอ้างอิง (พ.ค. 2026): Haiku เร็วสุด/ถูกสุด สำหรับงานปริมาณมากรูปแบบชัด, Sonnet สมดุล สำหรับ workflow ทั่วไป, Opus ลึกสุด สำหรับ reasoning/code/planning หลายขั้น · ลดต้นทุนได้ด้วย prompt caching (−90%) และ Batch API (−50%) — ตัวอย่างเด็ค: SME รัน skill ~30M tokens/เดือนด้วย Haiku ราว $30 ดิบ เหลือ $5–10 เมื่อเปิด caching

15) AI Harness — โครงที่ทำให้โมเดลกลายเป็น Agent

ปี 2025 พูดเรื่อง agent ปี 2026 พูดเรื่อง harness — เพราะ (ตามเด็ค) ราว 70% ของประสิทธิภาพ agent อยู่นอกตัวโมเดล อยู่ที่ "นั่งร้าน" ที่ห่อโมเดลไว้ ความเข้าใจนี้ตรงกับวงการ: การเปลี่ยนแค่ชั้น orchestration รอบโมเดล (โมเดลเดิม) ทำให้คะแนน benchmark กระโดดได้จริง (LangChain — Context Engineering) 6 ส่วนของ harness: Orchestration Loop (สมอง), Tools (อ่าน/เขียน/เรียก), Memory (สั้น/ยาว), Context Management, State Persistence, Guardrails + Observability · ภายใต้ Context Management มี 4 กลยุทธ์มาตรฐาน (LangChain): Write (เก็บ context ออกนอก window), Select (ดึงเฉพาะที่เกี่ยว/RAG), Compress (สรุปก่อนส่งต่อ), Isolate (แยก context ข้าม sub-agent)

Anthropic เสนอ pattern Three-Agent: Planner → Generator → Evaluator (ถ้าไม่ผ่านวนกลับ Planner) สำหรับงานยาวเป็นชั่วโมง/วัน และหลักการสำคัญ: "ทุก component ใน harness คือสมมติฐานว่าโมเดลยังทำเองไม่ได้ — เมื่อโมเดลเก่งขึ้น ควรถอด component ออก; นั่งร้านที่ไม่ถอดจะกลายเป็นหนี้ทางเทคนิค" (Anthropic Engineering) ตัวอย่างจริง: Claude Opus 4.7 (Anthropic, 16 เม.ย. 2026) เพิ่ม self-verification ระดับโมเดล ดัน SWE-bench Verified จาก 80.8% → 87.6% (Anthropic) — สัญญาณว่าบทบาท Evaluator กำลังถูกถอดออก

16) หลักการที่ไม่เคยเปลี่ยน — สร้าง "ห้องสมุด" ให้ AI

ถ้าจำอะไรไม่ได้เลย ให้จำข้อนี้: AI ต้องมี "ห้องสมุด" ให้กลับไปหยิบความรู้ ถ้าไม่มีที่อ้างอิง มันก็ hallucinate (หลอน) ใส่เรา ดังนั้นทุกครั้งที่ vibe-code ให้มันมีไฟล์/CSV/ฐานข้อมูลเป็นที่อ้าง ในเชิงวิชาการนี่คือ Knowledge Management + Information Retrieval องค์กรที่เก็บความรู้เป็นระบบ (แยกชั้น/แผนก/เจ้าของ เหมือนชั้นหนังสือ ไม่ใช่กองรวม) จะทำให้ AI หลอนน้อยลง และก่อนเอา AI ไปจับงานไหน ให้ กลับมาที่ Business Process ก่อน — วาด flow หาจุดที่ช้า/เจ็บสุด แล้วผ่าตัดตรงนั้น

17) ขึ้นใช้จริง — security และเส้นทาง MiniApp → Enterprise

ต้นแบบใน Artifacts/Cowork ยัง "เห็นแค่ในโฟลเดอร์" พอข้อมูลโตและใช้หลายคน งานจะทะลุไป Claude Code: ต่อ Google Sheets (เร็วถ้าไม่เกิน ~60,000 แถว ตามที่วิทยากรระบุ) หรือฐานข้อมูลจริง พร้อม login/สิทธิ์/แจ้งเตือน — ส่วนนี้คือ "งานตกแต่ง" ที่ไอทียังมีบทบาท · งานข้อมูลอ่อนไหว (PII/การเงิน) และ regulated (ธนาคาร/ก.ล.ต./ประกัน) ยังไม่แนะนำ AI สาธารณะ ต้องมีระบบปิด (closed VPC), data masking, login ผ่าน VPN/zero-trust, จำกัดโดเมน หรือ OTP · เด็คให้ภาพ MiniApp → Enterprise 5 ระดับ: (1) Prompt copy-paste → (2) Skill ใช้ซ้ำทั้งทีม → (3) เครื่องมือมี UI/ฐานข้อมูล → (4) บริการที่ schedule+แจ้งเตือน → (5) ระบบ governed เต็มรูป · SME ส่วนใหญ่หยุดที่ระดับ 2 แล้วพลาดผลทบต้น

งานไหนเหมาะ/ไม่เหมาะใช้ AI ตอนนี้:

18) ESG Hands-on — มุมที่เชื่อมกับ "ยุคสเกล"

เพราะโมเดลใหญ่ขึ้น compute หนักขึ้น ต้นทุนพลังงานและน้ำของ AI จึงเป็นเรื่อง ESG จริง: ปี 2025 ดาต้าเซ็นเตอร์ทั่วโลกใช้ไฟราว 448 TWh (ถ้าเป็นประเทศจะใหญ่อันดับ 11 ของโลก) และใช้น้ำหล่อเย็นมหาศาล (PBS) เวิร์กช็อปจึงมีเดโม ESG ที่ใช้ Claude อ่าน บิลค่าไฟ/น้ำ (utility bills) แล้วคำนวณ Scope 2 emissions ตาม grid factor รายภูมิภาค/ปี — เป็นตัวอย่างของ multimodal (อ่านเอกสาร→คำนวณ→รายงาน) ที่ SME เอาไปทำรายงาน ESG เบื้องต้นได้เอง

19) Durable vs Disposable — ลงทุนกับอะไร

วิทยากรแยกสิ่งที่ควร "ศึกษาเชิงลึก" ออกจากสิ่งที่ "รู้ไว้ใช้งาน": Durable (ลงทุนได้) — หลักการที่อยู่ทน เช่น BPMN, knowledge management, 6 components ของ harness (เป็น pattern ของ distributed systems ที่ใช้มาเป็นสิบปีและจะยังอยู่ปี 2030) · Disposable (รู้ไว้พอ) — เครื่องมือ/framework เฉพาะตัว (ครึ่งหนึ่งจะถูกแทนใน ~18 เดือน) เลือก 1 ตัวให้ทีมใช้ แต่ อย่ายึดติด และอย่าใช้เป็นเกณฑ์รับคน

20) Starter Pack + FAQ

สิ่งที่เอาไปทำ "วันจันทร์หน้า": เปิด Claude.ai ลองทำเดโม 1 ซ้ำกับข้อมูลของตัวเอง · เลือกหนึ่งกระบวนการที่เจ็บสุดในแผนกแล้ววาด BPMN · เก็บ prompt ที่ดีเป็น Skill · ส่วน FAQ ที่ถามบ่อย (security/cost/governance/rollout) วนกลับมาที่หลักเดิม — งานอ่อนไหวใช้ระบบปิด, ต้นทุนคุมด้วย model picker + caching, governance เริ่มจาก BPMN + run log + สิทธิ์การเข้าถึง

21) สรุป — เตรียมห้องสมุด ให้สกิล แล้วกำกับ

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

1. จัดบ้านความรู้ก่อนสร้างแชตบอต (ROI สูง, ทำได้เลย) — รวบรวมความรู้ที่ "อยู่ในหัวคน" เป็นคลังจัดหมวด มีเจ้าของ/สิทธิ์ ก่อนทำบอท
2. เริ่มจาก Business Process แล้วทำต้นแบบในงานแคบ ๆ (ROI สูง, ความพยายามปานกลาง) — หาจุดเจ็บสุดหนึ่งจุดต่อแผนก ทำ MVP ด้วย Claude วัดผล แล้วค่อยไต่ระดับ 1→5
3. แยกชั้น "ทดลอง" กับ "ขึ้นจริง" ให้ชัด (ROI ปานกลาง, กันความเสี่ยง) — งานไม่อ่อนไหวใช้ได้เลย; งาน PII/regulated ส่งต่อไอทีทำ security ก่อนเสมอ

หมายเหตุ: ตัวอย่างเดโม ตัวเลขเวลา/ต้นทุน และสถิติ ecosystem บางส่วนเป็นการสาธิตและการประเมินในเด็คของวิทยากร — ผู้อ่านควรปรับให้เข้ากับบริบทและข้อกำหนดขององค์กรตนเอง