用本地 AWS 仿真给 AI 调试闭环

删掉一个空字典，也可能让 DynamoDB 的下一次写入失败。Quito Lambda 在 10 月 28 日的一场演示，用两个投票故障展示了 AI 调试的关键：让代理运行能暴露真实服务约束的测试，再由工程师判断修复是否符合业务要求。

作者给出的路径是让应用通过原有 SDK 访问 LocalStack，在本地复现、修改和验证。它能减少调试时接触真实 AWS 的需要，但安全边界还得靠凭证隔离、命令权限和测试配置共同建立。

Mock 返回成功，不代表数据库接受这次更新

演示者 Gandhy García 是 Stack Builders 的开发者。他使用的项目是一个 Python 和 FastAPI 编写的 Chameleon 游戏 API，支持创建游戏、加入游戏、开始游戏、投票和查询结果。

每局游戏存成一个 DynamoDB item，里面放玩家、主持人、秘密词、游戏状态和投票记录。这个结构是为了方便演示，原文没有把它推荐为生产游戏的通用数据模型。

问题出在投票链路：接口调用仓储函数 cast_vote，后者通过 DynamoDB 的 update_item 和条件表达式修改数据。

如果测试把仓储调用 Mock 掉，固定返回成功，它能验证接口如何处理成功结果，却无法回答另一个问题：数据库到底接不接受这条更新表达式？

Mock 能证明代码处理了预设响应，不能证明数据库会执行实际请求。

LocalStack 在本地模拟 AWS 服务，让集成测试经过应用的仓储代码，再由模拟服务处理数据库操作。它提供的反馈比一个固定成功的返回值更接近实际故障发生的位置。

演示通过 Docker Compose 启动固定版本的 LocalStack 镜像，并启用 DynamoDB。原文没有给出具体镜像版本号。应用仍使用 AWS 的 Python SDK boto3，不需要改用一套 LocalStack SDK。

接入主要靠配置：本地服务端口 4566、选定的 region，以及假的 AWS access credentials。独立的 .env.test 保存测试配置，conftest.py 通过 Pydantic 加载，让测试框架负责选择服务地址。

这里有个容易漏掉的细节：假凭证不会自动把请求导向本地。endpoint 和凭证必须同时配置正确。另外，启动模拟器使用的 LocalStack authentication token，与应用访问模拟 AWS 服务使用的假凭证用途不同，不能一概当成可以公开的测试字符串。

两个投票故障，分别暴露了存储约束和业务遗漏

第一个故障来自预先准备好的错误重构：创建游戏时，原来会初始化一个空的 votes 字典，重构把它删掉了。

表面看，这只是省掉一个暂时没有内容的字段。但后面的投票操作会更新 votes 下的嵌套属性。父级 map 不存在，嵌套更新就无法执行。原文补充的 AWS 文档规则也支持这一点。

修复前，已有 4 个测试失败。代理运行测试、定位到这次重构，再恢复初始化。演示中，代理报告修改后全部 30 个测试通过，并完成了格式检查。

这个案例不能推导出「所有字段都应该提前初始化」。真正需要保留的是后续操作依赖的前提。在这套实现里，空 votes map 虽然没有业务数据，却承担了让下一次写入合法的作用。

第二个故障与数据库能否执行无关：玩家可以投给自己。

应用已经禁止同一玩家重复投票，但没有禁止自投。演示中，Bob 给 Bob 投票，接口返回 HTTP 204，请求成功了。

Gandhy 要求代理先用测试复现，再修复。演示展示了新增测试，以及仓储层比较投票者与目标玩家的条件。代理也运行了连接 LocalStack 的测试。

随后，他们又从 API 验证：Carol 给 Carol 投票返回错误，Carol 给 Alice 投票仍返回 204。

这组验证很重要。只检查「自投被拒绝」，无法排除修复顺手破坏正常投票的可能。原文没有给出错误响应的具体状态码，也没有贴出完整条件表达式，因此不能进一步判断错误分类和实现细节。

两个案例的边界也很清楚：模拟服务可以让存储约束暴露出来，但「玩家不能投自己」必须由人明确提出。数据库不会替产品补齐规则。

测试可重复，还需要把数据和权限分开

演示的 pytest 测试框架会为每次测试会话创建临时表，表名带随机标识，测试结束后删除。

手动填充的游戏表则继续保留在同一个 LocalStack 实例里。这样，Gandhy 可以查看游戏、尝试 API 请求，代理反复运行测试时也不会清掉演示数据。本地日志还能看到建表、测试写入和删表过程。

这里可复用的设计是资源归属：测试创建自己的资源，清理自己的资源。仅仅约定「大家都用本地数据库」，还不足以防止清理步骤误删其他开发数据。

安全边界也是如此。LocalStack 负责提供本地服务，不负责限制代理访问整台机器，更不能阻止代理通过另一条命令连接 AWS。

演示组合了几层措施：仓库指导要求代理运行测试、避开真实凭证；代理设置限制命令；独立测试配置选择本地服务。它们承担不同职责，不能互相替代。

本地服务地址只是安全边界的一层，代理能读取什么、执行什么同样重要。

原文还提出了超出演示本身的工程建议：让真实云凭证不进入代理测试环境，并在测试初始化时拒绝意外的远程 endpoint。这些属于建议，不能写成演示已经完整验证过的能力。

审查也不能只看绿色测试结果。代理改了业务代码，也可能改了断言；如果暴露问题的断言被删除，通过测试的证据价值就会下降。

我的判断

我认同这篇文章选择的切入点：先找一个依赖实际服务行为的失败，再给 AI 一条稳定的验证路径。它比泛泛要求代理「仔细检查」更有用，因为错误能够被重复观察，修复也有明确验收依据。

但这仍是两个准备好的调试案例。作者没有提供与纯 Mock、直接连接 AWS，或人工调试的耗时和成功率对照。因此，它能说明这种工作方式可行，不能证明引入 LocalStack 后，团队调试效率一定提升多少。

Mock 也有自己的位置。只验证接口的响应处理时，它通常更直接；涉及更新表达式、条件写入和存储行为时，再增加服务集成测试更合适。关键是让不同测试回答各自能回答的问题。

本地通过还不等于云端部署通过。原文明确保留了生产性能和目标 AWS 环境验证的责任，也提到可以混用服务，例如 DynamoDB 走本地，Amazon Bedrock 仍调用 AWS。此时只能说部分链路在本地，必须逐项确认请求去向。

成本同样有前提。原文称 LocalStack 当时的定价说明将免费 Hobby 计划限制为非商业用途，不同计划和档位的服务覆盖也不同。商业团队不能把「少用 AWS 资源」直接算成「工具免费」；如果只需要 DynamoDB，本篇提到的 DynamoDB Local 也应该进入比较范围。

能拿来做什么

• 给 AI 修复数据库问题时，先要求它交付一个可重复失败的测试，再修改实现。验收同时覆盖故障请求和相邻的正常请求，例如自投失败、投给其他玩家成功。
• 给测试单独配置 endpoint、region 和测试凭证，并在初始化阶段校验请求目的地。让测试框架决定连哪里，减少依赖代理每次运行时记住约定。
• 为集成测试创建带独立标识的临时资源，把清理范围限制在本次测试创建的对象中，保留日常手动调试使用的数据。
• 审查 AI 修复时，同时看业务代码、测试断言和测试环境配置。根据依赖范围比较 LocalStack 与 DynamoDB Local，并为本地测试没有覆盖的云端行为保留验证步骤。