AI推理强大不代表适合工作流：架构决策的反思
工程团队为自动化DNS记录生成重现了用AI做workflows的陷阱——回顾曾用Claude生成Terraform，最后移除了它，因为收益不足风险。
完整中文译文
一年多以前——按 AI 时代的时间尺度，这几乎已经是上古史了——我写过一篇博客，讲如何利用 AI 构建新的自助服务能力。
那时候，感觉未来已经到来。
我们构建了一个能够创建新自助服务操作的自助服务操作，帮助我们提高交付速度、减少瓶颈，并让一支规模不大的 Platform Engineering 团队能够为数百名开发者提供支持。
其中最有意思的一部分，是使用 Amazon Bedrock 在运行时动态生成 Terraform 代码，让系统能够基于我们现有的 Terraform 模块，判断该如何配置新的云资源。
现在回头看，放弃这种方案，是我们做过最正确的工程决策之一。
当时，它看起来只是一个孤立的技术决策。
最近，我们遇到了一个小得多的问题：希望通过自助服务平台自动在 Cloudflare 中创建 DNS 记录。
第一个提案完全符合当下的思路：“我们来构建一个 Claude Skill 吧。”
我立刻产生了一种强烈的似曾相识感。
但我的犹豫并不在于 AI 能不能做到，而在于它是否应该这样做。
我们只是问错了问题。
如今，许多工程师感觉自己过去十年学到的一切，突然都变得没那么重要了。
我们是 DevOps 工程师。
我们是 Platform Engineer。
过去，我们会花时间设计系统、定义标准、评审架构，并在写下第一行代码之前做好规划。
每一个自动化项目都会从同一个问题开始：
“我们应该如何自动化这件事？”
如今，这个问题已经悄然发生了变化。现在我们问的是：
“怎样让 AI 来做这件事？”
乍看之下，这似乎是一种进步。有时确实如此。Large Language Model 已经从根本上改变了我们构建软件的方式。过去需要几个小时的任务，现在几分钟就能完成；只需要一个 prompt，就能生成完整的原型。
这种诱惑显而易见。如果 AI 能做到……为什么不让 AI 来做？
但在这个过程中，我们很多人无意识中改变的不只是工具，也改变了自己的工程流程。
我们不再先设计架构，而是先选择技术。
讨论变成了：
“我们应该使用 Claude 还是 GPT？”
“这应该是一个 Agent 吗？”
“Hermes 能做到吗？”
而在回答这些问题之前，我们其实应该先回答一个简单得多的问题：
这个问题真的需要“推理”吗？
运行时推理与确定性执行
人们经常谈论 AI Agent、Skill、MCP server 和 LLM workflow，仿佛它们只是下一代自动化技术。
但它们解决的是另一类问题。
LLM 非常擅长处理混乱、模糊的问题。它们可以适应变化，也可以调整计划。但推理会引入概率——结果不再是 100% 确定的。
这种能力非常强大，但也伴随着根本性的取舍。按照定义，推理会为流程引入概率。
传统自动化是确定性的。每一个步骤都可预测、可测试，并且每次都会产生相同的结果。
再回到我们的 DNS 示例：
Slack Form ──► Lambda ──► DynamoDB ──► Terraform ──► Cloudflare
这条流水线里没有任何环节需要解释或推断。
我们知道自己想要什么状态，代码已经存在，执行步骤也非常明确。那么，为什么要给一个“确定如此”的流程引入“也许如此”？
在边缘推理，在核心执行
LLM 在系统边界上可以发挥巨大的价值。想象一下，一名开发者在 Slack 中写道：“为 api.staging 创建一条 CNAME，指向我们的新负载均衡器。”
把这句自然语言转换为结构化 JSON payload，恰恰是 LLM 最擅长处理的模糊场景。自然语言本身就很混乱，人类经常省略上下文，而识别意图需要进行解释。这才是真正的推理问题。
Structured Outputs 解决的是格式问题，而不是决策问题。
真正的风险，是让概率模型来决定在生产环境中运行哪些工具。
一旦用户意图被转换为结构化数据——或者你一开始就通过结构化的 Slack 表单收集了这些数据——后续流水线就无法再从推理中获益。之后的每一步都应该像标准生产软件一样运行：可预测、可测试，而且具备确定性。
关键在于，LLM 生成的结构化数据必须在核心层经过严格的 schema 验证和确定性的授权策略（RBAC）。即使边缘层的 LLM 遭到操纵，它也只能请求执行操作——在任何执行接触基础设施之前，核心层都会独立验证该用户是否有权执行这些操作。
LLM 提议操作。
平台决定是否允许执行。
这个认识让我们得出了一条明确的架构原则：
在边缘推理，在核心进行确定性执行。
运行时推理的隐性成本
使用 AI Skill 代替 workflow，起初看起来速度很快，但它会给稳定性和安全性带来隐性成本。
当你把运行时推理引入执行路径时，就意味着接受了一系列根本性的取舍，而这些取舍会直接影响生产环境的稳定性、安全性和成本。
下面是这些取舍在生产环境中的具体表现：
Human in the Loop 带来的瓶颈
如果不能信任 LLM 在无人值守的情况下执行生产变更，那么就必须有人手动审核每一次运行结果，例如检查它创建的 PR。
这会重新引入你原本试图解决的瓶颈。
概率化的基础设施
脚本遵循指令；LLM 做出选择。
生产环境不是用来发现 AI 犯错的地方。
为用不上的智能付费
脚本的运行成本几乎可以忽略不计，而 LLM 会消耗 token。
如果 workflow 本来就完全可预测，那么你是在为自己根本不需要的“智能”付费。
扩大攻击面
确定性的 workflow 只会执行你明确编写的代码。
LLM 则会根据自己对 prompt 的理解来执行操作。
一旦 LLM 直接进入执行路径，prompt injection、context poisoning 和意外的工具调用就都会成为威胁模型的一部分。
对于基础设施，我们需要的是可预测性，而不是临场发挥。
一个可以用相同方式运行一百万次的脚本，胜过一个大多数时候都能“猜对”的系统。
在 AI 真正能够创造价值的地方使用它
我们使用 AI 的频率比以往任何时候都高——只是不让它运行我们的生产系统。
我们使用 AI 设计 Terraform 模块、生成 Lambda 函数、构建 CI/CD pipeline、评审 Infrastructure as Code、编写测试，以及理解不熟悉的系统。
让 AI 构建自动化，但不要让 AI 本身成为自动化。
一旦我们审核完生成的代码，推理阶段就结束了。
从那一刻开始，生产环境执行的是确定性软件，而不是 prompt。模型参与的是开发过程，而不是生产控制平面。
AI 只推理一次，软件可以永远运行。
30 秒架构审查
在下一个系统中引入 AI Agent、Skill 或运行时 LLM 之前，先问问自己：
- [ ] 这个问题真的需要运行时推理吗？
- [ ] 能否预先描述每一个执行步骤？
- [ ] 相同的输入是否始终应该产生相同的期望输出？
- [ ] AI 能否生成 workflow 代码，而不是亲自执行 workflow？
如果这些步骤是可预测的，你需要的就不是 LLM，而是可靠的软件。
LLM 非常擅长推理，但并非每个问题都需要推理。
使用 AI 理解用户的需求，并帮助你编写代码。但计划一旦确定，就应该让软件接手。
当你的生产系统已经确切知道接下来需要做什么时，就不要再推理，而应该开始执行。
User
│
▼
Natural Language
│
▼
LLM (Intent Extraction)
│
▼
Validated JSON
│
▼
Authorization (RBAC / Policies)
│
▼
Deterministic Execution
Lambda ──► DynamoDB ──► Terraform ──► Cloudflare
在不确定的地方推理，在明确的地方执行。
因为优秀的架构并不意味着消除 AI。
它真正要做的，是把不确定性限制在系统中确实能从中获益的部分。
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。