用 AI 编程助手管理构建流水线一个月：22 条"铁律"是怎么沉淀出来的

不是测评，不是软文，是一个真实项目的一个月构建排障复盘。核心心得一句话：AI 助手的价值不在于替你踩坑，而在于每个坑只踩一次。

背景

我在 Windows 上用 AI 编程助手（WorkBuddy）持续开发一个 Flutter Android 项目，前后经历了 30 轮左右的 APK 构建。前十几轮的状态是：每轮构建都像开盲盒——有时 15 分钟顺利出包，有时僵死一小时，有时倒在莫名其妙的"拒绝访问"上。

到后来，构建稳定在 15 分钟左右一次成功。中间发生了什么？

复盘：从"开盲盒"到"确定性"的四个阶段

阶段一：盲人摸象（第 1~10 轮）

每轮失败后都在猜：是网络？是版本？是内存？试过的错误方向包括——

• 重装 Flutter SDK（没用）
• 加 -Dorg.gradle.native=false（反而引发 daemon fork，更多问题）
• 设 JAVA_TOOL_OPTIONS（和 Gradle daemon JVM 参数打架）
• 疯狂 flutter clean（治标不治本）

教训：没有根因分析的 retry 纯属烧时间。

阶段二：根因定位（第 20 轮前后）

转折点是系统性地做了一次归因，把所有历史失败日志拉出来对齐分析，发现 90% 的失败集中在三类锁文件 + 一类缓存旧文件上（细节见我前两篇帖子）。从这以后排障才有了靶子。

教训：日志要留全。每次构建的完整日志落盘、按轮归档，是后续归因的唯一素材。 没有日志归档，排障就是抽风。

阶段三：知识固化（第 22~29 轮）

把解法写进构建脚本，但第一版脚本有个致命设计：删锁失败只警告不阻塞。结果就是"带病启动"——脚本报着 warning 冲出去，一小时后死在半路。

改法很朴素：任何关键前置步骤失败 = 立即 FATAL 退出 + 打印手动处理指引。宁可 10 秒失败，不要 1 小时白跑。

到这一步，脚本里积累了 22 条前置检查和自愈逻辑，我称之为"铁律"：锁文件泊车、缓存目录重建、孤儿进程清理、daemon 参数、OOM 防护、日志容错……每一条背后都是一次真实的失败。

阶段四：沉淀外移（第 30 轮之后）

最后把这一个月的排障经验整理成一份结构化的"排障手册"（触发条件 + 症状 + 解法 + 验证命令的速查表形式），交给 AI 助手作为技能使用。效果：新会话里一句"构建失败了"就能直接命中知识库里的解法，不用从头排查。

一个月下来最有价值的几条方法论

1. 警告不是免费的。 任何 (!!) 开头的警告行都要逐条处理，放行警告 = 预定一场一小时的失败。

2. 可靠指标优先于直觉。 "进程活着"≠"构建活着"，"日志在涨"≠"任务在推进"。用产物活动和进程链说话。

3. 删不掉就改名。 Windows 上文件删除会被安全机制拦截时，rename 是几乎 100% 成功的替代通道。

4. 坑只踩一次。 每次失败都问一句"下次怎么让它在 10 秒内自动暴露"，把答案写进脚本或手册，而不是写进自己的记忆。

5. 让 AI 干它擅长的。 构建排障这种"模式识别 + 大量日志阅读"的活，交给 AI 助手非常合适——前提是你把领域知识喂给它（见第 4 条），否则它也会像阶段一的我一样瞎猜。

给同样在折腾构建的朋友三个建议

1. 先修环境再修代码。 构建失败的锅 80% 在环境，代码 bug 会在环境修好之后自己显形（而且显形得飞快——9 分钟快速失败，比环境问题的一小时僵死友好得多）。
2. 构建脚本是第一等公民。 值得花一个下午认真写，比每轮手工救火便宜太多了。
3. 把你的踩坑史变成资产。 无论是 wiki、脚本注释还是 AI 技能，固化下来的坑才是阶梯，没固化的坑只是坑。

一个月，30 轮构建，从随机失败到确定性成功。构建这种事，从来没有玄学，只有还没找到的规律。