阶段 8：文档与持续运营

1. 文档交付物（来自 Technical Writer：写给真的会读的人）

README / 产品主页（结构照抄）

1. 它为什么存在：一段话，解决什么痛
2. 快速开始：下载链接 → 安装 → 第一次打开看到什么（配图）
3. 核心用法：每个核心功能一小节，只写最短路径
4. 常见问题：杀毒软件警告怎么办（未攒够 SmartScreen 信誉时必写）、数据存在哪里、如何导出
5. 隐私与遥测：收集什么、怎么关
6. 许可与致谢

用户可见文档三件套

• 发布说明：每个版本，用户语言（"修复了导出中文文件名乱码"，不是"fix encoding bug #123"）
• FAQ：从第一周的用户反馈里长出来
• 反馈渠道：GitHub Issues / 邮箱，写清楚期望用户提供什么（版本、系统版本、复现步骤）

写作规则：每个步骤可照做（版本号、路径、按钮名与实际一致）；能截图就不描述；发布前请一个不了解项目的人照着走一遍。

2. 多语言（只有需要时才做，要做就按规矩，来自 i18n Engineer）

1. 禁止拼接翻译片段："你有 " + n + " 条" 不可翻译——每条消息是完整模板 + 占位符
2. 复数按 CLDR：用 ICU {count, plural, ...}，别写 if (n===1)
3. 日期/数字/货币永不手写格式：一律走系统/Intl；硬编码 YYYY/MM/DD 是缺陷
4. 按文本膨胀设计：德语比英语长约 35%，按钮和表头要能伸缩
5. 字符串带上下文：给翻译者写清 "Book" 是动词还是名词
6. 语言是用户选择：跟随系统 + 应用内可覆盖，不靠 IP 猜
7. 从第一天就把所有界面文案过资源文件（哪怕只有中文一种语言），后补成本极高

3. 运营节奏（来自 Phase 6，单人版压缩）

频率	动作
每日（发布后两周）	看崩溃上报、差评/反馈渠道；严重问题当天热修
每周	崩溃分诊：符号化、聚类、按影响面排序；更新采纳率曲线
每月	指标复盘（对 North Star）；依赖更新 + 安全扫描；备份验证
每季度	回滚演练复排；OS/WebView2/.NET 运行时弃用跟踪；路线图重排

崩溃分诊约定

• 符号上传自动化（发版流水线内）；minidump 能符号化归组
• 严重度：数据丢失/安全 > 核心流程崩溃 > 功能性缺陷 > 体验问题
• 每次事故的三问：怎么发生的？为什么测试没抓到？怎么让这类问题不再发生？（答案写回本 skill 包）

4. 迭代回到循环

• 用户反馈 → backlog → RICE 打分（阶段 1 的工具复用）→ 进下个 Sprint
• 新功能重新走阶段 5–7 的轻量版：实现规范不变，测试与签名发布一步不少

5. 质量门

#	判据	通过？
1	README/发布说明/反馈渠道就位且经外人走查	☐
2	崩溃上报看板 + 符号化链路可用	☐
3	运营节奏表贴出来（日历/提醒）	☐
4	（如做多语言）字符串已全部入资源文件	☐