当 AI 从“帮我写一段代码”进入“完成需求、提交变更、通过审查并部署生产”的链路，软件工程面对的就不再只是模型能力问题，而是一套完整的自治软件开发生命周期（Autonomous SDLC）问题。真正决定系统能否规模化运行的，是安全边界、组织知识、工程基础设施和生产度量能否同时升级。
这类系统的目标不是让 AI 无限自由地修改代码，而是把它放进一个可观察、可回滚、可验证的交付流程中，让长时间运行的 AI 任务也能被团队信任。
自治开发的核心：把 Prompt 接入交付系统
传统 Copilot 式工具通常服务于单个开发动作：补全函数、解释错误或生成测试。自治 SDLC 则需要处理更长的任务链：
- 理解产品需求和仓库上下文。
- 选择代码、配置和测试文件。
- 修改代码并运行验证。
- 生成变更说明和审查材料。
- 根据反馈继续迭代。
- 在满足策略后进入部署流程。
其中每一步都可能产生风险。一个模型即使能写出正确代码，也不应该直接拥有生产凭据、任意网络访问权限或绕过审查流程的能力。因此，工程重点需要从“提高一次生成的正确率”扩展到“控制整个任务的权限、状态和证据”。
可以把一次 AI 任务抽象成一个受策略约束的执行单元：
# autonomous-task.yaml
apiVersion: delivery.example/v1
kind: AutonomousTask
metadata:
name: improve-checkout-timeout
spec:
repository: services/checkout
baseRef: main
objective: "Add a configurable timeout and tests for upstream payment calls"
permissions:
filesystem:
read:
- src/**
- tests/**
- pyproject.toml
write:
- src/**
- tests/**
network:
mode: deny
secrets:
mode: none
checks:
- command: python -m pytest -q
- command: python -m ruff check .
- command: git diff --check
approval:
required: true
deployment:
environment: staging
这份配置不是某个平台的固定格式，而是一个可以落地的设计示例。关键点在于：任务目标、可读写范围、网络策略、验证命令、审批要求和部署环境都被显式声明。系统可以据此创建临时工作区，限制执行权限，收集测试结果，并在需要人工判断的节点暂停。
安全沙箱不是附加功能，而是执行模型的一部分
自治代理会执行 shell 命令、读取仓库文件、安装依赖、运行测试，甚至可能根据错误信息调整策略。仅靠 Prompt 告诉它“不要做危险操作”无法形成可靠的安全边界，因为 Prompt 不是权限系统。
更稳妥的沙箱设计通常包含以下层次：
- 身份隔离：每个任务使用短期身份和独立工作区，避免共享开发者凭据。
- 文件系统隔离：默认只读，写入范围限制在当前变更所需的目录。
- 网络隔离：默认拒绝外网访问；确实需要访问时，仅允许经过代理的域名和方法。
- 资源限制：设置 CPU、内存、磁盘、进程数和执行时间上限。
- 命令审计：记录每条命令、输入输出、退出码和触发的策略结果。
- 结果验证：把测试、静态检查、依赖扫描和差异审查作为任务证据，而不是让模型自行宣布成功。
在 Linux 环境中，可以用容器作为基础隔离层，再叠加只读根文件系统和最小权限。下面是一个适合本地验证思路的示例：
docker run --rm \
--name autonomous-task \
--network none \
--read-only \
--cap-drop ALL \
--security-opt no-new-privileges:true \
--tmpfs /tmp:rw,noexec,nosuid,size=256m \
--cpus 2 \
--memory 2g \
-v "$PWD:/workspace:rw" \
-w /workspace \
python:3.12-slim \
sh -lc 'python -m pytest -q && git diff --check'
生产环境还需要补充容器镜像签名、系统调用限制、依赖缓存策略、任务取消机制和集中式审计。这个命令不能单独构成完整的安全方案，但它说明了一个重要原则：模型的行为必须落在操作系统和平台策略可以强制执行的范围内。
用代码审查样例提取组织知识
模型知道通用编程知识，却未必知道某个团队如何处理数据库迁移、日志字段、错误码、灰度发布或隐私数据。组织真正有价值的知识，往往散落在代码审查意见、修订记录和长期维护的优秀变更中。
一种可实践的方法是建立“审查样例库”，把高质量变更整理为可检索的工程案例。每个案例至少包含：
- 变更目标和背景。
- 原始实现与最终实现的差异。
- 审查者提出的问题。
- 作者如何修改，以及为什么这样修改。
- 适用范围和不适用场景。
- 关联的测试、监控和发布要求。
检索时不应只返回一段孤立代码，而应返回完整决策上下文。例如，关于“重试”的样例应该同时说明哪些错误可以重试、最大次数是多少、是否需要幂等键，以及失败后如何告警。这样，AI 学到的不是表面代码风格，而是团队的工程判断。
样例库也需要治理。过时的架构、已经废弃的接口和未经验证的审查意见不能持续进入上下文。可以为每条样例添加所有者、更新时间、适用版本和质量评分，并在系统提示中要求代理优先参考当前目录和测试，而不是盲目复制历史模式。
基础设施要适应长时间运行的 AI 任务
当一次 AI 任务从几分钟延长到几十分钟甚至更久，传统的人机交互假设会失效。任务不能依赖单个进程的内存状态，也不能只通过聊天窗口展示进度。
面向长运行任务的基础设施至少需要具备：
- 可恢复状态：保存计划、工具调用、补丁、测试结果和当前阶段。
- 幂等执行：重复运行同一个阶段不会重复创建资源或污染分支。
- 阶段性检查点：在修改代码、运行测试、提交变更和部署前保存状态。
- 人工接管：开发者可以暂停、修改目标、拒绝某个补丁或接管后续操作。
- 可观测性：区分模型耗时、工具耗时、等待审查时间和流水线耗时。
- 失败恢复：遇到依赖安装失败、测试不稳定或上下文不足时，系统能够重试、缩小范围或请求人工输入。
一个简单的状态模型可以这样设计：
from dataclasses import dataclass, field
from enum import Enum
from typing import List
class Phase(str, Enum):
PLAN = "plan"
EDIT = "edit"
VERIFY = "verify"
REVIEW = "review"
DEPLOY = "deploy"
BLOCKED = "blocked"
@dataclass
class TaskState:
task_id: str
phase: Phase = Phase.PLAN
checkpoints: List[str] = field(default_factory=list)
approved: bool = False
def checkpoint(self, name: str) -> None:
self.checkpoints.append(name)
def can_deploy(self) -> bool:
required = {"plan", "edit", "verify", "review"}
return required.issubset(self.checkpoints) and self.approved
state = TaskState(task_id="task-42")
for step in ("plan", "edit", "verify", "review"):
state.checkpoint(step)
state.approved = True
if state.can_deploy():
state.phase = Phase.DEPLOY
print("deployment is allowed")
else:
state.phase = Phase.BLOCKED
print("deployment requires more evidence")
这段代码只展示状态管理的最小模型。真实系统还需要把状态持久化到数据库或事件流中，并为每个工具调用记录输入、输出、权限决策和关联的代码版本。这样，团队才能回答“这次部署为什么发生”“模型看过哪些数据”“哪一步允许了高风险操作”等审计问题。
重新定义生产力：关注特性速度与自动化质量
如果仍然只统计提交次数、代码行数或模型生成的代码量，自治开发很容易被错误激励。更值得关注的是从需求进入队列到可用功能上线的时间，以及这个过程产生的质量和风险。
可以组合观察以下指标：
- Feature lead time：从需求确认到功能进入目标环境的时间。
- Autonomous task completion rate：无需人工重做即可完成的任务比例。
- Review rework rate：进入审查后需要大幅返工的比例。
- Validation pass rate：自动生成变更通过测试、静态检查和策略门禁的比例。
- Deployment rollback rate：自治变更导致回滚的比例。
- Long-running turn efficiency：长时间 AI 任务中，模型推理、工具执行、等待和人工介入各占多少时间。
- Human intervention cost：每类任务平均需要多少人工判断和修改。
这些指标需要结合观察。特性速度提升但回滚率上升，说明自动化可能只是把成本推迟到了生产环境；任务完成率提高但审查返工率不变，说明模型可能在完成形式上的任务，而没有真正理解团队标准。
实践中可以为不同风险等级设定不同自动化边界：低风险文档和测试变更可以更自动化；涉及权限、支付、数据迁移和用户隐私的变更则需要更强的证据和人工审批。自动化程度不应该是一个全局开关，而应由变更风险、可回滚性和验证能力共同决定。
落地时的工程检查清单
开始构建自治 SDLC 时，可以按以下顺序推进：
- 先选择边界清晰、验证成本低的任务类型，例如补测试、修复明确的静态检查错误或更新小型配置。
- 为每类任务定义可写目录、允许命令、网络范围、凭据类型和退出条件。
- 建立可审计的任务状态和检查点，确保长任务能够恢复和人工接管。
- 从真实代码审查中整理高质量样例，并持续清理过时内容。
- 将测试、静态分析、依赖扫描、策略检查和部署门禁接入同一条证据链。
- 用特性交付速度、返工率、回滚率和人工介入成本评估收益，而不是只看生成量。
- 从 staging 开始验证，再逐步扩大到更高风险的生产路径。
自治开发的关键不是让模型获得更多自由，而是让系统拥有更清晰的权限、更完整的证据和更可靠的恢复能力。当 Prompt、代码审查知识、沙箱、流水线和度量体系被连接起来，AI 才可能从一个代码生成工具，逐步成为可被工程团队信任的交付参与者。