白烛魁的小站

如果你最近发现 README 里的 Star History 图片裂了，先别急着换 URL、加重试，也别先怀疑自己的 Markdown 写错了。 这次坏得比较彻底：GitHub 改了 Stargazer 接口的访问规则，Star History 赖以生成完整曲线的数据拿不到了。以前那种「输入任意公共仓库，马上吐出一张历史图」的玩法，前提已经没了。 我维护的 Knife4j Next 也中招了。后来我们没再找下一个在线图表服务，而是用 GitHub Actions 把数据和 SVG 生成本地化，放进自己仓库。 结论先行整套做法分两阶段： 123一次性初始化：有权限的 Token → 拉取现有 Stargazer 时间 → 聚合成 history.json长期每日运行：公开 Star 总数 → 追加当天快照 → 生成 SVG → 推送到独立分支 核心思路是把需求收窄： 只为自己拥有或协作的仓库生成图表 有权限的 Token 只在初始化历史时用一次 日常任务只读公开的 stargazers_count 只存日期和数量，不存 Stargazer 身份 数据与 SVG 放在独立分支，避...

关于 AI 写代码的讨论很多，我不太吃两种调调：一种把 AI 当演示道具，另一种把能力吹到天上、顺便贩卖焦虑。 我更在意一个朴素问题：在真实工程里，它能不能稳定帮上忙。能写代码只是起点；场景要真实，结果要可验证，做错了要发现得了、回得去。离开这些，再漂亮的生成结果也只是 demo。 过去一段时间，我在 Knife4j Next 上试的就是这类场景：让 AI 参与维护一个已经停更、但仍有人在用的开源项目，而不是从零造一个新产品。 为什么先盯上“停更但仍有人用”的项目Knife4j 是很多 Java 团队用过的 API 文档工具，入口常常是熟悉的 /doc.html。官网在 doc.xiaominfo.com/knife4j。维护节奏慢下来之后，用户需求并不会一起消失：页面要能开，调试不能莫名其妙挂掉，发布说明和实际产物还要对得上。 Knife4j Next 是它的社区维护 fork。我对这类项目的定位一直很克制：稳住现有体验，修回归和兼容，发布可重复，前端增量演进。目标是把项目继续养着，不是重写一个「更现代」的产品。 它适合拿来练 AI 协作，主要是因为足够务实： 有真...

如果你做过 Java 后端，大概率见过 doc.html。 很多团队不是不会用 Swagger UI 或 springdoc-openapi，而是已经习惯了 Knife4j 这一套：接口分组、参数说明、在线调试、全局参数、鉴权、离线导出，以及启动后直接打开的 /doc.html。对国内不少业务团队来说，它比“生成一份 OpenAPI JSON”更贴近日常。 麻烦在于 Spring 生态这几年一直在动：Boot 2.7 → 3.x → 4.x，Jakarta 命名空间，springdoc 1.x / 2.x / 3.x，Gateway 也跟着换代。文档工具一旦跟不上，就会从顺手的东西，变成升级时绕不开的包袱。 Knife4j Next 就是在这个背景下继续维护的社区 fork：源自 Knife4j，目标很克制——保留熟悉的 doc.html 体验，把还在用的 Boot 版本线继续撑住，而不是重做一个“更现代但迁移成本巨大”的新产品。 当前稳定版是 5.0.16，Maven 坐标在 com.baizhukui。 先看现在的界面OpenAPI3 主线已经切到 Rea...

说明：本文基于 Simon Willison 的一篇英文文章整理，结合原文案例，重写其中更值得复用的协作方法，不追求逐字翻译。原文标题：Adding a new content type to my blog-to-newsletter tool原文作者：Simon Willison’s Weblog原文链接：https://simonwillison.net/guides/agentic-engineering-patterns/adding-a-new-content-type/#atom-everything 很多人第一次用 Coding Agent，都会有一种类似的挫败感：模型看起来很强，真放进项目里，却还是会理解错需求、改错地方，或者忙了半天，最后没把问题真正解决。 这种落差不一定说明模型不行，很多时候，是任务交代得不够适合让它工作。 Simon Willison 最近写了一篇文章，里面有个很典型的例子。他想给自己的 blog-to-newsletter 工具新增一种内容类型，于是把这件事交给 Claude Code 去做。值得注意的是他给任务的方式，而不是功能本身...

【转载】三省六部幻觉：为什么“虚拟公司”式多 Agent 架构在工程上不成立 说明：这篇文章整理自一篇我认为很有价值的外部帖子。因为不少读者访问不了 X，我把它转成了适合博客阅读的版本，方便存档和传播。文中观点保留原意，表达和排版做了适度整理。 原始链接：https://x.com/i/status/2043898494818410731 一个在 AI 社区广泛流传的架构思路，正在让大量团队走弯路。 先说结论如果你正在考虑把多个 AI Agent 分别命名为“产品经理”“架构师”“测试工程师”，让它们像公司部门一样传递文档、协作完成任务——请先停一下。 这个模式看起来很直觉，逻辑上似乎也很合理，但它在工程上存在根本性的缺陷。更重要的是，Anthropic、OpenAI、Google 在构建自己的 Agent 系统时，没有一家真正采用这种模式。 这不是巧合。 什么是“三省六部”式架构这里的“三省六部”，指的是一类在社区里很流行的多 Agent 设计方式。它在不同框架和文章里有不同名字，比如： role-based agents virtual team CrewAI 式分工 M...

我把博客从 Halo 换回 Hexo，是因为看似无关的 AI在互联网世界中拥有一小片自治领土，记录和分享解决问题的经验，是程序员的浪漫。 我在上大一时，跟着 CSDN 上的教程一个一个命令地搭建起了我的第一代博客：一个用 Hexo 部署在 GitHub Pages 上的静态博客。 彼时的我脑子空空，不知道这些咒语般的命令是什么意思，我只知道我的文章都放在一个目录下，每次发布需要敲几个固定的命令，过一会儿文章就会出现在一个 GitHub 分配好的网站里。 但我对装修这块领地很感兴趣，喜欢安装各种插件和主题。后来我发现，配置文件晦涩难懂，安装插件也很麻烦。我逐渐失去了对博客的热情。 很多年后我回头看，才发现当年那个让我望而生畏的「命令行博客」，其实有一个被我忽略的优点：它足够朴素。文章是文件，配置是文件，发布是一组明确的命令。只是那时的我并不觉得这有什么价值，我更想要一个「像产品」而不是「像工程」的博客系统。 为什么当初选择 Halo后来我学习了 Docker、计算机网络，也拥有了自己的服务器。我了解到一个可以部署在自己服务器上的博客框架：Halo。 如果说早年的我嫌 Hexo 太像...

Claude Code macOS 等待确认与任务完成通知背景在使用 Claude Code 进行开发时，Claude 有时会在执行关键操作前等待用户确认，或者在任务完成后进入空闲状态。如果你不盯着终端，就会错过这些时机，导致任务卡在那里迟迟不推进。 本文介绍如何通过 Claude Code 的 Hooks 机制 + terminal-notifier，在以下场景自动推送 macOS 系统通知： ✅ Claude 需要用户确认或输入时发送通知 ✅ Claude 完成任务时发送通知 前置准备安装 terminal-notifier： 1brew install terminal-notifier 验证安装（第一次使用 terminal-notifier 可能会弹出系统通知授权，允许通知即可）： 1terminal-notifier -title 'Test' -message 'Hello from terminal-notifier' 核心配置将以下配置合并到 Claude Code 的 settings.json（路径：~/.cl...

Nginx Proxy Manager 使用 Let’s Encrypt 获取 SSL 证书报错 Internal Error最近在用 Nginx Proxy Manager 申请 Let’s Encrypt 证书时，我遇到了一个很烦人的问题：前端界面里看起来一切正常，但点击申请证书后，最后只得到一个模糊的 Internal Error。 这种报错的难点在于：信息量太少。如果你不去容器里进一步排查，很难知道到底是 DNS、80 端口、邮箱、ACME 验证，还是 Nginx Proxy Manager 自己的状态出了问题。 我这次遇到的情况，最终定位到的是 certbot 的锁文件没有被正确清理。下面把现象、原因和解决方法整理一下。 现象在 Nginx Proxy Manager 中为某个域名申请 Let’s Encrypt 证书时，界面弹出 Internal Error，证书无法签发。 如果你也遇到了类似情况，建议不要一上来就反复重试。因为这类问题经常不是“再点一次就好”，而是某个内部状态已经卡住了。 先确认不是更常见的问题在处理锁文件之前，可以先快速排除几类更常见的原因： ...

前言《数据密集型应用系统设计》（Designing Data-Intensive Applications，简称 DDIA）是分布式系统领域的经典著作，深入探讨了数据系统的底层原理、分布式计算的实践挑战，以及如何构建可靠、可扩展、可维护的应用。本文是我阅读本书后的核心要点记录与思考。 结论先行本书的核心价值在于：帮助技术决策者理解各种数据系统和架构方案背后的权衡取舍。无论是存储引擎的选择、数据复制策略、还是分布式事务的处理，都不存在银弹，只有在具体场景下的最优解。理解这些权衡的本质，才能做出明智的技术决策。 一、数据系统的底层原理数据的存储结构对于如何在磁盘上组织数据，有两个主要的数据结构：B-Tree 和 LSM-Tree。两者各有优劣，适用于不同的场景。 LSM-Tree（日志结构合并树） 这是一张描述 LSM-Tree 存储结构的图，出自这篇文章。该作者的 mini-bitcask 项目基于 LSM-Tree 实现了一个简单的数据库，非常适合新手学习。 核心思想： LSM-Tree 的核心思想是以追加日志的形式组织数据，在内存中维护索引，索引保存的是一条数据在日志文件中的偏...

前言《SRE: Google 运维解密》（Site Reliability Engineering）是 Google 首次公开其运维方法论的经典著作。本书揭示了 Google 如何通过工程化手段保障海量服务的可靠性，涵盖监控、容量规划、故障处理、过载保护等核心主题。本文记录了我阅读本书时的关键要点与实践思考。 结论先行SRE 的核心理念是：通过工程化手段和自动化工具来保障系统可靠性，而不是依赖人工运维。 其中最重要的实践包括：用监控黄金指标量化系统健康度、通过流量抛弃和优雅降级避免过载、合理设计重试和超时机制防止雪崩。 一、监控体系监控的 4 个黄金指标Google 认为，衡量一个系统的健康状况，应该关注以下 4 个核心指标： 延迟（Latency）：请求的响应时间 流量（Traffic）：系统的 QPS（每秒查询数） 错误（Errors）：请求失败率 饱和度（Saturation）：系统的瓶颈指标（如 CPU 利用率、内存利用率），也可以理解为”水位” 这 4 个指标简洁而全面，能够快速反映系统的运行状态。 保持监控系统简单核心原则：系统越简单，可以发生故障的地方就越少，就...