Responsible Vibe Coding

作者： -

圖片

昨天 “恰巧” 碰上了洗版全台的 vibe coding 事件，所以很多人以為我說 Responsible Vibe Coding 是玩笑話 ​😆

不~我是認真的。💪

你拿 Responsible Vibe Coding 這個字去網路上搜尋，就會發現，早已經有太多人在討論 Vibe Coding 帶來的風險以及如何因應。

特別是對於原本不在軟體開發領域的開發新手而言，有許多需要注意的事情，甚至已經有人針對 Responsible Vibe Coding 列出了 guidelines…

LLM確實讓進入軟體開發的門檻大幅下降，甚至有人用了 democracy 這個詞來形容(意味著過去被少數人壟斷的專有能力，如今已釋放給所有人…)，但這也是 吳恩達(Andrew Ng) 不喜歡 vibe coding 這個詞彙的原因 👉 讓人誤以為軟體開發從此就變得人人可做了。

然而其實不是的。

因為，專業 與 非專業 的差異，其實不只是能力，而是 『態度』。

專業不只是因為能力比較強，或是比較有經驗，也是因為願意去做那些流程中看似無聊和瑣碎的雜事，以至於我們的成品可以在安全性和品質上得到保障。

寫程式，或許變得容易了(反正都是AI寫嘛)，但寫出高品質的好程式，則依舊是專業人士才能作到的事情。

新手面對 Vibe Coding 到底該注意些什麼，如何才能兼顧品質、安全、和效率?

我把相關資訊，放在底下:
https://vibe-coding-manifesto.com/

https://medium.com/@harsz89/from-heads-down-to-hands-off-a-journey-into-responsible-vibe-coding-3d81a1c5634c

https://www.businessinsider.com/andrew-ng-vibe-coding-unfortunate-term-exhausting-job-2025-6

針對 vibe-coding-manifesto 這份給開發人員的 Responsible Vibe Coding 建議，整理如下:

Rules for AI-Assisted PR Submissions（AI 輔助的 PR 提交規則）

這一部分主要在講：如果你用 AI 幫忙產生程式碼，當你要把變更提交成 Pull Request（PR）／Merge Request 時，要遵守哪些好規範，以減少審查負擔、提高品質。
圖片
(Prepared by AI, Reviewed by David)

Project automation for the Vibe Coding/Review Workflow（Vibe Coding／審查流程的專案自動化建議）

這一部分則是在講，在一個支援 AI 輔助的開源或團隊專案裡，可以加一些自動化工具或檔案來讓 AI 與審查流程更順、更一致。

圖片
(Prepared by AI, Reviewed by David)

我覺得這些資源對於團隊準備走入以 vibe coding 為主的開發模式時，是一個很重要的提醒。

後記

昨天，敏捷大賞工作人員餐敘。
席間，有位好友問到，這兩天我都在談 Responsible Vibe Coding，但現在 AI 的能力已經比很多 “人類” 還強了。會不會有一天，我們能夠 “直接” 信任 AI 作的建議或決策? 而不需要再人為介入?

我說： 『不能!』
而且這是使用 AI 的人『永遠的責任』。

如今，我們大概不可能阻止學生使用 AI 來幫忙寫作業或是潤飾論文，甚至有些學校是鼓勵學生這麼做的。作家們也開始使用 AI 幫忙創作，但這些行為的前提是 👉 你必須詳細閱讀 AI “為你” 產生出來的每一個字，而非蒙著眼照單全收。

因為你才是那位作者，AI 不是。

同樣的，vibe coding 的主體是誰? 是開發者。
AI 只是 “幫你” 產生 程式碼，而非替你完成一個系統。

請注意，這兩者有天大的差別。

如果有朝一日 AI 不需要產 code 了，可以幫你直接做出成品，過程中不是 “藉由” 程式碼這媒介，那我就不會說你必須去作 code review，必須對產出的 code 負責(因為根本沒有 code 了)。

到了那一天，你只需要對成品作黑箱測試，對結果負責即可(對，你還是得負最終責任)。

但現在不是，現在 AI 並非幫你產生整個系統，而是幫你產 “code” ，你才是那個最終整合所有程式碼，把系統交付給用戶的那個人。

而正因為如此，你必須得 code review。

有人說：可是我又看不懂(或是沒時間看)這些程式碼啊? 怎麼辦?

就是不行，因為你必須為這份程式碼負責。

因為 (不去看程式碼的)這種行為，就好比一個書籍譯者，接了太多專案，開始叫 AI 幫忙翻譯，出了問題最後雙手一攤說：『我沒時間看完 AI 翻譯的東西啊，而且…其實我也看不太懂!』

這樣可以嗎? 當然不行。

因為你才是那個翻譯者，翻譯的稿費是你拿走的，並非直接付給AI。

說了這麼多，我只想說，vibe coding 不一定是壞事，甚至是一個未來會走的方向。但請牢記 Responsible Vibe Coding ，作一個負責任的 AI 工具使用者。

後記：順帶一提

剛說到的那個聚餐，來到了內湖一家相當老字號的餐廳，這餐廳號稱『台北最強烤鴨餐廳』。他們的烤鴨頗具盛名，網上大家是這樣形容的…
「皮脆肉嫩」、「鴨皮油亮酥脆」、「甜麵醬不死鹹還很香，是整道菜的靈魂」、「皮非常之脆且油而不膩」、「肉質多汁」、「鴨肉油脂豐富不乾柴」、「軟嫩好入口」、「無論是單吃還是沾甜麵醬都好吃」…

來來來，這就給大家品嘗一下…
圖片

圖片

你問我好吃嗎?
當然好吃，哪次有人請客我會說不好吃的。是吧~😁

留言

張貼留言

這個網誌中的熱門文章

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

在 ADO Pipeline 中使用 GitHub Copilot CLI：實現全天候24h開發的夢想

作者： -
圖片
我跟你說，我夢想著實現這個功能很久了✌ 我一直希望能夠在 CI/CD Pipeline 中加入 LLM 的力量。 我一直想透過 CLI 讓 LLM 在 Pipeline 中自動處理重複性任務。例如，在晚上讓 AI 自動幫我找 bugs、自動做 Code Review、甚至自動撰寫說明文件或一部分程式碼… 然後，我夢寐以求的 “兩班制全天候24h開發團隊” 就可以實現了!!! 白天，由 Developer 搭配 AI 進行開發。 晚上，由 AI 自己去做比較不需要人監督或無傷大雅的工作，像是寫文件，找 bugs 之類的。 然後隔天早上工程師上班之後，就可以繼續接手 AI 昨晚產出的成果，接著進行開發。 嘿嘿，這樣是不是太完美了? 想想都覺得興奮。 緣起 在現代軟體開發中，效率與自動化是不可或缺的要素。 GitHub Copilot CLI 的出現，為我們提供了一個強大的工具，能夠在開發過程中自動生成程式碼、撰寫技術文件，甚至協助除錯。 假設我能將這項工具整合到 Azure DevOps 的 Pipeline 中，自動在晚上運行，就可以實現我之前說的 全天候的開發流程 。(以前是把程式碼發包給印度的工程師，現在 AI 就是我的夜班工程師!!!) 嘗試在 Azure DevOps Pipeline 中使用 GitHub Copilot CLI 想要將 GitHub Copilot CLI 整合到 Azure DevOps Pipeline 中，有幾個關鍵步驟。 首先，你要能夠在 Build Agent 上安裝 GitHub Copilot CLI。要這麼做不難，只需透過底下這個 bash script 指令就可以完成安裝 。 npm install -g @github/copilot 只是，你得先確定 Node.js 已經安裝在你的 Agent 上，且是最新版本。 因此，我們會在 pipeline 中，先用一個 step 來安裝 Node.js。 steps : - task : NodeTool@0 displayName : 'Use Node 22.x' inputs : versionSpec : 22.x 接著，我們就可以安裝 GitHub Copilot CLI 了...
Read more »

原來使用 .net 寫個 MCP Server 如此簡單

作者： -
圖片
MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...
Read more »

VS Code的字體大小

作者： -
圖片
身為.net developer，這年頭是什麼code都得要會寫的年代。 而雖然我的NB還沒從Windows淪陷為Mac OS，但寫Node.js和Python免不了要用VS Code，這是一種愛的表現。 但歲月不饒人，盡管微臣非常熱於配合，但VS Code預設字體的大小在我還沒錢買大尺寸螢幕的狀況下，實在讓老臣難以適應。當下的第一個反應是什麼? 當然是 Ctrl+滑鼠滾輪往上推…哇靠，沒用。看…這設計…恩，千錯萬錯一定是我的錯。 只好從選單 file –> Preferences –> Settings: 在出來的視窗中，你可以看到 editor.fontsize: 沒錯，改它就行了。改不動? 喔，不好意思，我沒仔細看說明，要copy到右邊是吧，沒問題，copy->paste->modify->Save…搞定。 好簡單啊…連ctrl+(mouse scroll up)都用不到了呢… 咦?這是一篇抱怨文嗎? 沒有，誰說的? 免費的tool我們還有什麼好抱怨的呢…要感恩啦。 啊….對了，如果你還是堅持要使用 Ctrl+滑鼠滾輪，請找關鍵字… "editor.mouseWheelZoom"
Read more »