從問 AI 到用 Agent · 架構補充

找痛的方法論

客戶說不清楚自己要什麼,不一定是他的問題 —— 痛有七種形態,其中只有一種是「問」得到的。這頁把判斷方式、 實際運轉的迴圈、以及該長在哪裡,畫成三張圖。

🩺 第一層:先判斷這是哪一種痛

flowchart TB
  Q{"對方講得出來嗎?"}:::decision
  Q -->|講得出來| L1["① 喊得出來的痛
他們列得出清單"]:::proc L1 --> W1["⚠ 但清單貼著現有系統
低槓桿,別照著做"]:::warn Q -->|講不出來| Q2{"為什麼講不出來?"}:::decision Q2 -->|習慣了,不覺得是問題| L2["② 麻痺的痛"]:::proc Q2 -->|沒有資料,所以沒感覺| L3["③ 看不見的痛"]:::proc Q2 -->|各自以為是特例| L4["④ 碎掉的痛"]:::proc Q2 -->|扛的人不是受益的人| L5["⑤ 不對稱的痛"]:::proc Q2 -->|早就結案「沒救」| L6["⑥ 認命的痛"]:::proc Q -->|對方還沒感覺| L7["⑦ 你自己的痛"]:::result L2 --> M2["做個東西丟出去
他們才想得起來"]:::data L3 --> M3["聽「不知道」
「就這樣不見了」"]:::data L4 --> M4["把人湊在一起
讓他們互相對照"]:::data L5 --> M5["問誰在扛、誰受益
然後把負擔挪走"]:::data L6 --> M6["主動說「現在做得到了」
問要不要試"]:::data L7 --> M7["直接動手
它天然是真的"]:::data classDef proc fill:#dbeafe,stroke:#2563eb,color:#17335e classDef data fill:#fef3c7,stroke:#d97706,color:#4a2f06 classDef decision fill:#ede9fe,stroke:#7c3aed,color:#3b1d78 classDef result fill:#dcfce7,stroke:#16a34a,color:#0f3f22 classDef warn fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
判斷點 痛的種類 對應的挖法 起手式

只有第一種是問得到的。而業界的需求訪談方法幾乎全是為那一種設計的 —— 所以用問的去挖後面六種,問到最後會以為「這客戶講不清楚自己要什麼」, 其實是拿錯工具。

🔁 第二層:實際運轉的迴圈(有兩個出口)

flowchart TB
  S(["① 從小方法開始"]):::result --> D["② 做一個具體的東西
小 · 快 · 能丟掉"]:::proc D --> G["③ 給出去 · 讓它被用"]:::proc G --> O["④ 去看
被怎麼用、卡在哪"]:::data O --> C{"⑤ 有人自己回來用?"}:::decision C -->|是| DONE(["✅ 收斂
切去做穩"]):::result C -->|還沒| N{"⑥ 這次否定
有教你新東西?"}:::decision N -->|沒有,連幾輪都沒| STOP(["🛑 停損
收手"]):::warn N -->|有:多一條限制/判準| R["⑦ 記錄 + 聽他講故事"]:::data R --> AI["⑧ 跟 AI 討論下一步"]:::infra AI --> F["⑨ 修正對「怎麼用」的理解"]:::proc F -.回第②步.-> D classDef proc fill:#dbeafe,stroke:#2563eb,color:#17335e classDef data fill:#fef3c7,stroke:#d97706,color:#4a2f06 classDef decision fill:#ede9fe,stroke:#7c3aed,color:#3b1d78 classDef result fill:#dcfce7,stroke:#16a34a,color:#0f3f22 classDef infra fill:#e5e9f0,stroke:#475569,color:#1e293b classDef warn fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
起點 你做的動作 拿到的資訊 AI 在這裡幫忙 收斂出口 停損出口
1迴圈會落地 —— 從兩個出口不是無限打轉
「探索和建置沒有乾淨的分界線」是對的,但別誤讀成「永遠不收斂」。迴圈有兩個出口:收斂 —— 否定從「方向錯」變成「再順一點」、有人自己回來用,就切去做穩;停損 —— 連換幾個方向都榨不出新資訊、沒人願意為它改任何現有做法,就承認這是死路、收手。沒有出口的不是這個方法,是還沒學會什麼時候該停的人。
2記錄是獨立動作不要只記結論
每一輪都要記:撞到什麼限制、他們用什麼標準判斷對錯、有哪些例外。這些散開來看沒意義,累積起來才會浮出模式 —— 而模式就是你要找的那個東西。
2.5「被否定=方法在運作」有前提別當免死金牌
只有當否定帶來新資訊(多一條限制、多一個判準)時,才叫方法在運作。如果同一個反對重複第三次、對方只給「就是不喜歡」、或已讀不回 —— 那不是方法在運作,是在燒你們的關係。這一條防的是把方法變成「怎樣都對」的不可證偽套語。
3AI 幫的不只是「做」也幫你決定下一步
AI 讓做一版的成本崩掉,這是它最明顯的貢獻。但同樣重要的是:把累積的紀錄丟給它,一起整理模式、討論下一步該往哪換。判斷還是你的,但整理和發想可以一起做。
4你迭代的不是那個東西是你的情境理解
表面上在改介面、加功能;實際上在修正「他們會怎麼用」的想像。所以「這不對」大多不代表功能少了 —— 補功能解決不了想錯的情境,只會讓東西越來越肥、越來越沒人用。

🧱 第三層:做出來的東西該長在哪

flowchart TB
  subgraph CORE["🏢 既有系統 · 管的是常態"]
    C["穩定、被依賴
所以它才改不動"]:::infra end subgraph EDGE["🌱 可以長的地方 · 價值在例外"] direction TB E1["關係 / 脈絡"]:::proc E2["特殊事件
系統不收,只在人腦裡口耳相傳"]:::proc end subgraph LOAD["⚖️ 負擔怎麼放"] direction LR A["收集端
扛的人 → 幾乎零負擔"]:::result B["消費端
受益的人 → 才數位化"]:::data end C -.->|不動它,長在旁邊| EDGE EDGE --> LOAD A -->|累積| B classDef proc fill:#dbeafe,stroke:#2563eb,color:#17335e classDef data fill:#fef3c7,stroke:#d97706,color:#4a2f06 classDef result fill:#dcfce7,stroke:#16a34a,color:#0f3f22 classDef infra fill:#e5e9f0,stroke:#475569,color:#1e293b
改不動的核心 可以擴充的外圍 零負擔的那一端 受益的那一端

撞到「這個改不動」的時候不要硬幹 —— 那不是阻礙,是地圖上的邊界, 而且你應該慶幸這麼早就撞到。核心系統正是因為穩定才留得下來,也才不能亂動; 而系統不收的例外,剛好就是知識還沒被固化的地方。 最好的探針不一定是軟體 —— 是使用者真的願意用的那個。

📺 對應單集:痛有七種 · 需求還不存在的時候 · 做出來被說不對,才是正常的  |  📚 回課綱總表 →