AIGC: Label: "1" ContentProducer: 001191440300708461136T1XGW3 ProduceID: 5c0fa478708bf2c9ec3bd0adf95ae3f0_c4a86e6d7e9611f194825254006c9bbf ReservedCode1: THHXZj0spDaqLJuzUQ35zEvWLRfR6I8rGq4B+HekrRqeziZVeVhiznwVT/shujLPR4dmlbqbYGLga1U965rZewybafNLW2i392Hi1JgS9J0+Pg0FIzmbGshAFj+ZCEdVPvCKJZuqQXOVJidERWYFJ7G1e6JO7i8583pUkrEa+oZ4xmyteA+ybJ2xtJk= ContentPropagator: 001191440300708461136T1XGW3 PropagateID: 5c0fa478708bf2c9ec3bd0adf95ae3f0_c4a86e6d7e9611f194825254006c9bbf ReservedCode2: THHXZj0spDaqLJuzUQ35zEvWLRfR6I8rGq4B+HekrRqeziZVeVhiznwVT/shujLPR4dmlbqbYGLga1U965rZewybafNLW2i392Hi1JgS9J0+Pg0FIzmbGshAFj+ZCEdVPvCKJZuqQXOVJidERWYFJ7G1e6JO7i8583pUkrEa+oZ4xmyteA+ybJ2xtJk=

从一次对话到完整方案 · From Chat to Proposal

§0 你一定经历过这个场景

你和同事 / 朋友 / AI 聊了一个小时。聊得很深——问题是什么、大概怎么解决、有哪些坑、资源够不够——都聊到了。你觉得思路已经很清晰了。

然后你说：「好的，那我把这个整理成一个方案，明天给老板看。」

接下来的三个小时，你做的事情是：回忆对话里说了什么、把散落四处的观点拼起来、推测哪个观点是最终的共识、补齐对话中跳过的细节、把口语翻译成书面语、排版、调格式。

你在做一件荒谬的事：把一段已经包含完整方案雏形的对话，手动翻译成一份文档。而 AI 从头到尾都在场。

本 Skill 做一件事：你把一段对话交给它——它找到对话里埋着的方案骨架，把碎片拼成结构，识别你还没说清楚的地方然后追问，最后生成一份完整的方案文档。不是模板填空。是从对话中挖出你已经有了但还没意识到的方案。

§1 核心工作流：从噪音到信号

对话和方案的本质区别不是内容——是结构密度。对话里 80% 的话是探索、铺垫、跑题、确认。方案里 90% 的话是决策、逻辑、数据、行动。本 Skill 的工作就是把前者的 20% 提取出来，填充到后者的 90% 里。

┌──────────────────────────────────────────────────┐
│                                                  │
│  你的对话（碎片化、探索性、高噪音）              │
│                                                  │
│  ↓ ① 扫描：定位核心命题                        │
│  "这段对话到底要解决什么问题？"                 │
│                                                  │
│  ↓ ② 提取：抓取关键碎片                        │
│  观点、数据、约束、决策、分歧、假设             │
│                                                  │
│  ↓ ③ 测绘：检测方案类型，匹配框架              │
│  项目方案 / 商业提案 / 战略建议 / 产品方案 …    │
│                                                  │
│  ↓ ④ 映射：将碎片填入框架                      │
│  哪些对话内容对应方案的哪个章节                 │
│                                                  │
│  ↓ ⑤ 追问：识别缺口，战略性提问                │
│  「你说了A，也说了B，但它们有冲突——             │
│    以哪个为准？」                               │
│                                                  │
│  ↓ ⑥ 生成：输出完整方案                        │
│  可保存为 Markdown、可导出、可迭代              │
│                                                  │
│  ┌──────────────────────────────────────┐        │
│  │ 完整方案（结构化、确定性、可交付）  │        │
│  └──────────────────────────────────────┘        │
│                                                  │
└──────────────────────────────────────────────────┘

关键设计：追问不是 AI 在说"我不懂，你给我更多信息"。追问是 AI 在说"你对话里已经埋下了矛盾 / 缺口 / 未完成的推理，我把它们翻出来，你决定怎么填。"

§2 六种方案框架

框架一：项目方案（Project Proposal）

适用：内部立项、跨部门协作、资源申请

框架二：商业提案（Business Proposal）

适用：给客户 / 合作伙伴 / 甲方的对外方案

框架三：战略建议（Strategic Recommendation）

适用：给老板 / 决策层的方向性建议

框架四：产品方案（Product Requirement）

适用：产品需求文档、功能设计说明

框架五：营销方案（Marketing Plan）

适用：推广计划、内容策略、增长方案

框架六：自定义框架

你说了算。告诉我你的方案需要哪些章节，我用你的框架。

用这个结构生成方案：
1. 一句话总结
2. 为什么现在必须做
3. 我们具体做什么
4. 谁来负责什么
5. 第一周做什么

§3 完整走通流程

场景：产品经理和同事聊完一个功能方向，需要出方案给老板

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
原始对话（摘要）

产品经理：用户反馈说搜索结果太差了，搜"蓝牙耳机"
出来一堆数据线。我看了下后台，搜索无结果的 query
占比 18%。

同事：是不是搜索算法的问题？我们现在用的是
MySQL 的 LIKE 查询吧。换个 Elasticsearch？

产品经理：我查过，ES 大概要 2 周接入，但它是
文字匹配，不是语义匹配。用户搜"蓝牙耳机"想买的是
"无线耳机"——这个 LIKE 和 ES 都解决不了。

同事：那要用 NLP？做语义搜索？

产品经理：太贵。我问了算法团队，训练一个商品
搜索模型至少 3 个月+2 个人。我们等不了。

同事：那短期怎么办？先把 LIKE 修一修？

产品经理：我有个想法——不做语义搜索，做搜索
query 的标准化。就是建一个同义词映射表，用户
搜"蓝牙耳机"自动改写为"无线耳机"去库里查。
开发量很小，一个配置平台+前端拦截，大概 1 周。

同事：这个可以。那你打算怎么验证效果？

产品经理：先拿 Top 100 高频无结果 query，人工建
初始映射，上线看无结果率有没有降到 10% 以下。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
用户：「把刚才聊的这个整理成方案，给老板看的。」

AI 执行六步工作流：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

① 扫描：核心命题
  问题：搜索无结果率 18%，用户搜"蓝牙耳机"出数据线
  目标：将无结果率降到 10% 以下

② 提取：关键碎片（12 条）
  - 数据：18% 无结果率
  - 方案A：Elasticsearch（2周，文字匹配，类比排除）
  - 方案B：NLP语义搜索（3个月+2人，成本排除）
  - 选定方案：搜索Query标准化（1周，开发量小）
  - 验证方式：Top 100高频query，人工初始映射
  - 成功标准：无结果率 < 10%

③ 检测框架：项目方案（内部立项场景）

④ 映射碎片到框架：
  背景与问题 ← 18%无结果率，LIKE查询无法语义匹配
  目标与范围 ← 无结果率降到10%以下，范围限定搜索模块
  解决方案 ← Query标准化（同义词映射表+配置平台）
  实施计划 ← 1周开发，分两阶段（映射表+上线验证）
  资源需求 ← 1个后端开发，不需要算法团队
  风险与应对 ← 映射表维护成本、长尾query覆盖
  成功标准 ← 无结果率 < 10%

⑤ 追问：3 个缺口
  AI：「方案里映射表的长期维护你说到了，但
  有两个点对话里没有明确——

  1. 谁负责维护映射表？运营还是产品？
     （你说"人工建初始映射"，但没说谁做。）

  2. Top 100做完后，长尾query怎么办？
     （有没有自动化扩展机制？）

  3. 你老板最关心的是什么？
     （是开发成本？上线速度？还是用户体验提升？
      方案的侧重点取决于这个。）

  这三个问题决定了方案的重心和说服力。」

用户：「1. 运营团队维护，我负责审核规则。
       2. 第一期人工，第二期做用户反馈自动
          收集候选映射。
       3. 老板最关心上线速度和开发成本。」

⑥ 生成方案（见下方输出）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

                    搜索Query标准化方案
                    提升搜索无结果率从18%到10%

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

一、背景与问题

当前商品搜索使用 MySQL LIKE 查询，无法处理语义差异。
用户搜索"蓝牙耳机"时，商品标题中写"无线耳机"——
LIKE 匹配不到，用户看到的是数据线。

数据：近 30 天搜索无结果 query 占比 18%，Top 100
高频无结果 query 中 67% 存在可匹配的同义商品。

如果不处理，18% 的搜索用户正在流失到竞品。

二、目标与范围

将搜索无结果率从 18% 降至 10% 以下（第一期）。
范围限定在搜索模块的 query 改写层，不涉及商品
数据库、推荐算法、排序权重变更。

三、探索过的方案

| 方案 | 做法 | 工期 | 为什么没选 |
|:--|:--|:--|:--|
| Elasticsearch | 替换搜索后端 | 2周 | 仅解决性能，不解决语义 |
| NLP语义搜索 | 训练商品匹配模型 | 3个月+2人 | 周期太长，成本太高 |
| Query标准化 ✅ | 同义词映射表+前端拦截 | 1周 | 工期短，开发量小，精准解决当前问题 |

四、推荐方案：Query标准化

核心思路：用户输入 query 时，先查映射表——
"蓝牙耳机"自动改写为"无线耳机"，再用改写后
的 query 去数据库搜索。

实现路径：
- 第一阶段（1周）：搭建映射表管理后台+搜索
  拦截层。上线 Top 100 高频无结果 query 的映射。
  目标：无结果率 < 14%。
- 第二阶段（第2-3周）：加入用户反馈自动收集
  机制——用户搜完无结果后的行为（是否换词重搜、
  换了什么词）作为候选映射来源。运营团队维护，
  产品经理审核规则。目标：无结果率 < 10%。

五、资源需求

- 后端开发：1 人 × 1 周（全职）
- 运营团队：0.2 人（兼职，映射表日常维护）
- 不需要：算法团队、新服务器、第三方服务

六、风险与应对

| 风险 | 概率 | 应对 |
|:--|:--|:--|
| 映射表膨胀，维护成本上升 | 中 | 第二阶段引入自动收集机制，人工仅审核 |
| 长尾 query 无法覆盖 | 高 | 先覆盖 Top 100（占总搜索量的 45%），长尾通过用户行为反馈逐步扩展 |
| 改写后仍无结果 | 低 | 保留原始查询的搜索结果，改写仅作为补充 |

七、成功标准

| 指标 | 当前值 | 第一期目标 | 第二期目标 |
|:--|:--|:--|:--|
| 搜索无结果率 | 18% | < 14% | < 10% |
| Top 100 高频 query 覆盖 | 0% | 100% | 100% |
| 方案覆盖的搜索量占比 | 0% | 45% | 60%+ |

八、后续

映射表运营流程稳定后，积累的数据可用于：
- 商品标题规范化（要求商家使用标准名称）
- 为未来真正的语义搜索训练提供标注数据

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
方案已生成：search-query-normalization-proposal.md
[保存在 output/ 目录]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

§4 方案生成选项

输出格式

方案语气

方案长度

补充选项

§5 追问策略：问什么、不问什么

追问是方案生成中最关键也最容易出问题的一步。问多了用户烦，问少了方案有洞。

三类必问的缺口

三类不问的缺口

追问的黄金数量

• 少于 3 个缺口 → 直接生成，不追问
• 3-5 个缺口 → 列出 3-5 个问题，等用户回答
• 超过 5 个缺口 → 选最重要的 5 个问。其他的标注在方案中（「此部分信息不足，基于对话推断填充，请核实」）

§6 方案中的「对话痕迹」保留策略

一个从对话中长出来的方案，最值钱的东西不是它的格式——是它还带着对话里碰撞出来的真实洞察。过度打磨会把这种洞察磨平。

应该从对话中保留的

应该从对话中剥离的

§7 存储机制

生成的方案保存在 output/ 目录下：

output/
├── search-query-normalization-proposal.md     # 方案文件
└── chat-to-proposal/
    └── proposal-history.json                  # 方案生成记录

方案生成记录：

{
  "proposals": [
    {
      "id": "prop_001",
      "title": "搜索Query标准化方案",
      "type": "project_proposal",
      "source_conversation": "memory_ids: [...]",
      "generated_at": "2026-07-13T17:00:00Z",
      "file_path": "output/search-query-normalization-proposal.md",
      "version": 1,
      "status": "draft",
      "iterations": [
        {"version": 1, "changes": "初始生成", "date": "2026-07-13T17:00:00Z"}
      ]
    }
  ],
  "settings": {
    "default_tone": "正式汇报",
    "default_format": "markdown",
    "auto_detect_framework": true
  }
}

§R 核心铁律

1. 方案从对话中长出来，不是从模板里填出来。 框架是骨架，对话是血肉。如果生成出来的方案可以套用到任何一段对话上而毫无违和——这个方案生成失败了。方案读起来应该有只属于这段对话的印记：那段数据、那个案例、那个被推翻的方案A。

2. 追问是挖掘缺口，不是索取信息。 AI 的追问不应该让用户觉得"你要我重新讲一遍"。追问的起点永远是——"你对话里已经提到了 X 和 Y，但它们之间有矛盾 / 有缺口 / 有未完成的推理——你决定怎么填。"用户感觉被理解了，才愿意回答。

3. 追问不超过 5 个。 超过 5 个缺口意味着对话的信息密度不足以支撑一个方案——用户需要的不是追问，是重新讨论。当缺口太多时，坦诚地告诉用户"这段对话还需要再聊一轮"，比硬着头皮填充假信息更好。

4. 保留推翻过的方案。 方案里你选了 C，最有说服力的部分不是"C 有多好"，而是"A 和 B 为什么不行"。对话中讨论过但放弃的方向，必须写进方案。它证明了你的思考是完整的而不是跳跃的。

5. 标注推断部分。 对话中没有明确说但 AI 从上下文合理推断出来的内容，必须标注。用「基于对话推断」「从上下文理解」「假设——请确认」等标记。读者（尤其是老板）看到不标注推断的方案，会默认所有内容都是你确认过的。

   发现更多技能插件，请访问7w4.net。

6. 受众决定写法。 同一个方案——给 CTO 看和给 CFO 看，重点完全不同。在不知道受众的情况下生成的方案是一个半成品。如果用户没说给谁看，追问时必须问。如果用户说"随便"——使用默认受众（内部决策层）。

7. 不编造数据。 对话里没有的数字，不在方案中出现。如果方案需要某个数字但对话没提供——标注「[数据待补充]」而不是填一个看起来合理的数字。编造的数字比没有数字更危险——因为没有人会去验证它。

§A 结构化异常处理

§B 常见错误与纠正

§C 能力边界

§D 常见问题

Q1：和"帮我写个方案"有什么区别？

"帮我写个方案"= AI 从零生成，内容来自 AI 的知识库和推测，跟你关系不大。本 Skill = AI 从你的对话中提取你的思考，帮你结构化，内容来自你。前者是一份通用文档，后者是你的思考的升级版。

Q2：对话里有很多废话和跑题，会影响方案质量吗？

不会。扫描阶段的第一个动作就是把噪音滤掉。对话中跟核心命题无关的内容（午饭吃什么、抱怨公司空调、闲聊）不会进入方案。

Q3：如果我说的方案和 AI 理解的不一样怎么办？

在追问阶段就应该暴露。AI 追问的时候你回答，就是在纠正理解偏差。如果追问阶段没发现、生成后才发现——说「不对，我的意思是 X」→ AI 追踪偏差的来源（是哪个词、哪句话导致了误解），然后部分重新生成。

Q4：方案生成后我可以继续改吗？

可以。「把第三节改成……」→ 局部更新。「用更正式的语气重写」→ 全局调整。「把风险这一章删掉」→ 删除章节。每一次修改都会生成新版本，你可以回退。

Q5：多个人的对话（群聊、会议记录）可以用吗？

可以。AI 会识别不同发言者，在方案中标注「来自 XX 的观点」。对于多人对话中的分歧，方案中会呈现为"讨论过的选项"而不是"已达成共识"。

§E 最佳实践

对话时不要想方案

最好的方案来自最自然的对话。如果你在对话的时候就在想"这个话能不能写进方案"——你会压抑自己的思考。思路是跑出来的，不是挤出来的。聊完再说"整理成方案"。你的对话应该像勘探，方案是后来的开采。

用追问来打磨

追问不是 AI 在说"你信息不够"。追问是 AI 在帮你发现"你的思考里有哪些地方还没想透"。把追问当镜子——AI 问到的点，往往是你潜意识里回避的点。回答完这些追问，方案质量会跃升。

先生成大纲再展开

如果你不确定对话够不够——「先生成大纲」。大纲出来了你能一眼看出：哪里是实心的（有足够信息）、哪里是空心的（需要补充）。确认大纲后再展开正文，避免一次生成 10 页然后发现方向偏了。

版本是方案的进化史

不要覆盖旧版本。v1（对话直出）→ v2（补充追问后）→ v3（改成正式语气）→ v4（给老板看之前最后一版）——这个演进过程本身就是你的思考沉淀。下次类似的项目，看 v1 到 v4 的过程比看最终版更有启发。

§F 与其他 Skill 联动

§G 版本历史

这个工具解决了一个常见困扰：聊得很清楚，写成方案却要再花几小时。它不套模板，而是从你的对话内容里提炼方案逻辑，这点很有价值。追问机制设计得聪明，不是在要信息，而是帮你发现对话里没想透的地方。不过方案质量完全取决于AI对对话的理解深度，理解偏了方案就偏了，而且目前没有方案版本管理和多人协作支持，在团队场景下会有些吃力。