Terraform PR自动评审：AI跑plan/安全/成本检查

原文要点

该n8n模板由GitHub PR事件触发，提取仓库、分支、作者、标题、PR号等元数据后，由带会话记忆的OpenAI代理评审Terraform变更，可按需调用HTTP工具执行terraform plan、安全扫描、成本估算，并通过RAG检索内部IaC规范向量库。代理输出结构化JSON（findings、overall_risk、verdict、blocking_issues、cost_impact_summary），结果写入Postgres的terraform_pr_reviews表并回贴PR评论；verdict为pass时自动approve，否则发Slack等待人工用securityApproved回调Wait节点webhook后再批准或要求修改。模板免费，但OpenAI等模型服务可能另收费，HTTP检查端点需自行搭建。

这次做成什么

在自己的n8n实例搭一条Terraform PR自动评审流水线：PR打开即触发AI评审，干净变更自动approve，有风险时转Slack人工审批。因原模板未提供可导入文件，以下是本站设计的等价搭建方案，界面名称和参数需以你n8n版本的实际节点为准核对。

准备什么

• 一个可访问的n8n实例（自托管或云），版本支持AI Agent与Wait节点
• GitHub账号凭据，权限需覆盖读取PR、创建评论与review
• OpenAI API密钥，模型可按模板示例选gpt-4.1或你可用的等效模型
• Postgres数据库及可建表权限
• Slack工作区与可发消息的机器人凭据
• 三个HTTP检查端点（plan/安全/成本），本指南用自建的占位API代替真实CI

具体怎么做

1. 创建触发与元数据提取

   新建工作流，添加GitHub Trigger节点，事件选Pull Request，填入owner与repository。后接一个Code或Set节点，把webhook负载里的repository.full_name、pull_request.head.ref、pull_request.user.login、pull_request.title、pull_request.number提取为repo、branch、author、title、prNumber五个字段，供后续所有节点引用。

2. 配置AI代理与四个工具

   添加AI Agent节点，挂OpenAI Chat Model子节点（填API密钥，模型如gpt-4.1）和Window Buffer Memory子节点，session key用prNumber保证同一PR多轮上下文连续。给Agent挂四个工具：三个HTTP Request Tool分别指向你的plan端点、安全扫描端点、成本估算端点（POST JSON含repo、branch、prNumber），一个Vector Store Tool连接你预先导入内部IaC规范文档的向量库，让代理检索规范条款作评审依据。

3. 写系统提示词并解析结构化输出

   把下方artifact中的评审系统提示词粘贴进Agent的System Message，要求只输出规定JSON。Agent后接Code节点，用JSON.parse解析其输出，校验必须含findings数组、overall_risk、verdict（pass/review/fail）、blocking_issues、cost_impact_summary五个字段；缺字段时给默认值并打标记，避免下游报错。

4. 落库与回贴PR评论

   添加Postgres节点执行INSERT，字段映射：pr_number=$json.prNumber、repo、author、findings（JSON字符串）、overall_risk、verdict、blocking_issues、cost_impact_summary、created_at用$now。再添加GitHub节点在PR下创建评论，评论体用模板拼接风险等级、各条findings与成本摘要。建表SQL见artifact。

5. 分支：自动通过或Slack人工审批

   添加IF节点判断verdict是否等于pass。是：GitHub节点提交PR review，事件选APPROVE。否：Slack节点向#terraform-security-review发送findings摘要和审批说明，后接Wait节点（模式选On Webhook Call）；审批人向该webhook POST {"securityApproved": true}或false，Wait后用第二个IF分流：true则APPROVE，false则GitHub提交REQUEST_CHANGES并附blocking_issues。

6. 端到端测试

   先在测试仓库发一个含明显问题（如公开S3桶）的Terraform PR，确认触发器收到事件、Agent调用了plan与安全工具、Postgres写入一行、PR出现评论且verdict不为pass、Slack收到消息；再向Wait webhook POST securityApproved=true确认最终approve。再发一个无问题PR确认自动approve路径。

可直接复制的材料

你是基础设施变更评审员。用户会给你一条GitHub PR的元数据（仓库、分支、作者、标题、PR号）和变更描述。你可以调用以下工具：terraform_plan（获取计划变更摘要）、terraform_security_scan（获取安全扫描结果）、cost_estimate（获取月度成本变化估算）、iac_standards_search（检索内部IaC规范条款）。
评审规则：
1. 必须调用terraform_plan和terraform_security_scan；变更涉及新增计费资源时调用cost_estimate；不确定是否合规时调用iac_standards_search核对。
2. 发现的问题逐条记录，每条包含rule（违反的规范或最佳实践）、severity（critical/high/medium/low）、detail（具体资源与原因）。
3. 判定：存在critical或high问题，或违反强制规范时verdict为fail；仅有medium/low提示时verdict为review；无问题时verdict为pass。
4. 只输出一个JSON对象，不要输出任何其他文字，格式：{"findings":[{"rule":"...","severity":"...","detail":"..."}],"overall_risk":"critical|high|medium|low|none","verdict":"pass|review|fail","blocking_issues":["..."],"cost_impact_summary":"一句话说明月度成本变化，无变化写无明显变化"}

CREATE TABLE IF NOT EXISTS terraform_pr_reviews (
  id SERIAL PRIMARY KEY,
  pr_number INTEGER NOT NULL,
  repo TEXT NOT NULL,
  author TEXT,
  findings JSONB,
  overall_risk TEXT,
  verdict TEXT,
  blocking_issues JSONB,
  cost_impact_summary TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

请求（Agent的HTTP工具自动发出）：POST https://ci.internal.example/terraform/checks/plan
{"repo":"acme/infra","branch":"feat/add-s3-logs","prNumber":42}

plan端点示例响应：
{"to_add":2,"to_change":0,"to_destroy":0,"resources":["aws_s3_bucket.logs","aws_s3_bucket_public_access_block.logs"]}

安全扫描端点示例响应：
{"issues":[{"rule":"S3_BUCKET_PUBLIC","severity":"critical","detail":"aws_s3_bucket.logs 未启用公共访问阻断"}]}

成本估算端点示例响应：
{"monthly_delta_usd":12.4,"detail":"新增S3存储与请求费用约12.4美元/月"}

输入与输出示例

本站虚构演示，非原作者运行结果，未在任何真实仓库执行。

输入

测试PR #42：作者dev-li，标题“Add S3 logs bucket”，分支feat/add-s3-logs，变更新增aws_s3_bucket.logs但未配置公共访问阻断，预计月增成本12.4美元。

对应输出

Agent输出：{"findings":[{"rule":"S3_BUCKET_PUBLIC","severity":"critical","detail":"aws_s3_bucket.logs 未启用公共访问阻断，违反内部规范SEC-03"}],"overall_risk":"critical","verdict":"fail","blocking_issues":["为aws_s3_bucket.logs启用公共访问阻断"],"cost_impact_summary":"新增S3存储与请求费用约12.4美元/月"}。随后Postgres插入一行verdict=fail的记录，PR下贴出含critical问题的评论，Slack收到待审批消息；审批人POST {"securityApproved":false}后，工作流在PR上REQUEST_CHANGES。

做完检查这些

• 测试仓库发PR后n8n执行记录中GitHub Trigger被触发，且提取出正确的prNumber与repo
• Postgres的terraform_pr_reviews表新增一行，findings为合法JSON且verdict非空
• 无问题PR走完verdict=pass路径后，GitHub上该PR出现一条APPROVE review
• 有问题PR触发Slack消息，且只有收到Wait webhook回调后才继续执行最终review动作
• PR评论内容包含overall_risk、至少一条finding描述和成本摘要

容易卡住的地方

• GitHub凭据若无write权限，评论和review提交会静默失败，需在凭据上勾选repo全部读写范围
• Wait节点webhook URL在测试模式与激活模式下不同，审批脚本里写死测试URL会导致激活后回调404
• Agent会话记忆按prNumber分key，同一PR反复push会累积上下文，token消耗随之上升
• 三个HTTP检查端点需自行实现，模板不含真实terraform执行环境；端点超时会让Agent拿到空结果并误判
• verdict字段解析失败时若无默认值兜底，下游IF节点会走入错误分支，务必在Code节点校验
• 原模板未提供可下载的工作流文件，本指南为等价搭建方案，节点名称以你n8n版本实际界面为准