开源本地语音工作室：声音克隆+工作流引擎实战指南-平芜编程栈

1. 这不是“语音合成”，而是一个能自己搭、自己调、自己养的本地语音工作室

最近两周，我桌面上常驻的三个窗口分别是：一个跑着 Whisper 的终端、一个加载了 So-VITS-SVC 模型的 WebUI、还有一个正在调试节点连接的 Flowise 工作流画布。这不是在复现某篇论文，也不是在跑某个云服务API——这是我在 Windows 11 笔记本上完整搭建起来的「开源声音克隆与工作流引擎」，整套系统不联网、不传数据、不依赖任何远程服务，所有音频处理、声学建模、流程调度全在本地完成。核心关键词就五个：开源、声音克隆、工作流引擎、本地运行、语音工作室——它不是一个工具，而是一整套可拆解、可替换、可演进的语音生产基础设施。

很多人第一反应是：“这不就是个变声器？”或者“是不是又一个带UI的TTS前端？”——完全不是。真正的差异在于控制粒度。传统语音工具（哪怕是开源的）大多封装成黑盒：你给文本，它吐音频；你传一段人声，它返回相似音色。但这个项目把整个语音生成链路彻底打开：从原始音频预处理（降噪/切片/对齐）、声学特征提取（F0/pitch、mel谱、说话节奏）、音色建模（VITS、DiffSVC、RVC v2/v3）、到后处理（响度均衡、混响注入、格式封装），每个环节都暴露为独立可配置的模块。更关键的是，这些模块之间不是硬编码串联，而是通过标准化接口（HTTP API + JSON Schema + WebSocket事件）被一个轻量级工作流引擎动态编排。你可以用拖拽方式定义“先用Whisper转写→再用Bert-VITS2做情感增强→最后用Real-ESRGAN音频超分”，也可以写Python脚本触发特定分支逻辑，甚至接入本地知识库做语义驱动的语调调整。

它解决的不是“怎么让AI说话”这个表层问题，而是“如何让普通人像搭乐高一样构建自己的语音生产流水线”。比如我帮本地一家儿童绘本工作室做的定制流程：录入主播5分钟干声 → 自动切出127个有效句子 → 对每个句子打标（疑问句/感叹句/拟声词） → 根据标签路由到不同音色模型（女声温柔版/男声故事版/卡通音效版） → 批量生成后自动插入背景音效（雨声/篝火/飞船引擎）→ 最终导出带章节标记的MP3+配套SRT字幕。整个流程从原始录音到成品交付，耗时23分钟，全程无人工干预。而这一切，全部运行在我那台16GB内存、RTX 3060 Laptop的旧笔记本上——没有GPU加速？那就用ONNX Runtime量化模型；显存不够？就用CPU推理+分块缓存策略。所谓“本地运行”，不是一句口号，而是每一行代码、每一个模型、每一个调度决策都经得起你亲手审计和修改。

这套系统真正面向的，从来不是想“一键克隆老板声音”的短视频运营，而是那些需要长期、稳定、可控语音生产能力的实体：无障碍内容制作团队、方言保护项目组、教育类APP开发者、播客独立制作人、甚至工业设备语音提示系统维护员。他们不需要“最先进”的模型，但需要“最可靠”的路径——模型可以换，数据可以重训，流程可以迭代，但底层架构必须透明、可验证、可审计。这也是为什么它强调“开源”：不是为了贴个MIT License标签，而是确保从音频采样率设置（48kHz vs 16kHz对基频提取的影响）、到梅尔频谱参数（n_mels=80还是128）、再到VITS损失函数中KL散度权重（β=0.1还是0.5）——所有影响最终音质的37个关键参数，都在config.yaml里明明白白写着注释。你不需要成为语音博士，但必须清楚每个开关拧下去会改变什么。这才是“语音工作室”的本质：它不是消费工具，而是生产环境。

2. 为什么必须是“工作流引擎”？——拆解语音克隆背后的真实复杂性

2.1 声音克隆从来不是单点技术，而是一条脆弱的链式反应

很多人以为声音克隆 = “喂一段音频 + 输入文字 → 输出语音”。实测过就会发现，这个等式在真实场景中几乎永远不成立。我拿自己录制的10分钟普通话新闻稿测试过主流开源方案，结果如下：

环节	RVC v2默认流程	So-VITS-SVC v4	Bert-VITS2 v2.1	我的本地工作流
音频预处理	仅简单降噪	需手动切片对齐	内置Whisper强制对齐	自动检测静音段+能量阈值自适应切片
特征提取	固定hop_size=256	支持pitch shift但无GUI	F0提取精度高但耗时长	并行计算F0+energy+duration，缓存中间结果
模型推理	GPU显存占用峰值4.2GB	CPU模式下崩溃	支持ONNX但需手动转换	动态显存分配+CPU/GPU混合推理调度
后处理	无	可选Griffin-Lim	内置HiFi-GAN vocoder	可插拔式后处理链（响度标准化→房间模拟→格式转换）

表格里最后一列“我的本地工作流”不是某个现成软件，而是用Flowise + FastAPI + PyTorch构建的调度系统。关键差异在于：其他方案把所有环节打包成一个不可拆分的二进制，而工作流引擎把每个环节变成可独立升级的“服务单元”。举个具体例子：当客户要求“保留原声中的轻微气声质感”，RVC默认的MelGAN声码器会抹平这种细节，但So-VITS-SVC的BigVGAN就能保留。在传统方案里，这意味着重装整个环境；而在工作流引擎中，只需在WebUI里把“声码器”节点从MelGAN切换到BigVGAN，重新部署该模块即可——其他12个节点（切片、对齐、F0提取等）完全不受影响。

提示：工作流引擎的价值不在“炫技”，而在“容错”。语音克隆中最常见的失败不是模型不准，而是上游环节的微小偏差被逐级放大。比如预处理时静音阈值设高了0.5dB，导致句子切歪100ms，后续对齐误差就会让F0曲线抖动，最终输出语音出现卡顿。工作流引擎通过节点间明确的数据契约（如每个切片必须包含start_time/end_time/timestamps字段）和实时日志追踪（每个节点输出SHA256校验值），让问题定位从“整个流程崩了”变成“第3个节点的timestamp字段缺失”。

2.2 工作流引擎不是流程图，而是语音生产的操作系统

市面上很多“工作流引擎”本质是可视化脚本编辑器（比如Node-RED），但语音处理有其特殊性：计算密集、IO频繁、状态敏感。这就决定了它不能简单套用通用引擎。我们采用的方案是三层架构：

调度层（Flowise + 自定义Adapter）：负责可视化编排、节点状态监控、异常熔断。特别改造了Flowise的HTTP节点，使其支持流式音频传输（multipart/form-data分块上传）和WebSocket实时进度推送。
执行层（FastAPI微服务集群）：每个语音处理能力（Whisper转写、RVC克隆、FFmpeg后处理）都封装为独立FastAPI服务，通过Docker Compose管理生命周期。关键设计是服务发现机制：调度层不硬编码IP端口，而是通过Consul注册中心动态获取可用实例。
数据层（SQLite + 内存映射文件）：避免传统数据库的IO瓶颈。音频片段用memory-mapped numpy array直接读写，元数据（时间戳、标签、模型版本）存SQLite。实测10万条语音记录查询响应<15ms。

这个架构带来的实际收益是什么？举个运维场景：客户突然要求增加粤语克隆能力。传统做法是停机更新整个系统；而在这里，只需：

新建一个whisper-cantonese服务容器（基于OpenAI Whisper的粤语微调版）
在Flowise中添加新节点并配置输入输出Schema
将原有“语言识别”节点的路由规则改为：检测到粤语文本 → 转发至whisper-cantonese服务整个过程耗时11分钟，期间其他普通话业务完全不受影响。

注意：工作流引擎的“轻量级”是相对的。我们刻意避开Airflow/Kubeflow这类重型方案，因为它们引入的K8s/YAML学习成本远超语音处理本身。最终选择Flowise的核心原因是：它的节点定义是JSON Schema，而语音处理的关键参数（如RVC的index_ratio、f0up_key）都能用JSON精确描述——这意味着你可以用Python脚本自动生成工作流配置，实现“流程即代码”（Workflow as Code）。

2.3 “本地运行”的真实代价与取舍智慧

“完全本地运行”听起来很美，但必须直面三个物理现实：

第一，显存墙。RVC v2的PyTorch模型在FP16精度下需3.2GB显存，而So-VITS-SVC的VITS部分需4.8GB。我的RTX 3060 Laptop只有6GB显存，这意味着：

无法同时加载多个大模型
无法使用高分辨率mel谱（n_mels=128会爆显存）
推理batch_size只能设为1

解决方案不是“等硬件升级”，而是算法级妥协：我们用ONNX Runtime替代PyTorch推理，在保持98%音质的前提下将显存占用压到1.9GB。具体操作是：

# 将PyTorch模型导出为ONNX（需修改VITS源码，禁用torch.nn.functional.interpolate的动态shape） python export_onnx.py --model_path ./models/vits.pth --output_path ./models/vits.onnx --opset 15 # 使用ORT优化器量化（INT8精度，实测PSNR下降仅0.7dB） onnxruntime-tools quantize --input ./models/vits.onnx --output ./models/vits_quant.onnx --calibrate_dataset ./calib_data/

第二，CPU瓶颈。Whisper-large-v3的CPU推理耗时约8分钟/小时音频，根本无法满足批量需求。我们的解法是异步流水线：将音频切片后分发到4个CPU核心并行处理，每个核心运行独立的Whisper实例，结果汇总后再进入下一环节。实测效率提升3.2倍，且内存占用稳定在3.1GB（未超16GB上限）。

第三，存储压力。一个高质量语音克隆项目，原始数据+中间特征+模型权重轻松突破50GB。我们采用分层存储策略：

热数据（当前项目音频、缓存特征）：NVMe SSD（读写>2GB/s）
温数据（历史项目模型、通用声码器）：SATA SSD（读写>500MB/s）
冷数据（原始录音备份、日志）：机械硬盘（自动归档脚本每日执行）

这套策略让1TB NVMe SSD足够支撑20个并发项目，而无需购买昂贵的全闪存阵列。

3. 从零开始搭建：一套可复现的本地语音工作室实操指南

3.1 环境准备——拒绝“pip install一切”，精准控制依赖

不要试图用pip install -r requirements.txt一键安装。语音项目的依赖冲突是出了名的（PyTorch/CUDA/ONNX/Triton版本稍有不匹配就会报CUDA_ERROR_INVALID_VALUE）。我的实践是分层隔离：

基础环境（一次性配置）

# 创建专用conda环境（避免污染全局Python） conda create -n voice-studio python=3.9 conda activate voice-studio # 安装CUDA Toolkit 11.8（适配RTX 30系显卡） conda install -c conda-forge cudatoolkit=11.8.0 # 安装PyTorch 2.0.1（严格对应CUDA 11.8） pip3 install torch==2.0.1+cu118 torchvision==0.15.2+cu118 torchaudio==2.0.2+cu118 --extra-index-url https://download.pytorch.org/whl/cu118

模块化安装（按需启用）

# 仅安装核心框架（不碰模型） pip install fastapi uvicorn flowise onnxruntime-gpu gradio # RVC克隆模块（需额外编译） git clone https://github.com/RVC-Project/Retrieval-based-Voice-Conversion-WebUI.git cd Retrieval-based-Voice-Conversion-WebUI pip install -e . # So-VITS-SVC模块（注意分支） git clone -b v4.1 https://github.com/svc-developers/so-vits-svc.git cd so-vits-svc pip install -e ".[dev]" # Whisper转写（官方包即可） pip install openai-whisper

实操心得：每次新增模块前，务必用conda list检查CUDA版本是否一致。曾因onnxruntime-gpu自带CUDA 12.1导致PyTorch CUDA 11.8失效，排查耗时3小时。建议在environment.yml中锁定所有关键包版本：

dependencies: - python=3.9 - cudatoolkit=11.8.0 - pytorch=2.0.1=py39_cuda118_cudnn8_0 - onnxruntime-gpu=1.16.3=py39_cuda118_h7a5c63c_0

3.2 核心模块部署——每个服务都是可独立验证的原子单元

步骤1：部署Whisper转写服务（FastAPI）
创建whisper_api.py：

from fastapi import FastAPI, UploadFile, File import whisper from pathlib import Path app = FastAPI() model = whisper.load_model("large-v3") # 加载时指定设备 @app.post("/transcribe") async def transcribe_audio(file: UploadFile = File(...)): audio_path = Path("temp") / file.filename audio_path.parent.mkdir(exist_ok=True) with open(audio_path, "wb") as f: f.write(await file.read()) # 关键：强制使用CPU避免显存争抢 result = model.transcribe(str(audio_path), device="cpu", language="zh") # 返回结构化JSON（供工作流引擎解析） return { "text": result["text"], "segments": [{"start": s["start"], "end": s["end"], "text": s["text"]} for s in result["segments"]] }

启动命令：uvicorn whisper_api:app --host 0.0.0.0 --port 8001 --workers 2

步骤2：部署RVC克隆服务（Flask轻量版）
为避免RVC WebUI的臃肿，我们提取核心推理逻辑：

# rvc_inference.py import torch from lib.infer_pack.models import SynthesizerTrnMs256NSFsid from assets.model import load_hubert, get_f0, get_content def load_rvc_model(model_path, device="cuda"): cpt = torch.load(model_path, map_location=device) net_g = SynthesizerTrnMs256NSFsid(**cpt["config"], is_half=False) net_g.load_state_dict(cpt["weight"]) net_g.eval().to(device) return net_g @app.route('/clone', methods=['POST']) def rvc_clone(): # 接收base64音频、目标文本、模型路径 data = request.json audio = base64_to_numpy(data['audio']) # 执行F0提取、内容编码、声码器合成（省略细节） # 关键：所有tensor操作指定device，避免CPU/GPU混用 f0 = get_f0(audio, device=device) content = get_content(audio, hubert_model, device=device) # 合成并返回base64音频 output = net_g.infer(content, f0, ...).cpu().numpy() return {"audio": numpy_to_base64(output)}

步骤3：配置Flowise工作流
在Flowise UI中创建三个节点：

Whisper Transcribe：HTTP节点，POST到http://localhost:8001/transcribe
RVC Clone：HTTP节点，POST到http://localhost:5000/clone
FFmpeg Postprocess：自定义节点，调用ffmpeg -i input.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 output.mp3

连线逻辑：Whisper输出 →RVC输入（文本字段）→RVC输出 →FFmpeg输入。每个节点配置超时（300秒）、重试次数（2次）、错误回调（发送Telegram通知）。

3.3 模型与数据管理——建立可追溯的语音资产库

模型版本控制
不把模型文件直接丢进Git（体积太大）。我们用git-lfs管理，并建立models/registry.json：

{ "rvc_chinese": { "version": "v2.3.1", "hash": "sha256:abc123...", "url": "https://huggingface.co/xxx/resolve/main/model.pth", "license": "CC-BY-NC-4.0" }, "so-vits-svc_japanese": { "version": "v4.1.2", "hash": "sha256:def456...", "url": "https://github.com/yyy/releases/download/v4.1.2/model.zip", "license": "MIT" } }

每次git pull后运行./sync_models.sh自动校验哈希并下载缺失模型。

数据标注规范
语音克隆效果高度依赖标注质量。我们强制执行三项标准：

时间戳精度：使用Audacity手动校准，误差≤±20ms（人耳可辨阈值）
文本清洗：删除口语填充词（“呃”、“啊”）、统一数字读法（“123”→“一百二十三”）
声学标签：为每段录音打标[breath]、[laugh]、[pause_long]等，供模型学习韵律

实测表明，符合此规范的5分钟录音，克隆成功率从63%提升至91%（以MOS评分≥3.8为基准）。

3.4 性能调优实战——让老旧硬件跑出专业级效果

显存优化三板斧

梯度检查点（Gradient Checkpointing）：在VITS训练脚本中启用，显存降低35%，训练速度慢12%

from torch.utils.checkpoint import checkpoint # 替换原forward中的encoder调用 x = checkpoint(self.encoder, x, use_reentrant=False)

混合精度训练（AMP）：torch.cuda.amp.autocast()包裹前向传播，配合GradScaler，显存省40%
模型分片（Model Parallelism）：将VITS的Encoder和Decoder部署在不同GPU（如有），用torch.distributed.rpc通信

CPU推理加速
Whisper的CPU推理瓶颈在Mel谱计算。我们用librosa替代torchaudio的STFT：

# torchaudio.stft耗时：12.4s/10s音频 # librosa.stft（预编译Cython）耗时：3.1s/10s音频 import librosa y, sr = librosa.load(audio_path, sr=16000) mel_spec = librosa.feature.melspectrogram(y=y, sr=sr, n_mels=80, hop_length=256)

磁盘IO优化
音频切片时避免频繁小文件读写：

# 错误：每切一片就保存一个WAV文件（1000片=1000次IO） for i, segment in enumerate(segments): sf.write(f"slice_{i}.wav", segment, 16000) # 正确：内存中批量处理，最后一次性写入NPZ压缩包 all_segments = np.stack(segments) np.savez_compressed("segments.npz", segments=all_segments, timestamps=timestamps)

4. 常见问题与排查技巧实录——那些文档里不会写的坑

4.1 音质问题排查速查表

现象	可能原因	排查命令	解决方案
输出语音有明显“金属感”	声码器采样率不匹配	`ffprobe -v quiet -show_entries stream=sample_rate output.wav`	确保声码器输出采样率=目标播放设备采样率（通常16kHz或44.1kHz）
克隆语音语速忽快忽慢	F0提取异常	`python -c "import numpy as np; print(np.std(np.load('f0.npy')))"`（正常值<15）	降低Whisper对齐精度（`--word_timestamps False`），改用Praat手动校准
音频开头有“咔哒”杂音	静音切除不干净	`sox input.wav -n stat 2>&1 \| grep 'RMS.*amplitude'`	在FFmpeg后处理中添加`-af apad=pad_dur=0.1`补零
某些音节发音含糊	训练数据音素覆盖不足	`espeak-ng -v zh -q "你好世界" --pho`（查看音素序列）	用MFA（Montreal Forced Aligner）重新对齐，补充缺失音素的录音样本

实操心得：遇到音质问题，永远先检查数据链路而非模型。我曾花两天调试RVC模型，最后发现是预处理脚本里librosa.resample的res_type='kaiser_fast'参数导致高频失真，换成res_type='polyphase'立刻解决。

4.2 工作流中断故障树分析

当Flowise显示“节点超时”时，按此顺序排查：

第一层：网络连通性

# 测试Whisper服务是否存活 curl -X POST http://localhost:8001/transcribe -F "file=@test.wav" -v # 若返回Connection refused → 检查uvicorn进程：ps aux \| grep uvicorn

第二层：服务健康度

# 查看RVC服务日志（关键看CUDA初始化） tail -f /var/log/rvc_service.log \| grep -E "(CUDA|error|OOM)" # 出现"out of memory" → 降低batch_size或启用ONNX量化

第三层：数据契约一致性
检查Flowise节点配置的JSON Schema是否匹配API实际返回：

// Flowise中配置的期望结构 { "type": "object", "properties": { "text": {"type": "string"}, "segments": { "type": "array", "items": { "type": "object", "properties": { "start": {"type": "number"}, "end": {"type": "number"} } } } } }

若API返回"start_time"而非"start"，工作流必然中断。此时需在FastAPI中添加兼容层：

@app.post("/transcribe") def transcribe(...): result = model.transcribe(...) # 兼容旧版Schema segments = [{"start": s["start"], "end": s["end"], "text": s["text"]} for s in result["segments"]] return {"text": result["text"], "segments": segments}

4.3 模型训练避坑指南

坑1：数据集太小导致过拟合

现象：训练loss快速下降但验证集MOS评分停滞
解决：强制启用--augment参数（添加白噪声、时间拉伸、音高偏移）
数据量底线：中文克隆至少需30分钟高质量录音（信噪比>25dB）

坑2：GPU显存溢出却报错模糊

现象：RuntimeError: CUDA out of memory但nvidia-smi显示显存仅用60%
根本原因：PyTorch缓存未释放（特别是多卡训练时）

解决：在训练脚本开头添加

import os os.environ['PYTORCH_CUDA_ALLOC_CONF'] = 'max_split_size_mb:128' torch.cuda.empty_cache()

坑3：克隆音色“不像”本人

关键误区：认为“录音越长越好”
真相：录音质量 > 时长。实测对比：
- 5分钟手机录音（环境嘈杂）→ MOS 2.1
- 2分钟专业麦克风录音（安静环境）→ MOS 3.9
必做动作：用Adobe Audition降噪后，用ffmpeg -i input.wav -af "highpass=f=100, lowpass=f=4000" output.wav滤除无效频段

4.4 本地化部署的终极验证清单

在交付客户前，必须完成以下10项验证（缺一不可）：

✅离线验证：拔掉网线，运行全流程，确认无外部API调用
✅显存验证：nvidia-smi监控全程，峰值≤GPU总显存×85%
✅时间验证：10分钟音频端到端耗时≤25分钟（含人工交互）
✅一致性验证：同一输入重复运行3次，输出音频MD5值完全相同
✅错误注入验证：故意传入损坏WAV文件，系统应返回清晰错误码而非崩溃
✅权限验证：以非root用户启动所有服务，确认无权限拒绝
✅温度验证：连续运行4小时，CPU温度≤85℃，风扇无异常啸叫
✅恢复验证：kill -9所有进程后，docker-compose up -d能自动重建服务
✅日志验证：所有服务日志包含ISO8601时间戳、服务名、操作ID
✅审计验证：git log --oneline -n 20显示最近20次commit均关联issue编号

这份清单不是形式主义。去年帮某政务热线做部署时，第7项“温度验证”发现散热硅脂老化，及时更换避免了夏季宕机事故——真正的“本地运行”，必须经得起物理世界的考验。

5. 语音工作室的延伸可能性——从工具到生态的进化路径

5.1 教育场景：方言保护的最小可行系统

我参与过浙南闽语（温州话）保护项目。当地老人平均年龄72岁，会说纯正方言者不足200人。传统方案是请专家逐字记录，但耗时耗力。我们用语音工作室快速构建了“方言活化系统”：

采集端：定制Android App（基于Oboe音频库），支持离线录音+自动增益控制，老人只需按红按钮说话
处理端：工作流自动执行：降噪 → 方言ASR（微调Whisper） → 音素对齐 → 声学建模
应用端：生成的方言语音库接入本地小学APP，学生点读课本生词即播放老人原声

关键创新在于模型热更新：当新采集到更高质量录音，只需在Flowise中替换RVC模型节点，整个系统无需重启。三个月内，团队用3台二手华为MatePad完成了12位老人的方言建档，成本仅为传统方案的1/7。

5.2 工业场景：设备语音提示的敏捷迭代

某国产数控机床厂商面临难题：不同型号机床需不同语音提示（“主轴启动”、“冷却液开启”），但外包TTS供应商每次修改需2周+5万元。我们部署的本地语音工作室实现了：

模板化提示生成：Excel表格定义提示语（含优先级、语速、音调），Python脚本自动生成工作流JSON
A/B测试机制：同一提示语生成3种音色版本，现场工人扫码投票，数据实时回传优化模型
OTA更新：新语音包打包为ZIP，通过企业微信下发，机床端用Python解压即生效

上线半年，提示语迭代周期从14天缩短至4小时，工人投诉率下降68%。这里“本地运行”的价值不是技术炫技，而是把语音从“IT部门的麻烦事”变成“产线工程师的日常工具”。

5.3 个人创作者：播客工作流的终极自动化

对我自己而言，这个工作室最大的收益是消灭重复劳动。一集30分钟播客的制作流程原本需：

12分钟：用Audacity剪掉口误、填充词
8分钟：用Descript修复语序
15分钟：用Adobe Audition降噪+均衡
5分钟：导出MP3+生成SRT字幕

现在，工作流自动完成：
原始录音 → Whisper转写 → 正则过滤“嗯/啊” → RVC克隆修正发音 → FFmpeg标准化响度 → Whisper二次转写生成SRT
全程耗时22分钟，且所有中间产物（原始稿、修正稿、字幕）自动存入SQLite，支持按关键词全文检索。

最后分享一个小技巧：在Flowise中创建“紧急修复”快捷入口。当客户临时要求“把第12分33秒的‘区块链’改成‘分布式账本’”，不用重跑全流程——直接调用rvc_inference.py的patch_segment函数，只重合成那一秒音频，再用FFmpeg精准拼接。实测修复耗时<90秒，这才是本地工作室的真正生产力。

这套系统没有终点。上周我刚把LoRA微调模块集成进工作流，让客户能用10分钟录音快速适配新音色；下个月计划接入本地知识库，让语音生成自动引用最新行业术语。它始终遵循一个原则：不追求“最先进”，只坚持“最可控”——因为真正的语音生产力，永远诞生于你指尖可触的确定性之中。