01
時間位移
AI 省下主動編碼與搜尋時間，卻把工時搬到審查輸出、修正方向、等待生成，以及處理 AI 引入的錯誤。
00:00–05:31 · 問題發生
個人覺得變快，
不等於組織真的變快
WPS 從 3 月起要求產品與研發全面使用 Cursor、Claude Code 等 AI 工具。半年後，單點產出確實加速，但講者的判斷很尖銳：至少一半的「AI 提效」，更多是在向組織與老闆提供情緒價值。這個落差也出現在 METR（Model Evaluation & Threat Research，模型評估與威脅研究機構）的隨機對照實驗：16 位熟悉大型開源專案的資深開發者，在 246 個真實任務中使用 AI，主觀一直覺得自己變快，計時結果卻顯示整體反而慢了 19%。
24%開發者事前預測
AI 會讓自己更快
AI 會讓自己更快
20%完成後仍然估計
AI 確實讓自己更快
AI 確實讓自己更快
−19%計時器實際測量
使用 AI 反而更慢
使用 AI 反而更慢
246METR 隨機對照實驗中的
真實任務數
真實任務數
這組數據真正揭露的不是「AI 沒有效」。AI 把生成變快了，卻也增加等待、提示、審查、修正與返工；如果只量產出環節，就會把後段照護成本排除在外。個人對速度的感受，因此可能和組織實際付出的總工時完全相反。
02
表面產出膨脹
研究中被反覆引用的「AI 提速 56%」常量測程式碼行數與提交次數；AI 把任務拆得更碎，產出多了，總工時未必下降。
03
笨實習生效應
生成很快，但需求寫不準就要反覆抽卡、照顧與 review。若只計算生成環節，就會漏掉龐大的事後照護成本。
真正稀缺的能力：當人人都能做出 100 個項目，價值不再是「能不能做」，而是判斷哪一個該做、哪一個不該做，以及誰做得更有品味、更重視互動與細節。
06:04–13:39 · 實踐復盤
WPS 的四條線：
把完整產品鏈路一起拉進來
不是只要求產品經理「多寫 Prompt（提示詞／給 AI 的指令）」，而是同時改造上游運營、內部產品工作流、下游研發銜接與公共數據回收，讓產出能沿著同一條鏈路流轉。
01
運營配置上游｜提出活動
主要工作用對話建立活動、商品與投放規則
交給下一站清楚且可執行的商業需求
02
產品工作流內部｜需求標準化
主要工作統一 PRD（產品需求文件）、原型與審查標準
交給下一站研發可以直接讀懂的交付包
03
研發銜接下游｜產品開發
主要工作依 G0–G5（第 0 至第 5 階段）檢查關卡推進
交給下一站可測試、可驗收、可回滾的產品
04
數據閉環回流｜效果驗證
主要工作自動完成埋點、驗收與成效分析
回到第一站把真實結果送回下一輪決策
重點：四條線不是四個獨立專案，而是一條持續循環的交付鏈。任何一站格式不一致，前面省下的時間都會在交接與返工時被吃掉。
運營案例
天策運營工作台：從「配介面」改成「說需求」
促銷活動原本要跨 9 個平台、配置 70–80 項甚至 200+ 項參數。改成自然語言入口後，AI 拆解任務、呼叫商品／計費／策略 Skill（可重用的 AI 任務技能），再用歷史數據、合規紅線與審批流做 AI 審查；熟手約兩小時的工作，新實習生也能在幾分鐘內完成。三個月後整體配置效率提升 50%。
產品案例
魯班工作台：統一 8 個產品團隊的交付語言
過去 PRD、原型、埋點與審查格式各自為政。WPS 用 24 個規範文件建立標準流水線，要求原型不通過就不能生成 PRD、PRD 不通過就不能流入研發；9 個 Agent（能自主拆解並執行任務的 AI 代理）分工為 8 個業務 Agent＋1 個通用規則 Agent。
研發案例
Corelink（WPS 內部產研協作系統）：把「人盯人」改成「系統盯系統」
需求到上線拆成 G0 需求、G1 設計、G2 開發、G3 測試、G4 驗收、G5 回歸，每個 Gate 有進入條件、輸出與回滾規則。在兩個完整專案中驗證：權限中心涵蓋 9 套系統、603 個權限項、1,581 個帳號賦權。
數據案例
功能埋點：AI 自動生成，也自動驗收
設計階段從 PRD 雲文檔生成埋點方案並匯入平台；驗收階段抓包後自動比較方案與實際上報，30 分鐘出具驗收報告。流程串起曝光、點擊、付費、轉化、續費，讓產品不再「恐懼寫埋點」。
Corelink 的作用：替產品上線設 6 個檢查站
Gate（檢查關卡）就像登機前的層層檢查：這一關該確認的事情沒有完成，就不能直接往下走，避免錯誤一路帶到上線後才被發現。
🚦 G0–G5 不是分數，而是 6 個依序通過的檢查站
要做什麼？
目標、範圍與成功標準清楚嗎？通過後：需求定案怎麼使用？
操作流程、例外與原型完整嗎？通過後：設計可開發怎麼做出來？
示範原型、接口與技術限制說清楚了嗎？通過後：功能完成有沒有出錯？
一般情境與極端狀況都測過了嗎？通過後：可以驗收符合期待嗎？
產品、數據與業務都確認合格嗎？通過後：允許上線結果正常嗎？
數據是否正常，異常時能回復嗎？通過後：完成閉環核心改變：從「一直問人做到哪裡」變成 「系統自動判斷能不能進下一關」
埋點自動化：讓數據驗證跟著產品一起完成
過去要人工撰寫、接入、抓包、比對；現在把六個零散步驟收斂成三個清楚階段。
先規劃
定義要追蹤什麼
從 PRD 生成方案找出曝光、點擊、付費等關鍵事件
統一資料格式事件名稱與參數使用同一套標準
再執行
接入並自動檢查
自動接入埋點把追蹤規則放進產品功能
比對實際資料抓包檢查送出的事件是否正確
最後驗證
確認結果並回流
30 分鐘完成驗收自動列出預期與實際資料的差異
帶回下一輪決策用付費、續費與轉化結果改善產品
一句話看懂產品經理寫好需求後，系統會自動規劃要收哪些數據、檢查有沒有正確收到，再把結果送回產品團隊。
13:39–20:11 · 痛苦教訓
車越多，路越堵：
沒有規則的 AI 會製造新瓶頸
90+
重複造輪子
多個團隊各自維護競品調研、PRD、埋點 Skill，格式與邏輯彼此不相容。
7–8
同題多套平台
僅 Web coding 類改造，全公司就做了七八套，卻沒有形成可復用能力。
60%
產出被棄用
4 月 AI 產出中，超過 60% 在流轉時被修改、返工或直接丟棄。
3–4×
幻覺返工
原型或 PRD 漏掉一個變量，沿下游放大，最後可能付出三至四倍返工。
比單次 AI 幻覺更危險的敵人，叫做「幻覺複利」。
多流程步驟下，微小的幻覺、格式偏差與邏輯漏洞會在每次轉換中被當成事實，越傳越遠、越放越大，而且常到交付驗收才被看見。
幻覺如何沿著工作流複利
錯誤不是單純往下傳，而是每經過一次自動補全、格式轉換與下游實作，就被包裝得更像真的。
原型漏掉一個狀態變量
PRDAI 用錯誤假設補齊缺口
程式碼偏差被實作成系統行為
交付到驗收才發現方向錯誤
最終代價：不是修一個欄位，而是可能付出 3–4 倍返工。
隱蔽性
每一環單獨看都像沒問題；把多個模組拼起來，才會看出目標與假設已經漂移。
累積性
原型 → PRD → 程式碼 → 測試 → 報告，每多一次格式或語義轉換，偏差就再放大一層。
發現滯後
錯誤常在配置端發生，卻到數據分析、策略報告甚至正式交付才暴露。
三個真實模式：best-effort（盡力而為、但不保證結果）假設被當成事實；多團隊複用 Skill 時標準漂移（Markdown，輕量標記文件格式／JSON，結構化資料交換格式／雲文檔互轉）；運營配置小錯進入數據分析，最後導致策略決策偏差。
20:11–31:14 · 解法建立
不只 Harness 模型，
還要 Harness 整條工作流
傳統 Harness Engineering 約束模型的提示詞、上下文、輸出與 Agent 規則；Workflow Harness Engineering 再往外一層，約束人機協同、角色權責、環節流轉、交付標準與品質閘門。
我們真正要的結果
可控的 AI 提效
不只做得快，還要方向正確、品質穩定，而且能順利交給下一個人。
→
提高 AI 自動化產能讓 AI 承接更多可重複、可標準化的工作。
降低每次駕馭成本把審查、權限與交付規則做成可重用標準，不必每次重來。
不是把約束拿掉。而是讓約束更標準、更自動、更容易重用；這樣 AI 做得越多，團隊才不會跟著增加同等程度的檢查與溝通負擔。
支柱 1 · 模型側駕馭
先給 AI 能力，也先畫邊界
- 上下文持久化：分層知識庫與歷史決策沉澱
- 輸出剛性校驗：格式、合規、邏輯、幻覺攔截
- 權限沙箱：最小權限，先畫邊界再給能力
- 獨立評估 Agent：生成與校驗分離，低於 80 分打回
- 錯誤沉澱規則庫：每次攔截自動歸因並反向更新約束
支柱 2 · 工作流側駕馭
替整條流水線修跑道
- 階段閘門：需求 → 方案 → 原型 → 評審 → 交付
- 角色協同：AI 聚合與初稿；人判斷、兜底與背書
- 流轉規則：模板、版本、觸發條件、回滾與統一銜接
- 品質閉環：產出 → 校驗整改 → 標準迭代
- 治理底座：訪問控制、輸出審核、審計、合規、成本管控
WPS 把團隊經驗集中到共同知識底座
下面三個數字都是已建立或沉澱的「數量」，不是分數。
10座業務知識庫
保存跨產品共用的規則與專業知識。
2座運營需求庫
保存活動配置方式與商業判斷脈絡。
337條共享記憶規則
把錯誤、審查結果與決策變成下次可直接使用的規則。
兩條控制線，各自檢查不同問題
這不是四個依序進行的步驟，而是模型與工作流同時接受兩種檢查。
模型側控制檢查這一次 AI 輸出
資料是否足夠格式是否正確有沒有幻覺權限是否合規
工作流側控制檢查能否交給下一個角色
是否通過關卡誰負責決策交付物是否完整異常能否回滾
發現錯誤 → 更新共同規則 → 下一次模型輸出與工作交接一起改善
五條治理護欄，同時保護交付
這五項不是步驟，也沒有先後相依。它們分別處理「答案是否可信、知識能否累積、環境是否安全、決策由誰負責、工具能否復用」五種風險。
生成與校驗分開
用不同模型或 Agent 交叉檢查，避免同一個 AI 為自己的答案打高分。
Memory 進共同知識庫
錯誤、審查與決策跨團隊累積，不散落在個人 Prompt 裡。
生產環境保持隔離
AI 只在測試環境產生變更，通過回歸測試與人員確認後才發布。
高風險決策由人背書
資金、合規、程式碼審查與最終決策保留 HITL（人類參與決策迴路）。
Skill 精簡並統一交接
WPS 將 90+ 個 Skill 合併為 30 個共用版本，覆蓋不同產品與海外團隊。
🛡️五條護欄共同指向：讓 AI 的產出可驗證、可追溯、可交接、可負責
邊界判斷：若工作只有「產出」，模型層約束通常足夠；只要涉及多人協作、跨團隊交接、多環節流轉，就需要工作流駕馭。創意探索、概念驗證與個人獨立工作，過度約束反而是負擔。
4 月 → 6 月 · 從試錯到見效
同樣的人，
換了跑道後才出現組織級提升
4 月是各自為戰的「虛假繁榮」；5 月開始統一工作流、設 Gate、沉澱知識；6 月看見真正效果。
關鍵不是模型突然變聰明，而是 AI 產出從「還要返工」變成「可以直接接用」。
| 維度 | 4 月｜各自為戰 | 6 月｜統一平台 |
|---|---|---|
| Skill 數量 | 90+（重複冗餘） | 30（統一復用） |
| PRD 一次通過率 | 63% | 89% |
| 研發返工率 | 34% | 12% |
| 埋點設計時間 | 2.5h+ | 20min |
| 埋點驗收時間 | ≥2h | 30min |
| Token 使用效率 | 高消耗、低產出 | 消耗降、產出穩 |
Gate 帶來的不是更多審批，而是更早發現錯誤
一次前置審查攔住了原本可能造成一個月返工的需求偏差；同類品質問題也從每週 3–4 次降到 0。
真正的收益，是把錯誤發現點從交付末端搬到需求與設計前端。
337
Memory 沉澱
每次攔截自動歸因、反向更新規則並永久攔截，讓知識不是「某人記得」，而是系統能約束。
T+0
品質通報閉環
T+0（事件發生當天）處理：PRD 因背景缺失被攔，當天就同步更新規範 Skill、檢查清單與知識庫。
80
最低品質門檻
生成與評估分離；獨立評估低於 80 分就打回，讓 PRD 從「好看」轉成「能用」。
28:32–36:49 · 人與組織
產品經理不會消失，
但競爭維度已經換了
Prompt 與工具把「能不能做」的門檻拉平；真正拉開差距的，是能否約束產出、設計流程、判斷價值與建構系統。能力從單點調優，升級成體系設計。
1
入門：操作工具
會用工具、寫 Prompt、調用 Skill
能把事情做出來
完成單點產出，是基本功，但還不足以形成競爭力。
2
進階：控制品質
能約束模型、管理上下文與幻覺
能把事情做對
設定品質標準與人工審查點，知道什麼時候不能交給 AI 決定。
3
核心：設計系統
能重構工作流、設 Gate、定規則
讓組織持續做對
統一交付物、權責與治理機制，把個人能力放大成組織能力。
能力升級的重點從「自己會用 AI」走向「讓整個團隊穩定交付」。
L1–L4（Level 1–4，能力等級）考試制度
WPS 從 4 月開始對產品經理考試：L1 是 AI 基礎與安全邊界；L2 要能實作 Demo（可操作的示範原型）；L3 要建立約束 AI 的流程與判斷；L4 尚未全面開考，但代表未來的系統級能力。
平台架構思維
最大陷阱是把 AI 當「替人做重複勞動」的工具。WPS 的護城河是 30 年工程規範、業務 know-how（實務經驗與專業訣竅）與用戶理解；AI 應調度這些積木，而不是每次從零造輪子。
講者的組織觀：不要只把 AI 當減少人力的工具，而要把它變成組織能力的放大器——從個人的趁手生產工具，走向改善生產關係的武器。
37:35–53:20 · 現場 Q&A
好產品怎麼評、團隊記憶怎麼管、
PRD 怎麼避免傳遞偏差？
Q&A（Questions and Answers，問答）把方法落到三個最難的組織問題：品質由誰定義、規則如何持續更新，以及人與 AI 共同交付什麼。
Q1｜創意工作難以量化，怎麼判斷 PRD「好不好」？
「好」不能交給 AI 自己定義。WPS 由 P9（公司內部資深職級）以上產品專家把經驗寫成可復用標準，再由各事業部依 B 端／C 端情境分層。
- 邊界完整：平台、裝置、異常狀態與極端條件是否納入。
- 用戶旅程：主線、分叉與例外路徑是否完整描述。
- 多目標取捨：商業化、用戶、體驗、互動、可行性與成本是否有設計。
- 品質流程：約 20 項校驗，通常經 3 次評審，再由資深專家判斷亮點與品味。
Q2｜七、八個團隊的 Memory 如何共享、分層與處理衝突？
WPS 內部知識庫先按商業產品、平台產品、基礎產品分域，再把記憶切成個人、專案與領域三層；使用 Markdown 與知識圖譜串聯記憶、文件與議題。Memory 最終進入 Skill 標準，讓 B 端調研關注權限與覆蓋，C 端調研關注體驗與差異化，既共享底座又保留領域判斷。
Q3｜SOP（Standard Operating Procedure，標準作業流程）與知識一直變，靠人維護還是靠 AI？
不能只靠人的自覺。WPS 用專門 Agent 定時蒐集程式碼、PRD 與業務變更，自動提議更新記憶庫；但規則的生效權限依職級與治理制度管理，並做跨規則衝突校驗，最後仍由有權責的人判斷。
Q4｜為什麼工作流做完，組織效率還是可能上不去？
因為組織摩擦是團隊效率上限。若調研、寫需求、評審、驗收等原流程一項都沒刪，只是在每個步驟多加 AI，總負擔不會下降。講者舉例：同事一天完成 Diff（版本差異內容）、PRD 與樣板工程，卻花一週雕琢一篇 7,000 字文件。真正的改造要合併、精簡與自動化原流程。
Q5｜跨事業部都各做各的，誰能真正推動統一？
WPS 建立虛擬產品委員會，從「提建議」升級為有決策約束力的治理組織：PRD、SOP 與知識庫都要依委員會規則執行。這未必是終極解，但在現有公司治理下，是把專家經驗轉成共同跑道的現實解。
Q6｜Markdown、原型與 Demo 分散，怎麼減少研發理解偏差？
交付物不再是一份孤立 PRD，而是一個文件包：Markdown 文件、圖文 PRD、原型、可運行 Demo、測試用例與驗收標準。AI 可以依設計規範生成頁面與說明，但產品經理要做最後決策與把關。
可落地清單
把演講轉成一套組織檢查表
先找真正的瓶頸
把生成、等待、審查、修正、交接、返工一起計時；不要只量 PRD 生成幾分鐘。
畫出端到端工作流
從需求、方案、原型、評審、開發、測試、發布到數據回收，標出每次轉換與責任人。
只在高風險處設 Gate
資金、合規、邏輯邊界、程式碼與生產發布必須有人背書；探索型工作保留自由度。
把生成與評估拆開
不同模型／Agent 做交叉校驗；設置剛性門檻與打回條件，避免 AI 自我肯定。
統一交付物與 Memory
合併重複 Skill、統一格式、版本與知識庫；讓下游 Agent 和人都能無損接手。
追求「直接接用率」
以一次通過率、返工率、驗收時間與下游直接採用率衡量組織成效，而不是 Token 燒多少。
本頁以逐字稿時間順序為主線，並逐張核對 46 頁原始簡報；簡報截圖已全部移除，圖中的流程、架構、比較與數據均改寫為本頁原生資訊圖表，方便手機閱讀與後續維護。
36:49 · 全場總結
三句話，記住今天
AI 跑得快的前提，是先跑對方向。
給 AI 套韁繩，也要替工作流修跑道、設 Gate、定交規。
約束不是限制，而是讓速度可以持續的基礎設施。
開始加速前，先通過四道檢查
這不是四項並列指標，而是一條依序判斷的路徑。前一題沒有明確答案，就先停下修正，不要急著讓 AI 繼續往下做。
任何一關未通過：回到該環節補齊資訊、修正品質或釐清交接，不讓錯誤被 AI 放大到下一站。
✓方向正確 × 品質可靠 × 順利交接，速度才有價值
Audio deep dive
Podcast｜工作流駕馭工程
NotebookLM 繁體中文深度對談
拆解個人提效與組織提效的落差，以及 WPS 的雙軌駕馭與知識沉澱。
雙人對談 · 繁體中文 · 21:43