ทำไมการ Micromanage ถึงกลับทำให้ AI Agent ของคุณโง่ลง

นักพัฒนาหลายคนยังใช้งาน LLM ยุคใหม่เหมือนเป็นแค่สคริปต์ Regex ที่เปราะบาง แค่เปลี่ยนจากการตั้งกฎที่ตายตัว มาเป็นการให้ "หลักการสำคัญ" (Core Principles) คุณก็สามารถยกระดับ AI Agent ของคุณได้อย่างมหาศาล และนี่คือเหตุผลว่าทำไม "น้อยแต่มาก" ถึงเวิร์คกว่าจริงๆ

ทำไมการ Micromanage ถึงกลับทำให้ AI Agent ของคุณโง่ลง
Feng LiuFeng Liu
12 มีนาคม 2569

ลองเปิดไฟล์ system_prompt.txt สุ่มๆ จาก GitHub repo สมัยใหม่ดูสิครับ คุณจะเจออะไร? ส่วนใหญ่จะเป็นกำแพงตัวหนังสือที่ดูตื่นตระหนก "ห้ามทำ X เด็ดขาด", "ต้องตอบกลับมาเป็น bullet 3 ข้อเป๊ะๆ", "ห้ามใช้ library นี้เด็ดขาด"

นักพัฒนากำลังปฏิบัติกับ reasoning engine (เอนจิ้นการใช้เหตุผล) ที่ล้ำหน้าที่สุดในประวัติศาสตร์มนุษยชาติ ราวกับว่ามันเป็นสคริปต์ regex ที่เปราะบาง

ความหวาดระแวงนี้เป็นเรื่องที่เข้าใจได้ถ้าย้อนดูอดีต แค่ปีสองปีก่อน LLM ยุคแรกๆ ต้องการการจับมือทำแบบสุดๆ แค่เพื่อให้มันตอบตรงประเด็น แต่ยุคสมัยมันเปลี่ยนไปแล้วครับ โมเดลสมัยใหม่ฉลาดขึ้นอย่างเหลือเชื่อ แต่เราก็ยังเขียน prompt เหมือนกำลังโปรแกรมไมโครเวฟยุค 80s เรากำลังพยายาม hardcode ความฉลาดลงไป

เมื่อไม่นานมานี้มีเรื่องน่าสนใจเกิดขึ้นที่ Vercel ซึ่งพิสูจน์ประเด็นนี้ได้ดีเลยครับ ทีม Engineer ของพวกเขาได้ตีพิมพ์บทความเจาะลึกว่าพวกเขาพัฒนาโปรดักต์ v0 ให้ดีขึ้นได้อย่างไร โดยมีรายละเอียดของการตัดสินใจที่ดูค้านความรู้สึก (counterintuitive) นั่นคือ: พวกเขาลบ tools ของ agent ออกไปถึง 80%

ผลลัพธ์น่ะเหรอ? ระบบไม่ได้พังครับ แต่มันกลับทำงานได้ดีขึ้นมาก การตัด tools ที่กำหนดไว้จุกจิกและกฎเกณฑ์ที่ตายตัวออกไป ช่วยลดความสับสนและปล่อยให้โมเดลได้ทำในสิ่งที่มันทำได้ดีที่สุด นั่นคือการใช้เหตุผลแก้ปัญหา (reason through the problem) ยิ่งมีแรงเสียดทานน้อย โค้ดที่ได้ก็ยิ่งออกมาดี

นี่คือบทเรียนที่ลึกซึ้งมากสำหรับใครก็ตามที่กำลังสร้างโปรดักต์ด้วย AI ในตอนนี้: จงให้หลักการ (Principles) ไม่ใช่กฎเกณฑ์ที่ตายตัว (Rigid rules)

กระบวนทัศน์เทคโนโลยีแบบย้อนยุคเทียบกับสมัยใหม่

เวลาที่คุณบอก LLM ว่าต้องทำอะไรแบบเป๊ะๆ ทีละสเต็ป คุณกำลังบังคับให้มันใช้ attention (พลังประมวลผล) ที่มีจำกัดไปกับการทำตามคำสั่ง (compliance) แทนที่จะโฟกัสที่คุณภาพ (quality) คุณกำลังพรากความสามารถในการดึงข้อมูลมหาศาลที่มันถูกเทรนมา เพื่อหาทางออกที่สวยงามกว่าสิ่งที่คุณ hardcode ไว้

เพื่อให้เห็นภาพความแตกต่าง ลองดูวิธีที่นักพัฒนาส่วนใหญ่เขียน agent prompt เทียบกับวิธีที่พวกเขา ควร จะเขียนดูครับ

วิธีที่แย่ (กฎเกณฑ์ตายตัว):

"จงเขียนฟังก์ชัน Python เพื่อดึงข้อมูล user คุณต้องใช้ library requests คุณต้องจัดการ error ด้วยบล็อก try/except คุณต้อง return ค่าเป็น dictionary ที่มี key 'name', 'email' และ 'status' เป๊ะๆ ห้ามใช้ async และจงใส่คอมเมนต์ในทุกบรรทัด"

วิธีที่ดี (หลักการ & เป้าหมาย):

"จงเขียนฟังก์ชัน Python ที่แข็งแกร่ง (robust) เพื่อดึงข้อมูล user แนะนำให้ใช้ library มาตรฐานที่ทันสมัย โค้ดควรอยู่ในระดับ production-ready ซึ่งหมายถึงสามารถจัดการกับ network failure และ edge case ได้อย่างนุ่มนวล ให้ความสำคัญกับความสามารถในการอ่านโค้ด (readability) และสถาปัตยกรรมที่สะอาด (clean architecture) มากกว่าการเขียนโค้ดแบบท่ายาก ระบบปลายทาง (downstream) คาดหวังข้อมูล user profile ตามมาตรฐาน (name, email, status)"

สังเกตเห็นความเปลี่ยนแปลงไหมครับ? ตัวอย่างแรกปฏิบัติกับ AI เหมือนเป็น Junior Developer ที่เรายังไม่ไว้ใจ ส่วนตัวอย่างที่สองปฏิบัติกับมันเหมือนเป็น Senior Engineer ที่เข้าใจเป้าหมายและบริบท คุณแค่บอกมันว่าผลลัพธ์ที่ดีหน้าตาเป็นอย่างไรและ ทำไม ถึงต้องเป็นแบบนั้น จากนั้นก็ถอยออกมาแล้วปล่อยให้มันหาวิธีการ (อย่างไร) เอาเอง

แน่นอนครับว่า กฎนี้มีข้อยกเว้นสำคัญอยู่ข้อหนึ่ง

เมื่อ agent ต้องคุยกับ agent ตัวอื่น—หรือเมื่อ upstream agent ต้องส่งข้อมูลไปให้ database parser ปลายทางที่ต้องการความเป๊ะ—คุณจำเป็นต้องมีความเข้มงวดขั้นสุด การส่งมอบข้อมูลระหว่างเครื่องจักร (Machine-to-machine handoffs) ต้องการ JSON schemas ที่แม่นยำและยืดหยุ่นไม่ได้ แต่สำหรับการใช้เหตุผล (reasoning), การสร้างสรรค์ (generation) และการแก้ปัญหา (problem-solving) ล่ะก็? ปล่อยมือให้หลวมลงหน่อยเถอะครับ

ถ้าคุณอยากอัปเกรด coding assistant ของคุณให้เก่งขึ้นทันทีตั้งแต่วันนี้ ลองก๊อปปี้ข้อความบล็อกนี้ไปวางใน claude.md, memory.md หรือใน core system prompt ของ agent คุณดูครับ:

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

เลิกพยายามจู้จี้จุกจิก (micromanage) กับเครื่องจักรได้แล้วครับ จงเชื่อใจ LLM สมัยใหม่ พวกมันเร็วกว่า ฉลาดกว่า และมีความสามารถมากกว่าอย่างไม่มีที่สิ้นสุด เมื่อเราเลิกปฏิบัติกับพวกมันเหมือนเป็นเด็กเตาะแตะ

โครงสร้างที่ตายตัวเทียบกับการใช้เหตุผลที่ลื่นไหล

แชร์สิ่งนี้

Feng Liu

Feng Liu

shenjian8628@gmail.com

ทำไมการ Micromanage ถึงกลับทำให้ AI Agent ของคุณโง่ลง | Feng Liu