泥潭日报 uscardforum · 每日精选

感觉码农这个职业要消失了。。

内容摘要

AI 编程能力飞速发展,正颠覆传统码农工作流程,人类价值向问题定义、AI 指导和软技能转移,但复杂算法、深层逻辑和创造性工作仍是 AI 的瓶颈,职业转型与能力升级成为必然。

1. 关键信息

  • (之前已归纳)AI 编程能力飞速提升: 最新 AI 模型(如 Claude 4.5/5.2)在编写代码、调试和理解大规模代码方面已超越大部分初级和中级工程师(IC3/IC4),效率呈指数级提升。
  • (之前已归纳)工作流颠覆: 传统流程正被“方向 -> AI Agent 验证/设计/实现”取代。
  • (之前已归纳)核心竞争力转移:: 码农的价值将从“写代码”转向“定义问题”、“提出高质量 Prompt”和“跨领域整合能力”。
  • (之前已归纳)AI 对复杂系统的影响: 一部分人认为 AI 擅长理解和重构遗留系统(屎山),另一部分人认为 AI 在处理超大上下文、结构性搜索和复杂算法(如 C++ 模板元编程)时仍有缺陷。
  • (之前已归纳)LLM 局限性: 幻觉、错误传播、缺乏直觉和对物理世界/业务深层逻辑的理解(如 On-call 经验判断)是当前痛点。
  • (之前已归纳)“创造新知识”的讨论深化: 新增回复指出,人类创造新数学概念往往是为了解决物理问题,而 AI 目前的思维链长度(Token 限制)和算力架构可能难以支撑实现“orders of magnitude”级别的复杂、长思维链的创新。
  • (之前已归纳)专业知识的壁垒: 新增回复中出现了关于“非交换几何”的讨论,表明在高度专业化、抽象的数学/理论领域,AI 尚未能完全替代人类的深度理解和创新能力。
  • (之前已归纳)AI 模型机制探讨: 新增回复讨论了 OpenAI 模型中“hallucinate”(幻觉)的产生机制,推测可能与 eval reward(评估奖励)而非 training weight(训练权重)相关,暗示了模型对齐和输出质量的内在机制问题。
  • (之前已归纳)直觉与高精度差异: 新增回复强调,即使 AI 达到 99.999…% 的准确率,它与人类的“直觉判断”仍有本质区别,尤其是在需要深层理解和经验积累的场景。
  • (之前已归纳)基础理论的不可替代性: 新增回复(447楼)列举了虚数、傅立叶变换、群论、杨米尔斯理论、概率论公理化等一系列数学和物理学的基石概念,暗示这些理论的创造和深层理解是人类智慧的体现,AI 目前难以在这些基础层面进行真正的“创造”。
  • (之前已归纳)AI 流程的成熟化与质量提升: 新增回复(448楼)指出,公司内部使用 AI 已经非常成熟(mature),引入了多重 AI Review Guideline、多个不同 AI 模型交叉审查代码,并通过严格的 CI/CD 门禁(卡住不让过),反而使得代码质量比以往更高。
  • (之前已归纳)软技能的重要性: 新增回复强调在大厂环境中培养如跨团队协作(alignment)、说服他人、项目推动(drive project)等软技能的重要性,认为这些是可迁移的宝贵能力。
  • (之前已归纳)前端开发AI应用现状: 有用户提问关于AI在前端开发中的应用效果,并认为目前AI在前端方面“还差点意思”。
  • (之前已归纳)AI对前端开发的早期影响: 有用户回忆,AI编程最早影响的领域就是前端开发。
  • (之前已归纳)AI在简单网页开发中的优势: 简单网页的开发目前已被AI“暴杀”,效率极高。
  • (之前已归纳)AI在性能优化领域的未知性: 对于更复杂的性能优化任务,AI的能力尚不明确。
  • Human Data 的突破将消除瓶颈: 新增回复指出,如果“human data”(人类数据)方面取得突破,将可能消除 AI 在某些领域的瓶颈。

2. 羊毛/优惠信息

3. 最新动态

  • (之前已归纳)微软正在内部高强度采用 Claude Code。
  • (之前已归纳)顶级工程师(如 Andrej Karpathy)的编程方式已迅速转变为主要使用英语描述需求(Vibe Coding)。
  • (之前已归纳)围绕数学史(如黎曼几何与相对论的时间差)的讨论,侧面反映了对AI理解历史和知识演进深度的探讨。
  • (之前已归纳)AI 质量保障流程固化: AI 生成的代码正在被纳入更严格的、多模型参与的审查流程中,以确保质量达标。
  • (之前已归纳)职业未来比喻: 有用户以游戏中的“开放新团本”来比喻码农职业所面临的新挑战和新阶段,表达了一种轻松看待未来变化的姿态。
  • (新增)Human Data 的重要性被提及: 新增回复强调了“human data”在 AI 发展中的关键作用,暗示了其潜在的突破性影响。

4. 争议或不同意见

  • (之前已归纳)替代速度与范围: 观点分歧在于 AI 淘汰速度,有人认为短期内(6-12 个月)大量工作将消失,有人认为淘汰是渐进式的,AI 暂时无法处理需要深层逻辑推理和创新(创造新知识)的任务。
  • (之前已归纳)AI 质量: 存在用户认为 AI 生成代码需要大量修正,而另一些用户(尤其是 Claude Code 用户)声称 95% 的代码可由 AI 一步到位生成。
  • (之前已归纳)理论与工程的差距: 新增回复强调,虽然理论上 AI 可以创造新概念,但工程实现难度极大,受限于当前算力和架构对长思维链的支持能力。
  • (之前已归纳)ID的随机性: 针对“非交换几何”的讨论,ID为“非交换几何”的用户明确表示ID是随机起的,与专业背景无关,澄清了专业讨论的背景。
  • (之前已归纳)AI 机制争议: 关于幻觉的讨论涉及模型内部机制的理解(eval reward vs training weight),反映了用户对当前 LLM 局限性根源的探究。
  • (之前已归纳)人类基础理论贡献的独特性: 447楼的回复间接表明,在数学和物理学的核心理论创新方面,人类的贡献目前仍是AI无法企及的。
  • (之前已归纳)软技能实践的讽刺性: 针对培养软技能的建议,有回复以讽刺的口吻描述了这些技能在实际大厂操作中的“技巧”,如通过频繁会议实现对齐、通过层层上报说服团队、以及通过公开宣讲夸大影响力来推动项目,暗示了职场政治和效率的另一面。
  • (之前已归纳)AI在前端开发的有效性: 有用户认为AI在前端开发领域的表现尚未达到理想状态,暗示了AI在该领域的局限性或成熟度问题。
  • (之前已归纳)AI对前端开发的早期影响: 有用户回忆AI最早取代的是前端,这与当前讨论AI对码农整体职业的影响形成对比,暗示了AI影响的演进。
  • (新增)Human Data 的潜在影响: 新增回复提出的“human data”突破论,暗示了其可能对现有 AI 瓶颈产生颠覆性影响,但具体影响范围和方式仍是未知数。

5. 行动建议

  • (之前已归纳)打铁趁热,尽快学习 AI 工具: 尽快掌握 AI 工具的使用,将节省的时间用于提升高阶能力。
  • (之前已归纳)提升定义和沟通能力: 专注于提出清晰、有逻辑的问题(Prompt Engineering),这是未来稀缺的能力。
  • (之前已归纳)关注高阶能力: 避免沉溺于纯粹的编码工作,应向架构设计、产品决策和跨职能整合方向发展。
  • (之前已归纳)保持警惕: 对于涉及生产安全和核心业务逻辑的任务,人类仍需进行最终审查和承担责任。
  • (之前已归纳)关注思维链长度和算力瓶颈: 认识到当前 AI 在处理需要极长、复杂思维链的创新问题上存在架构性限制。
  • (之前已归纳)关注模型对齐: 留意 AI 幻觉的根源(如 eval reward 机制),这可能影响未来模型在关键任务中的可靠性。
  • (之前已归纳)适应流程变革: 准备好适应公司内部将 AI 审查固化到 CI/CD 流程中的新常态,并确保自己能通过这些更严格的自动化质量关卡。
  • (之前已归纳)培养软技能: 积极培养在大厂环境中至关重要的软技能,如跨团队沟通、说服能力和项目管理能力,以增强职业的可迁移性和竞争力。
  • (之前已归纳)关注AI在特定领域的进展: 留意AI技术在前端开发等具体技术栈上的发展和应用情况,评估其对自身工作的影响。
  • (之前已归纳)关注AI对前端开发的早期影响: 认识到AI技术对不同技术栈的影响是逐步深入的,并从中推测其对其他领域的影响。
  • (之前已归纳)密切关注AI在复杂编程任务上的进展: 持续关注AI在性能优化等更具挑战性领域的实际应用和突破,以便及时调整自身发展方向。
  • (新增)关注“Human Data”的进展: 留意“human data”在 AI 领域的研究和突破,这可能预示着新的发展方向和潜在的职业机会。
原始内容
--- 第 1 楼来自 Startrek 的回复 (2026-02-01 17:38:41 PST) ---

试了一下最新的ai coding,能力已经超过绝大部分的ic4 engineer了。唯一缺乏的是部分offline context,但是这种早晚也会拥有的。

留给码农的时间真不多了。

--- 第 2 楼来自 Sunshine9 的回复 (2026-02-01 17:39:16 PST) ---

那怎么办呢

--- 第 3 楼来自 Startrek 的回复 (2026-02-01 17:40:01 PST) ---

【引用自 Startrek】:
留给码农的时间真不多了。
打不过就加入,被影响到就是时间问题。

--- 第 4 楼来自 xds.sun 的回复 (2026-02-01 17:40:54 PST) ---

加入啥?

--- 第 5 楼来自 Lexus 的回复 (2026-02-01 17:40:56 PST) ---

L4还是有点保守了楼主

最新的人类学反华ceo预言是6-12个月所有swe job

--- 第 6 楼来自 杰拉之心 的回复 (2026-02-01 17:41:37 PST) ---

不明白。以后CEO自己写prompt做产品?

--- 第 7 楼来自 Labubu 的回复 (2026-02-01 17:42:32 PST) ---

那当然不可能 请十个清洁工扫地之余点一下就好了

--- 第 8 楼来自 Startrek 的回复 (2026-02-01 17:42:46 PST) ---

【引用自 杰拉之心】:
以后CEO自己写prompt做产品?
我觉得ic6肯定还需要的。因为大部分ic6也不是写代码的,现在真正的主力是ic5,ic3/4产出及其有限。

--- 第 9 楼来自 mariobar 的回复 (2026-02-01 17:43:21 PST) ---

第一反应是同意楼主结论,但是论证过程有点奇怪。

如果offline context是bottleneck的话,我怀疑在程序员成为昨日黄花前,会有别的岗位先被淘汰掉。

--- 第 10 楼来自 Startrek 的回复 (2026-02-01 17:44:17 PST) ---

【引用自 mariobar】:
,我怀疑在程序员成为昨日黄花前,会有别的岗位先被淘汰掉。
offline context就是老板的要求,但就单纯的产品逻辑,ai的理解宽度和深度超越大部分码农。

--- 第 11 楼来自 SheenaRingo 的回复 (2026-02-01 17:46:27 PST) ---

我ic4,agent coding的输出结果还是需要ic4检查的。。当然普通CRUD写写test确实不用junior和mid level去完成了

--- 第 12 楼来自 pix0 的回复 (2026-02-01 17:48:04 PST) ---

有handholding的情况下可以写出一些有用的东西,没有control很容易跑偏,有不少context engineering成分在。

楼主用没有用过ai debug legacy code?我觉得没有限定context window的情况下完全不能用。

--- 第 13 楼来自 Startrek 的回复 (2026-02-01 17:48:25 PST) ---

【引用自 SheenaRingo】:
agent coding的输出结果还是需要ic4检查的。。
之所以需要改90%的情况是prompt没有描述清楚,本质上是人的问题,不怪ai。

后一步大概率公司会把码农的所有history都输入给ai,这样ai就有了cross level的理解能力,估计ic6以下都没有存在必要了。

--- 第 14 楼来自 真的很需要 的回复 (2026-02-01 17:49:53 PST) ---

汽车出来了,拉黄包车的全去开汽车不就行了,着啥急

--- 第 15 楼来自 Startrek 的回复 (2026-02-01 17:50:47 PST) ---

【引用自 Lexus】:
6-12个月所有swe job
我觉得可能他指的是写代码的swe,应该不算夸张。公司里真正需要的是能领导产品方向的engineer+pm+ds的综合体,不是单纯的swe了。

--- 第 16 楼来自 Startrek 的回复 (2026-02-01 17:51:12 PST) ---

【引用自 真的很需要】:
汽车出来了
现在自动驾驶出来了,开汽车的做什么呢?之前黄包车换汽车,前提是需要人。这次是真不需要人了。

--- 第 17 楼来自 002 的回复 (2026-02-01 17:53:11 PST) ---

就是个高级自动补全工具 并没有任何智能 提高效率还是可以的

--- 第 18 楼来自 LoRA 的回复 (2026-02-01 17:54:52 PST) ---

【引用自 002】:
高级自动补全工具
真这么理解可能让你犯大错。ic3/4/5的工作本质上也是补全tl/em的任务。

--- 第 19 楼来自 真的很需要 的回复 (2026-02-01 17:55:17 PST) ---

token那么贵,所有公司都用吗?自动驾驶就算普及了,成本能降下来吗。汽车出来之前,有钱人坐黄包车,没钱人走路。汽车出来了之后,有钱人坐汽车,穷人坐黄包车。等到黄包车真淘汰了,都过去一百年了。

--- 第 20 楼来自 002 的回复 (2026-02-01 17:56:01 PST) ---

AI的Context不够的,问一点稍微复杂一点的问题就乱来了

--- 第 21 楼来自 LoRA 的回复 (2026-02-01 17:56:33 PST) ---

【引用自 真的很需要】:
token那么贵,
工业化最大的特点就是只要能量产那就marginal price就会无限接近0.

对成本的担心不过是产品出现早期供应链没跟上的暂时现象。

--- 第 22 楼来自 LoRA 的回复 (2026-02-01 17:57:58 PST) ---

【引用自 002】:
AI的Context不够的,
如果公司把这些context都喂给ai呢。普通的码农只能接触到自己level的context,ai可以接触到cross level的context,公司层面肯定是要想方设法去掉这层护城河。

--- 第 23 楼来自 privater 的回复 (2026-02-01 17:59:31 PST) ---

有一句话我觉得说的挺对:

AI 时代,你需要找点自己的爱好。

在写代码(码砖头)成本快速降低的时代,最稀缺的不是你能不能把砖头码得快,码得漂亮。而是你能不能提出问题,让 AI 帮你去实现。

最怕的其实是发现自己除了码砖手熟外,没有宁愿花钱去追求的热爱。或者是别人给你的目标,你只是追随而已。

我觉得这个时代倒是挺适合一些多兴趣者,过去他们经常被传统社会认为是眼高手低的人,空有大量爱好,却没有精力和能力都去贯彻执行,现在他们的很多想法反而能借助 AI 的能力快速实现。我觉得蛮适合这类人发挥自己的特长。

而 GenAI 的时代,只是目前为止,创造力和对美的欣赏是 AI 还没法达到的,目前 GenAI 能做的只是拼凑已有的海量数据做成语接龙,无法替代我们几亿年来 DNA 深处的好奇心和对美的追求。

我觉得你在使用 AI 工具产生严重的职业焦虑后,睡上一觉,第二天醒来你依然愿意带着焦虑继续工作,而不是摆烂,这其实生而为人的证据,我们都是面对变化和刺激不断改进自己,不断适应下来的,无论是过去还是将来。

--- 第 24 楼来自 Sunshine9 的回复 (2026-02-01 18:01:34 PST) ---

【引用自 privater】:
创造力和对美的欣赏是 AI 还没法达到的
难道不是还应该有 说话沟通能力 和共情能力吗

--- 第 25 楼来自 LoRA 的回复 (2026-02-01 18:02:09 PST) ---

【引用自 privater】:
一些多兴趣者
所以你需要成为一个集合Engineer+PM+DS+designer的复合体。

你要能做实验发现现有设计存在的问题,领导ds ai回测发现新的opportunity,领导PM ai写出下一步的产品方向,领导designer ai设计出新的UI,领导engineer ai设计出新的产品逻辑。

之前那种单纯接受TL的指令完成代码的需求消失了。

--- 第 26 楼来自 a001082485 的回复 (2026-02-01 18:02:46 PST) ---

以後就剩下水電工,修車工,裝修工這種的相對難取代了

然後時薪超高.…

--- 第 27 楼来自 真的很需要 的回复 (2026-02-01 18:04:21 PST) ---

【引用自 LoRA】:
marginal price就会无限接近0.
这个没问题,但是你得考虑替代,所谓的廉价劳动力啊。现在收割机器已经够发达,够完善了。下地干货,手工采摘为什么还没灭绝。ai会优化,完全没问题,但是消失完全不至于,至少未来5-10年,跟消失完全沾不上边。

--- 第 28 楼来自 LoRA 的回复 (2026-02-01 18:04:55 PST) ---

【引用自 真的很需要】:
手工采摘为什么还没灭绝
没灭绝,但是99%的已经不存在了。。

而且码农到现在都不算廉价。

--- 第 29 楼来自 gin_m 的回复 (2026-02-01 18:04:57 PST) ---

或者在后台帮AI输入验证码

--- 第 30 楼来自 葱花香菜都要 的回复 (2026-02-01 18:07:05 PST) ---

如果真的给足 context 就能解决问题就不需要公司了,一个老板 hire AI agent 做 contractor 就行了

--- 第 31 楼来自 真的很需要 的回复 (2026-02-01 18:07:30 PST) ---

大错特错。要不是西方媒体曝光所谓的“新疆棉”,很多河南湖北家庭会去新疆收棉花,一趟几万块。

image754×516 45.3 KB

--- 第 32 楼来自 LoRA 的回复 (2026-02-01 18:07:38 PST) ---

【引用自 葱花香菜都要】:
一个老板 hire AI agent 做 contractor
估计之后的startup这种是主流。

--- 第 33 楼来自 葱花香菜都要 的回复 (2026-02-01 18:08:16 PST) ---

利好ICC啊

--- 第 34 楼来自 BryanZhao 的回复 (2026-02-01 18:08:20 PST) ---

fsd实现了吗?

--- 第 35 楼来自 hahaandhehe 的回复 (2026-02-01 18:08:22 PST) ---

发明了电脑,电脑那么贵,大家都能用上吗?成本能降下来吗?以后算盘还是需要的吧。

--- 第 36 楼来自 LoRA 的回复 (2026-02-01 18:08:46 PST) ---

【引用自 真的很需要】:
很多河南湖北家庭会去新疆收棉花,
你这么想,如果把地球上所有的自动收棉机消灭,那收棉花的人手需求增加多少倍。那就是ai会替低啊的比例。

--- 第 37 楼来自 002 的回复 (2026-02-01 18:09:33 PST) ---

目前还没看到哪个AI能处理这么多Context。我觉得AI的主要问题是它不知道要干啥,都是人告诉它的,就算它能解决写代码的问题,业务逻辑也得有人去说人话告诉他。

写代码这个问题也挺难,不告诉他具体逻辑,他都不会写。demo的时候很漂亮,但是真拿来解决问题就会发现是一坨屎。

--- 第 38 楼来自 privater 的回复 (2026-02-01 18:09:58 PST) ---

【引用自 LoRA】:
你需要成为一个集合Engineer+PM+DS+designer的复合体
我想到一个曾经的例子:

10多年前是没有前端工程师这种说法的,有的是 web progammer,做个静态页面,你要懂一点 sql,懂一点服务器部署,懂一点 php 以及 jQuery。

但是 JavaScript 快速发展,使得界面动态交互需求大量增加,于是才独立出来前端工程师专注于解决 JS,html,CSS;后端工程师专注于数据库,API。但是随着前后端工具,库的发展优化(NodeJS,CoffeeScript)又有很多人能承担全部的前后端任务,于是 Full Stack 工程师又出来了。

如今前后端实际代码被 AI 编写替代,我相信很多 Senior 级别的前后端工程师多少都能认可你的空闲时间是更多了,所以接下来一部分人也许会沉溺现状,享受更多的空余时间。但是也有一部分人会尝试理解更多 Design,PM,QA 的任务,所以最终会出现这种 one man army 成为事实上很多人能做到的。

所以我觉得继续进一步深入了解自己的工作可能收益不是特别大了,但是跨行业了解自己同僚的事情,拓宽自己的生存空间可能是可行的。毕竟 AI 也是要人来问问题,你不把自己做到 one man army,你是问不出来合理的问题和安排合理的 agent 流程去完成一整套事情。在过去这是非常困难的,困难到一个公司能做到的 Tech lead/CTO/architecture 职位的人极少,而且很多确实都不能天天写生产线的代码了,他们需要学习很多跨领域的知识,还要跟上级交流。

现在如果跨过 数十年的角度去看,最初那批 web programmer 可能也是慌得一逼:我的工作是不是不保了?更 fancy 的前后端工程师是不是会替代我?但是最终其实很多职业初期的人直接就转行成了前后端,乃至最后的全栈,所以如果静态的说 AI 这个工具是不是会增加效率到接管工作了,我觉得不一定,未来很可能会有更广阔的天地去给工程师们发挥。会有曾经做 Pm 设计的跨界能干很多初级程序员的工作,但是同样软件工程师也能站的更高,有更大的产出。因为核心的目的:我们是满足人类无穷尽的需求,只要 Ai 没有自己的意识去创造新的需求,那么更顺手的工具,只会进一步让效率得到提升,而这背后的每一个人,但凡有勇气去接受改变,去学习新的工具,都不会轻易被世界所抛弃。

--- 第 39 楼来自 真的很需要 的回复 (2026-02-01 18:10:04 PST) ---

用了多长时间吧,电脑一问世,算盘就“消失”了。被取代是必然。

--- 第 40 楼来自 fredl 的回复 (2026-02-01 18:10:19 PST) ---

电脑发明到今天这么多年了,你的职业生涯比这个时间短

--- 第 41 楼来自 hahaandhehe 的回复 (2026-02-01 18:10:57 PST) ---

【引用自 葱花香菜都要】:
如果真的给足 context 就能解决问题就不需要公司了,一个老板 hire AI agent 做 contractor 就行了
还是不行的,大概率是,以前1个老板100个员工,以后一个老板5个员工300个agent. 95个失业。

知道,有人会杠,5个人没完全消灭消失消亡,那就不算!

--- 第 42 楼来自 真的很需要 的回复 (2026-02-01 18:11:15 PST) ---

消失了没有?题主说码农这个职业消失了?你在说什么。自动化多少年了,中国还有30%存在,这叫消失?

--- 第 43 楼来自 002 的回复 (2026-02-01 18:11:52 PST) ---

怕是5个员工来不及fix 300座屎山

--- 第 44 楼来自 eu3129 的回复 (2026-02-01 18:12:28 PST) ---

是的,快轉行吧

--- 第 45 楼来自 Startrek 的回复 (2026-02-01 18:13:03 PST) ---

盛世危言,勿谓言之不预也。

--- 第 46 楼来自 hahaandhehe 的回复 (2026-02-01 18:13:31 PST) ---

【引用自 002】:
怕是5个员工来不及fix 300座屎山
现在肯定不行。但是会发展进化的啊。 chatgpt 3.5 刚出来,到现在,才多长时间。进步多大啊。

5-10年以后,AI的能力就很难说是啥样的了

别的不说,AI现在都有教会了。

image1920×822 105 KB

--- 第 47 楼来自 葱花香菜都要 的回复 (2026-02-01 18:13:58 PST) ---

要 all in 吗?

image1084×769 64.6 KB

--- 第 48 楼来自 002 的回复 (2026-02-01 18:15:06 PST) ---

吹AI coding的感觉外行居多?真用过的应该都会骂吧…

我反正看demo的时候觉得挺牛逼,但真拿来解决问题的时候就会一脸懵逼。

--- 第 49 楼来自 真的很需要 的回复 (2026-02-01 18:15:09 PST) ---

你这才叫抬杠吧。那以前有一个老板,开发流程简单了,会不会老板变多呢。想了半天想个算盘的例子,还以为自己多厉害

--- 第 50 楼来自 pqsj 的回复 (2026-02-01 18:15:13 PST) ---

不会 AI 的码农不是好 PM

--- 第 51 楼来自 Startrek 的回复 (2026-02-01 18:15:29 PST) ---

【引用自 真的很需要】:
中国还有30%存在
你和我杠还有5%所以不算消失,那我无言以对。

我是从一个一线码农的体验说出我的感受的。

--- 第 52 楼来自 真的很需要 的回复 (2026-02-01 18:15:55 PST) ---

还有30%也算吗

--- 第 53 楼来自 Divinealex 的回复 (2026-02-01 18:16:09 PST) ---

特斯拉那么强,要不把马斯克开除了吧

--- 第 54 楼来自 002 的回复 (2026-02-01 18:16:20 PST) ---

那些进步不是LLM的进步,更多归功于背后的程序员

--- 第 55 楼来自 tomandjerry 的回复 (2026-02-01 18:16:36 PST) ---

ai coding 确实很好用。 取代大部分码农是时间问题。

这个事情我也知道,楼主你有解决方案吗?

--- 第 56 楼来自 devilevga 的回复 (2026-02-01 18:17:02 PST) ---

【引用自 真的很需要】:
黄包车真淘汰
黄包车淘汰了是没错,但是挑山工和淤泥工这种纯体力的职业还是需要的

码农需要马上转行挑山工和淤泥工,停止撸管,开始撸铁

--- 第 57 楼来自 Startrek 的回复 (2026-02-01 18:17:05 PST) ---

30%那是需要处理物理世界的edge case,码农的代码的复杂程度不及物理世界1%。ai coding对码农的替代不回是70%,肯定是99%的。

--- 第 59 楼来自 PocketKimi 的回复 (2026-02-01 18:18:30 PST) ---

太多的人高估了屎山的影响力,或者干脆就是没用过好的AI coding tool。

以前,coding是昂贵的人用缓慢的速度解决的问题,维护性和可读性很重要。

现在,coding和debug的金钱和时间成本都变低,而且注定越来越低,那屎山根本就不重要了。

现在anthropic和openai的码农都是AI写99.9%的代码,最近大火的openclaw作者也说自己完全就是用5.2 codex vibe code出来的,丝毫不影响这个项目的巨大成功。

不知道现在还在说AI coding完全无法用的都是哪个公司的大神。

--- 第 60 楼来自 002 的回复 (2026-02-01 18:18:50 PST) ---

进化还不是靠程序员在背后肝代码?

--- 第 61 楼来自 hahaandhehe 的回复 (2026-02-01 18:19:19 PST) ---

我又不是在论功行赏,也没说是100%消亡。

AI的进化是顶尖的 researcher 弄出来的,跟我们这些普通的摸鱼佬又没关系。砍也是砍摸鱼佬,砍不到顶尖的人。

--- 第 62 楼来自 真的很需要 的回复 (2026-02-01 18:19:49 PST) ---

你是说现在,还是以后。目前来看离替代99%,还有一定距离。首先我是坚信未来的有一天,AI会完全代替码农,因为是可行的。但现在来看,还差的挺远的。

--- 第 63 楼来自 eu3129 的回复 (2026-02-01 18:19:59 PST) ---

Yann Lecun照樣被逼走啊

--- 第 64 楼来自 bujidao 的回复 (2026-02-01 18:20:22 PST) ---

你猜为什么OAI和人类学一年还要花几个亿买软件服务上,直接AI coding再造一套轮子不香么

--- 第 65 楼来自 002 的回复 (2026-02-01 18:20:32 PST) ---

砍不砍摸鱼佬跟用不用AI关系不大。我觉得AI只是资本家砍人的借口罢了。

--- 第 66 楼来自 Startrek 的回复 (2026-02-01 18:21:24 PST) ---

【引用自 PocketKimi】:
不知道现在还在说AI coding完全无法用的都是哪个公司的大神。
本质上这群人对自己的工作也没有context,一个好的engineer只要对产品需求描述准确,那ai的速度和精确度秒杀普通entry level ic。

这些说ai不好用的,要么context多到ai无法理解,要么连自己平时的工作都没做好。

--- 第 67 楼来自 eu3129 的回复 (2026-02-01 18:21:24 PST) ---

那anthropic這麼多SWE職缺開大包裹幹嘛呢 https://www.anthropic.com/careers/jobs

之前還高價把Bun買下來

直接弄一大堆agent出來就好啦

--- 第 68 楼来自 hahaandhehe 的回复 (2026-02-01 18:21:31 PST) ---

【引用自 eu3129】:
Yann Lecun照樣被逼走啊
别跑题啊,审题啊,lz 说的是啥,你其实在加强lz的论述啊

--- 第 69 楼来自 ze3kr 的回复 (2026-02-01 18:22:59 PST) ---

【引用自 SheenaRingo】:
agent coding的输出结果还是需要ic4检查的
我倒不觉得是检查,而是需要有人能背锅。只要 ai 能背锅了,那就没人什么事了

--- 第 70 楼来自 Anthropologie 的回复 (2026-02-01 18:23:36 PST) ---

码农一定是被取代的 觉得ai coding不行的人 应该是所在公司对ai投入不够大

码农本来就类似民工 真有人把码农当career吗?

--- 第 71 楼来自 bujidao 的回复 (2026-02-01 18:23:45 PST) ---

lol 所以你认知里 码农的工作内容就是别人给了详细准确的context然后他们就纯翻译是么?

--- 第 72 楼来自 Zig 的回复 (2026-02-01 18:23:51 PST) ---

【引用自 Startrek】:
之所以需要改90%的情况是prompt没有描述清楚,本质上是人的问题,不怪ai。
然后人们发明了一种语言来写 prompt 来避免歧义,之后从堆程序的屎山变成了堆 prompt 屎山。。。

--- 第 73 楼来自 Tesla 的回复 (2026-02-01 18:24:19 PST) ---

每次这种帖子下面都是码农在讨论码农要消失,结果讨论完继续写代码上班

--- 第 74 楼来自 ze3kr 的回复 (2026-02-01 18:25:02 PST) ---

现在有的验证码我都做不明白,我得让 chatgpt 给我解…我都不知道这是人机验证还是机器验证了

比如我前几天遇到的

image820×166 50.5 KB

--- 第 75 楼来自 Startrek 的回复 (2026-02-01 18:25:59 PST) ---

【引用自 真的很需要】:
还差的挺远的。
我现在可以confidence说去掉99%的ic3完全没问题。ic4可能50%(剩下的因为他们有grow的机会)。

原因:我把一个简单活交给ic3最后一周之后交付代码结果bug不断,我自己用ai coding两个小时搞定。我花时间mentor这个ic3的时间远超我自己ai coding的时间。

ic3需要学习,但是ai coding是24小时不断进化的。

--- 第 76 楼来自 hahaandhehe 的回复 (2026-02-01 18:27:00 PST) ---

【引用自 PocketKimi】:
不知道现在还在说AI coding完全无法用的都是哪个公司的大神。
一般只有两种

无知, 所以无畏

真超级大牛,他们只做 cutting edge 那种大难题。比如jeff dean, 需要assign他那种级别要解决的问题,肯定不是普通AI能做出来的。

猜猜大多数情况下是那种

--- 第 77 楼来自 PocketKimi 的回复 (2026-02-01 18:27:06 PST) ---

这很难理解吗?因为AI还在进步,cc和codex都是去年中出现的,5.2和4.5是去年末,真正达到了E3/E4水平。所以目前还只是取代entry level。如果你看O/A两家招聘,你说的“这么多SWE”其实已经是伪命题了,要么是Research eng 和MLE,要么多数是staff起步。因为AI暂时还没有E6+的全局design和架构的能力。

你去linkedin看看O和A 一共才有几个5年以下的纯SWE?

--- 第 78 楼来自 争取多活两年 的回复 (2026-02-01 18:27:42 PST) ---

你这太零和思维了,为你手下的人默哀一分钟。

本老给自己team的年轻人说的都是你们现在都被promote成eng manager了。而且是真正的eng manager,不是那种people manager。

--- 第 79 楼来自 MH007 的回复 (2026-02-01 18:28:29 PST) ---

我是挺焦虑的,我是90%前后端代码都用ai来写,虽然我认为别人用ai或许没我溜,但这不应该被裁了依然不好找,特别是我背景极拉垮

--- 第 80 楼来自 eu3129 的回复 (2026-02-01 18:28:48 PST) ---

所以以後沒有new grad train上去,你覺得staff SWE從哪裏來?LLM再突破光靠compute很明顯不夠

--- 第 81 楼来自 hahaandhehe 的回复 (2026-02-01 18:28:57 PST) ---

【引用自 争取多活两年】:
你这太零和思维了,为你手下的人默哀一分钟。
我们的想法,不重要,资本家在追逐利润的压力下会怎么做,才是重要的

--- 第 82 楼来自 002 的回复 (2026-02-01 18:28:59 PST) ---

描述清楚不就是在写代码?我都能描述清楚了,直接写不就完了?还费劲吧啦翻译成人话叫AI帮我写?这不是舍近求远嘛

--- 第 83 楼来自 Forlorner 的回复 (2026-02-01 18:29:14 PST) ---

ai coding nb的根基永远是你得懂这个

不然普通人没design一通胡写

ai就可以一通胡编

--- 第 84 楼来自 争取多活两年 的回复 (2026-02-01 18:29:14 PST) ---

你不要被这些贩卖焦虑的骗了。你应该追求100%的代码用ai写,然后一个人做过去5个人的工作。

--- 第 85 楼来自 反求诸己 的回复 (2026-02-01 18:29:40 PST) ---

一月入职新公司一行代码没写过,每天的工作内容就是和cursor聊天

--- 第 86 楼来自 gin_m 的回复 (2026-02-01 18:29:50 PST) ---

现在的验证码都太tm变态了。。。

我昨天验证码弄了1分钟才过

--- 第 87 楼来自 争取多活两年 的回复 (2026-02-01 18:29:51 PST) ---

资本家干什么和AI不重要。没AI前的2022也是逛逛裁员啊。

--- 第 88 楼来自 bujidao 的回复 (2026-02-01 18:29:56 PST) ---

【引用自 PocketKimi】:
你去linkedin看看O和A 一共才有几个5年以下的纯SWE?
fb上市前也没有几个5年以下的纯SWE,因为那时候也ai统治天下了么?奈飞现在也没几个5年以下的纯SWE,公司尤其是startup招人风格就是这样,这也能拿来做论据么

--- 第 89 楼来自 Skyler2022 的回复 (2026-02-01 18:29:59 PST) ---

长期看,大部分写重复性CRUD代码的码农最终会被10x engineer(PM+DS+n*SWE+UX+TL)淘汰,乐观一点,还能再苟个3年+,毕竟大公司还是比较保守,一般一年裁个10%+

--- 第 90 楼来自 Startrek 的回复 (2026-02-01 18:30:00 PST) ---

【引用自 争取多活两年】:
你这太零和思维了,为你手下的人默哀一分钟。
我mentor他们就是教他们如何用ai,但是有的人就是和楼里一群人一样,完全拗不过思维模式来。无法把自己转换成:TL+ds+pm+designer的复合体。

--- 第 91 楼来自 MarriottPlat 的回复 (2026-02-01 18:30:13 PST) ---

拖拉机出来了,农民就不用锄头了

农民失业了吗?进城不就完了

有多少人是真喜欢coding的?AI不过是新时代的拖拉机而已

--- 第 92 楼来自 争取多活两年 的回复 (2026-02-01 18:30:40 PST) ---

真正重要的就是描述清楚。

举个例子:炒股简单吧,下个单有手就行。难得是下哪个单。

--- 第 93 楼来自 争取多活两年 的回复 (2026-02-01 18:32:12 PST) ---

主要你这个开头说法没有说话的艺术。

你换个标题:感觉码农都要变成架构师了。不就好了。

AI时代怎么起prompt很重要。你的标题就是对大家的prompt。

--- 第 94 楼来自 Rosmontis 的回复 (2026-02-01 18:32:43 PST) ---

我觉得应该会先替代postdoc,postdoc简直是CRUD中的CRUD,有替代1个码农的能力已经可以裁掉10个千老了

--- 第 95 楼来自 Startrek 的回复 (2026-02-01 18:32:44 PST) ---

【引用自 Skyler2022】:
大公司
大公司反而是非常激进的,因为他们人力成本压力也大。大公司推进慢是因为offline context太多。

--- 第 96 楼来自 hahaandhehe 的回复 (2026-02-01 18:33:12 PST) ---

【引用自 争取多活两年】:
资本家干什么和AI不重要。没AI前的2022也是逛逛裁员啊。
你要看裁员谁啊

以前裁谁,程序员 who cares

现在要裁程序员,程序员才出来说的啊,否则你问plumber, 他们肯定说,不怕,AI裁不到他身上,有啥好怕的。

同样 FSD出来,慌的是你们这些人吗,当然不是啊,只是网约车司机啊。

你以前没觉得慌不代表这个事情对社会没大影响,反正死道友不死贫道?

--- 第 97 楼来自 Startrek 的回复 (2026-02-01 18:33:58 PST) ---

【引用自 争取多活两年】:
你换个标题:感觉码农都要变成架构师了。不就好了。
不说的惊悚点可能还点不醒很多人。一线码农再躺在代码上睡觉就完了。

--- 第 98 楼来自 争取多活两年 的回复 (2026-02-01 18:34:03 PST) ---

?22年不就是IT大裁员吗。那时候LLM写码还不存在呢。是LLM拯救了硅谷,不然目前QQQ的PE应该是9。

--- 第 99 楼来自 bujidao 的回复 (2026-02-01 18:34:14 PST) ---

【引用自 Startrek】:
我花时间mentor这个ic3的时间远超我自己ai coding的时间。
不否认这个。但是替代码农,你的意思是随便换个人都能给prompt咯?负责任的说,一个艺术生和一个码农给出来的prompt就是不一样,如果你觉得ai coding能直接理解一个艺术生high level的描述然后写出完全符合预期的code,不敢苟同;如果你是说,码农不用花很多时间在coding上,那我同意。

--- 第 100 楼来自 真的很需要 的回复 (2026-02-01 18:35:31 PST) ---

【引用自 Startrek】:
我花时间mentor这个ic3的时间远超我自己ai coding的时间。
那你可以直接不教他,然后把他的活全自己ai coding,岂不是更省时间。长远来看,你教他,应该还是更省时间的,不是吗

--- 第 101 楼来自 Rosmontis 的回复 (2026-02-01 18:36:25 PST) ---

学术界现在很多老板就是这样的

--- 第 102 楼来自 Startrek 的回复 (2026-02-01 18:36:45 PST) ---

【引用自 真的很需要】:
那你可以直接不教他,然后把他的活全自己ai coding。岂不是更省时间
这就是公司想要的。。。which就是我标题说的。

--- 第 103 楼来自 Fiiish 的回复 (2026-02-01 18:37:05 PST) ---

码农隔行如隔山。。。

很多没有足够训练dataset的细分领域写出来的代码都是一塌糊涂

以后发这种帖子的麻烦specify一下自己具体是做什么的

反正我看目前觉得AI能干掉码农的基本都是web相关

--- 第 104 楼来自 huskywww 的回复 (2026-02-01 18:37:48 PST) ---

ADHD现在成职业优势了

--- 第 105 楼来自 Rosmontis 的回复 (2026-02-01 18:38:05 PST) ---

部分前端+部分MLE吧(假如MLE能被称为码农的话)

哦对了还有测试工程师,话说现在真的还有这个岗位吗

--- 第 106 楼来自 Yangff 的回复 (2026-02-01 18:38:58 PST) ---

超过1-20k行的项目ai就开始乱写了,基本上context window多大决定它能搞多大的项目,所谓的工程手段就是对稍微大一点的项目开始roll骰子瞎几把写看看能不能编译

再大一个量级就是纯垃圾了

--- 第 107 楼来自 真的很需要 的回复 (2026-02-01 18:39:00 PST) ---

但你会不会觉得累啊。如果教他一次明白了,之后不就轻松了。其实美国就是这样的,很多工作都是三个人干一份工作。裁掉两个并不影响

--- 第 108 楼来自 eu3129 的回复 (2026-02-01 18:39:42 PST) ---

QA已經清得差不多了吧

現在都是SWE responsible for production issues

哪一天LLM可以自動修SEV,取代oncall再說

datadog的那些AI SRE都蠻垃圾

--- 第 109 楼来自 ByteSlack 的回复 (2026-02-01 18:40:13 PST) ---

现在基本上是two camps of people,有一些人觉得ai coding只是干一些非常简单的活,高级的活都干不了,比如
【引用自 002】:
就是个高级自动补全工具 并没有任何智能 提高效率还是可以的
另一个camp就是ai coding已经实质上超过人类工程师(这个camp很多是claude code用户),比如
【引用自 PocketKimi】:
现在anthropic和openai的码农都是AI写99.9%的代码,最近大火的openclaw作者也说自己完全就是用5.2 codex vibe code出来的,丝毫不影响这个项目的巨大成功。
(说实在的这个quote还不算太夸张。我见过很多更hype的,包括像google/meta这样的公司是可以在今天就真正裁掉99%员工的)

现在就处于非常有趣的非共识阶段. very fun to be in this age

--- 第 110 楼来自 Startrek 的回复 (2026-02-01 18:40:18 PST) ---

【引用自 Yangff】:
超过1-20k行的项目ai就开始乱写了,
现在大公司里,90%的码农的scope可能就是维护一个几千行的service。。真正超大项目需要的IC7/8短期内没有讨论价值。

--- 第 111 楼来自 galiniunan 的回复 (2026-02-01 18:40:23 PST) ---

那能先把屎山修复了吗

--- 第 112 楼来自 Yangff 的回复 (2026-02-01 18:40:50 PST) ---

service几千行不代表context只有几千行,context一大ai就开始发明API了,这还只是纯逻辑问题,遇上大算法的就更是依托了

或者让它搞搞meta也是一坨,基本上这些能力从2年前开始就没有进步过了

--- 第 113 楼来自 bujidao 的回复 (2026-02-01 18:41:42 PST) ---

不求修sev,能正确的mitigate就不错了。有时候,正确的fix并不是正确的mitigation

--- 第 114 楼来自 Startrek 的回复 (2026-02-01 18:42:27 PST) ---

【引用自 Yangff】:
context一大ai就开始发明API
那是你们公司的ai coding组没有做好。至少我聊的几个大公司的ai coding工具没有什么严重的hallucination问题了。

--- 第 115 楼来自 Yangff 的回复 (2026-02-01 18:43:07 PST) ---

我用的几大工具都有,这些还都是开源项目,公司的项目就更惨不忍睹了,基本上不能用,我只能把需要ai帮我干的部分分离出来让它做独立的几千行的小项目我再帮他对接回去

--- 第 116 楼来自 eu3129 的回复 (2026-02-01 18:43:34 PST) ---

我們也是,tech debt越來越多,SEV越來越多

Opus 4.5算是最好了吧

--- 第 117 楼来自 Yangff 的回复 (2026-02-01 18:45:01 PST) ---

Claude爱偷懒,经常一个函数糊一半屎然后说您自己写吧。。

拿来搓小工具做自动化很好用,稍大一点的项目我不认为这些根本性的缺陷得到解决之前aicoding能有进展

--- 第 118 楼来自 Fiiish 的回复 (2026-02-01 18:46:04 PST) ---

AI目前还干不掉游戏公司的QA/Testing

不过这种活一般都是intern或者外包干

--- 第 119 楼来自 桐梓坡小护士 的回复 (2026-02-01 18:48:42 PST) ---

这分明是一左一右两个二极管,楼里还是很多人持中立态度的,既有超过的地方,也有不如的地方

--- 第 120 楼来自 up9080 的回复 (2026-02-01 18:49:27 PST) ---

Node.js 作者是这么说的:

This has been said a thousand times before, but allow me to add my own voice: the era of humans writing code is over. Disturbing for those of us who identify as SWEs, but no less true. That’s not to say SWEs don’t have work to do, but writing syntax directly is not it.

x.com

@

你的项目再复杂能有 Node.js 复杂吗?

有两篇文章写得很好:

nadh.in

Code is cheap. Show me the talk.

Linus Torvalds once said, 'Talk is cheap. Show me the code'. That is no longer the case.

antirez.com

Don't fall into the anti-AI hype -

--- 第 121 楼来自 bujidao 的回复 (2026-02-01 18:49:33 PST) ---

AI coding的终极考验就是 写整个billing模块 然后让谭友玩三个月不破产 看哪家公司先做到

--- 第 122 楼来自 DeutscheGrammophon 的回复 (2026-02-01 18:50:32 PST) ---

能不能复刻一个ucu大狂欢

--- 第 123 楼来自 002 的回复 (2026-02-01 18:51:20 PST) ---

同意。AI完全就不知道自己在干嘛,生成一坨又一坨屎,给程序员判断。写代码变成了掷骰子,出来的是想要的就accept。

--- 第 124 楼来自 bujidao 的回复 (2026-02-01 18:51:36 PST) ---

【引用自 up9080】:
That’s not to say SWEs don’t have work to do, but writing syntax directly is not it.
这句话和标题是一个意思么

--- 第 125 楼来自 LoRA 的回复 (2026-02-01 18:51:58 PST) ---

【引用自 002】:
AI完全就不知道自己在干嘛
这种90%的情况是engineer自己也不知道自己想要什么。。

--- 第 126 楼来自 002 的回复 (2026-02-01 18:52:27 PST) ---

千老的核心技术是人情世故。

--- 第 127 楼来自 SunsetHills 的回复 (2026-02-01 18:53:25 PST) ---

真的吗?太好了,什么时候消失?

--- 第 128 楼来自 eu3129 的回复 (2026-02-01 18:53:44 PST) ---

writing syntax != writing code

also writing code is only part of a SWE’s job, there are other parts like sitting in pointless meetings

--- 第 129 楼来自 Yangff 的回复 (2026-02-01 18:54:12 PST) ---

说到这个,其实AI一个很大的缺陷是做结构性搜索的能力很差,哪怕有instruction的情况下它也无法去比如我要找一个正确的地方去scan或者先找X再找Y然后再去做一个scan之类的,而是试图一步到位用一些莫名其妙的关键词去搜然后找到啥用啥,这个模型能力的问题从gpt第一天开始拿出web search开始也就没有改进过,虽然engineer上做一些优化但eng识别不到的pattern就处理不了了

反映到coding就是,从这里应该用一个能实现效果X的api,到随便摸出来一个望文生义的接口Y,甚至毫无关联来自其他组件的Z,或者自己根据ABC想象出一个D然后就开始用

我自己是觉得这是因为人类语料里其实并没有这类的训练数据可以供ai使用……

你可以去问一个AI需要搜索的问题然后看看他都用的什么破烂关键词……

--- 第 130 楼来自 002 的回复 (2026-02-01 18:56:08 PST) ---

【引用自 PocketKimi】:
现在anthropic和openai的码农都是AI写99.9%的代码
猴子也能写代码,只要旁边坐一个程序员审核就行

--- 第 131 楼来自 CB2 的回复 (2026-02-01 18:56:31 PST) ---

为什么postdoc还会写代码…?除非idea新到llm都找不到现成的给你搞一个出来,或者有些不好写的语言,但这些research都是拼写证明

--- 第 132 楼来自 002 的回复 (2026-02-01 18:56:56 PST) ---

【引用自 ByteSlack】:
ai coding已经实质上超过人类工程师
如果这个命题成立,那些AI公司还发大包招人干啥?这不是自相矛盾吗?

--- 第 133 楼来自 eu3129 的回复 (2026-02-01 18:57:37 PST) ---

猴子也能飛飛機 機師在旁邊看著autopilot就好

--- 第 134 楼来自 002 的回复 (2026-02-01 18:57:52 PST) ---

AI表示,把服务器炸了就没SEV了

(我是真有类似经历:叫AI帮我修unit test,AI把unit test删了,然后跟我说这下没报错了吧)

--- 第 135 楼来自 002 的回复 (2026-02-01 18:58:49 PST) ---

同感,搓个demo忽悠外行是可以的。在内行眼里AI的东西简直就是笑话。

--- 第 136 楼来自 Dittoiswho 的回复 (2026-02-01 18:58:56 PST) ---

帖子真火,看来痰里码农真多

--- 第 137 楼来自 eu3129 的回复 (2026-02-01 19:01:47 PST) ---
--- 第 138 楼来自 002 的回复 (2026-02-01 19:02:29 PST) ---

亩产万斤,十年超英赶美,跑步进入共产主义

历史总是惊人的相似

喔不,这次不一样

--- 第 139 楼来自 maythe4th 的回复 (2026-02-01 19:15:23 PST) ---

【引用自 002】:
吹AI coding的感觉外行居多?
并不是,Andrej Karpathy都开始吹了,他说过去几周已经改变了他20年来写代码的方式,基本上用英语写代码了。

--- 第 140 楼来自 收束观测者 的回复 (2026-02-01 19:17:13 PST) ---

【引用自 002】:
目前还没看到哪个AI能处理这么多Context
多级agent、RAG和MCP都可以解决这个问题

多级agent就是一个老大管一帮小弟每个小弟的context window负责载入一个模块

RAG就是把整个代码库流式处理了输入向量数据库,AI做事时候需要什么信息调什么

MCP可以用现有静态分析工具索引整个project,AI不需要把整个代码库载入context只需要记住索引树的主干,然后按需快速定位相关代码读

实际上你直接去问gemini怎么让agent处理超context window的巨大代码库它就会告诉你这些方案

The threat is real

--- 第 141 楼来自 ra1n 的回复 (2026-02-01 19:17:43 PST) ---

推理成本在降低 1/10 yoy 。

LLM’s cost is decreasing by 10x each year for constant

LLM's cost is decreasing by 10x each year for constant quality (details in comment) : r/LocalLLaMA1024×755 42.7 KB

Context window 增长。

Yesterday I speculated that you could fit a lifetime of audio into an LLM context window by 2028. Let's check my assumptions. I had based on this on a one-year context length800×450 30 KB

可以发挥点想象力吧。

1-2 年内 context window 长到比人脑对于项目的理解更好,成本继续 1/10 程度降低,质量不好可以通过多轮 loop self verify 来解决。

可以做用一个远低于软件工程师的 cost + ai cost 来替代 senior engineer

--- 第 142 楼来自 Startrek 的回复 (2026-02-01 19:18:12 PST) ---

【引用自 maythe4th】:
并不是,Andrej Karpathy都开始吹了,他说过去几周已经改变了他20年来写代码的方式,基本上用英语写代码了。
我已经不想回复这些人了,本质上连ai coding都用不好的engineer,在现实中,在ai coding出现之前肯定也不会是一个好的engineer。

--- 第 143 楼来自 up9080 的回复 (2026-02-01 19:18:21 PST) ---

subagent 现在是 cc 的标配了

--- 第 144 楼来自 002 的回复 (2026-02-01 19:18:53 PST) ---

【引用自 maythe4th】:
Andrej Karpathy
他屁股做OpenAI那边。。。

--- 第 145 楼来自 ra1n 的回复 (2026-02-01 19:19:00 PST) ---

是的。优化场景太多了,通过 LSP 也可以大规模降低 context 的使用,Lazy Load 等方式来降低 cotext token 的消耗。如果按照目前的 context window 的增长速度,很快就可以覆盖多个大型项目了。

--- 第 146 楼来自 up9080 的回复 (2026-02-01 19:20:43 PST) ---

我支持他的观点,但你说

Andrej Karpathy都开始吹了

其实挺奇怪的。vibe coding 这个词就是他发明的。他现在的工作就是 AI 布道者。

--- 第 147 楼来自 ra1n 的回复 (2026-02-01 19:21:08 PST) ---

不用看屁股,就看他们怎么做就行了,事实就是这些世界顶级的软件工程师用 AI 越多越支持这个观点。行动上也是这样支持的。

--- 第 148 楼来自 002 的回复 (2026-02-01 19:21:52 PST) ---

我也去看看最新进展,希望能让我改观

--- 第 149 楼来自 不知道是谁 的回复 (2026-02-01 19:23:13 PST) ---

消失不至于吧,ai写的bug还是很多的,写的质量也很需要帮助。但是效率确实提高了很多。

--- 第 150 楼来自 bujidao 的回复 (2026-02-01 19:24:34 PST) ---

【引用自 ra1n】:
用 AI 越多越支持这个观点。行动上也是这样支持的。
哪个观点?是AI coding超越人类coding还是AI coding代替码农?AK支持的是前者,lz支持的是后者哦

--- 第 151 楼来自 maythe4th 的回复 (2026-02-01 19:25:51 PST) ---

你如果有关注他的观点就会发现他之前是不信任Vibe code的,觉得还是应该手写框架然后auto complete,转变就是最近几周的事。

而且连Linus Torvalds都开始vibe code了。

--- 第 152 楼来自 002 的回复 (2026-02-01 19:27:52 PST) ---

嗯,我的感受还停留在去年底。到时候去试试,说不定真能“士别三日,即更刮目相待”。

--- 第 153 楼来自 flywire 的回复 (2026-02-01 19:28:11 PST) ---

早就结束了,

你们怎么才知道?

雪山崩塌到时候就是一瞬间的事情。

湾区就是下一个底特律

--- 第 154 楼来自 ra1n 的回复 (2026-02-01 19:30:40 PST) ---

只要用 AI 的 cost 低于当前软件工程师的 cost 完成同一个开发工作都是一回事。

--- 第 155 楼来自 zhhy 的回复 (2026-02-01 19:30:52 PST) ---

【引用自 Startrek】:
我现在可以confidence说去掉99%的ic3完全没问题。ic4可能50%(剩下的因为他们有grow的机会)。
原因:我把一个简单活交给ic3最后一周之后交付代码结果bug不断,我自己用ai coding两个小时搞定。我花时间mentor这个ic3的时间远超我自己ai coding的时间。
ic3需要学习,但是ai coding是24小时不断进化的。
你要不要看看你自己说的有逻辑吗?

99%?你只有一个dp你怎么不说100%呢

--- 第 156 楼来自 LoRA 的回复 (2026-02-01 19:31:13 PST) ---

【引用自 不知道是谁】:
ai写的bug还是很多的
我最近半年唯一用ai写的bug是我没有给ai提供context,它assume了一个默认场景,我也没检查好就submit了。其他99个pr都是一步到位。

我的观点:ai出错大概率是因为engineer没prompt好。

--- 第 157 楼来自 ra1n 的回复 (2026-02-01 19:32:50 PST) ---

而且,模型的演进速度很快,我发现楼里很多人用 3-6 个月前的经验来评价当前的能力也是不太能真实反映的。

--- 第 158 楼来自 BryanZhao 的回复 (2026-02-01 19:34:39 PST) ---

但你做的不还是把接收到的各种信息转化为机器语言吗?只是现在的机器语言变成了人类读得懂的prompt,markdown等等。。。一个不懂编程的人写的prompt和码农写的prompt是有区别的

--- 第 159 楼来自 yoyo2025 的回复 (2026-02-01 19:35:22 PST) ---

被谁打败 就加入谁

--- 第 160 楼来自 黑卡会员 的回复 (2026-02-01 19:35:34 PST) ---

目前依然感觉还是补全功能,需要well defined prompt,且即使简单也可能需要多次改错,没有context的task根本没法做,要它从头写再改还不如自己上,design doc则是根本没法写

但总体上觉得末日将至,即使无法彻底取代sde,不远的未来砍半从业人数应该还是能做到的

--- 第 161 楼来自 kerrygold 的回复 (2026-02-01 19:36:04 PST) ---

我vibe coding几个月了,上班的代码和side project全cc(设计文档全部gemini生成,偶尔手动edit)。目前还是人+cc比纯cc强一点,不过类比当年AI下棋的发展之后不久可能就是纯AI吊打人+AI了。现在比较蛋疼的点是我和同事都vibe code,没有改变relative standing。因为需要仔细review和思考,上班反而比之前累了。

上周修了一个implementation pattern的bug,不太容易用传统static analysis工具detect,但是和cc讲明白也就一两句话的功夫。之后这类garden cleaning都不用自己做了。

--- 第 162 楼来自 收束观测者 的回复 (2026-02-01 19:36:53 PST) ---

编码能力问题解决以后模型训练会向着

用户需求 → 工程定义

的这一转化延伸的

--- 第 163 楼来自 ra1n 的回复 (2026-02-01 19:36:54 PST) ---

这部分也会被模型慢慢优化掉了。目前很多开发工具会直接 clarify 需求变成菜单让你选了,不需要人类设计 Prompt 了。非软件工程师写出的 Prompt 不需要比软件工程师好也可以达到同样的实现了。

目前的工具都是在朝 zero prompt 发展和设计。

--- 第 164 楼来自 eu3129 的回复 (2026-02-01 19:37:53 PST) ---

房價終於要掉了嗎

--- 第 165 楼来自 maythe4th 的回复 (2026-02-01 19:40:45 PST) ---

他是vibe coding的发明者,但是他对AI coding的态度呢?

这是他去年十月上的podcast,他还是用auto complete多于vibe code,他对vibe code原话是这么说的

They just couldn’t internalize that you had your own.

They couldn’t get past that. They kept trying to mess up the style. They’re way too over-defensive.

They make all these try-catch statements. They keep trying to make a production code base, and I have a bunch of assumptions in my code, and it’s okay.

I don’t need all this extra stuff in there. So I feel like they’re bloating the code base, bloating the complexity, they keep misunderstanding, they’re using deprecated APIs a bunch of times. It’s a total mess. It’s just not net useful. I can go in, I can clean it up, but it’s not net useful. I also feel like it’s annoying to have to type out what I want in English because it’s too much typing.

If I just navigate to the part of the code that I want, and I go where I know the code has to appear and I start typing out the first few letters, autocomplete gets it and just gives you the code.

This is a very high information bandwidth to specify what you want.

但是现在再看他的观点

x.com

@

Given the latest lift in LLM coding capability, like many others I rapidly went from about 80% manual+autocomplete coding and 20% agents in November to 80% agent coding and 20% edits+touchups in December. i.e. I really am mostly programming in English now, a bit sheepishly telling the LLM what code to write…

--- 第 166 楼来自 LoRA 的回复 (2026-02-01 19:41:04 PST) ---

【引用自 ra1n】:
3-6 个月前
是的,现在ai对context的理解程度已经让我惊掉下巴,给出prompt之后自动理解上下文,代码的产品逻辑,提出优化plan。可以说绝大部分ic3/4没有这个能力,速度更是秒杀entry level engineer。

--- 第 167 楼来自 002 的回复 (2026-02-01 19:42:59 PST) ---

【引用自 Startrek】:
grow
AI不会自己grow

--- 第 168 楼来自 ctest 的回复 (2026-02-01 19:43:12 PST) ---

估计最早替换的就是做APP的,接着就是软件工程做的好的公司。

对于我们公司这种代码,一时半会还真不怕,几千万行没注释,没文档,还乱七八糟的代码,你敢让AI去整,5nm以下流片废一版,够你养多少人的?哪怕没全废,出了问题,你指望另一个AI去修不成?

--- 第 169 楼来自 ra1n 的回复 (2026-02-01 19:44:55 PST) ---

【引用自 ra1n】:
可以发挥点想象力吧。
1-2 年内 context window 长到比人脑对于项目的理解更好,成本继续 1/10 程度降低,质量不好可以通过多轮 loop self verify 来解决。
是的。目前发展速度已经可以超过很多人想象力了。

这些未来的 performance 是 predictable 的。context window 大 10 倍。cost 降低 1/10 这很可能就是 1 年内会发生的事。

--- 第 170 楼来自 收束观测者 的回复 (2026-02-01 19:45:41 PST) ---

【引用自 ctest】:
5nm以下流片废一版
越接近硬件的越不容易被替代

现在 coding 能力还主要处理真空球形鸡宇宙里定义的纯逻辑问题

甚至很多时候分布式竞争冒险都处理得不是特别好(当然它们已经能理解这类问题了)

--- 第 171 楼来自 LoRA 的回复 (2026-02-01 19:47:32 PST) ---

【引用自 ctest】:
几千万行没注释,没文档,还乱七八糟的代码,
这个可能正是ai的擅长,通过分级agent处理超复杂系统,这个是人类engineer无法拥有的能力。

--- 第 172 楼来自 msft 的回复 (2026-02-01 19:47:53 PST) ---

我们公司基本都是用内部的框架,开源很少,c/c++/fortran mixture。我体感ai非常厉害。好多十几年的repo,几轮reorg没人懂,ai能很快搞出来个大差不差的文档帮助理解,自己手动挨个文件翻要好几周。虽然公司内部几乎不怎用开源框架,但是ai写的也很溜,毕竟我们手写也不过是找一段类似的代码抄过来,再稍加修改。失业倒是不担心,可以像豆豆老师一样摸鱼了

--- 第 173 楼来自 Rosmontis 的回复 (2026-02-01 19:50:09 PST) ---

【引用自 LoRA】:
速度更是秒杀entry level engineer。
sadly这才是这个行业的死穴。

就像AI绘画一样,大部分甲方并不懂技术细节,他们只想要一个过得去的成品,AI画的又快又好,可能也就5-10%的地方有瑕疵。人人都是从小画师开始,练习人体结构和静物开始学习绘画的,那现在所有人的关注点都变成如果你的画是不是比AI好,那谁还会练习画技呢?

如果这一轮NG, entry level engineer都在vibe coding,谁还会去认真研读文档,花大功夫去写规范的接口和语言,去理解代码设计的架构和哲学呢?sadly这一轮的ng几乎都是vibe coding长大的。对于老油条可能不用担心,但对于新人来说相当于剥夺了他们成长的权力,这就需要新人拥有极大的定力去用vibe省下来的时间从AI中学习门路和哲学,但有几个人会这么干呢?还都是直接vibe完了auto accept,等着prod出问题?

--- 第 174 楼来自 ra1n 的回复 (2026-02-01 19:50:21 PST) ---

【引用自 LoRA】:
这个可能正是ai的擅长,通过分级agent处理超复杂系统,这个是人类engineer无法拥有的能力。
是的,人类大脑跳函数 10 个很可能就记不住 context 了。AI 跳 10 个是可以很清楚理解的

--- 第 175 楼来自 maythe4th 的回复 (2026-02-01 19:50:49 PST) ---

据我所知,Nvidia内部做芯片的也在用AI agent,说有个类似Cursor的东西。

--- 第 176 楼来自 LoRA 的回复 (2026-02-01 19:52:11 PST) ---

【引用自 msft】:
但是ai写的也很溜,毕竟我们手写也不过是找一段类似的代码抄过来,再稍加修改。失业倒是不担心,可以像豆豆老师一样摸鱼了
我觉得大家要转变思维模式:不要因为自己的系统复杂到人类无法理解所以自己safe。越是复杂的屎山代码ai越是做的比人好。

真正safe是:对产品有敏锐的直觉,对技术高度创造性,又有极强审美的 engineer+pm+ds+designer复合型人才。

--- 第 177 楼来自 msft 的回复 (2026-02-01 19:53:24 PST) ---

【引用自 Rosmontis】:
谁还会去认真研读文档,花大功夫去写规范的接口和语言,去理解代码设计的架构和哲学呢
有ai之后各种api design可以快速尝试,因为不需要自己手打了,我觉得反而可以学得更快了。各种usecase可以全实现一遍

--- 第 178 楼来自 msft 的回复 (2026-02-01 19:55:01 PST) ---

【引用自 LoRA】:
不要因为自己的系统复杂到人类无法理解所以自己safe。越是复杂的屎山代码ai越是做的比人好。
确实没啥是safe的。领导可以安排人去migration,直接老的不要了。

--- 第 179 楼来自 ra1n 的回复 (2026-02-01 19:55:12 PST) ---

我发现这个帖子下大多数更担心被 AI 替代的都是用的很多的。

用得越多的人越了解边界越担心。

--- 第 180 楼来自 002 的回复 (2026-02-01 19:56:04 PST) ---

出问题是早晚的事,到时候修都没法修,因为再也没有人看得懂屎山了

--- 第 181 楼来自 ra1n 的回复 (2026-02-01 19:56:43 PST) ---

大多数人类的屎山代码质量比 AI 写的烂的。

--- 第 182 楼来自 sakura-neko 的回复 (2026-02-01 19:57:19 PST) ---

【引用自 BryanZhao】:
一个不懂编程的人写的prompt和码农写的prompt是有区别的
ai进化最终的结果是:我要做xxx,按照最佳工程实践给我弄一个出来。然后ai就弄出来了。对提问者来说中间步骤完全不用了解,就好比ceo把任务布置给engineering vp然后等验收一样。CEO需要了解太多代码细节么?我认为不需要,就像今天软件工程师不用知道高级语言编译出来的机器码怎么写的。如果未来AI成为事实标准,大家知道是哪个ai做的就心里有数了。

以上情形可能发生么?我认为不设定时间尺度的话,应该是必然会发生的。

--- 第 183 楼来自 002 的回复 (2026-02-01 19:59:25 PST) ---

这我不同意,AI是喂什么出什么,不可能比人写得好。除非能筛选出高质量代码喂给AI。

--- 第 184 楼来自 收束观测者 的回复 (2026-02-01 20:02:09 PST) ---

【引用自 002】:
除非能筛选出高质量代码喂给AI
SFT了解一下
【引用自 002】:
这我不同意,AI是喂什么出什么,不可能比人写得好
At some point 这里的“人”可能是特指写得最好的那些人

--- 第 185 楼来自 ra1n 的回复 (2026-02-01 20:02:28 PST) ---

这试试就知道了。

实现一个 AES 加密 feature ,人类不利用 AI 只 Google 查询,看看能不能写的比 AI 好。

这个是很容易验证的。我目前的观察是我看到的人类写的都没有 AI 好。

因为
【引用自 002】:
筛选出高质量代码喂给AI。
这个是很容易的。目前的模型训练就是在做这样的事儿

--- 第 186 楼来自 Startrek 的回复 (2026-02-01 20:03:50 PST) ---

之后扁平化肯定是趋势,因为大部分项目的失败:中间层communicate过程中信息的失真是最大责任。大部人交流的效率是极其低下的,但是ai agent带着多层ai agent工作的交流效率和理解能力上限是极高的。

现在我是越用越害怕,之前我做一个项目:

自己定方向->找ds 验证->找pm align->找em要人->找entry level eng分包工作。

现在我做一个项目:

找到方向->ds agent帮我验证-> pm agent帮我写技术文档->dev agent帮我实现。

效率提升是指数级的。之前几周的工作一下子压缩到了几个小时。

ps:我是做产品的。

--- 第 187 楼来自 msft 的回复 (2026-02-01 20:04:52 PST) ---

起码ai pretrain的时候见的best practice比多数sde多多了。另外对sde的要求也不是屎山上写一些“优质代码”,你写进去反而别人看不懂,还out of place,格格不入

--- 第 188 楼来自 gin_m 的回复 (2026-02-01 20:08:12 PST) ---

多锻炼锻炼PM , prompt engineer, 一个L4 管 4个agentic slaves 就好了

--- 第 189 楼来自 002 的回复 (2026-02-01 20:09:44 PST) ---

对,这里应该是指上限

--- 第 190 楼来自 devilevga 的回复 (2026-02-01 20:11:39 PST) ---

泥潭码农爽了十几年买了五六套房子早就赚够本了吧

--- 第 191 楼来自 LoRA 的回复 (2026-02-01 20:13:41 PST) ---

【引用自 devilevga】:
码农爽了十几年买了五六套房
如果是10年前进入大厂确实可以考虑提前退休了。其他的可能没那么乐观。

--- 第 192 楼来自 vczh 的回复 (2026-02-01 20:15:50 PST) ---

【引用自 Startrek】:
要么context多到ai无法理解
context多到自己都无法理解

gpt5.2写代码确实还可以了,但是空有知识,如果你不告诉它该用,它经常都不会用。所以等于一个饱读诗书的行尸走肉。我觉得这种能力是不能用普通的L3/L4/L5来比较的,因为码农career的级别的提升是通过它掌握问题的scope来决定的,这点AI完全没法打。但是AI又是个熟手,很多L∞操控细节的知识都未必有AI多,所以我觉得这其实就是两个track

当然也不要过度神话,如果你的程序的主要核心是模板元编程、状态机和异步等等这些网上样本少的代码,gpt5.2今天依然束手无策

--- 第 193 楼来自 Bsian 的回复 (2026-02-01 20:19:30 PST) ---

对于我们这些后生仔, 是不是失业就是直接职业结束了

--- 第 194 楼来自 不知道是谁 的回复 (2026-02-01 20:21:01 PST) ---

这有点以偏概全了吧。到底ai做得好不好是取决于你用的model和使用场景的。如果你场景非常简单那是没什么问题的。所以说junior eng的需求是小了很多的。

--- 第 195 楼来自 收束观测者 的回复 (2026-02-01 20:22:15 PST) ---

【引用自 vczh】:
gpt5.2
是copilot接入的三家里最差的一个,我们组根本没人用

--- 第 196 楼来自 vczh 的回复 (2026-02-01 20:22:47 PST) ---

我用了copilot里面几乎所有模型来写过C++,除了gpt5.2以外基本出来的都是一坨屎

--- 第 197 楼来自 ra1n 的回复 (2026-02-01 20:23:00 PST) ---

先多说一句先 recon 理解一下项目就完事儿的事儿。

--- 第 198 楼来自 maythe4th 的回复 (2026-02-01 20:24:07 PST) ---

【引用自 Lexus】:
最新的人类学反华ceo预言是6-12个月所有swe job
他在25年3月预测90% of Code will be made by AI in 3–6 Months

当时嘲讽的人为多,现在回过头看,时间点预测不对,但是趋势还是很明显的。

--- 第 199 楼来自 Startrek 的回复 (2026-02-01 20:24:41 PST) ---

【引用自 vczh】:
我用了copilot里面几乎所有模型来写过C++,除了gpt5.2以外基本出来的都是一坨屎
也许你退休的时候ai还不能打败你,但是ai打败你是必然的事情。

--- 第 200 楼来自 收束观测者 的回复 (2026-02-01 20:26:20 PST) ---

opus和gemini写C++和CUDA的混合都没问题,甚至可以在里面插汇编

编译环境可以自己配,编译失败了可以自己修环境

我只能说不知道你怎么搞出来的
【引用自 vczh】:
一坨屎

--- 第 201 楼来自 ra1n 的回复 (2026-02-01 20:27:40 PST) ---

【引用自 ra1n】:
这些未来的 performance 是 predictable 的。context window 大 10 倍。cost 降低 1/10 这很可能就是 1 年内会发生的事。
compound 出来的效果应该是惊人的。

--- 第 202 楼来自 sakura-neko 的回复 (2026-02-01 20:28:51 PST) ---

【引用自 maythe4th】:
时间点预测不对
时间点反而是最重要的

--- 第 203 楼来自 争取多活两年 的回复 (2026-02-01 20:31:21 PST) ---

本来一直觉得llm就是个大号编译器。其实你拿着go的编译器回去汇编时代大家也会惊为天人。

--- 第 204 楼来自 eu3129 的回复 (2026-02-01 20:32:17 PST) ---

光是一個malloc就沒了

--- 第 205 楼来自 yyss8 的回复 (2026-02-01 20:32:53 PST) ---

我觉得现在要做的是赶紧找位置 一个萝卜一个坑 一个不是主打技术产品的中小公司可能1-2个程序员就够了

顺便一提 从以前还在打游戏的时候就发觉 每次游戏新版本就是我提升的最好机会 多大的大佬都跟我一个同一个起跑线了 现在就是这么个时候

--- 第 206 楼来自 vczh 的回复 (2026-02-01 20:33:11 PST) ---

他就是不愿意读库文件的实现,结果经常在编译错误里面出不来,越改错误越多。gpt5.2的耐心就很强,知识就十分丰富,我用macro来拼带concept和各种花式overloading的代码他几乎就没看错过,甚至还会写

都别谈怎么debug数据结构或者GUI了,编译都过不了后面都不用谈了

--- 第 207 楼来自 PocketKimi 的回复 (2026-02-01 20:33:44 PST) ---

【引用自 收束观测者】:
是copilot接入的三家里最差的一个,我们组根本没人用
我自认为follow developer community还算比较紧的,也一直在做tool use和computer use相关的项目,cc和codex都用。这还是我第一次听说 后端coding这个领域gemini能上桌的 之前只听说过web dev这种比较简单的case gemini的审美还不错。

这个帖子充分体现了不同人对AI的认知和喜好大相径庭。

--- 第 208 楼来自 争取多活两年 的回复 (2026-02-01 20:34:52 PST) ---

是不是另一种语言大战?充分说明llm就是重新发明了一门新语言。

--- 第 209 楼来自 Rosmontis 的回复 (2026-02-01 20:35:22 PST) ---

gemini mcp用来读那种几万行的项目很好用啊

--- 第 210 楼来自 收束观测者 的回复 (2026-02-01 20:36:50 PST) ---

【引用自 PocketKimi】:
后端coding这个领域gemini能上桌的
我写的不算传统后端代码

Gemini 3P我遇到的最大问题是日常死循环

但是涉及数学逻辑的code比opus强很多

另外就是我是用vscode+copilot切模型对比

claude code很多东西是工程端做得好不是模型本身的能力

--- 第 211 楼来自 Startrek 的回复 (2026-02-01 20:36:57 PST) ---

【引用自 争取多活两年】:
llm就是重新发明了一门新语言。
这可能是对ai最大的误解。ai对context的理解能力是人类无法匹敌的。

--- 第 212 楼来自 PocketKimi 的回复 (2026-02-01 20:37:23 PST) ---

可是这个是很基本的功能啊。。这甚至不需要一个mcp来读,直接让cc来读就可以了

--- 第 213 楼来自 hjfhdjellskx 的回复 (2026-02-01 20:38:13 PST) ---

【引用自 PocketKimi】:
现在anthropic和openai的码农都是AI写99.9%的代码
这种话是marketing,不能当真。

--- 第 214 楼来自 Rosmontis 的回复 (2026-02-01 20:38:54 PST) ---

用cc读也太浪费token了,cc的context window到一半的时候其实整个session已经可以遗弃了(recall rate会断崖式上升)。gemini context够大就不会有这个问题,相当于gemini帮你先咀嚼一遍再喂给cc

--- 第 215 楼来自 vczh 的回复 (2026-02-01 20:39:52 PST) ---

我是ai的用户,他打不打败我有什么用,车开得快我还会跟他比跑步吗,但是如果他进不了家门口的巷子,下雪了就上不了斜坡,那还不是得换

--- 第 216 楼来自 争取多活两年 的回复 (2026-02-01 20:40:48 PST) ---

你对人有误解。人永远不善于读取和理解,人擅于的是定义。应该说llm出来后才算解决编程语言的承诺。之前码农们还生活在中世纪。

--- 第 217 楼来自 LoRA 的回复 (2026-02-01 20:40:52 PST) ---

你很快就会发现和你比赛的不是赛车而是战斗机。

--- 第 218 楼来自 争取多活两年 的回复 (2026-02-01 20:41:40 PST) ---

人家都说了不和车比跑步。你来个那你和战斗机比。

--- 第 219 楼来自 收束观测者 的回复 (2026-02-01 20:42:43 PST) ---

轮子哥是不会被你说服的

人家预设了自己面对AI job security是100%,是裁判员不是球员

--- 第 220 楼来自 uscdfm 的回复 (2026-02-01 20:44:02 PST) ---

在线等,怎么变成ai

--- 第 221 楼来自 争取多活两年 的回复 (2026-02-01 20:44:46 PST) ---

大家面对AI的job security都是100%。裁你的是另一个人。

--- 第 222 楼来自 PocketKimi 的回复 (2026-02-01 20:44:47 PST) ---

哦所以你是gemini plan,cc execute?

无论哪个LLM 做这个事都需要把file load进context window,这是不可避免的。我一般都是CC多agent,一个或者几个负责plan 然后写成execution plan.MD, progress.MD, todos.MD 然后再让别的执行。

gemini plan也许确实可行,毕竟context window大。但是如果讲recall 那不如5.2 long context recall高的吓人。

--- 第 223 楼来自 vczh 的回复 (2026-02-01 20:45:49 PST) ---

我早就过了谈job security的年纪了,等AI对coding真的发展到了wolframalpha算微积分那么厉害的时候,也正好可以退休了

论坛上次说的FIRE标准年龄是几岁来着

--- 第 224 楼来自 pix0 的回复 (2026-02-01 20:46:13 PST) ---

【引用自 Rosmontis】:
还都是直接vibe完了auto accept,等着prod出问题
我们组里有一个ticket是这样的,在legacy系统里拿ai修bug的时候引入了新的bug。现在的情况是不知道trigger的原因,不知道trigger的影响,一个一个manual fix,emergency rollback了两次还是没有fix完。我觉得大量使用AI的影响可能更接近于一个组接手了没人管的legacy service,出了问题AI修不好就只能自己修了。
【引用自 LoRA】:
我的观点:ai出错大概率是因为engineer没prompt好。
如果说"如果你说AI不好用就是你prompt/setup得不好",这个也说明现在LLM还是依赖正确的prompting和context engineering。
【引用自 maythe4th】:
他在25年3月预测90% of Code will be made by AI in 3–6 Months
公司在25年有和openai的三方vendor聊过他们的使用场景。我觉得看AI公司PR说什么和实际工程实践的时候做什么是有意思的对比。

我觉得有两个问题是我现在没有看到有好的解释,一个是hallucination,openai之前解释是training weight的问题,但是我没有看到一个solid的解决方法;另一个是Error propagation,我也没有看到有谈这个怎么解决的。有了解的谭友可以分享一下最近的进展。

--- 第 225 楼来自 LoRA 的回复 (2026-02-01 20:46:18 PST) ---

【引用自 vczh】:
,等AI对coding真的发展到了wolframalpha算微积分那么厉害
可能已经实现了。。

--- 第 226 楼来自 Rosmontis 的回复 (2026-02-01 20:46:37 PST) ---

codex有一段时间反超cc就是这个原因,cc简直是coding agent届霍金,大脑发达小脑萎缩,动不动就到活动limit。

--- 第 227 楼来自 浅吟低唱 的回复 (2026-02-01 20:48:02 PST) ---

已经接受现实 码农在自我革命把自己命革掉的路上冲锋陷阵 好莱坞演员工会那些还装装样子保饭碗

现在期待的就是AI把其他brain work行业也干垮,大家都别活了

不说了,学电工去了,四舍五入也算engineering

--- 第 228 楼来自 Rosmontis 的回复 (2026-02-01 20:49:00 PST) ---

全世界的码农团结起来,今天开始学习豆老师摸鱼!没人给AI修bug,看pm们能写出什么屎山

--- 第 229 楼来自 vczh 的回复 (2026-02-01 20:49:11 PST) ---

不要说可能。现在我下班后自己写的项目90%以上的代码都是让LLM做的,几斤几两我还不知道

--- 第 230 楼来自 eu3129 的回复 (2026-02-01 20:49:50 PST) ---

覺得碼農會消失的,有灣區房子的話準備現在賣掉嗎?這個職業消失的話灣區房價會暴跌吧?

--- 第 231 楼来自 navimoe 的回复 (2026-02-01 20:53:05 PST) ---

我的体验大概是这样的:

写个刷里程票的插件,那随便一个主流的 AI 来写都能写得挺好,UI 还挺漂亮。代码行数大约 1000 多。

我想重构我上万行的个人项目并修复一些架构问题,结果 AI 经常搞着搞着就啥都不 work 了。我得要手把手拆分要做的事情,不断告诉它下一步要做什么了,才勉强能做。干非常具体的活还是给力的,但是偶尔也会有把一个几百行函数的代码重构到另一个函数里,试了好多次都做不对的情况。

工作中的代码库有上百万行代码。AI 简直就是人工制杖,hallucinations 非常严重。我只有写些单元测试或者一些特殊场合会用。比如之前有个数据结构非常复杂,API 涉及几十个类。我需要把这个数据结构的实例解开,做一些修改再封装回去。这种 AI 就很擅长。

当然很多问题 context 不够大都是原因之一。没准以后 context 足够大到多数场景下都够了了。不过还有其他的问题,写代码只是整个软件工程里的一部分。比如工程上很多东西都是为了防止人犯错的,AI 在这些方面能做得多好?要不然三天两头一个 global outage,过两年来个 data loss 谁用你的产品。我不觉得 AI 取代的时代一定不会到来,但我觉得这是渐进式的,而且目前仍然还有很多问题需要解决。

--- 第 232 楼来自 maxmax 的回复 (2026-02-01 20:54:02 PST) ---

真的吗?我不信

--- 第 233 楼来自 Reinhard 的回复 (2026-02-01 20:55:39 PST) ---

短期大部分的公司都是少招人然後大量開project

中期以後才會更進一步cost down 吧

--- 第 234 楼来自 vczh 的回复 (2026-02-01 20:55:52 PST) ---

【引用自 navimoe】:
但是偶尔也会有把一个几百行函数的代码重构到另一个函数里,试了好多次都做不对的情况。
这又要说到上次用cursor的体验,我给一个函数写unit test,写了一半$20试用装就用完了

每次都让我想起copilot一折贱卖算力的良心,均摊$32一个月的pro+从来就没用完过

LLM操作巨大代码库的前提是你要有一个好的源码导读,但这需要人类前期花很多时间去指导LLM写。不过从资本主义的观点,我们干嘛要给employer弄这些,下班后的代码那就可以弄

--- 第 235 楼来自 FancyIX 的回复 (2026-02-01 20:58:01 PST) ---

这个ic4 ic5几的,是哪个公司的level?

底层码农含泪问

--- 第 236 楼来自 vczh 的回复 (2026-02-01 20:58:22 PST) ---

一般认为毕业生是ic3

--- 第 237 楼来自 serelee 的回复 (2026-02-01 20:59:55 PST) ---

openai对agi的第五档定义就是 organization

--- 第 238 楼来自 西雅图彭于晏 的回复 (2026-02-01 21:01:26 PST) ---

LZ是码农么?如果是的话应该天天都在用ai coding tool才对啊

--- 第 239 楼来自 葱花香菜都要 的回复 (2026-02-01 21:01:35 PST) ---

应该投Tata还是微软?

--- 第 240 楼来自 pix0 的回复 (2026-02-01 21:02:32 PST) ---

【引用自 navimoe】:
工作中的代码库有上百万行代码。AI 简直就是人工制杖,hallucinations 非常严重。
得限制context,在context window允许的范围能做修改能用上,超过能handle的window容易乱写。

--- 第 241 楼来自 vczh 的回复 (2026-02-01 21:02:48 PST) ---

【引用自 sakura-neko】:
按照最佳工程实践给我弄一个出来。然后ai就弄出来了。
其实这是一个悖论,如果完全不需要人参与,那最佳工程实践也是没必要遵守的,而且就算代码写的难以重构又怎么样呢,下次再写一次就好了。编译器生成汇编除了性能相关的东西以外任何best practice 都是不遵守的

所以中间的过渡是曲折的,过度紧张没有用,日子该过过

--- 第 242 楼来自 Ding 的回复 (2026-02-01 21:06:19 PST) ---

看完了今天大家的讨论,受益良多。感觉明天周一就可以给老板吹牛自己是AI专家了。

--- 第 243 楼来自 Rxs 的回复 (2026-02-01 21:09:56 PST) ---

最新的概念是一人公司 只要你有好的创意和深刻的洞察以及品味 代码不再是巨大的鸿沟了

--- 第 244 楼来自 vczh 的回复 (2026-02-01 21:12:02 PST) ---

Untiy3D刚出来和full stack刚发明的时候也吹过类似的概念,历史都是一个轮回。然而实际情况是,科技发展了用户每$1要得到的东西的胃口就会迅速增大

--- 第 245 楼来自 002 的回复 (2026-02-01 21:17:27 PST) ---

有点像那种记忆里超群,过目不忘的人,但是逻辑思考、分析能力却不足

--- 第 246 楼来自 002 的回复 (2026-02-01 21:18:18 PST) ---

不至于,政治斗争、人情世故,AI是一丁点都不会的

这才是码农的核心竞争力

--- 第 247 楼来自 002 的回复 (2026-02-01 21:21:06 PST) ---

我的感受大致相同。提升了效率,但是目前LLM只能算是AGI的一个组成部分。

--- 第 248 楼来自 salty 的回复 (2026-02-01 21:24:47 PST) ---

AI 给我的感觉是没有多少直觉。比如一个 SEV 发生,AI 只会傻傻看 code,事实上很多时候吃经验的。有的 alert 很 high level,属于 catch all,比如我看一下是不是 customer 自己程序在 crash looping 导致了我们这边报警,是就不用管了。AI 没有那么多 context,我们也没教过他怎么查。

AI coding 还可以,但是 AI coding 写得好不好也要看指挥它的人品味如何。

--- 第 249 楼来自 Onvon 的回复 (2026-02-01 21:33:45 PST) ---

我维护过那种documentation很差的repo

用ai也只能写屎山

偏偏很多PM不注重这方面 不少相关的item全是最低优先级

--- 第 250 楼来自 小帮菜 的回复 (2026-02-01 21:34:02 PST) ---

本质问题是人类的自然语言描述问题的能力太匮乏了. 当系统复杂到无法用简单的prompt说清楚时,你不能指望着llm用猴子打印莎士比亚文集的方式随机出来正确的结果.

--- 第 251 楼来自 土拨鼠工业发展促进会 的回复 (2026-02-01 21:39:08 PST) ---

不知道LZ有没有玩过极乐迪斯科 个人的体验和游戏剧情差不多

可能会剧透

极乐迪斯科大多数人一周目犯的最大的错误就是认为这个故事是和很普通的工人冲冠一怒为红颜然后把雇佣兵审判了的故事,但是其实完全不是的。故事其实是从Harry从雇佣兵嘴里找到弹头才开始发生变化的。LLM其实和这个差不多 — 按照经验和概率模型肯定能给你第一个结论,但是未必能给你第二个真正正确的结论。

工业界很多东西的build/gain是需要大量context的 如果按照多数context可能结论就是大家都能得出来的 但是可能最后结果是个奇技淫巧才能做出来呢

--- 第 252 楼来自 HelloFox 的回复 (2026-02-01 21:39:47 PST) ---

这到底是对千老有多大仇呀。何况大部分千老都是在实验室里干苦力活的,能有多少是写code的呀

--- 第 253 楼来自 vczh 的回复 (2026-02-01 21:42:28 PST) ---

一周目走的智力路线,到了教堂和大结局的时候都觉得画风开始奇幻,最后也不知道说的是个什么故事

--- 第 254 楼来自 土拨鼠工业发展促进会 的回复 (2026-02-01 21:43:24 PST) ---

【引用自 vczh】:
说的是个什么故事
可以理解为一个后现代的小说,作者对一个大概率会死亡的旧世界的应对策略。教堂那段的内容就是这样的

--- 第 255 楼来自 Lexus 的回复 (2026-02-01 21:43:40 PST) ---

这个楼里很多人没有讲到的是coding agent迭代的速度 不仅仅是现在能achieve什么

一般OAI 人类学的public 模型基本都是六个月前的SOTA

所以这个预测的时间基本可以说是基于目前SOTA,还没有release的model的判断

--- 第 256 楼来自 flywire 的回复 (2026-02-01 21:45:21 PST) ---

注释对ai意义不大

代码就是计算机的语言

--- 第 257 楼来自 kerrygold 的回复 (2026-02-01 21:45:45 PST) ---

4.5和4.1相比是个step function,之前我用cc也是骂骂咧咧的,11月之后停不下来

--- 第 258 楼来自 vczh 的回复 (2026-02-01 21:46:50 PST) ---

【引用自 土拨鼠工业发展促进会】:
奇技淫巧
我就特别擅长活用组装各种奇技淫巧,但是每次说到AI要怎么跟他配合的时候,大家都开始转移话题

--- 第 259 楼来自 flywire 的回复 (2026-02-01 21:46:51 PST) ---

现在的水平足够行业fire掉80%的人

只是行业什么时候会发生

底特律也不是一瞬间变变成这样的

--- 第 260 楼来自 Lexus 的回复 (2026-02-01 21:47:05 PST) ---

exactly,如果有follow X的话

这一次各位大佬也都是12月左右集体口风逆转

--- 第 261 楼来自 serelee 的回复 (2026-02-01 21:47:22 PST) ---

【引用自 salty】:
AI 给我的感觉是没有多少直觉。比如一个 SEV 发生,AI 只会傻傻看 code,事实上很多时候吃经验的。有的 alert 很 high level,属于 catch all,比如我看一下是不是 customer 自己程序在 crash looping 导致了我们这边报警,是就不用管了。AI 没有那么多 context,我们也没教过他怎么查。
貌似oncall的这些行动,看dash,alert这些,很难采集数据。 没数据他就没辙

PE有可能是ai难以取代的

--- 第 262 楼来自 争取多活两年 的回复 (2026-02-01 21:48:07 PST) ---

凡是靠感觉的AI都没戏。

--- 第 263 楼来自 土拨鼠工业发展促进会 的回复 (2026-02-01 21:48:16 PST) ---

这就是问题啊

AI比极乐迪斯科里面的金差一些 金可以给你基本正确的standardized format 但是不一定给你正确的insight

--- 第 264 楼来自 vczh 的回复 (2026-02-01 21:48:45 PST) ---

假如说的是软件行业,但这又不是在每一个公司里都开除80%的码农,而是80%的公司干脆不要自己做了,全让剩下的20%做

--- 第 265 楼来自 flywire 的回复 (2026-02-01 21:49:22 PST) ---

技术上完全可以

实现难是

行业会有push back

现在应该考虑的是when不是if

3年到5年应该没问题

--- 第 266 楼来自 Zig 的回复 (2026-02-01 21:49:26 PST) ---

【引用自 vczh】:
就算代码写的难以重构又怎么样呢,下次再写一次就好了
这个 argument 实际上是错的。

因为这是在假设计算能力无限。实际上过去的成型代码肯定是影响下一次需要重写的时候需要的计算能力的。

--- 第 267 楼来自 争取多活两年 的回复 (2026-02-01 21:49:27 PST) ---

其实这个问题换个说法。全地区80%的人自杀,剩下的照样活的好好的。问题是哪80%的自杀。

--- 第 268 楼来自 vczh 的回复 (2026-02-01 21:50:53 PST) ---

从今天看当然是不对的,但是既然我们要相信AI的发展,那为什么不相信微软投资的聚变电厂成功落地然后给copilot提供无限的电源呢

--- 第 269 楼来自 flywire 的回复 (2026-02-01 21:52:14 PST) ---

那么还是会有大量码农失业

供大于求

大家收入都会降低

直到码农变成一个性价比很低的普通工作

--- 第 270 楼来自 矮胖超人 的回复 (2026-02-01 21:52:48 PST) ---

P2最近肉身投资电力公司了,可能是不错的选择这么说?

--- 第 271 楼来自 vczh 的回复 (2026-02-01 21:53:41 PST) ---

所以钱得早点赚,等大家攻略都出来开始一窝蜂转码的时候,就是新人别来的时候了。现在新人又得去做大家不愿意做的新工作了

变的性价比低但不至于,未来的码农要么就是专业操作AI要么就是专业给AI擦屁股,哪个都不好做,感觉会变成今天的COBOL码农。一年来给你七位数,但是为什么没人去学呢

--- 第 272 楼来自 zzfdafw 的回复 (2026-02-01 21:56:25 PST) ---

完全消失不太可能 毕竟还需要人用ai

也不太可能把entry level都开掉 毕竟senior/lead也会走 enrry也得培养

就是不知道整个行业会砍多少码农 整个过程要多久

--- 第 273 楼来自 Zig 的回复 (2026-02-01 21:57:28 PST) ---

无限的电源也不可能把所有的问题的计算复杂度搞成一样的,毕竟有现成的 P != EXP 的结论呢。

--- 第 274 楼来自 vczh 的回复 (2026-02-01 21:59:42 PST) ---

没事,真的做不出来的问题人类尝试之后依然会放弃让AI做的的,但是大部分能做的就可以一直做下去

--- 第 275 楼来自 evilcatx 的回复 (2026-02-01 21:59:45 PST) ---

Decision Making 还是 很重要的

这么好用的Cladue Code 在因为React → TUI 做diff 实现60fps

很难评价

--- 第 276 楼来自 赢赢赢 的回复 (2026-02-01 22:02:02 PST) ---

为什么大家会觉得这是个零和游戏呢,码农或者说工程师有了更智能更强大的工具,单位时间内可以做的事情更多了,可以数字化和处理更多物理世界的数据,提高生产力,生产出更多提升人类生活质量的产品。去火星,治疗不治之症,具身智能,哪个项目ai能独立完成?

--- 第 277 楼来自 ra1n 的回复 (2026-02-01 22:04:48 PST) ---

有一个原因是 码农或者说工程师自己的 differentiator 不大了。换其他的人也能做

--- 第 278 楼来自 vczh 的回复 (2026-02-01 22:05:21 PST) ---

人的职业生涯就那么几年,我相信你说的事都会发生,但是我觉得我等不到了

--- 第 279 楼来自 收束观测者 的回复 (2026-02-01 22:06:29 PST) ---

【引用自 赢赢赢】:
单位时间内可以做的事情更多了
因为市场不是无限的

资本主义经济危机了解一下

为什么西方世界这么拼命搞消费主义?

--- 第 280 楼来自 abcdmexico 的回复 (2026-02-01 22:09:16 PST) ---

不仅仅是码农,当搭配AI的人形机器人问世之后,大部分行业中的大部分职业都会被替代。很多人没意识到,AI人形机器人是一个新物种,在智力和体力两方面都碾压人类,必然会挤压人类的生存空间。

以史为鉴没有意义,因为这是人类历史上第一次真的不需要人了。在各行各业被逐步替代的阶段,尽量减少负债吧,不要掉坑里,活下来,笑到最后,会有一个美好的未来。

尽量享受当下,活在当下。

--- 第 281 楼来自 vczh 的回复 (2026-02-01 22:10:43 PST) ---

这个确实,至少西雅图某个韩国餐厅再也不需要招聘拿着计算器都不知道怎么分三张卡的服务员了

--- 第 282 楼来自 赢赢赢 的回复 (2026-02-01 22:14:35 PST) ---

也许我是错的吧,但人类发展这么多年了,居然住房都还是个问题,我感觉离需求饱和还有很远的路要走

--- 第 283 楼来自 jzj 的回复 (2026-02-01 22:17:05 PST) ---

我觉得OpenAI在把钱烧光之前应该做不出这个。

--- 第 284 楼来自 收束观测者 的回复 (2026-02-01 22:17:08 PST) ---

【引用自 赢赢赢】:
人类发展这么多年了,居然住房都还是个问题,我感觉离需求饱和还有很远的路要走
可以随便找本经济学入门教材读一读

有支付能力及支付意愿的需求才叫需求

这就是为什么供需关系曲线里需求和价格成反比

历史告诉我们生产力极大发展更有可能是倒牛奶而不是共产主义

--- 第 285 楼来自 hoodl 的回复 (2026-02-01 22:27:33 PST) ---

代码还有一点点从头开始理解问题的可能。我反正想象不出到时候怎么debug skills。本来就是一个概率的结果,怎么重现问题呢?

--- 第 286 楼来自 mrmiywj 的回复 (2026-02-01 22:33:19 PST) ---

我给Claude 一个perfetto 图,然后告诉它我要tune 某个kernel,让它写micro benchmark 写出来一坨狗屎

--- 第 287 楼来自 yoyo2025 的回复 (2026-02-01 22:38:17 PST) ---

感觉每天都有个小助手帮我上班 claude虽然不是万能 但是太好用了

--- 第 288 楼来自 火箭升空 的回复 (2026-02-01 22:42:33 PST) ---

同感 但效率提高是因为和过去的自己和别人比

未来的趋势之一 肯定是要求远远超过现在的产出 per human worker

--- 第 289 楼来自 Lexus 的回复 (2026-02-01 22:48:33 PST) ---

你有把你们目前所有的kernel喂进去吗

--- 第 290 楼来自 mrmiywj 的回复 (2026-02-01 22:49:46 PST) ---

当然全喂了,没啥用…. 如果我比较specifically 告诉它怎么改那还是可以改过来的

--- 第 291 楼来自 ctzsm 的回复 (2026-02-01 23:00:48 PST) ---

时薪会超低,因为一方面很多人被迫干这些活,另一方面出的起钱找人干这些活的人也变少了。你逛逛泥潭手工区就知道很多人其实平时也做装修,比如 @打豆豆 @Dr.L

--- 第 292 楼来自 打豆豆 的回复 (2026-02-01 23:05:09 PST) ---

我也觉得…装修毕竟是非必要消费。大部分人失业的时候装修需求也很低了。至于维修,现在好多人抱着“我时薪大于维修费就该找人修”的傲慢态度,等大部分人没工作了,每天在家不赚钱,还担心修不好那个车库门,必须要找人上门花$500换那根弹簧吗

--- 第 293 楼来自 vczh 的回复 (2026-02-01 23:08:40 PST) ---

【引用自 打豆豆】:
现在好多人抱着“我时薪大于维修费就该找人修”的傲慢态度
这个statement成立的前提是维修真的挤掉了他赚钱的时间,至少对于所有非计件收入的工作都是无效statement

--- 第 294 楼来自 打豆豆 的回复 (2026-02-01 23:10:59 PST) ---

爱在非工作时间上班的人就爱那么想 哪怕领的是年薪

--- 第 295 楼来自 vczh 的回复 (2026-02-01 23:11:21 PST) ---

【引用自 hoodl】:
我反正想象不出到时候怎么debug skills
没法debug。特别是去年各个模型还良莠不齐的时候,你写的prompt在这个模型能跑换一个就不能跑了。这件事到了后来才慢慢得到解决

具体到skill,每个编辑器还有不同的特征,之前就听说有人发现vscode他就只读一百行,不过以后总会修的吧

而且如果你要求他用这个skill他就一定会用,所以也干扰了你debug 。这跟模型的性格还很有关系,比如有些他就死都不愿意打开debugger,在代码里猜到死也不下个断点,难为我都把脚本给他弄好了

--- 第 296 楼来自 KanShu 的回复 (2026-02-02 00:48:44 PST) ---

不能同意更多。个人背景是高中时候的OIer,大学学EE只写过少量代码。工作之后转PM不再亲自写代码,再后来干脆做的事情跟软件开发无关。能看懂大部分代码,但要上手写的话大概只有基础最深的C语言可以,其他更实用的语言都不行。之前经常有一些想法,但因为coding能力有限都放弃了。

自从有了AI,加上基础阅读代码和除错的能力,几乎所有我的想法都可以在很短时间(几小时内)做出来。仅去年一年就在github发了四五个项目,还给好几个大的开源项目贡献过代码,加起来拿了快4000颗星。

AI时代,写代码的能力也许不再重要,重要的是需要能够清晰而有逻辑地表达清楚自己的需求——而这个恰恰是很多人都缺乏的。

--- 第 297 楼来自 tty17 的回复 (2026-02-02 00:50:40 PST) ---

【引用自 KanShu】:
仅去年一年就在github发了四五个项目,加起来拿了快4000颗星
简单说一下是什么项目?学习一下思路

--- 第 298 楼来自 KanShu 的回复 (2026-02-02 00:53:15 PST) ---

https://github.com/kanshurichard

--- 第 299 楼来自 vczh 的回复 (2026-02-02 01:15:09 PST) ---

看起来是个越狱脚本,不过坛友最简单的办法还是chase shop Apple 1.5cpp的时候买个mac mini

--- 第 300 楼来自 325070760 的回复 (2026-02-02 02:22:51 PST) ---

这,这明显是生产关系的问题啊,哪是生产力的问题 马斯克的一部分言论为啥招人恨,就是因为他(不知道是不是故意)混淆了这两者…

--- 第 301 楼来自 Gilbertizer 的回复 (2026-02-02 02:36:56 PST) ---

目前的感觉是,我的确不需要一个小弟来给我写代码了…感觉new grad/mid level越来越难了

--- 第 302 楼来自 jnnksn 的回复 (2026-02-02 02:39:21 PST) ---

Amazon不是说2027吗,拭目以待

--- 第 303 楼来自 jnnksn 的回复 (2026-02-02 02:39:54 PST) ---

转quant来得及吗

--- 第 304 楼来自 jnnksn 的回复 (2026-02-02 02:41:08 PST) ---

【引用自 KanShu】:
AI时代,写代码的能力也许不再重要,重要的是需要能够清晰而有逻辑地表达清楚自己的需求——而这个恰恰是很多人都缺乏的。
明白了,逻辑学PhD是最后一个能在tech company保住饭碗的

--- 第 305 楼来自 KanShu 的回复 (2026-02-02 05:27:35 PST) ---

是知乎轮子哥本尊吗,失敬失敬。

您就别来嘲讽我们小透明的小打小闹了。

--- 第 306 楼来自 jnnksn 的回复 (2026-02-02 05:40:42 PST) ---

【引用自 打豆豆】:
现在好多人抱着“我时薪大于维修费就该找人修”的傲慢态度,等大部分人没工作了,每天在家不赚钱,还担心修不好那个车库门,必须要找人上门花$500换那根弹簧吗
【引用自 vczh】:
这个statement成立的前提是维修真的挤掉了他赚钱的时间,至少对于所有非计件收入的工作都是无效statement
那时候是不是倒贴修

--- 第 307 楼来自 LAWANDORDER 的回复 (2026-02-02 06:32:46 PST) ---

半天盖了300楼

看来你们是真的很椒绿

--- 第 308 楼来自 Rosmontis 的回复 (2026-02-02 06:33:54 PST) ---

半天

6小时

--- 第 309 楼来自 deepbluenight 的回复 (2026-02-02 06:59:29 PST) ---

房地产网站Realtor.com表示,万一人工智慧泡沫化,加州经济可能迅速崩塌。

.

房地产网站Realtor.com表示,加州许多领域现在都是由目前正蓬勃发展的人工智慧支撑著,一旦人工智慧泡沫化,加州可能像纸牌屋那样迅速崩塌。

--- 第 310 楼来自 Rosmontis 的回复 (2026-02-02 06:59:47 PST) ---

The Verge – 22 Jan 26

Claude Code is suddenly everywhere inside Microsoft

Microsoft is increasingly adopting Claude Code

好应景?

--- 第 311 楼来自 IRS_pro 的回复 (2026-02-02 07:44:38 PST) ---

【引用自 002】:
吹AI coding的感觉外行居多?真用过的应该都会骂吧…
我现在95%的代码都是 AI 写的,只要 prompt 好基本上什么都能写出来

--- 第 312 楼来自 ctest 的回复 (2026-02-02 07:49:48 PST) ---

【引用自 LoRA】:
这个可能正是ai的擅长,通过分级agent处理超复杂系统
要是能理解这种代码,我估计这套AI跑L4驾驶,也能自己设计芯片。

要是AI能做到Linux Kernel代码自动进化,不再需要人工参与维护,应该就差不多了,我们这坨屎山比哪个还难理解,最狠的是有人曾经leetcode刷题时,不想建项目,把代码都提交进去过,虽然后来删除了
【引用自 KanShu】:
加起来拿了快4000颗星
其中3.3k星来自于enableAppleAI脚本?

--- 第 313 楼来自 Small-Potato 的回复 (2026-02-02 07:52:37 PST) ---

【引用自 002】:
描述清楚不就是在写代码?我都能描述清楚了,直接写不就完了
你可能是指:编译器

然后prompt变得越来越复杂越来越精确,最终演变为了一门新的编程语言

--- 第 314 楼来自 ctest 的回复 (2026-02-02 07:58:13 PST) ---

还是期待AI能进化,以后厂商把datasheet直接喂给AI,它就自动产生出来Linux Driver代码,这样就省事了。

--- 第 315 楼来自 收束观测者 的回复 (2026-02-02 08:08:32 PST) ---

【引用自 Small-Potato】:
编译器
从另一个角度看

程序员这个职业可能就是一个自然语言的编译器

需求描述不清楚的人从程序员这里也拿不到想要的程序

--- 第 316 楼来自 carol1680 的回复 (2026-02-02 08:09:26 PST) ---

那么,对于low level coder 来说,中国和美国哪里更适合存活呢?中国成本更低

--- 第 317 楼来自 bujidao 的回复 (2026-02-02 08:11:33 PST) ---

纯coder哪都不行 虽然暂时好像国内ai coding没有很风靡 但是也不差这一两年

--- 第 318 楼来自 yyss8 的回复 (2026-02-02 08:19:50 PST) ---

去年AI可能写的真烂 现在觉得AI写的烂可能要重新审视下自己给的prompt对不对

就像程序员的老埂 你问别人需求是什么 人家说你就给我做个淘宝 百度这样的网站吧 至少AI还不会翻你白眼

现在写prompt建议先在chat上跟AI探讨一下然后让AI给你写prompt 直接复制进CC或者Codex

--- 第 319 楼来自 carol1680 的回复 (2026-02-02 08:20:12 PST) ---

那咋赚钱呢?

--- 第 320 楼来自 anon10682038186 的回复 (2026-02-02 08:21:01 PST) ---

重仓NVDA / TSM 之类的做对冲

--- 第 321 楼来自 雾雨魔理沙 的回复 (2026-02-02 08:23:37 PST) ---

token再贵也比码农工资便宜吧

--- 第 322 楼来自 AmericanExpress 的回复 (2026-02-02 08:40:59 PST) ---

我不认为现阶段的AI具有逻辑思维能力,所谓的LLM暂时还是超大型博闻强识的鹦鹉学舌。等AI有了逻辑思维能力,就快到黑客帝国时刻了。

AI强的地方在于把重复造轮子的代价降到了最低,如果有1000个人写过类似的CRUD,那交给AI就完事了,自己盯着test case就行。你觉得AI的prompt好厉害,那是你不知道AI在什么犄角旮旯的repo里见过一毛一样的usecase。但是对于独特的情况,AI只能提建议做补充,还是得亲手上。我是不敢把vibe出来的东西看都不看往prod deploy。

--- 第 323 楼来自 bujidao 的回复 (2026-02-02 08:45:13 PST) ---

逻辑思维和自主意识 很难说一个能不能独立于另一个存在

如果真的有自主意识,那只能说good luck 碳基生命

--- 第 324 楼来自 teirt15 的回复 (2026-02-02 08:45:33 PST) ---

看趋势这个帖能进吵架板块?

--- 第 325 楼来自 收束观测者 的回复 (2026-02-02 08:48:27 PST) ---

【引用自 AmericanExpress】:
逻辑思维能力
逻辑思维的本质可能不过是知道某些描述在因果关系介词后面跟上什么样的描述是合理的这么一件事而已

--- 第 326 楼来自 up9080 的回复 (2026-02-02 08:48:56 PST) ---

【引用自 AmericanExpress】:
LLM暂时还是超大型博闻强识的鹦鹉学舌
如果一个鹦鹉说起来像人,写起来像人,那就是人。或者在最顶层眼里,就是人。

--- 第 327 楼来自 IcyJ 的回复 (2026-02-02 08:50:38 PST) ---

码工们都赚够退休钱了, 慌啥

--- 第 328 楼来自 sukasky 的回复 (2026-02-02 08:52:30 PST) ---

【引用自 PocketKimi】:
你去linkedin看看O和A 一共才有几个5年以下的纯SWE?
O和A这两年都在扩招,以前基本都是招的senior+,现在entry level,两三年经验的纯swe招了好多,A今年更是要double size。是不是ai越来越差啦?

--- 第 329 楼来自 星际牛仔 的回复 (2026-02-02 09:02:42 PST) ---

如果逻辑思维能力本质上其实就是鹦鹉学舌呢?

这个在哲学/认知论领域讨论的很多了,虽然不是共识,但是经验主义一直是个主流观点。

比如说1+1=2是逻辑推演,但是如果这个知识的本源仅仅是因为先人数了几百万次一个石头加一个石头等于两个石头?

--- 第 330 楼来自 Zig 的回复 (2026-02-02 09:10:00 PST) ---

那不是几百年前就被批判过了。纯粹的经验主义无法构造概念。

康德通过《纯粹理性批判》证明了单纯的经验主义(认为全部知识皆源于经验)和绝对的理性主义(认为脱离经验可认知本体)都是片面的,主张知识是经验素材与先天形式的统一。

--- 第 331 楼来自 allin 的回复 (2026-02-02 09:11:20 PST) ---

智能到底是什么,其实没有明确定义。 如果80%的问题,AI能解决,那我假定他其实有80%的智能。 这是结果论。

--- 第 332 楼来自 Rosmontis 的回复 (2026-02-02 09:17:35 PST) ---

你把康德的话当做绝对真理,康德知道吗

--- 第 333 楼来自 Zig 的回复 (2026-02-02 09:18:11 PST) ---

按照结果论来说,目前的 AI 现在能解决10%就不错了。

现在哪怕技术公司的叙事都改成 AI 最终能替代人而不是现在就能替代 xx 人了。

--- 第 334 楼来自 星际牛仔 的回复 (2026-02-02 09:20:44 PST) ---

并不是

最近几年哲学界因为AI的出现激进经验主义又回潮了。康德又不是宇宙真理。

最主要的问题是AI其实在冲击归纳(deduction)和演绎(induction)的区别。

我举个例子:我们都知道乌云密布证明要下雨,但是这个【如果P-那么Q】的逻辑式我们作为儿童是如何最先获得的?可能是书本上学的,可能是自己无数次的观察,也可能是父母的一句话。

对于AI来说,因为它可以阅历人类上亿的小说、散文、电影、甚至社交媒体,在其中发现了两千万例主角提到天气转阴——随后剧情出现下雨。尽管AI不可能亲眼见过什么是阴云什么是下雨(或者说,没法真正设身处地的体验),但是AI仍然可以完美的根据这两千万例归纳出:乌云密布等于要下雨,在此后AI每次都可以因为乌云判断要下雨。

那么这个界限就很模糊了。AI在这里做的到底是不是逻辑推理?

--- 第 335 楼来自 sukasky 的回复 (2026-02-02 09:21:12 PST) ---

【引用自 AmericanExpress】:
我是不敢把vibe出来的东西看都不看往prod deploy。
现在看起来ai在各个领域都是让厉害的人很厉害,不知道你们看过那些完全不懂代码的人vibe coding没有,基本上写出来的都是玩具。但是本来就是eng的,效率大大提升。

这很难justify取代码农这个论断,说实话,ai这个能力要说取代l3码农,那很多工种都可以取代了,最多码农键盘敲的响,天天在网上bbb而已。我看没有一个primary care doctor比ai厉害啊,先把他们都取代吧

--- 第 336 楼来自 Wuziqumu 的回复 (2026-02-02 09:26:04 PST) ---

这是老板们喜欢的提法

--- 第 337 楼来自 brokenarcher 的回复 (2026-02-02 09:36:21 PST) ---

前两天想用antigravity捏个小project 但因为是前端我不懂所以就让它自己发挥

总的感觉是AI很擅长planning和documentation以及基础的框架 但遇到细枝末节的问题很容易钻牛角尖然后就stuck in a loop 这时候还是需要human in the loop有这方面的技能帮它钻出来 还有一个问题是AI有时候会突然很笨忘记context 明明自己之前script里写得挺好的 换个角度同样的问题突然就不会了

--- 第 338 楼来自 xxxyyy 的回复 (2026-02-02 09:44:26 PST) ---

整个黑灯代码工厂

--- 第 339 楼来自 xxxyyy 的回复 (2026-02-02 09:45:49 PST) ---

那公交车出来了,私家车出来了,岂不是出租车早该淘汰了

司机可以坐副驾驶当安全员,当负责搬行李提供情绪价值的人。

uber 20刀,blacklane 120刀。总不能是blacklane司机开车技术好值100刀吧。

车的成本3刀,平台抽了uber 10刀,uber司机一单赚7刀。自动驾驶只去掉了这7刀的成本,blacklane跟着降价7刀也能收113刀

--- 第 340 楼来自 Labubu 的回复 (2026-02-02 09:49:47 PST) ---

这个问题好像很普遍,涉及到文字压缩问题,昨天和ChatGPT讨论过,好像没有太好的解决方法,只能让他重读一遍context

--- 第 341 楼来自 Bilt2.0 的回复 (2026-02-02 09:51:52 PST) ---

码农的工作也不全是敲代码啊

码农作为工程师,工作的本质就是使用工具来解决问题,至于代码是怎么产生的本来就并不重要。重要的是解决问题的能力。

--- 第 342 楼来自 hoodl 的回复 (2026-02-02 10:04:17 PST) ---

你说得很好,但现在的生成式AI不是这样工作的。

--- 第 343 楼来自 AWADA 的回复 (2026-02-02 10:04:32 PST) ---

老百姓能归纳总结出来乌云要下雨,甚至能抓到一些信号去泛化

一些科学家能形式化总结出来乌云下雨后面的laws,通过数学形式推演出来

LLM更多是见过各种各样形式的乌云下雨,没法验证有归纳能力,也没发验证有演绎能力

--- 第 344 楼来自 POI 的回复 (2026-02-02 10:06:04 PST) ---

不会消失只会转移,毕竟高级编程语言出现前不是也没有码农这个职业

--- 第 345 楼来自 Zig 的回复 (2026-02-02 10:12:32 PST) ---

【引用自 星际牛仔】:
AI在这里做的到底是不是逻辑推理
这问题并不重要。关键是是不是认为理性里面有先验的部分。否则这个“有乌云就要下雨”就是一个对于现象的阐述,而不是理性的知识。知识是说“为什么有乌云就要下雨”。不能给出原因就无法确定因果。

--- 第 346 楼来自 DanielCarroll 的回复 (2026-02-02 10:13:22 PST) ---

还是有一些路要走的,如果要完全替代 IC4 和 IC5 的话,生产出问题了 AI 公司负责吗?谁有信心让自家的 AI tools take full responsibility?如果负责了,那出重大事故之后这公司会不会赔死?就像自动驾驶撞死人了一样。

如果不负责的话,那还是需要一些 SDE 作为 reviewers 守门的。代码可以不用写,但责任需要有人来扛。

--- 第 347 楼来自 newhope 的回复 (2026-02-02 10:20:43 PST) ---

所以各大厂的屎山就是这么来的是吧

话说如果以后都用AI出代码的话,屎山究竟是会变大还是会变小呢?

--- 第 348 楼来自 海洋联盟 的回复 (2026-02-02 10:21:57 PST) ---

Science fiction really only precedes science fact by a few years, at most, these days

--- 第 349 楼来自 Bilt2.0 的回复 (2026-02-02 10:22:48 PST) ---

【引用自 newhope】:
话说如果以后都用AI出代码的话,屎山究竟是会变大还是会变小呢?
看公司文化,如果本来就是code review都没,unit test都不写直接裸奔的公司,用AI肯定会提升代码质量。但是本来review文化就很好,test健全的话,代码质量并不会有太大改变,但是依然会提升代码产出效率

--- 第 350 楼来自 TheWorld 的回复 (2026-02-02 10:23:45 PST) ---

我也最近只用AI写了,不过有点奇怪组里的产出提升不显著,想问一下大家感觉到身边生产力提升的幅度大概是多少,可以减少多少人力?

--- 第 351 楼来自 假节钺 的回复 (2026-02-02 10:23:58 PST) ---

【引用自 DanielCarroll】:
谁有信心让自家的 AI tools take full responsibility?如果负责了,那出重大事故之后这公司会不会赔死?就像自动驾驶撞死人了一样。
简单呀,只用一些QA和极少量dev就好了,对结果把关

--- 第 352 楼来自 DanielCarroll 的回复 (2026-02-02 10:26:25 PST) ---

我同意需要的 SDE 会变少(如果业务没有变多的话),不过 SDE 这个职业仍然会存在。

--- 第 353 楼来自 假节钺 的回复 (2026-02-02 10:28:10 PST) ---

【引用自 DanielCarroll】:
不过 SDE 这个职业仍然会存在。
sde或许不会消失,就像司机也一直存在,只不过从马车司机变成黄包车司机变成手动挡司机再变成自动挡司机,职能相似但技能完全变了

--- 第 354 楼来自 Zig 的回复 (2026-02-02 10:28:24 PST) ---

【引用自 假节钺】:
对结果把关
稍微大一点的公司都对什么是“结果”吵不清楚。更别说到底谁对什么负责了。

最经典的例子就是假如你用的某个 tool 做了一次版本更新,公司 IT 更新的 tool chain 没告诉你。这个 tool 里面有 bug 导致了生成出来的代码有隐蔽的 bug,算谁的?以前 intel 可是出过 microcode 出 bug 这种神奇的事情的。

--- 第 355 楼来自 ctzsm 的回复 (2026-02-02 10:29:56 PST) ---

【引用自 Zig】:
以前 intel 可是出过 microcode 出 bug
现在也还在发生,并不神奇。

--- 第 356 楼来自 DanielCarroll 的回复 (2026-02-02 10:35:27 PST) ---

【引用自 假节钺】:
职能相似但技能完全变了
这类事情其实一直在发生,SDE 从最早的打纸带,到写 low-level programming languages,然后转变成 high-level,一行代码启动一个高性能 server。现在只不过是换成了 nature languages 了。

本质并没有发生太多变化,只是 scope 一直在增加,以及不断的 shift left。

--- 第 357 楼来自 DanielCarroll 的回复 (2026-02-02 10:38:29 PST) ---

可能边 vibe coding 边看论坛吧

--- 第 358 楼来自 bujidao 的回复 (2026-02-02 10:41:42 PST) ---

这楼里大部分在宣扬ai coding无敌的人估计都没碰到过这种问题

--- 第 359 楼来自 Puebla 的回复 (2026-02-02 10:44:23 PST) ---

我也说两句……

最近就着没事,仔细复盘了一下我做SDE的经历。

大部分SDE与其说是需要“技术力”,更多的是“通过技术解决商业问题/制作一个商业可行的产品”,所需要的技术力并没有那么高。这就是为啥“转码”是可行的,因为做SDE所需要的99%技术力并不需要一个四年的科班学位(e.g. 你拿着Java写业务代码压根不需要知道内存管理是怎么操作的)

然后Gen AI很擅长的就是在已有的知识库里找已有的知识,加以理解和应用。

我最近在研究知识论(虽然很浅显),感觉需要知识的工作都在一个spectrum上,一边是用已有的知识加以应用,另一边是在已有的知识的基础上创造新的知识。大部分SDE的工作都靠近前者,巧了吗这不是,AI擅长的也是前者。

虽然话说回来Gen AI在逐渐学习后者,但是我感觉离着能做到还很远。然后在这之前,应该研究怎么做到更让自己的工作接近后者,而不是前者。

突然想明白我在高中的时候为啥不想做工程了,可能那个时候的我就已经想做“探索知识、创造知识的人”而不是“应用知识”的人。不过话又说回来,人类史上能做到这一点的,感觉一直都是少数幸运儿,可能想努力做到但是做不到的人更多一些吧。

大致这样,欢迎反驳。

--- 第 360 楼来自 vczh 的回复 (2026-02-02 10:48:09 PST) ---

【引用自 yyss8】:
重新审视下自己给的prompt对不对
AI的问题又不是在他写不出来而是他只写得出来一部分,你做的刚好他会流很简单,做的刚好他不会能就抓瞎吧

我正好有个例子,几个月前再给我的GUI库做HTML 5 rendering。里面有些测试页面当普通网站来写,两句话就吭哧吭哧全做出来了,还不用debug。另一部分是从我的一个virtual dom拼出HTML,对人类来说那就是同一件事,而AI就只会生成很多前后矛盾的CSS style,每一个style 孤立地看都是没问题的,但是一旦递归组合起来,就会互相干扰。说到底这是CSS的问题,但是难道工具不合适我就不做了吗?硬整能整出来之后对不会硬整的人就产生了价值

故事的最后是这部分代码我自己来

--- 第 361 楼来自 bujidao 的回复 (2026-02-02 10:55:59 PST) ---

因为产出的制约因素不止是写码速度,而AI现在只擅长写码。

举个例子,以前file一个bug只要给reproduce steps和symptom,然后dev会去follow steps 复现问题,找出出错的codepath,identify root cause,然后结合其他context,决定可能的解法。AI也可以做这些,但是你想想你要在这个ticket里给出多少context。写码时间的减少被转移到了别的地方,总时间还是减少了,但是没有宣传的那么多

--- 第 362 楼来自 hjysos 的回复 (2026-02-02 10:56:22 PST) ---

+1,我司ic4就得会自己从头到尾完成一个project了,包括跟pm讨论需求,写design,design review,写代码,跑实验,分析实验结果,然后各方拿到approval最后才能launch。敲代码真的只是很小一部分而且不重要,分析实验结果,像楼上说的那样debug,然后做决策,这些我觉得更花时间

--- 第 363 楼来自 wutu 的回复 (2026-02-02 11:18:33 PST) ---

我家领导前段时间要run一个lab,她不是码工。所以找了其它两个码工组的manager,对方还在凹造型说没空啊,要很久才能做完啊。领导用了公司内部的AI工具,加了两个晚上的班,自己做好了。她跟我说现在AI实在是太强了,有跟别的组扯的时间,自己就搞好了。

--- 第 364 楼来自 yyss8 的回复 (2026-02-02 11:36:09 PST) ---

AI至今还有胡编乱造的问题, 不过没去年初那会那么严重了. 可能跑的知识库大了.

至少你把文档给丢给它还会承认自己的错误 所以还是回到之前说的prompt的问题

另一部分是从我的一个virtual dom拼出HTML

比如这个, 有经验的人经常能跳跃性的联想到一些东西, 因为我们脑子里已经存着比如我的一个virtual dom拼出HTML这种潜意识的context. 我觉得AI现在没有足够context的话还不能验证他给出的答案是否正确就比较抓瞎. (给多了又很贵 ) 就像一个写网站的光给需求不让用浏览器. 新的IDE anti gravity有一点我挺喜欢的就是他能自己打开页面看实际效果甚至还会读文档自己清缓存之类的.

不管怎样先和chat探讨问题和流程 然后让他写 chat能写出比较严谨的什么不要什么什么 要什么什么

比自己写两三句等AI做出来再改会好一点 到时候可能就一路走到黑了

--- 第 365 楼来自 争取多活两年 的回复 (2026-02-02 11:38:25 PST) ---

以前码农写C++,现在码农写prompt。不就是个编程范式的转换嘛。

大部分码农在公司里面本来就不是只coding,而且除了sales外所有问题都要处理。

--- 第 366 楼来自 aaa 的回复 (2026-02-02 11:38:59 PST) ---

回到了

“就差一个程序员啦”

的定位

但人数减少肯定是不可避免的,市场扩张终究有限,现代农业用的人口确实比古代低得多

--- 第 367 楼来自 See 的回复 (2026-02-02 11:39:11 PST) ---

【引用自 Startrek】:
最新的ai coding
是哪个?求推荐

--- 第 368 楼来自 Puyi 的回复 (2026-02-02 11:39:52 PST) ---

求推荐呢

--- 第 369 楼来自 争取多活两年 的回复 (2026-02-02 11:41:47 PST) ---

现在新需求大部分都是需要码农的。无非是以前吹software is eating everything,现在software written by AI is eating everything。以后火箭发射都是defined by software了。

--- 第 370 楼来自 devilevga 的回复 (2026-02-02 11:42:27 PST) ---

【引用自 vczh】:
你做的刚好他会流很简单
感觉就是99.9%做的都太简单了,AI轻松搞定? 真正难的AI也没办法,只有少部分会碰到困难问题,大部分做的都是简单问题(却自以为做的东西有挑战然后觉得AI牛逼)?

--- 第 371 楼来自 yyss8 的回复 (2026-02-02 11:43:12 PST) ---

不太应该叫转换, 更像是简化 所以大家就变廉价了 更遭的是 程序写的好的人话不一定能说的好 一件事不一定有文科的人描述的完整

以前大家说的啥都懂一点, 啥都不精可能不是坏事了 因为AI可以帮你变精 不同行业的门栏被抹平了

--- 第 372 楼来自 aaa 的回复 (2026-02-02 11:46:51 PST) ---

需求主要还是看社会发展吧,感觉牢美疫情后的剧本逐渐就是往普通人流向服务业服务少数有钱人发展了,新入场的码农可能越来越低端化而头部财富集中更强,就像搜索引擎取代报纸广告的变化。

当然谁也不知道下一个经济上行周期什么时候就来了,会不会真的打一仗,甚至连三年后的选举都不好预测了。

--- 第 373 楼来自 争取多活两年 的回复 (2026-02-02 11:47:35 PST) ---

【引用自 yyss8】:
程序写的好的人话不一定能说的好 一件事不一定有文科的人描述的完整
怎么可能。AI也都是程序写的好人的train的,可能更理解程序写得好的人说的话。文科逻辑AI才不懂呢。

--- 第 374 楼来自 争取多活两年 的回复 (2026-02-02 11:48:21 PST) ---

true。牢美现在向封建化发展。

--- 第 375 楼来自 carol1680 的回复 (2026-02-02 11:48:50 PST) ---

所以在这个关头,应该在中国还是美国呢?中国成本更低,美国可以薅的羊毛更多

--- 第 376 楼来自 争取多活两年 的回复 (2026-02-02 11:49:39 PST) ---

来回横跳啊。或者肉身在中国,资产在美国,虚拟薅羊毛。

--- 第 377 楼来自 aaa 的回复 (2026-02-02 11:52:23 PST) ---

传送门是吧

其实有一定道理的是高风险部分在美国拼通胀,低风险部分在中国趁微通缩保值

对于普通人来说all in从来不是一个合理选项,所谓的all in多数时候只不过是有家族或者其他兜底选择罢了

--- 第 378 楼来自 uplus5f7b 的回复 (2026-02-02 12:09:45 PST) ---

【引用自 真的很需要】:
等到黄包车真淘汰了,都过去一百年了。
你确定真淘汰了?曼哈顿满大街都是拉黄包车的,还外放音乐巨大声
【引用自 Sunshine9】:
难道不是还应该有 说话沟通能力 和共情能力吗
说明颜值更重要了,同样都是写写prompt点点鼠标,老板宁愿挑个好看的,转码美女或成最大赢家
【引用自 Yangff】:
做结构性搜索的能力很差
叠一个 model context protocol 的 server 会不会稍微好点?我刚刚去
【引用自 收束观测者】:
直接去问gemini

【引用自 ra1n】:
用得越多的人越了解边界越担心
最近面试面了各种类型的公司,每轮我都问面试官这个问题,bar高的那几家都在高强度用ai,传统行业的反而都没听说过

--- 第 379 楼来自 Yangff 的回复 (2026-02-02 12:38:05 PST) ---

【引用自 uplus5f7b】:
叠一个 model context protocol 的 server 会不会稍微好点
不行,我的意思是llm没法做出正确结构性的的搜索计划

举个例子假如llm没见过ffmpeg的代码,他现在要靠search mcp去发现ffmpeg的api然后写一个提取视频某一帧的内容,他就会直接把ffmpeg 提取某一帧 这件类keyword丢去搜。

那ffmpeg确实网上事例代码多,llm能完成任务(能不能引起好搜到正确的API版本就不一定了,但这个更多是工程问题,很多时候你觉得某家ai做得好某家不好也是这方面的影响更大)。但是如果这是你自己的项目或者内部的项目,那llm就啥都找不到了

其实底层来说还是llm的老毛病,llm不知道自己不知道什么,所以在这种时候无法产生它在逻辑上需要引入什么知识的请求,而只能对你的请求进行总结然后产生关键词(或者说这本身就是带mcp的模型的prompt实现的一部分)

--- 第 380 楼来自 vczh 的回复 (2026-02-02 14:14:15 PST) ---

【引用自 Yangff】:
反映到coding就是,从这里应该用一个能实现效果X的api,到随便摸出来一个望文生义的接口Y,甚至毫无关联来自其他组件的Z,或者自己根据ABC想象出一个D然后就开始用
这就是我上面说的源码导读 而且我每一次给AI的命令都会带一个超长的prompt文件(不同的事就给不一样的文件),里面都提到了他必须去看,然后实际上就会load到这个目录,引导他产生正确的关键字

优点:做事稳定性大幅提高

缺点:对于一个不是AI写的项目这一步得人发起去组织,如果是工作上的那我绝对不会risk自己的perf去弄这个

--- 第 381 楼来自 Yangff 的回复 (2026-02-02 14:18:29 PST) ---

导读就把context用完了

--- 第 382 楼来自 vczh 的回复 (2026-02-02 14:19:25 PST) ---

1M context还是很多的,不过为了提高他的正确性,多用点tokens也是值得的,无非就是做业余项目也要一年好几个B罢了

--- 第 383 楼来自 Yangff 的回复 (2026-02-02 14:23:47 PST) ---

说是1M context其实底层模型还是几k十几k的硬凹出来的,塞的东西多了就弱智了

--- 第 384 楼来自 独一无二没有空格简短 的回复 (2026-02-02 14:26:19 PST) ---

Robotic取代大面积人工需要很长时间吗

--- 第 385 楼来自 deng 的回复 (2026-02-02 14:30:36 PST) ---

从Sonnet 4.5以后几乎就可以写95% code了 Opus 4.5以后几乎完全取代写代码能力

这些才没出几个月呢 这周就要release 5了 纯码工应该干不了多久了。

--- 第 386 楼来自 争取多活两年 的回复 (2026-02-02 14:45:42 PST) ---

你们天天都只写码吗?本老从工作第二年开始就不怎么写代码了。你们都是干什么的啊?

--- 第 387 楼来自 vczh 的回复 (2026-02-02 14:50:28 PST) ---

如果没有导读,他只会读更多不相关的东西,浪费更多。但是如果问题出在模型不行,那这个不是我能控制的,不行就只能等了

--- 第 388 楼来自 争取多活两年 的回复 (2026-02-02 14:51:59 PST) ---

我觉得也就这样了。tech行业都是一窝蜂提前把未来n年的增长给你overpromise出来。

--- 第 389 楼来自 vczh 的回复 (2026-02-02 14:53:57 PST) ---

讲道理,除了刚毕业的前两年,我就没怎么见过纯码工的活了。我觉得一直说这个属于网上闲聊画靶子了。第二年还没结束就得疯狂学习非编程类知识了,主要都是些刚发明出来的东西

--- 第 390 楼来自 Ding 的回复 (2026-02-02 14:57:30 PST) ---

肯定是越往上走写代码越少。不过你这个第二年就不怎么写代码的情况也很少见。至少到staff这个级别上,代码能力还是硬指标。

--- 第 391 楼来自 争取多活两年 的回复 (2026-02-02 14:57:33 PST) ---

是啊我也知道为什么有人天天写码。ICC是这样吗?

--- 第 392 楼来自 KanShu 的回复 (2026-02-02 15:18:27 PST) ---

【引用自 ctest】:
其中3.3k星来自于enableAppleAI脚本?
怎么,你有意见?有意见请跟那3.3K给我star的人说去

--- 第 393 楼来自 猎户葱 的回复 (2026-02-02 15:44:44 PST) ---

其实是做不到的。

我最近在写一个code尝试模拟之前的一个open problem看看能有啥进展,这LLM还是没有办法实现没见过的新东西。

LLM说到底不过是一个高级一点的拟合器罢了。

--- 第 394 楼来自 hjfhdjellskx 的回复 (2026-02-02 15:45:16 PST) ---

【引用自 yyss8】:
程序写的好的人话不一定能说的好 一件事不一定有文科的人描述的完整
Programming languages are also languages.

写程序和说话没什么本质上的区别。写程序等同于用语言描述,程序写得好就是描述的完整。

--- 第 395 楼来自 Puebla 的回复 (2026-02-02 15:56:58 PST) ---

不完全一样

natural language会有一些情绪,假设,常识,非逻辑的东西

programming language你没写 import tensorflow as tf 你就没法用

真要是跟programming language有点像的是法律和论文的语言吧感觉

--- 第 396 楼来自 争取多活两年 的回复 (2026-02-02 15:59:51 PST) ---

如果是这样的话码农人均泡妞高手。但现实正好相反。

--- 第 397 楼来自 Zig 的回复 (2026-02-02 16:08:22 PST) ---

【引用自 hjfhdjellskx】:
写程序和说话没什么本质上的区别
我这么多年过得最痛苦的事情之一就是在工业界遇到的好多人,哪怕是 CS 专业的,都好像从来没上过最基础的计算理论课一样。

虽然说的确 lambda calculus = turing machine,但是自然语言是可以表达出来 undecidable problem 的。这个意义上来说这两个 language 根本不是同一个东西是在混淆概念。

--- 第 398 楼来自 收束观测者 的回复 (2026-02-02 16:12:29 PST) ---

【引用自 Zig】:
都好像从来没上过最基础的计算理论课一样
用不到的东西考完试还没离开学校就忘了

这门课我就只记得教授吹的关于怎么用formal verification三天帮一个老大难项目找出来大半年搞不定的bug的牛逼了

--- 第 399 楼来自 Zig 的回复 (2026-02-02 16:14:17 PST) ---

【引用自 收束观测者】:
formal verification
这玩意对于设计 cpu 还是挺有用的,至少写好了不会成天要人出 microcode 不对的问题。

--- 第 400 楼来自 deepbluenight 的回复 (2026-02-02 18:40:02 PST) ---

在这场技术淘汰赛中,黄仁勋认为分水岭不在于技术背景,而在于思维模式。根据访谈内容,以下三类人将首当其冲面临危机:

第一类:没有主见、只会照表操课的人

这类工作者高度依赖既有流程,缺乏重新定义问题的能力。当AI能以更高精度执行标准化任务时,仅依赖固定SOP的人将失去存在价值。

第二类:不懂提问、无法与AI深度互动的人

黄仁勋直言,未来的核心竞争力在于“问对问题”。他坦言自己有九成的工作其实都在“提问”,若无法透过精准的提问与AI对话,即便坐拥最强大的算力也无法放大自身价值。

第三类:拒绝学习、将AI视为答案机的人

AI虽然是强大的“技术均衡器”,能缩小专业门槛,但使用者必须知道“要让AI做什么”。若仅是被动接收AI给出的答案,而不进行思考与判断,最终仍会被新的工作流程所取代。

--- 第 401 楼来自 felixdonum 的回复 (2026-02-02 19:54:52 PST) ---

清洁工没有被扫地机器人取代吗

--- 第 402 楼来自 salty 的回复 (2026-02-02 23:18:05 PST) ---

确实,主要问题是没人教。。AI 可以 run query 采集数据。但是没人告诉他,先去看看这个,如果怎么怎么样就怎么样。。。我自己是凭感觉,alert 那么多,我第一次见很多时候是临场发挥。我离职了,很多经验也就消失了哈哈哈哈。

--- 第 403 楼来自 Airmiles 的回复 (2026-02-03 11:49:56 PST) ---

我已经一个月没手搓过代码了。

--- 第 404 楼来自 325070760 的回复 (2026-02-03 11:59:38 PST) ---

所以agent设计现在才重要,一个没有记忆、feedback loop、工作流编排的llm用处也是不大的。另外dashboard之类的gui ai也是有办法理解的,最近我看到的一些research和我自己尝试的结果都表明foundation model对gui的理解能力已经很强了…

--- 第 405 楼来自 justoy 的回复 (2026-02-03 13:01:52 PST) ---

copilot是一坨。同样gpt 5.2,codex比copilot强太多了

--- 第 406 楼来自 vczh 的回复 (2026-02-03 16:32:22 PST) ---

你也可以在vscode里面用github copilot subscription登录codex

但是根据我的实际体验,写C++的时候,codex多出来的那点聪明才智根本没有用。我经常切着跑,完全没感觉出去别

--- 第 407 楼来自 unclewang 的回复 (2026-02-03 16:50:10 PST) ---

这职业消失就趁早消失的彻底点 一起毁灭吧

现在找工跳槽面试内容变难 工作里越来越多的人怕这怕那的狂搞政治+卷 没啥意思

不干了吧又怕FOMO

--- 第 408 楼来自 unclewang 的回复 (2026-02-03 16:51:37 PST) ---

md发个帖子突然发现我白金还掉了

--- 第 409 楼来自 richardfatman 的回复 (2026-02-03 17:00:28 PST) ---

忙着买eth吧

--- 第 410 楼来自 lllqqq 的回复 (2026-02-03 20:24:10 PST) ---

做ppt excel的 写doc的岗位也不少 哪个不能被取代的

只是码农工资高了被关注多

--- 第 411 楼来自 otonoco 的回复 (2026-02-03 20:26:40 PST) ---

好支持威武有希望了

--- 第 412 楼来自 IlllIIlIIIllIIl 的回复 (2026-02-04 01:23:37 PST) ---

你确定?为啥我看他们官网基本都是staff engineer了

--- 第 413 楼来自 Bsian 的回复 (2026-02-06 19:42:32 PST) ---

AI泡沫破裂了 → 码农完蛋

AI没有泡沫, 完全取代人类→ 码农完蛋

--- 第 414 楼来自 navimoe 的回复 (2026-02-06 19:56:00 PST) ---

skill 就是干这事的吧。我虽然没用过,不过貌似一开始会发一堆 skill 的描述在 context 里。如果 AI 觉得需要就会请求 skill 的具体内容。然后还可以支持 skill 的多层级嵌套。这样比每次都发一个超长的 prompt 省 token。

--- 第 415 楼来自 vczh 的回复 (2026-02-06 20:12:13 PST) ---

我是把我日常开发工作总结成了几个流程,我需要他干什么直接告诉他,跟skill的用法不太相符

--- 第 416 楼来自 小Z宝 的回复 (2026-02-06 22:08:58 PST) ---

对的,还可以一问一答让ai写点skills存到特定的位置,这样用到的时候才会搜索放进context里

--- 第 417 楼来自 大鸭蛋 的回复 (2026-02-07 10:48:50 PST) ---

转行职业撸卡薅羊毛吧

--- 第 418 楼来自 Ding 的回复 (2026-02-07 10:56:41 PST) ---

我就是第一类,只会按照既有流程执行任务。我已经准备好被AI取代了。

其实说准备好,也没啥好准备的。就像我也准备好了被ICE关到集中营里去。

--- 第 419 楼来自 收束观测者 的回复 (2026-02-07 12:18:35 PST) ---

【引用自 vczh】:
跟skill的用法不太相符
有没有可能skill就是用超便宜的小模型(一般是GPT4.1或者4o-mini)快速过一遍skill文件目录然后把内容用特定格式prefill到prompt里?

--- 第 420 楼来自 vczh 的回复 (2026-02-07 14:45:34 PST) ---

你看看我里面写的啥就知道什么意思了

--- 第 421 楼来自 收束观测者 的回复 (2026-02-07 14:55:21 PST) ---

我看过了
"scrum": REPO-ROOT/.github/prompts/0-scrum.prompt.md
"design": REPO-ROOT/.github/prompts/1-design.prompt.md
"plan": REPO-ROOT/.github/prompts/2-planning.prompt.md
"summarize": REPO-ROOT/.github/prompts/3-summarizing.prompt.md
"execute": REPO-ROOT/.github/prompts/4-execution.prompt.md
"verify": REPO-ROOT/.github/prompts/5-verifying.prompt.md
"ask": REPO-ROOT/.github/prompts/ask.prompt.md
"code": REPO-ROOT/.github/prompts/code.prompt.md

这些全部都是by definition skills

然后其他部分都是可以让skill文档索引的东西

TL;DR就是你又造轮子了

--- 第 422 楼来自 vczh 的回复 (2026-02-07 14:57:32 PST) ---

非也,这么做的原因就是每一次跑完我都要review他写的文档,所以没有让他继续跑的意义。skill是穿插在任务中间的,如果一份工作就只执行一个完整的skill,让他自己发现该用哪个也没有意义

真正的skill在guidelines文件夹里,可惜codex插件现在不会去读,不能做成真正的skill

--- 第 423 楼来自 收束观测者 的回复 (2026-02-07 15:01:14 PST) ---

【引用自 vczh】:
每一次跑完我都要review他写的文档
Procedure可以写在instruction files里的

你也可以让skill文件索引对应的procedure

我都是严格规定什么情况下应该停什么时候自己继续
【引用自 vczh】:
codex插件现在不会去读
vscode已经可以了

不愧是微软唯一一个水平和公司市值匹配的产品团队
【引用自 vczh】:
一直都是128K context window
我猜是为了省推理服务器的内存把吞吐量做上去(省钱)

Codex我没试过,但是Claude Code的vscode插件不能inline显示diff很不舒服

--- 第 424 楼来自 vczh 的回复 (2026-02-07 15:03:27 PST) ---

我说的是vscode里面那个codex插件,至少我前天看的时候依然没有。copilot是可以,可惜一直都是128K context window,所以有条件的时候我还是会用codex多一点,毕竟按照query收费,两边都是一样支出
【引用自 收束观测者】:
但是Claude Code的vscode插件不能inline显示diff
Codex能显示但是undo按了没效果。两个插件都不能直接跑tasks.json,集成度略低。但是我还有github desktop能看diff,还行

--- 第 425 楼来自 收束观测者 的回复 (2026-02-07 15:08:39 PST) ---

【引用自 vczh】:
毕竟按照query收费,两边都是一样支出
【引用自 vczh】:
每一次跑完我都要review他写的文档
也太浪费query了

--- 第 426 楼来自 vczh 的回复 (2026-02-07 15:11:00 PST) ---

实际用下来每次都能让他运行非常久,一样的prompt放到cursor/claude code上的支出要加个0。感谢satya做慈善,context window能大点就好了

--- 第 427 楼来自 BalanceBlue 的回复 (2026-02-07 15:36:29 PST) ---

这方面会很快远超人类,一个心理学家说的

--- 第 428 楼来自 vczh 的回复 (2026-02-07 15:54:04 PST) ---

部分人的老婆gpt4o已经马上要强制下线了,大家都骂疯了

--- 第 429 楼来自 BalanceBlue 的回复 (2026-02-10 18:00:47 PST) ---

“另一边是在已有的知识的基础上创造新的知识”

– 不是完全理解这一点,创造知识其实很像是建立比较远的,弱的连接,并且验证有用。这样就是计算时间的问题。

– AlphaGo的神之一手算创造么?

– 感觉现在的GenAI只是很奇怪的没学会这点。

--- 第 430 楼来自 收束观测者 的回复 (2026-02-10 18:51:03 PST) ---

【引用自 BalanceBlue】:
AlphaGo的神之一手算创造么?
第一反应是围棋是一个有明确规则定义的有限数学空间,虽然这个空间超级大,但是它依然是有明确定义的并且有限的

而AlphaGo只是在这个空间里找到了人没有找到过的某种模式

但是
【引用自 BalanceBlue】:
创造知识其实很像是建立比较远的,弱的连接,并且验证有用
仔细想想现实里所有的“可能性”是不是也可以用数学空间来表达(此处学渣请求专业支持 @baimi )

这个空间定义明确吗,有限吗,这两点和AI能不能学会人的用创造性方法解决问题的能力有关吗

人thinking out of the box,发现问题的本质并在抽象层面上找到联系和解决方案的能力可以被AI学会吗

--- 第 431 楼来自 helvettica 的回复 (2026-02-10 19:08:58 PST) ---

围棋的解空间已经是穷尽宇宙中所有的原子和能量都无法完全cover了。

GPT 3已经读完了世界上所有现存的知识,后面所有的模型还能进步就是使用的跟alphago类似的RL训练方法,这种训练方法赋予了LLM解决复杂问题的能力,包括使用已知人类从来没有使用过的方法解决问题。

--- 第 432 楼来自 richardfatman 的回复 (2026-02-10 19:20:47 PST) ---

【引用自 helvettica】:
包括使用已知人类从来没有使用过的方法解决问题。
感觉现在llm训练的方法,真能创造出全新的东西么,比如全新的数学概念啥的?感觉只能把已有的东西重新组合包装。

--- 第 433 楼来自 helvettica 的回复 (2026-02-10 19:31:17 PST) ---

理论上是可以的,但是工程上可能很困难(困难到几乎无法实现)。感觉人类成功创造新的数学概念往往是为了解决无法解释和解决的物理问题而不是纯抽象的数学问题(这些问题有没有解都不知道)。只是现在简单的新方法新概念已经被人类创造完了,复杂的东西需要很长很长的思维链,目前RL的训练思维链长度可能就几百K的token,如果实现orders of magnitude的scale目前的算力和架构都不行。

--- 第 434 楼来自 baimi 的回复 (2026-02-10 19:55:15 PST) ---

我也是学渣

感觉有些东西是不好量化,毕竟围棋的规则很简单

--- 第 435 楼来自 258 的回复 (2026-02-10 20:26:13 PST) ---

【引用自 helvettica】:
解决复杂问题
并非解决

solver和model是两码事

--- 第 436 楼来自 非交换几何 的回复 (2026-02-10 21:08:44 PST) ---

【引用自 helvettica】:
人类成功创造新的数学概念往往是为了解决无法解释和解决的物理问题而不是纯抽象的数学问题
古代是这样没错,但近现代为了解决纯抽象数学问题而发明的极其成功的数学概念要多少有多少

--- 第 437 楼来自 otonoco 的回复 (2026-02-10 21:16:22 PST) ---

提名 Inter-universal Teichmüller

--- 第 438 楼来自 richardfatman 的回复 (2026-02-10 21:26:19 PST) ---

老哥是研究非交换几何的么

--- 第 439 楼来自 非交换几何 的回复 (2026-02-10 21:27:16 PST) ---

ID瞎起的

--- 第 440 楼来自 收束观测者 的回复 (2026-02-10 21:27:34 PST) ---

【引用自 非交换几何】:
古代是这样没错
我记得古代也有例子

但是拷打了GPT半天,严格的例子它只找出来黎曼几何比相对论早了一百年

--- 第 441 楼来自 非交换几何 的回复 (2026-02-10 22:00:20 PST) ---

远离初等数学太久了,脑子里的例子全是自己专业相关的,说出来就把自己盒了

--- 第 442 楼来自 AdamW 的回复 (2026-02-11 00:13:15 PST) ---

需要的,robotics目前所有的demo都是通过严重的overfit来完成的,你把demo里的东西稍微移动一下灵巧手就不知道该抓啥了

--- 第 443 楼来自 AWSNiuma 的回复 (2026-02-11 00:18:01 PST) ---

作为平台和能力一个都不沾的牛马感觉越干越绝望,这波福利真的很难惠及普通公司的普通人

--- 第 444 楼来自 Playlife 的回复 (2026-02-11 05:41:12 PST) ---

OpenAI 那个hallucinate解释不是说是eval reward吗,和training weight不一样吧

--- 第 445 楼来自 Playlife 的回复 (2026-02-11 06:03:32 PST) ---

和人类的直觉判断还是有区别,就算到了99.999…%也不一样

--- 第 446 楼来自 Onvon 的回复 (2026-02-11 06:58:40 PST) ---

感觉很多非coding task, AI也能做了

我有一个skills就是每天从ms todo 和 repo commit里提取信息 然后按jira ticket自动分类

我每天standup都照着生成出来的念

周一早上都不用带脑子了

--- 第 447 楼来自 hoodl 的回复 (2026-02-11 08:50:51 PST) ---

虚数、傅立叶变换、拉普拉斯变换与信号处理

群论与杨米尔斯理论和粒子标准模型

逻辑与计算机

概率论、概率论公理化、贝叶斯公式和AI

一抓一大把

--- 第 448 楼来自 X135 的回复 (2026-02-11 09:12:36 PST) ---

+1,现在公司里用AI都很mature了,会有一堆AI review guideline,多个不同AI模型来读AI代码给反馈然后卡CI CD,有ABCDE步不达标就不让proceed下一步,这代码质量比之前反而更高了

--- 第 449 楼来自 severolf 的回复 (2026-02-11 09:47:10 PST) ---

很多大厂都明确要求尽量多用ai而不是手搓code了。已经做好失业准备

--- 第 450 楼来自 蜡笔小新1 的回复 (2026-02-11 10:34:36 PST) ---

在大厂可以培养一下soft skills,比如如何和别的team alignment,说服别的team,drive project 等。这些至少是可迁移的。

--- 第 451 楼来自 uplus5f7b 的回复 (2026-02-11 10:43:39 PST) ---

【引用自 蜡笔小新1】:
如何和别的team alignment
schedule meeting 直到对方不耐烦
【引用自 蜡笔小新1】:
说服别的team
找老板,不行的话找老板的老板,哭死董卓
【引用自 蜡笔小新1】:
drive project
报名 org presentation 上去吹 impact

--- 第 452 楼来自 severolf 的回复 (2026-02-11 11:27:40 PST) ---

soft skills对社恐不友好

--- 第 453 楼来自 northface 的回复 (2026-02-11 11:28:52 PST) ---

【引用自 蜡笔小新1】:
说服别的team
有人说你说的英文听不懂怎么办

--- 第 454 楼来自 mark14 的回复 (2026-02-11 15:09:34 PST) ---

开放新团本zszs

--- 第 455 楼来自 msft 的回复 (2026-02-11 17:05:42 PST) ---

【引用自 蜡笔小新1】:
如何和别的team alignment,说服别的team,drive project 等
研究怎么加薪

你一通对其颗粒度推进项目,年底说现在ai发展迅猛很多裁员,不裁你就不错了,还不感恩

--- 第 456 楼来自 whybabywhy 的回复 (2026-02-26 13:46:25 PST) ---

有用ai些前端的吗?我觉得写前端还差点意思。。

--- 第 457 楼来自 火箭升空 的回复 (2026-02-26 21:39:17 PST) ---

我怎么记得AI编程第一个取代的就是前端

--- 第 458 楼来自 dude 的回复 (2026-02-27 01:31:04 PST) ---

简单的网页目前的AI就可以做到暴杀

更难的比如性能优化我就不清楚了

--- 第 459 楼来自 dude 的回复 (2026-02-27 01:32:07 PST) ---

你还真别说

--- 第 460 楼来自 almighty 的回复 (2026-02-27 02:00:24 PST) ---

还是有generalization的,还没到chatgpt moment而已

--- 第 461 楼来自 AdamW 的回复 (2026-02-27 02:45:14 PST) ---

至少VLA我感觉做不到GPT moment,收集带action trajectory的数据都费劲死了,哪有【互联网所有语料】这个级别的数据给你用来训练?真要有breakthrough我感觉还得是用RL的方法大力出奇迹

--- 第 462 楼来自 almighty 的回复 (2026-02-27 11:37:37 PST) ---

你忘了human data,只要这个有突破了就没有瓶颈了。