discipline/protocols/wish-pool.md
📑 本页目录
协议 · 许愿池（Case 1：需求直接观测通道）
状态：生效（v0.8）· 关联：观测信号谱系（02-foundations §4，陈述偏好）、 测量理论（代理/构念效度）、反身性公理 A6、SPM 子领域划分（RQ-A6） 定位：DSF 第一个需求直接观测通道——用户主动表达的意图，比行为痕迹 （榜单/下载）更接近潜在需求 D(o,m,t)，但属于陈述偏好（有系统性偏差）。
1. 学科定位
- 许愿池把「需求」从被动观测（榜单、下载、搜索）变成主动表达： 需求者说"我要什么"（表象），系统挖"我真正需要什么"（真实）， 开发者看"什么值得做"（供给信号），三方形成闭环。
- 它与 Case 0（ADDO：排序预测）互补：Case 0 预测"哪个领域先被深度改造"， Case 1 观测"此刻人们在表达什么需求"——前者是排序模型，后者是测量通道。
2. 核心对象与符号
| 对象 | 符号 | 定义 |
|---|---|---|
| 愿望（表象） | w_raw | 用户一句话（陈述偏好，含系统性偏差） |
| 需求向量（真实） | v_w | (task, object, context, constraints, value, status_quo) 的操作化构念 |
| 匹配对象 | i | 已有软件/进行中项目（带索引：分类/关键词/子领域/证据） |
| 匹配分 | m(w,i) | α·语义 + β·领域命中 + γ·关键词 + δ·时新性 + ε·证据 |
| 供给缺口 | gap(w) | 对 w 无 m 达标的 i → 缺口信号（对开发者的机会清单） |
| 愿望状态 | s(w) | open → claimed → in_progress → fulfilled / deprecated |
| 实现追踪 | τ(w) | 愿望 → 被实现/被替代/放弃 的观测（前瞻计分的地面真值） |
3. 深层需求挖掘（表象 → 真实）
- 动机：w_raw 是陈述偏好，用户说不清/说不准/受情绪影响； v_w 才是可匹配、可路由、可预测的构念。
- 方法栈： 1. 结构化追问（≤4 题渐进式：任务/对象/场景/现状/痛点）； 2. 痛点映射：w → 领域/子领域/痛点（pain_points.yaml）； 3. 类比检索：相似已实现需求补推断约束（标注"推断"）； 4. LLM 解析：意图提取 + 归一问（复用 chat 接入）。
- 测量纪律：推断字段标注；v_w 版本化；愿望实现后回看初始向量 （构念效度：初始 v_w 与实现的软件功能是否一致）。
4. 匹配与路由（模型 v0.2）
- 索引：趋势雷达 App 库（窗口聚合：热度/名次/首现/口碑，v0.2）+ 子领域签名 （subdomains.yaml）+ 项目动态（认领后）+ 未来 GitHub/arXiv。
- 匹配分：m(w,i) = β·领域命中（硬过滤） + α·语义关键词覆盖
- γ·关键词覆盖 + δ·时新性 + ε·证据（热度/口碑）。
当前权重 0.15/0.30/0.20/0.35（
wishpool.match_weights）；α 由 LLM 深层挖掘生成语义关键词，未配置 DeepSeek 时回退触发词/标签。 - 缺口证据层（v0.2 新增）：区分三类缺口，避免把"索引盲区"误报为"市场真空"——
index_gap：同分类已有 AI 应用但未命中签名 → 补登记子领域后重匹配；ai_gap：分类市场存在但无 AI 应用 → AI 化供给缺口（开发者机会）；market_gap：相关分类也无应用 → 真真空/新生需求。 每类缺口附证据（相关分类 / 相关 App 数 / AI 应用数 / 样例）。- 动态呈现：同一软件对不同 v_w 的解释按命中维度生成（子领域/关键词/ 热度/口碑）——"文档不静态，按需求呈现"（用户需求：不是一成不变的文档）。
- 路由：gap(w) 的愿望按 SPM 子领域路由给相关开发者 （愿望量聚合 = 需求热力图 = 出生检测的领先指标）。
- 评价：推荐接受率、愿望→实现 hit@k、匹配解释有用性（H12 用）。
5. 双边激励（为什么愿意用）
- 需求者：表达成本低（一句话）+ 即时回馈（马上给最接近的软件）+ 进度可视化（状态机）+ 被听见感（认领=信号）+ 认知收益（追问帮想清楚）
- 同求聚合（"x 人同求"）。
- 开发者：免费市场调研（真实需求语料）+ 冷启动验证（愿望量=领先指标）
- 竞争情报（同求数+覆盖度）+ 种子用户锁定（认领→第一批用户）+ 声望系统（解决数/好评/徽章）。
- 冷启动：先靠"推荐已有软件"让需求侧跑起来（不需要开发者）， 愿望量积累后供给侧进入。
6. 质量与防垃圾
最低门槛（一句话+领域标签）→ 轻承诺（可选"3 天内会用"）→ 相似聚合（同簇连通分量，"x 人同求"）→ 闭环确认（实现后需求者确认）→ 声望惩罚（认领无进展衰减）。写操作使用管理密钥/开发者 token；公开页只读。
7. 可证伪假设
- H11 愿望前瞻性：愿望涌入量是未来软件供给/实现的前瞻代理 （愿望量 → 未来 3-6 个月实现的 hit@k 显著高于随机）。
- H12 深层挖掘效度：需求向量匹配的推荐接受率 > 原话直接匹配。
- H13 认领-转化：认领愿望的需求者转化率显著高于非认领流量。
8. 与学科公理的关系
- A1 潜在性：许愿池把 D 从不可观测变成"有偏差的观测"，偏差由 挖掘流程显式校正（这正是测量理论的第一块基石）。
- A6 反身性：愿望被开发者看到 → 供给改变 → 需求被预测改变 （Goodhart/自我实现）。愿望池必须追踪二阶效应 （wish_events：谁看到、谁点赞、谁认领、什么时间）。
- A3 层次性：愿望按 SPM 子领域路由，父-子聚合一致（领域 → 子领域 → 愿望）。
9. 落地
- 工程原型：
app/forecasting/wishpool.py+scripts/forecast.py wish（愿望登记 → 需求向量 → 匹配现有 App 库 → 缺口输出）。 - 示例库：
knowledge/wishes.yaml（先做 6-8 个真实形态示例愿望）。 - 详细产品设计：docs/09-wishpool.md。
10. 运营节奏（Round 12 增补）
- 用户画像：默认非专业人士——对外措辞大白话，评估口径为"能否完成任务"。
- 新需求评估（提交时）：合并评估（同需求簇+文本相似度 → 建议合并）、 已实现评估（复用匹配层）、可行性评估（难度/能力基础/同求/市场，仅缺口时）。
- 月度复盘：
scripts/forecast.py wish-review [--queue-email]每月过一遍 愿望状态；有进展或匹配到产品 → 给留邮箱的用户排队通知（出站队列data/outbox.jsonl，SMTP 见WISHPOOL_EMAIL_SETUP.md）。