鸿蒙 PC Markdown 编辑器 Alpha 评审：如何用退出条件判断阶段完成

鸿蒙 PC Markdown 编辑器 Alpha 评审：如何用退出条件判断阶段完成

阶段评审不是把已开发功能重新念一遍，而是依据事先批准的退出条件做"通过、条件通过或不通过"判断。自动化全绿不能替代内部试用，配置入库不能替代远程 CI成功，模拟器截图不能替代数据丢失结论。评审价值在于阻止团队为了进度重新解释门槛。

本文基于 OhMarkdown的 G2计划，给出证据矩阵、风险分级和当前结论。当前 G2尚未通过：G2-08仍等待远程 CI首次确认和10人连续7天试用，G2-09未开始。代码位于 https://gitcode.com/VON-/codex_md_oh，基线提交 3a9146e。

PRD 的四项退出条件

G2 Alpha退出要求：

核心编辑保存闭环稳定。
无已知数据丢失缺陷。
关键自动化测试通过。
至少10名内部用户连续使用1周。

四项是 AND关系，不是完成三项就按75%通过。内部使用是外部时间条件，无法由更多代码或文章替代。

评审输入必须绑定版本

评审记录 commit、HAP SHA-256、构建环境、测试报告日期和设备。不同版本证据不能混用：修复 P0后的新 HAP必须重新跑关键链路，旧版本七天试用不能自动证明新版本。

当前工程基线 commit 3a9146e，Release unsigned HAP大小1006605字节，SHA-256：

6d08d725bcb219ae97508281477cedb40d766d6860d7062e14d873f30322e31c

unsigned说明尚非发布签名包，但可用于 Alpha工程验证。

核心编辑保存闭环

证据应覆盖：新建、打开、编辑、dirty、保存、重开、保存失败、选择器取消、外部修改冲突、关闭脏标签和崩溃恢复。

已完成事实：Core File Kit打开保存；UTF-8严格读取；BOM/CRLF保真；Mixed显式策略；短写检查；沙箱旧版本备份；多标签关闭取消/放弃；活动文档保存；恢复RPO模拟器主链。

未完全覆盖：真机 provider矩阵、窗口关闭所有脏标签汇总、完整多标签崩溃恢复、重复1000次强杀、外部冲突完整 Compare/Save As交互。

G2计划按已定义纵切可认为核心工程闭环完成到 G2-07，但PRD 1.0的全部 P0功能不等于 G2 Alpha范围。评审需按阶段范围，不把 Beta/1.0需求偷塞进 Alpha，也不把 Alpha门槛推迟。

数据丢失缺陷判断

"当前问题列表没有数据丢失"不等于"已经证明无数据丢失"。评审检查已知缺陷、设备故障注入、恢复测试和内部试用。

已知代码路径：写入失败保留缓冲区与旧版本备份；保存期间新输入保持 dirty；选择器取消不关闭；恢复记录 AtomicFile；外部变化拒绝覆盖。ohosTest故障注入通过。

但内部试用0人0天，所以"无已知数据丢失缺陷"只能描述当前测试范围，不能代表真实用户验证。任何内部试用P0会立即改变结论。

自动化证据

当前本地：Playwright 20/20，ohosTest 4/4，Debug、Release、UnitTestBuild成功，diff检查通过。测试覆盖 GFM、安全、输入、恢复快照、历史隔离、多标签、搜索、大纲、滚动、主题、格式、大文档和导出。

评审同时列缺口：设备 UI大部分仍为操作记录而非全自动；CommonMark官方完整套件未接入；工作区两千项规模未测；真机性能未跑 P95。

关键自动化按 G2纵切可通过，但远程 GitCode Runner结果尚未确认。若 CI基线的定义包含远程可重复执行，该项保持进行中。

CI 不能用 YAML 代替结果

.gitcode-ci.yml包含 Playwright镜像、npm ci和 test:e2e。仓库启用 jobs/shared runner，但没有可引用的首次绿色 job。评审表应写"配置已入库、远程结果待确认"，不是"CI通过"。

确认时记录 pipeline URL、commit、镜像、开始结束时间和20项结果。配置文件名或触发规则若不兼容，修复后重新执行。

内部试用硬门槛

docs/INTERNAL_DOGFOOD.md当前：有效人数0/10、连续天数0/7、核心闭环0。工程入口准备不计一天。

试用要求每天真实文档新建/编辑/保存/重开，不收正文。任何一天不足10人，连续性需要重新判断。中途更换含重大修复版本，受影响路径重新验证。

这项未完成，因此当前 Alpha不能正式通过。评审文章可以完成方法和当前事实，不能写虚假成功总结。

风险分级

P0：数据丢失、错误覆盖、跨标签串文、恢复不可用且无副本、恶意文档执行脚本。未关闭P0直接不通过。

P1：高频崩溃但可恢复、主要保存/打开失败、中文输入丢字、核心工作流卡死、严重内存问题。Alpha评审应关闭或有明确阻断计划，通常不应带入 Beta。

P2：非阻断样式、次要文案、边缘交互，可进入 Beta清单。严重度按用户后果，不按修复成本。

条件通过何时使用

条件通过只适用于不改变安全结论、完成时间明确的非核心项，例如真机某档窗口补截图。不能把10人七天、已知P0或关键自动化改成条件通过，因为它们就是退出条件。

当前 G1曾按性能距离目标29.9%且有路径条件通过，符合 G1退出定义"不超过30%"。G2内部试用没有类似容差，不能类比放宽。

证据矩阵

需求/风险 -> 实现提交 -> 自动测试 -> 设备证据
-> 未完成项 -> 责任人 -> 截止条件

例如恢复：RecoveryService与 Bridge；Playwright两秒快照；模拟器强杀恢复图；未完成多标签/1000次压力。矩阵让评审看到覆盖范围，而不是只看"Passed"标签。

每个证据路径必须可打开，截图实际格式正确，测试报告状态与计划一致。文档不能把旧报告"部分通过"引用成最终通过。

鸿蒙 PC Alpha 基线画面

下图是当前 G2工程基线的完整应用。它展示已完成工作台，但不代表外部退出条件达标。

评审截图用于确认版本和主要界面，真正结论来自构建、测试、风险和试用记录。

评审会议流程

先锁定版本；逐条读退出条件；查看 P0/P1；演示核心保存与恢复；查看自动化和远程 CI；查看内部试用统计；列遗留与 Beta计划；最后做结论。先看功能演示再补条件容易被完成感影响判断。

结论由产品、研发、测试共同签署。单一开发者不能既定义范围、执行测试又独自降低门槛。小团队也应在文档中分离角色判断。

不通过后的动作

当前应继续 G2-08：确认 GitCode流水线，组织10人试用，按日记录；P0出现先修复并回归；七天满足后更新试用文章、质量报告与进度；再启动 G2-09。

不通过不意味着代码失败，而是阶段证据未闭合。保持 G2状态能防止 Beta功能掩盖可靠性缺口。

Beta 输入

Alpha通过后，G3重点为图片、工作区搜索、链接、图表、导出和 PC交互，50-100人封闭测试。Alpha遗留必须进入 Beta风险清单并有 owner，不能在评审结论中消失。

性能内存、真机多窗口、多标签恢复、外部监听和完整命令系统是重要候选。Beta范围仍以 PRD批准为准。

当前评审结论

截至2026-07-18：G2-01至 G2-07完成；G2-08进行中；G2-09未开始。核心功能与本地质量基线已建立，远程 CI首次结果和10人连续7天未完成。

正式结论：第二阶段尚未结束，Alpha退出评审不能通过。 这是基于既定闸门的事实，不是对已完成工程质量的否定。

当前边界

本文是评审方法与当前状态，不是最终签署报告；参与者、远程 job、真机矩阵和 Beta最终排期尚无数据。条件满足后必须更新日期、版本和结论，不能只改一句"通过"。

核心保存演示清单

评审现场使用无敏感副本完成：打开 BOM+CRLF文件，不编辑保存并比较字节；编辑后保存重开；保存期间继续输入确认星号保留；另一个应用修改磁盘后确认冲突阻止覆盖；未命名脏标签关闭选择保存，再取消系统选择器，标签必须保留；让目标目录不可用，确认旧磁盘版本或沙箱备份可恢复。

每一步先写预期，再操作。演示失败不能用"刚才偶发"跳过，应暂停结论、保存日志并创建问题。演示版本必须与自动化报告和 HAP哈希一致。

恢复演示输入带版本标记，等待快照后 force-stop，重启 Recover，检查内容、dirty、格式和保存；随后再次启动确认已保存记录不重复出现。Discard分支也要验证清理。多标签恢复未承诺完整时，演示和报告明确只覆盖活动标签。

自动化评审清单

Web报告列出20项名称，不只显示总数；确认生产单 HTML测试实际读取 rawfile，而非开发服务器；确认安全用例检查脚本副作用；确认 Replace All与多标签历史；确认大文档保护。

ohosTest列出4项设备结果：BOM/CRLF字节一致、Mixed归一、目标失败备份恢复、大纲 UTF-16偏移。UnitTestBuild与设备执行分别显示。Debug和 Release日志无 ArkTS错误，Release HAP重新计算 SHA-256。

若某项仅代码审查通过，矩阵中写"Review"，不能计入 automated passed。模拟器手工路径写"Device manual"，并附前置、操作和证据。

负面证据同样进入评审

性能报告中的1MiB进程组324.7MiB高于250MiB目标，是重要负面证据；G1按30%容差通过不等于问题消失。评审把它带入 Beta优化清单。10MiB曾出现一次 LowMemoryKill，虽然修复后未复现，仍需压力测试。

G2-08的0人0天、远程流水线无结果也属于证据，不是"没有数据所以忽略"。明确缺口能防止团队把未知误解为成功。

目录两千项上限只有代码保护、没有设备规模；标签保存关闭分支部分依赖调用链；真机触控板和多窗口未完成。这些按是否阻断 Alpha分类，而不是从报告中删除。

退出条件不得动态改写

评审前若发现10人难组织，不能临时改为3人；远程 CI平台故障可记录外部阻塞，但不能把"配置已提交"算成功。确需修改 PRD，必须独立变更评审，说明原因、风险和替代证据，不能在结果会议口头调整。

同理，不能把"连续一周"改成累计七个使用日，也不能把测试 fixture操作计入真实文档使用。度量口径在试用开始前冻结。

评审记录模板

评审日期与参与角色
Commit / HAP SHA-256 / 环境
四项退出条件逐条结论
P0/P1/P2清单
自动化、构建、设备、CI、试用证据
已知限制与风险接受人
结论：通过 / 不通过
下一动作与重新评审触发条件

"条件通过"若使用，必须列每个条件、owner、截止日和不完成后果。核心闸门不使用模糊待办。

重新评审触发

远程 Web job在同一或更新 commit首次成功，十名用户连续七天达到且无未关闭P0，所有试用发现完成回归后，才触发 G2-09。若期间代码有实质修改，重新跑完整20/4、Debug/Release和受影响设备路径。

最终评审文章更新实际数据，阶段总结再写正式结论。当前文章保留原未通过记录，形成决策历史，而不是覆盖得仿佛从未受阻。

结语

可靠 Alpha评审把功能、数据安全、自动化、远程可重复性和真实使用放在同一矩阵中。OhMarkdown当前工程主体到 G2-07完成，但外部闸门未闭合，因此保持未通过。

一个想做大的鸿蒙 PC编辑器，阶段纪律与保存代码同样重要：只有证据满足预先约定条件，才进入下一阶段。