weihuo1988-svg 移动口述捕获
核心目标
把一段原始口述整理成可靠记录：
- 清理口述文本，不编造事实。
- 将内容拆成原子切片。
- 按类型和目的地分类每个切片。
- 将切片存入合适的项目文档。
- 识别具体日程安排，并在信息足够时创建手机提醒、日历事件或写入 Markdown 日程账本。
- 在政策允许时，抽取长期记忆候选并通过当前记忆机制写入。
做分类、路由或记忆抽取时，阅读 references/routing-and-memory.md。
完成标准
只有满足以下条件，任务才算完成：
- 口述中每个可用部分都被表示为切片，或被明确标记为不清楚。
- 每个已存储切片的目的地都来自证据，而不是为了方便随意选择。
- 长期记忆事实与项目笔记分开处理。
- 临时事件中嵌入的稳定事实已经被拆出；不要因为整句是短期状态，就漏掉其中的家庭关系、身份、偏好、重要日期等长期事实。
- 带有明确日期和时间的日程安排已经写入可用提醒系统或 Markdown 日程账本；如果缺少必填信息，已经向用户询问。
- 没有在缺少用户直接证据或当前政策不允许的情况下写入长期记忆。
- 如果用户在口述处理后指出执行问题，已经完成反思，并询问是否要基于该发现优化本 skill 或本次任务实际使用过的其他 skill。
- 最终回复说明已修改的文件、记忆更新和未解决的不确定点。
工作流程
1. 捕获并规范化
- 将 Codex 移动端语音转写视为初始文本。如果用户附上实际音频且有可用转写工具，先转写；否则，只有在没有可用文本时才询问用户补充转写。
- 保留用户原意和表达风格。只在上下文支持时，补充标点、段落，并修正常见语音识别错误、同音词、人名和项目名。
- 将“今天”“明天”“下周五”“那个纪念日”等相对日期，按当前系统日期和时区转换为具体日期。若日期仍有歧义，保留原词并标记。
- 对不确定词保留
[uncertain: ...]形式，不要悄悄猜测。
2. 切片
为每个原子想法、事件、任务、反思或长期事实创建一个切片。每个切片包含：
title：简短、可读的标题。type：参考分类中的类型标签。project_or_area：明确项目、推断项目或unrouted。date_context：可确定的日期或时间。content：用用户语言清理后的内容。actions：承诺、截止日期或后续动作。memory_candidate：yes、no或review。confidence：high、medium或low。
即使用户连续说成一段，也要拆开混合口述。 如果一句话同时包含项目笔记和长期个人事实，拆成多个切片。 如果一个临时事件中嵌入稳定事实，也必须拆开。例如“我爸爸妈妈回老家了”应拆成：
- 临时状态：父母回老家。
- 长期关系事实：用户有爸爸、妈妈。
如果切片是日程安排，补充识别以下字段：
event_title：日程标题。start_datetime：开始日期和时间，必须是具体时间。timezone：时区，默认使用当前系统时区。end_datetime或duration：结束时间或时长；缺失时可默认 1 小时，并在结果中说明。location、participants、notes、reminder：有则记录，缺失时不要臆造。
3. 分类并路由
按以下优先级选择目的地：
- 用户明确点名的项目或文档。
- 口述明显涉及的当前仓库或工作区。
- 文件名、标题或附近内容与切片类型匹配的现有项目文档。
- 项目明确但文档不明确时，使用项目本地收件箱，如
notes/voice-inbox.md。 - 如果项目和目的地都不清楚，问一个简短问题。
日程安排优先进入提醒/日程处理流程；只有在用户还要求记录笔记时，才额外写入项目或个人文档。
使用 rg --files 和有针对性的读取来发现可能文档，再创建新文件。
优先追加到已有的笔记、日记、想法或收件箱文件，不要覆盖或重组无关内容。
4. 存储项目笔记
除非目标文件已有固定格式，否则追加简洁 Markdown 记录：
## YYYY-MM-DD - <切片标题>
- 类型: <type>
- 来源: Codex 移动端口述
- 记录: <清理后的内容>
- 动作: <动作列表或无>
多个切片路由到同一文件时，如果符合该文件已有风格，按同一个日期标题分组。
5. 处理日程安排
当用户口述中出现具体日程安排，例如“今晚 19 点约朋友吃饭”“明天下午三点开会”，按以下规则处理：
- 必填信息是日程标题、具体日期、开始时间。相对日期必须按当前系统日期和时区转换为具体日期。
- 如果缺少任一必填信息，先问用户补充；不要创建含糊日程。
- 如果结束时间或时长缺失，默认创建 1 小时日程，并在回复中说明该默认值。
- 如果地点、参与人、备注或提醒缺失，不要追问，除非用户暗示这些信息很重要。
- 先查看用户主数据中是否记录了 Markdown 日程账本路径；如果有，新增安排前先读取账本并检查同日期、同时间段的
active或tentative安排是否冲突。 - 未来 72 小时内的重要事项，目标是让用户能被提醒；手机日历只是其中一种方式。
- 只有在用户明确授权且账号确认正确时，才写入电脑端 Calendar 或 Reminders。若电脑登录的是其他账号，禁止使用 macOS Calendar/Reminders 作为替代路径。
- 若没有可直接写入用户手机的工具，写入 Markdown 日程账本，并给出可直接对 Siri 说的提醒口令或其他手机端操作建议。
- 写入账本后，在回复中确认标题、日期、开始时间、结束时间或时长、地点、状态、提醒建议，以及是否发现冲突。
- 当用户询问“今天有什么安排”“接下来有什么安排”“某个时间能不能约”“有没有冲突”“未来 72 小时有什么重要事项”等问题时，先读取用户主数据中记录的 Markdown 日程账本，再回答。
6. 处理长期记忆
只抽取稳定、未来会反复有用的长期记忆候选。例子包括身份、持续偏好、重要关系、纪念日、反复出现的职责、长期目标，以及稳定的项目或协作规则。
严格遵守当前系统的记忆政策。在本 Codex 环境中，只有用户明确要求记住、存储长期记忆或让某条偏好长期生效时，才写入记忆；允许写入时，在配置好的 ad hoc 记忆更新目录创建一个小文件，说明拟新增、更新或删除的内容和证据。如果当前机制不可用或不允许写入，在最终回复中列出记忆候选供用户确认。
不要把短暂情绪、一次性任务、隐私秘密、凭证、健康细节、财务细节或第三方敏感事实写入长期记忆，除非用户明确要求且当前政策允许。
7. 回报结果
最终回复保持紧凑，说明：
- 更新了哪些项目文档。
- 创建了哪些提醒/日程记录，写入了哪个 Markdown 日程账本，或因缺少哪些必填信息而暂停创建。
- 存储了多少切片，以及它们的类型。
- 写入或提议了哪些长期记忆更新。
- 仍未解决的路由或转写不确定点。
如果因为路由不明确而没有更新文件，明确说明需要用户补充什么决定。
8. 从用户纠正中学习
当用户在一次口述任务后指出执行问题时，必须：
- 明确说出漏掉、误分、误写或不该写入的点。
- 说明哪条流程规则本应防止该问题。
- 提炼一个可复用的改进办法，而不是只道歉。
- 询问用户是否要基于这个发现优化本 skill，或本次任务实际使用过的其他 skill。
- 用户同意后，只写入简洁、长期有效的规则；不要把一次性解释、道歉或案例细节堆进 skill。
示例
- “我刚刚想到一个副业点子...” -> 清理文本，分类为
side-business-idea，路由到相关商业或项目想法文档。 - “今天带娃的时候我发现...” -> 分类为
parenting-reflection，如有家庭、育儿或个人日记文档，则路由过去。 - “记住，我女儿生日是...” -> 分类为
anniversary-date，在政策允许时写入长期记忆。 - “今晚 19 点约朋友吃饭” -> 分类为
calendar-event，将“今晚”换算为具体日期；若无法直接写入手机提醒，则写入 Markdown 日程账本，并给出可对 Siri 说的提醒口令。 - “这个产品以后都要先做可运行版本...” -> 分类为
durable-project-rule，存入项目操作指南或长期记忆候选。