最令人不安的 Reddit 讨论
真正的风险不是自动化，而是放弃责任。
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
最近 r/cscareerquestions 上的一个 Reddit 帖子切中了 AI 讨论的要点。一位三年经验的工程师看着他们的技术主管——一个曾经花数小时在白板上设计复杂系统的人——提交了一个描述为*"基于 ChatGPT 输出重构了认证流程"的 PR。当被要求解释更改时，该主管说："把它粘贴到 ChatGPT 里，让它解释。"*
同一个团队。另一位高级工程师现在通过将 diff 复制到 AI 聊天中来在三分钟内批准 PR。这个过程让一个竞态条件溜进了生产环境。理由是："AI 说它是线程安全的。"
这个帖子以一个值得深思的问题结尾："我不知道是我反应过度，还是我们正在集体丧失推理自己系统的能力。"
这不是一个夸张的问题。这是一个正确的问题。
1、两个值得明确命名的问题
问题 1：合并你无法解释的代码。
用 AI 加速你理解的工作和用它生成你不理解的工作，两者之间有重要区别。前者是工具，后者是负债。
认证流程、线程、数据权限、支付逻辑——这些领域中，误解不仅会导致 bug，还会导致安全事件、数据泄露和生产故障，需要有人在午夜站在作战室里解释出了什么问题。
AI 做不到这一点。但 PR 上的名字可以。
问题 2：代码审查变成橡皮图章。
对一个非 trivial 的 diff 进行三分钟 PR 审批，不是审查。这是在你没读过的东西上签名。
What a real review cycle looks like vs. what's being described:
REAL REVIEW:
[PR Opened]
│
▼
[Read the diff - understand what changed and why]
│
▼
[Check context: how does this touch existing systems?]
│
├──► [Flag logic errors, edge cases, threading issues]
├──► [Check for security surface changes]
└──► [Verify tests cover the new behavior]
│
▼
[Approve or request changes - with reasoning]
AI-ASSISTED RUBBER STAMP:
[PR Opened]
│
▼
[Paste diff into chat window]
│
▼
["Looks good" → Approve] ← race condition ships here
那个进入生产的竞态条件之所以溜过去，不是因为 AI 不擅长审查代码。而是因为审查者把判断——而不仅仅是辅助——也委托了出去。
2、为什么这在高级别尤其危险
初级工程师会犯错。这是意料之中的正常情况。他们周围的团队部分存在的意义就是为了发现这些错误并解释为什么它们是错误的。
当一个主管工程师将跳过推理步骤正常化时，动态就颠倒了。初级工程师观察到这种行为，并得出结论：这就是生产级工作的完成方式。标准不仅仅是一个人下降——它在传播。
Influence flow on an engineering team:
Staff Engineer behavior
│
▼
┌──────────────────────────────┐
│ "If senior devs do it, │
│ it must be acceptable" │
└──────────────────────────────┘
│
▼
Senior Engineers adopt pattern
│
▼
Mid-level engineers adopt pattern
│
▼
Juniors have no reference point
for what "understanding your code"
even looks like
这就是机构知识悄然消失的方式——不是通过戏剧性的重组，而是通过"不需要理解你发布的内容"这种行为的缓慢正常化。
3、深思熟虑的 AI 使用实际上是什么样的
所有这些都不是反对在工程中使用 AI 的论点。而是关于清楚你在委托什么、没有委托什么。
# Using AI as an accelerator — not a replacement for understanding
def review_with_ai_assist(pr_diff, codebase_context):
"""
AI assistance belongs here:
- Initial surface scan for obvious issues
- Boilerplate pattern checks
- Syntax and style suggestions
Human judgment required here:
- Does this change make sense in context?
- What are the failure modes?
- Does the author understand what they shipped?
- Would I be comfortable explaining this at 2am?
"""
ai_scan = run_ai_review(pr_diff) # fast, automated
human_judgment = reason_about_system( # non-delegable
diff=pr_diff,
context=codebase_context,
ai_notes=ai_scan
)
return human_judgment # this is what gets merged
AI 扫描是有用的。但 human_judgment 调用是不可跳过的。
一个好的启发式方法：如果你无法在事后复盘（postmortem）中解释这个更改，你就不应该批准它。这个标准与 AI 无关——它一直以来都是标准。
4、真正面临风险的技能
问题不在于工程师在使用 AI 工具。而在于推理系统的习惯——追踪数据流、识别边界情况、在脑中维护组件交互的心智模型——这是一块肌肉。当它不再被使用时，它就会萎缩。
What gets lost when reasoning is consistently outsourced:
┌─────────────────────────────────────────────┐
│ System mental models → harder to rebuild │
│ Debugging instinct → slower to develop │
│ Design tradeoff sense → doesn't transfer │
│ Incident response speed → tied to both above│
└─────────────────────────────────────────────┘
这些不是软技能。它们是当某些东西以 AI 未预料到的方式出问题时最重要的技能——而在积累了多年约束的生产系统中，这种情况经常发生。
5、结束语
AI 在软件工程中是一个真正有用的工具。Reddit 帖子描述的问题不是 AI 存在本身。而是一组有经验的工程师不再将"理解"视为必要条件。
PR 上的名字仍然对结果负责。这在 AI 工具出现之前就是真理，现在仍然如此。
高级工程师塑造了团队中"正常"的样子。当标准变成 "AI 说没问题" 时，这个标准就会传播。失去的不仅仅是代码质量——还有如何推理那些无法整齐塞进聊天窗口提示中的系统的机构知识。
工程仍然是一份思考的工作。AI 让其中一部分变得更快。但它并没有让思考变成可选项。
原文链接: Reddit's Most Disturbing Engineering Post Isn't About AI Replacing Jobs.
汇智网翻译整理，转载请标明出处
