当我们变成“Yes工程师”：与AI协作的真实心态图鉴

在如今的开发圈子里，你是不是也经常有这种感觉：只要一“vibe”起来，自己立马就能无缝切换成一名完美的“Yes工程师”。

所谓的“Yes工程师”，并不是指对老板唯命是从，而是对咱们现在的“数字同事”——AI助手言听计从。

日常对话大概是这样的：

当我vibe的时候，感觉像一个Yes工程师

我： 先给我想一个方案，等我审核通过了你再动手。

AI： 没问题，这是针对你需求设计的详细代码架构方案，包含上下文管理、错误处理日志模块……（噼里啪啦甩出一大段复杂逻辑）。

我： （盯着屏幕看了三分钟，心里默默OS：这写的啥？虽然每个字都认识，但连起来怎么就看不懂了呢？）

我： 嗯……虽然有点复杂，但既然你有理有据，那就按你说的办吧。

这场景是不是极其眼熟？

以前我们写代码，讲究的是“知其然，更知其所以然”。现在呢？讲究的是“能跑就行，别报错就行”。这种现象背后，其实反映了我们在技术爆炸时代的一种微妙心态转变。

1. 从“掌控者”到“审批者”的角色滑坡

以前我们写代码是全栈掌控，每一行逻辑都烂熟于心。现在有了Copilot、GPT这些强力辅助，我们开始习惯性地让AI先输出。原本想的是“我要审核方案”，结果往往是被AI的方案绕晕。因为AI生成的逻辑有时不仅长，而且还会用一些你没见过但确实更优的写法。

于是，原本的“Code Review”变成了“盲信点赞”。只要它不报红，只要测试能过，我们就敢直接merge。这种“Yes”不仅是对AI能力的认可，也是对自己认知边界的无奈妥协。

2. 效率与深度的博弈

说实话，这种“Yes”模式在大多数时候是高效的。尤其是在处理棘手的Bug或者不熟悉的库时，AI给出的方案确实比自己去Stack Overflow翻半天帖子要快得多。我们节省了大量查文档的时间，换取了业务推进的速度。

但代价是什么呢？是代码理解的深度。我们越来越像是一个“项目经理”，在指挥AI干具体的活儿。长此以往，如果离开了AI，我们还能不能快速写出优雅的代码？这成了很多老程序员心里的隐忧。

3. 如何避免彻底沦为“复读机”？

虽然自嘲是“Yes工程师”，但我们也不能真就把脑子丢给AI。这里有几个小建议，帮你找回一点“主导权”：

• 拒绝直接Copy： 哪怕看不懂全部，至少要求AI解释核心逻辑。让它用“给五岁孩子讲故事”的方式给你讲讲这段代码到底在干嘛。
• 拆解任务： 不要扔给它一个巨大的需求让它直接生成全案。拆分成小步骤，每一步自己确认无误后再进行下一步。这样即使某一步它“胡说八道”，你也能及时发现。
• 留好后手： 对于关键的业务逻辑，不要全信AI生成的“黑魔法”。如果逻辑过于晦涩，哪怕自己重写一段朴实无华但看得懂的代码，也比维护一个神级“屎山”要强。

结语

变成“Yes工程师”未必全是坏事，这是工具进化带来的必然结果。幽默归幽默，该学的技术还是得学，该懂的原理还是得懂。毕竟，AI生成的代码出了问题，最后负责调试和背锅的，还得是我们自己啊。

所以，下次当AI给你甩出一大段看不懂的“神级代码”时，试着多问一句：“能不能换个我看得懂的方式写写？”

哪怕最后还是按它说的办，至少，咱们得装作努力过，对吧？