1. 大模型写Helm Chart，为什么我一开始就持怀疑态度
去年年中，我们平台团队接了一个需求：把"服务上线要写一堆Chart"这件事自动化。调研了一圈，最自然的想法当然是用大模型直接生成。当时群里有人发了个Demo，输入"给我生成一个nginx应用的Helm Chart"，几秒钟后Chart.yaml、values.yaml、deployment.yaml整整齐齐吐出来，大家都很兴奋。我跑到真实集群上测了几轮之后就冷静了——大模型确实能"写"Helm Chart，但它写出来的东西绝大多数时候不是"能用"的Helm Chart。
Helm Chart这个格式很特殊，它至少叠加了三层约束：第一层是Go template语法，{{ .Values.xxx }}、{{- if -}}、管道函数这些，稍有嵌套错误，渲染直接中断；第二层是YAML的结构约束，一个缩进错位、一个引号类型不对，解析阶段就完了；第三层是Kubernetes资源本身的Schema，Deployment的spec.selector必须匹配template.metadata.labels，Service的port是整数不是字符串，securityContext.runAsNonRoot是布尔值不是字符串"true"。更麻烦的是，很多约束是跨文件、运行时才暴露的——values里的一个类型错误，要等helm template渲染之后才爆炸。
大模型在这类任务上的表现，用我后来跟同事开的玩笑说：让一个文学系高材生去填报关单，文笔没问题，格式全错。模型擅长的是模式匹配和语义理解，而不是精确约束和跨文件一致性。这篇文章就是记录我把一个"生成Helm Chart的Agent"从第一代做到第三代的完整过程——三次架构迭代，四个关键技巧，里面踩过的坑比我预期的多得多。
1.1 先还原我最初的需求场景
先说清楚我们要解决什么问题。团队里几十个微服务，每个服务上线都要维护一套Chart，大部分Chart长得差不多：一个Deployment、一个Service、偶尔加个Ingress或者ConfigMap。区别只在于镜像地址、端口、副本数、资源配额、环境变量这些字段。纯粹手工写的话，复制粘贴一份再改字段，十分钟能搞定，但问题是每个人改出来的风格不一样——有的加了securityContext，有的忘了livenessProbe，有的把resources写成了字符串。于是我们想做一个内部工具：开发同学用自然语言描述需求（比如"给订单服务生成一个Chart，2个副本，CPU limit 500m，暴露8080端口"），Agent自动产出可用的Chart。
这个场景看起来很适合大模型，但真正做起来才发现，"适合"和"能直接干"之间隔着巨大的架构鸿沟。
1.2 Helm Chart到底约束在哪三层
这里花点篇幅把这层窗户纸捅破，因为后面三次架构迭代的问题，根子都在这三层上。
第一层是模板层。Chart里大量用到Go template，{{ .Values.image.repository }}这类表达式看起来简单，但一旦涉及{{- define "xxx" -}}、{{ include "xxx" . | nindent 4 }}、条件判断和循环，模型生成时经常搞错缩进和管道用法。典型错误是nindent 4后面少了一个换行，渲染出来的YAML直接错位。第二层是YAML语法层。YAML本身对缩进、引号、多行字符串非常敏感，模型生成的YAML经常出现"看起来正常、helm lint一跑就死"的情况，最常见的就是端口号被加上了引号变成字符串，或者resources.limits.cpu写成"500m"这种带引号的值。第三层是K8s Schema层。这是最隐蔽的，因为很多字段的合法性只能在渲染之后，拿渲染好的manifest去对比Kubernetes的OpenAPI Schema才能发现。selector.matchLabels和template.metadata.labels不一致、Service的targetPort引用了容器里不存在的端口、replicas写成浮点数，这类错误靠肉眼根本看不出来。
这三层叠加在一起，意味着"生成一个Chart"这个目标，本质上不是一次文本生成任务，而是一次多重约束满足任务。大模型天然不擅长这类任务，因为它没有一个"校验器"在生成过程中实时纠错。
2. 第一代架构：Prompt直出Chart，跑通Demo是最大的错觉
2.1 当时的实现长什么样
第一代架构简单粗暴：一个System Prompt，里面写上"你是资深的Kubernetes平台工程师，请根据用户需求生成标准Helm Chart，包含Chart.yaml、values.yaml、templates/deployment.yaml、templates/service.yaml，遵循最佳实践"。用户输入"应用名+镜像+端口+副本数"之后，模型一次性把四个文件全部吐出来，我们直接落盘到目录里。
当时选这个方案的理由也很直白：快。不用写任何模板代码，不用维护schema，把所有复杂度丢给模型。Demo跑起来确实快，输入一句话，几秒钟文件全出来了，tree一看结构还挺像那么回事。但现在回头看，第一代架构的成功率完全取决于模型训练数据里有没有恰好和你需求相似的Chart，本质是在赌概率，不是在做工程。
2.2 最典型的翻车现场
我拿真实测试里一个典型的输出来举例。让模型生成一个名叫order-service的Deployment，它给出这样的内容：
apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Values.orderService.name }} spec: replicas: {{ .Values.replicas }} selector: matchLabels: app: {{ .Values.orderService.name }} template: metadata: labels: app: {{ .Values.orderService.name }} spec: containers: - name: {{ .Values.orderService.name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" ports: - containerPort: 8080 name: http乍一看是不是没啥问题？但配套的Service文件里，它写的是：
spec: ports: - port: "80" targetPort: http问题一：port被写成了"80"带引号，K8s Schema要求port是整数，helm template渲染后直接被kubeconform拦下来。问题二：targetPort引用了容器端口名http，这个没问题，但同一个文件里如果容器端口名写的是http而Service里引用的是http-web，就彻底对不上了。问题三：replicas如果用户在需求里说"副本数为二"，模型可能生成replicas: 二这种中文值，或者生成2.0浮点数，K8s的int32字段直接报错。
这只是Deployment和Service两个文件之间的耦合。如果加上Ingress、ConfigMap、HPA，跨文件一致性要求呈指数上升，模型出错率也呈指数上升。
2.3 管中窥豹：模型为什么会犯这种错
要理解这些错误，得先理解大模型的生成机制。模型每一步在做的是"在概率分布里采样下一个token"，它生成的不是"通过校验的YAML"，而是"像YAML的文本"。它看到海量Chart训练样本之后，总结出了形态上的统计规律——知道Deployment大概长什么样、字段大概有哪些——但它没有能力在生成过程中"心算"一遍这个YAML渲染后的输出能否通过K8s Schema校验。
更关键的是，模型在生成两个文件时，对字段一致性的"记忆"会衰减。生成templates/deployment.yaml里的标签app: order-service时，它并没有在脑子里建立一个"待办清单"说待会Service的selector必须用同一个值。跨文件的约束依赖，对它来说是隐式的、概率性的，不是确定性的。所以你能看到它前半段写得好好的，后半段突然把selector写成了app: order-app，因为训练数据里另一个Chart长这样。
2.4 第一代架构的核心问题
把这次迭代的所有问题归纳起来就一句话：完全没有反馈回路。模型输出之后，不管对错，文件直接落盘，没有任何校验环节，也没有任何机制告诉模型"你错了、错在哪、怎么改"。这导致两个后果：一是错误率极高，在我们内部30个样例的小数据集上，helm lint+kubeconform全部通过的只有4个，通过率13%；二是一旦出错，排查成本比手写还高——你得人肉去看模型生成的四五个文件，逐个比对字段，还不如自己在模板上改十分钟。
这轮迭代给我的教训是：不要指望大模型"一次性生成正确"，要设计一个让它"逐步逼近正确"的机制。于是第二代架构来了。
3. 第二代架构：用校验反馈逼模型自我修正，效率变成最大拦路虎
3.1 校验流水线怎么搭
第二代架构的核心思路：在模型输出之后接一条校验流水线，校验失败就把错误信息回传给模型，让它修改，形成"生成-校验-修正-再校验"的循环。校验流水线我按成本从低到高依次做了四层：
# 第1层：Chart结构和YAML语法检查 helm lint ./chart # 第2层：模板渲染，暴露Go template错误和values缺失 helm template test ./chart --values ./chart/values.yaml # 第3层：渲染结果对K8s OpenAPI Schema做严格校验 kubectl create --dry-run=client \ -f <(helm template test ./chart) \ -o yaml > /dev/null # 第4层（可选）：有测试集群时，做真正的服务端校验 helm install test ./chart --dry-run=server --namespace=test层与层之间是递进关系，helm lint过了不等于模板能渲染，模板渲染过了不等于Schema校验能过。我在循环里设置最多重试5次，超过就放弃并把问题抛给人工。
3.2 错误信息回传：四个字段比一段日志好用
这里有个关键细节：校验错误信息不能原样丢给模型。helm lint加helm template出错时，输出可能几十行，里面夹杂着一堆warning堆栈和无关日志，模型根本分不清哪个是致命错误。试了几轮之后，我总结出了一个"四段式"反馈格式，效果好了很多：
| 反馈字段 | 内容示例 |
|---|---|
| 文件路径 | templates/service.yaml |
| 错误级别 | 致命 / 警告 |
| 错误信息 | port字段类型错误：期望integer，当前是string"80" |
| 上下文片段 | 出错行及其前后各两行YAML |
回传给模型时，用固定的模板拼装：
校验失败。请只修改下面列出的问题，保持其他部分不变。 文件: templates/service.yaml 级别: 致命 错误: ValidationError(Service.spec.ports[0].port): invalid type, expected integer, got string 上下文: ... - port: "80" targetPort: http ...这个设计是有讲究的。把"文件路径"和"级别"单列出来，是为了降低模型的注意力负担——它不需要在几十行日志里自己找重点。加上"上下文片段"，是为了让模型知道这一处在文件里的确切位置，避免改错地方。
3.3 打地鼠问题和成本失控
第二代架构跑起来之后，成功率确实上去了，但随之而来的是一堆新问题。最头疼的是"打地鼠效应"：模型修完一个错误，又引入另一个错误，而且往往是在无关字段上。我见过一个真实案例：模型第一轮把imagePullPolicy从IfNotPresent改成了ifnotpresent（全小写），第二轮改回来了，但同时把securityContext.runAsNonRoot从布尔值true改成了字符串"true"——它显然没有理解"修A的时候不要去动B"这个指令背后的意图。
打地鼠效应的根源在于：模型做局部修正时，并没有一个全局的"字段依赖图"。它不知道selector.matchLabels和template.metadata.labels是绑定的，不知道port和targetPort的关联，所以它的每次修改都像在盲人摸象——摸到哪算哪。
另一个问题是成本。每次重试都要把整个Chart重新生成一遍，加上历史错误信息全部堆在上下文里，token消耗越来越大。我们测过，一个Chart平均要2.6轮重试才能通过，最差的一个Chart花了6轮，单次生成消耗的token是手写模板的上百倍。算一笔账：如果一天要生成50个Chart，纯token成本就已经不划算了，更别提那38%重试超过5次仍然失败的case。
3.4 第二代架构的真实数据
在同样的30个样例上，第二代的表现是：第一轮直接通过43%，经过最多5轮重试通过率提升到62%，剩余38%要么重试超限，要么修来修去最后还是错的。看着还行？但注意一个细节——通过的62%里，有接近一半是5轮重试才通过的，整个流程跑下来平均耗时好几分钟，用户体验很糟糕。
这轮迭代让我想明白一个道理：校验循环再强，也只是"守门员"，不是"教练"。它能在球进门之前拦下来，但不能教球员怎么踢出好球。真正的出路，不是让模型在错误的道路上多试几次，而是从一开始就别让模型走那条路。
4. 第三代架构：把Chart拆成"确定性骨架+模型填空"，Agent终于收敛了
4.1 转折点：模型在这个任务里的不可替代价值是什么
第三代架构的起点，是我和团队复盘时问的一个问题：如果这个任务只能让大模型负责其中一小部分，那一小部分应该是什么？
答案是：理解自然语言需求，并把它转成结构化、业务相关的字段值。比如"给订单服务生成一个Chart，2个副本，CPU limit 500m，暴露8080端口"，模型真正不可替代的能力是把这个口语化需求映射成replicas: 2、resources.limits.cpu: 500m、containerPort: 8080这些字段。至于Chart本身的模板结构、K8s资源规范、命名规则、最佳实践——这些都是确定性知识，根本不需要模型来"创作"。我们平时手写Chart，也从来不重新发明模板，都是从现成骨架复制改字段。
那为什么第一代第二代要让模型直接生成整个Chart？因为偷懒。想用一个通用模型解决所有问题，结果模型在它不该参与的地方疯狂犯错。
4.2 三段式流水线：意图解析、字段映射、确定性渲染
第三代架构把整个流程拆成了三段，每一段都有明确的职责边界。
第一段是意图解析。用户输入经过大模型，但模型不是直接输出Chart文件，而是通过function calling + 结构化输出，生成一个中间层的"意图Schema"：
{ "appName": "order-service", "namespace": "default", "image": { "repository": "registry.internal/order-service", "tag": "v1.2.3" }, "replicas": 2, "containerPort": 8080, "service": { "type": "ClusterIP", "port": 80 }, "resources": { "limits": {"cpu": "500m", "memory": "1Gi"}, "requests": {"cpu": "250m", "memory": "512Mi"} } }这一步允许模型有一定"发散空间"，因为它要做语义理解和意图补全，比如用户说"开个4核跑一下"，模型要能把它转成cpu: "4"，这是模型擅长的。
第二段是字段映射与校验。这一步完全用确定性代码实现：把意图Schema映射到values.yaml的最终值，同时做硬校验——枚举检查（service.type只能是ClusterIP/NodePort/LoadBalancer）、端口范围检查、命名规范检查（用正则校验appName不能有中文和非法字符）。所有业务规则都写在这段代码里，不经过模型。
第三段是确定性渲染。使用一个团队评审过的Chart骨架，骨架里是写死的_helpers.tpl、deployment.yaml、service.yaml、hpa.yaml等模板文件，这些都是经过生产环境验证的。用第二段生成的values渲染骨架，得到最终Chart。
helm template order-service ./chart-skeleton \ --values ./generated/values.yaml \ --output-dir ./generated/chart模型不再直接写模板文件，它只负责两件事：理解用户意图、填充结构化字段。
4.3 给CRD留一个受控出口
有人会问：那遇到公司内部Operator的CRD怎么办？内置骨架里没有对应模板，难道又要让模型自由发挥？这就需要第三个架构里一个很重要的设计——保留一个受控的"模型补全"出口。
对于无法预置的CRD资源，我们允许模型只生成CR的spec部分，但必须满足两个条件：一是生成前必须先加载该CRD的OpenAPI Schema，二是生成结果必须过一遍kubeconform校验或者JSON Schema校验，不通过就不予落盘。这个口子的本质是：承认模型有它的用途，但给它的自由划一个边界。它只能在"结构已知、字段可校验"的范围内发挥，而不是替我们发明一个资源和字段。
4.4 三个版本的真实数据对比
在同样的30个样例上跑了一遍，结果对比非常直观：
| 维度 | v1 纯Prompt | v2 校验纠错 | v3 骨架+填空 |
|---|---|---|---|
| 模型负责范围 | 整个Chart所有文件 | 整个Chart所有文件 | 意图字段 + 少量CR spec |
| 反馈机制 | 无 | helm lint + kubeconform循环 | 静态校验 + 确定性映射 |
| 首轮通过率 | 13% | 43% | 86% |
| 最终通过率 | 13% | 62%（5轮重试后） | 93% |
| 平均耗时 | 约10秒 | 3~8分钟 | 约20秒 |
| 单Chart token成本 | 低但基本无效 | 非常高 | 约为v2的1/4 |
| 人工介入 | 大量排查 | 中等 | 少量diff评审 |
第三代最终通过率93%，剩下的7%基本都是用户需求本身模糊——比如没说清要不要Ingress、没给镜像地址、没说跑在哪个namespace。这类问题不是模型能靠猜测解决的，正确做法是让Agent反问用户，而不是瞎填。我后面也加了"信息缺失反问"的逻辑，效果很好。
这轮迭代给团队最大的感受是：Agent变"聪明"了，不是因为我们换了个更强的模型，而是因为我们让模型只做那20%它真正擅长的事。
5. 沉淀下来的4个关键技巧
三次迭代之后，我把踩坑经验总结成四个技巧，基本每个都是拿真实失败case换来的。
5.1 技巧一：给字段级few-shot，不给整份Chart
第一代失败后我一开始的改进想法是给模型更多示例Chart，结果发现效果很差——给一份完整Chart，模型会把它当模板逐字拷贝，包括里面不该拷的注释、没用的空字段、甚至示例里的镜像地址。后来改成给字段级映射示例，效果立竿见影。比如在System Prompt里放三组"用户表达 -> 意图Schema字段"的映射：
示例1: 用户表达: "给支付服务生成Chart，单副本，CPU限制1核" 意图字段: {"appName": "payment-service", "replicas": 1, "resources": {"limits": {"cpu": "1"}}} 示例2: 用户表达: "网关要暴露443，开3个pod" 意图字段: {"appName": "gateway", "replicas": 3, "containerPort": 443}这样模型学的是"表达怎么转字段"的映射规则，而不是去背一篇范文。范围小、意图明确，模型的表现稳定得多。
5.2 技巧二：反馈给模型的错误必须"去噪分级"
第二代架构里，我一开始把helm lint的完整输出直接回传给模型，效果非常差，因为模型会在无关的warning上反复纠结。后来做了两层处理：第一层按"致命/警告"过滤，第二层只回传与当前修改点相关的上下文，并附上"建议修复方向"。
我举个例子，这是处理前后的对比：
| 处理前（截断） | 处理后 |
|---|---|
[ERROR] templates/deployment.yaml: parse error...[WARNING] values.yaml: ...[WARNING] Chart.yaml: apiVersion is deprecated...（总共40+行，其中还有一堆stack trace） | 文件：templates/deployment.yaml 级别：致命 错误： resources.limits.cpu应为字符串，当前为数字500建议：改成 "500m" |
模型的注意力窗口是有限的，噪音越多，它越容易把"改这个文件"变成"全局返工"。把错误信息裁剪到"刚好能定位问题"的程度，是重试类Agent的重中之重。
5.3 技巧三：把约束写进JSON Schema，而不是写进System Prompt
这个技巧最容易被忽视。很多人习惯在Prompt里写"serviceType只能取ClusterIP、NodePort、LoadBalancer""imagePullPolicy只能取IfNotPresent、Always、Never"，但Prompt里的要求是软约束，模型看一遍之后转头就忘。真正可靠的做法是把它变成硬约束——在function calling的参数定义里，用JSON Schema把这些字段限定为enum：
{ "type": "object", "properties": { "serviceType": {"type": "string", "enum": ["ClusterIP", "NodePort", "LoadBalancer"]}, "imagePullPolicy": {"type": "string", "enum": ["IfNotPresent", "Always", "Never"]}, "replicas": {"type": "integer", "minimum": 1, "maximum": 100}, "containerPort": {"type": "integer", "minimum": 1, "maximum": 65535} }, "required": ["appName", "image", "containerPort"] }框架层直接校验，模型输出不合规就拒绝，从源头杜绝枚举字段的自由发挥。我在这个项目里学到的教训是：Prompt用来表达意图，Schema用来表达约束，两者不可混为一谈。
5.4 技巧四：强制diff评审，把人工修改变成下一轮的训练资产
第三代架构虽然通过率高了，但我仍然坚持在落盘前加一道"diff评审"环节。做法是生成Chart之后，和团队维护的基线Chart骨架做一次diff：
helm diff upgrade order-service ./generated/chart \ --namespace default \ --detailed-format或者用yq把values差异导出来，按"新增/修改/删除"分组展示给用户。这一步有两个目的：第一是给用户一个可审查的界面——Agent的生成结果不能直接进CI，必须有人类的最终确认；第二更有价值——每次人工在diff上做的修改，我们都记录下来，沉淀成下一轮Prompt优化、few-shot样例甚至模型微调的数据。这也是Agent系统迭代最重要的数据资产。
经验总结："生成 + 校验 + 人工兜底"三者缺一不可。不要让Agent的自我评估成为最终裁决，真实集群和人工review才是。
6. 三轮迭代之后，我对"用大模型生成基础设施配置"的理解
回过头看这三次架构迭代，最核心的变化其实只有一句话：我一直在收窄模型发挥的空间。从第一代让模型写整个Chart，到第二代让模型基于错误反馈修Chart，再到第三代只让模型填意图字段，模型的自由度越来越小，系统成功率却越来越高。这个反直觉的现象，本质上揭示了大模型在工程场景下真正合适的定位——它不是"万能钥匙"，而是一个"翻译器"，负责把人类的口语意图翻译成结构化的中间表达，剩下的事交给确定性代码和校验闭环。
我在实际操作中还有两个很深的体会。一是别把失败归咎于"模型不够聪明"。我们一开始也怀疑是不是应该换个更强的模型，但换完发现除了成本变高，该错的还是错。真正的问题在于我们把太多本不该由模型承担的责任塞给了它。二是每次架构迭代都要保留失败样本做分类统计。成功率数字会骗人，但一个具体的失败案例——比如"用户在需求里没说镜像地址，模型硬编了一个假地址进去"——会直接告诉你下一步该改哪里。我们最后能形成这套"确定性骨架+模型填空+diff评审"的方案，靠的就是这类样本的积累，而不是拍脑袋。
最后再分享一个可以立刻用起来的小技巧：如果你也在做类似的Agent，可以在生成流程的最后一步，把模型生成的字段值打印出来对照用户原话过一遍眼。很多诡异的错误，人一眼就能看出来，但模型就是反复改不对。这个习惯帮我拦下了不少"模型自认为正确但实际上荒谬"的输出。
