การใช้ AI เขียนโค้ดเป็นส่วนหนึ่งของงาน แต่ยังมีการส่งต่องาน เก็บบริบท และตรวจผลก่อนนำไปใช้ คลิป Develop at Idea Velocity โดย Jeffrey Lee-Chan จาก Snapchat ทางช่อง AI Engineer เล่าระบบที่เขาใช้จัดการผู้ช่วย AI หลายตัว พร้อมตัวอย่างงานและปัญหาที่ยังต้องแก้
แนวคิดหลักคือ harness หรือโครงระบบรอบ AI ที่จัดให้ผู้ช่วยแต่ละตัวมีบทบาทและข้อมูลที่เกี่ยวข้อง ทำงานคู่กันได้ และส่งผลกลับมาให้ตรวจ ผู้พูดอธิบายการใช้ OpenClaw ร่วมกับตัวจัดการผู้ช่วย AI และหน้าจอ terminal ที่ใช้ติดตามงาน
ระบบที่เขาเล่าครอบคลุมการเก็บบริบท การแบ่งบทบาท การทำงานคู่กัน และการตรวจผล ส่วนวิธีทดลอง staging หรือระบบทดลองก่อนนำโค้ดไปใช้จริงในช่วงท้าย ยังอยู่ระหว่างตั้งค่าและแก้ปัญหาในเวลาที่บรรยาย
เริ่มจากระบบรอบ AI ที่ส่งต่องานและตรวจผลงาน
ในตัวอย่างของผู้พูด OpenClaw มีบริบทและความจำเกี่ยวกับงาน เช่น ผู้ช่วยตรวจโค้ดที่เขาเรียกว่า skeptic agent จึงเข้าใจได้ว่าเขาหมายถึงงานไหนเมื่อส่งข้อความสั้นๆ ไปสั่งงาน
อย่างไรก็ตาม เขาระบุว่ายังมีงานที่ต้องแก้ปัญหาต่อ เช่น การเพิ่มเวลารอเมื่อระบบหมดเวลา การมีบริบทเดิมจึงไม่ได้แปลว่าผู้ช่วยจะทำทุกงานจบได้เอง
ผู้พูดพยายามให้คนกำหนดงานและตรวจผลมากขึ้น ขณะที่ผู้ช่วย AI ลงมือทำงานย่อยและทดสอบ เขายกตัวอย่างว่าถ้า AI บอกว่างานพร้อมแล้ว ขั้นถัดไปยังต้องสั่งให้รันทดสอบ
เมื่อประยุกต์กับงานธุรกิจ VibeSolo เสนอให้กำหนดตั้งแต่ต้นว่า งานนี้ต้องการผลอะไร และต้องส่งหลักฐานใดกลับมาให้คนตรวจ ก่อนตัดสินใจว่าขั้นตอนไหนควรให้ AI ทำต่อเอง
สื่อสารสั้นลงได้เมื่อระบบมีบริบทของงาน
ผู้พูดใช้คำว่า frictionless communication หมายถึงการติดต่อ AI ได้สะดวก เช่น ส่งข้อความไปสั่งงานโดยไม่ต้องกลับไปนั่งที่เครื่องทุกครั้ง และให้ระบบเชื่อมข้อความนั้นกับบริบทของงานเดิม
ตัวอย่างที่เขาเล่าคือการส่งข้อความสั้นๆ ให้แก้ skeptic agent แล้วถามต่อว่ามีงานสำคัญอะไรอยู่บ้าง ประเด็นจึงไม่ใช่แค่สั่งให้สั้น แต่คือระบบต้องรู้ว่าคำสั่งนั้นเกี่ยวกับงานไหน
ตัวอย่างต่อไปนี้เป็นข้อเสนอของ VibeSolo สำหรับข้อมูลที่อาจใช้เป็นบริบทของงานธุรกิจ:
- คำถามหรือข้อกังวลที่ลูกค้าถามทีมขายบ่อย
- แนวทางน้ำเสียงของแบรนด์และแคมเปญก่อนหน้า
- งานสำคัญของไตรมาส
- ขั้นตอนทำงานมาตรฐานที่เกี่ยวกับงานนั้น
ควรแยกข้อมูลที่เกี่ยวกับเป้าหมายออกจากรายละเอียดการลงมือทำ ตามเหตุผลของผู้พูดที่ต้องการให้ผู้จัดการงานมีบริบทสำหรับตัดสินใจต่างจากผู้ช่วยที่เขียนโค้ด
แยกผู้จัดการงานกับผู้ลงมือทำให้ชัด
ผู้พูดแยกผู้ช่วย AI เป็น manager หรือผู้จัดการงาน กับ worker หรือผู้ลงมือทำ เพื่อให้แต่ละบทบาทมีข้อมูลและหน้าที่ต่างกัน
ผู้จัดการงานมองเป้าหมาย ข้อกำหนดและประวัติของงาน ส่วนผู้ลงมือทำรับรายละเอียดที่จำเป็นต่อการแก้โค้ด เมื่อคนต้องการควบคุมมากขึ้น ผู้พูดใช้หน้าจอ terminal ของ cmux ติดตามงาน และใช้ Agent Orchestrator ที่เขาปรับจากโครงการโอเพนซอร์สจัดการผู้ลงมือทำ
ผู้พูดสังเกตว่า AI ที่ลงมือทำงานอาจอยากรายงานว่างานของตัวเองพร้อมใช้ การมีผู้จัดการที่เห็นบริบทต่างกันเปิดโอกาสให้ตั้งคำถามกับผลงานนั้นได้ แต่ตัวอย่างนี้ยังไม่ใช่หลักฐานว่าแยกบทบาทแล้วจะขจัดความเอนเอียงได้ทั้งหมด
เขายกตัวอย่างชุดแก้ไขโค้ดหรือ PR หมายเลข 294 โดยสมมติว่าตัวที่ลงมือทำอาจมองว่าควรรวมโค้ด แต่ผู้จัดการงานกลับเสนอให้ปิดชุดนั้น เพราะมี PR อีกชุดที่ควรมาแทน ประเด็นคือบริบทต่างกันอาจทำให้พิจารณาคนละทางเลือก
ตัวอย่างการแยกบทบาทในงานธุรกิจต่อไปนี้เป็นข้อเสนอของ VibeSolo:
- ผู้จัดการงาน สรุปเป้าหมายแคมเปญและจัดลำดับงาน
- ผู้ช่วยค้นข้อมูล รวบรวมข้อมูลลูกค้าและคู่แข่ง
- ผู้ช่วยเขียน เตรียมร่างหลายแบบ
- ผู้ช่วยตรวจ เช็กความสอดคล้องกับแนวทางแบรนด์
- คนตรวจรอบสุดท้าย พิจารณาหลักฐานและตัดสินใจนำไปใช้
ให้งานอิสระทำคู่กัน แล้วดูสถานะจากที่เดียว
ผู้พูดใช้ผู้ช่วย AI หลายตัวกับ worktree ซึ่งเป็นพื้นที่ทำงานแยกกันของ Git และใช้ terminal หลายชุดติดตามงาน เขาระบุว่าการแยกพื้นที่นี้เป็นส่วนสำคัญของการทำงานคู่กันและการรวมโค้ดภายหลัง
หน้าจอ cmux ที่เขาเล่ามีแท็บแนวตั้งและการแจ้งเตือนเมื่อมีงานที่ต้องกลับมาดู ผู้พูดจึงใช้ terminal ในบทบาทผู้จัดการมากกว่านั่งเขียนโค้ดทีละส่วนเอง
หากจะประยุกต์กับงานธุรกิจ VibeSolo เสนอให้เริ่มจากงานอิสระที่ไม่ต้องรอผลของกันและกัน เช่น:
- สรุปประชุม
- เตรียมข้อมูลสำหรับข้อเสนอราคา
- วิเคราะห์ข้อมูลคู่แข่ง
- ร่างอีเมลลูกค้า
- รวบรวมคำถามที่พบบ่อยสำหรับทีมบริการลูกค้า
ก่อนให้หลายงานเดินพร้อมกัน ควรระบุให้ชัดว่างานไหนต้องรอข้อมูลจากงานอื่น และใครจะตรวจการรวมผล การทำงานขนานไม่ได้แทนขั้นตอนตรวจความถูกต้อง
ประเด็นที่นำมาใช้ได้คือการมีที่ติดตามว่างานไหนกำลังทำ งานไหนเสร็จแล้ว และงานไหนรอการตัดสินใจ โดยไม่ต้องเฝ้าทุกหน้าจอตลอดเวลา
แยกบริบทเป้าหมายออกจากรายละเอียดลงมือทำ
เมื่อถูกถามว่าทำไมไม่ใช้เครื่องมือเขียนโค้ดโดยตรง ผู้พูดตอบว่าเขาต้องการแบ่งความเชี่ยวชาญ ให้ OpenClaw สนใจข้อกำหนด เป้าหมาย และประวัติข้อความที่เขาเคยส่ง ขณะที่ผู้ลงมือทำดูรายละเอียดโค้ดและเครื่องมือของงาน
ผู้พูดยกเรื่องพื้นที่บริบทของโมเดลมาอธิบายว่าข้อมูลเกี่ยวกับวิธีลงมือทำอาจใช้พื้นที่ไปมาก จึงต้องการให้ผู้จัดการงานเก็บภาพรวมไว้ แล้วส่งรายละเอียดที่จำเป็นไปให้ผู้ลงมือทำ
การแบ่งบริบทต่อไปนี้เป็นวิธีจัดข้อมูลที่ VibeSolo เสนอจากหลักคิดนั้น:
- เป้าหมาย งานนี้ต้องการผลลัพธ์อะไร
- ประวัติ มีอะไรทำไปแล้วบ้าง
- ข้อจำกัด ห้ามทำอะไรและต้องระวังอะไร
- ข้อมูลลงมือทำ รายละเอียดที่ผู้ช่วยต้องใช้กับงานย่อยนั้น
การแบ่งแบบนี้ทำให้ตรวจได้ว่าแต่ละบทบาทได้รับข้อมูลอะไร โดยยังต้องทดสอบว่าข้อมูลนั้นเพียงพอสำหรับงานจริงหรือไม่
ตรวจงานด้วยการทดสอบ ก่อนเชื่อคำว่าเสร็จแล้ว
ในตัวอย่างของผู้พูด เมื่อผู้ช่วย AI บอกว่าพร้อมแล้ว เขายังตอบให้รันทดสอบต่อ ช่วงที่อธิบายการตรวจงาน เขาพูดถึงการทดสอบการทำงานผ่านช่องทางอย่าง MCP หรือ HTTP และการตรวจส่วนที่ต้องดูบน browser
ควรแยกคำรายงานของ AI ออกจากผลที่ตรวจได้ เช่น:
- การทำงานผ่านช่องทางที่ระบบเปิดไว้ให้ทดสอบได้ผลหรือไม่
- หน้าจอแสดงผลตามที่คาดไว้หรือไม่
- ส่วนที่ต้องตรวจผ่าน browser ผ่านการตรวจแล้วหรือยัง
สำหรับงานที่ไม่ใช่โค้ด VibeSolo เสนอให้ใช้หลักเดียวกัน เช่น งานวิเคราะห์ตลาดแนบแหล่งข้อมูล งานร่างข้อเสนอแสดงสมมติฐาน และแผนสื่ออธิบายเหตุผลของงบประมาณแต่ละช่องทาง
การส่งหลักฐานพร้อมผลงานช่วยให้คนพิจารณาได้ว่าจะรับงานนั้น แก้ต่อ หรือทดสอบเพิ่มตรงไหน
เลือกโมเดลตามงาน โควตา และงบ
ช่วงท้ายผู้พูดเล่าว่าเขาเลือกโมเดลตามโควตาและเงินที่ใช้ เมื่อโควตาของตัวหลักเหลือน้อยก็สลับไปอีกตัว นี่เป็นวิธีจัดการต้นทุนของเขาในเวลาที่บรรยาย ไม่ใช่ผลเปรียบเทียบคุณภาพหรือราคาปัจจุบันของผู้ให้บริการ
สำหรับงานธุรกิจ VibeSolo เสนอให้พิจารณาว่างานไหนต้องการความสามารถอะไร และจะตรวจผลของโมเดลแต่ละตัวอย่างไร ควบคู่กับงบที่รับได้
ตัวอย่างการจัดชั้นงานต่อไปนี้เป็นแนวทางทดลอง:
- งานที่มีผลตัดสินใจสำคัญ ใช้โมเดลที่ผ่านการทดสอบกับงานนั้นแล้ว
- งานปริมาณมาก เช่น แปลงรูปแบบหรือจัดหมวดหมู่ ทดลองตัวที่ประหยัดกว่าและตรวจตัวอย่างผลลัพธ์
- งานตรวจซ้ำ เปรียบเทียบว่าตัวที่ต้นทุนต่ำกว่าจับข้อผิดพลาดที่ต้องการได้หรือไม่
- งานที่ต้องการหลายมุมมอง ทดลองเปรียบเทียบคำตอบจากหลายโมเดลโดยยังตรวจแหล่งข้อมูลต้นทาง
ผู้พูดโชว์เว็บที่รวบรวมคำตอบจากหลาย AI แทนการเปิดแต่ละตัวแล้วคัดลอกคำตอบมารวมเอง เขาระบุว่าชอบคำตอบแบบนี้มากกว่า แต่การมีหลายคำตอบตรงกันยังไม่ได้ยืนยันว่าข้อสรุปนั้นถูกต้อง
แยก sandbox ออกจาก staging ที่ยังอยู่ระหว่างทดลอง
ผู้พูดแยก sandbox ซึ่งเป็นพื้นที่แยกการทำงาน เช่น Docker ออกจาก staging หรือระบบสำหรับทดลองก่อนนำโค้ดไปใช้จริง เขาระบุว่าระบบ staging ที่กำลังตั้งค่ายังมีปัญหาและต้องแก้ต่อ
แนวทางที่เขาตั้งใจทดลองคือพัฒนาในเครื่อง ทดสอบการทำงานร่วมกันของส่วนต่างๆ บนระบบทดลอง แล้วค่อยรวมโค้ดและนำไปใช้จริง ส่วนตัวอย่างธุรกิจต่อไปนี้เป็นข้อเสนอของ VibeSolo:
- ให้ AI ร่างอีเมลก่อนส่งจริง
- สร้างหน้าโปรโมชันในพื้นที่ทดลองก่อนเผยแพร่
- ทดสอบงานวิเคราะห์กับชุดข้อมูลทดลองก่อนใช้ข้อมูลจริง
- ทดลองขั้นตอนทำงานภายในก่อนให้ทีมใช้วงกว้าง
ผู้พูดคาดว่าการมีระบบทดลองเพิ่มอาจเพิ่มการใช้โทเคนและช่วยเรื่องความน่าเชื่อถือได้บ้าง แต่ในคลิปเขายังไม่ได้รายงานว่าทดลองระบบนี้สำเร็จแล้ว จึงต้องตรวจผลและต้นทุนจริงก่อนสรุปว่าคุ้มกับงานนั้น
ดูสองเว็บที่ผู้พูดยกตัวอย่าง
ผู้พูดแสดงเว็บที่เขาระบุว่าสร้างไว้สองประเภท:
แบบแรกคือ AI RPG หรือเกมสวมบทบาทที่ AI สร้างเรื่องและโลกตอบสนองต่อผู้เล่น ผู้พูดอธิบายว่าระบบใช้กติกาแบบ D&D และการทอยลูกเต๋าเพื่อตัดสินว่าการกระทำสำเร็จหรือไม่ ต่างจากการให้ระบบสนทนาเล่าเรื่องไปอย่างเดียว
แบบที่สองคือเว็บรวบรวมการวิเคราะห์จากหลาย AI เพื่อช่วยลดขั้นตอนที่ผู้พูดเคยเปิดหลายโมเดลแล้วคัดลอกคำตอบมารวมกัน ทั้งสองเป็นตัวอย่างและคำอธิบายของผู้สร้าง ไม่ใช่ผลทดสอบความแม่นยำหรือประสิทธิภาพอิสระ
สิ่งที่นำไปคิดต่อได้คือ ต้องกำหนดกติกาของงานและวิธีตรวจผลให้ชัด ควบคู่กับการเลือกโมเดลและการส่งต่องานระหว่างผู้ช่วยแต่ละตัว
ที่มา: Develop at Idea Velocity โดย Jeffrey Lee-Chan จาก Snapchat ทางช่อง AI Engineer อัปโหลด 11 กรกฎาคม 2026 ตามเวลาไทย เนื้อหาเป็นการอธิบายระบบและการทดลองในเวลานั้น ตัวอย่างธุรกิจไทยเป็นข้อเสนอของ VibeSolo
