AI 搭建客服系统，暴露 21 处规格缺口

可以，前提是服务于通过邮件处理客服请求的小团队。我们把 Help Desk 蓝图交给在 Type 中工作的 Claude，让它依次执行四个阶段的 prompt。最终构建在全新数据库上完成了一轮浏览器测试，24 项验收检查全部通过，另有 64 项自动化测试。它支持通过邮件和网页表单创建工单、Zendesk 的六种状态及生命周期规则、公开回复和内部备注、邮件会话串联、首次响应时限、预设回复、周报、CSV 导出，以及按客户要求删除其数据。

这也是我们十三次构建测试中最难的一次。构建过程暴露了规格中的 21 处缺口：有的没有说明，有的含糊不清，有的自相矛盾，构建者只能自行猜测。这是所有已测试蓝图中缺口最多的一份；其余十二份的缺口中位数为 8。目前，这些缺口都已在公开发布的规格中修复。

需要明确的是：这并不是一次经过验证的生产部署。真实邮件收发、生产环境登录、真实调度器和托管环境都不在测试范围内。最后一节会准确列出哪些经过了检查，哪些没有。

我们构建了什么，又舍弃了什么

这份蓝图复刻的是一个 2 至 25 人团队通过邮件处理客服请求时会用到的那部分 Zendesk 功能。我们在 2026 年 10 月阅读了 Zendesk 的定价页面，以及帮助中心有关工单状态和触发器的文章，保留了小团队需要的规则：

• 遵循 Zendesk 规则的六种状态。 New、Open、Pending、On-hold、Solved 和 Closed。为 New 工单指派负责人后，工单会变为 Open。客户回复会让 Pending、On-hold 或 Solved 工单重新变为 Open。任何人都不能手动将状态设为 Closed：系统会在四天后关闭 Solved 工单；客户回复已关闭的工单时，会创建一个关联原工单的后续工单。

• 每张工单只有一位负责人。 未指派负责人的工单不能标记为 Solved；仍有未解决工单的客服人员也不能被停用。

• 回复能够串成同一会话。 每条公开回复都会通过邮件发送，主题中包含工单编号，并带有正确的 In-Reply-To header，确保客户的回复回到同一张工单。

• 内部备注始终留在内部。 备注绝不会通过邮件发送、被引用，或出现在客户收到的任何内容中。

• 首次响应时限。 每种优先级都有对应时限：Urgent 为 1 小时，High 为 4 小时，Normal 为 8 小时，Low 为 24 小时。队列会显示 Due soon 和 Overdue，并将最早的工单排在前面。

• 回复过时提醒。 如果你撰写回复期间有同事已经回复，系统会阻止发送，并提示：“Ben Cho replied 2 minutes ago. Review the ticket before sending.” 你的草稿会保留。

有意舍弃的功能包括：在线聊天、电话、社交渠道、AI Agent 和 AI 回复、知识库、触发器构建器、基于技能的路由、按工作时间计算的响应时限，以及满意度调查。如果你需要这些功能，Zendesk 的 Suite 套餐包含它们。

与 Zendesk 相比，成本是多少

Zendesk 按每位客服每月收费。以下依据我们在 2026 年 10 月于 Zendesk 定价页面看到的价格：

这个自建应用不按席位收费，但也不是免费的：你需要支付托管、数据库、邮件收发服务的费用，还要投入构建和维护时间。对于使用 Support Team 套餐、只有几位客服的团队，每年大约能省几百美元。如果你原本需要购买 Suite 套餐，想使用当前 Zendesk 套餐不支持的规则，或者希望把工单保存在自己的数据库中，自建就更有吸引力。我们的《自建还是购买》指南提供了完整的决策分析。

构建过程：逐阶段推进

构建者收到的是一份 Markdown 格式的蓝图文件，然后依次向自己发送四个阶段的 prompt。每个阶段完成后，都会运行该阶段的验收检查：浏览器脚本以指定人员的身份在应用中点击操作，每轮都从重新加载的种子数据开始。最后一个阶段结束后，再统一运行全部 24 项检查。

1. 基础功能。 客服人员、开发环境登录、种子数据和工单模型。

2. 队列、工单和回复。 五个带数量统计的队列、工单页面、公开回复和内部备注、首次响应状态，以及回复过时提醒。

3. 邮件接收、会话串联和后续工单。 接收邮件服务商请求的入站邮件 endpoint、根据工单编号和邮件 header 串联会话、忽略重复邮件，以及针对已关闭工单创建后续工单。

4. 自动关闭、报表和数据删除。 关闭已解决工单的定时任务、周报、CSV 导出，以及客户数据删除。

每个阶段的 prompt 都以同一句话结尾：“列出你构建的内容，以及规格中任何需要你自行解释的地方。” 正是这句话，让那些缺口浮出了水面。

完整清单及每项修复都记录在蓝图的构建笔记中。它们可以分成五类。

种子数据无法支撑验收检查（4 处缺口）

种子客服人员没有邮箱地址，种子工单也没有消息，因此，打开工单会话的检查没有任何内容可展示。有一张种子工单被某条回复“解决”，但那条回复的发送时间比它最早可能发送的时间还早一天。数据删除检查在全新数据上不可能失败，因为根本没有可供删除的 outbox 记录。此外，只有最后一个阶段才要求测试者在运行检查前重置种子数据，导致前面阶段的检查运行在已被后续阶段修改的数据上。

经验：种子数据也是规格的一部分。每项检查都需要能够让它失败的数据。

数字恰好落在边界上，或缺少取整规则（3 处缺口）

工单 #1001 的演示示例恰好落在 Due soon 的边界上，因此显示“Due soon”或“Due in 1 h”都有道理。规格给出了精确时长，却没有说明如何取整。有一项报表检查的结果还取决于种子数据是在星期几加载的。

经验：不要把演示示例放在边界上，并明确每个显示数字的取整方式。

不同章节相互矛盾（4 处缺口）

一条规则说，工单在被指派负责人或收到回复之前应保持 New 状态，但生命周期表又允许客服人员直接修改它的状态。会话串联规则没有要求检查发件人，这与另一条边界情况说明相矛盾：陌生人的回复不得附加到已有工单上。构建者遵循了前面的表述，这也是构建者常见的做法。报表中的“Tickets solved”有两种解释，而 Solved 队列也没有说明是否应包含 Closed 工单。

经验：两个章节描述同一种行为时，其中一个迟早会偏离。规则只写一次，其他地方引用它。

规格提出了要求，却从未给出定义（4 处缺口）

数据模型没有地方存储客服表单的限流数据、删除工单后仍需保留的工单编号计数器，以及邮件重试次数。某项检查需要查看删除事件，却没有任何界面展示该事件。队列的排序规则含糊不清；规格还要求保留审计记录，却没有列出每个操作应写入哪些事件。构建者自行补出了其中一些答案，跳过了另一些。

经验：对每一条规则，都要问清楚：它的数据存在哪里，用户又会在哪里看到它？

邮件藏着与真实世界打交道的细节（6 处缺口）

常见邮件服务商无法发送入站 endpoint 要求的 Bearer header，因此现在也接受 HTTP Basic auth。“会话中的最后一封邮件”可能错误地选中内部备注。请求人没有姓名时，预设回复的问候语会出错。规格没有说明如何将过长的入站邮件主题转换为工单主题，也没有说明已解决工单的负责人被停用后，客户再次回复应如何处理，还缺少调度器应发送哪个 header，以及邮件发送失败后应重试多少次的规定。

经验：凡是需要与外部世界交互的功能——这里就是入站和出站邮件——都必须写清楚确切的格式、header 和重试规则。这与我们在全部十三次构建中观察到的情况一致：包含公开表单和数据保留功能的招聘流程，缺口数量排名第二，共有 18 处。关于所有构建中反复出现的问题，可以参阅《AI 应用构建器会在哪些地方出错》。

生产环境登录。 已构建 Google 登录，但所有检查使用的都是开发环境中的“sign in as”身份切换器。

真实邮件收发。 出站邮件记录在 outbox 中。入站邮件通过符合 endpoint JSON 格式的请求进行测试；另有一项单元测试会提交 Postmark 文档中的示例 payload。

每小时调度。 测试覆盖了任务 endpoint 和“run job now”控件，没有测试真实调度器。

托管环境。 测试构建在单台服务器上使用 SQLite 运行。未测试 HTTPS 下的安全 Cookie，也未测试真实代理之后的限流机制。

这些遗漏并非这个客服系统独有。我们在《AI 构建的内部工具是否已能用于生产环境？》中列出了每次构建都未测试的内容。

Help Desk 蓝图免费提供：一份 Markdown 文件，包含数据模型、15 条业务规则、界面、种子数据、四个阶段的 prompt 和全部 24 项验收检查，并且已经纳入上述 21 项修复。将它粘贴到 Claude、ChatGPT、Cursor、Lovable、Replit 或 Type 中，然后逐阶段发送 prompt。如果你发现了我们遗漏的缺口，请通过 About 页面告诉我们；我们会修复，并在构建笔记中注明你的贡献。

本文最初发表于 Personal Software Factory，完整的 Help Desk 规格可在那里免费获取。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。