# 产品需求文档 — UnionDesk 客户工单服务平台 V1.0 | 文档版本 | 日期 | 负责人 | 说明 | |----------|------------|--------|--------------------------------------------------------------| | V1.0 | 2026-05-01 | 项目组 | 初稿，待定稿 | > **核心页面清单**（客户端 / 员工端主要页面入口）： > > **客户端**：登录/注册、业务域选择、工单提交、我的工单列表/详情、在线咨询、咨询历史、反馈/建议提交、我的反馈、公开知识库/帮助中心、通知中心、个人设置、隐私政策。 > > **员工端**：登录、域工作台首页、工单队列/详情、咨询工作台、反馈管理、知识库管理、域配置（工单类型/状态流/SLA/动态字段/通知模板/屏蔽词/角色权限/客户管理/日志）。 > > **平台管理**：平台工作台首页、业务域管理、员工管理（含 CSV 导入）、离职池、平台角色管理、公共知识库管理、系统设置、安全告警中心、数据归档与导出。 --- ## 1. 产品概述 ### 1.1 产品定位 UnionDesk 是一个企业级、多业务域、可配置的客户服务中台。它统一管理**工单、在线咨询、反馈/建议、知识库**四类请求，通过业务域实现不同品牌/业务线的独立运营与权限隔离。 ### 1.2 项目边界 - **后端（Spring Boot）**：API 服务、鉴权/授权、业务规则、通知引擎、审计日志。 - **前端（React）**：两个独立 SPA 应用 —— 客户端（用户端）与管理端（内部工作台）。 - **MVP 不包含**：AI 自动回复、可视化 BI 报表、外部供应商协作门户。 - **短信通道**：MVP 不内置短信发送网关；系统架构预留短信渠道接口，部署方可选接入第三方短信网关。未接入时，找回密码、手机号改绑等场景自动降级为邮箱验证码，邮箱也不可用时转管理员处理（详见 1.5 外部依赖确认表）。 ### 1.3 MVP 核心价值 - 多业务域完全隔离，独立品牌入口与可见策略。 - 客户端

Gemini 3.5 Flash

Answer: UnionDesk V1.0 MVP架构边界清晰、降级设计完备，能有效满足多业务域隔离的核心诉求，但需尽快补充客户端核心价值的未完内容以确保研发闭环。

从当前披露的PRD内容来看，UnionDesk V1.0 的整体架构设计非常务实且具备高度的可落地性。 首先，产品定位极其明确。将工单、在线咨询、反馈和知识库统一收归中台，并通过“业务域”实现多品牌/业务线的物理与逻辑隔离，精准切中了大型企业多产品线独立运营的核心痛点。这种设计既保证了底层技术架构的统一，又赋予了前端业务极大的灵活性。 其次，MVP的边界控制非常合理。在首个版本中果断剔除AI自动回复、可视化BI报表等高开发成本、非核心链路的模块，有助于集中资源快速交付。值得称赞的是其“降级策略”，如短信通道未接入时降级为邮箱、再降级为管理员处理的闭环设计，充分考虑了企业私有化部署或初期建设时的外部依赖不确定性，保证了系统的高可用。 最后，当前的文档在“1.3 MVP核心价值 - 客户端”处发生了截断。建议项目组尽快补充客户端的具体价值主张（如多业务域下的个性化入口、轻量化交互等），并细化多业务域下的配置下发机制，以确保前后端研发在理解上达成一致。

Grok 4.3

Answer: UnionDesk的MVP设计通过业务域隔离实现了多品牌独立运营，同时保留了统一的后端服务能力，符合企业级客户服务平台的核心需求。

该文档清晰定义了客户端、员工端和平台管理三类入口，覆盖了工单、咨询、反馈和知识库四大核心功能模块。 MVP边界明确排除了AI自动回复和BI报表等非核心特性，有助于快速验证多业务域隔离与权限控制的有效性。 短信通道的降级策略和第三方集成预留设计体现了务实的工程考量，降低了初期部署复杂度。 整体架构采用Spring Boot后端与React双SPA前端的组合，既保证了API服务的稳定性，也支持前后端独立迭代。

GPT-5.5

Answer: 该 PRD 已具备 UnionDesk MVP 的产品方向与模块框架基础，但在进入研发前应进一步收敛 MVP 范围、补齐验收标准、权限边界、数据模型与外部依赖说明。

从现有内容看，UnionDesk 的定位比较清晰：它不是单一工单系统，而是面向企业级、多业务域、多角色协作的客户服务中台，覆盖工单、在线咨询、反馈建议、知识库四类核心请求。这一定位合理，且“多业务域隔离”是一个明确的差异化重点，能够支撑多品牌、多业务线独立运营。 页面清单也比较完整，已经区分了客户侧、员工侧和平台管理侧，说明产品对使用人群、操作入口和管理职责有基本拆分。尤其是员工端的域配置能力、平台端的员工管理、离职池、安全告警、数据归档等内容，体现出企业级系统对权限、审计和运维治理的关注。 但作为 V1.0 初稿，当前范围偏大。客户工单、在线咨询、反馈、知识库、多业务域、动态字段、SLA、通知模板、角色权限、客户管理、安全告警、数据导出等都被纳入 MVP，会带来较高研发复杂度。建议明确哪些是必须首发，哪些是可配置但低复杂度实现，哪些应后置到 V1.1 或 V2.0，否则 MVP 容易变成“大而全”的一期项目。 此外，文档目前更多描述“有什么页面”和“系统包含什么能力”，但还需要补充可执行的验收标准。例如工单状态流如何定义、SLA 如何计算、在线咨询是否需要实时 WebSocket、咨询转工单规则是什么、知识库审核流是否存在、客户是否跨域可见、员工多域任职时权限如何合并等。这些如果不在 PRD 阶段明确，会在后端建模、前端交互和测试验收阶段产生大量返工。 权限与数据隔离是该产品的关键风险点，也应进一步细化。既然产品强调业务域隔离，就需要明确平台管理员、域管理员、客服人员、知识库维护者、普通客户等角色的可见范围、操作权限、审计要求，以及跨域公共知识库和域内知识库之间的边界。否则“多业务域”很容易在实现中变成简单字段过滤，而无法满足企业级隔离要求。 外部依赖方面，短信网关的处理思路比较务实：MVP 不内置短信，但预留接口，并在未接入时降级到邮箱验证码或管理员处理。不过这类降级流程还应进一步写成具体业务路径，包括用户无邮箱、邮箱失效、管理员重置身份验证、操作审计和安全告警触发规则。 总体而言，该文档适合作为产品立项和方案评审的基础版本，但还不宜直接作为研发排期依据。下一步最重要的是压缩首版范围、补充核心流程图、权限矩阵、数据实体关系、接口边界和逐项验收标准，使其从“产品愿景型 PRD”转化为“可开发、可测试、可交付的 MVP 规格说明”。

Claude Opus 4.7

Answer: This PRD draft has a solid backbone but needs targeted hardening around multi-tenant isolation semantics, ticket state-machine governance, and SLA/notification observability before it is ready for engineering kickoff.

From what is visible, UnionDesk V1.0 makes sensible scope choices: locking the MVP to four request types (工单、在线咨询、反馈/建议、知识库), explicitly excluding AI auto-reply, BI, and supplier portals, and deferring SMS via a pluggable gateway with a documented degradation path to email and then to manual admin handling. That kind of explicit fallback chain in 1.2 is exactly what a PRD should do — it removes ambiguity for both architects and ops. That said, several areas need sharpening before this can be called 'ready': 1) Multi-business-domain (业务域) isolation is named as the core value, but the document needs to spell out *what* is isolated (data, roles, knowledge base, notification templates, SLA, audit logs) and *what* is shared (user identity? a single customer account across domains? public knowledge base?). Without this, downstream choices about row-level security, JWT claims, and the 公共知识库 vs 公开知识库 distinction will drift. 2) The ticket lifecycle is implied by '状态流' under domain configuration, but the PRD should fix a canonical default state machine (created → assigned → processing → pending-customer → resolved → closed → reopened) and define which transitions are configurable per domain versus locked by the platform. Otherwise SLA timing, notifications, and audit semantics become undefined. 3) SLA, 动态字段, 通知模板, and 屏蔽词 are listed as domain-level configuration items, but the PRD should clarify the precedence model (platform default → domain override) and whether changes are versioned and auditable. The 'V1.0 初稿待定稿' header already signals that policy gaps are expected. 4) The 离职池 (offboarding pool) is a strong inclusion for an enterprise tool, but it needs explicit rules: what happens to in-flight tickets, consultations, and knowledge-base authorship when an employee is moved to the pool — automatic reassignment, supervisor takeover, or read-only retention? 5) Security and compliance surfaces — 安全告警中心, 数据归档与导出, 隐私政策 — are listed as pages but need concrete requirements: what triggers an alert, retention windows, export formats, and PII redaction rules. For an enterprise positioning, these cannot be left to implementation. 6) CSV 导入 for employees needs explicit error-handling, dedup, and rollback semantics; bulk import is historically the #1 source of P0 incidents in admin consoles. Net: the scoping discipline is good and the page inventory is comprehensive, but the document is currently a structural skeleton. Before engineering kickoff, I would require a dedicated section on tenant/domain isolation, a canonical ticket state machine diagram, an SLA computation specification (business hours, pause-on-pending-customer), and concrete acceptance criteria per page. Until those are added, the PRD is appropriately marked '待定稿' and should not be frozen.

Final Summary

the AI Roundtable 普遍认可 UnionDesk 的多业务域隔离定位与务实的 MVP 边界控制。Gemini 3.5 Flash 与 Grok 4.3 赞赏其降级策略设计，而 GPT-5.5 与 Claude Opus 4.7 则提醒文档目前仅为“骨架”，需在权限边界、工单状态机及 SLA 逻辑上深度补全以防研发返工。

All 4 models agreed