https://www.gcores.com/articles/157189 孩子不懂随便看的

Merry Christmas

Codex is so so good at finding bugs and little inconsistencies. Where Claude Code is good at "raw coding"

感觉 Claude Code 写新功能，然后 Cursor 的 Agent Review + GPT 5.2 检查代码是最佳搭配

Anthropic公司最近干了一件挺事，他们把研究对象对准了自己，调查了132位公司内部工程师和研究人员，做了53次深度访谈。 目的就是为了想搞清楚一个问题：AI到底是怎么改变他们自己工作的？ 这个视角很特别。 因为他们的今天，可能就是很多行业的明天。 这份报告读完，我感受到的不是恐慌，而是一种很复杂的情绪。 从数据上来看，一年前，这些工程师在日常工作中使用Claude的比例是28%，觉得效率提升了20%左右。 现在，使用比例到了59%，效率提升感知涨到了50%。 相当于一年时间，两个指标都翻了一倍多。 但有趣的是效率提升的具体表现。 你以为是同样的活儿干得更快了对吧？不完全是。 调查发现，在各类任务上，时间节省其实没那么夸张，但产出量的增加非常明显。 而且27%的Claude辅助工作，是那些一直想做但优先级不够高的事情。 比如给代码写更完善的文档，比如做一些提升工作体验的小工具，比如重构那些虽然能跑但结构很烂的代码。 但人人都在变成全栈，代价是什么？ 一个后端工程师描述了他用Claude做UI的经历。 他说设计师看到成品的时候惊了，问他这是你做的？ 他回答说不是，是Claude做的，我只是指挥了一下。 这听起来很美好，每个人都变成了多面手，原来不敢碰的东西现在敢碰了。 但报告里有一个词让我印象很深：skill atrophy，技能萎缩。 一位工程师说，他以前自己去调试一个难题，虽然花时间，但会顺便读很多文档和代码。 这些东西当时看起来跟问题没关系，但其实你一直在构建对整个系统的理解。 现在Claude直接帮你定位问题了，这种附带学习就没了。 有些困难是学习过程中必须经历的，绕过它你虽然省了时间，但也错过了真正的成长。 这里有一个很微妙的矛盾。 现在的AI还不能完全信任，你需要监督它的输出，尤其是在重要的工作上。 但监督AI的能力，恰恰来自于你自己动手干活积累的经验。 一位安全工程师举了个例子，Claude给出的某个方案看起来很聪明，但他一眼就看出这是那种聪明过头的危险方案，是资深人士才能识别的陷阱。 他说这种判断力，只有做过很多年才有。 如果新人从一开始就依赖AI，他们怎么培养这种判断力？ 报告里把这叫做paradox of supervision，监督悖论。 你越用AI，你监督AI的能力可能越弱。但你越不用AI，你的效率又跟不上。 这个困境目前没有标准答案，有些工程师的应对策略是刻意练习。 就算知道Claude能搞定，偶尔也强迫自己不用它，保持手感。 报告的结尾，抛出了一个有意思的视角。 软件工程一直在朝更高抽象层次发展。 最早的程序员要手动管理内存，要写汇编语言，甚至要用物理开关输入指令，后来有了高级语言，很多底层操作自动化了。 一位员工建议想当工程师的人：学会让AI写代码，然后把精力放在更高层面的概念和模式上。 这个建议有道理，但也有人指出，每一次抽象层级的提升都有代价。 当大家都用高级语言之后，大多数程序员就不再深入理解内存管理了。这种丢失的知识，有时候在关键时刻会变成问题。 读完这份报告，我总结了几条对普通人有用的insight： 1、效率提升的红利期是真实的，但那些被省下来的时间，要有意识地投入到AI还做不好的事情上。比如建立人际关系，比如发展判断力，比如理解系统的底层逻辑。 2、刻意保持一些不用AI的练习，因为你需要保持监督AI的能力。 3、重新思考工作的意义。如果你的满足感来自于亲手完成某件事，那要想清楚这种满足感以后从哪里来。如果你的满足感来自于结果和影响力，那AI其实是你的加速器。 4、关注人的连接。技术在让协作变得更高效的同时，也在稀释那些低效但有温度的交流。这部分不会自动补回来，需要你主动去维护。 Anthropic这份报告的价值不在于给出答案，而在于它呈现了一种真实的复杂性。 这群站在AI前沿的人，他们既兴奋又焦虑，既享受效率又担心失去什么。他们没有确定的未来图景，只有一种共识：要保持适应能力。 https://web.okjike.com/u/9ca2b1fd-086e-4fbe-a1f8-b641f8f4b9d1/post/6937c2d9b756b2fd2ad2a853

Oxide 公司使用大语言模型（LLM）的核心原则：以责任感（Responsibility）为首要价值，强调人类对 LLM 生成内容承担最终责任，LLM 只是工具，人类判断必须始终在回路中。 - 严谨性（Rigor）：LLM 可辅助思考，但不能替代清晰思维 - 同理心（Empathy）：需考虑读者或作者的人类感受 - 团队协作（Teamwork）：避免 LLM 使用破坏团队信任 - 紧迫性（Urgency）：不能为追求速度牺牲其他价值 LLM 作为阅读者/研究者： 擅长阅读理解和文档摘要，可用于轻量级研究任务。但需注意数据隐私（Data Privacy），确保上传文档不会被用于模型训练；研究结果需验证来源，不可盲目信任。 LLM 作为编辑者 vs 写作者： 作为编辑器效果良好，可在写作后期提供结构和措辞反馈；但作为写作者问题较多——生成内容陈词滥调，破坏真实性和读写之间的社会契约，Oxide 员工应尽量避免用 LLM 写作。 LLM 作为代码工具： - 代码审查（Code Review）：可辅助但不能替代人工审查 - 调试（Debugging）：可作为"橡皮鸭"激发思路 - 编程（Programming）：适合实验性/辅助性代码，核心系统代码需谨慎；LLM 生成代码必须经过自我审查（Self-review）后再提交同行评审 LLM 反模式（Anti-patterns）： - 禁止强制使用 LLM 的行政命令（LLM Mandates） - 禁止将 LLM 拟人化（Anthropomorphization），因其无法承担责任 https://rfd.shared.oxide.computer/rfd/0576

▶️ 许子东重读鲁迅：06《灯下漫笔》 #youtube https://www.youtube.com/watch?v=ebZYk85Acwg

《论 Windows 如何才能作为一个稳定的服务器使用》

Bun 被 Anthropic 收购了 https://x.com/anthropicai/status/1995916269153906915

是啊，然后这个是我今天向别人索要的生日礼物

【中英双语】为 Linux 之父打造最强 Linux 主机！

https://www.youtube.com/watch?v=mfv0V1SxbNA 轻微拼写错误及补充说明与更正： 6:11 处的 "complier" 应拼写为 "compiler" (编译器) 34:50 讨论的是 Intel Arc GPU 的选型 — 这部分在视频中其实没有得到最终解释，因为两位 Linus（T 和 S）当时被其他话题吸引，聊得太投入，最后没有再绕回这个问题。在我们最初的邮件沟通中，Linus T 需要一块独立 GPU 的原因是，他要驱动 2 台 6K 显示器，需要比核显更强的图形输出性能，但又不希望使用高功耗、噪音大、发热高、偏游戏定位的GPU。原定方案是 Intel Arc B50，但我们在拍摄前没能及时拿到，所以最终使用了视频中的这张显卡。Linus T 在拍摄时明确表示：他完全可以接受这张显卡方案，并没有任何不满。抱歉这些内容没有以视频形式呈现，但当时大家聊得太开心了，我们忘了补拍这块的内容。 —— Elijah

@喜乐会会长:

发布视频-计算机技术-电脑 播放量:3.56万 弹幕:323 评论:236 点赞:982 投币:209 收藏:807 转发:322 发布日期:2025-11-30 15:41:32 上传日期:2025-11-30 15:41:33

📖 写在离开 Folo 之后 #article

同样的经历，类似的感受

https://innei.in/posts/experience/after-leaving-folo

想学做饭，从哪些视频博主开始入门 [by 北鸮] https://sspai.com/prime/story/vlogs-for-learning-to-cook

ADHD: Attention is all you need