产品与技术架构图 — 小澜

笔记侠 FDE 加速营 · 电商赛题 A · 澄野商业 CHENGYE × 澜序 LANSU · 2026-08-04

第一使用者

营销团队人群 / 内容负责人

不是 CEO，也不是数据分析师。公司没有专职分析师，业务人员就是第一道分析。

使用节点
节点频率期望产出
周一早会前每周翻上周历史卡片，或拖新文件问一个问题
大场直播复盘每场后这场触达到谁了、和目标人群差多远
被 CEO 追问时不定打开工作历史 → 找到那张卡 → 复制 → 发群
月度选品 / 内容策划每月拖多份文件，跨表交叉验证人群假设
系统预置数据（离线清洗后入证据库）
M1 抖音成交 / 投放（口径不一）
M2 直播人群画像切片（入库 23 场）
M3 客服月报 + 客户之声样本
M4 订单底表 / 工单 / 补发
M5 五类专家访谈摘要 → hypotheses 表
M6 口径 / 来源 / 权限规则
M6 不作为证据表入库——它被吸收进 metrics.yaml 的口径定义与 ingest.py 的清洗规则 （「分」单位字段、M4 履约口径、M3 无法抓取全量的确认）
主动数据（运行时拖入）
用户拖入的 xlsx / xls / xlsm / csv
外部行业报告（P2 预留）
文件拖入 → parse_excel → 结构摘要（列名 / 粒度 / 警告，不含数据行）→ 会话临时 DuckDB，任务结束即释放
⚠️ 上传数据默认不写入系统预置证据库，按会话使用
→
数据处理与证据化
预置数据：离线清洗后进入证据库，每个数字挂 evidence_id
上传数据：运行时解析、识别结构并进入会话临时库
受控聚合、口径检查与 evidence_id 追溯
M1–M6 规则用于边界校验和降级
⚠ 32 个指标零个来自 M5；专家观点只进 hypotheses，verified=false
核心数据流 · 一次工作 = 一张卡
DuckDB 证据库
+ metrics.yaml
32 指标 · 每指标带公式 / 来源 / 边界
→
Agent 层
deepseek-v4-flash
5 工具 · ≤3 轮 · strict FC
选题 / 归因 / 措辞
→
validator.py
四条校验硬拦截
不过 → 丢弃 + dropped_count
多张 → 只留最强
→
观点卡
+ 工作栏面板
可信度 / 洞察 / 注意事项 / 证据
⚠ LLM 全程接触不到原始数据行，只看到摘要 + ≤50 行聚合结果 + 按 ID 调取的有限证据
旁路一：追问 —— 独立轻链路，不重跑分析
卡片上点「追问」
→
POST /api/chat
src/chat.py
→
卡片上下文够 → 直接答
／
要查历史数据 → 只给 1 轮工具
→
答案落在卡片下方
刻意不做什么为什么
不过证据校验层、不产出新卡、不进工作历史追问的产出是一段话，不是第二张卡
默认关思考模式（实测 14s → 2.5s）对方在等你说话，不是在等一次新分析
工具只给 query_metric / query_table / search_voc / get_evidence，单轮 ≤4 次不许重新解析上传文件——那要几十秒，正是追问最不能忍的慢
不许自己加减乘除、不许编来源与主链路同一条铁律
旁路二：速度控制 · 鞭子
点鞭子 → /api/whip 为下一次任务排队快速模式， 真的会改后端 thinking 参数——只播加速动画而参数不变，视为未完成。
快速模式减什么一步不减什么
工具调用轮次腰斩
（少思考、少探索）		文件解析
证据校验
置信度重算
⚠ 代价必须明示：快速模式约 1/3 概率交白卷 → 自动重试一次； 但 dropped>0 与 data_gap 绝不重试
五个工具
工具用途调用耗时
parse_excel解析上传文件 → 结构摘要 + 落临时表1–2 s
query_metric查预置口径指标；违反口径返回错误~0.00 s
query_table通用聚合，limit 硬上限 50~0.00 s
get_evidence根据 ID 取原始出处~0.00 s
search_voc检索 M3 原声 + M5 观点，带 reliability~0.00 s
DuckDB 查询几乎全是 0.00 s · 所有优化空间都在 LLM 侧
五类陷阱 · 代码层规避
材料题面陷阱代码拦截
M1口径 / 单位不一；停播日；异常 ROI分模块口径；剔除进 excluded 表
M2三组人群不嵌套，不能相除ForbiddenCalculationError
M3人工归纳，缺全量原始记录sample_only；置信度上限 low；不提供比率
M4商品行 ≠ 订单数；金额重复COUNT(DISTINCT 主订单号)
M5专家局部真相、相互冲突32 指标零个来自 M5；引用写「某专家认为」
AI 与人的分工
环节谁负责代码位置
数据清洗 / 口径对齐代码src/ingest.py
指标计算（32 指标）代码metrics.yaml + src/tools_impl.py
异常检测代码src/metrics.py
证据校验（四条硬拦截）代码src/validator.py
置信度定级代码打底，AI 只能下调validator.min_confidence()
边界补全（注意事项）代码src/validator.py
选题 / 归因 / 措辞AIDeepSeek function calling
最终经营决策业务人员Agent 明确不做决策
Agent / Skill 分工
Agent职责
数据管家
ingest / parse_excel / query_metric / query_table		清洗、口径对齐、算数、打证据 ID
老板对话
DeepSeek function calling (strict beta)		选题、归因假设、措辞、卡片生成
证据审计
src/validator.py		四条校验硬拦截 · AI 无权绕过
多张只留最强 · 不计入 dropped_count
技术栈
层用什么
桌宠Tk 透明无边框 + tkinterdnd2 + Pillow
工作栏pywebview 独立进程 + 原生 HTML/CSS/JS
后端Python + FastAPI（桌宠自起 uvicorn，随机空闲端口）
数据pandas + openpyxl + DuckDB 单文件
LLMdeepseek-v4-flash · function calling · strict beta
降级路径（五种，全部可跑）· 宁可少说，不可错说
⚡ llm_unavailableDeepSeek 挂 / 超时
→ 模板卡片
证据链不少，无归因
🚫 all_dropped全部洞察未过校验
→「本轮未产出可信洞察」
+ 原始异常 + 丢弃原因
❓ out_of_scope问题超出数据覆盖
→「当前数据无法回答」
+ 需要补哪份数据
📭 data_missing某材料不在证据库
→ 列出缺哪张表
相关卡片不生成
💥 system_error分析链路自己崩
→「系统内部出错」
不伪装成数据不足
五种说法互不伪装 —— 系统崩了就说系统崩了，不会说成「数据不足」
反馈回路： 一开始 LLM 对 M2 三组人群做了跨组相除 → 代码层增加 ForbiddenCalculationError 硬拦截，谁除谁报错。 外加白卷自动重试；search_voc 关键词无命中时回落 + 显式警告。 这是 AI 原生做法——让 AI 进核心分析链路，不是给旧流程加聊天插件。