06号文档
技术实施
排产中枢
技术架构实施方案
用什么技术、怎么组织代码、怎么部署运行、怎么从零建起来
04号回答了"系统由什么构成"，05号回答了"每个模块做什么"
本文档回答第三个问题：怎么把它建出来
技术选型总览
每一个选型都附带理由——不为炫技，只为最快交付核心价值
⚛️
前端 · PMC工作台
甘特图需要复杂交互，React生态最成熟
React 18
TypeScript
Vite
🐍
后端 · API服务
AI生态全在Python；asyncio处理IO密集
Python 3.12
FastAPI
🧮
排产引擎
Google开源CP-SAT，底层C++性能优秀
OR-Tools
CP-SAT
🤖
LLM
中文理解强；国产模型做降级备选
Claude API
国产模型备选
🐘
数据库
JSONB灵活schema + schema级租户隔离
PostgreSQL 16
⚡
缓存 + 消息
排产状态缓存 + WebSocket pub/sub
Redis 7
⏰
任务调度
凌晨排产 + 数据同步 + 报表生成
Celery
Redis Broker
🐳
部署
初期单机；后续迁移K8s
Docker
Compose
为什么选Python？
最关键的选型决策 — 不是最快的语言，但是这个场景的最优选择
✅ 不可替代的优势
- OR-Tools的Python绑定是一等公民，Go/Node绑定不成熟
- LLM生态（LangChain、token计算、prompt管理）全部围绕Python
- numpy/pandas在工时预测、统计分析中必要
- 数据适配器（解析伙伴云API、处理脏数据）Python最灵活
⚠️ 已知劣势及应对
- 并发不如Go → FastAPI asyncio处理IO密集；Celery隔离CPU密集
- 类型不够严格 → 全面使用Pydantic做数据校验
- 部署不如Go简单 → Docker容器化消除环境差异
真正的瓶颈在LLM API延迟（1-3秒），不在服务端代码执行速度
系统架构全景
模块化单体 — 代码内部严格分层，未来需要拆时只改调用方式
客户端
PMC工作台 (React SPA)
H5端 (React Mobile)
企微/微信
↓ HTTPS / WSS ↓
网关层
Nginx 反向代理
/app/* → 静态资源
/api/* → 后端
↓
API 路由层
/delivery/*
/schedule/*
/chat/*
/workstations/*
/events/*
/reports/*
↓
服务层
AI Service
Schedule Service
Knowledge Service
Push Service
↓
引擎层
CP-SAT 求解器
贪心求解器
级联评估引擎
冲突检测器
↓
数据层
PostgreSQL 16
Redis 7
COS / OSS
伙伴云 API
关键决策：模块化单体
不做微服务 — 3-5人团队的运维开销不值得；但代码内部严格分层
单进程 FastAPI 内部分层
├── api/
├── services/
├── engine/
├── ai/
├── adapters/
├── knowledge/
├── models/
├── schemas/
├── core/
└── workers/
拆分触发条件（不急，等真的需要时）
排产引擎CPU占用影响API响应
→ 拆为独立 worker 进程
LLM调用量大到需要独立限流
→ AI翻译层独立部署
多租户数据隔离
PostgreSQL Schema 级隔离 — 最强的逻辑隔离，即使SQL注入也只能访问当前 schema
请求 → Schema 路由
JWT Token
→
中间件提取
tenant_id
→
ContextVar
注入
→
SET
search_path
async def get_db() -> AsyncSession:
async with session_factory() as session:
tenant_id = current_tenant_id.get()
await session.execute(
f"SET search_path TO
tenant_{tenant_id}, shared, public"
)
yield session
Schema 结构
tenant_factory_001
workstation, capacity_slot, scheduled_task, task_dependency, execution_log, customer_rule, conversation_log
tenant_factory_002
完全隔离，互不可见
排产引擎 · 三策略体系
根据场景特征自动选择求解策略 — CP-SAT超时则自动降级到贪心
CP-SAT 精确求解器
🎯
适用: < 50 个任务
超时: 10 秒
质量: 全局最优
原理: 约束编程
决策变量 → 工站分配约束
无重叠约束 → 前序依赖约束
目标: 最小化加权延迟
贪心求解器
⚡
适用: > 50 个任务
响应: < 1 秒
质量: 可用解
原理: 优先级排序
按优先级×紧急度排序
逐任务找最早可用工站
也做CP-SAT超时的降级方案
TOC-DBR
🔗
适用: 瓶颈利用率 > 90%
响应: < 3 秒
质量: 瓶颈最优
原理: 瓶颈优先
先排瓶颈工站
其他工站围绕瓶颈节奏
降低问题规模
请求进入
→
SolverSelector
评估任务数/瓶颈/时限
→
执行求解
→
超时?
降级贪心
→
返回结果
AI翻译层 · 两阶段意图路由
关键词匹配覆盖80%（<1ms），LLM只处理剩余20%（200-500ms）
第一阶段: 关键词快速匹配
| 意图 | 关键词示例 |
|---|
| 交期试算 | 能不能交、什么时候能出、排得下吗 |
| 插单评估 | 加一单、插个单、急单 |
| 异常响应 | 坏了、故障、停机、料没到 |
| 假设推演 | 如果、假设、要是、万一 |
| 状态查询 | 到哪了、进度、做完了吗 |
第二阶段: LLM 兜底分类
返回格式
{intent, confidence, entities}
设计哲学：LLM只做人理解，不做排产计算。所有数字结果由引擎产出。
LLM Client + Prompt Builder
多 Provider 降级 + 工厂上下文动态注入
LLM Client — 多 Provider 支持
"claude-sonnet" → claude-sonnet-4-6
"claude-haiku" → claude-haiku-4-5
"claude-opus" → claude-opus-4-6
complete()
stream()
Prompt Builder — 动态上下文
你是{factory_name}的排产助手。
- 工站共{workstation_count}台
- 今日在制工单：{active_orders}个
- 瓶颈工站：{bottleneck}
（利用率{bottleneck_util}%）
- 今日产能利用率：{today_util}%
1. 用PMC能理解的语言
2. 排产调整必须展示影响范围
3. 不确定的数据标注置信度
4. 给可操作建议
5. 多方案标注优劣
适配器层 · 伙伴云对接
统一接口抽象 + 数据质量补偿 — 不中断同步，记录异常
统一适配器接口
class BaseAdapter(ABC):
async def fetch_demands()
async def fetch_materials()
async def fetch_routings()
async def push_instructions()
async def push_alerts()
已实现: 伙伴云
预留: 飞书 Excel
数据质量补偿策略
库存 15% 安全缓冲
available = raw_stock × 0.85
库存数据可能不实时 → 置信度 0.7
异常不中断
单条订单数据异常 → 记录 warning → 继续同步
在途数量交叉补充
从采购明细表汇总在途量 → 丰富物料数据
前端架构 · 甘特图核心
Canvas 渲染性能 + HTML Overlay 交互 — 几百个任务不卡
Canvas 层 (渲染)
时间网格
任务块
依赖箭头线
"现在"标记线
为什么用 Canvas？
DOM方案需要创建几百个 div → 卡
Canvas 一次绑定，性能恒定
HTML Overlay 层 (交互)
拖拽排产流程
① onDragStart
创建半透明影子 + 高亮可放置工站
② onDragMove
实时显示新时间/工站 + 15分钟粒度吸附
③ onDragEnd
→ 调用后端冲突检测API (< 200ms)
④ 冲突处理
有冲突 → 弹出面板 | 无冲突 → 直接应用
WebSocket 实时联动 AI 对话窗 ↔ 甘特图高亮
数据同步 + 缓存策略
全量同步 (凌晨) + 增量同步 (事件驱动 / 轮询兜底) + 健康检测
同步策略
🌙 全量同步 · 每日凌晨 3:00
拉取伙伴云全量数据 → diff → 更新缓存 → 触发重算
⚡ 增量同步 · 事件驱动
伙伴云 Webhook → Redis 事件队列 → 处理
Webhook不可用时: 每1小时轮询兜底
🔍 健康检测
失败 3 次 → 告警
数据 > 4 小时 → 界面标注 "数据可能不是最新的"
Redis 缓存设计
| 缓存键 | TTL | 失效触发 |
|---|
| schedule:{tenant}:{date} |
5分钟 |
排产更新/任务完成 |
| capacity:{tenant}:{ws}:{date} |
10分钟 |
产能/排产更新 |
| material:{tenant}:{id} |
1小时 |
物料同步 |
| chat_session:{id} |
30分钟 |
会话关闭 |
策略: 写时失效 + TTL兜底。甘特图加载走缓存，排产操作走实时。
部署架构 · 渐进演进
从单机 Docker Compose 到 K8s — 每个阶段只用刚好够用的基础设施
Phase 0 · 单机
1 台 4核8G 云服务器
Docker Compose 一键部署
PG + Redis 同机
前端 CDN 加速
支撑 1-3 租户 · ¥300/月
Phase 1 · 小集群
API 2台 (2核4G × 2)
DB 独立 1台 (4核16G)
Redis 1台 (2核4G)
Celery Worker 1台 (4核8G)
支撑 10-30 租户
Phase 2+ · K8s
腾讯云 TKE / 阿里云 ACK
服务按需水平扩展
云 RDS (自动备份/读写分离)
云 Redis
按需弹性扩展
CI/CD 流水线
git push main
→
pytest + mypy
→
Build Docker
→
Push Registry
→
SSH Deploy
监控 · 安全 · 可观测性
Prometheus + Grafana 双看板 · JWT + RBAC 四角色 · Schema 级租户隔离
监控指标
业务指标
日活租户数
每日对话数
试算响应时间
建议采纳率
置信度趋势
技术指标
API P50/P95/P99
LLM成功率/延迟
引擎计算时间
Redis命中率
Celery队列长度
告警规则
API P99 > 5s · LLM 连续失败 3 次 · 同步失败 3 次 · 连接池用完 · 磁盘 > 80%
权限矩阵 (RBAC)
| 角色 | 核心权限 |
|---|
| admin |
全部权限 (*) |
| pmc |
排产读写 · 交期试算 · 完整对话 · 规则管理 · 报表 |
| sales |
交期试算 · 本客户排产只读 · 交期相关对话 |
| workshop |
本工站排产只读 · 报工 |
安全三层：
HTTPS全程加密 · JWT + schema隔离 · 密钥存云KMS
Phase 0 · 10天实施计划
两周内完成端到端闭环 — PMC用自然语言做交期试算
第一周: 基础骨架
Day 1-2 · 项目初始化
GitHub仓库 · Docker Compose环境
数据库模型 · Alembic迁移
基础API骨架 · JWT认证
Day 3-4 · 排产引擎核心
CP-SAT求解器（最简版）
贪心求解器 · 策略选择器
交期试算API · 单元测试
Day 5 · 前端原型
React + Vite + TypeScript
甘特图最简原型（Canvas + 静态数据）
API联调
第二周: AI + 伙伴云接入
Day 6-7 · AI翻译层
LLM Client · 意图路由器
Prompt Builder · 完整链路
NL → 意图 → 引擎 → NL
Day 8-9 · 伙伴云适配器
伙伴云API对接
字段映射配置 · 数据同步Task
真实数据跑通交期试算
Day 10 · 集成验证 🎯
端到端: 自然语言 → 交期试算 → 甘特图
响应时间 < 5 秒
Demo给内部团队
关键技术风险与应对
每个已知风险都有降级方案 — 没有单点故障可以让系统完全不可用
| 风险 | 概率 | 应对策略 |
|---|
| OR-Tools 复杂场景求解超时 |
中 |
10秒超时 → 自动降级贪心；瓶颈优先降低问题规模 |
| Claude API 中国访问不稳定 |
中 |
国产模型降级（通义千问/智谱）；缓存常见意图分类结果 |
| 伙伴云 API 变更或限流 |
中 |
适配器层解耦；本地全量缓存降级；监控API调用成功率 |
| 甘特图自研工期超预期 |
中 |
Phase 0 先做只读（简单得多）；拖拽交互 Phase 1 再加 |
| 多租户数据隔离出bug |
低 |
中间件强制注入tenant_id；单元测试覆盖跨租户访问 |
| LLM 幻觉导致排产建议出错 |
中 |
LLM 只做翻译不做计算；所有方案由引擎产出；PMC必须确认 |
核心原则
用最少的技术复杂度，最快地把核心价值 — 交期试算 + AI对话 — 交付到PMC手上