rion-wu-tech 微信个人情报库
Mission
把本地微信记录转化为可核查、可执行的个人情报。优先回答：发生了什么、和当前用户有什么关系、现在该做什么、依据是哪条消息。不要只生成更长的摘要。
Non-Negotiables
- 只读微信。不得发送、回复、转发、加好友或自动操作微信；回复内容只能作为本地草稿。
- 原始聊天、联系人和未公开商业信息只留在本机。不要发送给外部搜索或云端研究服务。
- 以原消息为证据。区分
已确认、高概率、待核实，不得把转发者自动认定为品牌方或组织者。 - 最新、现在、刚刚、今日等请求必须先刷新相关数据。索引过旧或采集失败时，明确说明覆盖缺口，不得把“没采到”写成“没有”。
- 用户未给时间时默认过去 24 小时；用户给出时间范围时严格使用该范围。
- Deal Radar 是微信个人情报库中的商业模块，不是整个产品名称。
项目目录优先读取 WECHAT_HUB_HOME；未设置时由入口脚本从当前目录、常见安装目录和用户 Documents 目录中自动发现。
个人姓名别名、重点微信标签和交付群识别词优先由 WECHAT_HUB_PROFILE 或项目内 config/profile.local.json 提供。不要把某个用户的名字、联系人、排除群或商业偏好写死进 Skill 或开源核心；无个人 Profile 时使用公开默认配置。
First-Run Personalization
首次真实数据接入或读取失败时，先由 wechat-cli 运行 access-plan 并按其接入指引处理。安装成功、个人Profile就绪和数据库可读是不同状态；缺key时不要继续空跑日报，也不要把通知预览冒充完整历史。现有配置可读则直接复用，不重复获取key。
首次安装、profile-status 返回 needs_context，或用户的月度/季度重点明显变化时，读取 references/onboarding.md。优先使用用户已有的个人说明、人生使用说明书、OKR 或当前计划等本地文档；没有时生成准备清单，不要假装已经了解用户。用 profile-init 把重点方向、个人关键词、自定义行业主题和本地文档路径写入私有 Profile。
主动建议用户在微信中按自己的关系和工作流建立 2–5 个标签，例如客户、同行、渠道、供应商、自媒体网友或品牌方。这些名称只是示例，不是公共默认工作流。可以只读列出现有标签并给候选建议，但不得自动修改微信标签，也不得未经确认猜测标签含义。
完整多会话时间范围报告运行前检查个性化状态。24/48 小时只是常用窗口，也可以按用户指定的一天、一周、一个月或明确起止日期处理。状态未就绪时仍可用通用维度生成报告，但要明确提示排序尚未结合个人目标；精确关键词与全微信搜索不得受标签限制。
统一命令入口：
"${CODEX_HOME:-$HOME/.codex}/skills/wechat-intelligence-hub/scripts/hub.sh" <command> <args>
需要拼装具体命令时读取 references/commands.md。分析商单、培训、附件、角色和任务状态时读取 references/signal-rules.md。
Delivery Router
默认使用 delivery=auto，根据请求选择直接文字、Markdown 或 HTML。单个联系人、单一品牌/项目/事件、关键词核实和回复建议通常直接在 Codex 回答，不为定制问答生成 HTML。完整多会话日报、周报、月报、指定时间段报告或明确要求网页的定向调查，默认保存短 Markdown 入口和完整分区 Markdown，并从本轮报告目录生成旗舰版交互 HTML。详细规则见 references/delivery.md。
wechat-cli 的原始输出和本 Skill 的机器初筛是证据层，不决定交付形式。不要为了给用户一个文件而扩大扫描范围，也不要把文件路径代替结论。
Intent Router
选择满足请求的最窄入口；复合请求才组合多个入口。
| 用户意图 | 首选入口 | 关键动作 |
|---|---|---|
| 不知道如何使用、查看首页 | home |
展示五入口和当前状态 |
| 过去 24/48 小时发生了什么 | group-daily + contact-daily + brief |
刷新近期群聊、私聊和重点标签；分别生成群聊日报与重点联系人日报，再给短行动总览 |
| 指定日期范围发生了什么 | group-daily + contact-daily + brief |
将范围转换为明确 since / until，确保索引和各报告使用相同边界 |
| 某条信息、产品、物品、项目或事件的来龙去脉 | chat-search + topic |
先用名称、别名和关键词定位，再读取命中上下文并按事件时间线去重总结 |
| 某个微信标签中的联系人进展 | wechat-labels + db-index --scope labels + contact-daily |
用标签限定联系人范围，再按用户指定时间和任务汇总；不得修改微信标签 |
| 今日微信群日报 | group-daily + 语义编辑 |
扫描指定窗口；先按真实话题/事件归纳，再按群追溯上下文 |
| 品牌方/中间人/自媒体博主私聊日报 | contact-daily |
单独汇总重点私聊，区分待回复、等待对方和留意，并给回复方向 |
| 某主题在所有聊天里出现在哪里 | topic |
已有索引不足时先做定向实时搜索 |
| 我和某人聊到哪、承诺了什么 | person |
涉及最新进展时加 --refresh |
| 某人刚回复、我该怎么回 | person + reply |
先核对最新原文和最后发送者，再按关系生成一条短草稿；详见 references/reply-style.md |
| 查看某个联系人或群的原始上下文 | chat-history |
限定联系人、日期和关键词 |
| 搜索全部微信里的精确关键词 | chat-search |
实时搜索并将命中写入本地库 |
| 搜索已经索引的历史记录 | db-search |
快速本地检索，不声称覆盖未索引聊天 |
| 商单/培训/合作/赚钱机会 | brief + opportunities |
同时检查自然对话、附件和链接信号 |
| 跨群重复链接、推广链接 | db-links |
每个链接只聚合一次并列出出现群 |
| 今天先处理什么 | today |
最多 10 项，按真实紧迫度排序 |
| 新发现的高优先级线索 | inbox |
作为候选，不直接称为真实商单 |
| 某品牌/中间人是否值得复联 | reactivation |
只把已经到期的候选列为今天动作 |
| 两人是否在共同群、是否交接 | common-groups |
用成员 ID 核实，不靠短昵称猜测 |
| 查看或更新合作进度 | opportunities / opportunity-update |
持久化管线是状态来源 |
| 清理长期未确认候选 | opportunity-maintain |
默认只预览；确认后才 --apply 标记过期 |
| 用户纠正误报、假商单或低优先级 | feedback-add |
立即持久化纠正 |
Execution Protocol
- 定窗口：把“最近、今天、过去几天”转换为明确起止时间；未指定则用 24 小时。
- 查新鲜度：运行
db-status。最新请求刷新近期private,group；涉及个人 Profile 中的重点标签时同时刷新标签联系人。 - 验证读取通道：若微信版本变化或读取失败，运行
compat-check。失败时继续分析已有索引，但标注截止时间和缺口。 - 执行最窄检索：先联系人/主题/时间过滤，再扩大到全微信；不要为一个联系人问题扫描全部历史。
- 补附件上下文：高信号消息旁有图片、文件或语音占位符时，尝试读取媒体；失败则标为
附件待核实。 - 对齐持久状态：摘要负责发现，
opportunities负责当前阶段。不要用一份旧日报覆盖人工确认过的状态。 - 去重与归因：相同链接或同一轮推广只出现一次；分别标记原始发布者、转发者、中间人、品牌联系人和纯加热者。
- 转成行动：区分我方待回复、我方待兑现、等待对方、临近截止、发布后数据义务和待结算。
- 保留控制权：金额、日期、身份、承诺完成、机会输赢和对外回复必须由用户最终确认。
Reply Suggestions
需要生成回复时读取 references/reply-style.md。默认先判断是否需要回复，再根据当前联系人的关系和双方已有语气生成一条简短草稿。不要默认给“推荐版、简短版、争取时间版”三套模板，也不要把一两句微信扩写成方案书。
个人语言习惯使用当前安装者最近 30 天跨联系人私聊的聚合特征，不限于重点标签；当前会话的称呼、语气和关系证据优先于全局习惯。没有配置本人昵称或样本不足时使用中性草稿，不冒充已经学会。原始聊天和学习结果只留在本机，开源包不得携带任何维护者或使用者的个人数据。
Group Digest Delivery
运行 group-daily 后，group_daily_digest.md 只是可复现的机器初筛，不能直接作为最终答复。必须读取同目录的 group_daily_editorial_packet.json，按 references/group-editorial.md 完成第二遍语义编辑，生成 group_daily_topics.md 和 group_daily_groups.md。group_daily_brief.md 仅作旧版兼容入口，不再是唯一群聊交付。
最终答复优先展示语义编辑后的报告。正式群聊日报保留两种阅读方式：话题日报 按真实项目、事件和问题跨群组织；重点群聊 按有信息增量的群追溯上下文。两份 Markdown 分开交付，不使用 HTML <details> 塞进 Markdown。必要证据以 [群名｜时间｜发言人] 和必要原链接就地放在日报中；附录和机器初筛只在本地保留供核查，不作为用户阅读入口。
完整复合日报还要生成 group_selection_matrix.md/json/csv，覆盖本时间窗内全部活跃群。筛选维度至少包括：活跃度、AI、赚钱、培训、商单、出海、产品、Web3、自媒体运营与增长、合作、B 端 AI 赋能。HTML 的群聊页提供第三种“群聊筛选”视图，允许搜索、按维度过滤、调整 重点 / 雷达观察 / 关注 / 低优先级 / 排除候选 并导出选择。浏览器选择只保存在本地，不得自动写入永久排除配置；需要由用户确认后再更新个人 Profile。
低价值娱乐/闲聊 与“本时段没有可读信息”必须分开：前者需要群名或讨论内容确实以生活、运动、娱乐为主且没有当前目标信号；后者只能标为窗口内信息不足，不得据此永久降级整个群。个人筛选基准应读取最新人生计划或 Profile；无个人上下文时使用公开默认维度。
复合日报在群聊与私信语义编辑完成后，必须对本轮运行目录执行 render-bundle。wechat_daily_report.html 只保留四个顶层功能：综合行动报告、群聊日报、重点联系人、商单信号雷达。群聊日报页面内可切换“话题日报 / 重点群聊 / 群聊筛选”；重点群聊在 HTML 中点击群名展开细节，但 Markdown 仍保持干净的分区正文。不在 HTML 中单列证据附录、机器审计或其他杂项。只有用户明确要求调试时，才把 CSV、JSON 或机器初筛作为主要交付。
如果群内已有成员发布文字或图片日报，只把它放入独立的“群内已有日报”索引，不得再当作主题、关键发言、商机或行动证据。文字日报按标题识别；图片日报通过 Profile 中的 group_recap_senders 和可选 group_recap_time_windows 限定，需要看原文时再定向读取媒体/OCR。
跨群重复链接继续保留在 cross_group_links.md 和商单信号雷达页：每个标准化 URL 出现一次，列出相关群、发布者和判断依据。群聊日报只在相关话题或“商单雷达链接”中放一次必要 URL，不得按出现群反复粘贴。
“红包、三连、四连、已加热、截图结算”等纯互动协调只是投放雷达证据，不是群聊话题，不进入重点群聊。只有同条消息同时出现明确品牌/项目、招募、预算、名额、brief 或截止时间时，才保留其实质合作内容。
contact-daily 是独立的关系推进日报，不混入微信群日报的 Markdown 正文。用户请求某个时间范围内的群聊和重点联系人私信时，必须先分别生成两份语义报告，再用短总览合并最重要的行动；综合 HTML 可以将两者作为独立栏目放在同一阅读器中，但不得把私信逐条塞进群聊栏目。当 Profile 设置 contact_daily.scope=priority_labels_only 时，重点联系人页只收录 labels.priority / commercial / creator 中的微信标签联系人；其他人的商业信号仍可进入全微信检索、群聊雷达和商机库，但不占用该页主列表。
Commercial Reasoning
- 商单既可能藏在跨群链接和红包加热中，也可能只出现在自然对话、私聊、接龙、剩余名额、预算、brief 或转介绍中。
- 培训、咨询和项目合作通常没有链接。重点检查自然对话以及相邻图片、文件和语音。
- 不因“没有链接”降级培训/项目机会；不因“出现链接”就认定为商单。
- 万粉以上博主参与付费加热是强信号，但只证明该内容可能是推广，不证明他是品牌对接人。
- 小型交付群、对接群、初稿/终稿群按直接商业会话处理，不按普通资源群处理。
- 详细分类、反例和阶段语义见 references/signal-rules.md。
State And Corrections
opportunities是合作进度的唯一持久状态来源；日报和搜索结果只是证据或候选。- 自动发现先进入
candidate；明确私聊交付证据或人工分流后才成为opportunity。候选默认 14 天无新证据后进入stale，不删除原始证据。 - 用户确认推进、等待、暂停、忽略、成交或失败后，使用
triage或opportunity-update记录。 pursue / wait / won / ignore会同时把针对该机会键的反馈持久化，避免相同判断只留在当前对话。wait必须有明确跟进日期；没有日期时先保留为待确认，不擅自编造。- 用户说是假商单、测试、无关群或低优先级时，用
feedback-add或排除名单持久化，不要只在当前回答里记住。 - 如果安装了外部商业管线，用户确认
pursue或wait后先 dry-run 导入；只在预览匹配后正式导入。微信库继续作为聊天证据源。 - 删除历史输出先运行
cleanup预览；只有明确确认后才能加--apply。
Output Contract
按下面顺序输出，跳过空栏目：
- 覆盖范围：明确时间、索引新鲜度、扫描了群聊/私聊/标签中的哪些部分，以及缺口。
- 立即处理：最多 10 项。先列逾期或临近交付、明确询价、品牌新回复、发布后义务和结算。
- 商单机会：链接型和自然对话型合并去重；说明项目、联系人、角色、证据和下一步。
- 培训/咨询/项目合作：独立栏目，不与商单链接混在一起。
- 等待与复联：标明谁在等谁、何时跟进；未到期提醒不冒充今日任务。
- 主要话题与事件：按真实项目、事件、问题或争议聚类，说明发生了什么、涉及哪些群和人、为什么值得关注；不得用“AI 产品/模型”等宽泛标签代替总结。
- 按群追溯：每个值得阅读的群先写一句编辑判断，再列群内大事、结论/分歧、行动和证据。群聊是来源导航，不得替代跨群话题综合。
- 重点联系人私聊：仅在复合日报中给短行动总览，并链接独立私聊日报；不得把私聊逐条塞进群聊栏目。
- 报告路径：只展示当前交付模式对应的最终产物；必要证据就地附在相关结论下，不单列用户面向的证据附录，也不粘贴大段原始聊天。
group-daily 中，同一跨群链接只在链接聚合区出现一次并列出相关群；不要再按出现群重复复述。未经人工分流的 new 候选必须标成“待审核”，不得和 active / waiting / paused 的正式机会混在一起。
每项建议必须解释“为什么与当前用户有关”。回复话术要自然、简洁、贴合用户已有对话语气，不虚构案例、报价、名额或关系。命令部分失败时继续处理其余数据，并清楚列出失败范围。