cf46b27610
P0-1 (limits.go): Allow()方法改为全程使用写锁保护counters map读写，避免RLock写入时的data race P0-2 (ticket_workflow.go+ticket_handler.go): Assign/Resolve/Close操作先查询ticket存在性和状态，返回明确的CS_TICKET_4001/CS_TKT_4002/CS_TICKET_4092/CS_TICKET_4093错误码，handler根据错误前缀路由HTTP状态码 P1-1 (ticket_store.go): 移除GetStats中3处手动rows.Close()，只保留defer Close()
4.9 KiB
4.9 KiB
AI-Customer-Service 实施计划
状态说明：本文件原先采用
MVP-proto口径，已不再作为生产上线判断依据。生产执行以PRODUCTION_EXECUTION_PLAN.md为准。
历史说明：以下内容保留为原型阶段记录，不代表当前生产目标已达成。
1. 选择该项目的理由
AI-Customer-Service 是当前三个项目里最适合优先实施的对象：
- 文档结构最完整，且章节一致性最好。
- 业务主链路最短：Webhook 接入 → Session → Intent → Reply/Handoff → Audit。
- 风险可控，适合作为从文档到实现的第一条样板链路。
- 相比 AI-Ops 和 Supply-Intelligence，外部依赖与状态机复杂度更低，更容易做最小闭环验证。
2. 实施目标
第一阶段只交付“最小生产可运行版本”，包含：
- 独立运行模式 HTTP 服务。
- 健康检查端点：
/actuator/health、/actuator/health/live、/actuator/health/ready。 - Webhook 接口：最小文本消息接入。
- Session 管理：内存版会话存储。
- Intent 识别：规则版最小实现（不用真实 LLM）。
- Reply 生成：规则版 FAQ / fallback 回复。
- Handoff：敏感意图或低置信度转人工。
- Audit：内存版审计日志记录。
- OpenAPI 占位文档。
- 最小测试：主路径 + 失败路径。
非目标：
- 不在第一阶段实现 PostgreSQL / Redis / 向量数据库。
- 不在第一阶段实现真正 RAG 检索。
- 不在第一阶段实现多渠道适配，只做单 webhook 文本入口。
- 不在第一阶段实现完整 RBAC 后台。
3. 推荐工程结构
ai-customer-service/
go.mod
cmd/ai-customer-service/main.go
internal/app/app.go
internal/http/router.go
internal/http/handlers/health_handler.go
internal/http/handlers/webhook_handler.go
internal/domain/message/message.go
internal/domain/session/session.go
internal/domain/intent/intent.go
internal/domain/audit/audit.go
internal/service/dialog/service.go
internal/service/intent/service.go
internal/service/reply/service.go
internal/service/handoff/service.go
internal/store/memory/session_store.go
internal/store/memory/audit_store.go
internal/store/memory/knowledge_store.go
internal/openapi/openapi.json
test/e2e/webhook_e2e_test.go
test/integration/dialog_service_test.go
Makefile
Dockerfile
4. 分阶段任务清单
Phase 1：工程初始化
- 创建 Go module。
- 建立
cmd/+internal/目录结构。 - 创建最小
main.go，支持 HTTP 启动。 - 增加 health handler。
- 增加基础 router。
- 写启动 smoke test。
Phase 2：主链路实现
- 定义
UnifiedMessage、Session、IntentResult、AuditEvent。 - 实现 webhook handler：接收最小 JSON 文本消息。
- 实现 session store（memory）。
- 实现 intent service（规则匹配：quota/token/error/handoff/general）。
- 实现 reply service（规则回复/fallback）。
- 实现 handoff service（敏感词或低置信度转人工）。
- 实现 audit store（memory）。
- 打通主链路：receive → parse → intent → reply/handoff → audit。
Phase 3：测试与门禁
- 单元测试：intent service。
- 单元测试：handoff service。
- 集成测试：dialog service。
- E2E 测试：webhook 主路径。
- E2E 测试：敏感词转人工失败路径。
- 验证 health/readiness 端点。
- 生成最小 OpenAPI 占位文档。
Phase 4：运行工件
- 编写 Dockerfile。
- 编写最小 Makefile。
- 本地运行验证：
go test ./...。 - 本地运行验证：启动服务并 curl health/webhook。
5. 阶段门禁
Gate A：进入实现前
- PRD / HLD / TEST_DESIGN / INTERFACE 已存在。
- 文档中门禁、威胁建模、阻断条件已补齐。
- 工程目录已创建。
Gate B：主链路完成
- 独立运行服务可启动。
- Webhook 能接收消息并返回应答。
- 敏感意图能够转人工。
- 审计事件会记录。
Gate C：可交付最小版本
go test ./...全通过。- health/live/ready 通过。
- 至少 1 条主路径 + 1 条失败路径 + 1 条转人工路径验证通过。
- Dockerfile 可构建。
6. 验证命令
go test ./...
go test ./test/e2e -v
curl -i http://127.0.0.1:8080/actuator/health/live
curl -i http://127.0.0.1:8080/actuator/health/ready
curl -i -X POST http://127.0.0.1:8080/api/v1/customer-service/webhook \
-H 'Content-Type: application/json' \
-d '{"message_id":"m1","channel":"widget","open_id":"u1","content":"查询额度"}'
7. 风险与控制
- 当前没有真实 LLM/RAG，先用规则实现，防止卡死在外部依赖。
- 先做内存存储，防止过早引入数据库和 Redis 增加噪声。
- 先独立运行，不先做集成模式，等主链路稳定后再补 IntegrationPlugin。
- 严禁把 demo 规则实现误标为生产完成；本计划交付的是“最小生产可运行原型”，不是最终版。