AI Coding 的工程转折：从“生成得更快”到“可被验证地生成”

原创

IT大佬 jzit-top

发布于 2026-10-27 15:51:53

1640

AI Coding 的瓶颈已经不在生成侧。Claude Code、Cursor 能在几十分钟内修改几十个文件，但人的 Review 能力并没有同步放大。蚂蚁数科在两个真实项目中的实践给出了一个值得注意的信号：40 万行 Rust 新项目从第一天内建约束与验证闭环，60 万行 C++ 存量项目先重建事实源和质量门禁再引入 Agent，改造后代码缺陷率从 20% 以上压降至个位数。这组数据的因果链不在模型更强，而在于验证能力终于跟上了生成能力。AI Coding 的工程转折，是从“让 AI 写得更快”转向“让 AI 写出的东西可被机械验证、可被审计、可被拒绝”。

验证闭环：把“记得跑测试”变成不可跳过的控制流

Superpowers（GitHub 超 26.5 万 Star）的核心规则只有一条：NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST。但真正关键的不是 TDD 的形式，而是测试不再由 Agent 自行决定是否运行。如果“跑不跑测试”仍然留在模型的判断里，它可能因为上下文接近上限或自认为任务已完成而跳过验证。可行的工程做法是将测试嵌入 Harness 控制流：文件变更触发关联测试，失败结果结构化回喂模型，Agent 进入修复循环，只有门禁放行才进入下一阶段。

以下是一个最小化的分层门禁实现，Lint 与类型检查在每次变更后强制触发，全量测试仅在任务完成前执行：

import subprocess, sys

QUICK_GATES = [
    ["ruff", "check", "--fix", "src/"],
    ["mypy", "src/", "--ignore-missing-imports"],
]
FULL_GATES = [
    ["pytest", "tests/", "-q", "--tb=short"],
]

def run_gate(cmd: list[str]) -> dict:
    r = subprocess.run(cmd, capture_output=True, text=True, timeout=300)
    return {"cmd": " ".join(cmd), "ok": r.returncode == 0,
            "stderr": r.stderr[-2000:]}

def gate_or_feed_back(agent_loop, stage: str) -> bool:
    gates = QUICK_GATES if stage == "on_change" else FULL_GATES
    for cmd in gates:
        res = run_gate(cmd)
        if not res["ok"]:
            # 失败不是抛异常，而是作为结构化工具结果回喂，驱动修复
            agent_loop.feed({"role": "tool", "content": res})
            return False
    return True

这段代码的要点在于失败不崩溃、不中断，而是转化为下一轮修复的输入。反馈越早回到 Agent，错误向后续阶段传播的范围就越小。

生成与裁决分离：隔离工作区与机器可检查的任务契约

更隐蔽的失败模式是“看似合理但实际越权”的修改。智能体在开发者当前工作区中安装依赖、改配置，失败后无法区分哪些变化来自任务本身、哪些来自尝试过程。解决思路是生成与裁决分离：Agent 在隔离的 git worktree 中工作，任务契约以机器可读的 JSON 定义，allowed_paths 之外的文件一旦出现在 diff 中，流水线直接失败。

{
  "id": "fix-parser-empty-input",
  "prompt": "修复 parse_items 空输入异常，补充测试。不要修改公开函数签名。",
  "allowed_paths": ["src/parser.py", "tests/test_parser.py"],
  "required_commands": [
    ["python", "-m", "pytest", "tests/test_parser.py", "-q"],
    ["python", "-m", "compileall", "-q", "src"]
  ],
  "timeout_seconds": 300
}

allowed_paths 不是提示词装饰，而是裁决规则。任务完成后逐条比对 diff 与白名单，越界即拒绝，与测试是否通过无关。确定性门禁（单测、类型检查、路径白名单）负责裁决，模型评价只能作为补充信息，不能替代程序断言。

权限必须 fail-closed：不依赖 Agent 的“自觉”

生产环境的另一个分水岭是权限。网龙和 PingCAP 的一线实践给出的原则是：在可逆、低爆炸半径且可追溯的隔离环境内，按任务范围给 Agent 最小充分权限；数据库变更、生产操作、外部网络访问必须严格收紧或设置人工门禁。这必须由代码强制执行，而非写入 System Prompt 寄希望于模型遵守。三值权限引擎是一个可落地的起点：allow 放行，deny 变成工具错误回喂模型，ask 在无人值守时默认拒绝——自主性永不静默升级。

from enum import Enum

class Decision(Enum):
    ALLOW = "allow"; ASK = "ask"; DENY = "deny"

SENSITIVE = (".ssh/", ".aws/credentials", ".env", ".pem", "id_rsa")

def decide(tool: str, arg: str, unattended: bool) -> Decision:
    if any(p in arg for p in SENSITIVE):
        return Decision.DENY
    if tool == "execute_bash" and "git push" in arg:
        return Decision.DENY if unattended else Decision.ASK
    if tool in {"write_file", "edit_file"}:
        return Decision.DENY if unattended else Decision.ASK
    return Decision.ALLOW

敏感路径的保护优先级高于任何普通规则，无人值守场景下 ask 收敛为 deny，checker 异常时一律拒绝。这不是对 Agent 的不信任，而是对 Agent 会被错误输入引导这一事实的工程承认。

AI Coding 的成熟度，最终不以“AI 写了多少代码”衡量，而以验证闭环是否机械、裁决是否独立于生成、权限是否 fail-closed 衡量。当生成速度不再是稀缺资源，证明正确性的证据、拒绝越权的门禁、可回滚的隔离工作区，才是工程团队真正需要建设的能力。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

工程化