ทำงานกับ AI ให้เหมือนมีเพื่อนร่วมทีมคนใหม่

จากการถามคำถาม ไปสู่การมอบหมายงานให้ AI ลงมือทำจริง

เช้าวันจันทร์ เวลา 9:07 น.

กาแฟยังไม่ทันออกฤทธิ์ แต่ข้อความจากทีมเด้งมาแล้วสามห้อง ลูกค้าขอแก้ Requirement, หน้าเว็บมีบั๊ก และบ่ายนี้ต้องมี Demo

คุณเปิด AI แล้วพิมพ์ว่า

“ช่วยสรุปทั้งหมดนี้ให้หน่อย”

ไม่กี่วินาทีต่อมา AI ส่งสรุปที่ดูดีมากกลับมา คุณอ่านแล้วพยักหน้าเบา ๆ ก่อนจะพบความจริงข้อหนึ่ง

งานทั้งหมดก็ยังนั่งรอคุณอยู่ที่เดิม

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

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

แต่ AI รุ่นใหม่เริ่มเดินออกมาจากหลังเคาน์เตอร์แล้ว มันเปิดไฟล์ อ่านเอกสาร ใช้ browser รันคำสั่ง แก้โค้ด ทดสอบสิ่งที่ทำ และส่งหลักฐานกลับมาให้เราตรวจได้ บทบาทจึงเริ่มขยับจาก “คนตอบคำถาม” ไปเป็น “คนที่ช่วยทำงานต่อ”

ตรงนี้เองที่วิธีคิดของเราต้องเปลี่ยนตาม

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

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

บทความนี้จะพาแกะเรื่องทั้งหมดตั้งแต่ศัพท์ AI ที่เจอบ่อย ไปจนถึงวิธีมอบหมายงานแบบ Agentic Workflow พร้อมตัวอย่างสร้าง Task Management App ตั้งแต่บรีฟหนึ่งประโยคจนได้ไฟล์ที่เปิดใช้ได้จริง

แนวคิดหลักมีอยู่ง่าย ๆ ว่า อย่าเพิ่งรีบเรียนแค่การ “ใช้ AI” ให้เก่ง แต่ให้เรียนรู้วิธี “ทำงานร่วมกับ AI” ให้เป็น

ถ้าอ่านจบแล้วคุณเริ่มคุยกับ AI เหมือนกำลังบรีฟเพื่อนร่วมทีม มากกว่ากำลังโยนเหรียญลงตู้กดคำตอบ บทความนี้ก็ทำหน้าที่ของมันแล้ว

---

1. วันที่ AI เริ่มลุกจากโต๊ะตอบคำถามมาช่วยทำงาน

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

วันหนึ่งพนักงานคนเดิมเปิดประตูเคาน์เตอร์ เดินมาที่โต๊ะเรา แล้วถามว่า “ไฟล์อยู่ไหน เดี๋ยวผมลองให้”

นั่นคือความรู้สึกของการเปลี่ยนจาก Chat ไปสู่ Agent

ที่ผ่านมา เรามักใช้ AI อยู่สี่แบบ

1. ถาม เพื่อขอคำตอบหรือคำอธิบาย
2. ร่าง เพื่อช่วยเริ่มงานจากหน้ากระดาษเปล่า
3. สรุป เพื่อย่อยข้อมูลยาว ๆ ให้จับประเด็นง่ายขึ้น
4. ลงมือ โดยให้ AI ใช้เครื่องมือและทำงานหลายขั้นต่อเนื่องกัน

สามข้อแรกคุ้นเคยดี ส่วนข้อสุดท้ายคือจุดที่โลกการทำงานกำลังเปลี่ยนเร็วที่สุด

ลองสมมติว่าเว็บของทีมมีบั๊ก ผู้ใช้เปลี่ยนสถานะ Task เป็น Done แล้ว แต่พอกด refresh สถานะกลับไปเหมือนเดิม

ถ้าใช้ AI แบบแชต เราอาจถามว่า

“Status เปลี่ยนแล้วไม่ถูกบันทึก น่าจะเกิดจากอะไร?”

AI อาจเสนอสมมติฐานให้ เช่น ลืมเรียกฟังก์ชันบันทึกข้อมูล เขียนค่าลงตัวแปรแต่ไม่ได้เขียนลง localStorage หรือโหลดข้อมูลเก่ามาทับหลัง render คำตอบเหล่านี้ช่วยให้เราคิดเร็วขึ้น แต่เรายังต้องเปิดไฟล์ หาโค้ด ทดลองแก้ และทดสอบเอง

ถ้าใช้ AI แบบ Agent เราอาจมอบหมายว่า

“สืบสวนบั๊กนี้ใน repository หาเหตุ แก้ไข แล้วทดสอบเคสเดิมให้ดู ก่อนสรุปว่าคุณเปลี่ยนอะไรและตรวจอย่างไร”

งานเดียวกัน แต่ขอบเขตความรับผิดชอบต่างกันมาก แบบแรกขอ “ความคิดเห็น” แบบหลังมอบ “ภารกิจ”

Agent ที่มีสิทธิ์และเครื่องมือเหมาะสมอาจทำงานต่อเนื่องแบบนี้

1. เปิดไฟล์ที่เกี่ยวข้อง
2. ไล่เส้นทางข้อมูลตอนผู้ใช้เปลี่ยนสถานะ
3. หาเหตุที่ข้อมูลไม่ถูกบันทึก
4. แก้โค้ด
5. เปิดแอปหรือรันทดสอบ
6. ทำเคสเดิมซ้ำ
7. ส่งผลพร้อมหลักฐานให้เราตรวจ

ความแตกต่างไม่ได้อยู่ที่ AI ตัวหลัง “ฉลาดกว่า” เสมอไป บางครั้งสมองข้างในอาจเป็น model เดียวกันด้วยซ้ำ สิ่งที่เพิ่มขึ้นคือเป้าหมาย เครื่องมือ วิธีทำงาน และสิทธิ์ในการลงมือ

เปรียบง่าย ๆ แบบนี้ก็ได้ Generative AI คล้ายฟรีแลนซ์มือดี เราส่งบรีฟไปแล้วรับชิ้นงานกลับมา ส่วน Agentic Workflow คล้ายเพื่อนร่วมทีมที่เราให้เป้าหมาย เปิดโต๊ะทำงานให้ แล้วเขาเดินไปหยิบข้อมูล ใช้เครื่องมือ ทำหลายขั้น และกลับมารายงานผล

ทั้งสองแบบมีประโยชน์คนละงาน ถ้าต้องการไอเดียชื่อปุ่ม 20 แบบ การคุยในแชตก็เพียงพอ แต่ถ้าต้องการแก้บั๊กในโค้ดจริง การให้ AI เห็นไฟล์และรันทดสอบได้ย่อมมีประโยชน์กว่า

ภาพจำแบบเร็ว: Chat ช่วยถือไฟฉายให้เรา ส่วน Agent ถือไฟฉาย เดินเข้าไปดูใต้ฝากระโปรง และกลับมาบอกว่าขันน็อตตัวไหนไปบ้าง

---

2. AI 101 ฉบับคุยกับคนในทีมรู้เรื่อง

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

ข่าวดีคือเราไม่ต้องสอบปลายภาค ข่าวดียิ่งกว่าคือไม่มีใครมายึดบัตรพนักงานถ้าเราจำคำว่า Multimodal สลับกับ Machine Learning เป้าหมายของบทนี้มีแค่ให้เราคุยกับคนในทีมแล้วนึกภาพเดียวกัน

AI คือร่มคันใหญ่

Artificial Intelligence หรือ AI เป็นชื่อรวมกว้าง ๆ ของระบบที่ทำงานบางอย่างซึ่งปกติต้องอาศัยความสามารถแบบมนุษย์ เช่น การจำแนกภาพ การวางแผน การเข้าใจภาษา หรือการตัดสินใจจากข้อมูล

ให้นึกถึงคำว่า “ยานพาหนะ” รถยนต์ จักรยาน เรือ และเครื่องบินล้วนอยู่ใต้ร่มเดียวกัน แต่ทำงานต่างกัน AI ก็คล้ายกัน มันไม่ได้หมายถึงเทคโนโลยีชนิดเดียว

Machine Learning เรียนแพตเทิร์นจากข้อมูล

Machine Learning คือแนวทางที่ทำให้ระบบเรียนรู้รูปแบบจากข้อมูล แทนที่เราจะเขียนกฎทุกข้อด้วยมือ

ตัวอย่างเช่น ถ้าอยากเดาว่า Task ไหนเสี่ยงส่งช้า เราอาจให้ระบบดูงานเก่าจำนวนมาก พร้อมข้อมูลว่าแต่ละงานใช้เวลากี่วัน เปลี่ยน owner กี่ครั้ง มี dependency แค่ไหน และสุดท้ายส่งทันหรือไม่ ระบบจะค่อย ๆ จับแพตเทิร์นแล้วนำไปประเมินงานใหม่

มันคล้ายพนักงานคลังสินค้าที่ทำงานมานานจนมองกล่องแวบเดียวก็เริ่มเดาได้ว่ากล่องไหนมีโอกาสเสียหาย เพียงแต่ Machine Learning เรียนจากข้อมูลจำนวนมากและสรุปแพตเทิร์นเป็นแบบจำลอง

Generative AI สร้างของใหม่จากสิ่งที่เรียนมา

Generative AI สร้าง output ใหม่ เช่น ข้อความ ภาพ เสียง วิดีโอ หรือโค้ด

เมื่อเราให้มันร่าง user story สร้างภาพประกอบ หรือเขียนฟังก์ชัน JavaScript มันไม่ได้หยิบคำตอบชิ้นเดิมจากลิ้นชักมาส่งให้ตรง ๆ แต่มันสร้างผลลัพธ์ขึ้นมาตามคำสั่งและบริบทที่ได้รับ

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

LLM คือสมองที่ทำงานกับภาษาเป็นหลัก

Large Language Model หรือ LLM เป็น model ที่เรียนรู้รูปแบบของภาษาจากข้อมูลจำนวนมาก มันจึงทำงานกับข้อความได้หลากหลาย ตั้งแต่ตอบคำถาม สรุป วิเคราะห์ เขียนโค้ด ไปจนถึงช่วยวางแผน

ชื่อ “Language Model” อาจทำให้ดูเหมือนมันมีไว้แต่งประโยค แต่ภาษาเป็นวัสดุหลักของงานจำนวนมาก Requirement, source code, test case, เอกสารสัญญา, SQL และ log ล้วนเป็นข้อความในรูปแบบต่าง ๆ เมื่อ model ทำงานกับภาษาได้ดี มันจึงเข้าไปช่วยงานได้กว้างกว่าการเขียนบทความ

Multimodal AI อ่านโลกได้มากกว่าข้อความ

Multimodal AI รับข้อมูลได้หลายรูปแบบ เช่น ข้อความ ภาพ screenshot เสียง หรือวิดีโอ

ลองนึกถึงผู้ใช้ที่แจ้งบั๊กด้วยภาพหน้าจอ ถ้า AI อ่านได้แต่ข้อความ เราต้องอธิบายทุกอย่างใหม่ แต่ถ้ามันอ่านภาพได้ เราอาจส่ง screenshot พร้อมบอกว่า “ปุ่มนี้ซ้อนกับข้อความบนจอมือถือ” แล้วให้มันช่วยวิเคราะห์ต่อ

Agentic AI รับเป้าหมายแล้วทำงานต่อ

Agentic AI เน้นความสามารถในการเดินหน้าไปสู่เป้าหมาย มันอาจวางแผน ใช้เครื่องมือ ดูผล ปรับทาง และตรวจงานก่อนรายงานกลับ

Agentic AI ไม่ได้อยู่คนละโลกกับ Generative AI ระบบ Agent จำนวนมากใช้ LLM เป็นสมองในการคิดและสื่อสาร ความต่างอยู่ที่ระบบรอบสมองนั้นอนุญาตให้ทำอะไรต่อได้บ้าง

ถ้า LLM เปรียบเหมือนเชฟที่คิดเมนูเก่ง Agentic System คือเชฟคนเดิมที่ได้เข้าครัว มีวัตถุดิบ อุปกรณ์ สูตรมาตรฐาน และรู้ว่าใครต้องชิมก่อนยกอาหารออกเสิร์ฟ

โจทย์เดียวกัน เทคโนโลยีช่วยคนละมุม

สมมติทีมอยากจัดการ Task ให้ง่ายขึ้น

• Automation ช่วยตั้งกฎ เช่น เมื่อ checklist ครบทุกข้อให้เปลี่ยนสถานะเป็น Done
• Machine Learning ช่วยเดาว่างานไหนเสี่ยงล่าช้าจากข้อมูลในอดีต
• Generative AI ช่วยร่าง user story ข้อความบนหน้าจอ หรือโค้ดเริ่มต้น
• Agentic Workflow รับเป้าหมาย เปิดไฟล์ที่เกี่ยวข้อง ลงมือแก้ และทดสอบผล

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

สรุปศัพท์ก่อนเดินต่อ: AI คือชื่อสนามใหญ่, Model คือสมอง, Generative AI ช่วยสร้าง, Multimodal รับข้อมูลหลายแบบ และ Agentic AI พางานเดินไปหาเป้าหมาย

---

3. ถ้าอยากให้ AI ทำงานต่อเอง ต้องเตรียมอะไรให้บ้าง

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

คิดเสียว่าเรากำลังส่งเพื่อนออกไปซื้อของ ถ้าเราบอกเพียง “ไปซื้ออะไรดี ๆ มาให้หน่อย” แล้วไม่ให้เงิน ไม่บอกว่าร้านอยู่ไหน และไม่พูดว่าเราแพ้ถั่ว ผลลัพธ์ที่ได้อาจสร้างเรื่องเล่าในงานเลี้ยงได้ดี แต่ไม่เหมาะจะเป็นมื้อเย็น

3.1 Goal เป้าหมายที่รู้ว่าเส้นชัยอยู่ตรงไหน

“ช่วยทำ Task App” เป็นความตั้งใจ แต่ยังไม่ใช่เส้นชัยที่ชัด

Task App อาจหมายถึงเว็บสำหรับคนเดียว แอปในองค์กร ระบบที่ต้องมี login หรือแค่หน้าต้นแบบ หาก AI ไม่รู้ว่าแบบไหนเรียกว่าเสร็จ มันต้องเดา และทุกครั้งที่เดา เรากำลังซื้อลอตเตอรี่หนึ่งใบให้โครงการ

เป้าหมายที่ดีควรบอก output และเกณฑ์สำคัญ เช่น

“สร้าง Task App เป็น index.html ไฟล์เดียว เปิดใน browser ได้โดยไม่ใช้ server ผู้ใช้เพิ่ม แก้ เปลี่ยนสถานะ และกรอง Task ตาม priority ได้ ข้อมูลต้องยังอยู่หลัง refresh”

ประโยคนี้ไม่ได้บอกทุกขั้น แต่ทำให้เส้นชัยมองเห็นได้

3.2 Tools เครื่องมือที่งานต้องใช้

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

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

เครื่องมือที่พบบ่อย ได้แก่

• Files สำหรับอ่านและแก้ไฟล์
• Terminal สำหรับรันคำสั่งและ tests
• Git สำหรับดู diff และประวัติ
• Browser สำหรับเปิดหน้าเว็บและทดลองใช้งาน
• Search สำหรับค้นข้อมูล
• API หรือ Database สำหรับเข้าถึงระบบที่ได้รับสิทธิ์

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

3.3 Loop วงรอบที่ทำให้แก้ทางได้

งานจริงไม่ค่อยสำเร็จในการยิงครั้งเดียว Agent จึงต้องมีวงรอบประมาณนี้

1. วางแผน
2. ลงมือ
3. ดูผลที่เกิดขึ้น
4. เทียบกับเป้าหมาย
5. ปรับและลองใหม่ถ้าจำเป็น

ถ้าเขียนโค้ดแล้วไม่รัน เราได้เพียง “โค้ดที่หน้าตาเหมือนจะใช้ได้” ถ้ารันแล้ว error แต่ Agent อ่าน error ไม่เป็น วงรอบก็ขาดตรงกลาง ถ้าแก้ error ได้แต่ไม่กลับไปทดสอบพฤติกรรมเดิม เราอาจซ่อมประตูหน้าแล้วทำหน้าต่างหลุดแทน

3.4 Boundary ขอบเขตและจุดที่ต้องถาม

Agent ควรรู้ว่าอะไรทำเองได้ อะไรห้ามแตะ และเมื่อไรต้องหยุดถาม

ตัวอย่าง Boundary ที่ช่วยลดเรื่องปวดหัว

• สร้างและแก้ไฟล์เฉพาะในโฟลเดอร์งานนี้
• ห้ามแตะ production data
• แจ้งก่อนเปลี่ยน database schema
• ถ้าโจทย์มีทางเลือกที่กระทบผู้ใช้ ให้ถามก่อนเลือก
• ถ้าทดลองแก้แล้วล้มเหลวซ้ำตามจำนวนที่กำหนด ให้หยุดและรายงานหลักฐาน

Boundary ไม่ได้มีไว้ผูกมือ AI แต่มันเหมือนรั้วข้างถนน ทำให้ขับได้เร็วขึ้นโดยไม่เผลอตกเหว

สูตรจำสั้น ๆ: Goal บอกเส้นชัย, Tools ให้ของใช้, Loop ทำให้แก้ทางเป็น และ Boundary กันไม่ให้งานไหลออกนอกสนาม

---

4. กายวิภาคของเพื่อนร่วมทีม AI

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

พนักงานใหม่อาจนั่งมอง Ticket อยู่ครู่หนึ่ง แล้วคิดในใจว่า “Priority P1 ของที่นี่แปลว่าด่วนที่สุด หรือแปลว่าเอาไว้ก่อนนะ?” แต่เพราะไม่มีใครอยู่ให้ถาม เขาจึงเลือกคำตอบที่ดูสมเหตุสมผลที่สุด แล้วเริ่มสร้างของผิดทางอย่างขยันขันแข็ง

เรื่องน่ากลัวไม่ใช่คนที่ไม่ทำงาน เรื่องน่ากลัวคือคนที่ทำงานเร็วมากไปผิดทิศ และ AI ทำแบบนั้นได้เร็วเป็นพิเศษ

AI ก็เหมือนกัน การทำงานที่ดีเกิดจากองค์ประกอบหลายชิ้นประกอบกัน

องค์ประกอบ	เปรียบเหมือน	หน้าที่
Model	สมอง	คิด วิเคราะห์ สร้าง และสื่อสาร
Context	ความรู้เกี่ยวกับบริษัทและงาน	ช่วยให้ตัดสินใจบนข้อเท็จจริงที่เกี่ยวข้อง
Prompt	บรีฟงานรอบนี้	บอกว่าตอนนี้ต้องการให้ทำอะไร
Instructions	กฎของทีม	บอกข้อบังคับและพฤติกรรมที่ต้องรักษา
Skill	SOP หรือสูตรทำงาน	บอกขั้นตอนที่ควรใช้ซ้ำกับงานประเภทหนึ่ง
Tool	เครื่องมือในกระเป๋า	ทำให้เปิดไฟล์ รันคำสั่ง หรือใช้บริการได้
MCP	หัวต่อมาตรฐาน	เชื่อม AI กับข้อมูลและบริการภายนอก
Agent	ผู้รับเป้าหมาย	ประกอบทุกอย่างเข้าด้วยกันแล้วเดินงานต่อ

ต่อไปเราจะดูทีละชิ้น เพราะปัญหาที่ดูเหมือน “AI ไม่เก่ง” หลายครั้งเกิดจากเราให้ชิ้นส่วนไม่ครบ

4.1 Model เลือกสมองให้เหมาะกับงาน

Model แต่ละตัวมีจุดเด่นต่างกัน บางตัวเร็วและประหยัด บางตัวคิดปัญหาซับซ้อนได้ลึกกว่า บางตัวอ่านภาพได้ดี หรือรองรับบริบทยาวกว่า

เราไม่จำเป็นต้องเรียก CTO มาช่วยเปลี่ยนชื่อไฟล์ทุกครั้ง งานจัดรูปแบบข้อมูล 20 แถวอาจใช้ model ที่เร็วและประหยัด ส่วนงานออกแบบการย้ายข้อมูลที่มีผลกับระบบเดิมอาจต้องใช้ model ที่คิดรอบคอบกว่า

ก่อนเลือก model ลองถามสามเรื่อง

• งานต้องใช้การคิดหลายชั้นแค่ไหน
• ต้องการผลเร็วเพียงใด
• ความผิดพลาดมีต้นทุนสูงแค่ไหน

คำว่า “model ที่ดีที่สุด” จึงไม่มีคำตอบเดียว มีเพียง model ที่เหมาะกับงานนี้ ภายใต้เวลา งบ และระดับความเสี่ยงที่เรารับได้

4.2 Context แผนที่ของโลกที่ AI กำลังทำงานอยู่

Context คือข้อมูลที่ช่วยให้ AI เข้าใจสถานการณ์ เช่น ลูกค้าคือใคร กฎธุรกิจเป็นอย่างไร ระบบเดิมเก็บข้อมูลไว้ที่ไหน ทีมเคยลองอะไรแล้ว และคำว่า “เสร็จ” หมายถึงอะไร

ลองเปรียบเทียบคำสั่งสองแบบ

แบบแรก

“เพิ่ม priority ให้ Task หน่อย”

AI อาจสร้าง Low, Medium, High เพิ่ม field ใหม่ และออกแบบ UI ตามความเคยชินของมัน ทุกอย่างอาจดูดี แต่ชนกับระบบเดิมที่ใช้ P1, P2, P3

แบบที่มี Context

“เพิ่ม priority filter ให้ Task ระบบเดิมใช้ P1, P2, P3 ข้อมูลเก็บใน localStorage และผู้ใช้ต้องกรองรายการตาม priority ได้”

คราวนี้พื้นที่ให้เดาแคบลง AI มีโอกาสต่อของเดิมได้ถูกทางกว่าเดิมมาก

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

4.3 Prompt บรีฟงานที่อยู่ตรงหน้า

Prompt คือสิ่งที่เรามอบหมายในรอบนี้ เช่น “ช่วยวิเคราะห์ requirement” หรือ “เพิ่ม priority filter ตามข้อกำหนดนี้”

Prompt มีผลมาก แต่ไม่ควรแบกโลกทั้งใบไว้ในข้อความเดียว กฎที่ต้องใช้ทุกงานควรอยู่ใน Instructions ความรู้โครงการควรอยู่ในไฟล์หรือ Context ขั้นตอนประจำควรอยู่ใน Skill

นึกถึงโต๊ะทำงานในบริษัท Prompt คือโพสต์อิทที่บอกงานวันนี้ ไม่ใช่คู่มือพนักงาน ประวัติลูกค้า แปลนอาคาร และกฎความปลอดภัยทั้งหมดเขียนย่ออยู่ในกระดาษใบเดียว

4.4 Instructions กติกาที่ต้องรักษา

Instructions บอกวิธีปฏิบัติที่ควรใช้สม่ำเสมอ เช่น

• ใช้ TypeScript ในโครงการนี้
• ห้ามแก้ production configuration
• เมื่อ requirement ไม่ชัด ให้ถามก่อนลงมือ
• สร้างไฟล์เฉพาะในพื้นที่ที่กำหนด
• ก่อนบอกว่าเสร็จ ต้องรายงานวิธีตรวจ

Instructions ที่ดีควรชัดและตรวจได้ “ทำงานให้ดีที่สุด” ฟังดีแต่ตีความกว้างมาก ส่วน “อย่าแก้ไฟล์นอกโฟลเดอร์นี้” มีขอบเขตที่เห็นได้ชัด

4.5 Skill สูตรทำงานที่หยิบใช้ซ้ำได้

Skill คล้าย SOP หรือสูตรอาหาร มันไม่ได้เพิ่มมือให้ AI แต่มันบอกว่าควรใช้มือนั้นทำอะไรตามลำดับ

ตัวอย่าง Skill สำหรับ Business Analyst อาจกำหนดว่า

1. อ่านบรีฟ
2. แยกสิ่งที่รู้จริงออกจากสิ่งที่กำลังสมมติ
3. ระบุคำถามที่มีผลต่อการออกแบบระบบ
4. จำกัดคำถามไว้เฉพาะเรื่องสำคัญ
5. ร่าง acceptance criteria ที่ตรวจได้

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

แต่อย่าเข้าใจว่า Skill คือใบขับขี่ตลอดชีพ เราควรอ่านว่าใครสร้าง มันทำอะไร ใช้ไฟล์หรือ connector ไหน และเหมาะกับโจทย์จริงหรือไม่ ก่อนเปิดใช้กับงานสำคัญ

4.6 Tool ทำให้ความรู้กลายเป็นการลงมือ

Tool ตอบคำถามว่า “AI ทำอะไรได้” ส่วน Skill ตอบว่า “งานแบบนี้ควรทำอย่างไร”

Tool อาจเปิดไฟล์ได้ แต่ Skill บอกว่าควรเปิดไฟล์ไหนก่อน Tool อาจรัน test ได้ แต่ Skill บอกว่าต้องทดสอบเคสปกติและเคสขอบอะไรบ้าง

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

4.7 MCP หัวต่อระหว่าง AI กับโลกภายนอก

Model Context Protocol หรือ MCP เป็นมาตรฐานสำหรับเชื่อม AI application กับข้อมูลหรือบริการอื่นผ่านเครื่องมือที่กำหนดไว้

เปรียบเหมือนหัวต่อกลาง ถ้าอยากให้ AI อ่าน issue ใน Jira ดึงข้อมูลจากระบบเอกสาร หรือเรียกบริการบางอย่าง เราไม่จำเป็นต้องคัดลอกข้อมูลมาแปะทุกครั้ง สามารถเชื่อมผ่าน server ที่เปิดความสามารถตามที่อนุญาต

แต่การเสียบสายไม่ได้แปลว่าปลอดภัยโดยอัตโนมัติ เรายังต้องดูว่า AI มองเห็นข้อมูลอะไร เรียก action ไหนได้ และ action เสี่ยงต้องขออนุมัติก่อนหรือไม่

MCP จึงเป็น “ทางเชื่อม” ไม่ใช่ “สมอง” AI ยังต้องตีความ วางแผน และใช้เครื่องมือให้ถูกงาน

4.8 Agent ผู้เอาชิ้นส่วนทั้งหมดมาทำงานร่วมกัน

Agent รับเป้าหมาย ใช้ model เพื่อคิด ใช้ context เพื่อเข้าใจสถานการณ์ ทำตาม instructions และ skills จากนั้นเรียก tools ผ่านการเชื่อมต่อที่มีอยู่

ถ้าส่วนใดหายไป ผลก็เสียรูปได้

• Model เก่งแต่ไม่มี Context ก็เดาผิดเรื่อง
• Context ครบแต่ไม่มี Tool ก็ลงมือไม่ได้
• มี Tool แต่ไม่มี Boundary ก็อาจทำเกินขอบเขต
• มี Skill แต่เป้าหมายไม่ชัด ก็ทำตามขั้นตอนได้สวยแต่เดินผิดทิศ
• ทำครบทุกอย่างแต่ไม่มี Verification ก็ยังไม่รู้ว่างานใช้ได้จริงหรือไม่

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

เวลางานพัง อย่าเพิ่งเปลี่ยนสมอง: ลองดูก่อนว่าเราให้แผนที่ผิด ลืมวางกติกา หรือเก็บประแจไว้ในตู้ที่ AI เปิดไม่ได้หรือเปล่า

---

5. Prompt เก่งอย่างเดียว งานก็ยังพังได้

วงการ AI ช่วงแรกทำให้หลายคนรู้สึกว่า prompt คือคาถา ใครเรียงคำสวยกว่า คนนั้นได้ผลลัพธ์ดีกว่า แน่นอนว่าบรีฟที่ชัดช่วยมาก แต่คุณภาพงานไม่ได้มาจาก prompt เพียงชิ้นเดียว

ถ้า Prompt เป็นคาถาจริง เราคงเห็นคนในออฟฟิศยืนโบกไม้กายสิทธิ์หน้าจอ พร้อมตะโกนว่า “ช่วยทำ Dashboard แบบมืออาชีพ สวยงาม ใช้ง่าย และว้าว!” แล้ว Dashboard ที่เชื่อมข้อมูลถูกต้องค่อย ๆ ลอยออกมาจากจอ

น่าเสียดายที่โลกจริงยังขอชื่อ table, นิยาม metric และสิทธิ์เข้าถึงข้อมูลอยู่ดี

เรามองเป็นสมการง่าย ๆ ได้ว่า

คุณภาพงาน = Prompt + Context + Instructions + Skill + Tools + Model + Verification

สมการนี้ไม่ได้มีไว้คำนวณเป็นตัวเลข แต่ช่วยเตือนว่าอย่าโทษประโยคสั่งงานทุกครั้งที่งานพัง

ถ้า AI ตอบผิดเรื่อง อาจขาด Context

ถ้า AI รู้คำตอบแต่แก้ไฟล์ไม่ได้ อาจขาด Tool

ถ้า AI สร้าง feature เกินขอบเขต อาจขาด Instructions หรือ Boundary

ถ้า AI ทำงานเดิมแต่ลืมขั้นไม่เหมือนกันทุกครั้ง อาจต้องมี Skill

ถ้า AI บอกว่าเสร็จทั้งที่ยังเปิดไม่ได้ อาจขาด Verification

เวลาเริ่มงานหนึ่งชิ้น ลองใช้ prompt อุ่นเครื่องแบบนี้

“ช่วยฉันเริ่มงานนี้หน่อย ก่อนลงมือ คุณต้องรู้อะไรจากฉันบ้าง?”

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

เคล็ดลับคืออย่าตอบทุกคำถามแบบเทข้อมูลทั้งหมด ถ้า AI ถามว่าใครเป็นผู้ใช้ เราไม่ต้องส่ง organization chart 40 หน้า ตอบให้พอเลือกแนวทางได้ เช่น “ใช้คนเดียว ยังไม่ต้อง login”

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

เกมตามหาชิ้นส่วนที่หายไป

ครั้งหน้าเมื่อ AI ทำงานไม่ตรงใจ ลองหยุดก่อนพิมพ์ prompt ใหม่ยาวกว่าเดิม แล้วถามว่าอะไรหายไป

• ตอบคนละเรื่อง อาจขาด Context
• ทำได้แค่แนะนำ อาจขาด Tool
• ทำเกินโจทย์ อาจขาด Boundary
• ลืมขั้นเดิมซ้ำ ๆ อาจขาด Skill
• บอกว่าเสร็จแต่ไม่มีหลักฐาน อาจขาด Verification

การวินิจฉัยถูกจุดช่วยได้มากกว่าการเติมคำว่า “กรุณาตรวจสอบอย่างละเอียด รอบคอบ และเป็นมืออาชีพ” ต่อท้ายทุก prompt

---

6. จาก Chat สู่ Agent วงรอบงานที่คนยังต้องถือพวงมาลัย

ถ้า Chat คือการถามเพื่อนข้างโต๊ะว่า “เรื่องนี้ทำยังไงดี” Agent คือการส่งกุญแจห้องทำงานให้ พร้อมบอกว่า “ลองจัดการส่วนนี้ให้หน่อย เสร็จแล้วเอาหลักฐานมาให้ดู”

คำว่า “ส่งกุญแจ” ฟังแล้วก็ควรทำให้เรานั่งตัวตรงขึ้นมานิดหนึ่ง เพราะเมื่อ AI ลงมือได้จริง ความสะดวกกับความเสี่ยงจะเดินเข้าห้องมาพร้อมกัน

Chat เหมาะกับงานที่ต้องการความคิด คำอธิบาย หรือร่างเริ่มต้น เราถาม AI ตอบ แล้วคนทำขั้นต่อไป

Agentic Workflow เหมาะกับงานหลายขั้นที่มีเป้าหมายและขอบเขตชัด เรามอบหมายเป้าหมาย Agent เสนอแผน ใช้ Tool ดูผล แล้วตรวจสิ่งที่ทำ

วงรอบพื้นฐานมักมีหน้าตาประมาณนี้

1. Goal รับเป้าหมายและเกณฑ์สำเร็จ
2. Plan แบ่งงานเป็นขั้นและเลือกเครื่องมือ
3. Act ลงมือทำ
4. Observe อ่านผลลัพธ์ error หรือสถานะที่เกิดขึ้น
5. Verify ตรวจว่าผลตรงกับเป้าหมายหรือไม่

จากนั้นอาจวนกลับไป Plan หรือ Act ถ้ายังไม่ผ่าน

วงรอบนี้คล้ายการทำอาหารจากสูตร เราไม่ได้อ่านสูตรรวดเดียวแล้วหลับตาปรุงจนจบ เราหั่น ชิม ปรับไฟ แล้วชิมอีกครั้ง การ Observe และ Verify ทำให้ Agent ไม่ใช่เครื่องยิงคำตอบครั้งเดียว

AI รับผิดชอบอะไร

AI ช่วยวิเคราะห์งาน เสนอแผน ลงมือด้วยเครื่องมือที่ได้รับ และรายงานผลพร้อมหลักฐานได้

คนรับผิดชอบอะไร

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

คำว่า Human in the Loop ไม่ได้แปลว่าคนต้องนั่งจ้องทุกตัวอักษรที่ AI พิมพ์ มันหมายถึงการวางคนไว้ตรงจุดที่การตัดสินใจมีความหมาย

ตัวอย่างเช่น AI อาจแก้ CSS และเปิด screenshot ให้ดูได้เอง แต่ถ้าจะลบข้อมูลผู้ใช้ ย้าย schema หรือ deploy production ควรมีจุดให้คนตรวจและอนุมัติ

เราอยากได้ระบบที่ AI ช่วยแบกแรงงาน แต่คนยังถือพวงมาลัยตรงทางแยกสำคัญ

AI ไม่เมื่อย แต่คนยังต้องรู้ว่าจะไปไหน: การปล่อยให้ Agent วิ่งเร็วโดยไม่มี Goal และ Checkpoint ก็เหมือนเปิด cruise control ตอนยังไม่ได้เลือกถนน

---

7. จัดโต๊ะทำงานให้ AI ก่อนปล่อยลงมือ

เมื่อจะใช้ AI ทำงานกับไฟล์จริง อย่าเริ่มด้วยการเปิดประตูทุกห้อง ลองจัดพื้นที่เหมือนเตรียมโต๊ะให้พนักงานใหม่

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

เลือกโฟลเดอร์งานให้ชัด

วางไฟล์ที่เกี่ยวข้องไว้ในโฟลเดอร์โครงการ แล้วให้ AI ทำงานเฉพาะพื้นที่นั้น วิธีนี้ช่วยทั้งเรื่องความเป็นระเบียบและความปลอดภัย

สำหรับ workshop Task App เราเริ่มจากโฟลเดอร์ประมาณนี้

task-app/
└── brief.md

จากนั้นไฟล์จะค่อย ๆ เพิ่มตามการตัดสินใจ

task-app/
├── brief.md
├── requirements.md
├── plan.md
├── design.md
├── index.html
└── test-cases.md

โครงแบบนี้มีข้อดีคือทุกบทบาทส่งงานต่อผ่านหลักฐานที่จับต้องได้ BA ไม่ได้ทิ้ง requirement ไว้ในความจำของแชตอย่างเดียว SA อ่านไฟล์ที่ตกลงแล้ว UX อ้างอิงแผน และ Developer สร้างจากสิ่งที่ทีมทบทวนมา

เขียนกติกาพื้นฐาน

ก่อนลงมือ เราอาจบอก AI ว่า

• ถ้าโจทย์ไม่ชัด ให้ถามก่อน
• สร้างไฟล์เฉพาะในโฟลเดอร์นี้
• อย่าเพิ่ม package หรือ server ถ้าโจทย์ยังไม่ต้องใช้
• ก่อนสรุปว่าเสร็จ ให้บอกว่าเปิดไฟล์ไหนและตรวจอะไร

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

หา Skill ที่มีอยู่ก่อนสร้างใหม่

ถ้าเครื่องมือมีรายการ Skills ให้ลองค้นดูก่อนว่า workflow ที่ต้องการมีอยู่แล้วหรือไม่ เช่น review requirement, ออกแบบเอกสาร หรือสร้าง test cases

ก่อนใช้ Skill ให้ตรวจสี่เรื่อง

1. ใครเป็นผู้สร้าง
2. มันกำหนดขั้นตอนอะไร
3. มันเข้าถึงไฟล์หรือ connector ตัวไหน
4. ผลลัพธ์เหมาะกับงานของเราหรือไม่

Skill เป็นคู่มือให้ AI ทำงาน การดาวน์โหลดคู่มือหนา 200 หน้าแล้วโยนให้พนักงานทันทีคงไม่ใช่วิธี onboarding ที่ดี เราควรเปิดอ่านสารบัญและดูว่ามันกำลังพาเราไปไหน

ถ้ายังไม่มี Skill ที่ตรงงาน ไม่ต้องหยุดทุกอย่าง เราสามารถทำงานด้วย prompt ปกติก่อน เมื่อเห็นขั้นตอนที่ใช้ซ้ำจริงค่อยสกัดออกมาเป็น Skill

Skill ที่น่าทำมักตอบได้สามข้อ

• ใช้เมื่อไร
• ทำอะไรตามลำดับ
• ส่งผลลัพธ์อะไรกลับมา

ยกตัวอย่าง Skill review requirement

ใช้เมื่อได้รับบรีฟที่ยังไม่ชัด แยกข้อเท็จจริงออกจาก assumption ระบุคำถามที่เปลี่ยนการออกแบบ และส่งคำถามสำคัญพร้อมเกณฑ์ตรวจงานกลับมา

นี่ชัดกว่าการเขียนว่า “ช่วยทำ requirement ให้ดี” เพราะทั้งคนและ AI รู้ว่าต้องทำอะไรและรอรับอะไร

ตรวจสิทธิ์ของ Tools

ให้ AI เข้าถึงเฉพาะสิ่งที่จำเป็นกับงาน ถ้า brief อยู่ในไฟล์ local ก็ยังไม่ต้องเชื่อม Jira จริง ถ้าต้องเปิด index.html ก็ให้ Browser เข้าถึงหน้าแอป ไม่จำเป็นต้องเชื่อมระบบอื่นที่ไม่มีส่วนเกี่ยวข้อง

ก่อนเริ่มงานจริง ลองเช็กสั้น ๆ

• เลือกโฟลเดอร์ถูกหรือยัง
• AI อ่าน brief.md ได้หรือไม่
• เครื่องมือที่ขอสิทธิ์เกี่ยวกับงานจริงหรือเปล่า
• เป้าหมายสุดท้ายชัดหรือยัง
• จุดไหนต้องให้คนอนุมัติ

ห้านาทีตรงนี้อาจช่วยประหยัดเวลาตามแก้ของที่สร้างผิดทางไปหลายชั่วโมง

ก่อนกดเริ่ม: เช็กโต๊ะ เช็กกติกา เช็กกุญแจ และเช็กว่าเรารอรับงานหน้าตาแบบไหน

---

8. Workshop สร้าง Task App ตั้งแต่บรีฟหนึ่งบรรทัดจนเปิดใช้ได้

เพื่อเห็นภาพการทำงานร่วมกับ AI แบบครบวงจร ลองใช้โจทย์เดียวเดินผ่านบทบาท BA, SA, UX, Developer และ Tester

ช่วงนี้ให้นึกว่าเรากำลังเล่นเกมส่งไม้ต่อ แต่ไม้ต่อของเราเป็นไฟล์ Markdown แต่ละบทบาทต้องส่งของที่ชัดพอให้คนถัดไปวิ่งต่อได้ ถ้า BA ส่งความกำกวมให้ SA, SA จะส่งแผนที่แกว่งให้ UX แล้ว Developer จะได้รับของขวัญชิ้นใหญ่ชื่อว่า “ช่วยเดาเองนะ”

โจทย์ตั้งต้นมีเพียงประโยคเดียว

“ทีมเราอยากได้ Task Management App เล็ก ๆ ใช้ใน browser”

อ่านแล้วดูเหมือนพร้อมสร้าง แต่จริง ๆ ยังมีหลุมอยู่เต็มพื้น

• ใครเป็นผู้ใช้
• ต้อง login หรือไม่
• Task มีข้อมูลอะไร
• สถานะมีกี่แบบ
• ข้อมูลเก็บที่ไหน
• ปิด browser แล้วข้อมูลต้องอยู่หรือไม่
• ต้องเพิ่ม แก้ ลบ กรอง หรือค้นหาได้แค่ไหน

ถ้าเราสั่ง “ทำเลย” AI จะเติมช่องว่างเหล่านี้ด้วย assumption ของมัน บาง assumption อาจดี บางอันอาจพาเราไปสร้างระบบ login และ database ทั้งที่ workshop มีเวลาไม่ถึงชั่วโมง

วิธีที่ดีกว่าคือเล่นทีละบทบาท แล้วให้แต่ละช่วงสร้างไฟล์ส่งต่อให้ช่วงถัดไป

ก่อนเริ่ม ลองทายเล่น ๆ ว่า ถ้าเราพิมพ์แค่ “ทำ Task App ให้หน่อย” AI จะเพิ่มอะไรมาให้โดยไม่ได้ขอ Login? Dashboard? Dark mode? ปุ่มลบสีแดงที่เด่นกว่าปุ่มสร้าง? การเดานี้สนุกในห้องเรียน แต่แพงขึ้นทันทีเมื่อเกิดในโครงการจริง

ขั้นที่ 1: BA ทำให้โจทย์ชัดพอที่จะตัดสินใจ

BA ในขั้นนี้ทำหน้าที่เหมือนนักสืบ เขาไม่ได้รีบจับผู้ร้ายคนแรกที่เดินผ่าน แต่พยายามแยกว่าอะไรคือหลักฐาน อะไรคือคำบอกเล่า และอะไรคือเรื่องที่ทุกคนพยักหน้าตามกันทั้งที่ยังไม่มีใครตกลง

เริ่มด้วยการห้าม AI รีบสร้างของ

อ่าน brief.md แล้วช่วยทำตัวเป็น BA
อย่าเพิ่งสร้างแอป
บอกว่าคุณเข้าใจโจทย์อย่างไร
และมีคำถามสำคัญอะไรที่ต้องถามฉันก่อน

คำว่า “คำถามสำคัญ” มีความหมาย เราไม่ต้องการแบบสอบสวน 47 ข้อ เราต้องการคำถามที่คำตอบจะเปลี่ยนหน้าตา โครงสร้าง หรือขอบเขตของระบบ

ตัวอย่างคำถามที่มีประโยชน์

• แอปนี้ใช้คนเดียวหรือหลายคน
• ต้องมีบัญชีผู้ใช้หรือไม่
• Task ต้องเก็บข้อมูลอะไรบ้าง
• ผู้ใช้ต้องการสถานะและ priority แบบไหน
• ข้อมูลต้องอยู่หลัง refresh หรือไม่
• ต้องมีการกรองหรือค้นหาหรือเปล่า

เมื่อได้คำตอบแล้ว ให้ AI เขียนเป็น requirements.md พร้อมแยกสิ่งที่ตกลงแล้วออกจากสิ่งที่ยังสมมติ

จากคำถามเมื่อกี้ เราตกลงกันว่า:
[ใส่คำตอบของคุณ]

ช่วยสรุปเป็น requirements.md ในโฟลเดอร์นี้
แยกสิ่งที่ตกลงแล้วกับสิ่งที่ยังสมมติไว้

สำหรับตัวอย่างนี้ เราอาจกำหนดกติกากลางดังนี้

• มีผู้ใช้คนเดียวและยังไม่ต้อง login
• Task มีชื่อ รายละเอียด วันที่สร้าง Priority และ Status
• Priority ใช้ P1, P2, P3
• Status ใช้ To do, Doing, Done
• ข้อมูลเก็บใน browser และยังอยู่หลังเปิดใหม่
• ผู้ใช้เพิ่ม แก้ เปลี่ยนสถานะ และกรองรายการได้

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

ขั้นที่ 2: SA ลดความฝันให้พอดีกับเวลาและเครื่องมือ

ถ้า BA ช่วยตอบว่า “เราจะสร้างอะไร” SA ช่วยตอบว่า “เราจะสร้างมันโดยไม่ทำให้ทีมต้องนอนที่ออฟฟิศได้อย่างไร”

เมื่อ Requirement ชัดขึ้น ให้ AI เปลี่ยนบทบาทเป็น System Analyst

อ่าน requirements.md ที่เพิ่งเขียน
ช่วยวางแผนทำแอปแบบง่ายที่สุด
เปิดได้ด้วย index.html ไฟล์เดียว
ไม่ใช้ package หรือ server
บอกด้วยว่าข้อมูลจะเก็บอย่างไร
เขียนแผนไว้ใน plan.md
ยังไม่ต้องสร้างแอป

ข้อกำหนด “ยังไม่ต้องสร้างแอป” ช่วยให้เรามีจุดตรวจแผนก่อนเสียเวลาเขียนโค้ด

เปิด plan.md แล้วถามว่า

• แผนตรงกับ requirements.md หรือไม่
• AI แอบเพิ่ม login, database หรือ framework เข้ามาหรือเปล่า
• ไฟล์เปิดด้วย browser ได้ทันทีจริงไหม
• ข้อมูลจะอยู่หลัง refresh ด้วยวิธีไหน
• โครงสร้างง่ายพอให้ตรวจและแก้ในเวลาที่มีหรือไม่

ถ้าแผนหลุด แก้ตอนนี้ง่ายกว่าแก้หลังโค้ดโต ลองนึกถึงการย้ายผนังบนแบบแปลน เทียบกับการทุบผนังหลังช่างติดแอร์แล้ว ค่าใช้จ่ายต่างกันคนละเรื่อง

ขั้นที่ 3: UX ทำให้สิ่งที่สร้างได้ กลายเป็นสิ่งที่ใช้เป็น

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

Requirement และ Plan บอกว่าระบบต้องทำอะไร แต่ยังไม่ตอบว่าผู้ใช้จะพบและเข้าใจความสามารถเหล่านั้นอย่างไร

ให้ AI ช่วยวาง UX ก่อนเขียนโค้ด

ใช้ requirements.md กับ plan.md
ช่วยออกแบบหน้าจอ Task App หนึ่งหน้า
อธิบายตำแหน่งปุ่มเพิ่ม Task วิธีแก้ไข
การเปลี่ยน priority และ status รวมถึงการกรอง
เขียนไว้ใน design.md ก่อน
ยังไม่ต้องเขียนแอป

จากนั้นลองสวมบทผู้ใช้ที่เพิ่งเปิดแอปครั้งแรก

• มองออกไหมว่าต้องกดตรงไหนเพื่อเพิ่ม Task
• เพิ่มแล้วเห็นผลทันทีหรือไม่
• การเปลี่ยน Done กับการลบต่างกันชัดไหม
• Status และ Priority อ่านง่ายหรือเปล่า
• Filter บอกหรือไม่ว่าตอนนี้กำลังซ่อนรายการอะไรอยู่
• ถ้าไม่มี Task เลย หน้าจอช่วยบอกขั้นต่อไปหรือไม่

UX review ไม่จำเป็นต้องได้หน้าตาเหมือนตัวอย่าง ทุกทีมอาจออกแบบต่างกัน แต่ผู้ใช้ควรรู้ว่ากดอะไรแล้วจะเกิดอะไร

ขั้นที่ 4: Developer ให้ AI สร้างไฟล์จริง

ถึงเวลาที่ความคิดบนกระดาษต้องลงไปเจอกับโลกแห่งวงเล็บปีกกา ชื่อตัวแปร และ error ที่โผล่มาตอนเรามั่นใจที่สุด

ตอนนี้เรามี Requirement, Plan และ Design ที่ตรวจมาแล้ว จึงค่อยให้ AI ลงมือ

อ่าน requirements.md, plan.md และ design.md
ช่วยสร้าง Task App เป็น index.html ไฟล์เดียว
ใช้ HTML, CSS และ JavaScript ธรรมดา
เก็บข้อมูลใน browser และเปิดใช้ได้ทันที
ทำเสร็จบอกฉันว่าเปิดไฟล์ไหนและลองอะไร

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

หลังได้ index.html อย่าเพิ่งฉลองจากประโยค “เสร็จแล้ว” ให้เปิดไฟล์จริงและลองอย่างน้อยสี่อย่าง

1. เพิ่ม Task ใหม่
2. เปลี่ยน Priority และ Status
3. กด refresh แล้วดูว่าข้อมูลยังอยู่หรือไม่
4. ใช้ตัวกรองแล้วดูว่ารายการถูกต้องหรือเปล่า

ถ้ามี Browser Tool เราอาจให้ AI ช่วยลองก่อน แต่คนควรลองซ้ำในจุดสำคัญ เพราะผู้ใช้จริงมีพรสวรรค์พิเศษในการกดสิ่งที่คนเขียนระบบไม่เคยนึกว่าจะมีใครกด

ขั้นที่ 5: Tester หาสิ่งที่วัน Demo ไม่อยากให้เจอ

Tester คือคนที่เห็นปุ่มสวย ๆ แล้วไม่ได้คิดว่า “น่ากดจัง” แต่คิดว่า “ถ้ากดติดกันสิบครั้งจะเกิดอะไรขึ้น” ทีมที่มีคนคิดแบบนี้ควรรักษาไว้ให้ดี

ให้ AI อ่าน Requirement แล้วสร้าง test cases ที่ตรวจได้

อ่าน requirements.md
ออก test cases สำหรับแอปที่เพิ่งสร้าง
รวมเคสปกติและเคสแปลก ๆ
เขียนใน test-cases.md
บอกด้วยว่าเคสไหนควรลองเองใน browser

สี่เคสเริ่มต้นที่ควรลอง

• เพิ่ม Task โดยไม่ใส่ชื่อ ระบบเตือนหรือสร้างรายการว่าง
• แก้ชื่อ Task แล้วข้อมูลใหม่ยังอยู่หลัง refresh หรือไม่
• เปลี่ยน Status แล้วเปิดใหม่ ค่ายังถูกต้องหรือไม่
• กรอง P1 แล้วเห็นเฉพาะ Task ที่เป็น P1 จริงหรือเปล่า

คำว่า “โค้ดดูแล้วน่าจะผ่าน” ไม่มีน้ำหนักเท่าการกดแล้วเห็นผล การทดสอบคือการเปลี่ยนความเชื่อให้กลายเป็นหลักฐาน

ขั้นที่ 6: รายงานบั๊กให้เหมือนคนทำงานจริง

คำว่า “มันพัง” ระบายความรู้สึกได้ดี แต่ช่วยหาบั๊กได้น้อยพอ ๆ กับการโทรหาช่างแล้วบอกว่า “รถไม่โอเค”

ถ้าพบว่าการเปลี่ยน Status หายหลัง refresh อย่าบอกเพียงว่า “มันพัง ช่วยแก้หน่อย” ให้ส่งข้อมูลที่ช่วยสืบสวน

ฉันลองเปลี่ยน status แล้วกด refresh
ค่ากลับไปเหมือนเดิม

ช่วยหาสาเหตุใน index.html แล้วแก้
ก่อนบอกว่าเสร็จ ให้ลองทำซ้ำเคสเดิม
และบอกฉันว่าตรวจอย่างไร

บั๊กที่ดีควรมีอาการ ขั้นตอนที่ทำ ผลที่คาดหวัง และถ้ามี ผลที่เกิดจริง

เมื่อ AI บอกว่าแก้แล้ว ให้ขอสามเรื่อง

• สาเหตุเกิดจากอะไร
• แก้ส่วนไหนของไฟล์
• ทดสอบซ้ำอย่างไรและได้ผลอะไร

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

สิ่งที่ได้จาก workshop นี้ไม่ใช่แค่ Task App

ปลายทางที่มองเห็นคือ index.html ที่เปิดได้ มีข้อมูลอยู่หลัง refresh และมี test-cases.md บันทึกสิ่งที่ผ่านหรือยังค้าง

แต่สิ่งที่สำคัญกว่าคือเราเห็นสายพานงานทั้งเส้น

• BA ลดความกำกวม
• SA เลือกแผนที่สร้างได้จริง
• UX ทำให้คนใช้เข้าใจ
• Developer สร้างชิ้นงาน
• Tester หาหลักฐานว่างานทำงานตามที่ตกลง

AI ช่วยได้ทุกช่วง แต่บทบาทของคนยังเปลี่ยนการตัดสินใจไปตลอดทาง

ชัยชนะของ workshop นี้: ไม่ใช่ทุกคนได้แอปหน้าตาเหมือนกัน แต่ทุกคนอธิบายได้ว่าเลือกอะไร เพราะอะไร และตรวจตรงไหนแล้ว

---

9. AI เป็นเครื่องมือของทุกบทบาท ไม่ได้อยู่แค่โต๊ะ Developer

ภาพจำว่า AI เป็นเรื่องของคนเขียนโค้ดทำให้หลายทีมพลาดโอกาส เพราะงานจำนวนมากก่อนและหลังการเขียนโค้ดก็อาศัยภาษา ข้อมูล การวิเคราะห์ และการตรวจสอบ

ถ้า AI เดินเข้าบริษัทแล้วตรงไปนั่งข้าง Developer เพียงโต๊ะเดียว ฝั่ง BA, UX, Tester และทีมข้อมูลมีสิทธิ์ลุกขึ้นถามพร้อมกันว่า “แล้วเอกสารกองนี้ใครจะช่วยอ่าน?”

Business Analyst

AI ช่วยอ่านบรีฟ แยกข้อเท็จจริงจาก assumption หาเรื่องที่ยังไม่ชัด และร่าง acceptance criteria ได้ BA ใช้เวลาน้อยลงกับการเริ่มเอกสาร และมีเวลาเพิ่มสำหรับการคุยกับผู้ใช้และตัดสินใจเรื่องที่มีผลจริง

System Analyst

AI ช่วยเปรียบเทียบทางเลือก ตรวจความสอดคล้องระหว่าง Requirement กับ Plan ชี้ dependency หรือ edge case และช่วยอธิบายผลกระทบของแนวทางต่าง ๆ

UX/UI Designer

AI ช่วยแตก user flow ร่าง microcopy สำรวจ state ที่มักลืม เช่น empty, loading และ error รวมถึงช่วยวิจารณ์ design จากโจทย์ที่กำหนด แต่คนยังต้องตัดสินใจว่าประสบการณ์นั้นเหมาะกับผู้ใช้จริงหรือไม่

Developer

AI ช่วยอ่าน codebase แก้ feature สืบสวนบั๊ก เขียน test และอธิบาย diff ได้ ผลจะดีขึ้นมากเมื่อมีขอบเขตไฟล์ กติกาโครงการ และวิธี verify ที่ชัด

Tester

AI ช่วยแปลง Requirement เป็น test cases สำรวจเคสขอบ สร้างข้อมูลทดสอบ และเชื่อมอาการกับส่วนของระบบที่น่าสงสัย แต่ผล “ผ่าน” ต้องมาจากการรันหรือการทดลอง ไม่ใช่การอ่านแล้วเดา

Data Engineer และสายข้อมูล

AI ช่วยอ่าน schema ร่าง SQL ตรวจสมมติฐานของ query และสืบสวนความผิดปกติได้ งานประเภทนี้ยิ่งต้องระวังสิทธิ์ข้อมูล ความเป็นส่วนตัว และการตรวจผลลัพธ์ด้วยตัวเลขจริง

Cloud และ Infrastructure

AI ช่วยอ่าน log เปรียบเทียบ configuration ร่าง runbook และช่วยไล่เหตุ incident ได้ แต่การเปลี่ยนระบบจริงควรมี approval และ rollback plan ที่ชัด เพราะคำสั่งผิดหนึ่งบรรทัดอาจเสียงดังกว่าบั๊กบนหน้าเว็บมาก

ดังนั้น AI ไม่ได้เป็นเพียง Developer Tool มันเป็น Work Tool ที่เข้าไปช่วยตามธรรมชาติของงานแต่ละบทบาท

AI ไม่จำเป็นต้องแย่งเก้าอี้ใคร มันอาจเป็นเก้าอี้เสริมที่ลากไปนั่งข้างคนซึ่งกำลังเจองานหนักที่สุดในวันนั้น

---

10. กรอบทำงานที่หยิบไปใช้กับงานพรุ่งนี้ได้

เมื่อมีงานใหม่เข้ามา เราไม่จำเป็นต้องจำศัพท์ทั้งหมดพร้อมกัน ใช้กรอบห้าข้อนี้ก็พอ

ถ้าบทก่อนหน้าดูเหมือนเราเทชิ้นส่วน LEGO เต็มพื้น บทนี้คือหน้าคู่มือที่บอกว่าจะหยิบก้อนไหนก่อน

1. Define งานคืออะไร

ระบุ output ผู้ใช้ ขอบเขต และความหมายของคำว่าเสร็จ ถ้ายังตอบไม่ได้ ให้ AI ช่วยตั้งคำถามก่อน

2. Context AI ต้องรู้อะไร

ให้ข้อมูลเฉพาะที่เปลี่ยนการตัดสินใจ เช่น Requirement กฎธุรกิจ ตัวอย่างข้อมูล โครงสร้างไฟล์ หรือข้อจำกัด

3. Equip AI ต้องมีอะไร

เลือก Model, Tools และ Skills ให้เหมาะกับงาน เปิดสิทธิ์เฉพาะที่จำเป็น และบอกจุดที่ต้องขออนุมัติ

4. Delegate เรามอบหมายส่วนไหน

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

5. Verify คนต้องตรวจอะไร

กำหนดหลักฐานล่วงหน้า เช่น test output, screenshot, diff, query result หรือขั้นตอนทดลองด้วยมือ จากนั้นตรวจจุดสำคัญด้วยตัวเอง

กรอบนี้ใช้ได้กับงานหลากหลาย ตั้งแต่ร่างเอกสาร วิเคราะห์ข้อมูล ไปจนถึงแก้ระบบ ลองถามตัวเองว่า “งานที่อยากให้ AI ช่วยพรุ่งนี้คืออะไร” แล้วเดินผ่านห้าข้อนี้ทีละข้อ เราจะได้ workflow ที่ชัดกว่าการเปิดแชตแล้วหวังว่า prompt แรกจะพาไปถึงเส้นชัย

โพยติดข้างจอ: Define ให้เห็นเส้นชัย, Context ให้รู้เรื่อง, Equip ให้ลงมือได้, Delegate ให้ขอบเขตชัด และ Verify ด้วยหลักฐาน

---

11. ใช้ AI ให้คุ้ม โดยไม่เผาเครดิตเล่น

เมื่อ AI เริ่มทำงานหลายขั้น ค่าใช้จ่ายอาจเพิ่มแบบเงียบ ๆ Model ที่แพงกว่า Context ที่ยาวกว่า และวงรอบที่ลองซ้ำล้วนใช้ทรัพยากร

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

การประหยัดไม่ได้แปลว่าต้องใช้ตัวที่ถูกที่สุดทุกงาน แต่หมายถึงใช้ทรัพยากรให้พอดีกับคุณภาพที่ต้องการ

อย่าเรียก CTO มาเปลี่ยนชื่อไฟล์

งานง่าย เช่น จัดรูปแบบข้อมูล สรุปข้อความสั้น หรือเปลี่ยนชื่อซ้ำ ๆ อาจใช้ model ที่เร็วและประหยัด

งานปานกลาง เช่น ร่าง test cases จาก Requirement ที่ชัด อาจใช้ model ความสามารถทั่วไป

งานซับซ้อน เช่น ออกแบบ migration ที่กระทบข้อมูลเดิม วิเคราะห์เหตุขัดข้องหลายระบบ หรือทบทวนเรื่องความปลอดภัย อาจคุ้มค่าที่จะใช้ model ซึ่งคิดลึกกว่า

หลักเลือกง่าย ๆ คือใช้ model ที่ประหยัดที่สุดซึ่งยังทำงานนั้นได้อย่างน่าเชื่อถือ

Context เยอะไม่ได้แปลว่า Context ดี

ถ้างานคือเพิ่ม priority filter ไฟล์ที่อาจเกี่ยว ได้แก่ requirements.md, component รายการ Task, data model และ tests ที่เกี่ยวข้อง

สิ่งที่มักไม่ต้องส่งทุกครั้ง ได้แก่ node_modules, ไฟล์ build, log เก่า รูปขนาดใหญ่ หรือเอกสารคนละระบบ

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

แบ่งงานเป็นช่วง แล้วดูผลก่อนสั่งต่อ

แทนที่จะสั่งงานยาวตั้งแต่วิเคราะห์จน deploy ในครั้งเดียว ลองแบ่งเป็นช่วงที่ตรวจได้

1. อ่านและสรุปความเข้าใจ
2. เสนอแผน
3. ทำส่วนแรก
4. ตรวจผล
5. เดินหน้าต่อเมื่อทิศทางถูก

วิธีนี้ลดโอกาสที่ Agent จะใช้เวลานานสร้างของผิดทาง และทำให้คนแทรกการตัดสินใจได้ตรงจุด

ตั้ง Stop Condition ก่อน Agent เริ่มวน

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

กำหนดไว้ล่วงหน้าว่า ถ้าล้มเหลวซ้ำกี่ครั้งให้หยุด ต้องเก็บหลักฐานอะไร และคำถามไหนต้องส่งกลับมาหาคน

ตัวอย่าง

“ถ้าทดสอบไม่ผ่านหลังแก้สองรอบ ให้หยุด สรุปสิ่งที่ลอง แนบ error ล่าสุด และบอกว่าต้องการการตัดสินใจเรื่องใด”

Stop Condition ที่ดีประกอบด้วยขอบเขตชัด วิธีตรวจชัด และ Human Checkpoint ที่มาในเวลาพอดี

แบบฟอร์มสั้น ๆ ก่อนเริ่มงานที่มีงบจำกัด

งาน:
Model ที่จะใช้:
Context ที่จำเป็น:
Tools ที่อนุญาต:
ขั้นตอนหลัก:
จุดหยุด:
หลักฐานที่ต้องส่ง:
จุดที่คนต้องตรวจ:

แบบฟอร์มนี้ใช้เวลาไม่กี่นาที แต่ช่วยป้องกัน Agent หลงป่าแล้วส่งใบเสร็จค่าเดินทางกลับมาให้เราทีหลัง

ประหยัดแบบมีสติ: ลดของที่ไม่เกี่ยว แบ่งงานให้ตรวจได้ และใช้ model ให้พอดี อย่าประหยัดด้วยการตัด Verification เพราะค่าตามแก้งานผิดมักแพงกว่าเครดิตที่เหลือ

---

12. หลักฐานสำคัญกว่าคำว่า “เสร็จแล้ว”

AI สื่อสารคล่องจนบางครั้งประโยคสรุปฟังมั่นใจกว่าความจริง “แก้ไขเรียบร้อยแล้ว” เป็นข้อความ ไม่ใช่หลักฐาน

คำว่า “เรียบร้อยครับ” จาก AI ให้ความรู้สึกอบอุ่นพอ ๆ กับพนักงานโรงแรมบอกว่าห้องพร้อมแล้ว แต่ก่อนทิ้งตัวลงบนเตียง เราก็ควรเปิดประตูดูสักนิดว่าห้องนั้นมีเตียงจริงหรือเปล่า

หลักฐานควรสอดคล้องกับประเภทงาน

• งานโค้ดใช้ผล test, diff และพฤติกรรมจากการเปิดแอป
• งานข้อมูลใช้ query result จำนวนแถว และการตรวจตัวอย่างข้อมูล
• งานเอกสารใช้การเทียบกับ Requirement และการตรวจความครบถ้วน
• งานออกแบบใช้ user flow, state สำคัญ และการทดลองกับสถานการณ์จริง
• งานระบบใช้ log, health check และแผนย้อนกลับเมื่อเกิดปัญหา

ก่อนมอบหมาย ลองบอก AI ล่วงหน้าว่าต้องส่งหลักฐานอะไร วิธีนี้ดีกว่ารอให้งานเสร็จแล้วค่อยถาม เพราะมันทำให้ Agent วางแผนเก็บหลักฐานระหว่างทำ

ตัวอย่างคำสั่งที่มีประโยชน์

“ก่อนสรุปว่าเสร็จ ให้รัน test ที่เกี่ยวข้อง รายงานผล และบอกไฟล์ที่เปลี่ยน ถ้ารันไม่ได้ให้บอกตรง ๆ พร้อมเหตุผล”

ประโยคท้ายสำคัญมาก เราต้องเปิดพื้นที่ให้ AI รายงานว่า “ตรวจไม่ได้” แทนที่จะผลักให้มันแต่งคำตอบที่ฟังเหมือนตรวจแล้ว

ความไว้ใจที่ดีกับ AI ไม่ได้เกิดจากการเชื่อทุกอย่าง หรือระแวงทุกบรรทัด มันเกิดจาก workflow ที่ทำให้เรามองเห็นว่ามันรู้อะไร ทำอะไร และตรวจอย่างไร

ความไว้ใจที่ตรวจสอบได้: ฟังสรุป อ่านหลักฐาน ลองจุดสำคัญ แล้วค่อยรับงาน

---

สรุป เพื่อนร่วมทีม AI ที่เก่งยังต้องการทีมที่ทำงานเป็น

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

ย้อนกลับไปที่เช้าวันจันทร์เวลา 9:07 น. กาแฟแก้วเดิมอาจยังไม่ช่วยให้ Inbox ว่าง แต่แทนที่จะขอให้ AI สรุปกองงานแล้วรับทุกอย่างกลับมาแบกต่อ เราอาจเลือกงานหนึ่งชิ้น จัด Context เปิด Tool ที่จำเป็น และมอบหมายให้มันเดินงานบางช่วงพร้อมหลักฐาน

บ่ายวันนั้นอาจยังยุ่งเหมือนเดิม เพียงแต่ครั้งนี้เรามีเพื่อนช่วยถือกล่อง ไม่ใช่มีคนยืนข้าง ๆ แล้วอธิบายว่ากล่องหนักเพราะอะไร

ถ้าอยากให้ AI ทำงานได้ดี ลองเลิกถามเพียงว่า “ต้องเขียน prompt ยังไง” แล้วเพิ่มคำถามเหล่านี้เข้าไป

• เป้าหมายชัดพอหรือยัง
• Context ชิ้นไหนช่วยให้ตัดสินใจถูก
• กติกาและข้อห้ามอยู่ที่ไหน
• ต้องใช้ Skill หรือ Tool อะไร
• AI ทำเองได้ถึงจุดใด
• จุดไหนต้องให้คนตัดสินใจ
• หลักฐานแบบไหนยืนยันว่างานเสร็จจริง

AI อาจช่วยพายเรือได้เร็วมาก แต่เรายังต้องบอกว่าจะไปฝั่งไหน ดูแผนที่ และเช็กว่าข้างหน้ามีก้อนหินหรือไม่

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

เมื่อทำแบบนี้ เราจะไม่ได้เพียงคำตอบที่ดูดีขึ้น แต่จะเริ่มได้ workflow ที่คนกับ AI ช่วยกันพางานไปถึงเส้นชัยจริง ๆ