AI时代，普通程序员该如何提升自己?-171主机测评

在这里插入图片描述

👨‍💻程序员三明治：个人主页

🔥 个人专栏: 《设计模式精解》《重学数据结构》《AI探索日志》《从0带你学深度强化学习》

🤞先做到再看见！

背景

时间进入2026年，随着OpenClaw、Claude Code、Codex等Agent爆火，Agent的能力大大加强。这条演进链背后，是我们对"如何驱动模型"的理解在不断加深：Prompt Engineering 解决怎么把话说清楚，Context Engineering 解决该喂给模型哪些信息，Harness Engineering 解决怎么把工具、环境、反馈接进模型的工作流，Loop Engineering 则解决怎么让模型自己迭代收敛。很多时候，在context起点不错的情况下，模型生成的代码要比程序员写的代码好很多倍，效率也很高，从原来写一个需求，程序员需要3pd的时间迅速缩短为1pd。

当模型变得这么强之后，程序员似乎只需要和AI对话，顶多再做一下业务测试和验证，剩下的环节好像都不再需要自己动手了——那自己的价值到底体现在哪里？既然大家都会使用AI来完成编程，那你用AI和别人用AI有什么区别呢？

甚至当有人比你的语言表达能力更强的时候，别人跟AI对话后得到的东西更有价值。

…我迷茫了，不知道怎样才能提升自己。在这里插入图片描述

破局之路

我把它概括为两个方向，第一个是术的层面，第二个是道的层面。

术

最开始我们把用AI生成代码叫做Vibe Coding（氛围编程），别人问你是不是Vibe Coding，也就是在问你对你 Accept 的代码负不负责？

所以结论先行：**不是"AI 做不了什么"，而是"AI 做什么都需要你先做对什么"。**下面这五件事，就是必须由人先做对的部分。在这里插入图片描述

一、问题定义能力

模型能解决你定义的问题，但定义问题，澄清需求本身就是最难的部分，也是需要人来去做好。

比如，**“加个登录功能”，**这是一句话，这不是需求定义，真正的需求定义要包括：

密码连续输错五次要不要锁定？锁定多久？
同一个账号在第二台手机登录时，要不要把第一台踢下线？踢之前要不要弹个通知？
"记住我"勾选了之后有效期是七天还是三十天？
…

在这一层面，人的优势是：能把模糊的需求拆解成清晰的技术规格——边界条件、异常处理、业务规则等，不讲清楚这些，代码一定写不对。在这里插入图片描述

二、上下文构建能力

同样一个需求，两种人使用AI：

A说"写一个登录接口" —> AI会凭想象去写，大概率不符合你的业务

B给了完整的业务规则、数据库表信息，上下游接口文档等 —> AI写的代码基本可用

上下文构建能力包括：

知道该给什么信息和不给什么信息
知道怎么组织语言：先给背景再给需求，和反过来，AI 的生成质量完全不同

这也是我认为语言表达能力的重要性。

三、结果验证能力

验证能力不是"跑一下看有没有报错"，而是：

业务语义验证：这段代码的行为是否符合业务意图
边界验证：极端情况下的行为是否符合预期
回归验证：这次改动有没有影响其他功能

这三层里最容易翻车的是第一层。我遇到过一次，AI 生成的一个金额计算逻辑，单测全绿、编译通过、CR 也没看出问题，但它把"优惠后金额"当成了"优惠前金额"去算佣金——语法上完全正确，业务语义上整个反了。测试用例是 AI 一起生成的，它按自己理解的语义写断言，自然全过。AI 生成的测试只能证明代码符合 AI 的理解，不能证明它符合业务的意图，这一层的验证只能由人来兜底。在这里插入图片描述

四、技术决策能力

前几天跟mentor聊到，自从有了AI，技术门槛被大大降低了，但是不意味着可以对于一些MySQL、Redis等常用的数据库、中间件等的基础进行忽略，关键的时候，你得知道这个技术栈和其他技术栈的区别是什么，在什么特定场景使用哪个技术栈最好，而不是一味听从AI给的技术方案，自己却没有判断能力。

AI 能列出方案 A 和方案 B 的 pros/cons，但拍板选哪个是你决定的，通用建议和具体场景之间，永远需要人来做判断。

举个例子：AI 会告诉你"高并发场景用缓存"，但不会告诉你你们团队的缓存之前出过两次线上事故，这次要用就得多加一层降级。这个判断只能人做。

五、成本控制能力

一次大模型交互，可能产生大量的token消耗，如果不加控制，甚至跑一天下来，比人的工资还高。

成本能力包括：

知道什么时候用弱模型，什么时候用强模型
知道怎么组织上下文才能省token
知道哪些任务让AI做更贵，让人工做更便宜

举个具体的例子：一个批量数据订正的需求，如果直接把整个仓库丢给 Agent 让它自己找、自己改、自己跑，一轮下来轻松几十万 token；而如果先自己花十分钟定位到那两个类，只把相关代码和表结构喂进去，同样的产出可能只要几千 token。同一件事，两种做法的成本能差出一两个数量级。更关键的是，这类消耗往往是无声的——没有人报警，直到月底看账单才发现。

总结：**AI 的输出质量取决于工程师的输入质量——定义问题、构建上下文、验证结果、做决策、控成本，这五件事 AI 替代不了人。**只要 AI 还需要人来驱动，那人的优势就在。

道

上面"术"的五件事，讲的是下限——把它们做好，你就不会被 AI 替掉。但下限只能保证你留在牌桌上，不能保证你和别人拉开差距，因为这五件事别人练练也能做到。接下来说的"道"，讲的是上限。

这里要先把一件事区分清楚：**贬值的是技术执行的稀缺性，不是技术本身的价值。**以前你能把一个复杂模块写出来，这件事本身就值钱，因为能写出来的人不多；现在能写出来的人（和模型）多了，这一段的溢价就没了。但判断该写什么、为什么写、值不值得写的能力，反而因为执行变便宜了而变得更稀缺。下面这两节，说的就是怎么往后者走。

商业思维

看到一句话：在现阶段，别只在功能层面把需求做完就完了，多从商业层面想想产品。

这句话挺扎我的，因为我之前的工作习惯就是：需求来了，交给AI把它翻译成代码，review下、然后测试验证、上线，需求结束。我很少停下来问，这个需求为什么会存在？它解决谁的问题？公司为什么愿意为这个功能付钱？

我们被训练的太像翻译器了，我们总是把需求文档翻译成代码，但不太过问这份文档为什么会有。

我以前一直觉得技术就是护城河，你算法厉害、架构牛逼、你搞过三高场景、你会写RPC框架、手撕红黑树，你就是稀缺人才，但这个逻辑现在没这么硬了。

所以我现在琢磨出一个可能不太被很多人认可的观点：单纯的技术执行没那么值钱了，值钱的是idea。不是说技术没价值了，而是当AI把程序员的能力提高到70分的时候，80分和90分之间的那道鸿沟，市场愿意付的溢价正在极度缩水。

坑就坑在，过去我们绞尽脑汁积累的，恰恰就是这部分执行层的稀缺性。承认它在贬值，确实让人难受，但早点承认，才能早点把精力换到还在升值的那一边。

而升值的那一边，又绕回了"术"里的第一件事——问题定义能力。区别在于，"术"里的问题定义是把别人给的需求定义清楚，而这里说的是自己找到那个值得被解决的问题。

因为AI最擅长的，是把问题给足上下文之后高效求解，但它不会凭空定义问题。定义问题这件事，需要你对世界有欲望、有观察、有偏见、有痛苦。

当工具不再稀缺

你会跟AI对话让它写代码，换一个人过来也能做，甚至当别人语言表达能力更强的时候，跟AI对话能获取到更高质量的答案，那自己的意义和价值是什么？

就像一个摄影师，以前他的价值是会调光圈，会修图，现在AI一键就能出大片，但他如果还只会按快门，那他确实会慌，可是他如果真正值钱的是知道什么时候拍、拍什么、为什么拍，那AI只是他的新相机。在这里插入图片描述

第一性原理（如何做）

第一，写代码之前，先把**为什么**问出来。不是敷衍地问一句为什么做这个需求，是真的去搞清楚，这个功能解决谁的什么问题，不做会怎么样。这个习惯会慢慢改变你看事情的角度。

第二，刻意去看自己项目的业务数据。不是只看技术指标，要看用户反馈、留存、转化率。要有商业思维。

第三，训练自己的表达。AI时代，想法的传播速度会决定想法的价值。一个想法再牛，你说不清楚，AI也帮不上忙。

第四，也是最重要的一点，别让AI代替你思考，只让它代替你动手。如果你每天的工作只是不断地把提示词改来改去，那你的价值确实会越来越薄；但如果你把 AI 省下来的时间，重新投到定义问题、理解业务、做判断这些事上，那 AI 越强，你被放大的倍数就越大。在这里插入图片描述

回到开头那个问题：大家都用 AI，你和别人的区别到底在哪里？

现在我的答案是：**区别不在于你会不会用 AI，而在于 AI 停下来的地方，你能走多远。**它能把你定义好的问题解得漂亮，但问题本身得你提；它能给出两个方案的利弊，但拍板得你来；它能写出能跑的代码，但这行代码到底该不该存在，得你回答。

迷茫往往不是因为能力不够，而是因为一直站在被替代的那一侧看问题。换到驱动的那一侧，你会发现要学的东西不是变少了，只是换了一批。

如果我的内容对你有帮助，请辛苦动动您的手指为我点赞，评论，收藏。感谢大家!! 在这里插入图片描述

AI时代，普通程序员该如何提升自己?

目录

背景