第40篇：智能助手模块的完整测试策略：从单 Skill 到工作流集成本文是"智能助手架构设计与实现"系列第 40 篇，也是系列的收官之作。前 39 篇从架构设计、技能框架、对话管理、工作流引擎、模板引擎、安全防护等多个维度拆解了智能助手的实现细节。本篇回归工程实践的本质——如何为这套涉及大模型交互、多步骤编排、本地模板渲染的复杂模块设计可落地、可维护的测试策略。一、问题背景：为什么智能助手需要分层测试1.1 测试困境：大模型不可控智能助手模块的核心链路是：用户消息 → 构建 System Prompt → 调用大模型 → 解析 JSON → 调用 Skill → 模板渲染 → 答复这条链路有三个难以测试的点：第一，大模型输出不可控。同样的输入，大模型可能返回标准 JSON、Markdown 代码块、前后带说明文字的 JSON，甚至格式错误的输出。测试中无法依赖真实的 LLM 响应。第二，Skill 依赖服务层。66 个 Skill 都通过call_service()调用后端服务，单元测试中不能启动真实的数据库和服务。第三，组件间紧耦合。DialogManager 依赖 WorkflowEngine、SkillR