原文播客：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 时代的新挑战：

1. 门槛降低带来的新瓶颈：代码生成变容易了，但审查、集成、测试成为新瓶颈
2. 约束的重要性：过去看似”偏执”的代码规范，在 AI 时代会显得更加正确
3. 跨领域领导力：承认不足比假装专家更能赢得团队尊重

延伸思考：在你的团队中，如何平衡 AI 辅助开发的效率与代码质量控制？