สมการความเก่ง: Model + Harness = AI Agent

เพื่อให้เห็นภาพง่ายที่สุด เราลองมาดูสมการที่สรุปความเป็น Agent ในยุคนี้กันครับ: Model (เครื่องผลิตข้อความ) + Harness (กฎและการกระทำ) = AI Agent

• Model: เปรียบเสมือน "เครื่องยนต์" (Engine) หรือสมองที่ประมวลผลความน่าจะเป็น มันเก่งเรื่องการคิดและเดาคำตอบถัดไป แต่ถ้าสมองไม่มีแขนขา มันก็ทำอะไรไม่ได้มากไปกว่าการตอบคำถาม
• Harness: เปรียบเสมือน "ร่างกาย" และ "พวงมาลัย" ที่ควบคุมสมองนั้นอีกที สำหรับเราแล้ว Harness คือส่วนผสมของ Infrastructure (เครื่องมือ/Sandbox) และ Rules (กฎการใช้เครื่องมือ) ที่กำหนดว่า Agent จะหยิบอะไรมาใช้ตอนไหน และจะจัดการกับข้อมูลอย่างไรให้ปลอดภัย

ถ้า Model คือเครื่องยนต์ที่มีพลังมหาศาล Harness ก็คือตัวถัง เบรก และระบบนำทางที่ทำให้รถวิ่งไปถึงเป้าหมายได้โดยไม่หลุดโค้งนั่นเองครับ

ก่อนจะมี Harness เราต้องเหนื่อยขนาดไหน?

ถ้าเราย้อนกลับไปช่วงปี 2023-2024 ยุคเริ่มต้นของ AI Agent เรายังไม่มีระบบ Harness ที่เป็นมาตรฐาน สิ่งที่เราทำกันตอนนั้นคือ "Manual Training" หรือการที่ เราต้องทำหน้าที่เป็นตัวกลาง (Middleman) คอยรับคำตอบจาก AI แล้วเอาไปรันเอง พอผลออกมายังไงก็ต้องส่ง Feedback กลับไปให้โมเดลดูอีกรอบ วนไปมาแบบนี้ด้วยมือเราเอง

ต่อมาในยุคของ AutoGPT หรือ BabyAGI เราเริ่มเห็นความพยายามทำให้ Agent ทำงานเองเป็นลูป (Loop) แต่เนื่องจากยุคนั้น "กฎ" (Guardrails) ยังไม่ชัดเจน เราจึงได้บทเรียนราคาแพง เช่น:

1. Infinite Loop: Agent วนทำงานซ้ำๆ ไม่รู้จบจน Token บานปลาย
2. Diving too deep: ดำดิ่งไปดึงข้อมูลที่ไม่เกี่ยวข้องมาเต็มไปหมดเพราะไม่รู้ว่าควรหยุดตอนไหน
3. Security Risk: เสี่ยงต่อการสั่งรันคำสั่งที่อาจทำลายระบบเพราะไม่มีกำแพงกั้น

Harness จึงเกิดมาเพื่อเปลี่ยนความไม่แน่นอน (Probabilistic) ของโมเดล ให้กลายเป็นระบบที่คาดเดาผลได้และปลอดภัย (Deterministic) มากขึ้นครับ

Harness vs. MCP vs. Skill: ต่างกันตรงไหน?

หลายคนอาจจะสงสัยว่า แล้วมันต่างจาก Protocol อย่าง MCP หรือการสอน Skill ยังไง?

เราสรุปความต่างมาให้ดูชัดๆ ครับ

9 องค์ประกอบที่ Agent Harness ที่ดีควรมี

การที่ Harness จะเปลี่ยนโมเดลธรรมดาให้กลายเป็น Agent ระดับโปรได้ มันต้องประกอบด้วย 9 ส่วนสำคัญนี้ครับ:

1. Loop Condition: การจัดการเมื่อทำงานไม่สำเร็จ จะ Retry กี่ครั้ง ถ้า Error ต้องแก้ท่าไหน
2. Context Management: ระบบบีบอัดข้อมูล (Context Compression) เหมือนที่ใช้ใน Cosee (Kho-Code) เพื่อให้ Agent ยังจำใจความสำคัญได้แม้คุยกันยาวจน Ram แทบเต็ม
3. Skill & Tool Management: การเตรียมเครื่องมือพื้นฐาน โดย Harness ที่เก่งจะรู้จักเครื่องมือผ่านไฟล์อย่าง Agent.md หรือ Skill.md ได้ทันทีโดยที่เราไม่ต้องเสียเวลา Prompt บอกมันทุกรอบ
4. Sub-agent Management: การแบ่งงานให้ Agent ย่อยช่วยทำงานเฉพาะทาง
5. Build-in Skills: คำสั่งพื้นฐานที่ติดมากับตัว เช่น File Edit หรือ Shell Execution
6. Session Persistence: การเก็บ Log และประวัติเพื่อให้ "Resume" งานเดิมต่อได้จากจุดที่ค้างไว้
7. System Prompt & Caching: การวางกฎเหล็กผ่าน Prompt และการใช้ Caching เพื่อความรวดเร็วและประหยัด
8. Lifecycle Hooks: จุดตรวจสอบสำคัญอย่าง Pre-run (เช็คก่อนเริ่ม) และ Post-run (ตรวจผลลัพธ์) เพื่อความแม่นยำ
9. Permission & Safety: การคุมขอบเขต Workspace Boundary เพื่อไม่ให้ Agent แอบไปอ่านไฟล์นอกพื้นที่ที่กำหนด และมีโหมดเลือกได้ว่าจะให้ลุยเลย (Yolo) หรือต้องขออนุญาตก่อน (Approval)

ส่องของจริง: เบื้องหลังการทำงานของ Harness ในเครื่องมือชื่อดัง

เพื่อให้เห็นภาพลึกถึงระดับ Code เราลองมาดู 2 กรณีศึกษานี้ครับ:

1. Codex: การจัดการแบบเป็นลำดับชั้น

Codex ใช้โครงสร้างที่ชัดเจนมากเพื่อให้งานออกมา Deterministic:

• Thread: Session ถาวรที่เก็บประวัติทั้งหมด
• Turn: 1 รอบคำสั่ง (User สั่ง -> Agent ทำจนจบ)
• Item: เลเวลย่อยของการใช้เครื่องมือ ซึ่งมีสถานะกำกับชัดเจนคือ Item Start, Item Streaming, และ Item Complete ทำให้เราติดตามได้ทุก Step ว่าตอนนี้ Agent กำลังอ่านไฟล์ (Read), คิดวิธีแก้ (Fix), หรือกำลังโชว์ความต่างของโค้ด (Diff)

2. Cosee (Kho-Code): ลูปการทำงาน 3 ระยะ

เครื่องมือตัวนี้ใช้คอนเซปต์ React (Reasoning + Action) อย่างเข้มข้น โดยแบ่งเป็น 3 ระยะ:

• Get Context: อ่านไฟล์ ค้นหาโค้ดใน Codebase
• Take Action: แก้ไขไฟล์ หรือรันคำสั่ง Command Line
• Verify Resource: รัน Test เพื่อตรวจสอบความถูกต้อง
• ความเทพ: Harness ของ Cosee สามารถทำ "Rewind" (ย้อนเวลาก่อนแก้ไฟล์) หรือ "Fork" เพื่อแตก Session ไปลองไอเดียใหม่ๆ ได้เหมือนการใช้ Git เลยครับ

อยากเริ่มทำ Harness ต้องทำยังไง? (3 Levels of Implementation)

สำหรับใครที่อยากจะเริ่มสร้างหรือปรับแต่ง Harness ของตัวเอง เราแบ่งแนวทางไว้ 3 ระดับ:

• Level 1 (User/Prompt Level): ใช้ Harness สำเร็จรูปอย่าง Cursor, Codex หรือ Cosee แล้วควบคุมพฤติกรรมผ่านไฟล์ .md หรือ System Prompt
• Level 2 (Framework Level): ขยับขึ้นมาเขียนสคริปต์ควบคุมเส้นทาง (Flow) เองโดยใช้เฟรมเวิร์กอย่าง LangGraph หรือ CrewAI
• Level 3 (Engineering Level): เขียนขึ้นมาจาก Scratch โดยใช้ SDK ของโมเดลโดยตรง (เช่น Anthropic SDK) โดยจุดสำคัญคือการเขียนฟังก์ชัน run_loop ขึ้นมาเองเพื่อจัดการ Token, จัดการการเรียกใช้ Tool และควบคุม Logic ทุกอย่างด้วยโค้ด 100%

ก้าวต่อไปของ Agent Engineering

สุดท้ายนี้ เราอยากให้ทุกคนจำไว้ว่า "Harness คือเบื้องหลังความเทพ" ที่แท้จริงครับ แม้ในอนาคตโมเดลจะฉลาดขึ้นจนเราอาจอธิบายกฎน้อยลงได้ แต่โครงสร้างการควบคุม (Infrastructure) และความปลอดภัยก็ยังเป็นหัวใจสำคัญที่ทิ้งไม่ได้ เพื่อไม่ให้ Agent ของเราเกิดอาการหลอน (Hallucination) หรือทำงานนอกลู่นอกทาง

การคุยแบบไม่มีโปรโตคอลเปรียบเสมือนการพยายาม Debug ระบบที่ไม่มี Log ผลลัพธ์ที่ได้มักจะเป็นความคลุมเครือ (Ambiguity) และ ความอึดอัดใจทั้งสองฝ่าย

ดังนั้นมันจะดีกว่าถ้าเราทำให้สิ่งเหล่านี้เคลียและชัดเจนขึ้น เราจำต้องปรับการให้ feedback ที่เป็นระบบอย่าง Performance Improvement Plan (PIP) มาใช้ ในฐานะเครื่องมือเชิงระบบเพื่อปรับจูน Performance ให้กลับมาอยู่ในค่า Parameter ที่คาดหวัง

PIP ในฐานะ System Interface: ทำไมการวิจารณ์ลอยๆ ถึง ล้มเหลว

การให้ Feedback ทั่วไป มักล้มเหลวเพราะขาด "Interface" ที่ชัดเจน พนักงานมักรู้สึกว่าถูกจ้องจับผิด (Criticism) มากกว่าการได้รับทางออก (Solution)

เราจึงต้องมอง PIP ใหม่ว่ามันไม่ใช่บทลงโทษ (Punishment) แต่ คือ Structured Opportunity

นอกจากนี้ PIP ไม่ได้มีไว้สำหรับ "Failure State" เท่านั้น

ในมุมมองของการวางระบบที่ยืดหยุ่น PIP คือ กระบวนการจัดการ State Transition ที่มีประสิทธิภาพ ไม่ว่าจะเป็นช่วงทดลองงาน (Probation) หรือ แม้แต่การเตรียมความพร้อมเพื่อเลื่อนตำแหน่ง (Promotion) ซึ่งต้องการการวัดผลที่เข้มข้นขึ้นกว่าปกติ

7 ขั้นตอนสู่การปรับจูนประสิทธิภาพ

เพื่อให้กระบวนการปรับจูนนี้มี Insight Density สูงสุด เราควรปฏิบัติแบบ Engineering Workflow ดังนี้:

1. การกำหนด Specification (Clear Goals): ระบุวัตถุประสงค์ที่วัดผลได้ (Deterministic Goals) เช่น "ลดอัตรา Bug Density ในโมดูลที่รับผิดชอบลง 20%" แทนการพูดกว้างๆ ว่า "เขียนโค้ดให้ดีขึ้น"
2. Bi-directional Handshake (Collaboration): สื่อสารสองทางเพื่อให้แน่ใจว่าทั้ง Lead และ Engineer เข้าใจเงื่อนไขการผ่านแผน (Success Criteria) และผลลัพธ์หากไม่ผ่าน (Termination) ตรงกัน
3. High-frequency Sampling (Regular Check-ins): สร้าง Feedback Loop ที่สม่ำเสมอ แทนการรอจนจบโปรเจกต์ การเช็คอินบ่อยๆ ช่วยให้ตรวจพบ Deviation ได้เร็วและแก้ไขได้ทันที
4. Blameless Root Cause Analysis (RCA): ค้นหาต้นตอที่แท้จริง เช่น ปัญหาส่วนตัว (External Interrupts) หรือการขาดทักษะเฉพาะทาง (Technical Debt ในตัวบุคคล) เพื่อจะได้แก้ที่ต้นเหตุ ไม่ใช่แค่แก้อาการ
5. Signal Integrity (Positive Communication): รักษาคุณภาพของสัญญาณสื่อสาร ย้ำเตือนว่านี่คือ "โอกาสสุดท้าย" ในการรักษาตำแหน่ง และองค์กรยังเห็นคุณค่าในตัวเขา มิเช่นนั้นคงไม่ลงทุนในกระบวนการ PIP
6. Resource Allocation (Support/Training): หากปัญหาเกิดจาก Skill Gap ต้องจัดหา "Library" หรือทรัพยากรที่จำเป็น เช่น Mentor หรือคอร์สฝึกอบรม เพื่อช่วยให้เขาบรรลุ Performance Specs
7. System Termination/Exit Protocol (Clear Consequences): หาก Error Threshold ยังสูงเกินกว่าที่ตกลงกันไว้หลังจบแผน ต้องมีความโปร่งใสเรื่องผลที่ตามมา (เช่น ย้ายตำแหน่ง หรือเลิกจ้าง) อย่างตรงไปตรงมาตั้งแต่วันแรก

ตัวอย่างการประยุกต์ (Quality Assurance Example)

• เป้าหมาย: เพิ่ม Code Review Throughput และลด Re-work
• การดำเนินการ: กำหนดให้ Engineer ต้องตรวจเช็ค Checklist พื้นฐานก่อนส่ง Pull Request และเข้าร่วม Pairing Session กับ Senior สัปดาห์ละ 2 ครั้ง
• ตัวชี้วัด: อัตราการตีกลับของ PR ต้องลดลงเหลือไม่เกิน 15% ภายในระยะเวลา 30 วัน

Trade-offs: การรักษาคน (Retention) vs. การสร้างระบบใหม่ (Re-hiring)

ในมุมมอง Software Economics การใช้ PIP คือ การ "Refactor" ทรัพยากรมนุษย์ที่มีอยู่ ซึ่งมักจะคุ้มค่ากว่าการ "Re-write" หรือ รับคนใหม่เสมอ เพราะการเลิกจ้างมีต้นทุนแฝง (Hidden Costs) ที่สูงมาก

• Context Loss: ความรู้ใน Domain และ System Architecture ที่หายไปพร้อมกับคนเก่า
• Onboarding Latency: ระยะเวลาอย่างน้อย 3-6 เดือนกว่าคนใหม่จะเริ่มสร้าง Value ได้เต็มที่
• Recruitment Overhead: ค่าใช้จ่ายในการสัมภาษณ์ การประกาศงาน และค่าเสียโอกาสของทีมที่ต้องสละเวลามาเทรนคนใหม่

การลงทุนกับ PIP จึงเป็นการประหยัดทรัพยากรในระยะยาว หากพนักงานผ่าน PIP มาได้ พวกเขามักจะกลายเป็น "Robust Components" ที่เข้าใจความคาดหวังของระบบอย่างถ่องแท้

Risk Assessment: ข้อควรระวังและการจัดการ Compliance

ผู้นำทีมต้องตระหนักว่า PIP มีความเสี่ยง และ การจัดการที่ซับซ้อนไม่ต่างจากการรัน Migration สำคัญ

• System Pressure: กระบวนการนี้สร้างความกดดันสูง อาจส่งผลให้ Performance ส่วนอื่นๆ ตกต่ำลงชั่วคราว
• Resignation Risk: พนักงานอาจมองว่านี่ คือ Exit Sign และ ตัดสินใจ Terminate ตัวเองก่อนจบแผน
• Audit-Ready Documentation (Legal Compliance): การทำ PIP ต้องมีความละเอียดสูงเหมือนการเตรียมเอกสาร SOC2 หรือ ISO ทุกขั้นตอนต้องเป็นลายลักษณ์อักษร เพื่อป้องกันความเสี่ยงทางกฎหมาย หากต้องจบลงด้วยการเลิกจ้างจริง

บทสรุป: PIP ในฐานะเครื่องมือสร้าง System Reliability

เป้าหมายสูงสุดของ PIP คือการสร้าง Accountability Culture ที่พนักงานทุกคนตระหนักถึงมาตรฐานที่ระบบต้องการ ผู้นำที่มีวุฒิภาวะจะมองว่างานของเขาไม่ใช่แค่การเขียน Code แต่คือการรักษาความเสถียรของ Human Infrastructure

จงมองพนักงานในทีมเป็นส่วนประกอบสำคัญของระบบที่ต้องการการซ่อมบำรุง (Maintenance) และการปรับจูน (Optimization) PIP คือ Maintenance Script ที่ถูกเขียนขึ้นมาเพื่อรักษาเสถียรภาพของทีม ไม่ใช่คำสั่ง Delete เพื่อกำจัดอะไหล่ทิ้งเมื่อเกิดปัญหา วัฒนธรรมที่กล้าเผชิญหน้ากับความจริงด้วยระบบที่ชัดเจน จะเป็นรากฐานของทีมวิศวกรรมที่แข็งแกร่งและยั่งยืนอย่างแท้จริง

จุดเริ่มต้นของยุค "Oh F***": เมื่อวิศวกรรมไม่ใช่แค่การเขียนโปรแกรม

โลกของการพัฒนาซอฟต์แวร์เปลี่ยนไปตั้งแต่วันที่ AI เริ่มเข้ามามีบทบาท แต่จุดเปลี่ยนที่แท้จริงคือสิ่งที่ Jeff เรียกว่า "Oh F*** moment" ซึ่งสำหรับเขา มันเกิดขึ้นเมื่อ 2 ปีที่แล้วผ่านงานวิจัย "Cursed" agent ที่ทำงานต่อเนื่องได้นานถึง 3 เดือน

เขาบอกว่าเราต้องสร้างความชัดเจนว่า เราต้องแยกให้ออกระหว่าง 'Software Development' และ 'Software Engineering'

การมี iPhone ไม่ได้ทำให้คุณเป็นช่างภาพงานแต่งมืออาชีพฉันใด การใช้ AI เขียนโค้ดได้ก็ไม่ได้ทำให้เราเป็นวิศวกรฉันนั้น

แต่มันกำลังทำให้ "ทุกคน" กลายเป็น Developer ได้ในชั่วข้ามคืน และสำหรับใครที่ยังไม่ตระหนักถึงความเปลี่ยนแปลงนี้ในปี 2024 เตรียมตัวพบกับ "Oh F*** moment" ของจริงในปี 2026 แล้วก็เราตามโลกไม่ทันอีกต่อไป

เศรษฐศาสตร์ที่พังทลาย: ซอฟต์แวร์ราคาถูกกว่าค่าแรงขั้นต่ำ

หัวใจสำคัญที่ผู้นำธุรกิจต้องตระหนัก คือ "Unit Economics" ของซอฟต์แวร์ได้เปลี่ยนไปตลอดกาล ปัจจุบันการรัน Agent เพื่อพัฒนาซอฟต์แวร์ผ่าน Frontier Model มีต้นทุนเพียง $10.42 ต่อชั่วโมง และมันทำงานในขณะที่เรากำลังหลับด้วย

แต่สิ่งที่น่าตกใจยิ่งกว่า คือ "รสนิยม" ในการเลือกใช้เครื่องมือ

Jeff ชี้ให้เห็นว่าเครื่องมืออย่าง Claude Code นั้นกิน Token มหาศาลราวเหมือนการดื่มรวดเดียวอึกใหญ่

ในขณะที่โมเดลอย่าง Pi นั้น มีประสิทธิภาพสูงกว่ามาก และหากเราใช้โมเดลอย่าง GLM ต้นทุนจะลดลงเหลือเพียง "ไม่กี่เซ็นต์ต่อชั่วโมง" (Cents to the hour)

Software development now costs less than minimum wage. It’s a provocative title. It’s meant to be.

นี่ คือ เหตุผลที่โครงสร้างธุรกิจแบบเดิมกำลังตายลง แม้แต่ในแวดวง Venture Capital

คำถาม คือ "เราจะระดมทุน Seed Capital ไปทำไม?" ในเมื่อยุคก่อนเราขอเงินเพื่อไปจ้างวิศวกรราคาแพง แต่ในวันนี้เราสามารถสร้างผลิตภัณฑ์ได้ด้วยตัวคนเดียวผ่าน Coding Agent ได้แล้ว

Knowledge Abundance และ "K-Shape Economy"

เรากำลังเปลี่ยนจากยุค "ความรู้ขาดแคลน" ไปสู่ยุค "ความรู้ล้นเหลือ" (Knowledge Abundance) ซึ่งทำให้โครงสร้างองค์กรแบบเดิมกลายเป็นภาระ

Jeff ยกตัวอย่าง SAP Concur แอปจัดการค่าใช้จ่ายที่ใช้คนถึง 6,800 คน เขาเรียกสิ่งนี้ว่าการสร้างองค์กรด้วย "Human Meat Bags" และ การประชุมที่ไร้ประสิทธิภาพ ซึ่งเป็นระบบปฏิบัติการที่ต่อต้าน AI (Anti-AI Operating System)

โลกกำลังแยกเป็น 2 ทางในแบบ K-Shape Economy:

• ด้านบนของ K: คือกลุ่ม "Shippers" ที่ใช้คนน้อยแต่สร้างผลลัพธ์มหาศาล
• ด้านล่างของ K: คือองค์กรที่ติดหล่มอยู่ใน "J-shaped people transformation" ที่พยายามเปลี่ยนคนแต่ช้าเกินไป

คำแนะนำของ Jeff ที่โคตรโหดและโคตรตรง คือ...

Yeet them. They are your token budget.

หากพนักงานคนไหนไม่ยอมขึ้นรถไฟขบวน AI หลังจากผ่านไป 2 ปี พวกเขา คือ ภาระต้นทุนที่เราควรตัดออก เพื่อนำงบประมาณไปลงกับ Token แทน

ทักษะวิศวกรรมที่แท้จริง คือ การ "สร้าง Agent"

วิศวกรซอฟต์แวร์ในอนาคตไม่ใช่คนที่มานั่งพิมพ์โค้ด แต่ คือ คนที่เข้าใจการสร้าง Agent Loop

Jeff เปรียบเทียบ การใช้ AI เปรียบเสมือนการเล่นเครื่องดนตรี ที่ต้องอาศัยการฝึกฝนอย่างหนัก (Deliberate Practice) เพื่อให้เกิด "Taste" ในการควบคุมผลลัพธ์

Jeff ยืนยันว่าการสร้าง Agent ไม่ใช่เรื่องไกลตัว เขามีเวิร์กชอปบน GitHub ที่มีคนกด Star ให้เขาเกือบ 6,000 star

ซึ่งพิสูจน์ว่า เราสามารถสร้าง Coding Agent เองได้ในโค้ดเพียง 300 บรรทัด โดยมีวงจรพื้นฐานคือ:

User input -> Array (Memory) -> Inferencing -> Tool execution

การที่ Bun ถูกพอร์ตจากภาษา Zig ไปเป็น Rust ได้ภายใน 6 วันด้วย Agent คือ เครื่องพิสูจน์ว่า ภาษาโปรแกรมกำลังกลายเป็นสิ่งทดแทนกันได้ (Fungible)

สิ่งที่สำคัญกว่า คือ ความสามารถของ ความเป็น Engineer ไม่ใช่จำนวนปีที่เขียน Java หรือ Ruby

The Lethal Trifecta: ภัยเงียบมูลค่าพันล้านเหรียญ

ในโลกของ Automation มีภัยคุกคามที่ยังไม่มีใครแก้ได้ ซึ่ง Jeff เรียกว่า "Lethal Trifecta" ของการทำ Prompt Injection

หากเราเชื่อมต่อสิ่งเหล่านี้...

• Untrusted Input (ข้อมูลจากภายนอกที่ไม่น่าเชื่อถือ)
• Private Data Source (ฐานข้อมูลส่วนตัวขององค์กร)
• Exfiltration Ability (ความสามารถในการส่งข้อมูลออก)

สิ่งนี่ คือ ช่องโหว่ร้ายแรงที่จะทำให้องค์กรถูกเจาะข้อมูลผ่าน AI Agent

Jeff กล่าวว่าใครก็ตามที่แก้ปัญหานี้ได้ จะถือครองขุมทรัพย์มูลค่านับพันล้านเหรียญเลยก็ว่าได้

จุดจบของ Open Source และ กลยุทธ์ "Crash Cart"

แนวคิดที่สวนทางกับความเชื่อเดิมที่สุด คือ "Open Source อาจไม่จำเป็นอีกต่อไป" ในยุค AI เราควรหันมาใช้ First-party Generation หรือ การสร้าง Dependency ขึ้นมาเองตามความต้องการ เพื่อหลีกเลี่ยง Supply Chain Attack และ เพื่อให้เราสามารถควบคุมการวิวัฒนาการของโค้ดได้ 100%

นอกจากนี้ วิศวกรต้องสร้าง "Back pressure" ให้กับการ generate โค้ดของ AI โดยการเลือกใช้ภาษาที่มีระบบ Type แข็งแกร่งอย่าง Rust หรือ Haskell

เขายกตัวอย่างเปรียบเทียบกับ Data Center ที่ไม่มีจอมอนิเตอร์

ถ้าเซิร์ฟเวอร์พัง เราต้องขับรถไปที่นั่น เพื่อเชื่อมต่อ Crash Cart (รถเข็นฉุกเฉิน) เข้ากับเครื่องเพื่อกู้คืนระบบ ซึ่งมันน่าเบื่อและเสียเวลา

ในโลกของ Software Factory หน้าที่ของ Engineer คือ การใช้ Compiler ที่เข้มงวด เพื่อปฏิเสธ "อาการหลอน" (Hallucination) ของ AI ให้ได้มากที่สุด เพื่อลดจำนวนครั้งที่เราต้องเข้าไปต่อ "Crash Cart" หรือ เข้าไปแก้ไขงานที่ Agent ทำพังด้วยมือนั่นเอง

บทสรุป: เมื่อ Ideas คือ Execution

ในอดีตเรามักพูดว่า...

ไอเดียนั้นไร้ค่า การลงมือทำสำคัญที่สุด

แต่ในวันนี้ เมื่อ AI ย่อระยะเวลาการลงมือทำ (Execution) ให้สั้นลงจนเกือบเป็นศูนย์

"ไอเดียที่ดี" จึงกลายเป็นสิ่งที่หายากและมีค่าที่สุด

คุณค่าที่แท้จริงของเราในฐานะวิศวกรไม่ได้อยู่ที่การจดจำ Syntax อีกต่อไป

แต่อยู่ที่ระดับความสามารถ (Caliber) ในการออกแบบระบบ และความกระหายที่จะเรียนรู้สิ่งใหม่ ภาษาโปรแกรมเป็นเพียงแค่เครื่องมือที่เปลี่ยนผ่านได้ แต่ "รสนิยมทางวิศวกรรม" คือสิ่งที่จะทำให้เราอยู่รอด

Reference:

https://ghuntley.com/

การ vibe code ในมุมของการทำ mvp หรือ ระบบที่ไม่ซับซ้อนนั้น เป็นไปได้ และ fragile น้อย เพราะมันแบนราบ ไม่มีรายละเอียดในทางระบบเยอะ

นึกภาพว่า ระบบที่ทำมาเพื่อรองรับคนหลักร้อย กับ ระบบที่ทำมาเพื่อให้คนหลักพันใช้นั่นวิธีคิด วิธีการออกแบบระบบ ภาพอาจจะต่างกันเลย

ผมเข้าใจว่าตนนี้คนสายอื่นๆ กำลังสนุกกับการสร้างของได้เอง โดยเฉพาะฝั่ง business ที่สามารถสร้าง mvp เพื่อหาลูกค้าได้เร็วขึ้น ไม่ต้องรอการสร้างระบบจากฝั่ง development ที่นานอีกต่อไป

แต่ส่วนใหญ่ที่เราใช้ ai ออกแบบกันตอนนี้ เราไม่ได้ให้มันออกแบบระบบที่ใหญ่มาก ระบบที่ให้ ai ออกแบบ เราไม่ได้สนใจเรื่อง Non-Functional Requirements เลย หรือบางคนยังไม่รู้จัดคำนี้ด้วยซ้ำ

ลองนึกภาพดูนะ...โจทย์ ระบบลงทะเบียนรับสิทธิ์ โดยมีการ verify email, กรอกแบบ form, ยืนยันการรับสิทธิ์.ถ้ามาแค่นี้เราก็ vibe code เลย... จบใช่มั้ย

แต่ถ้าระบบลงทะเบียนรับสิทธิ์นั้นเป็นรับสิทธิ์ของร้านค้าที่คนกำลัง hype มาก ที่ต้องกดแย่งชิงกันสิ่งนี้จะเปลี่ยนไปเลย...​เพราะเราต้องคิดเยอะขึ้น

เช่น

• จำนวนคนที่เข้ามาจะเท่าไหร่
• req/s เป็นเท่าไหร่
• availability ต้องเป็นยังไง
• scalability ต้องทำยังไง
• performance ต้องระดับไหน
• ถ้าเป็นระบบที่ดูแลระยะยาว...​ Maintenance ต้องเป็นยังไง
• เป็นต้น

แล้วถ้าโจทย์เป็น microservice ที่แบ่งออกมาเป็นหลายๆ ตัว การ vibe code ก็จะซับซ้อนขึ้น และ fragile มากขึ้น

ลองนึกว่าภาพ มีสัก features นึงที่ต้องทำงานต่อกัน 3 domain แล้วเราจะ vibe code ยังไง?

จะออกแบบภาพใหญ่เลย 1 features หรือ แยกออกไปแต่ละ domain ถ้าออกแบบของแต่ละ domain ภาพใหญ่ใครคุม?

การ vibe code เพื่อให้ได้ระบบนี้ ก็จะช้าลง... และจุดที่ vibe code ได้ก็จะแคบลงไปด้วย จากทำได้ทั้ง project -> domain -> api -> function

เท่านี้... เราก็เห็นแล้วว่าถ้าไม่มีความรู้ด้าน technical เรื่องพวกนี้ก็จบเลย ไปต่อไม่ได้ ถ้าเราไม่มีความรู้แล้วเราจะสั่งให้มันทำได้ยังไงนะ?

ในมุมของการทำของชิ้นเล็กๆ เอาสนุก หรือ ทดสอบตลาด อันนี้ ai ช่วยคุณได้จริงๆ

แต่ในมุมของการ scale หรือ complexity ของระบบ ai ยังช่วยเราได้ไม่หมด

ถ้าจะให้ ai มาช่วย เราต้องคิดเยอะขึ้นมาก... รวมถึงต้องเขียนบางอย่างเพื่อมาช่วยหรือคุม ai อีกที ซึ่งมันไม่ต่างอะไรกับที่ที่เรากำลังเขียนระบบ ai เพื่อให้สามารถสั่ง ai ทำในสิ่งที่เราต้องการอีกทีนึง

ภาพนึงที่ยังคงไม่เปลี่ยน คือ Business หาเงินได้เร็ว แต่ Technical ยังคงแบกระบบให้สามารถทำเงินระยะยาวได้

สรุปจบแบบหักมุม เวลาคุยเรื่อง AI Vibe code กลับมาดูกันก่อนว่า เรากำลังคุยกันที่โจทย์ไหน? ใช้โจทย์เดียวกันหรือเปล่านะ

เราไปลงลึกในแต่ละส่วนกัน...

วิธีทำความเข้าใจ SUT ใน 4 ขั้นตอน

ก่อนที่เราจะเขียน SUT Documents ต้องผ่าน 4 คำถามนี้ก่อนเสมอ

ขั้นที่ 1: วิธี Map Architecture ของระบบที่ต้องทดสอบ

ขั้นตอนนี้ คือ ขั้นที่สำคัญที่สุด ถ้า map ผิด ทุกอย่างที่ตามมาจะ scope ผิดหมด

กระบวนการ map ทำผ่าน 5 คำถาม ตามลำดับ:

3 วิธีที่ใช้ map ตามสถานการณ์

1. มี dev/architect ช่วยได้: ทำ Event Storming หรือ Architecture Review session 1–2 ชั่วโมง วาด whiteboard ร่วมกัน แล้ว tester จด component + connection ลงใน template

2. ไม่มีคนช่วย อ่านเอง: อ่าน codebase จาก entry point เช่น router.ts, main.py, App.java แล้วตาม import/dependency ออกไปเรื่อยๆ พร้อมกับอ่าน docker-compose.yml และ .env เพื่อดู infrastructure ที่ระบบต้องการ

3. ระบบรันอยู่แล้ว: ใช้ network tracing เช่น Jaeger, Datadog, หรือแค่ browser DevTools Network tab trace request จริงแล้วดูว่ามันเรียก service อะไรบ้าง

Output ที่ควรได้ ของ Architecture Map

นี่คือ format ที่ tester ควรได้หลังจาก map เสร็จ ก่อนจะไปขั้น 2:

═══════════════════════════════════════════
ARCHITECTURE MAP — [ชื่อระบบ / Feature]
═══════════════════════════════════════════

ENTRY POINT (Q1)
  Input:   POST /api/orders  (HTTP REST, JSON body)
  Trigger: ทุกครั้งที่ user กด "สั่งซื้อ" จาก frontend
  Output:  201 Created + orderId, event → queue

COMPONENTS (Q2)
  Name              | Role (1 ประโยค)
  ──────────────────────────────────────────────────
  API Gateway       | รับ request, verify JWT, route ไป service
  Order Service     | validate + สร้าง order, publish event
  Inventory Service | ตรวจ stock, reserve item
  Notification Svc  | subscribe event, ส่ง email/push

COMMUNICATION (Q3)
  Gateway → Order Service    : REST (sync)
  Order → Inventory Service  : REST (sync)
  Order → RabbitMQ           : Publish event (async)
  RabbitMQ → Notification    : Subscribe event (async)

EXTERNAL DEPENDENCIES (Q4)
  PostgreSQL   : เก็บ order + inventory data
  RabbitMQ     : message broker
  Redis        : cache session + rate limit
  Stripe       : ชำระเงิน (external API)
  SendGrid     : ส่ง email (external API)
  JWT Provider : verify token (internal auth service)

DATA FLOW — Happy Path (Q5)
  Client
    → [POST /api/orders + JWT]
    → API Gateway (verify JWT)
    → Order Service (validate, create order in DB)
    → Inventory Service (check + reserve stock)
    → Stripe (charge payment)
    → DB commit (order = CONFIRMED)
    → Publish event: order.confirmed
    → RabbitMQ
    → Notification Service (subscribe)
    → SendGrid (send confirmation email)
    → Client ← 201 { orderId }

ตัวอย่าง ก่อน และ หลัง map

ปัญหาที่เกิดขึ้นบ่อย คือ tester เริ่ม write test case โดยไม่มี map ผล คือ scope กว้างเกินไป หรือ พลาด dependency สำคัญ

ก่อน map: tester เขียน TC ว่า "ทดสอบ create order" แต่ไม่รู้ว่า Inventory Service ถูกเรียกด้วย → integration test ผ่านบน mock แต่ fail บน staging เพราะ stock logic ไม่ถูก test

หลัง map: tester เห็นว่า Order → Inventory เป็น sync REST call → ต้องรวมไว้ใน integration scope → ตัดสินใจ run Inventory Service จริงใน Docker Compose ไม่ใช่ mock

เมื่อ map เสร็จแล้ว ก็พร้อมไปขั้น 2: ขีด boundary ว่าอะไร in-scope อะไร out-of-scope และอะไรควร mock

ขั้นที่ 2: ระบุ boundary แบ่ง In-scope vs Out-of-scope ให้ชัดเจน

สำหรับการระบุ boundary เป็นทักษะที่สำคัญมาก ถ้า scope ผิด จะ over-test หรือ under-test ทั้งคู่มีปัญหา ขอแบ่งเป็น 3 ส่วน

1: แนวคิด boundary คือ อะไรและทำไมถึงสำคัญ

Boundary ของ SUT คือ เส้นที่ขีดรอบสิ่งที่ tester "เป็นเจ้าของ" ทุกอย่างข้างในต้องมี Test Case ครอบคลุม ทุกอย่างข้างนอกต้อง mock/stub หรือ ไม่สนใจ

ปัญหาที่เกิดจาก boundary ไม่ชัด:

• Scope กว้างเกิน → test ช้า, ยากดูแล, fail เพราะ external service ล่ม ไม่ใช่ bug จริง
• Scope แคบเกิน → พลาด bug ที่เกิดตรง integration point จริงๆ
• Boundary คลุมเครือ → dev กับ QA เข้าใจต่างกัน ทำให้ coverage ซ้ำบ้าง หายบ้าง

2: กระบวนการระบุ boundary

มี 4 คำถามตามลำดับ ทำในลำดับนี้เสมอ ไม่ข้าม เพราะแต่ละขั้นใช้ผลจากขั้นก่อน

คำถามที่ 1: "ใครเป็น owner ของแต่ละ component?"

ระบุทีมหรือคนที่รับผิดชอบแต่ละ component ซึ่งโดยทั่วไปแล้ว boundary ของ SUT มักตรงกับ ownership boundary อยู่แล้ว

เช่น

Component          | Owner           | ใน scope เรา?
────────────────────────────────────────────────────────────────
Order service      | Order team      | ใช่
User service       | Auth team       | ขึ้นอยู่กับ sprint
Payment gateway    | Vendor (Stripe) | ไม่ใช่
PostgreSQL         | Platform team   | ไม่ใช่ (แต่ใช้ Docker)
Notification svc   | Comms team      | ไม่ใช่

คำถามที่ 2: "Feature ที่ต้อง test ครั้งนี้มี scope แค่ไหน?"

Boundary ไม่ใช่สิ่งคงที่ตลอด แต่มันจะเปลี่ยนตาม sprint และ feature ที่กำลัง test

เช่น

Sprint A — "สร้าง order":
  In scope: Order service
  Out: User service (ใช้ mock JWT), Notification (ใช้ stub)

Sprint B — "order + notification integration":
  In scope: Order service + Notification service
  Out: User service (ยังคง mock), External email (ใช้ WireMock)

คำถามที่ 3: "Connection ไหนข้ามทีม/ข้ามระบบ?"

ทุก connection ที่ข้าม ownership boundary = boundary point ที่ต้องตัดสินใจว่า จะ mock หรือ run จริง

เช่น

Connection                      | ข้าม boundary?| ตัดสินใจ
─────────────────────────────────────────────────────────────────────────
Order → User service            | ใช่ (ข้ามทีม)   | Mock JWT, stub user data
Order → PostgreSQL              | ใช่ (infra)   | Docker container
Order → Stripe                  | ใช่ (vendor)  | WireMock / Stripe sandbox
Order → Notification service    | ใช่ (ข้ามทีม)   | Stub หรือ Docker compose
Order service → Order repository| ไม่ (ภายใน)   | รวมใน scope เลย

คำถามที่ 4: "Boundary point แต่ละจุดมี contract อะไร?"

เมื่อรู้แล้วว่าตรงไหนเป็น boundary ต้องระบุ input/output contract ที่จุดนั้น เพื่อใช้เป็นพื้นฐาน test และ mock spec

เช่น

Boundary point: Order service → User service
  Direction:  Order เรียก User
  Protocol:   REST GET /users/{id}
  Input:      userId (string, UUID format)
  Output:     { id, email, role, isActive }
  Error case: 404 ถ้า user ไม่มี, 401 ถ้า token หมดอายุ
  Mock spec:  stub ให้ return { id: "u1", role: "customer", isActive: true }
              และ stub 404 สำหรับ TC negative cases

3: SUT Boundary Map

tester ต้องระบุให้ชัดว่า ต้องการที่จะทดสอบในส่วนไหน ซึ่งมันจะตรงข้ามกับการทดสอบแบบ manual ที่ tester จะทดสอบ E2E ทั้งระบบ

แต่ในมุมของ automation เราจำเป็นต้อง scope services/functions ที่เราต้องการจะทดสอบ เพื่อลด dependency ที่จะทำให้การทดสอบแบบ automation ยากขึ้น

ตัวอย่าง

e-commerce ที่มี microservices - Tester ต้องเห็นภาพนี้ก่อนเสมอ:

ส่วนนี้เป็นการ map boundary เข้าหากัน ซึ่ง tester จะต้องระบุให้ได้ว่า แต่ละ boundary นั่นจะใช้วิธีการแบบไหน

• in-scope
• mock / stub
• docker / sandbox
• out of scope

ในระบบที่เป็น Microservices นั้น เราจะเจอกับการเรียก services หลายตัว ดังนั้น tester จำเป็นต้องเห็นภาพรวมของระบบ และ scope ให้ได้ว่า ส่วนไหนที่เป็นเราที่จะทดสอบ และ ส่วนไหนที่ไม่ใช่ scope ของเรา เราจะไม่ทดสอบการทำงานของส่วนนั้น เราจะสนใจแค่ input/output เท่านั้น

เราจะตัดสินใจยังไง ว่าอะไรอยู่ใน scope หรือ ไม่อยู่

มี decision framework ให้ใช้ ตอบคำถาม 5 คำถามนี้ ตามลำดับ คำตอบจะออกมาเองโดยไม่ต้องเดา

ขั้นที่ 3: จำแนก dependency ตัดสินใจ

นี่ คือ ทักษะที่สำคัญที่สุดในการออกแบบ test เพราะถ้าตัดสินใจผิดตรงนี้ test ทั้ง suite จะมีปัญหา

นี่คือส่วนที่ tester มักสับสนมากที่สุด เนื่องจากต้องถามตัวเองว่า "dependency นี้ ใน test level นี้ ควรเป็นอะไร?"

หลักการตัดสินใจ

• Unit → mock/stub เสมอ
• Integration → Docker สำหรับ infra, mock สำหรับ external
• E2E → real/sandbox เมื่อเป็น critical path
• ทีมอื่น → contract + mock

Decision Tree: ใช้ 4 คำถามตามลำดับ

stub vs mock ต่างกันยังไง - ต้องรู้ก่อนจะจำแนกได้

คนมักใช้สองคำนี้ปนกัน แต่มีจุดประสงค์ต่างกันชัดเจน

กฎง่ายๆ:

• ถ้า test สนใจแค่ "ได้รับข้อมูลกลับมา" → stub
• ถ้า test สนใจ "เรียก dependency ถูกต้องไหม" → mock

ตัดสินใจ mock vs docker vs sandbox

หากใครอยากได้ decision tree ที่ใช้ตัดสินใจ ซึ่ง tester สามารถเอาไว้ถามตัวเองเวลาเจอ dependency แต่ละตัวได้

เจอ dependency X → ถามคำถามนี้ตามลำดับ

1. X อยู่ใน in-scope หรือเปล่า?
   → ไม่ใช่ = out of scope, ไม่ต้องทำอะไร (ใช้ mock contract เพื่อ isolate)
   → ใช่ = ไปคำถาม 2

2. กำลัง test ที่ level ไหน?
   → Unit = mock/stub เสมอ (ไม่มีข้อยกเว้น)
   → Integration / API = ไปคำถาม 3
   → E2E = ไปคำถาม 4

3. X เป็น internal infrastructure (DB, Queue, Cache)?
   → ใช่ = Docker container (isolated, reproducible)
   → ไม่ใช่ (external API) = WireMock / MSW / mock server
              ยกเว้น partner มี sandbox = ใช้ sandbox

4. X เป็น critical external path (payment, auth)?
   → ใช่ = Sandbox ของ vendor (Stripe test mode, Google OAuth test)
   → ไม่ใช่ = Mock/stub ก็พอ ไม่ต้องรัน end-to-end จริง

หลักการ 3 ข้อที่ทำให้ scope ชัด

1.mock ที่ boundary: ทุก dependency ที่อยู่นอก boundary ของ SUT ต้องถูก mock เสมอ ไม่ว่าจะเป็น unit หรือ integration test ไม่มีกรณียกเว้น

2.Docker สำหรับ infrastructure จริง: DB, Queue, Cache เป็น infrastructure ที่ควรรันจริงใน integration test ไม่ใช่ mock เพราะ behavior ของมัน (transaction, locking, event ordering) ต่างจาก mock มาก

3.Sandbox สำหรับ external partner ที่ critical: Stripe, PayPal, Google Auth มี test mode/sandbox ให้ใช้ใน E2E ควรใช้แทนการ mock เพราะครอบคลุม error cases ที่ real API จะส่งกลับมา

สัญญาณที่บอกว่าเรา classify ผิด

ถ้า test suite มีอาการเหล่านี้ แปลว่า dependency classification ผิดอยู่

• test ช้าผิดปกติใน unit test → มี dependency จริงหลุดเข้ามา ควรเป็น mock แต่ไม่ได้ mock
• test ผ่านทั้งหมดแต่ staging fail → mock ที่เขียนไม่ตรงกับ real dependency เกิดจากไม่มี contract test
• test flaky ไม่สม่ำเสมอ → async dependency ใน integration test ไม่ได้ใช้ Docker จริง หรือ timeout ไม่พอ
• test ไม่จับ bug ที่ production เจอ → under-mock เกินไปใน integration ควรใช้ Docker แต่ยังคง stub อยู่

ขั้น 4: Assign test levels (Unit / Integration / API / E2E ครอบคลุมตรงไหน)

ขั้นตอนสุดท้ายของ SUT analysis เมื่อเรา map, scope, classify dependency ครบแล้ว ก็ assign level ได้เลย

โดยเราต้องเข้าใจก่อนว่า เราไม่จำเป็นต้องทดสอบ 100% ทุก level เพราะการทำแบบนั้น อาจจะกินเวลานานเกินไป หรือ อาจจะไม่ได้สร้างประโยชน์มากขนาดนั้น

จากตัวอย่าง ตัวเลข 70/20/7/3 ไม่ใช่กฎตายตัว เป็นแนวทางที่ทำให้ suite เร็ว เชื่อถือได้ และดูแลง่าย ในระบบที่ heavy integration อาจเป็น 50/40/7/3 ก็ได้

เกณฑ์การ assign: ถามตัวเองแค่ 3 ข้อ

ก่อน assign level ให้ component ไหน ถามตามลำดับนี้:

1. "component นี้มี logic อะไรที่ทดสอบได้แบบ isolated?"
   → ถ้ามี = ต้องมี Unit test เสมอ (แทบทุก component)

2. "component นี้ interact กับ dependency จริงยังไง?"
   → ถ้า interact กับ DB/Queue/Cache = ต้องมี Integration test

3. "component นี้อยู่ใน user-facing flow ที่ critical ไหม?"
   → ถ้าใช่ = ต้องมี API test ที่ boundary + E2E test ที่ flow

ตัวอย่าง Level Assignment

TEST LEVEL ASSIGNMENT — Order service  Sprint 12
─────────────────────────────────────────────────────────────────
Component          │ Unit │ Integration │ API │ E2E │ หมายเหตุ
───────────────────┼──────┼─────────────┼─────┼─────┼──────────
Order domain       │  ✓   │      —      │  —  │  —  │ pure logic
OrderService       │  ✓   │      ✓      │  —  │  —  │ unit=logic, int=transaction
OrderRepository    │  △   │      ✓      │  —  │  —  │ △ = optional, int เป็นหลัก
OrderController    │  —   │      —      │  ✓  │  —  │ HTTP contract
DiscountCalculator │  ✓   │      —      │  —  │  —  │ pure function
EventPublisher     │  ✓   │      ✓      │  —  │  —  │ unit=spy, int=real queue
Checkout flow      │  —   │      —      │  —  │  ✓  │ critical user journey
Payment flow       │  —   │      —      │  —  │  ✓  │ critical, Stripe sandbox
─────────────────────────────────────────────────────────────────
รวม TC ประมาณ:       ~60        ~15       ~20   ~3

สัญญาณที่บอกว่า assign ผิด level

TC อยู่ผิด level มักแสดงออกแบบนี้

• unit test ช้าผิดปกติ (>50ms/test) → มี real I/O แอบอยู่ ควรย้าย dependency ออกหรือ mock แทน
• integration test fail เพราะ validation error → validation logic ควรอยู่ใน unit ไม่ใช่ integration
• E2E test ครอบคลุม edge case validation → เปลืองทรัพยากรมาก ควรย้ายลงมา unit หรือ API test
• ไม่มี unit test เลยสำหรับ service layer → จะ debug ยากมากเมื่อ integration test fail เพราะไม่รู้ว่า logic หรือ infra ผิด
• อยากให้ช่วยสร้าง Level Assignment Table สำหรับ service ที่ทีมกำลังทำอยู่ไหม บอก component และ layer มาได้เลย

SUT Definition Template

หากต้องการ template เอกสารที่ใช้ หน้าตาจะเป็นประมาณนี้

═══════════════════════════════════════════════════════
SUT: [ชื่อระบบ]   Version: [sprint/version]
═══════════════════════════════════════════════════════

ARCHITECTURE STYLE
  [ ] Monolith   [x] Microservices   [ ] Serverless

IN-SCOPE COMPONENTS
  Component          | Type            | Owner
  ──────────────────────────────────────────────
  Order Service      | Backend         | Order Team
  User Service       | Backend         | Auth Team
  API Gateway        | Infra/Backend   | Platform Team

DEPENDENCY STRATEGY
  Dependency   | Unit        | Integration    | E2E
  ─────────────────────────────────────────────────
  PostgreSQL   | Mock ORM    | Docker         | Docker (staging)
  Redis        | Mock        | Docker         | Docker (staging)
  RabbitMQ     | Mock        | Docker         | Docker (staging)
  Stripe       | Stub        | WireMock       | Stripe sandbox
  SendGrid     | Mock SDK    | Mock SDK       | Mock SDK
  S3           | Mock SDK    | LocalStack     | Real bucket (staging)

OUT OF SCOPE
  - Inventory Service (ทีมอื่นดูแล)
  - Analytics Pipeline (ไม่เกี่ยวกับ flow ที่ test)

DOCKER COMPOSE SETUP
  test-db:      postgres:15-alpine
  test-cache:   redis:7-alpine
  test-queue:   bitnami/rabbitmq
  wiremock:     wiremock/wiremock:latest

โครงสร้างของ Test Suite ที่แนะนำ

Test Suite ที่ดีประกอบด้วย 3 ชั้น:

Test Suite
├── Test Scenario (SC-xxx)       ← "อยากทดสอบอะไร" — 1 scenario ต่อ 1 พฤติกรรม
│   └── Test Case (TC-xxx)       ← "ทดสอบยังไง" — 1 TC ต่อ 1 เงื่อนไข/ชุดข้อมูล
│       └── Test Data (TD-xxx)   ← "ใช้ข้อมูลอะไร" — แยก data ออกจาก steps

Level Tag System — หัวใจของ Multi-Level Suite

แต่ละ TC ต้องติด Level tag เพื่อบอกว่า TC นั้นรันที่ระดับไหน:

TC บาง TC สามารถติดหลาย level ได้ เพราะ logic เดียวกัน แต่ verify คนละมุม

Template มาตรฐาน — ใช้ได้กับทุก Level

═══════════════════════════════════════════════════════
TEST SCENARIO
═══════════════════════════════════════════════════════
SC-ID:        SC-[FEATURE]-[SEQ]
Feature:      [ชื่อ Feature]
Scenario:     [อธิบาย 1 ประโยค — ทดสอบพฤติกรรมอะไร]
Precondition: [สถานะระบบก่อนเริ่ม]
Expected:     [ผลลัพธ์ที่ควรได้]
Priority:     High / Medium / Low
Type:         Functional | Boundary | Negative | Security | State

───────────────────────────────────────────────────────
TEST CASE (ลูกของ SC นี้)
───────────────────────────────────────────────────────
TC-ID:        TC-[FEATURE]-[SEQ]
Title:        [อธิบาย 1 ประโยค — ทดสอบเงื่อนไขอะไร]
Parent SC:    SC-[FEATURE]-[SEQ]

Level:        [ ] Unit  [ ] Integration  [ ] API  [ ] E2E-Manual
              (ติ๊กได้มากกว่า 1 ถ้า TC นี้ verify ได้หลาย level)

Priority:     P1 (blocker) | P2 (major) | P3 (minor)
Technique:    EP | BVA | State Transition | Decision Table | Error Guessing

Preconditions:
  - [Auth state ที่ต้องการ]
  - [Seed data ที่ต้องมีก่อน]
  - [Environment: local | dev | staging]

Steps:
  1. [Action]
  2. [Action]
  3. [Action]

Expected Output:
  Status:       [HTTP status หรือ UI state]
  Response:     [Fields และ values ที่คาดหวัง]
  Side Effects: [DB เปลี่ยนยังไง, event ถูกส่งไหม, email ถูกส่งไหม]

Test Data Ref: TD-[SEQ]   ← ชี้ไปที่ Test Data แยกต่างหาก

Level-Specific Notes:
  Unit:         [Mock อะไรบ้าง, function ไหนที่ test]
  Integration:  [Component ไหนรวมกัน, DB จริงหรือ test DB]
  API:          [Endpoint, Headers, Auth token ที่ใช้]
  E2E-Manual:   [Browser, URL เริ่มต้น, ขั้นตอน UI]

═══════════════════════════════════════════════════════
TEST DATA
═══════════════════════════════════════════════════════
TD-ID:        TD-[SEQ]
Used By:      TC-[SEQ], TC-[SEQ]   ← TC ที่ใช้ data ชุดนี้

Input:
  [field]:    [value]   # [เหตุผล เช่น "min boundary = 3 chars"]
  [field]:    [value]

Expected State After:
  [entity]:   [state ที่คาดหวังหลัง action]

ตัวอย่างจริง — Feature: User Login

Scenario

SC-ID:       SC-LOGIN-001
Feature:     User Login
Scenario:    ผู้ใช้ที่มี account ถูกต้องสามารถ login และรับ token ได้
Precondition: มี user account ที่ active อยู่ในระบบ
Expected:    ได้รับ access token และ redirect ไปหน้า dashboard
Priority:    High
Type:        Functional

Test Cases ลูก — แต่ละ TC ติด Level ต่างกัน

TC-ID:    TC-LOGIN-001
Title:    Login ด้วย email/password ถูกต้อง — ได้รับ token
Parent:   SC-LOGIN-001
Level:    [x] Unit  [x] API  [x] E2E-Manual
Priority: P1
Technique: Happy Path

Steps:
  1. ส่ง credentials ที่ถูกต้อง
  2. ตรวจสอบ response

Expected Output:
  Status:   200 OK
  Response: { token: <non-empty string>, user: { id, email, role } }
  Side Effects: last_login_at ถูก update ใน DB

Test Data Ref: TD-LOGIN-001

Level-Specific Notes:
  Unit:        Test authService.login() โดย mock UserRepository + JwtService
  API:         POST /api/v1/auth/login — ใช้ test DB, ไม่ต้อง mock
  E2E-Manual:  เปิด browser → /login → กรอก form → คลิก Submit → ตรวจ redirect

───────────────────────────────────────────────────────
TC-ID:    TC-LOGIN-002
Title:    Login ด้วย password ผิด — ได้รับ 401 และ error message
Parent:   SC-LOGIN-001
Level:    [x] Unit  [x] API  [x] E2E-Manual
Priority: P1
Technique: Error Guessing / Negative

Expected Output:
  Status:   401 Unauthorized
  Response: { error: "Invalid credentials" }
  Side Effects: ไม่มี token ถูกออก, ไม่มี session ถูกสร้าง

Level-Specific Notes:
  Unit:        ตรวจสอบว่า authService throw UnauthorizedException
  API:         ตรวจสอบ status code + response body
  E2E-Manual:  ตรวจสอบว่า error message แสดงบน UI และ user ยังอยู่หน้า login

───────────────────────────────────────────────────────
TC-ID:    TC-LOGIN-003
Title:    Login ด้วย email ที่ไม่มีในระบบ
Parent:   SC-LOGIN-001
Level:    [ ] Unit  [x] API  [x] E2E-Manual
Priority: P2
Technique: EP (invalid partition)

Level-Specific Notes:
  Unit:        ไม่จำเป็น — ครอบคลุมโดย TC-002 แล้ว (logic เดิม)
  API:         ต้องตรวจสอบว่า error message ไม่เปิดเผยว่า "email ไม่มีในระบบ" (security)
  E2E-Manual:  ตรวจสอบ UX — message ที่แสดงบน UI

Test Data แยกออกมา

TD-ID:   TD-LOGIN-001
Used By: TC-LOGIN-001

Input:
  email:    "valid.user@example.com"    # registered, active account
  password: "ValidPass1!"               # correct password

Expected State After:
  users table: last_login_at = NOW() (within 5 sec)
  sessions table: new session record created

───────────────────────────────────────────────────────
TD-ID:   TD-LOGIN-002
Used By: TC-LOGIN-002, TC-LOGIN-003

Input (TC-002 - wrong password):
  email:    "valid.user@example.com"
  password: "WrongPass999!"

Input (TC-003 - unknown email):
  email:    "notexist@example.com"
  password: "AnyPass1!"

วิธีจัดระเบียบ Test Suite ทั้งหมด

แนะนำให้จัดแบบนี้ ไม่ว่าจะเก็บใน Excel, Notion, Jira, หรือ Markdown:

Test Suite
├── Feature: Authentication
│   ├── SC-AUTH-001: Register
│   │   ├── TC-AUTH-001 (Unit, API, E2E)
│   │   └── TC-AUTH-002 (API, E2E)
│   ├── SC-AUTH-002: Login
│   │   ├── TC-AUTH-003 (Unit, API, E2E)
│   │   └── TC-AUTH-004 (API, E2E)
│   └── SC-AUTH-003: Logout
│       └── TC-AUTH-005 (Integration, API, E2E)
│
├── Feature: Order Management
│   ├── SC-ORDER-001: Create Order
│   └── SC-ORDER-002: Cancel Order
│
└── Test Data Pool
    ├── TD-001 ~ TD-010: Auth data
    └── TD-011 ~ TD-020: Order data

สรุป — สิ่งที่ทำให้ Test Suite ใช้ได้หลาย Level

Background & Problem Statement

ปัจจุบันองค์กรใช้รูปแบบ Resource Pool คือ การจัดทีมแบบ “รวมคนตาม skill” แล้ว assign ไปตาม project โดยทุกที่ทีมจะช่วยกันพัฒนา Features ต่างๆ ภายในระบบ MyOrder

Problem

• Ownership ของระบบไม่ชัดเจน
• Context switching สูง → productivity ต่ำ
• Knowledge กระจาย ไม่สะสมเป็น domain expertise
• Quality และ maintainability ลดลงในระยะยาว
• ทีมโฟกัส “ส่งงานให้เสร็จ” มากกว่า “ดูแล product ให้ดี”

ซึ่งวิธีการทำงานแบบนี้ไม่ได้ผิด แต่เหมาะกับการทำงานในบริษัทที่เป็น Software House ที่ทำจบเป็น Project ไปมากกว่า

สิ่งที่ต้องเขาใจก่อนว่า Platform business ≠ Project-based business ที่ทำแล้วจบไป แต่จำเป็นต้อง optimize เพื่อ long-term system health ไม่ใช่แค่ delivery speed ระยะสั้น

จึงจำเป็นต้องปรับให้ทีมและวิธีการพัฒนาให้เหมาะสมมากยิ่งขึ้น ซึ่งก็คือ domain team นั่นเอง

Goal / Vision

เราจะเปลี่ยนจาก:

ทีมทำตามงานที่ถูก assign

เป็น:

ทีมที่มี ownership ใน domain และ ดูแล product lifecycle แบบ end-to-end

การปรับเปลี่ยนวิธีการทำงานของทีมในครั้งนี้ เพื่อทำให้ทีมที่มี ownership และมีส่วนร่วมในการพัฒนาและดูแล product ของ MyOrder มากขึ้น ดังนี้ความรับผิดชอบและสิ่งที่ต้อง โฟกัสจะถูกขยายมากขึ้นตามไปด้วย

เพื่อให้ทุกคนเราใจภาพรวมของการจัดการโครงสร้างใหม่นี้ เราจะไปลงรายละเอียดแต่ละส่วนกัน…

Team Topologies

เป็น กรอบแนวคิด (Framework) สำหรับออกแบบโครงสร้างทีมและปฏิสัมพันธ์ภายในองค์กร เพื่อเพิ่มความเร็วในการส่งมอบงาน (Fast Flow of Value) ลดภาระทางความคิด (Cognitive Load) และ จัดการ Dependency ระหว่างทีมพัฒนาซอฟต์แวร์ และ ทีมดำเนินงาน (Operations) ให้มีประสิทธิภาพสูงสุด

โดยภาพรวมจะเป็นภาพนี้

โดยจะมีการแบ่งทีมออกเป็นดังนี้

Stream-aligned Team / Domain Team

เป็นทีมพัฒนาโดยสนใจในส่วนของการพัฒนาระบบในแต่ละ domain เราจะแบ่งออกเป็นดังนี้

• Order Domain
• Chat Experience Domain
• Shipping Domain
• อื่นๆ

Complicated Subsystem Team

เป็นสาย specialist เป็นกลุ่มผู้เชี่ยวชาญที่รับผิดชอบในการสร้างและบำรุงรักษาส่วนหนึ่งของระบบที่ต้องการความรู้เฉพาะทางขั้นสูง (เช่น อัลกอริทึมที่ซับซ้อน ตัวแปลงสัญญาณวิดีโอ ปัญญาประดิษฐ์) โดยทีมที่จะอยู่ในส่วนนี้ คือ

• AI
• Research Development

Enabling Team

กลุ่มผู้เชี่ยวชาญเฉพาะด้าน (ชั่วคราว) ที่ให้ความช่วยเหลือทีมอื่นๆ (เช่น Tech Lead / EM, SRE, Data Engineer / Data Analytic)

โดยทีมที่จะอยู่ในส่วนนี้ คือ

• Tech Lead / EM
• SRE
• Data Engineer / Data Analytic

Platform Team

มีหน้าที่รับผิดชอบในการสร้าง และ บำรุงรักษาแพลตฟอร์มพื้นฐานที่สนับสนุนการพัฒนา การติดตั้งใช้งาน และการดำเนินงานของแอปพลิเคชันซอฟต์แวร์ (เช่น แพลตฟอร์ม, การปรับปรุงให้ทันสมัย) โดยทีมที่จะอยู่ในส่วนนี้ คือ

• Modernize
• Platform

DevOps

จะไม่ใช่ทีม operations แต่จะถูกปรับเป็น responsibility จะอยู่กับทีมแทน ตามหลักของ microservice และตามนิยามของ DevOps

Dev + Operations

Interaction Model (ภาพรวม)

ในการทำงานร่วมกันของแต่ละกลุ่มจะมีการ interact ตามนี้

อธิบายการทำงานร่วมกันได้แบบนี้

1.Collaboration

ใช้เมื่อ:

• ทำ feature ใหม่
• ยังไม่ชัดว่า boundary อยู่ตรงไหน
• ต้อง design ร่วมกัน

สิ่งที่ทำร่วมกัน:

• define flow (UX + business logic)
• design API contract
• define event (OrderCreated)

Rule สำคัญ:

• ต้อง มี timebox (เช่น 1 sprint)
• ต้องมี outcome ชัด:
  • API
  • contract
  • ownership

2. X-as-a-service

ใช้เมื่อ:

• ของมัน stable แล้ว
• มี boundary ชัดแล้ว

Example:

 Chat Team → Order API → Order Team

• Chat:
  • call createOrder()
• Order:
  • รับผิดชอบ logic ทั้งหมด

 Shipping:

 Order Team → Event → Shipping Team

• OrderCreated
• OrderPaid

Rule:

• ไม่ direct access
• ใช้งานผ่าน API / Event เท่านั้น

3.Facilitating (ช่วยให้เก่งขึ้น)

ใช้เมื่อ:

• ทีมยังไม่เก่งบางเรื่อง
• ต้อง upgrade capability

Example:

 Enablement Team → Chat / Order / Shipping

ช่วยเรื่อง:

• event-driven design
• observability
• test automation
• infra, CI/CD

ลักษณะ:

• ไม่ได้ทำแทน
• แต่ สอน + coach

Anti-pattern:

• กลายเป็นทีม support ถาวร
• หรือรับงานไปทำเอง

Domain Team Responsibility

ความรับผิดชอบสำหรับ Domain Team จะมีความหลากหลายเยอะขึ้น จะไม่ใช่แค่ Develop + Deploy แล้วจบไป

โดยทีมจะมี responsibility ใน scope เหล่านี้

1. Own Roadmap (ร่วมกับ PO)

• prioritize งานใน domain ตัวเอง
• align กับ business (Goal)

2. Own Business Logic ของ Domain

• รับผิดชอบ:
  • เป็นเจ้าของความถูกต้องของ domain นั้น

3. Own System / Service

รับผิดชอบ:

• Design
• Develop
• Deploy
• Operation

You build it, you run it

4. Own Outcome

ไม่ใช่มองแค่ Output

รับผิดชอบ:

• conversion
• success rate
• latency
• error rate

เช่น:

Chat Team:

• response time
• chat → order conversion

5. Own Quality

รับผิดชอบ:

• Testing strategy
• Monitoring
• Alerting

ไม่ใช่โยนให้ QA

6. Own API / Contract

• Expose API ให้ domain อื่นใช้
• Define contract ให้ชัด
• ไม่ใช่ Expose DB / internal logic

7. Collaborate กับ Domain อื่น

รับผิดชอบ:

• การคุยกันเมื่อมีการทำงาน cross-team
• การช่วยเหลือจะต้องมีกำหนดขอบเขตชัดเจน

Core Principle สำคัญมาก

ในมุมของ core principle นั้น ให้ถือตามนี้ (จำอันนี้พอ)

1.Strong Ownership

แยก domain ให้ชัด

• เคลีย domain ให้ชัด
• ตรงไหนใครทำ (Domain Team)
• ไม่ควรถือ domain เยอะเกินไป

2.Loose Coupling

คุยกันผ่าน API / Event เท่านั้น

ไม่มีการไป query table ของ domain อื่น ผ่าน database

3.High Cohesion

การแยกส่วนที่ไม่เกี่ยวข้องออกจากกัน

4.Minimize Coordination

ถ้าหาก domain team ยังต้อง sync กันเยอะ แปลว่า อาจจะ design ผิด เพราะงานทำงานระหว่าง Domain team นั้น ส่วนใหญ่การ Sync กันในเรื่องของการ Integrate, Data Transfers เป็นหลัก

5. Collaborate

ในบาง feature จำเป็นต้อง cross-domain

วิธีการปฏิบัติ คือ การนัดทีมที่ cross-domain กัน มาคุยและวางแผนร่วมกัน (ซึ่งถ้าทำกันอย่างถูกต้อง) ก็จะได้ประมาณนี้:

• จะทำ feature อะไร ยังไง
• มีทีมที่เกี่ยวข้องกี่ทีม
• แต่ละทีมต้องทำอะไรบ้าง
• จะส่งข้อมูลกันแบบไหน
• ระยะเวลาในการทำ ช่วงไหน
• ทีมวางทำช่วงนั้นไหม
• ต้องการความช่วยเหลืออะไร

ระวังอย่าไปหลงกับหน้า ui (แยก domain กับ ui ให้ชัด)

เช่น

ถ้าเราต้องการจะเพิ่ม create order เข้าไปในหน้า chat

• Order team: เป็นคนทำ
• Chat team: จะทำ message form ของ จำแนกที่อยู่ใน chat ให้
• แต่ กดแล้ว จะส่งที่อยู่ไปที่ form ยังไง order team และ chat team จะต้องเป็นคนออกแบบร่วมกัน และทำร่วมกัน หรือ ให้อีกทีมทำเพิ่มให้ (มองในมุม front-end)
• service จำแนกที่อยู่เป็นของ shipping team ที่จะต้อง provide ให้

Advanced

• ใช้ event-driven architecture
• ใช้ contract-first design
• ใช้ async flow (ใน MyOrder ยังไม่จำเป็นต้องใช้)

Anti-pattern

ในการทำงานแบบ domain team นั้น มักมีโอกาศที่ทีจะกลับไปใช้วิธีการทำงานเดิม ดังนั้นควรทำความเข้าใจและหลีกเลี่ยงการปฏิบัติ เพื่อไม่ให้กลับไปเป็นเหมือนเดิม

ซึ่งแบ่งออกเป็นข้อๆ ได้ดังนี้

1. แบ่งตาม Layer

ในการทำงาน การแยกงานเป็น Frontend, Backend มักมีปัญหาในการรอ integrate เพราะบางช่วงบางเวลา backend งานเยอะกว่า บางเวลา frontend งานเยอะกว่า เลยเกิดการรอขึ้น ซึ่งโดยทั่วไปแล้วสมาชิกในทีมมักไม่รอ และไปหยิบงานชิ้นอื่นมาทำแทน ซึ่งนำมาซึ่งปัญหาอื่นๆ ที่ตามมา จนมักนำกลับไปเป็น resource pool ได้ด้วย

2. Cross-domain logic กระจาย

การที่ให้ทีมอื่นเข้ามาเพิ่ม/แก้ไข domain ตัวเอง เช่น

• Chat ไปเขียน order logic เอง
• Shipping ไปแก้ order status

การทำแบบนี้เป็นการพัง domain team ในระยะยาว

แต่ถ้า Domain Team มีการออกแบบไว้แล้ว และขอให้ Cross-team Help Team มาช่วยได้ แต่ต้องมี scope และกรอบเวลาที่ชัดเจน (1-2 สัปดาห์)

3.ไม่มี clear ownership

ปัญหาหนึ่งของ MyOrder คือ ไม่มี ownership ใครก็แก้ได้

สุดท้าย = ไม่มีใครรับผิดชอบ

ดังนั้น Domain / Features ส่วนใหญ่จะต้องมีทีมรับผิดชอบเสมอ และ ไม่ควรมี Domain ที่ไม่มีทีมเป็น Ownership

ยกเว้น บ้าง features ที่เป็น system กลางที่หลายๆ domain team ใช้งานร่วมกัน ส่วนนี้จำเป็นต้องดูแลร่วมกัน และการ develop ตัว code ควรแยก business domain ชัดเจน

Team ว่าง ทำไง?

เมื่อเราดูแล Domain ของใครของมัน ถ้าหากช่วงนั้น ไม่มีการ priority หรือ ไม่มี features ใหม่ๆ ให้ develop แล้ว ทีมจะมีงานอื่นๆ ให้ทำ เช่น

1. Internal Improvement: การปรับปรุงระบบให้ดีขึ้น เช่น refactor code, improve test coverage, tech debt, improve CI/CD
2. Cross-team Help: เข้าร่วมทีม ในรูปแบบของ temporary collaboration ที่ทำงานขนาดเล็กที่จบได้ภายใน 1-2 สัปดาห์
3. Platform Contribution: การเข้าไป contribute feature, improve developer experience ของ platform team
4. Innovation / Experiment: ทำการ research หรือ ทดลอง แนวคิด หรือ เครื่องมือ เพื่อนำมาใช้กับ domain เช่น AI agent, new architecture, performance experiment
5. Backlog สำคัญที่ไม่ urgent: หยิบงานอื่นๆ มาทำ เช่น observability, monitoring, alerting, security hardening, analytics
6. Skill Upgrade: เรียนรู้ และ อัพเดททักษะของคนในทีม ที่เกี่ยวข้องกับ learning domain, cross-skill

จากทั้งหมดที่กล่าวมา แสดงว่าที่จะต้องมีการเก็บสิ่งที่ต้องทำไว้ด้วย รวมถึง technical dept ที่จำเป็นต้องแก้ในภายหลัง เมื่อมีเวลา ถึงกลับมาแก้ไขสิ่งเหล่านี้

Cross-team Help

โดยปกติแล้ว ปริมาณงานของแต่ละทีมที่รับผิดชอบนั้น มักจะ priority ไม่เท่ากันในแต่ละปี ซึ่งหากทีมไม่มีงานใน domain ที่ต้องทำแล้ว (อาจไม่จำเป็นต้องใช้ครบทุกคน)

แต่ละทีมสามารถให้คนในทีมมาร่วม Cross-team Help ได้ โดยทีมนี้จะเน้นเข้าไปช่วยแก้ปัญหาบางอย่าง แต่ไม่ใช่การ take full feature / domain โดยทีมจะยังเป็นคนออกแบบระบบอยู่ / เพราะจะต้องคุม Standard, Quality ของทีม

การทำงานของ Cross-team

การเข้าร่วมของ cross-team จะเป็นการส่งคนใน domain team เข้าร่วมกลุ่ม cross-team โดยจะจัดให้แต่ละคนอยู่ใน cross-team แค่ช่วงสั้นๆ (2 week = 1 sprint) เพื่อไม่ใช้ cross-team ถืองานนอก domain ของตัวเองนานเกินไป

Cross-team เข้ามาช่วยอะไรได้บ้าง

1. ช่วย แก้ปัญหา Incident Support: ในกรณีที่มีต้องการคนช่วยเหลือและแก้ไขปัญหา Incident ที่เข้ามา สามารถร้องขอให้ Cross-team เข้ามาช่วยเหลือได้โดยเคสที่เข้ามาช่วยเหลือ ควรเป็น เคสที่มีเอกสารในการแก้ไขปัญหาแล้ว Cross-team จะได้สามารถแก้ปัญหาได้ทันทีแต่ถ้าหากเป็น case แนะนำให้ cross team เข้าไปแก้ไขปัญหาในระดับ workaround, และถ้ามีเวลาเพียงพอสามารถหา root cause ออกเป็นเอกสาร ให้ domain team ได้

2. ช่วย develop ของให้ domain team: โดย develop ตาม Adept-Blueprint ที่ทางทีมออกแบบไว้แล้ว ไม่ควรยกทั้ง feature ให้ทีมอื่นทำ เพราะจะทำให้ domain team พัง และกลับไปสู่ resource pool ได้

การขอ Support จาก Cross-team

แต่ละ Domain team สามารถร้องขอ Cross-team เข้าช่วยเหลือได้ โดยเงื่อนไข / Signal ที่บอกว่าเราควรขอความช่วยเหลือจาก Cross-team

เช่น

• เวลาในการ develop มากกว่า เวลาที่กำหนดไว้ (Lead Time > threshold)
• เจอ Incident ซ้ำๆ (มีเอกสารวิธีแก้แล้ว)
• MTTR (Mean Time To Repair หรือ Mean Time To Recovery) คือ เวลาเฉลี่ยที่ใช้ในการซ่อมแซมหรือกู้คืนระบบให้กลับมาใช้งานได้ตามปกติหลังจากเกิดความเสียหาย ซึ่งเป็นตัวชี้วัด (KPI) ด้านประสิทธิภาพการบำรุงรักษา ยิ่งค่าน้อยยิ่งดี เพราะหมายถึงการหยุดทำงาน (Downtime) น้อยลง
• Dependency สูง (>20–30%)

การขอ request ให้คุยกับทาง Engineer Manager เพื่อให้จัดสรรในส่วนนี้

การ Exit จาก Support เคส

ทุกครั้งหลังจากจบการช่วยเหลือ Cross-team จะต้องทำ Knowledge Transfer/Documents ให้แก่ domain team เช่น

• demo solution
• explain root cause
• update runbook

แต่ปัญหา คือ หลายคนใช้ผิดวิธีพิมพ์สั่งงานไปแบบมั่วๆ เครดิตหมดไว งานออกมาก็ไม่ดีสุดท้ายก็บอกว่า “AI ไม่เห็นเก่งอย่างที่เขาว่า”

ผมบอกเลยว่า “ไม่ใช่ AI ไม่เก่ง แต่บางครั้งเราใช้มันไม่เป็น”

ผมเลยสรุปรวม "7 สเต็ปจับมือทำ Claude Cowork" มาเล่าให้ทุกคนฟังแบบเข้าใจง่ายๆ ทำตามนี้ภายใน 1 สัปดาห์เราจะใช้ AI ทำงานแทนเราได้แบบน่าตกใจ

Step 1: ดาวน์โหลด Desktop App ก่อนเลย

อันนี้สำคัญมาก หลายคนพลาดตั้งแต่จุดเริ่มต้นเพราะ Cowork มันใช้บนเว็บหรือมือถือไม่ได้ต้องใช้ Desktop App บนคอมเท่านั้น

เข้าไปโหลดที่ claude.com/download ติดตั้งให้เรียบร้อย

พอเปิดขึ้นมาจะเห็นแถบด้านบนซ้ายมี Chat, Cowork, Codeให้กด "Cowork"

ส่วนการเลือกโมเดล จะมี 3 ตัวหลักที่แนะนำ

• Opus: ใช้กับงานซับซ้อน ต้องคิดเยอะ
• Sonnet: ใช้กับงานง่ายๆ ถามตอบไว
• Haiku: ใช้กับการถามทั่วไปชีวิตประจำวัน

อย่าใช้ผิดตัวนะครับ เพราะถ้างานง่ายๆแต่ไปเปิด Opus ยิงเครดิตหมดแบบไม่รู้ตัว

Step 2: สร้าง 3 โฟลเดอร์ ให้ AI

ขั้นตอนนี้ คือ การ "จัดบ้าน" ให้ AI ทำงาน

สร้างโฟลเดอร์หลักชื่อ "Claude Cowork" 1 อัน แล้วข้างในสร้างโฟลเดอร์ย่อยอีก 3 อัน คือ

1. ABOUT ME = ข้อมูลเกี่ยวกับเรา(AI อ่านอัตโนมัติทุกครั้ง)
2. OUTPUTS = งานที่ AI ทำเสร็จแล้วมาเก็บที่นี่
3. TEMPLATES = เทมเพลตที่เราทำไว้ใช้ซ้ำ

เพราะ AI จะอ่านแค่โฟลเดอร์ ABOUT ME อัตโนมัติส่วน OUTPUTS กับ TEMPLATES เราต้องชี้ให้มันอ่านเอง

ทำแบบนี้ เครดิตเราจะไม่หมดเปลืองฟรีแถม AI ทำงานเร็วขึ้นด้วย เพราะไม่ต้องอ่านไฟล์เยอะ

Step 3: เขียน 3 ไฟล์หลักที่เปลี่ยนรูปแบบการทำงาน

1 ไฟล์ .md ดีๆ ชนะการอัพโหลดมั่วๆ 50 ไฟล์เลย ซึ่งเริ่มต้นเราจะสร้างไว้แค่ 3 ไฟล์นี้ ให้เอาทั้ง 3 ไฟล์นี้ ใส่ใน ABOUT ME ให้หมด

File 1: about-me.md เขียนว่าเราเป็นใคร ทำอาชีพอะไรทำงานสไตล์ไหน มีมาตรฐานอะไรบ้าง เขียนไม่เกิน 2,000 Token (ประมาณ 1,500 คำ) เพราะถ้ายาวเกินไป AI จะอ่านช้าและเปลืองเครดิต

File 2: anti-ai-writing-style.md อันนี้ คือ ไฟล์ลับที่เปลี่ยนชีวิตเลย เขียนรวมคำที่ "ห้าม AI ใช้เด็ดขาด" เช่น คำที่ฟังแล้วรู้เลยว่า AI เขียนอย่าง "ผสมผสาน", "ทรงพลัง", "น่าทึ่ง"

แบบว่า แบน 80+ คำ AI ทิ้งไปเลยพอทำแบบนี้ AI จะเขียนเหมือนเราเป็นคนเขียนไม่ใช่ AI เขียนแล้วค่อยมาแก้ทีหลัง

File 3: my-company.md เขียนเป้าหมายธุรกิจเรา กลยุทธ์ โฟกัสอะไรอยู่ และ ที่สำคัญ "อะไรที่เราจะไม่ทำ" อัพเดตไตรมาสละครั้งก็พอ

ย้ำอีกที! รวมทั้ง 3 ไฟล์ต้องไม่เกิน 6,000 Token เพื่อให้ Cowork อ่านได้ครบทุกครั้งที่ทำงาน

Step 4: ตั้ง Global Instructions ครั้งเดียวจบ

ข้อนี้ คือ การวาง "กฏเหล็ก" ให้ AIที่มันจะจำ และ ทำตามทุกครั้ง

ไปที่ Settings → Cowork → Edit Global Instructions แล้วใส่กฏพวกนี้เข้าไป

1. ก่อนทำงานทุกครั้ง ให้อ่านไฟล์ใน ABOUT ME ก่อน
2. ห้ามอ่านไฟล์ใน OUTPUTS หรือ TEMPLATES เว้นแต่ฉันจะสั่งให้อ่าน
3. งานที่ทำเสร็จทั้งหมด เก็บใน OUTPUTS แยกเป็นโฟลเดอร์ย่อยตามโปรเจค
4. ถ้าข้อมูลไม่ครบ ให้ถามกลับ "อย่าเติมเนื้อหาเอาเอง"

พอตั้งแบบนี้เสร็จ บวกกับ 3 ไฟล์ที่ทำไว้ก่อนหน้า ต่อให้เราพิมพ์แค่ 10 คำ AI ก็ทำงานออกมาดีแบบที่เราต้องการได้ มันจะช่วยเราประหยัดเวลาเขียน Prompt ไปได้เยอะ

Step 5: ลอง เลิกพิมพ์ ใช้พูดเอา

วิธีใช้ง่ายมากกดปุ่มรูปไมค์ค้างไว้ พูดสิ่งที่อยากสั่ง แล้วปล่อย AI มันจะพิมพ์ให้ทันที

ทำไมต้องใช้ ลองคิดง่ายๆ

• Claude อ่าน 100,000 คำได้ใน 15 วินาที
• แต่เราพิมพ์เฉลี่ย 60 คำต่อนาที
• ส่วนเราพูดได้ 150 คำต่อนาที

เห็นมั้ยครับว่า "พูดเร็วกว่าพิมพ์เกือบ 3 เท่า" ทำให้เราสั่งงาน AI ได้เร็วขึ้น งานเสร็จไว มันเลยบอกได้ว่า "คอขวดของ Cowork คือ ตัวเราเอง" ที่พิมพ์ช้า งั้นลองเปลี่ยนเป็นใช้พูดดู มันช่วยได้

Step 6: ใช้ Prompt เดียวจบทุกเรื่อง

ข้อนี้เป็นไอเท็มลับเลย 80% ของ Prompt ให้เริ่มแบบนี้...

ฉันอยากทำ [งาน] ให้ได้ [เกณฑ์ความสำเร็จ] อ่านโฟลเดอร์ของฉันก่อน จากนั้นถามฉันด้วย Ask User Question ก่อนที่จะลงมือทำ

ทำไมต้องแบบนี้?

เพราะ AI จะอ่านไฟล์ของเราให้ครบก่อนแล้ว สร้างคำถามแบบคลิกเลือกให้เรา เราแค่คลิก หรือ พูดตอบ ก็จบแล้ว

AI จะรู้ข้อมูลครบเพื่อทำงาน เทคนิคนี้ง่ายแต่ทรงพลังมากลองเอาไปใช้กันดู

Step 7: ประหยัดเครดิต เพราะมันหมดเร็วมาก

ข้อนี้หลายคนพลาด แล้วร้องไห้ทีหลังเพราะแพ็ค $20 เครดิตหมดไวกว่าที่คิดเยอะ

ผมรวมเทคนิคประหยัดเครดิตมาให้แล้ว

1. Restart ดีกว่า Follow up: ทุกครั้งที่เราถามต่อในแชทเดิม AI จะอ่านประวัติทั้งหมดข้อความที่ 30 เปลืองเครดิตกว่าข้อความแรกเป็นสิบเท่า ให้กด "Restart the conversation from here" แทน
2. เริ่มแชทใหม่ทุก 20 ข้อความ: สั่ง AI สรุปก่อน copy ไว้ แล้วเปิดแชทใหม่เลย
3. รวมงานเป็นก้อนเดียว: อย่าถาม 3 Prompt แยกกัน เพราะมันจะเท่ากับ AI โหลด Context 3 รอบ ถาม 1 Prompt มี 3 งาน จะเท่ากับให้ AI โหลดแค่ 1 รอบ
4. เลือก Model ให้ถูกกับงาน: งานง่ายๆ ใช้ Sonnet งานเกี่ยวกับไวยากรณ์ ระดมไอเดีย จัดฟอร์แมตไม่ต้องเปิด Opus เปลืองเครดิตเปล่าๆ Opus เก็บไว้ใช้งานที่ต้องคิดเยอะจริงๆ
5. ไฟล์ ABOUT ME ให้เล็กที่สุด: เพราะ AI อ่านก่อนทำงานทุกครั้งถ้าไฟล์ใหญ่ = เผาเครดิตฟรีก่อนเริ่มงานจริง

เห็นมั้ยครับว่า การใช้ AI ให้เก่งๆ มันไม่ใช่แค่พิมพ์ถามไปเรื่อยๆ แต่คือการ "จัดบ้าน" ให้ AI ทำงาน

สร้างโฟลเดอร์ → เขียนไฟล์ตัวตน → ตั้งกฏ → สั่งงานด้วยเสียง

ถ้าเราทำตาม 7 step นี้ได้ครบ ภายใน 1 สัปดาห์บอกเลยว่า เราจะทำงานเร็วขึ้นหลายเท่า แถม AI ยังเขียนงานเหมือนเราเป็นคนเขียนเองไม่ใช่ AI เขียนแล้วค่อยมาแก้ทีหลังประหยัดเวลาไปได้เป็นสิบเท่า

เพราะ AI คือ ผู้ช่วยที่ฉลาดที่สุดที่ทำงานแทนเราได้ตลอด 24 ชม ไม่มีวันลา ไม่มีวันหยุด แต่เท่าที่ผมเล่ามานี่ "ยังเป็นแค่พื้นฐานนะครับ"

ใครยังไม่เคยใช้ Claude Cowork ลองโหลดมาทำตามดูใครใช้อยู่แล้ว ลองเอาเทคนิคนี้ไปปรับดู

ปัญหาอาจไม่ได้อยู่ที่สมองของเรา แต่อยู่ที่ "วิธีการอ่าน" ที่ไม่สามารถทำให้เราเข้าใจ และ ดึงเอาความรู้ไปปรับใช้ในชีวิตจริงได้

คนส่วนใหญ่มักมีวิธีการอ่านหนังสือแบบเดียวกัน คือ เปิดหน้าแรกอ่านไปจนจบ แล้วก็หวังว่าจะจำและนำไปใช้ได้

แต่ความจริง คือ การอ่านแบบนี้เหมือนกับการกินอาหารโดยไม่เคี้ยว เราอาจรู้สึกอิ่ม แต่ร่างกายอาจรู้สึกแย่ ท้องเราอาจรู้สึกอืด

Mortimer J. Adler และ Charles Van Doren ผู้เขียนหนังสือ "How to Read a Book" ได้อธิบายถึงระดับการอ่าน 4 ระดับ ที่ทำให้เราไม่ใช่แค่อ่าน แต่ต้องรู้ลึกและเข้าใจในหนังสือหรือหัวข้อนั้นๆ

ซึ่งแต่ละระดับจะทำให้เราจะได้เห็นภาพรวมของ “ทักษะการอ่าน” และ ดึงความรู้ไปใช้ได้มากขึ้น โดยเฉพาะเมื่อคุณไปถึงในระดับที่ 3 - 4

1. การอ่านระดับพื้นฐาน (Elementary Reading) – เข้าใจว่าประโยคนี้พูดอะไร

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

2. การอ่านเพื่อสำรวจ (Inspectional Reading) – รู้ว่าหนังสือเล่มนี้เกี่ยวกับอะไร

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

มันเหมือนกับ การดูแผนที่ทั้งหมดก่อนเดินทาง เราจะรู้ว่ามีเส้นทางไหน จุดหมายปลายทางอยู่ตรงไหน แทนที่จะเดินไปเรื่อยๆ โดยไม่รู้ว่ากำลังไปที่ไหน

แต่เมื่อไหร่ที่เราเริ่มคิด วิเคราะห์ระหว่างอ่าน คุณกำลังอยู่ในระดับถัดไป

3. การอ่านเชิงวิเคราะห์ (Analytical Reading) – เข้าใจลึกและดึงไปใช้ได้

ระดับนี้คือ การอ่านอย่างละเอียดและถี่ถ้วน เพื่อทำความเข้าใจเนื้อหาอย่างลึกซึ้ง

วิธีการ:

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

ตัวอย่างเช่น

บิล เกตส์ ที่มักจะคิด และ เขียนข้อโต้แย้งของเขาลงในหนังสือที่เขากำลังอ่านไว้เสมอ เพื่อตกผลึกความคิด และ ไอเดียขณะที่อ่าน

หลักการของระดับนี้ คือ การอ่านต้องเป็นการพูดคุยระหว่างผู้อ่านกับผู้เขียน ไม่ใช่แค่อ่านเฉยๆ

4. การอ่านเชิงเปรียบเทียบ (Syntopical Reading) – สร้างความรู้ใหม่จากหลายแหล่ง

ระดับสุดท้าย คือ การอ่านหนังสือหลายเล่มในหัวข้อเดียวกัน เพื่อสร้างความเข้าใจในหัวข้อนั้นๆ มากกว่าแค่การอ่านหนังสือเล่มใดเล่มหนึ่ง

ซึ่งคล้ายกับ Elon Musk ที่มักอ่านหนังสือโดยเน้นไปที่การเข้าใจ “พื้นฐานแรกสุด” ของหัวข้อนั้น (First Principle) ก่อนจะขยายหัวข้อไปศึกษาเรื่องที่ใกล้เคียง เป็นเหมือนกับต้นไม้

กลับกันหลักการของ Mortimer J. Adler และ Charles Van Doren ผู้เขียนหนังสือ "How to Read a Book” นั้นเน้นการเข้าใจ “ภาพรวม” ก่อนแล้วค่อยขยายความรู้ไปอ่านในหัวข้อใกล้เคียง

การอ่านทั้ง 4 ระดับนี้ไม่ได้แยกออกจากกัน แต่ทั้งหมดเป็นวิธีการอ่านที่สามารถเกิดขึ้นพร้อมกัน อยู่ที่ว่า เราจะเริ่มตั้งคำถาม เริ่มคิดระหว่างอ่าน และเริ่มอ่านหนังสือหลากหลายขึ้นเมื่อไหร่?

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