泥潭日报 uscardforum · 每日精选

码农,AI,屎山代码

内容摘要

AI加速屎山,token限制、review失效,管理层盲目跟风,追责困难。

1. 关键信息

  • #1 楼主 teirt15 所在小众大厂(Blind WLB 2.6)自去年 Q3 起 all in agentic coding,要求年底前达到 100% agentic code,导致 WLB 恶化、人员流失(两倍多,含 senior)。
  • #1 楼主 KPI 中 timeline pushback 增多,上司常以“why don’t you just push that to a one-shot Claude session?” 要求提前完成,但 AI 生成的屎山代码无法 scale,导致连续三个月 975 工作。
  • #1 楼主 Claude token 用完后需等 approval 才能继续使用。
  • #6 Sheriaty 猜测公司为“小meta”,并认为干不久。
  • #9 fularji 质疑“all in AI 居然还有 token 限制”。
  • #16 teirt15 提到 SEV0 无声处理,源代码作者背锅。
  • #18 helvettica 指出 infra 和代码库未重构为 agent first,agent 无法发挥全部效率。
  • #28 teirt15 认为根本问题是公司文化强制缩短时间线,砍步骤,造成负反馈回路。
  • #39 老娘舅 指出 PR 数量过多导致 review 只能默认 AI 正确,未来 99% 代码无人见过。
  • #40 vczh 提到其公司(sqlserver)要求每个人对自己 AI 提交的代码要像自己写的一样熟悉。
  • #41 qwaszx 表示 975 对 quant 来说是休闲模式。
  • #42 折木奉太郎 指出使用 AI 后人变懒、阅读能力退化。
  • #44 vczh 认为保持好奇心和编程兴趣是个人努力问题,虽自己的业余项目也 95% AI。
  • #46 收束观测者 工作 0 手写 + 5% 人工 review,但代码 base 是自己从 0 写的,每次重构手把手带 AI 定义边界;业余项目 100% AI 且无 code review,有时连架构细节都会忘。
  • #47 vczh 工作 0 手写,review 差不多就行,坏了烧公司 token 刷 KPI;个人项目用自己的钱,不能瞎搞。
  • #48 收束观测者 问 vczh 公司是否给无限私人账号;vczh 回应 copilot rate limit 严重,不如 ChatGPT Pro,宁可自费 $100/mo 用个人账号。
  • #50 正经打工人 提到新人小妹入职 7 天用 AI 发 10 个 PR,review 通过后进 prod 次日 SEV0,全员熬夜通宵,现已离职。
  • #54 vczh 补充:premium request 和转 token 后总量无限,但 rate limit 都那样。
  • #55 收束观测者 表示自己公司 enterprise copilot 曾一天开约 40 个 long horizon 才 hit rate limit。
  • #56 vczh 解释自己喜欢一个 request 连着跑很久,中间不管,感觉内部也是 5h rate limit,撞上后 rate 逐步收紧;自己写代码没有周末,不想上班还有两天缓一缓。
  • #57-#58 收束观测者 问是否 GPT,vczh 确认是 GPT(微软自己 host)。
  • #59 收束观测者 认为 copilot 所有模型都是 azure host(包括 opus),GPT 老出问题是因为需求太高 serve 不了。
  • #60 vczh 指出 opus 应该是经过 anthropic 的,因为有时 cc 挂掉时 copilot 联网质量也下降。
  • #61 Zig 质疑大老板是否真的知道现状,表示自己感觉不知道。
  • #62 AppleVisionPro 呼应 #46,表示自己的业余项目里面有点啥都快不知道了。
  • #64 catkinkk: 我司现在限制claude $120一个月,codex也不是都给。
  • #65 572993482: 你见过哪个编译器编译5次给出5个不同的结果?ai感觉更像薛定谔的猫
  • #66 懵懂一时: 也可能是装不知道
  • #67 ze3kr: 企业版域正确配置了很难被下毒。像 openclaw 这种很容易被下毒的基本都不让用
  • #68 ze3kr: 这也太拉了,我摸鱼一个月都用两三百,卷王能上千;120 就是人均摸鱼了 而且最近组里研究发现,写屎山可以显著降低 token 使用。不写屎山 input/output token 成倍增加
  • #69 kaion: 做投行 工资估计只有2/3 hour可能是40%+
  • #70 vczh: 我在公司极致摸鱼都至少要用1000
  • #71 IRS_pro: kaion: 做投行 老中做投行的多吗?感觉这对语言要求很高
  • #72 002: 屎山+1 今天屎山生成爽 明天SEV火葬场
  • #73 002: 引用毛泽东回忆,讽刺管理层盲目相信浮夸
  • #74 002: 权责不对等,管理者用屎山生成器吹牛捞政绩,engineering debt 留给后人
  • #75 收束观测者: 问 ze3kr 写屎山降低 token 的原理;自己四月 token 比三月多近一倍
  • #76 ze3kr: 不写屎山需要让 AI 阅读更多已有代码,思考更久
  • #77 IRS_pro: 002: 明天SEV火葬场 没事,明天就跳槽了,管他洪水滔天
  • #78 Allen_Z: 中层又蠢又坏,CPO 来了7年啥都没干成赔几十billion,跳槽做CEO
  • #79 Zig: 中层最大期望是稳定,想折腾的都是高层
  • #80 两只饺子: 半年以前坚持古法编程,现在全扔给AI,刷抖音小红书,人形确认机和复制机
  • #81 Allen_Z: 定义中层为 director/VP 和产品 PM,为了KPI瞎弄
  • #82 Onvon: 公司有 skills 大炼钢 KPI,每月写 xx 个 skills 并 merge,很多人从 GitHub 搬运开源 skills 应付
  • #124 duola1004: 全看CEO/CTO,普遍要求大幅度提高效率,出岔子就是你的锅(你为啥不 review)。CEO 说不用电脑只用手机办公。普通人没话语权。有了AI后老板觉得你说的没道理。
  • #125 Zig: 想这个又不是KPI。
  • #126 duola1004: 老板也没办法,都是膨胀。不然META为啥AI造假。你没事也得把token用完,人家一看你AI usage不饱满、LINE写不够多。

2. 羊毛/优惠信息

3. 最新动态

  • #124-#126 补充了管理层视角:CEO/CTO 普遍要求大幅提高效率,出问题则归咎于员工未 review;AI usage 成为 KPI 指标,即使没事也得消耗 token 以显得饱满;有用户指出 META 曾 AI 造假,暗示行业风气。
  • 新增对“老板也没办法,都是膨胀”的讨论,认为高层为了政绩盲目推动 AI 使用,底层员工被迫配合。

4. 争议或不同意见

  • #61 Zig 质疑大老板是否真的知道现状;#66 懵懂一时 认为可能是装不知道。
  • #79 Zig 认为中层只想稳定,折腾的是高层;#81 Allen_Z 则认为 director/VP 和产品 PM 才是瞎搞的中层。
  • #124 duola1004 指出 CEO 自己不用电脑只用手机办公,却要求员工用 AI 提效,形成认知脱节。
  • #125 Zig 反驳“想这个又不是KPI”,暗示管理层并不关心实际后果。

5. 行动建议

  • 对于被迫使用 AI 的开发者:保留 review 记录,明确责任边界,避免背锅;主动与上级沟通 token 限制和代码质量风险。
  • 对于管理层:应建立合理的 AI 使用 KPI(如代码质量、SEV 率),而非单纯追求 token 消耗量或 PR 数量;重构 infra 和代码库以适配 agent first 模式。
  • 对于个人项目:谨慎使用 AI,保持对代码架构的掌控,避免遗忘细节;可自费购买 ChatGPT Pro 规避 rate limit。
  • 长期看,行业需反思“屎山生成器”文化,避免重蹈浮夸风覆辙。
原始内容
--- 第 1 楼来自 teirt15 的回复 (2026-05-01 14:31:04 PDT) ---

今天提前闲下来了,主要是 Claude token 用完了还在等 approval,突发奇想想问问泥潭其他码农:大家公司现在对 AI / agentic coding 到底是什么状态? 背景 本科毕业后进了某小众大厂当 junior SDE,Blind 上 WLB 大概 2.6。到现在将近 2 YOE,部门自疫情以来一直是 remote 观察 从去年 Q3 到现在,我司基本处于 all in agentic coding 的状态,middle manager也要亲自出 PR。同时公司也下定决心,要在今年年底前达到 100% agentic code 我司本身 WLB 就很差,Blind 上也一直有人抱怨 unrealistic expectations 和 unattainable goals。自从 all in AI 策略出台之后更离谱了,基本上能抱怨的人都在说自己在无偿加班、准备跳槽 也不是毫无根据。就我自己身边的情况来说,和去年 Q1 相比,已经走了大概两倍多的人,很多是 senior,5+ YOE,也有一些是刚好到 RSU cliff 的人 以我个人 KPI 来说,也能明显感觉到这个 all in 带来的力度 前年刚入职的时候,很多 ownership 还是比较直截了当的。我自己制定 timeline、描述项目时间跨度和抽时间设计,一般也不会遇到太多阻力。WLB 2.6 的公司,最明显的问题其实是各种不太现实的目标:凭空抽时间帮整个组 oncall、无偿修 bug、无偿 review 其他队员的 PR 但是从去年年底到现在,阻力明显上去了。也有可能是因为公司短期内在冲刺拿下一些项目,但我在制定 timeline 的时候,明显感觉 pushback 变多了。我上司也经常用类似“why don’t you just push that to a one-shot Claude session?”这种理由,要求我提前搞定。有几次扯得我都想骂回去了,但是只好忍住 问题是,在 oncall、无偿修 bug、无偿 review 之间,AI 写出来的屎山代码完全没法 scale。以前一个星期 execute 的 task,现在半天就能 generate 出来,但换来的是无止境地修 bug、处理 oncall、review 屎山代码 这个星期已经是连续第三个月 975 了。工作日基本就是睁眼开电脑上班,闭眼前还在上班。有时候 oncall 还会半夜被叫起来。泥潭也越来越少逛了 不知道谭友们有没有类似经历?大家公司现在对 AI coding / agentic coding 的态度是怎样的?是真的提高效率,还是只是把 unrealistic expectation 又往上抬了一截? AI极大地加快了工作进度 AI完全没法横向扩张 公司不让用AI 0 投票人 干,刚刚才看到掉到金卡去了

--- 第 2 楼来自 up9080 的回复 (2026-05-01 14:36:13 PDT) ---

teirt15: 小众大厂 还有这种公司么。faang-adjacent ?

--- 第 3 楼来自 折木奉太郎 的回复 (2026-05-01 14:36:16 PDT) ---

如果你还人工review那个效率确实会很慢的…… 我个人觉得效率确实高了,起码我解决了很多积累已久的bug。甚至可以一次回复两三个项目的小修改请求。不过我没变得清闲,一直在各个terminal tab之间切换 看这个标题才反应过来,歪楼点播一首 八月、某、月明かり https://www.youtube.com/watch?v=Vs5NViM8TSY

--- 第 4 楼来自 打豆豆 的回复 (2026-05-01 14:38:11 PDT) ---

teirt15: 主要是 Claude token 用完了还在等 approval 这是主要问题。我们没限制随便用,就不担心 teirt15: AI 写出来的屎山代码完全没法 scale 无论是拉新屎,还是堆旧屎,交给AI然后开始刷泥潭等结果就行了。。。

--- 第 5 楼来自 二号去听经晚上住旅店三号去餐厅然后看电影 的回复 (2026-05-01 14:38:33 PDT) ---

teirt15: Claude token 用完了还在等 approval 哪家公司分享一下泥潭避雷 让牲口干活牲口饲料不能断啊

--- 第 6 楼来自 Sheriaty 的回复 (2026-05-01 14:40:55 PDT) ---

我好像知道是哪个公司了。。是人称小meta的xxxx吗? 感觉这么搞干不久。。

--- 第 7 楼来自 msft 的回复 (2026-05-01 14:44:54 PDT) ---

teirt15: 不知道谭友们有没有类似经历?大家公司现在对 AI coding / agentic coding 的态度是怎样的?是真的提高效率,还是只是把 unrealistic expectation 又往上抬了一截? 没有类似经历,很看老板和组员。现在完全用ai,效率非常高,摸鱼时间好像更多了,ticket处理的速度也没增加。据我观察就是混得更加飞起了,随便prompt一下,之前一两天的活一会就干完了 上面貌似有提高要求,但是不加工资员工又不是傻子,没人多干,反正公司不裁员。

--- 第 9 楼来自 fularji 的回复 (2026-05-01 14:52:42 PDT) ---

都要all in AI了居然还有token限制吗

--- 第 10 楼来自 xh91 的回复 (2026-05-01 14:52:51 PDT) ---

现在真的是,多开几个session,然后就刷泥潭刷手机甚至刷个剧,然后等一阵检查下结果就行了

--- 第 11 楼来自 fularji 的回复 (2026-05-01 14:54:57 PDT) ---

个人体感AI确实能大幅提升效率 但距离AI native还有十万八千里

--- 第 12 楼来自 sukasky 的回复 (2026-05-01 15:00:33 PDT) ---

所以最主要的问题是没人问这种问题 teirt15: why don’t you just push that to a one-shot Claude session? 多的时间就是自己的 摸鱼的时间更多了

--- 第 13 楼来自 msft 的回复 (2026-05-01 15:03:37 PDT) ---

sukasky: 所以最主要的问题是没人问这种问题 teirt15: why don’t you just push that to a one-shot Claude session? 这种直接让问的人自己上手,不会coding可以跟chatgpt学

--- 第 14 楼来自 lionlin 的回复 (2026-05-01 15:03:37 PDT) ---

各位ai写代码的时候检查吗,如果ai被攻击了故意加了类似rm /谁负责

--- 第 15 楼来自 teirt15 的回复 (2026-05-01 15:04:53 PDT) ---

二号去听经晚上住旅店三号去餐厅然后看电影: 哪家公司分享一下泥潭避雷 up9080: 还有这种公司么 blind上面很多人推荐stay away

--- 第 16 楼来自 teirt15 的回复 (2026-05-01 15:11:14 PDT) ---

几次SEV0都是无声无响处理掉了,源代码作者背锅

--- 第 17 楼来自 Zwillingsturme 的回复 (2026-05-01 15:11:27 PDT) ---

还有谁的公司修bug reivew给钱的吗。。

--- 第 18 楼来自 helvettica 的回复 (2026-05-01 15:13:36 PDT) ---

你们公司的infra和代码库都还没有充构成agent first的,这种情况下agent还无法发挥出全部效率。要重构这些需要很多人合作,重构过程中会面临人嘴与人嘴沟通的10bit/s低效率瓶颈。 无解。

--- 第 19 楼来自 up9080 的回复 (2026-05-01 15:16:12 PDT) ---

helvettica: infra 现在大部分都是 Iac + cloud 了,足够 agent friendly 了吧…

--- 第 20 楼来自 up9080 的回复 (2026-05-01 15:17:33 PDT) ---

lionlin: 如果ai被攻击了故意加了类似rm /谁负责 不管,反正是公司电脑… --dangerously-skip-permissions YOLO

--- 第 21 楼来自 无敌的菜包 的回复 (2026-05-01 15:17:46 PDT) ---

在一个不是tech industry的公司有一个好处就是感觉好像无限token

--- 第 22 楼来自 msft 的回复 (2026-05-01 15:18:34 PDT) ---

我司直接这个选项给禁用了

--- 第 23 楼来自 helvettica 的回复 (2026-05-01 15:19:40 PDT) ---

每个公司的业务和目标不同。一般足够agent friendly的起码需要在代码库里加一些基础guideline和全套的能让AI自己验证代码的本地数据或者test架构。 另外如果你们公司的代码是原生状态下就是AI就能handle的,那你们公司业务离死不远了。你个人做多少努力都救不回来

--- 第 24 楼来自 IRS_pro 的回复 (2026-05-01 15:20:34 PDT) ---

lionlin: 各位ai写代码的时候检查 叫另一个 AI 检查

--- 第 25 楼来自 lionlin 的回复 (2026-05-01 15:23:13 PDT) ---

如果都被下毒了

--- 第 26 楼来自 lionlin 的回复 (2026-05-01 15:24:49 PDT) ---

到最后没有真人写代码了,ai学习ai写的代码,出错了人都看不懂

--- 第 27 楼来自 无敌的菜包 的回复 (2026-05-01 15:25:25 PDT) ---

最后就是没人任何人可以看懂代码

--- 第 28 楼来自 teirt15 的回复 (2026-05-01 15:26:03 PDT) ---

我感觉更大的问题是开发本身有个时间线,如果强制缩短这个时间线只能砍步骤,造成无法横向扩展的代码或者SEV0,造成很严重的负反馈回路 解决一个问题有最快方法和更深思熟虑的方法,但在极短时间内达到结果的方法肯定不是深思熟虑的 然后AI放弃了思考 其实这么一想还真不是AI的锅,是公司文化的锅

--- 第 29 楼来自 lionlin 的回复 (2026-05-01 15:26:04 PDT) ---

很期待二十一世纪见证机器奴役人类

--- 第 30 楼来自 IRS_pro 的回复 (2026-05-01 15:28:50 PDT) ---

找第三个 AI 检查

--- 第 31 楼来自 IRS_pro 的回复 (2026-05-01 15:29:42 PDT) ---

一点问题都没有,你看得懂汇编吗?不照样好好的 现在这个时代: 现在的普通程序语言 = 过去的汇编 现在的prompt = 过去的普通程序语言

--- 第 32 楼来自 收束观测者 的回复 (2026-05-01 15:37:30 PDT) ---

还是不太一样的 高级语言对硬件的实际行为约束比汇编弱很多,但是总体上还是很强的 prompt那就…… 让Gemini从理论角度做了个比较 #p-8113225-semantic-gap-framework-1语义鸿沟度量框架 (Semantic Gap Framework) 从计算机科学的底层逻辑来看,这种“约束力”的递减本质上是**确定性(Determinism) 向 概率性(Probability)**的范式转移。我们可以通过以下框架来定义其中的质变: #p-8113225-h-1-21. 约束层级的演变指标 特性 汇编语言 (Assembly) 高级语言 (High-level) 程序提示词 (Prompt) 映射比率 1:1 (指令级) 1:N (状态级) 1:\infty (意图级) 控制核心 寄存器与电子流 逻辑流与内存模型 概率分布与语义向量 约束性质 强物理约束 强逻辑约束 弱语义引导 #p-8113225-h-2-32. 定义差距的三个核心维度 #p-8113225-a-mapping-uniqueness-4A. 映射的唯一性 (Mapping Uniqueness) 汇编到硬件: 几乎是同构的。一条指令对应一个 CPU 微码序列,硬件行为是完全可预测的镜像。 Prompt 到硬件: 存在“解释器断层”。同一个 Prompt 每次生成的机器码可能完全不同,这意味着 Prompt 彻底丧失了对硬件行为的 唯一确定性约束 。 #p-8113225-b-semantic-noise-tolerance-5B. 语义噪声容忍度 (Semantic Noise Tolerance) 硬性约束(汇编/高级): 遵循“零容忍”原则。语法空间中一个比特的错误会导致逻辑完全崩塌。 软性引导(Prompt): 作用于高维向量空间。它是模糊容忍的,通过统计学概率而非硬性规则来驱动硬件产生结果。 #p-8113225-c-6C. 维度的坍缩与展开 从汇编到高级语言是 抽象化 :隐藏了硬件流水线、分支预测等实现细节。 从高级语言到 Prompt 是 意图化 :它不仅隐藏了过程(How),而是直接跳跃到了结果(What)。 #p-8113225-h-3-73. 结论:从“规定”到“描述”的质变 我们可以用一个公式化的定义来描述这种差距: 差距 = \frac{\Delta \text{Intent Complexity}}{\Delta \text{Hardware Determinism}} 高级语言 依然是在“编写”机器的行为(Code as Script)。 Prompt 则是在“描述”一种期望的状态(Prompt as Goal)。 这种质的差距在于:你失去了对微观电子流的绝对统治权,换取的是对宏观复杂逻辑的极速构建能力。 大跃进要不得 IRS_pro: 就类似于: 相同的prompt 不同 AI 给出的程序不一样 这就类似于不管剂量谈毒性 水喝太多了人也会死不代表水有毒 编译器和AI对硬件行为都不是1对1映射不代表两者可以类比

--- 第 33 楼来自 sukasky 的回复 (2026-05-01 15:37:45 PDT) ---

这不一样啊,汇编是稳定的啊,你写出来的程序他肯定准确编译成成汇编,但写的prompt出来有可能不知道是什么玩意啊

--- 第 34 楼来自 IRS_pro 的回复 (2026-05-01 15:39:55 PDT) ---

sukasky: 你写出来的程序他肯定准确编译成成汇编 不同编译器给出的汇编代码不一样的 就类似于: 相同的prompt 不同 AI 给出的程序不一样 一样的,把 AI 想象成“高级编译器”就行了

--- 第 35 楼来自 sukasky 的回复 (2026-05-01 15:39:56 PDT) ---

sb老板:那你收拾东西回家,我来做吧

--- 第 36 楼来自 Allen_Z 的回复 (2026-05-01 15:44:31 PDT) ---

其实AI就算牛逼 也要有牛逼的程序员去用 不然就是山 而且因为没人负责 会越来越崩溃 还是那些脑子里有的leadership看不到或者看到也不想管 他们只想要效率 要出成绩 要AI 我走之后洪水猛兽与我何干

--- 第 37 楼来自 up9080 的回复 (2026-05-01 15:49:13 PDT) ---

相同的代码相同的平台相同的编译器给出的代码是一样的,有可复现性。 相同的 prompt 相同的 AI 模型给出的代码是不一样的,没有可复现性。

--- 第 38 楼来自 IRS_pro 的回复 (2026-05-01 15:49:53 PDT) ---

up9080: 没有可复现性。 所以才叫“高级”编译器呀

--- 第 39 楼来自 老娘舅 的回复 (2026-05-01 15:57:14 PDT) ---

可以肯定的一点就是堆的越来越多我都没有看过的code 如果组里人“勤快”的话,那么每天产生的PR和code数量是人工review不过来的 简单的逻辑还好,如果是夹杂算法的玩意,你每天那么多的进来,我只能默认AI是对的,因为个人根本分析不过来只能approve推进同事的进度了 最后的结果我觉得,未来99%以上的code你可能都没有见过就运行了,你也不知道那些干什么的,只有AI自己知道了

--- 第 40 楼来自 vczh 的回复 (2026-05-01 15:58:22 PDT) ---

我司的项目都是大屎山,大老板们都知道performance这种事情没办法把话说死,于是就只有一个要求:AI用起来,要看到变化。有的人确实PR变多了,有的人就没有,最后都是具体问题具体分析 折木奉太郎: 如果你还人工review 然而sqlserver的要求是,每一个人对自己的AI提交的代码,要跟自己写的一样熟悉

--- 第 41 楼来自 qwaszx 的回复 (2026-05-01 16:05:43 PDT) ---

teirt15: 975 了。 说句被打死的话,就这?对quant来说这是休闲模式

--- 第 42 楼来自 折木奉太郎 的回复 (2026-05-01 16:11:05 PDT) ---

道理上应该这样 然而自从用了AI以后,人变懒了(代码不想看),阅读能力感觉都退化了(看不懂)

--- 第 43 楼来自 teirt15 的回复 (2026-05-01 16:11:06 PDT) ---

得支持反内卷

--- 第 44 楼来自 vczh 的回复 (2026-05-01 16:13:47 PDT) ---

折木奉太郎: 阅读能力感觉都退化了 这是一个需要你自己努力的问题,虽然自己的下班项目也早就95% AI很久了,我就不会丧失好奇心和对编程的兴趣

--- 第 45 楼来自 lionlin 的回复 (2026-05-01 16:49:47 PDT) ---

现在还有会计财务这些工作没被替代,估计以后码农还保留少数人有同样的作用

--- 第 46 楼来自 收束观测者 的回复 (2026-05-01 18:40:52 PDT) ---

我现在工作上是0手写加5%人工review 但是code base是以前自己从0写起的,每次重构也是手把手带着AI定义边界的所以基本对架构还有grip 自己的业余项目100% AI + 无code review,只review架构,最后有时候就连架构细节都会记不住

--- 第 47 楼来自 vczh 的回复 (2026-05-01 18:55:40 PDT) ---

工作我也0手写,review差不多就行了,弄坏了我还能再烧公司的token救回来刷KPI。自己的项目画的是自己的钱,代码也是自己的,可不能瞎搞

--- 第 48 楼来自 收束观测者 的回复 (2026-05-01 18:59:34 PDT) ---

vczh: 自己的项目画的是自己的钱,代码也是自己的,可不能瞎搞 不是说贵司给无限制的私人账号吗

--- 第 49 楼来自 vczh 的回复 (2026-05-01 19:01:36 PDT) ---

copilot rate limit限制成这样,一个job跑不了两个小时就挂起了,不如ChatGPT pro一根毛,宁可自己 $100/mo

--- 第 50 楼来自 正经打工人 的回复 (2026-05-01 19:02:22 PDT) ---

前段时间隔壁有个新来的国人小妹,基本功之类的不是很扎实的那种,刚进来7天用AI发了10个PR,然后也不知道谁review的给过了,进了Prd第二天就sev 0拉着整个大组起来熬了一宿。现在她已经离职了

--- 第 51 楼来自 收束观测者 的回复 (2026-05-01 19:03:34 PDT) ---

vczh: copilot rate limit限制成这样 不是说贵司送的账号是无限的吗

--- 第 52 楼来自 Zwillingsturme 的回复 (2026-05-01 19:12:49 PDT) ---

正经打工人: 现在她已经离职了 这样的给severance吗还

--- 第 53 楼来自 正经打工人 的回复 (2026-05-01 19:14:03 PDT) ---

可能signon都要吐出来

--- 第 54 楼来自 vczh 的回复 (2026-05-01 19:35:26 PDT) ---

premium request和转token后,总量是无限的,但是rate limit都那样

--- 第 55 楼来自 收束观测者 的回复 (2026-05-01 19:36:59 PDT) ---

rate limit比企业给得低? 还是说你用得太狠了? 我司买的enterprise copilot我有天开了差不多40个long horizon才hit的rate limit

--- 第 56 楼来自 vczh 的回复 (2026-05-01 19:39:11 PDT) ---

我喜欢一个request连着跑老久,中间不去管他。虽然文档没说,但是看错误信息感觉内部也是5h rate limit,撞上了。一旦撞上之后我能感觉rate逐步收紧 自己写代码是没有周末的,不想上班的话还有两天给他缓一缓

--- 第 57 楼来自 收束观测者 的回复 (2026-05-01 19:40:05 PDT) ---

是不是GPT? 我司的plan用GPT经常出错,反而更贵的opus没问题

--- 第 58 楼来自 vczh 的回复 (2026-05-01 19:41:13 PDT) ---

确实gpt,这个是微软自己host的

--- 第 59 楼来自 收束观测者 的回复 (2026-05-01 19:42:31 PDT) ---

copilot所有模型都是azure host的吧,连opus都是 我azure账户里可以看到有部署opus的选项(但是没quota) 甚至连mythos也有只不过被锁住了 感觉copilot的GPT老出问题是因为需求太高了serve不了

--- 第 60 楼来自 vczh 的回复 (2026-05-01 19:43:46 PDT) ---

opus我猜应该是经过了anthropic的,因为有时候大家说cc挂掉了的时候,copilot联网质量也会跟着下降

--- 第 61 楼来自 Zig 的回复 (2026-05-01 20:28:11 PDT) ---

你们大老板真的知道么?反正我们的感觉不知道。

--- 第 62 楼来自 AppleVisionPro 的回复 (2026-05-01 20:42:14 PDT) ---

我也是, 我现在自己的业余项目, 现在里面有点啥都快不知道了

--- 第 63 楼来自 Forlorner 的回复 (2026-05-01 20:47:11 PDT) ---

token无限的话不存在山问题 让agent自己去解决

--- 第 64 楼来自 catkinkk 的回复 (2026-05-02 13:56:56 PDT) ---

我司现在限制claude $120一个月 codex也不是都给。

--- 第 65 楼来自 572993482 的回复 (2026-05-02 14:04:56 PDT) ---

你见过哪个编译器编译5次给出5个不同的结果?ai感觉更像薛定谔的猫

--- 第 66 楼来自 懵懂一时 的回复 (2026-05-02 14:08:12 PDT) ---

也可能是装不知道

--- 第 67 楼来自 ze3kr 的回复 (2026-05-02 14:19:19 PDT) ---

企业版域正确配置了很难被下毒。像 openclaw 这种很容易被下毒的基本都不让用

--- 第 68 楼来自 ze3kr 的回复 (2026-05-02 14:19:52 PDT) ---

这也太拉了,我摸鱼一个月都用两三百,卷王能上千;120 就是人均摸鱼了 而且最近组里研究发现,写屎山可以显著降低 token 使用。不写屎山 input/output token 成倍增加

--- 第 69 楼来自 kaion 的回复 (2026-05-02 14:21:01 PDT) ---

做投行 工资估计只有2/3 hour可能是40%+

--- 第 70 楼来自 vczh 的回复 (2026-05-02 14:28:46 PDT) ---

我在公司极致摸鱼都至少要用1000

--- 第 71 楼来自 IRS_pro 的回复 (2026-05-02 14:38:56 PDT) ---

kaion: 做投行 老中做投行的多吗?感觉这对语言要求很高

--- 第 72 楼来自 002 的回复 (2026-05-02 14:39:44 PDT) ---

屎山+1 今天屎山生成爽 明天SEV火葬场

--- 第 73 楼来自 002 的回复 (2026-05-02 14:42:39 PDT) ---

据前https://zh.wikipedia.org/wiki/%E4%B8%AD%E5%85%B1%E4%B8%AD%E5%A4%AE%E7%BB%84%E7%BB%87%E9%83%A8常务副部长、毛泽东秘书https://zh.wikipedia.org/wiki/%E6%9D%8E%E9%94%90_(1917%E5%B9%B4)回忆,1958年底武昌会议时,他曾问毛泽东:“你是农村长大的,长期在农村生活过,怎么能相信一亩地能打上万斤、几万斤粮?”

--- 第 74 楼来自 002 的回复 (2026-05-02 14:47:09 PDT) ---

很明显这种管理模式下权责不对等 今天用屎山生成器吹牛 政绩先捞到手 后面engineering debt管它洪水滔天 反正老子已经升职加薪大包到手了

--- 第 75 楼来自 收束观测者 的回复 (2026-05-02 14:49:00 PDT) ---

ze3kr: 而且最近组里研究发现,写屎山可以显著降低 token 使用。不写屎山 input/output token 成倍增加 这是什么原理 vczh: 我在公司极致摸鱼都至少要用1000 我看了一下我四月的数据,比三月多了快一倍

--- 第 76 楼来自 ze3kr 的回复 (2026-05-02 14:50:24 PDT) ---

不写屎山需要让 AI 阅读更多已有代码,也需要思考更久

--- 第 77 楼来自 IRS_pro 的回复 (2026-05-02 14:56:31 PDT) ---

002: 明天SEV火葬场 没事,明天就跳槽了,管他洪水滔天

--- 第 78 楼来自 Allen_Z 的回复 (2026-05-02 16:43:30 PDT) ---

是这样 但没办法啊 中层又蠢又坏的太多了 别说中层 我们之前的CPO 来了7年 啥都没干成 公司还赔进去几十billion 现在还是跳走去别的公司做CEO了

--- 第 79 楼来自 Zig 的回复 (2026-05-02 17:23:23 PDT) ---

中层没这么大破坏力。中层最大的期望和公务员一样------稳定。 想折腾的都是高层啊。

--- 第 80 楼来自 两只饺子 的回复 (2026-05-02 17:34:31 PDT) ---

想想半年以前还在坚持古法编程,觉得AI在堆屎,顶多问问 ChatGPT,或者 Tab 补全,现在啥也不管统统扔给AI,然后刷泥潭,刷抖音小红奇真香,反正现在就是一个人形确认机和复制机

--- 第 81 楼来自 Allen_Z 的回复 (2026-05-02 17:54:12 PDT) ---

哦哦 可能我们对中层的定义不太一样 我觉得manager 就是直觉管sde的不算 主要是director和vp级别的 然后很多产品那边的PM 为了所谓kpi 在瞎弄

--- 第 82 楼来自 Onvon 的回复 (2026-05-02 18:47:01 PDT) ---

我们team也有这种kpi 不过是skills大炼钢 需要每个月写xx个skills 然后merge到公司repo 然后公司analytics会统计skill被llm call的次数 很多人为了应付就从github上搬运开源的skills 随便加点内容

--- 第 83 楼来自 美露可利 的回复 (2026-05-03 04:14:39 PDT) ---

002: 今天用屎山生成器吹牛 政绩先捞到手 后面engineering debt管它洪水滔天 经历了几个月的修一个bug结果vibe进来5个side effect的日子,大佬们上个月底刚刚强行把一个项目从一个team拿走转给另一个team了,条件就是不可以完全vibe,不允许再发生side effect。 原来的team现在没有任何工作,等候发落。 但凶多吉少,现在讨论的是追责到M几。

--- 第 84 楼来自 Zig 的回复 (2026-05-03 04:47:03 PDT) ---

side effect是什么东西?

--- 第 85 楼来自 美露可利 的回复 (2026-05-03 04:57:26 PDT) ---

就是你跟AI说:门关不严你修一下。 然后AI直接拿木板给门封死了,然后把窗户给你砸了让你出去

--- 第 86 楼来自 Zig 的回复 (2026-05-03 04:59:19 PDT) ---

这也没啥问题啊 主要是经常有junior eng也这么干。 关键是为啥会被人发现有问题?搞出来sev了么?

--- 第 87 楼来自 美露可利 的回复 (2026-05-03 05:03:19 PDT) ---

rollback了无数回,鞠躬道歉了无数回。 大佬们都绝望了,看不到尽头。 元team还没被解散仅仅是因为担心要是复用代码的话还是得有人给support。 但目前的结论是倾向于推到重做。新team全是staff+

--- 第 88 楼来自 Zig 的回复 (2026-05-03 05:06:21 PDT) ---

是出了sev需要rollback还是简单的deliver不了rollback?

--- 第 89 楼来自 up9080 的回复 (2026-05-03 05:38:03 PDT) ---

怎么感觉问题是 pr review 而不是 vice coding

--- 第 90 楼来自 美露可利 的回复 (2026-05-03 05:39:14 PDT) ---

Zig: deliver不了rollback 不是特别理解deliver不了却还要rolllback这种case是怎么存在的 up9080: 问题是 pr review 是的,但vibe上瘾之后我觉得已经没有太多人认真review了

--- 第 91 楼来自 002 的回复 (2026-05-03 09:13:25 PDT) ---

还是株式会社靠谱 不像某科技公司 真要追责怕是要追到CEO

--- 第 92 楼来自 002 的回复 (2026-05-03 09:14:44 PDT) ---

vibe太快了,根本来不及review。说实话,写程序根本不需要快,最重要的是bug free。

--- 第 93 楼来自 bujidao 的回复 (2026-05-03 09:32:18 PDT) ---

老板们觉得可以又bug free又快 来几个global outage炸一炸吧

--- 第 94 楼来自 Rosmontis 的回复 (2026-05-03 09:46:20 PDT) ---

后续还是会引进新bug,而且你自己的scope bug free也难免有激进的team member全都zero shot写出一堆屎,最后结果system肉眼可见的全都是屎。 其实最重要的感觉还是SRE思维,infra人工review,可观测性和容错性,IC会跟manager更像管理一堆coding agent然后迭代几个版本来出方案。one-shot根本就不靠谱,few shot也不靠谱,最终QA还是得人来把关。

--- 第 95 楼来自 Zig 的回复 (2026-05-03 10:10:12 PDT) ---

你这话老板不爱听

--- 第 96 楼来自 Bsian 的回复 (2026-05-03 11:45:54 PDT) ---

赛博许愿编程

--- 第 97 楼来自 SuEastPo 的回复 (2026-05-03 13:01:01 PDT) ---

现在的工作流程就是收菜游戏的体验。

--- 第 98 楼来自 kingsosing 的回复 (2026-05-03 13:14:20 PDT) ---

我们现在组里也是管理层拼命push,都是AI first,用新的AI software development cycle 做个小feature在山上加东西,如果整个流程哪里有问题导致进度比预计慢,反馈上去,得到的答复基本都是说"那是人的问题,需求没说清design没有给ai prompt好各种,沟通没做好一类的,反正AI没问题"

--- 第 99 楼来自 sukasky 的回复 (2026-05-03 14:36:36 PDT) ---

看完之后我的感觉是, window开了之后继续加仓点goog吧

--- 第 100 楼来自 vczh 的回复 (2026-05-03 15:34:29 PDT) ---

这话说的,问题明明很大,而且你们对“这么干的junior eng”太宽容了才是问题,而不是反过来说哎呀AI写得跟junior eng也差不多,梅事的! 美露可利: 但目前的结论是倾向于推到重做。新team全是staff+ 干得漂亮 002: 写程序根本不需要快,最重要的是bug free。 vibe省下来的时间,如果不是拿来多做一个feature,而是花在过程改进上,以后省下来的时间不仅更多,出问题还更难。但是有这种vision的地方实在太少了。所以我建议有追求的码农,最好去参加那些真的会因为质量问题导致产品暴毙的项目,自己的理想就能得到贯彻实现

--- 第 101 楼来自 vczh 的回复 (2026-05-03 15:43:54 PDT) ---

review的人自己也急着vibe多几个,有这种驱动力才是问题的根本,没认真review也只是一个结果罢了

--- 第 102 楼来自 AppleVisionPro 的回复 (2026-05-03 15:46:57 PDT) ---

今年我觉得码农行业越来越metrics的奴隶了

--- 第 103 楼来自 See 的回复 (2026-05-03 16:21:02 PDT) ---

折木奉太郎: 不过我没变得清闲 同感,应该改革变成四天甚至三天工作制,不然干得越快失业越快,现在还没失业只是把别人先淘汰了。不改革分配制度,全部失业迟早的事 东大首先判决ai替代劳动者非法,需要赔偿劳动者 http://www.zj.xinhuanet.com/20260430/1f6a0708d647452fbe9a9f94a99f7421/c.html

--- 第 104 楼来自 See 的回复 (2026-05-03 16:39:58 PDT) ---

https://www.reddit.com/r/Anthropic/s/H7Y9kHboLU Anthropic首先针对消灭的10个职业 https://finance.yahoo.com/news/10-jobs-most-exposed-ai-204721467.html

--- 第 105 楼来自 Zig 的回复 (2026-05-04 12:03:32 PDT) ---

vczh: 我建议有追求的码农,最好去参加那些真的会因为质量问题导致产品暴毙的项目,自己的理想就能得到贯彻实现 我就不知道整个公司有几个项目是这样的。 例如AI这东西就缺少衡量标准,导致好多人就是做做就行。

--- 第 106 楼来自 teirt15 的回复 (2026-05-04 12:41:33 PDT) ---

vczh: 如果不是拿来多做一个feature,而是花在过程改进上,以后省下来的时间不仅更多,出问题还更难。 我在楼中也总结了一下,差不多意思 teirt15: 我感觉更大的问题是开发本身有个时间线,如果强制缩短这个时间线只能砍步骤,造成无法横向扩展的代码或者SEV0,造成很严重的负反馈回路 解决一个问题有最快方法和更深思熟虑的方法,但在极短时间内达到结果的方法肯定不是深思熟虑的 然后AI放弃了思考 其实这么一想还真不是AI的锅,是公司文化的锅

--- 第 107 楼来自 whybabywhy 的回复 (2026-05-06 00:30:54 PDT) ---

正好也是我想探讨的话题。近一年公司极力让大家用ai coding,几乎成了kpi的一项。体感使用起来感觉还是很难用,举个例子当你改动一个已有的function的时候,一般来说你回去看看所有reference确保修改后existing reference still work,但是ai不会管你那么多。这就导致你需要花很多时间在review ai生成的code。 我感觉ai对已有代码库的支援还不是很好,很难想象用ai去改一些比较大型的项目。 我自己的观察,如果想要有更好的ai体验,codebase是需要重构的(但是重构是不可能重构的,从老板的角度来看)。屎山代码用ai就只是加速屎化,到最后啥都改不了。

--- 第 108 楼来自 whybabywhy 的回复 (2026-05-06 00:32:56 PDT) ---

vczh: 所以我建议有追求的码农,最好去参加那些真的会因为质量问题导致产品暴毙的项目,自己的理想就能得到贯彻实现 例如?

--- 第 109 楼来自 Zig 的回复 (2026-05-06 00:34:33 PDT) ---

whybabywhy: 老板 whybabywhy: 极力让大家用ai coding whybabywhy: 成了kpi的一项 打工人想那么多有什么用呢?是吧?想多了反而升不了职。

--- 第 110 楼来自 lyy 的回复 (2026-05-06 00:43:14 PDT) ---

比如火箭卫星系统,出bug直接星毁箭亡?

--- 第 111 楼来自 sukasky 的回复 (2026-05-06 00:45:09 PDT) ---

用的codex还是claude?

--- 第 112 楼来自 teirt15 的回复 (2026-05-06 08:24:41 PDT) ---

不去想了就出局/pip了

--- 第 113 楼来自 catkinkk 的回复 (2026-05-06 09:36:19 PDT) ---

啊?我觉得Claude opus做得很好啊

--- 第 114 楼来自 搞钱不到钱只能玩卡 的回复 (2026-05-06 09:43:31 PDT) ---

干活已经是必须要ai的了 甚至想跳槽太久没打码感觉都在重修 大型项目其实还好 一般会提前走一个DFS生成一些方便ai理解的文件就好 效果用着还行 顶一个NG哼哧半天了 真是新人杀手 最大问题是公司内部伦理(背锅)问题 aka如果是ai打码就不能ai review etc 其实还是整体效率翻倍不止的 自动scrub一些屎山做的还是比人好 前提是test coverage本来够好 不然铁定埋雷

--- 第 115 楼来自 whybabywhy 的回复 (2026-05-06 09:46:46 PDT) ---

windsurf,用的Claude sonnet4.6模型

--- 第 116 楼来自 Onvon 的回复 (2026-05-06 10:06:32 PDT) ---

Sonnet不行 哪怕是max 有时也会犯低级错误 一般都是用opus先自己扫几遍 把可能出的问题和side effect 全部写到md文档里 写成acceptance criteria 再用sonnet执行

--- 第 117 楼来自 catkinkk 的回复 (2026-05-06 11:09:27 PDT) ---

用opus with max effort做planning和review,可以用sonnet做implmentation。

--- 第 118 楼来自 duola1004 的回复 (2026-05-06 11:25:26 PDT) ---

merge 完事了 几年后公司在不在还两说

--- 第 119 楼来自 duola1004 的回复 (2026-05-06 11:26:16 PDT) ---

翻倍 你幽默 我们都target 10X 翻倍属于低效率 在老板看来现在都 这是一个大跃进的时代 ,你翻倍你都不好意思 说

--- 第 120 楼来自 sukasky 的回复 (2026-05-06 11:29:07 PDT) ---

whybabywhy: 极力让大家用ai coding,几乎成了kpi的一项 但是不舍得买最好的模型,这管理层也是醉了

--- 第 121 楼来自 catkinkk 的回复 (2026-05-06 11:40:11 PDT) ---

我们现在还在限制呢,一个月claude $120, 几天就没了

--- 第 122 楼来自 搞钱不到钱只能玩卡 的回复 (2026-05-06 12:39:38 PDT) ---

你也得看啥产品啊 我们直接面对国防客户的 敢出岔子你试试就逝世 整天大跃进脑子坏掉了吧

--- 第 123 楼来自 teirt15 的回复 (2026-05-06 12:52:44 PDT) ---

duola1004: 翻倍属于低效率 在老板看来现在都 私营部门饼画得够大够圆2x当10x engineer画。跟老板1v1讲究的是怎么忽悠,怎么踩队友,怎么lastname et al (从我现在这个公司学来的,旁观了很多ex亚麻middle manager,非常恶心人

--- 第 124 楼来自 duola1004 的回复 (2026-05-06 14:13:40 PDT) ---

我不知道 全看你们CEO CTO 我感觉普遍是要 大幅度提高效率 出岔子 那就是你的锅 你为啥不 review 反正就是AI AI AI 别人能做到 你为啥做不到 之类的 人类学CEO 都说他都不用电脑了 就手机 办公了 其实 普通人 没啥人 全看CEO CTO 怎么想 而且有了AI 之后他们 觉得你说的没道理

--- 第 125 楼来自 Zig 的回复 (2026-05-06 14:19:03 PDT) ---

想这个又不是KPI。

--- 第 126 楼来自 duola1004 的回复 (2026-05-06 14:19:11 PDT) ---

老板也没办法 都是膨胀 不然为啥META 要 AI 造假呢 ,你没事也得把token 用完啊 人家一看你这ai usage 不饱满 LINE 写的不够多啊