有用的 GitHub Issue，最好在故障还留在屏幕上时写。操作顺序还记得，异常的控制台行也看得见，哪个临时方案失败、最近一次发布后哪里发生了变化，都能说清楚。
可是一打开 Issue 编辑器，报告往往只剩下“Safari 无法登录”。
语音输入解决的是这类信息流失。它不会自动把模糊观察变准确，但能让你在证据、顺序和限制被压缩成标题加一句话之前，更轻松地把已经知道的内容保留下来。
GitHub Issue 可以跟踪错误、改进、任务和其他项目事项。正文使用 GitHub Flavored Markdown，支持标题、任务列表、链接和代码块。因此，Issue 不只是留言，而是一份让其他人可以检查、复现并判断何时关闭的小型工作记录。
固定结构交给模板，变化的事实用语音补充
很多团队需要的栏目早已固定：
- 摘要
- 复现步骤
- 预期结果
- 实际结果
- 环境
- 验收条件
输入这些标题并不费力。真正耗时的是回忆每一栏下面发生了什么。
更实用的分工是把 Markdown Issue 模板放在仓库里，再用语音填入每次变化的证据。GitHub 支持 Markdown 模板和 Issue 表单，所以打开编辑器时，稳定的问题已经可以出现。语音负责补充今天的事实：第四次点击、浏览器版本、旧令牌、意外出现的页面，以及修复后应通过的测试。
模板还能防止口述变成长而散的报告。结构由模板维持，录音只填空白。
复现步骤需要顺序，也需要明确的偏离点
“上传有时失败”会留下太多未知。是什么文件？在哪个页面？登录前还是登录后？重试是否有效？失败时屏幕上出现了什么？
按顺序说出步骤，并标明观察到的行为第一次偏离预期的位置：
- 从已知状态开始。
- 说出执行的操作。
- 说明关键操作后出现了什么。
- 在第一个错误结果处停下。
- 补充故障是否可以重复。
例如：
从一个已登录且没有头像的账户开始。打开设置，选择大于五兆字节的 PNG，然后只点击一次保存。进度条达到百分之百后，没有错误提示，页面却恢复到原头像。刷新后仍看不到新图片。换成更小的 PNG 重复操作则成功。
这一段包含对照情况、可见结果和可重复性。赶时间打字时，这些信息最容易先被删掉。
把观察和解释分开
如果把推测写成证据，Issue 会更难调查。
“缓存失效逻辑坏了”可能正确，但这是诊断。“上传接口返回 200 后，第二个请求仍返回旧头像 URL”才是观察。即使最终原因在别处，后一句仍然可以验证。
口述时，可以直接标出边界：
- 用“我观察到……”描述可见行为。
- 用“我原本预期……”描述依赖的约定。
- 用“目前的猜测是……”描述假设。
- 用“尚未确认的是……”描述开放问题。
说话时很容易把自己的解释一起带进去。把它明确称为猜测，即使后来证明错误，Issue 仍然有用。
精确字符串用键盘输入，它们的意义用语音说明
语音适合讲时间顺序和原因。不适合每个字符都重要的内容。
下面这些内容应使用键盘输入或直接粘贴：
- 提交哈希和 Issue 编号
- 文件路径和标识符
- 带查询参数的 URL
- Shell 命令和正则表达式
- 堆栈跟踪和日志片段
- 只差一位数字的版本号
日志和代码不要朗读，直接放进围栏代码块。GitHub 会渲染代码块，添加语言标识后还能显示语法高亮。空格、标点和行顺序都可能构成证据，所以短小的原始片段通常比口头改述更可靠。
然后再用语音说明精确字符串周围的上下文：日志来自哪里，哪个操作生成了它，哪一行最重要。键盘保留证据，语音保留意义。
验收条件给 Issue 一个可检查的终点
Issue 可以准确描述故障，却仍然难以关闭。“修复头像上传”并没有说明成功究竟是显示错误、接受更大文件、自动重试，还是立即更新图片。
加入修改后可以检查的验收条件。GitHub 任务列表使用 Markdown 复选框，因此工作进行时，条件也能一直保持可见。
以上传示例来说：
- 支持的图片无需手动刷新即可显示新头像。
- 不支持的文件大小会显示明确错误。
- 上传失败不会替换现有头像。
- 回归测试覆盖发生故障的大小边界。
口述这些条件往往更容易，因为你只需回答一个直接问题：“看到什么结果，我才会同意问题已修复？”除非实现方式本身就是要求，否则清单应描述结果，而不是指定做法。
Clean 忠实保留报告，Raw 保留整段发言
TalkTalkType 会在按住 Option-Space 时录音，松开后把结果送回录音开始时获得焦点的输入框。在 GitHub Issue 编辑器里，你可以一边看仓库上下文、模板和已有评论，一边说话。
Clean 会进行忠实的轻度整理。它保留所有说出的词、顺序、语体和原本想要的简短程度，只删除意义明确且不会改变内容的犹豫词，并返回一行文本。它不会悄悄把报告改成另一种错误模板，也不会补造缺失事实。
Raw 不做整理，会保留包括错误开头在内的完整转写。准备大幅手动编辑，或内容中有容易被整理步骤改动的少见专有名词时，可以使用 Raw。
无论哪种模式，都不能让精确技术文本适合直接口述。提交前读一遍草稿，把不确定的版本、名称、路径和数字替换成复制的原值。可在 Mac 任意应用中使用的听写说明了聚焦输入框投递和剪贴板备用路径。
输入方便，不代表秘密信息适合进入 Issue
错误报告可能位于公开仓库、公司的私有仓库，或未来会公开的项目中。输入目标本身就是数据边界的一部分。
不要口述 API 密钥、会话 Cookie、访问令牌、客户隐私数据或生产凭据。粘贴日志时也要先脱敏。语音输入只降低录入成本，不会改变最终 Issue 的可见范围。
TalkTalkType 不会把音频、原始转写或整理后文本保存为服务端历史记录，但创建 Issue 时，最终文本会提交给 GitHub。Mac 上的私密听写介绍了此前各阶段中录音和文本的流转。
从那个本来会被拖延的 Issue 开始
趁故障仍可复现，打开仓库的 Issue 模板。标题和精确标识符用键盘输入，然后一次说完起始状态、按顺序执行的操作、第一个错误结果、可重复性、预期行为和当前不确定之处。
读一遍，粘贴最小但有用的日志片段，再加上定义完成状态的清单。
目标不是写出更长的 Issue，而是把当时的信息保留到足够完整，让其他人在现场已经消失后仍能继续行动。