锤子前端

  1. CSS 技巧:防止布局在滚动条出现时横向跳动

    CSS 技巧:防止布局在滚动条出现时横向跳动。
    #CSS #UX
    html {
      scrollbar-gutter: stable;
    }

    https://x.com/denicmarko/status/2115765989883433445?a=o3joFmAEkpM1zSiEQ0k&s=19 Marko Denic (@denicmarko) on X

  2. 《修复 React 中的 Hydration Mismatch 错误与 UI 闪烁》

    《修复 React 中的 Hydration Mismatch 错误与 UI 闪烁》

    标签:
    #前端开发 #NextJS #HydrationMismatch #LocalStorage #SSR #UI闪烁 #React19

    总结:
    文章以 Next.js 全栈电影应用为例,系统讲解了服务端渲染(SSR)中 Hydration Mismatch 错误的成因与多种修复方案:包括挂载前渲染 null/骨架屏、用 useEffect 读取 localStorage 保持 SSR、用内联脚本在 hydration 前同步状态以避免闪烁,以及 React 19.3 新增的 use(browser()) API。

    文章要点:
    1. Hydration 是水合过程:React 用 SSR 时的同一组件树在客户端内存中重新渲染,并校验其输出与服务端 HTML 是否一致,不一致就报 Hydration Mismatch 错误。
    2. 错误常见诱因是渲染依赖了仅客户端可用的信息,比如 localStorage——服务端拿不到,导致两端输出不同。
    3. 通用解法一:useEffect 中设置 isClient,挂载前返回 null 或骨架屏,保证两端输出一致;代价是真实内容不进服务端 HTML,对 SEO 和大型布局不友好。
    4. 通用解法二:给元素加 suppressHydrationWarning,但它只压警告不修问题,且仅一层有效,不宜滥用。
    5. 在侧边栏场景中,作者改用 useEffect 里读 localStorage 并 setState,先用默认值 false 完成 SSR,挂载后再更新状态,既保留 SSR 又消除不匹配(但会有短暂闪烁)。
    6. 防闪烁的进阶方案:用 dangerouslySetInnerHTML 注入内联脚本,在 hydration 前直接把 localStorage 状态应用到 DOM,并把值挂到 window 上供 React 初始渲染读取,保证脚本和 React 修改同一批 class。
    7. 主题切换用 useIsClient 延迟渲染(官方推荐做法,小控件可接受);移动端遮罩层则用 CSS group-[.left-0]:block 跟随侧边栏 class,避免条件渲染造成的不匹配。
    8. React 19.3 引入的 use(browser()) 可以跳过组件的服务端渲染并留下最近的 <Suspense> 兜底,是 useEffect 方案的替代写法。

    URL:https://www.gmoniava.com/blog/hydration-mismatch-errors-and-how-to-fix-them What Is a Hydration Mismatch Error and How Do You Fix It?

  3. 《设计系统应该默认就是快的》

    《设计系统应该默认就是快的》

    标签:
    #前端开发 #设计系统性能优化 #性能测试 #性能预算 #WebComponents #组件渲染优化

    总结:
    这篇文章通过实测十大主流开源设计系统(Mantine、Ant Design、Material UI、React Spectrum、Carbon、Fluent、Web Awesome、UI5、Spectrum Web Components、Ionic),论证了性能应当与设计系统团队所重视的可达性(accessibility)平起平坐:底层组件的每一个性能修复,都会同时惠及所有基于该设计系统构建的应用。测试发现性能优劣并不取决于框架本身,而在于具体实现细节,作者还深入剖析了 Ionic、Ant Design、UI5、React Spectrum 等慢速组件的根因,并给出了可行的修复建议,最后提供了基于 Playwright 的自动化性能测试方案与「Fast by Default(默认即快)」的理念。

    文章要点:
    1. 浏览器的 JavaScript 主线程是所有层共用的,设计系统组件越慢,留给应用代码的余地就越小——修复一个设计系统组件的性能,等于同时提升所有依赖它的应用。
    2. 作者选取了十个基于不同框架(React、Lit、FAST、Stencil、SAP 自研框架)的设计系统,在 4 倍 CPU 降速、Chrome 155 环境下实测了两大典型场景:打开含 249 个国家的下拉选择器、一次性全选 100 个复选框。
    3. 实测结果差异巨大:国家选择器从最快 Fluent 的 61ms 到最慢 Ionic 的 1,266ms(比第二名慢 5 倍以上);复选框从 Fluent 的 29ms 到 Ant Design 的 421ms——同一框架(如 React 或 Lit)内部差距同样悬殊,性能问题出在实现而非框架。
    4. 十个设计系统中只有 Spectrum Web Components 在每个 PR 上自动跑组件级性能基准,多数团队只检查包体积——但包体积与组件在页面上的响应速度并无直接关系。
    5. 作者逐一剖析了慢速根因:Ionic 因 Stencil 在无 shadow DOM 的场景下用 appendChildSlotFix 模拟插槽、每次新增选项都要遍历全部既有子节点三次(O(n²));React Spectrum 因 React Aria 逐个清空高度再读取尺寸造成「布局抖动」;UI5 因隐藏弹层中预置全部 249 个选项,打开瞬间浏览器要一次性完成约 1500 个元素的样式计算;Ant Design 的慢则主要来自 100 个复选框同时触发的颜色渐变动画。
    6. 性能瓶颈各有解法:长列表用虚拟滚动(Ant Design 的做法值得借鉴,还为屏幕阅读器保留了高亮项的隐藏副本);动画改由合成器线程运行的 opacity 渐变替代主线程上的颜色渐变;Stencil 可直接修复插槽回退内容的第三次检查,作者实测去掉后加 2000 个元素快约 7 倍。
    7. 作者分享了用 Playwright + Chrome DevTools 协议(CPU 降速 4 倍 + Long Animation Frames 长帧 API)编写组件性能测试的完整代码,包含「总耗时预算 300ms」和「最长无响应帧不超过 100ms」两条性能预算(performance budget),以及一条「选项翻倍时耗时增长不超过 2.5 倍」的防 O(n²) 回归测试。
    8. 落地的最佳实践是「默认就提供快的行为」:超过性能预算的列表自动切换虚拟化、复选框仅在被直接点击时才播放动画,并在文档中写明每个组件的测试数据规模上限,发布说明中给出修复前后的量化数据(如「500 个选项下打开从 300ms 降到 150ms」)。
    9. 以上测试代码已开源在 GitHub 仓库 design-system-performance-tests 中,可直接复制改造用于自己的设计系统,并附带 GitHub Actions 工作流实现每个 PR 自动跑性能测试。
    10. 文章结尾宣传了作者的新书《Fast by Default: Practical Performance Engineering》(Manning 早期访问版),把这套思路延伸到后端与移动端。

    URL:https://denodell.com/blog/design-systems-should-be-fast-by-default Design Systems Should Be Fast by Default

  4. 《Uncle Bob 的 ub-mode:给 AI 编程助手装上"纪律开关"》

    《Uncle Bob 的 ub-mode:给 AI 编程助手装上"纪律开关"》

    标签:
    #软件工程 #AI编程辅助 #TDD #代码质量门禁

    总结:
    这是 Robert C. Martin(Uncle Bob)发布的一个 AI 智能体技能(agent skill),用于在 AI 编写或修改代码时强制执行严谨的软件工程纪律。它部分借鉴了 poteto-mode 的规则体系并加以精简,同时配套一组确定性的质量门禁工具(复杂度、重复率、变异测试),让"先让它能工作,再让它正确,最后持续练习"的原则可度量、可落地。

    文章要点:
    1. 核心理念分三层:先让它能工作(懒惰协议、TDD、先减后加、领域建模、边界与类型纪律等),再让它正确(修复根因、测试行为而非实现、持续重构),最后落实到日常练习(记日志、守护上下文窗口、小而有序的提交)。
    2. 规则部分借鉴并精简自 poteto-mode:作者明确说明 ub-mode 是 @poteto 规则集的删减版,与确定性工具搭配使用。
    3. 配套四个质量门禁工具仓库:crapper 计算圈复杂度与 CRAP 分数(要求 CRAP < 10),dryer 检测结构重复(相似度 ≥ 0.8 即需消除),mutator 做变异测试揪出"测试杀不死的活口",uml-viewer 可视化组件、覆盖率与依赖方向。
    4. 安装方式极简:只需把 SKILL.md 复制到所用 AI 工具的 skills 目录(如 /.claude/skills/ub-mode/),然后输入 /ub-mode 即可调用。
    5. 目标很明确:把 Uncle Bob 倡导的软件工艺原则变成 AI 编码时可检查、可强制执行的硬约束,而不是口头建议。

    URL:https://github.com/unclebob/ub-mode GitHub - unclebob/ub-mode

  5. 《把子代理折叠回主循环:Anthropic 谈智能体架构的新取舍》

    《把子代理折叠回主循环:Anthropic 谈智能体架构的新取舍》

    标签:
    #人工智能 #智能体架构 #子代理 #渐进式披露 #单一智能体循环 #评估驱动迁移

    总结:
    这是 Anthropic 应用 AI 团队于 2026 年 10 月 22 日发布的企业智能体架构指南。核心观点是:随着模型能力增强(从 Opus 4.5 开始),许多企业多智能体系统里的路由、规划器和领域子代理其实在替模型做它已经不再需要的"结构性工作",把这些部分折叠回一个主循环(配合 skills + tools 的渐进式披露),往往在质量、成本和延迟上同时更优——但文章并不否定子代理,而是强调用评估驱动、一次只改一处的迁移方式来决定每个子代理的去留。

    文章要点:
    1. 多个企业部署的对比显示,"单智能体 + skills"的设计在质量上经常同时胜过"一个大提示词包揽一切"和"子代理架构"两种方案,且单位任务的成本和延迟更低;有客户测得多智能体框架换成单循环后运行速度约快 2 倍。
    2. 按团队或问题类型划分子代理,会让架构变成组织架构图的复制品(康威定律),并带来五类典型问题:上下文交接丢细节、子代理泛滥无人负责、各团队往系统提示里加规则造成的"缝合怪提示词"(Frankenprompt)、评估各自为政、以及额外延迟。
    3. 单循环能成立靠两点:共享上下文让模型把各步骤结果串联起来,避免"传话游戏"式的层层摘要损耗;渐进式披露(先看到 skills 和 tools 的短描述,用到时才加载全文)消除了过去拆分子代理的主要理由——Anthropic 借此把 Claude Code 高阶模型的系统提示词缩减了 80% 以上。
    4. 推荐的单循环形态是:一个模型、一个上下文窗口跑开放式工具循环,harness 里设好回合与成本预算、写入闸门;模型第一回合就在上下文里写计划并随结果修订——写计划的人和执行计划的人是同一个模型,这是与"编排器 + 专家代理"最大的区别。
    5. 三类子代理应保留:单一循环因上下文膨胀出现可测量的性能退化时;多个任务需要并行处理、用完即弃的独立上下文时;单个智能体难以选对工具或系统提示中存在相互冲突的指令时。若保留,优先让主循环把它当工具调用,只有需要直接与用户对话时才做完整交接。
    6. 迁移路径分三步走:先建一个中央团队维护的端到端评估集(10 条黄金样本即可起步);从使用最多、上下文耦合最强的子代理开始合并;其余逐个折叠成 skills + tools,每次只改一处、用 hillclimb 对比"折叠前后"的表现再决定去留。
    7. 配套工具已就绪:Claude API 提供 build-eval、prompt-audit、hillclimb、cost-optimize 等技能,并随附迁移套件(含可在模拟系统上试跑的演示),GitHub 上还有 Apache-2.0 的参考实现 single-agent-loop-kit。
    8. 文章的落脚点是一个原则而非某种架构:持续测量、一次只改一件事、只保留经得起评估检验的部分——模型越强、循环越长,越多的子代理可以被 skills 和 tools 吸收。

    URL:https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop Building agents: When to fold subagents into your main agent loop

  6. 《我用 AI 做设计的六步法(第二篇:复杂功能篇)》

    《我用 AI 做设计的六步法(第二篇:复杂功能篇)》

    标签:
    #AI辅助设计 #工程师设计进阶 #AI_Slop治理 #复杂功能开发 #RefTools

    总结:
    作者分享了自己用 AI Agent 开发复杂产品功能时、如何避免"AI Slop(AI 生成的设计垃圾)"污染界面的完整流程。核心思路是:在让 Agent 动手之前先充分理解产品和约束,Agent 跑完后必须人工把每个界面状态过一遍,再聚焦打磨关键界面,最后靠团队协作和真实用户反馈收口。

    文章要点:
    1. 动手前先理解机制:花大量时间在调研规划阶段,搞清 Agent 会接触的产品界面和技术约束,甚至亲手写一遍用户流程,绝不让 Agent 的技术/产品决策带来意外惊喜。
    2. 追踪 Agent 的实现轨迹:让 Agent 先把功能粗做出来当"陶土"来塑形,然后通读它产出的所有产物(日志、截图、PR、演示视频),检查实现路线是否有异常偏离。
    3. 放大视角看遍所有状态:他要求 Agent 点击功能里每一个界面的每一个状态,输出全状态截图清单和沿途发现的 Bug 清单,先粗扫一遍再标记小问题,这一阶段说得最多的就是"删掉这个"。
    4. 聚焦打磨关键界面(Crux Surfaces):把最关键的几个界面拉到 Figma 或 HTML 原型里手工精修,这是 AI 时代里难得的专注打磨细节的乐趣。
    5. 走出孤岛、靠团队迭代:一个人用 Agent 能做完过去一个团队的活,但也失去了团队的品味把关;他们靠 Slack 的 #design-adjustments 频道让任何人贴"修改前/后对比图"来提设计改进。
    6. 上线、学习、接受意外:复杂功能总有你没想到的交互路径,用户一定会找到它,把产品交到用户手里才是真正的验证。

    URL:https://x.com/reactiverobot/status/2115075879923765615 Matt Dailey on X: "How I Design with AI. (pt 2)" / X

  7. 《如何更有野心:给有模型可用的人的教程》

    《如何更有野心:给有模型可用的人的教程》

    标签:
    #人工智能 #个人效率提升 #人机协作 #模型能力边界 #自我效能感 #Altitude_Depth_Range

    总结:
    作者 Felix Rieseberg(Claude 团队成员)指出,AI 模型能力在各方向增长并不均衡,许多用户还停留在"问首都、改邮件"的浅层用法。他把"更有野心"拆解为 Speed(速度)、Altitude(高度)、Depth(深度)、Range(广度)四种类型,并给出了每种类型的具体操作方法——从"让模型对结果负责"而非"执行单个任务",到"用行业顶尖专家的工具和方法",再到"用跨领域团队思维重写任务",最后还从心理学角度(自我效能感)解释了为什么这种"野心"需要刻意练习。

    文章要点:
    1. 野心分四种:速度(省时间,已基本普及,无需多讲)、高度(关注目标之上的目标)、深度(像顶尖专家那样做任务)、广度(引入多个领域的视角与方法)。
    2. 高度(Altitude)的关键问题是"下一步你想要什么结果":别只让模型填季度报告模板,而是让它分析全部数据找出变化与原因、推演最紧迫的三个决策、甚至设计一套比季度汇报更好的业务监控机制。
    3. 深度(Depth)的核心是坚持让模型使用行业顶级专家的工具,而非表面模仿专业术语:用数据库和统计模型替代 Markdown 表格,设定看似不合理的高目标,让模型用原始数据对抗性检验既有假设,甚至构建仿真模型产出"新知识"。
    4. 不要自我评判,要用外部裁判:作者在 2026 年 10 月仍坚持模型不能可靠地自我评估,最好用可运行的工具或测试来验证结果。
    5. 广度(Range)的技巧之一是把名词换成动词:季度报告不是"一份 PPT",而是"让忙碌的人在 30 分钟内相信因果故事并做出不确定决策",然后再像组建抢劫团队一样,为任务引入分析师、记者、编辑、做空者、法务会计等不同角色真正在"做的事"。
    6. 这一切的前提是模型要有电脑可用——能装软件、能访问数据(如 MCP 连接器),而不是只在一个聊天框里空转。
    7. 从心理学看,这本质是"自我效能感"问题:人类只敢在自己熟悉的窄领域相信自己能成功;好在这可被"破解"——设定具体的高难度目标(Locke 和 Latham 35 年研究)、看到别人做到后跟上(四分钟一英里、破二马拉松),以及允许自己失败(Linux 当年也只是"爱好")。

    URL:https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/ How to be more ambitious: A tutorial for humans with models

  8. 如果你正在用AI构建,收藏这些👇

    如果你正在用AI构建,收藏这些👇

    1. landdding.com — 170+ 视觉技巧
    2. modulify.ai/templates — 100+ 免费模板
    3. theinternetdesigns.com — 创意网页
    4. motionin.design — 动态部分
    5. scrolltide.co — 动画网站提示
    6. godly.website — 高端网页设计
    7. land-book.com — 着陆页灵感
    8. cta.gallery — CTA 灵感
    9. footer.design — 页脚灵感
    10. 60fps.design — 流畅交互
    11. backgrounds.supply — 背景
    12. inspora.design — 设计灵感 Free Templates to Clone – Built with Modulify

  9. 1. devault.design — 39 万+ 真实产品界面、全套 UX 流程,以及 UI 多年来的演变

    1. devault.design — 39 万+ 真实产品界面、全套 UX 流程,以及 UI 多年来的演变
    2. mobbin.com — 移动端和网页应用模式
    3. land-book.com — 登陆页面画廊
    4. recent.design — 原名 Godly,最“生动”的网页设计画廊
    5. pageflows.com — 录制的用户流程
    6. reallygoodemails.com — 电子邮件设计库
    7. navbar.gallery — 值得复制的每一种导航栏模式
    8. footer.design — 页脚,终于有了
    9. siteinspire.com — 精选网页设计
    10. minimal.gallery — 干净、极简的网站

  10. 《Thorsten Ball:我对软件开发未来的16条判断》

    《Thorsten Ball:我对软件开发未来的16条判断》

    标签:
    #软件工程 #AI编程 #代码审查 #单元测试 #终端工具 #Token计算范式 #开源生态 #软件开发未来 #ThorstenBall

    总结:
    2026年9月19日,知名开发者、《Writing An Interpreter In Go》作者、现供职于 Sourcegraph/Amp 的 Thorsten Ball 在 X 发布长文,抛出 16 条关于软件开发未来的判断。核心观点是:当 AI 写代码的可靠性足够高时,为人类防错而设计的整套工程实践(代码审查、单元测试、终端、命令行工具)都会逐渐失去必要性,工程师的价值将从"写代码的手艺"迁移到"理解业务、判断取舍、拿到反馈"上,而这一切需要一代人的时间完成。

    文章要点:
    1. 代码审查已死——人类不会再逐行 review 模型产出的代码,只会审查"系统与其组合方式"。
    2. 单元测试可能会消失——他让模型写 900 行 Arduino C 代码零错误一次通过,"摔不了跤就不需要护膝"。
    3. 写代码这门手艺会消失,但"造软件"(解决业务问题、判断何时上线、获取反馈)会比以往更重要。
    4. 大多数 bug 将不再是代码 bug,而是"你需求提错了"的 bug。
    5. 终端已死——Shell、编辑器、CLI 工具会被 token 冲刷,命令行知识将像 Perl 一行流一样变成"古老技艺"。
    6. Token 是新的计算范式,我们正在进入"后二进制时代",一切都会在它之上被重构。
    7. PM/设计/工程的铁三角和 Agile、Scrum 都会瓦解,只做"人肉代理"的工程师将不再有价值。
    8. 大小公司的工程差距会拉大——小团队比学大厂做法的初创公司跑得更快。
    9. "好代码"的标准(人类易读易维护)建立在人类要改代码的前提上,这个前提正在崩塌。
    10. 现有形式的开源不再合理——"众眼监虫"依然成立,但现在有了"人工眼睛"。
    11. 拿不到足够 token 的人会被排除在软件生产之外,token 是新的生产力门槛。
    12. 便宜模型未必有人用——更聪明的模型犯错少、轮次少,你未必愿意忍受它多错几次。
    13. 模型快到一定程度后,UI 会被实时生成,菜单、设置页、仪表盘这些"面向人类的 API"会大幅减少。
    14. 这场变革不会一夜发生——新旧范式更替需要一代人的时间,但反问是:"10年后还有写代码的工作,可你想要那份工作吗?"

    URL:https://x.com/thorstenball/status/2101305394190557466 Thorsten Ball (@thorstenball) on X

  11. 《Gr8r Studio:一款平静、结构化的项目管理工作台》

    《Gr8r Studio:一款平静、结构化的项目管理工作台》

    标签:
    #开源项目管理 #Web前端开发 #任务看板 #纯ES模块 #Vite构建

    总结:
    Gr8r Studio 是一个开源的项目管理应用,提供首页仪表盘、收件箱、我的任务和多视图项目管理(看板/列表/表格/日历/时间线/文件),以及成员、团队、动态和设置等完整功能;它完全用原生 JavaScript ES 模块和 CSS 构建,无任何 UI 框架和运行时依赖,仅由 Vite 打包。

    文章要点:
    1. 功能齐全:包含仪表盘、收件箱、我的任务,以及看板、列表、表格、日历、时间线、文件六种项目视图。
    2. 零框架零依赖:纯 JS ES 模块 + CSS 实现,不引入任何 UI 框架或运行时依赖。
    3. 结构清晰:src 目录按 styles、core(状态与主题)、ui、shell(路由与布局)、views、overlays、features、actions 分层组织。
    4. 工程化完善:内置 ESLint + Prettier 校验,CI 在每次推送和 PR 时跑 lint、格式检查和生产构建。
    5. 可直接预览:仓库附带演示数据(data/seed.js)和 README 截图,vercel.json 配置了一键构建部署到 Vercel。
    6. 上手门槛低:仅需 Node.js 18+(.nvmrc 固定 22),适合作为学习现代前端工程化的参考项目。

    URL:https://github.com/gr8rstudio/gr8r-studio GitHub - gr8rstudio/gr8r-studio: Gr8r Studio: a calm, structured project management workspace. Vite + plain ES modules.

  12. 《用 React Suspense 面板调试 Suspense》

    《用 React Suspense 面板调试 Suspense》

    标签:
    #前端开发 #React
    #React_Developer_Tools #Suspense面板 #加载调试 #骨架屏 #布局抖动

    总结:
    本文演示了如何用 React Developer Tools 8.0 新增的 Suspense 面板,排查一个仪表盘页面中"销售统计卡延迟约 2 秒才出现"和"内容到达时快速操作区被顶下去"两个问题。通过时间轴回放、Inspect Suspense Nodes、Suspended by 和强制回退功能,作者定位到负责延迟的边界和 Promise,并把骨架屏改成与真实内容形状、尺寸一致,从而消除了布局抖动。

    文章要点:
    1. Suspense 面板在 React Developer Tools 8.0 中默认启用,配合 React 19.2+ 的开发模式构建能显示最完整的信息。
    2. 面板分为四个区域:工具栏(Inspect Suspense Nodes 可直接从页面点选边界)、Minimap(页面边界的可视化地图,颜色区分渲染环境)、时间轴(每步对应一次初始绘制或边界揭示,可回放页面状态)、检查器(查看 Suspended by、props 和渲染来源)。
    3. 通过逐步回放时间轴,发现布局抖动发生在统计卡片揭示的那一刻,因为卡片比灰色占位块高,把上方的 QuickActions 顶了下去——嵌套边界只控制揭示顺序,并不为内容预留空间。
    4. 用 Inspect Suspense Nodes 从页面内容反查所属边界,比在大页面里挨个找 Minimap 区域更快;找不到时记得关闭 Unique Suspenders 过滤器。
    5. Suspended by 显示边界等待的对象、耗时和解析结果,能把排查范围缩小到数据、代码或资源,但无法解释为什么会慢。
    6. 检查器里的"暂停所选组件"按钮可以随时把边界强制切回 fallback,方便把骨架屏和真实内容并排对比,无需改代码或限速网络。
    7. 修复方法:让骨架屏复刻真实布局——直接渲染四张真实卡片和标签,只把查询得到的数值换成等高的占位行;重放时间轴后快速操作区不再移动。

    URL:https://certificates.dev/blog/debugging-suspense-with-the-react-suspense-panel Debugging Suspense with the React Suspense Panel

  13. 《React 编译器到底做了什么》

    《React 编译器到底做了什么》

    标签:
    #前端工程 #编译器优化 #ReactCompiler #组件内联 #细粒度更新 #状态选择器 #性能基准测试

    总结:
    作者 Jimmy Miller 通过"边做边讲"的方式拆解 React Compiler 的工作原理:它把组件代码转成基于 memo cache 槽位的低级形式,绕开 Hooks 规则限制自动做记忆化。在此之上,他手工原型化了一系列激进优化(组件内联、Block DOM、列表缓存、Context 选择器、外部 store 选择器等),在 13 项微基准测试中最高取得 51 倍加速,但强调这些都只是探索性原型,不代表 React 官方应该采纳。

    文章要点:
    1. React Compiler 的输出特征是把 JSX 构造包进 _c() 缓存槽位中,首次渲染写入缓存,后续渲染直接复用,本质上相当于给所有内容自动套上了 memo。
    2. 编译产物用的是比 Hooks 更底层的 API,可以在条件返回之后做缓存,绕开"useMemo 不能写在条件分支后"这类 Hooks 规则的限制,作者认为这个啰嗦的形式正是理想的编译目标。
    3. 编译器内部先把代码转成 SSA(静态单赋值)形式,再跑大量 pass:有的简化代码(如把 props.method() 拆成属性加载 + 普通调用),有的推断信息,有的做变换优化。
    4. 作者尝试组件内联,结果反而更慢(1038 ms 对比编译器的 444 ms),因为内联破坏了 Row 组件自带的缓存边界;说明内联本身只是为后续优化铺路的前置步骤。
    5. 借鉴 Million.js 的思路实现 Block DOM(静态/动态分离、按状态 diff 而非树 diff)后,追加 2000 行从 1038 ms 降到 164 ms,内联反而开始带来收益,因为静态边界变得更大了。
    6. 列表选择优化借鉴 Solid 的 createSelector:记录选中值变化只影响"旧选中行"和"新选中行",200 次选择从 250 ms 降到 5.4 ms;Context 细分选择器把 typing 更新场景从 80 ms 降到 11.7 ms。
    7. 对 Zustand 这类外部 store,把 === 判断挪进 selector 内部这一小改动就能带来数倍提升,编译器完全可以自动完成这类分析(200 次选择从 311.5 ms 降到 48.9 ms)。
    8. 作者反复强调:微基准测试的胜利不等于生产环境该采纳,真正的难点不在原型而在验证——理解真实负载、权衡内存代价、与生态和未来规划对齐;此外 SSR、hydration 等方向尚未触及。

    URL:https://jimmyhmiller.com/what-does-the-react-compiler-even-do Can we Make React Faster using the React Compiler?

  14. 《我实测了11个HTTP弹性库的21个场景,结果如何?》

    《我实测了11个HTTP弹性库的21个场景,结果如何?》

    标签:
    #软件开发 #HttpResilience_对比测试_Retry_CircuitBreaker_Hedging_取消与超时正确性

    总结:

    作者在开发自己的 fetch 弹性封装库 ffetch 时发现了大量隐藏的正确性问题,于是搭建了一套覆盖 21 个场景的测试矩阵,对 11 个流行的 HTTP 弹性库(包括自己 ffetch 5.7.1)进行横向对比。结果显示:基础的"重试"行为在所有库中都表现良好,但 25 个失败几乎全部集中在组合场景——取消发生在退避等待中、超时与重试叠加、队列中的请求被取消、熔断器半开状态下迟到响应等。作者也坦承测试套件源自自己修过的 bug,存在确认偏差,且部分判定标准(如取消后必须立即停止派发)严于官方文档。矩阵每周自动重建并公开于 fetchkit.org/http-resilience。

    文章要点:

    1. 测试方法很扎实:21 个场景覆盖重试、超时、熔断、舱壁、对冲、请求去重,用脚本化 fetch + Vitest 假定时器精确控制中止时刻,jitter 固定 random=0.5,并附 2 个真实 node:http 集成场景。

    2. 全部 11 个库都通关的"共同强项"是基础重试类场景:重试恢复、重试耗尽、零重试、真实 HTTP 重试、请求体字节级回放,共 55/147 个实现单元。

    3. 失败高度聚类于"组合场景":典型如"重试 + 退避中取消",fetch-retry、ofetch、wretch、resilient-fetch-client、fetch-resilience、@resili/fetch 六库会延迟结算甚至取消后继续派发请求;fetch-retry 的源码问题暴露——退避用的是裸 setTimeout,从不读 init.signal。

    4. 舱壁队列几乎全军覆没:五家有队列的库中四家在"排队请求被取消"场景全挂——取消的调用方仍占着坑位不放,替换请求被拒,个别还照样派发了已取消的请求,ffetch 是唯一通过者。

    5. 重试 + 整体超时、Retry-After + 取消、hooks 抛错等场景暴露多家库"超时只罩单次尝试不罩重试循环"、回调拒绝后调用方永久挂起等问题,wretch 甚至会变成一个永远 await 的悬空 Promise。

    6. 对冲(hedging)是最不成熟的表面:仅三个库提供带可配置启动延迟的对冲;flowshield 在所有超时设置下都失败,超时后仍启动对冲分支且分支不收手,等于白发给服务器一个没人等的请求。

    7. 熔断器组合场景里作者自己的 ffetch 也栽了:半开状态下迟到成功响应会错误清除新开启状态(缺代次计数器);fetch-smartly 和 ts-retry-circuit 更严重,新冷却期被误清导致下一个请求吃掉本应给健康调用方的恢复响应。

    8. 作者最后强调方法论局限:无性能基准、无 API 设计评价,场景源于自己修过的 bug 存在确认偏差;建议读者不要只看"功能有没有",而要按自己应用的真实组合方式去测。

    URL:
    https://blog.gaborkoos.com/posts/2026-10-04-I-Tested-11-Http-Resilience-Libraries/

  15. 《OpenRig:把 Claude Code 和 Codex 编成一支可恢复的多智能体团队》

    《OpenRig:把 Claude Code 和 Codex 编成一支可恢复的多智能体团队》

    标签:
    #AI_Agent编排 #多智能体协作 #ClaudeCode #Codex #Tmux #终端UI #任务队列 #快照恢复 #MCP工具 #开源工具

    总结:

    OpenRig 是一个自托管的多智能体 harness:它不替代 Claude Code 或 Codex,而是把多个 Agent 会话组织成“有结构、可命名、可恢复”的团队。你用 YAML(RigSpec)定义团队拓扑,用一条命令启动整队,并通过 TUI/CLI/MCP 观察状态、发消息、跟踪任务和做快照恢复,避免终端窗口越开越散。

    文章要点:
    1. 核心解决“终端蔓延”:把一堆各自为政的 Claude Code/Codex 会话,变成有角色、有地址、有协作关系的团队。
    2. 团队用 YAML 声明式定义:RigSpec 里包含 pods、成员、edges、continuity policies 和 culture 文件,便于版本化与复用。
    3. 一键启动与拓扑可视化:rig up 会拉起 tmux 会话、harness、启动文件和 readiness 检查;TUI 提供表格/图视图查看 rigs、pods、seats。
    4. 支持“收养”已有会话:rig discover 识别现有 tmux 中的 Claude Code/Codex 会话,rig adopt 将其纳入管理。
    5. 状态可保存也能回滚:rig down --snapshot 保存拓扑,rig up <name> 按名字恢复,重启后不再丢上下文。
    6. 跨 Agent 沟通有统一入口:rig send、rig broadcast、rig chatroom 让协作不再靠人肉切窗口。
    7. 提供 Agent 可用的 MCP 工具:Agent 能自管理拓扑(如 rig_up、rig_ps、rig_send 等),更适合“由 Agent 驱动”的工作流。
    8. 权限与安全边界清晰:默认非 YOLO;可配置 typing guard、权限模式、workspace trust、hooks 与活动上报(不包含 prompt 文本和工具参数)。
    9. 附带 starter rigs 与示例:如 first-project、product-team、conveyor、adversarial-review、research-team、secrets-manager(HashiCorp Vault 由专门 Agent 管理)。
    10. 运行要求明确:需要 Node.js 22/24、tmux,支持 macOS/Linux;可选 herdr/cmux 做终端工作区,Docker 用于服务化 rigs。

    URL:
    https://github.com/mvschwarz/openrig GitHub - mvschwarz/openrig: Build your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared…

  16. 《Paperclip:用开源“公司”编排 AI 智能体团队》

    《Paperclip:用开源“公司”编排 AI 智能体团队》

    标签:
    #AI_Agent编排 #Agentic任务管理 #组织治理与成本控制 #多智能体协作 #开源自托管 #Nodejs与React #OrgChart #Heartbeat调度 #预算管控 #多组织隔离

    总结:

    Paperclip 是一个开源的自托管应用,用“经营公司”的方式管理 AI 智能体团队:它把目标、组织架构、任务、预算、审批、审计和运行环境整合进一个控制台。你可以接入 Claude Code、Codex、Cursor、OpenClaw 等任意 Agent,让它们像员工一样有角色、汇报线、预算与心跳调度,并在一个看板里追踪进度与成本。

    文章要点:
    1. 核心定位是“管公司,不是管聊天”:Paperclip 不造 Agent、不做拖拽式工作流,而是把多个 Agent 编排成有目标、有层级、有治理的组织。
    2. 使用路径很直接:先定义商业目标,再“招聘”不同职能的 Agent(CEO/CTO/工程/设计/营销等),最后审批策略、设置预算并启动运行。
    3. 四大支柱覆盖日常到平台层:Agentic 任务管理、Agent 组织架构、Agent 员工培训、Agentic OS(运行基础设施)。
    4. 任务系统强调可审计与防冲突:任务带公司/项目/目标链路,支持原子领取、执行锁、阻塞依赖、评论、附件与产出物。
    5. Heartbeat 让 Agent 按计划醒来干活:支持定时唤醒、事件触发、上下文续接、结构化日志与自动恢复,减少人工盯梢。
    6. 成本控制是硬约束:按公司/Agent/项目/目标/模型等维度追踪 token 与费用,预算到线会告警并硬停止,避免“跑飞”。
    7. 治理与回滚机制完整:审批流、执行策略、决策记录、暂停/终止 Agent、配置版本化与审计日志都在系统内完成。
    8. 支持多组织隔离与可移植性:一套部署可跑多家“公司”,数据完全隔离;还能导出/导入组织配置并做密钥清理。
    9. 运行环境面向真实开发流程:支持项目工作区、隔离执行工作区(如 git worktree)、开发服务/预览链接、密钥注入与技能加载。
    10. 它不是聊天机器人、不是 Agent 框架、不是代码评审工具,而是面向“多 Agent 团队”的编排控制平面。

    URL:
    https://github.com/paperclipai/paperclip GitHub - paperclipai/paperclip: The open-source app everyone uses to manage agents at work