刚刚，谷歌的一位狠人公开了自己AI产品开发心得！
今天，谷歌高级AI产品经理 Shubham Saboo 在 X 上分享了一篇“2026年，什么技能最重要》的文章，其中提及了 Shubham 多年以来在谷歌的不少工作经历和所感所思。
“2026 年最优秀的开发者，更像电影导演，而不是程序员。”
Shubham 可以说是一个狂热的 Agent 时代开发者，他运营着一个非常优秀的优秀的开源 LLM 应用仓库 Stars 数高达 93k。
Shubham 在文中表示了，“过去十年里让开发者变得有价值的那些能力，在一次模型代际跃迁中就被彻底商品化了。”
重点是，这次的变化不是渐进式的变化，很多人都还没来得及更新自己的认知模型。
“6个月前我招人的技能标准，现在看来，已经变得毫无价值！”
这次代际变革发生得有多猛？3个月。
从去年11月的 Gemini 3 Pro 发布到上周 Claude Opus 4.6 的推出，短短不到 3 个月的时间，已经足以让改变产品开发范式。
Shubham 如此说道：
我过去一年每天都在构建 Agent，维护 100+ 开源实现的 Awesome LLM Apps 仓库，同时在 Google 做 AI 产品。一个明显的趋势是：价值正在从“实现能力”迁移到“上游能力”。
甚至，这里他指出，有四项原有能力已经被AI商品化了。
从零开始写代码、样板代码和项目脚手架、死记硬背语法和API、根据文档翻译成代码。
这些都已经可以被 AI 或智能体快速搞定。
Shubham 还给出了一个身边的例子。他在一家初创公司当顾问，上周，这家公司，一个实习生的交付速度甚至超过了资深工程师。
那位资深工程师花了三天手写的内容，实习生一个下午就交付了。
并不是实习生更强，而是他把问题定义得足够清晰，然后让 Claude Code 完成剩下的工作。
X 的评论区也有网友表示遇到过类似的情形。现在优秀的开发者基本上只用10%的时间来Coding，70%的主要精力用于拆解问题。
而 2026 年之后，哪些能力才是真正值得培养的呢？他给出了 5 个关键技能项。
1、问题拆解塑性能力：把模糊目标变成可执行的任务。这项能力，区分了“玩一玩 AI”的人，和真正用 AI 做出产品的人。
2、上下文设计能力：差别不在提示词技巧，而在于信息密度、边界条件、成功标准，以及对真实场景的理解。
3、审美能力：也就是近两年来被反复提及的“Taste”。简单理解就是：10 个选项摆在面前时，知道其中哪 9 个不行。
4、智能体编排能力：知道何时用一个智能体，何时用多个，何时串行、何时并行。
5、场景判断力：知道何种不适合使用智能体的判断能力。
最后，Shubham 还给出了培养这五种能力的方法。
下面是小编为大家整理的来自谷歌大佬的“ 2026 关键 Skills 更新指南”。
模型的代际跃迁，
让之前开发者的技能失效了
六个月前，我还会为一些如今在我看来毫无价值的技能招人。不是“没那么重要”。也不是“正在演变”。是毫无价值。
过去十年里让开发者变得有价值的那些能力，在一次模型代际跃迁中被彻底商品化。不是缓慢发生的。不是渐进式的。就在 Gemini 3 Pro 到 Claude Opus 4.6 之间。
但大多数人还没有更新自己的认知模型。与此同时，那些交付速度最快的人，几乎已经不再从零开始写代码。
过去一年，我每天都在构建智能体，维护一个包含100多个开源实现的 Awesome LLM Apps 仓库，也在 Google 交付 AI 产品。
我亲眼看到，真正有价值的技能正在实时迁移。
哪些能力被商品化了？
有4项开发技能，已经被智能体 cover 掉了。
其一，从零开始写代码。智能体写得更快，Bug 还更少。
其二，样板代码和项目脚手架。一句提示词，直接生成。
其三，死记硬背语法和 API。超长上下文窗口已经解决了这个问题。
其四，把规格说明翻译成代码。现在，规格本身就是代码。
这些事，智能体现在都能做；未必完美。也仍然需要监督；但已经足够快。快到瓶颈彻底上移。
上周，在我担任顾问的一家初创公司里，一个实习生的交付速度超过了一位资深开发者。
并不是实习生更强，而是他把问题定义得足够清晰，然后让 Claude Code 完成剩下的工作。
那位资深工程师花了三天手写的内容，实习生一个下午就交付了。
很明显，现在这已经不是个例了。这是一种新基线的信号。这些能力之所以曾经重要，是因为实现本身很难。它们需要多年训练。它们支撑了六位数年薪。
但实现已经不再是瓶颈。而整个行业，还在围绕旧瓶颈优化。价值，已经迁移到了五种新技能之上。
所有真正高效使用智能体构建产品的人，都已经在不自觉地培养这些能力。
无论他们是否意识到这一点。
技能一：问题塑形（Problem Shaping）
把模糊目标变成可执行的任务。这项能力，区分了“玩一玩 AI”的人，和真正用 AI 做出产品的人。
核心是拆解能力。
“帮我做一个仪表盘”不是任务，只是一个愿望。
问题塑形会把它拆成十二个具体、可测试的子任务，每个都有明确的成功标准。
这个仪表盘展示什么数据？
它帮助做什么决策？
用户在前三秒必须理解什么？
当你把一个模糊目标拆成精确子问题时，智能体的执行水平会完全不同。每个子问题都有清晰输入、清晰输出、清晰成功标准。智能体不需要猜测你的意图。
就比如那个由 Claude Code 和 Opus 4.6 构建的 C 编译器的例子。
一个人负责问题塑形、十六个智能体负责执行、最终产出是 10 万行可运行的 Rust 代码。
那个人没有写代码。但他把问题拆解到足够精确，让智能体仅凭拆解结构就能完成一个编译器。
ps：Anthropic 的 Safeguards 团队研究员 Nicholas Carlini 特别写了一篇博客
，详细拆解了他们是内部如何指挥“智能体团队”造出来这个 C 编译器的。
Anthropic 在 2 月 6 日发布工程博客时提到：他们让 Opus 4.6 通过智能体团队构建一个 C 编译器，然后基本“放手”。两周后，它能在 Linux 内核上运行。
真正的杠杆不在写代码。而在于，把问题拆到智能体几乎不会出错的程度。
问题塑形之所以成为最高价值技能，并不是因为它是新能力。相反，产品经理和资深工程师一直在做这件事。
变化在于：
当“问题定义得好”与“产品真正上线”之间的时间差压缩到几小时的情况下，问题定义的质量，就会决定一切。
技能二：上下文设计（Context Curation）
智能体产出的质量，与你提供的上下文质量直接成正比。
看看差的上下文：
Build me a customer support agent.
再看看好的上下文：
Target user: SaaS customers who are frustrated and considering canceling.
They've already tried the help docs. They're messaging because docs failed them.
Tone: Empathetic but efficient. Don't over-apologize. Don't be robotic.
Here are 3 real tickets that got 5-star ratings: [examples]
Here are 2 that got complaints: [examples]
Edge cases requiring human handoff:
- Billing disputes over $500
- Account security concerns
- Legal or compliance questions
Success metric: Resolution without escalation in under 4 messages.
差别不在提示词技巧。差别在于信息密度、边界条件、成功标准，以及对真实场景的理解。
“上下文设计”的本质，是选择什么信息进入模型的思考空间。给错信息，模型会稳定地输出错误方向；给对信息，它会稳定地产生接近产品级的结果。
未来的高价值人才，不再是“会不会写代码”。而是：你是否知道什么信息值得放进模型。以及，什么信息必须排除在外。
就如同上面两个提示词，同一个模型，同一个任务。写得差的提示词只会得到一个通用客服机器人；写得好的提示词，则会得到一个仿佛已经在你产品里训练了几个月的智能体。
我认识的高效构建者，把更多时间花在写上下文文档，而不是写代码。他们维护 CLAUDE.md、.cursor/rules、GEMINI.md 这类文件，让它们在每次会话中自动加载。智能体一开始就理解他们的产品世界观。
当我为 Awesome LLM Apps 仓库构建新的智能体时，从不从零开始。我的上下文文档已经定义了什么是“好”，应该采用什么模式，要避免哪些坑。第一版输出就达到 90%，而不是 50%。
这 40% 的差距，决定了“技术上能运行”和“真正可以发布”的区别。它完全来自上下文质量，与编码能力无关。
技能三：审美（Taste）
审美，是在东西尚未存在之前，就知道该做什么。是在十个选项摆在面前时，知道其中九个不行。
上周我让 Antigravity 为 Awesome LLM Apps 仓库做一个新智能体：一个 AI 讨价还价模拟器。两个智能体围绕二手车交易对弈，买家与卖家，各自拥有鲜明人格，并通过 AG-UI 实时直播。
第一版运行得很完美。代码干净，没有报错。双方你来我往。技术上完整。但我三十秒就否了。
界面只是一个普通聊天窗口。谈判过程像在看日志文件。没有人格张力，没有情绪起伏，没有那种“Shark Steve 坚守底线，对抗 Cool-Hand Casey 假装要走人”的戏剧瞬间。它作为软件是成立的。作为体验是失败的。
这个仓库有 9.3 万+ 星。
我看过无数开发者如何体验智能体 Demo。他们在十分钟内决定是否值得花时间。一个能运行的智能体远远不够。它必须让人愿意展示给别人看。
智能体能构建任何你描述的东西。它无法判断什么值得被描述。
智能体优化的是“正确性”。我优化的是“会不会有人克隆这个项目”。
这就是审美。这可不是抽象的设计感，而是长期积累的判断力，知道什么会让人点星，什么会让人直接关掉页面。
当智能体可以快速、批量地产出结果时，能判断哪个版本真正“落地”的人，才是房间里最有价值的人。
这比听起来难培养。审美无法通过读书获得。它来自反复发布、观察真实用户行为，以及对“能用”和“值得用”之间差距的敏感度。
一个简单练习：回顾你最近五个智能体产出。逐个写下你会改什么，以及为什么。那个“为什么”，就是审美正在形成。
技能四：智能体编排（Agent Orchestration）
知道什么时候用一个智能体，什么时候用多个。
什么时候并行，什么时候串行。
什么时候加护栏，什么时候放手。
什么时候亲自调试，什么时候让智能体自己排错。
最后这一点，比很多人想象中更关键。智能体确实擅长追踪错误。但它也可能陷入循环，反复尝试同一个失败路径。
知道何时放手让它调试，何时介入，是一种真正的能力。盲目信任和全部手动，代价一样昂贵。
三种核心模式：
1. 串行流水线
Agent A 完成任务后，把输出交给 Agent B。
这种方式简单，可预测。适用于步骤之间存在依赖关系的场景。
例如：研究智能体收集数据 → 分析智能体解读 → 写作智能体生成报告。
2. 协调者 + 专家团队
一个主智能体负责分派任务，并整合结果。
适用于需要质量控制的复杂任务。协调者会在专家偏离方向时重新提示，并最终合并输出。
这也是我现在构建复杂工作流的主要方式。
3. 并行执行 + 合并
多个智能体同时处理独立任务，最后由一个智能体整合。
适用于子任务之间无依赖关系的场景。市场调研、竞品分析、用户访谈可以并行进行。最后统一汇总。过去需要一个下午的串行工作，现在只需几分钟。
整体来说，大多数人默认选择串行流程，因为那样更“安全”。但知道什么时候并行，什么时候引入协调者，决定了你的工作流是五分钟完成，还是拖到一小时。
2026 年最优秀的开发者，更像电影导演，而不是程序员。
他们布置场景，挑选演员，知道什么时候喊停。
他们不写每一句台词。
他们塑造整场演出。
这只能通过不断构建来学会。读再多文章也不够。
技能五：知道什么时候不要用智能体（判断力）
在一个讨论智能体时代技能的文章里谈“不用智能体”，听起来有点矛盾。
但这是个真实陷阱。
当 Claude Code 可以构建你描述的任何东西时，你会开始把所有事情都交给它。
我也会下意识对一些根本不需要智能体的问题调用智能体：
一个小小的 UI 调整。
一个配置修改。
一次简单重构。
有时候，加载上下文、设计提示词、评估输出的成本，已经超过任务本身的价值。
不是每个问题都需要智能体。
有些问题只需要一个快速模型和清晰提示。
需要重新格式化 JSON？丢给 Gemini 3 Flash。
十个文件里的文案替换？轻量模型几秒搞定。
一个你已经完全理解的 Bug？自己改比向智能体解释更快。
真正的能力，是让工具和问题匹配。
模糊、多步骤、需要探索解空间的问题，用智能体。
简单、定义清晰、答案已知的任务，用快速模型。
那些你打字比描述还快的事情，用自己的手。
最高效的人，并不是凡事都用智能体。
他们在合适层级调用合适工具。
问题复杂，用智能体。问题简单，用模型。问题显而易见，用键盘。
如何培养这些能力
这些能力无法通过阅读获得。它们来自实践。
一、培养审美：
回顾最近五个智能体输出。写下你会改什么，以及为什么。
二、优化上下文：
为当前项目写一个 CLAUDE.md。哪怕只花 30 分钟。
三、练习问题塑形：
面对下一次模糊需求，在提示之前，先拆成 10 个子任务。
四、练习编排能力：
把一个串行工作流拿出来，看看哪些步骤可以并行。
五、校准工具判断：
连续一周记录：哪些任务你用了智能体，而其实一个简单提示就够。选一个。今天就做。
直觉的形成，比你想象得更快。
到底还剩下什么？
过去二十年里重要的技能之所以重要，是因为实现本身很难。而现在，实现已经不再困难。真正留下来的，是所有更上游的能力。
审美、上下文策展、问题拆解、智能体编排，以及判断力——知道什么时候该用智能体，什么时候一个简单模型提示就够，什么时候直接自己动手。
这些能力并非全新。优秀的工程师和产品经理一直具备它们。只是过去，它们被大量实现层的工作掩盖。
现在，那些实现负担被移除。这些能力被彻底暴露出来。它们成了工作的全部。
打开你最近一个项目。问问自己：你花更多时间在写代码，还是在塑造问题？
如果答案是写代码，那你仍在用旧时代的技能结构。新的方式，从一份上下文文档和清晰的问题定义开始。代码，会自己出现。
https://x.com/Saboo_Shubham_/status/2021416352637125110
ps：春节将近，小编特意为大家准备可爱的2026马年定制版的“51CTO技术栈”红包封面，感谢大家一直以来对我们的关注！点击就可以领取。
——好文推荐——
阿里蔡崇信：AI不应是国与国的竞争！自曝阿里一开始并没有清晰的AI技术栈蓝图！曝跟马云创办阿里经历：种子轮路演全军覆没，回应阿里味
菲尔兹奖得主陶哲轩有了新身份！下场AI for Science！最新专访：AI融入科研有很多错误路径，学术界不能只是等待！AI还谈不上真正的合著者
Claude Opus4.6内部实用经验公开！16个智能体并行跑2周，中间几乎无人插手！曝 Vibe Coding过时了，以后是agent团队自主完成软件开发！
