上周二下午三点，你团队合并了一个PR，就40行TypeScript，干净利落。代码评审一遍过——函数可读，类型正确，单元测试也绿了。二十分钟后部署上线，CloudWatch突然狂叫：你的Orders表正在被每一次请求全量扫描。那个刚合并进来的函数，直接调了.scan()，连个分区键过滤都没带。代码是Claude Code写的，而全场没一个人发现——评审人、单测、lint，没有任何一个环节能知道Orders表里躺着800万条记录。

这不是个例。这就是infrawise check要堵上的洞：一个跑在CI里的步骤，它直接读你真实的DynamoDB schema、PostgreSQL索引和实际的查询模式，一旦AI生成的代码对真实基础设施下毒手，构建直接标红。

代码评审和基础设施之间，有条巨大的裂谷，而AI助手正兴高采烈地在裂谷里埋雷。静态分析工具——ESLint、TypeScript、Semgrep之流——它们只盯着代码文本。一个叫listAllOrders()的函数，它们能看出啥？看不出这是全表扫描，也看不出你的PostgreSQL users表上连个索引都没有，随着数据膨胀，那条新写的查询将从毫秒级直接跌入秒级地狱。AI助手更是把这个裂谷掘成了深渊。它们写的代码语法完美，编译通过，测试全绿——但它们的世界观里只有源文件，没有活的基础设施。它们不知道你表的分区键是怎么分布的，不知道你已经建了status字段上的GSI。它们在脑补出来的基础设施上生成代码，一到规模化就在阴暗处崩给你看。

这不是性能优化聊胜于无的事。一个高流量Lambda里跑一次DynamoDB全表扫描，每一次调用吃掉的读取容量单位都正比于表大小，账单和响应延迟同时起飞。一个缺失的索引，让查询耗时跟着行数线性上涨。单元测试抓不住这些，它们只会在生产环境里，用真金白银和用户的忍耐来给你上课。

搞明白三个致命坑，你就知道为啥要在CI里加一道基础设施感知的卡口了。

第一坑：无心的全表扫描。看起来无害的一行.scan()，要是表里只有几十条测试数据，跑起来丝般顺滑。但你的真实表有800万条，每次请求扫一遍，DynamoDB的吞吐瞬间被吃干抹净。infrawise check直接报：表“Orders”正在无过滤扫描，建议换成带分区键或GSI的Query操作。它不是空泛地提醒“注意性能”，而是点名到具体表、具体调用方。

第二坑：索引缺位的慢查询。新业务逻辑来了，AI帮写了条SQL或ORM查询，本地数据少跑得呼呼的。但线上users表没有相关索引，查询走成全表扫描，几个并发就把数据库拖到报警。infrawise check知道你的真实索引结构，当新查询会触发这种线性退化时，构建直接失败，附赠具体修复方向。

第三坑：AI的幻觉基础设施。Claude Code写出的代码，假设表的分区键是按userId均匀分布的，实际上你的分区键是tenantId加时间戳。它不知道你为高频查询已经建了GSI on status，于是生成了冗余地再扫一遍的方案。这种错，代码评审看不出来，因为评审人脑中也只装着代码，没实时连接着云上的表结构。infrawise check把活生生的基础设施拓扑扔进分析，AI的幻觉一戳就破。

infrawise check怎么干活的？它刷新分析你的代码库和云基础设施，然后当有阻塞级发现时，啪地一个exit code 1甩出来，CI流水线就停在部署前。跑一次真实输出长成这样：

Blocking findings 2 at or above high
1. HIGH Full table scan detected on DynamoDB table “Orders”
The table “Orders” is being scanned without any filter, which reads every item.
→ Replace Scan with a Query operation using a partition key or GSI.
2. HIGH Full table scan detected on DynamoDB table “Sessions”
The table “Sessions” is being scanned without any filter. Called from: cleanupExpiredSessions
→ Replace Scan with a Query operation using a partition key or GSI.
✗ Check failed
2 high+ finding(s) must be resolved before deploy

每条发现直指真实的表名和调用函数。修改建议不是通用的文档片段，而是针对你这张表、这个操作的具体替换路径。

往GitHub Actions里加这一步只消几行：

- name: Infrastructure check
run: infrawise check --fail-on high

—fail-on high的意思是只有HIGH级别的发现才拦住构建。MEDIUM和LOW只会刷在日志里，不会打断管道。想更硬气一点，换成—fail-on medium，加强封堵。可用选项再往下一直到low，按你的质量阀值自己调。

让CI知道你的表、你的索引、你的查询模式，这不是过度工程，这是对AI生成代码最基本的尊重。你总不能让800万条记录的Orders表，去给一段连它长啥样都不知的TypeScript赔笑。