2025-第三十三周

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

技术

React 缓存：关键在于一致性

React Cache 的核心价值在于确保 React Server Components 渲染期间数据的一致性，而不仅仅是优化重复请求。通过缓存机制，可以避免因组件渲染时间差导致的数据不一致问题。

• 🌀 React 的 cache 函数不仅用于数据去重和优化，还能保证整个 RSC 渲染期间数据的一致性。
• 🌐 示例中，两个组件 ReactsPageTitle 和 ReactsPageDescription 通过 cache 共享同一份 HTML 数据，避免重复请求。
• ⏳ 当组件渲染时间不同（如被 SlowComponent 包裹时），未使用 cache 可能导致数据不一致（如页面内容中途变更）。
• 🔄 cache 的缓存仅在单次 RSC 渲染期间有效，刷新页面会重新创建缓存。
• 🛠️ Next.js 等框架默认对 fetch 请求启用 cache，但非请求操作（如 SQL 查询）需手动处理一致性。
• 📊 仪表盘场景中，通过缓存时间戳（如 new Date()）确保多个 SQL 查询基于同一时间点，避免数据矛盾。
• ⚠️ 不纯数据（如网络请求、数据库查询、Date）是一致性的主要威胁，需用 cache 隔离变化。
• 🌳 可预测性是优秀组件的关键：同一渲染中，无论组件位置或是否被延迟，输出应保持一致。
• 💡 理想情况下，React 应强制不纯操作使用 cache，但可能增加开发负担。
• ❓ 若组件需复用、随意嵌套或保持输出稳定，必须重视 cache 的作用。

一个使用 Web 组件和 CSS 模块脚本的优雅香草应用架构

构建数字界面时，组件化开发是核心思想，通过组合独立组件（如按钮、卡片、页眉等）来创建界面。JavaScript 框架（如 React、Vue）推动了这一理念，但如今我们能否在不依赖构建工具或框架的情况下实现组件化？答案是接近可行。

• 🏗️ 组件化开发：通过独立组件（如按钮、卡片、页眉）构建界面，类似“原子设计”理念。
• 🔧 框架推动：React、Vue 等框架强化了组件化开发模式。
• 🚀 无框架尝试：探索无需构建工具或框架的组件化项目，使用原生技术（如 Web Components）。
• 📁 组件结构：组件按文件夹组织，包含模板、逻辑和 CSS 文件，支持复杂场景（如 GraphQL、测试）。
• 💡 Web Components：无需框架即可使用，但需 JavaScript 实例化（如 Lit 轻量库）。
• 🧩 CSS 集成问题：传统依赖打包工具（如 webpack、Vite）注入 CSS，但原生方案有限。
• 🌐 CSS Module Scripts：原生 JavaScript 方案，支持直接导入 CSS 为可构造样式表，但目前仅 Chrome 兼容。
• ⚠️ 兼容性限制：CSS Module Scripts 的浏览器支持有限（Chrome 可用，Firefox 和 Safari 未支持）。
• 📝 语法示例：正确导入 CSS 模块的语法为import sheet from './styles.css' with { type: 'css' };。
• 🛠️ Lit 应用：在 Lit 中，可通过static styles = [sheet];将 CSS 模块应用到 Web 组件的 Shadow Root。

为什么大型语言模型无法真正构建软件

本文探讨了高效软件工程师的核心能力——建立和维护清晰的思维模型，并对比了当前大型语言模型（LLM）在编程中的局限性。作者认为，尽管 LLM 能生成代码和辅助简单任务，但缺乏维持复杂思维模型的能力，导致其在迭代和调试中表现不佳。文章强调，工程师仍需主导开发过程，而 LLM 仅作为辅助工具存在。

• 🧠 思维模型的重要性

  • 高效工程师的核心能力是建立并维护清晰的思维模型，以指导代码编写和需求调整。

• 🔄 软件工程循环

  • 工程师的典型工作流程：理解需求→编写代码→验证差异→迭代修正。

• 🤖 LLM 的局限性

  • LLM 擅长生成代码和简单修复，但无法维持长期一致的思维模型，易因测试失败或混淆而重启。

• 🚧 当前模型的缺陷

  • 上下文遗漏、近因偏差和幻觉问题严重限制了 LLM 处理复杂任务的能力。

• 🛠 工程师的优势

  • 人类能灵活切换上下文、聚焦细节或全局，并通过协作解决问题，而非盲目依赖生成。

• 🔮 未来展望

  • 需改进模型架构（如添加记忆功能）以接近人类的思维模型能力，但短期内 LLM 仍是辅助工具。

• 💡 实用建议

  • 工程师应清晰定义需求并验证代码，LLM 适用于简单任务或文档生成。

• ✨ Zed 的愿景

  • 倡导人与 AI 协作开发，但强调工程师的主导地位。文末附 Zed 编辑器下载和招聘信息。

工具

marker

Marker 是一个高效、多功能的文档转换工具，支持多种格式和功能，适用于研究和个人使用，部分商业用途需遵守许可限制。

• 📄 格式转换：支持 PDF、图片、PPTX、DOCX、XLSX、HTML、EPUB 等多种文件格式转换为 Markdown、JSON、HTML 等。
• 🏗️ 结构化处理：提取表格、表单、公式、代码块等，并支持自定义 JSON 结构（Beta）。
• 🚀 性能优势：比云服务（如 Llamaparse、Mathpix）和其他开源工具更快，批量模式下可达 25 页/秒（H100）。
• 🤖 LLM 增强：通过 --use_llm 标志使用 Gemini 或 Ollama 等模型提升准确性（如表格合并、数学公式处理）。
• 🖼️ 图像处理：提取并保存文档中的图像，支持 OCR 强制处理（--force_ocr）。
• 💻 多平台支持：可在 GPU、CPU 或 MPS 上运行，支持批量处理和分布式多 GPU 转换。
• 🌍 多语言兼容：支持所有语言的 OCR（基于 Surya），无需 OCR 时无语言限制。
• 📊 商业许可：研究和个人免费，商业使用需满足收入/融资限制（或购买授权）。
• 🛠️ 扩展性：可自定义处理逻辑、输出格式，支持 API 和 Python 集成。
• 📉 基准测试：在速度和准确性上优于竞品（如表格提取得分 0.816，LLM 模式提升至 0.907）。
• ⚠️ 已知限制：复杂布局或嵌套表格可能处理不佳，但可通过 LLM 和强制 OCR 缓解。

open-lovable

这是一个名为 "open-lovable" 的开源项目，旨在通过 AI 聊天快速构建 React 应用。以下是关键信息：

• 🚀 项目目标：通过与 AI 交互即时构建 React 应用，支持克隆并快速重建任何网站为现代化 React 应用。
• ⚙️ 技术栈：基于 TypeScript（占比 98.9%）、Next.js、Tailwind 等，使用 MIT 许可证开源。
• 📥 安装要求：需配置 E2B（沙盒环境）和 Firecrawl（网页爬取）的 API 密钥，并至少选择一种 AI 服务提供商（如 Anthropic/OpenAI/Groq）。
• 🛠️ 快速启动：克隆仓库后运行 npm install 和 npm run dev 即可本地开发（端口 3000）。

activepieces

Activepieces 是一个开源的自动化工具，旨在替代 Zapier，提供可扩展的 AI 自动化解决方案。

• 🌪️ 文档齐全：提供详细的文档支持。
• 🖉 创建模块：支持用户自定义模块（Pieces）。
• 🔥 部署灵活：可轻松部署并使用。
• 🤯 AI 优先：内置 AI 模块，支持多种 AI 提供商，并提供 Copilot 辅助流程构建。
• 💖 用户友好：界面直观，适合技术与非技术用户，学习曲线平缓。
• 🌐 开源生态：所有模块开源，60% 由社区贡献，可在 npmjs.com 获取。
• 🛠️ TypeScript 开发：模块基于 TypeScript，支持热重载，提供最佳开发者体验。
• 🏢 企业级支持：支持品牌定制与数据控制，适合团队协作。
• 🔒 安全设计：支持自托管和网络隔离，确保数据安全。
• 🧠 人工干预：支持延迟执行或审批流程，灵活适应业务需求。
• 💬 人机交互：内置聊天和表单界面，方便用户输入。
• 🔄 强大构建功能：支持循环、分支、自动重试、HTTP 请求、代码片段等。
• 🔌 丰富集成：支持 Google Sheets、OpenAI、Discord 等 200+ 服务，并持续扩展。

flyde

一个开源的可视化 AI 工作流工具，直接集成在 VS Code 中，支持 TypeScript，提供丰富的标准库和可视化调试器，适合团队协作开发 AI 驱动的后端逻辑。

• 🛠️ 集成开发环境：提供 VSCode 扩展和运行时库，无缝集成现有 TypeScript 代码
• 📚 丰富功能：内置标准库、可视化调试器和 TypeScript 支持
• 🚀 快速开始：支持浏览器 Playground、CLI 工具和手动安装
• 🔗 代码库集成：直接在代码库中运行，与现有后端框架和 CI/CD 管道集成
• 🤖 可视化 AI 工作流：用于原型设计、集成和迭代 AI 密集型后端逻辑
• 👥 降低协作门槛：连接开发者和非开发者，促进团队协作
• 🎯 目标用户：产品团队、开发 AI 后端的工程师及需要可视化清晰度的团队

AI

cursor-talk-to-figma-mcp

该项目实现了 Cursor AI 与 Figma 之间的模型上下文协议（MCP）集成，使 Cursor 能够与 Figma 通信，以编程方式读取和修改设计。项目包含 MCP 服务器、Figma 插件和 WebSocket 服务器，支持多种设计自动化功能，如批量文本替换、实例覆盖传播等，并提供详细的开发指南和工具列表。

• 🚀 项目目标：通过 MCP 协议实现 Cursor 与 Figma 的集成，支持设计自动化操作。

• 🛠️ 技术栈：TypeScript MCP 服务器、Figma 插件、WebSocket 通信。

• 📂 项目结构：

  • src/talk_to_figma_mcp/ - Figma 集成的 MCP 服务器
  • src/cursor_mcp_plugin/ - Figma 插件
  • src/socket.ts - WebSocket 服务器

• ⚡ 快速开始：

  • 安装 Bun 并运行bun setup
  • 启动 WebSocket 服务器：bun socket
  • 安装 Figma 插件（社区版或本地开发版）

• 🎥 功能演示：

  • 批量文本替换（贡献者@dusskapark）
  • 实例覆盖传播（减少重复设计工作）

• 🔧 开发配置：

  • 更新 MCP 配置指向本地目录
  • 手动设置 MCP 服务器和 WebSocket 服务器

• 💻 Windows + WSL 支持：

  • 通过 PowerShell 安装 Bun
  • 修改socket.ts以允许 WSL 连接

• 🛠️ MCP 工具：

  • 文档与选择（如get_document_info、get_selection）
  • 注释管理（如set_annotation、scan_nodes_by_types）
  • 原型与连接（如create_connections）
  • 元素创建与修改（如create_text、set_fill_color）

• 📝 最佳实践：

  • 操作前先加入频道并获取文档信息
  • 使用批处理操作提高效率
  • 错误处理和进度监控

其他

管理资深工程师的常见问题

作者分享了管理资深工程师的经验，指出他们虽然技术娴熟，但仍需针对性指导，并归纳了四种常见类型及其应对策略。

• �️ 资深工程师更需要管理：与预期不同，资深工程师反而需要更多指导，作者总结了四种常见类型。
• 🏗️ 过度设计型：热衷于复杂方案，需引导回归客户价值，强调简单可行方案并设置约束。
• 📝 跳过设计型：直接投入开发，需明确设计阶段的价值，鼓励先规划后实施。
• ❓ 模糊需求型：面对模糊需求易迷失，需教会提问和逆向思考（如“如何确保失败？”）。
• 🚀 单打独斗型：不愿协作，需帮助拆分并行任务并建立团队信任。
• 🌟 总结：资深工程师的优势可能成为盲点，管理者需通过教练式引导助其成长，从而提升团队整体能力。