[polish] 上下文纠错不足导致 issue 被误写成 iOS

[appergb]

现象

• 用户口述开发语境内容时，明显错误的 ASR 文本仍会进入最终输出。例如用户说“提交 issues / 这些 issue”，最终可能被整理成 iOS。
• 用户期望 polish 阶段根据本段上下文判断词语是否识别准确，自动修正语音输入中的易错词，而不是把明显错误原样输出。
• 这次具体场景里，用户要求把若干问题“提交 issues”，但输出没有可靠保留 issue/issues 语义，甚至会把 issue 误判成 iOS。

代码证据

• openless-all/app/src-tauri/src/polish.rs:415 明确要求不引用“项目上下文、外部知识或模型记忆”。这能避免幻觉，但也削弱了开发语境下纠正 issue / iOS 这类同音或近音误识别的能力。
• openless-all/app/src-tauri/src/polish.rs:420 要求“中英混输、专有名词、产品名、代码 / 命令 / 路径 / URL、数字与单位、emoji 原样保留”。如果 ASR 已经把 issue 错成 iOS，这条规则会诱导模型保留错误结果。
• openless-all/app/src-tauri/src/polish.rs:196 的热词注入措辞是“仅当原始转写明显是其误识别时才纠正”，和 feat: polish 提示词词汇本注入措辞调整 — 当前太保守 #63 的问题一致，整体偏保守。
• openless-all/app/src-tauri/src/coordinator.rs:616-617 中 ASR raw transcript 直接进入 polish，没有独立的上下文纠错步骤。

影响

• 开发者口述 GitHub / CI / issue / PR / tag 等内容时，最终文本会出现八竿子打不着的词，降低语音输入可信度。
• 用户把 OpenLess 输出直接发给 AI 或粘贴到 GitHub 时，会把错误词带进后续工作流。
• 该问题会让“清晰结构”模式看起来结构正确，但关键术语错误，风险比普通错别字更高。

建议接受标准

• polish prompt 明确包含“ASR 上下文纠错”规则：当原始转写中出现和上下文明显不符的词时，可以基于本段上下文纠正为更合理的术语。
• 在开发语境中，“提交 issues / 创建 issue / GitHub issue / issue 列表”必须保留为 issue/issues，不能输出为 iOS。
• 在 Apple / iPhone / Xcode / 系统平台语境中，iOS 仍应保留为 iOS，不能机械替换成 issue。
• 为 issue vs iOS 增加 prompt 级或单元级回归用例，覆盖中文口述和中英混输。
• 若仅改 prompt 不稳定，应拆到独立纠错层实现，见后续 ASR/LLM 混淆词纠错任务。

TODO / 不确定项

• 需要确认主要修复放在 prompt、LLM 前置纠错层，还是二者结合。
• 需要补充更多真实 ASR 错词样本，例如 CI、PR、tag、release、workflow 等开发词汇。

[H-Chris233]

看来我们需要维护一份容易出错的词汇列表并喂给AI,否则仅凭语境很难使AI建立issues和iOS这两个相差极大的词的关系。

[H-Chris233]

热词机制已经完成了他的使命,这个issue可以关闭了