讓電腦朗讀草稿,找出容易忽略的文字問題
Let your computer read your draft back to you
這篇教學介紹如何用文字轉語音朗讀草稿,找出默讀時容易忽略的文字問題。先用 Pandoc 將 Markdown 轉成純文字,再透過 macOS 的 say、Linux 的 espeak-ng 或 Windows PowerShell 朗讀;作者亦提供可重用的 listen 腳本。朗讀時可留意漏字、重複詞、過長句子和節奏問題,聽完後再集中修訂。
I can reread a paragraph five times and still miss the word I typed twice. My eyes know what I meant to write, so they fill in the gaps. My ears are much less forgiving. When I hear a draft read out loud, the clumsy sentences, the missing words and the three "really"s in a row are suddenly obvious.
Reading aloud myself works, but I tend to fix things as I go and lose the flow. Letting the computer do the reading is more honest. A text-to-speech voice reads exactly what is on the page, with no idea what I meant. Most systems already have one built in, so this costs nothing to try.
Turn the Markdown into plain text first
My drafts are Markdown files, and a speech engine will happily read every asterisk, link URL and heading marker if I let it. So the first step is to strip the formatting. Pandoc does this in one line:
pandoc draft.md -t plain -o draft.txt
The plain text output keeps the words and drops most of the syntax. Links become just their text, and emphasis markers disappear. Code blocks stay in, so for a technical post I either skip those parts while listening or accept a few odd seconds of the voice reading a command.
Let the voice read it
On macOS, the say command reads a file out loud:
say -f draft.txt
You can slow it down with -r, which sets the rate in words per minute:
say -r 160 -f draft.txt
On Linux, espeak-ng does the same job. It sounds more robotic, but for catching mistakes that doesn't matter much. Its -s option sets the speed, also in words per minute:
espeak-ng -s 150 -f draft.txt
On Windows, Windows PowerShell can use the built-in speech engine:
Add-Type -AssemblyName System.Speech
$voice = New-Object System.Speech.Synthesis.SpeechSynthesizer
$voice.Speak((Get-Content draft.txt -Raw))
If you'd rather not touch the command line at all, many editors and browsers have a "read aloud" option too. The tool matters less than the habit.
Put it in one small script
Since I do this for almost every piece, I keep a tiny script called listen in my path:
#!/usr/bin/env bash
# Read a Markdown draft out loud (macOS).
set -euo pipefail
tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT
pandoc "$1" -t plain -o "$tmp"
say -r "${2:-170}" -f "$tmp"
Run it as listen draft.md, or listen draft.md 150 for a slower pace. The temporary file is removed when the script exits, so nothing piles up in my drafts folder. On Linux, swap the say line for espeak-ng -s "${2:-170}" -f "$tmp".
What to listen for
I listen with the draft open and a pen, or at least a cursor, ready. These are the things that jump out most often:
- Missing or doubled words. "Save the the file" is invisible on screen and impossible to miss when spoken.
- Sentences that run out of breath. If the voice reaches the end of a sentence and I've forgotten how it started, the sentence needs splitting.
- Repeated words close together. Hearing "simple" three times in one paragraph is far more annoying than seeing it.
- Rhythm that never changes. Five sentences of the same length in a row sound flat, even if each one is fine on its own.
- Ambiguous words. If the voice stresses a word in a way that changes the meaning, a human reader might stumble on it too.
I don't stop the audio for every small thing. I make a quick mark and keep listening, then fix everything in one pass afterwards. Stopping constantly breaks the same flow I'm trying to hear.
Where it fits in my routine
Listening isn't my first edit. I do the structural work first: moving sections, cutting what doesn't belong, fixing the headings. Text-to-speech is for the late stage, when the content is settled and I want to catch the small things a spell checker won't flag because every word is spelled correctly.
It takes a few minutes per article. For something that catches mistakes my eyes have skipped over several times already, that's a trade I'm happy to make.
來源:DEV Community · dev.to