Now vibe coding, so learning hammer FE ?
《React 编译器到底做了什么》
标签：
#前端工程 #编译器优化 #ReactCompiler #组件内联 #细粒度更新 #状态选择器 #性能基准测试
总结：
作者 Jimmy Miller 通过"边做边讲"的方式拆解 React Compiler 的工作原理：它把组件代码转成基于 memo cache 槽位的低级形式，绕开 Hooks 规则限制自动做记忆化。在此之上，他手工原型化了一系列激进优化（组件内联、Block DOM、列表缓存、Context 选择器、外部 store 选择器等），在 13 项微基准测试中最高取得 51 倍加速，但强调这些都只是探索性原型，不代表 React 官方应该采纳。
文章要点：
1. React Compiler 的输出特征是把 JSX 构造包进
2. 编译产物用的是比 Hooks 更底层的 API，可以在条件返回之后做缓存，绕开"useMemo 不能写在条件分支后"这类 Hooks 规则的限制，作者认为这个啰嗦的形式正是理想的编译目标。
3. 编译器内部先把代码转成 SSA（静态单赋值）形式，再跑大量 pass：有的简化代码（如把
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，把
8. 作者反复强调：微基准测试的胜利不等于生产环境该采纳，真正的难点不在原型而在验证——理解真实负载、权衡内存代价、与生态和未来规划对齐；此外 SSR、hydration 等方向尚未触及。
URL：https://jimmyhmiller.com/what-does-the-react-compiler-even-do
标签：
#前端工程 #编译器优化 #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个场景，结果如何？》
标签：
#软件开发 #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 的源码问题暴露——退避用的是裸
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/
标签：
#软件开发 #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 编成一支可恢复的多智能体团队》
标签：
#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. 一键启动与拓扑可视化：
4. 支持“收养”已有会话：
5. 状态可保存也能回滚：
6. 跨 Agent 沟通有统一入口：
7. 提供 Agent 可用的 MCP 工具：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
标签：
#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 智能体团队》
标签：
#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
标签：
#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 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/
标签：
#软件工程 #前端性能优化 #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.
