开发过程中 AI 编程工具使用方法（AI 万能视频下载总结器实战）

内容团队每天从各平台扒几十条视频、人工看字幕写摘要，一个礼拜光转录就耗掉两三个人力。我算了笔账，与其每次写临时脚本东拼西凑，不如用 AI 编程工具直接搭一个”粘贴链接、自动下载、一键出总结”的应用。从需求拆解到上线，我用 Cursor 和 Claude Code 这类 AI 编程工具跑了 4 周，中间踩了不少坑，也趟出了一套”边聊边写”的干活节奏。下面把整条工作流摊开讲：哪些环节 AI 真能提速，哪些地方它只会帮倒忙，碰到问题该怎么跟它沟通，都会交代清楚。

一、整体工作流

先把流程图画出来，后面每一周的工作基本都沿着这个闭环推进。

需求 → AI 拆解 → 生成代码 → 我 review → 调整 → 集成 → 测试
   ↑                                                  ↓
   └──────────────── 反馈迭代 ←─────────────────────────┘

这张图看着简单，其实是我改了四版才定下来的。最开始我犯过一个典型错误：把整个需求直接丢给 Claude Code，让它”全权负责”，结果两天后它交回来一坨跑不起来的代码，模块之间怎么串的我完全看不懂。后来才收敛成现在的闭环——AI 只负责单点产出，拆解、把关、串联都留给我自己。

每篇功能开发都是”AI 写、我审、问问题、改”的循环。回头复盘，这个循环里最值钱的是”我审”那一步。AI 生成的代码不经 review 就上线，后面修 bug 的时间足够把省下来的时间全部吐回去，这一点在后面”踩坑”一节还会反复提到。

二、开发环境

先把工具摊开看，我实际用下来是这样分工的：

平台主要用 Cursor（VSCode 改造的 AI IDE），Alt+Tab 切到 Claude Code 做大型任务。

这套组合不是一开始就配齐的。最早我只装了 GitHub Copilot，写样板代码很顺，但碰到”重写整个模块”这种任务就使不上劲；后来试过把需求丢给 ChatGPT 网页版，来回复制粘贴代码效率太低。真正定下来”Cursor 主写、Claude Code 攻坚”，是在一次重构里同时开了俩窗口，发现分工干活明显顺手，之后就固定下来了。Copilot 现在只当补全助手，写重复性代码时手不离键盘。

三、第一周：架构设计

1. 需求拆解

“做一个能下视频 + AI 总结的 Web 应用”这个需求太模糊。我让 AI 帮我拆：

请帮我把"AI 视频下载总结器"的需求拆成具体功能模块。
目标用户：内容创作者、研究人员
核心功能：多平台下载、AI 总结、思维导图、付费订阅

拆之前我自己先列了一版清单，拿 AI 的结果一比，发现它补了两个我漏掉的点：字幕提取和思维导图。没有字幕，AI 总结就是空转；没有思维导图，用户看完总结还得自己理结构。这两个模块后来恰好是产品差异化的关键。

AI 给我拆成：

1. 用户系统（注册/登录/订阅）
2. 视频提交（链接解析）
3. 下载器（yt-dlp 封装）
4. 字幕提取
5. AI 总结（DeepSeek）
6. 思维导图（markmap）
7. 支付系统（Stripe）

这份列表后来成了整个项目的任务树，我照着它排每周的优先级，一周盯一两个模块，不至于做完下载器才发现支付还没动。

2. 技术选型

需求拆完就该选型了。我的原则是用自己熟的东西，但也不想闭门造车，于是把约束条件丢给 AI，让它给一套参考方案：

我需要后端框架选型建议：
- 用户量预期 1000/天
- 视频处理是 IO 密集
- AI 调用延迟高
- 团队熟悉 Python

AI 推荐：

• FastAPI：异步原生、SSE 友好、自动 OpenAPI
• SQLite：单机足够、零运维
• yt-dlp：开源下载器
• DeepSeek：中文 AI + 价格低

这轮选型我只做了两处改动。一是把 AI 首选的 PostgreSQL 换成了 SQLite，初期每天 1000 次请求量级，单机足够，少一个数据库就少一块运维；二是让 AI 复核了 yt-dlp 对抖音、小红书的解析支持程度，避免选完才发现关键平台跑不通。其余框架层面的选择基本照单全收。

四、第二周：核心功能开发

1. yt-dlp 封装

第二周先啃最硬的骨头——下载器。我让 AI 写：

请写一个 yt-dlp 的封装：
- 异步获取视频元信息
- 支持 YouTube/B站/抖音/小红书
- 处理各平台反爬（不同 UA 和 Referer）
- 返回统一格式

AI 给出完整代码，我审后发现：

• 抖音反爬没考虑全，提示要加 app_name 参数；
• 缩略图代理没考虑防盗链；
• 异常分类不细。

这三次修改全是典型的”AI 不知道平台反爬细节”。yt-dlp 本身支持大量平台，但抖音这类站点的请求头、签名参数经常变，AI 训练数据里的版本可能已经失效。我让 AI 修改：

抖音反爬请加上：
- 移动端 UA
- app_name=douyin_web
- aid=6383
如果失败有 fallback 到 PC UA

AI 改完。再测试。

这轮来回花了大半天。测试时又发现小红书部分视频要带 Cookie 才能解析，我又让 AI 加了一层”首次失败自动重试并附上平台通用 Header”的兜底逻辑，跑通 20 个样本链接之后，下载器才算稳定下来。后来线上跑了一个月，各平台解析失败率一直压在 5% 以内。

2. AI 总结服务

下载器稳定之后接 AI 总结。我让 AI 写：

请写一个 DeepSeek 总结服务：
- 系统 prompt：总结视频字幕
- 流式返回（SSE）
- 包含 4 部分：一句话总结、核心要点、关键时间点、思维导图
- 中文输出

AI 给出基本代码。我追问：

总结 prompt 怎么设计更稳定？多评委交叉验证怎么做？

AI 给出：

• 温度 0.3；
• JSON 格式输出；
• 多评委取中位数。

这三个参数看着小，实际是稳定性的分水岭。温度调到 0.3 之后，同一段字幕反复总结，关键信息基本稳定；强制 JSON 输出让我不用再去解析大段 Markdown；多评委交叉验证则是跑 3 次结果取中位数，偶发的离谱输出会被自动过滤掉。上线一个月，这条总结链路的失败率一直控制在 2% 以内。

3. SSE 流式响应

总结服务写完了，但要是等它全部跑完再一次性返回，用户体验会很糟——DeepSeek 生成几千字总结要几十秒，用户盯着空白页面干等，多半直接关掉。我让 AI 写 SSE 流式：

请写 FastAPI SSE 流式响应：
- 阶段进度推送（下载中/转录中/总结中）
- AI token 流式
- 错误处理
- Nginx 配置建议

AI 给出 EventSourceResponse 代码 + Nginx 配置。

这里埋了个雷：SSE 在本地一切正常，部署到 Nginx 后面就卡在 30 秒超时，这个问题到第四周调试时才真正解决，详见后文”AI 辅助调试”一节。

五、第三周：UI 和集成

1. 前端页面

后端核心通了，第三周做前端。我让 AI 写：

请写视频详情页 HTML/CSS：
- 左栏视频信息（Sticky）
- 右栏内容 Tab（总结/思维导图/字幕/问答）
- 流式总结渲染
- 移动端响应式
- 不要用 Vue/React，原生 JS

AI 给出 200 行 HTML + 300 行 CSS。我调整：

• 配色改为更商务的灰蓝；
• 字体大小适配移动端；
• 进度条样式调整。

前端这块我坚持不用 Vue/React，一是页面不多，二是不想为了三个页面引入一整套构建链。原生 JS 配手写 CSS，加载快、部署简单。配色我让 AI 出了三版，最后选了灰蓝主色，后来用户反馈说看着像工具类产品，不算惊艳，但专业感是够的。

2. 支付集成

功能做完了，收钱这块不能拖。我让 AI 写：

请写 Stripe Checkout 集成：
- 月度/年度订阅
- 单次购买（积分）
- Webhook 验签
- 退款处理

AI 给出 FastAPI 代码。我加上：

• 幂等表（防 Webhook 重放）；
• 每日对账脚本；
• 邮件通知。

幂等表和每日对账脚本是我坚持加的。Stripe 的 Webhook 可能重试投递同一事件，不加幂等表，用户重复扣款的事故迟早要发生；对账脚本是兜底，万一某天 Webhook 丢了事件，第二天对账也能发现补上。

六、第四周：测试与上线

1. AI 辅助测试

上线前不能裸奔。我让 AI 写 pytest 测试：

请为以下功能写单元测试：
- 视频元信息解析
- AI 总结服务（mock DeepSeek）
- 配额检查
- Stripe Webhook 验签

AI 给出 100+ 测试用例。

这个数量看着唬人，质量其实参差。我重点补了边界用例：空字幕、超长视频、重复链接、并发配额竞争，这些 AI 生成时最容易漏。补完之后测试套件才算真的能当”安全网”用。

2. AI 辅助调试

部署后发现一个 bug：

我们发现 SSE 流在 Nginx 后 30 秒延迟，但本地 0.5 秒。AI 帮我排查：
- 检查 Nginx 配置
- 试过 proxy_buffering off 但没解决
- 看 upstream keepalive 配置

AI 排查出 proxy_buffering off + proxy_cache off + gzip off 三个都要开才解决。

这个 bug 我印象很深，因为三个开关单看任何一个都解释不了现象，只有组合在一起才会把 SSE 的增量数据压进缓冲。AI 能一步步把变量列全，但”同时关掉三处”这个结论，还是我在它列出的排查清单基础上试出来的。人机配合到这里才是舒服的状态。

七、效率提升

整个项目做完，我粗略记了一下各环节耗时，对比起来比较直观：

要说明的是，这些数字是我单人小项目里的体感数据，不代表所有场景都这样。真正明显的是”从想法到能跑的版本”这段路被大幅压缩了，4 周里大概有一半时间花在踩坑和返工上，另一半才是净收益。

八、AI 不擅长的部分

1. 业务决策

AI 建议用 OAuth 登录，但中国大陆用户习惯手机号登录，AI 不知道这个。改成手机号 + 验证码。

这类决策 AI 给不出答案，因为它没有我手里那些关于目标用户的信息——用户在哪、用什么注册习惯、付费意愿什么样，这些只能靠产品判断。

2. UI 细节

AI 生成的 UI 偏工程师审美，实际产品要兼顾”用户友好”。我让设计师朋友看了改了几版。

后来我总结出一条经验：让 AI 出三版风格，再人工选一版细调，比一开始就要求”好看”高效得多。

3. 性能调优

AI 给的代码能跑，但生产级优化（Redis 缓存、数据库索引、CDN）AI 不知道真实访问模式，要我根据压测结果调整。

比如缓存哪些接口、索引建在哪个字段上，取决于用户的真实行为分布。我压测出热点接口后，再带着具体数据去问 AI”这个接口怎么缓存”，它才能给出能落地的方案。

4. 商业模式

AI 不能帮你决定”免费 3 次/天还是 5 次/天”。业务决策是人的事。

这个最终定价我是盯着第一周的用户数据改的：免费额度太低用户不注册，太高没人买会员，后来按激活率调到”每天 5 次免费 + 会员无限”，转化率才稳下来。

九、踩坑

1. AI 给的代码不一定能跑

AI 引用了不存在的库或过时的 API，必须 review。

# AI 给的（有 bug）
from some_ai_hallucinated_lib import awesome_function

# 我改成
from pydantic import BaseModel

这个例子是我真实遇到的。AI 自信满满地导入了一个它自己编的库，我第一次跑就报 ModuleNotFoundError。从那以后我养成了习惯：AI 给出的新依赖先查一下有没有，再决定要不要装。

2. AI 容易”过度工程”

让 AI 写”用户登录”，它可能引入 OAuth + JWT + Refresh + CSRF 全套。要明确”最小实现”：

请写最简单的用户登录：邮箱密码 + JWT，不要加其他功能

我的经验是，prompt 里明确”最小实现””只做 X”这类约束，能省掉大量删代码的时间。AI 默认喜欢把方案做全，因为它认为这样更”正确”。

3. AI 不知道项目上下文

每个对话 AI 不知道前面聊过什么。要么：

• 把项目 README 喂给它；
• 用 Claude Code 这种长上下文工具；
• 在 Cursor 里 @ 相关文件。

这一点我吃过亏：同一个问题上午刚在 A 对话里解决，下午换到 B 对话又问了一遍，AI 给了一模一样的错误答案。后来我把项目 README 和模块说明整理成一个文件，每次开新对话先喂进去，准确率明显提高。

4. AI 重复提问

写完代码 AI 又问”要不要加单元测试？”——明确告知一次即可。

AI 没有记忆，也没有”上次已经确认过”的概念。我的做法是在项目规则里写死”所有新功能必须带测试，不要每次都问”，之后它就闭嘴干活了。

十、与 AI 协作的最佳实践

1. 给 AI 充分上下文

不要问：怎么写下载视频功能？
要问：项目用 FastAPI + yt-dlp，需要支持 YouTube/B站/抖音，
     每平台反爬不一样，请写下载器代码，含异常处理

带上下文和不带上下文，产出质量差别非常大。同样的任务，把技术栈和平台约束写清楚，AI 给出的代码基本能直接用；只丢一句需求，它只能给你一份通用答案，还得二次返工。

2. 让 AI 出方案，再写代码

不要：直接让 AI 写代码
要：先问 AI 几种方案对比，再选一种写

尤其对不熟的技术栈，这一步能帮你避开明显的坑。选型那轮我就是靠这个流程，避免了在数据库选型上走弯路。

3. 小步迭代

不要：一个 prompt 让 AI 写 1000 行
要：每个小功能单独 prompt，写完 review 再合并

我最初试过让 AI 一次生成整个模块，代码量大到根本 review 不过来，出错也不好定位。拆成小功能逐个推进之后，每个步骤都能验证，出问题也能迅速锁定是哪一步引入的。

4. Review 是必要的

AI 写的代码 100% 要人工 review。常见问题：

• 类型错误；
• 边界条件；
• 异常路径；
• 性能问题。

十一、推荐的 AI 工具

用过的工具里，按使用场景我最后留下了这些：

工具之间其实是互补关系，不是谁取代谁。一个项目里混用两三种 AI 工具，比死磕单一工具更容易顺。选型标准就一条：它能不能覆盖你当前任务的短板，而不是看宣传。

十二、未来展望

1. 多 Agent 协作：一个 Agent 写代码，一个 Review，一个测试；
2. AI 监控：AI 监控生产日志，自动发现异常；
3. 自然语言编程：用 LLM 解释业务逻辑生成代码。

前两条我已经在小范围试用：代码审查交给第二个 Agent 把关，生产日志异常用 AI 盯夜间告警，人工只处理真正要紧的事件。这个方向我会继续往下走。

常见问题（FAQ）

Q1：AI 写的代码能直接用吗？

不能直接上生产，必须人工 review。

Q2：AI 会不会让程序员失业？

不会。AI 替代”写代码”这部分，但”想清楚做什么”AI 替代不了。

Q3：AI 写代码有版权问题吗？

当前法律框架下，AI 生成代码的版权归使用者，但要遵守模型 ToS。