AI友好架構：DevOps平臺&平臺工程賦能AI自動程式設計|萬字長文

上下文感知一直是 AI 輔助程式設計的核心要素之一。在模型不再是瓶頸的 2025 年裡，如何獲得當前任務所需要的必要上下文資訊，將是 AI 助手能否成功的關鍵。AI 程式設計助手是透過 Workspace 與編輯器/IDE 來構建工具，進而讓模型獲得相關的上下文。

隨著客戶端側的 AI 程式設計助手的成熟，在服務端圍繞於 DevOps 平臺/平臺工程來感知任務所需要的上下文，將是今年的一個重要的趨勢。於是，結合我們過去在客戶側的探索以及 AutoDev 的諸多實現，我們將 AI 友好的平臺工程的模式進行了總結。

太長不看網頁版見：https://ide.unitmesh.cc/ai-friendly/platform-engineering

引子：標準化的工具與知識 => 平臺工程

在過去的幾年裡，DevOps 平臺的建設是國內外企業數字化轉型的一個重要組成部分。隨著 DevOps 平臺的成熟，平臺工程（Platform Engineering）作為一種新的軟體開發模式，正在逐漸興起：

平臺工程旨在為軟體開發團隊提供一套標準化的工具、服務、知識和自助能力，從而提升開發者體驗（DevEx）、提高生產力，並加速軟體交付的速度和可靠性。

簡單來說，開發人員可以透過平臺工程來獲取所需的工具、服務和知識，而不必再花費大量時間在基礎設施和工具鏈的配置上。

示例 1：面向 AI 生成的內部開發者平臺

我們在 AutoDev 中構建了遠端智慧體、MCP 能力，目標是讓開發人員快速使用內部的基礎設施，快速生成程式碼、CI/CD 流水線，讀取內部的知識庫、文件等，以加速開發者的工作。而藉助於平臺工程帶來的標準化的工具和知識，可以加速 AI 賦能開發人員：

提供需求、設計、實現和測試等不同階段的工件進行上下文豐富。
語義化識別公共 API，結合程式碼上下文與業務資訊，生成 API 呼叫程式碼。
透過內部的設計系統、元件庫、服務端框架生成前後端程式碼。
結合程式碼化的 CI/CD，快速生成、動態建立 CI/CD 流水線。
透過標準化的基礎設施即程式碼 (IaC)，快速生成、動態建立基礎設施資源。
……

除了簡單的問題，我們相信當智慧體越來越豐富之後，可以實現大量的聯動。一個聯動場景示例：

開發人員可以在 IDE 中呼叫智慧體，輸入一個建立資源的需求，隨後生成一個可點選的連結。當用戶點選連結時，會跳轉進行 OAuth 授權，隨後會自動生成一個建立資源的 CI/CD 流水線，並在流水線中自動生成一個建立資源的基礎設施即程式碼 (IaC) 模板。使用者只需點選“執行”按鈕，便可以快速建立所需的資源。

而這一切的實現，都依賴於平臺提供大量豐富的 API 和外部服務。因此，我們認為在引入複雜的 AI 輔助功能之前，企業應該優先投入基礎自動化與標準化：確保擁有堅實的基礎設施即程式碼（IaC）、CI（持續整合）/CD（持續交付）和基礎的可觀察性實踐。透過定義清晰的 “黃金路徑” 來標準化核心開發和部署流程。

PS：受限於組織規模、技術棧和團隊文化，企業所需要的形態是不一樣的。

示例 2：平臺工程整合元資料，構建智慧體自協作

除了用在輔助程式設計之後，我們可以看到國內外大量的 Ops 平臺在生成式 AI 上的建設思路：藉助生成式 AI 強大的推理能力，與傳統判別式 AI 擅長的領域（如監控、日誌分析、異常檢測等），來進行端到端的輔助分析與決策。

一個理想的場景示例：當你在監控平臺中發現一個異常時，可以透過自然語言詢問 AI，AI 可以：

自動分析相關的日誌、指標、事件等資料，並給出可能的根因和解決方案。
自動生成一個問題單，並將其分配給相關的團隊或人員。
結合程式碼庫資訊，自動生成一個修復補丁，並提交到程式碼庫中。
自動生成事故的報告分析，作為事後覆盤的參考。

要建設這樣的系統並不是一件簡單的事情。需要利用 LLM 和 RAG 技術，允許使用者使用自然語言查詢海量的遙測資料，獲取系統健康報告、效能問題摘要、儀表板解釋等。能進行異常檢測、預測性分析和根因分析，將來自不同來源（指標、日誌、追蹤、部署事件）的資料關聯起來，提供上下文豐富的洞察。

而在微服務架構中，服務之間的依賴關係和互動模式是非常複雜的。為了實現高效的故障排除和協作，平臺需要提供一個統一的檢視，幫助開發者理解服務之間的關係、依賴和互動。如 New Relic 提供的 “Service Architecture Intelligence”元件（包括 Catalogs, Teams, Maps）旨在整合服務元資料、所有權資訊和依賴關係，消除知識孤島，加速故障排除和協作。

故而，我們認為，平臺工程的建設不僅僅是工具和流程的整合，更是知識和上下文的整合。

構建 AI 友好程式設計：上下文感知重塑平臺工程

儘管透過建立 Ledge 知識平臺（ https://devops.phodal.com/ ），讓我在 DevOps 上積累了豐富的經驗，但是我並非一個平臺工程專家，所以對於平臺工程的理解，更多的是出自於我在 AI 程式設計、DevOps 在企業實施和落地的經驗，以及對平臺工程的理解。參考過往在開發者平臺的經驗，由於只是面向的是 AI 程式設計，我們把它劃分為以下幾個方面：

平臺使用者觸點：即開發者與平臺互動的方式和工具，如 Web 介面、命令列工具等。
平臺知識：即平臺所提供的知識和上下文資訊，如 API 文件、設計規範、架構決策等。
開發者視角：透過標準化、統一的 API，讓開發者可以更方便地訪問和使用平臺的功能和服務。
智慧體管理：即如何構建和管理 AI 助手的生態系統，如智慧體的註冊、配置、上下文訪問和策略執行等。
AI 度量：即如何評估和度量 AI 助手的效能和效果，如響應時間、準確性、使用者滿意度等。

圍繞其背後的重點是：構建智慧基礎設施，提供上下文，使 AI 工具成為開發者最有力的 Copilot。

平臺使用者觸點：規範化、元件化生成模板應用

問題：組織內部有大量的研發資產（如開發框架、工具等），而通用的大語言模型（LLM）是不具備這些知識的。需要將這些知識注入到 LLM 中，以便它們能夠理解和使用這些資產。

注意：對於絕大陣列織來說，有的只是潛在的資產，而不是現成的資產。我們需要將這些資產進行數字化、標準化和元件化，以便 LLM 能夠理解和使用它們。因此，需要尋找一種合理的方法來將負債轉化為資產。受限於篇幅，這裡只提供只幾個示例：國內可參考某些銀行內部的 API 市場或者開放 API、 Netflix 聯邦化平臺控制檯（Federated Platform Console）、Spotify：透過 Backstage 促進元件發現與標準化、Adidas 的 Capability Diamond 等。

實踐模式：結合 “黃金路徑” 加速初始化應用

解決方案：結合平臺工程的中 “黃金路徑”（Golden Path）的實踐方式，直接由自然語言來生成完整應用。即在模板應用的基礎之上，自動生成所需要的配置，以及相關的上下文資訊。

黃金路徑包含一系列的元件，諸如於專案/應用模板、腳手架工具、預配置的 CI/CD 流水線、文件庫和可重用元件。它們將組織的最佳實踐（如安全掃描、合規檢查、監控配置、部署策略等）嵌入到開發流程中，使開發者能夠自然而然地採用這些實踐。

實現示例：V0 在生成前端程式碼時，會預先生成專案結構，以及必要的相關上下文（如 AI SDK）和程式碼示例，以減少 AI 幻覺的發生，生成更貼合需求和規範的程式碼。

而實施這個模式的重點是：提煉出組織的最佳實踐（包含隱性知識），並將其嵌入到開發流程中。

實踐模式：為下游應用提供模板化的元件

解決方案：在下游的 AI 助手中，可以預先設定模板程式碼和配置程式設計，隨後使用者可以藉助其來生成符合組織需要的配置檔案和程式碼片段。

實現示例：

Builder.io 和 Codia，作為 Figma 外掛執行，支援轉換為多種 Web 和移動平臺程式碼。利用 AI 進行智慧佈局識別、智慧命名、圖層合併壓縮和 UI 元件檢測，生成生產級別的程式碼。
AutoDev 可以透過獲取專案的資訊，自動生成 GitHub Actions 流水線、Dockerfile 配置等，結合專案中的前端框架（React）元件，生成前端程式碼。

為了讓 AI 產物能夠無縫地融入團隊現有的開發工作流和質量標準體系中，需要控制輸入的質量和後續的整合。輸入的質量包括設計稿的規範性與一致性，以及設計稿中元件的可複用性。後續的整合包括生成程式碼的可讀性、可維護性，以及與現有程式碼庫的相容性。除此，對於前端頁面來說，提供及時的反饋和預覽是非常重要的。可以讓設計師和開發者能夠快速檢視生成的程式碼效果，並進行必要的調整和最佳化。

平臺知識：連結端到端研發上下文

問題：軟體開發過程天然伴隨著大量的知識碎片，這些知識分散在程式碼庫、文件、工具、甚至團隊成員的經驗中。開發者需要花費大量時間尋找、理解和應用這些知識，導致效率低下和上下文切換成本高昂。圍繞平臺賦能 AI 程式設計的一個關鍵目標是構建 “知識中樞”，將這些分散的知識進行整合、管理，並透過 AI 能力提供智慧化的訪問和輔助，從而降低認知負荷，提升開發者體驗 (DevEx)。

如下是一些常見的上下文型別和它們對 AI 助手的價值：

上下文型別	描述與對 AI 助手的價值
服務目錄/所有權	軟體生態系統地圖；用於生成正確的服務互動程式碼，理解依賴關係。
API 模式/規範	服務互動契約；用於生成正確的 API 呼叫程式碼。
IaC 配置	環境基礎設施定義；用於生成/修改 IaC，理解部署目標。
知識庫/文件	架構決策, 操作指南, 最佳實踐；用於提供基於內部知識的解釋和建議。
編碼標準/最佳實踐	程式碼質量、風格、安全規則；用於生成合規、一致的程式碼。
可觀測性資料	執行時效能/錯誤資料；用於輔助除錯和效能分析 (透過工具)。
部署歷史/CI/CD 日誌	構建/部署活動記錄；用於排查部署問題，理解近期變更。

與只提供知識相比，如何將知識與上下文結合起來，形成一個完整的知識圖譜，並透過 AI 助手進行智慧化的訪問和輔助，是一個更具挑戰性的任務。

實踐模式：平臺的 AI 助手作為試驗田

問題：平臺工具雖多，但缺乏統一互動通道和智慧整合方式，開發者仍需手動在多個系統（如 GitLab、Jira、Prometheus）中跳轉，造成高昂的認知負擔與時間成本；而直接設計一個平臺來支援 AI 助手的上下文感知是一個複雜的任務。我們需要考慮如何將知識、工具和流程整合在一起，以便 AI 助手能夠有效地訪問和利用這些資源。因此，我們可以先從一個小的試驗田開始，逐步擴充套件到整個平臺。

解決方案：在平臺構建內建的 AI 助手，將其打造為“語義查詢入口”和“經驗流轉中樞”：

它可以查詢服務之間的依賴路徑，輔助理解呼叫鏈；
它可以分析某段程式碼的部署歷史，定位與某次失敗構建的關係；
它還能在異常發生時，結合日誌和變更記錄，提供診斷建議。

例項示例：GitLab Duo，在 IDE 或 Web UI 中提供對話介面，用於程式碼解釋、測試生成、程式碼重構、漏洞解釋與修復、CI/CD 失敗的根因分析等

實踐模式：構建研發資產的數字主線

問題：當前軟體工件（需求、設計、程式碼、測試、部署等）之間缺乏有效關聯，無法清晰追溯某功能從業務需求到上線執行的全過程，影響問題排查、知識沉澱與變更管控。

數字主線（Digital Thread）是一種貫穿整個軟體開發生命週期的資訊主線，能夠將需求、設計、實現、測試、部署等各階段的工件與上下文關聯起來，形成可追溯、可重用、可理解的知識流。

解決方案：透過構建“數字主線”，實現研發資產全生命週期的語義化關聯，包括：

需求的例項化（如 Jira 任務）
從需求到程式碼的聯動（如 Jira 與 Git 提交對映）
從程式碼到部署的對映（構建記錄繫結具體提交）
從程式碼到測試的覆蓋鏈（單測與功能的自動繫結）
……

與此同時，我們要有新的思路變化，比如用 AI 來增強這部分的規範化的落地。如在 AutoDev 中，可以藉助本地智慧體獲得需求 ID，編寫到提交資訊中；可以從提交資訊中提取需求 ID，獲取相關的需求資訊，再進行 Code Review；

實踐模式：基於領域概念的上下文鏈路（試驗）

上下文鏈路指的是一套流程和系統，旨在使開發團隊成員能夠高效地追蹤、發現和理解不同軟體開發工件及知識元素之間的內在聯絡

問題：開發者面臨的資訊分散在多個維度與工具中，且工件之間的關聯性缺失，無法在多個視角間高效切換。例如：某個異常日誌如何追溯到觸發它的使用者故事或提交記錄？

設想一個理想的場景：開發者在檢視一個使用者需求時，能夠透過一次點選或一個簡單的查詢，即時跳轉到實現該需求的具體程式碼段、相關的單元測試和整合測試、最近的部署狀態和日誌、對應的技術設計文件，甚至能快速識別出負責該模組的團隊或開發者。反之，從一段程式碼出發，也能輕鬆回溯到它所滿足的需求、檢視其測試覆蓋情況、關聯的缺陷報告以及部署歷史。

解決方案：我們提出了一種新的模式來解決這個問題：我們簡單地將其稱為“上下文鏈路”，它是一個整合的知識管理系統，能夠在整個軟體開發生命週期中提供上下文資訊。核心能力包括：

可追溯性：支援需求/程式碼/測試/部署的前後路徑溯源
可發現性：支援基於上下文的智慧搜尋與推薦
可理解性：輔助開發者理解某工件在系統中的位置與演化路徑

圍繞於這個上下文鏈路的核心是構建一個基於領域概念的“知識圖譜”，可以將不同的工件和知識元素進行關聯和連結，諸如於：需求標籤、程式碼註釋、提交資訊、測試用例、部署記錄等。透過這些標籤和註釋，可以幫助開發者快速理解某個工件的上下文資訊，並在不同的視角之間進行切換。

實踐模式：預先生成的上下文

問題：生成式 AI 有一個顯著的問題是，它是逐個字元生成的，如果每次都要從頭開始生成，那麼它的效率會非常低下。尤其是當我們需要生成大量的程式碼時，我們需要一個更高效的方式來生成程式碼。即，將必要和常用的上下文資訊預先生成，並在使用時，可以優先在上下文中進行檢索。

實踐示例：諸如於 DeepWiki、Context7，可以基於文件和程式碼示例，生成相關的程式碼庫上下文。如下是 Context7 生成的上下文示例：

TITLE:ImplementingActionBehaviorinJava
DESCRIPTION:Shows the structure of the AnAction.actionPerformed() method where the main logic of an action is implemented.
It demonstrates how to access project, editor,and file information from the action event.
SOURCE: https://github.com/JetBrains/intellij-sdk-docs/blob/main/topics/basics/action_system.md#2025-04-06_snippet_1
LANGUAGE:Java
CODE:
\```
publicvoid actionPerformed(AnActionEvent e){
// ...
}
\```
----------------------------------------

開發者視角：標準化平臺 API 提供上下

問題：當前，AI 工具和 API 的多樣性與日俱增，但缺乏統一標準，導致整合複雜、效率低下。與此同時，AI 智慧體（Agent）作為能夠自主感知、決策和行動的軟體實體，其開發、部署和管理也對傳統平臺工程提出了新的挑戰。

實踐方式：語義明確的標準化 “智慧 API”

問題：透過制定統一的 API 設計規範和介面模型，將平臺能力封裝為 “智慧 API”，用於提供結構化、語義明確的上下文介面，方便 AI 智慧體統一呼叫並獲得準確、可控的結果。

解決方案：“智慧 API”的核心在於其語義明確性，其不應僅僅暴露資料或函式，更要以 AI 智慧體能夠理解的方式揭示其含義和預期用途。這要求 API 設計超越傳統模式，將 AI 智慧體視為首要使用者。

實現示例：

GitHub Copilot Extension 為第三方工具和服務提供了一種將其能力和上下文資訊整合到 GitHub Copilot Chat 中的機制。這種整合使得 Copilot 能夠利用外部知識和功能，為開發者提供更精準、更相關的輔助。
Windsurf、Cline 等採用了模型上下文協議（Model Context Protocol, MCP），基於其提供的通用語言來連線 AI 系統與外部資源。

PS：就當前而言 MCP 雖然有大量的問題，但是仍然是一個相對成熟的標準化協議。

實踐方式：智慧體的基礎設施即程式碼（潛在路徑）

方向：結合現在流行的各類程式碼化的概念，相信未來也會出現 “AI Agent 即程式碼” (AgaC) 的正規化，其可以將構成 AI 智慧體及其執行環境的所有要素都透過程式碼來定義、管理和版本控制。

解決方案：“AI Agent 即程式碼” (AgaC) 的核心思想是將構成 AI 智慧體及其執行環境的所有要素——包括模型、資料、計算資源、外部工具、特定配置及執行環境 ——都透過程式碼來定義、管理和版本控制。這借鑑了“基礎設施即程式碼”(IaC) 的成熟理念，旨在為 AI 智慧體的複雜系統帶來自動化、一致性、可重複性和版本控制等優勢。

智慧體管理：IDP 即智慧體中樞（潛在路徑）

方向：將 IDP 定位為 AI 助手整合、配置、上下文訪問和策略執行的中心點。利用 IDP 的服務目錄、配置管理、工作流引擎和 RBAC 功能來管理 AI 助手。

解決方案：內部開發者平臺 (Internal Developer Platform, IDP) 旨在透過抽象基礎設施複雜性，提供標準化的工具、服務和流程，從而提升開發者體驗和效率。將 IDP 作為 AI 智慧體管理的中樞，可以有效應對 AI 智慧體在整合、配置、上下文訪問和策略執行等方面的挑戰。

案例研究/示例：

Port.io：Port平臺中的原生AI智慧體利用其現有的資料模型和門戶構建塊，來回答有關係統、服務健康狀況、所有權等問題，並支援自定義自動化工作流。Port強調透過基於角色的訪問控制（RBAC）來確保AI智慧體的安全執行。
Google Agentspace：這是一個企業級搜尋和AI智慧體中心，它連線了各種工作應用（如Confluence, Drive, Jira），使用多模態搜尋，並利用Gemini模型執行總結、生成和操作等任務。它透過Vertex AI Agent Development Kit和Agent Gallery管理預構建和自定義的AI智慧體。

PS：新興的智慧體互動標準如開放智慧體模式框架 (OASF)、智慧體連線協議 (ACP) 和 Google 的 A2A (Agent-to-Agent) 協議等，也在推動智慧體間通訊和能力發現的標準化，為構建更廣泛的“智慧 API”生態系統奠定基礎。這些標準致力於解決資料孤島、API 不一致和互操作性等難題，長遠來看有助於形成一個更加互聯互通的“智慧體網際網路” 。

實踐模式：智慧體應用的可觀測性

問題：AI 智慧體憑藉其執行復雜、多步驟推理、動態規劃、利用外部工具以及與環境互動的能力，在自主性和功能性方面實現了顯著飛躍。然而，這些高階能力也帶來了獨特且重大的可觀測性挑戰。與傳統軟體甚至簡單的生成式 AI 應用不同，智慧體的行為本質上更難預測，其內部決策過程通常不透明（“黑箱”效應）。這使得診斷故障、理解意外行為、確保可靠性、最佳化效能和控制成本變得異常困難。

解決方案：為了有效應對 AI 智慧體帶來的可觀測性挑戰，需要構建一個專門的、全面的智慧體可觀測性框架。該框架應提供對智慧體從輸入感知到最終行動的整個生命週期和操作動態的深度可見性。除了傳統的遙測資料（如日誌、指標、追蹤）外，還需要關注於智慧體應用的特點：

智慧體特有故障檢測與告警：識別並告警特定於智慧體的故障模式，如卡在迴圈中、工具濫用或目標偏離。
視覺化分析與除錯：利用視覺化工具（如執行流圖、決策路徑圖）幫助理解智慧體複雜的行為模式並進行除錯。

示例：

LangSmith (LangChain/LangGraph): 提供對基於LangChain和LangGraph構建的智慧體的深度可觀測性，允許開發者逐步追蹤智慧體的執行過程，檢查每個元件的輸入輸出，快速定位和修復錯誤，並評估智慧體效能。
內建 OpenTelemetry的智慧體框架 (如CrewAI): 一些現代智慧體框架選擇內建OpenTelemetry支援，使得使用者可以開箱即用地收集標準化遙測資料，簡化了可觀測性的實施，並能與相容OTel的後端工具整合。

AI 度量：邁向 AI 輔助開發的有效度量

問題：如何區分和歸屬人類與 AI 在程式碼中的貢獻，現有的分類方法可能不足以有效應對。與此同時，AI 生成程式碼的質量、安全性、可維護性問題，以及其造成的技術債務的加速效應，讓我們不得不考慮將長期的系統架構治理置於更核心的位置。諸如於：

驗證開銷: 開發者需要花費大量時間來審查、除錯和驗證 AI 生成的程式碼建議，這部分開銷可能抵消部分速度優勢。
質量與安全風險: AI 生成的程式碼可能包含隱藏的錯誤、安全漏洞或不符合最佳實踐，增加了程式碼質量和安全風險。
技術債務: 過度依賴 AI 進行快速修復或生成樣板程式碼可能導致技術債務的加速積累，影響長期可維護性。
開發者技能與體驗: AI 對不同經驗水平的開發者影響不同，並可能引發對技能退化（deskilling）的擔憂，同時深刻影響開發者的心智負荷和心流狀態。

如果我們將 AI 視為開發者的 Copilot，那麼它帶來的生產力，到底是正還是負呢？

實踐方式：平衡 IDE 時間與有效程式碼接受率

問題：單純地衡量 AI 帶來的“速度提升”可能存在誤導。開發者在編碼階段投入的時間是有限的，AI 的引入可能導致開發者在編碼上花費更多時間進行驗證和除錯，但最終的生產力提升卻不成正比。例如，研究指出開發者可能將高達 50% 的時間用於驗證 AI 建議。

解決方案：為了有效應對上述挑戰，需要為 AI 輔助的編碼活動構建一個更精細化、更具洞察力的可觀測性策略。這種策略應超越表面指標，深入分析開發者與 AI 工具互動的真實情況和結果。核心在於：

細分 IDE 內活動：將開發者在 IDE 內的時間劃分為更有意義的類別，如主動編碼、與 AI 互動（包括撰寫提示、審查建議、修改建議）、除錯 AI 生成的程式碼、傳統編碼及除錯、以及其他活動。
情境化建議接受率：不僅追蹤接受率本身，更要結合後續程式碼質量和返工情況來評估接受的有效性。
量化驗證與認知開銷：明確度量開發者在驗證、修改 AI 輸出以及與 AI 工具進行多輪互動上所付出的時間和精力。
關聯開發者體驗：將這些度量與開發者的心智負荷、心流狀態和滿意度等體驗指標相結合，以全面理解 AI 影響。
透過這種方式，可以更清晰地揭示 AI 輔助開發的淨生產力收益、潛在的隱性成本以及對開發者工作體驗的真實影響。

實踐方式：人機協作下的 AI 度量指標

解決方案：為了更全面、更有效地度量 AI 輔助開發的成效，我們需要在度量粒度、全面性以及與業務成果的明確關聯方面進行深化。

超越採納率，關注實際貢獻：不僅要衡量 AI 工具的採用情況，更要深入評估其對研發效率、生產力、創新能力以及 AI 輔助本身質量的切實貢獻。
營造支援性環境，促進心流狀態：致力於建立並衡量一個能讓開發者感到受支援、積極參與並能輕鬆進入心流狀態的工作環境。在這個環境中，AI 工具應扮演無縫協作者的角色，而非摩擦的來源。
確保軟體系統質量與韌性：透過實施專門針對 AI 參與程式碼生成和系統運維細微差別的指標，確保 AI 輔助開發能夠產出高質量、可維護、安全且具有韌性的軟體系統。

示例：如下是我們讓 DeepResearch 結合 DORA 的交付結果指標、來自 SPACE 的多維度生產力視角、來自 DevEx 的人為因素考量設計出來的度量指標。AI 將其稱為 “戰略性 AI 驅動研發卓越 (SPARE)”框架：

AI 輔助研發裡的必要基礎設施

談論平臺的基礎設施是一個非常龐大的話題，這裡我們只說一些重點。

新興基礎設施

從現有企業採用的模式來看，AI 友好的平臺基礎設施應該具備的核心能力包括：

非編碼的智慧體編排。諸如於 Dify、Coze 這一類的 AI 編排工具，透過提供更直觀的視覺化介面、更豐富的預置模組和更便捷的整合能力，使得擁有深厚領域知識的專家也能積極參與到AI驅動的創新活動中，並透過模組化、可組合的方式加速研發應用的構建和迭代週期。
多樣化的模型服務。平臺應該支援從小型特定任務的專用模型到大引數基礎模型，以在不同的場景下取得最佳的效能和效率。
向量模型與向量資料庫。為高效處理和理解海量的非結構化研發資料（如需求文件），以在向量空間中進行快速、準確的相似性搜尋，賦能語義理解與知識發現。
統一的元資料與知識圖譜管理：構建能夠連線所有研發活動和資產的元資料層和知識圖譜，為 AI 提供全域性上下文。
強大的可觀測性與反饋閉環：不僅針對傳統應用，更要針對 AI 應用和智慧體本身，建立全面的可觀測性，並形成有效的反饋閉環，用於持續最佳化 AI 的效能和行為。
……

當然了，有些工具並非是現階段所需要的，可以在未來需要的時刻引入它們。

經典工具：緩解 AI 生成程式碼的安全風險

模型在生成程式碼時，可能會受其訓練資料影響而繼承安全缺陷，複製已知的易受攻擊模式（如 CWE 常見缺陷列表），並且缺乏對特定上下文安全隱患的感知能力。如果開發者在未進行徹底驗證的情況下，直接信任這些 AI 生成的程式碼，並接受這些程式碼，會增加了將漏洞引入生產系統的風險。

在現有的模式裡，經典的工具依舊是最有效的工具。在新一代的 AI 程式碼安全解決方案出現之前，我們需要藉助現有的靜態和動態分析工具來緩解這些風險。我們可以透過以下方式來實現：

提示詞設計：在程式碼生成前，在提示詞中明確要求 AI 生成的程式碼遵循特定的安全標準和最佳實踐，並在提示中包含相關的安全規則和檢查項。（儘管這並不能完全解決問題，但可以作為一種初步的防護措施）
靜態分析：在程式碼生成後，使用靜態分析工具（如 SonarQube）來掃描和識別潛在的安全漏洞和程式碼缺陷，並在平臺中整合這些工具，以便在程式碼提交時自動執行。
Code Review：在程式碼生成後，進行人工或自動化的程式碼審查，以確保程式碼符合安全標準和最佳實踐。
……

除此，在引入經典的工具之後，我們可以考慮用生成式 AI 工具來解決它們的不足，諸如於誤報率高、誤報不易排查等問題。還可以讓模型去生成對應的檢查規則，來提升靜態分析工具的準確性。

我們也可以看到新的工具正在出現，例如：SOSecure 是一個基於檢索增強生成（RAG）的系統，它利用 StackOverflow 等開發者社群中的討論來提升LLM生成程式碼的安全性。SOSecure 首先構建一個專注於安全的知識庫，其中包含從 StackOverflow 問答和評論中提取的、明確指出程式碼漏洞的條目。

小結

AI 友好架構核心在於以平臺工程為載體，透過標準化工具、元件和流程為 AI 程式設計助手提供豐富且結構化的上下文，使其在開發各階段（需求、設計、編碼、測試、部署）都能精準、高效地輸出結果。從“黃金路徑”到模板化元件，再到數字主線和上下文鏈路，目標都是將分散的知識與研發工件語義化、可追溯、可發現，為智慧體提供統一入口和完整檢視。

在平臺層面，透過語義明確的“智慧 API”、程式碼化的智慧體定義（AgaC），以及 IDP 中樞化管理和全面可觀測性，實現 AI 智慧體的可控、安全與高效運營。

最後，結合細化的 AI 度量（如提示有效性、IDE 活動時間、驗證開銷、心流狀態和技術債務指數等），可以客觀評估 AI 輔助開發的真實價值與潛在成本，持續最佳化人機協作體驗。

展望未來，AI 友好架構將越來越走向智慧體化的方向。我們可能看到“智慧體即程式碼”的實踐：智慧體的設計、配置與部署將像軟體一樣，透過程式碼版本管理、 CI/CD流水線、審查流程來治理。隨著跨平臺協作需求的增長，類似谷歌提出的A2A（Agent-to-Agent）協議將成為行業標準，實現不同系統間智慧體的互聯互通。