คุณสร้างนิสัยการทำงานขึ้นรอบ ๆ บอร์ดหนึ่งบอร์ด หนึ่งคอลัมน์ต่อหนึ่งงาน หนึ่งโค้ดดิ้งเอเจนต์ต่อหนึ่งการ์ด แต่ละตัวทำงานใน git worktree ของตัวเองเพื่อไม่ให้ชนกัน มันเป็นวิธีที่สะอาดในการรันเอเจนต์สามหรือสี่ตัวพร้อมกัน และยังรีวิว diff ทีละตัวได้ แล้วบริษัทที่ดูแลเครื่องมือนี้ก็ปิดคลาวด์ลง คำถามตรง ๆ ก็ผุดขึ้นมา: ตอนนี้คุณจะรันโค้ดดิ้งเอเจนต์ที่ไหน และคำตอบนั้นขยายเกินหนึ่งแล็ปท็อปกับหนึ่งคนได้ไหม
ถ้าคุณกำลังหาทางเลือกแทน Vibe Kanban คุณไม่ได้กำลังมองหาตัวแทนของ Claude Code หรือ Codex แต่กำลังมองหาชั้นที่ล้อมรอบรันไทม์เหล่านั้นอยู่ นั่นคือที่ที่มอบหมายงานให้เอเจนต์แต่ละตัว แยกงานของมันออกจากกัน และแสดงให้คุณเห็นว่ามีอะไรเปลี่ยนแปลงไปบ้างก่อนที่อะไรจะถูก merge คู่มือนี้จะพาไปสำรวจชั้นดังกล่าว ให้เครดิต Vibe Kanban อย่างเต็มที่กับแพตเทิร์นที่มันพิสูจน์แล้ว ชี้จุดที่บอร์ดในเครื่องไปได้ไม่ไกลกว่านั้น และแสดงว่า Sharkly ต่อยอดข้ามเส้นนั้นไปสู่ Task ที่แชร์กัน, Crew และ Sprint สำหรับทั้งทีมได้อย่างไร
สรุปสั้น ๆ
Vibe Kanban เป็นผู้บุกเบิกโมเดลหนึ่งบอร์ดต่อหนึ่งเอเจนต์: รันโค้ดดิ้งเอเจนต์หลายตัวพร้อมกัน แต่ละตัวอยู่ใน worktree ของตัวเอง แล้วรีวิวผลลัพธ์บนบอร์ดคัมบังในเครื่องของคุณ Sharkly รักษาโมเดลนี้ไว้และเพิ่มชั้นสำหรับทีมเข้าไปรอบ ๆ: Task ที่แชร์กัน, Computer ที่เชื่อมต่อ, Crew, Sprint และการรีวิวโดยมนุษย์ตั้งแต่คำขอจนถึงการปล่อยงาน ถ้าคุณทำงานคนเดียวบนเครื่องเดียว บอร์ดในเครื่องก็เพียงพอ แต่ถ้าทีมต้องมีคอนเท็กซ์ที่แชร์กันและด่านรีวิว นั่นคือจุดที่ Sharkly เข้ามารับช่วง
ปัญหาที่ทางเลือกแทน Vibe Kanban แก้ได้จริง
Vibe Kanban ทำบางสิ่งได้ถูกต้อง ซึ่งเครื่องมือส่วนใหญ่พลาดไป เมื่อคุณรันเอเจนต์เขียนโค้ด AI หลายตัวพร้อมกัน ส่วนที่ยากไม่ใช่ตัวโมเดล แต่คือการชนกัน เอเจนต์สองตัวแก้ไฟล์เดียวกัน เอาต์พุตกระจัดกระจายอยู่ตามแท็บเทอร์มินัล และไม่มีมุมมองเดียวที่บอกว่างานไหนเสร็จ งานไหนติดบล็อก และงานไหนที่แอบเลี้ยวออกนอกทาง
คำตอบแบบหนึ่งบอร์ดต่อหนึ่งเอเจนต์นั้นเรียบง่ายและงดงาม ให้แต่ละงานมีการ์ดของตัวเอง ให้แต่ละการ์ดมี git worktree ของตัวเอง เอเจนต์จึงทำงานบนแบรนช์ที่แยกออกมาในไดเรกทอรีที่แยกออกมา ปล่อยให้ Claude Code, Gemini CLI, Codex หรือรันไทม์อื่นทำงานภายในแซนด์บ็อกซ์นั้น แล้วนำ diff กลับมารีวิว วิธีนี้เปลี่ยน “ฉันมีเอเจนต์ห้าตัวและไม่รู้เลยว่าพวกมันทำอะไรไปบ้าง” ให้กลายเป็นบอร์ดที่อ่านออกจริง ๆ ถ้าคุณอยากได้กลไกของแพตเทิร์นแบบขนานนี้โดยเฉพาะ คู่มือของเราเรื่อง วิธีรัน Claude Code หลายตัวพร้อมกัน อธิบายการตั้งค่า worktree ไว้อย่างละเอียด
ช่องว่างไม่เคยอยู่ที่แพตเทิร์น ช่องว่างคือสิ่งที่บอร์ดในเครื่องเอื้อมไปไม่ถึง บอร์ดบนเครื่องคุณคือบอร์ดสำหรับคุณคนเดียว เพื่อนร่วมทีมมองไม่เห็นงาน หยิบการ์ดที่ติดบล็อกขึ้นมาทำต่อไม่ได้ รีวิว diff ก่อน merge ไม่ได้ และบอกไม่ได้จากอีกมุมห้องว่าสปรินต์ยังอยู่ในเส้นทางหรือไม่ เมื่อทำงานคนเดียวก็ไม่มีปัญหา แต่เมื่องานเป็นของทีม ชิ้นส่วนที่ขาดหายไปคือบันทึกที่แชร์กัน ซึ่งเป็นเครื่องมืออีกชนิดหนึ่งเลย
สิ่งที่ Vibe Kanban พิสูจน์ พูดให้ตรง ๆ
ให้เครดิตเวอร์ชันที่ดีที่สุดของเครื่องมือนี้ เพราะมันคู่ควร Vibe Kanban มองการรันเอเจนต์เป็นหน่วยงานชั้นหนึ่ง ไม่ใช่เซสชันเทอร์มินัลที่ใช้แล้วทิ้ง มันทำให้การแยกด้วย worktree เป็นค่าเริ่มต้น เอเจนต์ที่รันขนานกันจึงไม่เหยียบกันเอง มันทำให้การสลับรันไทม์มีต้นทุนต่ำ คุณจึงไม่ต้องผูกขาดกับโมเดลเดียว และมันทำให้การรีวิวเป็นขั้นตอนหนึ่ง ไม่ใช่สิ่งที่คิดทีหลัง ด้วยการวาง diff ไว้ตรงหน้าคุณก่อนที่คุณจะย้ายการ์ดไปไว้ที่เสร็จแล้ว
แนวคิดสี่ข้อนั้นถูกต้อง และทางเลือกจริงจังใด ๆ ก็ต้องรักษาไว้ทั้งหมด ทางเลือกแทน Vibe Kanban ที่ทิ้งการแยกด้วย worktree หรือซ่อน diff หรือล็อกคุณไว้กับรันไทม์เดียว คือการถอยหลังไม่ว่าจะเพิ่มอะไรมาอีก มาตรฐานที่บอร์ดตั้งไว้คือพื้น ไม่ใช่เพดาน
สิ่งที่เปลี่ยนไปคือเรื่องการดูแลรักษา โปรเจกต์นี้เป็นโอเพนซอร์สและยังรันในเครื่องได้ แต่ฟีเจอร์คลาวด์ที่บริษัทดูแลถูกถอดออก และการแก้ไขต่อเนื่องตอนนี้ต้องพึ่งพาผู้ร่วมพัฒนาในคอมมิวนิตี้ สำหรับนักพัฒนาคนเดียวเรื่องนี้อาจยอมรับได้สบาย ๆ แต่สำหรับทีมที่เดิมพันการส่งมอบทั้งไตรมาสไว้กับเครื่องมือนี้ คำว่า “แล้วแต่ใครจะโผล่มา” คือความเสี่ยงจริงที่ต้องชั่งน้ำหนัก และนี่คือเหตุผลตรงไปตรงมาที่ทำให้ความต้องการย้ายระบบเกิดขึ้นจริงในตอนนี้
จุดที่บอร์ดในเครื่องไปได้ไม่ไกล และ Sharkly ต่อจากตรงนั้น
นี่คือคู่การตัดสินใจ อธิบายแบบที่ทางเลือกนี้แยกออกจากกันจริง ๆ
ใช้บอร์ดในเครื่องเมื่อคุณเป็นคนเดียวบนเครื่องเดียว งานเป็นของคุณคนเดียว และไม่มีใครต้องเห็นงานจนกว่าคุณจะเปิด pull request การตั้งค่าแบบหนึ่งบอร์ดต่อหนึ่งเอเจนต์นั้นเบา มันรันที่เดียวกับที่คุณรัน และไม่เพิ่มภาระในการประสานงานเลยเพราะไม่มีใครให้ต้องประสานด้วย การไปหยิบแพลตฟอร์มสำหรับทีมในกรณีนี้ถือว่าเกินความจำเป็น
ใช้ Sharkly เมื่อการรันเอเจนต์ไม่ใช่เรื่องส่วนตัวอีกต่อไป ทันทีที่คนที่สองต้องมอบหมายงาน หยิบงานที่ติดบล็อกขึ้นมาทำต่อ หรือรีวิว diff ก่อน merge บอร์ดที่อยู่ในแล็ปท็อปของคุณก็กลายเป็นคอขวด นั่นคือเส้นแบ่ง Sharkly คือชั้นที่ล้อมรอบรันไทม์เดิมที่คุณใช้อยู่ และทำให้ทุกการรันมอบหมายได้ มองเห็นได้ และรีวิวได้โดยทีม ไม่ใช่แค่คุณ
นิยามสั้น ๆ ระดับพจนานุกรม เพราะส่วนที่เหลือของบทความนี้ขึ้นอยู่กับมัน Task คือหน่วยงานหลักใน Sharkly มันเก็บเป้าหมาย, Agent ที่ได้รับมอบหมาย, รันไทม์, ความคืบหน้า, อุปสรรค, diff ที่ได้ และการรีวิวโดยมนุษย์ ไว้ในบันทึกที่แชร์กันที่เดียว ถ้าการ์ดบนบอร์ดในเครื่องเป็นของคุณ Task ก็เป็นของทีม
และขอวางขอบเขตไว้ เพราะผู้อ่านที่ย้ายมาจากบอร์ดจะเข้าใจผิดแน่ ๆ ถ้าไม่พูด Sharkly ไม่ใช่ตัวแทนของ Claude Code, Codex หรือ Gemini มันไม่ได้รันโมเดลหรือเขียนโค้ด แต่เพิ่ม Task ที่แชร์กัน, Computer ที่เชื่อมต่อ, คอนเท็กซ์, การควบคุม และชั้นการรีวิว ไว้รอบเครื่องมือรันที่ทีมคุณใช้อยู่แล้ว ถ้าคุณชอบที่ Vibe Kanban ให้คุณสลับรันไทม์ได้อย่างอิสระ Sharkly ก็รักษาอิสระนั้นไว้และเพิ่มทีมเข้าไปล้อมรอบมัน
เส้นทางการย้าย: เก็บรันไทม์ไว้ เก็บ repo ไว้ แล้วเพิ่มชั้นการรีวิว
ส่วนที่ดีที่สุดของการย้ายออกจากบอร์ดที่กำลังปิดตัวลง คือคุณแทบไม่ต้องเสียอะไรไปเลย คุณไม่ได้สร้างสแต็กใหม่ แต่เก็บส่วนที่ทำงานได้ดีไว้ และเพิ่มส่วนที่ขาดหายไป
เก็บรันไทม์ไว้ Claude Code, Codex, Gemini CLI, OpenCode, Cline และอื่น ๆ ยังคงรันงานเหมือนเดิมทุกประการ การใช้โมเดลยังดำเนินต่อไปผ่านการสมัครสมาชิกหรือ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้นแล้ว คุณนำการสมัครสมาชิกของคุณมาเอง Sharkly ไม่ได้คั่นกลางระหว่างเอเจนต์กับโมเดล ถ้าคุณอยากได้พื้นฐานเชิงแนวคิดว่าจริง ๆ แล้วรันไทม์เหล่านี้ทำอะไร บทความอธิบายของเราเรื่อง agentic coding หมายถึงอะไรสำหรับทีมพัฒนา ได้วางนิยามไว้ให้
เก็บ repo และนิสัยใช้ worktree ไว้ Sharkly รันเอเจนต์ใน worktree ที่แยกออกจากกันบน Computer ที่เชื่อมต่อ ซึ่งเป็นการแยกแบบเดียวกับที่คุณพึ่งพาอยู่ ตอนนี้ผูกกับ Task ที่แชร์กันแทนการ์ดในเครื่อง งานฟรอนต์เอนด์ แบ็กเอนด์ การแก้บั๊ก และความครอบคลุมของเทสต์ เดินหน้าพร้อมกันได้โดยไม่ชนกัน ซึ่งเป็นเหตุผลทั้งหมดที่โมเดลหนึ่งบอร์ดต่อหนึ่งเอเจนต์ถือกำเนิดขึ้น
เพิ่มชั้นการรีวิวที่คุณขาดไป นี่คือส่วนใหม่ การรัน อุปสรรค ผลลัพธ์ และการพูดคุยติดตามผล ย้อนกลับไปที่ไทม์ไลน์ของ Task ที่ทีมมองเห็นได้ Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง มอบอำนาจ และยอมรับผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้ดุลยพินิจของทีม และส่งมอบงานกลับมาพร้อมคอนเท็กซ์ครบถ้วนและหลักฐานที่ตรวจสอบได้ ประโยคสุดท้ายนั้นคือสัญญาที่บอร์ดในเครื่องบังคับใช้ไม่ได้ เพราะไม่มีทีมอยู่อีกฝั่งของมัน
ดังนั้นการย้ายจึงเป็นการเพิ่มเติม เชื่อมต่อ Computer หนึ่งเครื่อง ชี้ Sharkly ไปที่รันไทม์ที่คุณมีอยู่แล้ว และเริ่มจัดเส้นทางงานได้เลย โดยไม่ต้องสร้างกระบวนการที่ทีมคุณเข้าใจอยู่แล้วใหม่ บอร์ดสอนให้คุณรันเอเจนต์แบบขนาน Sharkly เปิดให้คนที่เหลือในทีมเข้ามามีส่วนด้วย
จากบอร์ดส่วนตัวสู่ระบบของทีม: Crew, Sprint และ Project
เมื่อการรันถูกแชร์กันแล้ว ความสามารถสามอย่างก็เปิดขึ้น ซึ่งบอร์ดสำหรับผู้ใช้คนเดียวให้ไม่ได้
Crew สำหรับงานที่ต้องใช้เอเจนต์มากกว่าหนึ่งตัว Crew คือกลุ่มของคนและ Agent ที่นำกลับมาใช้ซ้ำได้ ซึ่งประสานโดย Agent หัวหน้าหนึ่งตัว สำหรับงานเล็ก ๆ ที่ขอบเขตชัดเจน คุณไม่จำเป็นต้องใช้ เพราะมอบหมาย Task ให้ Agent ตัวเดียวแล้วไม่ต้องมีชิ้นส่วนที่ต้องขยับเลย ใช้ Crew เมื่อ Agent หัวหน้าต้องตีความเป้าหมายที่กว้างกว่า ดึงสมาชิก Agent ตัวอื่นเข้ามา และนำผลลัพธ์ของพวกเขากลับมารวมใน Task เดียว นั่นคือกฎที่ตรงไปตรงมา Crew สร้างแรงทดเมื่องานมีหลายส่วนจริง ๆ และเป็นภาระเปล่าเมื่องานไม่ได้เป็นแบบนั้น
Sprint และ Project สำหรับการติดตามที่อยู่รอดเกินหนึ่งการ์ด บอร์ดในเครื่องแสดงงานที่อยู่ตรงหน้าคุณวันนี้ ส่วน Sprint ติดตามความสำเร็จ ความเป็นเจ้าของ การพึ่งพากัน การเปลี่ยนแปลงขอบเขต และอุปสรรค ครอบคลุมกลุ่มงานหนึ่ง ๆ ในระยะยาว สำหรับทีมแบบผสมของคนและ Agent นั่นคือความต่างระหว่าง “สัปดาห์นี้เอเจนต์ทำอะไรไปบ้าง” กับแผนที่คุณรายงานผลได้จริง บทความปูพื้นของเราเรื่อง AI agent orchestration สำหรับทีมพัฒนา อธิบายว่าทำไมชั้นการประสานงาน ไม่ใช่ตัวโมเดล จึงเป็นจุดที่ทีมได้หรือเสียปริมาณงานที่ทำได้ไป
ความโปร่งใสของทีม เป็นค่าเริ่มต้นไม่ใช่การแชร์หน้าจอ ทำให้คอนเท็กซ์ ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์ มองเห็นได้ตั้งแต่คำขอจนถึงการปล่อยงาน บนบอร์ดในเครื่อง การมองเห็นหยุดอยู่ที่จอของคุณ ในระบบที่แชร์กัน แรงทดไม่ได้มาจากการเปิดแชท AI เพิ่มขึ้น แต่มาจากการแชร์บทบาท กฎ คอนเท็กซ์ และเวิร์กโฟลว์ เพื่อให้การตั้งค่าที่ดีชุดหนึ่งกลายเป็นความสามารถที่ทั้งทีมนำกลับมาใช้ซ้ำได้
Vibe Kanban กับ Sharkly: การเปรียบเทียบอย่างเป็นธรรม
| มิติ | Vibe Kanban (บอร์ดในเครื่อง) | Sharkly (ชั้นสำหรับทีม) |
|---|---|---|
| หน่วยหลัก | การ์ดบนเครื่องของคุณ | Task ที่แชร์กันสำหรับทีม |
| เอเจนต์แบบขนาน | ได้ แยกด้วย worktree | ได้ แยกด้วย worktree บน Computer ที่เชื่อมต่อ |
| รันไทม์ | Claude Code, Gemini, Codex และอื่น ๆ | รันไทม์เดิม นำเข้ามาใช้ตามที่เป็นอยู่ |
| การรีวิว | รีวิว diff แบบคนเดียว | รีวิวโดยมนุษย์ตั้งแต่คำขอจนถึงการปล่อยงาน ทั้งทีม |
| การจัดกลุ่มหลายเอเจนต์ | ไม่ใช่รูปแบบของมัน | Crew ที่มี Agent หัวหน้า |
| การวางแผนระยะยาว | มุมมองบอร์ด | Project และ Sprint |
| การคิดค่าบริการโมเดล | คีย์ของคุณเอง รันในเครื่อง | นำการสมัครสมาชิกของคุณมาเอง คีย์ยังอยู่ในเครื่องมือ |
| การดูแลรักษา | โอเพนซอร์ส ดูแลโดยคอมมิวนิตี้หลังปิดบริการ | แพลตฟอร์มที่พัฒนาอย่างต่อเนื่อง |
| เหมาะที่สุดกับ | นักพัฒนาคนเดียวบนเครื่องเดียว | ทีมที่จัดเส้นทางและรีวิวงานเอเจนต์ร่วมกัน |
อ่านตารางนี้เป็นการแบ่งงานกันทำ ไม่ใช่กระดานคะแนน สำหรับนักพัฒนาคนเดียวที่อยากได้บอร์ดในเครื่องฟรี ๆ และไม่ต้องการมากกว่านั้น โปรเจกต์ที่ดูแลโดยคอมมิวนิตี้อาจยังเป็นทางเลือกที่ถูกต้อง และไม่น่าอายเลยที่จะอยู่ตรงนั้นต่อ สำหรับทีมที่ต้องการให้การรันถูกแชร์ มอบหมาย และรีวิวได้ บอร์ดยังไงก็ต้องชนเพดานในที่สุด และ Sharkly คือที่ที่รันไทม์เดิมทำงานต่อไปโดยมีทีมเพิ่มเข้ามา คุณสามารถ ดาวน์โหลด Sharkly และเชื่อมต่อ Computer หนึ่งเครื่องเพื่อดูความแตกต่างกับงานจริงได้
ข้อผิดพลาดที่พบบ่อยเมื่อย้ายออกจากบอร์ดในเครื่อง
- มองว่ามันคือการสลับของแบบเดียวกัน คุณไม่ได้กำลังหาบอร์ดอีกอัน แต่กำลังหาชั้นสำหรับทีมที่บอร์ดไม่เคยมี ถ้าทางเลือกใหม่แค่จำลองคอลัมน์และการ์ดขึ้นมา มันก็ไม่ได้แก้อะไร
- ทิ้งการแยกด้วย worktree เพื่อให้เร็วขึ้น การแยกคือเหตุผลที่เอเจนต์แบบขนานไม่ชนกัน รักษามันไว้ เครื่องมือใดที่ทำให้เอเจนต์ใช้ไดเรกทอรีทำงานร่วมกัน กำลังเอาปัญหาจริงกลับเข้ามา
- เพิ่ม Crew ให้งานที่ใช้เอเจนต์ตัวเดียว ใช้ Crew เฉพาะเมื่อเป้าหมายต้องมี Agent หัวหน้ามาประสานสมาชิกจริง ๆ สำหรับงานที่ขอบเขตชัดเจน หนึ่ง Agent และไม่มีชิ้นส่วนที่ต้องขยับคือคำตอบที่ถูกต้อง
- ข้ามด่านรีวิวเพื่อให้รู้สึกว่างานเดินหน้า จุดสำคัญของชั้นนี้คือให้คนเป็นคนยอมรับผลลัพธ์ การ merge diff ของเอเจนต์โดยไม่รีวิวเพราะเร็วกว่า คือการคืนความปลอดภัยที่ทั้งระบบมีอยู่เพื่อมอบให้
- ย้ายทุกอย่างตั้งแต่วันแรก เริ่มจากความต้องการจริงหนึ่งข้อและ Task ที่มีความเสี่ยงต่ำหนึ่งงาน พิสูจน์ว่าลูปทำงานได้ แล้วค่อยขยาย
บทสรุป
Vibe Kanban พิสูจน์แพตเทิร์นที่ควรค่าแก่การเก็บไว้: เอเจนต์ทำงานได้ดีที่สุดเมื่อรันแบบขนาน แยกอยู่ใน worktree ของตัวเอง และมีการรีวิวเป็นขั้นตอนจริง ตอนนี้แพตเทิร์นนั้นกลายเป็นพื้นฐานไปแล้ว และทางเลือกแทน Vibe Kanban ใดที่ทิ้งมันไปก็คือการถอยหลัง
- โมเดลหนึ่งบอร์ดต่อหนึ่งเอเจนต์นั้นถูกต้อง เอเจนต์แบบขนานที่แยกด้วย worktree พร้อมการรีวิว diff คือรูปทรงที่ใช่
- บอร์ดในเครื่องจบที่คนเดียวบนเครื่องเดียว งานที่แชร์กันต้องมีบันทึกที่แชร์กัน
- Sharkly เก็บรันไทม์ repo และนิสัยใช้ worktree ของคุณไว้ แล้วเพิ่มชั้นสำหรับทีมเข้าไปล้อมรอบ
- Task บรรจุเป้าหมาย รันไทม์ ความคืบหน้า อุปสรรค diff และการรีวิว ไว้ในที่เดียว
- Crew, Sprint และ Project เปลี่ยนการรันแบบขนานให้เป็นแผนที่ทีมรายงานผลได้
- Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง มอบอำนาจ และยอมรับผลลัพธ์
ถ้าคุณกำลังเลือกว่าจะรันโค้ดดิ้งเอเจนต์ที่ไหนต่อไป เก็บเครื่องมือที่ทีมคุณใช้อยู่ไว้ แล้วเพิ่มชั้นที่ทำให้การรันมอบหมายและตรวจสอบย้อนกลับได้ เชื่อมต่อ Computer หนึ่งเครื่อง สร้าง Agent หนึ่งตัว แล้วมอบหมายงานน่าเบื่อ ๆ ให้มัน จากนั้นปล่อยให้คนที่เหลือในทีมดูงานส่งกลับมาที่ Task เริ่มที่ Sharkly และเอกสารอธิบายแต่ละแนวคิดไว้ละเอียดขึ้นที่ docs.sharkly.ai
คำถามที่พบบ่อย
Vibe Kanban ยังใช้ได้อยู่ไหมหลัง Bloop ปิดตัว? ได้ โปรเจกต์นี้เป็นโอเพนซอร์สและยังรันในเครื่องได้ ฟีเจอร์คลาวด์ที่บริษัทดูแลถูกถอดออก และการแก้ไขกับอัปเดตตอนนี้ต้องพึ่งพาผู้ร่วมพัฒนาในคอมมิวนิตี้ สำหรับการใช้งานคนเดียวอาจไม่เป็นปัญหา แต่สำหรับทีมที่พึ่งพามันในการส่งมอบ ความเสี่ยงด้านการดูแลรักษาก็ควรค่าแก่การชั่งน้ำหนัก
Sharkly เป็นตัวแทนของ Claude Code หรือ Codex ใช่ไหม? ไม่ใช่ Sharkly ไม่ใช่ตัวแทนของ Claude Code, Codex หรือเครื่องมือรันอื่น ๆ รันไทม์เหล่านั้นทำหน้าที่รันงาน Sharkly เพิ่ม Task ที่แชร์กัน, Computer, คอนเท็กซ์, การควบคุม และชั้นการรีวิวเข้าไปรอบ ๆ พวกมัน คุณยังใช้เอเจนต์เดิมต่อไป
ฉันต้องเลิกรันเอเจนต์ใน worktree แบบขนานไปหรือเปล่า? ไม่ต้อง Sharkly รันเอเจนต์ใน worktree ที่แยกออกจากกันบน Computer ที่เชื่อมต่อ ซึ่งเป็นการแยกแบบเดียวกับที่โมเดลหนึ่งบอร์ดต่อหนึ่งเอเจนต์พึ่งพา ฟรอนต์เอนด์ แบ็กเอนด์ และเทสต์เดินหน้าพร้อมกันได้โดยไม่ชนกัน ดู วิธีรัน Claude Code หลายตัวพร้อมกัน สำหรับแพตเทิร์นพื้นฐาน
การย้ายจากบอร์ดในเครื่องต้องทำอะไรบ้างจริง ๆ? เก็บรันไทม์และ repo ของคุณไว้ เชื่อมต่อ Computer ชี้ Sharkly ไปที่เครื่องมือรันที่คุณใช้อยู่ และเริ่มจัดเส้นทางงานเป็น Task ที่แชร์กัน การใช้โมเดลยังดำเนินต่อไปผ่านการสมัครสมาชิกหรือ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้นแล้ว ดังนั้นการคิดค่าบริการจึงไม่เปลี่ยน
เมื่อไหร่ที่ไม่ควรใช้ Sharkly? เมื่อคุณเป็นคนเดียวบนเครื่องเดียว และไม่มีใครต้องเห็นหรือรีวิวงาน บอร์ดในเครื่องก็เพียงพอ Sharkly จะมีคุณค่าทันทีที่คนที่สองต้องมอบหมาย หยิบงานขึ้นมาทำต่อ หรือรีวิวการรันของเอเจนต์
การ์ดกับ Task ต่างกันอย่างไร? การ์ดบนบอร์ดในเครื่องเป็นของคุณและอยู่ในเครื่องคุณ ส่วน Task คือบันทึกที่แชร์กันของทีม: มันเก็บเป้าหมาย, Agent ที่ได้รับมอบหมาย, รันไทม์, ความคืบหน้า, อุปสรรค, diff และการรีวิวโดยมนุษย์ และผลลัพธ์จากการรันจะย้อนกลับมาที่มัน
