Bản đọc chính tả của bạn không nên tự dưng biến mất
Bạn đọc ý dài, chèn văn bản thất bại, chữ mất sạch. Vì sao app đọc chính tả làm mất lời bạn và lịch sử cục bộ chỉ gồm văn bản mà Keebye giữ lại.
Chín mươi giây đúng-y-như-tôi-muốn — một mô tả PR đầy đủ, một câu trả lời cẩn thận cho khách hàng — rồi một chuyện nhỏ nào đó trục trặc ngay khoảnh khắc chèn văn bản. Cửa sổ đích không đang focus. Cú dán không ăn. App bị nấc. Và văn bản thì đơn giản là mất. Không được lưu ở đâu cả. Không nằm trong bộ đệm nào. Mất. Bất kỳ đường xử lý đọc chính tả nào coi khâu chèn văn bản là bản sao duy nhất của bản chuyển văn bản đều có kiểu hỏng này.
Cái đến sau đó là một kiểu tức giận rất cụ thể và có vẻ quá mức, và tôi nghĩ nó chính đáng. Vấn đề không phải mấy giây bị mất. Vấn đề là bạn đã làm xong phần việc của mình — bạn đã hình thành ý tưởng, bạn đã nói nó ra hay, cái máy thậm chí đã chuyển đúng thành văn bản — rồi công cụ hủy hoại kết quả chỉ vì một trục trặc ở khâu giao hàng. Lần nói thứ hai không bao giờ hay bằng lần đầu. Ai từng đọc lại một đoạn văn theo trí nhớ đều biết bạn không tái tạo được nó; bạn chỉ tạo ra một phiên bản họ hàng nhạt hơn.
Chính tôi cũng từng mất những lượt đọc như vậy, với các công cụ khác, trước khi Keebye tồn tại. Đó là một trong những tình huống khẩn cấp nhỏ mà app này được xây quanh.
Vì sao văn bản đã đọc lại đơn giản biến mất?
Đây không phải lỗi của riêng nhà cung cấp nào. Đó là một quyết định thiết kế ở tầm cả nhóm sản phẩm, và đáng để hiểu vì sao cả ngành lại chọn như vậy.
Một app đọc chính tả là một cái ống, không phải một trình soạn thảo. Lời nói đi vào đầu này; văn bản đi ra đầu kia, vào cửa sổ của một app khác — một terminal, một ô Slack, một Google Doc. Nó không có tài liệu của riêng mình, và đó chính là thứ khiến những công cụ này vô hình và nhanh. Nhưng nghĩa là bản chuyển văn bản thường chỉ tồn tại đúng một khoảnh khắc: lúc chèn. Và khâu chèn là bước mong manh nhất trong toàn bộ đường xử lý. Nó phụ thuộc vào cửa sổ nào đang focus tại mili-giây giao hàng, vào việc clipboard không bị một app khác giành mất, vào việc quyền Trợ năng có đang vui vẻ hay không, vào việc app đích có chấp nhận đầu vào mô phỏng hay không. Khi bất cứ điều nào trong số đó hỏng, một cái ống thuần túy chẳng có gì phía sau. Nước đã đổ ra sàn.
Cũng có một lý do có nguyên tắc khiến các công cụ ngại giữ bản sao: một bản ghi mọi thứ bạn từng đọc ra là dữ liệu nhạy cảm. Những lượt đọc của bạn là tin nhắn của bạn, prompt của bạn, những quyết định còn nửa vời của bạn. Một nhà cung cấp lưu chúng lại — nhất là ở đâu đó gần đám mây — đã tạo ra một khoản nợ trách nhiệm, và cách dễ nhất để né khoản nợ đó là không giữ gì cả. Người dùng thừa hưởng sự thận trọng đó dưới dạng tính phù du: dưới góc nhìn nhà cung cấp, lượt đọc chính tả an toàn nhất là lượt chưa bao giờ tồn tại.
Tôi hiểu logic đó. Tôi chỉ nghĩ nó tối ưu cho nhầm bên. Kiểu hỏng của việc giữ lịch sử cục bộ là một tệp trên ổ đĩa của chính bạn. Kiểu hỏng của việc không giữ gì là công việc của bạn bốc hơi vì một cửa sổ mất focus.
Keebye giữ lại cái gì, và giữ ở đâu
Nên Keebye có giữ một lịch sử, bật sẵn theo mặc định, và đây chính xác là ý nghĩa của điều đó — không hơn, không kém.
Khi lịch sử được bật, mọi lượt đọc chính tả hoàn tất đều được ghi vào một cơ sở dữ liệu SQLite cục bộ trên máy Mac của bạn (rusqlite, chế độ WAL, dành cho ai quan tâm tới phần ruột). Tệp nằm trong thư mục app-support — com.keebye.app/keebye.db — và nó không bao giờ rời khỏi máy. Không có đồng bộ, không có tải lên, không gắn với tài khoản nào. Nó là một tệp, trên ổ đĩa của bạn, thuộc về bạn.
Việc khôi phục được thiết kế quanh hai cách bạn thật sự mất văn bản. Trường hợp phổ biến — khâu chèn vừa mới thất bại, một giây trước — có đường nhanh nhất: menu trên menu bar có mục Copy Last Dictation. Nhấp vào đó, lượt đọc gần nhất của bạn đã nằm trên clipboard, dán nó vào chỗ lẽ ra nó phải tới, rồi đi tiếp. Trường hợp hiếm hơn — “hôm thứ Ba tôi có đọc một thứ và giờ tôi cần lại nó” — đi qua Dictation History…, một cửa sổ với danh sách đầy đủ: có thể tìm kiếm, có nút xóa từng mục và một nút xóa sạch cho khi bạn muốn dọn trắng.
Thời gian lưu là 30 ngày, được thực thi tự động. Việc dọn dẹp chạy khi cơ sở dữ liệu mở lên và chạy lại sau mỗi lần chèn, nên cửa sổ 30 ngày là 30 ngày thật, không phải “30 ngày, đại khái, khi nào chúng tôi rảnh”. Và nếu bạn muốn kiểu hành vi phù du cũ — một số người nên như vậy, tôi sẽ nói tới họ — thì lịch sử là một cài đặt (history_enabled), và tắt nó đi nghĩa là không có gì được ghi lại cả.
Chỉ văn bản. Không bao giờ có âm thanh.
Phần tôi quan tâm nhất là những gì lịch sử không phải. Nó chỉ có văn bản. Schema lịch sử của Keebye không có cột âm thanh — không phải một cài đặt lưu âm thanh mặc định tắt, mà là không có cột nào. Bản thân các bản ghi âm không bao giờ được lưu. Điều đó nằm trong cấu trúc, và là có chủ ý: một bản chuyển văn bản ghi “trả lời Andrei rằng cuộc migration trễ một tuần” đã đủ nhạy cảm; âm thanh giọng bạn nói ra câu đó, kèm dấu thời gian, là một loại hiện vật ở cấp độ khác, và tôi không muốn app có khả năng tích lũy nó.
Còn một sắc thái nữa quan trọng hơn độ dài của nó: nếu bạn đọc chính tả vào một trường bảo mật — một ô kiểu mật khẩu — lịch sử không ghi lại. Đúng cái nơi mà ngay cả một dấu vết văn bản cũng là sai thì cũng là nơi duy nhất chúng tôi không giữ dấu vết nào.
Đây cũng là cùng một tư thế với phần còn lại của app — việc chuyển giọng nói thành văn bản chạy ngay trên máy, chúng tôi đã viết về nó trong ngữ cảnh đọc chính tả bằng ngôn ngữ của chính bạn — nhưng lịch sử là nơi tư thế đó bị thử thách, vì lịch sử là chỗ duy nhất Keebye lưu lại lời của bạn. Cục bộ, chỉ văn bản, tự xóa: đó là hình dáng mà tôi thấy xứng đáng để bật sẵn theo mặc định.
Những giới hạn trung thực
Phần trung thực, như thường lệ.
Bạn không nghe lại được. Việc chỉ giữ văn bản có hai mặt. Nếu phần chuyển văn bản sai — model nghe nhầm một cái tên, làm hỏng một con số — thì lịch sử trung thành lưu lại đúng văn bản sai đó, còn phần âm thanh có thể phân xử tranh cãi thì đã mất theo chủ ý. Với hầu hết các tình huống khôi phục, điều này không quan trọng; cái hỏng là khâu chèn, không phải bản chuyển văn bản. Nhưng nếu bạn muốn lịch sử đọc chính tả làm kho lưu ghi âm, thì nó không phải thứ đó, một cách có chủ ý.
Ba mươi ngày là ba mươi ngày. Lịch sử là lưới an toàn, không phải kho lưu trữ. Nếu một lượt đọc còn quan trọng sau một tháng, nhà của nó là cái tài liệu bạn đã đọc nó vào, chứ không phải cơ sở dữ liệu của app. Việc dọn dẹp không hỏi ý bạn.
Chỉ cục bộ nghĩa là chỉ cục bộ. Lịch sử của bạn không đi theo bạn qua các máy khác. Lượt đọc bạn làm trên máy để bàn không khôi phục được từ laptop. Tôi đang trình bày điều này như một tính năng về quyền riêng tư, và nó đúng là vậy — không có gì đồng bộ vì không có gì được truyền đi — nhưng tôi sẽ không giả vờ rằng nó không đồng thời là một giới hạn. Nó là cả hai. Bạn nên biết nó là cái nào với mình trước khi dựa vào nó.
Và trường hợp ranh giới: nếu bạn là người mà mô hình rủi ro nói rằng không được để lại dấu vết nào, hãy tắt lịch sử đi. Chỉ một cài đặt, và app tôn trọng nó hoàn toàn. Bật sẵn là lựa chọn đúng với đa số người dùng, những người thà lấy lại được đoạn văn của thứ Ba tuần trước; nó không nên trở thành cái bẫy cho số còn lại.
Công việc không nên có một điểm hỏng duy nhất
Lý do sâu xa hơn khiến tính năng này tồn tại: tôi chạy ngày làm việc của mình như những lane song song — các agent đang build ở vài cửa sổ, con người đang chờ ở những cửa sổ khác — và giọng nói là kênh nạp việc cho tất cả. Quy trình đó là toàn bộ tiền đề của bài điều khiển Claude Code bằng giọng nói. Một kênh thỉnh thoảng tự hủy hàng hóa của chính nó thì không phải kênh để bạn xây cả ngày làm việc lên trên. Lập trình viên trông chờ có đường khôi phục — undo, log, reflog, thùng rác — vậy mà nhiều quy trình đọc chính tả chẳng đưa ra thứ tương đương nào khi khâu chèn văn bản thất bại.
Nếu bạn đang cân nhắc các công cụ trong nhóm này, các bài so sánh của chúng tôi nói trung thực về chỗ những sản phẩm khác tỏa sáng: Keebye vs Superwhisper và Keebye vs Wispr Flow. Và chuyện văn bản biến mất có một lời than anh em — từ đầu tiên của lượt đọc bị nuốt mất trước khi micro kịp thức dậy — chúng tôi đã viết về nó trong bài vì sao các app đọc chính tả nuốt mất từ đầu tiên của bạn.
Keebye đang trong giai đoạn truy cập sớm cho macOS. Hãy bắt đầu bản dùng thử miễn phí bên dưới, đọc một đoạn văn, cố tình để trượt cửa sổ đích, rồi dùng Copy Last Dictation để lấy lại văn bản. Focus sai vẫn tốn của bạn một bước khôi phục; nó không còn phải tốn cả ý tưởng nữa.
Làm cho lượt đọc dài tiếp theo có thể khôi phục được
Bắt đầu bản dùng thử miễn phí và thử Copy Last Dictation trước khi giao cho giọng nói một mô tả PR dài.
Start free trialEarly access: we'll email you the moment the macOS build is ready — your 14 days start when you first sign in from the app.
Đọc tiếp
Vì sao các app đọc chính tả nuốt mất từ đầu tiên của bạn
Nhấn hotkey, nói, từ đầu tiên bị cắt. Vì sao khởi động nguội cắt mất từ, và micro đã làm nóng cùng 500 ms pre-roll giúp khắc phục ra sao.
Đọc prompt cho các agent song song, lane này qua lane khác
Chạy hai ba agent lập trình cùng lúc thì soạn prompt thành nút thắt. Quy trình dùng giọng nói để nạp việc cho các lane song song mà không rời lane đang làm.
Claude Code bằng giọng nói: xây dựng trên lane song song
Agent lập trình AI biến gõ phím thành nút thắt. Quy trình thực tế để đọc prompt, review và lệnh đổi hướng cho các lane agent song song trên macOS.