03 / SOFTWARE DEVELOPMENT
Scribyn｜从个人写作工具到可交付软件的研发与版本规划
独立软件产品项目｜2026 年 8 月下旬—11 月初
产品形态： Windows 本地优先的长篇写作软件
本人职责： 产品需求提出、功能范围取舍、开发任务沟通、反馈验收与版本决策；使用 Codex 等 AI 编程工具辅助开发
01｜项目背景：为什么需求从编辑器扩展为产品交付
Scribyn 面向需要同时管理正文、人物、地点、世界观、情节和大纲的长篇写作者。最初目标很直接：让用户在一个 Windows 本地工作环境中完成创作资料整理和正文写作，减少内容分散、查找困难和反复整理带来的成本。
项目从早期的 Eureka逐步演进为 Scribyn。随着功能积累，交付范围不再只是桌面编辑器，而是涉及四个相互依赖的部分：
| 组成 | 主要内容 | 项目管理关注点 |
|---|---|---|
| Scribyn 桌面端 | 正文、卡片、时间线、书签、导入导出、自动保存与 AI 对话 | 资料安全、操作连续性、功能验收、升级兼容 |
| ScribynWeb 官网 | 功能介绍、定价、下载入口、多语言与指南 | 与实际版本一致，用户能找到正确安装包 |
| ScribynPaymentsWorker | 支付回调、购买恢复、订阅管理、设备授权 | 订单、退款与权限状态保持一致 |
| 安装与更新流程 | 安装脚本、安装包、更新清单、旧版升级 | 用户实际收到的版本可用，旧数据不丢失 |
我在项目中逐渐调整了“完成”的定义：不是功能在开发环境中运行就算完成，而是需求明确、异常情况可处理、打包产物经过验证，用户能安装、升级并继续使用原有数据。这一变化成为后续版本管理的重点。
02｜实际版本演进：每阶段解决什么问题
以下是根据版本说明、缺陷审查和验证记录重建的阶段结构，用于说明开发顺序与交付重点。
| 阶段与时间 | 本阶段主要工作 | 可核查交付物 | 暴露的管理问题 |
|---|---|---|---|
| 功能探索（8 月下旬已有记录） | 编辑、书籍章节、书签、设定卡片、历史与导出；反复调整书签交互 | 基础写作流程与交互修改记录 | 需求容易停留在“做一个功能”，缺乏细化验收条件 |
| 商业化建设（8—9 月） | 官网、多语言、支付接入、授权与测试构建；支付方向经历调整 | 官网、支付集成与候选版本 | 一处商业规则调整，会同时影响网站、客户端和授权服务 |
| 稳定性修复（10 月中旬，1.3.11—1.3.13） | 修复导入、自动保存、备份恢复、导出等边界问题 | 缺陷审查、定向复现与回归记录 | 普通操作测试不足以覆盖数据冲突和失败场景 |
| 授权与功能迭代（10 月下旬） | 1.3.15 处理支付边界；1.4.x 增加创作辅助与 AI，1.4.7 简化正文发送 | 支付回归、功能说明与设置验证 | 功能复杂度、授权一致性与使用门槛同时增加 |
| 安装与发布补齐（11 月初，1.4.11—1.4.13） | 安装目录与旧数据迁移、密码提示、更新清单、主题和指南 | 安装场景检查、发布记录、旧版更新验证 | 发布涉及多个产物；“安装包上传”不等于“用户完成升级” |
在实际协作中，我根据使用反馈提出或调整需求，AI 开发代理负责代码检查和实现，再依据复现、测试与打包结果决定是否继续修改。这个过程更接近持续的小版本迭代，而非一次性制定并严格按表执行的瀑布式计划。
03｜需求拆解：从“做功能”转向“可验收的任务”
项目早期一个典型问题是：同一句需求往往有多种实现方式。例如“点击书签跳转”，不仅要确认能否跳转，还要明确整行点击区域、跨章节打开、与编辑／删除按钮的冲突，以及跳转后用户能否找到目标位置。相关操作在反馈后经历了多次修正。
基于这类经历，我将后续需求表达归纳成四个问题：用户要完成什么任务？正常操作如何表现？失败时如何保护数据？怎样证明功能完成？
以“旧版用户自动升级”为例，可以拆成以下交付检查：
| 可执行任务 | 验收条件 | 依赖关系 |
|---|---|---|
| 构建正式安装包 | 版本号、安装包内容与本轮源码一致 | 代码修改与基础回归结束 |
| 发布安装包 | 下载入口可访问，文件大小／信息与记录一致 | 安装包构建完成 |
| 同步更新清单 latest.yml | 更新清单指向新版本和对应文件 | 新安装包已确定且可访问 |
| 从旧版检查更新 | 旧版可以发现新版；新版不会提示更新到自身 | 安装包与清单已同步 |
| 检查升级后原有资料 | 已有稿件和关键设置仍可读取 | 安装与数据迁移检查完成 |
1.4.12 安装包上传后，线上更新清单仍指向 1.4.11，导致旧版误判“已经是最新版本”。随后补充同步清单，并验证旧版能够发现 1.4.12；1.4.13 也留下了更新发现检查记录。这个问题让我意识到，需要把跨环节依赖写进发布任务。
04｜关键问题与决策：如何控制交付风险
保存与导入冲突：先保证原稿安全
问题： 多轮审查发现，导入内容可能与自动保存交错，导致旧状态覆盖新内容；读取失败可能被误判为“没有书库”；备份失败后若继续导入，也可能失去恢复保障。
处理与取舍： 将“不存在、读取失败、内容损坏”区分处理；备份失败时中止覆盖性导入；导入期间阻止旧保存写回，并拒绝过期写入。相比新增便利功能，优先修复可能损害用户原稿的情况。
验证： 1.3.11—1.3.13 的记录覆盖磁盘不足、读取错误、延迟备份和自动保存交错等场景，其中还包含大文本保存与反复切换视图的检查。这证明相关缺陷在已覆盖场景下得到复测，但不能推导为全部设备和长期使用都没有风险。
PM 收获： 对写作软件，数据保护不是单独一个功能，而是导入、保存、备份、恢复与升级共同遵守的验收底线。
付款与授权：商业规则改变带来跨端依赖
问题： 项目从早期一次性购买方向扩展到订阅、买断和地区定价，并更换过支付服务。1.3.14 的审查发现：退款事件先于激活事件到达时，权限可能被错误恢复；部分退款累计处理不完整；并发登录可能突破设备数量限制。
处理与取舍： 按订单和付款记录授权事件；处理重复与乱序回调；累计退款；把设备额度检查与新增设备放进同一原子操作；客户端也修正了退出后旧购买流程可能写回状态的风险。
验证： 1.3.15 的记录显示 7 组原问题复现通过、支付服务 25 项测试通过，但使用隔离签名回调和模拟条件，没有真实扣款验证。〔S08、S09〕
PM 收获： 定价与套餐看似是商业决策，实际会连带影响客户端显示、支付回调、数据库权限和官网说明；版本计划需要提前标出这些依赖。
安装权限：开发环境正常不等于用户能用
问题： 用户反馈注册失败、程序无法正常关闭，而开发者本机未复现。模拟不可写目录后，发现账号文件写入失败可能触发防丢稿机制，进而影响窗口关闭。
处理与取舍： 调整新安装的默认位置为当前用户可写目录，补充历史安装记录和旧数据迁移逻辑。对已有目标数据不覆盖，迁移失败时保留原文件并停止高风险步骤。
验证： 1.4.11 的检查覆盖首次安装、历史机器级安装、受保护目录、自定义目录和迁移失败等 8 类场景；这不能直接证明原反馈用户现场问题的最终原因。〔S11、C02〕
PM 收获： 安装位置、普通用户权限、旧版升级和数据迁移应进入版本验收，不应留到外部反馈后才考虑。
AI 功能收敛：减少不必要的复杂度
问题： 新增 AI 对话后，用户需要理解服务商、Key、模型和基础地址；正文检索工具链也让功能依赖和内容发送范围更难解释。
处理与取舍： 1.4.7 移除“AI 主动按问题检索正文”的工具链，改为用户自己选取文字、加入聊天草稿并确认发送；复杂的接口地址配置则逐步移到高级设置。
验证边界： 相关设置与流程通过了定向检查；使用Deepseek API接入测试。
PM 收获： 版本升级并不总是增加功能。若一个方案提高维护成本和用户理解成本，缩小功能范围也可能是更好的交付决策。
05｜下一阶段版本规划
如果继续推进，我会把下一阶段定位为 “提升首次使用与升级可靠性”，暂时降低新增复杂功能的优先级。
| 建议里程碑 | 工作重点 | 主要交付物 | 通过条件 |
|---|---|---|---|
| M1：可靠性基线 | 整理高风险回归场景，统一版本台账 | 原稿安全测试清单、安装升级测试清单、发布登记表 | 保存／导入／恢复和主要安装场景有可重复的验证记录 |
| M2：首次使用优化 | 观察新用户从安装、创建书籍到导出的过程 | 新手任务流程、问题清单、分优先级的改进任务 | 严重阻碍首次写作的问题有处理结论和复测证据 |
| M3：交付与数据闭环 | 串联构建、安装包、更新清单、官网入口；明确运营指标口径 | 发布检查单、更新验证记录、指标定义 | 旧版可发现新版，发布资料一致，统计名称与真实含义一致 |
任务排序原则：原稿丢失／付款授权风险 > 安装与升级阻断 > 主要写作体验问题 > 非关键视觉优化。风险较高的变更先做隔离复现与回归，再考虑合入对外版本。
为避免再次出现“某一部分已完成，但整个交付链未完成”，每个版本至少记录：范围、负责人或执行方式、验收场景、阻塞项、测试结果、安装包标识、更新清单状态、发布状态和遗留风险。
06｜个人复盘
项目反思：
早期更关注“实现了什么”，验收条件补充偏晚，导致交互和边界问题反复修改。
发布涉及桌面端、官网、支付服务和更新元数据，必须识别跨环节依赖；仅检查源码或安装包不够。
当时没有统一的发布台账，部分版本说明、旧目录和交付包分散，降低了追溯效率。
AI 编程协作能提高实现速度，但不能替代本人对目标、取舍、风险和验收证据的判断；也不等同于真实的人类团队管理经验。
我想传达的 PM 能力： 能将模糊的软件需求拆成可检查的任务；在功能、数据安全与交付时间之间做出取舍；利用复现和测试记录跟进问题；清楚区分“代码完成”“测试通过”和“用户可以实际使用”三个阶段。
← 返回项目