Posts

回顾过去我做过的事情，在职业生涯早期做了2年多的业务开发，就是压根不带脑子按照需求完成就可以，有严格的需求评审流程，有导师帮忙评估实现难点，有测试帮你做上线前的质量把关，我只需要想清楚业务逻辑，活做完一个接一个，做了2年左右就有点乏味了。 后面加入了一个比较大的前端团队（非常不错的团队），开始有机会在内部孵化产品，开始从 0 到 1 做一个产品，这里也是有产品、设计师，但话语权慢慢变多了，不再仅仅是评估能不能做，开始尝试挑战产品合理性，那会儿还搞过封闭开发，是一段值得怀念的岁月。 而今天我在一家 Startup，我不定义我是一个前端工程师或后端工程师，那我是什么呢？我是一个 Builder 。我拥有了更大的 Scope，我可以引进我想要的技术方案，我可以决定界面上的每一个字号需要设置多大，或者是每一个间距的 px 需要设置多少，我可以完成我想要的产品的交互实现，我影响着产品的方方面面。这正是 Startup 魅力所在，现如今的大厂很少能有这种氛围。 作为产品 Builder，好的架构是成功的开始 前台“对话智能”由 Workus-agent Rust agentd 承担，Workus-ai 做 WebSocket 网关和 UI 状态管理。 后台 “任务执行 Runtime” 由 Workus-ai 的 Campaign orchestration 承担，按 sales/sourcing 分别落到 Temporal 或事件驱动 Job 编排。 Workus 的对话 Agent 运行时 它负责 Agent Session、推理循环、工具调用、确认流程和事件流输出。 Session Runtime：维护每个用户对话的 Agent Session，支持继续对话、历史恢复、compact、rollback、cancel 等操作。 Reasoning Loop：接收 start_task / user_input，驱动模型理解需求、规划步骤、选择工具。 Tool Execution：调用 sourcing、sales、review、create task card 等工具能力。 Human-in-the-loop：支持确认点、结构化补充信息、用户审批或修改。 Event Streaming：把 assistant message、tool call、tool result、UI card、状态变化等作为事件流输出给 workus-ai。 ...

生化危机女主角 Milla Jovovich 刚在 GitHub 开源了一个 AI 记忆系统，在行业标准 benchmark 上拿了有史以来第一个满分。 没错，就是那个爱丽丝🤯 为什么 Milla 要自己做记忆系统？ Milla 在AI对话中积累了几个月海量决策、思考和灵感，结果发现现有记忆系统（如 Mem0、Zep 等）总让 AI “决定”什么值得记住，导致大量宝贵上下文被丢弃。她亲自体会到痛点后，决定自己动手。 她借鉴古希腊“记忆宫殿术”（Memory Palace），把记忆组织成可导航的空间结构： Wing（翅膀）：顶级容器，对应人、项目或主题； Room（房间）：具体想法或子主题； Hall（大厅）：按类型（如事实、事件、发现、偏好、建议）关联房间； Tunnel（隧道）：跨 Wing 的交叉引用； Closet（衣柜）：压缩摘要； Drawer（抽屉）：原始文件永不丢失。 核心技术亮点包括： AAAK无损压缩：30倍压缩文本，任何LLM都能直接阅读，无需解码器； 知识图谱：SQLite 存储时序实体关系，支持时间窗口和时间线查询； MCP服务器：19个工具，让 Claude/ChatGPT 自动调用； 完全本地运行：零 API 密钥、零云服务，一切在用户机器上； 自动保存钩子：定期备份+紧急保存，避免上下文压缩时丢失。 项目 MIT 开源，纯 Python 实现，支持 Claude Code 快速开发，也能对接本地模型。安装只需 pip install mempalace，几条命令就能初始化宫殿、挖掘聊天记录或代码库，搜索历史对话瞬间返回。 GitHub 仓库（https://github.com/milla-jovovich/mempalace） 一点启示 MemPalace 不是简单的“明星玩票”，而是戳中了当前大模型最核心的痛点——长期记忆与上下文管理。传统 AI 公司让模型“自动萃取关键事实”，却忽略了人类真正需要的是“所有决策过程和 nuance”。Milla 的反向设计（人决定结构，AI 负责存取）提供了新范式。 更重要的是，它证明了AI工具正在彻底降低创作门槛： 有想法、有品味 + Claude Code + 工程师伙伴 = 可能超越大厂产品； 本地运行、开源、零成本，普通人也能部署自己的“记忆宫殿”； 跨界创新（演员 + AI）正在成为常态，2026年或许就是“人人皆可造物”的元年。 Milla 在 Instagram 和 Facebook 上亲自解释灵感来源：“我花了几个月精心整理文件，却发现AI找东西还是不行……为什么不创建一个虚拟记忆宫殿呢？”。 ...

昨天我写了一篇我深入研究了 Wechat Skills 并自己开发了一套 WeChat Skill ，今天继续把这个 Skill 完善了下，使得它变成一个内容创作助手。 功能介绍 知识库 输入微信文章链接，下载内容并生成 Markdown 到知识库。 目前是保存到本地目录，如果你想上传到飞书文档，只需要安装飞书相关的 Skills 就可以直接上传。 知识库没有使用 RAG ，使用的是 Markdown 文档方便阅读，后续也可以考虑 chunk embeding 下！ 基于知识库写文章 基于现有知识库使用 wechat-super-power skill 帮我写一篇 Claude Code 架构的文章。 它会经历3个步骤： 爆点分析，提取核心冲突点 框架选择，内置了多种文章框架 写作，内置写作的 prompt 全流程自动化创作 当然，你也可以全流程自动化，就输入以下提示词： 使用 wechat-super-power skill 帮我写一篇 RAG 的文章 它会自动获取 RAG 的文章整理成知识库。 最后在本地目录下就能看到成稿。 查重复 检测下 AI 浓度，把上面生成的文章拿去跑了下，居然全部为“人能文本”。 安装到小龙虾 帮我安装这个 skills -> https://clawhub.ai/jacoobwang/wechat-super-power 最后 项目目前开源，大家有兴趣的自己玩下。 https://github.com/jacoobwang/wechat-super-power

最近公司的项目已经把很多之前用 tool 实现的东西改成了 skills，但这些实现并不包含脚本逻辑这一块，主要以 prompt 为主。 趁着这两天休息花一点时间深入研究了 ClawHub 上 WeChat 相关 skills 的实现方式，又自己从零做了一套“微信公众号搜索 + 文章抓取转 Markdown”的 skill。 在 openclaw 中调用我的 skill： 一开始，我以为这件事的重点是 但做到后面，我越来越确定一件事： 开发一个好 skill，难点从来不在功能本身，而在于你是否真正理解了 skill 这种交付形态。 它不是普通项目，不是单纯脚本，也不是一段 prompt。 它是一个面向 agent 的“可执行能力包”。 一、最大的误解：Skill 不就是“脚本 + 文档”吗？ 刚开始接触 skill 的时候，很多人都会有一个很自然的想法： “这不就是把一个脚本放进目录里，再写个 SKILL.md 吗？” 表面看，确实像。 一个典型的 skill 目录可能就是这样： wechat-super-power/ ├── SKILL.md ├── agents/ │ └── openai.yaml ├── references/ │ └── implementation-plan.md └── scripts/ ├── search_wechat.js ├── fetch_wechat_article.js └── skill-entry.js 如果只看文件结构，你很容易把它理解成一个迷你项目。 ...

“飞书 CLI 现已面向所有用户开源。（真开源，不是要登记还要审核那种） 无论你想让 Claude Code、Codex 还是其他 Agent 直接操作飞书，或是希望围绕飞书构建新一代自动化工作流，欢迎使用” 中午正在开着车，等红灯的时候瞄了眼手机，就看到了上面的消息。第一反应是 “wow 一定要试试”，因为我现在也是高度的 Lark 使用用户！ 跑去仓库看了一眼，果然是新鲜出炉的，代码是2小时前提交的。 字节真棒啊，周六还在干活 — 现在大厂都足够拼搏的！ 一句话安装 安装特别简单，直接对着我的 Codex 口喷： 帮我装一下所有的东西：https://github.com/larksuite/cli/blob/main/README.zh.md 上面这个 Prompt 也是卡兹哥的文章上看到的，它是在 Claude Code 上跑的，我在 Codex 上跑了一遍也顺利的完成了安装。 而且建议使用上面的 Prompt 安装，不要直接说安装 飞书 Cli，这样有可能不安装 Skills。 网页授权 飞书的 Cli 需要去读取个人用户数据，所以安装完的第一个步骤就是授权登录。 让 Codex 继续完成登录即可。然后就会给你一个二维码链接，复制到浏览器里面自己手动配置一下。 点击授权即可完成授权登录。 功能 基本上涵盖了我们日常使用的功能，对于我来说最重要的是多维表格和文档功能，以后的技术架构、需求评审等文档可以直接用 AI 生成然后帮我上传到 Lark 上。 安全与风险 过于由于数据不互通，Agent 能力不能好好释放，现在有了 Cli，Agent 能够拿到这些数据，但也伴随着风险。 开放是一把双刃剑，AI 的 prompt 注入导致的数据泄漏案例不是1个2个了，因此建议还是开最小的权限（特别是数据敏感型公司）。 另外模型也有幻觉，现在 Agent 可以操作飞书聊天，但如果模型出 bug 了，在群里发疯会带来负面影响。因此当下建议飞书机器人作为私人对话助手使用。 MCP已死？CLI永生 Cli 会代替 Mcp 吗？ ...

最近发现了一款很好用的 Terminal，非常适合 AI Coding 工具，之前我一直用 iTerm 配合 zsh 来操作命令行，但它在 node 服务开的多的情况下会变卡。 以下内容原文出处来源于 X 上的 @BruceBlue，写的非常细致， respect。 你是不是也遇到过这些崩溃时刻： 终端卡得像老牛拉车？ Claude写代码时输出一堆文字看不清？ 想左右分屏（左边让Claude写代码、右边debug） 却不知道怎么加屏幕？ 配置一改就弹窗报错？ 慌！ Ghostty就是为你准备的！ 它像一个调皮的小鬼，跑得飞快、长得漂亮，还天生和Claude是好搭档。 这篇全新入门文章，我把所有坑都踩过一遍，用最简单的话 + 手把手截图 + 基础命令教你。 读完5分钟，你就能： 打开Ghostty就自动进Claude Cmd + D 一键左右添加屏幕 Cmd + Shift + Enter 一键放大Claude输出 配上彩虹状态栏 + 快乐现场 准备好了吗？我们一起“鬼混”开发吧！🚀 Ghostty官网：https://ghostty.org/ Ghostty由HashiCorp联合创始人 @mitchellh 从2021年开始当“副业”鼓捣，用Zig语言写的核心。2024年底正式开源。 它的三大好处（小白最爱）： 超级快：GPU加速（macOS用Metal），Claude输出再长也不卡，滚动丝滑像丝绸。 超级漂亮：原生macOS界面，支持透明毛玻璃、Catppuccin紫色主题、完美连字字体，看代码眼睛不累。 超级好用：支持Kitty图形协议（Claude让你画图？图片直接在终端显示！）、Quick Terminal下拉幽灵、一键分屏、永久保存布局。 一句话总结：Ghostty不逼你“要么快要么丑”，它全都要！ 免费开源，还在狂迭代。 第一步：安装Ghostty（超级简单，3分钟） 在你的Mac终端（或者已经打开的Ghostty）里敲下面这行，回车： brew install --cask ghostty 安装完直接在Spotlight搜索 Ghostty 打开它。 第一次打开可能会出现两个窗口（一个是下拉的幽灵终端），别担心，我们马上解决！ 基础命令： 想随时打开Ghostty？按 Command + 空格，输入 “Ghostty” 回车就行。 ...

Node.js 框架在 2024 年呈现出多样化的发展态势，其中 Elysia、Hono、Nest 和 Encore 等框架备受关注。本文尝试记录这些框架的优势、劣势以及适用场景，帮助日后技术选型。 框架特性概述 根据轻量级到功能丰富程度，这些框架的排序如下： 这并不意味着轻量级框架不好，而是取决于项目需求。Hono 的轻量级特性使其非常适合部署到 Cloudflare Workers，而 Encore.ts 则内置了许多功能，如自动追踪和本地基础设施。 Encore.ts 仓库地址：https://github.com/encoredev/encore Encore.ts 是一个开源框架，旨在简化使用 TypeScript 构建健壮且类型安全的后端应用。它内置了丰富的工具，可提升开发体验，在性能方面表现卓越，是本次比较中速度最快的框架。 Encore 具有内置的请求验证功能，使用常规 TypeScript 定义的请求和响应类型可在编译和运行时验证请求。与其他框架不同，实际验证在 Rust 中完成，而非 JavaScript，这使其验证速度极快。 Encore 便于创建和调用服务，从代码角度看，服务就像存储库中的普通文件夹，调用服务端点如同调用普通函数。其神奇之处在于，这些函数调用在底层会转换为实际的 HTTP 调用。部署时，你甚至可以选择将服务部署到不同实例，如 Kubernetes 集群，同时保持所有服务代码在同一存储库中。 Encore 还带有内置的开发仪表板，启动应用后，可通过localhost:9400访问。在这里，你可以像使用 Postman 一样调用端点，每次调用都会生成一个跟踪，用于检查 API 请求、数据库调用和发布 / 订阅消息。本地开发仪表板还包括自动 API 文档和系统的最新架构图。值得一提的是，尽管 Encore 功能丰富，但它没有任何 npm 依赖项。 Hono 仓库地址：https://github.com/honojs/hono Hono 由 Yusuke Wada 创建，始于 2021 年，旨在解决 Node.js 框架在 Cloudflare Workers 上运行不佳的问题。此后，Hono 增加了对 Node.js、Bun 和 Deno 等多种运行时的支持。 import { Hono } from 'hono' const app = new Hono() app.get('/', (c) => c.text('Hono!')) export default app Hono 非常小巧，hono/tiny预设版本不到 13KB，非常适合部署到 Cloudflare Workers，并且它也没有 NPM 依赖项，令人印象深刻！ ...

作为前端开发如何知道用户在页面上操作行为是否符合预期？用户点击某个按钮或使用某个功能异常时我们能否快速定位？上线的功能是否会导致线上 bug? 曾经一度这些问题深深困扰我们，作为一个没有测试团队的自研型产品研发团队，我们的上线依靠发布前走查关键测试用例来避免线上问题，但这种方式耗时耗力不说，因为人为测试总有遗漏的地方，也不能保证 100% 稳定可靠，只能保证核心功能不出问题。 因此，我们需要一套可靠的前端日志系统，来帮助我们实时观测用户使用数据及线上异常情况，另可以快速定位问题，不至于出现问题还需要跟用户远程复现（效率太低）。我们把技术方案瞄准为 ELK 套件 架构来帮助解决以下问题： 全链路问题排查，通过日志搜索查询用户的入参出参报错等全链路信息、按时间序列分析或还原用户的操作行为排查问题 数据统计分析，通过日志数据可以灵活的自定义统计分析，如系统的UV、PV、用户行为分析、接口调用量、接口响应速度、异常报错统计等等 自定义上报，因前端无法直接打印日志到服务器或数据库中，需要满足前端的一些浏览点击、资源加载、js报错、自定义上报等场景日志等需求 智能归因分析，监控报警需要做好报警的收敛和治理，如何使用AIGC技术去做智能化的报警分析是非常值得探索的方向 持久化存储，一些数据统计分析需求需要部分日志持久化存储，自行控制日志的生命周期。 系统架构 整体的系统架构采用的就是经典的ELK架构，即 Elasticsearch + Logstash + Kibana 的组合，同时引入了filebeat作为轻量化的nginx日志采集的组件。 整体的系统架构如下： 整体的方案是借助ELK架构去收集前端服务器的nginx日志及后端日志进行结构化存储到ES集群，通过ES强大的全文搜索能力及Kibana组件数据可视化能力进行日志的搜索和分析。 nginx服务器 前端服务主要使用的就是nginx进行页面部署和一些接口的代理转发，nginx日志本身就会记录用户所有的接口请求，但是nginx日志默认是不能记录到请求的响应值的和做一些前端自定义上报日志记录的，所以我们需要对nginx进行一些配置个改造。 为了能打印到接口的响应值，我们引入了OpenResty替代nginx，使用OpenResty结合lua脚本就可以非常简单的获取到接口的返回值并打印到nginx的access日志里，主要是获取接口的返回buffered并使用zlib库进行解码。 下面是nginx配置文件的简单示例，可以根据自己业务需求获取及打印所需字段： log_format main escape=json '{"user":"$user","uri":"$uri","$http_appkey","req_body","resp_body":"$resp_body","timestamp":"$time_iso8601","ups_res_time":"$upstream_response_time"}'; location /api/ { proxy_pass http://api.xxxx.jd.com/; body_filter_by_lua ' local zlib = require("zlib") if type(ngx.arg[1]) == "string" then local resp_body = string.sub(ngx.arg[1], 1, 5000000) ngx.ctx.buffered = (ngx.ctx.buffered or "") .. resp_body if ngx.arg[2] then local inflate = zlib.inflate() local ok, decoded = pcall(inflate, ngx.ctx.buffered) ngx.var.resp_body = ok and decoded or ngx.ctx.buffered end else ngx.var.resp_body = "" end '; } 为了实现前端可以自定义上报一些报警日志到nginx，我们采用的是构造一些约定的请求和对应的nginx日志字段，前段需要上报日志的时候去发起请求并把上报内容放到请求体，nginx端将其写入nginx日志即可完成对应的流程。 ...

我所在的团队几年前开始实现一款基于 URL 拼接方式的实时合图能力，应用场景则是用在广告图千人千面的场景下，很多 App 首页都有 banner 广告位，为了最大程度提升广告的效率，广告算法推荐需要实现了一套通过不同的 sku + 不同的文案 + 不同的模版，然后生成一张广告图的技术方案。 这套技术方案抛开推荐算法不提，最为重要的是如何在用户打开 App 的瞬间能够合成出广告图，而我当时主要负责服务端广告图合成技术。于是就有了本文的技术方案- 毫秒级广告图合成。 URL 设计 对于图片服务器而言，要求业务逻辑尽量简单，最大化利用图片路径来做参数传递，当浏览器打开一个图片资源时，源服务器可以快速找到所在服务器分片并迅速定位到文件资源返回给上游。基于此我们设计了一套 URL 方式能够承载动态信息： http://img.example.com/${appName}/${image}/${variable}/${token}/${meta}/q.jpg appName: 业务名 variable: 图片信息 + 文案信息 + 模版信息 token: 加密参数, 把 variable 加密下校验 URL 合法性 meta: 裁剪信息 + 缩放信息 + 质量信息 技术架构 架构设计一切从性能出发，使用了 Nginx + lua + c 扩展的方式来实现服务，而并不需要 nginx 接受请求转发给其它服务进程处理，减少 IO 开销与进程切换的开销。 ngx_lua 采用 “one-coroutine-per-request” 的处理模型，对于每个用户请求，ngx_lua会唤醒一个协程用于执行用户代码处理请求，当请求处理完成这个协程会被销毁。每个协程都有一个独立的全局环境（变量空间），继承于全局共享的、只读的"comman data"。所以，被用户代码注入全局空间的任何变量都不会影响其他请求的处理，并且这些变量在请求处理完成后会被释放，这样就保证所有的用户代码都运行在一个"sandbox"（沙箱），这个沙箱与请求具有相同的生命周期。 得益于Lua协程的支持，ngx_lua在处理10000个并发请求时只需要很少的内存。根据测试，ngx_lua处理每个请求只需要2KB的内存，如果使用LuaJIT则会更少。所以ngx_lua非常适合用于实现可扩展的、高并发的服务。 lua 逻辑 Nginx 接受到请求后通过 location 匹配到对应的 lua 脚本并执行，lua 里面的逻辑主要包含参数提取，主要通过正则的方式取出来文案+图片+模版+缩放等信息，然后获取模版+获取图片信息然后调用 c 扩展实现合图，最后返回合成后的图片信息。 ...

最近在 GitHub 上看到一个非常火的图转代码开源项目（https://github.com/abi/screenshot-to-code) ，star 数量达到了 5万+，结合我自己在做的 UI2Code 项目，探究下它的具体实现方法。 为什么值得学习？ 过往在 UI2Code 项目中都是基于设计稿件，通过解析出结构化的 Json 数据，然后来做布局处理，最后转化成代码。这里有一个前提，即需要提供 UI 设计稿，设计稿通常被定义为 figma 稿件 或者 sketch 稿件等。而这个开源项目使用的是静态图片，是无图层信息的位图，那这也是最吸引我的地方。 screentshot-to-code 上传截图自动生成网页 HTML，背后原理是使用 Claude Sonnet 3.5 或 GPT-4o 生成代码，使用 DALL-E 3 生成相似图像。 经过一番摸索测试，发现这个项目生成的效果不太稳定，如果用在业务中看起来不太可行。那么有没有一种更稳定的实现方式呢？ 实现路径 先构思下整体流程： 大体而言，跟 UI2Code 流程无太大差异，最大区别还是在第一个步骤：如何将图片转成设计稿件。设计稿件转代码已经是一套现有非常成熟的解决方案。 下面看下如何解决图片转设计稿件。 图转稿件 首先，需要明确下稿件有哪几种数据类型，下面以我们自研的类 figma 工具而言，一个稿件的图层类型如下： 而我们从静态图片中能够提取出来的数据类型有三种： 文本类型 文本可以通过 ocr 的方式获取图像上包含的文字信息和文字坐标以及文字的颜色等信息。 图像类型 需要去分解一张大图上的各个小图，从而实现图片类型图层的提取。 容器类型 容器是一个组，它是若干文本和图像的区块，可以理解把一张图片划分成多个组，前端同学可以理解为我们经常用 div 来包裹若干内容图层。 文本 OCR OCR 是比较成熟的技术，为了快速验证，选取 https://github.com/PaddlePaddle/PaddleOCR?tab=readme-ov-file 作为方案实现。提取文字内容和文字坐标。 如何提取文字颜色？ 通过 OCR 获取文字坐标后，尝试通过 cv 的方式获取文字颜色。 def get_font_color(self, image, text_nodes): for node in text_nodes: x0 = node['x'] x1 = node['x'] + node['width'] y0 = node['y'] y1 = node['y'] + node['height'] _img = image[y0:y1, x0:x1] _gray = cv2.cvtColor(_img, cv2.COLOR_BGR2GRAY) threshold = np.mean(_gray) rec, mask_ = cv2.threshold(_gray, threshold, 255, cv2.THRESH_BINARY) p = len(np.where(mask_ == 255)[0]) / (mask_.shape[0] * mask_.shape[1]) if p < 0.5: font_value = 255 back_value = 0 else: font_value = 0 back_value = 255 font_color = np.mean(_img[np.where(mask_ == font_value)], axis=0) back_color = np.mean(_img[np.where(mask_ == back_value)], axis=0) node['font_color'] = (int(font_color[0]), int(font_color[1]), int(font_color[2])) node['bg_color'] = (int(back_color[0]), int(back_color[1]), int(back_color[2])) print(node) 图像分割 分割则需要用到当下比较流行的 SAM 模型， https://docs.ultralytics.com/zh/models/fast-sam/ ...