下午四点，PR 已经改到第三轮。你看到一段缓存逻辑可能导致旧数据被重复读取，评论框也打开了，但手放到键盘上时，真正难写的不是技术判断，而是怎么把判断表达清楚。
只写“这里有问题”，对方不知道问题发生在哪。写成“这样写不对”，语气又容易变成对人的否定。想解释完整，就得补上触发条件、可能影响、修改方向和验证方式。一条看似不长的 Review 评论，背后其实包含了一次小型技术说明。
这种场景适合先说，再整理。
在 GitHub、GitLab 或 IDE 的评论输入框里，把光标放好，按住 Fn，直接把脑子里的判断讲出来。例如：“这里读取缓存之后没有校验版本号。如果用户刚完成配置更新，当前请求可能继续拿到旧值。建议在命中缓存时同时比较配置版本，不一致就回源，并补一个配置更新后立即读取的测试。语气帮我写得克制一点，不要像是在否定原来的实现。”
口述时不必一开始就组织成正式评论。技术人员更自然的表达往往是跳跃的：先想到风险，再补充复现条件，接着想到测试，说到结尾才意识到语气需要调整。SaySo 做的不是替你决定代码该怎么改，而是把这些已经存在的判断整理成一段可以直接继续编辑的文字。
整理后的评论可以接近这样的表达：“这里可能需要补充版本校验。当前逻辑在缓存命中后直接返回；如果配置刚刚更新，本次请求仍可能读取旧值。可以考虑在命中缓存时比较配置版本，不一致时回源，同时增加一条配置更新后立即读取的测试用例。”
这类写法比“这里有 bug”多了三个关键信息：问题在什么条件下出现，为什么值得改，以及建议如何验证。对提交代码的人来说，收到的是一条可执行意见，而不是一个需要重新猜测的结论。对 Reviewer 来说，也不用在评论框里反复删改语气，担心内容太硬或信息不全。
语音输入在这里的价值，也不是单纯把字打得更快。Code Review 的表达成本主要来自信息压缩：你需要把读代码时形成的一串判断，压缩成对方能准确理解、愿意继续讨论的评论。按 Fn 说出想法，让 SaySo 把口头表达整理成可用文字，省下的是这段来回组织的过程。
当然，不是每条评论都需要说。变量名拼错、少一个空值判断、格式需要调整，这些短意见直接打字更快。更适合口述的，是涉及上下文、边界条件、设计取舍，或者需要谨慎措辞的评论。内容越需要解释“为什么”，说出来通常越接近思考的速度。
Review 评论的目标不是证明谁判断得更快，而是让问题被看见，让修改能够继续推进。把技术判断说完整，再交给文字去保持克制，往往比在一句短评里同时处理逻辑和语气更轻松。
官网：SaySo - Mac 与 Windows AI 语音助手 | 语音转文字，效率提升10倍
邀请码：LW8J528A
