40
0原文播客：Soft Skills Engineering 第 503 期
节目信息
软技能工程 | 整理时间：2026年03月11日
节目简介
本期节目回答了两个职场难题：一是软件背景的 CTO 如何领导自己不擅长的硬件团队；二是当产品经理开始用 AI 生成代码并提交时，工程师该如何应对无休止的审查和修复循环。
核心话题讨论
话题 1：软件人如何领导硬件团队
一位拥有 15 年软件经验的开发者即将成为机器人公司的 CTO，虽然他有机器人领域的学术背景，但一直专注软件方向。现在他需要同时负责硬件团队。
关键建议：
- 保持谦逊：承认自己在该领域不是专家，这反而会让团队感到兴奋——”我们有一个知道自己不知道什么的领导，愿意听取我们的反馈”
- 不要假装专家：你无法在该领域指导他们，无法提前识别技术问题或架构风险
- 善用团队智慧：把决策权交给真正懂行的人，你的价值在于管理和协调，而非技术指导
💡 金句：”你不需要成为专家才能成为好的领导，但你需要承认自己的局限”
话题 2：产品经理的 AI 代码洪流
一位工程师发现，公司 CEO（产品背景出身）认为产品经理应该自己写代码并部署。结果产品经理们开始”氛围编程”（vibe coding），用 AI 生成代码。
问题现状：
- 代码质量低，工程师花大量时间审查和修复
- 原本就忙的工程团队雪上加霜
- 工程领导层似乎无法有效推动改变
解决方案：
- 建立自动化反馈机制：AI 生成的代码需要更强的约束条件，比如自动化的代码检查规则
- 用 CEO 听得懂的语言沟通：不要说”代码质量”，要说”AI 生成更好代码”、”更快完成审查”、”代码库保持 AI 友好性”
- 设置防护栏：AI 就像会反复撞上护栏再弹开，需要足够强、足够多的约束机制
💡 金句：”AI 就像会反复撞上护栏再弹开，需要足够强的约束机制”
🤔 思考与启发
本期节目揭示了 AI 时代的新挑战：
- 门槛降低带来的新瓶颈：代码生成变容易了，但审查、集成、测试成为新瓶颈
- 约束的重要性：过去看似”偏执”的代码规范，在 AI 时代会显得更加正确
- 跨领域领导力：承认不足比假装专家更能赢得团队尊重
延伸思考：在你的团队中，如何平衡 AI 辅助开发的效率与代码质量控制？
