Code is cheap, show me the talk! —— 当代码不再稀缺，什么才真正重要？
"Talk is cheap. Show me the code."
2000年，Linus Torvalds在Linux内核邮件列表中敲下这句话，干脆利落地终结了一场冗长的技术争论。此后二十余年，它被奉为程序员的信条——代码即正义，能跑的程序胜过一切雄辩。
但如今，这条铁律正在被现实击穿。
打开Cursor，唤醒Claude Code，或向任何前沿大模型描述需求——几秒钟后，数百行结构完整、注释齐全、甚至附带单元测试的代码便铺满屏幕。语法壁垒被连根铲平，代码生成成本正趋近于零。
当AI已能替你写出99%的代码，一个新命题浮出水面：
Code is cheap, show me the talk! ——代码越来越廉价，真正重要的，是你的"表达"。
一、Code为什么变"Cheap"了？
回想过去，程序员的日常有多少精力耗在"搬砖"上：
- Webpack配置文件怎么写？
- React的
useEffect清理函数是什么写法？ - 如何用正则匹配邮箱？
- 怎么把JSON映射成嵌套实体类？
这些曾需翻文档、查StackOverflow、甚至死记硬背的"手艺活"，如今不过是一句Prompt的事。AI像个精力无限、手册全知的高级打字员——你开口，它动手，不知疲倦。
当"写代码"本身不再是瓶颈，纯编码能力便从稀缺资源降维成了基础设施。
今天不会有人把"打字速度120字/分钟"写进简历。未来，"精通Java语法"恐怕也将沦为同等地位。
但请别误读——不是代码基础不再重要，而是它从"入场券"变成了"地基"。当AI产出99%的代码时，剩下1%的性能调优、安全修复、底层疑难排错，仍需你对语言机制的深刻理解。地基不可或缺，但光靠地基，建不起万丈高楼。
二、重新定义"Talk"：从空谈走向核心生产力
如果Code贬值了，新的价值锚点在哪？
答案是Talk。
但请注意——这里的Talk，不是会议室里的夸夸其谈，也不是脱离落地能力的PPT造火箭。在AI时代，Talk意味着精准的沟通、深刻的拆解、宏观的架构，以及敏锐的产品直觉。
1. Talk to the Machine —— 与AI对话的能力
AI是极其强大却也极其"盲目"的执行者。
你给它模糊的需求，它还你似是而非的垃圾代码；你给它精准的Prompt，它交付的方案甚至比手写更优雅。差距不在AI，而在驾驭AI的人。
真正的高手，能用精准的自然语言将复杂业务逻辑拆解为AI可执行的步骤——你不必亲自写for循环，但必须向AI讲清楚数据流转的边界、异常处理的策略，以及性能的约束条件。
但这还不是最本质的那一层。AI拥有全人类的知识库，但它没有意图（Intent）。它不知道我们要去哪，只是擅长铺路。所以，你不再是铺路的苦工，而是那个指着远方说"我们要去那里"的掌舵人。计算思维的本质，正在从"如何实现"，彻底转向"如何定义"。
2. Talk to the Business —— 与业务对话的能力
AI懂所有编程语言，却不懂你的用户。
它不知道为什么按钮放左边转化率更高；不知道当前商业模式下，该优先保证响应速度还是压缩服务器成本；更不知道功能上线后，运营团队是否会被客诉淹没。
代码解决的是"怎么做"，而Talk解决的是"做什么"和"为什么做"。
未来的顶尖开发者，必然是"产品型工程师（Product Engineer）"——能听懂客户的弦外之音，能将模糊的商业愿景翻译成精确的技术需求。这种从人话到机器的翻译能力，恰恰是AI最难复制的人类技能。
3. Talk to the System —— 与系统对话的能力（架构设计）
AI可以帮你写出完美的函数，甚至搭起微服务。但让它从零开始架构一个高可用、可扩展、契合企业现状的分布式系统？它做不到。
原因很简单：架构决策的本质不是编码，而是取舍。
CAP三选二怎么选？服务边界画在哪？同步还是异步？强一致还是最终一致？这些判断依赖对业务场景的深刻理解、对技术生态的全局把控，以及对未来演进方向的预判——全都远超当前AI的能力边界。
把一块块砖头（AI生成的代码片段）砌成摩天大楼，依然需要人类架构师手中的蓝图。AI砌得了墙，但画不出蓝图——因为蓝图的每一笔，都是一个取舍。
三、Talk的载体之辩：Prompt还是Doc？
如果你已经被说服Talk是新的核心竞争力，那你大概率听过一个流行的答案——Prompt。"Prompt Engineering"已被包装成一门新学科，"未来最值钱的能力就是写好提示词"几乎成了AI时代的政治正确。
我不同意。
回想你日常与AI的交互：绝大多数Prompt是即兴的、碎片的、用完即弃的。你在对话框里敲下一段提示词，AI吐出结果，这段Prompt便完成了使命——你不会回头翻阅上周写过的某条Prompt，更不会把它当作项目的技术资产来归档。
Prompt是草稿纸，不是答卷。
当然，我听过反对意见：优秀的Prompt也可以被模板化、版本化，沉淀为团队的提示词库——Cursor Rules、Copilot指令集，不都是Prompt资产化的实践吗？
没错。但请注意一个有趣的事实：当一条Prompt重要到值得被沉淀、复用、被团队共同维护时，它本质上已经变成了一种文档。 你给它加了版本号，写了使用说明，规定了适用场景——这不就是文档化吗？Prompt的终点，恰恰是Doc。
真正承载"Talk"的载体，是Doc——文档。
一份清晰的技术方案（Design Doc），一篇严谨的架构决策记录（ADR），一个定义精确的API契约，一份写明边界条件和验收标准的需求文档——这些才是经得起审视、能在团队中流转、可以跨越时间被回溯的"答卷"。它不一定是长篇大论——一条三行的ADR、一段关键函数上方的注释、一组命名精确的测试用例，都算。重要的不是形式的轻重，而是决策是否被记录下来。
为什么这个区分至关重要？因为它揭示了两种完全不同的能力层次：
- 写Prompt是"和AI聊天"——即时的、私人的、散落在无数对话框里的。
- 写Doc是"把思考结构化"——持久的、公开的、可被挑战和迭代的。
一个只会写Prompt的人，本质上仍是操作员——只不过操作对象从IDE换成了对话框。而能写出优秀文档的人，才真正完成了从"执行者"到"定义者"的跃迁：你不仅在解决问题，你在定义问题本身。
还有一个更尖锐的追问：AI也能写文档啊——Design Doc、ADR、API契约，哪个它写不了？
没错，AI可以生成文档的"文字"，但无法替代文档背后的"决策"。一份Design Doc的真正价值，不是格式工整的段落，而是"为什么选REST而非GraphQL""为什么这里牺牲一致性换取可用性"这些需要理解业务上下文、权衡多方利益后做出的判断。AI能帮你落笔，但拍板的那个人，必须是你。
这才是文档作为"答卷"不可替代的部分——它记录的不是文字，是决策者的思考轨迹。
所以，下次当有人说"AI时代最重要的技能是写Prompt"时，不妨追问一句：你的Prompt，最终沉淀成文档了吗？如果没有，那它不过是风中的一句耳语——说完就散了。
四、岗位的边界正在溶解
技术壁垒的消融，带来的不只是效率革命，更是一场静悄悄的身份重构。
回看过去的互联网分工：产品经理定义"做什么"，设计师决定"长什么样"，程序员负责"怎么实现"——泾渭分明，各司其职。这套分工之所以存在，本质上是因为每个环节都有足够高的专业壁垒，一个人吃不下全部。
但AI正在拆掉这些壁垒之间的墙。
当产品经理可以用Cursor直接把原型变成可运行的代码，当程序员可以用AI生成竞品分析报告和用户画像，当设计师可以一边出图一边让AI把设计稿转成前端组件——"岗位"这个概念本身，正在从清晰的格子间变成模糊的光谱。
我们已经看到了这种融合的产物：
- AI产品经理：既懂模型能力边界，又能定义产品逻辑，还能亲手调试Prompt Pipeline。
- Product Engineer：不再只是接需求的"翻译机"，而是从用户洞察到技术交付一肩挑。
- 全栈独立开发者：一个人，一个周末，一个MVP——用极低成本验证商业假说，以过去十人团队三个月的速度，独自交付完整产品。
这些新角色的共同特征是什么？它们都不再被单一技能定义。 定义它们的，恰恰是本文反复强调的Talk能力——Talk to the Machine、Talk to the Business、Talk to the System。只不过，这种能力的载体不再按岗位分配了。
所以，与其问"技术壁垒的消融对程序员是好消息还是坏消息"，不如换个问法：
你还在用旧的title来定义自己吗？
如果你是一台"人肉翻译机"——PM丢过来PRD，你把中文翻译成Java/Python——那AI确实是你的终结者。这条赛道上，没有人跑得过机器。
但如果你是一个"问题解决者"——利用一切工具（包括AI）去最低成本、最高效率地解决真实世界的问题——那么岗位的边界消融，恰恰是你的解放。你不再被title困住，不再被分工框死。一个人，就是一支团队。
结语
Linus当年说"Talk is cheap"，是因为那个时代，写得出代码的人太少，而空谈的人太多。
二十五年后，局面彻底翻转：写得出代码的人遍地都是——因为AI替每个人都写得出。而能把话说清楚的人，反而成了稀缺资源。
历史没有证明Linus说错了。它只是翻了个面：如今cheap的，恰恰换了一边。
Code is cheap. Show me the talk.