Đọc prompt cho các agent song song, lane này qua lane khác

Lần đầu bạn chạy hai coding agent song song, có gì đó lấn cấn, và phải mất một lúc mới gọi tên được. Agent nào cũng nhanh. Từng con một, riêng lẻ, đều là một cái lợi rõ ràng. Gộp lại lẽ ra phải lợi gấp đôi. Vậy mà ngày làm việc lại vụn vặt hơn cả khi chỉ có một con, và cuối buổi chiều bạn hoàn thành ít hơn mình tưởng.

Lý do không nằm ở các agent. Nó nằm ở hình dạng của thứ đầu vào mà chúng cần. Một coding agent chạy bằng văn xuôi: "tách cái handler ra, giữ nguyên chữ ký công khai, thêm một test cho nhánh timeout." Văn xuôi thì rẻ để nghĩ và đắt để giao, bởi giao nó nghĩa là đặt tay và sự chú ý của bạn vào đúng cửa sổ, đúng thời điểm. Với một agent, thời điểm đó khớp với nhịp tự nhiên của bạn. Với ba agent, các thời điểm đến lúc nào thì đến, và mỗi lần lại cắt ngang thứ bạn đang làm dở.

Bài này nói về vấn đề giao, không phải vấn đề nghĩ. Đây là một quy trình thực tế để đọc prompt vào các lane agent song song trên máy Mac, kèm những giới hạn thành thật. Nếu bạn chưa đọc Điều khiển Claude Code bằng giọng nói, bài đó nói về những điều cơ bản với một lane; bài này giả định bạn đã chạy nhiều hơn một.

Vì sao nhiều lane song song lại trừng phạt riêng việc gõ phím

Một prompt có ba loại chi phí: hình thành nó, giao nó, và hồi phục sau đó. Hình thành là điều không tránh khỏi và chủ yếu diễn ra trong đầu bạn. Giao nó, khi bạn gõ, nghĩa là chuyển tiêu điểm sang terminal của agent, tìm dòng nhập, gõ bốn mươi đến tám mươi từ, rồi nhấn Enter. Hồi phục nghĩa là quay lại việc bạn đang làm trước khi agent hỏi.

Với một lane duy nhất, chi phí giao rất nhỏ vì nhiều khả năng bạn vốn đã nhìn vào terminal đó. Với nhiều lane song song, gần như không bao giờ. Lane một hỏi một câu trong lúc bạn đang đọc diff của lane hai. Câu hỏi dễ; câu trả lời chỉ một câu. Nhưng trả lời nghĩa là rời cái diff, và khi quay lại, bạn phải đọc lại ba mươi dòng cuối để tìm chỗ mình đang dừng.

Nhân lên với mỗi lần đổi hướng, mỗi câu "ừ, tiếp đi", mỗi câu "không, file kia", và phần hao phí cứ dồn lại. Các lane song song thất bại không phải vì agent chậm. Chúng thất bại vì bạn trở thành cái đường truyền thông điệp, và một đường truyền phải di chuyển vật lý giữa các cửa sổ thì độ trễ khủng khiếp.

Giọng nói xoá gần hết chi phí giao. Bạn giữ mắt trên cái diff, giữ một phím, nói câu đó, thả ra. Chữ rơi vào ô nhập của agent. Bạn chưa từng rời đi.

Cách thiết lập chạy được

Đây là cách thiết lập, cố tình để cho nhàm chán.

Phím tắt, không phải cửa sổ. Keebye nằm ở thanh menu và lắng nghe một phím tắt kiểu giữ hoặc bấm (mặc định là Command phải; Fn và Option phải là hai lựa chọn khác, còn Escape huỷ lần đọc đang chạy). Không có cửa sổ ứng dụng nào để mở, không có chế độ nào để bước vào. Giữ, nói, thả. Điều này quan trọng hơn nghe tưởng: một công cụ đọc chính tả cần cửa sổ riêng thì cũng chỉ là thêm một lane nữa.

Chèn vào ô đang có tiêu điểm. Bản ghi được chèn ngay chỗ con trỏ. Mặc định là dán, có chia nhỏ theo kiểu hiểu terminal để một prompt dài không làm tràn shell. Nếu bạn chạy agent trong tmux hoặc qua SSH, nơi việc dán hoạt động tệ, có một chế độ gõ tuỳ chọn bơm chữ vào bằng các phím Unicode; đọc chính tả sống sót trong terminal giải thích khi nào nên bật nó.

Theo lô, không phải theo dòng chảy. Keebye chuyển giọng thành chữ khi bạn thả phím, như một lần phát ngôn. Bạn sẽ không thấy chữ hiện ra trong lúc nói. Với việc soạn prompt, đây là đánh đổi đúng: bạn muốn cả câu rơi xuống một lượt, đã được dọn sạch, thay vì nhìn nó hiện dần từng chữ trong khi ô nhập của agent đã có sẵn nửa ý nghĩ.

Mọi thứ chạy ngay trên máy. Việc nhận dạng chạy cục bộ (một mô hình mặc định tinh chỉnh cho tiếng Anh, hoặc một mô hình 25 ngôn ngữ nếu bạn chọn dùng). Sau khi tải mô hình xong, nó chạy được với Wi-Fi tắt. Với việc ra prompt cho agent, điều này ít mang tính trình diễn quyền riêng tư mà chủ yếu là độ trễ: không có vòng đi về máy chủ, nên một prompt ngắn gần như sẵn sàng ngay khi bạn thả phím.

Một nhịp chuyển lane

Quy trình cuối cùng trụ lại có ba thói quen.

Mắt ở lại lane cần phán đoán. Ở bất kỳ thời điểm nào, có một lane là nơi sự chú ý của bạn thuộc về, thường là một diff hoặc kết quả test. Đó là lane bạn đọc. Các lane còn lại chỉ nhận những chỉ dẫn ngắn bằng lời. Khi lane hai cần một quyết định, bạn liếc qua, bấm vào ô nhập của nó, giữ phím, nói ra quyết định, thả, rồi bấm quay lại. Cú bấm chuột là chi phí cơ học duy nhất; bản thân câu nói thì miễn phí.

Prompt được nói thành câu hoàn chỉnh. Agent xử lý câu hoàn chỉnh tốt hơn những mẩu rời rạc kiểu điện tín, và đọc chính tả tạo ra câu hoàn chỉnh một cách tự nhiên vì đó là cách người ta nói. "Hoàn tác thay đổi schema nhưng giữ lại việc đổi tên API, rồi chạy lại migration và cho tôi xem kết quả" là một prompt nói ra rất ổn. Gõ tay thì mệt.

Từ đệm bị bỏ, nghĩa thì không. Phần dọn dẹp của Keebye mặc định chạy theo quy tắc: nó bỏ "ừm", "à", từ lặp, và để nguyên cách diễn đạt của bạn. Có một tuỳ chọn đánh bóng bằng LLM cục bộ ngay trên máy cho câu gọn hơn, kèm một chốt chặn độ trung thực sẽ quay về bản ghi nguyên văn khi bản đã đánh bóng có dấu hiệu mất token nặng, phình ra hoặc lặp. Chốt chặn đó là một phép suy đoán, không phải kiểm tra ngữ nghĩa: nó không xác nhận rằng bản đã đánh bóng giữ đúng ý bạn hay giữ đúng một phủ định. Khi ra prompt cho agent, hầu hết mọi người để tắt phần đánh bóng; bản ghi nguyên văn đúng là thứ bạn đã nói, và đó là thứ bạn muốn agent chạy.

Giọng nói hợp với việc gì, lane này qua lane khác

Không phải prompt nào cũng nên nói ra. Sau vài tháng, sự phân chia đại khái như sau.

Đổi hướng và tiếp tục: luôn dùng giọng nói. "Cứ tiếp đi." "Không, cái config kia." "Thêm test cho trường hợp rỗng rồi chạy lại." Đây là những prompt nhiều nhất trong một phiên chạy song song và tất cả đều dài đúng một hơi thở.

Nhận xét review: chủ yếu dùng giọng nói. Đọc một diff rồi kể ra chỗ sai của nó là việc rất tự nhiên. "Vòng retry nuốt mất lỗi; ghi log trước khi sleep, và giới hạn năm lần thử." Đọc chính tả bắt được đúng nhịp nói trong lúc mắt bạn vẫn ở trên code.

Bản giao việc ban đầu: pha trộn. Một bản brief dài, có cấu trúc, kèm đường dẫn file và ràng buộc thì vẫn nên gõ, hoặc đọc ra bản thô rồi sửa. Giọng nói ổn cho phần văn xuôi; các định danh chính xác thì gõ dễ hơn. Từ điển tuỳ chỉnh giúp ở chỗ này: thêm tên module và thuật ngữ hay lặp của dự án một lần, chúng sẽ thôi bị nhận thành từ tiếng Anh gần giống nhất.

Bất cứ thứ gì có code: gõ tay. Đọc chính tả một biểu thức chính quy là trải nghiệm tệ. Hãy đọc phần chỉ dẫn ("viết một regex khớp với header phiên bản"), đừng đọc bản thân sản phẩm.

Những giới hạn thành thật

Một số là của Keebye; một số là của cả loại công cụ này.

Độ trễ ở lần đọc đầu tiên. Micro khởi động sau lần đọc đầu tiên trong phiên và từ đó giữ một vùng đệm 500 ms phía trước. Lần giữ phím đầu tiên trong ngày vẫn có thể phải trả cái giá khởi động luồng, và một từ nói ra trước khi vùng đệm kịp hoạt động có thể bị cắt. Vì sao các ứng dụng đọc chính tả nuốt mất từ đầu tiên nói về cơ chế này.

Độ chính xác với định danh. Tên biến kiểu snake case và các từ viết tắt nội bộ là chỗ mọi mô hình giọng nói đều vất vả. Từ điển làm giảm chuyện đó, nhưng không xoá bỏ được. Hãy đọc lại prompt trước khi nhấn Enter với bất cứ thứ gì có tính phá huỷ.

Ô nhập bảo mật. Keebye từ chối chèn chữ vào ô mật khẩu và ô nhập bảo mật. Điều này là cố ý và thỉnh thoảng gây bất tiện khi một terminal đang hỏi passphrase.

Không có lệnh bằng giọng nói. Không có từ vựng kiểu "xuống dòng" hay "chọn tất cả". Keebye là công cụ đọc chính tả, không phải lớp điều khiển bằng giọng nói. Việc chuyển giữa các lane vẫn là một cú bấm chuột hoặc một phím tắt.

Chỉ có macOS. Bản dựng cho Windows chưa phát hành.

Đi tiếp từ đâu

Nếu các agent của bạn chủ yếu sống trong một editor, hướng dẫn cho Cursor và Claude Code có phần chi tiết theo từng công cụ. Nếu bạn đang chọn giữa các ứng dụng đọc chính tả cho quy trình này, Keebye vs Superwhisper là một so sánh thành thật, có nói cả chỗ Superwhisper hợp hơn.

Bản rút gọn của tất cả những điều trên: các agent song song không cần bạn gõ nhanh hơn. Chúng cần bạn thôi làm cái chặng chậm nhất giữa chúng. Giữ mắt ở lane cần phán đoán, và nói với những lane còn lại.