程序员最喜欢确定性
程序员其实很喜欢和机器沟通，因为机器讲规矩。你输入：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 对程序员最大的冲击，不只是“会不会抢饭碗”，而是我们这么多年赖以生存的确定性工作方式，正在被概率性交互一点点打碎。它改变了我们 和机器交互的基本方式。过去是命令式、确定性、强校验、有报错，现在是自然语言、概率性、弱反馈、需要人主动设计边界和验证流程
