阅读笔记 - 2026-02-08

• 创建了一个自建的 excalidraw 的实例，并给他支持了 mcp
• 可以用 ai 控制 excalidraw 画图，比如使用 prompt

"Draw an architecture diagram showing a user connecting to an API server which talks to a database”

• 需要维持一个与 excalidraw 实例的连接（他是用 streaming 模式绘图的）

• 价值：有趣，但可能不如 drawio llm，后者有自己的 prompt 封装
• 风险：光只有这个 mcp 可能无法控制绘图质量
• 适用条件：娱乐用途

• 快速部署 openClaw
• 1分钟内搞定起服务，申请账号，开虚拟机，连接 im 等工作

• 脚本化的开启云服务来承载
• 自动创建bot

• 价值：其实就是工程方法的服务化，适合快速上手的用户
• 风险：不知道他里面有没有什么后门或者漏洞
• 适用条件：如果有人想要快速尝试，可以推荐，自己玩就算了

• 使用 gemini 快速生成的广告视频，创意，音乐和文案，演员对口型，都很完美
• 广告从业者会受很大冲击

• gemini seedans2.0
• 所展示的图片
• prompt: [动作] 大家拿着瓶子做动作 [音效] 动感音效，指定主要台词 12-15s [收尾：品牌定格] [画面] 所有人对着画面说台词，并做表情，最后定格在产品上

• 价值：极大的提高广告短片的创造速度，很有可能会形成某种迷因在互联网传播
• 风险：出片质量低，还是需要有广告经验的从业者指导，或者需要抽奖
• 适用条件：低预算的新产品广告投放，或学生作品

• 直接使用 mcp + jina reader 能快速获得公开内容，分析后输出到 obsidian 中
• 使用 mcp 是为了让 ai 能直接调用工具，省掉中间层
• 他给他的 puppeteer-mcp 加了 jina 支持，实现对反爬网站的支持

• 直接 mcp + jina reader ，如果遇到反爬就是 puppeteer
• 使用 puppeteer-mcp 增加了 jina 支持
• 使用 obsidian 作为数据收集

• 价值：很好的方法论，我的阅读记录也可以使用
• 风险：puppeteer-mcp 看起来需要一些改造，不确定是怎样的改造
• 适用条件：可以快速尝试

• agent code 时代，在多个上下文中快速切换比文件选择更重要
• 所以一定要多建立快捷跳转工具

• 他做了一个 skill 专门让 agent 能快速在多个项目中切换，并启动相关任务

• 价值：没太大价值，但是一个值得学习的思路
• 风险：风险就是没什么用，项目扩展起来这个多一层维度
• 适用条件：适合大量的轻量项目之间的切换，比如文章写作这类

• 可自部署的终端日志
• 支持 docker 部署，完全本地可导出，支持语义搜索，而且提供了与 llm 结合的接口，直接调用 llm 调用日志
• 使用一种本地向量存储 memvid，支持语义化搜索
• 多种 ui ，有日历视图，也可以和 llm 聊天
• 还提供了一个 rpi 的开源硬件方案，提供了所有3d打印材料

• 一键部署，快速在终端唤起，并输入
• 简单的日志方案，支持日期和 tag ，还有向量搜索和llm支持
• 不知道他的硬件方案怎么和输入设备连接，难道是 ssh 上去？

• 价值：和我之前的键盘副件的笔记工具很像，但自成体系，无法和现有工作流结合
• 风险：项目不知道未来如何扩展，有可能未来大家不需要这种形式的日志工具了呢
• 适用条件：可以作为参考，具体设施比如 memvid 加入到我的项目中，是一个很高完成度的项目

• 传统的项目 issue 管理是针对人类的，不是针对 ai 的，和 ai 的工作流不符合。
• 比如，所有的任务都是在同一个设计文档中的，文件更新是跟随 commit 的，不需要网络服务的 auth 等，就是以文件读写为优先方案，而且是以设计文档为中心，而不是 issue
• 而且他还解决了人与 agent 的交互，拆分了需求文档评审和 agent 演化工作流

• 提供了 emacs 插件，和 claude code 插件，这样两边都可以用相同的方式工作
• 设计文档放单独文件，里面使用 org mode headline 记录代办任务
• 工作流：Draft → Review → Accepted → Active → Complete
• 他有一套更基础的工作流设计，在 https://github.com/farra/dev-agent-work

• 价值：适合一些长期的任务迭代的项目，而且架构清晰，很有可以参考的意义。但他集成 emacs 的价值暂时没看出来。可能方便人类学习
• 风险：需要依赖 claude code ，不知道对 codex 是否也合适
• 适用条件：可以作为参考项目构建流程

• 使用 js 管理所有 vendor 或 provider 还有应用或设施，以提供代码化的 serverless 配置

• 实现了 sst 方案，可以用 js 来做相关配置，比如

  const db = new planetscale.Database("Db")
  
  const email = new sst.aws.Email("Email", {
  sender: "mail@example.com"
  })
  
  const api = new sst.aws.Service("Api", {
  memory: "4 GB",
  image: "./rails",
  link: [db, email]
  })
  
  const web = new sst.aws.Nextjs("Web", {
  link: [api],
  path: "./nextjs",
  domain: "example.com",
  dns: sst.cloudflare.dns()
  })
  

• 价值：可能会适合 ai 能更方便的做 serverless 服务编排，但也未必，因为 aws 的 yaml 是行业规范
• 风险：可能不适合国内的服务，比如 aliyun
• 适用条件：可能适合由 ai 快速起大量服务的中间件。但对小规模的服务可能直接用一站式解决方案会更方便

• ai的编程能力如初级毕业生，有广泛的知识但对具体项目意图缺乏了解，所以开发者应该细心指导他们
• ai在有明确测试覆盖或api参考时，效果会好，适合在完成一个适配后，迁移到其他服务的适配工作
• 作者会把阅读和思考也发给 cc ，并通过 docker 来运行 cc 以获得最大的可用性
• 有时他也会开启 worktree 但多数时候还是传统单线程开发
• 要充分利用自己的专业知识，然后要 ai 来帮助自己，把 ai 加入自己的工作流而不是去适应 ai
• mcp 对 ai 编程没用

• zed + docker 驱动的 claude code
• 做笔记使用 markdown

• 价值：传统的 ai 编程派，还是以自己技能优先的角度上引入 ai
• 风险：可能对 ai 的初始 adopt 需要一些工作，不是任意上来的项目都可以直接做
• 适用条件：适合一个相对成熟的项目，是一个中间状态的 ai 编程辅助的思路。长期来说 ai 编程应该是充分适配 ai 工作流的，比如如何快速起一个项目，快速上线，快速测试，都应该能由 ai 来完成，甚至是 ai 来负责。人的工作就是随时授权，随时回滚。

• 适合单人公司的资产管理、项目管理、文件管理（比如合同），以及 ai 助手提供的财务建议

• 使用 gemini 和 openai

• 价值：适合快速的单人公司，但也未必一定要这样，文件目录+cc说不定就够了。但他使用 https://supabase.com/ 来快速构建应用的尝试值得学习
• 风险：过于传统，无太多价值
• 适用条件：项目开发的参考

• 利用 orgmode 和协议，在多个用户之间同步 org file ，从而实现社交功能
• 纯文本，直接使用 emacs 作为编写器和阅读器，所有的编辑习惯都可以迁移
• 通过 p2p 协议在多个服务之间相互同步，引入了多级 relay server 作为跳板

• 价值：没啥价值，还不如把 org 文件发布到 github pages ，还能当 awesome 项目来用
• 风险：还要自己部署服务
• 适用条件：可能做某种同步协议的基础实验？

• python 不需要单例类，所有单例类都有各种问题：
  • 装饰器：暴露的类变成了暴露的函数了
  • 单例类覆盖 __new__ ，但这样无法覆盖 __init__
  • 单例类使用 metaclass ，但如果这个类被人当普通类调用，传参进去或覆盖掉其他实例的属性，不安全
• 真要使用，不如就是 module 中的全局变量，如果还需要暴露 class 做 isinstance 操作，可以暴露一个 _instance 的实例

• 价值：八股文的讨论和去魅
• 适用条件：面试或网络讨论

• 使用 guix 作为容器方案，只暴露 share 的目录，其他的方法都由 guix 限制
• emacs 是最好的 llm 容器，让 guix 提供 emacs 就有了所有的 function call 的能力和 ai 编辑能力

• 使用 guix 创建一个 container / jail / chroot
• 作者使用了 emacs 做 guix 的配置，所以做了个小脚本来 parse 配置

• 价值：可以尝试，但主流还是 docker 和 vm ，其他方案没有太多可研究的价值
• 风险：不如 docker 灵活，不如 vm 安全
• 适用条件：作为实验

• 介绍了多种 react component 的防御性编程策略，让 react component 尽量在不同使用环境中保持可用
• 具体的就是在 ssr/csr 的不同场景，节点在 iframe / host 等，组件本身对全局的副作用等的消除
• 属于经验之谈，是成熟组件库构建都可以学习的文档

• 价值：经验之谈，可能可以分享给 web 组件库开发者们，或许也可以成为代码 review 的 skills
• 想法：软件工程的一个要点就在于，我能否在开发完成交付后，我即使不再维护，代码都能稳定运行的。