AI 辅助编码正在改变研发流程：开发者不仅调用 CI、制品库和 Kubernetes，还会调用代码补全、聊天模型、智能代理与自动评审工具。平台团队面对的问题因此不再只是“如何提供基础设施”，而是“哪些 AI 能力应成为平台能力，以及如何在统一治理和团队自主之间划线”。
这类变化并不意味着平台团队要接管所有 AI 工具。更合理的方向，是把重复、敏感且需要审计的部分沉淀为共享能力，同时保留开发团队选择模型和设计工作流的空间。
哪些 AI 能力适合进入平台层
适合平台化的能力通常具有三个特征：多个团队重复建设、涉及组织级风险，或者需要统一的成本与可观测性管理。
可以将平台能力划分为四组：
- 统一模型入口：为不同模型提供稳定的内部 API，集中处理身份验证、限流、超时、重试和模型路由。
- 安全护栏：阻止密钥、个人数据或受限代码进入未经批准的模型；限制可用模型、区域和供应商。
- 可观测性与成本管理：记录调用方、模型、延迟、Token 用量和失败率，但避免默认保存完整提示词。
- 开发者自助服务：通过模板、CLI 或开发者门户，让团队自行申请权限、创建评测集和接入流水线。
平台不必统一每一条提示词，也不应强制所有团队采用同一种代理框架。提示词、上下文组装和业务评测往往包含领域知识，更适合由产品团队掌握。平台应提供“铺好的道路”，而不是只有一条不能绕开的轨道。
标准化接口，而不是冻结工具选择
AI 工具变化很快。如果平台直接把某个 IDE 插件、模型版本或代理框架写进组织标准，迁移成本会迅速累积。更耐用的标准化对象是边界和契约，例如：
- 调用必须经过组织身份认证。
- 生产数据只能发送到批准的模型和区域。
- 每次请求都必须携带团队、应用和环境标识。
- 模型输出进入生产操作前必须经过确定性校验或人工确认。
- 平台公开延迟、成本和质量指标，但业务团队负责定义“回答是否有用”。
这种方式允许团队更换模型或编排框架，同时保留一致的审计与安全控制。平台团队管理的是风险边界，开发团队管理的是解决问题的方法。
可以这样实践：搭建一个最小 AI 网关
下面是一个可运行的示例，用来演示平台层可以承担的最小职责：内部 API Key 校验、模型白名单、请求大小限制、调用标识和不保存原始提示词的审计日志。
假设条件：上游服务提供 OpenAI 兼容的 POST /chat/completions 接口。运行前需要把 UPSTREAM_URL 和 UPSTREAM_TOKEN 替换为组织批准的服务地址与凭据。该示例用于说明架构，不包含生产级高可用、分布式限流和敏感信息检测。
创建 requirements.txt：
fastapi==0.115.0
uvicorn==0.30.6
httpx==0.27.2
创建 gateway.py：
import hashlib
import json
import logging
import os
import time
import uuid
import httpx
from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel, Field
UPSTREAM_URL = os.environ["UPSTREAM_URL"].rstrip("/")
UPSTREAM_TOKEN = os.environ["UPSTREAM_TOKEN"]
PLATFORM_API_KEY = os.environ["PLATFORM_API_KEY"]
ALLOWED_MODELS = set(os.getenv("ALLOWED_MODELS", "approved-model").split(","))
logging.basicConfig(level=logging.INFO, format="%(message)s")
app = FastAPI(title="Internal AI Gateway")
class ChatRequest(BaseModel):
model: str
messages: list[dict[str, str]] = Field(min_length=1, max_length=50)
temperature: float = Field(default=0.2, ge=0, le=2)
@app.get("/healthz")
def healthz():
return {"status": "ok"}
@app.post("/v1/chat/completions")
async def chat(
request: ChatRequest,
x_platform_key: str = Header(),
x_team: str = Header(),
):
if x_platform_key != PLATFORM_API_KEY:
raise HTTPException(status_code=401, detail="invalid platform key")
if request.model not in ALLOWED_MODELS:
raise HTTPException(status_code=403, detail="model is not approved")
payload = request.model_dump()
encoded = json.dumps(payload, ensure_ascii=False).encode()
if len(encoded) > 64 * 1024:
raise HTTPException(status_code=413, detail="request is too large")
request_id = str(uuid.uuid4())
prompt_hash = hashlib.sha256(encoded).hexdigest()[:16]
started = time.monotonic()
async with httpx.AsyncClient(timeout=30) as client:
response = await client.post(
f"{UPSTREAM_URL}/chat/completions",
headers={"Authorization": f"Bearer {UPSTREAM_TOKEN}"},
json=payload,
)
duration_ms = int((time.monotonic() - started) * 1000)
logging.info(json.dumps({
"request_id": request_id,
"team": x_team,
"model": request.model,
"status": response.status_code,
"duration_ms": duration_ms,
"payload_hash": prompt_hash,
}))
if response.status_code >= 400:
raise HTTPException(status_code=502, detail="upstream model failed")
return response.json()
安装并启动：
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
export UPSTREAM_URL="https://your-approved-provider.example/v1"
export UPSTREAM_TOKEN="replace-me"
export PLATFORM_API_KEY="local-platform-key"
export ALLOWED_MODELS="approved-model,approved-model-small"
uvicorn gateway:app --host 127.0.0.1 --port 8080
从另一个终端调用：
curl --fail-with-body http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-H 'X-Platform-Key: local-platform-key' \
-H 'X-Team: payments' \
-d '{
"model": "approved-model",
"messages": [
{"role": "user", "content": "为这个函数生成三个边界测试用例"}
],
"temperature": 0.2
}'
这个网关刻意不记录完整提示词，只记录摘要、团队、模型、状态码和延迟。实际部署时还应加入工作负载身份、按团队配额、敏感信息检测、指标导出、密钥轮换和数据保留策略。仅有一个代理服务并不等于完成了 AI 治理。
工作流变化比工具接入更难
AI 不只是新增一个 API，它还会改变代码进入仓库和生产环境的方式。平台团队需要重新检查原有的质量关卡：
- AI 生成的代码是否仍经过同样的测试、静态分析和依赖扫描？
- 代理能否直接创建分支、合并代码、修改基础设施或触发部署？
- 当输出错误时，能否追溯使用的模型、工具权限和输入版本？
- 自动化节省的是开发时间，还是把审查成本转移给了维护者？
尤其要区分“生成建议”和“执行操作”。代码解释、测试草稿等低风险任务可以更开放；数据库迁移、生产发布和权限修改则应采用短期凭据、最小权限与人工确认。不要因为操作者从脚本变成了代理，就降低原有的生产控制标准。
落地时从一条铺好的道路开始
平台团队不必一次建立完整的 AI 控制平面。更稳妥的采用顺序是：
- 选取一两个高频场景，例如代码问答或测试生成。
- 提供统一入口、身份认证和基础审计，而不是先建设复杂门户。
- 同时记录延迟、成本和开发者反馈，避免只统计调用次数。
- 明确禁止的数据、允许的模型以及需要人工批准的操作。
- 给高级团队保留例外机制，但要求例外有负责人、期限和退出计划。
成功的平台能力应让安全路径比绕过平台更容易。如果开发者必须提交多张工单才能试用模型，他们往往会寻找未经治理的替代方案；如果平台隐藏了过多模型差异，又可能妨碍团队优化质量和成本。真正的平衡点，是统一身份、策略和可观测性，同时让业务团队保有模型选择、提示设计与评测方法的自主权。