tzuchienkao

三度參與 TUA 年會：在環環相扣的齒輪中，看見現場執行與 AI 的交會

2026-08-23

三度參與 TUA 年會：在環環相扣的齒輪中，看見現場執行與 AI 的交會

這是我第三次在 TUA（台灣泌尿科醫學會）年會擔任臨時工作人員。這次被分配到「會議組－播放（簡報）」角色，每一組由四人組成：場控、播放、時間控制與機動。

雖然只是整個大會中的一個小組，但實際在執行的時候，更能深刻感受到這是一套極其縝密且環環相扣的運作體系——每組都是彼此的齒輪，每一步都必須在會議前中後全神貫注地執行與待命。

正式議程的高壓：現場運作的精密齒輪與突發排除

當講者抵達會場，第一件事是去檔案組繳交簡報。檔案組會將訊息同步到工作群組，對應會議室的組員必須隨時盯緊訊息並即時回覆。身為播放人員，拿到檔案後的標準作業包含：檢查檔案是否存在、確認姓名無誤、在簡報最前面插入大會統一的簡介頁面。

然而到了議程進行中，現場狀況往往瞬息萬變。最具代表性的一幕，發生在某一場會議開始前的最後十分鐘——當時下一場的外賓要求提前測試簡報，但投射出來的畫面卻只有大會統一的背景，完全找不到講者的簡報檔案。

站在外賓身旁的我立刻向組員發出訊號，整組瞬間進入應變狀態：

分頭確認：我與時間控制人員分頭翻查工作群組訊息與檔案位置，比對簡報更新時間與內容；機動人員則同步上前，向外賓再次確認先前是否已將檔案交付給檔案組。
分工聯繫與現場決策：在確認檔案確實未同步到位、且距離開場只剩不到五分鐘時，機動人員立刻奔向檔案組，時間控制人員則在工作群組標記相關負責人。為了爭取時間，場控人員果斷下達指令，請外賓直接在現場交付隨身碟檔案。
極速處理與順暢接軌：接過檔案後，我快馬加鞭將大會簡介頁面插入到簡報最前方並完成確認；時間控制人員同步在群組回覆最新狀況，奔波回來的機動人員也確認現場問題排除。

從發現異常到完美解決，短短幾分鐘內，四個人完全不需要多餘的口頭拉扯，有人確認檔案、有人調度溝通、有人現場決策、有人快手設定。會議最終準時且順利地開始，這正是一次極致的團隊補位演練。

除了會議中的應變，會議前的準備同樣瑣碎且關鍵，我們必須逐一檢查現場設備（麥克風、簡報筆、滑鼠、電腦、螢幕、投影幕、燈光、冷氣等）是否運作正常。

事後回看：教育訓練背後的機制設計

在現場體驗到這份張力後，回過頭看事前的兩次教育訓練，才明白那些安排的用意。

第一次訓練是四位組員初次見面，首要目標是理解各自的工作與編號，並建立「四人是一個團隊、隨時要能互相 Cover」的共識。大會也制定了跨團隊工作群組的溝通規則，除了特定對應回覆外，其餘訊息必須「簡短說重點」。這次偏向紙上談兵式的模擬（畢竟實際場地可容納 270 人），針對播放與時間控制做情境練習，最後由召集人驗收。

第二次訓練則直接拉到實際會場，全體工作人員各自帶開進駐各自的會議室。除了再次複習播放與時控、讓機動人員實地演練外，這次更增加了「臨時代理」的換位流程與硬體測試。

正是因為有了「紙上模擬 ➔ 現場實測 ➔ 代理機制」這層層遞進的準備，正式上場時，面對突發的檔案缺失與時間壓迫，大家才能在幾分鐘內迅速遞補、冷靜排除，完全不掉鏈。

團隊小結：I 人組合的意外默契

回頭看這兩天的工作過程，其實蠻值得回味的。我們這一組大家事前完全不認識，而且性格上都是「I 人」（內向型）。

本以為大家會比較害羞或拘拘謹謹，但實際到了正式議程，四個人的配合默契卻好得出乎意料。沒有多餘的客套與繁文縟節，大家專注在各自的崗位上，又能時時保持覺察，做到互相提醒、不掉棒。在需要高專注度的現場，能遇到這樣彼此神補位、節奏一致的夥伴，真的覺得非常幸運，也很幸福。

跨界觀察：在醫療年會看見 AI 的落地應用

除了流程執行的體會，在兩天的議程中，我也從個人最近接觸 AI 的經驗出發，觀察到醫療領域對 AI 的實際應用。

身為非醫學背景的外部人員，現場所有臨床知識對我來說都是全新的概念，雖然吸收有限，但看見 AI 工具的介入非常有共鳴：

論文寫作的工作流：有醫師詳細比較了各家 AI 模型與工作流架構，分享如何藉由工具輔助大幅提升論文產出效率，最後也說到「終究要回歸到個人使用習慣的建立」。
臨床手術結合：分享了 AI 在泌尿系統內視鏡手術中的輔助應用。
簡報細節：不少講者的簡報內容與視覺資料中，也能看到 AI 協助生成的痕跡。

這次最大的收穫：Take Home Message

流程要順暢，溝通先簡短：跨團隊協作時，去除贅詞、直接講重點是降低溝通成本的不二法門。
準備做得足，現場不慌張：看似順暢的現場應變與突發排除，本質上都是事前對流程與代理機制的反覆確認。
配到神隊友，協作更輕鬆：好的團隊不一定要非常熱絡，能彼此覺察、互相 cover 不掉棒，就是最舒服的高效合作。

當需求開始變複雜，我讓 Claude 開了三個 Subagent 分頭行動

2026-08-22

當需求開始變複雜，我讓 Claude 開了三個 Subagent 分頭行動

在這一次接手的專案裡，進入正式開發前，我先使用了 Claude Design 完成了整體的視覺原型與 Dashboard 頁面規劃。設計確定後，我將產物匯出，正式交由 Claude Code 接手後續的工程實作。

當我準備讓 Claude Code 動手時，我面臨了一次相對複雜且多面向的需求——解析設計規範、重構 Layout 機制，還要將儀表板原型落地。

如果把這些龐大的任務通通塞給單一對話視窗，AI 通常會因為訊息量太大而上下文混亂，或是急著動手改程式，結果改到一半才發現規格根本沒對齊。

這一次，我試了一種協作方式——Claude Subagent（子代理人）。

我叫它「先開三個 Subagent 去規劃」

在這次的開發中，我對 Claude Code 提出了這樣一個需求：

「請協助我定義設計規範及版型……

subagent1: 執行定義設計規範
subagent2: 撰寫整體版型 Skill 及頁面調整
subagent3: 定義 Dashboard 頁面規格

以上請先定義及確認規格後再進行實作。」

這一段對話最有趣的改變，不是指令變長了，而是：

我把 AI 當成一個「專案經理（Main Agent）」，由它去發派任務給專門的工程師（Subagents）。

按下 Enter 之後，Claude Code 沒有急著去改程式碼，它在背景同時啟動了三個獨立執行的 Subagent，分別去解讀設計規範、評估 Layout 可行性，以及對照既有 API 確認資料落差。

而主對話視窗裡，Main Agent 只負責回報一件事：

「三個子代理已在背景並行執行，各自只產出規格文件、不動實作程式碼……三者完成後我會整理彙總給你確認。」

主對話視窗，變成了我的「規格確認會議」

在 Subagent 的模式下，主對話視窗被「乾淨地留了下來」。

Subagent 在背景跑了幾分鐘後，各自產出了獨立的規格文件，並把遇到不確定的決策點丟回給 Main Agent 彙總，由它來到我面前提問。

AI 沒有代替我做決定，也沒有直接把程式碼改得面目全非。

它把複雜的任務拆開，在子環境裡跑完分析，最後拿著「清楚的待確認事項」來到我面前。當我確認完規格後，Main Agent 才正式接手，一次性地把需求精準寫完。

真正難搞的，往往是那些「規格以外的小瑕疵」

程式寫完，畫面看起來已經有模有樣了。

但我打開瀏覽器一看，總覺得哪裡怪怪的——畫面四周被一圈神祕的空白包圍著。我沒有自己開 F12 去查，而是直接把現象告訴它：

「長得滿美的。不過頁面有個問題，body 有個神秘的間距把畫面元素往內擠了，請幫我加 reset css。」

Claude Code 很快就查出了原因，解決了邊界貼齊的問題。

這又再一次印證了我的感受：
AI 可以幫我們把 80% 的架構與設計原型很快蓋好，但剩下那 20%「用起來順不順、看起來對不對」的細節，依然需要人類開發者親自去觀察與判斷。

我依然是那個負責把關的人

從使用 Claude Design 設計原型，到讓 Claude Code 開 Subagent 進行工程落地，AI 並沒有讓我的工作消失。

它只是把我從繁瑣的細節中抽離出來，讓我能站在更高的維度去思考產品畫面順不順、判斷指標合不合理、決定哪些功能該第一版做。

AI 協作的工具和機制一直在進化，但那個「發現問題、下達判斷、負責驗收」的核心循環，始終沒有變過。

我依然在建立屬於自己的 AI 開發工作流，而這次，多了一群可以隨時分工的子代理人。

當我接手了一個夥伴用 AI 蓋好的專案

2026-08-21

當我接手了一個夥伴用 AI 蓋好的專案

在這之前，我是一個純前端的開發者。

過去雖然偶爾碰過前後端在同一專案裡的經驗，但遇到不熟悉的後端語言、資料庫設定或是複雜的路由，我常常會陷入一種「不知該從何看起」的焦慮感。

這次，我接手了一個全新的預約管理系統專案。這個專案的基礎架構——包含後端、資料庫、前端路由與基本的佔位頁面，已經由另一位夥伴透過 AI 完全建立好了。

面對這個全新的專案，我沒有急著去翻程式碼，而是決定先請 AI 幫我做第一件事。

讓 AI 以「新人工程師」的角度，幫我寫一份指引

接手一個由 AI 產出的專案，最怕的就是「看似有模有樣，卻不知道各個檔案在幹嘛」。

於是我打開 Claude Code，對它說： 「請以一個完全沒看過這個專案的新人工程師角度，幫我建立一份新人指引手冊。」

幾秒鐘後，AI 產出了一份指引文件。

它沒有丟給我一堆複雜的程式碼，而是用非常條理的方式梳理出整個專案：告訴我這個系統的核心商業邏輯是什麼、前後端資料夾各自負責什麼，甚至幫我畫出了資料在前後端之間是怎麼流動的。

這份文件不只是給未來的協作者看的，它首先成了我快速理解整個專案的防護網。

在本地 Run 起來：遇到了第一個問題

有了指引文件，下一步就是嘗試在本地把專案跑起來。

我輸入了啟動指令，畫面順利顯示登入頁面。但隨即我面臨了一個很尷尬的問題：「預設的帳號密碼到底是什麼？」

這是一個全新的專案，資料庫剛建立好，我完全不知道預設的測試帳號被寫在哪裡。

這一次，我沒有第一時間把問題丟給 AI，而是自己回頭去翻找專案內的文件與設定檔。因為在嘗試使用 AI 協作的同時，我依然希望保有自己查找與解決專案問題的能力，而不是把所有驗證與追查都無腦交給 AI。

最後，我在專案設定中找到了，順利釐清設定機制並順利登入。當畫面跳轉成功的那一刻，我知道：這個專案已經在我的電腦裡活過來了。

站穩腳步後，邁出我的第一步

確認前後端可以在本機正常運作，也釐清了整體的資料結構後，開始介面與視覺規範的建立。

我切換到了 Claude Design，告訴它我們專案使用的前端套件與系統類型，同時附上幾張自己喜歡的介面風格原型，跟它一起建立屬於這個專案的設計規範與 UI Kit。

AI 協作時代下的「接手專案」

過去我們接手別人的專案，最耗時的往往是「讀懂程式碼結構」與「踩遍環境設定的坑」。

但這次與 AI 協作的經驗讓我有了一個新的體會：

先建立 Context，再動手：善用 AI 整理出新人指引，把不熟悉的後端與資料庫結構可視化。
保有自主查錯的能力：讓 AI 處理大架構的整理，但在追查問題時依然訓練自己看文件的基本功。
釐清脈絡後，回歸專業：當環境跑通後，開發者就能把精力放回真正的產品設計與體驗優化。

你不需要變成一個全端專家，才能接手一個前後端混合的專案。只要懂得如何讓 AI 幫你「導覽」與「接棒」，同時保有自己的工程判斷力，任何人都能在陌生的程式碼庫裡快速站穩腳步。

當 AI 開始接得回來，我開始思考要怎麼教它工作

2026-08-19

我開始發現，和 AI 一起開發，真正重要的是讓它找得到「現在」

2026-08-13

我花了 12 個小時，和 AI 一起完成了一個產品

2026-07-18