近年來隨著大型語言模型（LLM）的推理能力提升，以及 Agentic Workflow（代理工作流）的成熟，AI 與軟體開發的協作已經從單純的「程式碼自動補全（Auto-complete）」，演進到「脈絡感知（Context-Aware）」與「自主代理（Autonomous Agents）」的深度結合。

以下整理近期在業界與技術社群中，因 AI 發展而延伸出的核心軟體開發新模式：

1. 脈絡導向開發（Context-Driven Development）

這是「附上規格書」的進化版。現在的模式不再只是盲目下 Prompt，而是極度重視「給予 AI 精準的邊界與架構成束縛」。

  • Schema-Driven 驅動模式： 在請 AI 生成 API 或後端邏輯前，先餵給 AI 完整的資料庫 Schema（如 PostgreSQL 的 DDL）或 OpenAPI/Swagger 規範。AI 以 Schema 為絕對真理（Ground Truth），能大幅減少欄位對錯、型態不符的幻覺。
  • UI-to-Code（視覺脈絡輸入）： 利用多模態模型（Multimodal），直接將 Figma 截圖、手繪原型（Wireframe）丟給 AI，並要求其結合現有的組件庫（Component Library），直接生成前端程式碼。
  • 「最少異動」與「補丁」模式（Diff-Based Refactoring）： 在既有的大型系統中，最忌諱 AI 把整段 Code 重寫。新模式是利用 Prompt 限制 AI 只能輸出 git diff 格式，或是明確指定「逐條修改（Line-by-line edit）」，確保只動到核心邏輯，不破壞原有的架構與連帶關係。

2. 智能化運維與架構（AI-Native DevOps & SRE）

DevOps 與 AI 的結合已經從單純的腳本撰寫，走向自動化觀測與自我修復。

  • RAG 導向的日誌分析與故障排除： 當系統發生 Exception 或 CI/CD Pipeline 失敗時，系統會自動將錯誤日誌（Logs）結合內部的知識庫（如內部的微服務架構圖、過去的 Postmortem 文檔），由 AI 自動診斷並給出修復建議（Fix Suggestion）。
  • 自動化架構與配置生成： 根據系統流量與安全需求，由 AI 評估並生成對應的 Kubernetes Manifests、Terraform 腳本或部署策略，甚至是自動調整 DB 連線池（Connection Pool）等配置。

3. 代理人工作流（Agentic Workflows in Coding）

這是近期最重大的典範轉移。過去是「人下指令，AI 執行」；現在是「人給目標，AI 組隊執行」。

[使用者設定目標] ──> [主管 Agent: 拆解任務] ──> [工程師 Agent: 寫 Code] ──> [測試 Agent: 跑測試/找 Bug] ──> [回報結果]
  • 多代理人協作（Multi-Agent Swarms）： 如 Devin、OpenAI Operator 或開源的 AutoGen、CrewAI 等概念在軟體開發的落地。一個任務會被拆解給多個虛擬角色：
  • Architect Agent： 負責分析需求，規劃系統設計與資料庫架構。
  • Coder Agent： 負責專注編寫符合架構的程式碼。

  • Tester Agent： 自動根據撰寫的 Code 生成單元測試（Unit Test），並在沙盒中執行，若失敗則把錯誤丟回給 Coder Agent 修正，直到測試全過才交付。

  • Repository-Level 靜態分析與重構： AI 不再只看單一檔案。透過將整個專案的抽象語法樹（AST）與向量資料庫（Vector DB）結合，AI 代理人可以自主理解整個 Repo 的依賴關係，進行跨檔案、跨模組的系統級重構。

4. 測試驅動與逆向工程（Test-Driven AI Development）

AI 非常擅長處理結構化、邏輯明確的任務，這讓測試開發模式有了翻天覆地的改變。

  • AI-Generated TDD（測試驅動開發）： 工程師或 PM 輸入業務邏輯需求，由 AI 先生成極度嚴格的測試案例（Test Cases）與邊界條件。接著，再由 AI 或工程師編寫程式碼去通過這些測試。這種「測試先行」的模式能有效防範 AI 的邏輯滑坡。
  • 逆向規格化（Inverse Specification）： 面對缺乏文件、前人留下來的「屎山（Legacy Code）」，現在的新模式是把舊程式碼丟給 AI，讓它逆向工程推導出當初的系統設計書、API 規格（JSON/YAML）以及資料流向圖，大幅降低維護與轉移陣痛。

5. 知識庫與 RAG 協同開發（Repo-Specific RAG）

在大型團隊或特定領域（如特定醫療法規、企業內部私有專案），通用的 AI 模型往往派不上用場。

  • 內聚型 AI 助理： 企業開始建構結合內部編碼規範（Coding Style Guides）、架構白皮書、以及底層 API 的私有 RAG 系統。工程師在開發時，AI 給出的建議會自動符合公司內部的安全性標準（如 SQL Injection 防範規範）與設計模式，而不是網路上抓下來的通俗寫法。

Q：因為同仁下prompt，造成每週同一個產品都長不一樣，每次要修的bug都會變，對我來看等於每周都從頭開始

A：這完全能理解您的痛苦。這是目前許多技術團隊導入 AI 協作時最常踩到的重災區——我們稱之為「AI 程式碼流失（AI Code Churn）」或「無邊界重構（Unbounded Refactoring）」。

當同仁把 AI 當作「每次都重新許願的神燈」，而不是「接手既有專案的工程師」時，AI 因為缺乏歷史脈絡（Context）與邊界約束，就會每次都用它當下認為「最完美」的另一種寫法來生成程式碼。這對負責把關架構與解決問題的管理者來說，無疑是一場災難。

要解決這個問題，必須將團隊從「Freestyle 下指令」轉變為「工程化協作模式」。以下是幾種能立即改善這個亂象的實務作法：

1. 確立「絕對錨點」：以資料庫與介面規格為尊

既然 AI 喜歡發散，就必須給它不可踰越的邊界。在團隊的 AI 協作規範中，必須確立「核心架構不可變動」的原則。

  • 實作方式： 同仁在下 Prompt 時，必須強制附上目前的 Database Schema 或是 API 規格（如 Swagger/OpenAPI 的 JSON 格式），並在 Prompt 中嚴格聲明：「這是目前的資料庫結構與 API 契約，你生成的任何邏輯與資料工程處理，都必須絕對吻合這些結構，嚴禁新增、修改或重命名任何欄位與介面。」
  • 效益： 透過將系統底層結構作為「Single Source of Truth（唯一真理）」，能有效將 AI 鎖定在填寫業務邏輯，而不是每次都異想天開重構底層架構。

2. 強制切換至「增量修改（Patch / Diff）」模式

禁止同仁使用「幫我寫一個某某功能」這種開放式問法。AI 必須被限制在「修改器」的角色，而不是「造物主」。

  • 實作方式： 要求同仁在 Prompt 中採用以下結構：
    1. 現況（As-Is）： 貼上目前的程式碼。
    2. 目標（To-Be）： 描述要修補的 Bug 或新增的小功能。
    3. 約束（Constraints）： 明確加入指令：「請採用逐條修改（Line-by-line edit）模式」、「只輸出發生異動的程式碼區塊」或「請輸出 git diff 格式」。嚴禁 AI 為了「最佳化」而順手修改沒有問題的舊程式碼。

3. 統一配發「System Prompt 範本」

不該讓每位同仁各自憑感覺下指令，這會導致每個人的產出風格迥異。

  • 實作方式： 由您這邊定義出符合專案架構的「系統提示詞（System Prompt）」，讓同仁每次開新對話時都必須先餵給 AI。
  • 範本內容應包含：
  • 技術棧與版本： 指定語言版本與框架版本。
  • 架構風格： 例如指定採用特定的設計模式、錯誤處理機制（Error Handling）。
  • 命名慣例： 約束變數與函式的命名規則。
  • 絕對禁忌： 例如「不要隨意引入新的第三方套件」、「不要改變資料庫連線方式」。

4. 縮小 AI 的影響範圍（架構層面的防禦）

如果同仁負責的模組容易牽一髮而動全身，可以在系統設計上預先防範。

  • 實作方式： 將核心業務邏輯與外部介面解耦。定義好清晰的 Interface 或 Abstract Class 後，同仁只能請 AI 實作（Implement）這些特定的介面。即使 AI 寫得再亂，災情也會被侷限在該介面的實作檔內，不會像癌細胞一樣擴散到整個系統的依賴中。

要把這些規範推行下去，通常需要搭配特定的工具或流程管控。