刚装好 SayIt，先别打开一段长文口述。更省时间的路径是先用三句结构不同的短句跑一遍最小测试，确认它把你的口语改成书面语时会动到什么程度，再决定长文能不能直接口述。判断依据主要来自三处：应用能否正常启动并录到音、短句的书面化边界在哪、连续口述时断句和去重会不会退化。任一处对不上，长文返工的概率就会明显上升。

SayIt 的书面化通常介于纠错、精简和重写之间，具体落在哪一档取决于模型配置和你的口述习惯，需要结合环境确认。建议装好后先做启动与录音验证，再用陈述、否定、带数字三句短样本逐句对照口述原文与输出，最后录一段 30 秒连续口述看断句和重复处理是否退化。三句测试通过、否定词与数字未被误改，再投入长文口述；否则先列提纲、按点分段口述更稳。

安装后先确认应用能正常启动和录音

这一步是为了排除安装或权限问题，避免把启动失败、录不到音误判成改写效果差。若项目提供 CLI，先用 `--help` 看可用参数，再决定用什么方式录音和输出；参数名以本机 `--help` 输出为准，不要照抄示例。

sayit `--help`
sayit `--version`
# 若支持设备枚举，名称以 `--help` 输出为准
sayit `--list-devices`

若只有图形界面，建议在首次录音前逐项确认：系统麦克风权限是否已授予、输入设备是否选中了正确的那一个、默认采样率与声道是否被应用接受、录音快捷键是否与系统或其他软件冲突、输出目录或历史记录位置是否可写。确认后录一段 5 秒左右的自测音并回放，能听到自己的声音再做后续测试。音频都进不来时，改写质量无从谈起。

设计三句话分别覆盖陈述、否定和带数字的场景

三句话不需要长，但结构要不一样，目的是用最小样本覆盖最容易出错的书面化边界。可以先用下面三句，也可以按自己的业务替换实体词，替换后要保证仍然分别属于陈述、否定、带数字三类。

• 陈述句："明天下午三点我在会议室和张工对一下接口文档。"观察点：时间、人名、动作是否保留，语序是否被调整，是否被加上原文没有的连接词。
• 否定句："这次不改登录流程，只调整提示文案，先不要合并到主干。"观察点："不""不要""只""先"这类否定和限定词是否被吞掉、弱化或改成正向表达。
• 带数字句："把超时从 30 秒改成 45 秒，重试次数保持 2 次。"观察点：数字与单位是否被改写、换算或丢单位，量词是否被替换。

三句分别录，不要连在一起说，这样才能定位是哪个类型的句子被改坏了。每次录完先保存输出原文，不要急着编辑。

逐句对比口述原文与书面化输出

把口述原文和 SayIt 输出并排放，逐项判断它是纠错、精简还是重写，从而确定自己的可接受范围。建议按下表记录，"改写结论"一栏由你自己填：

只要否定句出现意思翻转、带数字句出现单位丢失或数值被改，就属于不可接受，与你是否喜欢它的文风无关。若只是补标点、去口头语、把"对一下"改成"对齐"，通常还在可接受范围内。这一步的目的不是评价好坏，而是画出你自己的边界线。

再录一段 30 秒连续口述验证稳定性

短句通过后，连续口述才可能暴露问题：分句位置漂移、重复词被保留两次、长句中段被整段重写。测试时可以口述下面这类带口语词和插入语的样本，实际内容可替换为自己的工作场景：

我先说下背景，昨天测试环境的接口返回比较慢，大概三到五秒；
然后，那个，我把日志级别调到 debug 看了一次，
发现是下游超时，不是我们这边的问题；
所以这次先不改代码，先把超时时间和重试次数记下来。

录完对照原文，用下面几项记录：分段位置是否落在语义边界上、"那个"这类填充词是否被清掉、"三到五秒"这类约数是否被改成精确值、"不是我们这边的问题"这类否定是否保留、有没有出现原文没说过的新句子。连续口述里出现大段重写或重复句被保留两次，说明它更适合短段落输入。

给出继续用长文口述还是先列提纲的判断标准

用测试结果决定工作流，不要凭感觉直接开长文。可以通过的标准通常是这三条：三句样本里否定词和限定词没有被翻转或删除；数字与单位与口述一致，或有改动但方向可解释且你能接受；30 秒连续口述只做了断句、去填充词和轻度标点整理，事实顺序未变。三条都满足，可以直接口述长文，仍建议按自然段分批录、每段回读一次。

不通过的标准同样是三条：出现新增事实、否定被改成正向、关键限定词被删除；数字被换算或丢单位，导致你必须逐句核对；连续口述出现整段重写、重复句残留或分段打乱。命中任意一条，就先列提纲，把长文拆成要点，再按点短句口述并逐条拼接。不同语言、不同领域术语的表现可能不同，换场景后建议重新跑一次这三句测试。