AI Shell 先查后问：一次没有动云资源的 IaC 对话

今天在华为云 AI DevSpace 的免费体验版里，我只向 AI Shell 问了一个很简单的问题：请简单介绍你能帮我做什么，不要创建任何云资源。

这个提问本身没有技术难度，但 AI 的回答方式值得单独写一写。因为它没有直接进入“帮你建资源”的流程，而是先把自己的工作边界说清楚：先查现有资源、可用规格和区域信息，给出默认方案让你确认；生成 Terraform 配置后逐段解释；只有在你明确确认之后，才会去执行 plan、apply、destroy。

这就是我想说的“先查后问”：只读在前，改动在后，确认在中间。

只读，是一种先手而不是偷懒

AI Shell 列出的只读能力覆盖计算、网络、存储、身份、监控和账单，比如 ECS 规格、VPC 与子网、安全组、EIP、ELB、EVS、OBS、IAM、CES 告警和 BSS 账单。只读的好处很实际：它先摸清现状，再谈方案，避免在不了解已有资源的情况下凭空生成一份配置。

对开发者来说，这一步也降低了沟通成本。你不用先把现状背下来再提问，AI 可以先去查，再把查到的事实变成方案的前提。如果它查不到或者不确定，它在回答里也会标注出来，而不是用一句“最佳实践”把问题糊过去。

生成代码之前，先把方案讲成人话

这次对话里一个让我印象深的细节是顺序：不是先给代码，而是先给默认方案、等确认，再给代码、再逐段解释。代码对应华为云上的什么资源、为什么这样写，都要说清楚。

这个顺序对 IaC 尤其重要。Terraform 配置一旦 apply，就可能真的改动云上资源。把“方案确认”放在“代码生成”之前，把“代码解释”放在“执行”之前，等于给每一次改动留了两次刹车机会：一次在思路上，一次在代码上。

确认门：AI 主动把自己关在门外

AI Shell 在回答末尾专门列了“不会做的事”，第一条就是：不会在没有你明确确认的情况下修改或创建云资源。这不是一句客套话，而是一种工作规则。

在 Semi-Auto 模式下，我的理解是：AI 可以提议、可以查询、可以生成，但“动手”这个动作的钥匙始终在用户手里。它会说清楚要做什么、碰哪些资源、哪些不可逆，你明确回复“确认”后它才动手。出了问题也不藏着，会告诉你失败在哪、当前状态如何。

这种设计对新手和老手都友好。新手不容易因为一句话就误触生产资源，老手则可以把 AI 当成一个先做功课、再等指令的搭档，而不是一个自作主张的执行者。

一次没有动云资源的对话，为什么值得记录

这次会话结束时，云上什么都没有变，工作区文件夹也是空的。但这恰恰是它有价值的地方：一次好的 AI 协作，不一定要以“建了什么”来证明。它可以先证明一件事——它知道边界，并且愿意在边界内先把事情说清楚。

如果你也在用 AI Shell 做华为云 + Terraform 的工作，不妨试试这个顺序：先让它介绍能力与边界，再让它只读查询现状，接着让它给出方案并逐段解释代码，最后再决定是否确认执行。把确认门留给自己，把重复劳动交给 AI。

今天的体验就到这里。免费体验版的容器会在 3 小时后释放，这也提醒我：重要的结论和代码，还是要及时保存到自己的地方。

本文为原创记录，基于 2026 年 11 月 3 日在华为云 AI DevSpace 免费体验版中的一次真实 AI Shell 对话整理，未创建或修改任何云资源。