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對對話的理解深度，理解偏了方案就偏了，而且目前沒有方案版本管理和多人協作支援，在團隊場景下會有些吃力。