复杂系统不是"写一段代码"，而是多个互相依赖又边界清晰的模块。把它们全塞进一个长会话，必然踩坑：
| 坑 | 现象 | 代价 |
|---|---|---|
| 上下文爆炸 | 模块越多会话越长，早期定的硬约束被"挤"出注意力窗口 | 新代码违反旧约定，互相打架 |
| 重复犯罪 | "昨天刚纠过：搜索框开好友会开错"——下一轮又犯 | 反复返工，信任崩塌 |
| 无法并行 | 一个长会话只能串行思考，多个模块不能同时进行 | 周期拉长 2~3 倍 |
这三个坑的本质是同一件事：上下文没有隔离，责任没有拆分。
核心思路——把"总验收 / 总集成"和"单模块执行"拆成两个角色，用独立会话隔离上下文：
个微客服系统按"读 → 库 → 决策 → 发 → 编排"切成 6 个业务模块 + 1 个公共基座，依赖严格单向：
| 模块 | 职责 | 复用组件（版本锁） |
|---|---|---|
| M-F 基座 | LLM 接入 / 版本装配 / 配置 | dashscope-llm-stream v1 |
| M-A 感知读取 | 打开好友→红点判定→增量读→分类→入库 | open-contact / reddot v3 / bubble-classify v2 |
| M-B 语料与规则 | 库 schema / 去重 / 规则挖掘 + 知识库建设 | db-dedup-repair v1 |
| M-C 决策预警 | 回复决策 + 预警闸（强弹窗/暂停） | llm_client |
| M-D 自动回复 | 红点直点→IME 英文→粘贴→回车→验证 | wechat-auto-reply v2 |
| M-E 编排 | 人机入口 + 端到端串联 | 装配上述 |
每张卡固定 5 字段，最关键的是「已知坑」——把历史上踩过的雷写进任务，新会话开工前先读它。卡片用大白话命名（如"红点识别升级"），但保留模块编号方便总集成对应。
新会话没有历史上下文，靠两样"唤醒"：
总集成维护一张活看板 HTML（760px / #2f80ed / light，符合品牌规范），每张卡片列：编号 · 名称+模块 · 任务 · 状态 · 待执行。并在桌面放 .url 快捷方式，双击即开。每次核验一个任务，就改它的"状态 / 待执行"两列 + 顶部时间戳——看板永远是最新真相源。
kb_terms，决策路由读 terms，两套表并存——总集成裁决"统一落合约表"即可解。这套方法在个微客服项目跑出的真实状态（看板实时同步）：
| 编号 | 任务 | 状态 |
|---|---|---|
| ① | 给AI换新钥匙 | 已取消 |
| ② | 测微信记录读取（左栏直点已修） | 已完成 待：语音/媒体分类实测 |
| ③ | 红点识别升级（向量检索） | 待执行 |
| ④ | 语料去重+规则挖掘 | 已有报告 |
| ⑤ | 移植知识治理四件套 | 已落地 待：表名对齐 |
| ⑥ | 生成关键词清单给你确认 | 已跑 待：雷总确认流 |
| ⑦ | 测自动回复真发 | 待执行 |
| ⑧ | 预警闸+AI兜底 | 已验收 22/22 |
| ⑨ | 术语库业务路由 | 待裁决 🔴 表名冲突 |
| ⑩ | 端到端一键编排 | 待执行 |
| 适用 | 不适用 | |
|---|---|---|
| 系统规模 | 多模块（≥4）、长周期迭代 | 单文件小脚本 |
| 验证环境 | 需真实环境（如真机微信/数据库） | 纯算法/纯文档 |
| 协作形态 | 你总验收 + AI 分头跑 | 一次性问答 |
收益：① 上下文隔离，错误不跨会话传染；② 模块可并行，周期砍半；③ 进度可视（看板）；④ 知识沉淀为可复用组件 / skill。