目录

         一、代码开始批发，别再靠手速证明身价

二、真正拉开差距的，是你能不能判断AI在胡扯

三、别忙着证明自己像大神，先留下大神也挑不出毛病的证据

---

一、代码开始批发，别再靠手速证明身价

        以前，程序员证明自己牛逼，常靠三件套：代码写得快、框架背得熟、凌晨三点还在线。如今，Agent——能读项目、改文件、跑命令的AI助手——进场了：你还在纠结变量名，它已经生成三个版本，顺手附赠一份语气像诺贝尔获奖感言的说明。

        最扎心的变化是：过去需要练三年的熟练活，现在可能成了工具的默认功能。于是，初级开发担心没饭吃，资深开发担心经验贬值，技术负责人担心老板看完演示，就把下季度排期压成下周五。但先别急着转行卖烤肠，烤肠摊也讲选址、供应链和复购，照样不是会开火就能赚钱。软件同理，敲出代码只是中间环节。

        Stack Overflow的2025年调查显示，面对AI工具输出的准确性，46%的受访开发者表示不信任，信任的占33%；“答案差一点才对”也是突出痛点。注意，这不等于“AI代码有46%是错的”，而是大家确实不敢闭眼签收。这组数据最值得注意的，是信任与不信任之间的落差：工具已经能帮忙，大家却还不敢放心交卷。

        该题有效回答33,244份；图中“不太信任”26.1%、“非常不信任”19.6%，合计45.7%，报告概述取整为46%。这是受访者态度，不是代码错误率。原图未改动，保留来源和数据许可标注。这张图最值得注意的，是信任与不信任之间的落差：工具已经能帮忙，大家却还不敢放心交卷。对程序员来说，机会就在这段距离里。你能核对业务规则、识别隐藏错误、说明代码为什么可靠，就能为团队减少不确定性。别人负责一键生成，你负责避免一键出事。

        对程序员来说，机会就在这段距离里。你能核对业务规则、识别隐藏错误、说明代码为什么可靠，就能为团队减少不确定性。别人负责一键生成，你负责避免一键出事。Karpathy在X上介绍“vibe coding”时，也把那种几乎不看代码、跟着感觉生成的玩法，放在一次性周末项目的语境里。能拼出一个演示，和能维护一个收钱、管数据、不能随便宕机的系统，中间隔着的，往往是几个周末和一头秀发。     

        眼下不少程序员真正的困境，是把“熟悉工具”当成了“解决问题”：简历写着精通八个框架，被问到为什么用户总在付款前退出，却只能回答“接口返回200”。当代码开始批发，你得证明自己知道该生产什么，以及它到底有没有用。

二、真正拉开差距的，是你能不能判断AI在胡扯

        有人以为，新竞争力就是提示词写得长、Agent开得多。照这个逻辑，包工头的核心技术应该是微信群人数。

        真正稀缺的是判断力：需求到底是什么，方案值不值得，结果能不能信。老板说“做个智能客服”，普通执行者立刻接模型；更成熟的工程师先问：咨询主要是哪几类？用户卡在哪里？答错退款规则谁处理？有时最好的方案，是把订单查询做好，再把帮助文档写成人话。DORA的2025年研究把AI概括为组织能力的“放大器”：已有的优势和问题，都可能被放大。

        换句话说，流程清楚的团队可能跑得更快，需求混乱的团队也可能更快地产生一大堆需要返工的东西。Simon Willison给AI辅助编程提出过一条黄金法则，大意是：不要提交自己无法向别人解释的代码。这句话适合打印在“全部接受”按钮旁边。

        GitHub官方文档也提醒：“日志不能代替你自己的审查与测试。”Agent展示了执行过程，不等于已经证明结果正确。因为AI最危险的本领之一，是把不确定的答案说得像公司制度。Stack Overflow的同一份调查中，66%的受访者遇到过“几乎正确、但并不完全正确”的AI方案，45.2%遇到过“调试AI生成代码更费时间”的问题。这说透了一种新型加班：代码生成只用五分钟，寻找“差的那一点”花掉两小时。

        两个比例来自多选题，可以重叠，不能相加成总体出错率。它提醒我们，评估效率要把审查和返工算进去。先明确验收条件，再小步修改、及时验证，才可能把生成速度变成交付速度。测试全绿，也可能只是实现和测试一起误解了需求；页面能跑，不代表权限正确；算法离线分数漂亮，不代表上线后不漂移。

        该题有效回答31,476份，为多选题：66%遇到“几乎正确、但并不完全正确”的方案，45.2%遇到“调试AI生成代码更费时间”的问题。原图部分英文标签显示不全，此处补充其中文含义；图像未改动。*

        这图说透了一种新型加班：代码生成只用五分钟，寻找“差的那一点”花掉两小时。两个比例可以重叠，不能相加成总体出错率。它提醒我们，评估效率要把审查和返工算进去。先明确验收条件，再小步修改、及时验证，才可能把生成速度变成交付速度。

        所以，前端要懂体验、可访问性和真实设备表现；后端要懂业务规则、数据一致性与成本；测试要会找反例、设计独立的验收依据；运维要把权限、可观测性和回滚做实；算法工程师要解释数据质量、评估方法与失败边界。技术负责人还得说清楚：哪些步骤能自动化，哪些必须有人拍板。岗位可以不同，能力证明却有共通之处：你能发现什么问题，凭什么作出选择，又用什么证据确认结果。

三、别忙着证明自己像大神，先留下大神也挑不出毛病的证据

        那普通程序员明天该干什么？先挑一个真实、范围可控的问题，把它做成完整案例。比如客服查单麻烦、构建太慢、某页面加载卡顿，让Agent帮你读代码、列方案、做重复劳动，你负责确认目标、审核关键改动、验证效果。给它的任务也要能验收：别只说“帮我优化一下”，而要说清允许改哪里、哪些行为必须保留、达到什么条件才算完成。把大任务拆成可以独立检查的小步，发现方向错了及时停，往往比让五个Agent同时狂奔更省事。把过程留下来：原来的问题是什么，为什么选这个方案，怎么测试，出了错怎么退回，最后节省了多少时间、降低了多少成本。

摘自DORA研究员Dr. Kevin M. Storer的文章

《How gen AI affects the value of development work》原图讨论实际影响、声誉、经济回报、内在价值、工作乐趣五个维度。这是基于10次深度访谈提出的定性框架，不是行业比例统计。

        面试时，“我熟练使用五款Agent”像报菜名；“我把一项人工流程自动化，记录了前后耗时，并验证了异常处理”，才有可讨论的分量。数字必须来自实测，最好交代样本和条件，别让AI顺手把简历优化成科幻小说。

        新人尤其要警惕学习上的空心化：项目越来越完整，自己越来越解释不清。每做完一个功能，关掉助手复述原理，亲手定位一次故障，再改一个它没见过的需求。计算机基础也要继续学：网络、数据库、操作系统这些知识，正是你判断回答靠不靠谱的尺子。尺子都送人了，装修队说墙是直的，你就只能点头。

        资深工程师也别把“我以前踩过坑”当免检证书，要把经验变成团队能复用的约束、评审标准和排障文档。而那些擅长底层、嵌入式、安全或复杂领域的工程师，更不必为了赶时髦全员改行做聊天框；用AI清理重复劳动，再把腾出的时间投入真正难啃的问题。管理者则该算完整的交付账：生成省下的时间，扣掉审查、返工、故障和维护的时间，还剩多少？如果考核只看代码行数，就像餐厅只考核出菜重量，迟早有人端上一盆洗锅水。

        DORA研究员Kevin M. Storer的一篇文章，还基于10次深度访谈，把开发工作的价值拆成五个维度：实际影响、声誉、经济回报、内在价值和工作乐趣。这相当于五本账：工作有没有用、贡献是否被看见、收入如何、是否觉得值得，以及干得开不开心。它提醒程序员，提速未必同步带来涨薪与成就感。记录自己的判断和成果，也向团队说明这些贡献，才能让价值更容易被识别和讨论。        

        当然，工程判断力不会自动兑现为工资，岗位数量、公司预算和分配机制都真实存在；如果组织长期看不见你的贡献，也需要向外展示作品、寻找更匹配的机会。面对变化，更有用的出路是：守住一门专业，学会组织AI干活，再用可靠的成果争取选择权。以后证明你更牛逼的，不是你比Agent多打了多少字，而是同样拿着Agent，你更能把一件重要的事办成。

        毕竟，AI可以替你写周报，但周报里的成绩，最好真的发生过。