ai-ticket-platform/docs/product/acceptance/local-user-acceptance-2026-07-27.md

本地真实用户验收报告（2026-07-27）

验收结论

本轮结论：不通过，需修复后复验。

产品主导航、普通建单、评论、状态流转、协作成员、知识检索、知识草稿、解决方案、 Agent 配置发布、运行取消、权限查看和审计查询等功能可以通过浏览器完成。18 个业务 菜单页面均可访问。

但以下问题阻止当前版本进入完整用户验收：

• 工单信息编辑返回 HTTP 500。
• 工单详情中的 Agent 支持分析返回 HTTP 500。
• 智能受理任务取消返回 HTTP 500。
• 按本轮指定的两进程启动方式运行时，没有异步 Worker 消费任务，智能受理、模型 连通测试和正式 Agent 运行只能进入排队状态，无法验证模型输出和自动建单闭环。

本轮共执行 23 个业务操作检查点：通过 17 个、失败 3 个、受启动条件阻塞 3 个。 页面可访问性另行检查，共 18/18 个菜单页面可访问。

验收环境

项目	实际环境
验收日期	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	未启动；这是 Agent 和智能受理运行阻塞的直接条件

本轮只进行了真实页面操作、接口状态观察和运行日志核对，没有执行代码测试、测试 脚本、Pytest、Vitest、Ruff、ESLint 或构建命令。

验收方法

1. 使用浏览器打开本地前端，通过登录页进入系统。
2. 展开每个导航分组，逐项点击菜单，不通过地址批量探测替代用户操作。
3. 使用统一的 UAT-20260727 前缀创建验收数据，避免与既有业务数据混淆。
4. 对创建、保存、状态变化和异步启动同时观察页面反馈与 HTTP 状态。
5. 对 HTTP 500 进一步核对 Django 运行日志，记录稳定复现条件和服务端异常。
6. 截图前仅在浏览器 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")；分类关系可为空。
• 影响：用户无法在详情页补充或修正工单信息。

UAT-BUG-02：支持分析无法启动

• 严重度：阻断
• 复现：进入工单 13，在“支持分析”区域点击“开始分析”。
• 实际：POST /api/tickets/13/support-analyses 返回 HTTP 500。
• 日志：与 UAT-BUG-01 相同的 PostgreSQL 外连接锁定异常。
• 定位线索：backend/apps/agents/support_analysis.py 的工单锁定查询。
• 影响：工单 Agent 支持闭环无法进入运行队列。

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 与模型渠道。

本轮产生的验收数据

类型	标识
工单	TK202607270001 / ID 13
协作账号	acceptance-no-ai
智能受理	75f6655c-59cb-4765-8389-31846013def7
知识草稿	UAT-20260727 登录回调持续加载排查
解决方案草稿	UAT-20260727 登录回调恢复方案
Agent	ID 4 / uat_login_triage / 发布 v1
Agent 运行	59843de3-fd75-4f97-883c-a53728618a4f，已取消

这些数据保留在本地数据库中，便于修复后沿用同一上下文复验；本轮没有自动删除用户 数据，也没有清理已有业务记录。

复验准入条件

1. 修复三个 select_for_update() 与可空 select_related() 组合导致的 500。
2. 使用非 Docker 方式补充启动异步 Worker，并确认任务消费者在线。
3. 重新执行工单编辑、支持分析、智能受理取消三个失败场景。
4. 完成一次智能受理到自动建单的完整闭环，核对材料、字段证据和工单事件。
5. 完成一次模型连通测试与一次发布 Agent 运行，核对步骤输出、Token、耗时和审计。
6. 对修复后的关键页面重新截图，并将本报告结论更新为最终验收结果。