2026-第十一周

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

技术

你不知道的 Claude Code：架构、治理与工程实践

本文总结了作者深度使用 Claude Code 半年、每月花费 40 美元所获得的经验与洞见。核心观点是：Claude Code 并非一个简单的聊天机器人，而是一个需要系统化设计的代理（Agent）框架。其效能不取决于单一层面的优化（如编写冗长的 Prompt），而在于平衡其六个核心层次：长期上下文（CLAUDE.md）、动作能力（Tools/MCP）、工作方法（Skills）、强制约束（Hooks）、隔离执行（Subagents）和验证闭环（Verifiers）。文章详细探讨了各层的设计原则、常见陷阱及最佳实践，旨在帮助用户从“工具使用者”进阶为“系统设计者”，构建出在明确约束下能可靠自主运作的 AI 协作流程。

• 🤖 核心是代理循环：Claude Code 的核心是一个“收集上下文 → 采取行动 → 验证结果”的循环过程，而非单纯问答。性能瓶颈常源于错误的上下文或缺乏验证，而非模型智能不足。
• 🏗️ 六层系统框架：将 Claude Code 视为由 CLAUDE.md（契约）、Tools/MCP（能力）、Skills（方法）、Hooks（约束）、Subagents（隔离）、Verifiers（验证）构成的六层系统。只强化某一层会导致系统失衡。
• 🧠 上下文是治理问题：主要瓶颈常是上下文“太吵”而非“不够长”。需分层管理：常驻关键契约（CLAUDE.md），按路径加载规则（.claude/rules），按需加载工作流（Skills），隔离重型探索（Subagents）。
• 💡 Skill 设计精髓：Skill 是按需加载的工作流，非知识库。好 Skill 应有明确触发条件、完整步骤、清晰输入/输出，并将大型资料拆到支持文件中，以避免污染主上下文。
• 🔧 工具设计为 Agent 优化：给 Agent 的工具应命名清晰、参数明确、返回结果直接有用，并支持响应格式控制。避免暴露过多底层碎片化工具。
• ⚙️ Hooks 用于强制约束：Hooks 用于在 Claude 操作前后强制执行确定性逻辑（如格式化、保护文件、通知），弥补模型可能“忘记”遵守规则的情况，常与 CLAUDE.md、Skills 叠加使用以实现稳固约束。
• 🧪 Subagents 用于隔离：主要价值在于隔离上下文和权限，而非并行。用于执行会产生大量中间输出的任务（如代码扫描、测试），以保持主会话上下文的清洁。
• 💾 架构围绕提示缓存构建：高缓存命中率是降低成本和提高速率限制的关键。需保持系统提示和工具定义的静态性，动态信息（如当前

React 编译器与未来：编译器驱动 UI 框架的能力边界 - DEV 社区

本文对比了 React Compiler 与编译器优先的细粒度框架（以 Fict 为例）在技术路线、性能模型和语义约束上的差异，强调两者是面向不同工程目标的权衡，而非简单的优劣之争。

• 🧠 React Compiler 的核心作用：在 React 语义内通过自动记忆化优化渲染性能，减少手动useMemo/useCallback的使用，但未改变 React 基于组件调度的根本模型。
• ⚙️ Fict 的技术路线：采用编译器优先的细粒度响应式，在编译时构建依赖图，运行时通过信号传播执行更新，避免了全树 VDOM 对比，但仍有局部列表协调。
• ⚖️ 性能模型对比：React 优化渲染子树的开销，Fict 优化变更源到受影响绑定的传播路径；前者适用于 I/O 瓶颈或中等计算场景，后者在变更局部、依赖稀疏时更具优势。
• 🛡️ 语义与迁移成本：两者在副作用处理、错误边界等语义行为上存在差异，迁移至 Fict 需验证编译器覆盖边界和边缘情况，而 React Compiler 的迁移成本相对较低。
• 📊 工程决策依据：应基于具体场景（如 CPU 瓶颈、现有代码库规模、团队适应能力）选择，并依赖可复现的性能基准和语义对等测试，而非抽象论断。

克劳德代码实际选择什么——放大

本研究通过向 Claude Code 模型提出 2,430 次开放式问题，分析其在真实代码库场景下的工具选择偏好，发现其强烈倾向于构建自定义解决方案而非直接推荐现有工具，并在选择工具时表现出明确的默认技术栈倾向。

• 🛠️ 构建优先：在 20 个工具类别中的 12 个里，Claude Code 更倾向于构建自定义/DIY 解决方案（如自行实现功能开关、JWT 认证），而非推荐第三方工具。
• 🏆 明确偏好：当选择工具时表现出高度一致性，如 GitHub Actions（94%）、Stripe（91%）、shadcn/ui（90%）几乎形成垄断性选择。
• 🔄 模型代际差异：新版模型（Opus 4.6）更倾向于新兴工具（如 Drizzle 取代 Prisma）和自定义方案，呈现明显的“新近度梯度”。
• 🚀 默认技术栈：形成以 Vercel、PostgreSQL、Tailwind CSS、GitHub Actions 等为核心的 JS 生态默认工具链。
• ⚠️ 市场逆流：显著回避 Redux、Express、Jest 等传统流行工具，尽管这些工具在市场中仍被广泛认知。
• 🌐 部署分化：部署选择完全由技术栈决定——JS 项目 100% 选择 Vercel，Python 项目 82% 选择 Railway，传统云服务商未获主要推荐。
• 📊 高提取率：整体工具选择提取率达 85.3%，不同模型在 20 个类别中的 18 个上保持生态内一致。
• 💼 商业启示：为开发工具公司提供竞争分析基准，揭示 AI 代理在实际代码环境中的推荐模式。

TemPad Dev：MCP server 的设计与实现

本文详细介绍了 TemPad Dev 浏览器扩展如何通过实现一个本地的 MCP (Model Context Protocol) 服务器，将 Figma 设计稿的上下文信息高效传递给 IDE 和 AI 编程助手，从而在设计稿与代码生成之间架起桥梁。

• 🚀 背景与决策：在 AI 编程助手快速发展的背景下，作者决定为 TemPad Dev 扩展 MCP 能力，以程序化方式连接设计与工程环境。初期因官方 MCP 效果不理想而搁置，后因技术成熟度提升而重启开发。
• 🔌 架构核心：Hub 进程：为解决浏览器扩展无法直接与本地 IDE 通信的问题，引入了常驻本地的 Hub 进程作为中转。它通过 Unix socket 与轻量 CLI 通信，并管理来自浏览器扩展的 WebSocket 连接，实现请求路由。
• ⚙️ 进程协调与生命周期：通过文件锁机制确保同一时间只有一个 Hub 进程启动，并处理多客户端并发连接。Hub 按需存在，在最后一个客户端断开后自动退出，同时支持自动重连，确保服务稳定性。
• 🎯 多标签页与活跃扩展管理：Hub 维护所有已连接扩展的列表，并引入“活跃扩展”概念来路由工具调用。为避免浏览器多窗口焦点切换导致的误激活，采用手动切换而非自动切换策略。
• 🛠️ 工具设计：精简与整合：对外主要暴露 get_code（生成代码快照与上下文）和 get_structure（获取节点结构）两个工具。将截图、Token 定义、资源获取等功能整合或隐藏，以优化响应大小和减少 LLM 上下文干扰。
• 🧬 核心工具：get_code 管线：这是最复杂的工具，负责将 Figma 节点转换为 Tailwind 优先的 JSX/Vue 标记。其流程包括：构建可见树、样式采集与补全、变量名归一化、资产导出上传、渲染 Markup 以及 Design Token 输出。
• 🌳 可见树构建与优化：从选中的根节点开始，构建仅包含可见节点的树快照，并添加数据提示。通过识别矢量资产子树和可映射的组件实例，对树进行有效裁剪，避免输出噪声。
• 🎨 样式处理：采集、补全与转换：以 Figma 的 getCSSAsync API 为基础，针对其不足（如布局、渐变）进行大量补全和重写逻辑。最终将处理后的 CSS 映射为紧凑、类人手写风格的 Tailwind 工具类。
• 🔤 变量名归一化：通过逆向工程还原了 Figma 将变量名（含特殊字符）转换为合法 CSS 属性名的复杂规则，从而将样式中的变量引用准确关联回 Figma 的 Variable ID，为后续处理提供稳定锚点。
• 🖼️ 资产处理策略：将图片和矢量资源上传到本地 HTTP 资产服务，并在响应中提供稳定 URL。这避免了将 Base64 等大型数据直接塞入响应，从而节省宝贵的 LLM 上下文 token。
• 📝 富文本节点渲染：将 Figma 中扁平的富文本分段数据，通过标记栈等算法，逆向还原为语义化的嵌套 HTML 结构（如使用 <strong>、<em> 标签），并提升公共样式，生成更简洁、符合习惯的代码。
• 💾 Design Token 输出：解析并输出设计稿中实际使用的变量及其在不同模式下的值。支持沿 alias 链解析依赖，并通过插件系统允许用户自定义 token 名称的转换规则。
• ⚖️ 预算检查与错误处理：在服务端估算输出内容的 token 数量，并在超出预设预算时主动报错，引导客户端缩小选区或分块请求，避免因客户端静默截断导致数据结构破坏。
• 🔧 用户体验与配置简化：在 TemPad Dev 设置面板中提供针对不同 IDE/编程助手的一键配置功能，支持 Deep Link 跳转或复制配置片段，极大降低了用户启用 MCP 功能的门槛。
• 📖 辅助 AI 使用：为每个 MCP 工具编写了详细描述，并在 server instruction 中提供使用指南。同时，将基于 TemPad Dev MCP 的“Figma to code”技能发布到技能目录，方便用户通过一行命令安装。
• 🤖 开发与成文方式：项目代码主要通过与 AI（如 Copilot、Gemini、Codex CLI + GPT-5.x-Codex）协作的“vibe code”方式完成。本文的撰写也由作者与多个 AI 模型协作完成，用于确认逻辑、梳理大纲和文字审校。

工具

elastic-container

本文介绍了一个快速部署全容器化、TLS 加密的 Elastic 技术栈（包括 Elasticsearch、Kibana、Fleet 和检测引擎）的开源项目方案，并详细说明了其安装、配置与使用方法。

• 🚀 快速部署：项目支持在几分钟内启动一个预配置好的、容器化且 TLS 加密的完整 Elastic 技术栈，包含 Elasticsearch、Kibana、Fleet 和检测引擎。
• ⚠️ 项目声明：该项目并非由 Elastic 官方创建、赞助或维护，Elastic 不对其设计与实现负责。
• 📋 核心步骤：部署流程包括克隆代码库、安装必要工具、修改默认密码、执行启动脚本，最后通过浏览器访问本地 Kibana。
• 💻 系统要求：支持 Linux 和 macOS 系统，需要预先安装 Docker 套件、jq、curl 和 git 等工具。
• 🔧 灵活配置：用户可以通过修改环境配置文件来更改密码、Elastic 堆栈版本，并可以按操作系统批量启用预构建的检测规则。
• 🔄 脚本化管理：项目提供了统一的 Shell 脚本，用于一键执行启动、停止、重启、销毁、查看状态、清除数据、预拉取镜像等操作。
• ⚙️ 高级调整：支持通过修改 Docker Compose 文件来调整 Elasticsearch 的 JVM 堆大小以满足性能需求。
• 🤖 代理自动接入：文档说明了如何获取 Fleet 的注册令牌，并提供了通过 API 以及使用 WinRM 或 Ansible 脚本自动部署 Elastic Agent 的示例。

agent-safehouse

本文介绍了如何在 macOS 上使用 Agent Safehouse 工具为 LLM 编程代理设置沙箱环境，以限制其对文件和集成的访问权限，遵循最小权限原则，同时保持开发效率。

• 🛡️ 工具简介：Agent Safehouse 是一个基于 sandbox-exec 的沙箱工具，采用可组合的策略配置和“默认拒绝”模型，适用于主流编程代理和应用托管的工作流。
• 📦 安装方式：支持通过 Homebrew (brew install eugene1g/safehouse/agent-safehouse) 或独立脚本安装到 ~/.local/bin/safehouse。
• 🧭 设计理念：遵循“实际最小权限”原则，从全拒绝开始，仅允许代理完成工作所需权限，注重开发效率，并默认简化风险控制。
• ⚠️ 安全说明：该工具是加固层，而非能抵御坚定攻击者的完美安全边界。
• 📚 文档资源：提供官方网站、详细文档和策略构建器，网址分别为 agent-safehouse.dev、agent-safehouse.dev/docs 和 agent-safehouse.dev/policy-builder。
• 🖥️ 机器特定配置：支持通过 Shell 包装脚本和本地附加策略文件管理机器特定的默认设置（如共享仓库、缓存路径），便于团队协作时统一配置。

bippy

Bippy 是一个通过模拟 React DevTools 来访问 React 内部（如 Fiber 树）的工具包，无需修改 React 代码，适用于 React v17–v19，并提供了一系列实用函数来简化对 Fiber 树、Props、State 和 Context 的遍历与操作。

• 🛠️ 核心功能：通过模拟 React DevTools 的全局钩子（window.__REACT_DEVTOOLS_GLOBAL_HOOK__）来访问 React 内部 Fiber 树，无需修改 React 源码。
• 🚀 使用便捷：无需 React 源码知识，提供 instrument、secure 等函数安全地集成，支持在 React 应用运行前导入。
• 📦 安装与配置：通过 npm 安装，需在 React 之前导入（如在 Next.js 的 instrumentation-client.js 或 Vite 的入口文件顶部）。
• 🔧 实用工具：包括 traverseFiber（遍历 Fiber 树）、traverseProps/traverseState/traverseContexts（遍历数据）、overrideProps/overrideHookState/overrideContext（运行时覆盖数据）等。
• 🎯 高级特性：支持获取 Fiber 标识、源代碼位置、渲染计时，以及区分宿主 Fiber（如 DOM 元素）和复合 Fiber（如组件）。
• ⚠️ 注意事项：部分功能（如源代碼获取）仅限开发模式，且需要正确配置导入顺序和 TypeScript 设置。
• 📚 示例应用：可用于构建类似 React 性能分析工具，如高亮渲染元素，通过处理 onCommitFiberRoot 事件实现。
• 📖 术语解释：涵盖 Fiber、提交、渲染、宿主树等核心概念，帮助理解 React 内部机制。

GitHub - suhaotian/broad-infinite-list: 一款高性能、双向无限滚动列表组件，适用于大型列表渲染，支持 React/Vue/Expo。应用场景：流畅的双向聊天历史、新闻动态更新或日志流，无布局偏移。最适合大型滚动列表。· GitHub

broad-infinite-list 是一个用于高效渲染大型列表的轻量级组件，它通过仅显示有限范围内的项目来实现高性能，无需配置行高或使用固定高度，适用于聊天消息列表、新闻流列表和日志流等场景。

• 🔄 支持双向无限滚动
• ⚡ 高性能，仅渲染固定数量的项目
• 📏 动态高度，无需配置
• 🪟 支持窗口或容器滚动
• 🧩 支持 React、Vue 和 React Native
• 📦 轻量级，仅 2KB gzipped
• 🛠️ 提供丰富的 API 和自定义选项
• 📚 包含详细文档和示例

clewdr

ClewdR 是一个用于 Claude 服务的 Rust 语言代理工具，它通过提供 OpenAI 兼容的 API 端点，使现有客户端能轻松接入 Claude，并包含一个用于管理的小型 Web 管理界面。

• 🛠️ 核心功能：作为 Claude.ai 和 Claude Code 的代理，提供 OpenAI 风格的 API 端点，资源占用极低。
• 📦 部署简便：提供适用于多平台（Linux、macOS、Windows、Android）的单一静态二进制文件及 Docker 镜像。
• 🖥️ 管理界面：内置 React 管理仪表盘，支持实时状态查看、Cookie 管理、热重载配置，无需重启服务。
• ⚡ 高性能：典型生产环境占用内存 < 10 MB，启动时间 < 1 秒，二进制文件约 15 MB。
• 🔌 兼容性强：支持 Claude 原生及 OpenAI 兼容的聊天与代码端点，所有端点均支持流式响应。
• 🚀 快速开始：下载对应平台版本，运行二进制文件后，通过控制台显示的密码访问本地管理页面进行配置。
• 🔧 客户端集成：可轻松配置到 SillyTavern、Continue (VS Code)、Cursor 等支持 OpenAI API 的客户端中。
• 📚 更多资源：详细使用指南和配置说明可查阅项目 Wiki 页面。

更新

Vite 8.0 正式发布！ | Vite

Vite 8.0 正式发布，采用 Rolldown 作为统一的 Rust 构建工具，带来高达 10-30 倍的构建速度提升，同时保持插件兼容性，并引入了多项新功能与改进。

• 🚀 性能飞跃：Vite 8 集成 Rolldown 作为单一 Rust 构建工具，构建速度提升 10-30 倍，同时完全兼容现有插件。
• 🔗 统一工具链：整合 Vite、Rolldown 和 Oxc，实现从解析到压缩的全栈一致行为，支持更高级的优化功能。
• 📊 实际成效：多家公司报告生产构建时间大幅减少，如 Linear 从 46 秒降至 6 秒，Beehiiv 减少 64%。
• 🛠️ 新功能亮点：内置开发工具、TypeScript 路径别名支持、装饰器元数据支持、Wasm SSR 支持及浏览器控制台转发。
• 📦 安装大小：由于集成 lightningcss 和 Rolldown，安装包增加约 15 MB，团队将持续优化。
• 🔄 平滑迁移：提供兼容层自动转换配置，建议复杂项目先试用 rolldown-vite 包再升级至 Vite 8。
• 🌐 生态扩展：推出插件目录 registry.vite.dev，帮助开发者导航日益增长的插件生态。
• 🤝 社区致谢：感谢 Rollup 和 esbuild 的历史贡献，以及社区在测试和反馈中的关键作用。

发布 v2.0.0 · sindresorhus/emittery · GitHub

Emittery 2.0.0 版本发布，引入了重大变更、新功能及错误修复，主要更新包括监听器参数格式统一为对象、错误处理改进、Node.js 版本要求提升至 22，并新增生命周期钩子与 Disposable 支持等。

• 🚨 重大变更：监听器现在接收统一的 {name, data} 对象，而非原始数据，影响 .on()、.onAny()、.once() 及异步迭代器。
• ⚠️ 错误处理改进：emit() 在多个监听器抛出错误时，现在抛出 AggregateError 收集所有错误，而非静默丢弃后续错误。
• 📦 环境要求：最低 Node.js 版本从 14.16 提升至 22。
• 🔧 新功能：新增 init/deinit 生命周期钩子，用于在监听器订阅/取消订阅时执行设置与清理逻辑。
• 🧹 自动清理支持：.on() 和 .onAny() 返回的取消订阅函数现在支持 Disposable，可与 using 语句配合实现自动资源管理。
• 🔄 异步迭代器增强：.events() 和 .anyEvent() 返回的异步迭代器现在支持 AsyncDisposable，适用于 await using。
• 🎛️ 外部控制支持：为 .events()、.anyEvent() 和 .once() 添加 AbortSignal 支持，允许通过信号外部取消订阅。
• ⚙️ 配置扩展：.once() 现在接受选项对象 {predicate, signal}，而不仅是谓词函数。
• 🏗️ 装饰器兼容：Emittery.mixin() 现在同时支持旧版和 TC39 标准装饰器语法。
• 🐛 错误修复：解决了 emit() 静默丢弃多个监听器错误、调试日志器内部元事件噪音、子类中异步 emit() 覆盖被破坏、Proxy 包装失效及混合装饰器语法兼容性问题。

2026 年 3 月 - shadcn/cli v4 - shadcn/ui

shadcn/cli v4 正式发布，带来多项增强功能，旨在提升开发者体验并更好地支持 AI 编程助手。新版本引入了预设系统、技能包、新的 CLI 标志、项目模板以及对注册表功能的扩展，使设计系统的搭建、共享和维护更加高效和智能化。

• 🤖 AI 技能包：新增 shadcn/skills，为 AI 助手提供使用组件和注册表的完整上下文，使其能更准确地执行命令（如创建项目、添加组件）。
• 🎨 预设系统：通过 --preset 参数，可用一个代码字符串打包整个设计系统配置（颜色、主题、字体等），便于项目初始化、团队共享或与 AI 协作。
• 🔄 轻松切换预设：使用 init --preset 可快速在项目中切换不同的设计系统配置，CLI 会自动重新配置所有组件。
• 👁️ 预览与检查：新增 --dry-run、--diff 和 --view 标志，允许在添加组件前预览更改内容，便于人工或 AI 助手进行审查。
• 🚀 项目模板：shadcn init 现在支持多种框架模板（如 Next.js、Vite、Astro），并可通过 --monorepo 设置 monorepo，或通过 --base 选择 Radix 或 Base UI 作为基础。
• 📊 项目信息与文档：info 命令可显示项目完整信息，docs 命令可直接从 CLI 获取组件的文档和示例代码，为 AI 助手提供必要上下文。
• 📦 注册表增强：注册表现在支持通过 registry:base 分发整个设计系统，并新增 registry:font 类型，使字体安装和配置像组件一样简单。

Video.js | 开源视频播放器

本文介绍了 Video.js 10，这是一个完全重写的现代网页视频播放器，它通过模块化架构和独立的 UI 组件提供了高度可定制性，同时显著提升了性能。

• 🎬 模块化架构：Video.js 10 采用全新架构，UI 与媒体渲染器分离，每个组件独立并通过开放 API 协作，支持树摇和代码分割。
• ⚙️ 高度可定制：开发者可以完全控制播放器的各个组件，包括自定义错误对话框、控制按钮和皮肤样式，实现个性化设计。
• 📦 轻量高效：相比旧版本，Video.js 10 的初始加载时间大幅缩短（从 3.96 秒降至 0.75 秒），文件大小从 200kB 减少到 38kB，显著提升用户体验。
• 🔧 现代化开发：专为现代 JavaScript 打包工具设计，提供 React 组件库和完整的 CSS 样式系统，支持响应式设计和无障碍访问。
• 🚀 开发路线图：包含技术预览（2025 年 10 月）、测试版（2026 年 3 月）、正式版（2026 年中）和功能完善（2026 年底）四个阶段。
• 🤝 企业支持：由 Mux 作为企业赞助商领导开发，提供 CDN、设备测试和静态托管等基础设施支持。

Astro 6.0 | Astro

Astro 6.0 正式发布，带来了一系列新功能和改进，包括内置字体 API、内容安全策略 API 以及支持实时内容集合，同时重构了开发服务器和构建管道，提升了开发与生产环境的一致性。

• 🚀 开发服务器重构：利用 Vite 新环境 API，开发时可直接运行生产环境，减少“开发正常、生产出错”的问题，尤其优化了对 Cloudflare Workers、Bun 和 Deno 等非 Node.js 运行时的支持。
• 🌐 增强 Cloudflare 适配：开发、预渲染和生产阶段均运行 workerd 运行时，本地即可使用 Cloudflare 平台 API 和绑定，无需模拟层。
• 🔤 内置字体 API：简化自定义字体配置，支持本地文件或 Google 等提供商，自动处理下载、缓存、优化回退字体和预加载链接，提升性能与隐私。
• 📄 实时内容集合：稳定功能，支持请求时获取外部托管内容，内容更新即时生效，无需重新构建，可与构建时集合共存。
• 🛡️ 内容安全策略（CSP）：稳定 API，为静态和动态页面提供内置 CSP 配置，自动哈希脚本和样式，支持自定义指令和算法。
• 📦 依赖包升级：包括 Vite 7、Shiki 4、Zod 4，并需 Node.js 22 或更高版本，提升性能和安全性。
• ⚙️ 实验性 Rust 编译器：替代原有 Go 编译器，速度更快、诊断更强，可通过标志启用，未来计划设为默认。
• ⚡ 实验性队列渲染：新渲染策略，采用两阶段处理，早期测试显示渲染速度提升高达 2 倍，更高效内存使用。
• 💾 实验性路由缓存：平台无关的服务器渲染响应缓存 API，支持设置缓存时长、重新验证窗口和标签，与实时内容集合集成自动失效。
• 👥 社区贡献：感谢核心团队及众多贡献者的代码、文档、审查和测试工作，推动 Astro 6 的完善。

设计

设计流程已死：Anthropic 设计负责人 Jenny Wen 谈 AI 时代的设计变革

本文基于 Anthropic 设计负责人 Jenny Wen 在 Lenny's Podcast 的访谈，探讨了 AI 时代设计流程的颠覆性变革。她指出传统设计流程（如双钻石模型）已无法适应工程效率的暴增，设计师的角色正从“流程执行者”转向“协作引导者”。AI 虽在品味与判断上持续进步，但人类在决策、责任与愿景规划上的价值不可替代。Jenny 还分享了 AI 产品的迭代逻辑、团队管理心得，以及未来设计师需具备的跨领域能力。

• 🚨 传统设计流程失效：经典“发散 - 收敛”模型因工程速度提升而瓦解，设计师做稿时间从 60-70% 降至 30-40%，更多精力转向与工程师协作甚至直接编码。
• 🏃 愿景规划周期缩短：产品愿景从 2-5 年压缩至 3-6 个月，输出形式从精美演示稿变为指向性原型，强调快速验证。
• 🤖 AI 与人类价值的平衡：AI 在品味和判断上持续进步，但软件构建中最难的部分并非技术实现，而是人际决策与责任承担，人类仍是最终责任主体。
• ⚡ Co-work 的诞生逻辑：外部传闻“10 天开发”实为长期探索后的冲刺，产品信任靠快速响应用户反馈建立，而非完美发布。
• 🧩 未来设计师的三类原型：方块型强通才（多领域深度）、深 T 型专家（单一领域顶尖）、有匠心的应届生（快速学习、无固化思维），第三类在变革期尤其珍贵。
• 🛠️ 工具链的演变：Figma 仍用于发散探索与视觉微调，但设计师需掌握 AI 编码工具（如 Claude Code），IDE 逐渐成为产品侧的高效调整工具。
• 🌐 界面范式的融合：未来交互将是“可点击 UI + 对话”结合，模型动态生成界面可能成为趋势，聊天范式不会消失但会与特定任务 UI 互补。
• 🔍 管理者的新定位：纯粹“人员管理”角色可能弱化，未来管理者需兼具方向指引与实操能力，亲身参与低杠杆工作反而能创造高价值信号。
• 💡 识别创新机会的方法：关注“不可读但有能量”的内部原型（如 Claude Studio），模糊的用户兴奋点常是突破性产品的雏形。
• 🧠 设计思维的隐性挖掘：AI 可帮助设计师分析个人笔记与决策记录，提炼出自身未意识到的评估标准，从而提升自我认知与专业判断。

AI

据 The Information 报道，OpenAI 正在开发替代微软 GitHub 的产品。

OpenAI 据报正在开发一款对标微软旗下 GitHub 的代码托管平台，该项目尚处早期阶段，可能在未来数月内推出并考虑向客户销售，此举或使其与重要投资者微软形成直接竞争。

• 🛠️ 项目启动原因 – 因近期 GitHub 服务中断问题频发，OpenAI 工程师决定自主开发替代平台。
• ⏳ 开发阶段 – 项目仍处于早期，预计需数月时间完成，具体发布时间未定。
• 💡 商业模式 – 团队考虑将平台作为产品向现有客户群出售，可能开辟新营收渠道。
• ⚔️ 竞争关系 – 若产品上市，OpenAI 将与持股方微软直接竞争，凸显其业务扩张野心。
• 📈 市场背景 – OpenAI 近期以 8400 亿美元估值完成巨额融资，显示 AI 领域投资热度持续高涨。

其他

你的经理已经在投资于你

许多职场人渴望得到上级的“指导”与“mentorship”，却可能忽视了日常工作中已存在的成长支持。本文指出，管理者通过具体、即时的反馈，实际上已在投资你的发展；关键在于如何识别并主动争取更多有效指导。

• 💡 别理想化“指导”形式：管理者未必会以理想化的方式提供指导，日常工作中具体的改进反馈就是对你的一种投资。
• 🔍 识别现有支持：若管理者愿意指出问题并提供改进建议，这本身就是一种 coaching 和 mentoring。
• 🎯 争取更多反馈：展示反馈能为业务创造价值，让管理者觉得投入时间值得。
• 🌱 成为值得投资的人：展现快速学习能力、主人翁意识和持续进步，让管理者更愿意指导你。
• 💬 鼓励直接沟通：主动邀请管理者直言不讳地批评，减少其反馈时的心理负担。
• ❓ 提出具体问题：避免模糊的成长提问，转而针对具体工作场景寻求改进建议，降低管理者回答难度。
• 📝 善用引导性问题：通过“你会怎么做？”“哪里可以更好？”等问题，激发管理者的具体指导。

与高管对话：那不是脱轨，那是会议本身

与高管沟通时，核心目标不是证明自己正确，而是确保被理解，从而帮助他们做出明智决策。关键在于清晰传达业务影响、控制风险并建立信任，而非展示技术细节。

• 🎯 沟通目标：高管会议的重点是促进决策，而非单向演示；需以高管关注的业务风险、清晰度和决策需求为中心。
• 📖 个人教训：作者早期因坚持技术术语而失去汇报机会，学会高管对话中每个词都需谨慎，灵活应对话题转向。
• 👥 人性化视角：高管也是普通人，过度紧张或形式化的准备（如精美幻灯片）可能不必要；自然、直接的交流更有效。
• 🧩 四 C 框架：确保沟通具备清晰性（避免行话）、上下文（关联业务全局）、后果（明确决策影响）和控制力（展现对主题的掌控）。
• ⚙️ 技术校准：根据听众背景调整技术细节深度，避免过度解释或解释不足，重点强调业务影响、客户影响和风险。
• 🕒 时间管理：预留一半时间用于讨论和提问，高管会议常被打断，需灵活应对。
• ❓ 诚实应对：不知道答案时坦诚承认并承诺后续跟进，比猜测更能维护可信度。
• 🔄 解读信号：将高管的中途打断或深入提问视为兴趣信号，顺势探讨而非强行回归原议程。
• ⏱️ 简洁价值：高管日程紧凑，直接简洁是尊重其时间的表现，而非漠不关心。
• 🤝 建立信任：通过减少模糊性、促进共识和揭示风险来赢得信任，推动有效决策。

人人都在装龙虾，但装完之后能干嘛？

本文探讨了近期国内兴起的“龙虾”（实指 AI Agent，如 OpenClaw）热潮。文章指出，这股热潮已从技术圈蔓延至大众、企业乃至政府层面，形成了广泛的安装与讨论，但其核心应用场景尚不明确。作者认为，这种现象类似于新操作系统的早期阶段，虽伴随泡沫与迷茫，却真正实现了不同平台间的生态连接，并已展现出清晰的商业变现潜力。热潮背后的“空生态”恰恰预示着巨大的机会，未来红利属于那些能真正解答“装龙虾后能做什么”并创造具体价值的人。

• 🦞 热潮现象：AI“龙虾”热度席卷全国，从云服务、硬件到各类软件产品纷纷蹭此概念，引发全民安装狂热，甚至成为一种“跟上时代”的身份象征。
• 🤔 灵魂提问：多数用户在安装后普遍感到迷茫，发出“装了能干嘛？”的疑问，这与早期操作系统（如 Windows）普及时的状态相似，应用生态尚处空白。
• 🏛️ 政府推动：地方政府（如深圳、无锡）反应迅速，出台专项政策支持，推动“一人公司”（OPC）模式，降低创业门槛，为热潮注入长期发展信心。
• 💰 商业变现：热潮已产生真实商业价值：模型公司（如 Kimi）收入暴增；云厂商、硬件商销量飙升；甚至催生了上门安装等新兴副业，用户与企业都展现出强烈付费意愿。
• 🔗 生态破壁：此前封闭的企业 IM 生态（如飞书、企业微信）主动接入开放标准，打破了多年建立的平台壁垒，使 AI 应用能更轻易进入企业，实现了“重新连接”。
• 🎯 空即机会：大众不知“龙虾”能做什么，恰恰说明上层生态空白，这正是最大的机会所在。真正的赢家将是能在此生态中找准位置、创造独特价值并回答“能干嘛”的人。