一项最新的路透社/益普索民意调查显示，随着人工智能（AI）在各行业快速扩张，美国社会对就业前景的忧虑显著加剧，约半数美国人担心自己或家中成员可能因AI而失去工作。 该项为期六天的全国性调查于本周一结束，结果显示有53%的受访者表示存在这一担忧，这种忧虑在不同年龄、性别和受教育程度人群中分布相对均衡。约37%的受访者称自己完全不担心这一问题，另有约10%表示不确定或选择不回答。 这次民调是在多家大型企业宣布与AI相关的裁员之后进行的，其中包括软件公司Intuit。该公司上月告知员工，将裁减其全球员工总数的17%，以精简运营并更加聚焦包括AI在内的重点业务方向。与此同时，AI在公众场合的争议也不断发酵。上个月，前Google首席执行官埃里克·施密特在亚利桑那大学毕业典礼上谈及AI影响时，现场学生以嘘声表达不满。随着AI可能被用于政治宣传、娱乐乃至战争等领域，部分民选官员甚至教宗利奥十四世都相继发出警示。 尽管科技公司频频宣布裁员，但AI对整体美国就业市场的真实冲击仍有待观察。近期美国经济仍在持续增加就业岗位，整体就业数据表现强劲。不过，在社会情绪层面，焦虑已明显显现。民调发现，对AI持怀疑态度的民主党选民比例高于共和党选民。民主党更容易吸引受过大学教育群体，而共和党自总统唐纳德·特朗普崛起以来则在工人阶层中支持率上升。本次调查中，61%的民主党支持者表示担心AI会威胁到家庭成员的工作，而在共和党支持者中这一比例为47%。 此次路透社/益普索民调面向全美4，531名成年受访者，调查时间为6月3日至8日，整体样本误差幅度为正负2个百分点，细分群体误差约为正负3个百分点。受访者中不乏已经感受到冲击的人士。来自新泽西州利特尔费里的62岁自由撰稿人詹妮弗·沙勒胡布表示，她近期失去了撰写信函、为特定政策进行倡导的工作，而她怀疑这在一定程度上与AI的兴起有关。她认为，AI之所以快速取代人类，是因为“人们越来越不在乎工作成果的质量”。 人工智能在美国社会大规模进入公众视野是在2022年。那一年，AI企业OpenAI推出面向普通消费者的产品ChatGPT，这一工具可以以类似人类的方式回答用户提问，并提供一种不同于传统搜索引擎的新型信息检索方式，被视为对Google母公司Alphabet既有业务的直接威胁。另一家AI公司Anthropic也迅速在企业客户中站稳脚跟，其中包括销售用于计算机代码编写辅助的工具Claude Code。OpenAI和Anthropic均因计划向公众发行股票而在华尔街引发巨大关注。 民调还显示，受教育程度越高的人群，使用AI的频率也越高。整体来看，40%的受访者表示自己经常使用AI，而在大学毕业生当中，这一比例达到50%，明显高于没有大学学历人群中的34%。调查同样基于6月3日至8日期间对4，531名成年人的在线问卷，相关数据的统计误差约为正负2个百分点。 在更广泛的层面上，73%的美国人表示担心社会对AI的使用正在不断增加。这一比例较2023年路透社/益普索民调中的68%略有上升，表明过去一年中公众忧虑有所加深。部分受访者将担忧集中在AI可能带来的伦理与心理风险上。美国华盛顿州的一位临床心理学家劳伦·黑斯表示，她注意到有一些来访者在两次心理治疗之间，会求助于AI来缓解焦虑情绪。她指出，自己并不认为AI能够具备人与人之间交流所需要的“细腻理解和情感把握”。 这项调查结果显示，在AI迅速渗透政治、经济和日常生活的当下，美国社会对于技术进步与就业安全、心理健康之间的平衡问题愈发敏感。虽然宏观就业数据暂时尚未全面反映大规模冲击，但围绕AI的未来走向、监管力度以及对普通家庭生计的潜在影响，美国社会的讨论与分歧正在不断加剧。 查看评论
美国国家经济研究局（NBER）一篇 2026 年工作论文指出，美国总生育率自 2007 年以来下降了 22%，而这一下滑并不能轻易用经济形势、避孕使用、住房或育儿成本等常见因素解释 。研究作者将目光转向一个不同的冲击：智能手机，尤其是第一代现代智能手机 iPhone 的普及 。 他们利用 iPhone 在 2007 年 6 月到 2011 年 2 月之间只在 AT&T 网络上销售这一独特时期，把 AT&T 移动宽带覆盖范围当作自然实验，来识别 iPhone 对生育的影响 。 这项研究把县级数据拼成一个 2003 至 2011 年的面板，结合了各县的 AT&T、Sprint、T-Mobile 和 Verizon 移动宽带覆盖情况，以及按年龄分组的出生数据 。作者重点比较了 AT&T 覆盖几乎全覆盖的县和几乎没有覆盖的县，因为在 iPhone 独家销售时期，能否“功能性使用”iPhone 取决于是否接入 AT&T 的移动宽带网络 。研究采用了两种方法：一种是熵平衡泊松事件研究，另一种是合成差分中的差分（SDID），都用来尽量消除治疗组和对照组在城市化、种族、政治倾向等方面的系统差异 。 结果显示，iPhone 的扩散与年轻女性出生率下降显著相关 。在 15 至 19 岁女性中，研究估计出生率下降 4.5% 到 8.0%；在 20 至 24 岁女性中，下降 3.2% 到 6.6% 。更年长群体也出现下降，但幅度较小，且部分结果统计上不显著 。按全国县域规模折算，作者认为 iPhone 传播可解释 2007 年以来美国 15 至 44 岁女性总生育率下降的 33% 到 52% 。 作者还用全国调查数据去验证可能的机制，结果与“iPhone 减少面对面互动、增加色情内容使用、降低性行为频率”这一解释一致 。论文提到，围绕手机和社交媒体的行为研究已经发现，智能手机时代的年轻群体在面对面社交、约会、饮酒、开车等方面投入更少时间，同时性伙伴数量和性生活频率也在下降 。研究因此认为，iPhone 不是单纯改变通信工具，而是改变了年轻人的时间分配和社交方式，从而对生育行为产生了可测量影响 。 iPhone 及其开启的智能手机时代，实质上加速了美国 2007 年后持续至今的生育下行趋势 。作者强调，这一结论并不意味着手机是唯一原因，但它提供了一个量化幅度很大的解释，尤其对年轻女性出生率的下降最为明显 。这项研究把此前学界关于“智能手机改变了年轻人生活方式”的观察，推进到了更明确的因果识别层面 。 了解更多： https://www.nber.org/system/files/working_papers/w35310/w35310.pdf 查看评论
SQLite 默认未开启 WAL ，这会显著限制并发性能。 PlanTodo 是一个计划管理软件，最近我为它的同步服务编写了性能测试，经过实测，仅开启 WAL 就让同步服务的吞吐量便提升至原来的 3 倍， 其实关于 SQLite 性能优化的文章早有珠玉在前，比如 Optimal SQLite settings for Django 和 Optimizing SQLite for servers ，所以本篇文章并没有独创性，只是为了让更多人了解 SQLite 的 性能 以及分享一个真实的性能 测试用例 。 PlanTodo 同步服务性能测试 性能测试分为三个： oo_upload (one user, one device for a user, only upload) ，就是一个用户一台设备仅上传 oo_download 就是仅下载 oo_cross 是上传和下载交错进行 oo_upload 和 oo_download 是为了查看上传和下载场景下的极限性能，是为了将来专门优化时用来参考的。而 oo_cross 则较为贴近真实使用场景：用户的某个设备上传几个更新，另一个设备被触发下载；因此可以拿它计算服务器能承受的用户量。 如果你不想看下面具体的测试数据，这里简单展示了吞吐量的变化： oo_upload ，18027 -> 61682 ，是原来的 3.42 倍 oo_download ，17082 -> 49635 ，是原来的 2.90 倍 oo_cross ，17085 -> 44203 ，是原来的 2.58 倍 一般查询是比写入要快的，因此下载应该比上传快，但 PlanTodo 的同步服务却反了过来，说明有很大的优化空间。 下面是开启 WAL 前的测试数据： + just -f services/sync/justfile headless_oo_upload --less-output ============================================================ Performance Summary for test_oo_upload ============================================================ Requests : 18,027 Failures : 0 Failure Rate : 0.00% Average RT : 78.14 ms P50 : 78 ms P95 : 110 ms P99 : 130 ms Max : 272.81 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=18,011 Avg=78.1ms P95=110ms P99=130ms Max=272.8ms POST /v1/clients Requests=8 Avg=76.2ms P95=110ms P99=110ms Max=109.9ms GET /v1/sync/full Requests=8 Avg=57.2ms P95=120ms P99=120ms Max=120.3ms + just -f services/sync/justfile headless_oo_download --less-output ============================================================ Performance Summary for test_oo_download ============================================================ Requests : 17,082 Failures : 0 Failure Rate : 0.00% Average RT : 82.63 ms P50 : 82 ms P95 : 110 ms P99 : 130 ms Max : 370.33 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=16 Avg=172.6ms P95=370ms P99=370ms Max=370.3ms GET /v1/sync/delta?cursor=1780662404990&limit=100 Requests=2,087 Avg=83.4ms P95=110ms P99=130ms Max=316.1ms GET /v1/sync/delta?cursor=1780662403978&limit=100 Requests=2,102 Avg=83.3ms P95=110ms P99=130ms Max=325.5ms + just -f services/sync/justfile headless_oo_cross --less-output ============================================================ Performance Summary for test_oo_cross ============================================================ Requests : 17,085 Failures : 0 Failure Rate : 0.00% Average RT : 83.05 ms P50 : 82 ms P95 : 120 ms P99 : 150 ms Max : 245.89 ms Endpoints ------------------------------------------------------------ GET /v1/sync/delta?cursor=1780662760888&limit=100 Requests=1 Avg=245.9ms P95=250ms P99=250ms Max=245.9ms GET /v1/sync/delta?cursor=1780662760900&limit=100 Requests=1 Avg=245.4ms P95=250ms P99=250ms Max=245.4ms GET /v1/sync/delta?cursor=1780662758760&limit=100 Requests=1 Avg=228.2ms P95=230ms P99=230ms Max=228.2ms 下面是 开启 WAL 之后 的测试数据： + just -f services/sync/justfile headless_oo_upload --less-output ============================================================ Performance Summary for test_oo_upload ============================================================ Requests : 61,682 Failures : 0 Failure Rate : 0.00% Average RT : 22.30 ms P50 : 22 ms P95 : 32 ms P99 : 41 ms Max : 74.82 ms Endpoints ------------------------------------------------------------ POST /v1/clients Requests=8 Avg=33.8ms P95=48ms P99=48ms Max=48.1ms POST /v1/sync/delta Requests=61,666 Avg=22.3ms P95=32ms P99=41ms Max=74.8ms GET /v1/sync/full Requests=8 Avg=20.7ms P95=32ms P99=32ms Max=32.5ms + just -f services/sync/justfile headless_oo_download --less-output ============================================================ Performance Summary for test_oo_download ============================================================ Requests : 49,635 Failures : 0 Failure Rate : 0.00% Average RT : 28.03 ms P50 : 28 ms P95 : 38 ms P99 : 46 ms Max : 305.64 ms Endpoints ------------------------------------------------------------ POST /v1/sync/delta Requests=16 Avg=127.0ms P95=310ms P99=310ms Max=305.6ms GET /v1/sync/delta?cursor=1780663066610&limit=100 Requests=6,109 Avg=28.4ms P95=38ms P99=46ms Max=246.0ms GET /v1/sync/delta?cursor=1780663068640&limit=100 Requests=6,064 Avg=28.3ms P95=38ms P99=46ms Max=95.8ms + just -f services/sync/justfile headless_oo_cross --less-output ============================================================ Performance Summary for test_oo_cross ============================================================ Requests : 44,203 Failures : 0 Failure Rate : 0.00% Average RT : 31.80 ms P50 : 28 ms P95 : 45 ms P99 : 150 ms Max : 477.37 ms Endpoints ------------------------------------------------------------ GET /v1/sync/delta?cursor=1780663421960&limit=100 Requests=1 Avg=477.4ms P95=480ms P99=480ms Max=477.4ms GET /v1/sync/delta?cursor=1780663421963&limit=100 Requests=1 Avg=475.9ms P95=480ms P99=480ms Max=475.9ms GET /v1/sync/delta?cursor=1780663421966&limit=100 Requests=1 Avg=475.4ms P95=480ms P99=480ms Max=475.4ms 每个测试只持续了 3 min ，因此数据量很小，在大数据量的情况下，性能可能会下降很多，这个会在将来补充。 在测试 oo_cross 里，3min 处理了 44203 个请求，也就是一秒 245 个。测试其实是不断在重复先上传再下载，而客户端也是上传下载成对出现，因此一秒能处理 122 （ 245 / 2 ）台设备的请求，即便因为多用户、多设备带来的其他压力，至少能稳定在一秒 100 个请求。 考虑到，真实使用下，平均要几分钟到十几分钟才会更新一次内容，取 10 分钟一次的话，一个同步服务极限下能支撑 100 x 60 x 10 ，6 万个设备正常使用。 如何开启 WAL 不管是什么 ORM ，开启的方式都是一样的，就是在连接数据库后，执行一次 PRAGMA journal_mode=WAL 。 开启了 WAL 后，在原本的 SQLite 数据库文件那里，会多出两个 .db-shm 、 .db-wal 的文件，可以以此判断是否成功开启。 SQLAlchemy from sqlalchemy import create_engine, event engine = create_engine( DATABASE_URL, echo=False, connect_args={ "timeout": 5, }, ) if engine.dialect.name == "sqlite": @event.listens_for(engine, "connect") def set_sqlite_pragma(dbapi_connection, _): cursor = dbapi_connection.cursor() # cursor.execute("PRAGMA foreign_keys=ON") cursor.execute("PRAGMA journal_mode=WAL") cursor.execute("PRAGMA synchronous=NORMAL") cursor.execute("PRAGMA temp_store=MEMORY") cursor.execute("PRAGMA cache_size=2000") cursor.execute("PRAGMA mmap_size=134217728") cursor.close() PlanTodo 的同步服务就是使用 FastAPI + SQLAlchemy 开发的。由于同步服务的特殊性，这里没有开启外键约束。 Django 在项目的 settings.py 文件里，添加 init_command： DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": BASE_DIR / "db.sqlite3", "OPTIONS": { "init_command": ( "PRAGMA foreign_keys = ON;" "PRAGMA journal_mode = WAL;" "PRAGMA synchronous = NORMAL;" "PRAGMA busy_timeout = 5000;" "PRAGMA temp_store = MEMORY;" "PRAGMA cache_size = 2000;" "PRAGMA mmap_size = 134217728;" ), }, } } drift 在数据库类的 migration get 方法里，在 beforeOpen 这个回调里增加执行命令： class PtdDatabase extends _$PtdDatabase { // 省略无关代码 @override MigrationStrategy get migration { return MigrationStrategy( beforeOpen: (details) async { // 在每次打开数据库，正式使用之前，执行的命令 await customStatement('PRAGMA journal_mode = WAL'); await customStatement('PRAGMA synchronous = NORMAL'); await customStatement('PRAGMA busy_timeout = 5000'); await customStatement('PRAGMA temp_store = MEMORY'); await customStatement('PRAGMA cache_size = -2000'); }, ); } } 原文链接： https://yanh.tech/2026/06/sqlite-performance-optimization/ 版权声明：本博客所有文章除特別声明外，均为 AhFei 原创，采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 技焉洲 (yanh.tech) 。
IT之家 6 月 3 日消息，据新华社今日报道，中国科学院分子植物科学卓越创新中心巫永睿、王海海团队，联合上海师范大学王文琴团队和四川农业大学黄永财团队，成功从野生玉米中克隆出第二个高蛋白主效基因 THP3-T，相关成果于北京时间 6 月 3 日晚在线发表于《自然》。 玉米是我国第一大粮食作物，也是畜禽养殖业中不可或缺的“饲料之王”。然而，由于我国主栽玉米品种的蛋白含量普遍偏低，动物饲料长期以来严重依赖进口豆粕作为蛋白补充来源。据测算，我国大豆年进口量超过 1 亿吨，对外依存度高达 80% 以上，培育高蛋白玉米被视为缓解这一结构性矛盾的重要路径。 研究团队介绍称，野生玉米的蛋白含量可高达 30%，然而在现代玉米长达 9000 多年的驯化与现代育种过程中，多数与高蛋白相关的优异基因已逐渐丢失，导致当前杂交种玉米的蛋白含量普遍徘徊在 8% 左右。 早在 2012 年，巫永睿研究员便投身于提高玉米蛋白含量的相关研究。经过长达十年的努力，该团队于 2022 年率先从野生玉米中挖掘出首个高蛋白基因 THP9-T，实现了主栽玉米品种蛋白含量的初步提升。此次成功克隆的 THP3-T，则进一步补齐了高蛋白玉米育种的“关键拼图”。 研究发现，THP3-T 编码谷氨酸-草酰乙酸转氨酶 1，是氮代谢途径中的核心酶。该基因主要通过增强氮同化能力，在不影响产量的前提下显著提升玉米籽粒及全株蛋白含量。群体遗传学分析显示，THP3-T 在现代玉米品种中出现的频率仅为 2.1%，十分稀有。当研究团队将 THP3-T 与已发现 THP9-T 进行聚合后，这两个基因展现出显著的协同增效作用，实验结果显示自交系玉米籽粒蛋白含量从 10% 提升至 15%。 在实际育种应用层面，该团队将这两个高蛋白基因导入我国推广面积最大的玉米杂交种“郑单 958”中，成功将其籽粒蛋白含量从 8.5% 提升至 12% 到 13%，全株蛋白含量从 7% 提升至 9% 以上，且产量保持稳定。 据团队测算，我国饲用玉米蛋白含量若每提升 1 个百分点，所增加的蛋白总量约可等效替代 800 万吨进口大豆；若全国玉米蛋白含量从 8% 提升至 12% 以上，每年可减少大豆进口约 3000 万吨，相当于当前进口总量的约 30%。 目前，该团队已利用分子标记辅助育种技术，精准改良了 80 余个国内玉米主栽品种的亲本，改良后亲本蛋白含量可提升至 14% 以上。 此外，来自权威机构的饲用价值评估报告显示，高蛋白玉米不仅可部分替代进口豆粕，还有望改善鸡蛋、猪肉等禽畜产品的风味。研究团队透露，目前已与新希望、牧原等养殖企业签约合作，推动相关成果的产业化落地。 IT之家附论文地址： https://doi.org/10.1038/s41586-026-10575-8
最近和学校打交道，博士生说他们的很多横向，实际上发现微调后的效果用户根本感知不出来，只能通过一些数据集测试准确率反应效果，实际体验还不如挂个知识库RAG来的快又好。在开源大模型能力愈发强大的当下，微调还有价值吗？ 2 个帖子 - 2 位参与者 阅读完整话题
目前看起来 AI 对软件行业影响巨大，开发速度显著提升。 那么对于医药行业，AI 起到了哪些帮助？提升效果怎么样？能不能在未来几十年内看到大部分疾病都有创新性的治愈方法？
目前看起来 AI 对软件行业影响巨大，开发速度显著提升。 那么对于医药行业，AI 起到了哪些帮助？提升效果怎么样？能不能在未来几十年内看到大部分疾病都有创新性的治愈方法？
求助鼠标界大手子，国内外厂商8k轮询的鼠标真的有显著区别吗，好像没看到这方面的测评对比，想要换一个但是囊中羞涩在考虑 6 个帖子 - 4 位参与者 阅读完整话题
开到max简单用了一下好像没有什么显著提升？都说蒸馏了很多模型，不知道蒸了这么多，现在的世界知识和哈吉米3.1pro比起来怎么样呢 4 个帖子 - 3 位参与者 阅读完整话题
SK海力士发布了一项名为“iHBM”的控温散热存储技术。 该技术的核心在于其新开发的冷却元件“ICE”，这是一种采用绝缘、高导热性硅基材料制成的元件。 传统的HBM产品主要依靠热量经由核心芯片向外传导的间接散热方式，而iHBM则直接将ICE嵌入发热最集中的D2D PHY区域，为该区域构建专用的热量排出通道。 相比传统方案， iHBM的热阻降低了30%以上，在高温、高负载等严苛环境中，产品运行的稳定性得到有效保障。 在量产可行性方面，iHBM采用了已在市场中广泛验证的先进MR-MUF晶圆级封装工艺，能够实现规模化稳定量产。 此外，该技术与客户现有的系统级封装环境具备较高的设计兼容性，客户无需进行大规模设计改动即可直接部署，从而有效降低了实际导入的技术门槛。 SK海力士计划将iHBM技术应用于HBM5等下一代产品中，以满足高性能计算及AI数据中心等超高集成度、高带宽应用场景下的散热管理需求。 查看评论
近期迹象表明，人工智能公司 Anthropic 正显著加速其模型 Claude Mythos 的部署步伐，并有望将其推向更广泛的用户群体。 根据最新的 Project Glasswing 更新显示，Mythos 模型目前已开始为包括开源项目在内的更广泛组织提供安全防护支持。这与 Anthropic 此前将 Mythos 严格限制使用的初衷相比，是一个重大的战略转变。 Anthropic 在更新中明确表示： 在开发出所需的更强有力保护措施后，我们期待通过公开发布的方式提供 Mythos 级别的模型。 据悉，Mythos 模型的痕迹近期已出现在 Google Cloud 和 AWS 的漏洞发现项目中。此外，在 Claude 的用户界面中，部分用户已经能够看到标有“Mythos 1”预览版（claude-mythos-1-preview）的选项，且源代码中也出现了明确指向 Claude Code 和 Claude Security 的相关接口字符串。 在推进安全模型的同时，有消息称 Claude Opus 4.8 目前正处于开发后期。据了解，部分核心合作伙伴已开始进行内部评估。考虑到 Opus 4.7 在今年 4 月发布的节奏，Opus 4.8 极有可能在未来几周内正式亮相，并与 Mythos 及安全工具的更新形成协同效应，进一步巩固 Anthropic 在模型性能领域的领先地位。 注：尽管近期有用户在界面中捕捉到了 Mythos 1 的身影，但由于当前系统高负载及容量限制，部分功能的访问仍处于间歇性不可用状态。 TestingCatalog AI News – 23 May 26 Anthropic prepares Mythos 1 for Claude Code and Security Anthropic’s Claude Mythos is moving closer to public release as Mythos 1, with new leaked evidence and an updated Claude Security dashboard for Enterprise customers. 19 个帖子 - 17 位参与者 阅读完整话题
如题，chatGPT APP 和 codex APP 有什么显著区别呢？chatGPT主要是对话功能，在codex里也可以对话，是不是codex涵盖了chatGPT的能力 6 个帖子 - 6 位参与者 阅读完整话题
Cursor 介绍 Composer 2.5 · Cursor 相较于 Composer 2，Composer 2.5 在智能和行为表现上都有显著提升，尤其是在长周期智能体任务上。 Cursor Composer 2.5 可用了！ 众所周知 cursor composer 基于 kimi 模型构建的。 我实际使用 cursor auto （composer2.0）也挺好用的， 比 kimi2.6 + claude code 好用 今天 composer2.5 又升级强化了。 cursor auto 的性价比和质量，综合下来比国模套餐划算。还能用 opus gpt 兜底。（偶尔可能会随机到GPT, 那接住你的语气感觉是GPT） 现在我的 AI 组合就是 Cursor + Codex(中转)， claude code 基本放弃了（A\该死,封号，中转也不稳定）。 兜兜转转，又回到 cursor 了。 之前 claude 4.0 左右。掌控力十足，我喜欢一步一步确认，看 cc 完成。它屁才放了一半，我就知道哪里出错了，立马终止和cc说方向不对。感觉问题不大在开自动编辑。 那时候我是船长，cc 是舵手。出了问题我一秒，就能意识到哪里可能出错，让 cc 排查解决。大家都在说降智的时候，我完全没有感觉，只有是推进的感觉。因为我对掌控了全局。 再后来 claude 变强了，慢慢的就放手了，只看结果，不跟过程。慢慢的这种掌控力就不见了,很夸张，这个按钮代码在哪里，表格字段是什么我都不知道。 出问题了AI也搞不定了。要花大半天熟悉代码。 （最恐怖的是，可能读不进去代码，脑子空空，脑雾的感觉，理解速度特别迟钝, 不知道有没有佬有这种感觉） 总之，现在我 auto 用的挺多的， review 不说细看每一行，每个文件我都会过一遍，有个印象，现在掌控力又回来了，感觉不错。 最后如题，不追求机制一次性搞定的模型。 停下来思考一下也是可以的。 强制让你 review ,你就得和 AI 说这不对，那里要如何修改。 这种踩坑能促使你思考，对代码的掌控力也更高。 选择慢下来，也是一个不错的选择。 7 个帖子 - 5 位参与者 阅读完整话题
IT之家 5 月 19 日消息，据首尔经济日报 5 月 18 日报道，三星电子设备解决方案（DS）部门常任顾问、前负责人 Kyung Kye-hyun（庆桂显）预测， 明年下半年起存储芯片价格将开始下跌 ，敦促韩国产业提前做好准备。 庆桂显在韩国首尔的第 285 届 NAEK 论坛上发表了主题演讲，他表示：“中国企业正在积极扩充产能，市场可能从明年下半年或 2028 年上半年开始发生变化，届时内存供应将激增。” 庆桂显预测，随着全球内存扩充产能快速增长，明年下半年内存价格将下降。他说：“如果大型科技公司的资本支出（CAPEX）回报率下降，投资可能会被削减，”他警告说，不仅价格， 甚至内存需求本身也可能在 2028 年后萎缩 。 这位曾领导三星电子半导体业务的专家认为，尽管韩国工业目前在三星电子和 SK 海力士的领导下，通过挖掘大型科技的内存需求实现前所未有的增长， 但必须为繁荣后的时期做好准备 。 他的观点是， 韩国应独立保障先进技术 —— 包括内存、无晶圆厂系统半导体和主权人工智能 —— 并积极应用于现有制造业优势。他补充道：“韩国在硬件和软件方面同时与美国和中国竞争是很困难的。韩国必须做好自己擅长的事情，为此，我们必须认真考虑如何 引入人工智能 。”
Fernando Borretti – 18 May 26 Human Bottlenecks Why AI won't augment human capabilities much. 个人一直认为，ai在对特定行业提升生产力之外，对每个个体来说，最大的用途是用来学习。 这是我在B站下的一个留言，也分享给大家。 15 个帖子 - 14 位参与者 阅读完整话题