สร้าง Manus ขึ้นมาใหม่ด้วย Manus: อะไรที่เปลี่ยนไป อะไรที่พังทลาย และเราทำงานกันอย่างไรในตอนนี้
โดย Tao Zhang ผู้ร่วมก่อตั้งและประธานเจ้าหน้าที่ฝ่ายผลิตภัณฑ์ Manus
ปลายเดือนกันยายน ในช่วงโค้งสุดท้ายของ Manus 2.0 ผมส่งคำขอฟีเจอร์และรายงานบั๊กไม่กี่รายการให้วิศวกรคนหนึ่งของเราทาง Slack ต่อมาผมเข้าไปดูว่าเขาคืบหน้าไปถึงไหน หน้าจอของเขามีแถวของเซสชัน Agent ที่เปิดอยู่ บางส่วนอยู่ใน Manus และบางส่วนอยู่ใน Codex ผมคลิกเข้าไปอันหนึ่ง พรอมต์คือข้อความ Slack ของผม วางไว้แบบคำต่อคำ
เมื่อปีที่แล้ว เขาคงจะอ่านข้อความของผม ตีความว่าผมหมายถึงอะไร แล้วค่อยเขียนโค้ด ตอนนี้ Agent อ่านคำขอ ค้นหาโค้ดที่เกี่ยวข้อง และเสนอการเปลี่ยนแปลง หน้าที่ของวิศวกรคือกำกับงาน ตรวจสอบ และรับผิดชอบผลลัพธ์ ส่วนใหญ่แล้วคำขอหนึ่งๆ กำลังทำงานอยู่ ไม่ได้รอเขา ทุกวันนี้ที่นี่เป็นเรื่องปกติที่วิศวกรคนหนึ่งจะมีคำขอ 10 ถึง 20 รายการขับเคลื่อนไปพร้อมกัน
ผมภูมิใจกับความเร็วในการปรับตัวของทีมเรา แต่ผมก็รู้สึกไม่สบายใจเช่นกัน จังหวะนี้ถูกต้องหรือไม่? มีอะไรที่เรายังไม่ทันสังเกตเห็นบ้าง?
เราสร้าง Agent ที่ Manus ดังนั้นเรายึดถือกฎสองข้อ เราใช้ผลิตภัณฑ์ของเราเองในการทำงานจริง และเรายังคงมองหาจุดที่ AI หยุดทำงาน
ผมอยากบันทึกสิ่งที่เกิดขึ้นภายในบริษัทเมื่อผู้คนและ Agent ทำงานเคียงข้างกันเป็นค่าเริ่มต้น โพสต์นี้ครอบคลุมสามทีม — วิศวกรรม ผลิตภัณฑ์ และการตลาด — และรวมถึงสิ่งที่ยังไม่ประสบความสำเร็จ นี่คือรายงานของการทดลองที่กำลังดำเนินอยู่ ไม่ใช่คำนิยามของ "องค์กรที่ขับเคลื่อนด้วย AI โดยกำเนิด"
สิ่งที่เราได้เรียนรู้มาจนถึงตอนนี้:
•ไม่มีจุดครึ่งทาง การเพิ่ม AI เข้าไปในวิธีการทำงานแบบเดิมบางครั้งเพียงเพิ่มสัญญาณรบกวน สิ่งต่างๆ เปลี่ยนแปลงก็ต่อเมื่อลูปปิดสมบูรณ์เท่านั้น
•Agent ต้องการภาพรวมทั้งหมด บริบทที่ดีขึ้นช่วยเราได้มากกว่าพรอมต์ที่ดีขึ้น
•ความไว้วางใจมาจากการทดสอบและบริบท ไม่ใช่จากคุณภาพของโมเดลเพียงอย่างเดียว
•ความเป็นอิสระต้องการเส้นชัย Agent สามารถทำงานด้วยตัวเองได้ก็ต่อเมื่อตรวจสอบความสำเร็จได้เท่านั้น ในทุกที่อื่น มนุษย์เป็นผู้ตัดสินใจ
•คอขวดเคลื่อนย้าย เมื่อวิศวกรรมเร็วขึ้น การตัดสินใจว่าจะสร้างอะไรกลายเป็นข้อจำกัด
•บทบาทของคนไม่ได้ลดลง มันกลับมีความชัดเจนในสิ่งที่มีผลกระทบสูงกว่า
1. ไม่มีจุดครึ่งทาง
ก่อนปี 2026 เราทำสิ่งที่บริษัทส่วนใหญ่ทำ: เราเพิ่ม AI เข้าไปในวิธีการทำงานที่เราทำอยู่แล้ว ซึ่งหมายความว่าฝ่ายสนับสนุนจะชี้ประเด็นปัญหาด้วยการสรุปของ AI วิศวกรใช้ผู้ช่วยในการเขียนโค้ด และบอตโพสต์การวิเคราะห์ในช่องแชต แต่ละชิ้นส่วนมีประโยชน์ในตัวเอง แต่ชิ้นส่วนเหล่านั้นไม่ได้เชื่อมโยงถึงกันมากนัก จนกว่าลูปจะปิดสมบูรณ์จริงๆ เราเพียงแค่ทำงานในแบบเดิมๆ แต่มี AI หลายตัวพูดทับกัน
มีประโยคหนึ่งที่เรามักกลับมานึกถึง: วิศวกรรมซอฟต์แวร์คือการเขียนโปรแกรมที่บูรณาการตลอดช่วงเวลา การเขียนโค้ดเป็นสิ่งที่วัดได้ง่าย การรักษาผลิตภัณฑ์ที่ซับซ้อนให้มีสุขภาพดีเป็นเวลาหลายปีนั้นไม่ง่าย เปอร์เซ็นต์ที่สูงของโค้ดที่เขียนโดย AI อาจหมายถึงความก้าวหน้าที่แท้จริง หรืออาจหมายถึงการสะสมของกากที่ใครบางคนจะต้องมาเก็บกวาดในภายหลัง
การทดสอบที่เราให้ความสำคัญนั้นยากกว่า Manus เป็นผลิตภัณฑ์ที่ซับซ้อนซึ่งเปิดใช้งานมานานกว่าหนึ่งปี มันสามารถพัฒนาต่อไปภายใต้วิธีการทำงานใหม่โดยไม่ล่มสลาย ในขณะที่แต่ละคนทำงานได้มากขึ้นได้หรือไม่? จนถึงตอนนี้คำตอบคือใช่
2. ให้ภาพรวมทั้งหมดแก่ Agent
เช่นเดียวกับบริษัทเทคโนโลยีส่วนใหญ่ เราสูญเสียเวลามากที่สุดในช่วงการส่งต่องาน วิศวกรฝั่งหน้าบ้านและวิศวกรฝั่งหลังบ้านแต่ละคนจะตีความคำขอ ตกลงกันเรื่องอินเทอร์เฟซ แล้วใช้เวลาหลายวันในการแก้ไขความไม่สอดคล้องกัน คนสองคนไม่ค่อยเข้าใจข้อกำหนดในแบบเดียวกัน
หาก AI สามารถเขียนโค้ดได้ทั่วทั้งสแตก คนคนเดียวจะสามารถดูแลคำขอตั้งแต่ต้นจนจบได้หรือไม่? อุปสรรคคือบริบท โค้ดของเราอยู่ในที่เก็บแยกกัน ดังนั้นจึงไม่มี Agent ตัวใดสามารถมองเห็นทั้งระบบในคราวเดียวได้
คำตอบของเราต่อเรื่องนี้เริ่มต้นจากการทดลองภายใน เราอยากดูว่า AI จะไปได้ไกลแค่ไหนในการสร้างผลิตภัณฑ์โดยใช้ข้อมูลป้อนจากมนุษย์น้อยที่สุดและแทบไม่มีโค้ดที่เขียนด้วยมือเลย วิธีการที่เราพัฒนาขึ้นระหว่างทางได้กลายมาเป็นเครื่องมือภายในที่ตอนนี้เราเรียกว่า Manus-mono หรือ Mono
Mono ไม่ได้รวม repository ของเราเข้าด้วยกัน แต่เป็นจุดเข้าเดียวพร้อมคู่มือที่เขียนให้ agent อ่าน ว่าแต่ละ repository ทำอะไร เชื่อมโยงกันอย่างไร และเราทำงานกันอย่างไร agent จะดึงสิ่งที่ต้องการเข้ามาเอง เรายังเก็บไลบรารีของบันทึกการตัดสินใจทางสถาปัตยกรรมไว้ด้วย เพื่อให้ทุก session ของ agent เริ่มต้นด้วยเหตุผลเบื้องหลังการตัดสินใจในอดีต ไม่ใช่แค่โค้ด เมื่อใครก็ตามทำงานร่วมกับ agent, agent นั้นจะมีบริบทของทุกคนที่เคยทำมาก่อน
Mono เติบโตขึ้นเป็นขั้นเป็นตอน และแต่ละขั้นก็แก้ปัญหาคอขวดที่ขั้นก่อนหน้าเปิดเผยออกมา:
1.มองเห็นทั้งระบบ เราเพิ่มบริบททางธุรกิจที่ไม่มี repository ใดเพียงอันเดียวบรรจุอยู่ และใช้ Git worktrees สำหรับการทำงานแบบขนาน
2.ตรวจสอบในเครื่อง การ push ไปยัง test environment เคยใช้เวลา 5 ถึง 10 นาที ตอนนี้ Manus stack ทั้งหมดทำงานบนแล็ปท็อปได้ และการตรวจสอบใช้เวลาเพียงไม่กี่วินาที
3.ดีบั๊กปัญหาใน production ด้วยสิทธิ์ที่กำหนดขอบเขตไว้ Mono สามารถอ่าน log, การตั้งค่า และรายงานข้อผิดพลาดที่ต้องใช้เพื่อวินิจฉัยบั๊กใน production
4.ดำเนินการ release ตั้งแต่ต้นจนจบ ตอนนี้ Mono จัดการขั้นตอน release ที่งานเคยติดขัด คนยังคงเป็นผู้ตัดสินใจอนุมัติ
5.ทดสอบตั้งแต่ต้นจนจบ เมื่อการตรวจสอบกลายเป็นส่วนที่ช้า Mono เริ่มรัน flow ผู้ใช้จริงด้วยบัญชีทดสอบ ทั้งในเบราว์เซอร์และใน mobile simulator
(Mono ทำงานอย่างไรและพัฒนามาอย่างไร สร้างโดยเพื่อนร่วมทีมด้วย Manus)
บางครั้งผู้คนถามว่า Mono เป็น code wiki หรือไม่ เอกสารเป็นส่วนหนึ่งของมัน แต่ส่วนที่เหลือคือทุกสิ่งรอบๆ โค้ด: เราทดสอบอย่างไร เรา release อย่างไร เราตัดสินใจอะไรและทำไม และ agent สามารถและไม่สามารถแตะต้องอะไรได้บ้าง
เมื่อเวลาผ่านไป Mono ได้กลายเป็นฐานความรู้ร่วมกันที่ดีขึ้นเมื่อผู้คนเพิ่มเติมเข้าไป เช่น วิศวกร ops ของเราเบื่อที่ถูกขอให้ช่วยทำ release เขาจึงเขียนขั้นตอน release ลงใน Mono ตอนนี้ใครก็สามารถรัน release ได้ และ agent ก็ทำได้เช่นกัน แต่การอนุมัติยังคงอยู่กับคนที่มีสิทธิ์ release ผมชอบวิธีที่ทีมทำงาน: คนหนึ่งแก้ความหงุดหงิดของตัวเอง ซึ่งนำไปสู่การที่ทั้งบริษัทเร็วขึ้นเล็กน้อย
ตอนนี้ทีมสันนิษฐานว่าคนหนึ่งคนสามารถส่งคำขอได้บนทุกแพลตฟอร์ม ทีม mobile ของเรามีเจ็ดคนมาตลอด พวกเขาดูแลแอปสี่ตัวในสองผลิตภัณฑ์และก้าวทันกับเว็บ
Mono แพร่กระจายไปทั่วบริษัทโดยไม่มีคำสั่งจากเบื้องบน ผมคิดว่าวัฒนธรรมอธิบายเรื่องนี้ได้มากพอๆ กับเครื่องมือ การทดสอบขีดจำกัดของ AI เป็นส่วนหนึ่งของเหตุผลที่เราดำรงอยู่ และองค์กรของเราแบน เครื่องมือจะไปได้ไกลเท่าที่องค์กรยอมให้ไปเท่านั้น
3. ปิดลูป: จากรายงานบั๊กของผู้ใช้ถึงการแก้ไขที่ผ่านการตรวจสอบ
Mono ทำให้ทุกคนสามารถทำงานในส่วนใดก็ได้ของผลิตภัณฑ์ นั่นเป็นเพียงครึ่งหนึ่ง อีกครึ่งหนึ่งคือการให้ agent ค้นหาปัญหาด้วยตัวเอง
ที่บริษัทอินเทอร์เน็ตส่วนใหญ่ รายงานบั๊กของผู้ใช้ต้องผ่านฝ่ายสนับสนุน ผลิตภัณฑ์ และการคัดกรองก่อนที่จะถึงมือวิศวกรที่สามารถแก้ไขได้
สำหรับเรา ตอนนี้ agent ภายในจะตรวจสอบรายงานก่อนและย้อนรอยปัญหาไปยังการเปลี่ยนแปลงที่เป็นสาเหตุ จากนั้นจะโพสต์ใน Slack และ tag วิศวกรที่เป็นเจ้าของการเปลี่ยนแปลงนั้น วิศวกรจะตัดสินใจว่าเป็นหน้าที่ของเขาที่ต้องแก้ไขหรือไม่ และส่งต่อให้ agent ของเขาเอง agent อีกตัวจะตรวจสอบการแก้ไขโดยรันการทดสอบและ flow ที่สำคัญ
สาม agent สามบทบาท: หนึ่งคัดกรอง หนึ่งทำงาน หนึ่งตรวจสอบ คนตรงกลางเป็นผู้ตัดสินใจ ส่วนแบ่งที่เพิ่มขึ้นของงานวิศวกรรมของเราตอนนี้เริ่มต้นแบบนี้ โดย agent นำปัญหามาให้คน
ลูปนี้มีขีดจำกัดที่ชัดเจน agent ที่อ่านรายงานผู้ใช้ไม่สามารถเปลี่ยนโค้ดได้ มันทำได้แค่ตรวจสอบและรายงานกลับมาให้เรา การเปลี่ยนแปลงมาจาก agent ของวิศวกรเอง หลังจากที่วิศวกรตัดสินใจแล้ว ไม่มีอะไรจะถูก ship โดยไม่มีการอนุมัติจากคนที่มีสิทธิ์ release
4. เราเรียนรู้ที่จะไว้วางใจโค้ดที่เขียนโดย agent ได้อย่างไร
เป็นเวลานานที่ทุกการเปลี่ยนแปลงที่เข้าสู่ branch หลักของเราต้องได้รับการอนุมัติจากวิศวกรอาวุโสหนึ่งในสองคน เราไม่ไว้วางใจ AI มากพอที่จะข้ามขั้นตอนนั้น เมื่อ agent ผลิตโค้ดมากขึ้น ขั้นตอนการตรวจสอบนั้นก็กลายเป็นคอขวด
ในด้านความสามารถการเขียนโค้ดล้วนๆ โมเดลเหล่านี้แข็งแกร่งอยู่แล้ว เราตระหนักว่าความแตกต่างมาจากสองสิ่ง อย่างแรก คนรู้วิธีทดสอบงานของตัวเอง อย่างที่สอง คนได้มีส่วนร่วมในการสนทนาทั้งต้นน้ำและปลายน้ำ จึงรู้ว่า "ถูกต้อง" หมายความว่าอย่างไรสำหรับธุรกิจ โค้ดที่ถูกต้องไม่เหมือนกับผลิตภัณฑ์ที่ถูกต้อง
เราแก้ไขทั้งสองประเด็น:
•ให้ agent เข้าร่วมการสนทนา agent ของวิศวกรแต่ละคนตอนนี้อยู่ใน Slack threads ที่ถูกเพิ่มเข้าไป และติดตามบริบท เมื่อมีคนบอกในที่สุดว่า "ไปได้" agent ก็รู้แล้วว่าทีมตัดสินใจอะไรและทำไม
•ให้ agent ทดสอบแบบ end to end เมื่อทำงานร่วมกับทีม backend ของเรา เราให้ agent มีความสามารถในการรัน flows จริงและการทดสอบ regression ใน Manus หลังการเปลี่ยนแปลงแต่ละครั้ง เมื่อ test coverage เพิ่มขึ้น ความไว้วางใจของเราก็เพิ่มขึ้นตาม
ทุกวันนี้ ทุกการเปลี่ยนแปลงต้องผ่านการตรวจสอบนั้นและผ่าน code review bot ที่รันโมเดลที่แข็งแกร่งที่สุดที่มี พร้อมกฎพิเศษสำหรับส่วนที่อ่อนไหว เช่น การชำระเงิน Bot เข้ามาแทนที่คิว ไม่ใช่การตัดสินใจของมนุษย์ Agent สามารถเปิด pull request ได้ แต่ไม่สามารถ merge เข้าสู่ branch หลักของเราได้โดยไม่ได้รับการอนุมัติอย่างชัดเจนจากคน คนยังคงเป็นผู้ตัดสินว่าอะไรจะถูกสร้างและใครสามารถปล่อยได้
5. ความเป็นอัตโนมัติต้องการเป้าหมายปลายทาง
ความไว้วางใจมีขีดจำกัด และเราได้เรียนรู้สิ่งนี้ด้วยวิธีที่ยากลำบาก
ครั้งหนึ่ง ทุกคนตื่นเต้นกับ agent loop แบบอัตโนมัติเต็มรูปแบบ เราจึงลองทำดู Agent รวบรวม feedback จากช่อง feedback ภายในของเราและเริ่มโปรเจกต์สำหรับแต่ละรายการ เพื่อนร่วมทีมคนหนึ่งปล่อยให้มันรันในช่วงสุดสัปดาห์ เช้าวันจันทร์ มีกว่า 200 รายการรอการตัดสินใจของเขา
ทำไมไม่ให้ agent ตัดสินใจเหล่านั้นด้วย? Loop อัตโนมัติจะทำงานได้ดีเมื่อระบบสามารถตรวจสอบได้ว่าเป้าหมายบรรลุหรือไม่ Tests ผ่านหรือล้มเหลว; หน้าโหลดได้หรือไม่ได้ งานจริงส่วนใหญ่ไม่มีการตรวจสอบแบบนั้น ต้องมีคนตัดสินว่าเสร็จแล้วหรือไม่ และคุ้มค่าที่จะทำหรือไม่ตั้งแต่แรก
เราได้บทเรียนสองประการจากสุดสัปดาห์นั้น อย่างแรก คนไม่สามารถตัดสินใจได้เร็วเท่ากับ loop ที่ไม่มีการตรวจสอบสร้างมันขึ้นมา อย่างที่สอง หากไม่มีใครตัดสินว่าควรทำบางสิ่งหรือไม่ ก็ไม่มีใครเป็นเจ้าของผลลัพธ์ Bug-fixing loop ในส่วนที่ 3 ทำงานได้เพราะ tests กำหนดความสำเร็จ การตัดสินใจเกี่ยวกับผลิตภัณฑ์ไม่มี tests ดังนั้นทุกการเปลี่ยนแปลงผลิตภัณฑ์ที่ Manus ยังคงเริ่มต้นด้วยคนที่ตัดสินว่ามันคุ้มค่าที่จะทำหรือไม่
6. เมื่อวิศวกรรมเร็วขึ้น ผลิตภัณฑ์กลายเป็นคอขวด
กระบวนการผลิตภัณฑ์แบบดั้งเดิมมีการส่งต่องานหลายครั้ง และลำดับความสำคัญก็เปลี่ยนไปเล็กน้อยในแต่ละครั้ง เมื่อ coding agent ทำให้วิศวกรทำงานได้เร็วขึ้น ปัญหาใหม่ก็ปรากฏขึ้น: ไม่มีผู้จัดการผลิตภัณฑ์เพียงพอที่จะเขียน requirements ที่ดี เป็นครั้งแรกที่วิศวกรรมไม่ใช่ข้อจำกัด
ที่ Manus วิธีแก้ไขแรกของเราคือขอให้วิศวกรไม่กี่คนกลายเป็น "builders" ที่เป็นเจ้าของปัญหาตั้งแต่การค้นพบจนถึงการเปิดตัว มีน้อยคนที่มีทั้งการตัดสินใจทางเทคนิคและผลิตภัณฑ์ ต่อมาเราให้ PM เปลี่ยนแปลงโค้ด แต่นั่นก็หยุดชะงักเช่นกัน การส่งต่องานยังคงอยู่ และหากไม่มีสัญชาตญาณของวิศวกร PM สามารถเปลี่ยนข้อความและการโต้ตอบได้ แต่ไม่ใช่ตรรกะพื้นฐาน
Mono แก้ปัญหาทั้งสองได้เพราะมันพกกฎไปด้วย:
•การเปลี่ยนแปลงใดๆ ที่สัมผัสการเรียกใช้โมเดลหรือต้นทุนต้องได้รับการอนุมัติจากเจ้าของก่อนที่จะเขียนโค้ด
•ทุกการเปลี่ยนแปลงต้องผ่านการตรวจสอบและทดสอบเหมือนกันกับการเปลี่ยนแปลงของวิศวกร
•Mono สามารถทำการ sign-up และการชำระเงินด้วยบัญชีทดสอบและบันทึกแต่ละขั้นตอน เพื่อให้ PM สามารถชี้ไปที่ช่วงเวลาที่แน่นอนที่บางสิ่งบางอย่างทำงานผิดพลาด
นี่คือสิ่งที่ปรากฏในทางปฏิบัติ PM ที่ทำงานเกี่ยวกับ speech-to-text ให้ Manus benchmark โมเดลมากกว่า 10 ตัว จากนั้นเลือกหนึ่งตัว เธอดึงโค้ด frontend ผ่าน Mono สร้างเดโมในระบบการออกแบบของเรา และให้ Manus แสดงผลแต่ละสถานการณ์ผู้ใช้เป็นรูปภาพให้เธอตรวจสอบ เธอเปลี่ยนเดโมเป็นวิดีโอ แผนชัดเจนพอที่เธอจะสร้างฟีเจอร์ด้วยตัวเอง รวมถึง UI ของเว็บและเดสก์ท็อป
ผู้คนตัดสินใจสามครั้งระหว่างทาง เธอเลือกโมเดล ฝ่ายผลิตภัณฑ์และดีไซน์ตรวจสอบเดโม วิศวกรที่มีสิทธิ์ปล่อยเวอร์ชันตรวจสอบโค้ด เมื่อปีที่แล้ว สิ่งเหล่านี้คงเป็นไปไม่ได้เลย
เราอธิบายสิ่งนี้ว่าเป็นการเปลี่ยนจาก human in the loop ไปสู่ human on the loop AI เคยทำงาน 70-80% ของงานหนึ่งๆ และคนเติมส่วนที่เหลือ ตอนนี้คนตั้งกฎ ควบคุมดูแล Agent หลายตัว ตรวจสอบวิธีการและผลลัพธ์ที่จุดสำคัญ เข้ามาแทรกเมื่อจำเป็น และเป็นเจ้าของผลลัพธ์
PM บางคนตอนนี้ส่งมอบวิดีโอสั้นแทนสเปกที่เขียนหรือม็อกอัพ ในไม่กี่นาที มันแสดง use case แต่ละหน้าจอ แต่ละคลิกทำอะไร edge case ทำงานอย่างไร และทุกอย่างทำงานเบื้องหลังอย่างไร สำหรับเรา ดีไซน์ วิศวกรรม และ QA เห็นพ้องกันเร็วขึ้นว่า "เสร็จแล้ว" หมายความว่าอย่างไร และ PM อธิบายเพียงครั้งเดียว
(วิดีโอข้อกำหนดผลิตภัณฑ์สำหรับการป้อนด้วยเสียง)
ปัจจุบันประมาณครึ่งหนึ่งของ PM ของเราปล่อยฟีเจอร์ด้วยตนเอง และ PM ทุกคนได้ commit โค้ด ดีไซเนอร์ก็เริ่มทำเช่นกัน PM คนหนึ่งเขียนอินเทอร์เฟซของ Manus Studio ส่วนใหญ่ใน Manus 2.0 อีกคนเขียน Video Editor เบื้องหลังแต่ละสิ่งเหล่านี้คือคนที่ใช้เวลาหลายเดือนผลักดันไปไกลกว่าสิ่งที่บทบาทของพวกเขาเคยครอบคลุม นั่นคือสิ่งที่ผมภูมิใจที่สุด
นี่ไม่ได้หมายความว่าทุกคนต้องเป็นผู้สร้าง เมื่อใครก็ตามในบริษัทสามารถสร้างได้ คนอาจปล่อยสิ่งที่ไม่ควรมีอยู่ ทีมผลิตภัณฑ์ของเรามักถามคำถามหนึ่งว่า: "ถ้าสิ่งนี้ใช้เวลาหนึ่งวินาทีและไม่มีค่าใช้จ่าย คุณจะปล่อยมันไหม?" บางครั้งคำตอบคือไม่ เรายังต้องการเจ้าของโมดูลที่ตัดสินใจว่าสิ่งใดจะถูกสร้าง สิ่งใดจะไม่ และสิ่งใดที่ผู้ใช้จะเห็นในที่สุด เรายังต้องการคนที่ดูแลโครงสร้างพื้นฐานเช่น Mono เมื่อการสร้างทำได้ง่าย การตัดสินใจว่าจะสร้างอะไรยิ่งสำคัญมากขึ้น
7. เพื่อนร่วมทีม AI ในเวิร์กโฟลว์การตลาด
พาร์ทเนอร์ชิพด้านการตลาดเคลื่อนผ่านการตรวจสอบสคริปต์ การกำหนดราคา สัญญา การอนุมัติ การชำระเงิน การเปิดตัว และการตรวจสอบผลลัพธ์ ขั้นตอนเหล่านั้นอยู่ในอีเมล เครื่องมือสัญญา ระบบอนุมัติ สเปรดชีต และแพลตฟอร์มโฆษณา งานส่วนใหญ่เคยเป็นการย้ายข้อมูลระหว่างสิ่งเหล่านั้น ซึ่งทำให้มีเวลาน้อยสำหรับงานสร้างสรรค์ที่ต้องใช้วิจารณญาณ
เราเริ่มจากปัญหาเล็กๆ หนึ่ง: เมื่อเนื้อหาของพาร์ทเนอร์หรือโฆษณาเปิดตัว เรามักได้ยินเรื่องนี้ช้าไป ดังนั้นเราจึงให้ AI เขียนสคริปต์ที่ตรวจจับเมื่อเนื้อหาถูกเผยแพร่ จากนั้นเราต้องการข้อมูลประสิทธิภาพ จากนั้นการตรวจสอบพาร์ทเนอร์ชิพในอดีต จากนั้นเวิร์กโฟลว์ภายในทั้งหมดก็เชื่อมต่อกัน: เมื่อลงนามสัญญาหรือการอนุมัติผ่าน Agent จะอัปเดตสถานะและแจ้งผู้ที่เป็นเจ้าของขั้นตอนถัดไป
Manus สร้างทั้งหมดนี้ให้เป็นเว็บไซต์ภายใน สำหรับคน มันคือแดชบอร์ดและปฏิทิน สำหรับ Agent มันคือชุดเครื่องมือ Agent ที่ใช้เครื่องมือเหล่านั้นภายในเวิร์กโฟลว์ของเราคือสิ่งที่เราเรียกว่าเพื่อนร่วมทีม AI มันทำงานเฉพาะในช่องทางและระบบที่ทีมเชื่อมต่อให้เท่านั้น โดยมีการเข้าถึงที่จำกัดอยู่ในเวิร์กโฟลว์นี้
นี่คือสิ่งที่มันทำ:
•มันจัดการคิวของตัวเอง หลายคนส่งข้อความถึงมันพร้อมกัน ดังนั้นมันจึงพูดคุยกับทุกคนในเซสชัน "โต๊ะต้อนรับ" เดียวและมอบงานให้กับเซสชันคู่ขนาน มันตัดสินใจว่าข้อความนั้นเกี่ยวข้องกับมันหรือไม่ จากนั้นจึงตัดสินใจว่าจะขัดจังหวะงานปัจจุบันหรือรอ มันเสนอกฎเหล่านี้ด้วยตัวเองในระหว่างการพัฒนา และเราตรวจสอบก่อนที่จะเก็บไว้
•มันเรียนรู้จากบริบทที่ถูกส่งต่อ การเปลี่ยนกลยุทธ์เคยหมายถึงการประชุมและสรุปที่เขียนไว้ ตอนนี้หัวหน้าฝ่ายการตลาดของเราส่งต่อการสนทนาและบอกว่า "เรียนรู้สิ่งนี้"
•มันคอยติดตามเป้าหมายระยะยาว ครั้งหนึ่ง เพื่อนร่วมทีมในเธรด Slack ที่มันถูกเพิ่มเข้ามา จำไม่ได้ว่าโปรเจกต์อยู่ตรงไหน โดยไม่ถูกแท็ก มันตอบว่า: "B ยังอยู่ในการทดสอบ ควรรอผลลัพธ์ของ A ก่อนที่จะดู B ไหม?"
•มันตรวจสอบข้อเท็จจริงกับทีมอื่น หลังจากที่เราเปิดตัว 3D model rigging มันถามทีมผลิตภัณฑ์ว่าอะไรรองรับบ้าง มันเรียนรู้ว่า rigging ครอบคลุมเจ็ดหมวดหมู่ รวมถึงปลา งู และสัตว์สี่ขา เพื่อให้คำอธิบายของเรายังคงถูกต้อง
ตอนนี้เพื่อนร่วมทีมพาเข้ามาในการตรวจสอบสคริปต์และการกำหนดราคา เพราะมันได้อ่านบันทึกพาร์ทเนอร์ชิพในอดีตของเราแล้ว คนยังคงเป็นผู้ตัดสินใจ
เว็บไซต์ภายในยังสามารถพัฒนาจากผู้ใช้ของตัวเองได้ รวมถึง Agent ด้วย เมื่อ Agent พบอุปสรรค มันจะยื่นคำขอผ่าน feedback endpoint สิ่งนั้นจะเปิดงานพัฒนาใน Manus ผ่าน Automations ใน Manus 2.0 และวิศวกรจะตรวจสอบการเปลี่ยนแปลงก่อนที่มันจะถูกปล่อย มันใช้งานมาประมาณหนึ่งสัปดาห์ เราต้องการเคสอีกมากก่อนที่เราจะพึ่งพามันได้
แล้วคนในทีมทำอะไร? สามสิ่งยังคงอยู่กับพวกเขา พวกเขาตัดสินใจและเป็นเจ้าของการตัดสินใจที่สำคัญทุกครั้ง พวกเขาจัดการเคสที่ Agent ยังไม่เคยเห็น และสอนมันว่าต้องทำอะไรหรือต้องถามใคร และพวกเขาเปลี่ยนทิศทางมันทุกครั้งที่การวิเคราะห์ของมันชี้ไปยังมุมมองใหม่
8. ขัดจังหวะกันให้น้อยลง
ในทุกทีมเหล่านี้ มีคำถามจำนวนมากที่ไม่จำเป็นต้องรบกวนใครอีกต่อไป
ถาม Agent ก่อน เพื่อนร่วมทีมสร้างบอท Slack บน Mono ที่ทำงานบนคอมพิวเตอร์คลาวด์และตอบในเธรด ผู้ที่ไม่ใช่วิศวกรใช้งานมากที่สุด ฟีเจอร์นี้ทำงานอย่างไร สตริงนี้อยู่ที่ไหน อันนี้ส่งออกไปแล้วหรือยัง พวกเขาไม่จำเป็นต้องหาเจ้าของก่อนอีกต่อไป
เปิดเซสชันแทนที่จะถามอัปเดตสถานะ ความคืบหน้าของวิศวกรเคยอยู่ในแชท AI ของพวกเขาเอง ซึ่งมองไม่เห็นเมื่อออกจากระบบ ดังนั้นเราจึงสร้างฟีเจอร์ภายในที่ให้สมาชิกของโปรเจกต์เห็นเซสชันของกันและกันและขอเข้าร่วมได้ วิศวกรอาจสร้างฟีเจอร์ส่วนใหญ่ด้วย Agent จากนั้น PM เข้าร่วมในเซสชันเดียวกันเพื่อปรับระยะห่าง สไตล์ และข้อความ การโพสต์ในเซสชันของคนอื่นต้องได้รับอนุมัติจากพวกเขา และเรายังคงหาข้อสรุปเรื่องสิทธิ์การเข้าถึง
(ตัวอย่างประกอบ: วิศวกร PM และนักออกแบบทำงานร่วมกันในเซสชันเดียวได้อย่างไร ไม่ใช่การเปลี่ยนแปลงราคาจริง)
ประเด็นไม่ใช่การคุยกันน้อยลง แต่คือการรบกวนกันน้อยลง
ตัดสินใจเฉพาะสิ่งที่ต้องตัดสินใจ ผู้ใช้ AI มากที่สุดของเรามีเซสชันหลักหนึ่งเซสชันที่มีงานเดียว: แสดงรายการสิ่งที่ต้องการการตัดสินใจของเขา พร้อมคำแนะนำสำหรับแต่ละรายการ เมื่อ Slack ยุ่ง เขาอยู่ห่างจากมันและถามว่า "ตอนนี้ฉันต้องตัดสินใจอะไรบ้าง?"
ฉันทำสิ่งที่คล้ายกัน ฉันมีสิ่งที่ต้องทำมากกว่า 20 อย่างต่อวัน และอย่างที่ฉันได้แชร์ต่อสาธารณะ ฉันเป็น ADHD การเริ่มต้นเป็นส่วนที่ยากที่สุดสำหรับฉัน ตอนนี้ทุกสิ่งที่ต้องทำจะเข้าสู่โปรเจกต์ Manus เฉพาะที่เปลี่ยนแต่ละรายการให้เป็นงานของตัวเอง มันเริ่มสิ่งที่มันทำได้ เมื่อไม่แน่ใจ มันจะถามฉันเกี่ยวกับข้อมูลพื้นฐานและ PM คนไหนควรเป็นเจ้าของ จากนั้นใช้สิทธิ์การเข้าถึงที่ฉันให้ไว้กับ Slack, Gmail และ Notion ของฉันเอง มันรวบรวมบริบทและส่งคำขอที่สมบูรณ์ให้ PM แทนที่จะเป็นโน้ตบรรทัดเดียว สำหรับฉัน การเปลี่ยนแปลงนี้ไม่ได้เกี่ยวกับประสิทธิภาพเท่านั้น ตอนนี้ฉันใช้เวลาในแต่ละวันกังวลว่าจะเริ่มต้นที่ไหนน้อยลงมาก ซึ่งเป็นเรื่องใหญ่ในระดับส่วนตัว
9. คุ้มค่ากับต้นทุนหรือไม่?
เราใช้จ่ายกับ AI มาก และเราติดตามค่าใช้จ่ายนั้นอย่างใกล้ชิด เราไม่ได้ใช้มันเพื่อตัดสินประสิทธิภาพของใคร เราใช้มันเพื่อตัดสินการใช้จ่ายเอง: ตอนนี้คุ้มค่าหรือไม่ หรือกำลังเตรียมเราไว้สำหรับอนาคต?
นี่คือสิ่งที่เราคิดว่ามันซื้อให้เรา และที่ที่เราคาดว่าต้นทุนจะไป:
•มันซื้อเวลาและความสนใจ เมื่อทีมเติบโตขึ้น การประสานงานกินเวลาและความสนใจของทุกคน AI ปกป้องความสนใจของแต่ละคนและให้ความเป็นเจ้าของในงานของพวกเขาอย่างเต็มที่ และเรายังคงจ้างงานอยู่
•การใช้โมเดลที่ดีที่สุดคือวิธีที่เราเรียนรู้ว่าขีดจำกัดของ AI อยู่ที่ไหน การตั้งค่าการตรวจสอบและทบทวนโค้ดที่อธิบายไว้ในส่วนที่ 4 ทำงานบนโมเดลที่แข็งแกร่งที่สุดเท่าที่เราจะหาได้ เพื่อนร่วมงานที่นำด้านผลิตภาพของนักพัฒนาเรียกมันว่าการใช้จ่ายที่คุ้มค่าที่สุดของเรา
•ต้นทุนควรลดลงผ่านผลิตภัณฑ์ การพัฒนาของเราส่วนใหญ่ตอนนี้เกิดขึ้นใน Manus Studio ซึ่งเป็นผลิตภัณฑ์ของเราเอง ดังนั้นข้อมูลการใช้งานของเราแสดงให้เราเห็นว่า tokens ถูกเสียเปล่าที่ไหน การแก้ไขจะเข้าไปในผลิตภัณฑ์ ดังนั้นควรทำให้ Manus มีประสิทธิภาพมากขึ้นสำหรับผู้ใช้ด้วย เราคาดว่าต้นทุนในปัจจุบันจะลดลงอย่างมีนัยสำคัญเมื่อโมเดลราคาถูกลงและเราขจัดการสูญเปล่า นั่นเป็นความเชื่อ ไม่ใช่คำสัญญา!
10. สิ่งที่ยังไม่ทำงาน
การรบกวนน้อยลง แต่ความสนใจกระจัดกระจายมากขึ้น คนที่เคยจัดการสี่หรือห้าสิ่งต่อวันตอนนี้อาจผลักดัน 20 หรือ 30 สิ่งไปข้างหน้าในคราวเดียว ทุกครั้งที่สลับหมายถึงการโหลดบริบทใหม่ AI ขยายสิ่งที่คนสามารถทำได้ และยังผลักดันให้พวกเขาทำมากขึ้น PM คนหนึ่งบอกฉันว่าเมื่อใดก็ตามที่งานกำลังทำงาน เธอก็อดใจไม่ไหวที่จะเริ่ม Agent อีกตัว การทำสิ่งต่างๆ มากขึ้นไม่ใช่เป้าหมาย เรากำลังมองว่านี่เป็นปัญหาที่ต้องแก้ไข ไม่ใช่จังหวะที่ต้องเฉลิมฉลอง
ข้อมูลกระจัดกระจายมากขึ้น หัวหน้าฝ่ายผลิตภัณฑ์ของเราเคยรู้ทุกการเปลี่ยนแปลงและเหตุผล ตอนนี้บางครั้งเขาถ่ายภาพปัญหาและถาม Mono ว่า "ใครเปลี่ยนสิ่งนี้?" เป็นเรื่องตลก แต่คำถามเป็นจริง เมื่อทุกคนได้รับอำนาจในการเปลี่ยนแปลงผลิตภัณฑ์ ใครรับผิดชอบต่อภาพรวม?
สิทธิ์การแชร์ต้องออกแบบใหม่ เมื่องานสามารถแชร์และส่งต่อได้ และ Agents อยู่ในการสนทนาของเรามากขึ้น เราต้องตัดสินใจว่าอะไรเปิดและอะไรต้องการการอนุมัติ
การแก้ไขของเรายังคงเป็นพื้นฐาน ในตอนนี้ Agent หนึ่งควบคุมดูแลตัวอื่นๆ และรายงานเฉพาะสิ่งที่ติดขัดและสิ่งที่ต้องการการตัดสินใจของมนุษย์ เรารู้ว่านี่สามารถดีขึ้นได้
11. สิ่งที่เรากำลังสร้างต่อไป
ปัญหาเหล่านี้ชี้ไปที่งานด้านผลิตภัณฑ์ที่ทีมอื่นๆ ก็น่าจะต้องการเช่นกัน เราไม่ได้วางแผนฟีเจอร์เหล่านี้ไว้ล่วงหน้า มันเกิดขึ้นจากปัญหาที่เราเองประสบอยู่เรื่อยๆ
•Sessions ในฐานะพื้นที่ทำงานร่วมกัน คนหนึ่งหยิบยกปัญหาขึ้นมา นักออกแบบเสนอวิธีแก้ วิศวกรสร้างมันขึ้นมา และ PM นำไปใช้งาน ทั้งหมดอยู่ในที่เดียวกัน
•งานที่เคลื่อนย้ายข้ามอุปกรณ์และผู้คน เครื่องในเครื่องและบนคลาวด์ยังคงเชื่อมต่อกัน ดังนั้นงานสามารถดำเนินต่อไปได้เมื่อผู้คนก้าวออกไป
•Agent ที่ค้นพบตัวเลือกที่ผู้คนยังไม่เคยพิจารณา Agent ที่ทำงานอยู่ภายในระบบของบริษัท ด้วยสิทธิ์ที่เหมาะสม ควรสามารถเสนอวิธีแก้ปัญหาได้ ไม่ใช่เพียงแค่ทำตามคำสั่ง
เราจะลองใช้สิ่งเหล่านี้กับตัวเองก่อน แล้วจึงนำไปให้ผู้ใช้
12. สิ่งที่ผู้คนทำอยู่ตอนนี้
วิศวกรที่เปิด agent sessions เรียงกันเป็นแถวไม่ได้เป็นเพียงเรื่องราวเกี่ยวกับประสิทธิภาพ มันคือการเปลี่ยนแปลงในสิ่งที่องค์กรดำเนินอยู่ บริษัทเคยส่งข้อมูลผ่านบทบาทและลำดับชั้น สิ่งที่คนหนึ่งสามารถทำได้ขึ้นอยู่กับว่าเขาสามารถใช้ประโยชน์จากคนและทรัพยากรได้มากแค่ไหน ตอนนี้เราใช้เวลาเล็กน้อยเพื่อให้บริบทและเครื่องมือแก่ AI และใช้เวลามากขึ้นในการตัดสินใจและใช้วิจารณญาณ บ่อยครั้งขึ้นเรื่อยๆ Agent คือฝ่ายที่นำปัญหามาให้เรา การตัดสินใจว่าจะทำอย่างไรกับมันยังคงเป็นหน้าที่ของเรา
เราเคยพูดเล่นกันว่า: ถ้า Manus ทำได้ขนาดนี้ แล้วจะมาที่ออฟฟิศทำไม ปล่อยให้ agents จัดการกันเองสิ แต่คำถามสำคัญยังคงต้องการให้ผู้คนหยิบยกขึ้นมา โต้แย้ง และตัดสินใจ ตัวอย่างเช่น อะไรที่นับว่าเป็นผลิตภัณฑ์ที่ดี? หรือหากจะพูดให้เกินจริงเล็กน้อย: สร้างผลิตภัณฑ์ที่ยอดเยี่ยมที่มีรายได้จริงและยังคงผลักดันขีดจำกัดของ AI ต่อไป หรือมุ่งเน้นที่อัตรากำไร? AI ไม่รู้ว่าเราต้องการอย่างไหน แต่เรารู้ วัฒนธรรมและความไว้วางใจเกิดขึ้นจากการทำงานร่วมกันผ่านสิ่งต่างๆ วันแล้ววันเล่าและในช่วงเวลาที่สำคัญ นั่นคือรากฐานที่งานในทุก session ตั้งอยู่
ดังนั้น ณ ตอนนี้ นี่คือคำตอบของเรา ในการทดลองของเราในฐานะองค์กรที่เป็น AI-native บทบาทของผู้คนไม่ได้ลดลง แต่มีความมุ่งเน้นมากขึ้นในด้านที่พวกเขาสามารถสร้างผลกระทบได้มากที่สุด: กำหนดปัญหา ตัดสินคุณภาพ ตัดสินใจว่าอะไรคุ้มค่าที่จะทำ และเป็นเจ้าของผลลัพธ์
นั่นคือเหตุผลที่เรายังคงรับสมัครงานอยู่ ทักษะและวิจารณญาณของผู้คนเป็นศูนย์กลางของวิธีการทำงานนี้ — และสิ่งนั้นจะไม่เปลี่ยนแปลงในเร็วๆ นี้
ขณะที่ฉันเขียนสิ่งนี้ ฉันสงสัยว่าโพสต์นี้จะเขียนอย่างไรในอีกหนึ่งปีข้างหน้า ทุกบริษัทมีเป้าหมาย โครงสร้าง และวัฒนธรรมที่แตกต่างกัน ดังนั้นอาจไม่มีคำตอบมาตรฐานและไม่มีรูปแบบสุดท้าย แต่สำหรับบริษัทที่สร้าง agents การคิดหาวิธีให้คนและ AI ทำงานร่วมกันไม่ใช่ทางเลือก มันคือส่วนหนึ่งของงาน เราจะเดินหน้าต่อไป และจะแบ่งปันสิ่งที่เราได้เรียนรู้ต่อไป
หมายเหตุเกี่ยวกับตัวเลข ตัวเลขในโพสต์นี้มาจากบันทึกภายใน ขนาดทีมและตัวเลขการส่งมอบของ PM เป็นข้อมูล ณ ปลายเดือนตุลาคม บางจุดเป็นการประมาณการหรือเป็นประสบการณ์ของคนคนเดียวมากกว่าการวัดผล
