Twitter/X · @dotey · 10月12日 00:11 UTC · 喜欢 17 · 转发 0 · 回复 11 · 浏览 5759
Codex 默认上下文以前大约是 200k 到 300k 之间，现在变成 500k 了，可以减少压缩频度；最大上下文长度可以到 1M
从 31 条内容中筛选出 8 条重要资讯。
- Karpathy 指出对 LLM 能力理解的差距正在扩大 ⭐️ 8.3/10
- 陶哲轩的数学 2.0：AI 在数学中的作用 ⭐️ 8.0/10
- 通行密钥是陷阱：对安全性与可用性的批判性审视 ⭐️ 8.0/10
- Google 试点 AI 辅助“代码理解”技术面试 ⭐️ 8.0/10
- 开发者用 REA 和 Claude Code 逆向 Claude Slides 编辑器 ⭐️ 8.0/10
- GPT-6.1 Sol 在 Codex 与 Work 中默认上下文长度提升至 500k ⭐️ 7.3/10
- AI 智能体耗用 5000 亿令牌反编译第一人称射击游戏 ⭐️ 7.0/10
- 开发者用 REA 发现 Codex 中隐藏的 OpenAI 标注 API ⭐️ 7.0/10
Karpathy 指出对 LLM 能力理解的差距正在扩大 ⭐️ 8.3/10
Andrej Karpathy 在 Twitter 上发帖讨论对 LLM 能力共同理解的差距正在扩大，引发了 347 条评论的辩论。讨论聚焦于精通 AI 的用户与普通公众之间对 AI 现实影响的认知分歧。 这凸显了一个关键的社会问题：随着 AI 能力快速进步，普通公众的理解滞后，可能导致不切实际的期望或错误的恐惧。它强调了提高 AI 素养和沟通以弥合这一差距的必要性，影响政策、教育和技术采用。 Karpathy 的帖子据称包含粗略估算，约 60 亿人（约 75%的人口）几乎没有接触过 LLM。讨论还涉及那些审查代码并对 LLM 错误保持警惕的人与那些不审查代码就信任 AI 输出的人之间的分歧。
hackernews · albertzeyer · 10月11日 20:20 · 社区讨论 · 3 个来源
核验: 多源印证
背景: 像 GPT-4 这样的 LLM（大型语言模型）在文本生成、编码和推理方面表现出色，但它们对日常生活的实际影响仍然不均衡。NVIDIA 的 Terminal-Bench 2.0 等研究揭示了实际任务中的显著能力差距，表明 LLM 在某些领域表现出色但在其他领域失败。这种感知能力与实际能力之间的差异加剧了 Karpathy 所指出的理解差距。
参考链接
社区讨论: 社区评论反映了怀疑与赞同的混合。一些用户认为 AI 没有改善普通人的生活，甚至可能使其恶化，列举了汽车、洗碗机未变以及成本上升。其他人质疑 75%数字的准确性，指出人们可能在社交媒体上不知不觉地遇到 AI 生成的内容。还存在分歧：一方强调需要代码审查并对 LLM 错误保持警惕，另一方则盲目信任 AI 输出。
标签: #AI, #LLM, #capability gap, #social impact, #tech analysis
陶哲轩的数学 2.0：AI 在数学中的作用 ⭐️ 8.0/10
陶哲轩的“数学 2.0”幻灯片概述了数学的未来愿景，即利用 AI 工具来维持数学社区，与当前强调 AI 自动解决开放问题的做法形成对比。这是对 OpenAI 发布数百个 AI 生成的开放数学问题解决方案的回应。 这一讨论意义重大，因为它涉及 AI 对数学研究的变革性影响，可能重塑数学家的研究方式以及何为进展。它还引发了关于 AI 在医学等领域可靠性的更广泛辩论，影响跨学科的研究人员和从业者。 幻灯片提到 OpenAI 发布了超过 370 个开放问题的结果，平均每个问题解决时间为三小时。陶哲轩的“数学 2.0”愿景强调利用 AI 来维持数学社区，而非仅仅自动化问题解决，并强调需要对理论“代码库”进行优雅的补充。
hackernews · Anon84 · 10月11日 13:16 · 社区讨论
核验: 多源印证
背景: 陶哲轩是著名数学家，他的“数学 2.0”演讲回应了近期 AI 模型（如 OpenAI 未发布的先进模型）解决众多开放数学问题的事件。这引发了关于数学研究未来的讨论，一些人将 AI 视为进步的工具，而另一些人则担心其对人类数学家以及医学等 AI 可靠性受到质疑的领域的影响。
参考链接
社区讨论: 社区评论对陶哲轩在其领域之外的权威性表示怀疑，特别是在 AI 在医学中的应用方面，例如麻醉机制尚未完全理解。其他人则讨论当 AI 解决数学家多年研究的问题时带来的情感冲击，一些人用软件术语解读陶的观点，强调需要优雅的理论扩展。
标签: #AI in Mathematics, #Terence Tao, #Research Impact, #AI Tools, #Scientific Computing
通行密钥是陷阱：对安全性与可用性的批判性审视 ⭐️ 8.0/10
一篇详细文章认为，尽管通行密钥被宣传为密码的安全替代品，但它们存在显著的安全和可用性缺陷。文章指出了平台锁定、可能永久锁定以及登录时无法追溯要求证明等问题。 这很重要，因为通行密钥正被各大平台广泛采用，理解其权衡对开发者和用户至关重要。这场辩论影响着认证标准的演进，以及通行密钥是否真正兑现其更好安全性和可用性的承诺。 文章指出，证明只能在注册时要求，登录时无法追溯，且浏览器会提示用户授权，许多网站可能不会强制执行。文章还指出，通行密钥是域绑定的，能抵抗中间人攻击，但这一点在批评中常被忽视。
hackernews · laurex · 10月11日 21:59 · 社区讨论
核验: 多源印证
背景: 通行密钥基于公钥密码学，私钥存储在用户设备上，公钥存储在服务器上。它们旨在取代密码并减少网络钓鱼，但关于可移植性、设备丢失和用户控制的担忧已被提出。WebAuthn 标准是通行密钥的基础，不同平台的实现各不相同。
参考链接
社区讨论: Hacker News 的讨论显示出复杂的情绪：一些用户担心可移植性和设备丢失，而另一些人则认为在 Bitwarden 或 1Password 等灵活密码管理器中使用通行密钥仍能保留用户控制。一位评论者指出，证明只能在注册时进行，并怀疑大型网站是否会强制执行。另一位评论者强调，文章的附录承认遗漏了域绑定这一关键安全特性，该特性可缓解中间人攻击。
标签: #passkeys, #authentication, #security, #web standards, #usability
Google 试点 AI 辅助“代码理解”技术面试 ⭐️ 8.0/10
Google 正在软件工程师面试中试点全新的“代码理解”（Code Comprehension）环节，允许候选人使用 Gemini 来阅读、调试和优化现成代码。该消息最初由 Business Insider 在 5 月依据内部文件披露，试点计划于 2026 年下半年在美国的少量团队中启动。 这标志着大厂招聘的重要转变，意味着 AI 协作能力正变得与纯编码能力同等重要。据报道 Meta 也在试点类似的 AI 辅助面试，这一趋势可能重塑整个行业工程师备考和参加技术面试的方式。 试点仅针对初级到中级岗位，只在美国的部分团队进行，Google Cloud 和平台与设备部门率先参与。面试官将评估候选人的“AI 熟练度”，包括提示词编写、AI 输出验证和调试能力——但网上流传的许多具体细节（200-500 行代码、CoderPad、60 分钟时限）尚未得到 Google 官方确认。
twitter · 宝玉 · 10月11日 21:59
核验: 多源印证
背景: 传统 Google 编码面试要求候选人在在线编辑器中从零编写算法题，即程序员常说的“LeetCode 式”面试。新的“代码理解”环节反其道而行——候选人拿到他人编写的代码，需要理解、调试和优化，这反映了开发者越来越多地与 AI 生成和继承的代码库打交道的现实。Gemini 是 Google 的 AI 助手系列，其中 Gemini Code Assist 和 Gemini CLI 等工具将 AI 编码能力直接带入开发者工作流。
参考链接
社区讨论: 社区反应总体积极，Yuchen Jin（@Yuchenj_UW）表示“AI 终结了 LeetCode 面试”，指出即使是 10 亿参数的 LLM 也能一次性解决所有 LeetCode 难题，他现在转而测试候选人如何使用 AI。这一观点反映了部分工程师对摆脱记忆型算法测试、转向更贴近实际的 AI 协作评估方式的广泛热情。
标签: #AI面试, #软件工程招聘, #Google, #行业趋势
开发者用 REA 和 Claude Code 逆向 Claude Slides 编辑器 ⭐️ 8.0/10
开发者@dotey 分享了一个实用工作流，使用开源工具 REA 和 Claude Code 5.5 逆向 Claude Slides 编辑器，实现了几乎完整的功能。该方法包括下载编辑器的脚本和样式表，使用 REA 去混淆代码，然后用 Claude Code 重写以获得结构良好、类型完整的代码。 这展示了一种强大的 AI 辅助逆向工程方法，可以帮助开发者在没有源代码的情况下复制或理解复杂的 Web 应用。它凸显了 AI 编程智能体处理实际逆向工程任务的能力日益增强，可能降低工具开发和定制的门槛。 开发者没有直接逆向提示词，而是让 Claude 创建一个与原始质量相当的 slides 技能，从而获得功能等效的提示词。完整代码可在 GitHub（github.com/JimLiu/baocut）上获取。该工作流使用 REA，它与 Claude Code、Codex 和 Cursor 集成，并利用 Ghidra、IDA Pro 和 Hopper 进行分析。
twitter · 宝玉 · 10月11日 05:18
核验: 多源印证
背景: REA（Reverse Engineer Anything）是一个开源工具，将 AI 编程智能体连接到 Ghidra、IDA Pro 和 Hopper 等逆向工程工具，使其能够检查没有源代码的软件。Claude Slides 是一项允许用户在浏览器中创建和编辑演示文稿的功能，付费计划提供实时编辑器。开发者的方法结合了自动去混淆和 AI 驱动的代码重写，以生成可维护的代码。
参考链接
社区讨论: 社区评论称赞了该工作流，一位用户认为第 3 步（使用 REA 去混淆）最有价值，并建议同时提取网络请求/API 契约，以避免遗漏服务端逻辑。另一位评论者强调第 5 步（重写）是关键，建议在重写前增加一个中间步骤，输出模块依赖图和接口清单，以保留边界情况。
标签: #AI agents, #reverse engineering, #Claude Code, #REA, #developer tools
GPT-6.1 Sol 在 Codex 与 Work 中默认上下文长度提升至 500k ⭐️ 7.3/10
Tibo 宣布，通过 Codex 和 Work 使用 GPT-6.1 Sol 时，默认上下文长度已从 272k 提升至 500k tokens，增幅约 80%。最大上下文长度仍为 1M tokens，用户仍可覆盖默认设置。 此次更新通过减少上下文压缩的频率，显著提升了开发者体验，这对于需要长时间保持大量上下文和细节的任务至关重要。它使 GPT-6.1 Sol 成为复杂、长期开发任务的更强选择，可能影响开发者工具的选择。 新的 500k tokens 默认值经过仔细测试，被描述为大多数用户的新最佳平衡点。最大上下文长度仍为 1M tokens，用户可以根据需要覆盖默认值，设置更高或更低的值。
twitter · Tibo · 10月11日 23:45 · 中文阅读 · 2 个来源
核验: 多源印证
背景: 上下文长度指模型一次能处理的 token 数量。更长的上下文允许模型处理更大的文档或对话而不丢失信息。上下文压缩是一种将对话较早部分总结以释放空间的技术，但可能导致细节丢失。增加默认上下文长度减少了对压缩的需求，保留了更多细节。
参考链接
社区讨论: 未提供社区评论，因此无法总结观点。
标签: #GPT-6.1, #上下文长度, #Codex, #开发者工具, #AI产品更新
AI 智能体耗用 5000 亿令牌反编译第一人称射击游戏 ⭐️ 7.0/10
博主 momo5502 开展实验，利用 LLM 智能体消耗 5000 亿 Luna 令牌，将 2009 年的第一人称射击游戏（《使命召唤：现代战争 2》）反编译为 C 代码，目标是逐字节相同的汇编输出而非仅功能等价。因商标下架请求，相关源码后已被移除。 该实验凸显了使用 AI 进行逐字节匹配反编译的巨额令牌成本，同时展示了功能等价方法大幅降低成本的潜力。它还引发了对法律边界的关注，因为反编译商业游戏可能面临商标和版权下架风险。 该反编译目标是逐字节完全相同的汇编输出，迫使智能体反复尝试编译器版本、优化选项等变量，使令牌消耗比功能等价方法高出 10-100 倍。评论者还指出，改用能力更强的模型（如 Sol 6.1）而非 Sonnet，虽单令牌成本更高，但逆向工程效果可能好 100 倍。
hackernews · davikr · 10月11日 02:02 · 社区讨论
核验: 多源印证
背景: 反编译是一种逆向工程，从编译后的二进制文件恢复源代码或接近原始代码的表示，本质上执行与编译器相反的操作。功能等价指两个程序在计算输出上相同，但不要求逐字节匹配，这对 AI 智能体而言是成本低得多的目标。本次实验追求完全相同的汇编输出，要求更为严格，从而极大增加了令牌消耗。
社区讨论: 社区评论强调，5000 亿令牌的消耗对一个有趣的小项目来说过于巨大，其碳排放量约相当于 15 次旧金山-伦敦往返航班。多位评论者认为，以功能等价为目标而非逐字节匹配，可将成本降低 10-100 倍，而选择更智能的模型（如 Sol 6.1）则能获得更好效果。一位评论者还指出该游戏是 2009 年的《使命召唤：现代战争 2》，并提到相关帖子此前已被下架。
标签: #AI agents, #decompilation, #LLM efficiency, #code generation, #developer tools
开发者用 REA 发现 Codex 中隐藏的 OpenAI 标注 API ⭐️ 7.0/10
一位开发者演示了如何使用 REA 工具分析 Codex 内置浏览器中标注和评论提交的实现方式，而无需反编译代码。分析发现了一个未公开的 OpenAI API——document.oai.annotation.request()，它允许以编程方式向输入框注入内容。 这一发现对 AI 开发者工具爱好者意义重大，因为它揭示了一个隐藏的功能，可能实现与 Codex 和 ChatGPT 的自定义集成和自动化。同时，它也展示了一种实用的 REA 工作流，可用于逆向分析其他软件行为，可能加速开发和定制。 开发者使用 REA 检查了 Electron 应用的源代码，并找到了关键代码路径，期间用户通过发送消息进行配合。该 API——document.oai.annotation.request()——可以弹出标注对话框并预填充内容，但不能直接向输入框附加评论。开发者还分析了 Cursor 和 Claude Code，但它们不支持此 API。
twitter · 宝玉 · 10月11日 22:53
核验: 多源印证
背景: REA 是一个用 TypeScript 编写的开源（MIT）工具，为 AI 编码代理提供了一种一致的方式来调查软件，从而实现无需大量手动工作的逆向工程。Codex 是一个 AI 编码代理，包含内置浏览器和标注功能，允许用户直观地标记元素并提交反馈。发现的 API 是 OpenAI 浏览器标注可扩展性的一部分，允许网站触发标注请求，但需要用户许可，且不会自动发送消息。
参考链接
社区讨论: 社区讨论（28 条回复）可能包括对这一发现的反应，一些用户对 REA 工作流和隐藏 API 表示兴趣，而其他人可能讨论限制或潜在用例。由于没有具体评论，情绪似乎是积极和好奇的，关注自动化和集成的实际影响。
标签: #Codex, #REA, #OpenAI API, #AI agents, #reverse engineering
更多追踪内容
以下内容已于今日成功抓取，但未进入上方主列表。
其他追踪推文
Twitter/X · @dotey · 10月11日 22:41 UTC · 喜欢 100 · 转发 15 · 回复 24 · 浏览 19667
丰田的老规矩：改善省出的人手，不能拿去裁
日本博主“黔騎士”发了一条推文 https://t.co/gbkvfLDORn ，核心观点是：AI 一提效就裁员的公司，员工再也不会主动琢磨怎么用好 AI。
他拿丰田举例。丰田当年把“改善”（Kaizen，一线员工持续提小建议、优化流程的做法）推广到海外时，讲师反复强调一条铁律：
“流程改善后工时减少了，也绝对不能因此裁人。”
因为如果提建议的结果是自己或同事丢了饭碗，现场就再也不会有人提建议。
他认为 AI 导入是同一个道理。效率一上去就砍人力成本，员工就会把用 AI 的好点子藏起来。
反过来，把省出的时间用来想更有意思的企划、多花时间陪客户、学新技能，现场才会越用越多。在他看来，能把公司文化往这个方向转的企业，才能在 AI 时代把一线的智慧收上来。
Twitter/X · @dotey · 10月11日 21:51 UTC · 喜欢 236 · 转发 23 · 回复 37 · 浏览 33087
Andrej Karpathy 说，人们对 AI 能力的理解差距在扩大，这种认知差距正在变成一个漏斗。
约 60 亿人几乎没接触过大模型；10 亿到 20 亿人偶尔用免费版 ChatGPT 查东西、写东西，觉得用处不大，很多数学和编程以外的专业人士也在这一层，对 AI 的进步只是道理上懂。
约 2000 万人（Karpathy 按 0.2% 估算的，我觉得偏高，至少除以 10）在编程和数学里重度使用最前沿的模型，亲眼看着要做几周、几个月的项目，一段提示词发给 Agent 几天就能做完；还有约 5000 人能在公司内部用上更强的系统。
差距主要有三个原因：
一是问题够不够大，一段话就能答完的问题用不到 AI 的真本事。
二是能力只在部分领域冒尖：编程和数学的结果能自动验证，比如代码测试通没通过，模型很适合用强化学习（做对了就给奖励）来练，这类能力卖给企业又最赚钱，厂商投入最多；文章写得好不好很难判定，进步就慢。
三是能用到哪一档，免费版、付费版、内部版看到的东西差别很大。
所以，如果你只偶尔问问免费的聊天机器人，看到的离最前沿差了好几层；如果你主要拿 AI 写东西、查资料，觉得这一年没怎么进步，这个感觉也没错。
Twitter/X · @dotey · 10月11日 19:12 UTC · 喜欢 20364 · 转发 2556 · 回复 895 · 浏览 1682306
Dusting off this tweet from April because this gap in shared understanding of LLM capability is *widening*. It's now less "two groups of people speaking past each other" and more a sharp funnel.
- Napkin math somewhere around 6B people (~75% of the population) have barely come in contact with LLMs at all.
- Around 1-2B (~20%) are casual and infrequent users of free-tier ChatGPT-like products. This group sees derpy chatbots and treats them a bit like a better Google search, a writing aid, or etc. Maybe an agent tries to book you a flight. I have non-tech friends who (reasonably, imo) say they have not much use for it at all. Even many professionals outside of math&code are in this tier. For example, execs and many other functions spend a lot of their time talking to other people, so while they understand what is happening intellectually, it is still second-hand and a bit abstract.
- Now we get to professional use of frontier-grade LLMs in math&code. Somewhere around 20M people (0.2%) see first-hand that large, complex projects that used to take them weeks/months can now be completed by agents with a prompt. Building apps, copying apps, translating apps, decompiling apps from binaries... This has all happened very quickly and recently - less than 1 year ago, I was writing code manually by hand, typing memorized computer code commands into a code editor character by character, occasionally pressing Tab to autocomplete a little chunk of code.
- And finally we get to the ~5,000 people (~0.00006%) with access to frontier-grade systems internally. The external world has seen the preview. It looks like swarms of thousands of agents collaborating over weeks on software mega projects: minting zero days, running cyber attacks and defenses at machine speeds, discovering new science, advancing the frontier of mathematics. Things that would have taken top professionals in the industry years of work. Meanwhile, human review and comprehension are starting to fall behind. For example, people are still involved in the "archeology" of the OpenAI-HF incident from many months ago. Mathematicians may be poring over the 722 manuscripts on frontier mathematics for a while.
The funnel is driven by a combination of factors:
1. The impact scales with ambition, problem size, and horizon. A question with a paragraph answer barely stresses the system. You need a reservoir of big, difficult problems that you really care about. This aspect drives the consumer / professional dimension of the funnel.
2. The jaggedness of the system (which I have written about a lot separately). Capability peaks in domains that are digital, verifiable and economically valuable. This is because LLM capability emerges from reinforcement learning on verifiable rewards on a curated environment mixture driven by revenue potential. This aspect primarily drives the area (e.g. math&code) dimension of the funnel.
3. Access. Free-tier, paid-tier, internal.
So this is the weirdness of the moment. The general public has mostly not interacted with these systems. When they have, it looks like a derpy chatbot. The majority of professionals still see only a modest uplift. And a small sliver of professionals are experiencing the vertigo of the curve going vertical. And it is all happening at the same time.
Twitter/X · @dotey · 10月11日 17:37 UTC · 喜欢 957 · 转发 43 · 回复 83 · 浏览 42149
I'm so glad AI killed LeetCode interviews.
Google popularized LeetCode-style coding interviews ~20 years ago. Today, even a 1B LLM can one-shot all LeetCode Hard problems.
I dropped LeetCode interviews years ago. Now I test how well candidates can use AI.
Twitter/X · @dotey · 10月11日 13:36 UTC · 喜欢 27 · 转发 2 · 回复 4 · 浏览 16770
AI 提效之后，别急着把人裁掉
这一段关于丰田“持续改善”的讨论。
大意是，员工通过改进工作方式减少了工时，公司不应该立刻因此裁员。否则，下一次，一线员工就不会再主动告诉你，哪里还可以改进。
发帖的人把这个道理延伸到了 AI：如果员工每找到一种提效方法，得到的回应都是团队缩编，那么公司迟早会发现，大家依然在用 AI，却不再愿意分享自己是怎么用的。
那么问题来了：
如果改进工作的结果，是让改进者承担失业风险，我们凭什么期待他们持续贡献自己的经验和创造力？
AI 能不能提高效率，是技术问题。提高效率之后，员工愿不愿意继续和公司合作，则取决于另一套规则。
丰田在介绍其生产方式时，明确把“让员工的工作更容易”作为前提，并强调全体员工在日常工作中持续进行小步改善。这里的改善，既追求效率，也指向工作本身的改进。
企业要消除的是浪费，而不应该让消除浪费的人觉得，自己才是那个被消除的对象。
设想一个软件团队。
某位开发者花了不少时间，把一类原本需要三天完成的工作，改造成半天就能跑完的 AI 工作流。他整理了上下文，补充了测试，记录了常见错误，也愿意把方法分享给其他人。
管理者可以说：这套方法值得推广，你来带着团队继续完善，我们也终于有机会处理那些长期积压的问题。
管理者也可以说：既然这部分工作不需要那么多人了，我们重新评估一下团队编制。
第二种回应未必会让员工停止使用 AI，却可能让他们停止公开自己的真实效率。
自己用，但不说节省了多少时间；按时交付，但不主动分享整套方法；愿意提升个人能力，却不愿意再帮助公司拆解哪些岗位可以被替代。
在这种情境里，把员工简单归类为“思想保守”“抵制变革”，恐怕没有抓住问题。
他不是看不到技术的价值。恰恰相反，他看得很清楚，也在认真计算这份价值最终会落到谁的手里。
DORA 关于生成式 AI 与软件开发的研究也提供了一个相关观察：采取措施回应员工就业顾虑的组织，其团队 AI 采用程度更高。这是关联性发现，不能推出“不裁员就一定转型成功”，但至少提醒我们，就业预期并不是技术推广之外的题外话。
因此，企业在讨论 AI 使用率时，应该把两个问题分开。
一个是，员工有没有使用 AI。
另一个是，员工愿不愿意把自己摸索出来的方法，变成整个组织都能使用的能力。
买账号、办培训，可以帮助解决前一个问题。后一个问题，需要员工相信分享是值得的。
当一个人帮助公司减少了对自己的依赖，公司准备怎样评价他的贡献？
如果答案只是“既然不再依赖你，你就不重要了”，那么公司实际上是在鼓励员工保留那些只有自己才能处理的环节。
相反，越愿意消除个人依赖、把经验变成公共能力的人，越应该获得相应的认可和机会。
这不是要求公司永久保留某个岗位，而是要承认：让组织不必每次都依赖自己，是一种贡献，不是没有贡献的证明。
我一直在讨论一个变化：开发者的工作，可以从直接编写软件，转向为 Agent 构建软件生产线。
我把这样的角色称为 Builder。
在这个视角下，开发者的任务不只是让 AI 生成代码，还包括定义目标、组织上下文、设计约束、建立验证方式，以及让整个流程能够持续、可靠地运行。
这也意味着，评价开发者的方式需要跟着改变。
假设一个人搭建的工作流，让整个团队减少了重复操作和返工。他亲手写的代码可能变少了，但他对交付结果的贡献，未必变小。
如果公司仍然只通过代码量、任务数量、在线时长来判断价值，就可能出现一个荒谬的结果：一个人把工作方式改进得越好，越需要额外证明自己没有闲着。
更何况，某个环节提速，并不能直接推出团队可以按相同比例缩编。
代码生成快了，需求是否清楚、验证是否充分、上线是否可靠，仍然需要分别判断。2025 年 DORA 报告观察到，AI 采用与软件交付吞吐量改善存在正向关系，但与交付稳定性的关系仍然为负；报告强调，AI 的收益取决于它所处的工作系统，而不只是工具本身。
我的理解是，提效之后首先应该做的，是重新检查整个交付过程，看看瓶颈去了哪里，而不是只盯着原来的编码环节少用了多少时间。
比如在一条 Rust 软件生产线里，我会希望编译诊断、测试结果和运行反馈都能进入 Agent 的修正流程。但即便编译和测试通过，我也不会据此宣布业务需求已经全部满足。验收标准和证据覆盖到哪里，信任才能走到哪里。
这些工作需要有人设计，也需要有人维护。
当然，并不是给每个人换上 Builder 的头衔，就自动完成了转型。公司还要提供相应的时间、权限、培训和评价方式。
不能一边要求员工构建新的生产系统，一边仍然按照旧流水线上的忙碌程度给他们打分。
原帖提出，节省出来的时间应该用于“创造下一份价值”。
我赞同这个方向，但这句话同样需要警惕。
它不能变成另一种说法：既然 AI 已经帮你做完原来的工作，请你马上找到更大的价值，否则就证明你没有必要留下。
好的 AI 转型，应该让员工愿意淘汰低效的工作方式，而不是为了避免自己被淘汰，被迫保护低效。
Twitter/X · @op7418 · 10月11日 05:49 UTC · 喜欢 40 · 转发 3 · 回复 24 · 浏览 9455
Next Token 上周的观察，再次领先国内其他媒体
关于“一切都会被开源”和“游戏破解”这事，我们在前几天的播客里就非常详细地讨论过，今天突然就火了。
业内的人还是可以多看看我们聊的这些东西。
总结一下我们在播客里面的观点。 https://t.co/WxBbJKUOWD
@op7418: 重置了
1.0Twitter/X · @op7418 · 10月11日 02:01 UTC · 喜欢 12 · 转发 0 · 回复 30 · 浏览 14588
重置了
其他 Follow Builders 资讯
中文标题Thibault Sottiaux：专业用户，你们更希望拥有……
Follow Builders · X 动态 · Thibault Sottiaux · 10月11日 05:22 UTC · 喜欢 1235 · 转发 102 · 回复 1621
An incomplete poll question asking professional users about their preference, with high engagement but no specific technical content.
中文摘要这是一个不完整的调查问题，询问专业用户的偏好，虽然互动量高，但缺乏具体技术内容。
中文标题Thibault Sottiaux：把重置放回包里。全部传播。
Follow Builders · X 动态 · Thibault Sottiaux · 10月11日 04:01 UTC · 喜欢 4203 · 转发 190 · 回复 612
A cryptic tweet with no substantive information, just a link and a vague statement.
中文摘要一条没有实质内容的隐晦推文，仅包含链接和模糊陈述。
中文标题彼得·杨：确实出了问题
Follow Builders · X 动态 · Peter Yang · 10月11日 02:23 UTC · 喜欢 6 · 转发 0 · 回复 7
A cryptic tweet by Peter Yang with no substantive content.
中文摘要彼得·杨发布的一条内容模糊、缺乏实质信息的推文。
中文标题Thibault Sottiaux：当我们达到完美的那一天，一切将从那里重置
Follow Builders · X 动态 · Thibault Sottiaux · 10月11日 01:13 UTC · 喜欢 4085 · 转发 99 · 回复 652
A brief philosophical tweet suggesting that reaching perfection will lead to a reset, with no technical or practical substance.
中文摘要一条简短的哲学推文，暗示达到完美将导致重置，缺乏技术或实用内容。
中文标题Zara Zhang：代码是创意自我表达的新媒介
Follow Builders · X 动态 · Zara Zhang · 10月11日 01:04 UTC · 喜欢 74 · 转发 4 · 回复 10
A short post asserting that code has become a new medium for creative self-expression, with no additional context or technical detail.
中文摘要一条简短推文，主张代码已成为创意自我表达的新媒介，但未提供更多背景或技术细节。