[{"data":1,"prerenderedAt":43},["ShallowReactive",2],{"article-zh-from-tool-to-process-challenges":3},{"article":4,"related":17,"prevArticle":39,"nextArticle":40,"availableLocales":41},{"id":5,"slug":6,"image":7,"date":8,"published":9,"created_at":10,"updated_at":11,"title":12,"excerpt":13,"content":14,"custom_css":15,"keywords":16,"meta_description":13,"og_image":15,"image_width":15,"image_height":15,"category":15},"1092dc59-4718-4902-809c-74cfdfc5fffd","from-tool-to-process-challenges","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/blog_pictures/from_tool_to_process.png","2026-03-02T03:06:00+00:00",true,"2026-03-02T03:06:15.361498+00:00","2026-03-02T03:27:41.327+00:00","從單點工具到流程閉環的虛實與挑戰","探討2026年AI在軟體開發生命週期中的實踐，從單點工具普及化到流程閉環協作的轉變，以及QA自動化的真實與虛假繁榮。","\u003Cp>\u003Cstrong>未來已來，只是分布不均\u003C/strong>\u003C/p>\u003Ch2>前言：AI 競賽後的冷思考\u003C/h2>\u003Cp>農曆年前後，我受邀參加了幾家公司內部的 AI 競賽評審，上週剛結束最後一場，有感而發。\u003C/p>\u003Cp>年初的這個時間點很有趣，大家不約不同地都在回顧過去一年的 AI 應用，並試圖為新的一年錨定新的方向。在幾場 AI 應用競賽與分享會中，我近距離看了許多團隊——從初創公司到大廠部門——在軟體開發生命週期（SDLC）中實踐 AI 的成果。\u003C/p>\u003Cp>在熱鬧的技術展示背後，我觀察到了三個極具指標意義的現象。這些現象反映出領先者與追隨者之間，已經不再是「有沒有用 AI」的區別，而是「如何定義流程」的本質差異。\u003C/p>\u003Ch2>觀察一：工具普及化，AI 已從「對話框」走入「生產線」\u003C/h2>\u003Cp>回想前一年的這個時候，我們在進行 AI 評審時，大部分的應用還停留在某些看起來特別炫的技術上。那時大家熱衷於討論是不是用上 Vibe Coding，討論用哪個工具更會寫，Bug 更少，但今年，這個現象有了顯著的轉變。\u003C/p>\u003Cp>現在，不論是 PM（產品經理）、RD（軟體工程師）還是 QA（測試工程師），這些所謂的Coding tools已經成為他們工作流程中一個不可或缺的「組件」。\u003C/p>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>現象：\u003C/strong>雖然每個角色的應用深度不同，有的團隊用得精細、有的用得樸實，但「在日常工作中使用 AI」已經形成了共識。\u003C/p>\u003C/li>\u003Cli>\u003Cp>\u003Cstrong>關鍵點：\u003C/strong>這代表 AI 已經脫離了「新鮮感」的階段。我們看到的不再是「AI 能幫我解決工作中某一個問題」這種小確幸，而是 AI 如何被編織進開發環境、專案管理工具與測試框架中。\u003C/p>\u003C/li>\u003C/ul>\u003Cp>這種普及化帶來的第一個警示是：當「使用 AI」變成及格線，競爭的維度就發生了位移。\u003C/p>\u003Ch2>觀察二：單點應用的瓶頸 vs. 流程閉環的協作\u003C/h2>\u003Cp>這是我在競賽中觀察到最深刻的斷層。過去在流程跟協作上，還在修修補補的執行團隊，他們的思考邏輯仍停留在「單點應用」上。\u003C/p>\u003Cp>\u003Cstrong>什麼是單點應用？\u003C/strong>\u003Cbr class=\"hard-break\">例如，RD 用 AI 生成程式碼片段，PM 用 AI 整理需求草案。雖然這確實提升了「產出速度」，但如果我們拉長視角看整個系統流程，會發現整體的開發效率依然被卡在「環節與環節之間的轉換」。\u003C/p>\u003Cp>\u003Cstrong>「AI 膠水」與流程閉環（Closed-loop）\u003C/strong>\u003Cbr class=\"hard-break\">目前領先的團隊（特別是主流大公司的核心部隊），基本早就完成所謂的「流程閉環」。在現代化的 SDLC 中，AI 扮演的角色不只是產出內容，而是\u003Cstrong>「銜接（The AI Glue）」\u003C/strong>。\u003C/p>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>自動化銜接：\u003C/strong>過去從 PRD（需求文案）轉化為技術設計文件，再由技術設計轉化為測試案例，中間需要大量的人工對接、會議溝通與確認。現在，這些轉換層是由 AI 來串接。\u003C/p>\u003C/li>\u003Cli>\u003Cp>\u003Cstrong>競爭點的轉移：\u003C/strong>誰能用 AI 銜接得更快、更準確、且更能解決跨職能的溝通誤差，誰就是贏家。\u003C/p>\u003C/li>\u003Cli>\u003Cp>\u003Cstrong>核心痛點：\u003C/strong>如果思維還停留在單點運作，雖然寫 Code 變快了，但如果前後環節依然靠人工手動搬運資訊，整體的 Lead Time（交付週期）並不會縮短太多。這正是目前主流大廠與一般團隊之間，最可惜的一段差距。\u003C/p>\u003C/li>\u003C/ul>\u003Ch2>觀察三：QA 自動化的「虛假繁榮」與驗證斷層\u003C/h2>\u003Cp>這是我最想深入談的一點。在競賽中，我們看到不少 QA 團隊開始利用 Claude、Codex 或相關工具來開發自動化測試。這件事表面上看來，是讓過去不具備程式能力的 QA 擁有了自動化武裝，但實際上卻隱藏著極大的技術風險。\u003C/p>\u003Cp>\u003Cstrong>「翻譯官」能力的缺失\u003C/strong>\u003Cbr class=\"hard-break\">過去，一個優秀的自動化 QA 必須具備「轉化（Translate）」的能力。所謂轉化，是能理解 Test Case 的核心意圖（要驗證什麼業務邏輯），並將其有效率地編寫成程式腳本來執行。這個「人為轉化」的過程，本質上就是一種\u003Cstrong>「邏輯審計」\u003C/strong>。\u003C/p>\u003Cp>然而，現在的情況是：\u003C/p>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>無法驗證的結果：\u003C/strong>因為 AI 生成腳本太容易了，許多不具備開發背景的 QA，缺乏耐心（甚至缺乏能力）去逐行審核 AI 寫出來的 Automation Code 是否真的符合原本 Case 的預期。\u003C/p>\u003C/li>\u003Cli>\u003Cp>\u003Cstrong>關聯性斷裂：\u003C/strong>當 QA 叫 AI 生成測試腳本時，他無法確認 AI 寫出來的邏輯跟需求文件是否「對在一起」。他以為 AI 幫他做好了自動化，但實際上那段程式碼可能只是跑了一段無意義的驗證，那結果我們就不用談對錯了。\u003C/p>\u003C/li>\u003Cli>\u003Cp>\u003Cstrong>幻覺安全感：\u003C/strong>這是我認為最危險的點。當 AI 產出的測試結果顯示 \"Everything's fine\" 時，QA 會因為看見 Passed 而感到心安，卻忽略了 AI 可能根本沒有抓到真正的驗證點。\u003C/p>\u003C/li>\u003C/ul>\u003Cp>\u003Cstrong>驗證（Verification）才是深水區的考驗\u003C/strong>\u003Cbr class=\"hard-break\">目前主流意見公認，不論是 Vision-based（視覺化操作）還是 Text-based 的驗證，在真正應用於複雜的 SDLC的驗證時，距離「完全可信」還有一段距離。\u003C/p>\u003Cp>驗證網頁功能，對人來說，可能對錯一看便知；但自動化測試程式碼，如果你沒有能力判斷其邏輯深度，你根本不懂 AI 幫你驗出來的東西，到底是「真對」還是「假對」。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>總結與建議：建立「嚴格約束」的思維\u003C/h2>\u003Cp>面對這三個觀察點，我想給所有正在推動 AI 轉型的團隊幾個具體的注意方向：\u003C/p>\u003Col>\u003Cli>\u003Cp>\u003Cstrong>告別單點思維，投資「流程銜接」：\u003C/strong>重新審視你的 SDLC。不要只問「AI 能幫 RD 做什麼」，要問「AI 能如何縮短 整個交付流程 的轉換損耗」。\u003C/p>\u003C/li>\u003Cli>\u003Cp>\u003Cstrong>重新定義 QA 的角色：\u003C/strong>在 AI 時代，QA 的核心競爭力不再是「寫出腳本」，而是「審計邏輯」。如果你不具備理解 AI 自動化測試的能力，你就無法對測試結果負責。\u003C/p>\u003C/li>\u003Cli>\u003Cp>\u003Cstrong>建立 Strict Condition（嚴格約束）：\u003C/strong>不要讓 AI 在模糊的語義下自由發揮。在自動化流程中，必須由具備邏輯判斷能力的人，為 AI 設定明確的衡量標準與驗證邊界，然後，才是在這個邊界下，讓 AI 努力地去替代勞動力。\u003C/p>\u003C/li>\u003C/ol>\u003Cp>AI 的應用已經從「會聊天」演進到「能協作」。在這個階段，我們最需要的除了更強大的模型，而是更嚴謹的驗證意識。唯有當我們能有效地驗證 AI 的產出，這份效率的提升才具備真實的價值，而不是一場建立在沙灘上的虛假繁榮。\u003C/p>\u003Cp>\u003C/p>\u003Ch2>下一步，我們可以做什麼？\u003C/h2>\u003Cp>如果你也觀察到了團隊中存在「AI 銜接斷層」或「QA 驗證困難」，或許我們可以深入聊聊：如何建立一套有效的「AI 輸出審計體系」？\u003C/p>\u003Cp>\u003Cbr class=\"hard-break\">這不只是技術問題，更是管理與流程設計的挑戰。希望這篇觀察能帶給你一些啟發，讓我們在 AI 的深水區裡，不只是游得快，更能游得遠。\u003C/p>\u003Cp>\u003C/p>",null,"AI應用, 流程閉環, 自動化測試, 軟體開發生命週期, SDLC, QA自動化, 工具普及化",[18,25,32],{"id":19,"slug":20,"title":21,"excerpt":22,"image":23,"date":24,"category":15},"deb70edd-ff7f-4b6e-b230-fa1c83dc0afa","qaptly-v0175-codex-support","Qaptly Desktop 開始支持 Codex","Qaptly Desktop 的 AI Assistant 從 v0.17.5 開始正式開放 Codex 支持。如果你本來就是 ChatGPT 訂閱用戶，現在可以直接讓 AI Assistant 使用 Codex，在日常測試設計與自動化調整上節省成本。","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/blog_pictures/qaptly_support_codex.jpg","2026-05-16T13:01:00+00:00",{"id":26,"slug":27,"title":28,"excerpt":29,"image":30,"date":31,"category":15},"eebc38be-6eec-4e68-af7f-e5dd6c611a0f","ai-agent-workflow-critical-things","AI 協作進入 workflow 之後，那些最容易被低估、卻最關鍵的幾件事","過完年後，基本上都在幫幾間新創與大公司內部的開發部門導入 agentic development。這段時間看了不少團隊的做法，也有一些很直接的感受，想趁這個機會整理一下。","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/articles/ai-workflow.jpg","2026-03-24T16:10:00+00:00",{"id":33,"slug":34,"title":35,"excerpt":36,"image":37,"date":38,"category":15},"f8ca9973-a5ea-41fe-9a1c-a9a921f8244f","pikmin-with-fake-gps","原來測試工具也可以拿來玩","我們為什麼願意開放「跳過 Accessibility 檢查」的能力、這個設計背後的工程與產品思考，以及 Qaptly Auto for Android 如何在「正式測試」與「非典型使用場景」之間，保持工具的彈性與邊界。","https://hfrcmkawcuoorqukvkpe.supabase.co/storage/v1/object/public/pictures/blog_pictures/pikmin_qaptly_gps_mock.jpg","2026-02-03T12:44:00+00:00",{"slug":34,"title":35,"date":38},{"slug":27,"title":28,"date":31},[42],"zh",1786442173671]