用Vibe Coding搞定AI Infra：从资源调度到故障恢复的实践

说实话大模型项目做得越多越发现最让人失眠的往往不是模型指标差一截而是AI Infra那堆“听起来不难、跑起来要命”的破事。最近我换了一种玩法把最头疼的训练任务管理整体重写了一遍全程几乎都是用Vibe Coding完成的。所谓Vibe Coding就是不再逐行手写逻辑而是用自然语言描述行为目标让AI去生成代码你负责理解、审查和调整方向。很多人觉得它只适合写点小游戏或者前端demo但我亲测下来的结论是它用在AI Infra上反而特别顺手。原因很简单AI Infra最缺的不是复杂算法而是把一团模糊需求翻译成有边界实现的能力而这恰恰是AI的强项。这篇文章不会讲怎么调模型而是分享我怎么用Vibe Coding把最折磨人的AI Infra项目从一个念头聊成一套能用的系统。1. 大模型Infra的痛点为什么模型好写、环境难搭1.1 模型是直线思维Infra是网状协作跑过大模型实验的人应该都有这种体验写模型代码的时候脑子里跟着数据流走一遍就行——输入进了网络经过卷积或者注意力层算出loss反向传播更新参数。这是一个相对线性的过程每一步都有明确的输入输出调试起来也能靠直觉判断哪里出了问题。但AI Infra完全不是这个调性。数据管道、资源池、任务队列、调度器、重试器、监控日志它们彼此纠缠在一起。多个训练任务同时排队、显存碎片化、某个节点被占着不释放、一个进程崩了等待自动重启这些状态是并发的任何一个环节出错都可能让后面的任务跟着遭殃。就好比做菜只需要照着菜谱一步步来但经营一个后厨却要同时处理采购、切配、烹饪、出菜和应急任何一个环节堵住整条线就瘫痪了。这种网状协作特质让很多人面对Infra时产生一种说不清的焦虑它不是靠多写几个if就能解决的而是要同时考虑时序、并发、失败恢复和资源竞争。1.2 旧方法人手维护脚本风暴改一行都哆嗦以前我做Infra用的也是最常见的方式一堆Python脚本、配置文件再加上一堆手工敲的服务器命令。听起来灵活实际上特别脆。配置文件里多个空格可能让整个服务起不来某次升级之后依赖冲突一调就是半天为了处理偶发的崩溃要写一大段重试逻辑而这些逻辑又会变成新的维护负担。更难受的是这类基础设施代码不像模型代码那样有丰富的经验直觉可以依赖。你不能靠“多跑几次看看”来赌它没问题因为问题往往出现在并发第三十七次才触发。所以在很长一段时间里我对Infra的态度是“不想碰但绕不开”。Vibe Coding在这时候的作用很有意思。它不能直接替你消除复杂性但能把“从想法到代码”的摩擦降到最低。我不用再一个字一个字抠语法而是把精力省下来去思考真正要命的拓扑、状态和边界条件。1.3 明确边界Vibe Coding是铺路不是造桥有一点必须说清楚我用Vibe Coding不是让AI替我做架构决策而是让它把我已经想清楚的结构填补成代码。比如“我要一个优先队列”但队列里任务的优先级怎么动态调整、任务状态怎么回写、重试失败以后怎么告警这些最终还是要我来定。如果一开始就把架构决策整个交给AI你得到的会是一个看起来完整、但经不起真实调用推敲的系统。AI生成的代码再流畅也只是一个执行者不是规划者。把这条边界立起来后面排查问题的时候才能少走弯路。2. 实操第一步把需求拆成AI能听懂的任务清单2.1 先写“一句话需求”而不是大喊“做个系统”很多人在Vibe Coding上翻车是因为给AI的指令太抽象。你如果直接甩一句“帮我做个AI Infra”它只会给你一个天马行空的大纲根本落不了地。我的做法是先写一句话把核心约束说清楚让AI基于这句话拆分任务清单。比如我最近做的训练任务管理模块当时给AI的输入是请帮我设计一个训练任务管理模块一个GPU资源池最多同时运行2个任务每个任务有优先级资源不够时新任务排队任务可能崩溃需要自动重试最多3次每次重试间隔递增任务状态需要写入日志存储。这个prompt不长但把几个关键约束都点到了并发上限、优先级、排队、重试次数、退避策略、状态记录。AI拿到之后立刻拆出了一长串模块清单任务队列、优先级排序、资源检查器、任务状态机、重试器、通知器。我不需要它马上写代码先让它把分工列出来。这一步的好处是你能低成本地看到整个系统长什么样然后及时调整方向。很多人都跳过了这个环节直接让AI写完整实现最后得到的代码往往结构混乱想要重构都不知道从哪里下手。2.2 分模块生成骨架每块都配一个“模拟入口”拿到模块清单以后我不会让AI一次性生成所有代码而是一个模块一个模块地来。比如先做队列模块同时要求它提供一个dry-run入口。这个dry-run用假的训练任务模拟排队逻辑让我在没有GPU的笔记本上也能验证调度顺序是否正确。AI很擅长写这种“假数据加真逻辑”的测试入口因为它不需要理解大模型本身只需要理解你声明的行为。当时我给它的要求是“所有外部依赖都要能在没有真实集群时被mock掉提供一个模拟命令让我能看到两个任务提交以后谁先运行、谁在等待。”这个约束特别重要。如果不在开头说明AI生成的代码里可能满是真实环境调用本地根本跑不起来。一旦加了依赖注入的约束AI就会自然生成便于替换实现的代码后面接真实集群的时候只需要改一小块适配层。2.3 用例驱动给AI“小剧本”来验证行为还有一个我屡试不爽的方式不写传统的单元测试用例而是用自然语言描述一个“小剧本”让AI把测试代码写出来。比如场景队列里有任务A优先级为3任务B优先级为1资源池还能运行1个任务。请写一个函数验证下一个被调度的是B等A成功运行后B才开始运行。当AI面对这种具体场景时它生成的测试代码往往比直接写业务代码更准确。因为场景描述已经给出了明确的输入输出模型只需要做模式匹配不需要自己做判断。等测试代码通过以后再用同样描述去驱动业务实现你会发现AI在“自证”的过程中会修正很多理解偏差。这种自然语言驱动的测试开发是我在Vibe Coding里最推荐的方法之一。它让人始终掌握验收标准又让AI承担了写测试的重复劳动。3. 核心模块实战资源调度与容错我这样一步步聊出来3.1 资源调度让AI先生成“不够好但能跑”的调度器资源调度是AI Infra里最容易出乱子的部分。多个训练脚本抢GPU、排队顺序不合理、任务等待超时没人管都会导致资源利用率直线下降。我先跟AI描述了一个简化版本资源有限任务按优先级排序运行中的任务如果超过最大时长会自动释放。AI生成的简化代码大概长这样from collections import deque class TaskQueue: def __init__(self, max_running2): self.max_running max_running self.running [] self.waiting deque() def submit(self, task): if len(self.running) self.max_running: self.running.append(task) task.start() else: self.waiting.append(task) def tick(self): finished [t for t in self.running if t.is_done()] for t in finished: self.running.remove(t) self._start_one_waiting()这段代码的优点是清晰缺点也明显队列没有按优先级排序也没有考虑同一个任务重复提交。我需要继续追问AI“如果任务有优先级怎么调整”“正在运行的任务超时了怎么处理”然后它会逐步补齐排序和超时逻辑。关键心得是AI给的初版通常是一个“玩具级”版本但这不重要。重要的是它帮我把主干搭好了我只需要在这些主干上补充约束。后来我给队列加上了最大等待时间超过时间就把任务标记为超时并重新排队避免某个低优先级任务永远被饿死。这就是Vibe Coding该有的用法——你出边界AI出骨架。3.2 故障恢复让AI把“挂了怎么办”变成重试和检查点训练进程故障是AI Infra里最常见的事故显存不够、数据读取超时、驱动异常随便一个都能让任务突然退出。Vibe Coding在这里最好用的地方是生成一个可配置的重试器因为它只需要定义规则。我当时给AI的输入是如果一个训练任务异常退出自动重启它。重启最多3次等待时间分别是30秒、2分钟、5分钟每次重启前都要记录原来进程的退出日志如果3次都失败把任务标记为“失败”。AI很快生成了一套带状态机的重试逻辑。但我还会额外要求它考虑“检查点恢复”如果训练进程支持断点续训重启时要用最新检查点继续跑而不是从头开始。这个信息AI没办法凭空知道它只能生成一个插件接口检查点路径怎么读、如何校验是否最新仍然要由我提供给它。这里有一个必须强调的避坑点不要让AI设置无限重试。大模型训练里的一次失败往往说明环境已经不对劲无限重试只会让两个坏任务反复互相卡死。限制重试次数并且在重试前先做一次环境健康检查这些策略都应该显式写进prompt里而不是指望AI自己理解。3.3 环境复现从手工登服务器到一条命令启动另一个让我非常受益的应用是环境初始化。以前每上新机器我都要照着文档手动敲几十条命令建目录、装依赖、配环境变量、同步数据。只要漏掉一步后面训练跑起来就要排查半天。现在我会把wiki内容复制给AI让它生成一个幂等初始化脚本并明确要求“任何一步重复执行都不应该报错”。AI生成出来的脚本通常已经能处理大多数判断逻辑比如目录是否存在、某个工具是否已经安装。它还会顺带生成一个参数化入口支持传入不同环境名来加载不同配置。#!/bin/bash set -e ENV_NAME${1:-dev} DATA_DIR${DATA_DIR:-/data/samples} mkdir -p $DATA_DIR if [ ! -d $ENV_NAME ]; then python -m venv $ENV_NAME fi source $ENV_NAME/bin/activate pip install -r requirements.txt echo init done这类脚本的价值是把散落在文档里的知识变成了可执行代码。但依然要人工检查set -e在部分场景下会因为你不想中断的命令而中断幂等的要求也要靠逻辑判断来保证。AI不会自动知道你的私有依赖仓库地址这些必须显式告诉它。环境初始化是AI Infra里最安全、最适合Vibe Coding练手的场景我强烈建议第一次尝试从这里开始。4. 哪些Infra工作适合交给Vibe Coding哪些千万别碰4.1 适合胶水代码、配置生成、模拟器和文档用了一段时间Vibe Coding以后我慢慢总结出适合它的Infra工作类型。第一类是胶水代码把两个服务串起来、写数据转换、写简单的运维脚本。这类代码规则明确AI生成质量很高基本不需要大改就能用。第二类是配置和初始化逻辑。只要把变量、路径、环境名列清楚AI就能生成像模像样的配置文件和初始化脚本。第三类是模拟器和测试脚手架。给AI一个具体场景让它输出可运行的验证逻辑这是它的强项比让手写快得多。这些任务的共同点是“如果……那么……”的结构非常清晰。AI不需要做复杂权衡只需要按规则翻译成代码。你给它越清晰的约束它产出的东西就越接近你想要的成品。4.2 不适合架构权衡、安全策略和性能优化反过来有几类Infra工作我建议不要依赖Vibe Coding。一是架构决策比如任务队列用单点还是分布式、状态存储到底选哪种、跨机房的网络拓扑怎么设计。这类决策依赖你对整个系统的理解和全局资源评估AI看不到现场给不了靠谱结论。二是安全策略。密钥管理、网络隔离、权限模型这些真的不要交给AI。我见过AI生成代码时直接把密钥硬编码进去看起来能用实际是埋雷。这类风险只能由人来做最终兜底。三是性能优化。AI生成的代码经常是“正确但不高效”遇到大量并发时锁粒度过大、没考虑批量写入等都是常见问题。它擅长把逻辑做对但不擅长把性能压榨到极致。所以用Vibe Coding的时候我心里始终有一条线AI负责把想法翻译成代码但这个想法值不值得实现、安全边界在哪里、性能会不会爆炸必须由我自己判断。4.3 一套可以复制的Vibe Coding工作流最后说下我常用的提示词模板。每次和AI协作之前我会粘贴一段固定背景描述内容包括项目代称比如“某训练管理系统”、技术栈约束、通用约定必须幂等、禁止硬编码敏感信息、必须提供dry-run入口、输出格式要模块清单、代码、测试还是文档。这段背景描述放在版本库里每次根据任务稍作修改就行不用反复从零开始写。这算是DRY原则在prompt上的应用。因为它能避免每次对话让AI重新猜你的环境和标准减少大量无效沟通。配合的工作流节奏是写一句话需求让AI拆模块选一个模块生成骨架跑dry-run验证补齐边界条件提交到版本库。完成一个模块再做下一个不要一口气让AI写500行代码。这个节奏看着慢实际是最快的因为每个模块都能独立验证问题不会堆积到最后一次性爆发。5. 踩坑实录Vibe Coding搞Infra最怕遇到的5个问题5.1 问题速查表真实项目里我踩过不少坑有些靠经验能马上定位有些要折腾半天。我整理了一个速查表按症状、可能原因和排查方向来对号入座症状可能原因排查方向脚本本机正常换台机器就挂环境变量、库版本、路径硬编码不一致让AI生成环境对比脚本锁定依赖版本两个任务同时跑导致排队卡死队列缺少并发控制或超时释放打印任务状态时间线确认谁持有锁AI生成的配置里有明文密钥prompt缺少禁止硬编码的约束全局搜索敏感信息把密钥改走配置中心重试把任务打得更乱重试次数无限等待时间太短限制重试次数加入指数退避和健康检查日志只有最后一行错误没法定位AI只打印了最终错误没打中间态要求AI在关键节点打印当前状态、参数、步骤这个表格是我在实际排查时经常对照的。其中至少三种情况我都是靠让AI重新审自己的代码才定位到根因。5.2 三个真实踩过的坑第一个坑是让AI生成训练任务启动器时它把路径写死在某个临时目录里。我以为脚本在本地没问题换到另一台机器直接全部崩掉。后来我要求AI所有路径都通过环境变量注入并且脚本开头自动检查必需环境变量是否设置。这个改动彻底根除了路径类问题。第二个坑是AI生成的调度逻辑在mock测试里完全正常但一到真实集群就出现“排队后状态不同步”。原因是AI默认任务状态由自己更新而实际环境里状态是外部监控系统写回的。解决方法是让AI把状态更新抽象成事件回调并且在prompt里明确指出“状态必须由外部事件触发禁止内部轮询”。这两个条件补齐后调度才真正跑通。第三个坑是数据清洗模块遇到损坏样本后直接抛异常导致整个数据管道中断。AI默认所有文件都是好的这显然不符合真实世界。我让AI加了一个“损坏样本跳过并单独记日志”的逻辑同时确保重试时不会卡在同一条坏数据上。类似这样的真实世界细节如果不体现在prompt里AI永远不会主动替你想。5.3 怎样让AI越来越懂你的Infra与其每次重新介绍背景不如把背景沉淀成一个文件。我会维护一个“项目上下文”文档里面写清楚目录结构、技术栈、常用命令、环境变量约定以及我认为什么样的代码才算合格。每次对话开始前粘贴这个文档AI给出的输出会明显更贴切。另外一个技巧是让AI先读一段你现有的代码然后说“请保持接口不变重构这段逻辑”。它会从上下文里学习你的编程习惯之后生成的代码风格会更统一。我在一个重构任务里试过AI生成的代码几乎没有风格差异只补了几个边界条件就能合并。最后一定要给AI设定“完成定义”。我在prompt里固定要求代码必须幂等、必须包含日志、必须检查退出码、禁止硬编码凭据。有了这些默认约束即使AI不了解每个具体场景它也会输出符合预期的代码。Vibe Coding并不是无条件的玄学它更像一套方法论前提是你把规则定清楚AI才能把活干明白。最后说一点自己的体会。用Vibe Coding搞定AI Infra我最深的感受是它并没有让我少思考而是让我把思考的时间花在了真正重要的地方。以前我花大量时间敲配置、调脚本、试命令经常一天下来人很累但复盘时发现根本没动过脑子。现在我会先在纸上走一遍流程想清楚谁先谁后、谁失败了该怎么办、谁可以重试然后把这张纸翻译成自然语言去喂给AI。AI给我的不是一根银弹更像一个手脚很快但偶尔自作聪明的实习生。你得不断补充边界、审查产出、擦掉它多出来的想象。如果你正在被AI Infra折磨不妨挑一个最小的模块比如环境初始化脚本先让AI试一把。体验过那种不用读几十页文档就能跑通的感觉你会回来感谢我的。