锤子前端

#UX

Fri, 30 Oct 2026 07:37:25 GMT

#UX

子菜单需要一个三角形
https://x.com/a1x45h/status/2115805964725367180?a=gwiH1zIFoji-uGHK9A0&s=19

Bookmark this ⬇️

Submenus need a safe triangle.

When you move from a menu item to its submenu, you rarely go straight across. You cut diagonally, and that path crosses the items below. A bad imp…

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

Fri, 30 Oct 2026 01:36:44 GMT

CSS 技巧：防止布局在滚动条出现时横向跳动。
#CSS #UX

html {
  scrollbar-gutter: stable;
}

https://x.com/denicmarko/status/2115765989883433445?a=o3joFmAEkpM1zSiEQ0k&s=19

X (formerly Twitter)

Marko Denic (@denicmarko) on X

CSS tip: stop your layout from jumping sideways when the scrollbar appears.

html {
scrollbar-gutter: stable;
}

The browser reserves space for the scrollbar ahead of time, so nothing shifts.

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

Thu, 29 Oct 2026 22:20:12 GMT

《修复 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

Gmoniava

What Is a Hydration Mismatch Error and How Do You Fix It?

Understanding hydration mismatch errors and what to do about them.

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

Thu, 29 Oct 2026 09:14:04 GMT

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

标签：
#前端开发 #设计系统性能优化 #性能测试 #性能预算 #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

Den Odell

Design Systems Should Be Fast by Default

If a design system’s components are slow to interact with, so are any apps built with it. I timed large dropdowns and checkbox lists in some popular design systems, worked out how to make the slow ones faster, and wrote tests that fail when they’re too slow.

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

Thu, 29 Oct 2026 01:22:56 GMT

《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

GitHub - unclebob/ub-mode

Contribute to unclebob/ub-mode development by creating an account on GitHub.

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

Wed, 28 Oct 2026 13:05:13 GMT

《把子代理折叠回主循环：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

Claude

Building agents: When to fold subagents into your main agent loop

When to consider using fewer subagents and how to migrate the into your main loop.

Puter 团队新项目:把全世界的软件从零重写并开源

Wed, 28 Oct 2026 11:25:44 GMT

Puter 团队新项目:把全世界的软件从零重写并开源。Office 三件套、PS 平替 Photo Studio、CAD、Slack 平替 Teamchat、剪映平替 Video Studio……51 款应用一个 monorepo 全装下,每款附在线试用链接,MIT 协议商用随便用。上线 9 天 3,550 星。

https://github.com/HeyPuter/everything

《我用 AI 做设计的六步法（第二篇：复杂功能篇）》

Wed, 28 Oct 2026 01:12:46 GMT

《我用 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

X (formerly Twitter)

Matt Dailey on X: "How I Design with AI. (pt 2)" / X

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

Mon, 26 Oct 2026 23:26:47 GMT

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

标签：
#人工智能 #个人效率提升 #人机协作 #模型能力边界 #自我效能感 #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/

Felix Rieseberg

How to be more ambitious: A tutorial for humans with models

“We’re not ambitious enough” is easy to post and hard to follow. Here’s a practical tutorial, with prompts.

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

Sat, 24 Oct 2026 15:59:42 GMT

如果你正在用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 — 设计灵感

modulify.ai

Free Templates to Clone – Built with Modulify

Browse production-ready website templates built with Modulify. Preview any design and clone it into your dashboard to start your project in minutes.

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

Fri, 23 Oct 2026 12:49:19 GMT

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 — 干净、极简的网站

* inspora.design — 每日设计灵感

Fri, 23 Oct 2026 12:41:42 GMT

* inspora.design — 每日设计灵感
* land-book.com — 落地页灵感
* Backgrounds.supply — 自定义背景素材
* mobbin.com — App UI 界面灵感
* obsidianui.dev — 动效 React 组件
* reelfolio.io — 动效 Showcase / Showreel
* bencho.dev — 交互式 UI 组件
* minimal.gallery — 极简风格网站设计
* refero.design — 真实上线产品 UI

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

Fri, 23 Oct 2026 01:09:56 GMT

《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

X (formerly Twitter)

Thorsten Ball (@thorstenball) on X

Most predictions I see are still way too conservative.

Here's mine

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

Wed, 21 Oct 2026 15:13:34 GMT

《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

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

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

《用 React Suspense 面板调试 Suspense》

Thu, 15 Oct 2026 03:04:58 GMT

《用 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

certificates.dev

Debugging Suspense with the React Suspense Panel

The Suspense panel in React Developer Tools shows which boundary suspended, what it was waiting for, and the order your page revealed its content.

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

Sat, 10 Oct 2026 23:31:54 GMT

《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

Jimmy Miller

Can we Make React Faster using the React Compiler?

I prototyped a number of optimizations as a way to learn more about the React Compiler and got some significant improvements.

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

Thu, 08 Oct 2026 02:00:14 GMT

《我实测了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/

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

Tue, 29 Sep 2026 23:17:24 GMT

《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

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

Build your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work. - mvschwarz/openrig

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

Tue, 29 Sep 2026 23:09:27 GMT

《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

GitHub - paperclipai/paperclip: The open-source app everyone uses to manage agents at work

The open-source app everyone uses to manage agents at work - paperclipai/paperclip

《在 GitHub Copilot 应用中流畅渲染超大 Pull Request》

Sat, 26 Sep 2026 23:54:52 GMT

《在 GitHub Copilot 应用中流畅渲染超大 Pull Request》

标签：
#软件工程 #前端性能优化 #PullRequest #虚拟化渲染 #React #测量调度 #滚动锚定 #性能监控

总结：
文章介绍了 GitHub Copilot 应用如何重构 Pull Request 视图，使其能够流畅处理包含 2,200 个文件、超过 100 万行代码变更和 400 多条内联评论的超大型 PR。核心挑战在于评论高度的动态性——与代码行不同，评论高度取决于 Markdown 换行、可展开区块、回复框和图片加载等渲染时才能确定的因素。团队通过分离确定性与动态几何、实现智能测量调度器、采用滚动锚定技术，并建立自动化测量循环来解决这一问题，最终实现了百万行 diff 的流畅浏览体验。

文章要点：

1. 代码与评论的几何分离：代码行高度固定且可预先计算，而评论高度动态变化。团队将文档高度分为确定性代码高度（精确前缀和）和动态块高度（估算后测量），两者独立管理，避免评论调整时重建整个代码几何。

2. 智能测量调度器：放弃每块一个 ResizeObserver 的方案（会触发反馈循环），改为单一的空闲和滚动门控测量通道。仅在视口附近约 2400px 范围内进行测量，屏幕上的块优先批量读取，离屏块最多做一次有限渲染，超过视口高度的块跳过测量。

3. 滚动锚定技术：当测量高度与估算不符时，通过身份而非像素来校正——记录用户锚定的行或块，应用高度增量后，将同一锚点解析到新像素位置并滚动，确保用户视线不跳动。区分用户滚动与程序滚动，避免侧边栏切换等操作误触发保护机制。

4. 数据管道优化：流式传输结构优先于内容，文件树和元数据在文档加载时即可渲染；语法高亮在主线程外运行，行先以纯文本显示；释放文档时保留最近几个 diff 的缓存，平衡内存与返回时的加载速度。

5. 自动化测量循环：建立"变更→测量→改进"的无人值守循环，包括无头探针车道（声明式流程 + 生产环境插桩）和自动驾驶仪（驱动真实桌面应用），通过健康信号（如无未填充间隙、评论块非空）自动检测问题，实现机械式调试而非人工复现。

URL：
https://github.blog/engineering/user-experience/rendering-huge-pull-requests-in-the-github-copilot-app/

The GitHub Blog

Rendering huge pull requests in the GitHub Copilot app

How we rebuilt the diff surface in the GitHub Copilot app to open a million-line pull request with hundreds of inline review comments.