Codex 全栈实战 · 本地知识库 · 数字人自动化：一份写给普通人的智能体流水线自建指南

本文由 莫潇羽@无忆研习社（www.wuyi.wiki） 撰写，转载请注明出处。文中所有工具选型、参数、提示词均基于我个人在 2026 年上半年的一线实测整理，供学习交流使用。

快速摘要

如果你只有一分钟，看这段就够：

这套流水线的核心是把 Codex 智能体当成"流程总控"，让它去调用国产大模型做推理、调用即梦 3.0 API 做图生视频、调用 Faster-Whisper 做本地语音识别、调用 RAGFlow 做本地知识库、调用影刀 RPA 做浏览器抓取，最后用 PyQt6 打包成一个可以分发的桌面工具。整条链路里，Codex 负责"想清楚每一步做什么"，其他工具负责"把每一步做扎实"。

四个关键结论提前抛出来：

• 底座模型可以完全国产：Codex CLI 在 2026 年 6 月已经开放了第三方 Provider，只要通过 Responses API 桥接（比如 Moon Bridge、codex-relay），就能把 DeepSeek V4、Kimi、GLM、通义千问接进来，国内网络直连即可，不需要任何额外网络工具。
• 技能包（Skills）机制是效率关键：把"教会智能体一次"的对话过程封装成 SKILL.md + scripts 的目录，下次直接调用，省掉重复解释流程的时间。这一条比换任何大模型都省事。
• 本地化要挑对场景：本地化部署对语音识别（Faster-Whisper）和文档知识库（RAGFlow）非常合适；但本地化做图、做视频目前依然打不过云端 API，别在错的方向上耗算力。
• 合规是长期底线：AI 生成的视频、图片、克隆声音在国内平台发布都要按平台规则做 AI 内容标注；调用境外模型服务需遵守国内网络与内容管理相关规定；商用素材要拿到正版授权。

想看完整拆解，往下翻。

⚠️ 合规前置声明（请务必先读这一段）：本文介绍的所有工具与技术均为学习交流用途。Codex CLI 及其中接入的境外模型服务需遵守国内网络与内容管理相关规定，日常使用场景下强烈建议优先选择 DeepSeek、通义千问、Kimi、GLM 等完全走国内公网的国产模型方案——这也是本文实操部分的首选路径，从源头避免合规风险。文中涉及 AI 生成内容（图片、视频、数字人、克隆声音）在国内自媒体平台发布时，必须按各平台规则做 AI 内容标注，缺标可能面临作品下架、账号降权乃至行政处罚。商用素材（字体、背景、音效、图标）请从正版渠道获取授权，切莫贪图方便使用来路不明的资源。RPA 抓取只限公开可见数据，严禁绕过登录墙抓取隐私数据、严禁突破网站反爬机制、严禁抓取涉及个人信息的非公开内容。AI 声音克隆与数字人形象仅限使用本人或已获书面授权的素材，禁止用于冒充、诈骗、误导公众等违规场景。以上每一条都不是轻飘飘的"建议"，而是长期安全做事的硬底线。 跳过这一段直接往下看实操，代价可能在几个月后以你不想看到的形式出现。

一、开篇：为什么这条流水线值得走一遍

先说一下我为什么会花大半年时间把这条链路完整跑通。

2026 年之前，我做自媒体和小工具开发大多数时间都花在"手工把一步一步的东西串起来"这件事上：想做十条历史人物短视频，就要一条一条写文案，一条一条生成图，一条一条剪辑，中间还夹杂着开各种网页、切各种工具。莫潇羽@无忆研习社 的这个账号，之前上稿的节奏也一直卡在"人手瓶颈"上。

到了今年上半年，我做了一个决定：不再靠加班扩产能，而是把整套流程搬到智能体里去执行。跑通之后的感受是这样的——一个人做八份人的事情，前提是你能把八份人的经验固化下来，让智能体在你不在电脑面前的时候仍然按你的方法做事。这就是我今天想跟大家分享的这条流水线的价值所在。

在正式动手之前，我用一张图先把整个链路铺开来看一眼，你心里就有底了：

flowchart LR
    A[你/口播/文档/表格] --> B[Codex 智能体总控]
    B --> C{任务类型}
    C -->|文案/长文| D[DeepSeek/Kimi<br/>推理引擎]
    C -->|图片/视频| E[即梦 3.0 API<br/>火山引擎]
    C -->|数字人| F[OmniHuman/豆包]
    C -->|语音识别| G[Faster-Whisper<br/>本地部署]
    C -->|知识检索| H[RAGFlow<br/>本地知识库]
    C -->|浏览器操作| I[影刀 RPA]
    D & E & F & G & H & I --> J[技能包 Skills]
    J --> K[飞书/本地文件/桌面工具]

看着模块多，但整个逻辑其实只有三层：Codex 是脑子，下面这一排工具是手脚，技能包是把每次跑的路径固化下来的肌肉记忆。你只要理解这一点，后面每一节的内容就都能对上号。

这套流水线适合的人群，我这里也把话说透——如果你只是偶尔用 AI 写点东西、生成个图片，那么直接用聊天窗口就够了，不必折腾。如果你需要批量、可复用、可交给别人跑的自动化流程，那么这条路走下来的性价比会明显高于人工堆叠。判断标准很简单：一件事你一年会做几十上百次，就值得做成技能包；只做一两次的东西，用聊天窗口临时解决就好。

下面进入正式的动手部分。前面几章的重点是打好"总控层"的基础，中间几章处理各种"手脚层"的接入，最后几章聚焦在数字人自动化、办公场景落地和合规底线上。

二、Codex CLI 从零安装配置：绕过账号壁垒的四条合规路径

先讲清楚 Codex 是什么。Codex 不是一个聊天工具，而是 OpenAI 出品的智能体编程工作台，你可以把它理解成"一个能读你本地文件、能写文件、能执行 shell 命令、能抓网页、能看工具返回结果继续推理的 AI 打工人"。这个特性是它区别于普通聊天窗口的关键——它不只是回答你的问题，它会自己动手把事情做完，做完后再把结果返回给你。

在国内环境下，直接用 Codex 的原生服务会遇到两个问题：一是账号获取门槛较高，二是网络访问不稳定。好在这两个问题都有非常直接的合规解法：把 Codex 的底座模型换成国产大模型。这条路径完全走国内公网，不涉及任何突破网络管制的动作。

2.1 Codex 桌面版和 CLI 版怎么选

先说客户端。Codex 提供两种形态，一种是桌面版（Codex Desktop App），另一种是命令行版（Codex CLI）。这两者的区别我个人的建议是：

初学者我推荐先从桌面版起步。安装方法在 Windows 上非常直接——打开系统的 Microsoft Store，搜索 Codex，找到应用后点"免费下载"就可以了；Mac 上同理，去 App Store 搜。这里有一个关键的坑要提前说清楚：装完之后先不要着急打开它。 因为默认的登录方式是走 OpenAI 官方账号的，你没有账号点进去也是白点。要先把接下来的桥接配置做好，再打开客户端。

桌面版和 CLI 版的配置差异（重点）： 两者共用同一套配置文件体系，但有一个关键区别——桌面版是通过图形界面里的 Provider 设置来切换模型的，你配好 config.toml 之后在桌面版的设置菜单里选对应的 Provider 就行；CLI 版则完全依赖 config.toml 和环境变量，没有图形界面可以点，所有配置都在终端里完成。 具体差异如下：

我的实际使用习惯是：日常探索和调试用桌面版，确认流程跑通之后，把最终的命令写成 CLI 脚本放到定时任务里跑。 这种"桌面版做原型 + CLI 版做生产"的组合，是我在莫潇羽@无忆研习社踩了无数次坑之后沉淀下来的最优分工。简单说：桌面版让你"看得见"，CLI 版让你"睡得着"。

2.2 为什么需要一个"协议桥"

2026 年 6 月之前，Codex CLI 允许通过 Chat Completions 协议接入第三方模型，配置起来直接改 config.toml 就行。之后 Codex 做了一次协议升级——弃用了 Chat Completions，强制使用 Responses API。这个变化带来了一个直接后果：DeepSeek、Kimi、GLM、Qwen 等国产模型原生只提供 Chat Completions 兼容接口，没法直接被新版 Codex 识别。

解决办法就是在中间加一层"协议桥"。这个桥的作用是把 Codex 发出来的 Responses API 请求翻译成 Chat Completions 请求，转发给国产模型，再把返回的结果翻译回 Responses 格式。听起来复杂，但目前社区已经把这套工具做得非常成熟了，普通人只需要选一个装上就行。

2.3 四条主流桥接方案横向对比

我把目前市面上比较活跃的四种方案整理成一张表，大家按自己的操作系统和习惯选：

如果你是刚上手，不知道选哪个，我建议直接用 Moon Bridge。它把整个过程做成了自动化脚本，跑一遍基本就好。

阿里云百炼直连方案（零中间层，推荐给已有阿里云账号的人）： 阿里云百炼的 Token Plan 已经原生支持 Responses API，Codex 可以直接对接，不需要任何第三方桥接工具。前提是你有一个阿里云账号，去百炼控制台创建 API Key，然后在 ~/.codex/config.toml 里这样写：

model_provider = "Model_Studio_Token_Plan_Personal"
model = "qwen3.8-max-preview"

[model_providers.Model_Studio_Token_Plan_Personal]
name = "Model_Studio_Token_Plan_Personal"
base_url = "https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

然后把 API Key 设到环境变量 OPENAI_API_KEY 里（macOS/Linux 写进 .zshrc 或 .bash_profile，Windows 用 setx 命令），重启终端即可。百炼 Token Plan 目前支持的模型包括 qwen3.8-max-preview、qwen3.7-max、qwen3.7-plus、qwen3.6-flash、glm-5.2、deepseek-v4-pro，覆盖推理、编码、长文等主流场景，个人测试额度也够用。注意：非 Responses API 原生支持的模型需把 wire_api 改成 "chat" 并安装旧版 Codex；日常选 qwen3.8-max-preview 走 Responses API 最省心。

2.4 一份最小可跑的 config.toml

以 DeepSeek 为例，桥接跑起来之后，Codex 端的配置文件长这样。这段代码你可以直接照抄，把 sk-你的Key 换成自己的即可：

model = "deepseek-chat"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com/v1"
wire_api = "responses"
experimental_bearer_token = "sk-你的DeepSeek-API-Key"

DeepSeek 提供的是与 OpenAI 兼容的接口，国内直连延迟很低，作为 Codex 的日常推理引擎表现相当稳。莫潇羽@无忆研习社 这边的实测经验是：编码任务和长文档整理这两类活儿，DeepSeek V4 已经完全够用；如果任务涉及非常复杂的多步推理，可以再多备一份 Kimi 或者 GLM 的 Key 做备用。

如果你手边有多个模型的 API Key，可以直接在 config.toml 里配多个 Provider，然后用 Codex 的 Profile 机制切换，做到"一天里不同任务用不同模型"。

2.5 三条常见坑我先替你踩了

• base_url 末尾要不要加 /v1：加。不加会拼错路径，出现"404 not found"报错。
• wire_api 要不要写成 responses：要。这就是前面说的协议桥的关键点。
• API Key 用环境变量还是明文写在配置里：建议环境变量。把 Key 明文塞进 config.toml 之后如果不小心把配置分享出去，Key 就废了。

配置搞定之后，重启 Codex 客户端或者 CLI，登录时选择你新加的 Provider，就能看到国产大模型作为底座跑起来了。此时你会发现，即便没有官方账号，Codex 完整的智能体能力（读文件、写文件、执行命令、抓网页）在国产模型上全部都是可用的。

关于合规，这里必须把话说透——Codex 客户端本身是境外服务商 OpenAI 提供的开源工具，安装使用不受限制；但如果你在其中调用了境外模型服务（如直接使用 OpenAI 官方 API），需严格遵守国内网络与内容管理相关规定。如果你不确定某条链路是否合规，有一个简单的判断标准：凡是数据传输全程走国内公网、服务器在国内、运营主体持有国内相关牌照的服务，就是最省心的合规方案。本文后续所有实操均以 DeepSeek、通义千问、Kimi、GLM 等国产模型为主力，正是基于这个考量。如果你因特殊需求确实要接入境外模型，建议提前咨询法务或合规人员，不要仅凭社区教程"能跑通"就上线使用——能跑通和合法合规是两回事。

配置到这里为止，你已经拥有一个可以在国内网络环境下正常运转的 AI 智能体工作台了。接下来要做的，就是让这个工作台变得越来越懂你的工作方式——这就要靠"技能包"机制。

三、技能包（Skills）机制：让智能体记住你的工作方法

先讲一个我自己反复踩的坑，帮大家绕开它。刚上手 Codex 的时候，我每次开新对话都要把"我要做什么、每一步做什么、每一步要什么参数、每一步遇到问题怎么回退"这一整套流程再对它说一遍。头几次觉得没什么，做多了就发现——我不是在用 AI，我是在教 AI。每次都在教。

技能包（Skills）就是解决这个问题的机制。 你可以把它理解成"智能体的肌肉记忆包"：把一次完整的对话过程沉淀成一个可重用的技能，下次直接调用就行，中间的说教环节全部省掉。

3.1 一个技能包长什么样

技能包其实非常朴素，就是一个文件夹，里面固定有两样东西：

• 一个叫 SKILL.md 的文件，用来描述"这个技能是干嘛的、什么时候触发、要满足哪些约束、输出是什么样"。
• 一个 scripts/ 目录（如果需要的话），放具体执行时会用到的脚本、模板、参考例子。

以下是一个"历史人物短视频"技能包最简化的骨架：

my-skills/
└── historical-figure-video/
    ├── SKILL.md          # 技能说明书
    └── scripts/
        ├── prompt-image.md   # 图片提示词模板
        ├── prompt-video.md   # 视频提示词模板
        └── api-example.json  # API 调用示例

SKILL.md 的写法有一套约定俗成的结构，我给一个可以直接照抄的模板：

---
name: historical-figure-video
description: 输入一个历史人物名字，自动完成"文案-配图-视频-剪辑"全流程，
             产出可发布的短视频素材。触发条件：用户上传或提到历史人物名字并
             说"帮我做条视频""帮我做条短剧""帮我做人物介绍"。
---

# 技能说明

## 输入
- 历史人物名字（必填）
- 视频时长偏好（可选，默认 30 秒）
- 画面风格偏好（可选，默认写实历史剧风格）

## 执行步骤
1. 生成人物一生的关键节点九段文案，每段不超过 80 字
2. 为每段文案生成一张 9:16 的配图，调用即梦 4.6 图片 API
3. 用首尾帧方式把九张图组合成九段短视频，每段约 5 秒
4. 输出一份剪辑草稿 JSON

## 输出
- 结构化的 result/ 文件夹，包含 文案.md / 图片 9 张 / 视频 9 段 / 剪辑草稿.json

## 约束
- 图片提示词必须 UTF-8 编码
- 图片和视频要并行调用 API，并行下载文件
- 全程不引用真实照片，避免肖像权风险

这份说明书是给智能体看的，写得越清晰、越像"新员工岗前培训手册"，效果越好。

3.2 从"教它一次"到"自动封装成技能"

一个很关键的用法在于——你不用自己动手写这份 SKILL.md。你只需要跟 Codex 完成一次完整的对话，把流程跑通、跑对，然后说一句"把刚才这一整套流程封装成一个技能，命名叫 xxx"，Codex 会自己整理对话历史，把关键步骤、依赖工具、参考例子全部沉淀到一个新的技能包里。

这里有一个我自己总结的小规矩：先跑通，再封装，绝不反向操作。为什么？因为一次都没跑通的流程，你封装出来的技能包也是错的，下次调用只会一次比一次错。我一般会至少跑通两遍——第一遍作为原型验证，第二遍换个输入参数（比如换一个历史人物）确认它的通用性没问题，然后才让它封装。

3.3 技能调用 vs 每次现教的效率对比

用一张表直观感受一下差别（时间是我在莫潇羽@无忆研习社实操记录的近似值）：

差别不在生成本身，而在"教它"的部分。做十次任务差别就出来了。

3.4 技能包的组织建议

我个人的经验是不要一上来就搞很大的技能库，那样反而会让智能体在检索技能时出现选错情况。先从三到五个高频技能开始：比如"给一段文案配九张图"、"用文案生成一段口播视频"、"把飞书表格里的客户按优先级排序"，这三样跑熟了再扩展。

技能包之间也可以嵌套引用。举个具体例子——"历史人物短视频"技能会调用"图片生成"技能，"图片生成"技能会调用"UTF-8 提示词处理"这样的底层小技能。这样每一层都可以独立测试，出了问题定位也快。

四、并发与工具接入：让流水线跑起来的两根关键血管

技能包解决的是"智能体记得你的做事方法"，但如果单次流程本身跑得很慢，再多技能包也没用。这一节讲两件事：怎么把并发用起来，以及怎么让智能体学会调用你新接入的工具。

4.1 并发数不是想开就开

第一次做九张图的批量生成的时候，我天真地以为智能体会自己并行处理，结果它老老实实一张一张排队做，跑完九张花了将近十分钟。后来我才意识到——并发是要显式告诉它的，不然它默认串行。

告诉智能体并行有两个关键点：并行调用 API 和并行下载文件。这两件事必须一起说，因为很多任务的瓶颈其实在下载环节，不是在生成环节。你调九个生成请求是可以同时发的，但下载九个文件如果一个一个来，反而拖慢整体节奏。

在提示词里加这样一句话就基本能解决问题：

批量任务执行要求：
1. 所有图片生成 API 并行调用，同时提交所有请求
2. 所有生成产物并行下载，一个不用等另一个下完
3. 单次并发数保持在 5 到 8 之间，不要超过 10

关于并发上限，这里再补一句——不是你电脑不行，是 API 服务商的限流。以火山引擎的即梦系列 API 为例，一般的账户级并发数就在 5 到 10 之间，你开到 20 也没意义，请求会被排队甚至拒绝。刚开始跑的时候我建议保守一点，从 5 开始，观察一下服务端的响应稳定性再往上调。

4.2 智能体怎么学会一个新工具

这套流水线里会用到的外部工具越来越多——即梦 API、DeepSeek API、Faster-Whisper、RAGFlow、影刀 RPA。每次接入一个新工具，都要让智能体先"学会"它。学会的方法说起来只有三步：

1. 把官方 API 文档丢给它：直接从 API 文档页复制一整段完整的接口说明，粘贴到对话里。莫潇羽@无忆研习社 建议大家不要总结、不要精简、不要"我用大白话给你讲"，就丢原文，越原始越好。
2. 附上一个可跑的调用示例：这是最容易被忽视的一步。文档里的字段解释再多，也不如一个真实的调用样例来得直观。绝大多数官方 API 文档页都有"快速接入"或者"示例代码"的按钮，一键复制就能拿到。
3. 告诉它约束条件：这个约束不是文档里的，是你自己踩坑总结出来的。比如"提示词必须 UTF-8 编码"、"输入图片必须是链接不能是本地路径"、"输出比例默认 9:16"这类。

三步做完，智能体基本能一次调对。如果调用失败，让它自己看返回的报错信息去改，而不是你去改——这个习惯很重要，因为你会发现它自己排查错的效率经常比你手动改还快，你只要在一边看着，出现严重跑偏时再喊停。

4.3 一份适用于所有 API 接入的通用提示词模板

我把这套接入流程压缩成一份可以直接复用的模板，接入任何新的 API 都能套：

# 新工具接入
你现在要接入一个新的 API：{工具名字}

## 官方文档
{粘贴完整的官方文档说明}

## 调用示例
{粘贴一段官方给的可跑示例}

## 关键约束
- {你自己总结的约束一}
- {你自己总结的约束二}
- 提示词/参数一律 UTF-8 编码

## 期望
- 先做一次最小测试调用，看能否走通
- 走通之后再帮我把这个能力封装成一个技能包
- 走不通请把完整报错信息告诉我

这份模板我从年初用到现在，基本上是无往不利。核心思路就是——先给它文档、再给它例子、再给它约束、最后让它自己封装成技能。

4.4 UTF-8 与中文乱码的老问题

有一个坑要单独讲，因为它太常见——生成图片的时候，提示词里的中文经常出现乱码。乱码的原因通常是编码没显式声明，导致 API 服务端拿到的是乱七八糟的字节流。

解决办法很简单，在提示词里明确说明"输入提示词的编码为 UTF-8"，把这句话作为一条硬性约束写进技能包的 SKILL.md 里。这一句话能省下你后面无数次调试。

4.5 什么时候该中断，什么时候该让它跑

最后说一个心态问题。用 Codex 智能体这种工作台，你会有大量时间是在"等"。刚开始不习惯，总觉得自己应该做点什么。但真到你打断它、手工介入之后，往往它反而更混乱。

我的经验是这样区分：

• 可以让它跑的情况：进度条在动、有阶段性输出、报错在自我修复、消耗在预算之内。
• 必须中断的情况：连续三次调用同一个 API 都失败、开始重复自己刚做过的动作、生成的中间结果明显跑偏了主题、消耗即将超出预算。

一个小技巧是——给智能体设置一个"预算兜底"，比如"这个任务的总 API 调用次数不超过 50 次，超过就暂停等我确认"。这样你就不用一直盯着屏幕，也不用担心一觉醒来账单爆表。

到这里为止，"总控层"的基础就打完了。接下来的章节我们要开始真正接入各种"手脚层"的工具，让这套流水线跑出实际的产出。

五、多模态素材流水线：图-视频-音一条龙的实操路径

前面搭好了脑子，这一节开始让手脚动起来。多模态素材是这条流水线里最"看得见摸得着"的部分——图片、视频、口播语音、数字人，做出来就能用。

5.1 图片生成：即梦 4.6 的正确打开方式

图片这块，国内目前性价比和质量的综合最优我个人还是投给火山引擎的即梦 4.6。原因有两个：一是它对中文提示词的理解本土化程度高，古装、水墨、国潮这些场景吊打大部分海外模型；二是接入即梦 API 需要遵守国内网络与内容管理相关规定这一层已经天然满足，不需要担心合规问题。

调用即梦图片 API 的关键参数其实就四个：

这里补一个提示词写作的小秘诀——你不需要成为提示词工程师，你只需要成为"抄写员"。即梦官方文档里每一个模型页面都有一堆调好参数的示例，直接复制、把里面的主体换成你要生成的东西，效果就已经比大部分人从头写的要好。

关于价格：AI 图片生成 API 的价格变动非常快，上面所有描述都是我写稿时（2026 年 7 月）的近似情况；请以官方定价页面的实时数据为准。 一般来说测试用的额度平台会免费送一部分，够普通人跑几百张图不成问题。

5.2 视频生成：即梦 3.0 首尾帧是关键

视频这块，即梦 3.0 系列有一个特别关键的能力叫首尾帧图生视频——你给一张起始图和一张结束图，它自动补出中间的运动过程。这个能力对做"多段视频拼接"的自媒体人来说是革命性的。

举一个具体场景：你要做一个"武则天一生"的短剧，需要九个场景（少年、入宫、册封、称帝、晚年等等）。传统做法是每一段单独生成视频，结果九段视频画面风格根本连不上。用首尾帧的做法是这样的：

第 1 段视频：起始图 = 少年图，结束图 = 入宫图
第 2 段视频：起始图 = 入宫图，结束图 = 册封图
第 3 段视频：起始图 = 册封图，结束图 = 称帝图
...以此类推

因为每一段视频的起始图就是上一段的结束图，最终拼接出来的整个短剧画面就是连贯的。这个技巧值得写进你的技能包里。

即梦 3.0 的视频接口是异步任务——你提交一个生成请求，服务端返回一个 task_id，你需要用这个 task_id 去轮询查询结果。这个模式对写脚本的人比较友好，因为你可以在等待的时候做别的事。但对新手来说容易踩一个坑：不要设置太短的轮询间隔，一般 15 到 30 秒查一次就够，太频繁会被限流。

视频生成能力目前分成 720P、1080P、3.0 Pro 三档，分辨率越高单次成本越高，Pro 还多了多镜头叙事能力。莫潇羽@无忆研习社 的建议是：日常测试用 720P，正式发布用 1080P，做产品宣传片这种需要多镜头叙事的再用 Pro。

5.3 数字人对口型：OmniHuman 和豆包声音合成

数字人这一节要说的是"让一张照片开口说话"这类能力。核心逻辑其实很简单——你上传一张人物图片、上传一段音频，模型自动做面部关键点检测和口型对齐，输出一段视频。

火山引擎的 OmniHuman 系列在这方面表现相当稳定。1.5 版本开始支持"上传一张图 + 一段视频"作为参考，让生成的数字人的动作和口型都对得上。对普通的口播视频制作来说，这个已经够用了。

配套的音频合成用豆包的语音合成 API。豆包可以让你上传一段自己的语音样本做声音克隆，然后用这个克隆声音去合成任意文字的语音。这里必须给一个合规提示：AI 声音克隆技术涉及肖像权和声音权，只能克隆你自己本人的声音，或者拿到明确授权的他人声音；不得用于诈骗、误导、冒充他人身份等违规场景。国内自媒体平台发布 AI 合成的音频视频，需按平台规则做 AI 内容标注。

5.4 图-视频-数字人的成本感（写稿时近似值）

我把三类能力的成本感给大家一个大致的锚点，方便你估算预算。注意：这些价格变动非常快，上面所有数字均为写稿时的近似行情；请以官方定价页面的实时数据为准。

以我个人做一条完整"历史人物三分钟短视频"的经验为例，全流程包含九张图 + 九段视频 + 一段数字人开头 + 一段语音合成，端到端的 API 消耗大概在几块到十几块钱之间。如果你的思路是"用这个做副业尝试"，这个成本结构基本可以覆盖，前期完全可以拿新用户免费额度测试，验证方向对了再充值。

5.5 服装电商这个案例说透了

素材里我讲得最多的一个案例是服装电商的短视频批量生产。这个场景的通用价值高，我在这里把方法论总结成四步：

1. 模特图确定风格：先用即梦生成一张符合品牌调性的模特图，作为所有后续视频的"锚点"。
2. 首尾帧多角度：以这张模特图为起始帧，让模特做不同角度的展示（正面、侧面、转身、手持产品），生成多段短视频。
3. 动作幅度控制：告诉模型"面部保持 80% 不变，其余部分做中等幅度的生活穿搭动作"。这一句是关键，防止出现动作过大导致人物走形。
4. 室内场景稳定：室内的空间要保持一致，不然拼起来会像不同场景乱剪。

这套方法你换成珠宝、化妆品、家居用品都能直接套用。核心就是"锚定风格 + 首尾帧连贯 + 动作幅度可控"这三条。

六、本地模型的正确用法：语音识别是甜点，图像视频先别碰

前面五节都在讲云端 API。这一节要处理一个大家很关心的问题——哪些能力值得本地化部署，哪些不值得。

我这里直接给结论，然后再解释：语音识别本地化极其香，文档知识库本地化也很香，图像生成本地化目前效果一般，视频生成本地化基本可以放弃。

6.1 为什么这么判断

判断依据只有一条——开源模型和商用模型的能力差。企业不会把自己最强的模型开源出来免费给大家用，开源出来的都是"够用但不惊艳"的档次。对图像生成和视频生成这两个特别看效果的场景，"够用但不惊艳"就意味着"做出来没法给客户看"。而语音识别是一个"看准确率就够了"的场景，开源模型的准确率已经和商用不相上下，本地化就非常合理。

用一张表把这个判断说清楚：

6.2 Faster-Whisper：4 倍速的本地语音识别

Faster-Whisper 是原版 OpenAI Whisper 的"性能怪兽"重实现，基于 CTranslate2 推理引擎做的深度优化。它的准确率和原版 Whisper 完全一致，但推理速度快 4 倍，显存占用降低 38% 左右——这是社区实测得出的稳定结论。

对普通人来说，装这套东西的步骤有两条路：

路径一：拉源码自己装（适合有 Python 基础的）

# 建议先建个虚拟环境
python -m venv whisper-env
whisper-env\Scripts\activate  # Windows
# source whisper-env/bin/activate  # Mac/Linux

# 安装 faster-whisper
pip install faster-whisper

装完之后写一段最简单的转录脚本，直接就能跑：

from faster_whisper import WhisperModel

# 加载模型，第一次运行会自动下载
# medium 是中等大小模型，兼顾速度和精度
model = WhisperModel("medium", device="cuda", compute_type="float16")
# 没有显卡用 CPU 版本：
# model = WhisperModel("medium", device="cpu", compute_type="int8")

segments, info = model.transcribe("your_audio.mp3", beam_size=5)
print(f"检测语言：{info.language}")
for segment in segments:
    print(f"[{segment.start:.2f}s -> {segment.end:.2f}s] {segment.text}")

路径二：下载整合包直接用（适合完全零基础）

社区里有大佬把 Faster-Whisper 打包成了带图形界面的整合包，双击就能用。你只需要选择模型大小、选择音频文件、点开始，几分钟就出结果。莫潇羽@无忆研习社 的建议是先用整合包体验一下，觉得效果符合预期再考虑源码集成。

6.3 模型大小怎么选

Faster-Whisper 支持从 tiny 到 large-v3 一共七种模型规格。选择的原则是"用够用的最小的那一档"：

医疗、法律这类对准确率要求极高的场景用 large-v3；日常口播视频转字幕、会议记录用 medium 就完全够了。

6.4 模型下载：三条国内合规路径（告别 HuggingFace 直连焦虑）

Faster-Whisper 默认从 HuggingFace 拉模型。这里要说一下：HuggingFace 是一个开源模型社区，Codex 智能体的默认下载源之一就是它。如果你的网络访问 HuggingFace 不稳定，有两种合规方案：

• 走 HuggingFace 的国内镜像源：在环境变量里设置 HF_ENDPOINT=https://hf-mirror.com，就会自动走镜像。
• 手动下载模型文件：从整合包提供的网盘或者国内的模型社区（比如魔搭 ModelScope）直接下载模型文件，放到对应目录即可。

请注意 HuggingFace 是境外服务，直接通过其境外域名下载模型属于访问境外网络资源，需遵守国内网络与内容管理相关规定。对于个人学习研究用途，强烈建议优先使用以下国内合规替代方案，完全规避潜在的网络合规风险：

6.4.1 魔搭 ModelScope 直接下载（最推荐）

魔搭（modelscope.cn）是阿里云旗下的国内模型社区，Faster-Whisper 的多个版本模型（从 tiny 到 large-v3）均已上架，下载全程走国内 CDN，速度快且完全合规。先用 pip install modelscope 装好 SDK，然后：

from modelscope import snapshot_download
model_dir = snapshot_download(
    "dev4life/faster-whisper-medium",
    cache_dir="./faster-whisper-models"
)

下载完成后用本地路径直接加载模型即可，不再经过 HuggingFace。魔搭网页端也支持直接下载压缩包，解压即用。

6.4.2 HuggingFace 国内镜像（备选）

设置环境变量 HF_ENDPOINT=https://hf-mirror.com，自动走镜像拉模型。稳定性不如魔搭，作备选。

6.4.3 整合包自带网盘分流（零基础友好）

社区整合包通常附带百度/夸克网盘的模型分流，对零基础最友好。

核心原则：数据不出境、下载走国内，魔搭是首选。

6.5 Ollama：本地大模型的极简部署

除了语音识别，你可能还想在本地跑一个大模型用作离线场景。Ollama 是目前最平民的方案，装完之后基本就是一条命令的事：

# 下载 Ollama 本体（跨平台）
# https://ollama.com/download

# 拉一个模型
ollama pull qwen2.5:7b   # 通义千问 7B，中文能力强
# 或者
ollama pull deepseek-r1:7b  # DeepSeek 蒸馏版

# 起服务（自动占用 11434 端口）
ollama serve

# 用命令行直接聊
ollama run qwen2.5:7b

跑起来之后，Ollama 提供的是一个 OpenAI 兼容接口（http://localhost:11434/v1），你的 Codex CLI 直接把这个 URL 填进 config.toml 就能把本地模型接进来。这就是所谓的"本地化闭环"。

6.6 本地大模型的能力边界要认清

我最后再泼一盆冷水——本地跑的 7B、13B 参数的模型，能力上确实无法和云端 DeepSeek V4、Kimi 这些商用模型比。它们适合的场景是：

• 对隐私极度敏感的数据处理（比如公司内部合同、员工信息）
• 完全离线的场景（户外、无网环境）
• 成本极度敏感的批量任务（跑几百万次调用云端会心疼）

如果你的场景不是上面这三种，坦白说走云端更省心。莫潇羽@无忆研习社 这边最终的落地组合是——云端 DeepSeek 跑主流程 + 本地 Faster-Whisper 处理语音 + 本地 RAGFlow 存知识。这是我实测下来综合成本最低、效果最稳的一个组合，供大家参考。

七、本地知识库：RAGFlow 从零搭建到日常使用

前一节说了本地大模型的边界，这一节要讲的 RAGFlow 是我认为这条流水线里最被低估、但价值最高的一个环节。

7.1 先把 RAG 说清楚

RAG 全称 Retrieval-Augmented Generation，检索增强生成。用大白话讲就是——大模型本身像一个知识面很广但没做过你行业作业的实习生，你让他直接答问题他会瞎编（也就是所谓的"幻觉"）；如果你先把你行业的资料塞给他，让他看完再答，他就靠谱多了。

RAG 的一般流程是：把你的文档（PDF、Word、Excel、图片等）切成一小块一小块的碎片 → 每一块做向量化处理存进向量数据库 → 用户提问时先从数据库里检索出最相关的几块碎片 → 把碎片和问题一起塞给大模型 → 大模型基于碎片生成回答，同时告诉你这个结论出自哪份文档的哪一段。

这套流程听起来复杂，但 RAGFlow 已经把它全链路封装好了，你只需要用就行。

7.2 RAGFlow 为什么值得用

市面上开源的 RAG 框架其实不少，我最终选定 RAGFlow 主要看中它三个能力：

• DeepDoc 深度文档理解：能处理 PDF 扫描件、复杂表格、图文混排的文档，不会一切就把关键信息切散。
• 多种分块模板：内置了针对报告、合同、法律、表格、论文等不同类型的分块模板，选对模板检索精度立刻上一个档次。
• 可视化引用溯源：生成的每一句回答都能点回去看到原文出处，对做严肃工作的人来说这是刚需。

7.3 部署最小配置

RAGFlow 官方推荐用 Docker 部署，硬件门槛我这里说清楚：

个人使用的话，一台 32G 内存 + 500G 空余磁盘的台式机就能跑得比较顺畅。启动命令我贴一份最简版本：

# 前置条件：装好 Docker Desktop

# 拉取镜像和配置
git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

# 检查 vm.max_map_count 不小于 262144
sysctl vm.max_map_count
# 如果小于就调整（Linux）
# sudo sysctl -w vm.max_map_count=262144

# 一键启动
docker compose up -d

启动后浏览器打开 http://localhost 就能进入管理界面。这里补一句——如果你实在没有本地环境，官方也提供了在线 demo（demo.ragflow.io）可以直接体验，验证一下效果再决定要不要本地部署。

7.4 挂载国产大模型作为推理引擎

RAGFlow 本身只负责"文档管理 + 检索 + 提示词组装"，真正的回答生成还要挂一个大模型。它支持挂 OpenAI、DeepSeek、Ollama、百度文心、Kimi 等多种主流模型。

我推荐挂 DeepSeek 或者本地的 Ollama。前者精度更高，后者完全离线：

模型供应商：DeepSeek
API Key：你的 DeepSeek Key
Base URL：https://api.deepseek.com/v1
模型名称：deepseek-chat

Ollama 那边的挂法更简单，Base URL 填 http://host.docker.internal:11434/v1（Docker 里要访问宿主机就用这个特殊域名），模型名称填你在 Ollama 里 pull 下来的那个即可。

7.5 分块策略是精度的分水岭

这是我踩过最多坑的地方，一定要单独讲一下。RAGFlow 里同一份 PDF，你用不