从纯写代码到变成 AI Prompt 审核员，程序员的护城河还剩什么

最近半年，我的工作状态发生了某种诡异的偏移。以前最让我有成就感的时刻，是死磕一个内存泄漏的 Bug 或是手写一套复杂的递归逻辑，那种掌控代码每一行流向的快感是无可替代的。但现在，我的日常操作变成了：在 Claude 3.5 Sonnet 中输入需求 → 复制生成的代码 → 快速扫一眼逻辑 → 提交 PR。

不可否认，生产力确实翻倍了，甚至在某些模块的开发速度提升了三四倍。但随之而来的是一种深深的焦虑：我发现自己正在从一个“创造者”变成一个“审核员”。当 AI 接管了所有繁琐的“重活”后，那种通过编码获得的底层掌控感在迅速消失。如果未来的 3-5 年，AI 能够处理 90% 的实现细节，软件工程师的竞争壁垒到底应该建在哪里？

在经历了一段时间的自我怀疑后，我意识到不能在 AI 提供的便捷中产生依赖，必须强行将重心从“实现功能”转向“定义系统”。

首先是把精力向系统架构与设计倾斜。AI 能够写出语法完美、运行高效的独立函数，但在面对极其复杂的业务场景时，它很难做出最优的架构决策。例如，在处理高并发下的数据一致性方案，或者在决定是采用微服务拆分还是单体架构优化时，AI 往往给出的是教科书式的通用答案，而非基于具体业务痛点的精准决策。我现在花在模块解耦、数据流设计和可扩展性思考上的时间，远超之前写代码的时间。

其次，我开始强迫自己培养“产品工程能力”。以前作为一名 Coder，我的职责是把产品经理给的 PRD（产品需求文档）实现出来，至于这个功能对用户是否有真实价值，那不是我的考量范围。但现在，由于实现成本被 AI 极大地降低了，真正的挑战变成了“定义什么才是正确的产品”。一个能定义产品的 Engineer，其价值远高于一个只会把需求翻译成代码的翻译官。

最关键的一点，为了防止自己被 AI “养废”，我给自己制定了一套极其严苛的禁令：在某些核心业务模块，我强行禁用 GitHub Copilot 和所有 AI 助手，必须手动编写逻辑。

我发现一旦习惯了 AI 补全，大脑在处理复杂逻辑时的“深度思考”能力会迅速退化。前段时间在处理一个涉及多线程同步的死锁问题时，我尝试让 AI 修复，结果它给出的方案虽然通过了单元测试，但在压力测试下依然触发了偶发性的竞态条件。直到我关掉 AI，手绘时序图，重新梳理锁机制，才发现了问题的根源。这让我意识到，如果失去了在没有 AI 辅助下 debug 的能力，我们最终会变成 AI 的附庸，而不是它的掌控者。

这种从“工匠”到“监工”的转变过程其实挺痛苦的，它要求我们放弃那种通过重复劳动获得的虚假安全感，去面对更抽象、更具有不确定性的系统级挑战。但这可能正是 AI Agent 时代必然的进化路径：我们不再需要证明自己能写出完美的循环，而需要证明自己能定义一个完美的系统。