第02章：架构设计——从需求表到技术方案
第02章：架构设计——从需求表到技术方案
2.1 需求表驱动：避免"技术炫技，业务冷场"
大多数AI项目的失败，不是技术不行，而是技术解决的是不存在的问题。
需求表驱动的核心思想很简单：业务方必须用结构化表格的方式输入他们的真实需求，技术方才生成对应的技术方案。这个环节做扎实，后面少走三个月弯路。
标准需求表模板
每个项目启动前，业务方必须填写这张表：
【项目基本信息】
项目名称：________________
核心目标（一个，不要超过三个）：________________
KPI指标（如何衡量成功）：________________
【数据来源】
现有数据：□ Excel □ 已有系统 □ 无，需从零建
数据类型：□ 顾客档案 □ 知识文档 □ 订单记录 □ 客服记录 □ 其他
数据量级：□ <1000条 □ 1000~10万 □ 10万~100万 □ >100万
【长期记忆对象】（哪些实体需要被AI记住）
□ 客户（字段：姓名/肤质/消费记录/回访偏好...）
□ 产品/项目（字段：名称/分类/禁忌症/价格区间...）
□ 员工（字段：岗位/权限/所属门店...）
□ 其他：________________
【权限范围】
谁可以看：________________
谁可以改：________________
谁可以删：________________
【模型层要求】
是否需要本地模型：□ 是 □ 否
对话风格：□ 正式专业 □ 亲切随和 □ 幽默活泼
是否有敏感词过滤需求：□ 是 □ 否
【交付期望】
预算范围：________________
可接受的学习曲线：□ 低（开箱即用） □ 中（需配置） □ 高（需开发）
这张表的价值在于：强制业务方把模糊的需求精确化。“我想要一个智能客服"和"我想让员工在飞书里用自然语言查询顾客档案，店长能看到所有数据，员工只能看自己的客户”，技术方案完全不同。
2.2 架构分层设计
拿到需求表之后，技术架构分四层设计：
第一层：入口层（客户端）
决定用户/员工怎么和系统对话：
| 入口方式 | 适用场景 | 接入难度 |
|---|---|---|
| 飞书机器人 | 连锁门店员工内部协作 | ⭐⭐（官方Skill支持） |
| Web界面 | 内部管理后台 | ⭐⭐⭐（FastAPI+Streamlit） |
| API | 第三方系统集成 | ⭐⭐（REST API） |
| 微信/企微 | 客户服务 | ⭐⭐⭐⭐（需企业资质） |
推荐起点：飞书机器人 + Web管理后台组合，覆盖内部员工协作和客户触达两个场景。
第二层：网关/大脑层（OpenClaw）
这是系统的核心枢纽，负责：
- Agent调度：根据用户输入，决定调用哪个Skill/工具
- Text-to-SQL：把自然语言翻译成SQL查询
- RAG检索：从向量数据库中检索相关知识
- 权限校验：判断当前用户是否有权执行这个操作
- 回复生成：结合知识库+上下文生成最终回复
用户消息
↓
OpenClaw 鉴权（是谁，什么权限）
↓
意图识别（查客户？查知识？新增记录？）
↓
工具调用（PG查库 / ChromaDB检索 / Ollama生成）
↓
结果整合 + 回复生成
↓
返回结果并持久化（写回数据库）
第三层：数据存储层
PostgreSQL + pgvector（推荐）或 ChromaDB：
| 数据类型 | 存储方案 | 说明 |
|---|---|---|
| 顾客档案 | PostgreSQL | 结构化，强类型查询 |
| 订单/咨询记录 | PostgreSQL | 带时间戳的时序数据 |
| 美业知识 | PostgreSQL + pgvector/ChromaDB | 结构化内容+向量embedding |
| 客户会话历史 | PostgreSQL + 向量 | 对话历史也需要语义检索 |
| 定时任务配置 | PostgreSQL | remind_tasks 表 |
第四层：模型层（本地推理）
| 模型类型 | 推荐方案 | 用途 |
|---|---|---|
| 主对话模型 | Qwen-7B/14B (Int4) via Ollama | 生成自然语言回复 |
| Embedding | bge-small-zh | 生成文本向量 |
| Rerank（可选） | bge-reranker-base | 提升检索排序准确率 |
2.3 核心数据模型
顾客档案（customers）
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL, -- 客户姓名
age INTEGER, -- 年龄
gender VARCHAR(10), -- 性别
skin_type VARCHAR(50), -- 肤质：干性/油性/混合/敏感肌/中性
allergy TEXT, -- 过敏史（重要！高风险字段）
risk_level VARCHAR(20), -- 风险等级：高/中/低
phone VARCHAR(30), -- 联系电话
create_user VARCHAR(100), -- 接待员工（权限归属）
store_id INTEGER, -- 所属门店
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
对话记录（dialogue_records）
CREATE TABLE dialogue_records (
id SERIAL PRIMARY KEY,
customer_id INTEGER REFERENCES customers(id), -- 关联客户
user_input TEXT NOT NULL, -- 客户原始输入
ai_reply TEXT, -- AI回复
intent VARCHAR(50), -- 意图：咨询/预约/询价/风险/闲聊
store_id INTEGER, -- 所属门店
created_at TIMESTAMP DEFAULT NOW()
);
美业知识库（medical_knowledge）
CREATE TABLE medical_knowledge (
id SERIAL PRIMARY KEY,
title VARCHAR(200) NOT NULL, -- 知识标题
content TEXT NOT NULL, -- 知识内容
category VARCHAR(50), -- 分类：眼鼻/抗衰/祛斑/轮廓
tags TEXT, -- 标签：光子/敏感肌/术后护理
forbidden BOOLEAN DEFAULT FALSE, -- 是否有禁忌提示
embedding vector(1536), -- pgvector模式：向量存储
created_at TIMESTAMP DEFAULT NOW()
);
定时回访任务（remind_tasks）
CREATE TABLE remind_tasks (
id SERIAL PRIMARY KEY,
customer_id INTEGER REFERENCES customers(id),
content TEXT, -- 回访内容
remind_time TIMESTAMP, -- 计划回访时间
is_sent BOOLEAN DEFAULT FALSE, -- 是否已发送
target_chat_id VARCHAR(100), -- 飞书Chat ID
created_at TIMESTAMP DEFAULT NOW()
);
2.4 权限体系设计
多门店场景下的权限体系，核心是三层角色：
| 角色 | 权限范围 |
|---|---|
| 总部管理员 | 所有门店、所有客户、所有数据、配置权限 |
| 店长 | 本门店所有数据，可新增员工，可看本店统计 |
| 员工 | 仅自己的顾客档案，仅新增和查询，不可删除 |
飞书身份映射：飞书用户在首次对话时，自动根据飞书部门/角色映射到系统内部角色，无需单独维护一套账号体系。
飞书用户 → 飞书部门/角色 → 系统角色（店长/员工/只读）
↓
权限规则引擎判断操作是否合法
2.5 需求到技术方案的转换流程
业务方填写需求表
↓
技术负责人拆解每个需求单元
↓
每个单元映射到具体技术实现
↓
输出：表结构SQL + API列表 + 提示词模板 + 交付里程碑
↓
业务方确认
↓
进入开发阶段
落地动作
- 下载或自制需求表模板，让业务方填写一个真实场景的需求
- 根据需求表，手绘一个简单的四层架构图（入口/大脑/存储/模型）
- 编写核心表结构的CREATE TABLE语句
- 确定飞书机器人的接入方式（官方Skill vs 自行开发）