为什么你无法“管理”不懂的代码

Source: Dev.to

背景

在 AI 时代，一个常见的问题是：“如果 AI 编写代码，开发者就只会变成产品经理了吗？”

答案是 不，原因在于上下文权威原则。

• 产品经理 主要负责 问题空间（用户需求、市场匹配、价值）。
• 工程师 主要负责 解决方案空间（架构、可靠性、可维护性）。

如果 PM 不了解市场，他们会打造错误的产品。如果工程师不理解系统，他们会构建脆弱的产品。

“如何”蕴含风险

当开发者在没有保持所有权的情况下把任务委托给 AI 时，他们实际上在外包解决方案空间。故事变成：“AI 负责‘怎么做’，我只负责‘做什么’”。但怎么做包含了你无法外包的技术风险。

• 怎么做决定数据库在高负载下是否会锁死。
• 怎么做决定安全模型是否有效。
• 怎么做决定系统能否在下个月进行扩展。

如果工程团队把怎么做委托给 AI 而不保持深刻理解，代码库就会成为负债。团队不会变成 PM；他们会成为无法推理的技术债务的看护人。

承包商陷阱

当你因为不理解代码（或不想处理其复杂性）而把任务交给 AI 时，你实际上在充当承包商。你把 AI 当作抵御复杂性的盾牌。AI 产生一个“黑盒”补丁，解决眼前的工单，但你无法预测它对系统其余部分的影响。

一次又一次地这样做会侵蚀你对软件的心理模型。你会变成“代码的产品经理”——能够描述想要什么，却无法可靠地解释为什么有效或何时会失效。

与真正的产品经理依赖工程团队确保结构完整性不同，你依赖的是一个（没有强反馈回路的）模型，它的优化目标是产生看似合理的输出，而非系统保证。

代理的架构师

规模化的最佳策略不是成为黑盒的管理者，而是成为代理的架构师。使用 AI 执行任务，但要严格审计输出是否符合你的心理模型。把低杠杆的语法生成工作，换成高杠杆的系统验证工作。

这需要保持所有权的委托。不要要求“相信我”的输出。要求审计轨迹：固定行为的测试、明确的不变式、权衡说明，以及在接受更改前你能够推理的叙事性差异。

你不是通过委托失去所有权，而是因为停止审视而失去所有权。