🦞 2026-06-01 记忆
Monday

大麦让我按 SOP v3.75 手动执行进门早间（一）16 轮扫描。实测 2 轮后上下文爆了——每轮 MCP 返回 100 条完整原文（约 20-30 万字符/轮），16 轮 ≈ 480 万字符，远超单 session 上下文上限。

v3.75 的 16+18 轮串行扫描设计是为 cron 子进程（context=isolated，每轮搜完落盘就忘）准备的，不适合手动直接对话执行。但更深层问题是：即使 cron 子进程串行 16 轮，总耗时 48 秒也不够高效。

• 架构：从串行轮次 → 每关键词一个子进程并行（8/9 个子进程同时跑）
• 超时：主扫子进程 240s，深挖子进程 180s（不变）
• 间隔：进门财经 4s，Alpha派 8s（Alpha派用 Python 脚本调 API，无 MCP 网关限流风险）
• 摘录规则：四级信号分级——硬信号不设限 / 定性保留逻辑链 / 纯方向压缩 / 去重合并。数字穷举独立于摘录
• 去重机制：必须在主进程收齐全部子进程事件簿后统一执行（子进程无跨词视野）
• 事件簿格式：标准化 JSON，11 字段（eventId/chainSegment/title/source/time/excerpts/coreChange/keyNumbers/variables/isNew/needDeepDig/deepDigKeywords/grade）
• 可核实：三层索引——eventId → 关键词级事件簿 → 原文片段 / raw 文件

模板 B（Alpha派）写"规则与进门财经完全相同"——子进程 context=isolated，看不到模板 A，这句话对子进程无意义。修复方案：两个模板各自完全自包含，6a-6d 规则和 JSON 格式在两个模板内完整重复写出。约 80% 内容相同但必须各写一遍。

• 新 SOP 文档：v3.76，https://jcnkfj0yixa1.feishu.cn/docx/IvXIdj35ioy1nYxU43Mcicldne9
• 位置：「其他」文件夹（DamIfN946l8SccdzCfTcBLPvnDh）
• 验证：55,962 字节，全文完整，零表格
• Cron 更新：8 个 Cron 全部指向新文档 + v3.76 架构指令

• 子进程 Task 必须完全自包含：不引用任何外部上下文（其他模板 / SOP 章节 / 变量），所有规则完整内嵌
• 去重必须在主进程：只有主进程能看到全部子进程事件簿的全貌
• 数字穷举独立于摘录：即使用原文段落被压缩，所有数字必须全部提取
• 硬信号不设摘录上限：新订单/新客户/新涨价/新产能/新认证/新产品量产 → 原文段落完整保留

• 8 个 Cron 已更新但尚未经过首次实际跑验证。今晚晚间扫描（20:50/20:59）将是 v3.76 架构的首测
• 如果子进程并发遇到 429，可能需要按 batched 4+4/5+4 分两批，但先让 8/9 并发跑一次看结果