Arsh Goyal断言：编写代码已成商品。一位曾经放弃的工程师，把「工程师思维」的全部写出来

昨天，我在写一篇关于安全的文章。

用vibe coding写出的代码有45%存在安全漏洞。Cisco为此推出了Project CodeGuard。写下”大公司开始伸出援手了”这句话时，我心里有一丝宽慰。

第二天早上，一个新的问题冒了出来。

修好安全漏洞之后，然后呢？在”能写代码”和”能保护代码”之后，下一个问题难道不是”该做什么”吗？就在这个时候，我读到了Arsh Goyal的一句话，从那之后就一直在我脑子里转。

---

编写代码已成商品

印度籍工程师兼内容创作者Arsh Goyal在开发者大会DevSparks Pune上这样直接说道：

“编写代码正在商品化。工程学是另一个维度。”

“商品”是指失去稀缺性的东西——就像铁和小麦，任何人都能获得。编写代码的商品化，意味着”会写代码的人很稀缺”这一前提正在崩塌。

第一次读到这句话时，我说实话——有些不安。

通过vibe coding，我终于到达了能写代码的状态。多次有过”借到了顶尖工程师神力”的感觉。如果这种能力正在成为商品——也就是任何人都能拥有——那我的”我终于会了”又算什么？

这个问题的方向在大约30分钟后发生了转变。

商品化的是”编写代码这件事”本身。随着AI的普及，代码生成正在快速自动化。GitHub Copilot的自动补全越来越精准，Claude Code能在几分钟内输出复杂实现，Cursor提出重构建议。vibe coder数量增加这一事实本身，就印证了商品化正在发生。

那么，当”编写代码”本身商品化之后，什么东西的价值会上升？Goyal所说的”另一个维度”的工程学，具体指什么？

为了回应这个问题，先从外部数据看起。

---

Deloitte 2026年报告的观察

Deloitte 2026 Global Software Industry Outlook每年对软件行业的结构变化进行分析。

整个行业都能观察到同样的趋势。

随着代码生成AI的普及，对工程师的技能要求正在从”实现”向”判断”转移。相比”写什么、怎么写”，“该做什么、为什么”的比重在增加——这是Deloitte分析所指向的大方向。

同样的模式在其他地方也得到了验证。

GitHub每年发布的Octoverse调查显示，随着AI编程工具的普及，“花在设计、评审、测试上的时间增加了”的回答呈上升趋势。Cursor也在官方博客中多次指出，“决定成果差异的是你给出怎样的指令，而不是自动补全的精度”。

模式是一致的。

“编写”被自动化。“判断”留下来。编程和工程学之间的边界线，正在以极快的速度变得可见。

补充一点关于Deloitte所说的”向高阶技能转移”的含义：评估多种技术选项并选出最优的能力；在容忍需求模糊的同时确定优先级的能力；在业务目标和系统约束之间架桥的能力。这些都是AI所不擅长的领域。AI擅长在给定约束条件内优化代码，但不擅长思考”应该设置哪些约束条件”。

昨天写的Cisco Project CodeGuard也在同一张地图上。安全问题光靠”能写代码”无法解决，需要判断”保护什么、优先处理哪些风险”。商品化的是编程，工程学的判断层不会被自动化——这一结构，通过各公司的动向不断被可视化。

---

编程与工程师思维的区别

听起来相似，但实际上差别很大。

编程是将给定的需求转化为代码的行为。输入进来，输出出去。这是AI最擅长的领域，已经以高精度自动化推进中。

工程师思维是追问”应该做什么”的能力。是定义需求本身、拥有设计判断基准、并能验证所做之物是否真正创造价值的力量。

用具体例子来整理。

“想做一个能自动回复Slack消息的机器人”——这是编程的输入。交给AI，能用的东西就出来了。30分钟完成。

“加入这个机器人，团队的回复成本真的会下降吗？还是反而会增加噪音？与其这样，是不是先减少这个Slack频道的消息量更重要？“——这是工程师思维的问题。只有拥有上下文的人才能提出。

我在自制工作工具时，花时间最多的是后者。先思考”这个工具加入之后，谁的哪个业务会如何变化”。有了答案之后，再请AI写代码。把这个顺序倒过来，就会做出”能跑但没人用的东西”。实际上我做过几个。

作为CS出身，听了无数次”不明白为什么是这样运作的”之后，我可以说：决定工具价值的，是问题的质量，而不是代码的质量。

有一件让我深刻感受到这一点的事。

以前，我曾尝试自动化团队的报告生成——一个从电子表格提取每周KPI并发布到Slack的脚本，和AI花了2小时完成。完美运行。第二周，没有人再打开那个Slack通知。

问题定义有误。问题不是”把KPI推送到Slack”，而是”建立一个让所有人把每周KPI确认当作自己的事的机制”。自动化了就会有人看——这个前提崩溃了。在写代码之前，我没有追问”这个通知到达时，成员会做什么”。

---

工程师思维的3个维度

不想以抽象结尾。把我所说的”工程师思维”从实际经验出发，分解为3个部分。

维度1：精确定义问题

在写代码之前，能否用一行话说清”问题是什么”？这是第一个维度。

常见的输入是”想要一个仪表盘”。但真正的问题可能是”每天早上花30分钟手动确认多个表格”。问题定义变了，解决方案也变了。有时候，每天早上自动向Slack发布汇总的脚本，比仪表盘更快解决问题。

我养成了在写AI提示词之前，先”用一行话写下想解决的问题”的习惯。有了这一行，就有了评估AI生成代码的基准。从”能跑了”变成了”原来的问题解决了吗”。

这个问题陈述也能提升提示词质量。“我想消除每天早上手动核对3张表格的30分钟作业”比”帮我做个仪表盘”能得到精度更高的代码。定义问题这件事本身，就在提升与AI协作的效率。

我使用的模板是：“[谁]在[什么]上花了[多久]。我想把它变成[目标状态]。“比如：“销售担当每周花2小时做报告。我想把它控制在15分钟以内。“把这句话放在提示词开头，AI输出的方向会大幅收窄。

维度2：判断权衡

设计中必然有权衡。速度与准确性、简洁性与扩展性、当前成本与未来灵活性——取一样，必然放弃一样。

AI能仔细说明权衡的”两面”。“告诉我A和B的权衡”这样的问题，AI会给出高精度的回答。但”选哪个”的判断，属于拥有现场上下文的人。

“这项业务中，最重要的是速度还是准确性？“——这个问题是了解现场的人的。

我曾用vibe coding花3小时做了一个工具，后来想换个设计重做。问题在于把设计判断推后了。正因为AI移动得快，所以更需要有意识地把设计判断提前。重做的成本，在设计阶段的30分钟就能收回。

出现分叉时，我不会立即选择其中一个。我先请AI”列出A和B的权衡”，然后自己判断。仅仅把这个两步流程变成习惯，我的设计意识就改变了。

维度3：评估所做之物

代码跑起来的那一刻令人兴奋。“这真的跑起来了！“这种感觉无论经历多少次都是最棒的。

但”能跑”和”有价值”是两回事。

“Slack机器人能回复了”是能跑的状态。“每周减少了3小时的回复成本”是有价值的状态。能衡量这个差距的能力，就是第三个维度。

我意识到的做法是，“2周后再用一次”自己做的东西。在发布后的感动冷却的状态下，确认”现在还在用吗""哪里用着不顺手""最初的问题解决了吗”这3点。

认真做这个循环，会有意外发现。觉得是”神器”的东西，2周后打开一看，发现自己根本没在用。追究原因，不是”问题定义有误”就是”设计判断偏差”。通过运转评估循环，下一次的问题定义精度会提升。

这3个维度不是独立的，而是循环的。问题定义越精确，设计判断就越犀利；价值评估的结果会反馈到下一次问题定义中。有意识地转动这个循环，才能让vibe coding从”批量产出能跑的东西”变成”创造价值的行为”。

---

CS出身×挫败工程师才懂的事

正如开头所写，我曾经放弃了写代码。

在大型项目中遇到的工程师们，和我的差距是清晰得近乎爽快的。架构的优美、性能调优的直觉、代码的精炼程度——那里确实有我够不到的地方。于是我把职业重心转移到了CS。内容营销的CMS导入支持、媒体增长、管理——离开代码的3年。

那时觉得够不到的，是”编程”的部分。

现在回看，我在CS里积累了另一种能力。

不断追问”这个功能是为谁设计的”的日子。面对数字追问”用户为什么在这里流失”的时间。每天追问”这篇内容读者真的能行动起来吗”的3年。听了无数次”不明白为什么是这样运作的”的经历——这些全部都是工程师思维的训练。没有代码。

现在通过vibe coding能写代码了，那段训练正在被直接使用。

当追问”做什么""为谁做""是否起作用”的能力，与AI的代码生成结合在一起时，第一次有了连接的感觉。Arsh Goyal说”工程学是另一个维度”所指向的能力，我在离开代码的那3年里，走了另一条路在积累。

挫败后转向CS的选择，不是弯路。

那是积累工程师思维核心的时间——我现在这样认为。这种解读也许只是自我安慰。但每次通过vibe coding做工具时，CS时代不断追问的习惯都在支撑着我的设计判断。不仅仅是”能写代码了”，而是在”知道该做什么”的状态下在做。这个差距，体现在实际的输出中。

如果商品化的是编程，那么在编程之外度过的时间就是资产。过去的挫败成为武器的时代来了——至少对我来说，是这样感受的。

再补充一点。

我有时会想，在那个大型项目中遇到的顶尖工程师们，现在过得怎样。他们的编程技术无疑是真材实料。但在AI写代码的时代，一定有越来越多的场景，仅凭那种技术是不够的。拥有编程能力但没有工程师思维的工程师，将面临来自AI的替代压力。反过来，拥有工程师思维的工程师，能把AI当作工具来用，提升自身价值。商品化的浪潮不会均等地吞噬所有人。

---

vibe coder现在就能开始的3个实践

工程师思维是可以训练的。不是困难的理论，而是习惯的问题。

实践1：在提示词之前先写”问题一行”

在让AI写代码之前，在纸上或笔记里只写一行。“我想解决的问题是这个。”

不是”做个仪表盘”，而是”消除每天早上30分钟的手动汇总”。写下问题，就有了评估生成代码的基准。从”跑起来了”变成了”问题解决了吗”。

开始这个习惯之后，发给AI的提示词质量提升了。问题陈述越具体，代码精度越高。提出问题这件事本身，兼具了提示词工程的作用。

实践2：提出2个设计选项后再做选择

出现技术分叉时，不要立即选择其中一个。先让AI”列出A和B的权衡”，然后自己判断。

能说出”选择的理由”，事后就能回顾设计。不知道”当时为什么那样做”，重做时就会重蹈覆辙。仅仅养成这个两步流程的习惯，设计意识就会改变。

实践3：2周后再使用一次

不是完成次日，而是2周后自己再使用一次。只确认3点：“现在还在用吗""哪里不顺手""问题解决了吗”。

运转这个循环一次，下一次问题定义的精度就会提升。“能跑的东西”和”被使用的东西”的差距，会变成体感而不只是数字。

这3个实践，都不难。不难，但不有意识地去做就不会做——因为”交给AI、代码出来了”就停下，是最自然的流程。训练工程师思维，意味着在那个”自然流程”的前后，有意识地插入步骤，形成习惯。

---

结语

Arsh Goyal的话所指向的未来，从某种意义上说很简单。

能写代码，成为入场券。随着AI的普及，“会写代码的人很稀缺”的时代正在走向终结。

在此之后有价值的，是工程师思维。能够定义问题、判断设计、评估价值的能力。这3个维度，不会被AI自动化。

挫败后转向CS的3年，我在不知不觉中走着通往工程师思维的另一条路。现在通过vibe coding到达了”能写代码”的状态，那段积累终于有了用武之地。

“能写代码”成了入场费。

下一个问题是：做什么、为谁做、如何设计来做。持续持有并追问这个问题的人，才能走在商品化的前面——我是这样认为的。

从代码的复归，不是在”能写代码了”的时候结束的。“在拥有工程师思维的同时能写代码”，才是真正的终点——现在才明白。vibe coding是入口。穿过入口，还有一条很长的路。我想和读到这篇文章的每一个人，一起走下去。

---

参考资料

• Arsh Goyal（印度籍工程师兼内容创作者）——在DevSparks Pune 2026上的发言（综合多家媒体报道）
• Deloitte 2026 Global Software Industry Outlook
• Claude Code怎么用，不再迷茫的指南（NAGI）
• AI让不会写代码也没关系的时代来了（NAGI）