白烛魁的小站

现在关于 AI 写代码的内容很多，但我不太喜欢其中两种倾向：一种是用 AI 做炫酷但不实用的花瓶，另一种是夸大 AI 能力来博眼球、贩卖焦虑。 我更关心的是：AI 到底能在哪些真实工程场景里，稳定地产生价值。关键不只是 AI 能不能写代码，而是场景是不是真实、反馈是不是可验证、失败是不是能被及时发现和回滚。离开这些前提，再漂亮的生成结果也很容易停留在演示层面。 过去一段时间，我在 Knife4j Next 上尝试的就是这样一个场景：不用 AI 从零写一个新项目，而是让它参与复活一个已经停止维护、但仍然有人需要的开源项目。 Knife4j Next 是 Knife4j 的一个社区维护 fork。Knife4j 本身是很多 Java 项目用过的 API 文档工具，官网在 doc.xiaominfo.com/knife4j。当一个有历史用户的项目维护节奏变慢后，需求不会自动消失：文档页面要保持可用，调试链路不能莫名断掉，发布说明和发布产物也需要对得上。 这类项目很有代表性：它不是一个需要每天重新定义方向的新产品，也不是一个改错一次就会造成巨大损失的核心系统；它有真实用户、有明...

如果你做过 Java 后端项目，大概率见过 doc.html。 很多团队不是不知道 Swagger UI，也不是不会用 springdoc-openapi，而是已经习惯了 Knife4j 这套更适合国内团队的接口文档体验：接口分组、参数说明、在线调试、全局参数、鉴权配置、离线文档导出，以及那个启动后直接访问的 /doc.html。 问题在于，Java 生态这几年变化很快。 Spring Boot 2.7、Spring Boot 3.x、Jakarta namespace、springdoc-openapi 2.x，再到 Spring Boot 4.x 和 Spring Framework 7，这些变化都在持续推着项目升级。一个 API 文档工具如果不能跟上这些版本线，就会慢慢从“顺手的开发工具”变成“升级时绕不开的历史包袱”。 这也是我维护 Knife4j Next 的原因。 它不是一个全新项目，而是 Knife4j 的社区维护 fork。目标也不玄乎：让已经熟悉 Knife4j 的团队，继续保留 doc.html 的使用习惯，同时把 Spring Boot 2.7 /...

说明：本文基于 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 个指标简洁而全面，能够快速反映系统的运行状态。 保持监控系统简单核心原则：系统越简单，可以发生故障的地方就越少，就...

简单但是代码“说不清”的功能，不如让AI来实现！场景想象你是一个售卖软件激活码的商家，在收款后把激活码通过邮件的方式发送到客户的邮箱里，你的美好生活就这样一单一单地继续着。 直到有一天，你的好朋友说他给你介绍了个大生意，有几百个客户要从你这里购买软件，他给你发来了几张手写下来的便签照片、几段格式杂乱的文本，上面记录了你所需要的信息：用户的名字和邮箱。 在你被迫转行干这个之前，你是个程序员，你给自己开发了个录入客户信息自动发货的系统。可是，这几百单要是一单一单录入的话要花很久。你摩拳擦掌地拿起ocr、正则表达式准备将这个苦差事自动化时，问题出现了： ocr解析从图片里解析出来的文本还是乱糟糟的，错别字、无关的字符…显然ocr并不知道它要处理的是人名和邮箱，它只管识别图片里的字符，有一个算一个！ 记录客户信息的文本，有的前面有序号，有的没有，有的用逗号作为分隔符，有的用句号，有的人名和邮箱分开了两行…本来你的正则就是上网抄的水平，如何用正则匹配格式这么灵活的文本真让你犯了难 幸运的是，在2024年，AI已经足够聪明来解决这样的问题。 我将用上面的例子介绍我是如何在一个CRUD的小...