码农不惑 | 第005篇

最近有个词很火——Vibe Coding。

简单说就是：你不再一行一行地写代码，而是用自然语言告诉AI你想要什么，AI帮你生成代码，你负责”感觉”对不对。

听起来像科幻？不，这就是我最近每天在干的事。

我39岁，算法组长，双非三本，非科班出身。做过监控工程、当过产品经理、三十多岁自学转码。按照互联网的叙事，我应该是”最容易被AI取代的那批人”。但现实恰恰相反——我可能是团队里用AI用得最狠的人。

而且我越用越觉得：Vibe Coding比的不是谁代码写得好，而是谁需求想得清、坑踩得多、产品感觉准。

这些能力，恰恰是我这种在现场摸爬滚打过、做过产品经理的35+程序员，花了十几年练出来的。

这篇文章，我想聊聊我用Codex做自动开发的真实体验——为什么产品思维和现场经验，才是Vibe Coding时代最被低估的武器。

01 一切从”懒”开始

程序员最大的美德是什么？懒。

不是摸鱼的懒，是”能自动化的事情绝不手动做”的懒。这种懒驱动了整个软件工程的进化——从汇编到C++，从手动编译到CMake，从手动部署到CI/CD。

而Vibe Coding，就是这种”懒”的最新版本。

以前写一个功能，你需要：想清楚逻辑 → 选技术方案 → 一行一行写代码 → Debug → 测试。现在呢？你只需要想清楚你要什么，然后用人话告诉AI。

这个转变看似简单，但对我这种35+的老程序员来说，冲击其实特别大。因为它意味着——我们花了十几年积累的”写代码”能力，正在被重新定价。

但别急着焦虑，往下看。

02 Codex初体验：说实话，第一次被震到了

第一次正式用Codex做自动开发，是一项TCP数据对接的任务。

做过嵌入式或者通信协议的人都知道，TCP数据对接是一种很”脏”的活——你要跟对方系统约定好数据包格式，然后一个字节一个字节地拆包、封包、对齐。大小端转换、字段偏移量、校验位计算……全是机械、枯燥、但又不能出一丁点错的苦力活。

以前做这种事，你得对着协议文档，一个字段一个字段地写解析代码。稍微错一个偏移量，整个数据包就全乱了。调试的时候盯着十六进制看得眼睛发花，改一个字节跑一遍，再改一个字节再跑一遍。做过的人都懂——这不是难，是磨人。

那天我抱着试试看的心态，打开Codex，把协议文档直接截图丢了过去。

没错，就是截图。 不是我手动把字段一个一个敲进去，而是直接把协议文档上那些密密麻麻的字段定义、字节长度、对齐规则截下来，扔给AI看。

然后——

它真的开始一个结构体一个结构体地往外蹦了。 字段偏移、大小端转换、数据类型映射、甚至连CRC校验的逻辑都写了。

我坐在椅子上看着屏幕，那种感觉很奇妙。这种字节对齐的活，我在工厂写单片机的时候就干过——那时候用汇编，一个字节一个字节地手搓，调一个通信协议能调一整天。十五年后，AI用几分钟就把框架给我出好了。

更让我震惊的是——一次过。 跑了测试数据，字段解析全部正确。字节偏移、字段对齐，甚至连大小端都给我考虑到了——做过嵌入式的人都知道，大小端转换是最容易踩坑的地方，很多老手都栽过。AI从截图里”看”出了字段格式，自动处理了端序问题。

要知道，以前手写这种代码，就算是老手也很难一次过。总有那么一两个偏移量算错了、某个字段的大小端搞反了，然后你就得抓着十六进制数据一个字节一个字节地对。而AI，截图一丢，一次过。

以前这种活至少要一两天，各种翻文档、对偏移量、一遍遍调试。现在核心框架半小时就出来了。

我人生中第一次真正体会到”降维打击”这四个字。 而且说实话，心里还有另一层感慨——当年在工厂用汇编手搓通信协议的那个我，做梦也想不到，十几年后会用自然语言让AI来干这件事。

03 但等等——能跑 ≠ 能用（产品经理的直觉救了我）

如果故事到这里就结束了，那这篇文章就变成了AI的广告。

TCP那次字节对齐确实一次过，但那是因为协议文档本身足够清晰——输入质量高，输出自然好。 实际工作中不是每次都这么顺。用得多了你会发现，AI生成的代码，大约70%是能用的，30%需要你去改。 而那30%，恰恰是决定这个东西能不能上线的关键。

但这里有个有意思的事——你的经验越多，那30%就越小。

举几个我遇到的真实场景，你就明白了：

场景一：AI不懂的业务潜规则，产品经理的直觉能补上。

还是那个TCP对接的项目。AI生成的解析代码能跑，但我做产品经理那几年养成了一个习惯——拿到任何功能，第一反应不是”能不能跑”，而是”实际使用中会遇到什么？边界情况是什么？”

所以我马上就想到：对方设备在某些异常状态下，会发过来一些不完整的数据包——包头有了但数据还没传完。一个纯写代码的人可能测试跑通了就提交了，但做过产品、跑过现场的人会本能地去想——这个”正常情况”的逻辑，碰到异常情况会不会直接崩？

果然，AI生成的代码没有做粘包和断包处理。如果我没有这个产品直觉，这个Bug要到线上设备断断续续抽风的时候才会被发现。

场景二：AI不会告诉你”这个功能不该做”。

有一次我让AI做一个批量操作的功能。AI写得很利索，功能完整。但我看了一眼就把”一键全选”的按钮删了——因为我做产品经理的时候见过太多次了：用户不小心点了全选，然后批量操作了几千条数据，打电话过来骂人。

AI只会忠实地执行你给它的需求。但一个做过产品的人知道：有些需求，最好的实现方式就是——不做。

场景三：现场经验能帮你预判AI想不到的坑。

AI生成的代码往往缺乏工程化考量——没有错误处理、没有日志、没考虑并发。但对我来说，这些不需要看到Bug才想到。我在监控工程现场见过太多”系统能跑但不能用”的场景：日志把磁盘写满了系统就挂了、几百路摄像头同时访问后端就卡了、甲方断电重启后数据全丢了。

这些踩坑经验变成了AI的”补丁”。 每次AI出代码，我脑子里自动就会跑一遍现场部署的checklist：异常处理有没有？日志规范不规范？大数据量扛不扛得住？

所以我的结论是：Vibe Coding不是”AI替你写代码”，而是”AI出草稿，你的产品思维和踩坑经验来把关”。 经验越多，把关越快，AI出来的东西就越能直接用。

04 两大武器：产品思维 × 现场经验

用了一段时间之后，我越来越确信一件事——Vibe Coding比的不是编码能力，而是两种能力：需求定义能力和质量判断能力。

而这两种能力，恰好对应了我身上最”非典型程序员”的两段经历。

武器一：产品思维——知道”要什么”和”不要什么”

我做过几年产品经理。那段经历当时看没什么用——无非是写PRD、画原型、跟开发扯皮。但现在回头看，那是我学到的最值钱的能力：把一个模糊的想法，拆解成精确的、可执行的需求描述。

Vibe Coding的本质是什么？就是用自然语言描述需求，让AI来实现。

这不就是写PRD吗？

同样让AI做一个”设备通信模块”：

• 一个25岁的纯码农可能会说：”写一个TCP客户端，连上设备收数据。”
• 而我会说：”写一个TCP客户端模块，连接设备端口8080。协议是自定义二进制格式，包头4字节，包含长度字段；需要处理粘包和断包；连接断开后自动重连，间隔5秒，最多重试3次；接收到的数据按协议解析后写入环形缓冲区；注意线程安全，收发在不同线程。”

同样是一句话Prompt，喂给AI的信息量差了十倍。 出来的代码质量自然也差了十倍。

产品经理训练出的那种”场景化思考”——用户是谁？怎么用？会不会误操作？出了问题怎么回退？——全都变成了Prompt里的上下文。 以前这些能力是用来写PRD跟开发沟通的，现在是用来跟AI沟通的。

做过产品经理的程序员，天生就是Prompt Engineer。

武器二：现场经验——知道”会出什么事”

AI能帮你生成代码，但AI不知道这个代码部署到现场之后会发生什么。而我知道。

因为我在监控工程现场亲眼见过系统挂掉的一百种方式：

• 日志没做轮转，磁盘写满了系统崩了
• 几百路摄像头同时推流，带宽直接打满
• 甲方机房突然断电，数据库没做持久化全丢了
• 一个码流参数没调对，几百路画面同时卡顿

这些经验，在我用Vibe Coding的时候变成了一种”本能”——AI每出一段代码，我的脑子里就自动开始跑”现场部署模拟”。

错误处理够不够？日志打了没有？并发撑不撑得住？网络断了会怎样？这些问题我不需要刻意去想，它们会自动冒出来——因为这些都是我在四十度天花板上穿线、在没暖气的监控室里调设备时，用汗水换来的条件反射。

年轻人看代码看的是”语法对不对”，我看代码看的是”上线后会不会炸”。

所以，在Vibe Coding时代：

• 产品思维解决的是”输入端”的问题——怎么把需求喂准
• 现场经验解决的是”输出端”的问题——怎么判断代码靠不靠谱

两个能力加在一起，你就从”让AI帮你写代码”升级成了”指挥AI做工程”。

05 我的Vibe Coding工作流：产品经理 + 现场老兵 + AI

讲了这么多理念，来点实操的。我现在用Codex做开发，基本上是这么个流程：

第一步：用产品思维拆需求（10~15分钟）

在打开Codex之前，我会先用产品经理的方式把需求拆清楚。不是”做一个XX功能”这种笼统的描述，而是一份迷你PRD：

• 用户是谁？ 给谁用的，使用场景是什么
• 核心流程是什么？ 输入 → 处理 → 输出
• 边界情况有哪些？ 如果用户输入了空的呢？如果数据量有十万条呢？
• 哪些不做？ 这个很关键——告诉AI你不要什么，跟告诉它你要什么一样重要

这一步就是产品思维的核心价值。 你在这里多花10分钟拆需求，后面能省两个小时改代码。

第二步：喂给Codex，让它出第一版

把拆好的需求喂给Codex，让它生成代码。第一版我不期望完美，只看方向对不对、架构合不合理。

第三步：用现场经验做Code Review

这一步是我跟年轻人最大的差距。我Review AI代码的时候，脑子里跑的是现场部署的checklist：

• ✅ 异常处理够不够？——想起那次日志把磁盘写满系统挂了
• ✅ 并发扛不扛得住？——想起几百路摄像头同时推流网络崩了
• ✅ 数据丢了能不能恢复？——想起甲方机房断电数据全没了
• ✅ 用户会不会误操作？——想起那个”一键全选”按钮引发的投诉

发现问题就告诉AI：”这里有个问题，XXX场景没考虑到”，让它迭代。通常两三轮就到位了。

第四步：人工精修最后20%

代码规范、性能优化、跟现有系统的对接——这些AI做不好的，我自己来。

整体下来，效率提升了3~5倍。 不是因为AI多厉害，而是因为产品思维帮我把AI的”输入”做到了最精确，现场经验帮我把AI的”输出”审核到了最严格。两头一夹，AI的”有效产出”就被最大化了。

06 几个真实的感悟

用了这么久，有几个感悟想分享：

“写代码”这件事正在被重新定义

以前”会写代码”是程序员的核心能力。以后，”会用AI写代码”才是。这就好比——以前会手算是本事，后来会用计算器是本事，再后来会用Excel是本事。工具在变，但解决问题的思维没变。

不要全信AI，也不要不信AI

AI写的代码不能无脑用，需要你有判断力。但如果你完全不用AI——那你就是在2026年坚持用烽火台传信的人。

35+程序员的新护城河

以前我的护城河是”现场经验 + 产品思维 + 持续学习”。现在这个护城河反而更深了——因为AI把”写代码”这件事的门槛拉低了，但同时把”想清楚需求”和”判断代码靠不靠谱”的价值拉高了。

我的产品思维，通过Prompt变成了AI能理解的精准需求。我的现场经验，变成了AI代码的质量检验标准。人和AI不是替代关系——是我的经验在指挥AI，AI在放大我的经验。

真正会被淘汰的是什么人？

不是35+的程序员，不是非科班的程序员。是”只会写代码，不会想问题”的程序员。

如果你的全部价值就是”把需求翻译成代码”——那AI确实在替代你。但如果你的价值是”想清楚需求是什么、代码上线后会发生什么”——那AI只会让你更强。

以前是”能写代码”值钱。以后是”能定义问题”值钱。

07 写在最后

39岁，非科班，双非三本，从工地拉线到算法组长。

现在我每天的工作是——用自然语言告诉AI我想要什么，然后审查它给我写的代码。

如果十年前有人告诉我，未来写代码会变成这样，我一定觉得他在说梦话。但它就是发生了。

而且说实话——我觉得这是Coding有史以来最好的时代。

为什么？因为在这个时代，决定你价值的不再是你能写多少行代码，而是你能定义什么问题、你能判断什么风险。 产品思维和现场经验——这些你花了十几年才练出来的东西，AI一行代码也学不会。

小学在小霸王上写代码，靠的是好奇心。大学自学ASP做毕业设计，靠的是折腾劲儿。做产品经理写PRD，练的是需求拆解的能力。在监控现场穿线踩坑，练的是工程落地的直觉。三十多岁转码，靠的是不服输。

现在39岁用Codex做Vibe Coding——靠的是把以上所有能力打包，变成AI的”总指挥”。

工具一直在变，但我一直在用——而且每一段看似”弯路”的经历，最后都变成了指挥AI的素材。

35岁不是deprecated，是LTS版本——Long Term Support，带着十年产品思维和现场经验的长期支持版。

如果你也是35+的程序员，如果你也有做过产品、跑过现场、踩过坑的经历——恭喜你，Vibe Coding时代，这些才是最值钱的能力。拿起AI，让它成为你经验的放大器。

欢迎关注「码农不惑」，一个39岁一线程序员的真实记录。下一篇，我们聊聊——AI时代，35+程序员应该学什么、怎么学。