พูดป้อน prompt ให้ agent ขนาน ทีละเลน

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

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

บทความนี้ว่าด้วยปัญหาการส่งมอบ ไม่ใช่ปัญหาการคิด มันคือเวิร์กโฟลว์ใช้งานจริงสำหรับการพูด prompt เข้าไปในเลน agent ขนานบน Mac พร้อมข้อจำกัดตามจริงครบถ้วน ถ้าคุณยังไม่ได้อ่าน ขับ Claude Code ด้วยเสียงของคุณ บทความนั้นครอบคลุมพื้นฐานของเลนเดียว ส่วนบทความนี้ถือว่าคุณรันมากกว่าหนึ่งเลนอยู่แล้ว

ทำไมเลนขนานถึงลงโทษการพิมพ์เป็นพิเศษ

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

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

คูณด้วยทุกคำสั่งปรับทิศทาง ทุก "ใช่ ทำต่อ" ทุก "ไม่ใช่ อีกไฟล์หนึ่ง" แล้วภาระมันก็ทบขึ้น เลนขนานไม่ได้ล้มเหลวเพราะ agent ช้า มันล้มเหลวเพราะคุณกลายเป็น message bus และ message bus ที่ต้องขยับตัวจริง ๆ ระหว่างหน้าต่างนั้นมี latency แย่มาก

เสียงตัดต้นทุนการส่งมอบออกไปเกือบหมด คุณคงสายตาไว้บน diff กดปุ่มค้าง พูดประโยคนั้น ปล่อย คำต่าง ๆ ไปลงในช่องอินพุตของ agent คุณไม่เคยออกไปไหนเลย

การตั้งค่าที่ได้ผล

นี่คือการตั้งค่า ซึ่งจงใจให้น่าเบื่อ

hotkey ไม่ใช่หน้าต่าง Keebye อยู่ในเมนูบาร์และคอยฟัง hotkey แบบกดค้างหรือแตะ (⌘ ขวาเป็นค่าเริ่มต้น ส่วน Fn และ ⌥ ขวาเป็นตัวเลือกอื่น และ Esc ยกเลิกการพิมพ์ด้วยเสียงที่กำลังทำอยู่) ไม่มีหน้าต่างแอปให้เปิด และไม่มีโหมดให้เข้า กดค้าง พูด ปล่อย เรื่องนี้สำคัญกว่าที่ฟังดู: เครื่องมือพิมพ์ด้วยเสียงที่ต้องมีหน้าต่างของตัวเองก็เป็นแค่อีกเลนหนึ่ง

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

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

ทุกอย่างบนเครื่อง การถอดเสียงรันในเครื่อง (โมเดลเริ่มต้นที่จูนมาเพื่อภาษาอังกฤษ หรือโมเดล 25 ภาษาถ้าคุณเลือกใช้) หลังดาวน์โหลดโมเดลแล้ว มันทำงานได้แม้ปิด Wi-Fi สำหรับการสั่ง prompt ให้ agent เรื่องนี้ไม่ได้เกี่ยวกับการแสดงท่าทีเรื่องความเป็นส่วนตัวมากเท่ากับเรื่อง latency: ไม่มีการวิ่งไปกลับ ฉะนั้น prompt สั้น ๆ จึงพร้อมแทบจะทันทีที่คุณปล่อยปุ่ม

จังหวะการสลับเลน

เวิร์กโฟลว์ที่อยู่ตัวในที่สุดมีนิสัยสามอย่าง

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

พูด prompt เป็นประโยคเต็ม agent รับมือกับประโยคเต็มได้ดีกว่าเศษคำแบบโทรเลข และการพิมพ์ด้วยเสียงผลิตประโยคเต็มออกมาเองโดยธรรมชาติ เพราะนั่นคือวิธีที่คนพูดกัน "ย้อนการเปลี่ยนสคีมากลับ แต่คงการเปลี่ยนชื่อ API ไว้ แล้วรัน migration ใหม่และแสดงผลลัพธ์ให้ผมดู" เป็น prompt ที่พูดออกมาแล้วดี แต่พิมพ์แล้วน่าเบื่อ

คำฟุ่มเฟือยถูกตัด ความหมายไม่ถูกตัด การเก็บกวาดของ Keebye ใช้กฎเป็นค่าเริ่มต้น: มันเอา "เอ่อ" "อืม" และคำที่พูดซ้ำออก แล้วปล่อยถ้อยคำของคุณไว้ตามเดิม มีการขัดเกลาด้วย LLM ในเครื่องแบบเลือกใช้เพื่อให้ประโยคเรียบร้อยขึ้น โดยมีตัวป้องกันความซื่อตรงคอยถอยกลับไปใช้ข้อความตามตัวอักษรเมื่อฉบับขัดเกลาแสดงการสูญเสียโทเคนอย่างรุนแรง การขยายตัว หรือการซ้ำ ตัวป้องกันนั้นเป็นฮิวริสติก ไม่ใช่การตรวจเชิงความหมาย: มันไม่ได้ยืนยันว่าข้อความที่ขัดเกลาแล้วรักษาความหมายหรือการปฏิเสธของคุณไว้ สำหรับการสั่ง agent คนส่วนใหญ่ปิดการขัดเกลาไว้ ข้อความตามตัวอักษรคือสิ่งที่คุณพูดออกมาเป๊ะ ๆ และนั่นคือสิ่งที่คุณอยากให้ agent เอาไปรัน

เสียงเก่งเรื่องอะไร ทีละเลน

ไม่ใช่ทุก prompt ที่อยากถูกพูดออกมา หลังผ่านไปไม่กี่เดือน การแบ่งคร่าว ๆ เป็นแบบนี้

คำสั่งปรับทิศทางและการสั่งให้ทำต่อ: ใช้เสียงเสมอ "ทำต่อไป" "ไม่ใช่ อีก config หนึ่ง" "เพิ่มเทสต์สำหรับเคสว่างแล้วรันใหม่" พวกนี้คือ prompt ที่มีปริมาณมากที่สุดในเซสชันแบบขนาน และทั้งหมดยาวแค่ลมหายใจเดียว

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

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

อะไรก็ตามที่เป็นโค้ด: พิมพ์ การพูด regex เป็นเรื่องทรมาน ให้พูดคำสั่ง ("เขียน regex ที่จับคู่กับ version header") ไม่ใช่พูดตัวชิ้นงาน

ข้อจำกัดตามจริง

บางข้อเป็นของ Keebye บางข้อเป็นของทั้งหมวดหมู่นี้

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

ความแม่นยำกับตัวระบุ ชื่อตัวแปรแบบ snake case และตัวย่อภายในองค์กรคือจุดที่โมเดลเสียงทุกตัวมีปัญหา พจนานุกรมช่วยลดได้ แต่ไม่ได้กำจัดมันหมด อ่าน prompt ก่อนกด return กับอะไรก็ตามที่ทำลายข้อมูล

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

ไม่มีคำสั่งเสียง ไม่มีคำศัพท์อย่าง "ขึ้นบรรทัดใหม่" หรือ "เลือกทั้งหมด" Keebye เป็นเครื่องมือพิมพ์ด้วยเสียง ไม่ใช่ชั้นควบคุมด้วยเสียง การย้ายไปมาระหว่างเลนยังคงเป็นการคลิกหรือคีย์ลัดอยู่ดี

macOS เท่านั้น เวอร์ชัน Windows ยังไม่ได้ปล่อย

ไปต่อที่ไหน

ถ้า agent ของคุณส่วนใหญ่อยู่ในเอดิเตอร์ตัวเดียว คู่มือ Cursor และ Claude Code มีรายละเอียดเฉพาะของแต่ละเครื่องมือ ถ้าคุณกำลังเลือกแอปพิมพ์ด้วยเสียงสำหรับเวิร์กโฟลว์นี้ Keebye เทียบกับ Superwhisper คือการเปรียบเทียบอย่างตรงไปตรงมาที่รวมถึงจุดที่ Superwhisper เหมาะกว่าด้วย

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