前言

提前祝大家5.1快乐，在ai爆发的这几年，我们程序员群体都经历来自ai的冲击，天天受到无数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 对程序员最大的冲击，不只是“会不会抢饭碗”，而是我们这么多年赖以生存的确定性工作方式，正在被概率性交互一点点打碎。它改变了我们 和机器交互的基本方式。过去是命令式、确定性、强校验、有报错，现在是自然语言、概率性、弱反馈、需要人主动设计边界和验证流程

所以真正的问题是我们跳出原有的思维模式，适应ai时代下的设计范式，别把 ai 当神仙，也别把 ai 当骗子

联系我

• 联系我，做深入的交流

至此，本文结束

在下才疏学浅，有撒汤漏水的，请各位不吝赐教...