上周有位做知识付费的朋友找我吐槽他一个人要管选题、写稿、录音、剪片子、做配图、发公众号、发知乎再同步一份到自己的网站一周下来产出三篇人先垮了。我把他的流程拆开看了一遍发现他真正缺的不是时间而是三个人手——一个转录员、一个排版美工、一个发稿助理。这三个人手其实 GitHub 上都有现成的开源项目能顶上而且都能装在自己电脑上跑素材不出本地成本几乎为零。这篇不是那种收藏夹式的清单。我会按照内容生产的实际流水线顺序讲——采集、转写、写稿、配图、发布——每推荐一个项目都把我自己用的参数、版本、踩过的坑写清楚。你不需要每个都装看完之后挑一两个最堵你流程的环节先上手就行。适合个人创作者、小型工作室以及被一个人顶一个团队这种命题逼到墙角的内容岗。1. 一个人做内容的真实瓶颈以及我为什么按流水线来选工具1.1 内容团队的六个岗位哪些能被工具吞掉先把内容团队这个模糊概念拆开。一个正常运转的三人内容小组实际承担的是这些活岗位职责具体动作可被工具替代的程度对应开源项目选题策划刷信息源、记灵感低需要判断辅助类工具素材转录录音转文字、截图取字极高Umi-OCR、faster-whisper撰稿改稿初稿、改写、改标题中AI 出草稿人定调Ollama Open WebUI视觉设计头图、配图、封面中高模板化需求ComfyUI排版发布多平台格式适配高Hexo数据复盘看数据、调方向低无看这张表你会发现一个规律凡是把一种形式的信息转换成另一种形式的活工具替代率都极高凡是做判断、定调性的活工具替代率都很低。转录是典型的格式转换配图在模板化需求下也是格式转换排版发布更是纯机械劳动。这三块吃掉了个人创作者至少一半的时间而它们恰恰是最该被工具吞掉的部分。我见过太多人反过来做花大量时间研究怎么让 AI 写出有人味的稿子却依然在手动听录音、手动截图打字、手动把同一篇内容排版三遍。顺序搞反了。1.2 选工具的四个硬指标离线、批量、可脚本化、可迁移GitHub 上的开源项目多如牛毛同一个需求能搜出二十个仓库。我筛项目有四条标准缺一条就基本不考虑第一能不能离线跑。内容素材里经常有未发布的访谈、客户原话、内部数据把这些东西传到别人的服务器上风险是你自己担的。离线工具至少保证素材不出本机。第二支不支持批量。处理一个文件和处理一百个文件是两种完全不同的工具。我要求的是能一次性拖进去一批能按规则输出到指定目录不需要我守在旁边点确认。第三有没有命令行或者本地接口。这一点很多人忽略。图形界面很快但当你需要把五个工具串成一条流水线时只有带命令行或者 HTTP 接口的工具才能被脚本调用。Umi-OCR 有本地 HTTP 服务faster-whisper 是纯 Python 库Hexo 本身就是命令行工具——这些都是可编排的。第四数据落盘格式是不是通用格式。输出成 txt、md、srt、json 的我欢迎只肯存在自己数据库里、导出还要收费的直接放弃。工具是给你打工的不是把你锁住的。提示判断一个仓库值不值得深入我一般看三样东西——最近半年有没有提交、Issue 区的作者回不回话、README 里有没有给可复现的安装命令。三样缺两样说明它更像个演示项目而不是能用的工具。1.3 这 5 个项目在流程里的位置把上面五个项目按流水线摆好整条链路是这样的素材进来录音文件、截图、PDF、网页Umi-OCR处理所有图里的字输出纯文本faster-whisper处理所有声音里的字输出带时间戳的文稿文稿汇总进素材库用Ollama Open WebUI做初稿整理、标题候选、多平台改写ComfyUI按选题出配图Hexo把定稿排版成站点同时导出适合其他平台的分发版本这套组合里没有一步需要联网把素材送出去也没有一步需要你手动复制粘贴超过三次。下面逐个讲。2. Umi-OCR把截图和扫描件里的字抠出来素材不再靠手打2.1 它真正解决的场景比你想的要多大部分人对 OCR 的印象还停留在把图片转成文字。Umi-OCR 这个项目GitHub 上的 hiroi-sora/Umi-OCR比这个定位宽得多我实际用它做四件事截图取字看到一个好的观点、一段数据、一条评论截图之后直接识别不用手打。批量图片识别一次拖进去几百张截图按文件名输出对应的 txt素材整理效率直接翻倍。扫描件和 PDF 取文老资料、纸质合同、印刷品拍照之后转可编辑文本。二维码和条码识别这个功能很多人不知道处理活动物料、票据的时候很省事。它底层用的是 PaddleOCR 系的识别引擎中文识别质量在同量级开源方案里属于第一梯队。关键是完全离线、免费、没有调用次数限制——这一点对我这种一天要处理几十张截图的人来说比识别率再高两个百分点重要得多。2.2 我的安装和使用路径避开那些折腾人的环节项目的分发方式是绿色包去仓库的 Releases 页面下载对应系统的压缩包解压之后直接运行主程序不需要额外装 Python 环境。这一步就过滤掉了大量技术门槛。装好之后我建议你先做两件事第一件事进设置里把输出目录固定下来。默认情况下识别结果跟着程序走一旦你换版本或者清理目录历史结果就找不到了。我一般建一个专门的素材目录比如D:/content/raw/ocr/所有识别结果按原图文件名命名落在这个目录里。命名规则我强制要求自己统一日期_来源_简短描述.png识别出来的 txt 自动继承文件名后面写稿时一眼就能定位出处。第二件事开启本地 HTTP 服务。Umi-OCR 内置了一个可以本地调用的接口开了之后你就能用脚本或者别的程序去调用它。这个功能是把 OCR 接进流水线的关键。举个最小例子用 Python 调用import base64, requests url http://127.0.0.1:1224/api/ocr with open(cover.png, rb) as f: img_b64 base64.b64encode(f.read()).decode() payload {base64: img_b64, options: {data.format: text}} r requests.post(url, jsonpayload, timeout30) print(r.json()[data])接口地址和端口以你本地设置里显示的为准不同版本的字段名可能有差异第一次用之前去仓库文档里核对一下字段别硬套。2.3 识别率上不去的三个真实原因我帮人排查过很多次为什么我识别出来一堆乱码原因基本集中在三个地方跟工具本身关系不大原因一原图分辨率太低。手机截屏再做二次压缩之后笔画会糊在一起。经验值是中文正文部分每行字的像素高度最好在 24px 以上低于这个数什么引擎都救不回来。遇到识别不准先别换工具先把原图放大两倍试试。原因二混排和竖排。一张图里同时有横排标题、竖排标签、斜排水印引擎的版面分析会打架。我的做法是手工分区域截取一个区域一张图识别完再拼。看起来笨但准确率能提高一大截而且比反复纠错快。原因三表格线干扰。带框线的表格识别出来经常串行。这时候可以试试关掉版面分析、或者先做一次去线处理。如果表格结构很重要别指望 OCR 一步到位识别出文字之后导入表格软件重新对一遍更快。注意OCR 结果一定要做一次人工抽查尤其是数字、金额、人名、专有名词。识别引擎最容易在1/l、0/O、rn/m这类形近字符上出错而这类错误恰恰是最致命的——错一个数字整篇内容的可信度就没了。2.4 把 OCR 接进流水线的一个小技巧我给自己写了一段整理脚本逻辑很简单把raw/ocr/目录下所有的 txt 合并成一个带来源标记的素材文件方便后面扔给模型做整理。import os, pathlib src pathlib.Path(raw/ocr) out [] for p in sorted(src.glob(*.txt)): text p.read_text(encodingutf-8).strip() if not text: continue out.append(f## 来源{p.stem}\n{text}\n) pathlib.Path(digest/ocr_all.md).write_text(\n.join(out), encodingutf-8)这个脚本不复杂但它带来一个质变素材从散落在几十个文件里变成一个可以整体检索的文档。后面无论是自己翻查还是给模型做参考效率完全不一样。很多人抱怨 AI 写东西没有素材支撑其实不是模型的问题是素材从来没被整理成模型能读的形态。3. faster-whisper一小时访谈十分钟出字幕稿3.1 为什么我不推荐用在线转写服务在线转写服务这两年体验确实好了不少但我依然把长音频转写放在本地做原因有三个都很实际。一是素材的私密性。访谈录音里有受访者没打算公开的原话会议录音里有内部信息。这些东西一旦上传你对它的去向就没有控制权了。二是时长成本。长音频按分钟计费一个每周产出三小时音频的账号一年下来的转写费用足够买一块入门级显卡了。本地转写只有电费。三是可控性。在线服务的模型和参数你改不了遇到方言、术语、多人交叉说话你只能接受它的结果。本地跑 faster-whisper提示词、VAD 参数、时间戳粒度全都能调。faster-whisper 是 Whisper 模型在 CTranslate2 推理框架上的重实现说白了就是同样的识别质量快得多、省得多。它的量化版本能在 CPU 上跑到可用的速度有显卡的话更是接近实时。3.2 模型规格和量化方式怎么选这部分是新手最容易踩坑的地方——下了个最大的模型结果跑不动或者用了个最小模型中文识别稀烂。我把常用规格整理成一张表参数是按我自己机器上的实测感受给的模型规格参数量级中文可用度显存占用大致范围适用场景tiny / base极小差同音字多很低只做关键词检索small小一般低口播稿粗转需大量校对medium中较好中等日常访谈、播客large-v3大好高正式内容、需直接发布的字幕large-v3 int8 量化大接近原版明显下降显存吃紧时的首选我的建议很直接如果你一次转写要产出能直接用的文稿直接用 large 级别加 float16如果显存不够用 int8 量化别退回小模型。小模型省下的那点时间会在校对环节成倍还回去。基础调用长这样from faster_whisper import WhisperModel model WhisperModel(large-v3, devicecuda, compute_typefloat16) segments, info model.transcribe( interview_01.m4a, languagezh, beam_size5, vad_filterTrue, vad_parametersdict(min_silence_duration_ms500), initial_prompt以下是普通话访谈内容涉及产品设计、用户增长、内容运营等话题。, word_timestampsTrue, ) with open(interview_01.srt, w, encodingutf-8) as f: for i, seg in enumerate(segments, 1): f.write(f{i}\n{seg.start:.2f} -- {seg.end:.2f}\n{seg.text.strip()}\n\n)注意compute_type要按你的硬件选有独立显卡用float16纯 CPU 用int8。别硬抄跑不起来的时候先看报错里提示的精度支持情况。3.3 三个参数决定文稿能不能直接用这三个参数是我反复调整之后固定下来的值得单独讲vad_filterTrue。语音活动检测作用是把静音段和纯噪声段切掉。不开这个模型会把长达几十秒的空白也当成片段输出来还会在静音处幻觉出一些根本不存在的句子。开这个之后我一般把min_silence_duration_ms设在 500 左右太小会把正常换气切断太大又会把两句话粘在一起。initial_prompt。这是被严重低估的参数。它相当于给模型一段上下文提示能显著改善专有名词的识别。我的做法是每次转写前把这次访谈涉及的人名、产品名、行业术语列一遍写进去。实测下来术语错误率能降一半以上。这个小技巧几乎没人提但效果立竿见影。word_timestampsTrue。开启之后每个词都有时间戳好处是你可以基于它自动生成精确的分段字幕也可以按关键词定位到音频位置。做视频剪辑的人尤其需要这个配合剪辑软件可以直接按词切。3.4 中文转写绕不开的几个坑Whisper 的中文能力整体不错但有几个坑是结构性的标点的问题。模型输出的标点有时候会缺失或者用得奇怪尤其是长句。我不会让模型自己纠结标点而是把原始输出当成带空格的原始文本后面用规则脚本过一遍——句末补句号、连续空格合并、英文与中文之间加空格。写一次脚本后面所有转写都受益。数字和单位。一百二十和120混着出是常有的事。如果文稿要用于数据类内容这块必须人工核对别指望模型统一。多人对话不分轨。原生 Whisper 不做说话人分离两个人的对话会混成一段。变通办法是如果录音时用双麦克风录制两个声道可以分成两个单声道文件分别转写再按时间戳合并如果只有一个声道那就只能靠人工标注或者结合字数、语气做粗略切分。这块目前没有特别省事的开源方案我一般直接接受混排 人工标说话人。提示转写完的文稿别急着删音频。剪辑时你需要用到时间戳口播复查时你需要核对原声。我的习惯是把xxx.m4a、xxx.srt、xxx.md三个文件放在同一个目录下永远成套存在后面查证的时候省事太多。4. Ollama Open WebUI本地跑一个写作助手把改稿这一步压缩4.1 本地模型的定位不是替你写是替你改先说一个反常识的结论本地小模型写得不如云端大模型但在改稿这件事上它足够用而且更听话。为什么因为改稿这个任务的信息输入是完整的——你已经有了一份转写好的、素材丰富的原始文本模型要做的只是整理结构、换语气、改标题。这种任务的难度在于理解上下文而不在于凭空创造。一个几十亿参数级别的模型配合好的提示词完全能胜任。而它最大的优势是素材原文不用发给任何人。一份未公开的访谈稿扔给本地模型改一百遍也还是在你自己的硬盘上。部署方式我选的是 Ollama 加 Open WebUI 的组合。Ollama 负责跑模型和管模型Open WebUI 提供一个像样的聊天界面支持多会话、对话历史、文件上传。两个都是开源项目装完之后你得到的就是一个完全属于你自己的写作助手。4.2 装好之后第一件事是写 Modelfile很多人装完模型就直接用默认设置聊天然后抱怨输出太水。问题出在你没有告诉它你是谁、在做什么。Ollama 支持用 Modelfile 自定义模型的人格和参数这是我用得最狠的功能。FROM qwen2.5:14b PARAMETER temperature 0.75 PARAMETER top_p 0.9 PARAMETER num_ctx 8192 PARAMETER repeat_penalty 1.1 SYSTEM 你是一名中文内容编辑服务对象是独立创作者。 你的任务是把粗糙的原始素材整理成结构清晰、可直接发布的内容。 要求 1. 不使用随着……的发展综上所述这类空话。 2. 保持原文事实与数据不得编造任何未经提供的信息。 3. 段落之间要有逻辑推进不要用罗列代替论述。 4. 输出使用中文专业术语保留原文。 num_ctx是上下文窗口处理长文稿时必须调大默认值往往只有 2048 或者 4096长文本会被截断导致模型读到一半就开始写这是很多人抱怨模型乱编的真实原因。建好之后用ollama create editor -f Modelfile创建之后就能像用普通模型一样调用editor。这一步花十分钟能省下后面每次都要重复粘贴提示词的麻烦。4.3 我常用的三个提示词结构结构一素材整理。把 OCR 和转写出来的原始素材扔进去要求它做三件事——按主题分块、去掉口语重复、标出信息缺口。最后一点特别有用它会告诉你这里缺少一个具体案例你就知道该去补什么素材。结构二标题候选。我的要求是给出十个标题并且每个标题后面必须写明它用了什么角度。这样我不是在一堆标题里凭感觉挑而是能看到不同角度的覆盖情况再组合出一个。结构三多平台改写。一份长文稿改写成适合短内容平台的版本。关键是明确约束字数范围、段落长度、需不需要保留小标题、要不要在开头直接给结论。约束越具体输出越能用。注意本地模型最大的风险是看起来很对的编造。它会把一段没有出处的表述写得非常确定。我的处理方式是在提示词里强制要求只能使用我提供的素材中出现的数字和事实并且在改完之后专门做一轮事实比对尤其是数字、时间、名称。这一步不能省。4.4 让模型读你自己的历史内容检索增强的最小实现当你积累了上百篇历史内容之后一个新需求就出现了怎么让模型参考你自己过去的写法最朴素的做法是把所有文稿拼进提示词但上下文窗口装不下。最小可行的做法是检索增强把历史文稿切成段用文本向量模型把每段转成一个向量存起来GitHub 上开源的 M3E 系列就是这个用途新问题进来时先在向量库里找出最相关的几段只把这几段塞进提示词。# 伪代码展示思路 query_vec embed(new_topic) hits vector_store.search(query_vec, top_k5) prompt 参考资料\n \n.join(hits) \n\n请基于以上资料风格写一段开场。这套东西的工程复杂度不高但带来的体验差异很大——模型从一个通用写手变成读过你所有旧作的助理。如果你只做一件事来提升输出质量我会选这个。5. ComfyUI配图不再等设计排期5.1 内容号为什么需要一条配图流水线配图这件事的痛点和写稿不一样。写稿的痛是没思路配图的痛是每张都要重来一遍。一篇文章配三张图一周十篇就是三十张如果每张都从零开始调时间成本高得离谱。ComfyUI 的价值在于把出图这件事变成工作流。你把一套参数调好、节点连好保存成一个工作流文件之后每次出图只需要换关键词其他全都不用动。这才是流水线的意义——不是让每一张图都完美而是让每张图都够用且可复现。5.2 我用的最小工作流我不追求复杂的节点编排日常配图用的就是一个最基础的结构文本编码、采样器、解码、保存。核心参数我固定在这么一组参数我的取值原因分辨率1024×576 或 768×768横图适配站点头图方图适配封面采样步数2430再往上收益很小时间却翻倍采样器常用的中阶采样器稳定、速度快引导强度67.5太高会糊、颜色发死批次大小4一次出四张挑一张用批次大小设成 4 是我最推荐的习惯。出图有随机性一次一张、不满意再抽效率极低一次四张你总能在里面挑出一张可用的剩下三张也不浪费——可以裁切当小图用。5.3 让出图风格稳定下来的两个手段手段一固定随机种子。当你抽到一张风格很满意的图把种子记下来微调关键词时继续用这个种子出来的图风格会保持一致。做系列内容的时候这套方法能让你的配图有统一的视觉语言而不是每篇风格都不一样。手段二关键词分层写。我一般按主体 场景 光线 风格 画质五层来写比如一台老式打字机木质桌面侧逆光复古胶片感细节清晰。分层写的好处是你可以单独替换某一层——需要换场景就只改第二层主体和风格不动出的图就是同一套视觉体系里的变体。如果对构图有更严格的要求比如必须留出放标题的位置可以加上控制类节点用一张简单的示意图约束构图。这个属于进阶用法等你把基础流程跑顺了再折腾。5.4 版权与合规这条线必须划清楚用生成模型做配图有几条线我会严格守住也建议你守住不生成真实人物的形象尤其是公众人物和任何可识别的个体。生成某某明星在某某场景这类内容涉及的问题不是技术问题是法律问题。不生成可能被误认为真实新闻现场的画面。内容创作可以有风格化的抽象图、插画、示意图但不要产出那种看起来像真事发生的图像。商用之前确认模型和素材的许可条款。不同模型、不同训练权重对商用的规定不一样仓库文档里一般会写别嫌麻烦看一遍。平台规则优先。你要发布的平台如果对生成内容有标注要求那就老老实实标注。这既是合规也是长期的信任成本。提示我现在的工作习惯是生成类图片只用于氛围图、示意图、概念图这三类。凡是涉及具体人物、具体事件、具体数据的图一律用图表工具或者实拍素材。这条边界划清楚之后心理负担小很多。6. Hexo GitHub Pages写完就发一次写作多端复用6.1 一次写作多端复用才是内容效率的真正杠杆前面几个项目解决的是生产环节Hexo 解决的是分发环节。它的价值不在省下几分钟排版时间而在于让你的内容有一个属于自己的、长期沉淀的根据地。道理很简单你写在别人平台上的内容格式、图片、排序、能不能被检索全都不由你控制。而自己搭的站每一篇都是 Markdown 文件图片和文字都躺在你的硬盘里想改随时改想迁随时迁。写一篇文章同时分发到站点和其他平台成本只增加一次粘贴。Hexo 是一个静态站点生成器你写 Markdown它生成 HTML。配合 GitHub Pages 托管你连服务器都不用买。6.2 从零到能访问几步走# 安装命令行工具 npm install -g hexo-cli # 初始化站点 hexo init my-blog cd my-blog npm install # 新建一篇文章 hexo new 我的第一篇 # 本地预览 hexo server # 生成静态文件并部署 hexo generate hexo deploy部署需要在配置文件里指定仓库地址和分支。配置文件里的部署段大概长这样deploy: type: git repo: 你的仓库地址 branch: main这里有个细节容易忽略generate之后一定要看一眼本地预览确认图片路径、内部链接都正常再去部署。我见过太多次部署完才发现图片全裂的情况返工一次比预览一次麻烦十倍。另外一个强烈建议把源文件仓库和生成产物分开放或者至少在用版本控制时把node_modules、生成出来的目录写进忽略文件。否则每次提交都是一堆无关文件仓库很快就臃肿得没法看。6.3 Front-matter 是我用得最狠的地方每篇 Markdown 顶部那段用三条短横线包起来的内容叫 Front-matter。大多数人只填标题和日期我很认真地填--- title: 一个人做内容的五个开源工具 date: 2026-08-20 09:30:00 tags: [内容运营, 开源工具] categories: [效率] cover: /images/cover-001.png description: 按流水线顺序拆解五个开源工具的实际用法与参数。 ---其中description这一项最有价值。它既会出现在站点的摘要里也能直接复用到其他平台的导语位置写一次用三处。tags写规范之后站内会自然形成主题聚合页对长期内容资产的检索帮助极大。注意日期格式一定要按配置文件里要求的写。我踩过的坑是时区没设置对导致文章在本地显示是今天的部署上去显示成了昨天首页排序就乱了。配置里有个时区项填对之后这类问题一次性解决。6.4 部署时最常见的四个错误错误一仓库分支写错。托管服务换代之后默认分支名从老的叫法变成了main配置里还写着旧的部署就会静默失败。部署完一定要去仓库页面确认有没有新提交。错误二缓存没清就重新生成。有时候你改了配置但页面没变八成是缓存。清理缓存再生成比反复折腾配置快。错误三图片用绝对路径。站点如果有子路径写死绝对路径的图片会全部失效。统一用相对路径或者配置好根路径变量。错误四提交了自动生成的文件。这些文件体积大、变动频繁提交进去之后仓库会迅速膨胀而且每次合并都会冲突。把它们加进忽略文件这一步越早做越好。7. 把这五个项目串起来我的日常动线和一个真实案例7.1 目录结构决定你后期有多轻松工具装完之后真正决定效率的是文件怎么组织。我的素材目录固定成这样content/ ├── raw/ # 原始素材不许改 │ ├── audio/ # 录音原文件 │ ├── ocr/ # OCR 输出 │ └── trans/ # 转写输出 ├── digest/ # 整理后的素材汇总 ├── draft/ # 草稿 ├── images/ # 配图 └── publish/ # 定稿关键是raw/这一层永远不动。所有中间加工都写到别的目录去。这样做的好处是任何时候结果出问题你都能回到原点重来而不是在改了几十遍的文件里找原始版本。7.2 一个真实案例一份 40 分钟访谈到三篇成稿我上个月处理过一次典型的活一份 40 分钟的访谈录音需要产出三篇不同角度的内容。第一步转写。用 faster-whisper 的 large 规格开了 VAD 和时间戳加上术语提示词40 分钟音频大概跑了七八分钟出一份带时间戳的完整文稿。第二步过一遍 OCR。把访谈里的几张 PPT 截图和聊天记录截图批量识别合并成素材文档。这一步补上了录音里没说清楚的数据。第三步整理。把转写稿和 OCR 结果拼在一起扔给本地模型要求它按主题分块标出可以独立成篇的三个方向同时指出哪一块缺少案例支撑。第四步成稿。三个方向分别出初稿我逐个改。改稿时间从原来的一整天压缩到大概两个多小时。第五步配图。按三个方向的调性各出一批四张风格一致的配图。第六步发布。定稿进站点同时导出适合其他平台的版本Front-matter 里的描述直接当导语用。整条链路走下来从素材到三篇成稿加配图大概半天。这个效率在纯手工时代是不可想象的。但我要强调一点提速的是那些机械环节判断、取舍、定调性这些事一点都没少做反而因为素材看得更全要求更高了。7.3 有几个环节工具确实替代不了最后说点实在的。这五个项目能替掉大量重复劳动但有三件事我从来没想过交给它们一是选题的判断。哪个话题现在值得做、哪个角度没人讲过、你的读者此刻关心什么这需要对人和场的理解工具只能给你信息给不了判断。二是表达的独特性。模型能写通顺但写不出你的经历、你的偏好、你说反话时的那个语气。这些东西恰恰是读者认你的理由。三是关系。内容创作的下半场拼的不是产量是信任。回复一条认真评论、记住一个老读者的名字这些事只会花你几分钟但它们是工具永远做不了的。我在实际使用中发现一个规律越早把机械环节交出去的人越早开始认真思考上面这三件事。反过来那些一边喊着AI 写的没人看一边还在手动对着录音打字的通常两个问题都没解决。如果你手头正卡在某个环节我建议先从最疼的那个入手——素材永远整理不完的装 Umi-OCR录音堆成山的先跑通 faster-whisper。装一个用两周比把五个都装一遍然后全吃灰强得多。另外分享一个小技巧每次装完一个新工具我都会强迫自己把它的最小可用流程写成一段不超过十行的笔记存进同一个文件里。三个月之后再回来不用重新查文档看笔记就能直接上手。这个习惯帮我省下的时间比工具本身还多。