ARTICLE · 1016486

AI 给了我一个方案,我把它一步步改成了自己想要的样子

发布时间：2026-09-16 04:03:34 最近访问：2026-09-16 04:03:33

最近计划做一个音视频处理服务，团队中一直有这样的需求，现在 AI 强大，所以重新思考这个事情，原始的需求是这样：

视频压缩、统一转 MP4；
音频转 MP3；
视频截图；
支持 720P、1080P。

底层用 FFmpeg，Go 做服务层。

其实我感觉有意思的不是让 AI 写代码，而是怎么和 AI 沟通，让 AI 给的方案是我想要的。

第一次问 AI 就把事情搞复杂

我说：要异步处理视频。

AI 很快给出经典方案：

API → Queue → Worker → FFmpeg → Redis / Database

但我感觉有些重，我马上加了一个条件：

把任务队列和重试放在上层，这一层取消 Queue。于是 Queue、Redis 被删掉，Worker 只干一件事：有资源就执行任务，没资源就拒绝。

比如一个服务实例只允许 4 个任务：

maxConcurrency = 4

满了就返回：

503 BUSY

WORKER 不做任务排队。

接着我发现：WORKER 集群如何负载均衡

假设三个 Worker（当前任务/最大任务数）：

A：4/4B：1/4C：0/4

如果把请求发给 A，就失败了，A会返回 503 BUSY，但 B、C 明明还有资源。于是我给 AI 说要不增加一个很轻的 Master：

Caller -> Master   -> Worker A / B / C

Worker 通过 WebSocket 上报数据给 Master：

capacity = 4available = 3

Master 优先找空闲的 Worker，但我又想到一个问题：

Master 的 available 数据上报延迟怎么办？可能原因有很多。我把问题抛给 AI，继续聊下来，我发现根本不用解决。因为 Master 的状态只负责：

决定先问谁。

真正的并发锁永远在 Worker：

TryAcquire()

抢到 Slot 才接任务，抢不到就 BUSY，Master 再找下一个 Worker。

Slot 代表什么？

我又问了一个问题：

FFmpeg 已经结束，但视频还在上传 S3，要不要释放 Slot？

如果马上释放，就可能出现：

4 个新转码+4 个旧任务上传

配置明明是并发 4，实际上机器同时跑着 8 个任务。

当然也可以继续设计：

downloadSlotsffmpegSlotsuploadSlots

但我最后决定不做，一个 Slot 就代表一个完整任务：

下载↓ffprobe↓FFmpeg↓结果上传↓完成↓释放 Slot

这样设计吞吐可能不是很好，但资源特别好控制，简单直接。以后压测真的发现上传拖慢 CPU 利用率，再拆。

最后，留下了几个很普通的事情

聊下来，最终架构反而非常简单：

           Caller             ↓          Master             ↓   ┌─────────┼─────────┐   ↓         ↓         ↓Worker    Worker    Worker   ↓FFmpeg / ffprobe          ↓  Local / S3          ↓    Callback

技术栈也很普通：

GoFFmpegffprobeHTTPWebSocketSQLiteDocker

SQLite 只保存 Worker 本地的执行记录和 Callback 重试。没有 MQ，没有 Redis，没有分布式锁，也没有复杂任务平台。

这次真正让我有感触的，是怎么问 AI

如果一开始就问：

帮我设计一个高可用、高性能、可扩展的音视频处理平台。

AI 可能会给我一个标准答案，不断反问：

消息队列真的需要吗？任务重试和调度放在上层，会不会更简单？Worker 满了为什么不能直接拒绝？Master 的状态真的必须强一致吗？Callback 失败为什么要重新跑 FFmpeg？Master 性能如何？未来如何保证 Master 高可用？

每问一次，架构就少一点东西，就更加深入一层，思路也更加开阔和收敛，知道做什么？为什么这样选择。

所以我觉得，AI 很适合帮助开发人员发散和推演，但真正重要的能力还是收敛，以及人如何抉择。

AI 会告诉你：

这个可以加，那个也可以加。甚至给你多个“完美”的方案

而我们要不断问：

它真的有必要存在吗？这样有什么问题？会不会太复杂？

AI 编程时代，开发人员的价值可能不只是比以前更快地写代码，更重要的是哪些代码根本不该写，哪些复杂度根本没有必要引入。

AI 可以帮我们快速实现一个方案，但怎么拆系统、定边界、哪些应该简单、哪里必须可靠，最终还是需要人根据实际团队的情况来判断和决策。

代码越写越快以后，真正拉开差距的，反而是其他：对系统的理解、对架构的取舍，以及一次次具体的技术决策。

最后，我让 AI 给我把方案总结成 Markdown 文档，我准备直接作为 AI 编程项目的需求文档和规则，有需要的可以参考，通过下面方式获取：

向公众号发送消息：音视频处理

如果你关注我以后，也会收到这个markdown文档的推送。

个人观点，仅供参考，在 AI 时代共勉。

第一次问 AI 就把事情搞复杂

接着我发现：WORKER 集群如何负载均衡

Slot 代表什么？

最后，留下了几个很普通的事情

这次真正让我有感触的，是怎么问 AI

相关学习资料