智叟云集系统架构解析：从品牌 AI 可见度监测到前后端协同
随着用户越来越多地通过 AI 助手获取信息，企业开始关注新的问题：当用户询问某个行业、产品或解决方案时，AI 是否会提到自己的品牌？回答是否准确？引用了哪些内容？不同平台的回答又有哪些差异？
智叟云集系统围绕这些问题，提供品牌管理、监控问题配置、多平台任务执行、回答与引用整理、历史趋势分析，以及服务商 API 接入能力。
它将一次分散的人工查询转化为可以持续执行、记录和分析的监控流程。
1. 系统解决什么问题
传统人工监测通常需要逐个平台提问，再手动保存回答和截图。这种方式适合偶尔检查，但在持续运营中容易遇到三个问题：
- 执行不统一：不同时间、不同人员使用的问题和操作方式可能不同。
- 结果难追溯：回答、引用和截图分散保存，无法快速对应到具体任务。
- 历史难比较：缺少统一数据结构，难以观察品牌表现随时间的变化。
智叟云集系统以"品牌---问题---任务---结果"为基本业务结构，将这些信息组织起来。
例如，企业可以为某个品牌配置一组真实用户问题，再选择需要监测的 AI 平台。系统执行后，将各平台回答、品牌提及情况、来源链接和可用证据关联到同一任务，方便查看和比较。
2. 系统整体技术架构
系统采用前后端分离的组织方式。
| 层级 | 主要技术或组成 | 主要职责 |
|---|---|---|
| Web 前端 | React、Vite | 页面展示、配置表单、任务交互、结果查看 |
| 业务后端 | Node.js、Fastify | 身份校验、租户权限、业务接口、任务管理 |
| 数据存储 | SQLite | 保存品牌、问题、任务、结果及相关业务记录 |
| 采集执行 | Playwright、第三方采集接口适配 | 执行平台查询、获取回答和证据 |
| 文件存储 | 受保护的截图及附件目录 | 保存和提供采集证据 |
| 部署入口 | Nginx、应用服务进程 | 请求转发、静态资源访问和服务运行 |
业务请求的基本过程如下：
用户浏览器 / 服务商系统
│
▼
Web / API 入口
│
▼
身份校验与租户权限判断
│
▼
品牌、问题、任务等业务模块
│
▼
采集执行模块
├─ 浏览器采集
└─ 第三方采集接口
│
▼
回答、引用、截图与执行记录
│
▼
页面展示 / API 返回目前的架构适合围绕业务模块持续迭代。随着并发量增加，可以进一步把业务 API 和采集 Worker 拆成独立部署单元。
3. 前端如何组织业务功能
前端不仅展示监控结果，也承担监控配置和问题定位的入口职责。
3.1 品牌总览
品牌总览围绕当前选中的品牌展示监控信息，帮助用户快速了解已有结果。
这里需要注意，品牌出现率等指标应结合有效样本数一起阅读。少量样本中的高出现率，并不等同于品牌在整个 AI 平台中的整体覆盖水平。
3.2 监控问题管理
问题管理用于维护需要提交给 AI 平台的查询内容，包括问题新增、编辑和分类。
问题设计直接影响监测结果。例如：
- 品牌认知问题：某品牌怎么样？
- 行业推荐问题：某类产品有哪些值得关注的品牌？
- 场景需求问题：某种业务场景适合什么解决方案？
- 产品比较问题：不同方案有哪些区别？
将问题按类别管理，可以让后续分析更有业务意义。
3.3 监控任务与结果详情
任务页面展示执行状态、平台范围、检查进度及结果摘要。进入任务详情后，可以进一步查看各问题与平台对应的回答、引用和诊断信息。
前端应把"提交成功"和"采集完成"明确区分。创建任务成功，只代表系统已经接受请求，实际采集通常需要等待。
3.4 来源、趋势与报告
来源中心帮助用户查看回答引用了哪些网页或内容；历史趋势用于观察不同日期的监测变化；报告模块用于集中查看任务与品牌相关结果。
这些功能共享同一套结果数据，避免用户在多个页面重复整理信息。
4. 后端为何需要按模块拆分
监控系统的复杂度主要来自业务之间的关联。如果把接口、采集、权限和计费都放进一个文件，后续增加平台或修改规则时会越来越难维护。
现有工程已按路由、服务、安全、Worker、基础设施和数据库等目录分开组织。其职责可以概括为：
web/
src/ 前端页面及交互
dist/ 前端构建产物
src/
api/routes/ HTTP 路由
services/ 业务服务
security/ 身份与访问控制
worker/ 任务执行
infrastructure/ 外部能力适配
db/ 数据库访问与结构管理
shared/ 前后端或接口共享定义这种结构的重点是明确边界：
- 路由处理请求与响应。
- 服务层组织业务规则。
- 采集模块处理不同平台的执行差异。
- 安全模块统一执行身份和权限判断。
- 数据访问模块负责持久化。
例如，增加一个 AI 平台时，主要修改平台能力定义和采集适配器，而不应在每个业务接口里加入大量平台判断。
5. 数据如何形成完整的监测记录
系统中的核心对象包括：
| 对象 | 含义 |
|---|---|
| 租户 | 数据和权限的组织边界 |
| 品牌 | 被监测的业务主体 |
| 问题 | 提交给 AI 平台的查询内容 |
| 监控任务 | 一次监控执行的整体记录 |
| 采集样本 | 某个问题在某个平台上的一次执行结果 |
| 来源与证据 | 引用链接、截图及相关记录 |
其中，"任务"和"样本"需要分开理解。
一个任务可以包含多个问题和平台。部分平台成功、部分平台失败时，应保留成功样本，并准确记录失败原因，而不能只留下一个笼统的失败状态。
6. 技术代码展示：前端任务查询
以下代码为脱敏后的实现示意，不是项目源码原样摘录，展示如何将 API 调用与页面组件分离。
// services/monitoring-client.ts
export async function getMonitoringRun(runId: string) {
const response = await fetch(
`/api/monitoring-runs/${encodeURIComponent(runId)}`,
{ credentials: "include" }
);
if (!response.ok) {
throw new Error(`任务查询失败：${response.status}`);
}
return response.json();
}
// components/RunDetailButton.tsx
import { useState } from "react";
import { getMonitoringRun } from "../services/monitoring-client";
export function RunDetailButton({ runId, onLoaded }) {
const [loading, setLoading] = useState(false);
const [error, setError] = useState("");
async function openDetail() {
setLoading(true);
setError("");
try {
const detail = await getMonitoringRun(runId);
onLoaded(detail);
} catch (err) {
setError(err instanceof Error ? err.message : "请求失败");
} finally {
setLoading(false);
}
}
return (
<div>
<button disabled={loading} onClick={openDetail}>
{loading ? "加载中..." : "查看任务"}
</button>
{error && <p role="alert">{error}</p>}
</div>
);
}这个示例强调的是职责分离，以及失败时给出明确反馈。对于实际运营系统，清晰的错误提示和正常展示结果一样重要。
7. 当前架构的演进方向
随着客户数量与任务量增加，系统可以继续完善：
- 将采集 Worker 与业务 API 独立部署。
- 增加持久化队列和任务恢复机制。
- 将截图等证据迁移到私有对象存储。
- 在并发和多实例需求明确后评估数据库迁移。
- 完善性能指标、失败告警与恢复演练。
智叟云集系统的核心价值，在于把 AI 平台中的品牌表现转化为可持续执行、可追溯和可分析的数据流程。