每天下班前花二十分钟翻聊天记录、听会议录音、回忆今天谁交代了什么事然后再手写一份明天的待办清单——这套流程我坚持了大半年最后发现真正被执行的条目不到一半。问题不在于我懒而在于手动整理信息这件事本身就是个伪需求信息早就以音频、文字、图片的形式散落在各个角落了我却还在用最原始的方式把它们誊抄一遍。后来我换了个思路把每天产生的所有信息——通话录音、微信聊天、会议录音——全部丢给一套自动化流水线让 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 silenceremovestop_periods-1:stop_duration2:stop_threshold-40dB meeting_trimmed.wavstop_duration2表示静音超过 2 秒就切掉stop_threshold-40dB是静音判定阈值。这个参数要根据实际录音环境调会议室噪音大的话阈值要放宽否则会把正常的停顿也切掉导致语句断裂。4. 转写与结构化把一堆音频变成任务 JSON4.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 在这里的角色不是替我做决定而是替我做那些机械的、重复的、容易出错的信息搬运工作。真正需要判断的部分——哪些任务重要、怎么安排节奏——还是我自己说了算。如果你也在被每天的信息洪流淹没不妨从最小闭环开始试试先跑通一个信息源剩下的就是复制粘贴的事了。
