BeautifulSoap 最近的时间轴更新 BeautifulSoap 最近的时间轴更新 |
BeautifulSoapV2EX 第 266237 号会员，加入于 2017-11-10 15:25:23 +08:00今日活跃度排名 9031 |
BeautifulSoap 最近回复了
2 天前 回复了 guoziq09 创建的主题 › 程序员 › 话说自动大模型和小龙虾以及类似的 agnet 出来后，已经很少看到有人说隐私的问题了。 |
ai 还在野蛮生长阶段，这个阶段无论什么行业都差不多的。注重隐私之类的要到 ai 发展平稳之后才会逐渐被重视
2 月 28 日 回复了 Lullaby001 创建的主题 › 问与答 › AI 发展这么迅速？怎么解决产能过剩问题的？ |
@Lullaby001 我用你的原话回你。我希望可以更加实际的讨论问题， 而不是抛一些类似没有被证实或大规模发生的话来当论据。
AI 大量替代人工：实际上现在 AI 并没有在全球范围内大范围替代人工
人类赖以生存的智力、体力都会被替代：AI 也根本没有替代人类的智力、更别说体力
大量人类被排斥到生产活动之外：依旧是根本没发生的事情。
你一方面让我别说虚的来点实际的（我甚至还是用的已经发生过的过去的历史的总结），但结果你自己的论据却是比我还虚的妄想。做人能不能别这么双标？
AI 大量替代人工：实际上现在 AI 并没有在全球范围内大范围替代人工
人类赖以生存的智力、体力都会被替代：AI 也根本没有替代人类的智力、更别说体力
大量人类被排斥到生产活动之外：依旧是根本没发生的事情。
你一方面让我别说虚的来点实际的（我甚至还是用的已经发生过的过去的历史的总结），但结果你自己的论据却是比我还虚的妄想。做人能不能别这么双标？
2 月 28 日 回复了 Lullaby001 创建的主题 › 问与答 › AI 发展这么迅速？怎么解决产能过剩问题的？ |
@Lullaby001 1.我不认为 “回路这么短” 算人身攻击，我只是在奇怪为什么你思考问题只考虑一步 2.按照你的逻辑，任何一个跨时代取代大量人力的自动化技术出现都会导致你所谓的没人消费。但实际上人类至今为止的所有工业化从最终结果来看，并不支持你的观点。新技术的确会让一开始非常多人失业，但新技术让更多需求爆发社会生产量增加，先前失业的人口立刻就被社会生产的增量消耗掉了。
反正对我来说，我对今后 AI 和社会的发展并没有你如此悲观（仅指短期、不是十几几十年后）。
反正对我来说，我对今后 AI 和社会的发展并没有你如此悲观（仅指短期、不是十几几十年后）。
2 月 28 日 回复了 Lullaby001 创建的主题 › 问与答 › AI 发展这么迅速？怎么解决产能过剩问题的？ |
@Lullaby001 ?你的思考回路这么短的吗,亲??? 释放需求意味着社会生产增加，为此必定伴随着大量的劳动力需求，最终必定带动消费。
你的观点无非就是那套 AI 抢了所有工作，需求全被 AI 拿走了那套。而我并不认同你的观点，我认为 AI 释放出的巨大需求反倒会抹平这些问题。
你的观点无非就是那套 AI 抢了所有工作，需求全被 AI 拿走了那套。而我并不认同你的观点，我认为 AI 释放出的巨大需求反倒会抹平这些问题。
2 月 27 日 回复了 Lullaby001 创建的主题 › 问与答 › AI 发展这么迅速？怎么解决产能过剩问题的？ |
@Lullaby001 所以你是没看懂我在说什么？
> AI 之前的非常多项目和需求都受限于人力和成本实际上并没有被释放出来
> AI 让编码效率提升后，非常多的新需求新出现
你认为需求赶不上 AI 解放得生产力，而我认为目前阶段来说 AI 解放多少生产力就会被多少新需求给吃掉
至于十几几十年之后的事情，没人能猜中
> AI 之前的非常多项目和需求都受限于人力和成本实际上并没有被释放出来
> AI 让编码效率提升后，非常多的新需求新出现
你认为需求赶不上 AI 解放得生产力，而我认为目前阶段来说 AI 解放多少生产力就会被多少新需求给吃掉
至于十几几十年之后的事情，没人能猜中
2 月 27 日 回复了 Lullaby001 创建的主题 › 问与答 › AI 发展这么迅速？怎么解决产能过剩问题的？ |
@BeautifulSoap 打错了“AI 让编码效率提升后，非常多的新需求出现会立刻吃掉当前全世界的算力”
2 月 27 日 回复了 Lullaby001 创建的主题 › 问与答 › AI 发展这么迅速？怎么解决产能过剩问题的？ |
我倒不认为现在就已经产能过剩了
我的看法是 AI 之前的非常多项目和需求都受限于人力和成本实际上并没有被释放出来
AI 让编码效率提升后，非常短的新需求出现会立刻吃掉当前全世界的算力
我的看法是 AI 之前的非常多项目和需求都受限于人力和成本实际上并没有被释放出来
AI 让编码效率提升后，非常短的新需求出现会立刻吃掉当前全世界的算力
2 月 27 日 回复了 tomyark123 创建的主题 › 职场话题 › 工作中捅出大篓子怎么心理调节 |
我曾经因为写出的一个代码逻辑错误导致客户公司没有收回部分用户付款，最终客户损失 300w 日元，由公司负担。干 it 总归是要出点事故的，吸取教训就行了
2 月 26 日 回复了 Qcui 创建的主题 › 职场话题 › 为什么后端同学普遍不愿意使用 AI 辅助写代码 |
我在的公司大家都在用 cursor ，甚至因为大家用太多，每个月到了中后半都会触发公司设定的氪金上限（上限几万$都不够）
大家天天都在问 it 部门什么时候能开放用 codex ，claude code ，但因为这两公司对企业用户数据承诺，协议相关问题一直被公司禁止使用
大家天天都在问 it 部门什么时候能开放用 codex ，claude code ，但因为这两公司对企业用户数据承诺，协议相关问题一直被公司禁止使用
2 月 24 日 回复了 yikyo 创建的主题 › 程序员 › 标题： [求推荐] 寻找开箱即用的 Go Web 模板（需 GORM + DI + 垂直切片架构），顺便探讨一下 Go 社区对 DI 的态度 |
很多 Go 程序员嘴巴上说 Go 不需要框架，不需要 DI ，不需要分层。面对这些东西的讨论的时候就仿佛触发了什么底层的哈气代码一样有一种天生的仇恨。
但矛盾的是，实际上真工作中遇到项目对应复杂度的时候，排除掉堆屎山的，大部分人都自己手搓出了对应的简陋的 DI 、DDD 分层框架。只不过大部分人要不根本没意识到自己已经这么干了（取的名字千奇百怪，结构千奇百怪），要不就根本不想承认自己已经这么干了。
话题偏了，回到 lz 问的问题，我的 Go 项目一般都是在 Gin 上自己分层，DI 虽然有 wire 这东西但真的非常难用，一般我喜欢用 dig 做 DI 。为了避免动态 di 在运行时出问题的坑，我所有依赖都尽量通过工厂函数在服务器启动时完成注入，从不在运行时动态获取依赖。这样一旦依赖出问题就能在启动服务的那一瞬间报错崩溃注意到
ORM 以前喜欢用 GORM 但是后来发现 GORM 这玩意实在没有多好用，现在喜欢直接 sqlx 。而且我最近的项目很多都涉及到 serverless+Dynamodb ，所以通过分层框架实现多数据库兼容已经是现在项目的基本前提了，一旦系统设计不局限于 sql 要考虑兼容性，就能立刻扩展系统设计水平和意识到分层的重要性
但矛盾的是，实际上真工作中遇到项目对应复杂度的时候，排除掉堆屎山的，大部分人都自己手搓出了对应的简陋的 DI 、DDD 分层框架。只不过大部分人要不根本没意识到自己已经这么干了（取的名字千奇百怪，结构千奇百怪），要不就根本不想承认自己已经这么干了。
话题偏了，回到 lz 问的问题，我的 Go 项目一般都是在 Gin 上自己分层，DI 虽然有 wire 这东西但真的非常难用，一般我喜欢用 dig 做 DI 。为了避免动态 di 在运行时出问题的坑，我所有依赖都尽量通过工厂函数在服务器启动时完成注入，从不在运行时动态获取依赖。这样一旦依赖出问题就能在启动服务的那一瞬间报错崩溃注意到
ORM 以前喜欢用 GORM 但是后来发现 GORM 这玩意实在没有多好用，现在喜欢直接 sqlx 。而且我最近的项目很多都涉及到 serverless+Dynamodb ，所以通过分层框架实现多数据库兼容已经是现在项目的基本前提了，一旦系统设计不局限于 sql 要考虑兼容性，就能立刻扩展系统设计水平和意识到分层的重要性
Select Language