{ "version": "https://jsonfeed.org/version/1.1", "title": "LAB. — Soda Hsu", "home_page_url": "https://lab.sodahsu.com/", "feed_url": "https://lab.sodahsu.com/feed.json", "description": "Soda Hsu 的 AI Coding、前端互動、設計思考與實驗型文章沙盒，記錄 Vibe Coding、介面原型、工作流程與技術探索。", "language": "zh-Hant-TW", "authors": [ { "name": "Soda Hsu", "url": "https://www.sodahsu.com/" } ], "items": [ { "id": "https://lab.sodahsu.com/writing/ai-as-new-colleague", "url": "https://lab.sodahsu.com/writing/ai-as-new-colleague", "title": "不要把 AI 當神，也不要把 AI 當工具：把它當成一位新進同事", "summary": "AI 不該被理解成神，也不只是工具。更準確的管理方式，是把它當成一位能力很強、但仍需要脈絡、規則與信任邊界的新進同事。", "content_text": "很多人在導入 AI 的時候，會落入兩個極端。一種是把 AI 當神。只要丟問題，它就應該產出答案；只要答案看起來完整，就以為可以直接用。另一種是把 AI 當工具。像開 Word、開 Excel、開 Figma 一樣，期待它只是更快、更便宜、更自動化的按鈕。但我越使用 AI，越覺得這兩種理解都不夠準確。AI 比工具更主動，卻還沒有足夠的脈絡可以獨立負責。它能快速整理、生成、推演、拆解，但它不知道組織裡那些沒寫出來的限制，不知道某個客戶為什麼難搞，不知道某個功能背後曾經踩過什麼坑。所以我現在更常把 AI 想成一位新進同事。能力很強，學得很快，反應速度驚人。但第一天進公司，你不會直接把最重要的客戶交給他，也不會讓他自己去決定產品方向。你會先給背景、給規則、給範例，讓他做一小段，再看他的判斷是否可靠。 AI 協作也是這樣。管理 AI 的第一件事，不是下指令，而是給脈絡很多人抱怨 AI 答案不好，其實不是 AI 不會，而是它不知道你在哪個情境裡問這個問題。「幫我寫一份需求文件」是一種問法。「這是一個政府系統，使用者包含承辦人、主管、外部申請者；目前痛點是重複填寫、案件狀態不透明、審核流程容易卡住。請先幫我拆出需求假設、角色權限與可能的驗收條件」是另一種問法。兩者差異不在 prompt 長短，而在於你有沒有把真實世界的限制交給它。管理者在帶人時也是一樣。你不能只說「這個東西做漂亮一點」、「這個流程優化一下」、「這個報告幫我整理」。如果你沒有說清楚背景、目標、限制與判準，對方只是在猜。 AI 讓這件事變得更明顯。你給的脈絡越混亂，它產出的東西就越像一份精緻但沒有靈魂的文件。所以 AI 時代的管理能力，某種程度上就是 context design。你能不能把混亂的情境整理成清楚的背景？你能不能把抽象的期待變成具體的限制？你能不能把「我要一個好方案」改寫成「好方案應該符合哪些條件」？這些能力過去也重要，只是 AI 把它放大了。 AI 可以發散，但人要負責收斂 AI 很適合發散。它可以快速列出十種解法，模擬不同角色的看法，補足你沒想到的情境，甚至幫你把反對意見先寫出來。但發散不等於決策。真正困難的是：十條路裡，哪一條值得走？哪一條現在不能走？哪一條看起來漂亮，但三個月後會變成技術債？哪一條短期可以交差，但會傷害長期信任？這些不是 AI 可以替你負責的事。 AI 能給你選項，但不能替你承擔選擇的後果。它能幫你生成方案，但不能替你面對主管、客戶、工程師與使用者。這也是為什麼我不喜歡把 AI 協作理解成「讓 AI 幫我完成工作」。更準確的說法是：讓 AI 擴大我的思考範圍，再由我做判斷。 AI 不是拿來取代判斷，而是拿來暴露判斷。當它一次給你十個方向，你選哪一個、刪哪一個、保留哪一個，才真正顯示你的專業。管理者的責任，是建立信任邊界如果 AI 像新進同事，那管理者就要設計它的信任邊界。哪些任務可以讓它先做？哪些任務必須人類審查？哪些決策不能交給它？哪些輸出可以直接用，哪些只能當草稿？這些都要被明確定義。我認為 AI 協作可以分成三個層級。第一層是助理型任務：整理會議紀錄、摘要資料、產生草稿、列 checklist。這些任務低風險，適合大量交給 AI。第二層是參謀型任務：拆解需求、比較方案、分析風險、模擬利害關係人觀點。這些任務很有價值，但必須由人判斷。第三層是決策型任務：資源取捨、產品方向、人員評估、對外承諾。這些事情 AI 可以輔助，但不能替代人負責。真正成熟的 AI 管理，不是「全部自動化」，而是知道哪些事情可以交出去，哪些事情必須留下來。結語：AI 會放大管理者的本質 AI 不會讓管理變簡單。它會讓好的管理更有效，也會讓壞的管理更混亂。如果一個管理者本來就擅長定義問題、給清楚脈絡、設計判準、做取捨，那 AI 會成為他的槓桿。但如果一個管理者原本就習慣丟模糊指令、期待別人自己通靈、用感覺評估成果，那 AI 只會更快產生更多看似完整但方向錯誤的東西。 AI 時代的管理，不是把事情丟給 AI。而是更清楚地知道：什麼該交給 AI，什麼必須由人負責。", "date_published": "2026-06-27T00:00:00.000Z", "date_modified": "2026-06-27T00:00:00.000Z", "image": "https://lab.sodahsu.com/images/articles/ai-as-new-colleague.svg", "tags": [ "AI 與管理", "AI協作", "管理", "PM", "Agent", "工作流" ] }, { "id": "https://lab.sodahsu.com/writing/ai-era-judgement", "url": "https://lab.sodahsu.com/writing/ai-era-judgement", "title": "會做的人變多了，會判斷的人變少了", "summary": "AI 讓執行變便宜，也讓產出變得過剩。未來真正稀缺的不是更快完成任務，而是能定義問題、辨識風險與做出取捨的判斷能力。", "content_text": "以前我們評估一個人的專業，常常問的是：你會什麼？會不會 Figma？會不會寫 HTML/CSS？會不會做簡報？會不會寫 PRD？會不會做研究？這套標準在很長一段時間裡是有效的。因為工具有門檻，技能需要時間累積，會做的人本來就不多。但 AI 出現之後，「會做」這件事正在快速貶值。不是因為執行不重要，而是因為執行變得太容易被放大。以前一個人一天只能產出一版 wireframe，現在可以產出五版。以前整理一份競品分析要花兩天，現在半小時就能得到一個初稿。以前寫一份規格文件很痛苦，現在 AI 可以協助你快速鋪出架構。當產出速度變快，管理者真正該問的問題就不再是「你做了多少」，而是「你怎麼判斷」。產出變多，不代表價值變高 AI 最容易製造的管理幻覺，就是讓團隊看起來變得很有效率。文件變多了。方案變多了。會議摘要變完整了。設計稿變快了。功能雛形變容易了。但這些東西變多，不代表決策品質變好。一個團隊可能在一週內產出二十個方案，卻沒有一個真正對準問題。一個 PM 可能寫出非常完整的 PRD，卻沒有看見最關鍵的使用情境。一個設計師可能用 AI 做出很漂亮的畫面，卻沒有解決使用者真正卡住的地方。 AI 讓「看起來很完整」變得太容易了。所以管理者不能只獎勵產出量。否則團隊會開始追求可見的忙碌，而不是有價值的判斷。真正值得管理的，不是產出本身，而是產出背後的選擇。 AI 時代的核心能力，是需求定義與評估能力我認為未來專業價值會集中在兩種能力上。第一種是需求定義能力。也就是你能不能把模糊的問題講清楚。你能不能分辨這是使用者問題、流程問題、商業問題，還是溝通問題。你能不能知道哪些限制是真的，哪些只是組織習慣。你能不能在所有人都想加功能時，說出真正該解的問題是什麼。第二種是評估能力。也就是 AI 給你答案後，你知道它哪裡對、哪裡錯、哪裡只是看起來合理。你能不能看出這個方案會不會造成後續維護成本。你能不能判斷這個流程在真實現場會不會失敗。你能不能發現一個漂亮畫面背後缺少的使用情境。需求定義決定你問什麼問題。評估能力決定你是否被答案騙過。這兩種能力，才是 AI 時代真正稀缺的專業。管理者要重新設計績效指標如果「會做」變便宜，「會判斷」變稀缺，那管理者的績效標準也要調整。過去我們常看：做了幾個頁面？完成幾份文件？開了幾個需求？交付幾個功能？這些指標不是不能看，但它們越來越不足以代表價值。更值得追蹤的是：他有沒有問出更準的問題？他有沒有提早發現風險？他有沒有幫團隊少走冤枉路？他有沒有把模糊需求變成可執行的判準？他有沒有在被質疑時，能清楚說明自己的取捨？這些比較難量化，但更接近專業本質。一個成熟的人，不一定是產出最多的人，而是能讓團隊少浪費時間的人。團隊訓練也要改變如果我們還用舊方法訓練新人，就會出問題。過去訓練新人，常常是教工具、教流程、教模板。這些仍然需要，但已經不夠。因為 AI 可以讓新人快速補上「形式」，卻不能自動補上「判斷」。所以訓練應該增加三種練習。第一，練習寫問題。不要只叫新人寫文件，而是請他先說明：這份文件要解決什麼決策？誰會用？如果寫錯，會造成什麼後果？第二，練習做取捨。給他三個方案，要求他選一個，並說明放棄另外兩個的理由。重點不是答案是否完美，而是他是否能把判斷講清楚。第三，練習事後回顧。每次決策後，都記錄原本假設、實際結果與落差。判斷力不是靠一次成功養成，而是靠反覆校準。結語：未來值錢的不是更快完成，而是更準判斷 AI 會讓很多事情變快。但快不是價值本身。方向錯的快，只是更快浪費資源。未來真正有價值的人，不一定是最會操作工具的人，而是能判斷工具產物是否有用的人。不是最會生成答案的人，而是能定義問題、辨識風險、做出取捨的人。會做的人會越來越多。會判斷的人，才會越來越珍貴。", "date_published": "2026-06-27T00:00:00.000Z", "date_modified": "2026-06-27T00:00:00.000Z", "image": "https://lab.sodahsu.com/images/articles/ai-era-judgement.svg", "tags": [ "AI 與管理", "AI", "職涯", "管理", "判斷力", "PM" ] }, { "id": "https://lab.sodahsu.com/writing/product-taste-validation", "url": "https://lab.sodahsu.com/writing/product-taste-validation", "title": "好決策不是有品味，而是能把品味變成可驗證", "summary": "產品與設計討論不能永遠停在我覺得。真正成熟的決策，是把品味外顯成判準，讓團隊可以討論、驗證與迭代。", "content_text": "很多產品與設計討論，最後都會卡在一句話：「我覺得這樣比較好。」這句話很常見，也很危險。因為它可能代表真正的專業直覺，也可能只是個人偏好。可能是長期經驗累積出的判斷，也可能只是因為自己習慣某種形式。問題是，在團隊協作裡，如果一個判斷只能停留在「我覺得」，那它就很難被討論、被驗證、被迭代。 AI 時代讓這件事更嚴重。以前設計方案產出慢，所以大家會花比較多時間討論方向。現在 AI 可以快速生成多個版本，團隊反而更容易陷入選擇焦慮。每個方案看起來都可以，每個方向都有道理，每個人都能用自己的品味支持自己的選項。這時候，真正重要的不是誰比較有品味。而是誰能把品味變成可驗證的判準。品味不是主觀感覺，而是壓縮過的判斷我越來越不認為「品味」只是審美。在產品與管理裡，品味其實是一種壓縮過的判斷。它把過去看過的失敗案例、使用者反應、技術限制、商業目標、團隊能力，濃縮成一種快速辨識方向的能力。所以有經驗的人常常能很快說：「這樣不對。」但真正的問題是，他能不能說清楚為什麼不對。如果說不清楚，團隊只能相信他的權威。這在小團隊或短期專案裡也許有效，但長期會出問題。因為團隊學不到判斷邏輯，只學到迎合某個人的偏好。好的管理者，不只是自己有判斷，而是能讓判斷被團隊理解。把品味寫成可觀察的句子要讓品味可驗證，第一步是把它外顯化。不要說：「這個流程比較順。」要改成：「使用者第一次進入這個頁面時，應該在三秒內知道下一步要做什麼。」不要說：「這個設計比較有質感。」要改成：「主要操作不應該被裝飾元素干擾，使用者視線應該先落在任務入口。」不要說：「這個功能比較完整。」要改成：「在沒有客服協助的情況下，使用者應該能完成申請、查詢進度、補件與收到通知。」這種改寫很重要。因為「比較順」、「比較好看」、「比較完整」都很難討論。但一旦變成可觀察的句子，團隊就能拿真實案例來比對。這不是把品味消滅，而是把品味轉成團隊可以共同檢查的語言。用小樣本驗證，不要等市場宣判很多人以為決策只能等市場回饋。但對產品與設計團隊來說，等到市場回饋才知道方向錯，通常已經太晚了。尤其在 B2B、政府系統、內部工具這類專案裡，市場回饋週期很長，使用者也不一定會明確表達問題。所以我更偏好建立「小樣本驗證」。選 10 到 20 個代表情境，把兩個方案放進去跑。如果是流程設計，就拿常見任務測試：新手能不能完成？老手會不會覺得多餘？異常狀況是否有出口？如果是資訊架構，就拿真實查找任務測試：使用者能不能找到？是否誤解分類？是否需要來回跳轉？如果是 AI 產出，就拿既有品質案例測試：是否符合語氣？是否遺漏限制？是否產生幻覺？這種驗證不一定完美，但它比空談有效。它把「我覺得」變成「在這些情境裡，哪個方案命中率更高」。品味衝突時，不要急著投票團隊裡最常見的錯誤，是把品味衝突變成投票。多數人喜歡 A，所以選 A。主管喜歡 B，所以選 B。設計師覺得 C 最美，所以選 C。但這其實沒有解決問題，只是決定誰的偏好比較有權力。更好的方式，是先建立共同判準。我們這次最在意的是轉換率、可理解性、開發成本、品牌感，還是長期維護？這些目標的優先順序是什麼？哪些是必須達成，哪些只是加分？當判準清楚，討論就會從「我喜歡哪一個」變成「哪一個更符合我們共同同意的標準」。這是管理者很重要的工作。不是替團隊決定所有答案，而是讓團隊知道要用什麼標準判斷答案。記錄每一次判斷，品味才會進步品味不是天生的。它是在一次次選擇、錯誤、修正裡累積出來的。所以我認為團隊應該建立決策記錄。不是那種很重的會議紀錄，而是簡單記下四件事：我們當時的判斷是什麼？我們為什麼這樣判斷？我們預期會發生什麼？後來結果跟預期差在哪裡？如果沒有記錄，團隊只會一直靠印象做決策。每次討論都像重新開始，每次犯錯都很難萃取成方法。但如果有記錄，品味就會慢慢從個人直覺變成組織能力。結語：好的品味，應該能被討論我不認為產品與設計決策可以完全量化。很多時候，直覺、經驗、品味仍然很重要。尤其在複雜專案裡，資料永遠不完整，時間永遠不夠，利害關係人永遠不會完全同意。但越是這樣，我們越需要把品味說清楚。好的品味不是不能被質疑。好的品味是被質疑後，仍然能說出它背後的邏輯。當一個團隊能把主觀判斷變成可觀察的判準，把偏好衝突變成證據討論，把每次選擇變成下次學習的材料，品味就不再只是某個人的天分。它會變成團隊的決策品質。", "date_published": "2026-06-27T00:00:00.000Z", "date_modified": "2026-06-27T00:00:00.000Z", "image": "https://lab.sodahsu.com/images/articles/product-taste-validation.svg", "tags": [ "AI 與管理", "產品管理", "品味", "決策", "UX", "團隊協作" ] }, { "id": "https://lab.sodahsu.com/writing/ai-era-design-and-collaboration", "url": "https://lab.sodahsu.com/writing/ai-era-design-and-collaboration", "title": "把 AI 當操作者：談 AX 體驗設計與被徹底重構的開發邊界", "summary": "當 AI 代理人開始代替人類操作產品，UX 的對象就變了。從 AX (Agentic Experience) 設計的崛起，到設計與工程邊界的消失，產品團隊正被迫進行一場不轉型就淘汰的職能重塑。", "content_text": "這幾個月在梳理團隊的 AI 工作流時，我意識到一件有點驚悚的事：我們習以為常的產品設計思維，可能有一半已經過時了。當我們還在討論「如何讓使用者用得更順手」時，戰場早就轉移了。現在真正操作你產品的，越來越多是自主執行的 AI 代理人（Agent）。它會代替人類訂機票、爬資料、填表單。問題來了：你的產品，有針對這位「非人類用戶」設計過嗎？ UX 已死，AX 當立？傳統的 UX（User Experience）是設計給人看的，我們在意留白、動畫反饋、直覺的視覺層級。但 AI Agent 看不懂這些。如果一個頁面缺乏清晰的語意（Semantic HTML、ARIA 標籤），或者狀態機定義得不夠精準，Agent 就會像個瞎子一樣在頁面裡亂撞。它遇到華麗的彈窗可能直接卡死，遇到邊界條件可能引發不可逆的操作，更可怕的是靜默失敗——它用錯誤的方式繞過了步驟，而沒有人發現。這催生了一個全新的設計領域：AX（Agentic Experience）設計。未來的設計師不能只懂視覺。你必須確保你的設計能提供清晰的機器可讀路徑。錯誤提示不能只有「哎呀，出錯了」，還必須帶有明確的錯誤代碼與退出路徑讓 Agent 判斷下一步。GenUI（生成式介面）是 AI 即時組裝介面給人用，而 AX 則是人設計路徑給 AI 用。兩者完全相反，卻又必須共存在同一個產品裡。設計與開發的界線，正在物理意義上消失另一個巨大的衝擊，發生在團隊協作的邊界上。以前的流程很直觀：設計師畫好圖 → 丟出標註 → 工程師切版寫邏輯。這是典型的「序列式等待」。但現在？藉由像 Figma MCP（Model Context Protocol）這樣的技術，設計稿不再是圖片，而是結構化的數據。設計系統（Design Tokens）、Component API 與 Code Connect 的映射關係，可以直接穿透進入 VS Code 或 Claude Code。這意味著什麼？意味著 AI Agent 可以在你定義好 Token 的那一刻，自動幫你把按鈕的各種變體、甚至整個頁面的初步程式碼生出來。設計與開發變成了並行作業。這對設計師是個殘酷的考驗。如果你只會「畫圖」，不懂設計系統的底層邏輯，你很快就會淪為 AI 的輸入媒介，失去在產品開發上的話語權。設計師必須主動成為定義系統規則的人；而工程師的價值，則從「把圖刻出來」轉移到了「審查 AI 生成的架構」與處理極端邊界情況。說到底，還是「品味」的對決當流程被重構、產出速度被 AI 壓縮到極致，身為 PM 或產品決策者，我們的價值剩什麼？在實踐中，我們歸納了與 AI 協作最核心的心法：AI 負責發散，人負責收斂；AI 負責產出，人負責扛責。不要再傻傻地從頭手寫 System Prompt 了。把整包 Codebase 當作 Context 丟給 AI，讓它對著活生生的系統找盲點、寫 Spec。當你遇到難題，讓 AI 扮演不同角色給你十種解法草稿。但最終，決定選哪一條路徑、要承擔多少技術債、要不要犧牲一點流暢度換取安全性——這些決策 AI 幫不了你。當工具拉平了所有人「產出」的能力，決定一個產品高度的，終究是你對領域的深度理解，以及在無數次取捨中淬鍊出來的「品味」。我們不是在學怎麼用 AI，我們是在學習如何在不確定性中，更優雅地做決定。", "date_published": "2026-06-26T00:00:00.000Z", "date_modified": "2026-06-26T00:00:00.000Z", "image": "https://lab.sodahsu.com/images/articles/ai_design_collaboration.jpg", "tags": [ "AI 與產品管理", "AI", "UX", "Agent", "PM", "Workflow" ] } ] }