背景
词典「自动添加」不是随使用默默攒词，而是：
听写成功落字 →（可选）短时观察目标 App 内对手改 → 建议卡确认 → 写入词典（note = 从手改中自动收集）。
今日完整宿主手改观察 仅 macOS AX。watch_for_edits 在非 macOS 直接返回 None。Windows / Android 上「自动添加」筛选会长期为空，与 README「dictionary that learns」的产品叙述不对齐（文案已写 macOS-only，但 Win/Android 用户仍会看到空的「自动添加」筛选项）。
现状（源码）
| 环节 |
现状 |
| Core |
arm_edit_observation + EditObservationAdapter + PendingCorrection + accept_pending_correction 已抽象 |
| macOS |
AX 手改观察约 60s；需 cursor_context_enabled；确认卡约 10s |
| Windows |
host_document 明确无 UIA；watch_for_edits → None |
| Android |
无障碍服务已有，但只做粘贴焦点缓存 / 键盘悬浮窗，不做 baseline diff；IME「编辑结果」勾选加词已存在，未统一到「自动添加」筛选语义 |
| Linux egui |
Noop（L02） |
锚点：host_document/mod.rs、macos.rs、api.rs（arm_edit_observation）、VocabSuggestionCard.tsx、OpenLessAccessibilityService.kt、OpenLessImeService 编辑结果流程、native_bridge.rs spawn_add_vocabulary_word。
目标
- Windows / Android 尽量复现「落字后短时观察宿主改词 → 建议 → 确认入库」。
- 宿主观察不可行或覆盖不到时，提供 不依赖读宿主 的替代入库，仍走确认，不静默加词。
- 保持与 macOS 相同的隐私红线：密码框不读、可关、确认前不入库。
方案摘要（调研）
A. 宿主观察（对齐 macOS）
Windows（主候选）
- UI Automation：焦点 Edit 订
UIA_Text_TextChangedEventId（可加 Value 变更），读 Text/Value，复用 minimal_edit / is_vocab_worthy。
- 密码：
UIA_IsPasswordPropertyId 跳过。
- 风险：不能假设所有 provider 发全套事件；Chrome / Electron / Office / 自定义控件覆盖面需真机矩阵。
- 不推荐：TSF 作通用 60s 观察；进程注入；全局钩子。
Android（主候选）
- 扩展现有
OpenLessAccessibilityService：武装窗口内处理 TYPE_VIEW_TEXT_CHANGED（beforeText / getText）→ Core queue_pending_correction。
- 补强：API 33+ Accessibility
getSurroundingText。
- IME 用户：强化已有「编辑结果 → 勾选加词典」，统一
LEARNED_VOCAB_NOTE。
- 不推荐：截屏 OCR、无节制全文轮询。
两边继续接 EditObservationAdapter，失败则学不到、不阻断主链路。
B. 看不到宿主改词时的替代
| 路径 |
说明 |
| ASR 原文 ↔ 润色 diff |
跨平台易做；学的是模型改写，须过滤 + 确认 |
| 历史页内编辑 |
信号明确，不依赖辅助功能 |
| 选区语音改写前后 |
保真度高 |
| Android IME 编辑结果加词 |
已实现，统一 note 即可 |
| 显式「记住刚才的词」 |
兜底 |
建议优先级：选区/IME（有则用）→ 历史编辑 → ASR–润色 diff（严过滤）→ 显式入口。
产品开放点（需先定）
- 开关拆分：今日
cursor_context_enabled 同时管「读上下文给 LLM」与「手改观察」。Win 用户是否允许「只学词、不上传光标上下文」？
- Android 确认 UI：无桌面胶囊时，建议卡放 overlay / IME 条 / 其它？
- 纠正规则：
accept_pending_correction 目前只写词典，不写 RuleSource::Learned；Corrections 页 learned 筛选基本空置——是否另开？
- 能力文案：设置 / README 是否改为「支持的平台」并写清 Win/Android 实验范围与覆盖缺口？
接受标准（草案）
阶段 1 — 设计拍板
阶段 2 — Windows 宿主观察（若做）
阶段 3 — Android
阶段 4 — 替代路径（可选并行）
非目标
- 静默自动入库
- 进程注入 / 全局键盘日志 / 截屏 OCR 学词
- 本 issue 不要求 Linux egui 同期交付（现网 L02 Noop）
参考
- README：dictionary learns + cursor context macOS-only
- Microsoft：Edit control TextChanged / UIA events overview
- Android：
TYPE_VIEW_TEXT_CHANGED、canRetrieveWindowContent
- 本地调研草稿（若合入可链 docs）：
docs/win-android-vocab-auto-add-research.md
背景
词典「自动添加」不是随使用默默攒词，而是：
听写成功落字 →（可选）短时观察目标 App 内对手改 → 建议卡确认 → 写入词典（
note = 从手改中自动收集）。今日完整宿主手改观察 仅 macOS AX。
watch_for_edits在非 macOS 直接返回None。Windows / Android 上「自动添加」筛选会长期为空，与 README「dictionary that learns」的产品叙述不对齐（文案已写 macOS-only，但 Win/Android 用户仍会看到空的「自动添加」筛选项）。现状（源码）
arm_edit_observation+EditObservationAdapter+PendingCorrection+accept_pending_correction已抽象cursor_context_enabled；确认卡约 10shost_document明确无 UIA；watch_for_edits→None锚点：
host_document/mod.rs、macos.rs、api.rs（arm_edit_observation）、VocabSuggestionCard.tsx、OpenLessAccessibilityService.kt、OpenLessImeService编辑结果流程、native_bridge.rsspawn_add_vocabulary_word。目标
方案摘要（调研）
A. 宿主观察（对齐 macOS）
Windows（主候选）
UIA_Text_TextChangedEventId（可加 Value 变更），读 Text/Value，复用minimal_edit/is_vocab_worthy。UIA_IsPasswordPropertyId跳过。Android（主候选）
OpenLessAccessibilityService：武装窗口内处理TYPE_VIEW_TEXT_CHANGED（beforeText/getText）→ Corequeue_pending_correction。getSurroundingText。LEARNED_VOCAB_NOTE。两边继续接
EditObservationAdapter，失败则学不到、不阻断主链路。B. 看不到宿主改词时的替代
建议优先级：选区/IME（有则用）→ 历史编辑 → ASR–润色 diff（严过滤）→ 显式入口。
产品开放点（需先定）
cursor_context_enabled同时管「读上下文给 LLM」与「手改观察」。Win 用户是否允许「只学词、不上传光标上下文」？accept_pending_correction目前只写词典，不写RuleSource::Learned；Corrections 页 learned 筛选基本空置——是否另开？接受标准（草案）
阶段 1 — 设计拍板
阶段 2 — Windows 宿主观察（若做）
EditObservationAdapterWindows 实现（UIA），60s / 失焦 disarm，generation 屏障阶段 3 — Android
LEARNED_VOCAB_NOTE/ 词典筛选阶段 4 — 替代路径（可选并行）
非目标
参考
TYPE_VIEW_TEXT_CHANGED、canRetrieveWindowContentdocs/win-android-vocab-auto-add-research.md