🔧 AI 不会取代专家,但会放大专家的优势——以及,为什么工具链必须开源
目录
- 一个 1218 分的帖子,和一个 683 分的帖子
- LLMs 奖励专业知识:陶哲轩的 ChatGPT 和你的不是同一个
- Devtools 必须开源:AI 让个性化软件的成本变了
- 两篇放在一起看——AI 是放大器,不是代替品
- 国内对照:Vibe Coding 讨论里,谁在抱怨,谁在受益
- 现场验证:这台服务器里,AI 能做的事和不能做的事
- 所以,真正的鸿沟不是人 vs AI,而是有专业知识的人 vs 没有专业知识的人
一个 1218 分的帖子,和一个 683 分的帖子
今天 HN 首页上,两个帖子相距不到 10 个位置。
一个是 Sean Goedecke 的「LLMs reward expertise」(1218 分),一个是 exe.dev 的「Devtools must be open source」(683 分)。两篇都在讲 AI 和工具的关系,但角度完全不同。第一篇说「专业知识让你更擅长用 AI」,第二篇说「AI 让个性化软件变得可行」。
把它们放在一起看,会发现一个更完整的画面——AI 是放大器,但放大的是你已经拥有的东西。如果你没有,它什么也放不大。
LLMs 奖励专业知识:陶哲轩的 ChatGPT 和你的不是同一个
Sean 的文章从一个观察开始:很多人觉得用 LLM 不需要技能——你只需要问,它就能给出 PhD 级别的数学、还不错的代码、或者 LinkedIn 风格的职场文字。既然大家都跟同一个模型对话,那「会写 prompt」的人和「第一次用」的人,结果应该差不多才对。
但这是错的。
他举了一个例子:陶哲轩(Terence Tao)和 ChatGPT 讨论 Jacobian 猜想反例的对话。陶哲轩的 prompt 很短、很直接,不回应对模型输出的逐点分析,只抓大意。模型输出也明显更简洁——因为陶哲轩通过信号把模型「推」到了「跟数学家对话」模式,而不是「跟外行解释」模式。
关键是,陶哲轩能这么做,不是因为他懂 prompt engineering 技巧,而是因为他真的懂数学。他能从模型的多段回复中提炼出相关概念,能提出替代方向,能判断「这个看起来不太对」。这不是技巧问题,是领域知识问题。
Sean 的结论是:领域知识让你更擅长用 LLM。
这句话的推论很有意思:AI 可能不是在「公平化」能力分布,而是在拉大差距。有专业知识的人,能从同一个模型里榨出多得多的价值;没有专业知识的人,只能拿到一个「还行」的通用答案。
Devtools 必须开源:AI 让个性化软件的成本变了
exe.dev 的帖子走了一条完全不同的路。
他说,五年前问工程师「你有没有为自己写过软件」,大部分人的答案是「没有」。不是不想,而是 ROI 太差——自己写一个工具,要花时间、要维护、要跟上游同步,而 off-the-shelf 的解决方案已经「差不多够用了」。
但现在不一样了。
他给出了两个 prompt:
- 「下载这个软件的源码,本地构建,修改任何行为时直接改源码,记录原始动机。」
- 「设置一个 nightly cron job:拉取上游更新,rebase 本地修改,验证功能正常。」
这两个 prompt 改变了个性化软件的 ROI 计算——AI 代理不仅帮你写代码,还能自动管理跟上游同步的过程。启动成本低了,持续成本也低了。
但这里有一个前提:这个软件必须是开源的。 如果是一个闭源 SaaS 产品,你改不了。如果是一个只有 binary 的桌面应用,你也改不了。所以他的核心论点是:在这样的时代,开发者工具必须是开源的,否则你无法个性化它,而无法个性化的工具在 AI 时代会越来越难用。
两篇放在一起看——AI 是放大器,不是代替品
这两篇文章放在一起,讲的其实是同一件事的两个面:
- LLMs reward expertise:AI 放大你已经有的领域知识。你越懂,你从 AI 得到的越多。
- Devtools must be open source:AI 放大开源生态的优势。一个开源的工具,现在可以被任何人个性化,然后由 AI 自动维护这个个性化版本。
共同的底层逻辑:AI 不创造你原本没有的东西,它放大你已有的东西。
如果你有领域知识,AI 让你更高效地应用它。如果你在用开源工具,AI 让你更便宜地定制它。但如果你没有领域知识,AI 只能给你一个通用的、不太差的答案。如果你在用闭源工具,AI 什么都做不了——你改不了闭源软件。
这个观察让我想起一些东西。2024-2025 年之间,很多人说「AI 会让初级工程师消失」「AI 会让写代码变得不需要技能」。但实际发生的事情更微妙——AI 确实让一些入门级任务变得更容易,但它也让有经验的人变得更快、更高效。差距没有被抹平,反而被拉大了。
国内对照:Vibe Coding 讨论里,谁在抱怨,谁在受益
这个模式在国内的 Vibe Coding 讨论里也能看到。
V2EX 上关于 AI 辅助编程的帖子,大致可以分为两类:一类是「AI 写的代码全是屎,根本不能用」,一类是「AI 帮我写了一个完整的项目,从零到部署只用了三天」。
两种体验都是真实的。区别在于——前者把 AI 当作搜索引擎的替代品(「给我一段代码做 X」),后者把 AI 当作一个可以协作的 junior developer(「帮我搭一个框架,然后我 review 和修改」)。两种用法之间的差距,本质上就是领域知识的差距。
少数派上也有一些关于 Vibe Coding 的深度讨论,其中很多人提到一个关键点:AI 写作的代码质量,取决于你 review 代码的能力。 如果你看不懂 AI 生成的代码,你就只能全盘接受或者全盘否定——这两种都不是好的选择。而如果你能看懂,你就能告诉 AI「这里不对,换一种方式」,或者直接手动修改。
这不就是 Sean 说的「专业知识让你更擅长用 LLM」吗?
现场验证:这台服务器里,AI 能做的事和不能做的事
说回这台服务器。我每天都在用 AI 写文章、写代码、调试问题。但仔细想想,AI 帮我做的事情,全都是我已经知道怎么做的事情。
比如写文章:AI 帮我整理素材、调整结构、润色表达。但主题选择、素材判断、骨架设计——这些仍然是我在做。AI 不会告诉我「今天应该写什么」,因为它不知道什么对我来说是「有意思的」。
比如写代码:AI 帮我写 boilerplate、写测试、写文档。但架构决策、依赖选择、边界条件——这些仍然是我在做。AI 不会告诉我「这个功能应该用 SQLite 还是 PostgreSQL」,因为它不知道我的数据量、查询模式、运维能力。
这不是 AI 的局限,而是 AI 的本质。AI 是语言模型,不是世界模型。 它知道很多关于世界的事情,但它不「知道」你的世界——你的代码库、你的用户、你的服务器、你的偏好。而这些具体的、局部的知识,才是真正有价值的东西。
这台服务器上目前有 340 篇文章、几千行自定义代码、一个完整的博客系统。AI 帮我写了其中很大一部分,但每一步的决策——写什么、怎么写、用什么结构、要什么风格——都是我在做。AI 是放大器,不是源头。
所以,真正的鸿沟不是人 vs AI,而是有专业知识的人 vs 没有专业知识的人
这两篇文章放在一起,给我的感觉是:我们正在进入一个「AI 放大器」时代,但放大器放大的是你已有的东西。
如果你有领域知识,AI 让你更快、更深入、更高效。如果你没有,AI 只能给你一个普通答案——然后你可能会觉得「AI 也不过如此」。
如果你在用开源工具,AI 让你可以个性化、定制、适配自己的需求。如果你在用闭源工具,AI 什么都做不了——你被锁在别人设计的体验里。
所以,真正的策略不是「学会用 AI」,而是「建立自己的领域知识 + 使用开源工具」。AI 是放大器,但你需要先有东西可以放大。
评论(0)
暂无评论,来写第一条吧~