他把写代码交给AI后，工程效率反而翻倍了

Ras Mic 在这支视频里做了一件反直觉的事：不再把 AI 当“写代码的助手”，而是当成真正的“工程代理”。结果不是失控，而是效率、产品判断力同时提升。这是一套正在被低估的 agentic engineering 工作流。

最反直觉的一点：工程师先停手，代码才跑得更快

视频一开始，Ras Mic 就抛出一个几乎所有资深工程师都会皱眉的做法：在真正动手写代码之前，他几乎不写代码。他把大量前期工作交给 AI——不是让它直接生成最终版本，而是让 AI 先“跑流程”。从高层设计、功能拆解、交互预期，到可能的实现路径，AI 先生成一个粗糙、甚至“很丑”的版本。Ras 反复强调：丑没关系，关键是快。这个阶段的目标只有一个：验证方向，而不是优雅实现。这和传统工程习惯完全相反——我们太习惯一上来就追求干净的架构和漂亮的代码。

Agentic workflow 的核心：不是写功能，而是“逼产品现形”

在 Pluto 这个项目里，他想做的是一个类似 COD 的 artifacts 功能。注意他的表述：“我知道我想要什么样的体验。”于是他并没有先画完美 PRD，而是用 agent 直接把功能跑出来。AI 一边生成代码，他一边观察：这个功能在真实产品里站不站得住？哪些地方从产品角度看就不合理？这里的 AI 更像一个高速原型机，而不是代码外包。Ras 明确提到：从产品视角看，有些问题只有在“功能真实存在”时才会暴露，而不是在文档里。Agentic engineering 的价值就在这里——它把产品判断提前了。

“它会卡住”不是问题，真正的问题是你怎么接手

Ras 并没有美化 AI 的能力。他非常坦率地说：它会卡住，会生成很烂的代码。尤其是在使用 GLM55 这类模型时，结果往往不优雅。但关键不在于模型完不完美，而在于工程师的角色变化——你不再是“从 0 到 1 的码农”，而是“从 0.7 到 1 的编辑者”。当 agent 卡住，你介入；当方向错了，你修正；当功能跑通了，你再清理。这也是为什么他在后期会说“现在我们只剩下测试了”——因为大部分认知成本，已经在前面被 AI 吃掉了。

真正的收益：不是更快写代码，而是更少走弯路

视频后半段最容易被忽略的一点是：Ras 多次从“产品视角”回看整个流程。这个 workflow 带来的最大变化，并不是代码量，而是决策质量。很多原本要在评审、重构、推翻中浪费的时间，被压缩到 AI 快速生成的原型阶段。最终功能合并到 staging 时，他已经非常确定：这个东西值不值得继续。这对个人开发者、创业团队尤其致命——因为时间和注意力才是最贵的资源。

总结

这套 agentic engineering 工作流 给 AI 从业者一个很现实的提醒：未来的竞争力，可能不在于你会不会写代码，而在于你如何驾驭生成过程。你可以从一个小功能开始尝试：先让 AI 跑完整流程，哪怕结果很丑，再由你来收尾。问自己一个问题：如果原型 30 分钟就能看到，我还需要花两天纠结设计吗？当你开始这样工作，你的工程角色已经悄悄升级了。

关键词： Agentic Engineering， 代码生成， AI工作流， 产品原型， 工程效率

事实核查备注： 需要核查：视频具体时长；GBD55、GLM55 的准确名称与定位；Pluto 是否为作者个人项目；artifacts 功能与 COD 的类比是否为原话或示意。