当前位置：首页 > news >正文

亚马逊内部数据曝光：6 个工程师 76 天干了 30 人一年半的活，AI 编程五原则拆解

news 2026/6/16 20:08:55

亚马逊内部数据曝光：6 个工程师 76 天干了 30 人一年半的活

这周 Swami（亚马逊云科技 Agentic AI VP）发了一篇文章，公开了亚马逊内部团队用 AI 编程的真实数据。不是营销稿，是跑了几百个团队实验后的总结。

几个数字先看：

6 个工程师，76 天，重写了 Amazon Bedrock 推理引擎——原本计划 30 人干 12-18 个月
Amazon Stores 团队的中位生产力提升 4.5 倍（按部署频率归一化计算），部分团队超过 10 倍
Perfect Order Experience 团队：从两周一个 feature → 一个下午交付
WW Grocery 团队：设计文档从 5 天 → 几小时

这些不是实验室数据，是在 Amazon 内部生产环境跑出来的。

五个核心实践

文章总结了成为"前沿团队"的五个方法。我翻译成人话：

1. 先建 Agent Context，再写代码

别上来就让 AI 写代码。先投入时间做这些：

写清楚的 steering files（引导文件）
统一编码标准
结构化的代码仓库

# 一个好的 steering file 示例（放在项目根目录）## 项目架构
- 服务类型：微服务，Python FastAPI
- 数据库：DynamoDB single-table design
- 部署：CDK + Lambda
- 测试：pytest，覆盖率 > 80%## 编码规范
- 函数不超过 50 行
- 所有外部调用加 retry + timeout
- DynamoDB 操作封装在 repository 层
- 错误处理用自定义 Exception 类## 禁止事项
- 不用 print 调试，用 structlog
- 不在 Lambda handler 里写业务逻辑
- 不硬编码配置，全走环境变量

这些前置投入看起来慢，但 AI agent 有了这些上下文后，产出质量会有质的飞跃。

2. 接受初期变慢

重构工作流程的前 2-3 周，效率可能反而下降。这很正常——需要时间：

把隐性知识文档化
建立 agent 能理解的任务分解方式
调整 code review 流程适应 AI 产出

关键是坚持穿越这个阶段，不要因为短期变慢就退回老路。

3. 保持稳定的任务积压

Agent 需要持续有活干。如果 backlog 空了或者任务定义不清晰，agent 就会空转。

实际操作：

保持 20-30 个 well-scoped 的任务在 backlog 里
每个任务有清晰的输入/输出/验收标准
Agent 可以并行跑多个任务，不需要人盯着

# 一个 agent-ready 的任务定义
task: "添加 S3 文件版本控制支持"
input:- 当前 S3 操作的 repository 层代码- DynamoDB 表结构- 接口规范文档
output:- 新增 version_id 字段到所有 S3 操作- 更新 DynamoDB schema- 补充单元测试（覆盖正常流 + 异常流）
acceptance:- pytest 全通过- 无 type error- 接口向后兼容

4. 先明确意图，再生成代码

不要给 AI 一句模糊的描述就让它动手。先用结构化规格把意图说清楚：

要解决什么问题
约束条件是什么
不做什么（这个经常被忽略）
验收标准

这和 Kiro 的 Specs 理念一致——先写清楚要什么，agent 的产出才能一次到位。

5. 测试前移

让 agent 能自己跑测试、自己修 bug，不要等代码进了 CI pipeline 才发现问题。

# Agent 工作流中嵌入测试
# 1. 生成代码
# 2. 立刻跑测试
pytest tests/ -x --tb=short
# 3. 如果失败，agent 自行修复
# 4. 循环直到通过
# 5. 跑 lint + type check
mypy src/ --strict
ruff check src/
# 6. 全通过后才提交

这样人只需要 review 最终结果，不需要来回打回修改。