Project 不是文件夹，而是一层新的默认信任边界#

官方说明中，一个 Project 包含底层 AWS account，以及成员共享和资源相关的设置。新用户创建项目后，AWS 会自动建立这套结构并应用额外安全控制。成员通过邮件邀请加入，而且只获得被指定项目的访问权。S1

这意味着 Project 更接近一个预配置的安全域，而不是控制台里的视觉分组。对个人开发者来说，它把过去需要自己组合的几件事放在一起：资源归属、成员身份、权限关系、成本边界和 Agent 访问入口。

可以把传统方式与新方式抽象成两条路径：

1
传统路径：
2
Identity -> IAM policy -> role/user -> resource -> billing/account
3

4
简化路径：
5
Identity -> Project -> platform-managed permissions -> resource
6
                   -> spend limit / members / agent setup

第二条路径减少了显式配置，但它并不意味着 Agent 拿到了“无限权限”。相反，平台必须在后台维护更严格的映射：哪个 Agent 属于哪个 Project、哪些服务之间允许建立权限、哪些成员可以改变项目设置，以及什么时候需要切换到高级治理能力。

工程上最重要的变化，是默认安全边界开始围绕“项目”而不是“账号里所有东西”组织。对于一次性原型、学生项目和小团队，这种默认隔离比让每个新人从 AdministratorAccess 起步更合理。

Coding Agent 的一段 Prompt，其实是 Bootstrap Protocol#

AWS 官方演示中，新项目创建后会展示一段给 Coding Agent 的 Prompt。Agent 接收后安装 AWS CLI 和 Agent Toolkit，完成登录，并生成包含工作指导的 CLAUDE.md。随后示例 Agent 创建了 Lambda、DynamoDB 和 API Gateway，并完成部署。S1

表面看这只是“复制一段提示词”，但从 Agent 工程角度，它更像一个 bootstrap protocol：把环境发现、CLI 安装、身份建立、项目约束和仓库级说明一次性初始化。

这类流程至少应该区分四层：

1. 身份层：Agent 以谁的授权工作，凭据是否短期、是否能撤销。
2. 项目层：Agent 被限定在哪个 Project，能否跨项目枚举资源。
3. 资源层：Lambda、DynamoDB、API Gateway 等资源之间的权限由谁建立。
4. 仓库层：CLAUDE.md 等文件告诉 Agent 应遵守哪些开发规范，但它不是云端强制授权本身。

最后一点尤其容易混淆。Prompt 和 CLAUDE.md 是行为指导，IAM/Project 权限才是强制边界。即使 Prompt 写着“不要删除生产数据库”，如果 Agent 的云身份仍允许删除，那么安全性依旧依赖模型是否服从文本。可靠设计应该让高风险操作在权限层不可达，而不是只在 Prompt 里禁止。

“自动配置权限”不等于“权限问题消失”#

AWS 表示，控制台工作流与 Coding Agent 会自动配置受支持服务和资源之间的权限关系。S1 对新用户而言，这是体验提升；对工程团队而言，则应该继续问三个问题：权限是谁创建的、权限范围有多大、权限生命周期什么时候结束。

可以用下面的检查清单审视自动权限：

1
[ ] Agent 是否只能看到当前 Project？
2
[ ] 新建资源时，服务角色是否按资源范围收窄？
3
[ ] 删除 Project 后，临时角色与授权是否同步回收？
4
[ ] Agent 登录凭据是否有明确过期时间？
5
[ ] 高风险动作是否需要额外确认或升级权限？
6
[ ] CloudTrail/审计记录能否区分人类与 Agent 操作？
7
[ ] 从简化体验升级到 advanced features 后，旧权限如何映射？

这里的核心原则是：自动化应该降低配置成本，而不是降低可审计性。 如果一个平台替开发者生成了权限，那么它反而更应该提供清晰的解释界面，让用户知道“为什么这个角色存在、谁在使用、它能做什么”。

支出上限是 Agent 时代非常重要的第二道护栏#

新的体验允许付费计划为每个 Project 设置月度 spend limit。官方描述中，当项目接近上限时会先通知；达到上限后，AWS 会暂停项目，而不是继续累计费用；不同 Project 可以拥有不同上限。S1

这对 Coding Agent 特别重要。传统的人类操作通常具有天然节奏：人会打开控制台、看价格、点击创建。Agent 则可能在一个循环里连续创建资源、重试部署、扩大实例规格，甚至因为测试失败反复调用昂贵服务。此时，仅有 IAM 只能回答“允许不允许”，不能回答“允许花多少钱”。

因此 Agent 的生产护栏至少需要两个正交维度：

1
Capability Budget: 允许创建/修改哪些资源？
2
Economic Budget: 允许消耗多少费用？

一个 Agent 可以被允许创建 Lambda，但项目月预算只有 20 美元；也可以有更高预算，却不能触碰某些网络或身份资源。把二者分开，才能避免“权限最小化”与“成本可控”被错误地当成同一个问题。

从简化模式升级到完整 AWS，关键是“不迁移”#

AWS 还提供 advanced features 激活路径。当团队需要多 Region、自定义 Organizations policy 等能力时，可以在不迁移工作负载的情况下进入完整 AWS 组织能力，已有配置会保留并反映到下层 AWS 服务。S1

这个设计值得注意，因为很多“简化云平台”最大的问题不是起步，而是毕业：原型阶段体验很好，一旦业务成长就必须迁移到另一套账号、网络或权限体系。AWS 选择让简化层建立在真实 AWS 资源之上，理论上降低了这类断层。

但升级也意味着隐藏的复杂度重新显现。团队应在升级前导出或记录：项目成员、Agent 身份、自动生成角色、服务间权限、预算、Region 使用和审计要求。不要等到需要 Organizations/SCP 时才第一次理解此前平台替你做了什么。

一套可复现的验证方法#

如果拿到新的 Builder Experience，可以不依赖主观“好不好用”，而是做一组边界实验。先创建两个 Project A/B，各部署一个最小资源；让 Agent 在 A 中列资源并尝试读取 B，确认跨项目隔离。然后在 A 中部署 Lambda + DynamoDB，检查自动生成的角色是否只覆盖必要资源。再设置低额 spend limit，观察接近和达到阈值时的通知、暂停与恢复行为。

同时记录以下指标：首次从注册到部署成功的时间、人工 IAM 配置次数、Agent 需要人工确认的次数、自动生成角色数量、跨项目拒绝是否可解释、达到预算后的停止延迟。它们比“几分钟就部署成功”更能反映这套体验是否适合长期工程。

AWS 这次变化真正值得关注的，并不是把按钮变少，而是云平台正在适应一个新事实：第一位操作云资源的“开发者”越来越可能是 Coding Agent。 当执行者从人变成高频自动循环后，好的默认值、项目隔离、权限自动化、可审计身份和经济预算必须一起设计。简化不是把控制面删掉，而是让控制面在正确的时候出现。