ai 时代程序员的核心不适:从确定性逻辑到概率性交互的范式转移

📅 2026/6/25 13:33:01
ai 时代程序员的核心不适:从确定性逻辑到概率性交互的范式转移
程序员最喜欢确定性程序员其实很喜欢和机器沟通因为机器讲规矩。你输入print(hello world)控制台就输出hello world不会突然给你来一句hello world顺便我觉得你今天状态不错也不会根据心情把输出改成Hello, my friend!更不会因为你上一次问过它一个 Kubernetes 的问题这一次就顺手把hello world扩展成一篇微服务架构设计传统计算机系统最大的特点就是确定性。同样的输入在同样的环境、同样的代码、同样的依赖版本下理论上应该得到同样的输出如果结果不一样我们通常可以从这些地方找原因代码变了、配置变了、环境变了...总之它一定有原因而且这个原因通常可以被定位、复现、解释和修复这就是程序员喜欢的世界。虽然它有时候很冷冰冰但它讲逻辑有确定流程。少一个括号它告诉你语法错误。变量名拼错它告诉你未定义。类型不匹配它告诉你不能这么干。接口参数传错它给你一个 400。数据库字段不存在它给你一个 SQL 报错。虽然这些报错有时候看起来很烦但它至少在告 诉你老哥你这里错了。这对程序员来说非常重要。因为报错本质上是一种边界反馈。它告诉你哪里不合法哪里不符合规则哪里没有按系统预期来ai并不确定甚至会胡说没有异常捕捉。没有标准错误码。没有严格的 schema 校验。甚至很多时候问题已经发生了但你还不知道问题发生在哪。而现在我们面对 AI很多不 适感就来自这里。AI 看起来像机器但它的交互方式更像人AI 对程序员这一职业带来的深层冲击并不是简单的“它能写代码”。真正的冲击是我们从确定性系统开始进入概率性交互。过去我们使用工具是这样的输入固定命令 → 系统执行 → 返回确定结果 → 根据报错修正现在我们使用 AI很多时候变成了这样输入自然语言 → 模型理解意图 → 生成一个看起来合理的结果 → 人再判断是否可信注意中间多了一个非常关键的环节模型理解意图这个环节不是传统意义上的语法解析它不是简单检查你有没有少写一个分号它是在根据上下文、语义、训练数据、概率分布和当前提示词去猜测你到底想要什么所以同样一句话在不同上下文里可能得到不同答案。同样一个问题用不同模型可能得到不同答案。同样一个模型在不同温度、不同系统提示词、不同历史对话下也可能给出不同答案这对于习惯了确定性闭环的程序员来说确实非常反直觉没有报错是最难受的地方面对 AI最难受的不是它直接告诉你“我不会”。最难受的是它经常给你一个看起来很像真的答案。而你不知道这个答案到底是真懂还是在满嘴跑火车 。传统系统里如果命令错了它会报错。AI 不一定。它可能会非常自信地回答你。它可能会把不存在的 API 写得像官方文档一样。它可能会把错误的排障路径说得头头是道。你无从判断到底是自己没说清楚还是模型理解偏了还是结果本身存在隐性错误过去程序员依赖的东西是什么精准控制、确定输入、确定输出、异常反馈、可复现链路而 AI 默认的聊天式交互把这些东西都削弱了不是完全没有而是不会自动给你本质是范式转移AI 带来的变化本质上是从“确定性逻辑”向“概率性建模”的范式转移传统编程世界更像数学题规则清楚边界明确输入输出可验证。AI 世界更像和一个知识很多、表达能力很强、但偶尔会脑补的实习生协作。你要给它上下文、边界、验收标准你要把它的输出放进工程流程里验证。这和过去“写命令 、看输出”的方式完全不一样。所以程序员在面对 AI 的时候会有一种天然的不安全感程序员需要补的新能力过去程序员最核心的能力之一是把人类需求翻译成机器能执行的代码。现在又多了一层把模糊意图翻译成 AI 能稳定理解的任务结构。这不是简单的“ 会不会写 prompt”。更像是一种新的工程表达能力。上下文组织能力ai 很依赖上下文但上下文不是越多越好。你要知道哪些信息必须给哪些信息会干扰哪些信息需要脱敏哪些信息应该结构化。 这和写 需求分析文档 很像约束表达能力你不能只告诉 ai 做什么还要告诉它不要做什么。工程场景里很多时候“不知道”比“瞎猜”更有价值。不要编造不存在的接口不要假设没有给出的日志不确定就说不确定只输出可执行步骤先列事实再给判断结果验证能力ai 给出的结果必须进验证链路。写代码就跑测试写 SQL 就 explain改配置就 dry-run排错就查日志和指标不要把 ai 输出当最终结果它更像候选方案流程设计能力把常见任务做成流程让它会变成流程中的一个环节AI 不是天生不可控很多时候是我们使用 AI 的方式还停留在“人类聊天模式”而不是“工程模式”什么叫聊天模式比如帮我分析一下这个线上问题这句话涉及的东西太多了完全没法聚焦就算是问一个程序员他也没法回答你他也要去检查告警、日志、变更等等数据才能回复更别说ai如果ai没有数据获取的渠道那就智能瞎猜了工程模式应该是什么工程模式不是让 AI 自由发挥而是把 AI 放进一个有边界、有输入、有输出、有校验的流程里。比如你现在是一个线上故障排查助手。 背景 - 服务order-service - 现象最近 10 分钟 P99 延迟从 120ms 升到 2.3s - 影响下单接口超时率约 8% - 最近变更20 分钟前发布了 v1.8.3 - 已知事实CPU 正常内存正常数据库连接数升高 请你只基于上述事实分析不要编造不存在的日志。 输出格式 1最可能的 3 个原因 2每个原因对应的验证命令或指标 3优先级排序 4如果证据不足请明确说证据不足程序员不会消失但工作方式会变笔者不太喜欢那种“ai 来了程序员完了”的说法。程序员这个职业不会因为 ai 一夜之间消失。但程序员的工作方式一定会变过去更重要的是记住语法、熟悉 API、手写样板代码、根据报错一点点调未来更重要的可能是把问题定义清楚、把上下文组织清楚、把约束表达清楚、把 ai 输出验证清楚、把不确定性管理清楚也就是说过去我们主要面对的是确定性机器以后我们会越来越多面对概率性系统谁能把概率性系统装进工程流程谁就更容易把 ai 用出价值总结说白了ai 对程序员最大的冲击不只是“会不会抢饭碗”而是我们这么多年赖以生存的确定性工作方式正在被概率性交互一点点打碎。它改变了我们 和机器交互的基本方式。过去是命令式、确定性、强校验、有报错现在是自然语言、概率性、弱反馈、需要人主动设计边界和验证流程