标签 程序员 下的文章

大家好,我是凌览。

如果本文能给你提供启发或帮助,欢迎动动小手指,一键三连(点赞评论转发),给我一些支持和鼓励谢谢。


刷到一个挺扎心的话题:程序员为什么不自己做产品赚钱。

身边还真有不少人问过类似的话:"你天天写代码这么厉害,怎么不自己搞个App、做个小程序?随便弄弄不就发财了?"

每次听到这种问题,我都不知道该从哪儿开始解释。

最近在 X 乎上看到同行的回答,看完只能说:太真实了。

理想很丰满、现实很骨感

首先,假装我们是程序员,某天深夜加班回家,瘫在沙发上刷手机,突然一个念头炸开——"我去,这个功能市面上根本没有!我要是做一个,肯定爆火!”。

脑子里的画面瞬间清晰:产品上线、用户疯涨、投资人排队、财务自由...,满脑子都是"老子不干了,要创业"。

说干就干,流程走起来:

第一步:注册账号结果发现邮箱早就被自己多年前注册过,还冻结了。解冻、换邮箱,折腾一圈。

第二步:想名字绞尽脑汁想了个好名字,一搜,已被占用。再想想想,终于通过。

第三步:开发前端后端一把抓,不会前端?没事,Ai结伴编程一把梭。uniapp启动,一套代码多端运行,微信、QQ、抖音、快手平台全都要上。

第四步:买服务器,阿里云一核两G,一年600块,付款的时候手还没抖。

第五步:搞域名,随便挑一个,一年30块,便宜。

第六步:备案到这里,噩梦开始了。拍照、填表、等审核,来来回回折腾。好不容易过了,提交小程序审核——"该项目类型个人不支持,需要企业认证。"

卒。亏损-630元。

但程序员嘛,头铁。不信邪,继续:

第七步:注册公司个体户要经营场所,干脆直接注册公司。准备材料、开对公账户、刻公章,又是一顿操作。

第八步:重新认证企业认证要的材料堆成山,干脆重新注册个小程序。又是想名字(原来的还要等两天才能释放)、填资料、承诺书、盖章...

终于,小程序上线了。

上线只是开始,赚钱才是难题。

每天努力宣传、引流,结果广告收益长这样:昨日收入0.65元。

对,你没看错,六毛五。折线图上的曲线在0.3元到1.8元之间反复横跳,月收入6.72元。服务器钱还没赚回来,先赔进去几百块。

什么会这样?

  • 个人开发者不能收费,只能通过挂广告,而广告收入低到离谱。激励广告单价居然只有4.29元/千次展示,Banner广告更惨,几块钱千次展示。算笔账:日访问量要达到2万,才能日入500。2万UV什么概念?很多小公司的官网一天都没这么多人。
  • 推广难,小程序是个封闭生态,你不能诱导分享,否则直接封号。只能从其他平台往微信导流,但用户路径一长,流失率奇高。要开通流量主还得先引流500人,这第一道门槛就卡死不少人。
  • 审核机制让人头大,页面上文字一多,就说你涉及"内容资讯",不给过。个人开发者经营类目受限,动不动就踩红线。

不是技术问题,是商业问题

程序员不做小程序赚钱,不是因为不会写代码,而是因为写代码只是万里长征第一步。

做一个能赚钱的小程序,需要:

  • 产品能力:做什么?解决谁的什么问题?凭什么用你的?
  • 运营能力:流量从哪来?怎么留存?怎么变现?
  • 商业资质:公司、对公账户、各种许可证,合规成本不低;
  • 时间和精力:白天上班,晚上搞副业,服务器半夜挂了还得爬起来修。

而大多数程序员,只是喜欢写代码而已。让他们去搞流量、谈商务、处理工商税务,比写一万行代码还痛苦。

更扎心的是,就算你愿意干这些,小程序的红利期也早过了。2017年刚出来那会儿,确实有人靠简单工具类小程序赚到第一桶金。现在?各大平台库存量几百万个,用户注意力被某音、被红书切得稀碎,新入局者基本就是炮灰。

成功案例

网上经常能看到"做小程序月入过万"的帖子,但仔细看会发现,要么是卖课的,要么是有特殊资源的(比如手里有公众号矩阵导流),要么是早期入局者吃到了红利。
对于普通程序员来说,接个外包项目,按时薪算可能比折腾三个月小程序赚得还多,还省心。

技术只是工具,商业才是战场。会拿锤子的不一定会盖房子,会写代码的不一定能做出赚钱的产品。这不是技术问题,这是两个完全不同的赛道。

最后

所以,开发一个小程序到底能不能赚钱?

能,但跟你关系不大。

要么你有现成的流量池,比如几十万粉丝的公众号、抖音号,小程序只是变现工具;要么你有特殊资源,比如独家数据、行业资质;再要么你踩中了某个极小概率的风口,比如当年疫情期间的健康码周边工具。否则,个人开发者大概率是炮灰。

写代码是确定性的事,输入逻辑输出结果;做生意是概率性的事,投入不一定有回报。 大多数人适合前者,却误以为自己能驾驭后者。

你呢?有没有过"做个产品改变世界"的冲动?最后成了吗?

##手工编排吧!

今天是第三天,我的 pdd 后台流量依旧打满,平台扶持的。但是没任何用。依旧不出单,这些和正文无关简单交代背景。

我想的四吃办法是:
1 小红书种草,写我全职开副业之路--pdd 电商(瓢多多)。给程序员同行点借鉴作用,为社会产生点价值

2 youtube 拍视频,同款内容做长,做成经验教程的模式,用英语配文

3 x 上发帖吐槽,寻找矛盾点卖惨,争取关注粉多点,后面开蓝标搞长文赚钱

4 蝴蝶号拍视频写拍电商内幕

总结就是依托一件事情,搞持续内容个人 ip 输出变现。电商的亏的钱要从其他地方赚,做电商就默认亏钱,这样子。

老程序员已经在逃离猝死的路上,给各位打样,如果那天不更新了,d 各位记得帮我长草

最近刷 X 乎时看到这样一个耐人寻味的的讨论话题,浏览量超 170w,参与讨论的同学也好多。

问题描述是这样的:

“为什么没人走后门当程序员?”

我认真浏览了一圈,心里五味杂陈。

在许多人眼中,程序员是一个高薪的职业。然而,即便程序员们拿着如此令人羡慕的高薪,尽管互联网行业如此火热,但却几乎很少听说有人说走后门想进去。

其实这事情一点也不难理解,这得先从程序员工作的本质说起。

因为程序员这个职业,从根子上来说压根就不靠后门吃饭。

而且程序员这行,恰恰是最混不了日子的,它要求你持续学习,跟上技术迭代,解决一个个具体而棘手的问题。

编程是一个实实在在的技术活,当你的代码运行不起来,它就是运行不起来,你写的系统有漏洞,它就会在某个深夜悄然崩溃,这种刚性特质就决定了程序员这个岗位无法容忍滥竽充数者。

而程序员的门槛,是技术,是能力,走后门也写不出一行能跑通的代码。

退一步说,哪怕就算你真靠后门挤进了公司,项目一上来,分分钟就会露馅。

那些想走后门的人,大概率是想找一个稳当、轻松、有人脉资源的工作。但反思程序员这行,是这样吗?好……好像哪个也不沾边吧……

所以没人走后门干程序员,不是因为这行没前途,而是因为它太实在、太透明、太难伪装。

这是一份必须用真本事去交换的职业,关系在这里,价值被迅速稀释到近乎为零。

另外大家往往有种误解或者说错觉,总觉得程序员赚得多就是香,而实际却忽略了这个高薪背后所付出的代价,这一切都是来源于高强度脑力劳动和长时间脑力付出所带来的回报。

再者,互联网行业的本质是工程化与扁平化。在这个体系里,你是谁、认识谁、从哪来,其实并不太重要,没人会关注你这个,英雄不问出处。

重要的是,你能不能解决问题,能不能为项目创造价值。

所以,当我们回过头来再看,为什么没人走后门干程序员这个问题,其实本身就蕴含着一种误解。它预设了程序员是一个好差事,一个可以让人躺着赚钱的美差。

但事实上,程序员是一份需要真才实学、持续奋斗、直面挑战的工作。你付出多少努力,掌握多少技能,最终都会在你的代码和收入上得到真实的反馈。

当然,这里还有一点需要反思的是:

该说不说,程序员行业的这种去关系化特质,其实某一角度来说也带来了一些副产品。

比方说,技术至上的工作文化有时会导致个体沟通能力的忽视,对硬技能的过度强调可能让软技能的发展有所滞后,另外代码世界的非黑即白有时候也会让人忽略了现实世界的复杂灰度。

这些其实都是程序员文化中值得反思和平衡的地方。

有一说一,其实很多代码之外的东西对现如今的生存也很重要,因为思维如果不开阔出来的话,路可能就会越走越窄了。

其实很多程序员在年龄大了之后越来越焦虑的一个重要原因就是因为生存技能太过单一了,所以千万不要给自己设限,不要把目光仅仅聚集在自己的一亩三分地上,还是要多培养一些其他方面的一些软实力,会很有帮助。

不知道大家有没有看过《软技能》那两本书,讲的就是代码之外的一些软技能和经验,里面提到了很多有关职场的分析,自我提高的一些路径,个人的持续学习和成长,甚至包括像理财、健身、时间管理、心态调整等等。

有意识地去关注这方面东西的原因在于可以帮助自己把思维给开阔出来,毕竟很多时候有必要跳出来看问题,这时候这些软技能往往就能发挥作用了。

另外,程序员作为一个有个性的创造性群体要专注精进技术这本身没错,但是职场毕竟也是一个充满人情世故的江湖,所以掌握一些通用的职场规则、沟通技巧,甚至是向上管理的艺术,这对于程序员来说也是十分有必要的。

仰望星空,脚踏实地,埋头赶路的同时也不要忘记时常抬头看看周围的环境和机会。

那关于这个问题,你的看法是什么呢,如果有不同的见解,也欢迎一起来分享交流~

注:本文在GitHub开源仓库「编程之路」 https://github.com/rd2coding/Road2Coding 中已经收录,里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记,以及程序员生活和感悟,欢迎star。

以前一个项目可能要 5 个程序员搞定的现在只要 2 个就可以了,但是产品经理是没办法被取代的!!强烈建议转岗,AI 根本没办法理解一个人应该如何使用产品,交互,比如按钮为什么会在这?

目前在一家小企业做乙方项目负责人,最近招投标感觉竞争力越来越大,投标价越来越低。
这两年做的项目基本都不挣钱,也就保住部门正常运行。
同时也感觉到 AI 能力越来越强,肉眼可见的 AI 已经慢慢快要超过程序员(我们部门用 Java 搞工程化的)。
和好多甲方聊了聊,他们之前人少,所以有好多项目会外协。现在 AI 能力越来越强,他们之前会发标的项目,现在好多都内部研发人员用 AI 实现了。


所以不知道哪天我们部门就被撤掉了。


已经过了 35 了,再就业的可能性很小了,现在正在寻找失业后的方向。


有没有类似的同仁,大家有没有给自己留什么退路?

起因:连续讲了 30 多分钟故事,她还是不睡

每天晚上 9 点半是我家的固定节目:女儿洗完澡,躺在床上,把她最爱的几本绘本摆成一排。

"爸爸,今天讲这本小兔子,还有恐龙的,还有..."

通常的流程是

  • 9:30 开始讲第一本绘本
  • 9:45 "爸爸再讲一个"
  • 10:00 "这个讲过了,编一个新的"
  • 10:15 我开始口干舌燥,她开始挑刺:"爸爸你昨天说小熊是红色的"
  • 10:30 她终于睡着,我瘫在床边刷手机缓一会儿

有天晚上特别崩溃:讲完三本绘本,她说"爸爸你编一个恐龙和兔子一起玩的故事"。

我临时编了个"霸王龙帮小兔子找萝卜",讲到一半自己都接不下去了,因为前面埋的坑忘了怎么圆。

她睁着大眼睛看着我:"然后呢?萝卜找到了吗?"

那一刻看着她期待的眼神,突然有点心酸。

不是不想讲,是真的每天都在掏空脑子,还得记住前面自己说过什么。

更难受的是,有时候加班晚了,或者状态不好,讲着讲着就敷衍了,她能听出来。会小声说:"爸爸今天讲得不好玩。"

我当时就想:能不能有个东西,让我即使累到说不出话,也能给她讲一个像样的故事?


程序员的痛点,可能也是你的痛点

说实话,在我做这个东西之前,试过市面上所有能找到的方案:

  • 故事 App: 凯叔、口袋故事都买了会员,但听多了不光无趣,也没有个性化
  • GPT 生成: 文本确实能定制,但 TTS 合成音就像客服机器人,毫无感情
  • 录音: 自己录了 20 多个故事,但每次要翻半天找文件,而且孩子总想听"新的"

这些方案单独看都没问题,但放到每天晚上十点半这个场景里,就全都不太行。

最崩溃的是某天晚上:

  • 22:30 讲了三只小猪
  • 23:00 她说"再讲一个有兔子的"
  • 23:20 编到词穷,开始重复情节
  • 23:45 她睁着大眼睛说"爸爸你刚才讲过了"

我坐在床边看着天花板,想着明天还有早会,突然冒出个念头:能不能让 AI 用我的声音讲?

顺便说下我是怎么折腾这个东西的(技术相关,可跳)

1. 故事生成不是调 API 那么简单

  • 一开始直接用 GPT 生成,结果经常前后打架,只好自己加了一层检查,避免讲着讲着把前面的设定忘了。(避免重复/逻辑 bug )
  • 分龄模板: 2-3 岁重复句式多,4-5 岁加入简单因果,6+开始有小反转
  • 安全过滤: 硬编码了很多禁用词库(包括"死亡""分离"等敏感词)

2. 音色克隆的坑

  • 最开始用开源 TTS ,效果像变声器
  • 后来接了某云的语音定制 API ,需要录多句话做训练
  • 真正的难点是韵律: 同样的文本,讲给 3 岁和 6 岁要用不同的停顿节奏

3. 成本控制

  • 大模型生成一个故事约 0.2 元(目前提示词就几千 token )
  • 音频克隆+合成约 0.4 元
  • 单张图片 0.2-0.4 元
  • 算上服务器和存储,也就是说,这玩意儿要是真被孩子天天听,其实还挺烧钱的。

对用户来说只要三步:

  1. 使用官方音色或者录一句话( 15 秒左右)
  2. 填孩子的基本信息(年龄、爱好、最近关注的事)
  3. 自己可以定制场景、故事
  4. 点生成,1-2 分钟后收到一个 5-8 分钟的音频故事


真实效果:一些意外的反馈

我家的变化

  • 女儿的入睡时间从原来的 40 分钟缩短到 20 分钟
  • 有天她指着我说: "爸爸你今天声音怎么跟手机里不一样?" (我感冒了)
  • 现在有时候出差也不焦虑了,每天睡前会提前生成好第二天的故事

朋友的案例(他们催我做出来的)

  • @老王: 双胞胎爸爸,每天要讲两遍不同的故事,现在各生成一个,省了一半时间
  • @小林: 孩子有语言发育迟缓,医生建议多输入,他用这个每天给孩子听 3 个故事

最触动我的是有一位朋友的反馈,她说:"技术能做的不只是效率,还有情感的延续。"


目前的纠结:三个灵魂拷问

1. 这需求到底有多普遍?

我的假设是:

  • ✅ 认同"父母声音对孩子重要"
  • ✅ 工作忙/经常出差/没空编故事
  • ❓ 愿意为此付费(而不是凑合用免费 App )

V2EX 的各位宝爸宝妈,你们会为这种服务付费吗?你们觉得合理价格是多少?

2. 音色克隆是噱头还是刚需?

有朋友直言:"孩子听谁讲不是一样?"

但我观察女儿的反应,她听到"爸爸的声音"时,真的会下意识抱紧小枕头,这和听凯叔讲故事的状态完全不同。

可能儿童心理学上有答案?有相关背景的朋友求指点。

3. 定位是"解放家长"还是"陪伴工具"?

  • 如果定位成"让家长省时间",很容易被批"用技术逃避责任"
  • 但如果定位成"让陪伴更高质量",又显得太虚

我现在的想法是: 这不是替代父母讲故事,而是在父母不在场/不方便时,提供一种接近真人的补充方案

就像视频通话不能替代见面,但总比完全失联好。


想听听大家的真实想法

如果你是家长:

  • 每天哄睡要花多长时间?
  • 试过哪些方案?痛点在哪?
  • 如果有这个工具,最看重什么(声音相似度/故事质量/价格)?

如果你做过类似产品:

  • 定价策略怎么定的?(订阅制 vs 按次付费)
  • 怎么平衡"商业化"和"不制造焦虑"?
  • 推广渠道主要靠什么?


最后

这个东西现在还很粗糙,甚至都不确定该不该做成产品。

但每次看到女儿听着"爸爸"讲的新故事安静入睡,会觉得这件事可能有点意义。

不是为了让父母逃避陪伴,而是让那些想陪但确实分身乏术的爸妈,多一种选择。

如果你有想法,无论是吐槽还是建议,都欢迎留言。

先谢过各位。


留言区如果超过 50 楼,随机抽取 5 位送年度会员


P.S. 如果有宝爸宝妈想试用,可以留言或私信。目前还在内测阶段,大家可以多提意见。

附上小程序码(微信搜:妈咪故事屋):
地址: https://imgur.com/hMjpDCr (图片无法显示,尴尬)

一个程序员2004年的决定,如何悄悄改变了整个互联网?

想象一下:

你正在写一份工作报告,想给标题加个粗体,或者插入一个网址链接。

在传统的 Word 文档里,你需要花几分钟时间找各种按钮、菜单,偶尔还会因为误操作把整页格式搞乱。

现在,你只需要输入 # 标题 就能得到大标题,输入 **粗体文字** 就能得到粗体,输入 [点击这里](网址) 就能得到一个可点击的链接。

简单、直接、高效,就像发微信一样自然。

这就是 Markdown。

本篇和你讲讲 Markdown 背后的故事,以及为什么它能成功到风靡全球,以及它的故事对我们的启示。

1. 一个决定

故事要从 2004 年说起。

那时的互联网还很“原始"”,如果想在网页上发布一篇文章,你必须学习一门叫 HTML 的语言。

想象一下,每次写文章都要像这样编码:

<h1>我的文章标题</h1><p>这是一段<strong>重要</strong>的文字,包含一个<a href="链接地址">链接</a>。</p>

这就像是想给朋友写封信,却必须先学会用摩斯密码一样荒谬。

就在这时,一个叫约翰·格鲁伯的程序员做了一个大胆的决定:创造一种“反HTML”的格式。

HTML是“标记语言”,那他就创造一种“反标记语言”——Markdown。

约翰的想法很简单:为什么不能让写文章就像写普通邮件一样简单?

1.png

2. 意外传播

约翰发布 Markdown 时,并没有想到它会成为互联网的基础设施。

他只是厌倦了复杂的 HTML 语法,想为自己和朋友提供一个更简单的选择。

但接下来发生的事情连约翰自己都没想到:

  • 2004 年:Markdown 悄悄诞生
  • 2005-2010 年:程序员们开始用 Markdown 写技术文档
  • 2010-2015 年:各大平台开始支持 Markdown 格式
  • 2015-2020 年:笔记软件、协作工具全面拥抱 Markdown
  • 2020 年至今:连苹果的 Notes 都支持 Markdown 了

这就像你发明了一种新的记账方法,结果全世界的企业都跟着用了。

2.png

3. Markdown 成功的十个原因

所以为什么 Markdown 能在众多技术中脱颖而出呢?

让我们看看它的成功秘密:

1. 绝妙的名字

“Markdown”这个名字很好!懂技术的人一眼就知道它是“反 Markup”,普通人听起来也简单好记。

2. 解决了真实痛点

不是所有新技术都解决了实际问题,但 Markdown 确实让无数人从 HTML 的折磨中解脱了出来。

3. 顺应了用户习惯

Markdown 的语法基于人们已经在邮件和文档中形成的习惯。比如用 * 表示强调,用 # 表示标题等。

4. 找到了最佳时机

2004 年正值博客爆发期,人们正在寻找更好的写作工具。Markdown 正好撞上了这个风口。

5. 开放包容的社区

从一开始,Markdown 就有一个开放的社区。

各种版本出现:GitHub 版本、通用版本、扩展版本...但核心依然保持一致。

6. 极简主义的设计哲学

保持简单,而不是追求复杂。这是很多成功技术的共同特点。

7. 技术人员的推动

程序员们是早期使用者,他们发现了 Markdown 的价值并大力推广,形成了滚雪球效应。

8. 可读性强

即使不懂 Markdown 语法的人,看到 .md 文件也能大概猜出意思。这种“自我解释”的能力很珍贵。

9. 跨平台兼容

Markdown 文件在任何设备、任何系统上都能正常显示和编辑。不怕软件更新,不怕系统迁移。

10. 零专利壁垒

最重要的是,约翰·格鲁伯没有为 Markdown 申请专利。这意味着任何人都可以自由使用它。

3.png

4. 带给我们什么启发?

Markdown 的故事不仅仅是一个技术成功的案例,它还给我们很多启发:

4.1. 简单比复杂更有力量

在这个喜欢把简单事情搞复杂的世界里,Markdown 证明了“less is more”的智慧。

4.2. 从解决实际问题出发

不是为了技术而技术,而是为了解决人们的实际问题。Markdown 的成功源于它真的让写作变得更简单。

4.3. 长期主义的重要性

从 2004 年到今天,Markdown 已经存在了20年。它没有一夜爆红,而是慢慢渗透,最终无处不在。

4.png

5. 最后

不是每个人都需要发明影响世界的技术,但每个人都可以创造一些让世界变得更美好的小东西。

关键在于:观察人们真正的问题,提出简单的解决方案,然后分享给世界。

或许这就是 Markdown 的故事给我们的最珍贵的礼物。

我是冴羽,10 年笔耕不辍,专注前端领域,更新了 10+ 系列、300+ 篇原创技术文章,翻译过 Svelte、Solid.js、TypeScript 文档,著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”,关注我的公众号:冴羽(或搜索 yayujs),每天分享前端知识、AI 干货。

Ryan Dahl 在 1 月 20 日给软件工程下了结论:“人类写代码的时代已经结束。”留下的工作里,不包括继续手写语法。

 

如果这话出自某个科技网红,大概刷过去就算了。但 Ryan Dahl 不一样——他不仅写出了 Node.js,后来还“推倒重来”做了 Deno。你可以把他的意思理解为:写代码这部分会越来越自动化,而人的价值会更多落在判断、取舍和责任上。

 

而在 Ryan Dahl 这次“宣判”之前,1 月 3 日,Ruby on Rails 作者 DHH 也在 X 上连发多条,语气罕见地偏“乐观派”:

 

“别让那些粗制滥造和尴尬翻车,遮住你对 AI 的惊叹。自从我们把计算机连上互联网以来,这是我们让计算机做到过的最令人兴奋的事。如果你在 2025 年一直对 AI 悲观或怀疑,不如在 2026 年的开端,用一点乐观和好奇再试试看?”

 

于是,社区里迅速冒出一种更夸张、但传播力极强的解读:“DHH 都松口了。”“连最不买账的人都开始给 AI 站台——你还有什么理由不用?”甚至有人干脆把它说成:“DHH 也扛不住了,最终还是向 AI 屈服低头了。”

 

但你真去听 DHH 的原话,会发现所谓“DHH 屈服论”,并不是那么回事儿。

 

在最新一期播客中,他说在 37signals,AI 没有在写真实产品,更谈不上“从零写出什么东西”。

 

他在用 AI,而且每天都用,但更多是做那种“一发入魂”的小实验;一旦进入真工程:要持续演进、要迭代、要打磨,他就会觉得:“这在浪费我的时间,到这一步我自己写更快。”

 

所以他们的新产品 Fizzy 里 95% 的代码,还是人类亲手敲出来的。

 

他还补了一句:我们离那种“AI 让一切始终更好、更快、更省心”的明显拐点,还差一点

 

“就现在而言,我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。”

 

更关键的是,他不是在怀旧。他明确说:“手写代码依然有竞争力。”“至少在此时此刻,这是一个仍然有竞争力的选择。”

 

而且他的判断正好和 Ryan Dahl 相反:“我们并没有到 AGI,没有到那种‘人类写代码的时代死了’的程度。”

 

挺好玩的是,DHH 还说要远离 Anthropic 的 CEO:他一听到那种“再过五分钟就不需要程序员了”的口吻就火大,直接开喷:“你们到底用的啥模型啊?”反正他自己用的是 Opus 4.5(或当下版本),但在他的体验里,这种“程序员马上下岗”的说法完全不符合现实——尤其是那些要长期维护、持续迭代、不断演进的真实工程,离“五分钟结束”差得十万八千里。

 

以下是 DHH 播客整理全文翻译:

 

“如果浏览 Web 的不再是人类”

 

主持人:欢迎大家来到《Next Token》。今天这期节目对我来说有点特别,可能要追溯到 25 年前。很高兴请到 DHH——David Heinemeier Hansson。欢迎你。

DHH:很高兴来,谢谢邀请。

 

主持人:我猜你可能是刚从赛车里下来(笑)。

DHH:现在是休赛期,正好歇一歇。

 

主持人(Torsten):那我就先来点“热血沸腾”的话题。我从 2010 年左右就开始关注你,你可能是对我影响最大的前五位程序员之一。如果没有你,我可能不会走到今天。我职业生涯中有七八年都在写 Rails,看了你所有的书、博客。我们其实从没见过面,但有一次“交集”让我印象极深——我发过一条关于 Cookie Banners 的吐槽推文,那是我人生中传播最广的一条推文。那天中午我被 Cookie Banners 气疯了,随手发了一条,然后彻底炸了。第二天你转推并评论说:“这就是为什么人们不再浏览 Web,而是开始用 ChatGPT。” 所以我想直接问你:欧盟最近说要“取消 Cookie Banners”,你觉得这真的能改善什么吗?还是说——已经太迟了?

 

DHH:我认为 Cookie Banners 是 Web 体验变得糟糕的一个主要原因。它们几乎比早期那种弹窗广告还要糟糕——你知道的,“打地鼠”“打猴子”那种 2000 年初的弹窗。当年浏览器还能通过技术手段封杀弹窗,但 Cookie Banners 没有一个统一、有效的技术解决方案。我知道有插件能挡,但大多数人不会装。结果就是:Cookie Banners 成了互联网的一场瘟疫。

 

我是丹麦人,所以我觉得我有资格狠狠吐槽欧盟。Cookie Banners 最初的出发点是“高尚的”——限制数据收集、提高透明度。但这套东西在第一个 Cookie Banners 出现 5 分钟后,就已经被证明是失败的。可欧盟花了整整 15 年,才开始承认这个问题。现在他们说要“移除”Cookie Banners。

但“移除”是什么意思?你以为这就能抹掉你对互联网造成的破坏吗?不可能。接下来30 年,仍然会有大量网站继续保留 Cookie Banners——因为删掉它比留着更麻烦,或者网站早就没人维护了。

 

这是一件非常悲哀的事。当然,我并不是说:如果没有 Cookie Banners,人们就不会去用 ChatGPT。 那不现实。但它确实在可测量的层面上伤害了 Web,让浏览体验变得远比必要的程度更糟。

 

一旦你已经在用户体验上制造了第一道伤口,后面再多来几刀,心理成本就低多了。Cookie Banners 把“底线”拉得太低了,以至于很多 Web 设计师会觉得:再多放点广告、再恶心一点,好像也没那么糟。 这就像“破窗理论”。

 

主持人:那在 Cookie Banners 把 Web 搞成这样之后,你觉得互联网浏览的未来会走向哪里?

如果未来主要“浏览 Web 的不再是人类”,那这些问题还重要吗?

 

DHH:这是一个好问题。我觉得现在有很多聪明的人都在试图搞明白这件事,我们也在尝试各种不同的做法。某种意义上,这真的很像上世纪 90 年代中后期——当时我们在摸索互联网的第一个版本:这一切究竟会怎么运作?谁会掌握权力?谁会成为平台?谁又会成为把关者?所有这些问题,如今再次被抛回到空中,悬而未决。

 

不管我个人怎么看它最终会走向哪里,我都觉得这是一件令人兴奋的事情。互联网和计算技术,已经很久没有像现在这样让人感到兴奋了——上一次有这种感觉,还是在 2007 年。

 

那是 iPhone 刚刚问世的时候,我们迎来了一个全新的形态。随后经历了很长一段时间:好,一切都转向移动端了。而现在,我们又站在另一次巨大的转折点上——这一次,不只是“移动”不再以同样的方式重要了,它不再是你思考和构建产品时的那个主导视角。

 

与此同时,还有大量没有答案的问题。如果人类不再亲自阅读互联网内容,因此也不再阅读广告,那究竟是谁在为互联网写作?谁还会去生产那些美好的内容?当我们摆脱了 cookie 弹窗,重新拥有一个“干净体面”的门面,这件事真的还重要吗?

 

如果这件事本身已经不再重要,如果人们不再想为互联网写作,那 AI 又将从哪里获取它所需要的信息?我觉得现在有太多悬而未决的问题,以至于没有任何人哪怕稍微知道,最终的解决方案会是什么样子。而这,恰恰是活在这个时代最令人振奋的地方。

 

我毫不怀疑,将来我们回头看今天这个时刻时,会说:“好吧,这里发生了一次决定性的变化。”而且,这种变化在当下的可感知程度,甚至比前两次都要更明显。

 

互联网的出现,花了五六年的时间才真正渗透进社会,对整个社会产生巨大影响。后来是手机,速度快了一些,但也没有快到哪里去——iPhone 本身也经历了好几代迭代,我们一开始甚至都没有 App Store,这些东西都是慢慢才出现的。

 

但 AI 不一样。

 

AI 的出现,在当下这一刻就已经非常明显。任何一个用过第一版 ChatGPT 的人,都会立刻意识到:哇,这完全是一个全新的东西,它将重写规则。

 

所以,在这三次巨大的技术变迁中——互联网的诞生、移动时代的到来,以及现在的 AI——这是第一次,我们在实时发生的过程中就清楚地知道:世界一定会变得完全不同,而我们却不知道最终会变成什么样。

 

因此,我觉得你能做的最好的事情,就是接受三点:第一,我们不知道答案;第二,这真的令人兴奋;第三,赶紧上车,狠狠干脆坐稳了,看看它会把我们带到哪里去。

 

因为还有另一种冲动,过去在互联网时代出现过,在移动时代也出现过:那就是一部分人会说,“我更喜欢以前的样子。我喜欢变革发生之前的一切。我不喜欢 AI。我不喜欢也许会被整个互联网重新中介化。我不喜欢这些东西。我们能不能把一切都倒回去?”

 

不,不能。你没有这种权力。你无法把这些东西倒回去。

 

你当然可以在个人层面选择:我不用生成式 AI,或者我不买任何包含 AI 方案的产品。但这种想法,本质上是一种“阿米什式”的思维方式——而在任何时代,这都只是非常小众的选择。

 

如果这就是你,如果这就是你想与世界互动的方式,那很好,祝你一切顺利。我们有时候确实需要一些“疯子”来提醒我们:事情也可以用完全不同的方式来做。但这,并不会改变历史前进的轨迹。

 

“这真的是一个无比令人兴奋的时代”

 

主持人:你的兴奋更多来自哪里?是因为规则被打乱、棋盘被掀翻?还是因为你真的想用 AI 做事?

 

DHH:首先也是最重要的一点,我热爱计算机。我喜欢看到计算机做出以前做不了的新事情。说实话,让我觉得非常惊讶的是:有这么多在科技行业工作的人,其实并不怎么喜欢计算机——甚至包括那些每天都要和计算机打交道、让计算机“跳舞”的程序员,并不是所有人都真的喜欢计算机。

 

但我不一样。我爱计算机。我真的爱计算机本身,爱的是它作为一台机器的纯粹性。我并不是只把计算机当成一种“工具”,不是只想用它来完成某个目的。确实有一大类人,把计算机仅仅视为通往某个结果的手段。但不是这样,对我来说,这要更深得多——我就是单纯地热爱计算机这个东西本身,也热爱看到它去做全新的事情。

 

而现在发生的这件事,是计算机在我这一生中做过的最令人兴奋的新事情之一,至少可以和当年“计算机连上网络”这件事相提并论。

 

那时我们从 Commodore 64、Amiga 时代走过来,突然“砰”地一下就上网了,用小小的调制解调器拨号,连接世界各地的 BBS,听着它唱出那种刺耳却又美妙的声音——那同样是一次巨大的转变,也彻底改变了我和计算机之间的关系。

 

而现在,很可能是第二次这样规模的变化。

 

另一件让我感到兴奋的,是棋盘被彻底翻转了。尤其是我们已经形成了一些根深蒂固的格局。比如 Apple,我和那家公司有过不少摩擦。我非常期待看到 Apple 通过 App Store 以及整个移动生态所建立的那种“封闭控制”,被彻底掀翻,因为它也许将不再以同样的方式重要。

 

当然,我也并不天真到以为:只要棋盘一翻转,接下来就会迎来一个人人和谐共处的“涅槃世界”,一切都会变成开放平台,没有任何人占据主导地位。这显然不可能发生。不管最终的主导者叫 OpenAI、xAI、Google,还是别的什么名字,某种形式的集中和垄断,迟早都会出现。

 

但至少在现在,我们还处在“尚未整合”的阶段。有这么多公司同时在追逐前沿模型,却没有任何一家明显胜出。

 

就在五秒钟前,整个科技行业还准备给 Google 判死刑——“他们错过了浪潮”,“早期研究是他们做的,《Attention Is All You Need》那篇论文也是他们团队出的,但后来落后了整整九个月”,当时大家已经在谈论 Google 的衰落了。而现在,他们也许又重新回到了领先位置,至少在某些领域确实如此。

 

这种不确定性本身就让人兴奋——我们并不知道,最终谁会占据主导地位,甚至都不确定“主导地位”这种东西是否一定会出现。

 

这件事也很有意思。就在几周前,我还在推特上说,跑本地模型这件事有点“奇怪”。因为我之前试过一些本地模型,说不上什么时候,总之那时体验一般。但就在这周,我又开始重新跑本地模型,然后我心里想:“靠,我之前说的话,保质期也太短了吧。”

 

现实变化的速度已经快到:三个月前说的任何一句话,现在看起来都可能有点傻。

 

而且我真的被本地模型现在的水平震惊到了。它们当然还比不上最前沿的模型,但如果再往前看两年呢?有没有一种可能,根本不会出现一个“唯一的赢家”?赢家反而会是开放模型?最终的局面,会不会类似开源软件对后端软件世界造成的影响?

 

过去我们是有绝对主导者的。我们有过 Sun,有过 IBM,在某种程度上也有过 Microsoft。但这些都已经不存在了。整个后端世界——从 Linux 到各种数据库,再到 Ruby、Rails,以及所有这些东西——几乎全都是开源的。你再也看不到那种一家独大的绝对统治。

 

而在另一边,在前端世界,尤其是移动端,我们却看到的是彻底的垄断:只有两个赢家,Google 和 Apple。他们对平台拥有完全的控制权,而且还在不断收紧螺丝。我们唯一的希望,似乎只剩下立法或监管,而说实话,我对这条路也已经越来越悲观了。

 

所以现在的局面真的很令人兴奋——它可能朝两个完全不同的方向发展。

 

我们很可能还是会走向某种形式的垄断,因为这是面向用户的界面层。而在历史上,我几乎想不起有哪个时代,这种层面没有被“征服”过。

 

但也有另一种可能:这些开放模型会好到一个程度,以至于“谁占据商业主导地位”这件事根本不重要,你甚至不需要那种商业上的统治。

 

这真的是一个无比令人兴奋的时代。

 

“我们的产品也试过 AI 功能,但最后都没上线”

 

主持人:这挺有意思的——你正好是在这个变动时期推出新产品。HEY 大概是五年前发布的,然后最近 Fizzy 也上线了。我们特别想知道:37signals 内部现在到底在发生什么?你们到底怎么用 AI?你们做 Fizzy 的时候,用没用 AI?用到什么程度?我很想听点“细节层面的现实”,AI 在 37signals 具体怎么落地、怎么被用起来的。

 

DHH:哦,用的,当然用。我们每一个开发者都在某种程度上使用 AI。我自己每天也在用 AI。

但我也得先加一句前提:我虽然对我们即将进入的新现实非常兴奋,但我每天处理的仍然是“此时此刻真实存在的东西”。你必须学会在“ hype 的列车”和“现实的列车”之间保持平衡。

 

而在我的“现实列车”里,AI 没有在写 Fizzy(一个 Kanban 工具)。

 

AI 也没有从零写任何东西。

 

我确实用过 AI 做过各种“一发入魂”的实验——但它们通常都只停留在“一发入魂”。因为只要我进入真正的细节:要持续演进、要迭代、要打磨,我就会想:“嗯,这就是在浪费我的时间。到这个阶段,我自己写反而更快。

 

当然,AI 在另一些方面确实能大幅加速。我们在做这些产品时,也在一定程度上使用 AI。但我们并没有大量用 AI 来写 Ruby 代码。如果用 AI 写 Ruby,通常也只是“机械式翻译”——比如:“这里有个我们知道已经存在的东西,你能把它用 Ruby 版本写出来吗?” 它能给出一个初稿,有时候会稍微帮点忙。

 

AI 更有价值的地方是在我们的一些 Go 代码上,因为那里面“样板代码”更多,收益更明显。

但即便是 Ruby 和 Go 这两块,也谈不上“改变游戏规则”。

 

真正改变游戏规则的是:

  • 你想学习一个新 API

  • 你想理解一个新概念模型

  • 或者我们做实验,直接用 AI 去尝试构建“能真正带来价值”的 AI 功能

在这些方面,收益更大。

 

但我们离那种——某些 CEO(比如 Anthropic 的 CEO 那种语气)说的——“再过五分钟我们就不需要程序员了”还差得远。我就想问一句:你们到底用的是什么模型?我用的是 Opus 4.5(或者现在的版本),但那种说法完全不符合现实——至少对于“持续演进”这类工作来说,是完全不成立的。

 

我仍然保持开放心态,我也能看到那种承诺。我记得互联网在 1994、1995 年那会儿是什么状态,我当然能做外推:我们也许真的会走到那一步。也许我们会到一个阶段:人类不再编写大多数代码。

 

但如果你看 Fizzy:95% 的代码,是人类亲手敲出来的

 

主持人:有意思。真的?你们内部也这样认为?

 

DHH:你回头看 Fizzy 的整个开发历史,会更有意思。我们在 Fizzy 里做过一堆 AI 功能实验:我们试过做一个 AI 驱动的命令行,用来和卡片(cards)交互;我们也试过 AI 摘要,给一些内容自动做总结。但最后这两项我们都没有发布

 

Basecamp 也是一样:我们实验过很多不同的 AI 功能,但没有一个能达到“明显更好、用户会一直爱用”的标准,所以都没进最终版本。

 

我仍然相信未来这会改变。只是我们现在还没到那个时刻。

 

我也见过其他地方做得更成熟的案例。比如我在 Shopify 董事会,Shopify 做的 Sidekick(他们的 AI agent)——用来帮助商家搭建店铺、优化店铺——真的很不可思议。那里面有一些非常具体、非常可触达的收益,我觉得几乎无可争辩。

 

我们仍然处在一个阶段:距离“AI 让一切始终更好、更快、更省心”那种明显的拐点,还差一点。

 

也正因为还没到那个拐点,所以才会出现一些反弹——我认为其中不少反弹甚至是合理的。

因为很多人用了所谓“AI 功能”之后会觉得:“这玩意儿太烂了。”“不更好,也不更快,甚至很蠢。”

 

比如摘要。我们刚刚还提到 Apple。Apple 对新闻、短信之类的摘要,我真不知道有多少人真喜欢开着它。它在很多情况下都离谱地糟糕、离谱地错误。连 Apple 这种体量的公司都做不对,那你基本可以合理推测:很多别的公司也同样做不对。

 

不过我也想强调:最近我们确实找到了几个非常好的 AI 用例。其中一个是我们的安全漏洞赏金项目(通过 HackerOne 运行)。我们会收到海量的报告——某个研究员声称在我们的应用里发现了漏洞。我们必须处理这些报告,而现实的数学非常残酷。我们大概会收到……可能一个季度 300 份报告之类的数量。但真正“靠谱、有效、值得修”的——大概只有 3 份。

 

也就是说,真正有价值的比例大概只有1%。而这个 1% 非常重要,因为它们可能真的指出了一个严重问题,我们必须修。但为了抓住这 1%,你必须花巨大精力去验证剩下99%的垃圾——这对团队来说是巨大的麻烦、巨大的时间黑洞、巨大的烦躁来源。

 

AI 在这件事上简直太厉害了:它能在报告进来时就先处理一遍,给我们一个初步判断——“这到底是扯淡,还是不扯淡?”然后还会帮我们写回复邮件。

 

而写回复其实才是痛点的一半:当 99% 的提交都是彻头彻尾的狗屎,写这些狗屎的人还常常—— 根本不懂自己在说什么,却又特别理直气壮,还特别不耐烦,甚至还一副“你必须立刻给我 5000 美金赏金”的态度。

 

这时候让人类程序员保持冷静、不直接对他们开喷,是很难的。真的,你会很想直接骂人。

 

AI 就完全没这个负担。它特别乐意用一种非常冷静的语气写一大段回复:“为什么你这个东西不成立。”它帮我们省了大量时间。

 

主持人:有意思。所以 AI 是拿到报告之后,去看你们代码库,然后判断它到底对不对?

 

DHH:对。没错。就是这样。把这两件事结合起来。

 

主持人:听起来需要一点技巧:拿到安全报告,很多是垃圾,但到了某个层级,你确实得打开代码去确认“这到底是不是真的”。

 

DHH:以前要看 100 份报告,现在可能只要看 5 份——这就是真实的生产力提升。就算你最后要看 10 份、20 份,只要你能把原本 100 份的工作压缩到 20 份,这就是 AI 承诺的生产力收益。如果我们能把这种压缩能力用到业务的其他方面——那简直太好了。这也是为什么我们一直在尝试把 AI 用在一些具体环节上。

 

另一个我们断断续续尝试了好几年的方向是客服支持(support)。但 support 很微妙:如果你只能 90% 正确,那其实很糟糕。因为这意味着你会有 10% 的概率把事情说错——而且是对着客户说错。你如果给客户一个完全错误的答案,让客户体验很差,客户可能就直接流失了。

 

那这个客户的终生价值是多少?

 

你以为 AI 带来的那点“节省成本”,可能瞬间就被一次流失抵消得干干净净。我们上一次认真测试让 AI “做完整客服链路”,大概是 18 个月前左右。效果不太行。但一切都在飞速变化。我知道 Intercom 有一个叫 Finn 的 AI agent,采用得很好,看起来我们也确实该再试一次。

 

而这又回到我最初的那种兴奋:一切变化太快了。

 

有些人会觉得这很让人迷失方向,我觉得这也是很多焦虑的来源。但如果你像我一样,只是单纯喜欢看计算机变得更强大——那现在真的就是一场大戏。坐在第一排,实时看它发生。

 

我们从“那个吃意大利面的人”——看起来像噩梦一样的生成图——走到了今天这种几乎不可区分的输出。接下来,我们很可能会在更多领域看到同样的跃迁。你得保持一种“敬畏感”和“惊奇感”。

 

如果你此刻身处这个行业,和计算机打交道——你的“惊奇感”就是你的安全绳。它能对冲焦虑,对冲不确定性,让这一切变得可承受。

 

当然,我们并不能消除不确定性和焦虑。比如:我的工作三个月后还存在吗?这种焦虑非常合理。但你可以用惊奇感来对冲它:“这些硅做的小东西也太聪明了吧。”

AI 时代,为什么你发布的产品别人看不见?

 

主持人:它们真的很神奇。这就引出了一个更大的问题:软件商业模式的未来到底会怎样?这确实很神奇,但也真的太不一样了。你能不能展开讲讲:创业公司会走向哪里?软件产品会走向哪里?软件工程师会走向哪里?未来到底会怎样?

 

DHH:有一点我现在非常确定:今天发布一个新产品,从“把它做出来”的角度看,是史上最容易的。AI 让构建更容易;工具史上最好;Ruby 和 Rails 也从未如此成熟。对所有人来说,这都很棒。结果就是:市场被海量新产品发布淹没了——永无止境的“上百万、上亿级别”的新发布。

 

这就是你现在要面对的现实。门槛被降低了。而我不确定所有人都会在“轮到自己发布时”还为门槛降低而兴奋——因为你一发布,可能就是一片寂静,连个回响都没有。我们刚发布 Fizzy,算是一次不错的发布,但它并没有像我们历史上某些发布那样“声量巨大”。

 

这当然不只是 AI 的原因,还有社交媒体算法的原因。以前,我在 X(Twitter)上有粉丝,他们就能看到我发的东西。但现在,你会发现:X 上正在发生 Facebook 在 2010 年左右发生过的那一幕——你有粉丝,但你触达不了他们,除非你付钱给平台“买触达”。

 

但现在甚至都不只是“付钱”这么简单。问题变成:我甚至都看不到我合伙人 Jason 的推文了。除非他发了一条“爆款(banger)”,爆到病毒式传播,否则他的内容就不会出现在我的 For You 页面里。一切被压缩成了“你能不能发出爆款”。

 

拥有大量粉丝这件事的价值,被严重稀释了。我在 X 上有五十多万粉丝——这在我发一些犀利观点、能引起传播时依然好用。但当我想发“右勾拳”(也就是营销、转化)的时候,它不再提供过去那种收益。当然,这种变化也不全是坏处。现在小账号也可能爆:就算你只有 10 个粉丝,只要你发了一条爆款,算法也可能把你推上去。算法选赢家和输家的方式,反而让那些没有花 20 年积累粉丝的人受益。但这真的好吗?我大概发了 7 万条推文——这真是离谱。但 18 年下来,这些投入几乎没有“可积累的剩余权益”(residual equity)。

 

我不确定这是不是我们长期想要的生态。但可以确定的是:对我们的营销方式、产品发布方式来说,这已经是一个全新的世界。

 

我们公司现在的阶段是:我们能承受“靠一靠、观望一下”,说一句“挺有意思”。但如果你还处在“必须打出名气”的阶段,你肯定会更焦虑。因为以前那套打法,已经不像过去那样奏效,你得发明新的东西。

 

事实上,这种认知直接影响了 Fizzy 的发布策略:我们承认——你不能再用老办法发布产品了。你手里的名单、你已有的受众,不可能再用“传统方式”被激活。你需要持续不断的“滴灌”:一滴、一滴、一滴。

 

如果我们希望 Fizzy 这个品牌能在用户心里留下印象,以至于当他们遇到我们要解决的问题时,会想起它、会去 fizzy.do,我们就必须设计一种策略,让我们能一直这样做下去。这也部分解释了为什么我们从一开始就把 Fizzy 开源。

 

把 Fizzy 从发布第一天就开源——

  • 对所有想学习“生产级 Ruby/Rails 应用如何构建”的人来说,这是一个巨大的礼物;

  • 同时,对我们来说,它也给了我们一个“更频繁谈论 Fizzy 的许可”。

 

现在社交平台上,纯商业化的转化号召(call-to-action)越来越推不动。以前它传播力也一般,但好歹还能“硬塞”一下——那就是所谓的“右勾拳”。现在右勾拳打不出去,你就得换一种卖法。我目前觉得最管用的策略,是把“给价值”和“求转化”合成一拳:轻击(jab)和右勾拳(right hook)不再分开打,而是同一条内容里同时完成。

 

比如我会发:“Fizzy 里有个很酷的小功能——可能是我们做的,也可能是社区做的,或者我只是想提醒你注意到它。”这条对开发者有用;与此同时,我也顺势把品牌名反复露出来:Fizzy、Fizzy、Fizzy……品牌就是靠重复进入脑子。

 

关键是:重复仍然有效,但必须绑着价值一起出现。光当“慷慨的好人”持续免费输出已经不够了——你得把输出和你正在做的产品强绑定。这就是我们现在的打法。当然规则也可能随时被改写,但就此刻来看,这就是现实的游戏规则。

 

主持人:你说“现在你只要把东西做出来就行”,这句话听起来很有趣,因为我觉得你以前不会这么说。你从一开始就很重视营销——从最早的 Rails demo、到各种“挑衅”、到你如何推销愿景……你一直都在想怎么卖、怎么讲故事。但现在市场被淹没了,好像营销反而变得更重要。

 

更巧的是,我们内部也在聊类似的事。我们在做 AMP(我们在做一个 coding agent),我们内部一直说:现在外界没有太多“强烈的 OTE”(那种外溢式的注意力/势能)。我们想做的是:用一个故事把人“拉着走”——告诉他们我们在这个动荡的时代学到了什么,让他们产生一种感觉:“如果你跟我们走,门是开着的;如果你跟我们走,我们会分享我们学到的东西。”这不是那种“社交媒体上再来 10 个小贴士”的套路,而更像是:“我们一起干这件事。”

 

而你刚刚说的,正好对应了很多人最近在讲的: “爆款发布(big launch)这套已经不灵了。”Product Hunt 死了。Hacker News 的 launch 也……

 

而且我认识 Fizzy,就是因为 Jason 一直在 X 上做这些小 screencast:“现在进展到哪了”、“这里出了一些 X 问题”、“这里哪里又崩了”。我会偶尔刷到它们,可能是 Grok 或者算法觉得我会喜欢。但我的感觉是:我被“拉着走”了——像在跟着你们一起把产品做出来。所以我后来才注意到:噢,原来它上线了。

 

DHH:你说得对,这确实是我们这个时代发生的巨大变化之一。我记得我们在 2006 年写《Getting Real》(那本书)时,我们谈过“爆款发布(blockbuster launch)”这套模型:先放 teaser(预告),再放 trailer(预热视频),最后来一个 blockbuster launch(大爆发)。

 

这套模型已经死了。爆款不再发生。因为我们已经没有共享文化了。没有共享的事件。我们只有每个人各自的个性化信息流——正如你说的,算法之神决定:今天给你投喂哪一小块“刚好合适”的东西。所以,一方面,你必须“灌满渠道”(flood the channel)。

 

另一方面,也有个有意思的反面:以前我会更克制,比如提醒自己别发太多推。有时候我会突然进入那种“多条意识流同时开喷”的状态,但在过去你会想:“哎,我今天已经发第七条了,会不会太多?”

 

现在这种限制不存在了。你一天发 100 条都没关系。因为你不会“淹没”任何人的 For You 页面——算法会替你处理。而你发得越多,你就越有机会让一些小种子落地、生长、发芽。你还需要更长的周期。

 

爆款发布以前的核心逻辑是:“就在这一天,我们发布,然后所有人都在这一天关注。”现在不会了。大家不会在同一天关注同一件事。但随着时间推移,如果你把“发布”理解为:一整个季度、或者一年、甚至某些情况下是一整个十年——你依然可以做“分步骤的搭建”,依然能起作用。因为营销的底层真价值仍然成立:口碑传播、故事激活、好产品、好钩子——这些依然有效。

 

只是,它变得慢得多。你不会再看到那种巨大峰值,然后被“发布日的高潮”爽到。某种意义上,现在的发布没有那个“超级尖峰”了。当然,很多人本来也从来没有过“超级尖峰”,因为大多数发布都什么也不会发生——失败一直是常态。但我现在更强烈地觉得:你越来越难“工程化制造一个爆款”。

 

这个夏天我又学到(或者说被提醒)了一点。我在做一个项目叫Omarchy——一个 Linux 发行版。我做得很开心。当我推进它时,我从营销角度体会到:如果你不断分享项目进展、再配合一个疯狂的发布节奏,价值非常大。

 

我记得第一个月我做了大概 40 次发布?简直离谱。节奏快得惊人,整个过程一直都充满了不确定性,所以特别刺激、特别带劲。这让我可以连续三个月“轰炸”所有人的信息流。更有意思的是:人们明明意识到自己在被轰炸,却仍然无力抵抗。我收到过无数条推文,大意都是:“行行行,我第 17 次听说 Omarchy 了,我服了,我试一下。”“我投降,好吧,我装。”这又回到了营销最本质的东西:重复。

 

有一个老的经验法则(我也不知道现在是不是过时了):你需要听到一个品牌七次,它才会在你遇到问题时被激活——你才会想起它能解决什么。所以我当时就是在努力让尽可能多的人“听到七次”。同时我也在做 Jason 说的那个:enthusiasm transfer(热情迁移)——把创作者的兴奋感转移给别人。这一直是营销的一部分,但现在比以前更重要,因为营销越来越“人格化”。

 

我们还发现:社交平台从来就不怎么喜欢公司账号,但现在它们几乎把公司账号都“幽灵化”了。我们公司账号发什么都没用:从 37signals 发,没人理;从 Basecamp 发,也没人理。一片寂静。然后我看到一些“巨型媒体账号”——几百万粉丝那种——表现也一样惨。这就是算法:它现在真的讨厌品牌账号。除非你是那种“神级品牌账号”——有账号运营团队,能自己成为内容源。

 

但另一部分也让我们意识到:这游戏即便对我们而言仍然很残酷——而且很耗人。这种耗人让我想起我听一些 YouTuber 讲过的东西:如果你是 influencer(网红)、content creator(内容创作者)——这俩词简直是现代词汇里最让我厌恶的词之一——你就会被迫持续生产内容。

 

你维持曝光的方式只有一个:不停输出、不停输出、不停输出(chop chop chop)。以前还有一种“喘息”:你做完 teaser、trailer、爆款发布,然后你还能休息五分钟。现在不行了。那种节奏不存在了。所以一切的速度被推到一个夸张的程度。说实话,我很庆幸我现在不需要“去攒人生的第一桶金”了(笑)。

 

主持人:我们最近也在高频发东西:过去 10 天我们写了 8 篇 release post。这和你做 Omarchy 的方式很像:你需要重复。但那种 5 年前的“空洞重复”已经不行了——比如:“两天前我们大发布,记得吗?”“一周前我们大发布,记得吗?”这种完全没效果。你必须一直有新内容,否则算法不推。节奏太夸张了。

 

而在我们这个做 AI agents 的领域,你还会被大模型厂商不断“催更”——他们两天发一个新模型,用户两天后就来问:“你怎么还不切?怎么还没上新?”所以现在疯狂的事情特别多。

 

我的问题是:你写过《It Doesn’t Have to Be Crazy at Work》(工作不必这么疯狂),但现实已经如此——这在实践中到底怎么改变软件开发?你一直是小团队、小公司路线的拥护者。 但现在如果你想让产品成功,你好像必须把一天切成两半:一半写代码,一半发推、做内容、做传播、分享进展。你觉得这会怎么影响未来的软件开发者/软件公司?营销和软件是在融合吗?

 

DHH:我一直都说:这些东西本来就是一回事。“Marketing is everything(营销就是一切)”——这是《Rework》里的一章。而“everything”真的就是一切:软件、发布、客服、那些乱七八糟的推文、写作、播客……全都是。我们这么干已经 25 年了。但我同意:现在的节奏、算法的胃口,确实到了一个“无底洞”的程度,这种感觉以前没有这么强烈。不过我也觉得:这可能就是竞争加剧的样子。

 

当年我们做 Basecamp 的时候,行业比现在小太多了。那时做 Web 产品的团队少得可怜,以至于我们能关注到每一次发布。后来进入 Product Hunt 时代,你至少还能“一天看一个新东西”。现在结束了。

 

甚至 OpenAI 发一个新模型——那可能烧了 4 亿美元——它也只能获得几个小时的峰值关注与兴奋。

 

所以,它在很多方面变得更难了。可另一方面,基本面依然没变,你得小心别被这些压力带着跑偏。做有趣的东西、做值得讲的东西——这带来的杠杆还在。

 

你要“脱颖而出”的难度变大了,因为参与者更多了。

 

但只要你真的突出,注意力仍然在那里。注意力并没有从系统里被抽走。甚至可以说:注意力比以往更多,因为参与系统的人更多了。

 

这有点像 Spotify。你总听音乐人抱怨 Spotify 付得太少,但你再看数据:音乐产业的规模依然很大,甚至更大,而且在很多情况下,更多收入是直接流向音乐人(因为他们不再必须签那些苛刻的发行合约)。

 

所以一部分现实就是:我们在抱怨“事情太美好了”,但又没有人真的开心。

 

有个段子讲得很好:“一切都很棒,但没人开心。”我觉得这确实说中了某种人性。事情确实很棒:越来越多人能更快地做出东西。而这自然会带来更多竞争。资本家最讨厌的一件事是什么?是竞争。这就是那个系统最大的讽刺。我们都在拼命挖“护城河(moat)”。但护城河是用来挡谁的?不是挡“龙”(Not dragons)——是挡竞争对手。

 

竞争对手,这才是护城河真正要挡的东西。这个隐喻本身也很有趣:你会想,那它把谁“圈”在里面?客户?你在护城河里放鳄鱼,让客户别游出来?这个隐喻挺自利,也挺资本家叙事的。但无论如何,我玩这个游戏,也乐在其中。同时我也很高兴——现在我比过去任何时候都更清楚地知道:我对“什么真正有效、什么无效”的确定性变少了。

 

一直以来,很多东西本就是谜。比如我们 2004 年发布 Basecamp,它一路成了现象级成功,今天仍然成功。

 

我经常会想:为什么?为什么偏偏是 Basecamp?在我 25 年的职业生涯里,我做过很多东西,但没有任何一个产品层面的命中,能像 Basecamp 这么“正中靶心”。我至今也不完全明白原因。尤其是现在,Basecamp 所在的领域竞争者多得多。但每周仍然有成千上万的人注册一个新的 Basecamp 账号。每周我都会想:这怎么可能?怎么会每周都有几千几千人来注册?

 

这一直是个巨大的谜。

 

我觉得这种谦逊非常重要——无论你在做产品、还是在做营销,你都要记住:你不可能了解一切。你不可能确切知道什么有效、什么无效。你能做的,是去尝试很多东西,然后得到一些迹象、一些推力、一些暗示:市场想要什么、算法想要什么、客户想要什么。

 

但你不可能制定一套“主战略”,并指望它具备可重复的复刻性。即便是在一个高度“爆款驱动”的行业——比如我刚刚提到的音乐行业——也没人真正搞明白。的确,有些人比别人更擅长做出爆款,但也没有谁掌握一套公式:“照着这套流程,我们就能稳定生产爆款。”商业也是一样。

 

只是现在曲调又变了。你可以因此沮丧:“我以前那套把戏不灵了。”也可以因此兴奋:“什么?那我更迫不及待想学习——现在到底什么才有效!”我也接受一个现实:我不可能永远拥有过去拥有的一切。世界不是这样运作的。

 

“独立开发者”之梦没变:核心还是“一个人也能干”

 

主持人:我感觉我们好像回到了 2004 年。我记得你发布 Basecamp 的时候,你在 YC 还是哪里做过一个演讲,你当时大意是说:如果你有个想法,然后能找到 1000 个客户,每人每月付你 25 美元,你的人生就彻底不一样了。那次演讲就是我决定辞掉 Web 开发工作、去做 Dropsend 的起点——也开启了我整个职业生涯。

 

我觉得我们又回到了那种状态:现在你真的可以有一个想法,甚至可能是“一人团队”。所以,我们现在是不是就处在这个阶段?还是说,所有 indie hackers(独立开发者)最终都会被“吃掉”?这难道不是好事吗?

 

DHH:我也觉得这是好事。而且这里还有个讽刺点:我 20 多年来一直在讲——开发者生产力真的重要

 

这就是 Ruby 和 Rails 的核心前提:你不需要一个八人团队,你一个人也能做出来。Rails 从一开始就试图成为“单人开发者的框架”,而且我认为它在这件事上比几乎所有框架都做得更成功。

 

而我们今天对 AI 兴奋的原因也一样:我们对小团队能获得的杠杆感到兴奋,因为 AI 能做很多事。

 

有一个根本事实没变:当你降低实验成本、降低构建一个“值得做的东西”的生产力成本时,你就会有更多“射门次数”(shots on goal)。

 

Ruby + Rails 能做到这一点;AI 也能做到;甚至更好的是:AI + Ruby on Rails 一起做到。

但我不确定游戏的本质在这点上发生了根本变化,也许只是变得对更多人可及了。

 

我觉得这大概率是好事——不,只能说:这就是好事。我们应该从“对人类整体有什么分类级别的好处”来理解:对全人类而言,难道不是更好——我们有更多实验吗?即便最终“命中并变成可持续商业”的人,可能比例更低(我甚至不确定这是否属实,但先这么假设)。

 

而作为一个文明整体,我们最终仍然会在更多类别、更多细分领域里,更快地获得更好的软件。问题的一部分在于:无论是 Web 开发圈,还是独立开发者(indie hacker)圈,很多讨论都过于短视地集中在那些我们一直反复折腾的“通用大类”上。

 

比如待办事项应用。好吧,我职业生涯里大概已经做过七个了,而全球可能已经有二十亿个同类产品。最后真正成功的,可能也就那么几个,剩下 99% 都失败了。

 

但你知道吗?你有没有试过给美发沙龙做软件?他们可没有一万种选择。有时候,他们甚至几乎没有任何选择,除了那些“狗屎一样”的系统。那种三十年前做出来的烂软件,出自一些对“好软件”毫不在意的人之手。所以,如果你愿意跳出这些吸引了绝大多数人的大而泛的领域,其实机会依然多得很。

 

颇具讽刺意味的是,我自己长期以来恰恰以“不去碰这些方向”为傲——只解决我自己的问题。因为我觉得那样更简单,而且也确实如此:当你解决的是自己的问题时,你立刻就能判断你做出来的软件到底好不好。

 

这并不意味着它一定会成功,但至少你有了第一道过滤器。如果让我去给美发沙龙做软件,我其实并不知道什么是好、什么是坏,我得不停地去问别人:“你们怎么看?你们给我什么反馈?”老实说,我不确定自己是否适合为了正在构建的软件,去进行这么多和他人的互动。

 

但我认为,对那些愿意这么做的创业者来说,机会是非常多的,而这其实也是大多数人。只要我们稍微把视野放宽一点,不要总是说:“天啊,现在再做一个新的待办事项应用太难了。”因为这个领域在过去三十年里,已经被来来回回地“薅”了大概五十亿次。

 

但你往外看——就只要离开它五米远——到处都是一大片未被开发的绿地。真的,到处都是。

 

DHH 说 95% 代码是手写的,但他又天天用 AI

 

主持人:David 你说 Fizzy 95% 的代码还是手写的,对吧?你每天都在用 AI。但对我来说,今年正好相反:我现在大概 90% 的代码都是 AI 写的。所以我的疑问是:如果你说你不怎么用 AI 写代码、或者 AI 不替你写代码——那生产力提升到底从哪里来?尤其对一家小公司来说,比如给美发店做软件,它不需要庞大的客服团队,也不需要很多外围部门,核心就是把软件做出来、交付出来。所以你觉得 AI 让软件开发更快的关键在哪里?

 

DHH:我说说我自己的体验——从这波 AI 开始我就一直在用。

 

我的生产力提升,主要来自:它让我更强、更聪明、更快——

  • 更快上手新 API、新技术

  • 更快理解新概念(我会让 AI 解释给我听)

  • 更快找到“为什么这个 bug 会这样”的正确线索

 

比如 Omarchy 这个项目,如果没有 AI,它就不会存在。我不会有耐心去 Linux 论坛里翻半天,去解读那些晦涩的错误信息到底是什么意思。这对我来说不可能。

 

AI 带来的巨大提升,是给了我一个地方,把错误信息贴进去,然后得到比那种居高临下、还过时三年的 Stack Overflow 回答更好的线索。

 

收益巨大。真的巨大。

 

还有我需要读某个东西时、学习某个东西时,它也很有帮助。举个快例子:我们最近把 Rails 的 CSRF 防护机制改了——从以前“把 token 放进 cookie”的方式,改成使用现代浏览器的新特性:通过一个 header 来做。

 

我可以直接问 AI:“那个 header 是什么?”“什么时候开始支持的?”“具体有哪些细节?”这些答案我当然也能手动查:去 caniuse.com、看历史、查 RFC……全都能做。但 AI 能把这些东西一盘端上来,整合在一起,省事又快。

 

“AI 只是让我变聪明了”

 

我能更快学到更多东西。而这正是我真正喜欢的地方:不是让 AI 替我做事,而是用 AI让我更聪明

 

当然,这种模式未来未必会成为主流。

 

就像你说的,你已经让 AI 写很多代码,甚至多数代码。我完全准备好在某个时点,我也会进入那种状态。

 

但就现在而言,我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。

 

这可能是一种“奢侈”,有点像现代的马鞍匠:他会在意字母压得是否刚好、针脚是否完美。你可以说:“但你已经不是交通运输的主力生产体系了。”我会说:那又怎样?只要我还享受,我就会继续做我手写代码的“马鞍”。

 

而且我也意识到:这种模式目前仍然是有竞争力的。

 

在 37signals,我们并不觉得自己在产出能力、发布能力、改进能力上落后。因此我对一些说法保持怀疑:“AI 已经强到可以把标准 SaaS 公司的一半程序员裁掉,还能跑得更快。”我没看到。

 

我当年也用同一套“根本测试”来审视云计算:“我们能不能用更少的人、花更少的钱,做更多的事?”我们几年前退出云,就是因为这个测试没有通过。而且我也不太听说这个测试在别处通过过。云计算并没有让你把运维团队砍半、把基础设施预算砍半。很多时候恰恰相反:上云之后团队规模翻倍,账单翻四倍。

 

主持人:你们切换之后是不是省了类似每月一百万美元?很夸张的数字?

 

DHH:我们现在大概是一年省200 万美元。我们云预算峰值大概是 340 万美元,现在的持续成本在 100 多万美元左右。所以在成本上,节省非常巨大。

 

这和 AI 有一些相似之处——不完全相同,但有相似之处:我觉得现在很多人在用 AI,脑子里觉得自己“好高产”,但他们其实交付更少、做出来的东西更少,甚至理解得更少。

 

“Vibe Coding”的风险:能力会从指尖流走

DHH:AI 还有另一个因素:当我尝试“氛围式写代码”(vibe coding)的时候——尤其在一个我还没完全内化的新领域——我能明显感觉到我的能力在从指尖滴走。

 

我刚开始做 Omarchy 时,写了很多 bash。我以前从没系统写过大量 bash,最多就是命令行里用用。然后我发现自己一次又一次问 AI:“某个 if 条件到底怎么写?”

 

这时你就会想:“为什么我没有内化这件事?我没内化,是因为我把它外包给 AI 了。”那这样更好吗?我现在更划算了吗?还是说,我跟当年那些老师一样天真:他们以为有了计算器,学生就不需要背乘法表了?不对。如果你不能迅速在脑子里算出 7×7,你真的会把自己变成傻子。

 

主持人:那你有没有形成一种直觉:该在哪里划线?你不可能知道一切,对吧?你也会把你不会的事交给信任的同事去做,你不会因为让同事设计某个东西就觉得“能力在流失”。你能接受:“这事我不需要会 / 我不想会”。那在 2025 这样疯狂的一年里,你有没有更清晰的边界:哪些你想自己掌握、哪些你可以忽略?比如 bash。为了推进 Omarchy,你觉得 bash 该学到什么程度?又有哪些可以不学?

 

DHH:我觉得我得会几乎全部,除了怎么在 bash 里搞数组(笑)。因为 bash 里数组那玩意儿复杂得离谱,简直反人类。但我其实认为:人类大脑是个很惊人的器官,它不会像 LLM 那样“容量到顶就装不下”。我们用得越多,记忆和能力的“配额”会增长。

 

所以我真正担心的趋势是:随着时间推移,我知道得更少、我变得更不胜任。我需要一条向上增长的移动平均线。

 

我不需要把所有领域都吞进去——我不需要什么都懂。但一年结束时,我应该在更多领域懂得更多。如果我不在这种上升轨道上,我会无聊。我无聊就会没动力。没动力我就什么也不干。这也是 AI 讨论的一部分:我们得想清楚,我们真正享受这套方程式里的哪一部分。

 

我个人不享受当项目经理。我会做——而且不止偶尔——因为我想要“组织一群人”能产出的结果。

 

但当我看 AI 这件事时,我不想当一群 AI agent 的项目经理。那不是我想要的状态。

 

我喜欢写代码。而至少在此时此刻,这是一个仍然有竞争力的选择。

 

当然,这可能三个月后就变了;下周就变了;随时都可能变。但 AI 公司那些领袖已经预言“再过五分钟就结束了”预言了很久了——现在也没结束。

 

你看 AI 公司自己,它们也还在招聘大量程序员。

 

我们并没有到 AGI,没有到那种“人类写代码的时代死了”的程度。

 

这并不否认你说的:有些程序员已经觉得自己大多数代码都让 AI 写了。但至少在市场上——按我看到的情况——还没有出现那种“压倒性差距”,就像:一个公司用马车送啤酒,另一个公司用卡车送啤酒。那种经济差距会非常快把前者淘汰。我还没在 AI 身上看到这种情况。也许数据有滞后;也许已经发生了——我仍然怀疑。

 

即便我在长期上是极度“AI 乐观派”,但就当下,我没看到。

 

有时神得离谱,有时烂得没法维护

 

DHH:而且原因之一是:我每天都在“盯”着它。我一直在问 AI:你能给我写这段代码吗?

它会写。然后我会想:“不,我不喜欢这个。”“我甚至不想维护它。”“它做得还不如大多数初级程序员会被要求做到的水平。”

 

但偶尔,它也会给出另一种答案:我问它一个东西,它拼出来的结果让我震惊:“它怎么知道的?它怎么能把这些全部串起来?”那真的很惊人。

 

所以我感觉它像一个闪烁的灯泡:你在完全黑暗里,它突然一闪——你觉得“我什么都看见了”。两秒后,啪,又全黑。如果你能让这个灯泡稳定下来、一直亮着——那对人类当然是巨大的福音。

 

顺便说一句,我很喜欢美国的一点就是:美国把这个“闪烁灯泡”当成一种信仰——相信我们能把它变可靠,能到 AGI。现在大家就是一场巨大的押注:押注这一定会发生。即便我这么 AI 乐观,我仍然会对这种规模的“集体确信”感到惊叹:一个经济体一起说: “不管花多少代价,100 万亿、1000 万亿,我不在乎,我们一定能到那里。”我会想:这也许就是为什么它会成为“第一名”。

 

主持人:确实是个令人兴奋的时代。就像你说的——能活在此时此刻本身就是一种奇迹。我们也差不多到一小时的时间上限了。今天能和你重新连上线真的很开心,感谢你抽时间来。你现在也在忙 Fizzy。要不你简单跟大家说说:Fizzy 是什么?在哪能了解更多?然后我们就收尾。

 

DHH:当然。Fizzy 在fizzy.do。它是对 Kanban(看板)的一个全新诠释。这里还有个小故事:Jason 特别擅长解释“为什么值得回头重新解决一个问题”。

 

Kanban 这个概念来自 50 年代,是丰田为了管理生产线提出来的。后来我们把它做成了软件。第一代软件化的版本大概是 2000 年初。再后来 Trello 出现,把这个领域彻底带火、带爆。但我们还是回到这个领域,说:“你知道吗?我觉得我们还能做一个更好、更舒服的版本。”

 

很多人很难理解软件这件事:明明一个问题领域已经有很多玩家了,为什么你还要进去?原因可能只是:你想做得更好、更有趣、更轻量、更丰富多彩、更令人愉悦、功能更少——这些带着“爱”的细节,我们都烘焙进了 Fizzy。而且我们把它定价得很便宜:1000 张卡片免费,之后是 每月 20 美元。同时我们也把整个代码库开源了:如果你想自托管(self-host),你可以免费用。服务器我们不替你付,你自己折腾就行。你也可以贡献代码,也可以从中学习。

 

做 Fizzy 是一件很快乐的事,而且它也像一个实验室。我们现在正在做 Basecamp 5。我们在 Fizzy 上尝试了很多新技术——不管是编程层面还是产品层面——我们会把最好的想法带回 Basecamp 5。如果你关心我对这些话题(或任何话题)的观点,你可以去 dhh.dk,我的东西都在那。

 

主持人:太棒了。很高兴你来做客,也迫不及待想看未来会发生什么。感谢你的时间,我们下期再见。

 

参考链接:

https://www.youtube.com/watch?v=uWqno4HM4xA

https://www.reddit.com/r/ClaudeCode/comments/1qhiicv/the_creator_of_nodejs_says_the_era_of_writing/

最近 V 站 各种小作文层出不穷,我也斗胆写一篇,给大家看个乐呵~

参考主题:小白,第一次去过商 K 后有点上头了怎么办

以下正文内容:

周五晚上 9 点,我还在工位上跟一个死活调不通的 API 接口死磕。PM (产品经理)突然拍了拍我的肩膀,说:“别写了,老大请客,去放松一下。”

我以为是去楼下吃顿烧烤,结果车子停在了“XX 商务会所”门口。看着那炫目的 RGB 灯效(虽然配色有点土),我心里瞬间拉响了警报。这种环境对我来说,比处理高并发场景还让人头秃。本能地想找借口撤退——“我回去改个 Bug”,但看着老大那不容置疑的眼神,为了团队的 KPI 和年终奖,我只能硬着头皮,像接受一个无法拒绝的 PR ( Pull Request )一样,走进了这个嘈杂的“生产环境”。

包间里,同事们已经开始“疯狂输出”,麦克风像是开了最大音量,疯狂 GC (垃圾回收)。我缩在沙发角落,像个被遗忘的守护进程( Daemon ),只想找个机会把自己 kill -9 了。

就在这时,包间门被推开了,进来了一排“实例”( Instances )。我本来正低头刷着 GitHub ,眼镜滑到了鼻尖,下意识地抬眼一推眼镜,CPU 瞬间飙到了 100%。

队列里第三个女孩,穿着一身剪裁得体的职业装,鼻梁上架着一副金丝眼镜,手里甚至拿着一个类似平板的东西(后来发现是点歌屏)。她的眼神犀利,表情冷静,像极了我们公司那位以“逻辑严谨、气场强大”著称的产品总监。那一瞬间,我的内存里瞬间溢出了一行日志:“Exception in thread ‘main’:有人三分似 PM ,我便不敢吱声。”

意料之中,我指向了她。她在我身边坐下,没有那种刻意的娇嗔,只是微微点了点头,像是在确认一个需求。系统负载仿佛瞬间降低了一半,但心理压力却陡然增加。

我尴尬地搓了搓手,坦白道:“我不会玩骰子,我只会写代码。”她推了推眼镜,那眼神像是在进行一场需求评审,冷静地说:“没关系,我教你。规则很简单,就像梳理业务逻辑。你需要先定义需求(喊点数),然后进行风险评估(猜对方有什么),最后进行 A/B 测试(开盅验证)。”

于是,在那个充斥着噪音的“服务器”里,她耐心地给我讲解“吹牛”的底层逻辑。我学得很快,毕竟逻辑判断是我的强项,但我故意输了几把,只是想多听她用那种冷静、专业的口吻分析我的“逻辑漏洞”。

中途我去了一趟“释放内存”(洗手间),出来时,她竟然等在门口,手里递过来一张纸巾,就像给程序打了一个完美的补丁,动作干脆利落,没有任何多余的情感表达。回到座位,我的杯子空了,她立刻执行了 pourWater()方法,精准控制水量,不多不少;果盘里的西瓜被“GC”了,她又调用了 serveFruit()接口,水果摆放得整整齐齐,像是一份完美的 PRD (产品需求文档)。

我们聊了聊最近互联网的寒冬,聊了聊 AI 对行业的冲击。她的观点犀利,逻辑清晰,完全不像是在闲聊,更像是在进行一场头脑风暴。看着她冷静地处理着各种“需求”,再看看我自己——顶着三个月没理的、像乱码一样的头发,穿着印着公司 Logo 的冲锋衣,我心里不禁自嘲:真是难为这个“产品经理”了,要对我这么一个满是 Bug 的“客户端”进行用户访谈。

整个 Session (会话)期间,我们没有发生任何“越权访问”(亲密接触),甚至连 Handshake (握手)都没有。我知道,这一切都是基于 Session 的假象,数据不会持久化到数据库。她的专业是封装好的 API ,冷静是设计好的 UI 交互。

但那一刻,在这个高压的、天天与机器对话的生活里,这种“逻辑同频”的错觉,却让我产生了一种“内存泄漏”般的留恋。就像终于遇到了一个能把需求讲清楚的产品经理,虽然知道明天还要面对残酷的线上环境,但此刻的“高效协作”,却让人无比上头。

回到工位,看着满屏的代码,我敲下了今晚的第一行注释:

// 2026-01-09: 在非生产环境中,意外进行了一次完美的逻辑同步。

程序员中的超级“保守派”、Linux 之父Linus Torvalds,现在也用起了 AI 编程。

image

图源:GitHub

最近,Linus 在 GitHub 上悄悄上传了一个小项目。项目本身不大,但特别的是,它是他用一款谷歌系 AI 编程助手 进行 Vibe Coding 完成的。

这个仓库很快就被眼尖的网友挖了出来,目前已经收获了 1600+ 颗 Star

image

Linus 缔造的 Linux,与 Windows、macOS 一起,构成了当今计算世界的三大通用操作系统阵营之一。

不过他曾直言:“在过去将近 20 年里,我并没有从事编程工作。”这并不是他远离技术,而是早就从亲手写代码的人,转变成了为整个系统长期演进负责的人。

在这种角色下,这位老哥过去对“AI 帮你写代码”这套叙事,一直保持高度警惕甚至是嗤之以鼻——他关注重点的不是代码写得快不快,而是代码在多年之后是否还能被理解、维护和演进。

而现在,Linus 对 AI 编程的态度可谓是“大转弯”:不仅开始亲自尝试 Vibe Coding,还公开表示自己对这种方式“相当积极”。

这些事情的冲击力并不在于“AI 又进步了”,而在于连最不吃 AI 编程这一套的人,也开始松动了

反 AI 编程的“顽固派”们,也开始接受 Vibe Coding 了

在生成式 AI 席卷软件行业的当下,有这么一群特殊的 “顽固派”, 他们定义了现代计算机的技术基石,却曾长期对 AI 编程嗤之以鼻,甚至公开泼冷水。

比如 Linux 之父 Linus Torvalds、Java 之父 James Gosling、Redis 之父 antirez(Salvatore Sanfilippo),个个都是编程界的殿堂级人物。

但有意思的是,随着 AI 工具能力的突飞猛进,这群昔日的 “反 AI 先锋”,正以各自的方式重新划定 AI 的边界:有人有限度拥抱,有人批判中认可,还有人干脆彻底转身。

比如 Linus 老哥,之前对生成式 AI 一直保持观望的态度。

他并不否认 AI 的潜力,但极度厌恶围绕 AI 的过度炒作。在一次开源峰会上,他直言当前关于生成式 AI 的讨论“90% 是行销炒作,只有 10% 是现实”,并毫不掩饰自己的反感。正因为讨厌炒作,他选择在相当长一段时间内 主动忽略 AI 热潮

Linus 之前一直没有使用各种 AI 编程工具。不过,这并不代表他对新范式抱有敌意。相反,他对 Vibe Coding 总体持正面态度,只是并未急于亲自下场。

而现在,随着工具逐渐成熟、噪音开始下降,Linus 也终于对 Vibe Coding 上手了。

他用上了谷歌的智能体优先开发平台 Antigravity,靠 Vibe Coding 搞定了项目里的 Python 音频采样可视化工具。

从最初的 “搜索 + 照猫画虎”,到后来直接让 AI 写代码,甚至自定义组件,最终效果比他手写的还要好。

面对内核社区里 AI 生成补丁泛滥的争议,他的立场很清醒:问题不在于 AI 本身,而在于维护者是否真正理解代码、承担责任。在他眼里,AI 可以当帮手,但不能当甩手掌柜。

而 Redis 创始人 Salvatore Sanfilippo(网名:antirez) 的转变更具戏剧性。

这位以 “简洁、可预测” 为信仰的系统级程序员,曾固执地坚持一行行手写代码,对自动化工具保持高度警惕。

但最近,他公开抛出了一句颠覆自己过往理念的话:

“对于大多数项目而言,除非是为了娱乐,现在自己写代码已经不再明智了。”

image.png

让他改口的,是实打实的体验。

在使用 Claude Code 的过程中,他发现 AI 在极少人工干预的情况下,就能完成原本需要数周的系统级任务:修复 Redis 测试中的并发与时序问题、重写核心库、复现复杂的数据结构改动。

更夸张的是,他只提出需求,Claude Code 5 分钟就生成了一个 700 行的纯 C 库,用于 BERT 类嵌入模型推理,性能仅比 PyTorch 慢约 15%;而他耗时数周完成的 Redis Streams 内部改动,AI 根据设计文档,20 分钟便复刻完成。

他坦言,对抗浪潮没什么意义,不如主动拥抱:

“忽略人工智能对你或你的职业生涯都没有好处。花几周时间仔细研究,而不是五分钟浅尝辄止。”

但 antirez 强调,这不是编程乐趣的终结,而是转移:“真正有趣的事情,已经从‘如何写代码’,变成了‘要做什么、为什么这样做’。”

当然,这位技术极客也没丢掉警惕性。他担忧 AI 技术的集中化风险。少数公司掌握核心能力,可能引发程序员失业、技术权力失衡等问题。

相比前两位,Java 之父 James Gosling 的态度要尖锐得多。他多次炮轰,当前的 AI 热潮 “基本上是一场骗局”,AI 已经沦为“自带误导属性的营销术语”。

在他看来,生成式 AI 编程的本质,不过是对已有代码和模式的重组,根本谈不上真正的创造力。那些看起来惊艳的演示,一旦碰上复杂项目就露馅:“刚开始接触氛围编程,会觉得它特别酷炫。可一旦项目变得稍微复杂一点,氛围编程就会很快耗尽开发者的脑力。”

Gosling 的核心质疑点很明确:AI 只能复刻见过的代码,但专业软件开发的精髓,在于开拓性的创新 —— 这些内容从来不在现成的代码库里。

不过,他也没把话说死。他承认 AI 技术背后的数学与统计原理很复杂,也认可它的实用价值,不是取代程序员,而是 “生成没人愿意去写的文档”,或者解释现有代码的功能。说到底,AI 更像一个智能搜索引擎,而非编程大神。

他还不忘吐槽一把资本:“科技行业里骗子和炒作者的数量之多,令人难以置信。风险投资者只关心成功获利,而不是开发出真正有用的技术。” 他甚至预言,“绝大多数 AI 投资都会被烧个精光。”

说到底,这三位大佬的转变,都不是向 AI “投降”。

他们认可的,是 AI 在重复劳动上的效率;他们坚守的,是人类程序员不可替代的核心价值,对复杂系统的理解、对工程架构的判断、对长期维护的责任,以及开拓性的创新能力。

对 Linux 内核开发,Vibe Coding 还欠火候

需要说明的是,虽然 Linus 现在对 Vibe Coding 的态度很积极,但他也直言称,这种方式 并不适用于 Linux 内核开发

一个重要原因在于,今天的计算机系统早已比他学习编程的年代复杂得多。Linus 曾回忆,当年他接触的一些输入程序,甚至是从计算机杂志上照着敲下来的。

虽然他已经很久没有深度参与具体功能编程,长期为整个内核的演进负责。在他的“系统维护者”视角下,稳定性、安全性和可维护性,远比“写得快不快”更重要。

这一点,其实在他最近上传到 GitHub 的那个项目里有所体现:AI 主要写的只是对 Python 可视化工具部分,核心 C 语言部分(音频效果的数字信号处理等)还是他亲自写的。

在 Linus 看来,Vibe Coding 在小项目和探索性场景中确实优势明显:进入门槛低、反馈速度快,能迅速把模糊的想法变成可运行的程序,用来生成样板代码、辅助脚本,或者“先跑起来看看”,都非常合适。

但这种方式的短板同样明显——生成代码往往风格不稳定、抽象边界模糊、依赖隐性假设,短期能用,长期却很难维护。

而 Linux 内核,恰恰是一个对“可维护性”极端苛刻的系统:代码需要被不同年代、不同背景的维护者反复阅读、修改和重构,任何一次“看起来省事”的生成式决策,都可能变成未来十年的技术债。

不过话说回来,即便不能“全靠 AI 写代码”,“部分交给 AI”本身,就已经在重塑程序员的工作方式

在另一条时间线上,有些工程师甚至已经开始用 AI 来开发 AI 本身。

比如 Boris Cherny。作为 Anthropic 工程师、也是 Claude Code 的创造者,他已经几乎不再以传统方式写代码了,而是把自己打造的 AI 编程工具玩儿出了花:

他让 Claude Code 自己参与开发自己,然后竟在一年内完成了 1096 提交。

image

这个工具已成为全球最受欢迎的 AI 编程工具之一,去年还给 Boris 带来了超过 10 亿美元(约合人民币 70 亿元) 的收入。

参考链接:

https://github.com/torvalds/AudioNoise

https://www.theregister.com/2025/11/18/linus\_torvalds\_vibe\_coding/

https://antirez.com/news/158

https://www.bnext.com.tw/article/81200/linus-torvalds-gen-ai-bubble

https://x.com/bcherny/status/2009072293826453669

首先你需要找到一个蛇头,在本论坛就有,他/她负责接单,你负责搬砖,如果找不到可以去留学生论坛去以“作业辅导”的名义发帖,然后小红书是一个非常重要的宣传口,里面巨多富哥富姐
作业的内容千奇百怪,不过最好你只接本专业的,比如我是数学系,我接了很多统计学的,然后我本人是程序员,也接了很多开发任务,有时甚至有回头客

薪资方面,基本上 3-500 一小时,遇到土豪老板 700 一小时也是有的

需要注意的是,很多作业是不让用 AI 的,所以不要用 AI 去糊弄然后翻车,你可以遇到不会的用 AI 自学,然后手写
另外富哥们一般都是 deadline 前几天才出来找枪手,所以你的时间会非常紧张,不要浪费时间

nature 是一款较新的编程语言,其轻量简单,易于学习。在设计理念和运行时架构上参考了 golang ,同时有着更丰富的语法特性,更适用于业务开发,并在持续探索更广泛的应用领域。

性能是衡量编程语言核心竞争力的关键指标,接下来我们将从 IO 并发、CPU 计算、C 语言 FFI 、协程性能四个维度,并以 golang 作为基准对 nature 编程语言进行性能测试。

测试环境

配置项详情
宿主机Apple Mac mini M4 ,16GB 内存
测试环境Linux 虚拟机( Ubuntu 6.17.8 ,aarch64 架构)
编译器 / 运行时版本Nature:v0.7.0 ( release build 2025-12-15 )
Golang:go1.23.4 linux/arm64
Rust:cargo 1.85.0
Node.js:v20.16.0

所有测试均采用相同的代码逻辑实现,文中代码示例均以 nature 编程语言为例。

IO 并发

IO 并发是网络服务的核心能力,本测试通过 HTTP 服务端压力测试,综合考察语言的 IO 调度、CPU 利用率与 GC 稳定性。

nature 代码示例

import http  
  
fn main() {  
    var app = http.server()  
  
    app.get('/', fn( http.request_t req, ptr<http.response_t> res):void! {  
        res.send('hello nature')  
    })  
  
    app.listen(8888)  
}

ab 工具测试命令

ab -n 100000 -c 1000 http://127.0.0.1:8888/
  • -n 100000: 总请求数 10 万次
  • -c 1000: 并发数 1000

测试结果

Nature vs Golang: 性能基准测试3

可以看到 nature 在 HTTP 并发性能上超越了 golang ,这对于早期版本的编程语言来说可以说是不错的成绩。

由于 nature 和 node.js 均使用 libuv 作为 IO 后端,所以 node.js 也参与到基准测试中(libuv 线程不安全,node.js 和 nature 的事件循环均在单线程中运行),但 nature 作为编译型语言其并发处理能力远胜过 node.js 。

CPU 计算

使用经典的递归斐波那契数列计算 fib(45) 来测试语言的 CPU 计算与高频函数调用开销。

nature 代码示例

fn fib(int n):int {
    if (n <= 1) {
        return n
    }
    
    return fib(n - 1) + fib(n - 2)
}

测试方法

time ./main
1134903170./main  2.50s user 0.01s system 101% cpu 2.473 total

测试结果:

Nature vs Golang: 性能基准测试2

nature 和 golang 均采用自研的编译器后端,性能上也相差无几。而耗时高于 rust 的主要原因之一是两者在函数运行前进行了额外处理。

golang 采用了抢占式调度,不需要关注 GC safepoint ,但仍需要关注协程栈是否需要扩容,也就是下面的汇编指令

nature 采用了协作式调度,所以需要处理 GC safepoint 。但 nature 采用共享栈协程,所以不需要关心栈扩容问题。

nature 的 safepoint 实现仍有优化空间,若后续采用 SIGSEGV 的触发模式,函数调用性能将会得到进一步提升。

nature 和 golang 采用了截然不同的调度策略和协程设计方案,这会带来哪些不同呢?不妨看看后续的测试 👇

C 语言 FFI

通过调用 1 亿次 C 标准库中的 sqrt 函数,测试与 C 语言的协作效率。

nature 代码示例

import libc  
  
fn main() {  
    for int i = 0; i < 100000000; i+=1 {  
        var r = libc.sqrt(4)  
    }  
}

测试结果

Nature vs Golang: 性能基准测试1

可以看到在 C FFI 方面,nature 相较于 golang 有着非常大的优势,这是因为 golang 的 CGO 模块有着非常高的性能成本,独立栈协程和抢占式调度设计与 C 语言难以兼容,需要经过复杂的处理。

而 nature 的共享栈和协作式调度设计与 C 语言更兼容,不仅仅是 C 语言,只要符合 ABI 规范的二进制库,nature 都能直接进行调用。

在高性能计算、底层硬件操作等场景中,nature 可无缝集成 C / 汇编编写的核心模块,弥补 GC 语言在极致性能场景下的不足,兼顾开发效率与底层性能。

协程

协程是现代并发编程的核心组件,本测试通过 “百万协程创建 + 切换 + 简单计算” 场景,评估 Nature 与 Golang 的协程调度效率、内存占用与响应速度。

nature 代码示例

import time  
import co  
  
var count = 0  
  
fn sum_co() {  
    count += 1  
    co.sleep(10000)  // ms, Remove this line if no sleep
}  
  
fn main() {  
    var start = time.now().ms_timestamp()  
    for int i = 0; i < 1000000; i+=1 {  
        go sum_co()  
    }  
  
    println(time.now().ms_timestamp() - start)  // create time
    
    int prev_count = 0  
    for prev_count != count {  
        println(time.now().ms_timestamp() - start, count)  
        prev_count = count  
        co.sleep(10)  
    }  
    println(time.now().ms_timestamp() - 10 - start) // calc time
    co.sleep(3000) // ms
} 

测试结果

Nature vs Golang: 性能基准测试4

语言创建耗时(ms)计算耗时(ms)无 sleep 计算耗时(ms)占用内存
Nature540564170900+M
Golang100010151402500+M

nature 的协程在综合性能上非常优秀,内存占用更是远低于 golang 。而这是建立在 nature 的协程调度器未进行优化的前提下,预计在后续的版本中 nature 的协程调度器会进一步优化,届时将会有更加亮眼的表现。

总结

这是一次非专业的性能测试,但在粗略的测试中,nature 编程语言展现出了超越预期的能力与潜力。作为早期的编程语言,其运行时和编译器还有着非常大的优化空间,在正式版本发布时性能将进一步提升。

以现在的性能表现来看,nature 无疑是值得关注和尝试的编程语言,尤其是在云原生、网络服务、API 开发等服务端开发领域。


这是 nature 编程语言的官网 https://nature-lang.cn/ 如果你感兴趣的话也可以加入讨论组,v ➡️ nature-lang


📌 转载信息
原作者:
weiwenhao
转载时间:
2025/12/26 11:46:26

先来看下,近几年大厂发生的几个影响较大的运营事故:

这几起事件的共同点:影响范围广、故障时间长、造成非常负面的舆论影响;

这次快手的事情,还是远远超出了我的想象,服务故障只会影响正常使用,但是被攻击进而导致了大面积非法活动;对于监管来说,没有比这更严重的事情,属于妥妥的红线


为什么会发生

黑客、灰产,从互联网诞生之初,就一直存在,今天我们不去讨论黑客如何操作大规模账号、如何进行的实名认证,我们从开发这个角度去考虑,怎样去避免事件的发生?

直播和视频播放不一样,它的内容属于实时产生,平台没有办法提前审核;因此直播平台建设怎样的审核机制,就关系平台能否控制用户的直播内容。

大部分直播审核机制我们可以简化为上图:截取画面、音频等,通过模型自动化判定,然后再人工复审,最后处罚封禁。

瓶颈节点

在开发中,我们经常会提一个瓶颈节点的概念,意味着它决定着整个链路的承载量,如果它停止工作,则整个链路瘫痪。

而在上面的审核链路中,可以认为人工复审是一个瓶颈节点,因为人力是有限的;也许平时只需要 1000 个审核员既可以应对,但是当极端情况出现,同时涌现出上万个甚至更多非法直播时,这套机制自然就被攻破了。

我们可以猜测,黑客操作大量账号,同时开启非法直播,当部分账号被封禁后,又不停的新增非法账号直播,人工复审节点一直处于过载状态,没办法处理全部的审核。


可能的解决方式

假设我们按照上图的审核机制,怎样优化可以解决同时出现大量非法直播的问题呢?

自动判定节点

根据模型分析结果,辅助额外账号信息,自动判定是否需要“二次人工复审”,对于不需要的案例,直接处罚。当然自动判定存在误判的风险,而快手这次事件,可以看到大部分直播是常规的淫秽视频,通过模型辅助账号信息是可以精确判定的。

为了让自动判定足够精确,我们需要做些什么?

  • 模型不断训练更加精准
  • 收集更多维度信息,账号活跃度、登录 ip 、设备等等风控数据

目的

减轻“人工复审”节点的压力,使它不再是瓶颈节点,是我们的最终目的,毕竟其他节点都可以通过扩容的方式解决。也许自动判定可能会存在误判的情形,但是我们可以不断优化,不断减少误判的概率。

思考

小概率事件

对快手而言,“同时出现大规模非法直播”是一个小概率事件,在它们设计审核机制时,可能也有考虑到过?但是可能认为“几万人同时直播黄片”是几乎不可能出现的事情,因此并没有做预案。

在互联网领域,尤其是后端模块,海量用户+长时间运行,任何小概率 bug 都演变成必然触发;如果没有完美解决方案,则往往可以采取有损的妥协折中方案。

欢迎快手同学现身说法!

最后宣传下自己的技术公众号:欢迎关注,讨论交流


📌 转载信息
原作者:
youngxxx
转载时间:
2025/12/26 11:44:45

  序言

  成为php开发职员,很长一段时间以来,很多人始终在使用md5哈希算法来保护密钥数据并生成唯一的哈希算法。但是你应当或多或少看见过,md5不再安全了!

  PHP5.5中有一些密钥身份验证替代方案,即sha1,?为什么被觉得更安全?应当如何选用?

  学习时间

  这些研究论文尚未证明过了,md5计算出的哈希值可以被反向。我们也应当完全中止使用。论文的名子也十分具有冲击力《HowtoBreakMD5andOtherHash》,演示了整个逆向的过程,可谓触目惊心,看的我瑟瑟发抖。

  破解php网站后台密码

  成为升级版的用法破解php网站后台密码函数安全系数足够强大到抵挡一段时间的破译。在PHP5.5中可以安心使用。后来加入到标准库中的crypt函数,则把安全级别向前推动了一大步。

  首先举例说明一下的用法:

   $options = [

    <p>![破解php网站后台密码][2]

        &#39;cost&#39; => 12,
    ];


  也有使用算法的crypt密码生成:

   if (CRYPT_BLOWFISH == 1) {

        echo &#39;Blowfish:     &#39; . crypt(&#39;rasmuslerdorf&#39;, &#39;$2a$07$usesomesillystringforsalt#39;) . "\n";

  还是那句话,PHP都打算好函数了,用法极为简略高效,等着研发者开箱即用呢。

  破解php网站后台密码

  深入一步

  为什么坚决不能再用md5了?

  由于例如MD5网络培训脚本插件,SHA1和等等的哈希算法被设计为十分迅速和高效。随着现代科技和计算机设施的发生黑客纯情,“暴力破解”所须要的时间愈发越短。由于现代计算机“逆向”这些哈希算法的速率很快,因此许多安全专业员工强烈建议不要将其适于密码哈希。

  为什么PHP5.5中推介使用导数?

  在对密钥进行哈希处理时,两个最重要的考量原因是估算量和学费。哈希算法在估算上越高昂,对它进行暴力破解所耗费的时间就越长。PHP5.5提供了一个本机密码哈希API,就是(),可以安全地安全处置哈希和验证密钥。

  写在最终

  计算机软件的突飞猛进,使得本来还要长期的时间和费用就能进行的破译工作周期大为减短。在硬件层面培训脚本,我们势必要跟得上节奏,才能确保在一段时间内的安全。

  此外,PHP提供的方程如此高效破解php网站后台密码,简单,有哪些原因不用呢!

  Happy:_)

  我是@程序员小助手,持续分享编程知识,欢迎关注。

  记者|孙文豪

  编辑|

  4月15日中午,破解百度云盘的研发者受审的喜讯登上微博热搜。

  据无锡网警官方查处,宝应县网安抓获一起黑客攻击计算机信息平台案件。通报表示,今年2月接到被害人刘谋的举报,称其使用后,百度云盘上的相关隐私信息受到泄露。

  宝应警方知道到该硬件可以以非会员权限实现百度云盘资源的高架下载,致使百度公司损失高达上千亿元。4月初,警方于江苏抓捕贩毒嫌疑人蔡某萌,并扣押其作案工具。经查,该硬件研发者共非法获利30万余元。

  最初于2017年开播,是最早一批破解百度云盘的相关硬件。据认识黑客吧百度贴吧,使用方式并不复杂,用相机进行扫码登录后就可同步进行百度云盘中的文件下载、分享、删除等操作。

  黑客吧百度贴吧

  用户在没有搜狗会员权限状况下,可以自如进行文件在线解压,且可以进行多任务不限速同时下载。据网民反映,下载速率通常在1M/s以上,执行单任务下载时流速甚至可以超过10M/s。且具有百度云资源搜索用途黑客吧百度贴吧,可直接搜索百度云盘资源进行下载。

  据认识,目前设计者研发出适应、安卓和iOS多个平台版本。据交警通报,其使用者长达数千人。界面新闻记者看到,百度贴吧社区关注者长达3万余人。

  对于警方查处的违法泄漏用户在搜狗网盘信息一事,界面新闻记者看到、2019年8月就有顾客在知乎等居委反映使用后遭受隐私泄漏等状况,但始终没有给与正面否认。

  介面新闻知道到,曾于今年9月其间遭受限速,此后一度恢复。随后又于明年3月下旬宣布暂停服务,声称一周内修复,但自此经常无法正常运转。4月15日晚,已经完全中止服务,且其官网网站未能开启。界面新闻就此事问询百度,截至发稿,百度表示对此事暂无官方否认。

找海外工作很重要的一个要求语言过关,根据国家的不同,对语言的要求也不同,英语国家当然英语就足够了,有的欧洲国家公司还会要求你掌握当地语言,如果你不会,那投递简历时就可以跳过这些公司了。本文谈一谈我的英语学习经验,仅供参考。英语主要分为听说读写四个方面,下面就分开写一写我的经验。

听力

要提高听力,没有别的办法,就是要多听,就可以提高自己的听力水平,不要相信什么灵丹妙药,不存在的。大学的时候,试过听 BBC 英语,然后尝试自己去把听到的东西转译成文字,这样能够确保自己听懂了,这种方式比较浪费时间,不过对听力的提升我认为是有帮助的。

我还尝试过看电影或者电视去提高听力,但是个人感觉效果很有限,美剧或者电影,角色讲话速度一般较快,难以跟上,另外经常会被剧情吸引,专注不到听力本身,有的电视剧或者电影字幕都是内嵌的,看着看着就开始看字幕了,总之这种方式在我身上收效甚微。

另外一种方式是直接看 YouTube 视频,这是我推荐的方式。研究生毕业的时候,我的听力水平还不高,后面提升听力,就主要是通过看 YouTube 视频,自己感兴趣的内容,各种话题,各种口音的英语内容都会去看,接收了大量听力内容的洗礼。关于口音,一般美国人或者英国人纯正的英语只要速度不是非常快,都比较容易懂,印度英语带口音,就比较难懂,欧洲人英语速度一般不是很快,也容易听懂。另外 YouTube 可以开倍速,用 1.25 或者 1.5 倍速度放视频,如果你不看自动字幕听起来无压力,那你的英语水平应对面试没问题。

如果喜欢听 podcast ,也可以使用 spotify 或者其他 app 听科技播客,也是不错的提升听力的方式。不过很多 podcast 没有字幕,如果听力水平不行,听起来会比较吃力。

口语

在开始面试之前,其实我也没有专门练习过口语。如果经常听英语,对口语也会有帮助,你下意识就会知道怎么去应对,怎么说话。

如果需要练习口语,可以在网上找母语是英语的外国人聊天。有一些付费的软件,例如 cambly ,也可以从淘宝上找付费的外教练习口语。当然也有一些免费的语言交换,推荐 reddit 的 language exchange 板块,可以在上面找到一些练习语言的伙伴。

口语的目的是要让自己的表达被别人听懂,而不是自己的口音有多么的纯正,国人经常犯这个错误,批评别人的口音,其实毫无意义。流利的表达比纯正的美音或者英音更重要。

阅读

英语阅读是长期积累,不可能短期提升。看一些自己感兴趣的英文书可以提升自己的英语阅读能力,推荐非虚构类作品,例如名人传记类,历史类,科学类。不推荐阅读英语原著小说,小说通常阅读难度要更大,而且有不少生单词,经常遇到生单词会挫败人的阅读乐趣。

阅读工具,推荐使用电子产品( iPad ,kindle 等),而不是使用书,使用电子产品如果遇到不懂的单词可以随时查字典,很方便,也可以加入到自己的生词本,书用起来就很麻烦。

写作

我提升写作的经验就是多写,一般遇到技术问题,我都会用英语写成文章放到自己的博客上面,经常输出,就会逐渐提升自己的写作速度和水平。如果担心语法不过关,可以用 grammarly 检查。

工作

对于程序员来说,日常工作也要尽可能使用英语,不会用英语的程序员不是好程序员。大量的最新的技术都是用英语写成,中文互联网的质量堪忧,平时搜索问题都是使用英语的机会。

在 GitHub 上提问或者回答别人的问题,也都需要使用英语,都是锻炼自己英语的机会。

原文发布于 https://jdhao.github.io/2023/02/18/work_overseas_english/