576 lines
20 KiB
Markdown
576 lines
20 KiB
Markdown
# Product Requirements Document: 语音共创模式增量方案
|
||
|
||
**Version**: 0.1
|
||
**Date**: 2026-04-19
|
||
**Author**: Codex (based on founder direction)
|
||
**Status**: Discovery Track / 不插队当前主开发线
|
||
|
||
---
|
||
|
||
## Executive Summary
|
||
|
||
DreamWeaver 当前已经具备“输入主题 -> 生成故事/绘本 -> 补全封面/语音 -> 保存回看”的稳定主链路，但它仍然更接近一个“单次提交、单次返回”的生成器。创始人提出的新方向，是把产品进一步升级为一个“孩子能直接用声音参与创作、并在讲述过程中纠正故事走向”的语音共创体验。
|
||
|
||
这个方向的价值不在于再加一个输入方式，而在于把 DreamWeaver 从“生成结果”推进到“陪伴式创作过程”。孩子不是先写清楚需求再等待结果，而是可以像和讲故事的人对话一样，说出自己想要的角色、情节和变化，系统实时或准实时地接住这些表达，再继续讲下去。
|
||
|
||
本增量 PRD 的目标不是立刻把语音共创插入当前主开发线，而是先把它定义为一条独立、可评估、可拆阶段落地的产品路线。当前主线仍应继续沿着统一生成工作流、跨环境观测、断点续跑与稳定性治理推进；语音共创作为下一波产品升级方向，先完成需求定义、架构判断和分阶段实施策略。
|
||
|
||
---
|
||
|
||
## Roadmap Position
|
||
|
||
### Decision
|
||
|
||
语音共创模式 **现在进入产品发现与方案设计阶段**，但 **不插队当前主开发线**。
|
||
|
||
### Why
|
||
|
||
- 当前主线已经明确：统一生成工作流、任务控制、Provider 运营分析、监控与恢复能力。
|
||
- 语音共创会引入新的交互模式、新的数据模型和新的低延迟系统要求，如果直接插入，会同时打断稳定性主线和架构收束节奏。
|
||
- 先写清楚增量 PRD，可以避免后续“想到什么做什么”，也能帮助后面的技术选型、原型验证和资源预估。
|
||
|
||
### Proposed Sequencing
|
||
|
||
1. 继续推进当前主线：跨环境 Provider 汇聚、监控告警、断点续跑与更细粒度任务控制。
|
||
2. 并行完成语音共创模式的交互原型、增量 PRD 和技术预研。
|
||
3. 等当前主线进入相对稳定阶段后，再按分阶段方案启动语音共创 MVP。
|
||
|
||
---
|
||
|
||
## Problem Statement
|
||
|
||
### Current Product State
|
||
|
||
DreamWeaver 当前的核心体验仍然是“家长或用户输入文本指令，系统一次性生成结果”。这条链路已经能稳定支持故事、绘本、封面和语音朗读，但它有三个天然限制：
|
||
|
||
1. **孩子参与感不够强**
|
||
当前孩子更多是内容接收者，而不是创作参与者。
|
||
|
||
2. **故事方向难以中途修正**
|
||
一旦提交生成请求，用户通常只能等待结果，然后再重来，而不是在讲述过程中自然修正。
|
||
|
||
3. **声音只承担播放，不承担创作交互**
|
||
现在的语音能力是 TTS 朗读，是结果层资产，不是输入层或互动层能力。
|
||
|
||
### User Problem
|
||
|
||
对于 3-8 岁孩子来说，“打字描述需求”不是自然交互方式。更符合他们习惯的体验是：
|
||
|
||
- 直接说“我想听一个关于恐龙和月亮的故事”
|
||
- 讲到一半再说“不要坏人了，我想让小兔子帮它”
|
||
- 如果系统理解错了，可以马上纠正，而不是整段作废
|
||
|
||
也就是说，孩子真正需要的不是一个更复杂的表单，而是一个 **能听、能接、能改、能继续讲** 的声音共创伙伴。
|
||
|
||
---
|
||
|
||
## Product Vision
|
||
|
||
DreamWeaver 的语音共创模式应当成为一种“孩子可以开口参与的故事编织方式”：
|
||
|
||
- 孩子用语音说出主题、角色或希望发生的事情
|
||
- 系统用温暖的语音回应，并逐步讲出故事
|
||
- 孩子在关键节点可以插话、纠正或改写走向
|
||
- 系统保留上下文，继续讲述，而不是从头全部重来
|
||
- 最终形成一个可以保存、回放、补全插图和沉淀到故事库的正式作品
|
||
|
||
这个模式本质上把 DreamWeaver 从“故事生成器”升级为“语音驱动的亲子共创体验”。
|
||
|
||
---
|
||
|
||
## User Personas
|
||
|
||
### Primary Persona: 孩子（3-8 岁）
|
||
|
||
- **Role**: 直接参与讲故事与改故事的人
|
||
- **Goals**:
|
||
- 用说话而不是打字表达想法
|
||
- 让故事里出现自己喜欢的角色、动物和发展
|
||
- 在听的过程中随时改变剧情
|
||
- **Pain Points**:
|
||
- 难以通过文字清楚描述想法
|
||
- 注意力持续时间短，不适合长时间等待
|
||
- 如果系统不理解，缺少自然纠正方式
|
||
|
||
### Secondary Persona: 家长 / 陪伴者
|
||
|
||
- **Role**: 陪伴孩子使用、保证内容安全和完成保存的人
|
||
- **Goals**:
|
||
- 让孩子更主动参与故事
|
||
- 获得安全、温和、可回放的亲子体验
|
||
- 能把共创结果沉淀为正式故事资产
|
||
- **Pain Points**:
|
||
- 担心纯开放对话失控或跑偏
|
||
- 担心延迟太高，孩子失去耐心
|
||
- 担心故事很有趣但无法保存和复用
|
||
|
||
### Tertiary Persona: 产品拥有者 / 系统维护者
|
||
|
||
- **Role**: 定义体验边界、控制成本与稳定性的人
|
||
- **Goals**:
|
||
- 在儿童安全前提下提供有趣的语音共创体验
|
||
- 控制实时语音链路成本和复杂度
|
||
- 让新模式尽量复用现有 generation workflow、memory、profile、universe 能力
|
||
- **Pain Points**:
|
||
- 语音链路天然更难做低延迟和可控性
|
||
- 需要同时解决识别、推理、朗读和状态同步
|
||
- 容易在“实时体验”与“工程稳定性”之间失衡
|
||
|
||
---
|
||
|
||
## Core User Journeys
|
||
|
||
### Journey 1: 孩子发起一个语音故事
|
||
|
||
1. 孩子进入“语音共创”模式
|
||
2. 点击说话或自动开始收音
|
||
3. 说出“我想听一个关于小猫去太空的故事”
|
||
4. 系统识别语音、理解意图，并用语音确认
|
||
5. 系统开始讲述第一段故事
|
||
|
||
### Journey 2: 孩子中途修正故事走向
|
||
|
||
1. 系统讲到一半
|
||
2. 孩子说“不要让它哭了，我想让它找到一个朋友”
|
||
3. 系统识别到这是“剧情修正”而不是新的故事请求
|
||
4. 系统更新当前故事状态
|
||
5. 后续讲述按照新方向继续
|
||
|
||
### Journey 3: 结束后保存为正式作品
|
||
|
||
1. 一轮共创完成后，系统给出标题、摘要和正式文本版本
|
||
2. 家长选择“保存到故事库”
|
||
3. 系统将共创结果写入现有 Story / Storybook 体系
|
||
4. 后续可以补封面、插图、语音缓存和成长记忆
|
||
|
||
---
|
||
|
||
## Product Principles
|
||
|
||
1. **Voice First，不是 Voice Only**
|
||
主要交互靠语音，但关键步骤仍要允许家长看到文本摘要、状态提示和保存入口。
|
||
|
||
2. **先做可控回合制，再追求完全实时**
|
||
第一阶段优先做低风险、可验证的回合式语音共创，而不是一开始就追求复杂的全双工实时对话。
|
||
|
||
3. **故事状态必须可追踪**
|
||
每一次“孩子说了什么、系统如何理解、故事如何被改写”都需要有清晰的会话状态，而不是只保留最终结果。
|
||
|
||
4. **儿童安全高于自由度**
|
||
产品目标是温暖陪伴，而不是无限开放对话。需要控制题材、安全边界和表达风格。
|
||
|
||
5. **尽量复用现有主干系统**
|
||
Profile、Universe、Memory、Generation Job、Story 持久化、TTS Provider 等能力优先复用，不另起一套孤立系统。
|
||
|
||
---
|
||
|
||
## Scope Definition
|
||
|
||
### In Scope for This PRD
|
||
|
||
- 定义语音共创模式的产品目标、交互边界和分阶段路线
|
||
- 定义与当前系统的关系和复用策略
|
||
- 定义关键功能需求、非功能需求、风险与架构方向
|
||
- 明确什么可以作为未来 MVP，什么应延后
|
||
|
||
### Out of Scope for Immediate Mainline
|
||
|
||
- 当前 Sprint 立刻开始实现实时语音共创
|
||
- 为所有页面全面重做 UI
|
||
- 一开始就支持多人同时共创
|
||
- 一开始就支持完全开放世界、无限长对话
|
||
- 一开始就做跨设备实时同步、家庭房间、复杂社交机制
|
||
|
||
---
|
||
|
||
## Functional Requirements
|
||
|
||
### FR-001: MUST - 用户可以通过语音发起故事共创会话
|
||
|
||
系统必须支持孩子使用语音表达故事主题、角色或目标，而不是只依赖文字输入。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 提供独立的“语音共创”入口
|
||
- 用户可以开始录音、结束录音，并获得识别结果反馈
|
||
- 系统能够把一次语音输入解析成结构化创作意图或剧情修正指令
|
||
- 当识别失败时，系统给出可理解的重试提示
|
||
|
||
### FR-002: MUST - 系统可以区分“新建故事”与“修正走向”
|
||
|
||
语音输入不能一律视为新的生成请求，系统必须识别当前输入是开启新故事、继续讲述还是修改走向。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 会话中至少支持三类意图：开始、继续、修正
|
||
- 修正输入不会默认清空整个已生成故事
|
||
- 系统会在内部保留当前故事状态与修正后的新状态
|
||
- 用户在听感上能感知“故事接住了刚刚的修改”
|
||
|
||
### FR-003: MUST - 系统可以用语音回应并继续讲述
|
||
|
||
语音共创模式下，系统不只返回文字，也必须以语音形式继续讲述故事。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 每轮系统响应可生成可播放语音
|
||
- 语音风格默认保持儿童友好、温和、清晰
|
||
- 当 TTS 失败时，系统至少保留文本响应，不让会话完全中断
|
||
- 语音播放与文本状态能在界面中同步显示
|
||
|
||
### FR-004: MUST - 共创过程可以保存为正式故事资产
|
||
|
||
语音共创不应只是一段即时对话，它必须能在某个节点沉淀为正式故事内容。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 会话结束后可生成正式标题、摘要和正文
|
||
- 用户可以选择保存为 Story，后续扩展为 Storybook
|
||
- 保存后的结果能够进入现有故事库
|
||
- 保存后的作品仍可复用现有封面、插图、TTS、Memory 和 Reading Event 流程
|
||
|
||
### FR-005: MUST - 系统必须记录语音会话状态
|
||
|
||
产品必须有独立于最终 Story 的语音会话状态模型，以支持恢复、调试和后续体验优化。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 每次语音共创会话拥有唯一 ID
|
||
- 至少记录：用户语音转写、系统文本响应、系统语音响应、会话阶段
|
||
- 会话中断后可以恢复最近上下文，而不是完全丢失
|
||
- 关键节点可映射到可观测事件，便于排障
|
||
|
||
### FR-006: SHOULD - 家长可以查看或确认关键改写
|
||
|
||
考虑儿童表达噪声和误识别，家长应在关键节点拥有轻量确认能力。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 至少提供一个可选的“本轮系统理解为”可视反馈
|
||
- 当系统置信度较低时，可提示家长确认或重说
|
||
- 家长可选择“保存当前版本”作为正式结果
|
||
|
||
### FR-007: SHOULD - 共创过程支持分段生成插图节点
|
||
|
||
系统应当为未来“边讲边出图”保留能力，但不要求首版立刻做到全量每回合同步出图。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 会话状态模型中为未来插图节点留出扩展点
|
||
- MVP 阶段至少支持结束后统一补图
|
||
- 后续版本可以基于关键段落触发插图生成
|
||
|
||
### FR-008: COULD - 支持故事分叉或“如果这样会怎样”的选择分支
|
||
|
||
共创模式后续可支持轻量分叉体验，但不作为首版必须项。
|
||
|
||
**Acceptance Criteria**
|
||
|
||
- 文档中明确分叉能力属于后续增强
|
||
- 当前状态模型设计不阻断未来扩展分支结构
|
||
|
||
---
|
||
|
||
## Non-Functional Requirements
|
||
|
||
### NFR-001: MUST - 首版交互应优先保证响应可接受
|
||
|
||
- 回合式语音识别结果返回目标：95 分位 <= 2.5 秒
|
||
- 系统语音开始播放目标：95 分位 <= 4 秒
|
||
- 若无法满足实时级别要求，允许先以“说一句、等一句”的回合式体验上线
|
||
|
||
### NFR-002: MUST - 儿童内容安全优先
|
||
|
||
- 系统需要有儿童场景安全提示词与内容过滤策略
|
||
- 对明显不适宜内容、暴力或成人化内容进行拦截或柔性改写
|
||
- 需要提供家长可理解的安全降级提示
|
||
|
||
### NFR-003: MUST - 成本必须可观测
|
||
|
||
- ASR、对话生成、TTS 调用应能够分能力记录
|
||
- 共创模式需要纳入现有 Provider analytics / cost 体系或其扩展版
|
||
- 必须能评估单次会话成本，而不是只有最终故事成本
|
||
|
||
### NFR-004: MUST - 会话必须可恢复
|
||
|
||
- 浏览器刷新、页面切换或短暂断线后，最近会话上下文不能完全丢失
|
||
- 至少支持恢复最近一轮会话状态和最后一次系统响应
|
||
|
||
### NFR-005: SHOULD - 架构保持可插拔
|
||
|
||
- ASR、对话模型、TTS 都应沿用 Provider/Capability 思路，而不是写死单一供应商
|
||
- 允许首版先只接一套最稳组合，但系统边界要为后续扩展留口
|
||
|
||
---
|
||
|
||
## Recommended Rollout Strategy
|
||
|
||
### Phase A: 回合式语音共创 MVP
|
||
|
||
**Goal**
|
||
验证“孩子用语音发起故事 + 中途修正剧情 + 保存正式故事”是否真的有产品价值。
|
||
|
||
**Characteristics**
|
||
|
||
- Push-to-talk 或显式录音按钮
|
||
- 一次说完一句，系统识别后再回应
|
||
- 先输出文本 + TTS，不做复杂打断
|
||
- 故事会话结束后保存为正式 Story
|
||
|
||
**Why This First**
|
||
|
||
- 技术风险最低
|
||
- 最容易复用当前 generation workflow
|
||
- 能最快验证孩子是否真的愿意参与“改故事”
|
||
|
||
### Phase B: 低延迟准实时共创
|
||
|
||
**Goal**
|
||
让对话更像自然讲故事，而不是轮流发消息。
|
||
|
||
**Characteristics**
|
||
|
||
- 引入流式 ASR
|
||
- 允许系统分段说、用户分段打断
|
||
- 引入更细粒度的会话状态和中间故事状态
|
||
|
||
### Phase C: 实时沉浸式语音陪伴
|
||
|
||
**Goal**
|
||
把 DreamWeaver 升级为更连续的声音陪伴系统。
|
||
|
||
**Characteristics**
|
||
|
||
- 更自然的 barge-in
|
||
- 多轮上下文记忆更稳定
|
||
- 关键段落插图联动
|
||
- 更丰富的角色语气、音色和故事节奏控制
|
||
|
||
---
|
||
|
||
## Architecture Direction
|
||
|
||
### Recommended Architecture
|
||
|
||
首版推荐采用 **“语音会话层 + 现有生成主干复用”** 的增量架构，而不是重写整套系统。
|
||
|
||
#### 1. 新增 Voice Session 层
|
||
|
||
新增独立的语音会话概念，用于管理：
|
||
|
||
- 当前会话 ID
|
||
- 当前轮次 turn
|
||
- 每轮用户语音转写
|
||
- 每轮系统文本回应
|
||
- 每轮系统语音回应
|
||
- 当前故事状态摘要
|
||
- 当前修正意图
|
||
|
||
建议未来新增的数据对象包括：
|
||
|
||
- `voice_sessions`
|
||
- `voice_turns`
|
||
- `voice_story_snapshots` 或等价状态字段
|
||
|
||
#### 2. 复用现有主干能力
|
||
|
||
以下能力应优先复用：
|
||
|
||
- `profiles` / `universes`
|
||
- memory context 构建
|
||
- 统一 generation workflow
|
||
- Story / Storybook 持久化
|
||
- TTS Provider Router
|
||
- generation job / generation event 可观测机制
|
||
|
||
#### 3. 新增 ASR / Dialogue Orchestrator 能力
|
||
|
||
当前系统已有 `text` / `image` / `tts` / `storybook` capability，但 **没有输入侧语音识别能力**。未来至少需要新增：
|
||
|
||
- `asr` 或 `speech_input` capability
|
||
- 会话级 story planner / dialogue orchestrator
|
||
|
||
这里的核心不是单纯“把语音转文字”，而是让系统理解：
|
||
|
||
- 这是新故事还是修正
|
||
- 修正的是角色、风格还是情节
|
||
- 该在当前故事哪一层生效
|
||
|
||
#### 4. 首版通信建议
|
||
|
||
首版不要一开始就强依赖 WebRTC 或复杂全双工实时架构，建议先使用：
|
||
|
||
- 前端录音上传
|
||
- 后端异步识别与生成
|
||
- 前端轮询或 SSE 获取本轮结果
|
||
|
||
等 MVP 价值被验证后，再考虑：
|
||
|
||
- WebSocket
|
||
- Realtime API
|
||
- WebRTC
|
||
|
||
---
|
||
|
||
## Model Capability Guidance
|
||
|
||
本 PRD 不锁死具体供应商，但建议能力分层如下：
|
||
|
||
| Capability | Role | 首版建议 |
|
||
| --- | --- | --- |
|
||
| `speech_input` | 语音转写 | 选择低延迟、儿童普通话识别稳定的 ASR 方案 |
|
||
| `dialogue_orchestrator` | 判断用户意图、维护故事状态、决定下一段叙事 | 选择低延迟、指令遵循稳定的对话模型 |
|
||
| `story_generation` | 生成正式叙事段落与收束文本 | 优先复用现有稳定文本模型 |
|
||
| `tts` | 讲述输出 | 优先复用当前已接通的 TTS Provider 体系 |
|
||
|
||
### Practical Recommendation
|
||
|
||
- **首版优先稳定组合，不追求最先进组合**
|
||
- **优先验证体验价值，再做多 Provider 优化**
|
||
- **如果需要低延迟实时感，可在第二阶段单独引入 realtime 类模型**
|
||
|
||
---
|
||
|
||
## Key Gaps vs Current Architecture
|
||
|
||
当前架构 **可以支撑语音共创方向**，但还不能直接无痛实现，主要差距有：
|
||
|
||
1. **没有语音输入能力层**
|
||
现在只有 TTS，没有 ASR / STT。
|
||
|
||
2. **没有会话态故事模型**
|
||
现在更像“提交任务 -> 等结果”，缺少持续共创 session。
|
||
|
||
3. **没有剧情修正语义**
|
||
当前重试和取消针对 job，不针对“故事中途被改写”。
|
||
|
||
4. **没有低延迟链路设计**
|
||
当前 worker 化设计适合生成任务，不适合直接承载高频实时会话。
|
||
|
||
5. **没有儿童语音场景安全机制**
|
||
需要额外的识别置信度、内容边界和家长确认机制。
|
||
|
||
---
|
||
|
||
## Risks and Blockers
|
||
|
||
### Risk 1: 延迟过高，孩子失去耐心
|
||
|
||
如果每次说完都等待太久，产品体验会从“共创”退化成“多轮卡顿提交”。
|
||
|
||
**Mitigation**
|
||
|
||
- MVP 先做短回合
|
||
- 优先压低首响应延迟
|
||
- 必要时让系统先做简短确认，再继续讲长段内容
|
||
|
||
### Risk 2: 语音识别错误导致故事跑偏
|
||
|
||
儿童语音、环境噪音和吐字不清会显著增加误识别。
|
||
|
||
**Mitigation**
|
||
|
||
- 低置信度时进行轻量确认
|
||
- UI 中显示“系统理解为”
|
||
- 允许家长快速纠正
|
||
|
||
### Risk 3: 开放对话导致内容不可控
|
||
|
||
孩子的表达可能跳跃，系统也可能走向不适合儿童的内容。
|
||
|
||
**Mitigation**
|
||
|
||
- 强化儿童安全 prompt
|
||
- 限定世界观和风格边界
|
||
- 对危险输入进行柔性改写或拒绝
|
||
|
||
### Risk 4: 实时架构过早引入，打乱当前主线
|
||
|
||
如果还没验证价值就上 WebRTC / 全双工，会显著增加工程复杂度。
|
||
|
||
**Mitigation**
|
||
|
||
- 先做回合式 MVP
|
||
- 先验证留存和参与感
|
||
- 价值成立后再升级实时架构
|
||
|
||
---
|
||
|
||
## MoSCoW Prioritization
|
||
|
||
### Must Have
|
||
|
||
- 语音发起故事
|
||
- 语音修正剧情走向
|
||
- 系统语音回应
|
||
- 会话状态落库或可恢复
|
||
- 保存为正式故事
|
||
- 儿童安全边界
|
||
|
||
### Should Have
|
||
|
||
- 家长低置信度确认
|
||
- 分阶段插图补全
|
||
- 会话成本统计
|
||
- 与现有 analytics 打通
|
||
|
||
### Could Have
|
||
|
||
- 分支剧情
|
||
- 角色多音色切换
|
||
- 更自然的打断式实时对话
|
||
|
||
### Won't Have in MVP
|
||
|
||
- 多人实时共创
|
||
- 完整开放世界长时对话
|
||
- 复杂社交分享房间
|
||
- 首版就做跨端同步协作
|
||
|
||
---
|
||
|
||
## Success Metrics
|
||
|
||
### Product Metrics
|
||
|
||
- 语音共创发起成功率 >= 90%
|
||
- 首轮系统语音响应开始时间中位数 <= 3 秒
|
||
- 至少一次剧情修正被成功接住的会话占比 >= 60%
|
||
- 会话后保存为正式故事的比例 >= 40%
|
||
|
||
### Experience Metrics
|
||
|
||
- 内部评审中，80% 以上样本能明显感受到“孩子参与改变了故事”
|
||
- 家长主观反馈中，“比纯文字生成更适合孩子参与”的比例 >= 70%
|
||
|
||
### Technical Metrics
|
||
|
||
- 单会话成本可拆解到 ASR / 对话 / TTS
|
||
- 最近会话恢复成功率 >= 95%
|
||
- 关键失败都能映射到可观测事件
|
||
|
||
---
|
||
|
||
## Open Questions
|
||
|
||
1. 首版是否只支持普通故事，不支持绘本共创？
|
||
2. 首版是否允许孩子自由说，还是需要半结构化引导句式？
|
||
3. 家长确认机制默认开启还是仅在低置信度时触发？
|
||
4. 正式保存时，是只保存最终版本，还是同时保留关键修正轨迹？
|
||
5. 是否需要单独的“语音共创故事”内容类型，还是复用现有 Story 即可？
|
||
|
||
---
|
||
|
||
## Final Recommendation
|
||
|
||
语音共创模式是一个值得做、也确实能把 DreamWeaver 从“工作流完整”再往上推一层的方向，但它不应该现在就直接插队主开发线。
|
||
|
||
最合理的做法是：
|
||
|
||
1. 把它作为独立增量 PRD 固化下来
|
||
2. 将其定位为下一波产品升级方向，而不是当前 Sprint 任务
|
||
3. 未来先从“回合式语音共创 MVP”开始
|
||
4. 复用现有生成主干，新增 voice session 层，而不是另起一套平行系统
|
||
|
||
这样既能保持当前 PRD 主线不被打断，也能确保后续做语音共创时，我们是在按计划推进，而不是临时起意。
|