每天下班前花二十分钟翻聊天记录、听会议录音、回忆今天谁交代了什么事，然后再手写一份明天的待办清单——这套流程我坚持了大半年，最后发现真正被执行的条目不到一半。问题不在于我懒，而在于"手动整理信息"这件事本身就是个伪需求：信息早就以音频、文字、图片的形式散落在各个角落了，我却还在用最原始的方式把它们誊抄一遍。后来我换了个思路，把每天产生的所有信息——通话录音、微信聊天、会议录音——全部丢给一套自动化流水线，让 AI 在凌晨把第二天的规划直接推给我。这篇文章就把这套东西从架构到落地完整拆一遍，包括音频怎么转文字、聊天记录怎么导出、AI 怎么被约束成"靠谱的规划助手"而不是"废话生成器"，以及我在调试过程中踩过的那些坑。
1. 先想清楚：为什么"手动列待办"这件事注定失败
1.1 信息源头和待办清单之间隔着一道人工鸿沟
我们每天接收的工作信息，本质上分布在三个物理位置：手机通话记录里的语音、微信里的文字和语音条、会议软件录下来的音频文件。这三类信息的共同点是——它们都是"原始素材"，不是"结构化任务"。一条微信语音说"那个方案你明天上午看一下，顺便把预算那部分跟财务对一下"，这里面其实藏着两个任务、一个时间约束、一个协作对象，但你手动誊抄的时候大概率只会写一句"看方案"，剩下的信息全丢了。
我统计过自己过去三个月的待办清单，平均每条任务只有 6 个字，而对应的原始信息平均有 40 多字。也就是说，手动整理的过程是一个信息压缩比高达 85% 的有损压缩，丢掉的恰恰是执行时最需要的上下文。这就是为什么很多待办事项第二天打开时你会一脸茫然："这个'对接一下'到底是跟谁对接什么？"
1.2 AI 介入的价值不是"帮你写清单"，而是"帮你保真"
很多人对 AI 做规划的误解是：让大模型凭空生成一份看起来很专业的日程表。这是错的。AI 在这套流程里的核心价值是信息保真 + 结构化：把非结构化的音频、聊天记录，无损地转成带时间、带对象、带优先级的任务条目，然后再做去重、排序、冲突检测。它不需要"聪明"，它需要"忠实"。
我一开始也走过弯路，直接让模型"根据今天的聊天记录给我安排明天的工作"，结果它开始自由发挥，编出一些我根本没提过的任务。后来我把 prompt 改成"只允许从提供的原始文本中提取任务，不允许推断和补充"，输出质量立刻稳定了。这个原则后面会详细讲。
1.3 这套方案适合谁，不适合谁
适合的人群很明确：每天信息输入量大、信息来源分散在多个 App、且有一定动手能力愿意折腾脚本的人。比如项目经理、需要对接多方的小团队负责人、自由职业者。如果你每天就三五个任务且都在一个工具里，那确实没必要上这套东西，杀鸡用牛刀。
不适合的情况也要说清楚：如果你的通话和会议涉及大量不便外传的内容，那本地化部署就是硬性要求，不能图省事直接调云端 API。这一点在架构设计阶段就要定下来，后面会展开。
2. 整条流水线的架构：从原始音频到一份可执行规划
2.1 四个阶段的数据流转
整套系统我拆成了四个阶段，每个阶段职责单一，方便单独调试：
| 阶段 | 输入 | 处理动作 | 输出 |
|---|---|---|---|
| 采集 | 通话录音、微信记录、会议音频 | 定时抓取、格式统一 | 原始文件池 |
| 转写 | 音频文件 | 语音识别转文字 | 带时间戳的文本 |
| 结构化 | 全部文本 | 大模型提取任务 | JSON 任务列表 |
| 规划 | 任务列表 | 去重、排序、冲突检测 | 次日工作规划 |
这个拆法的好处是：任何一环出问题都能快速定位。比如规划结果不对，你可以先看结构化输出的 JSON 是不是就已经错了，如果 JSON 是对的，那问题就在规划阶段的 prompt 上。
2.2 为什么选 ffmpeg 做音频预处理
所有音频进转写引擎之前，必须先过一遍 ffmpeg。原因有三个：第一，不同来源的音频格式五花八门，通话录音可能是 amr，会议软件导出的是 m4a，微信语音是 silk 格式，转写引擎通常只吃 wav 或 mp3；第二，采样率不统一会影响识别准确率，统一重采样到 16kHz 单声道是语音识别的黄金标准；第三，长音频需要切片，否则一次性喂给识别引擎容易超时或内存爆掉。
我用的标准化命令是这样的：
ffmpeg -i input.m4a -ar 16000 -ac 1 -c:a pcm_s16le output.wav-ar 16000是重采样到 16kHz，-ac 1是转单声道，-c:a pcm_s16le指定 16 位 PCM 编码。这三个参数是语音识别的通用最优配置，实测比直接喂原始 m4a 的识别准确率高出一截，尤其是带背景噪音的会议录音。
对于超过 5 分钟的长音频，我会先切片：
ffmpeg -i long.wav -f segment -segment_time 300 -c copy part_%03d.wav每 300 秒切一段，切完并行送去识别，最后按时间戳拼回来。这里有个坑：-c copy切片时如果不在关键帧切，拼接处会有杂音，稳妥做法是切片时重新编码而不是 copy，虽然慢一点但不会出问题。
2.3 转写引擎为什么选 SenseVoice
语音识别这块我对比过几个方案，最后选了 SenseVoice。选它的理由很实际：它对中文口语的识别准确率明显好于通用方案，尤其是带口音、带语气词、语速快的场景；而且它自带标点恢复和情感识别，输出直接就是可读的文本，不需要额外做后处理。会议录音里那种"嗯""那个""就是说"的口语填充词，它处理得比较自然，不会像有些引擎那样把整句话切得七零八落。
部署上它是可以本地跑的，这对隐私敏感的场景很关键。我的做法是把 SenseVoice 跑在一台常开的机器上，暴露一个本地 HTTP 接口，转写阶段直接 POST 音频文件过去拿文本。这样音频数据不出本地网络，只有转写后的文本才会进入下一步。
注意：本地部署语音识别对硬件有要求，纯 CPU 跑长音频会很慢。如果每天音频量超过一小时，建议至少配一块入门级显卡，否则转写阶段会成为整条流水线的瓶颈。
2.4 大模型环节：Claude Code 在这里扮演什么角色
结构化提取和规划生成这两步，我用的是 Claude Code。这里要澄清一个常见误解：Claude Code 不只是写代码的工具，它本质上是一个能读写本地文件、能执行命令、能按指令处理文本的 agent。我把它当成流水线里的"文本处理大脑"来用——转写好的文本文件放在一个目录里，让它读取、提取、输出 JSON。
为什么不用普通的 API 调用？因为 Claude Code 能直接操作文件系统，我可以让它读一整个目录下的所有转写文本，自己决定怎么合并、怎么去重，省掉了我写一堆胶水代码。而且它支持在 VS Code 里配置使用，调试 prompt 的时候改一行就能重跑，迭代效率比写脚本高得多。
3. 采集阶段：三类信息源怎么拿到手
3.1 通话录音的获取与格式处理
通话录音这块，安卓和 iOS 的差异很大。安卓相对开放，很多机型自带通话录音功能，录音文件一般存在固定目录下，写个定时脚本扫这个目录就行。iOS 就麻烦得多，系统层面不开放通话录音，通常需要借助第三方录音设备或者运营商侧的录音服务，这部分要看你自己的实际情况。
拿到录音文件后，第一件事是统一命名。我的命名规则是日期_时间_来源_对象，比如20250115_0930_call_张三.wav。这个命名不是强迫症，而是后面结构化阶段的重要线索——模型可以从文件名里直接读到"这是跟谁的通话"，提取任务时就能自动补上协作对象，不用再从正文里猜。
3.2 微信记录的导出：这是整个流程最麻烦的一环
微信聊天记录的导出是公认的难点，因为它的本地数据库是加密的。这里我必须强调：请务必在合规前提下操作，只处理你自己的账号数据，不要涉及他人隐私。技术上，微信的本地存储是加密的 SQLite 数据库，需要拿到密钥才能解密读取。
我的做法是只导出文本消息，不碰图片和文件，因为文本才是任务提取的主要来源。导出后按天切分，每天一个文件，格式化成"发送者: 内容"的纯文本。语音条单独处理——微信语音是 silk 格式，需要先转成 wav 再走转写流程：
ffmpeg -i voice.silk -ar 16000 -ac 1 voice.wav这里有个实操心得：微信语音条通常很短，几秒到几十秒，单独转写效率低。我的做法是把同一天的所有语音条按时间顺序拼接成一个长音频再统一转写，这样识别引擎的上下文更完整，准确率也更高。拼接用 ffmpeg 的 concat 协议就能搞定。
提示：导出和解析微信数据涉及个人隐私，请确保只处理自己账号的数据，导出的中间文件用完及时清理，不要长期留存明文。
3.3 会议录音的批量处理
会议录音一般来源比较规整，要么是会议软件自动录制的，要么是自己用录音笔录的。这类音频的特点是时长长、说话人多、有明确的议题结构。处理时我会做两件额外的事：一是用 ffmpeg 的静音检测把明显的空白段切掉，减少无效转写；二是转写后按说话人分段（如果识别引擎支持说话人分离）。
静音检测切片命令：
ffmpeg -i meeting.wav -af silenceremove=stop_periods=-1:stop_duration=2:stop_threshold=-40dB meeting_trimmed.wavstop_duration=2表示静音超过 2 秒就切掉，stop_threshold=-40dB是静音判定阈值。这个参数要根据实际录音环境调，会议室噪音大的话阈值要放宽，否则会把正常的停顿也切掉，导致语句断裂。
4. 转写与结构化：把一堆音频变成任务 JSON
4.1 转写结果的清洗规则
SenseVoice 出来的文本已经比较干净了，但还是需要一轮规则清洗。我总结了几条必做的：
- 去掉纯语气词开头的句子，比如"嗯那个""就是说"开头的，这类句子 90% 没有任务信息
- 合并被错误断句的短句，识别引擎有时会把一句话切成两三段
- 统一时间表达，把"明天上午""后天下午"这类相对时间，结合录音日期换算成绝对日期
第三条特别重要。如果不做时间归一化，模型提取出来的任务时间就是"明天"，但你第二天再看这份规划时，"明天"已经变成了"今天"，全乱了。我的做法是在转写文本的头部注入一个元信息行：[录音日期: 2025-01-15]，让模型在提取时自己完成相对时间到绝对时间的换算。
4.2 用 Claude Code 做任务提取的 prompt 设计
这是整套系统里最需要打磨的部分。我前后改了十几版 prompt，最后稳定下来的核心约束有三条：
第一，只提取，不推断。明确告诉模型："只允许从原文中提取明确的任务，不允许根据上下文推断隐含任务。"这一条直接消灭了模型自由发挥编任务的问题。
第二，强制输出 JSON schema。规定好字段：任务描述、来源、协作对象、截止时间、优先级、原文出处。原文出处这个字段很关键，它让你能回溯每个任务是从哪句话来的，出错了能查。
第三，给优先级判定规则。不要让模型自己拍脑袋定优先级，而是给明确规则：带"紧急""尽快""今天"字样的为高优先级，带明确截止日期的为中，其余为低。
一个简化版的 prompt 骨架长这样：
你是一个任务提取器。读取以下转写文本，提取所有明确的工作任务。 规则： 1. 只提取原文明确提到的任务，禁止推断 2. 每条任务输出 JSON，字段包括：task, source, collaborator, deadline, priority, evidence 3. priority 判定：含"紧急/尽快/今天"为 high，含明确日期为 medium，其余为 low 4. deadline 必须换算成绝对日期，格式 YYYY-MM-DD 输出格式：[{...}, {...}]4.3 去重与合并：同一个任务被提了三次怎么办
实际跑下来你会发现，同一个任务经常在多个来源里重复出现。比如张三在微信里说了一遍，开会时又提了一遍，通话里再确认一遍。如果不去重，你的规划里会出现三条一模一样的任务。
我的去重策略是语义相似度 + 协作对象 + 时间窗口三重判断。具体做法是把所有提取出的任务再喂给模型一次，让它做聚类："以下任务列表中，哪些是同一个任务的不同表述？合并它们，保留信息最全的那条。"这一步用模型做比写规则靠谱得多，因为自然语言的表述差异太大，纯字符串匹配根本处理不了。
合并时有个原则：保留最具体的版本。如果一条说"看方案"，另一条说"看 Q1 预算方案并跟财务确认数字"，合并后要保留后者，因为信息更全。
5. 规划生成：让 AI 输出一份真正能执行的清单
5.1 规划不是排序，是资源约束下的调度
很多人以为规划就是把任务按优先级排个序，这是把问题想简单了。真正的规划要考虑约束：你一天只有那么多小时、有些任务必须等别人回复才能做、有些任务有硬性时间窗口（比如会议）。所以规划阶段的输入不只是任务列表，还要包括你的可用时间块和已知的固定日程。
我的做法是让模型先做一次"可行性检查"：把所有任务的总预估耗时加起来，如果超过当天可用时间，就标记出哪些任务需要顺延。这一步能避免你列出一份根本做不完的清单，然后因为完不成而焦虑。
5.2 时间块分配的具体逻辑
时间块分配我遵循几个原则，这些原则是写进 prompt 让模型执行的：
- 高优先级且需要深度思考的任务，放在上午精力最好的时段
- 需要等人回复的任务，放在上午尽早发出，给回复留出时间
- 碎片化任务（比如回消息、确认数字）集中放在午后低谷期批量处理
- 每个深度任务之间留 15 分钟缓冲，避免任务切换的认知损耗
这些原则不是拍脑袋定的，是我观察自己几个月的工作节奏总结出来的。你也可以根据自己的实际精力曲线调整，关键是让模型知道你的偏好，而不是让它用一套通用模板套你。
5.3 输出格式：为什么我坚持要 Markdown 而不是 App
规划生成后，我没有做成 App 或者同步到某个待办工具，而是直接输出一份 Markdown 文件。原因很实际：Markdown 可以在任何编辑器里打开、可以版本管理、可以随手改，而且不会被某个工具的格式绑架。我每天早上打开这个文件，做完一条就打个勾，比在 App 里点来点去快得多。
输出结构大概是这样的：
# 2025-01-16 工作规划 ## 上午（精力高峰） - [ ] 完成 Q1 预算方案初稿（来源：张三通话，截止 01-16） - [ ] 回复李四关于接口联调的邮件（来源：微信，紧急） ## 午后（批量处理） - [ ] 确认三份合同数字（来源：会议录音） - [ ] 整理本周周报素材 ## 待确认（需他人回复） - [ ] 等王五提供测试数据后开始压测6. 调试过程中踩过的坑与排查思路
6.1 转写准确率突然下降：先查采样率
有一次连续几天转写质量都很差，识别出来的文本驴唇不对马嘴。我一开始以为是识别引擎的问题，折腾了半天模型参数，最后发现是采集阶段的一个脚本改动把重采样参数漏了，音频以 44.1kHz 立体声直接进了识别引擎。改回 16kHz 单声道后立刻恢复正常。
这个坑的教训是：流水线出问题，永远从最上游开始查。转写不对，先看音频格式对不对，再看切片有没有问题，最后才怀疑识别引擎本身。
6.2 模型开始"编任务"：prompt 约束不够狠
前面提过，早期模型会编造任务。我排查的过程是这样的：先对比原始转写文本和提取出的任务，发现有几条任务在原文里根本找不到对应句子。确认是模型推断出来的之后，我在 prompt 里加了"禁止推断"的硬约束，并且要求每条任务必须带evidence字段（原文出处）。加了 evidence 之后，模型编任务的情况基本消失了，因为它知道每条任务都要给出原文依据。
6.3 时间换算错乱：相对时间是个大坑
"下周三""这个月底""过两天"这类相对时间，模型换算经常出错，尤其是跨月、跨年的时候。我的解决方案是在 prompt 里明确给出当前日期，并且要求所有时间换算都以这个日期为基准，同时要求模型在输出时把原始表述也保留在 evidence 里，方便我核对。如果换算错了，我能一眼看出来是哪个环节的问题。
6.4 长音频转写超时：切片策略要按内容切
最初我按固定时长切片，结果经常把一句话从中间切断，导致识别出半句话。后来改成按静音点切片，虽然实现复杂一点，但切出来的每段都是完整的语义单元，识别质量明显提升。这个改动值得做，尤其是会议录音这种有自然停顿的场景。
7. 隐私与合规：本地化部署的边界在哪里
7.1 哪些数据绝对不能出本地
通话录音和会议录音里往往包含大量敏感信息，这类数据我的原则是转写必须在本地完成，只有转写后的文本才考虑是否送云端。如果连文本都不方便外传，那结构化环节也要用本地模型。这个边界要在架构设计阶段就划清楚，不能等出了问题再补救。
7.2 中间文件的清理策略
转写过程中会产生大量中间文件：原始音频、切片音频、转写文本、JSON 中间结果。我的做法是设置一个保留窗口，比如只保留最近 7 天的中间文件，超期自动清理。最终的工作规划文件可以长期保留，因为它是脱敏后的结构化结果，不含原始敏感内容。
7.3 关于微信数据处理的合规提醒
再强调一次：只处理自己账号的数据，导出的明文文件用完即删，不要分享、不要上传到任何第三方服务。技术上能做到不代表可以随意做，这条线要守住。
8. 一些让整套系统更顺手的实操心得
8.1 把流水线跑成定时任务
整套流程我是用定时任务串起来的：每天凌晨 2 点触发，先做音频预处理，再转写，再结构化，最后生成规划。早上 7 点我打开电脑，规划文件已经躺在目录里了。定时任务的好处是你完全不用管它，坏处是出错了你不知道，所以我在每个阶段结束都加了一个简单的日志输出，第二天扫一眼日志就知道昨晚跑得顺不顺。
8.2 给模型留一个"人工修正"的入口
再好的自动化也会有错，所以我在规划文件里留了一个"待确认"区块，模型拿不准的任务放这里，我早上花两分钟手动归类。这个设计比追求 100% 自动化更实际，因为那 5% 的模糊任务，人工判断比模型猜要快得多。
8.3 定期回看提取质量，反向优化 prompt
我每周会抽一天，把这一周提取的任务和原始转写文本对照一遍，看看有没有漏提、错提的。这个习惯帮我发现了好几个 prompt 的盲区，比如早期模型对"顺便""另外"这类词引导的次要任务经常漏提，后来在 prompt 里专门加了一条规则才解决。
8.4 别追求一步到位，先跑通最小闭环
我最初想一次性把所有功能都做全，结果卡在微信导出那一环好久，整个项目停滞。后来我改变策略，先用通话录音跑通"音频→转写→规划"的最小闭环，验证了核心思路可行之后，再逐步接入微信和会议录音。这个顺序很重要，先跑通再完善，比一开始就追求大而全要快得多。
这套东西我用了几个月，最大的感受是：它并没有让我变得更忙，反而把我从"整理信息"这件低价值的事情里解放出来了。AI 在这里的角色不是替我做决定，而是替我做那些机械的、重复的、容易出错的信息搬运工作。真正需要判断的部分——哪些任务重要、怎么安排节奏——还是我自己说了算。如果你也在被每天的信息洪流淹没，不妨从最小闭环开始试试，先跑通一个信息源，剩下的就是复制粘贴的事了。
