V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  BeautifulSoap  ›  全部回复第 1 页 / 共 128 页
回复总数  2555
1  2  3  4  5  6  7  8  9  10 ... 128  
13 小时 43 分钟前
回复了 Lullaby001 创建的主题 问与答 AI 发展这么迅速?怎么解决产能过剩问题的?
@Lullaby001 我用你的原话回你。我希望可以更加实际的讨论问题, 而不是抛一些类似没有被证实或大规模发生的话来当论据。
AI 大量替代人工:实际上现在 AI 并没有在全球范围内大范围替代人工
人类赖以生存的智力、体力都会被替代:AI 也根本没有替代人类的智力、更别说体力
大量人类被排斥到生产活动之外:依旧是根本没发生的事情。

你一方面让我别说虚的来点实际的(我甚至还是用的已经发生过的过去的历史的总结),但结果你自己的论据却是比我还虚的妄想。做人能不能别这么双标?
14 小时 12 分钟前
回复了 Lullaby001 创建的主题 问与答 AI 发展这么迅速?怎么解决产能过剩问题的?
@Lullaby001 1.我不认为 “回路这么短” 算人身攻击,我只是在奇怪为什么你思考问题只考虑一步 2.按照你的逻辑,任何一个跨时代取代大量人力的自动化技术出现都会导致你所谓的没人消费。但实际上人类至今为止的所有工业化从最终结果来看,并不支持你的观点。新技术的确会让一开始非常多人失业,但新技术让更多需求爆发社会生产量增加,先前失业的人口立刻就被社会生产的增量消耗掉了。

反正对我来说,我对今后 AI 和社会的发展并没有你如此悲观(仅指短期、不是十几几十年后)。
17 小时 53 分钟前
回复了 Lullaby001 创建的主题 问与答 AI 发展这么迅速?怎么解决产能过剩问题的?
@Lullaby001 ?你的思考回路这么短的吗,亲??? 释放需求意味着社会生产增加,为此必定伴随着大量的劳动力需求,最终必定带动消费。
你的观点无非就是那套 AI 抢了所有工作,需求全被 AI 拿走了那套。而我并不认同你的观点,我认为 AI 释放出的巨大需求反倒会抹平这些问题。
@Lullaby001 所以你是没看懂我在说什么?

> AI 之前的非常多项目和需求都受限于人力和成本实际上并没有被释放出来
> AI 让编码效率提升后,非常多的新需求新出现

你认为需求赶不上 AI 解放得生产力,而我认为目前阶段来说 AI 解放多少生产力就会被多少新需求给吃掉
至于十几几十年之后的事情,没人能猜中
@BeautifulSoap 打错了“AI 让编码效率提升后,非常多的新需求出现会立刻吃掉当前全世界的算力”
我倒不认为现在就已经产能过剩了
我的看法是 AI 之前的非常多项目和需求都受限于人力和成本实际上并没有被释放出来
AI 让编码效率提升后,非常短的新需求出现会立刻吃掉当前全世界的算力
2 月 27 日
回复了 tomyark123 创建的主题 职场话题 工作中捅出大篓子怎么心理调节
我曾经因为写出的一个代码逻辑错误导致客户公司没有收回部分用户付款,最终客户损失 300w 日元,由公司负担。干 it 总归是要出点事故的,吸取教训就行了
我在的公司大家都在用 cursor ,甚至因为大家用太多,每个月到了中后半都会触发公司设定的氪金上限(上限几万$都不够)
大家天天都在问 it 部门什么时候能开放用 codex ,claude code ,但因为这两公司对企业用户数据承诺,协议相关问题一直被公司禁止使用
很多 Go 程序员嘴巴上说 Go 不需要框架,不需要 DI ,不需要分层。面对这些东西的讨论的时候就仿佛触发了什么底层的哈气代码一样有一种天生的仇恨。
但矛盾的是,实际上真工作中遇到项目对应复杂度的时候,排除掉堆屎山的,大部分人都自己手搓出了对应的简陋的 DI 、DDD 分层框架。只不过大部分人要不根本没意识到自己已经这么干了(取的名字千奇百怪,结构千奇百怪),要不就根本不想承认自己已经这么干了。

话题偏了,回到 lz 问的问题,我的 Go 项目一般都是在 Gin 上自己分层,DI 虽然有 wire 这东西但真的非常难用,一般我喜欢用 dig 做 DI 。为了避免动态 di 在运行时出问题的坑,我所有依赖都尽量通过工厂函数在服务器启动时完成注入,从不在运行时动态获取依赖。这样一旦依赖出问题就能在启动服务的那一瞬间报错崩溃注意到

ORM 以前喜欢用 GORM 但是后来发现 GORM 这玩意实在没有多好用,现在喜欢直接 sqlx 。而且我最近的项目很多都涉及到 serverless+Dynamodb ,所以通过分层框架实现多数据库兼容已经是现在项目的基本前提了,一旦系统设计不局限于 sql 要考虑兼容性,就能立刻扩展系统设计水平和意识到分层的重要性
2 月 19 日
回复了 383394544 创建的主题 OpenAI 各位现在还在用 GPT 还是转向别的 LLM
可以啊,到时候 AI 就事论事把你的国家,民族,信仰,尊敬的人物批得体无完肤,你又只能无能狂怒
AI 甚至都不需要故意骂用户,把知识库里收集的那些材料拿出来就行了

有的人可能无所谓,但有的宗教要是被骂了那可能真的直接去炸 AI 公司总部的。你在这说说倒是简单,但 AI 公司还是惜命的

同样道理,涉及到社会团体,关键政要的时候,AI 可以随便乱说,但 AI 公司的投资者,员工,高层可不想死
codex 很适合实现 UI 设计,不太适合设计 UI
给它明确的设计它能很好实现,并且不像 claude code 那样自作主张瞎几把改

还有,codex 意外挺适合用 svg 设计 logo 的。对比 claude code 和 codex 设计的一个项目的 logo 。claude code 设计的 log 简直就是难看到令人发指。而 codex 在抽卡几次之后甚至还能出几个比较让你眼前一亮的东西
2 月 11 日
回复了 x97bgt 创建的主题 程序员 codex 的遵循性似乎不如 Claude Code?
说 codex 遵循性不如 claude code ,看来 lz 是是真没用太多。。。。。。Claude Code 的模型是最会自作聪明,自作主张,画蛇添足的模型了。所有用了 claude 系列模型的 ai 编码工具也都一个吊样。导致我现在让 claude 给我改东西我都要死死盯着它到底动了哪里,一不对劲就立刻终止
2 月 10 日
回复了 lianxin 创建的主题 日本 赴日 工作交流
@lianxin 我留学过来日本的,日语交流没问题所以周围反倒没中国人 or 外国人。。。。。。真没中文工作环境可以介绍。。。
2 月 10 日
回复了 lianxin 创建的主题 日本 赴日 工作交流
Base 45K 来日本有点想不开了。。。。。我在日本干了 6 年,税前年收都还没到 1000w 日元(当然和我咸鱼在现在公司拼命躺平摸鱼不跳槽也有关),没必要来这没苦硬吃
2 月 10 日
回复了 byp 创建的主题 全球工单系统 2026-02-10 GitHub 崩了
玛德,我网站要发布了,正测试 sso 登录呢,结果就 github sso 登录各种拼命报错。我满头大汗排查了半天发现就是 github 炸了,气死我了
2 月 5 日
回复了 PhpBB 创建的主题 旅行 三大运营商 哪个国际漫游时提供中国 IP
@Lowlife 你是看不懂我我在说什么吗?说的是,据我所知国外的运营商(至少日本、美国的运营商),没有像你说的国内电信这样,提供用户海外漫游的本地流量的功能。所以我才说「还真从没听过哪个日本和美国运营商国际漫游会提供本地流量的」
2 月 5 日
回复了 PhpBB 创建的主题 旅行 三大运营商 哪个国际漫游时提供中国 IP
@Lowlife 你这贴出的图片买的是哪个国家运营商的国际漫游?我根本没见过日本或美国的运营商提供目的地本地流量的国际漫游的
2 月 5 日
回复了 PhpBB 创建的主题 旅行 三大运营商 哪个国际漫游时提供中国 IP
@Lowlife 那的确第一次听说。我在日本生活,还真从没听过哪个日本和美国运营商国际漫游会提供本地流量的。见识短浅了
2 月 5 日
回复了 PhpBB 创建的主题 旅行 三大运营商 哪个国际漫游时提供中国 IP
国际漫游都是把流量传回 sim 卡所属国的运营商,然后再访问目标网站的
所以国内 sim 卡在国外国际漫游也没法翻墙,因为你的流量最终被当地运营商转发到了国内访问对应网站
同理,这就是为什么你拿着国外的 sim 卡在国内能翻墙。这就是为什么那么多人想在国内整国外的 esim

这种漫游的坏处就是延迟爆炸,你的流量必须传回 sim 卡所属地再出去
1  2  3  4  5  6  7  8  9  10 ... 128  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2374 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 38ms · UTC 00:26 · PVG 08:26 · LAX 16:26 · JFK 19:26
♥ Do have faith in what you're doing.