สรุปจากคลิป ดูคลิปต้นฉบับ

AI Coding For Real Engineers: วิธีใช้ AI ทำงานจริงแบบไม่หลงทาง

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

นี่คือประเด็นหลักจาก workshop ของ Matt Pocock บนช่อง AI Engineer ที่พูดเรื่อง AI-assisted development แบบลงมือทำจริง ตั้งแต่รับ requirement ที่คลุมเครือ ไปจนถึงให้ agent ลงมือเขียนโค้ดแบบอัตโนมัติ สิ่งที่น่าสนใจคือแม้เนื้อหาจะมาจากโลกวิศวกรรมซอฟต์แวร์ แต่วิธีคิดหลายอย่างกลับใช้ได้ตรงกับเจ้าของธุรกิจและคนทำงานไทยที่อยากเอา AI ไปใช้ในงานจริง

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

สารบัญ

• Step 1: เริ่มจากความจริงข้อแรกว่า AI มีทั้งช่วงฉลาดและช่วงหลุด
• Step 2: อย่ารีบให้ AI วางแผน ให้มัน “ถามกลับ” ก่อน
• Step 3: เปลี่ยนบทสนทนาให้เป็นเอกสารปลายทาง ไม่ใช่สเปกที่ตัดขาดจากของจริง
• Step 4: แตกงานเป็น vertical slices แทนการทำทีละชั้น
• Step 5: สร้าง Kanban board ที่ AI หยิบงานไปทำต่อได้เอง
• Step 6: ค่อยปล่อยให้ AI ทำงานเองตอนที่งานพร้อมจริงแล้วเท่านั้น
• Step 7: ถ้าจะให้ AI ทำงานต่อเอง ต้องมี feedback loops ที่เข้มพอ
• Step 8: โค้ดหรือระบบที่ดีสำหรับ AI ต้องเป็นระบบที่คนก็เข้าใจง่ายเช่นกัน
• Step 9: อย่าเผลอเก็บเอกสารเก่าไว้จนกลายเป็นภาระของ AI
• Actionable Insights
• Troubleshooting
• การต่อยอด
• สรุป Checklist ทั้งหมด

Step 1: เริ่มจากความจริงข้อแรกว่า AI มีทั้งช่วงฉลาดและช่วงหลุด

Matt เสนอภาพที่เข้าใจง่ายมาก เขาเรียกมันว่า smart zone กับ dumb zone ของ LLM ยิ่งใส่ข้อมูลยาวขึ้น context ยาวขึ้น งานซับซ้อนขึ้น โมเดลจะยิ่งตัดสินใจพลาดง่ายขึ้น แม้ model รุ่นใหม่จะมี context window ใหญ่ขึ้น แต่ไม่ได้แปลว่าคุณภาพการคิดจะคงเดิมตลอดทั้งหน้าต่างนั้น

สำหรับคนทำธุรกิจ นี่คือบทเรียนสำคัญมาก เพราะหลายทีมชอบใช้ AI แบบ “โยนทุกอย่างเข้าไปทีเดียว” เช่น เอา brief ทั้งบริษัท แผนการตลาด ข้อมูลลูกค้า competitor pricing และขอให้ AI สรุปกลยุทธ์พร้อม execution plan ในคำสั่งเดียว แบบนี้มักได้คำตอบที่ดูครบ แต่ไม่คม และนำไปใช้ต่อยาก

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

• จาก “ช่วยวางแผนเพิ่มยอดขาย” เปลี่ยนเป็น “ช่วยตั้งสมมติฐาน 5 ข้อว่าทำไมลูกค้าหลุดในขั้น checkout”
• จาก “ช่วยทำแคมเปญ retention” เปลี่ยนเป็น “ช่วยออกแบบระบบสะสมแต้มสำหรับลูกค้าเก่าที่ซื้อซ้ำภายใน 30 วัน”
• จาก “ช่วยทำคู่มือทีมขาย” เปลี่ยนเป็น “ช่วยสร้าง FAQ 20 ข้อที่เซลส์ใช้ตอบ objection ลูกค้า”

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

Step 2: อย่ารีบให้ AI วางแผน ให้มัน “ถามกลับ” ก่อน

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

ตัวอย่างที่ใช้ใน workshop คือ brief สั้นๆ จากลูกค้าว่า retention ของ platform คอร์สเรียนไม่ดี อยากเพิ่ม gamification ฟังดูเหมือนโจทย์ง่าย แต่พอ AI เริ่มถามกลับ คำถามจริงๆ กลับมีเยอะมาก เช่น

• แต้มได้จากพฤติกรรมไหนบ้าง
• แต้มควรถูกนับย้อนหลังหรือไม่
• ระบบ level ควรขึ้นแบบไหน
• UI ของ gamification ควรไปอยู่จุดใด
• streak กับ points ควรสัมพันธ์กันหรือแยกกัน

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

ถ้าเอาไปใช้กับธุรกิจไทย เราสามารถดัดแนวคิดนี้ได้กับหลายงาน เช่น

• การออกโปรโมชันใหม่ ให้ AI ไล่ถามจนรู้ว่ากลุ่มเป้าหมายคือใคร กำไรต่อออเดอร์รับได้แค่ไหน และอยากเพิ่มยอดระยะสั้นหรือซื้อซ้ำ
• การทำ SOP ทีมบริการ ให้ AI ถามกลับว่าปัญหาหลักคือ response time, คุณภาพคำตอบ หรือการส่งต่องาน
• การทำแผนคอนเทนต์ ให้ AI ถามว่าต้องการ lead, awareness หรือ conversion กันแน่

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

Step 3: เปลี่ยนบทสนทนาให้เป็นเอกสารปลายทาง ไม่ใช่สเปกที่ตัดขาดจากของจริง

หลังจากซักจนเข้าใจกันแล้ว Matt จึงให้ AI สรุปออกมาเป็น PRD หรือ Product Requirements Document โดยเอกสารนี้มีไว้เพื่อบอกว่า “ปลายทางคืออะไร” ไม่ใช่เพื่อแทนความเข้าใจทั้งหมดของทีม

ใน workshop เขาเน้นจุดที่น่าสนใจมาก คือไม่ควรยึดติดกับแนวคิด specs to code มากเกินไป หรือความเชื่อที่ว่าแค่เขียนสเปกดีๆ แล้วปล่อย AI สร้างทุกอย่างให้เองได้ เพราะในโลกจริง โค้ดหรือระบบงานจริงยังต้องถูกมอง ถูกปรับ และถูกตัดสินโดยมนุษย์

ถ้าแปลเป็นภาษาคนทำธุรกิจ PRD ก็คือเอกสารปลายทางแบบย่อที่ควรมีอย่างน้อย

• ปัญหาคืออะไร
• ทางออกที่ต้องการคืออะไร
• ใครคือผู้ใช้หรือผู้เกี่ยวข้อง
• นิยามของคำว่า “เสร็จ” คืออะไร
• อะไรบ้างที่ยังไม่ทำในรอบนี้

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

Step 4: แตกงานเป็น vertical slices แทนการทำทีละชั้น

อีกหัวใจของ workshop คือการเปลี่ยนจากแผนแบบ phase 1, phase 2, phase 3 มาเป็นงานย่อยแบบ vertical slices หรือชิ้นงานที่ตัดข้ามทุก layer ของระบบและให้ feedback ได้เร็ว

ปัญหาของการแตกงานแบบเดิมคือ AI มักทำงาน “แนวนอน” เช่น เริ่มจากฐานข้อมูลก่อน ต่อด้วย API แล้วค่อยไปหน้า interface ปัญหาคือกว่าจะรู้ว่างานใช้ได้หรือไม่ เราต้องรอจนเกือบจบ ทำให้ feedback มาช้า

แต่ถ้าแตกเป็น vertical slice งานชิ้นแรกอาจเป็น “เมื่อลูกค้าเรียนจบบทหนึ่ง ระบบเพิ่มแต้มและแสดงบน dashboard ได้” นี่คืองานที่เชื่อมครบทั้ง logic, data และสิ่งที่มองเห็นได้ ทำให้ทีมตรวจได้เร็วกว่า

ถ้าเอาไปใช้กับงานธุรกิจที่ไม่ใช่โค้ด ก็ใช้หลักเดียวกันได้ เช่น การเอา AI มาช่วยทำระบบขายหน้าร้าน

• อย่าทำทีละแผนก เช่น เริ่มจากฐานข้อมูลสินค้า แล้วไป script พนักงาน แล้วไป dashboard ผู้จัดการ
• ให้ทำเป็น slice เช่น “เมื่อลูกค้าสนใจสินค้า พนักงานถาม 3 คำถามหลัก ระบบแนะนำรุ่นที่ตรง และบันทึก lead ได้”

แบบนี้เราจะเห็นผลจริงตั้งแต่เร็ว และรู้ด้วยว่าอะไรเวิร์กหรือไม่เวิร์ก

Step 5: สร้าง Kanban board ที่ AI หยิบงานไปทำต่อได้เอง

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

สิ่งที่ Matt ชอบคือใช้ Kanban board แทน sequential plan เพราะ Kanban ทำให้งานแยกเป็นก้อนอิสระและ parallelize ได้ ถ้าแปลในโลกธุรกิจ มันคล้ายการจัดงานให้ทีมหลายคนหรือหลาย agent ทำพร้อมกัน โดยไม่ต้องรอคิวแบบเส้นตรง

ตัวอย่างการใช้กับธุรกิจไทย เช่น ถ้าเราต้องการทำ onboarding ลูกค้าใหม่ด้วย AI

• Issue 1: รวบรวมคำถาม onboarding ที่ต้องถามลูกค้า
• Issue 2: สร้าง template เอกสารสรุป requirement
• Issue 3: สร้าง email follow-up อัตโนมัติ
• Issue 4: สร้าง dashboard ติดตามสถานะลูกค้า

บางงานขึ้นต่อกัน บางงานทำพร้อมกันได้ พอจัดดี AI ก็รับช่วงต่อได้ง่ายขึ้นมาก

Step 6: ค่อยปล่อยให้ AI ทำงานเองตอนที่งานพร้อมจริงแล้วเท่านั้น

อีกประเด็นที่น่าจำคือ Matt แยกงานออกเป็น 2 ประเภท

• Human-in-the-loop tasks คือ งานที่คนต้องอยู่ในวงตัดสินใจ เช่น การตีโจทย์ การเลือก trade-off การยืนยันสิ่งที่ลูกค้าต้องการ
• AFK tasks คือ งานที่ปล่อยให้ AI ทำต่อได้เอง เช่น implementation ที่มีขอบเขตชัด มี test และมี feedback loop รองรับ

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

ตัวอย่างง่ายๆ ในองค์กรไทย

• ให้คนกำหนด positioning ของแคมเปญ
• ให้ AI แตกข้อความโฆษณาเป็นหลายเวอร์ชัน
• ให้คนเลือกมุมที่เหมาะกับแบรนด์
• ให้ AI สร้าง draft landing page หรือชุดอีเมลต่อเนื่อง

ถ้าสลับลำดับผิด เช่น ปล่อย AI ตัดสิน positioning เองตั้งแต่แรก งานมักเพี้ยนตั้งแต่ต้นน้ำ

Step 7: ถ้าจะให้ AI ทำงานต่อเอง ต้องมี feedback loops ที่เข้มพอ

ใน workshop นี้ Matt ย้ำเรื่อง TDD หรือ test-driven development หนักมาก เพราะสำหรับ agent แล้ว test ไม่ใช่แค่เรื่องคุณภาพโค้ด แต่มันคือระบบนำทาง ถ้าไม่มี test หรือ feedback loop ที่ชัด AI จะทำงานแบบเดาสุ่ม

สำหรับคนที่ไม่ใช่ developer อาจไม่จำเป็นต้องใช้ TDD ตรงตัว แต่แนวคิดนี้เอาไปใช้กับ workflow ธุรกิจได้เต็มๆ คือก่อนให้ AI ทำงาน ต้องมีระบบเช็กผลที่ชัด

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

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

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

Step 8: โค้ดหรือระบบที่ดีสำหรับ AI ต้องเป็นระบบที่คนก็เข้าใจง่ายเช่นกัน

ช่วงท้ายของ workshop มีไอเดียที่กว้างกว่าการเขียนโค้ด นั่นคือเรื่อง architecture Matt หยิบแนวคิดเรื่อง deep modules มาอธิบายว่า AI ทำงานได้ดีกับระบบที่มี interface ชัด แต่ซ่อนความซับซ้อนไว้ข้างใน

ถ้าแปลเป็นภาษาธุรกิจ มันคล้ายการออกแบบ process ให้ภายนอกดูง่าย เช่น

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

แต่ข้างในอาจมี logic ซับซ้อนพอสมควร แบบนี้ทั้งคนและ AI จะทำงานต่อได้ง่ายกว่า

สิ่งที่น่าหยิบไปใช้คือ ถ้าเราจะสร้าง AI workflow ในบริษัท อย่าทำเป็นขั้นยิบย่อยเต็มไปหมดจนไม่มีใครเห็นภาพรวม ให้รวม logic เป็นโมดูลใหญ่ที่มีหน้าที่ชัด เช่น

• โมดูลคัดกรอง lead
• โมดูลสร้างข้อเสนอราคา
• โมดูลติดตามลูกค้าหลังซื้อ

เมื่อ interface ของแต่ละส่วนชัด เราจะควบคุมคุณภาพได้ง่ายขึ้น และ AI ก็ไม่ต้องหลงกับความซับซ้อนที่กระจัดกระจาย

Step 9: อย่าเผลอเก็บเอกสารเก่าไว้จนกลายเป็นภาระของ AI

อีกข้อที่คมมากคือเรื่อง doc rot หรือเอกสารเก่าที่ค่อยๆ ไม่ตรงกับของจริง ถ้าเก็บ PRD หรือแผนงานเก่าไว้ใน repo หรือระบบความรู้โดยไม่ดูแล AI อาจหยิบของเก่ามาอ้างอิงแล้วทำงานเพี้ยน

ในโลกธุรกิจไทย ปัญหานี้เจอบ่อยมาก เช่น SOP เวอร์ชันเก่า ราคาเก่า policy เก่า หรือ promotion ที่เลิกใช้ไปแล้ว แต่ยังอยู่ใน Google Drive และ AI ไปหยิบมาใช้ต่อ ผลคือพนักงานใหม่สับสน ลูกค้าได้รับข้อมูลผิด และทีมเสียเวลาตามแก้

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

Actionable Insights

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

Troubleshooting

ปัญหา: AI ตอบเร็ว แต่คำตอบไม่ค่อยตรงงาน

สาเหตุ: โจทย์ตั้งต้นกว้างเกินไป และไม่มีการซัก requirement

วิธีแก้: ให้ AI ถามกลับทีละข้อก่อนเริ่มงาน สรุปคำตอบ แล้วค่อยให้สร้างแผนหรือ draft

ปัญหา: AI ทำงานต่อเนื่องได้พักหนึ่งแล้วเริ่มหลุด

สาเหตุ: context ยาวเกินจนเข้า dumb zone

วิธีแก้: เคลียร์ session บ่อยขึ้น แยกงานเป็นรอบสั้น และสรุปเฉพาะสิ่งจำเป็นจริงๆ

ปัญหา: ได้ output เยอะ แต่ตรวจแล้วต้องแก้แทบทั้งหมด

สาเหตุ: ไม่มี feedback loop หรือ checklist ที่ชัดพอ

วิธีแก้: ตั้งเกณฑ์ผ่านก่อนให้ AI ลงมือ เช่น รูปแบบภาษา ข้อจำกัดแบรนด์ ตัวเลขที่ต้องตรง และขั้นตอนส่งต่อเมื่อไม่มั่นใจ

ปัญหา: ทีมเริ่มงงว่า AI อ้างอิงข้อมูลจากไหน

สาเหตุ: มีเอกสารเก่าเยอะ และไม่มีสถานะว่าฉบับไหนใช้จริง

วิธีแก้: จัดคลังความรู้ใหม่ แยก active, archived, deprecated ให้ชัด และให้ AI เข้าถึงเฉพาะแหล่งที่ผ่านการคัดแล้ว

ปัญหา: ใช้ AI แล้วเร็วขึ้น แต่ทีมไม่เห็นภาพรวมของระบบงานแล้ว

สาเหตุ: ปล่อยให้ AI สร้างรายละเอียดเองมากเกินไป โดยไม่มีการออกแบบโครงก่อน

วิธีแก้: ให้คนออกแบบโมดูลหรือขั้นตอนหลักก่อน แล้วค่อยให้ AI ไปจัดการรายละเอียดภายในแต่ละส่วน

การต่อยอด

• สร้าง “Grill Me prompt” ฉบับบริษัท สำหรับใช้รับ brief งานการตลาด งานขาย และงานบริการให้เหมือนกันทั้งทีม
• ทำ Kanban board สำหรับงานที่ AI ช่วยได้ เช่น content production, proposal generation, customer support macro และให้แต่ละงานมีสถานะพร้อมตรวจ
• เริ่มจาก 1 workflow ที่มีผลกับรายได้ชัด เช่น lead qualification หรือ onboarding ลูกค้า แล้วค่อยขยายไปส่วนอื่น

สรุป Checklist ทั้งหมด

• ☐ ระบุเป้าหมายของงานให้ชัดว่าอยากได้ผลลัพธ์อะไร
• ☐ ให้ AI ซักคำถามกลับจนโจทย์ชัดพอ
• ☐ สรุปเป็นเอกสารปลายทางแบบสั้นที่ใช้ตัดสินใจได้
• ☐ แตกงานเป็น vertical slices ที่ตรวจผลได้เร็ว
• ☐ จัดงานลง Kanban board พร้อมความสัมพันธ์ของแต่ละงาน
• ☐ แยกงานที่คนต้องตัดสินใจออกจากงานที่ AI ทำแทนได้
• ☐ สร้าง feedback loops หรือ checklist ก่อนปล่อย AI ทำงานต่อเอง
• ☐ ออกแบบระบบงานให้มีโมดูลหรือขั้นตอนหลักที่ชัด
• ☐ ล้างเอกสารเก่าหรือแยกสถานะให้ชัดเพื่อกัน AI หยิบข้อมูลผิด
• ☐ ตรวจงานปลายทางด้วยสายตาคนเสมอ โดยเฉพาะงานที่กระทบลูกค้า แบรนด์ และรายได้

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