Vibe Coding 之後，誰來把軟體真正用起來？

概念插圖：第一版完成之後，維護和使用還會繼續。

在 TikTok 上看到 @blameanthony 談 Adobe 的影片，有一句話很有意思。他在貼文說明裡說，剪這支影片時 Adobe 崩潰了三次，自己還遇到了影片編碼格式的支援問題。於是他問：要不要用 Vibe Coding 做一個開源替代品？

但他也說，自己願意為 Adobe 付錢，前提是有人提供支援，修好問題，而且足夠快。

這讓「用 AI 做軟體」的討論多了一層。做出功能當然讓人興奮，真正開始使用之後，大家還會在意：出了問題，誰來處理？這個工具能不能一直用下去？

應用程式上線，工作才剛剛開始

Vibe Coding 縮短了從想法到第一版的距離。以前可能要安排開發時程的小工具，現在可以先做出來試試。對有明確需求的人來說，這很有吸引力。

不過，@blameanthony 的抱怨也提醒了我們：使用軟體時，打斷工作的往往是具體的小問題。打不開一個檔案、處理到一半崩潰、上次好用的功能突然出了錯，都足以讓人停下來。

自建工具同樣要面對這些事。第一版交付之後，回饋會繼續出現，使用方式會變化，也會有人提出最初沒想到的要求。

產生程式碼的速度可以很快，這些後續工作仍然需要時間。

多一個工具，也會多一處交接

在團隊裡，問題還會多一道：誰知道這件事，誰來接著處理？

回饋可能留在聊天裡，處理進度放在專案工具裡，相關客戶資料又在另一個系統。要決定先改什麼，往往得先把這些資訊找齊。

工具越容易做出來，這類整理工作就越值得注意。每多一個入口，都要想好收到的資訊去哪裡，處理結果又怎麼回來。否則，新工具雖然能用了，同事之間仍然要來回詢問和轉傳。

最容易漏掉的，是回饋處理之後的那一步。問題已經修好，提出問題的人卻沒收到回覆；團隊討論過暫時不做，下週又有人把它當作新需求提出來。記下處理狀態，再把結果送回原來的討論裡，能省掉不少重複溝通。

回饋有了紀錄、負責人和回覆，才算有人接著往下做。

讓新工具接上已有工作

Leina 關注的是這些日常工作。團隊可以在聊天裡交代任務，讓它透過已授權的 Apps 查詢相關資料，把分散的資訊整理到一起。能串接哪些系統、執行哪些操作，以實際支援和帳號權限為準。

你可以先交給它一項具體工作：

整理過去七天的產品回饋，合併重複問題，保留每條原始紀錄的連結。列出受影響的功能、目前狀態和紀錄中已有的負責人；沒有寫明的標成待確認。另列出已經處理、但還沒有回覆使用者的問題。先把整理結果發到這裡。

這份結果有兩個用途：幫助團隊決定先處理什麼，也幫助負責溝通的人找到該跟進誰。它不需要替團隊猜優先順序，先把遺漏呈現出來就有價值。

檢查幾次之後，把有效的整理方法儲存為 Skill。這樣，AI 除了幫忙做出第一版，也能參與軟體投入使用之後的日常整理。

從上線後的第一週開始

如果你剛用 AI 做出一個工具，可以先觀察它投入使用後的第一週：

• 哪些資訊仍要手動搬到別處？
• 誰在反覆詢問進展或補充背景？
• 哪些提交已經收到，卻沒有進入下一步？

選一項最常發生的整理或交接，看看能不能少花一點時間。

回到那支 Adobe 影片，願意自己做替代品和願意付訂閱費，其實可以出現在同一個人身上。大家想要的很樸素：手邊的事能夠順利做完，遇到問題有人處理。

AI 讓第一版來得更快。之後的每一天，也值得有人照顧。

建立 Leina，從一週的真實回饋試起。先在整合目錄確認資料所在的服務和所需操作是否支援；確認能完成後，可以把這套要求儲存為 Skill，留給下一次使用。