prd.md 47 KB


stepsCompleted: ['step-01-init', 'step-02-discovery', 'step-02b-vision', 'step-02c-executive-summary', 'step-03-success', 'step-04-journeys', 'step-05-domain', 'step-06-innovation', 'step-07-project-type', 'step-08-scoping', 'step-09-functional', 'step-10-nonfunctional', 'step-11-polish'] inputDocuments: [] workflowType: 'prd' classification: projectType: Desktop App domain: Content/Publishing complexity: Medium

projectContext: Greenfield

Product Requirements Document - 223-236-template-6

Author: User Date: 2026-03-13

Executive Summary

产品愿景

序灵 Matrix 助手是面向中文网络小说作者的本地化 AI 翻译流水线,解决百万字级长篇网文出海的核心基础设施问题。产品将复杂的翻译流程(分段、术语处理、批量翻译、格式化)简化为一键操作,使 200-500 万字网文的海外发布从"数周手动工作"变为"一夜自动完成"。

核心问题: 现有翻译方案无法满足网文出海场景 — 在线翻译服务数据安全风险高、批量处理效率低、术语无法统一;专业人工翻译成本高昂且周期过长。作者需要的是批量、高质量、安全、成本可控的端到端解决方案。

目标用户:

  • 主要:想要将自有网文作品推向海外市场的个人作者
  • 次要:小型翻译工作室

What Makes This Special

  1. 本地化安全:全流程在本地桌面运行,作品未发布前零外泄风险

  2. 网文专门化

    • 术语锁定:Top200 人名/地名/门派名全书统一翻译
    • 智能章节识别:正确识别"第123章"并在章节边界分段
    • 定长分段:900 字符分段适配 GPU 批处理
  3. GPU 极速:基于 CTranslate2 + m2m100_418M + 本地 CUDA 加速,比在线翻译服务快 5-10 倍

  4. 一键全流程:拖入 TXT 文件 → 自动完成指纹查重/清洗/术语提取/翻译/上传 → 输出结构化英文版,无需任何手动分段、上传、下载操作

核心洞察: 这个产品解决的不是"翻译"问题本身,而是"网文出海的基础设施"问题 — 批量处理能力、质量可控、数据安全、成本可控四个维度的综合需求。

商业模式: 一次性软件买断 + 按量计费混合模式(按 CU = 章节字数÷100 计费,预充值扣费)

Project Classification

维度 分类
项目类型 Desktop App (桌面应用)
领域 Content/Publishing (内容出版)
复杂度 Medium (中等 - CUDA加速、大规模文本处理、任务调度)
项目上下文 Greenfield (绿地项目 - 全新产品)

Success Criteria

User Success

任务完成标志:

  • 用户界面显示绿色勾号 + 状态消息:"翻译完成,共 XXX 章,XX 万字"
  • 输出文件:英文版 TXT 文件生成成功 + 目标平台上传确认
  • 用户感知:一觉醒来,500 万字小说已自动翻译完成

质量标准:

  • 术语准确率:≥ 95%(核心人名/地名全书一致)
  • 翻译流畅度:达到可出版水平(编辑仅需润色,无需重译)
  • 章节完整性:0 断章、0 漏章

效率提升:

  • 对比基准:手动方案 2-3 周处理周期
  • 自动方案:1 晚完成 500 万字
  • 量化收益:节省 95% 处理时间

Business Success

3 个月指标:

  • 软件购买用户:≥ 100 人
  • 平均 CU 消耗:5000-50000 CU/用户(对应 50-500 万字)

12 个月指标:

  • 用户留存率:≥ 60%(续用或充值)
  • 净推荐值 (NPS):≥ 40

成功标志:

  • 用户自发传播:"这个工具救了我"
  • 海外平台出现明确标注:"使用 Matrix 助手翻译"

Technical Success

关键性能指标:

  • 翻译速度:≥ 5000 字符/分钟(基于 RTX 3060)
  • GPU 利用率:≥ 80%(非空闲处理状态)
  • 崩溃恢复率:99.9%(Crash-Safe 机制可靠性)

Measurable Outcomes

指标类别 具体指标 目标值
用户时间 500 万字处理时间 8-12 小时
术语质量 核心术语准确率 ≥ 95%
章节完整性 断章/漏章率 0%
业务增长 首季购买用户 ≥ 100
用户留存 12 个月留存率 ≥ 60%
技术性能 翻译速度 ≥ 5000 字符/分钟

Product Scope

MVP - Minimum Viable Product

六大核心模块(必需功能):

  • 指纹查重模块:MD5 唯一 work_id 生成,防重复处理
  • 清洗分章模块:章节识别、正文清洗、900 字符定长分段
  • 术语提取模块:Top200 人名/地名/门派名自动提取
  • 翻译模块:m2m100 中译英,CUDA 加速
  • 上传模块:逐章上传,按章节字数扣费
  • 任务调度模块:Pause/Resume/Crash-Safe/失败重试

技术基础:

  • Python 3.11
  • CTranslate2 + facebook/m2m100_418M
  • CUDA 支持(RTX 3050/3060)
  • 零授权费依赖(requests MIT)

Growth Features (Post-MVP)

版本 2 增长功能:

  • 多语言支持:中→日/韩/西语扩展
  • 批量多文件处理:同时处理多部小说
  • 翻译记忆库:用户自定义术语表导入/导出

Vision (Future)

版本 3+ 愿景功能:

  • AI 辅助润色:基于用户反馈自动优化翻译质量
  • 平台 API 直接对接:Webnovel/Wattpad/Royal Road 直接发布
  • 协作功能:多译者协作、审阅流程

User Journeys

Journey 1: 首次使用 - 李明的出海之旅

角色: 李明,35 岁网络小说作者,已完成 300 万字仙侠小说《九天剑主》

场景设定: 李明在作者群看到有人推荐"序灵 Matrix 助手",说"一晚上把 500 万字翻完了"。他的小说在国内已经完结,一直想推向海外市场,但咨询了翻译机构 — 50 万美元,3 个月交稿。这对个人作者来说完全不可接受。

上升动作: 李明下载了 Matrix 助手安装包,安装过程中软件检测到他的 RTX 3060 显卡,显示绿色勾号:"GPU 已就绪,预计翻译速度 5200 字符/分钟"。他心跳加速,这可能真的有用。

他拖入《九天剑主》的 TXT 文件(1500 章,约 300 万字)。软件自动扫描:

  • "检测到 1500 章"
  • "提取到 238 个术语"(人名、门派、功法名)
  • "预计处理时间:9.5 小时"

李明点击"开始翻译"按钮,看到一个圆圈开始旋转,显示进度条和预计完成时间。他去睡了一觉。

高潮时刻: 第二天早上,李明醒来看到桌面通知:

✅ 翻译完成!
《九天剑主》- 1500 章,312 万字
术语准确率:96.7%
已生成英文版 TXT

他颤抖着手打开英文版,搜索主角名字"叶凡" — 从第 1 章到第 1500 章,全部是 "Ye Fan",从未变成 "Leaf Emperor" 或 "Ye Van"。章节标题 "Chapter 1234" 规规整整,没有断在句子中间。

结局: 李明将英文版上传到海外网文平台。两周后,他的小说获得了首批英文读者评论:"This cultivation novel is amazing! Can't wait for more chapters."

李明在作者群发了条消息:"Matrix 助手救了我。我的小说现在有英文版了。"

此旅程揭示需求:

  • GPU 检测和可用性提示
  • 导入前预览(章节数、术语数、预计时间)
  • 进度显示和预计完成时间
  • 完成通知(桌面通知)
  • 术语验证功能
  • 英文版生成和下载

Journey 2: 续更翻译 - 张华的连载更新

角色: 张华,29 岁,连载作者,每天更新 2 章

场景设定: 张华的《星河霸主》已经翻译到第 800 章(英文版),每天晚上他会更新 2 章中文。之前他需要手动提取新章节、上传到翻译服务、等待、下载、合并到英文版 — 每天 1 小时。

上升动作: 张华启动 Matrix 助手,软件自动识别:

检测到已知作品:《星河霸主》
work_id: 7f8e9d2a... (MD5)
已翻译:800 章
新章节:801-802 (2 章)

他直接拖入包含新章节的 TXT 文件,点击"继续翻译"。软件自动复用之前的术语库(已经锁定的 156 个术语),只翻译新增内容。

20 分钟后,桌面通知:"2 章翻译完成"。张华将新章节追加到英文版 TXT,一键上传到平台。

高潮时刻: 张华看了一眼时间 — 从导入到上传完成,总共 25 分钟。之前需要 1 小时,现在节省了 58% 的时间。他可以多写 1000 字了。

结局: 张华继续连载,每天晚上重复这个流程。他的英文读者和中文读者几乎同步追更,收入增加了 40%。

此旅程揭示需求:

  • 续更自动识别(基于 work_id)
  • 术语库复用
  • 增量翻译(只处理新章节)
  • 追加到现有英文版
  • 快速流程优化

Journey 3: 崩溃恢复 - 王芳的意外断电

角色: 王芳,32 岁,翻译工作室负责人,处理 500 万字作品

场景设定: 王芳正在用 Matrix 助手翻译客户的 500 万字小说。翻译到 60% 时,突然停电了。她惊慌失措 — 之前用其他工具,断电意味着一切从头开始。

上升动作: 王芳重启电脑,忐忑不安地打开 Matrix 助手。

软件启动界面显示:

⚠️ 检测到未完成任务
《长夜将明》- 已完成 60%
上次中断:意外断电
是否恢复? [恢复] [放弃]

她点击"恢复"。软件显示:

✅ 任务已恢复
已翻译:300 万字 / 500 万字 (60%)
剩余:200 万字
预计剩余时间:6.4 小时
跳过已完成章节...

高潮时刻: 王芳松了一口气 — Crash-Safe 机制救了她。软件从第 3001 章继续翻译,没有重复处理已完成的内容,也没有遗漏任何章节。

结局: 6.5 小时后,500 万字全部翻译完成。王芳的客户收到英文版,非常满意。王芳在工作室的 SOP 中更新了:"强制使用 Matrix 助手,唯一支持断点续传的工具。"

此旅程揭示需求:

  • Crash-Safe 机制(状态持久化)
  • 崩溃检测和恢复提示
  • 断点续传(跳过已完成)
  • 进度可见性
  • 任务状态管理

Journey 4: 术语校准 - 陈刚的专有名词

角色: 陈刚,40 岁,资深玄幻作者,作品包含大量自创术语

场景设定: 陈刚的《虚空战纪》有大量自创术语:"虚元力"、"九转虚空决"、"虚空殿"等。他担心 AI 翻译会把这些术语翻得五花八门。

上升动作: 陈刚导入 TXT 文件后,软件显示"术语提取完成"按钮。他点击后看到一个术语列表:

原文 自动翻译 频次
叶辰 Ye Chen 2341 次
虚元力 Void Origin Power 1876 次
九转虚空决 Nine Revolution Void Art 543 次
虚空殿 Void Temple 421 次

陈刚发现"虚元力"应该翻译成 "Void Origin Force" 而不是 "Void Origin Power"。他直接在表格中修改,点击"保存并锁定"。

高潮时刻: 翻译完成后,陈刚搜索"虚元力" — 全书 1876 处,全部是 "Void Origin Force",无一例外。

结局: 陈刚将自己常用的术语表导出保存。下次翻译新作品时,他直接导入这个术语表,确保系列作品术语一致。

此旅程揭示需求:

  • 术语提取和预览
  • 手动编辑术语翻译
  • 术语锁定机制
  • 术语表导入/导出
  • 术语验证功能

Journey 5: 失败处理 - 赵敏的网络异常

角色: 赵敏,27 岁,兼职作者,网络不稳定

场景设定: 赵敏在翻译过程中上传模块遇到了网络异常 — 连接超时。她不知道哪些章节上传成功了,哪些失败了。

上升动作: 翻译完成后,Matrix 助手显示:

⚠️ 部分章节上传失败
成功:1245 章
失败:3 章(章节 892, 893, 895)
是否重试? [重试] [跳过]

赵敏点击"重试"。软件自动重新上传失败的 3 章,这次成功了。

结局: 赵敏在历史记录中看到这次任务的完整日志,包括失败和重试记录。她感到安心 — 即使网络不稳定,也不会丢章节。

此旅程揭示需求:

  • 上传失败检测
  • 失败章节列表
  • 批量重试功能
  • 任务历史记录
  • 详细日志

Journey Requirements Summary

基于以上用户旅程,序灵 Matrix 助手需要以下核心能力:

功能领域 需求来源 优先级
GPU 检测和配置 Journey 1 P0
导入前预览(章节/术语/时间) Journey 1 P0
进度显示和预计完成时间 Journey 1 P0
完成通知(桌面通知) Journey 1 P0
Crash-Safe 机制 Journey 3 P0
断点续传 Journey 3 P0
术语提取和预览 Journey 1, 4 P0
术语手动编辑 Journey 4 P0
术语锁定机制 Journey 1, 4 P0
续更自动识别 Journey 2 P1
术语库复用 Journey 2 P1
术语表导入/导出 Journey 4 P1
上传失败检测 Journey 5 P1
批量重试 Journey 5 P1
任务历史记录 Journey 5 P2
详细日志 Journey 5 P2

Domain-Specific Requirements

Compliance & Regulatory

版权与知识产权:

  • 用户必须拥有源内容的翻译权和发布权
  • 软件需明确声明:不处理盗版内容,用户承担版权责任
  • 生成内容添加翻译标识:"Translated by 序灵 Matrix 助手"

内容合规:

  • 过滤敏感内容(可选功能,适配平台规则)
  • 保留原作版权声明和作者信息
  • 翻译内容不得用于训练第三方 AI 模型(本地处理保障)

Technical Constraints

翻译质量标准:

  • 术语一致性:≥ 95% 核心术语全书统一
  • 章节完整性:0 断章、0 漏章
  • 可读性:达到"可直接发布"水平(仅需润色,无需重译)

性能要求:

  • 翻译速度:≥ 5000 字符/分钟(RTX 3060 基准)
  • GPU 利用率:≥ 80%(高效资源使用)
  • 批处理能力:支持 500 万字单文件处理

数据安全:

  • 全流程本地处理,零数据外泄
  • work_id MD5 仅用于指纹查重,不上传内容
  • 用户术语表本地存储,不上云

Integration Requirements

平台对接(MVP 后):

  • 目标平台:Webnovel、Wattpad、Royal Road、起点国际
  • 上传格式:章节化 TXT/EPUB
  • API 集成:Vision 阶段功能

术语管理:

  • 用户自定义术语表导入/导出(JSON/CSV)
  • 术语表复用于续更和系列作品
  • 术语锁定机制保证全书一致

Risk Mitigations

翻译质量风险: | 风险 | 缓解措施 | |------|----------| | 术语翻译不一致 | Top200 术语锁定 + 占位符替换机制 | | 断章影响阅读 | 900 字符分段 + 章节边界识别 | | GPU 翻译失败 | 三级降级:批量→单条→失败清单 | | 网络上传失败 | 失败检测 + 自动重试 + 手动重试 |

数据完整性风险: | 风险 | 缓解措施 | |------|----------| | 断电/崩溃丢失进度 | Crash-Safe:原子写 progress.json | | 重复处理浪费 CU | MD5 指纹查重 + work_id 去重 | | 分段数据损坏 | .tmp 原子写 + fsync + rename | | 章节遗漏 | 分段元数据校验 + 缺失检测 |

用户体验风险: | 风险 | 缓解措施 | |------|----------| | 首次配置困难 | GPU 自动检测 + 一键向导 | | 进度不可见 | 实时进度条 + 预计完成时间 | | 术语不可控 | 术语预览 + 手动编辑界面 | | 暂停无响应 | Pause 立即中断 + Resume 断点续传 |

六大核心模块领域规格

1. 指纹机制

输入: TXT 文件第一章正文

处理流程:

去空行 → 去标点 → MD5 计算 → API 调用

API 规格:

POST /api/fingerprint/check
Request: { "fingerprint": "md5hash", "chapter_1": "content" }
Response: { "work_id": "uuid", "exists": false }

异常处理:

  • 每 2 秒重试,最多 3 次
  • 失败后记录日志,不阻塞后续流程
  • 此阶段不可 Pause(原子操作)

2. 清洗模块

章节识别:

  • 正则匹配:第\s*[一二三四五六七八九十百千0-9]+\s*章
  • 兼容格式:"第123章"、"第一千二百三十四章"、"Chapter 123"

正文清洗:

  • 合并连续空行为单换行
  • 统一缩进为 2 空格
  • 压缩多余空格

定长分段:

  • 基准:900 字符
  • 软上限:950 字符(避免句子中间断开)
  • 硬上限:1200 字符(强制断点)

输出格式:

{
  "chapters": [
    {
      "chapter_id": 1,
      "title": "第123章 少年觉醒",
      "parts": [
        { "part_index": 0, "content": "..." },
        { "part_index": 1, "content": "..." }
      ]
    }
  ]
}

Crash-Safe:

  • 原子写:novel_cleaned.json.tmp
  • fsync() 强制刷盘
  • rename() 原子替换

3. 术语提取

候选抽取规则:

  • 中文:[\u4e00-\u9fff]{2,6}(2-6 字连续中文)
  • 英文/拼音:[A-Z][A-Za-z0-9\-]{1,20}(大写开头)
  • 排除:常见停用词(的、了、是、在等)

统计算法:

Counter(terms)  # 全文频次
cross_chapter_count  # 跨章出现次数

筛选条件:

  • count >= 2(至少出现 2 次)
  • chapters >= 2(至少在 2 章出现)
  • 取 Top200,按频次降序

回退机制:

  • 可选 jieba 分词补充(未匹配到足够术语时)

输出格式:

{
  "terms": [
    { "source": "叶凡", "count": 2341, "chapters": 1500 },
    { "source": "逍遥派", "count": 1876, "chapters": 1342 }
  ]
}

4. 翻译模块

模型配置:

  • 模型:facebook/m2m100_418M
  • 推理引擎:CTRanslate2
  • 设备:CUDA(RTX 3050/3060)

推理参数:

{
  "beam_size": 1,  # 贪心解码,速度优先
  "int8_float16": true,  # 混合精度
  "batch_size": 8  # 动态调整 4-12
}

术语锁定流程:

原文 → 占位符替换(§Ti§) → 翻译 → 术语还原 → 输出

失败降级策略:

  1. GPU 批量翻译(正常)
  2. GPU 单条翻译(批量失败)
  3. 记录失败清单(单条失败)

Pause/Resume:

  • 章节级中断点
  • Pause:立即停止当前批次
  • Resume:从中断章节开头重跑

5. 上传模块

上传策略: 逐章上传(固定策略)

扣费逻辑:

CU = 章节字数 ÷ 100(向上取整)
上传前触发扣费 API
余额不足时跳过并记录

失败重试:

  • 自动重试 1 次
  • 仍失败 → 记录到 upload_failed.jsonl
  • 提供批量重试界面

分段合并:

  • 同章分段 → 合并为整章
  • 缺失分段 → 标记 incomplete: true

6. 任务调度

状态机:

pending → running → (success | failed | paused)
         ↓
      crashed → resume → running

Pause/Resume:

  • Pause:状态设为 paused,保存当前章节
  • Resume:从保存章节开头重跑(保证数据完整)

Crash-Safe:

  • progress.json 原子写
  • 记录:当前章节、分段索引、翻译状态
  • 启动时检测未完成任务

失败清单:

  • 格式:JSONL(每行一个失败项)
  • 写盘时机:每 10 个失败项或章节切换时
  • 边界保护:即使崩溃也保存已记录失败

Innovation & Novel Patterns

Detected Innovation Areas

1. 技术创新:本地 GPU 翻译流水线

创新描述: 将消费级 GPU (RTX 3050/3060) 用于大规模文本翻译,实现比在线翻译服务快 5-10 倍的处理速度。

新颖性:

  • 现有方案:在线翻译服务(Google/DeepL)受限于网络延迟和 API 配额
  • Matrix 方案:本地 CTranslate2 + CUDA,完全受控的吞吐量
  • 突破点:在消费级硬件上实现企业级翻译吞吐

技术组合:

  • CTranslate2 推理引擎(优化 Transformer 模型)
  • m2m100_418M 多语言模型
  • 混合精度推理(int8_float16)
  • 动态批量大小调整(4-12)

2. 流程创新:术语锁定占位符机制

创新描述: 使用占位符替换机制(§Ti§)确保全书术语 100% 统一翻译。

新颖性:

  • 现有方案:后处理正则替换(容易遗漏)或逐句人工校对
  • Matrix 方案:预替换占位符 → 翻译 → 原位还原
  • 突破点:从根本上解决术语不一致问题

实现原理:

原文: "叶凡加入了逍遥派"
↓ 占位符替换
"§T1§ 加入了 §T2§"
↓ AI 翻译
"§T1§ joined §T2§"
↓ 术语还原
"Ye Fan joined Xiaoyao Sect"

3. 流程创新:Crash-Safe 原子写设计

创新描述: 使用 .tmp + fsync() + rename() 原子写模式,确保断电/崩溃不丢失进度。

新颖性:

  • 现有方案:定期保存(崩溃时可能损坏)或无保护(崩溃需重跑)
  • Matrix 方案:数据库级别的 ACID 保证应用于桌面应用
  • 突破点:长时间任务(8-12 小时)的崩溃安全性

技术细节:

# 原子写模式
write("progress.json.tmp", data)
fsync(fd)  # 强制刷盘
rename("progress.json.tmp", "progress.json")  # 原子替换

4. 产品创新:网文专门化流水线

创新描述: 针对网文特点(章节结构、术语密集、超长篇幅)优化的端到端翻译方案。

新颖性:

  • 通用翻译工具:按段落/句子分割,破坏章节结构
  • Matrix 方案:章节识别 → 900 字符分段 → 术语锁定
  • 突破点:首次将网文翻译作为专门领域

专门化特性:

  • 智能章节识别(兼容"第123章"/"第一千二百三十四章")
  • 定长分段适配 GPU 批处理(900 字符基准)
  • Top200 术语自动提取(人名/地名/门派名)

5. 商业模式创新:混合计费

创新描述: 软件一次性买断 + 翻译按量计费 (CU) 的混合模式。

新颖性:

  • 纯订阅:用户持续付费压力
  • 纯买断:厂商缺乏持续收入
  • Matrix 方案:降低使用门槛 + 持续收入激励

6. 用户体验创新:续更自动识别

创新描述: 基于 work_id 自动识别已翻译作品,仅处理新增章节。

新颖性:

  • 现有方案:手动管理版本、手动提取新章节
  • Matrix 方案:MD5 指纹自动匹配、增量翻译
  • 突破点:连载作者的日更无缝衔接

Market Context & Competitive Landscape

竞品分析:

竞品类型 代表产品 局限性 Matrix 差异化
在线翻译 Google/DeepL 数据外泄、批量限制、术语不一致 本地安全、批量处理、术语锁定
CAT 工具 Trados/MemoQ 面向专业译员、需要人工翻译 全自动 AI、面向作者
网文平台 Webnovel 平台垄断、分成比例低 独立发布、作者控制
翻译公司 人工服务 成本高($50万/500万字)、周期长 成本低、速度快

市场空白:

  • 无专门针对网文的翻译工具:现有工具都是通用设计
  • 无本地化批量翻译方案:都是云服务,存在数据安全风险
  • 无术语锁定机制:AI 翻译术语一致性是行业痛点

Validation Approach

技术验证:

  • ✅ m2m100 模型已在中文-英文翻译上验证有效
  • ✅ CTranslate2 + CUDA 性能在 NVIDIA 官方文档验证
  • ⚠️ 术语锁定占位符机制需要原型测试

市场验证:

  • 用户访谈:10 位网文作者试用原型
  • A/B 测试:术语锁定 vs 无锁定的翻译质量
  • 性能基准:与 Google Translate 的速度对比

风险假设: | 假设 | 验证方法 | 成功标准 | |------|----------|----------| | GPU 翻译质量可接受 | 100 章盲测 | ≥ 85% 用户认为"可直接发布" | | 术语锁定有效 | 全书一致性检查 | ≥ 95% 核心术语一致 | | 本地处理是刚需 | 用户调研 | ≥ 70% 用户因"数据安全"选择 |


Risk Mitigation

技术风险:

风险 概率 影响 缓解措施
GPU 翻译质量不足 三级降级策略;保留人工编辑入口
CUDA 兼容性问题 降级到 CPU 模式(速度慢但可用)
术语锁定引入错误 术语预览 + 手动编辑界面

市场风险:

风险 概率 影响 缓解措施
作者不愿付费 免费试用 + 按量计费降低门槛
网文平台自建翻译 专注长尾作者/小型工作室
开源竞品出现 建立用户习惯 + 持续优化体验

回退计划:

  • 如果 GPU 翻译质量不达标:集成第三方翻译 API(有成本但可接受)
  • 如果混合计费不被接受:转为纯订阅模式
  • 如果网文作者市场太小:扩展到小说出版商、翻译工作室

Desktop App Specific Requirements

Project-Type Overview

序灵 Matrix 助手是一款本地桌面应用,专为中文网络小说作者设计的 AI 翻译流水线。作为桌面应用,核心优势在于:

  • 数据安全:全流程本地处理,作品内容零外泄
  • 性能可控:直接访问 GPU 硬件,无云端延迟
  • 离线可用:核心翻译功能无需网络连接

Platform Support

目标平台(MVP):

  • 主要:Windows 10/11(占据网文作者市场 80%+)
  • 次要(V2):macOS 12+(Intel/Apple Silicon 统一)

技术选型:

# 跨平台 GUI 框架
PyQt6 / PySide6  # 成熟稳定,商业友好
或
Electron + Python 后端  # 开发效率高,但包体积大

# 推荐:PyQt6 + Nuitka 编译
# 原因:零授权费依赖要求,Nuitka 可生成原生二进制

GPU 支持矩阵:

GPU 系列 CUDA 支持 目标速度 备注
RTX 40 系列 ✅ 完整 ≥ 8000 字符/分 最高性能
RTX 30 系列 ✅ 完整 ≥ 5000 字符/分 标准配置
GTX 16 系列 ✅ 完整 ≥ 3000 字符/分 入门配置
GTX 10 系列 ⚠️ 有限 ≥ 1500 字符/分 降级支持
无 NVIDIA GPU ❌ 不支持 N/A 提示升级硬件

最低硬件要求:

  • CPU:4 核 2.0 GHz+
  • 内存:8 GB(推荐 16 GB)
  • 显卡:NVIDIA GTX 1650 或更高,4GB VRAM
  • 存储:10 GB 可用空间(模型文件 + 缓存)

System Integration

文件系统集成:

  • 拖放支持:直接拖入 TXT 文件启动翻译
  • 文件关联:双击 TXT 文件自动打开 Matrix 助手
  • 最近文件:记住最近处理的 10 个作品

GPU 检测与初始化:

# 启动时自动检测
def detect_gpu():
    try:
        import torch
        if torch.cuda.is_available():
            gpu_name = torch.cuda.get_device_name(0)
            vram_gb = torch.cuda.get_device_properties(0).total_memory / 1e9
            return {
                "available": True,
                "name": gpu_name,
                "vram_gb": vram_gb,
                "estimated_speed": calculate_speed(gpu_name)
            }
    except:
        return {"available": False}

桌面通知:

  • Windows:原生 Toast 通知
  • macOS:NotificationCenter 集成
  • 通知类型:"翻译完成"、"部分章节上传失败"、"GPU 温度警告"

系统托盘:

  • 最小化到托盘(后台运行)
  • 托盘图标显示进度百分比
  • 右键菜单:暂停/恢复/查看进度

Update Strategy

MVP(手动更新):

  • 启动时检查更新(HTTP GET /api/version)
  • 发现新版本时显示通知
  • 用户手动下载安装包覆盖安装

V2(自动更新):

  • 增量更新:仅下载变更的模型文件
  • 后台下载,安装时提示重启
  • 回滚机制:保留上一版本

Offline Capabilities

离线核心功能:

  • ✅ 清洗分章(完全离线)
  • ✅ 术语提取(完全离线)
  • ✅ GPU 翻译(完全离线)
  • ⚠️ 指纹查重(需要网络)
  • ⚠️ 上传模块(需要网络)

网络断开处理:

  • 检测网络状态:定期 ping 服务器
  • 网络断开时显示状态图标(橙色)
  • 上传失败时保存到本地队列
  • 网络恢复时自动重试上传

本地数据存储:

~/.matrix-assistant/
├── models/               # 模型文件缓存
├── works/               # 作品工作目录
│   └── {work_id}/
│       ├── progress.json       # 进度状态
│       ├── novel_cleaned.json  # 清洗后数据
│       ├── terms_temp.json     # 术语提取
│       └── translated/         # 翻译结果
├── config/              # 配置文件
└── logs/                # 日志文件

Implementation Considerations

打包与分发:

MVP(简单方案):

  • PyInstaller 单文件打包
  • 生成的 EXE 约 500 MB(含模型)
  • 用户下载后直接运行

V2(专业方案):

  • Nuitka 编译为原生代码
  • 安装程序(NSIS/InnoSetup)
  • 模型文件分离下载(首次运行时下载)

许可证管理:

  • 一次性购买密钥绑定
  • 硬件指纹绑定(防止共享)
  • 在线激活(MVP)或离线激活(V2)

性能优化:

  • GPU 预热:启动时加载模型到显存
  • 内存管理:大文件流式处理,避免全部加载到内存
  • 多线程:UI 线程与翻译线程分离

Project Scoping & Phased Development

MVP Strategy & Philosophy

MVP 方法:问题解决型 (Problem-Solving MVP)

  • 核心目标:验证"本地 GPU 翻译能否满足网文出海需求"
  • 目标用户:早期采用者 — 对数据安全敏感的网文作者
  • 成功标准:用户完成端到端翻译,愿意付费

MVP 哲学:

  • 专注核心价值:一键完成 500 万字翻译,术语统一
  • 技术验证优先:验证 GPU 翻译质量、术语锁定机制、Crash-Safe 可靠性
  • 快速迭代:3 个月 MVP,6 个月 V2,12 个月 V3

资源需求:

  • 团队规模:2-3 人(1 全栈 + 1 ML/后端 + 1 QA 兼职)
  • 技能栈:Python、PyQt6、CTRanslate2、CUDA、REST API
  • 开发周期:12 周(2 周设计 + 8 周开发 + 2 周测试)

MVP Feature Set (Phase 1)

核心用户旅程支持:

  • ✅ Journey 1:首次使用 - 完整端到端翻译
  • ✅ Journey 2:续更翻译 - 增量翻译
  • ✅ Journey 3:崩溃恢复 - Crash-Safe 断点续传
  • ✅ Journey 4:术语校准 - 术语预览与编辑
  • ⚠️ Journey 5:失败处理 - 基础重试(P1 优先级)

六大核心模块(P0 必需):

模块 功能 验收标准
指纹机制 MD5 查重 + work_id 防止重复处理
清洗模块 章节识别 + 900 字符分段 0 断章,0 漏章
术语提取 Top200 自动提取 ≥95% 核心术语覆盖
翻译模块 m2m100 + CUDA 加速 ≥5000 字符/分钟
上传模块 逐章上传 + 扣费 API 调用成功率 ≥99%
任务调度 Pause/Resume/Crash-Safe 断电后可恢复

用户界面(P0 最小可用):

功能 描述 优先级
GPU 检测 启动时检测 GPU 可用性 P0
文件导入 拖入 TXT 文件 P0
进度显示 实时进度条 + 预计时间 P0
完成通知 桌面通知 P0
术语预览 翻译前预览术语列表 P0
术语编辑 手动修改术语翻译 P0

平台支持(MVP 限制):

  • ✅ Windows 10/11(主要市场)
  • ❌ macOS 支持(移至 V2)
  • ❌ Linux 支持(不考虑)

Out of Scope (MVP 明确不做)

明确排除的功能(避免范围蔓延):

功能 排除原因 计划版本
多语言支持(非中→英) 聚焦核心场景 V2
多文件批量处理 用户需求待验证 V2
用户术语表导入/导出 MVP 内置提取足够 V2
平台 API 直接对接 依赖平台合作 V3
协作功能 B2C 产品优先 V3
macOS 支持 市场份额验证 V2
CPU fallback 性能无法保证 永久不做
在线翻译备选 与本地定位冲突 永远不做

Post-MVP Features

Phase 2: Growth (V2 - MVP 后 6 个月)

目标: 扩大用户群体,提升产品竞争力

功能类别 具体功能 用户价值
平台扩展 macOS 12+ 支持 覆盖 Mac 用户
语言扩展 中→日/韩/西语 拓展海外市场
效率提升 批量多文件处理 工作室需求
术语管理 用户术语表导入/导出 系列作品一致性
质量优化 翻译记忆库 提升翻译质量

Phase 3: Expansion (V3 - MVP 后 12 个月)

目标: 构建平台生态,深化护城河

功能类别 具体功能 用户价值
AI 增强 AI 辅助润色 减少人工编辑
平台对接 Webnovel/Wattpad/Royal Road API 一键发布
协作功能 多译者协作 + 审阅流程 团队翻译
社区功能 术语表共享市场 网络效应

Risk Mitigation Strategy

技术风险:

风险 概率 影响 缓解措施
GPU 翻译质量不达标 MVP 原型验证;保留人工编辑入口
CUDA 兼容性问题 明确硬件要求;GPU 检测提示
术语锁定引入错误 术语预览;用户可编辑

市场风险:

风险 概率 影响 缓解措施
作者不愿付费 免费试用(10 万字);按量计费降低门槛
网文平台自建翻译 专注长尾作者;快速建立用户习惯
GPU 普及率不足 明确系统要求;目标用户筛选

资源风险:

风险 概率 影响 缓解措施
开发周期延长 MVP 功能裁剪;分阶段发布
团队规模不足 外包非核心模块(如安装包制作)
模型下载流量成本 CDN 加速;增量更新

Development Phases Summary

阶段 周期 核心交付 成功指标
Phase 0: 设计 2 周 技术方案验证 原型可运行
Phase 1: MVP 10 周 可发布的 Windows 版 100 用户试用
Phase 2: Growth 6 个月 macOS + 多语言 60% 留存率
Phase 3: Expansion 12 个月 平台生态 NPS ≥ 40

Functional Requirements

能力契约声明: 此功能需求列表是产品能力的正式定义。任何未在此列表中列出的功能将不会出现在最终产品中,除非我们明确添加。

文件处理与指纹识别

  • FR1: 系统能够读取用户导入的 TXT 格式网文文件
  • FR2: 系统能够从 TXT 文件第一章提取内容并计算 MD5 指纹
  • FR3: 系统能够通过 API 检查指纹是否已存在于服务器数据库
  • FR4: 系统能够为首次处理的作品生成唯一 work_id 标识符
  • FR5: 系统能够检测续更作品(已存在 work_id)并仅处理新增章节
  • FR6: 系统能够在网络错误时自动重试 API 调用

内容清洗与结构化

  • FR7: 系统能够识别 TXT 文件中的章节标题(兼容多种格式)
  • FR8: 系统能够清洗正文格式(合并空行、统一缩进、压缩空格)
  • FR9: 系统能够将清洗后的内容按固定长度分段(避免句子中间断开)
  • FR10: 系统能够将清洗后的数据输出为结构化 JSON 格式
  • FR11: 系统能够使用原子写机制保存清洗数据(防止断电损坏)

术语提取与管理

  • FR12: 系统能够从全文中提取候选术语(中文 2-6 字、英文大写开头)
  • FR13: 系统能够统计每个术语的出现频次和跨章分布
  • FR14: 系统能够根据频次和分布筛选核心术语(Top200)
  • FR15: 系统能够向用户预览提取的术语列表及其建议翻译
  • FR16: 用户能够手动编辑术语翻译并锁定
  • FR17: 系统能够复用已翻译作品的术语库处理续更内容

AI 翻译处理

  • FR18: 系统能够使用本地 GPU 加速的 m2m100 模型进行中译英翻译
  • FR19: 系统能够在翻译前将核心术语替换为占位符
  • FR20: 系统能够在翻译后将占位符还原为锁定的术语翻译
  • FR21: 系统能够批量处理多个分段以提高 GPU 利用率
  • FR22: 系统能够在批量翻译失败时降级为单条翻译
  • FR23: 系统能够记录翻译失败的项目到失败清单

内容上传与发布

  • FR24: 系统能够将同一章节的分段合并为完整章节
  • FR25: 系统能够逐章调用上传 API 发布翻译内容
  • FR26: 系统能够在上传前根据章节字数计算并扣除 CU 费用
  • FR27: 系统能够在上传失败时自动重试
  • FR28: 系统能够记录上传失败的章节并提供批量重试
  • FR29: 系统能够标记缺失分段的章节为不完整状态

任务调度与状态管理

  • FR30: 系统能够显示翻译任务进度(当前章节/总章节)
  • FR31: 系统能够响应用户暂停请求立即中断翻译任务
  • FR32: 系统能够从暂停点或崩溃点恢复翻译任务
  • FR33: 系统能够在任务执行过程中持续保存进度状态
  • FR34: 系统能够在启动时检测并提示用户未完成的任务
  • FR35: 系统能够显示任务预计完成时间

用户界面与交互

  • FR36: 系统能够在启动时检测 GPU 可用性并显示状态
  • FR37: 用户能够通过拖放方式导入 TXT 文件
  • FR38: 系统能够在导入后显示作品预览信息(章节数、术语数、预计时间)
  • FR39: 系统能够在翻译完成后发送桌面通知
  • FR40: 系统能够最小化到系统托盘并在后台运行
  • FR41: 用户能够查看历史任务记录和日志

数据安全与合规

  • FR42: 系统能够全流程在本地处理翻译任务(不上传原始内容)
  • FR43: 系统能够在生成的翻译内容中添加"Translated by 序灵 Matrix 助手"标识
  • FR44: 系统能够声明用户需拥有内容翻译权和发布权
  • FR45: 系统能够将用户数据本地存储(不上传云端)

离线与网络处理

  • FR46: 系统能够在网络断开时继续执行本地翻译任务
  • FR47: 系统能够检测网络连接状态并显示给用户
  • FR48: 系统能够将网络断开期间的上传任务保存到队列
  • FR49: 系统能够在网络恢复时自动执行队列中的上传任务

软件更新与维护

  • FR50: 系统能够在启动时检查是否有新版本可用
  • FR51: 系统能够向用户通知新版本的发布说明
  • FR52: 系统能够记录应用日志用于问题诊断

Non-Functional Requirements

Performance

翻译性能:

  • NFR-P1: 翻译速度 ≥ 5000 字符/分钟(基于 RTX 3060 基准 GPU)
  • NFR-P2: GPU 利用率 ≥ 80%(非空闲处理状态)
  • NFR-P3: 内存占用 < 4 GB(不含模型文件)

响应时间:

  • NFR-P4: 应用启动时间 < 10 秒(GPU 检测 + 模型加载)
  • NFR-P5: Pause 命令响应时间 < 1 秒(立即中断)
  • NFR-P6: 用户界面操作响应 < 200 毫秒(无卡顿感知)

批处理能力:

  • NFR-P7: 支持单文件 ≥ 500 万字处理
  • NFR-P8: 支持同时加载 ≥ 10 个作品记录

Reliability

数据完整性:

  • NFR-R1: 数据完整性 100%(原子写机制保证)
  • NFR-R2: 崩溃恢复率 99.9%(Crash-Safe 机制)
  • NFR-R3: 进度保存频率:每完成一个章节

服务可用性:

  • NFR-R4: 上传成功率 ≥ 99%(含自动重试 1 次)
  • NFR-R5: 网络错误自动重试间隔:2 秒
  • NFR-R6: API 调用超时:30 秒

错误处理:

  • NFR-R7: 所有失败项记录到失败清单(JSONL 格式)
  • NFR-R8: 失败清单写盘边界:每 10 个失败项或章节切换时

Usability

学习成本:

  • NFR-U1: 零学习成本 — 新用户拖入 TXT 即可开始翻译
  • NFR-U2: 新用户 5 分钟内完成首次翻译(从启动到生成英文版)
  • NFR-U3: 无需阅读用户手册完成核心功能

界面清晰度:

  • NFR-U4: 错误信息清晰可懂,包含解决建议
  • NFR-U5: 进度显示包含:当前章节/总章节/预计完成时间
  • NFR-U6: GPU 不可用时明确提示升级硬件

操作效率:

  • NFR-U7: 续更作品自动识别,无需手动配置
  • NFR-U8: 术语预览界面支持批量编辑

Security

数据保护:

  • NFR-S1: 100% 本地处理翻译内容(不上传原始文本)
  • NFR-S2: work_id MD5 仅用于指纹查重,不包含原文内容
  • NFR-S3: 用户术语表本地存储(不上传云端)

版权合规:

  • NFR-S4: 生成翻译内容添加"Translated by 序灵 Matrix 助手"标识
  • NFR-S5: 用户需确认拥有内容翻译权和发布权

许可证管理:

  • NFR-S6: 硬件指纹绑定(防止密钥共享)
  • NFR-S7: 在线激活验证(MVP)或离线激活(V2)

Compatibility

平台支持:

  • NFR-C1: Windows 10/11(64 位)- MVP 唯一支持平台
  • NFR-C2: Windows 7/8 不支持(明确提示升级)

硬件要求:

  • NFR-C3: NVIDIA GPU(GTX 1650 或更高,4GB VRAM)
  • NFR-C4: CUDA 11.0 或更高版本
  • NFR-C5: CPU 4 核 2.0 GHz 或更高
  • NFR-C6: 内存 8 GB(推荐 16 GB)
  • NFR-C7: 存储 10 GB 可用空间

运行时依赖:

  • NFR-C8: Python 3.11 运行时(打包在安装包中)
  • NFR-C9: 零授权费依赖(requests MIT 许可)

GPU 支持矩阵:

GPU 系列 支持 最低性能 备注
RTX 40 系列 ≥ 8000 字符/分 最高性能
RTX 30 系列 ≥ 5000 字符/分 标准配置
GTX 16 系列 ≥ 3000 字符/分 入门配置
GTX 10 系列 ⚠️ ≥ 1500 字符/分 降级支持
无 NVIDIA GPU N/A 明确提示不支持

Maintainability

日志记录:

  • NFR-M1: 所有操作记录到日志文件(轮转,最大 100MB)
  • NFR-M2: 日志级别:DEBUG/INFO/WARNING/ERROR
  • NFR-M3: 任务历史记录包含:开始时间/结束时间/状态/错误信息

诊断支持:

  • NFR-M4: 支持导出诊断包(日志 + 配置 + 进度文件)
  • NFR-M5: GPU 信息显示:名称/VRAM/驱动版本/CUDA 版本

Data Models

progress.json

任务进度状态文件,用于 Crash-Safe 恢复:

{
  "work_id": "uuid-v4",
  "fingerprint": "md5hash",
  "current_chapter": 123,
  "current_part": 2,
  "status": "running|paused|completed|failed",
  "updated_at": "2026-03-13T12:00:00Z",
  "total_chapters": 1500,
  "total_parts": 4500
}

novel_cleaned.json

清洗后的结构化章节数据:

{
  "chapters": [
    {
      "chapter_id": "Chapter 0001",
      "part_index": 0,
      "title_src": "第1章 礼物",
      "content": "清洗后内容..."
    },
    {
      "chapter_id": "Chapter 0001",
      "part_index": 1,
      "title_src": "第1章 礼物",
      "content": "更多内容..."
    }
  ]
}

terms_temp.json

术语提取结果(Top200):

{
  "terms": [
    {
      "term": "叶凡",
      "translation": "Ye Fan",
      "count": 124,
      "chapters": 87
    },
    {
      "term": "逍遥派",
      "translation": "Xiaoyao Sect",
      "count": 56,
      "chapters": 42
    }
  ]
}

novel_translated.json

翻译结果数据:

{
  "chapters": [
    {
      "chapter_id": "Chapter 0001",
      "part_index": 0,
      "title_src": "第1章 礼物",
      "title_en": "Chapter 1: The Gift",
      "content": "中文内容",
      "content_en": "English content..."
    }
  ]
}

upload_failed.jsonl

上传失败清单(JSONL 格式,每行一个失败项):

{"chapter_id": "Chapter 0892", "part_index": 0, "error": "Connection timeout", "retry_count": 1}
{"chapter_id": "Chapter 0893", "part_index": 0, "error": "Connection timeout", "retry_count": 1}

Appendix

Glossary

术语 定义
CU Chapter Unit,章节字数÷100 向上取整,计费单位
work_id 作品唯一标识符,基于第一章 MD5 生成
术语锁定 使用占位符替换机制确保全书术语翻译一致
Crash-Safe 原子写机制保证断电/崩溃不丢失进度
定长分段 900 字符基准分段,适配 GPU 批处理
Pause/Resume 任务暂停和恢复功能,章节级断点
失败清单 记录翻译/上传失败项目的 JSONL 文件

References

技术栈参考:

竞品参考:

行业标准:

  • WCAG 2.1: Web 内容无障碍指南
  • ISO 9241-210: 以人为中心交互系统设计

文档版本: 1.0 最后更新: 2026-03-13 文档状态: ✅ 完成


PRD Workflow Completion

创建日期: 2026-03-13 工作流版本: BMAD PRD Workflow 项目名称: 序灵 Matrix 助手

工作流完成摘要

PRD 创建工作流已成功完成

已完成步骤:

  1. ✅ Workflow Initialization (step-01-init)
  2. ✅ Project Discovery (step-02-discovery)
  3. ✅ Product Vision Discovery (step-02b-vision)
  4. ✅ Executive Summary Generation (step-02c-executive-summary)
  5. ✅ Success Criteria Definition (step-03-success)
  6. ✅ User Journey Mapping (step-04-journeys)
  7. ✅ Domain-Specific Requirements (step-05-domain)
  8. ✅ Innovation Discovery (step-06-innovation)
  9. ✅ Project-Type Deep Dive (step-07-project-type)
  10. ✅ Scoping Exercise (step-08-scoping)
  11. ✅ Functional Requirements Synthesis (step-09-functional)
  12. ✅ Non-Functional Requirements (step-10-nonfunctional)
  13. ✅ Document Polish (step-11-polish)
  14. ✅ Workflow Completion (step-12-complete)

交付成果

文档位置: /mnt/code/223-236-template-6/planning-artifacts/prd.md

包含内容:

  • Executive Summary(执行摘要)
  • Success Criteria(成功标准 - 用户/业务/技术)
  • Product Scope(产品范围 - MVP/Growth/Vision)
  • User Journeys(用户旅程 - 5个完整场景)
  • Domain-Specific Requirements(领域需求 - 六大核心模块规格)
  • Innovation & Novel Patterns(创新分析)
  • Desktop App Specific Requirements(桌面应用特定需求)
  • Project Scoping & Phased Development(范围界定)
  • Functional Requirements(功能需求 - 52项)
  • Non-Functional Requirements(非功能需求 - 性能/可靠性/可用性/安全/兼容性)
  • Data Models(数据模型 - 5个)
  • Appendix(附录 - 术语表/参考文档)

下一步建议

选项 1:验证 PRD 完整性

使用 bmad-check-implementation-readiness 技能
验证 PRD 是否包含开始实现所需的所有信息

选项 2:创建架构设计

使用 bmad-create-architecture 技能
基于 PRD 创建技术架构设计方案

选项 3:创建 UX 设计

使用 bmad-create-ux-design 技能
基于用户旅程创建交互设计规范

选项 4:分解 Epic 和 Story

使用 bmad-create-epics-and-stories 技能
将功能需求分解为可执行的 Epic 和 User Story

选项 5:项目文档

使用 bmad-generate-project-context 技能
为项目创建 AI 上下文文件

恭喜!序灵 Matrix 助手的 PRD 文档创建完成! 🎉