周期建议：8–14 天。所有顾客、订单、渠道和知识内容均为合成数据；系统不得向真实用户发送消息。
项目背景
一家虚构的小型电商用聊天工具处理售前与售后问题。普通机器人在单轮 FAQ 上表现尚可，但一进入连续追问就会遗忘上下文；资料中没有答案时仍可能承诺退款或到货时间；复杂问题转给人工后，客服又要重新阅读整段对话。
团队需要的不是“永远能回答”的机器人，而是一个可靠客服 Agent：有证据才回答，记住必要上下文，不确定时明确兜底，高风险或用户要求时顺畅转人工，并为运营复盘留下记录。
项目目标
交付一个本地客服控制台和可测试的会话服务，走通“模拟渠道入站 → 多轮会话 → 知识证据 → 回答或兜底 → 转人工 → 审计复盘”的链路。
系统必须证明它知道什么时候不能继续自动回答，而不是以回复数量作为成功标准。
用户故事
- 作为顾客，我希望连续追问时系统理解当前话题，从而不必重复说明。
- 作为顾客，我希望答案能够核对知识来源，从而不被虚构承诺误导。
- 作为人工客服，我希望收到结构化交接摘要和完整证据，从而快速接手。
- 作为运营人员，我希望查看兜底、转人工和失败原因，从而发现知识缺口。
功能要求
必须完成
- 模拟渠道与会话
- 提供本地聊天 UI 或 Mock 入站接口，输入包含稳定的
channel_event_id、会话标识和消息文本。
- 重复发送同一个事件不得产生两条顾客消息或两次 Agent 回复。
- 会话至少支持
bot_active、handoff_pending、human_active、closed 状态。
- 多轮上下文
- 保存有顺序的消息历史，并从最近对话提取当前主题或关键实体。
- 至少支持一个需要引用上轮信息才能正确回答的合成场景。
- 对过长历史采用明确的截断或摘要策略，并在文档中说明信息损失风险。
- 知识检索与证据
- 使用本地 FAQ/知识条目完成检索；每个回答返回采用的证据标识和摘录。
- 知识条目需有版本或更新时间，便于审计回答依据。
- 可靠回答与无证据兜底
- 默认使用确定性 Mock Agent；回答只能依据当前会话事实与知识证据。
- 无命中、证据低于阈值或问题超出业务范围时，不得猜测，应给出明确兜底状态和下一步。
- 不得自动承诺退款、赔偿、物流时效或其他未在合成规则中授权的结果。
- 转人工规则
- 至少覆盖：用户主动要求、连续两次无证据、高风险关键词/意图三类触发。
- 触发后创建唯一交接单，包含原因、会话摘要、关键消息、证据和待确认事项。
- 转人工后 Bot 不得继续自动发送业务答案；人工可添加回复并关闭会话。
- 运营与审计
- 控制台可查看会话、证据、兜底原因、交接状态和知识缺口。
- 审计记录至少包含事件时间、决策类型、触发规则、关联会话和结果；不可通过普通 UI 改写历史记录。
- 失败处理
- 可稳定模拟检索或 Agent 失败；界面/API 给出可恢复错误，不丢入站消息，也不重复回复。
可选增强
- 渠道签名、时间戳和重放窗口的本地演示。
- 运营规则测试台、质量抽检和日报导出。
- 知识缺口聚合与待补充 FAQ 建议。
- 接入真实模型的 Adapter 接口设计；验收仍使用本地 Mock。
非功能要求
- 可运行性：仓库提供合成 FAQ、对话脚本和一键种子数据，离线可跑完整演示。
- 可靠性：入站事件幂等；状态迁移受约束；Agent 失败不得吞消息或重复生成交接单。
- 性能：在 50 个会话、100 条知识的本地样本下，单轮 Mock 回复应在 2 秒内返回。
- 可观测性：每次自动回答、兜底和转人工都能由会话标识关联审计，但日志不得泄漏凭证或不必要的全文。
- 安全与隐私：合成身份与订单号也应按最小化原则展示；输入按不可信文本处理，不能改变系统规则。
- 无障碍：会话状态、发送失败和转人工状态有文字说明，核心操作可键盘完成。
范围与限制
范围内
- 单业务、单团队的本地客服演示。
- 模拟渠道、多轮会话、本地知识、有证据回答、兜底、转人工和审计。
- 合成的售前 FAQ、物流规则、退换货规则和用户消息。
范围外
- 连接微信、短信、邮件、电话或其他真实渠道。
- 真实订单查询、退款、赔付、身份验证或支付操作。
- 生产级坐席排班、全量数据分析、复杂 RBAC 和多租户 SaaS。
- 复制任何现有客服项目的源码、客户资料或内部规则。
技术与时间限制
- 周期为 8–14 天；先保证可靠边界与交接，再增加运营能力。
- 技术栈可自选，但必须提供可演示的操作界面和可自动测试的服务接口。
- 默认仅允许本地知识库、Mock 渠道和 Mock Agent；测试不能访问公网。
- 不得要求真实手机号、账号、渠道 Secret 或模型 API Key。
- 不要求部署；若自行部署，必须先脱敏并保留无需外部依赖的本地验收路径。
澄清机制
在“澄清 Issue”记录问题，包含：背景、歧义、候选方案、推荐方案、影响和未回复时的可逆假设。
例如“连续两次无证据是按整场会话还是同一主题计算”会直接影响转人工规则，需要明确。展示文案等非阻塞问题可记录假设继续；涉及真实渠道、外发消息、真实用户数据、费用或改变高风险边界的问题必须等待组织者确认。若发现 A/B/C 都不适用，应保留 D/or 路径并说明如何验证。
交付物与证据
- 可运行源码、依赖锁文件、安全配置示例、合成知识和对话夹具。
README.md：架构、启动、主路径、兜底路径、转人工路径、故障模拟、测试和限制。docs/PRD.md：角色、会话状态、转人工规则、范围、验收映射和澄清决策。docs/PLAN.md：渠道、会话、检索、Agent、交接和审计的模块边界与数据流。- 自动化测试：至少覆盖事件幂等、多轮引用、证据兜底、三类转人工、Bot 停止回复和失败恢复。
docs/TEST_EVIDENCE.md：命令、结果、验收映射及脱敏的成功/失败/交接证据。docs/AI_COLLABORATION.md：AI 建议、本人判断与核验，不得粘贴私人会话全文。docs/RETROSPECTIVE.md、阶段 Issue、PR 和可解释的提交历史。
公开可测试验收标准
技术讲解与追问准备
请准备说明：会话状态机；上下文如何选择与截断；证据与答案的关系；三类转人工规则的取舍；事件幂等和失败恢复；为什么“无法回答”是可靠性能力而不是缺陷；AI 生成代码如何被你核验。
验收可能模拟一个模糊请求、重复事件或临时新增规则。你需要先澄清风险与状态影响，再在独立分支实现，并用回归测试证明没有破坏原流程。
安全与合规
- 仅使用合成人物、订单、消息和知识条目，不得导入真实聊天、手机号、地址、工单或客户数据。
- 不得连接真实消息渠道，也不得让系统自动执行退款、赔付或外部通知。
- 用户消息和知识内容均是不可信输入，不能覆盖系统规则、读取环境秘密或触发任意工具。
- 不得提交、共享或中转 Codex/模型/渠道账号、会话、Token、API Key、Cookie 或私钥。
- 本活动用于项目实践和能力反馈，不承诺就业、录用、薪资或面试结果。