用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_running=2): 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重新审自己的代码才定位到根因。

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试一把。体验过那种不用读几十页文档就能跑通的感觉，你会回来感谢我的。