氛圍編碼 讓非技術使用者（我們稱之為公民建置者）能夠使用 AI 建構以往無法建置的應用程式。當我們在 Thoughtworks 全球行銷部門的 AI 應用程式團隊被要求，將一位公民建置者在全球行銷部門所建構的氛圍編碼原型進行規模化時，我們發現了嚴重的缺陷，這些缺陷會阻礙氛圍編碼的應用程式安全地進入生產環境。

沒有防護機制的速度是任何團隊都無法忽視的風險。以下是我們所發現的內容、這對使用 AI 建構的團隊意味著什麼，以及我們正在採取的步驟，以確保我們所交付的每一個工作流程、原型和應用程式，都是我們能為之背書的。

我們從慘痛經驗中學到的教訓

全球行銷部門內的 AI 應用程式團隊被要求，將使用 Gemini、Replit AI 和 Claude AI 建構的影片組裝原型進行規模化，以便為我們的 10,000 名員工製作符合品牌的影片。團隊遇到了兩次讓工作完全停滯的時刻。在這兩種情況下，AI 都建議了一條具有嚴重安全隱患的路徑。在這兩種情況下，都是人類提出正確的問題才得以捕捉到問題。

安全風險 #1

公開儲存存取權限

AI 建議將儲存貯體設為公開，或將雲端檔案儲存設定為「知道連結的任何人」。當受到質疑時，它以「每家公司都這麼做」作為理由。只有堅決的拒絕才促使它提出安全的替代方案。

這可能會導致未公開的敏感品牌資產和受眾資料洩露到公開網際網路上。

安全風險 #2

過度權限的權杖

服務帳戶被指派了「Access Token Creator」角色，授予它建立短期權杖的能力，並能存取資料庫和其他遠超出任務所需的資源。團隊在執行程式碼之前就發現了這個問題。

這可能會讓遭到入侵的服務帳戶在整個雲端工作區中進行橫向移動。

這裡的關鍵洞見是，AI 工具經常建議阻力最小的路徑。那條路徑不一定是安全的路徑。人工判斷仍然是必要的，但不應是唯一的控制機制。目標是從第一個提示就將技術安全規則作為上下文提供給代理，然後透過開發工作流程中的確定性檢查來驗證其輸出，以確保不安全的程式碼、權限、機密或基礎架構不會在未被察覺的情況下通過。

風險背後的數據

44%

利用應用程式漏洞的攻擊年增率

五分之一

企業資安事件如今是由 AI 生成的程式碼所造成

50%

沒有針對 AI 的敏感資料政策的組織

25%

AI 生成的程式碼含有已確認的漏洞

這些事件並非個案。2026 年發表的研究證實，以高速進行的 AI 輔助編碼會造成系統性的安全暴露。我們所遇到的相同風險正在整個產業中上演。

調查結果數據來源
AI 生成的程式碼含有已確認的漏洞25%AppSec Santa, 2026
利用應用程式漏洞的攻擊年增率44%SQ Magazine AI Coding Security Statistics, 2026
含有高嚴重性或關鍵嚴重性漏洞的程式碼庫78%Black Duck OSSRA 2026
沒有針對 AI 的敏感資料政策的組織50%AppSec Santa, 2026
每個程式碼庫的平均漏洞數年增率+107%Black Duck OSSRA 2026
企業資安事件如今是由 AI 生成的程式碼所造成五分之一Aikido Security, 2026
2026 年 3 月單月 AI 生成程式碼的新 CVE 數量35Georgia Tech Vibe Security Radar, SSLab, March 2026
2026 年稽核中具有提示注入暴露的 AI 系統73%SQ Magazine AI Coding Security Statistics, 2026
所有新企業軟體中為 AI 生成的比例42%Sonar developer survey, 2026
安全團隊表示跟上 AI 生成程式碼的量越來越困難62%ProjectDiscovery AI Coding Impact Report, April 2026

真正的問題：提示並不夠

在與工程和安全同事分享這些事件後，得到了一個明確的訊息：告訴 AI 代理要安全，並不等同於強制它安全。提示可以被覆蓋、誤解或忽略。當使用者對限制提出異議，或以不同的方式表達請求時，約束可能就會消失。

「僅僅告訴 LLM 您輸出產物的期望行為是不夠的。如果您絕對不希望某件事為真，它就必須在開發生命週期中的某個地方被編寫成不可協商的規則。」——工程領導層

可以這樣想：提示進行測試驅動開發，並不等同於在建置工具中強制執行程式碼覆蓋率門檻。一個是建議，另一個則是關卡。Birgitta Böckeler 關於 harness engineering 的研究透過概述一個用於建立對編碼代理信任的心理模型，使這一點具體化。開發人員不是僅依賴提示，而是將代理包裝在一個沿著兩個軸建構的外部「harness」中：

  • 導引（Guides）（前饋控制）預測不希望的行為，並在模型採取行動前引導它，而感測器（Sensors）（回饋控制）則在代理行動後觀察程式碼以標記錯誤。
  • 計算性（Computational）控制是確定性的、快速的，並由 CPU 執行（例如 linters 或測試套件）。推論性（Inferential）控制則依賴語義分析和 AI 驅動的判斷（例如特定的系統提示約束）。

為什麼業務部門需要關注

像我們的行銷團隊這樣使用 AI 建構的業務部門，並不能免除適用於建構應用程式的工程師所應負的安全義務。將安全性建構到軟體中是保護客戶和員工資料的基本要求。即使是輕量級的內部原型，也必須符合企業安全標準。如果沒有正確的防護機制，AI 輔助開發可能會在應用程式進入生產環境之前就暴露敏感資料。

客戶信任

合規性是合約規定的

遵守 ISO 27001 等標準可確保敏感資料受到保護。所有應用程式，無論建構速度有多快，都必須達到這些安全基準，以維持客戶和員工的信任。

品牌完整性

品牌資產需要保護

核心工作涉及敏感的功能性資料（例如，未公開的活動資產、財務資料或受眾洞察）。權限過度的服務帳戶所承擔的風險遠不止是程式碼。

聲譽

業務部門可以設定標準

當像行銷這樣的業務部門以安全紀律作為領導時，它們向整個組織和客戶傳達了負責任的 AI 採用訊息。

短期習慣

您不需要成為安全專家就能開始負責任地建構。這三個習慣可以讓您入門。

將您的技術安全規則輸入到每一次工作階段中

將貴組織的安全指南作為「Rules」新增到 Claude、Cursor 或 Replit 中（稍後再投資於跨所有工具的共享合理預設層）。AI 代理會將它們作為指導使用，從一開始就更有可能採用安全的模式。它們仍然需要由確定性檢查作為後盾，在任何東西部署之前，這些檢查會使不安全的程式碼、暴露的機密、廣泛的權限、易受攻擊的相依性或不安全的基礎架構失敗。

質疑 AI 所建議的每一個權限

如果工具建議公開某個東西或指派廣泛的服務帳戶角色，請停下來並詢問原因。阻力最小的路徑與安全的路徑很少是相同的。

嘗試 紅隊提示

要求您的 AI 扮演壞角色的角色，並對它剛剛建構的東西進行滲透測試。這項技術能持續發現前瞻性提示所遺漏的漏洞，特別是關於權限和資料暴露的漏洞。

中期解決方案

閱讀風險是一回事，對它做些什麼是另一回事。這些事件促使我們採取了兩項實際的措施。它們背後的原則可以被任何使用 AI 建構的團隊複製，無論其技術背景如何。

安全上下文檔案

我們將技術安全規則編譯成一個結構化的上下文檔案，在任何程式碼撰寫之前載入到每一次 AI 編碼工作階段中。它涵蓋了零信任執行、機密管理、harness engineering 和供應鏈完整性。與隨意的提示的關鍵區別在於操作紀律：該檔案是版本控制的、預設載入的、經過審核的，並搭配自動化檢查。它作為一個全面的推論性導引，告訴代理什麼是好的；但它必須與管道中的計算性感測器搭配使用，以驗證輸出是否可接受。

每日安全情報摘要

目前，這項自動化整合可確保我們在供應鏈警示發布的當天就能看到它們。未來，隨著我們朝向代理型企業邁進，我們預想代理能主動建立故事卡，並在幕後識別和修補已知的漏洞，供人類審核，從而大幅縮短軟體開發生命週期 (SDLC) 的週期時間。

安全上下文檔案的實務應用

這種方法背後的想法很簡單：AI 工具會在工作階段開始時讀取上下文，因此請將該上下文設定為您的技術安全規則。該檔案是將貴組織的安全要求進行整理，並將其建構為 AI 可以採取行動（而非僅僅承認）的形式所產生的結果。

以下是任何此類檔案應包含的涵蓋範圍類型。具體內容會因組織而異，但類別是一致的。

涵蓋領域好的做法是什麼為什麼重要
零信任與最小權限在每一個服務帳戶和儲存資源上執行嚴格的身分驗證和最小存取權限設定推論性導引參數，以直接防止權杖權限風險。
機密管理AI 拒絕在程式碼中生成或儲存 API 金鑰、密碼或權杖；永遠導向環境變數或機密管理員在憑證洩露到儲存庫之前阻止它。
Harness engineering 關卡SAST 掃描、憑證掃描和基礎架構驗證必須在部署前通過；不能僅依賴提示指示以確定性的計算性感測器來支持推論性指示。
供應鏈完整性僅使用成熟的函式庫；定期稽核每一個相依性以查找已知漏洞降低 AI 建議使用不明或未經驗證套件的風險。
AI 問責制所有 AI 生成的程式碼在部署前都必須經過同儕審核和自動化安全掃描；禁止未經授權的 AI 使用合規性稽核所必需。

與提示的關鍵區別在於，該檔案包含不可協商的規則，迫使 AI 代理拒絕違反政策的請求。如果 AI 代理被要求繞過檢查、停用日誌記錄或將某個東西設為公開存取，規則應引導它拒絕並解釋原因。但重要的控制是，即使代理未能遵循該指導，確定性檢查和部署關卡仍應捕捉到問題。這種拒絕正是我們兩次差點出事的意外事件中所缺少的。

安全情報摘要的實務應用

保持資訊靈通本身就是一種防禦。這個工作流程會監控您的團隊正在積極使用的工具和語言，並提供每日摘要，包含新的 CVE、平台公告和安全公告。最重要的涵蓋領域在各組織中是一致的：他們用來撰寫的語言、他們部署到的雲端平台、AI 編碼工具本身，以及整個 CVE 資料庫。

目標很簡單：在漏洞揭露的當天就了解它，而不是幾週後。在 42% 的新企業軟體現在是由 AI 生成或 AI 輔助的情況下，加速開發的工具也是最有可能出現在新 CVE 揭露中的工具。積極監控它們是擁有您的安全的一部分。

更廣泛的觀點

這兩種方法都不需要工程背景就能採用。一個是為 AI 消費而建構的政策文件。另一個是自動化搜尋。它們共同點在於承認，當 AI 以高速生成程式碼時，被動的安全意識是不夠的。

長期組織變革

從提示到管道

將 harness engineering 整合到您的標準原型模板中。從機率性提示轉向明確的回饋迴路。如果計算性感測器（如自動化安全掃描器）觸發，代理迴路必須在結構上強制模型自我修正，直到通過為止。

將安全規則輸入到應用程式建構器（Cursor、Claude 等）中

將貴組織的技術安全規則編譯成結構化的上下文 Markdown 檔案，並將其作為「Rules」載入，模型將必須遵守它。它會在最便宜的修復點（即任何程式碼提交之前）捕捉最常見的錯誤。

讓安全的路徑成為容易的路徑

為建置者提供一個預設安全的起點。預先設定驗證模式、私有儲存預設值、機密處理和相依性掃描的模板，可以降低任何人在截止期限壓力下走捷徑的機會。

跨職能定義入門 harness

由業務部門、工程和安全共同建構的共享入門 harness，為每一位建置者從第一天起就提供安全的基礎，而不是讓每個團隊獨立地重蹈相同的覆轍。

結論：超越原型的規模化

這趟旅程始於我們被要求支援另一個團隊，為全球行銷黑客松建構影片組裝平台。當我們幫助規模化解決方案時，很明顯，「氛圍編碼」如果沒有企業級的防護機制，可能會引入組織絕對不能忽視的風險。

透過將我們的技術安全規則直接嵌入到代理工作流程中，我們將那些早期的差點出事事件轉化為一個安全的、可投入生產的平台，並在黑客松期間成功推廣給 150 位使用者。

這種轉變——從依賴人類來捕捉問題，到將技術安全規則、自動化檢查和人類問責制建構到工作流程中——已經成為我們在代理時代快速前進同時維持工程嚴謹性的藍圖。

Thoughtworks 的延伸閱讀

這些挑戰並非我們團隊所獨有。Thoughtworks 的同事一直在深入探討這些問題並發表他們的發現。以下是與我們所描述的內容最直接相關的文章。

Thoughtworks 技術長 Rachel Laycock 探討為什麼當 AI 生成程式碼時，工程嚴謹性並不會消失，而是重新定位。涵蓋了給編碼代理套上繫繩、零信任架構，以及為什麼安全防護機制現在是不可協商的。

Thoughtworks 舉辦的一場實務工作者和企業領導者的聚會發現，在 AI 採用過程中，安全性 consistently 被降級。授予代理廣泛的工具存取權限，特別是對電子郵件的存取，被標記為一個立即且具體的風險。

Thoughtworks 傑出工程師 Birgitta Boeckeler 探討如何在代理迴路中放置確定性控制。建構 harness 的權威指南，它能在不使模型癱瘓的情況下執行安全規則。

如何在任何 AI 輔助開發工作流程中嵌入安全防護機制和永不允許規則作為強制性的 pre-commit hooks。

Thoughtworks 的年度技術展望警告說，如果沒有嚴謹的工程監督，生成式工具可能會累積技術債務並引入安全漏洞。成功需要一個共同建構模式，讓人類確保 AI 生成的程式碼維持架構完整性。

致謝

非常感謝團隊進行了塑造這篇文章的熱烈討論，特別是 Julie Woods-Moss 倡導 AI 原型風險，以及 Natalie Drucker 在塑造內容和標題方面扮演的重要角色。

感謝 Martin Fowler 重塑了我們對短期與長期習慣以及 harness engineering 的看法，以及 Kief Morris 對 LLM 繞過提示的核心論點提供了基礎。

感謝 Jim Gumbley 引入關鍵的治理和 ISO27001 重點並審核文章。榮譽提及 - Craig Stanley 倡導策略性推廣，以及 Andherson Maeda 提出集中式技能儲存庫的概念，Simone Thompson 提出壞角色模擬方法，Premanand Chandrasekaran 定義 LLM 執行的技術邊界，Matteo Vaccari 提出在嚴格規則與模型靈活性之間取得平衡的細微差別，以及 Bilal Jaffery。

GenAI（Gemini 和 Claude）被用於簡化研究過程、提取見解，並潤飾語言以達到最大的清晰度和可讀性。