DevPulse Alpha 阶段问题总结与 Beta 改进方向

一 最初的目标与现有基础

DevPulse 希望解决资料分散、重复查找、回答难以核对的问题。最初的主链路是：用户上传资料，系统完成入库和检索，生成带来源的回答，用户再通过引用和反馈判断答案是否有帮助。

现有实现记录已经覆盖这条主链路，包括异步入库、混合检索、流式问答、引用与反馈、权限控制和容器化运行。11 月 2 日的后续更新还记录了 DeepSeek 实时问答、追问和比较等五组调用验证。这说明项目具备进一步试用的基础，但不能据此推断所有用户都能顺利使用，或所有问题都能得到正确回答。

Beta 的重点是补足从“主链路可运行”到“别人能理解和使用”的验证过程。

二 设计与实现的问题

需求和实现之间需要明确对应关系

历史设计以 13 张业务基础表组织数据，实现方案补充了任务、认证会话和缺口事件等支撑表，后续验证记录按 16 张应用表描述实际落地。数量变化本身有业务原因，但如果设计、博客和讲解分别使用不同版本，接收者就很难判断当前系统以哪一套为准。

同样，早期材料对旧引用的描述与后续实现记录存在差别；旧方案中的摘录回答也已经被实时模型调用替代。Beta 应按具体版本建立一张对应表，写清每个需求由哪个页面、接口和验证步骤支持。对于已经改变的设计，保留原因并更新用户可见的说明。

功能存在不等于用户能完成任务

上传成功之后仍要等待解析和索引，用户可能把“文件已接收”误解为“已经能问答”。流式生成、停止、重试以及旧引用提示也都有不同状态。Beta 拟通过实际体验任务检查这些状态是否容易理解，再根据问题决定是否调整提示和操作流程。

这里需要验证的是用户是否知道当前发生了什么，以及下一步能做什么。不能仅以按钮存在或接口返回成功作为使用体验的结论。

三 测试与发布的问题

回归数据与真实使用效果需要分开

历史记录列出了 25 项后端测试、3 项前端 SSE 测试和 30 道固定检索题的结果。这些是相应版本的验证记录；后续实时问答更新也有自己的小样本验证。固定题集有利于比较改动前后是否退化，但不能替代独立用户的问题，更不能把“召回相关片段”直接写成“回答完全正确”。

Beta 拟把检索结果、回答事实、引用支持性和用户任务完成情况分别记录。一次回答即使引用了正确文档，也可能只支持其中一部分结论；人工核对时应逐条检查主要结论，而不是只看是否出现引用卡片。

本机运行与交付可用需要分别验收

项目已有 Docker 部署说明，历史记录也包含真实环境的主链路检查。但 localhost:8088 只服务于运行机器本身，其他人不能直接通过这个地址访问。交付时需要明确采用现场部署、局域网或公网演示中的哪一种方式，并在相应环境检查访问流程。

性能也需要清晰边界。实现记录明确说明 50 文档、20 并发和系统性引用支持性评估仍需单独验证。Beta 应记录实际测试规模、数据和模型配置，再解释结果；不沿用计划中的目标值冒充测量结果。

四 变更管理与协作的问题

计划与当前工程配置出现偏差

旧 Alpha 规范要求前端运行 npm run lint 和独立的类型检查脚本，但当前 frontend/package.json 只有 dev、build、preview 和 test，类型检查包含在构建命令中。这样的差异会使接收方照着博客执行时找不到命令。

Beta 的规范将以实际仓库命令为依据。未建立的检查工具只能写为后续拟引入项；功能或配置发生变化时，应同步修改说明和验收步骤。

岗位职责需要落实到具体交付物

仅用“负责前端”“负责测试”难以解释每天的成果。Beta 拟按任务记录主责岗位、协作岗位、预期产物和验收条件。开发任务关联 Issue 与代码提交，测试工作关联结果和缺陷，文档工作关联修改内容和接收验证。

这是一项面向下一阶段的协作改进，并不据此判断 Alpha 某位成员是否投入不足。下一阶段的协作复盘将重点分析交接等待、信息同步和问题反馈的效率。

五 设想与计划的问题

旧 Alpha 启动稿把七日计划排在 11 月 23～29 日。本次 Beta 要求 11 月 26 日截止，前置博客还必须更早发布，因此旧日期不能继续沿用。

另外，登录、文档上传和基础问答已经在实现记录中出现。Beta 如果再次把这些功能整体写为“从零完成”，就无法体现本阶段增量。新的计划应把已有能力列作回归基线，把用户发现的问题、说明修订与必要改进列作新增任务。

六 Beta 改进任务

七 复盘结论

Alpha 留下了可以继续推进的应用基础，也留下了需要收敛的文档口径和验证边界。Beta 将优先把现有能力讲清、测清，并让真实用户走完主要任务。新增功能应由具体问题推动，完成情况则由验收结果解释。

下一步按照凡事预则立执行，阶段结束后在 Beta 总结逐项回应 R1～R7。