DevPulse 凡事预则立与 Beta 七天计划

一 本阶段的目标

DevPulse 的基本功能已有实现基础。本阶段将围绕使用过程组织任务：新用户能否顺利进入系统，上传后的状态是否清楚，回答是否有依据，引用能否用于核对，异常发生后是否有明确反馈，交付说明是否足以支持接收方使用。

Beta 的预期产出包括一套核对过的项目基线、一组真实体验记录、一份可追踪的问题清单，以及相应的修订和回归证据。对于没有发现缺陷的已有功能，可以形成验证结论；不为增加“新增功能数量”而重复开发。

二 拟改进和新增的内容

本阶段不预设 OCR、跨知识库搜索或新的业务平台等大范围功能。用户反馈若提出此类需求，先记录价值和成本，再决定是否进入后续迭代。

三 初始任务清单

Beta 初始范围划分为 10 个工作包，编号为 B01～B10。启动时将按实际粒度建立 Issue，固定任务基线并追踪范围变化。

B10 在 Day 7 形成初版，11 月 23～25 日完成发布前复核。发现新的开发工作时，应加入任务台账；不能把额外任务隐藏在原工作包中而保持总量不变。

四 协作与流程改进

协作分工以岗位职责和具体交付物为基础。前端交互负责页面和可见状态；后端与数据负责接口、任务和数据一致性；检索与问答负责证据召回、模型交互和引用；测试与质量负责验收、复测和用户记录；文档与协调维护任务和交付资料。同一个人可以承担多个岗位，具体分配由团队内部落实。

每项任务先写明问题和预期结果，再开发或验证。涉及接口、字段和错误状态的变化，先同步给相关岗位。开发完成后由测试或协作岗位依据验收条件核对；没有达到条件的任务保持未完成，不能以“代码写完”替代验收。

站会拟每天 21:30 开始，控制在 15 分钟左右。依次说明上次会议后的成果、耗时与剩余时间、当前阻塞和次日安排。复杂问题另开讨论，避免把站会变成现场排错。

五 七天时间安排

六 博客发布安排

11 月 13 日拟发布置顶集合、文档交接、Alpha 问题总结和本计划；代码规范在冲刺前发布。11 月 16～22 日每天发布对应冲刺日志，记录当天的实际进展。用户调查报告在数据整理后发布，Beta 总结在最终回归与完成情况核对后发布，两者均安排在 11 月 25 日前完成，留出一天核对提交。

集合随笔统一维护各阶段进度和发布链接。每日记录与当天工作对应，调查分析依据实际体验和问卷结果。

七 工作量统计与燃尽图

初稿拟按 10 个工作包统计；启动时若拆成更多 Issue，就重新冻结初始任务数。每日 PM 报告统一采用同一种单位，累计完成数只统计已验收且未重开的当前范围任务。

当前范围总数 = 初始任务数 + 累计新增任务数 − 累计移出任务数。

剩余任务数 = 当前范围总数 − 当前累计验收完成数。

任务重开时从已完成数中扣回，并说明原因。任务数量只反映完成趋势，不代表每项工作成本相同；各岗位另行记录工时和剩余时间。燃尽图展示每日实际剩余任务数，并用范围变化表解释新增、移出和重开的影响。实际曲线从冲刺开始后的每日统计中生成。

八 验收与调整原则

主链路出现阻断、权限越界或资料丢失风险时，优先处理并复测。非关键的界面建议可以列入后续计划。涉及外部模型的结果要记录环境和日期，实际延迟与失败情况分别统计，避免用一次顺利演示代替整体效果。

到 Day 7 仍未完成的工作，应写明具体停在哪一步、对交付有什么影响，以及后续如何处理。Beta 总结将按 B01～B10 和 R1～R7 两套清单分别核对计划完成与复盘改进。