自我介紹
初次見面，我是株式會社辛西亞的徐 聖博。
在株式會社辛西亞，我們除了承接 Web 系統與行動 App 的委託開發、IT 人才媒合之外，目前也以新事業的形式開發名為「Dandori AI」的服務。
Dandori AI 是一項面向活動產業、協助製作報價與整理案件的 AI 服務。
我們公司在推動新事業開發的過程中，不只是工程師，Biz 端成員也會活用 AI 參與產品開發。
由於我是工程師出身，最近也會針對 Biz 端成員，進行使用 Claude Code、Cursor 等 AI 程式開發代理工具的培訓。
這篇文章會介紹我們實際在做的「Biz 端在產品開發中的 AI 活用」。
是否每次都把「小改動」交給工程師？
「我想稍微修改一下系統這裡」
當你這麼想的時候，是否每次都用 Slack 去找工程師幫忙？
當然，我並不認為所有開發都應該由非工程師自己完成。
不過，若是以下這類小型修改，透過 AI 程式開發代理工具，非工程師現在也已經能自己處理相當大一部分了。
- UI 文案修改
- 按鈕顏色變更
- 連結目的地變更
- 圖片替換
- 簡單的版面調整
- 錯誤訊息改善
- LP 或後台的輕微修改
過去被認為「只能請工程師處理」的部分，如今正逐步因 AI 而向 Biz 端開放。
這篇文章會整理出非工程師使用 AI 進行小型系統修改的實作步驟。
過去的系統修改，為什麼會花這麼多時間？
以往，即使是小修改，也很容易變成下面這樣的流程。
- Biz 端向工程師提出修改需求
- 工程師確認內容
- 若有認知落差，再額外提問
- 工程師實作
- Biz 端確認
- 若還要修改，再重新提出需求
這種來回本身是必要的。
但即使只是把按鈕文案改一點、或是替換連結目的地，只要發生這樣的往返，就可能花上數小時到數天。
結果就是，Biz 端會變成「反正只是小改，先擱著吧」，工程師則會覺得「瑣碎需求太多，無法專注在核心開發上」。
從事業速度的角度來看，這其實相當可惜。
使用 AI 程式開發代理工具後，會有什麼改變？
使用 Claude Code 或 Cursor 這類 AI 程式開發代理工具後，Biz 端自己就能先處理第一線的修改。
只要向 AI 說明：
- 是哪個畫面
- 哪個位置
- 想怎麼改
- 什麼不能改
AI 就能幫你搜尋程式碼、提出修改方案，甚至有時還能直接幫你改好。
例如，像這樣的需求：
請修改管理後台的使用者列表頁面，
把「查看詳情」這個按鈕文案
改成「確認個人檔案」。
請不要變更既有邏輯，只改文案。
也請告訴我修改了哪些檔案。這樣一來，AI 就會去找出對應的程式碼並幫你修改。
當然，最後還是需要確認與審查。
不過，「不知道該改哪裡」這個最初的門檻，已經大幅降低了。
非工程師容易上手的 AI 程式開發工具
代表性的選擇如下。
| 工具 | 特點 | 非工程師適用性 |
|---|---|---|
| Cursor | 基於 VS Code 的 AI 編輯器。可以一邊看畫面上的程式碼，一邊向 AI 提出需求 | 最容易上手 |
| Claude Code | 在終端機上運作的 AI 程式開發代理工具。擅長多檔案修改 | 需要一些熟悉度 |
| GitHub Copilot | 可在編輯器內進行程式碼補全與聊天 | 較偏向開發者使用 |
如果非工程師第一次要用，我個人覺得 Cursor 最容易入門。
原因很簡單，因為即使不會直接寫程式碼，也能在畫面上和 AI 對話，同時確認變更內容。
另一方面，Claude Code 一旦上手會非常強大。它很適合跨多個檔案的修改，以及既有程式碼的調查。
向 AI 提出需求時需要的 3 個資訊
想讓 AI 更好地幫你修改，提出需求的方式很重要。
至少要傳達以下 3 項資訊。
1. 在哪裡：對象頁面或畫面
首先，要告訴 AI 你想修改哪個畫面。
錯誤範例：
- 幫我修一下那個後台
- 把使用者那邊改一下
- 修改平常那個列表頁
這樣 AI 無法特定目標。
正確範例：
https://example.com/users的使用者列表頁- 後台的「發票列表」頁面
- 登入後從左側選單的「設定」進入的公司資訊畫面
如果有 URL，直接貼上最快。
2. 什麼地方：對象區塊
接著，要說明頁面中的哪個部分要修改。
正確範例：
- 頁面右上角的「聯絡我們」按鈕
- 使用者列表表格中的「狀態」欄
- 個人檔案詳細頁顯示的姓名
- 註冊表單下方的錯誤訊息
即使不知道檔案名稱或元件名稱也沒關係。
只要用「畫面上看得到的名稱」來描述，AI 會幫你搜尋程式碼並找到相應位置。
3. 想怎麼改：修改內容
最後，說清楚你希望如何變更。
錯誤範例：
- 幫我弄得更好看一點
- 改得更容易懂
- 幫我弄得更帥一點
正確範例：
- 把按鈕背景改成藍色，文字改成白色
- 把「送出」這段文案改成「申請免費諮詢」
- 只有在狀態是「處理中」時，才把文字顏色改成橘色
- 點擊姓名後，導向 LinkedIn 的網址
對 AI 來說，越具體的修改內容，效果越好；比起抽象描述，具體指示更有效。
可直接使用的需求模板
用下面這種格式提出需求，會更容易傳達。
請修改以下畫面。
對象畫面：
https://example.com/users
對象區塊：
使用者列表表格的「狀態」欄
想修改的內容：
當狀態是「處理中」時，請把文字顏色改成橘色；
當狀態是「完成」時，請把文字顏色改成綠色。
注意事項：
- 請盡量不要變更既有顯示邏輯
- 只修改外觀
- 修改後請說明變更了哪些檔案
- 如果可能會影響其他功能，請先告訴我重點是把「對象畫面」、「對象區塊」、「修改內容」、「注意事項」分開寫。
光是這樣，AI 的準確度就會提升很多。
實際作業步驟
以下是使用 Cursor 時的流程。
步驟 1：在 Cursor 開啟專案
首先，在 Cursor 中開啟目標專案資料夾。
非工程師要自行完成這一步有時會有困難。
如果是這樣，第一次可以先請工程師幫忙如下：
請用 Cursor 開啟這個專案，
並把本機環境設定成可以確認畫面的狀態。
之後我想在 AI 的協助下，
自己嘗試做一些簡單的文案修改與 UI 修改。做到這一步之後，後續的小型修改就會更容易自己推進了。
步驟 2：向 AI 聊天視窗提出修改需求
在 Cursor 的 AI 聊天中輸入以下內容：
請將 https://example.com 的首頁中，
頁面右上角的「聯絡我們」按鈕背景色改成藍色（#0066CC），
文字色改成白色（#FFFFFF）。
修改後請告訴我你改了哪些檔案。AI 會找出對應檔案並提出變更方案。
步驟 3：確認差異
當 AI 修改程式碼後，系統會顯示哪些檔案、哪些部分被變更。
非工程師至少要確認以下幾點：
- 被修改的檔案數是否過多
- 是否有看起來無關的檔案被改到
- 是否有刪掉不該刪的處理
- 是否與你要求的文案或顏色一致
即使不能完全讀懂程式碼，只要確認「有沒有明顯怪異的變更」就很有意義了。
步驟 4：在瀏覽器中確認
在本機環境實際打開畫面，確認修改結果。
例如如果是 Next.js 這個框架，通常會用類似以下網址來確認。
※ 環境設定與確認畫面請與工程師協作確認。
http://localhost:3000確認時要看以下幾點：
- 你要求修改的地方是否已改動
- 其他顯示是否有跑版
- 按鈕或連結是否正常運作
- 在手機寬度下是否有明顯跑版
比起 AI 的說明，更應該優先確認實際畫面。
步驟 5：提出審查需求
如果看起來沒問題，就向工程師提出審查需求。
非工程師不需要一開始就直接做正式環境上線。
反而在初期運作上，建議由非工程師負責「用 AI 做出修改方案」，而「審查與正式上線」則由工程師負責，這樣比較安全。
審查需求範例：
我使用 AI 修改了首頁的「聯絡我們」按鈕顏色。
本機已確認畫面正常。
請幫我審查修改內容是否有問題。照這樣的流程，Biz 端就能提升改善速度，同時也能由工程師確保安全性。
非工程師較適合用 AI 處理的修改
以下這些，非工程師也比較容易處理。
- 按鈕或標題文案修改
- 說明文、錯誤訊息、標籤文字修正
- 顏色、留白、字型大小調整
- 圖片替換
- 連結 URL 變更
- 顯示順序調整
- 依特定條件切換文案這類簡單的顯示邏輯修改
例如像這樣的需求：
請把價格頁面的「聯絡我們」按鈕文案，
從「申請免費諮詢」改成「先來聊聊看」。
請不要更動按鈕的顏色或大小。這類修改很適合交給 AI。
應該交給工程師的修改
另一方面，以下這些不應該只靠非工程師獨自推進。
- 資料庫資料表新增、欄位新增
- 與驗證、登入、權限管理相關的變更
- 與金流／付款流程相關的變更
- 與個資或資安相關的變更
- 外部 API 串接變更
- 基礎設施或伺服器設定變更
- 與大量資料處理或效能相關的變更
- 大幅改變既有功能規格的變更
這一類屬於事業風險與資安風險都很高的領域。
即使 AI 說「可以做」，也不應該直接往下推進。
如果不確定，可以這樣問 AI：
這個修改會影響資料庫、驗證、付款、資安、外部 API 或基礎設施嗎？
請判斷這是否屬於非工程師可以用 AI 修改的範圍，還是應該交給工程師處理。只要在這一步先問一下，就能更容易避開危險的修改。
避免失敗的注意事項
1. 不要直接碰正式環境
這一點最重要。
即使 AI 很方便，也不要直接編輯正式環境的程式碼。
務必依照以下流程進行：
- 在本機環境修正
- 在畫面上確認
- 請工程師審查
- 沒問題後再正式上線
這是最低限度的安全底線。
2. 不要全盤相信 AI 說的話
AI 有時候會很有自信地說錯話。
特別是當你問：
這個修改沒問題嗎？AI 很容易回答「沒問題」。
重點不是 AI 的回答，而是實際畫面與實際行為。
- 畫面有沒有跑版
- 是否有如預期運作
- 有沒有影響到其他功能
這些都一定要由人確認。
3. Git 操作最好一開始就先整理好
非工程師不需要把所有 Git 指令都學會。
但為了保留變更紀錄，Git 是必要的。
可以請工程師這樣協助：
請幫我整理成非工程師只要用自然語言請 AI 指示，
就能完成分支建立、變更保存、提出審查需求的流程。
例如我只要說：
「把目前變更存起來，幫我發出審查需求」
就能完成必要的 Git 操作。如果使用 Claude Code 或 Cursor，這類操作也能相當自然地透過自然語言完成。
4. 把修改範圍縮小
一次對 AI 提出太大的需求，很容易失敗。
錯誤範例：
請讓整個後台變得更好用。正確範例：
請把使用者列表頁搜尋框的 placeholder
改成「用姓名・電子郵件搜尋」。一開始最好一次只做一個修改，這樣最安全。
5. 如果不順利，就重設對話
在和 AI 一起作業時，討論可能會越來越複雜，導致修改方向變得混亂。
這時候不要硬撐下去，直接重設對話、重新從頭提出需求，反而更快。
剛才那個修改先全部忘掉。
我們重新開始。
對象畫面：
https://example.com/users
對象區塊：
使用者列表的搜尋框
修改內容：
請把 placeholder 改成「用姓名・電子郵件搜尋」。AI 本來就是要透過嘗試與修正來使用的。
不要期待第一次就完美，通常會更順利。
如果要在公司內部運用，最好制度化
當非工程師也能用 AI 進行修改時，現場的速度會明顯提升。
但如果毫無規則地進行，也會很危險。
若要在公司內部運用，至少應該訂出以下規則：
- 不要直接碰正式環境
- 不要處理資料庫、驗證、付款、資安相關內容
- 修改後一定要在本機確認畫面
- 正式上線前必須有工程師審查
- 每次修改範圍要小
- 不要直接相信 AI 修改的內容
- 在審查需求中寫清楚修改理由
只要有這些規則，非工程師也能更安全地活用 AI。
Biz 端能使用 AI，產品開發的推進方式就會改變
當 Biz 端也能使用 AI 之後，帶來的不只是「小修改變快」而已。
也會更容易把從客戶那邊聽到的問題，直接轉化成改善方案。
例如，客戶可能會這樣回饋：
- 這個按鈕名稱讓人看不懂
- 這個畫面不知道下一步該做什麼
- 錯誤訊息不夠友善
- 輸入欄位順序和實際作業流程不一致
過去，Biz 端必須先整理內容、再交給工程師、還要調整優先順序。
當然，這些流程未來還是需要。
只是有了 AI 之後，Biz 端自己就能先做出以下初步動作：
- 製作修改方案
- 請 AI 確認影響範圍
- 整理畫面上的改善想法
- 撰寫規格草案
- 若是簡單修改，甚至可以直接做出修改方案
這也會提升和工程師溝通的品質。
因為不再只是說「希望你幫我改一下」，而是可以說：「基於這個理由，我想把這個地方改成這樣，我也已經用 AI 做出修改方案，請幫我審查。」
我認為這對產品開發來說，是非常大的改變。
總結
隨著 AI 程式開發代理工具的出現，非工程師也進入了能參與小型系統修改的時代。
尤其是以下這些修改，只要善用 AI，就能更容易自己推進。
- 文案修改
- 按鈕與連結修正
- 顏色與留白調整
- 圖片替換
- 簡單的顯示條件變更
另一方面，與資料庫、驗證、付款、資安、基礎設施相關的變更，則一定要交給工程師。
重點不是讓非工程師取代工程師的工作。
而是讓 Biz 端能夠先推進小型修改，讓工程師能專注在更重要的設計、實作與審查上。
在未來的現場，「是否具備正確向 AI 提需求的能力」，會大幅影響業務改善與產品開發的速度。
我認為，最好的開始方式，就是先從改一個按鈕文案開始。
最後
株式會社辛西亞也積極招募非工程師的商務職人才。
我們公司正讓 Biz 端與工程師一同活用 AI，攜手推進新事業與產品開發。
如果你對業務、事業開發、客戶成功、產品改善等領域有興趣，也希望透過 AI 擴展自己工作的可能性，非常希望能有機會和你聊聊。
原文出處：https://qiita.com/yamadagenki/items/bc59607d940a9e87c189
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
