上下文感知一直是 AI 辅助编程的核心要素之一。在模型不再是瓶颈的 2025 年里，如何获得当前任务所需要的必要上下文信息，将是 AI 助手能否成功的关键。 AI 编程助手是通过 Workspace 与 编辑器/IDE 来构建工具，进而让模型获得相关的上下文。

随着客户端侧的 AI 编程助手的成熟，在服务端围绕于 DevOps 平台/平台工程来感知任务所需要的上下文，将是今年的一个重要的趋势。于是，结合我们过去在 客户侧的探索以及 AutoDev 的诸多实现，我们将 AI 友好的平台工程的模式进行了总结。

引子：标准化的工具与知识 => 平台工程

在过去的几年里，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: Implementing Action Behavior in Java
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:
\```
public void 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 赋能与价值实现	提示有效性	评估 AI 响应质量（如后续修改量、满意度评分）	优化人机交互的关键；高质量提示带来更好结果	难以标准化和客观量化
	建议接受率	(接受的建议数 / 显示的建议数) * 100%	强相关于开发者感知生产力；反映建议的即时相关性	不保证代码质量；可能被“游戏”；受任务类型影响
	贡献归属评分	开发者主观评估 AI 贡献度；结合代码来源分析	揭示 AI 的协作角色与信任感；有助于责任划分	主观性强；技术实现复杂
协同式开发者体验与心流	IDE 活动时间	IDE 插件追踪活动类型（编码、调试、审查、空闲）	显示 AI 如何影响开发活动结构，区分传统与 AI 驱动时间	活动分类颗粒度可能不足；时间 ≠ 效率
	验证开销时间	审查/调试/修改 AI 代码所花时间（需标记来源）	衡量 AI 生成代码带来的额外时间和心智负担	难以精准归因；不同项目容错标准差异大
	心智负荷评分	主观问卷（NASA-TLX）、任务切换频率、智能体指标	可反映 AI 是降低还是加重认知负担	主观性强；生理/智能体指标成本或关联性有限
	心流状态频率	自评频率/时长；中断次数记录	AI 应减少中断、促进沉浸；频繁中断表明交互质量差	中断成因复杂；心流评估主观
智能化代码质量与系统韧性	技术债务指数	结合复杂度、重复率、返工率、测试覆盖等综合打分	衡量 AI 对系统结构性质量的正负作用	构建难度高；归因复杂
	代码流失/返工率	某段代码的高频修改/回滚率（按 AI/人工区分）	AI 初稿质量与集成适配能力的体现	源追踪困难；返工未必代表负面
	代码重复率	静态分析工具识别重复片段（按来源区分）	衡量 AI 是否违反 DRY 原则，影响可维护性	检测算法有误差；有时“重复”是有意设计

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）协议将成为行业标准，实现不同系统间智能体的互联互通。