heihei (@baoweiheihei)

用 AI 跑通了一整条教学动画的制作流程：Opus 5.5 写手绘动画、排时间轴，Gemini 3.8 Flash TTS 配音，从一份文字稿做成带配音、字幕、配乐的完整视频。效果好得超出我的预期。 （视频内容来自码农高天的《十分钟学会正确的 GitHub 工作流》，这次只是借来练手、跑通流程。原视频： 但整个过程中，我一直在提醒自己一件事： 这些都是 AI 的能力、模型的能力，不是我的能力。 所以我很清楚自己不想做什么： 不做搬运，也不批量制造 AI 视频。这些对我来说没有意义。 我想做的是： 把 AI 当作工具，用它为自己赋能。从我这里出去的作品，至少要有我的参与、我的思维和思考，要做有增量、有意义的事。 AI 越来越强，一次次刷新我的认知。每到这时，我都会再提醒自己一遍： 这不是我的能力。我该做的，是用好这些能力，做出更有意义的东西。

我感觉一切都归因于软件工程，也就是软件架构实现的好不好。我们有没有按照自己的业务需求，选择一个好的框架？这个框架能不能在整个编码的生命周期中，约束 Agent 按照规范去实现？ 举个很简单的例子： 我最近开发了一个比较复杂的客户端系统。我是使用 goal 模式，几乎完全分阶段使用goal模式去完整地实现了这个软件。codex用了两个礼拜，把软件做出来了，功能完全可用。 但在最近需要新增一个很典型的需求（增加夜间模式）。仅仅因为这一个新需求，整个系统就遇到了极大的问题。因为在 Agent 之前实现模块的时候，它不会主动去考虑我们没有给过它的约束。它没有使用设计系统（Design System）上面的规范，也没有对各个层级进行分层（比如设计令牌层、组件层等）。 结果就是，整个软件不同的页面和模块里，大量分散着各种没有语义、直接硬编码的颜色值（更离谱的是，不同的模块硬编码的字体颜色都有一些偏差，而不是固定的几种。因为在这个过程当中，我使用了大量的多个子 agent 的去实现不同的模块）。对于增加夜间模式这种需要全局调整（横切关注点）的功能来说，这简直是灾难。 如果之前在做这个项目时，有一个好的架构设计，哪怕选一个好一点的前端脚手架，那么现在加这个功能就会非常简单——那大部分代码就只需要形成一个有关夜间模式的设计令牌（Design tokens）文件就够了。这种有弹性的架构，在应对未来需求变化时会非常轻松。也许这个功能只需要 20 分钟就可以搞定。 而我这个完全用 Agent 实现、几乎没有架构约束的项目，现在要加这个功能就非常糟糕，我可能需要花上三到四天去重构才能完成。而且后续加的功能越多，Agent 去迭代，无论是Agent还是我自己的体验也会越来越糟糕。 用 Agent 做的软件越多，我就越能深刻地感受到软件工程的重要性。