沒有程式背景的人，可以用 AI 開發平台做出公司內部的合約管理系統。我訪談的一位法律背景受訪者，在不知道系統用 Python 還是 JavaScript 寫成的情況下，用 Lovable 做出含登入驗證、合約風險標示、通知信與遠端核准的內部系統，依他的說法已正式上線使用。他能做到，靠的是講得清楚合約流程要怎麼走、做出來的結果能不能驗收，以及平台背後的模型有排錯能力。不過合約屬於敏感資料，系統做得出來，不等於可以不經檢查就上線，這一點本文後半會說明。
這位法律背景受訪者做出了什麼系統？
受訪者做出的內部合約系統，有公司帳號驗證、Word 合約上傳與風險條款標示、合約資料庫、自動通知信，以及主管點擊信件連結即可完成的遠端核准。
這位受訪者過去沒有資訊產業或程式相關經驗。他在人工智慧應用課程裡第一次接觸 Lovable、Emergent 這類 AI 開發平台，當時並沒有打算轉型成開發者。真正的起點是一個實際需求：公司需要能管理合約與簽核流程的內部系統。整套系統由對話驅動，他與平台反覆溝通、修正、測試完成。
| 功能 | 對應的合約工作 |
|---|---|
| 公司帳號身分驗證 | 整合企業現行登入體系，只有公司成員能進入 |
| 上傳 Word 格式合約 | 自動分析內容，把較具爭議的條款標示為高風險條款 |
| 完整資料庫架構 | 合約資料永久儲存、隨時讀取更新，並記錄審核狀態與進度 |
| 自動化通知機制 | 主動寄信給需要審閱的主管，或通知員工合約狀態有變 |
| 遠端核准流程 | 上級主管點擊信件內的連結，就能完成審核 |
上圖是受訪者提供的系統畫面。上方文件清單會標示偵測到的風險，下方是 AI 產生的九點檢核清單，使用者要逐點對照合約後再確認，也就是系統把判斷的最後一步留給了人。為保護受訪者與客戶資料，原圖上方含人名與範本名稱的區塊已裁去，文件名稱也已模糊處理。
Lovable 是什麼？平台替非工程人員承擔了哪些技術工作？
Lovable 是以 AI 為核心的線上應用程式開發平台，使用者用自然語言描述需求，就能在同一個平台內產生、預覽、測試並發布網站或網頁應用。
一般開發要先安裝編輯器與套件，理解專案結構。Lovable 把這些放在平台內，用對話當操作介面。Lovable 官方 FAQ 說明，使用者不需要程式經驗，平台是為各種程度的人設計的（Lovable Docs，FAQ）。
技術並沒有消失，只是被抽象化。資料庫、後端邏輯、身分驗證與部署流程依然存在，只是複雜度由平台與模型吸收了。
| 層面 | 傳統做法需要的角色 | 本案由誰處理 |
|---|---|---|
| 前端畫面 | 前端工程師 | 平台依對話生成，受訪者看預覽、提修改 |
| 後端邏輯與通知 | 後端工程師 | 平台與模型生成，受訪者驗收結果 |
| 資料庫 | 資料庫工程師 | 平台建立，受訪者確認欄位與狀態是否符合流程 |
| 身分驗證與部署 | 工程與維運人員 | 平台代管，受訪者確認誰能登入 |
當我問他系統是 Python 還是 JavaScript 寫的，他回答「我不知道」。這是分工改變的結果：底層交給模型與平台，他負責四件事。
- 系統需要完成什麼。
- 流程是否符合公司實際運作。
- 結果是否可以驗收。
- 哪些環節需要修正。
遇到 Webhook 設定失敗、API 金鑰失效，沒有技術背景要怎麼除錯？
沒有技術背景的開發者，可以把錯誤畫面截圖交給 AI，讓模型閱讀錯誤訊息、推論原因，再依步驟調整設定，這是受訪者全程採用的除錯方式。
受訪者遇過 webhook 設定問題、API token 無法運作、JSON 欄位格式不符、模組未觸發、訊息未成功傳送。他沒有研究技術文件，而是截圖貼給 AI，照指示一步步調整。他坦言自己並不理解底層邏輯，系統最後仍然運作了。
截圖交給 AI 的除錯循環能成立，取決於模型等級。受訪者試過別的工具，遇到問題時對方只建議聯絡客服或查文件，無法進一步分析原因。換成針對特定技術強化過的高階模型後，平台能讀錯誤訊息、推論來源、提供修正步驟，並協助重新配置設定。依他的經驗，差異不在介面，而在模型的推理與排錯能力。
完成合約系統之後，他又做了什麼？
受訪者接著串接 Gmail、Outlook、行事曆與 LINE Bot，做出個人智慧秘書，每五小時彙整重要郵件與未完成行程，並用 LINE 推播提醒。
個人智慧秘書整合了 Gmail、Outlook（含多個帳號）、行事曆與 LINE Bot。最核心的是他自己寫的一段 System Prompt，用來定義「什麼算重要」，例如與合約相關的郵件、需要即時回覆的事項、特定關鍵字、指定寄件人。平台依這些規則把內容排成高、中、低，濾掉大量群發電子報與非必要信件。定義重要性的是他，不是工程師，這是領域知識直接進入系統的一個例子。
合約這類敏感資料，上線前要檢查什麼？
合約系統上線前，要確認資料庫的存取權限、是否含受規管資料，以及有人負責維護；平台的安全掃描只能輔助，不能保證沒有漏洞。
書稿沒有描述受訪者的系統上線前做過哪些資安檢查，這是案例的空白，也是讀者最容易忽略的部分。以下是依官方資料整理的檢查重點，並非受訪者的做法。
| 檢查項目 | 依據 | 要做什麼 |
|---|---|---|
| 資料庫存取權限 | 公開弱點編號 CVE-2025-48757 記載，Lovable 截至 2025-04-15 的版本，因資料庫列級安全政策不足，遠端未驗證的攻擊者可讀寫所產生網站的任意資料表；供應商對此提出異議，主張各客戶要自行負責保護應用資料（CVE Program，2025 年 5 月） | 確認每張資料表都設了存取規則，登入與未登入的人各能讀寫什麼 |
| 平台安全掃描的限度 | Lovable 官方 FAQ：掃描「支援安全開發，但不保證」，並建議處理敏感資料或關鍵功能的應用做專業安全審查（Lovable Docs，FAQ） | 把掃描結果當成輔助，另請資安或工程人員審查 |
| 受規管資料 | Lovable 官方 FAQ：標準條款不允許健康、信用卡、政府證件等受規管資料，需先聯絡業務（Lovable Docs，FAQ） | 先確認合約內容是否含個資或這類資料，再決定能不能放進去 |
| 維護責任 | 受訪者的系統已上線，但書稿未說明誰負責長期維護 | 指定一位負責人，處理錯誤、權限調整與備份 |
比較穩妥的做法，是先用平台做出原型，讓工程或資安人員檢查權限與資料流，再決定要不要正式使用。
哪些條件可以借鏡？
合約系統案例可借鏡的條件是需求清晰、動機強烈、願意持續試錯，並使用能排錯的高階平台；但資安與長期維護需另外安排。
書稿整理出這類使用者的三項特徵：需求清晰、動機強烈、願意持續試錯。下表是我把案例拆開後，建議讀者複製前先確認的事。
| 要確認的事 | 案例中的情況 | 若不成立會怎樣 |
|---|---|---|
| 有沒有明確且切身的需求 | 公司真的需要合約與簽核系統 | 沒有真實需求，容易停在試做 |
| 平台與模型能不能排錯 | 高階模型能讀錯誤並提出修正 | 遇到錯誤只能自己查，容易卡住 |
| 能不能判斷結果是否正確 | 法律背景者能判斷風險條款標示是否合理 | 看不出結果對不對，系統再完整也不能信 |
| 資料是否敏感 | 合約屬於公司內部資料 | 需要先處理權限、存取紀錄與資料存放位置 |
常見問題
完全不會寫程式，可以用 Lovable 做公司內部系統嗎？
以這個案例來說可以。受訪者沒有程式背景，仍完成了含資料庫、登入與通知的系統。他能做到，是因為清楚知道合約流程，並且能判斷結果是否正確。
Lovable 做出來的系統，需要自己懂資料庫與後端嗎？
在這個案例裡不需要，資料庫、後端與部署由平台處理。使用者要懂的是流程與資料的意義，例如合約有哪些狀態、誰有權限核准。
遇到錯誤訊息看不懂，該怎麼辦？
受訪者的做法是把錯誤畫面截圖交給 AI，請模型分析原因並給出修正步驟。如果模型只回覆「請聯絡客服」，可能是工具或模型等級不足，可以換更強的模型或平台再試。
AI 標示的合約高風險條款可以直接採信嗎？
不建議。案例中的系統也要求使用者逐點對照合約再確認。AI 的標示適合當作提醒，最後的法律判斷仍應由專業人員負責。
Lovable 做的系統可以放合約這類敏感資料嗎？
要先確認。官方說明標準條款不允許健康、信用卡、政府證件等受規管資料，且安全掃描不保證沒有漏洞。涉及合約的系統，上線前請工程或資安人員檢查權限與資料存放。
資料來源與說明
案例整理自我在撰寫書稿期間，對十多位具有 Vibe Coding 或 AI 寫程式經驗的使用者所做的訪談，內容為受訪者的自述。系統功能、已正式上線與使用情形未經第三方查核，訪談時間書稿未標示。平台功能與條款會調整，請以官方說明為準。
參考資料
- Lovable，〈FAQ〉，Lovable Docs，現行文件，存取日期：2026 年 10 月 19 日。
- CVE Program，〈CVE-2025-48757〉，2025 年 5 月 30 日發布，存取日期：2026 年 10 月 19 日。
延伸閱讀
- AI 一天寫完工具，為什麼上線卻卡了近一個月？：同樣是非工程背景者開發內部工具，但卡在部署。
- AI 時代，為什麼懂工作流程的人也能參與系統開發？：從職務能力的角度，理解這類案例為何成立。
- 中小企業導入 AI 從哪裡開始？從工作流程找出真正值得做的專案：決定第一個內部工具該做什麼的評估方法。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19