| name | wechat-intelligence-hub |
| description | WeChat Intelligence Hub(微信个人情报库),本地只读微信情报 Skill。用于按任意明确时间范围,或围绕某条信息、某个人、某个群、某个产品/物品、某个微信标签、某个项目或事件检索和总结微信聊天;也用于生成群聊与私聊报告、发现并跟进商单/培训/咨询/项目合作、聚合跨群链接、检查待回复和待兑现承诺、维护商机状态及筛选值得复联的人。Use whenever the user invokes 微信个人情报库、WeChat Intelligence Hub、微信商单雷达、Deal Radar,或询问某人/某主题/某件事聊过什么、最近微信有什么新机会、谁需要回复或复联。 |
微信个人情报库
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 项,按真实紧迫度排序 |
| 新发现的高优先级线索 | |
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 的正式机会混在一起。
每项建议必须解释“为什么与当前用户有关”。回复话术要自然、简洁、贴合用户已有对话语气,不虚构案例、报价、名额或关系。命令部分失败时继续处理其余数据,并清楚列出失败范围。