14 KiB
14 KiB
本地真实用户验收报告（2026-07-27）
验收结论
初验结论：不通过。2026-07-27 定向修复复验结论：通过。
产品主导航、普通建单、评论、状态流转、协作成员、知识检索、知识草稿、解决方案、 Agent 配置发布、运行取消、权限查看和审计查询等功能可以通过浏览器完成。18 个业务 菜单页面均可访问。
初验时以下问题阻止当前版本进入完整用户验收：
- 工单信息编辑返回 HTTP 500。
- 工单详情中的 Agent 支持分析返回 HTTP 500。
- 智能受理任务取消返回 HTTP 500。
- 按本轮指定的两进程启动方式运行时，没有异步 Worker 消费任务，智能受理、模型 连通测试和正式 Agent 运行只能进入排队状态，无法验证模型输出和自动建单闭环。
本轮共执行 23 个业务操作检查点：通过 17 个、失败 3 个、受启动条件阻塞 3 个。 页面可访问性另行检查，共 18/18 个菜单页面可访问。
修复后沿用同一业务数据完成 6 个失败或阻塞检查点的定向复验，结果为 6/6 通过。 三个 HTTP 500 已关闭；非 Docker Celery Worker 已接入；自动建单、模型连通测试和发布 Agent 运行均取得真实终态，不再以“已入队”作为通过依据。
修复复验
| 初验项 | 修复内容 | 复验结果 | 证据 |
|---|---|---|---|
| TK-03 工单信息编辑 500 | 悲观锁只锁主表记录，不再锁可空外连接 | 通过 | 工单 13 保存成功并新增“更新工单”事件 |
| TK-06 支持分析 500 | 修正工单锁范围，发布符合当前输出契约的支持分析 v3 | 通过 | 运行 a0810d01-af54-4b53-9d18-0aaa5944bb45 成功，页面展示摘要、8 个排查步骤和客户回复草稿 |
| TK-09 智能受理取消 500 | 修正受理锁范围并由 Worker 消费撤销后的任务 | 通过 | 受理 a47ed6de-6800-4bd3-9a4c-fd6702be69e9 进入 rejected / analysis_cancelled，未创建工单 |
| TK-08 自动建单阻塞 | 启动 Celery Worker；模型总预算调为 60 秒；可信受理输出预算调为 8192 Token；保留新版结构化顶层字段 | 通过 | 受理 d82d1bc4-2563-4b9c-a419-329dcd4f26eb 自动创建 TK202607270003，保留 14 项字段证据 |
| AG-01 模型连通阻塞 | Worker 消费模型测试任务 | 通过 | DeepSeek 返回 UAT_MODEL_RETEST_OK，15 / 51 Token，3532 ms，0 重试 |
| AG-04 Agent 运行阻塞 | Worker 消费 Agent 任务；验收 Agent v2 补齐 environment 输入映射 |
通过 | 运行 c4e7c400-2b8c-444f-9364-ba8988b74ec8 成功，生成结构化输出和冻结配置 |
复验过程中还识别并关闭了两项在 Worker 恢复后才能暴露的问题：
- 可信受理的复杂字段证据契约会耗尽原 2048 Token 输出预算，导致 JSON 截断；发布配置 现固定使用 8192 Token。
- 旧版扁平输出兼容逻辑重组
fields时会丢弃新版problem_valid、证据和时间线；现仅 移除旧字段别名并保留完整顶层契约。
工单编辑、支持分析与取消复验
自动建单、模型与 Agent 复验
验收环境
| 项目 | 实际环境 |
|---|---|
| 验收日期 | 2026-07-27（Asia/Shanghai） |
| 前端启动 | npm run dev -- --host 0.0.0.0 |
| 后端启动 | python manage.py runserver 0.0.0.0:8000 --noreload |
| 前端地址 | http://localhost:5173，HTTP 200 |
| 后端探针 | http://localhost:8000/api/system/health/live，状态 alive |
| Python | 3.12.10 |
| Node.js / npm | v24.14.1 / 11.11.0 |
| 浏览器 | 本地 Chrome，由浏览器自动化执行真实点击和输入，1440 × 900 |
| 登录身份 | 本地管理员账号，凭据不写入文档 |
| Docker | 未启动、未使用 |
| 异步 Worker | 初验未启动；复验使用 python -m celery -A config.celery worker -l info -P solo，连接当前 Redis |
初验和修复复验均只进行了真实页面操作、接口状态观察、数据库终态与运行日志核对， 没有执行代码测试、测试 脚本、Pytest、Vitest、Ruff、ESLint 或构建命令。
验收方法
- 使用浏览器打开本地前端，通过登录页进入系统。
- 展开每个导航分组，逐项点击菜单，不通过地址批量探测替代用户操作。
- 使用统一的
UAT-20260727前缀创建验收数据，避免与既有业务数据混淆。 - 对创建、保存、状态变化和异步启动同时观察页面反馈与 HTTP 状态。
- 对 HTTP 500 进一步核对 Django 运行日志，记录稳定复现条件和服务端异常。
- 截图前仅在浏览器 DOM 中替换既有人员、企业名称，不修改数据库原始数据。
页面可访问性
| 分组 | 实际点击页面 | 结果 |
|---|---|---|
| 工单 | 工单中心、创建工单 | 2/2 可访问 |
| 知识与方案 | 知识库、知识检索、解决方案库 | 3/3 可访问 |
| AI 平台 | Agent 配置、模型渠道、Skill 配置、运行记录、Tool/MCP、渠道接入 | 6/6 可访问 |
| 系统治理 | 用户管理、用户组管理、角色权限、菜单权限、企业身份、操作审计、设计系统 | 7/7 可访问 |
所有页面均显示了对应标题和主要内容，没有出现整页“加载失败”。页面可访问不代表页面 中的所有写操作均已通过，功能结果以随后各表为准。
核心业务操作（初验）
| 编号 | 用户操作与验收数据 | 结果 | 页面或数据证据 |
|---|---|---|---|
| WB-01 | 工作台点击“我的待办” | 通过 | 跳转到分配给我的工单视图 |
| WB-02 | 工作台点击“新建工单” | 通过 | 跳转到创建工单页 |
| TK-01 | 普通表单创建 UAT-20260727 登录回调页面持续加载 |
通过 | 创建 TK202607270001，工单 ID 13 |
| TK-02 | 添加内部评论，记录已复现和后续排查计划 | 通过 | 评论进入工单时间线 |
| TK-03 | 编辑工单业务信息 | 失败 | PATCH /api/tickets/13 返回 500 |
| TK-04 | 工单从“待处理”流转到“处理中”，填写流转原因 | 通过 | 当前状态 in_progress |
| TK-05 | 添加 acceptance-no-ai 为协作人 |
通过 | 详情页显示协作成员 |
| TK-06 | 在工单详情点击“开始分析” | 失败 | POST /api/tickets/13/support-analyses 返回 500 |
| TK-07 | Agent 助手询问下一步排查顺序 | 通过 | 页面演示助手返回原因、步骤和建议回复；该助手明确不写业务数据 |
| TK-08 | 智能受理提交问题描述并开始分析 | 阻塞 | 受理 ID 75f6655c-59cb-4765-8389-31846013def7，持续显示“任务已排队” |
| TK-09 | 取消排队中的智能受理 | 失败 | 取消接口返回 500 |
| KN-01 | 检索“登录跳转失败” | 通过 | 返回 8 条，首条匹配度 0.47 |
| KN-02 | 创建知识草稿 UAT-20260727 登录回调持续加载排查 |
通过 | 保存后返回检索页；草稿不进入已发布检索结果，符合治理语义 |
| SO-01 | 解决方案库检索“视觉验收” | 通过 | 返回匹配方案 |
| SO-02 | 创建 UAT-20260727 登录回调恢复方案 草稿 |
通过 | 方案总数由 3 变为 4，新草稿可见 |
普通建单
工单详情与 Agent 支持分析失败
截图中可同时看到工单处于“处理中”、协作成员已加入，以及支持分析的 500 错误。
智能受理
知识检索与解决方案
Agent 专项验收（初验）
| 编号 | 用户操作与验收数据 | 结果 | 证据 |
|---|---|---|---|
| AG-01 | 对 deepseek-v4-flash 发起模型连通测试，提示词为“仅回复：UAT_MODEL_OK” |
阻塞 | 页面持续显示“排队中”，未产生模型回复 |
| AG-02 | 创建 uat_login_triage / UAT 登录回调排查 Agent |
通过 | 创建 Agent ID 4 |
| AG-03 | 使用 deepseek-v4-flash 和“问题结构化 v1”发布 Agent |
通过 | 当前版本显示“发布 v1” |
| AG-04 | 输入登录回调问题和本地 Chrome 环境，启动发布版本 | 阻塞 | 运行 ID 59843de3-fd75-4f97-883c-a53728618a4f，0/1 步，持续等待调度 |
| AG-05 | 对排队运行点击“尽力取消”，随后刷新 | 通过 | 状态变为“已取消” |
| AG-06 | 筛选 agents 审计记录 |
通过 | 可看到 Agent 创建、发布、运行启动和取消记录 |
模型连通测试和 Agent 运行都成功创建了任务及运行快照，说明前端、API、权限和版本化
配置链路可以工作；但没有异步 Worker 时不能证明模型渠道真实连通，也不能证明 Skill
输出、Token 统计和最终结果正确。审计中的 modelhub / test / success 表示请求已被接受，
不能作为模型已返回结果的证据。
系统治理与视觉检查
| 编号 | 用户操作 | 结果 | 证据 |
|---|---|---|---|
| SYS-01 | 搜索 acceptance-no-ai，打开“角色与用户组”，不保存修改后关闭 |
通过 | 用户状态、角色和用户组表单可读取 |
| SYS-02 | 操作审计筛选 agents |
通过 | 当前显示 41 条 Agent 相关记录 |
| SYS-03 | 打开设计系统预览 | 通过 | 按钮、状态、优先级、表格和详情区块正常渲染 |
缺陷与阻塞项
UAT-BUG-01：工单编辑返回 500
- 状态：已关闭，复验通过
- 严重度：高
- 复现：打开工单 13，编辑业务信息并保存。
- 实际：
PATCH /api/tickets/13返回 HTTP 500。 - 日志：
django.db.utils.NotSupportedError: FOR UPDATE cannot be applied to the nullable side of an outer join。 - 定位线索：
backend/apps/tickets/services.py的锁定查询同时select_for_update()和select_related("category")；分类关系可为空。 - 影响：用户无法在详情页补充或修正工单信息。
- 修复：使用
select_for_update(of=("self",))只锁工单主表记录；同类事务入口同步 收敛锁范围。
UAT-BUG-02：支持分析无法启动
- 状态：已关闭，复验通过
- 严重度：阻断
- 复现：进入工单 13，在“支持分析”区域点击“开始分析”。
- 实际：
POST /api/tickets/13/support-analyses返回 HTTP 500。 - 日志：与 UAT-BUG-01 相同的 PostgreSQL 外连接锁定异常。
- 定位线索：
backend/apps/tickets/support_analysis.py的工单锁定查询。 - 影响：工单 Agent 支持闭环无法进入运行队列。
- 修复：只锁工单主表记录，并发布支持分析 Agent v3 以匹配当前业务信任契约。
UAT-BUG-03：智能受理取消返回 500
- 状态：已关闭，复验通过
- 严重度：高
- 复现：创建智能受理，任务进入排队后点击取消。
- 实际：
POST /api/ticket-drafts/{id}/cancel返回 HTTP 500。 - 日志：同样为
FOR UPDATE作用于可空外连接一侧。 - 定位线索：
backend/apps/tickets/draft_services.py的受理锁定查询。 - 影响：用户无法从排队中的受理安全退出或转人工。
- 修复：只锁受理主表记录；取消后保留材料和字段，并阻止撤销运行继续自动建单。
UAT-BLOCK-01：两进程启动方式不具备异步消费能力
- 状态：已解除，复验通过
- 类型：环境阻塞，不等同于代码缺陷。
- 条件：仅运行 Vite 和 Django
runserver，未运行 Celery Worker。 - 现象：智能受理、模型连通测试、发布 Agent 运行均成功入队，但没有后续步骤。
- 影响：无法完成自动建单、模型返回、Skill 输出、证据落库和运行指标验收。
- 复验要求：保持非 Docker 方式，增加项目规定的 Celery Worker 启动命令，并确保其 连接到当前 Redis、PostgreSQL、MinIO 与模型渠道。
- 复验结果：Worker 已连接 Redis 并完成受理、模型测试和 Agent 运行三类任务。
本轮产生的验收数据
| 类型 | 标识 |
|---|---|
| 工单 | TK202607270001 / ID 13 |
| 自动创建工单 | TK202607270003 / ID 15 / pending_info |
| 协作账号 | acceptance-no-ai |
| 初验智能受理 | 75f6655c-59cb-4765-8389-31846013def7 |
| 复验自动建单受理 | d82d1bc4-2563-4b9c-a419-329dcd4f26eb |
| 复验取消受理 | a47ed6de-6800-4bd3-9a4c-fd6702be69e9 |
| 知识草稿 | UAT-20260727 登录回调持续加载排查 |
| 解决方案草稿 | UAT-20260727 登录回调恢复方案 |
| Agent | ID 4 / uat_login_triage / 初验 v1，复验发布 v2 |
| 初验 Agent 运行 | 59843de3-fd75-4f97-883c-a53728618a4f，已取消 |
| 复验 Agent 运行 | c4e7c400-2b8c-444f-9364-ba8988b74ec8，成功 |
这些数据保留在本地数据库中，便于修复后沿用同一上下文复验；本轮没有自动删除用户 数据，也没有清理已有业务记录。
复验完成情况
- 三个
select_for_update()与可空select_related()组合导致的 500 均已修复。 - 非 Docker Celery Worker 在线并消费当前 Redis 队列。
- 工单编辑、支持分析、智能受理取消三个失败场景均已通过。
- 智能受理已自动创建正式工单，字段证据、原始文本、运行和待补全任务可追溯。
- 模型连通测试与发布 Agent 运行均已取得真实成功输出及 Token、耗时记录。
- 复验截图已加入本报告；初验失败和阻塞项全部关闭。