核心问题

你不是要变成纯工程师，而是要学会用工程方式判断产品。

PM 懂软件工程，不是为了抢工程师饭碗，也不是为了在评审会上说几个技术名词。真正的价值在于：你能更准确地判断复杂度、风险、代价和迭代路径。

好 PM 不是只问：

这个需求能不能做？

好 PM 会继续问：

这个需求怎么做更值得？

课程定位

这门课训练的是一种双重视角：

  • 作为 PM，你要理解用户价值、商业目标和机会成本。
  • 作为工程合作者，你要理解技术约束、系统复杂度和长期维护成本。

当这两个视角能在同一个脑子里对话时，你就不再只是“需求输入方”，而是能参与系统构建的人。

课程地图

这套课程会围绕七个模块展开：

  1. 拥抱无聊的技术：技术选型首先是风险管理。
  2. 像侦探一样调试：Bug 排查是一种科学实验。
  3. 代码考古学：旧代码是过去约束条件的化石。
  4. 写给未来的自己：ADR 记录的是为什么，而不只是做了什么。
  5. AI 编程：AI 是副驾驶，不是船长。
  6. 技术共情：让价值和代价能被放在同一张桌子上讨论。
  7. 终身学习的策略：广度让你能对话，深度让你不可替代。

PM 的工程判断地图

需求出现
  ↓
它真的值得做吗？        -> Business / ROI
  ↓
它会引入什么复杂度？    -> Technical Empathy
  ↓
该用什么技术承载？      -> Boring Technology
  ↓
出问题如何定位？        -> Debugging
  ↓
旧系统为什么这样？      -> Code Archaeology
  ↓
决策如何留给未来？      -> ADR
  ↓
AI 能帮哪一段？         -> AI Co-pilot
  ↓
我长期该补什么能力？    -> T-shaped Learning

写作合同

后续每一节都会采用同一套结构：

核心问题
真实场景
常见误区
工程视角
PM 可以怎么做
Atlas Action
小结

这意味着课程不会停留在概念解释，而是不断回到一个实际问题：

明天在需求评审、技术方案会、Bug 复盘、项目排期里，PM 可以具体做什么？

小结

PM 学软件工程，不是为了多懂几个框架，而是为了提升判断质量。

你要能看懂工程师为什么犹豫，能理解一个需求为什么会拖慢系统，也能在技术方案里看见业务代价。

最终目标不是“PM 变成工程师”，而是：

PM 能和工程师一起判断：什么值得做，怎么做，代价是什么，未来的人能不能接得住。