2026-第三十三周

该周报主要为各个地方内容的汇总整理

技术

DeepSeek Harness 开发者预览版 一切皆插件

DeepSeek Harness 已推出开发者预览版，采用“一切皆插件”的架构，基于 Cordis 内核实现模块化组合，提供多种运行模式与完整可追踪日志，支持开发者自定义代理能力，并已开放源代码。

• 🧩 核心设计：所有能力均为插件，包括模型、工具、技能、会话、沙箱、存储、循环、调度和 UI，可在配置中自由替换或扩展。
• ⚙️ Cordis 内核：负责插件的挂载、卸载与依赖管理，通过服务与事件机制让各插件协同工作，无需改动源代码。
• 📜 全程可追溯：采用追加式会话日志记录模型所见一切，支持轨迹视图按来源检查、恢复、分叉、搜索与回放。
• 🚀 四种运行模式：标准模式提供完整工具集；代码模式允许模型通过生成代码编排多轮工具调用；极简模式仅保留 shell 与文件编辑器用于基准测试；创作者模式支持运行时检查与插件试验。
• 🛠️ 自定义能力：开发者可通过配置组合插件创建新预设，或使用 Creator Mode 在内存中测试并组合 Cordis 插件。
• 🌐 快速开始：支持 npx 一键启动 Web UI（npx @deepseek-ai/dsh web）或通过 Git 克隆源码本地安装。
• 🔭 仍处预览阶段：核心插件与 API 会持续演进，面向全球开发者开放，基于可复用和可组合的开源基础设施探索智能边界。

控制与复杂性：系统设计中的张力

• 🧭 文章探讨系统设计中“分析分解/控制”与“复杂性/涌现”两种对立思路的张力，尤其在 LLM 改变软件开发实践后更需审视系统设计的基本假设。
• ⚙️ 分析分解方法源于经典科学工程，主张将系统拆解至可理解、可预测的组件，通过层次控制、流程规范、冗余设计来保证可靠性，是工业、人因、组织管理的基础。
• 🌀 复杂性视角认为系统高度互联、动态开放、不可简化，强调干预应小而迭代，通过增加控制者的内部复杂性来适应现实，目标不是静态平衡而是持续运动。
• 🧩 两种思路在实践中往往混搭，但常因“加倍分析控制”或“盲目追求自主涌现”而失败；需要认清边界，判断何时该控制、何时该影响。
• 📋 文章用对比表格展示培训、安全、正确性、可靠性、事故处理、功能开发、标准规范等主题下两种立场的不同做法，以及代码评审、SLO、重构、混沌工程等活动的双重用途。
• 🔄 同一活动可服务控制或涌现目标，但实际效果取决于参与者对高阶目的和期望结果是否一致；若错配，则可能沦为形式主义或失去真正的益处。
• 🔍 面对不想要的行为，控制型策略靠规则、权限、屏障来限制，涌现型策略则先理解对方压力与动机，再设计干预；组合型策略先用复杂性眼光理解互动，再设置高杠杆的简单检查。
• ⚠️ 盲目切换设计模式（如用自动屏障取代代码评审、把工作拆为黑盒翻译、人人管理 agent、完全放弃内部结构）会忽略隐性功能和二阶效应。
• ❓ 控制导向系统需自问：观察是否失真？抑制了哪些必要变异？优化造成了哪些脆弱性？控制是真实的还是错觉？
• ❓ 涌现导向系统需自问：局部是否目标冲突？如何维护连贯性？失去可读性换来了什么？适应与漂移如何区分？异议和边缘信息如何保留？
• 🏭 技术公司常因新科技承诺而急遽重构，但自动化抽走可预测性的同时也会移除对适应性有用的不可预测性；必须明确系统何时迁移模式，哪些部分适合控制，哪些应视为生态。
• 🎯 最终核心问题不是“哪种方法更好”，而是“当前方法何时到达极限，接下来怎么办”；无论何种设计，系统仍会按系统的规律运行和失败。

为什么微小 JPEG 图元在 Chrome 中看起来不一样

Chrome 在渲染小尺寸 JPEG 时，并未完整解码再缩放，而是采用“部分 IDCT 缩放”优化，跳过高频系数，只保留低频信息，导致图片在小尺寸下显得更粗/更厚。这种优化与 Firefox 等浏览器不同，因此出现渲染差异。

• 🖼️ 发现现象：同事电脑上的同一张 Logo 在 Chrome 中看起来更粗，Firefox 中更接近原图，换用 SVG 可解决。
• 🔍 最初怀疑是渲染 bug，后证实是 Chrome 的 JPEG 解码优化所致。
• 📉 完整解压大图再缩放到小尺寸很浪费：2000×2000 解压约 12 MB，而 20×20 只需约 1.2 KB。
• 🌲 缩小图片时，丢失的主要是高频细节（如树叶、树皮的纹理），低频信息（整体颜色和形状）保留下来。
• 🧩 JPEG 将图像分为 8×8 块，通过 DCT 转换为频率域，低频是纯色，高频是棋盘格模式。
• ⚡ 按 1/8 缩放时，每个 8×8 块只需一个像素，因此可跳过高频系数，仅用低频数据解码，节省内存和计算。
• 🔧 Chrome 使用 Skia + libjpeg-turbo，在目标尺寸较小时自动执行部分 IDCT 缩放，再配合传统下采样算法达到最终尺寸。
• ⚠️ 实际效果受 IDCT 缩放和后续缩放算法共同影响，并非单一原因。
• 🚫 结论：不适合用 JPEG 做图标等小尺寸图像，JPEG 是为照片感知设计的格式。

让更多的 npm 包支持 jsDelivr 的 ESM 模式

jsDelivr 团队升级了 /+esm 工具链，并通过生产环境 APM 数据定位和修复了大量 npm 包兼容性问题，涵盖依赖升级、CommonJS 互操作、Node.js polyfill、source map 和性能优化，使更多包可在浏览器中直接运行。

• 🔄 升级后端为原生 ESM，并将 Rollup 从 2 代升到 4 代，同时修复了 JSON import attributes 等语法兼容问题。
• 📜 对声明 "type": "module" 的包，其 .js 入口不再进行 CommonJS 转换，从而支持顶层 await。
• 🌍 扩展 NODE_ENV 替换规则，覆盖 globalThis.process、global.process、括号属性写法等多种生成代码变体，同时避免误替换普通对象键。
• 🐚 将包入口的 #! shebang 替换为 // 以保持 source map 行列对齐，并修复 browser 字段中的自映射逻辑。
• 🔍 增强 CommonJS 命名导出检测：识别 TypeScript 的 __exportStar，合并两种 cjs-module-lexer 结果，支持条件分支赋值和非标识符属性名。
• 🔗 修复 CommonJS 导入外部 ESM 依赖时的默认导出误判，保留命名导出，并移除人为合成的 export default null。
• 📂 通过 resolveImportMeta 保留各模块发布时的 npm URL，使 import.meta.url 能正确解析同目录下的 .wasm、worker 等资源文件。
• 🗺️ 修复 source map 中空源、非法 sourceRoot 及 sourcesContent 冲突导致的加载失败，并改进生成 map URL 的标识方式。
• 🌳 将暂不支持的 Node.js 内置模块转为无副作用虚拟模块，先让 Rollup 进行 tree-shaking，若仍残留再返回原错误信息。
• 🛠️ 扩展 Node.js 兼容层共 16 项，涵盖 util、URL/path、timers/promises、crypto、fs 等 API，并修复多个 polyfill 实现和解析问题。
• ⚡ 对 ESM 包的最终压缩改用 esbuild 替代 Terser，大文件（>4MiB）同样走 esbuild；外部包 manifest 改为每包只拉取一次并复用。
• 📱 识别直接在 .js 中发布 JSX 的 React Native 包，返回明确的“unsupported JSX”提示，而非当作未知崩溃。
• ✅ 所有修复均配套回归测试；结合用户报告与生产数据，大幅减少了剩余兼容性积压，并让剩余失败原因更清晰。

工具

hucre

hucre 是一款零依赖、纯 TypeScript 的电子表格引擎，支持 XLSX、CSV、ODS、JSON、NDJSON、XML 等多种格式的读写，具备流式处理、往返保留、密码保护、图表与透视表等丰富功能，可在 Node.js、Deno、Bun、浏览器及边缘运行时中运行。

• 📦 零依赖、纯 TypeScript 实现，支持 XLSX、CSV、ODS、JSON、NDJSON、XML 等多格式读写。
• 🌳 支持树摇（tree-shaking），按子路径导入可显著减小打包体积，gzip 后约 4–129 KB。
• ⚡ 提供流式读写（streamXlsxRows、writeXlsxStream）与增量写入器，可处理数百万行数据并保持较低内存占用。
• 🔒 内置 XLSX 密码保护（Agile 加密），基于 WebCrypto，零额外依赖，兼容 Node.js 与浏览器。
• 📖 可读取旧版 XLSB 和 XLS（BIFF8）文件，支持共享字符串、公式缓存值、合并单元格等。
• 🔄 支持往返保留（openXlsx/saveXlsx），未建模的部分按字节复制，图表、宏等可无损保留。
• 📊 原生支持图表读取、写入与克隆，覆盖柱状、折线、饼图等主流类型；透视表可写入结构骨架。
• 🧩 提供统一 API（read/write/readObjects/writeObjects），自动检测文件格式，简化对象操作。
• 🖥️ 附带 CLI 工具，可执行 convert、inspect、validate 命令，支持多种格式互转。
• 🛠️ 提供工作表操作（插入/删除行列、排序、克隆、移动）并智能更新公式和引用。
• 📄 支持 HTML/Markdown 导出与 HTML 表格导入，另含 JSON/NDJSON/XML 处理工具。
• 🔢 内置数字格式渲染器、日期工具、单元格引用解析和构建器 API（WorkbookBuilder）。
• 📋 提供模板引擎（{{placeholder}} 填充）、Excel 2024 原生复选框、无障碍（WCAG 2.1 AA）审计功能。
• ✅ 支持模式验证（validateWithSchema），含类型强制、正则、自定义校验和错误收集。
• 🌍 跨平台支持：Node.js、Deno、Bun、现代浏览器、Cloudflare Workers 等。
• 🏆 相比 SheetJS/ExcelJS 等库，依赖更少、ESM 原生、TypeScript 类型完善、支持流式与 ODS。
• 🧱 架构模块化：内置 ZIP/XML 引擎，符合 CSP，无 eval，worker 友好。
• 🛣️ 路线图中规划了公式计算、更多图表类型写入、流式 XML 读取、XLS/XLSB 写入等未实现功能。

kitesurf

overview summary：Cloudflare 正式发布 Kitesurf，一个为 AI 代理设计的、运行在 Workers V8 隔离环境中的全新浏览器。它针对 AI 场景大幅优化了 CPU 与内存效率，并通过 CDP 协议兼容现有自动化工具，目前已在 Browser Run 中开放免费测试。

• 🚀 Kitesurf 是 Cloudflare 专为 AI 代理构建的浏览器，完全运行在 Workers 上，可在 Browser Run 中免费试用（beta 版）。
• ⚡ 相比 Chromium，Kitesurf 在常见代理任务中 CPU 消耗降低 3.1-3.8 倍，内存消耗降低 4.7-7 倍，但墙钟时间慢约 1.7 倍。
• 🧩 核心设计原则：以测试驱动开发，使用 Rust 编译到 WebAssembly，强调异常安全、严格隔离与尽可能无状态。
• 🏗️ 三大组件：Engine（处理 CDP API 与会话状态）、PageScript（用 Dynamic Workers 解析 DOM 并运行脚本）、PageRenderer（负责光栅化生成图片/PDF）。
• 🎯 通过 215,000+ 项 Web Platform Tests，并针对真实网站进行集成与视觉回归测试。
• 🖥️ 支持现有 CDP 客户端（Puppeteer、Playwright、chrome-remote-interface 等），只需添加 browser=kitesurf 参数即可使用。
• ✅ 适合 AI 代理的页面渲染、HTML 提取、截图/PDF 等一次性 Quick Actions 场景。
• ❌ 暂不支持视频、WebGL、复杂持久化会话或真实 TLS 指纹的 bot 挑战交互。
• 🔮 未来规划：完善 CDP 覆盖、提升截图/PDF 保真度、增加 WPT 通过率，并计划开源 Kitesurf 供用户自部署。

更新

useReactCompiler

该规则是 Biome 的实验性 lint 规则，用于通过 React Compiler 验证组件和 Hook 是否可安全编译，仅对 React 19 及以上项目生效，并支持多种编译模式配置。

• 🔬 属于 nursery 组，处于实验阶段，行为可能随时变化，默认严重级别为“信息”。
• ⚙️ 配置方式：在 biome.json 的 linter.rules.nursery 中设置 useReactCompiler 为 "error" 等。
• 🚀 仅在最近的 package.json 声明 React 19 或更新版本时运行；React 18 及以下或无 React 依赖的项目会跳过。
• ❌ 无效示例：在条件语句中调用 useState 会触发诊断，提示 Hook 必须始终在顶层以固定顺序调用。
• ✅ 有效示例：组件内只返回 JSX 且不违反 Hook 规则时不会报错。
• 🧩 提供 compilationMode 选项："infer"（默认，分析符合 React 约定的函数）、"annotation"（仅分析带 "use memo" 指令的函数）、"all"（分析所有函数，可能在非 React 代码中产生诊断）。
• 📦 使用 "all" 模式时，即使函数不符合 React 命名规范（如普通工具函数）也会检查外部变量修改等滥用问题。
• 🩹 该规则仍在积极开发中，可能缺少功能或存在粗糙之处，可通过相关 GitHub 链接反馈问题。

TanStack Form v2

TanStack Form v2 推出了 alpha 版本，这是基于 v1 一年来反馈进行的核心重写。v2 在保持基本 API 风格的同时，大幅改进了验证器、监听器、类型安全、SSR 等关键体验，并开放试用。

• 🚀 Form v2 alpha 正式发布，核心重写，API 基本兼容 v1，运行时性能更快、类型更安全。
• 🔄 验证器从事件键控对象改为管道模型，每个验证器独立声明自己的触发事件。
• 📌 一个验证器可以同时绑定多个触发事件（如 change 和 blur），避免重复注册和重复报错。
• 🔗 多个验证器可以共享同一触发事件，并通过 bailIfInvalid 控制执行顺序。
• 🎯 新增 when 条件，支持只在特定条件下触发验证（例如首次提交后才验证 change）。
• 🎧 监听器也改为同样的管道模型，支持多触发、多监听器共享触发以及条件执行。
• 🧩 新增 strictSchema 和 looseSchema 模式，解决 defaultValues 与 schema 类型不匹配时的问题。
• 🛡️ Form Composition 组件支持类型品牌约束，不兼容的组件（如字符串字段上的 NumberInput）会在编译期报错。
• 🌐 SSR 改进：服务端验证器移入共享 formOpts，serverValidate 返回结果而非抛错，客户端直接使用 serverState，省去手动合并。
• ⏳ v2 alpha 暂缺：内置表单持久化、非 React 适配器的 Form Composition、Submit meta。
• 📚 试用 alpha 需要查阅迁移指南，并关注两个 RFC 议题（#2296 与 #1823）。
• 🙏 感谢社区反馈，团队期待在 alpha 阶段收集更多意见以完善 v2。

pnpm 12 有什么不同 | pnpm

pnpm 12 是以 Rust 重写的版本，目前为发布候选版。它基本保持与 pnpm 11 兼容，但有三项关键差异：项目感知的全局 bin、Git 依赖解析方式变化，以及移除 --resolution-only 标志。

• 🔄 pnpm 12 是 Rust 重写版，命令、标志、设置和 lockfile 格式均与 pnpm 11 兼容，文档对两个版本通用。
• 📦 全局安装的 node、deno、bun 现在会优先使用当前项目固定的版本（通过 devEngines.runtime 或作为依赖安装），不再需要单独的版本管理器；由 globalShims 设置控制。
• 🔗 GitHub、GitLab、Bitbucket 上的依赖说明符现在视为身份标识，统一通过规范的 HTTPS URL 解析，不再记录 SSH URL。
• 📝 旧版 pnpm 生成的 lockfile 中若包含 SSH 形式条目，需用 pnpm update <package> 手动重新解析，pnpm 不会自动改写。
• 🔑 访问私有仓库的 SSH 配置应通过 Git 的 insteadOf 重写实现，pnpm 会调用 git 自动应用该配置。
• ❌ pnpm install --resolution-only 已被移除，相关功能改用 pnpm peers check 直接从 lockfile 读取 peer 依赖问题。
• 🧪 pnpm 12 以 next-12 标签发布为 RC，可通过 npm 或 GitHub 预发布安装；Homebrew、winget、Scoop、Chocolatey 尚未提供。
• 🐛 使用过程中遇到问题，请向官方报告。

其他

大型科技公司中功劳的给予与获取

在大科技公司里，埋头苦干并不能自动换来认可。工程师需要主动争取可见度，同时学会分享功劳，否则很容易被埋没，甚至成为问题出现时的背锅对象。

• 🏫 很多工程师认为“可见度”是经理的事，但这其实是“学校幻想”——以为公司会像学校一样公正评价你的表现，现实并非如此。
• 🔍 技术工作极其复杂，经理根本没能力直接评估，只能依赖团队里可信工程师的私下判断，因此“口碑”至关重要。
• 📣 有经验的工程师会主动展示成果：向经理汇报、写技术文章解释难度、建立信任关系，这就是“玩政治”的务实含义。
• 🎁 想要积累功劳，最有效的方式反而是把功劳分给别人。背后有庞大的非正式评审网络，分享功劳能让他们为你说话。
• 🤝 把个人项目变成共同项目，让同事和经理都能从中受益，他们就有动力替你宣传，功劳不是零和游戏。
• ⚖️ 责任和功劳遵循同一套规则。复杂失败中，归责往往主观且可引导；若你独占功劳，就容易成为被推卸责任的对象。
• 💡 结论是：既要主动告诉别人你在做什么，又不要过度自我吹嘘；分享功劳能建立盟友，而独占功劳只会让你成为指责的靶子。

极速上手：快速入职实用指南

快速上手新岗位的关键，不在于囫囵吞枣地接收所有信息，而在于将信息分类为“事实”“流程”“概念”三种类型，分别采取不同策略。事实需分清“必须记住”和“可参考查阅”；流程需通过亲手实践来内化；概念则要主动构建知识关系图，形成可迁移的思维模型。同时，持续记录自己的问题，并观察问题深度的变化，是衡量自己是否真正融入团队的有效标尺。

• 🆕 大多数新人容易陷入“资料山”和“提问困境”，感觉自己同时打两份工：一份本职工作，一份拼命追赶理解进度。
• 📚 不要试图记住所有事实：只把少数关键事实放入工作记忆（如核心目标、关键标识、服务等级协议），其余大量参考类信息（如错误码、配置详情）只需知道去哪里查阅。
• 🔧 与事实不同，流程知识无法靠背诵掌握，必须通过实际执行来内化；最佳方法是请同事在你第一次动手操作时“影子指导”或“结对陪伴”。
• 🧭 概念类知识是最强大的学习加速器，它告诉你“为什么”，帮助你构建底层思维模型（如“目录系统”的通用逻辑），从而跨项目、跨行业快速迁移。
• 🗺️ 构建概念地图时，先确定一个最核心的概念放在中心，再逐步添加分支概念，并明确标注它们之间的关系（如“依赖”“导致”“属于”），并请专家帮忙校验地图是否准确。
• ❓ 主动记录自己产生的所有问题，不要只追求答案；随着能力提升，问题的质量会从“基础定义类”转变为“挑战假设、探索边界类”，这正是你不再是“新人”的信号。
• ⚡ 快速上手不是天赋，而是可习得的技能；当你学会区分事实、流程与概念，并持续追踪问题，新挑战将不再是压力，而是快速成长的机遇。

管理界的大谎言：过度承诺

管理者过度承诺是常见的隐性谎言，尤其在挽留高绩效员工时，看似善意却会严重损害信任和团队士气。

• 😇 过度承诺危害极大：短暂快乐（1-72 小时）后回归平淡，一旦落空，员工幸福感骤降至 1/10 且长期难以恢复，可能永久损伤信任。
• 🤔 管理者常因乐观或压力而过度承诺，尤其面对高绩效者沮丧时，但“我会帮你升职”这类话其实无法保证。
• 📉 计划外变动频发：如组织重组、同事评价差、晋升冻结、裁员等，都能轻易让承诺落空，而承诺者却无法控制。
• ⚖️ 过度承诺会被视为撒谎，但仅仅隐瞒部分信息（如未披露收购意向）反而更容易被理解，因为前者是明确的不实陈述。
• 🛡️ 解决方案：绝不说出未经 100% 确定的未来承诺，用条件化措辞和免责声明替代空头支票。
• 💬 示例修正：把“我会让你升职”改为“我会帮你准备晋升材料并在校准会上积极争取”；把“你将管理新团队”改为“若现行架构不变，我的计划是你来管理”。
• ❤️ 可以真诚表达情感（如“你非常优秀，我希望你升职”），因为真实感受不会构成谎言，但承诺必须谨慎。
• 🔑 管理者的言语就是契约，掌握下属生计的权力让话语神圣化；宁可说得谨慎难听，也不做乐观自信的骗子。