一个让我困惑的短视频

前几天刷到一个短视频：病人在门诊看病，有人拍到医生全程偷偷用手机上的AI软件辅助诊断。视频下的很多评论都觉得医生水平不行、不负责任。

说实话，我的第一反应和评论区一样。但仔细一想又觉得不对劲——我们不是天天在Vibe Coding么？怎么换了医生用，大家的态度就这么差？

这套"双标"让我越想越好奇：为什么同样是AI辅助工作，程序员用就是先进、高大上，医生用就是不专业、不值得信任？

我一开始想到的解释是错误容忍度——医疗行业出错可能是一条人命，病人当然希望医生慎之又慎。而软件行业呢？bug 有自动化测试兜底，线上故障有回滚机制，公司更看重速度——程序员越快越好，出错反而是次要的。

这个解释貌似合理，但无法解释下面的两个例子。

智能驾驶和智能电话推销

第一个例子是智能驾驶。

你肯定看过那种新闻——车主开启智能驾驶后放松警惕，车辆径直撞上护栏或停在路边的故障车，车毁人亡。过去几年仅公开报道的严重事故就有十几起，每一起都是车主过度信任系统、系统没能识别边缘场景。这比医生误诊的风险还高。

但结果呢？很多人还是愿意用。 哪怕出了这么多事故，特斯拉的FSD、蔚来的NOP+等各家辅助驾驶系统照样有一大堆用户开得不亦乐乎，路上随处可见亮着小蓝灯的辅助驾驶车辆，一点没被那些新闻吓退。如果"出错代价高"就意味着AI接受度低，那智能驾驶应该被骂得最狠才对——但它没有。

第二个例子是智能电话推销。

这大概是每个人都经历过的——接听一个陌生电话，听了几句发现对面是AI，直接立刻挂断。甚至有时候聊了好几句才发现对面是AI，那一瞬间会有种被冒犯的感觉。

但智能电话推销出错的代价高吗？不高——顶多浪费几分钟、购买了一个没用的产品而已。比起医生误诊和智能驾驶出车祸，它的错误代价几乎可以忽略不计。

可我们偏偏对它容忍度最低。

这就矛盾了：高风险=接受（智能驾驶），低风险=拒绝（智能电话推销）。 错误容忍度这个框架，根本解释不了。

一个新的框架：标准化判断 vs 人性化判断

那真正在起作用的维度是什么？把四个场景放在一起重新看：

关键区别不在于"错了会怎样"，而在于AI在这里做的是"标准化判断"还是"人性化判断"。

标准化判断：有标准答案的事。智能驾驶就是典型——交通规则写在纸面上，红灯停绿灯行，所有人都一样。AI遵守规则，你没什么好不放心的。

人性化判断：没有标准答案、因人而异的事。医生给你看病，不是给"统计人群"看病——你要他看的是你独有的症状组合、生活习惯、过敏史，不是论文里的平均数据。智能电话推销也是——你接听电话是因为你的需求、你的喜好、你的情况，不是"大部分用户"的情况。

这正是 120+ Jobs That AI Can't Replace Across 13 Fields in 2026 在讲的核心洞察：

"The output produced by an AI tool is always predictive, based on algorithms and what the tool has been exposed to so far."

AI永远在输出训练数据的统计平均值。智能驾驶这种"平均值就是最优解"的场景，AI完美胜任。医生诊断、电话推销这种你需要的不只是一个平均值的场景，AI越帮忙，你越觉得它帮倒忙。

但还有一个更深的层次——

你反感医生用AI，不是因为AI准确率不够高（事实上在某些诊断任务上AI准确率已超过人类）。你反感是因为："你没在给我看病，你在给我所在的统计人群看病。" 你从医生那里想要的不仅是"正确答案"，还有"我得到了个性化的关注"——这个感受本身就是诊疗的一部分。

智能电话推销也一样。我不是不能接受AI说"这个产品很适合你"，我是不能接受你连问都不问我具体情况就给我一个模板回答。

那智能驾驶为什么不被排斥？因为司机要的本来就不是个性化服务——规则是统一的，你遵守好就行。你不需要它"懂你"，你只需要它遵守规则。

这就引出了问题的核心：AI的天花板不在能力边界，而在人性化判断的边界。

说了也没用：人性化判断的四个层次

前面论证了AI只能做标准化判断、做不了人性化判断。但人性化判断本身也有层次。有些可以教给AI，有些不行，有些不划算教。而不行和不划算的那部分，才是你真正的护城河。

第一层：我能说清楚，AI能学会

比如"我喜欢用函数式风格写代码"、"测试覆盖率要达到90%以上"、"优先选择社区活跃的库"。这些偏好和规则是明确的，写成 Prompt 喂给 AI，它就能照做。

第二层：我能说清楚，但不想告诉AI

比如"选A方案是因为团队里资历最深的同事更擅长A的技术栈"、"不选B是因为上次用B的失败项目让管理层对这条路有偏见"。这些因素直接影响决策，但你不适合写进 Prompt——它们太敏感、太政治、太容易引起争议。AI如果知道了这些，它要么无法恰当处理，要么在团队里说出来反而坏事。

第三层：我能说清楚，但不划算告诉AI

比如一次较大的代码重构——涉及几十个文件，修改点零碎分散，每个文件要改的模式又不完全一样。你没法用一两句话说清楚"要改什么"，必须逐个代码块分析上下文才能决定怎么改。这种情况下，把每个细节都描述给AI的功夫，自己早就改完了。告诉AI没有性价比。

第四层：我说不清楚，AI更学不会

这一层才是最关键的。

你有没有过这种体验？两个架构方案摆在面前，旗鼓相当，从数据上看选哪个都行。但你就是觉得应该选A。同事问你为什么，你想了半天也只能说"感觉"。

不是你在敷衍——那个判断来自你过去做过的类似决策、踩过的坑、对这个团队技术脾性的直觉。这些东西没有写在任何文档里，你也很难用语言完整表达。

但这里有一个更深的问题：即使你说清楚了，有些决策的本质也不是"求解"，而是"对齐"。

图：求解模式中 AI 可独立完成全流程，对齐模式中 AI 只能停在"团队讨论"之前——因为讨论的本质不是找答案，而是达成共识。

当"讨论"是决策本身

前阵子我们就遇到一个架构问题：一笔业务数据到底该存在哪个系统？有人说A系统，有人说B系统，各有各的技术理由，扯了半天谁也说服不了谁。

AI能帮上什么忙？它可以列出放A系统的好处（查询快、运维成熟）、放B系统的好处（数据一致性好、扩展方便）。两边优缺点列得清清楚楚，但决定就是做不出来。

为什么？因为技术上的优缺点在这里起不了决定作用。真正起决定作用的问题是：谁来维护这些数据？哪个系统更方便这个人操作？

这是数据所有权和管理权的问题。A系统的维护团队最熟悉这些数据的业务场景，把数据塞进他们不熟悉的B系统，出问题他们连排查入口都找不到。这个考量，AI完全使不上劲——它不知道两个团队各自的能力边界在哪，不知道上次A系统的维护团队被B系统坑过的事故，更不知道维护者们嘴上不说、但心里清楚的，"这个活儿落在谁头上"才是关键。

所以AI能做的，只是分析技术上的优缺点——这是标准化判断的范畴，AI做得很好。但它没法替你回答：谁对结果负责？谁更方便维护？谁的话语权更大？

因为讨论的本质不是在数据中找答案——如果答案在数据里，大家自己看数据就行，不需要讨论。讨论是在信息不完整、各方利益不一致、团队有自己的历史包袱和偏好时，通过碰撞达成共识的过程。

方案的选择通常被这些因素左右：

• 团队已有的技术实践（"我们一直在用Spring，换Quarkus有学习成本"）

• 个人技术偏好（"我觉得Haskell写起来就是爽，你有意见吗"）

• 战略方向（"技术VP说今年要把Go作为主力语言"）

• 历史包袱（"上次选了个冷门框架，半年后没人维护，大家都在骂"）

• 团队氛围（"这个团队习惯深度讨论，不是谁说了算"）

这些因素的共同点是：我无法全部告诉AI。 其中一部分我说不清，一部分我不愿说，一部分说出来也没用——因为决策权本来就不在我一个人手里，最终结论来自一群人的交流。

这个过程——讨论、让步、对齐、达成共识——和AI的能力边界无关。即使AGI明天就出现，你仍然需要和同事面对面讨论出一个大家都能接受的方案。因为技术决策的最终目标往往不是"正确答案"，而是"大家愿意往前走的方向"。

这就是程序员的护城河所在。

程序员的护城河不在"做得更快"

过去很长一段时间，程序员的核心价值是"能用代码解决问题"。写得越快越稳，价值越高。AI正在系统性地削弱这个价值——写代码这件事越来越接近标准化判断。GitHub Copilot、Claude、Cursor这些工具，正在把"需求翻译成代码"的效率提升一个量级。

但与此同时，AI正在放大另一端——需要参与判断的工作——的价值。

AI能帮你做的分析越多、越快，你需要做的判断就越重要。当一个架构方案的优缺点五分钟内就被AI梳理得清清楚楚，真正的瓶颈就变成了：谁来做决定？谁能推动团队对齐？谁能看到数据之外的因素？

这些问题，AI一个都回答不了。

所以与其说"找AI替代不了的岗位"，不如说程序员需要完成一次工作方式的转变：从"完成指令"到"参与判断"。

具体来说：

• 参与技术方案的讨论环节，而不是等着拿到方案后执行

• 主动推动团队对齐，理解每个人的偏好和顾虑，找到折中点

• 积累无法写在文档中的隐性知识——对团队的了解、对业务的理解、对技术方向的直觉

• 成为那个"最后做决定"的人，而不是那个"AI做了决定我照着写代码"的人

10 Jobs AI Won't Replace: Future-Proof Careers for the AI Era 把AI不可替代的工作归纳为"四大支柱"——高人际密度、复杂环境中的现场办公、开放式问题解决、道德法律责任。但拆开看，这四大支柱本质上都在说同一件事：这些工作需要人性化判断，而你无法把人性化判断外包给一个输出统计平均值的系统。

文章里还有一句话说得更直接："AI can remix patterns, but it cannot set cultural direction." 文章以创意总监为例阐述这个观点，但在软件行业也一样。AI可以帮你生成代码模式、分析架构选项、整理技术风险，但它永远无法参与"这个团队应该往哪个方向走"的对话。那是只有你——在这个团队里、了解这些人的历史、知道这些上下文的人——才能做的事。

结语

回到开头那个短视频。病人反感医生用AI，不是因为AI不够准，而是因为病人想要的不是一个平均水平的诊断，而是一个针对他自己的判断。

我们做程序员也一样。AI会写更多代码、分析更多方案、提出更多建议——但最终，那些需要和你一起讨论、需要你参与共识、需要你把说不清的东西带到对话里的判断，才是你真正不可替代的部分。

你的护城河不是那些AI做不到的事，而是那些AI无法参与的对话。

那些对话既需要你的隐性知识，也需要你人在现场。AI在左边，你在右边。它在搞定"该怎么做"，你在回答"我们该往哪走"。

后者，才是真正产生价值的地方。