从TL到EM：我不再盯着AI写代码，而是信任结果

今年以来，在使用编码智能体的工作流程中，我完成了从技术负责人（TL）到工程经理（EM）的角色转变，这一调整彻底重构了我和智能体的协作模式。

这两个角色的核心差异，在于技术参与的深度和广度：作为TL时，我会深度介入项目的技术细节，从系统设计到代码评审都需要亲自把关，本质上是因为当时对AI生成代码的质量不够放心。这种方式虽然能在一定程度上保障代码质量，但也让我自己成为了智能体发挥效能的瓶颈——大量的决策需要人工做出，细节也要由人工把控，极大限制了整体开发效率。

协作模式的转折点：从Fable 5开始信任结果

这一转变的关键节点出现在Fable 5版本上线前后。彼时我发现，AI生成的代码质量已经达到了相当可靠的水平，只需要经过简单的功能验证就能确保不会出现明显偏差。于是我逐渐减少了对代码编写过程的直接干预，转而站在项目全局的角度把控整体方向，我的核心工作也转变为：确定项目的执行路径，以及最终验收交付成果。

这套模式极大释放了智能体的生产力。大多数时候，我会先明确需要落地的功能需求，和智能体共同敲定技术方案，确认方案可行后，通过/goal指令提交完整的需求描述，让智能体自主完成代码编写和自动化测试工作。等到功能开发完成后，我只需要验收功能是否符合预期，不再逐行审查代码细节。如果遇到Bug，我只需要将问题描述清晰地反馈给智能体，让它自行复现并修复问题，同时补充对应的测试用例覆盖相关场景，修复完成后我再做最终的验证即可。

技术选型：不再被个人技能偏好束缚

这种角色转变还带来了另一个显著的优势：技术选型不再受限于个人的技能喜好和熟悉程度。

当我以TL的身份推进项目时，往往会不自觉地优先选择自己熟悉、擅长的技术栈，虽然能快速上手开发，但这种选择未必是最适配项目实际需求的方案。而切换到EM的视角后，我会完全以项目的最佳适配性为核心标准，不再纠结于自己是否掌握该技术。

比如最初开发字幕翻译应用时，因为我本身熟悉前端开发，优先选择了Electron技术栈，确实能快速完成初始版本的搭建，但后续使用中发现Electron的性能表现难以满足核心需求，于是果断切换到Swift + AppKit的原生技术栈。虽然我之前并不熟悉Swift，但在AI智能体的辅助下，整个技术迁移和重构过程没有遇到明显阻碍。

现在在规划BaoCut的下一个大版本时，跨平台方案的首选是Rust——哪怕我从未写过一行Rust代码，但我清楚这是当前最适配跨平台需求的技术选择。目前基于Rust的第一个版本已经完成开发，整个过程几乎没有遇到语言层面的障碍。

新的瓶颈：从代码编写到需求明确

通过这套协作模式，开发BaoCut的前期阶段基本实现了每日一个小版本的迭代效率。但最近开发进度有所放缓，原因在于需要构思全新的大版本功能规划，这时人的思考和需求梳理能力又成了新的瓶颈：如果没有明确的执行目标和落地路径，再强大的智能体也无法发挥应有的作用。