InfoQ 已开放 AI-Assisted Engineering 在线认证项目报名。这个为期五周的项目面向高级工程师和架构师，尤其是已经每天让编程代理处理生产代码的团队。此时真正困难的问题不再是“提示词怎么写”，而是代理可以修改什么、哪些操作必须禁止，以及如何在人工审查前自动发现错误。
从提示词技巧转向工程控制
当编程代理只负责生成一个函数时，开发者可以逐行检查输出。一旦代理开始跨文件修改、升级依赖、调整数据库访问或生成部署配置，风险模型就发生了变化。
团队需要把关注点放到三个可执行的控制面上：
- 权限边界：限定代理能够读取、修改和执行的资源。
- 自动验证：在变更进入人工评审前运行格式检查、静态分析、测试和安全扫描。
- 责任链路：记录代理收到的任务、执行过的命令、产生的差异以及批准变更的人。
这也是该项目所反映的行业变化：对于已经日常使用编程代理的高级工程师，提示词只是输入接口，仓库规则、测试系统和交付门禁才是决定结果能否进入生产环境的关键。
把“允许触碰什么”写成机器可读策略
仅在团队文档里写“不要修改生产配置”并不够。代理可能忽略约定，人也可能在审查较大的差异时漏看文件。可以这样实践：在仓库中维护一份权限策略，再由代理包装器或 CI 脚本执行检查。
下面的示例假设团队使用 YAML 描述边界。它不是该认证项目公开的专用格式，而是一种可以按现有工具改造的最小策略：
# .ai-agent-policy.yaml
version: 1
workspace:
readable:
- "src/**"
- "tests/**"
- "docs/**"
- "package.json"
writable:
- "src/**"
- "tests/**"
- "docs/**"
denied:
- ".env*"
- "secrets/**"
- "infra/production/**"
- "migrations/**"
commands:
allowed:
- "npm test"
- "npm run lint"
- "npm run typecheck"
require_human_approval:
- "npm install *"
- "git push *"
- "kubectl *"
denied:
- "rm -rf *"
- "terraform apply *"
limits:
max_changed_files: 20
max_added_lines: 500
策略中的路径和命令需要替换成项目实际使用的目录及工具。关键点不是 YAML 本身，而是把模糊约定变成可检查的规则。例如，依赖清单可以读取，但修改依赖必须经过人工批准；测试代码可以自动更新，而生产基础设施和密钥目录始终拒绝访问。
边界还应按任务变化。修复前端样式的代理不需要数据库迁移权限，升级数据库驱动的任务则可能需要临时开放迁移目录。长期授予宽泛权限会让一次错误推理扩散成仓库级事故。
让 CI 在人工之前拦截明显错误
权限控制只能限制影响范围，不能证明代码正确。代理生成的实现可能通过语法检查，却改变接口兼容性、遗漏异常路径，或者让测试通过但引入不安全依赖。因此，自动验证必须覆盖多种失败模式。
可以这样实践：为代理提交的分支增加一个独立的 GitHub Actions 工作流。以下示例以 Node.js 项目为假设，运行前需要确保 package.json 中已经定义 lint、typecheck 和 test 脚本。
# .github/workflows/agent-change-check.yml
name: Validate AI-assisted changes
on:
pull_request:
permissions:
contents: read
jobs:
verify:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- name: Install locked dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npm run typecheck
- name: Test
run: npm test -- --runInBand
- name: Reject protected-path changes
env:
BASE_SHA: ${{ github.event.pull_request.base.sha }}
run: |
changed_files="$(git diff --name-only "$BASE_SHA" HEAD)"
printf '%s\n' "$changed_files"
if printf '%s\n' "$changed_files" | grep -Eq '^(secrets/|infra/production/|\.env)'; then
echo "Protected files were changed; human escalation is required."
exit 1
fi
这个工作流做了两类检查：一类判断代码是否满足项目质量标准，另一类检查代理是否越过目录边界。实际项目还可以加入 API 契约测试、数据库迁移演练、软件成分分析、密钥扫描和端到端测试。
需要注意，自动检查只会发现已经被编码成规则的问题。测试集没有覆盖的业务约束、架构方向错误和看似合理的需求误解，仍然需要工程师判断。让代理自己生成测试再用同一批测试证明实现正确，也容易形成自证闭环；关键路径应保留独立测试、历史回归样例或人工编写的验收条件。
审查代理的过程，而不只审查最终差异
传统代码评审通常围绕最终 diff 展开，但代理可能在得到最终结果前读取敏感文件、执行高风险命令，或多次尝试会修改外部状态的操作。只保存代码差异不足以完成审计。
团队可以要求每个代理任务至少保留以下信息：
- 原始任务与验收条件；
- 使用的模型、工具和策略版本；
- 读取及修改的文件列表；
- 执行的命令、退出码和验证结果；
- 需要人工批准的操作及批准者；
- 最终提交与代理运行记录之间的关联标识。
日志本身也可能包含源代码、访问令牌或用户数据，因此不能无限制集中存储。落地时要进行脱敏，设置访问控制和保留期限，并明确哪些信息不得发送给外部模型服务。
采用前的检查清单
五周认证项目的价值，应当结合团队已经进入的使用阶段判断。对于偶尔用代理补全代码的开发者，先建立稳定测试和基础代码评审可能更紧迫；对于每天让代理处理生产仓库的高级工程师和架构师，系统化讨论权限、验证和治理已经是现实需求。
在扩大使用范围前，可以检查以下事项：
- 代理是否默认使用最小权限，并在任务结束后撤销临时授权；
- 密钥、生产配置、基础设施和数据库迁移是否有明确边界；
- 每次变更是否经过可重复执行的静态检查、测试和安全扫描；
- 高风险操作是否必须由明确的代码所有者批准；
- 是否能够从提交追溯到任务、命令、验证结果和审批记录；
- 是否定义了失败后的停止条件、回滚方式和责任人。
AI 辅助工程走向成熟，不取决于代理一次能生成多少代码，而取决于团队能否限制错误的影响范围、尽早暴露问题，并让每次生产变更都保留清晰的工程责任。