它能干什么 怎么用 设计与实现 技术栈 本文首发地址 https://h89.cn/archives/643.html 写博客这几年，一直有个头疼的问题：标签。 刚开博客那会儿，每篇文章都认真打标签，写描述。时间一长就懈怠了——发布按钮一点，标题扔上去就完事，哪还记得补 description 和标签。日积月累，文章几百篇，标签没几个，搜索结果页的描述也常年空缺。 试过手动整理，坚持了两天就放弃了。几百篇文章，一篇篇翻、写标签、写描述，这活不是人干的。 所以有了这个插件。当前版本支持：面板按文章质量、有无标签、有无Meta筛选文章，自动同步文章状态、批量TAG/Meta增强 SEO/GEO。 市面上 Typecho 的 SEO 插件不少，但基本只做静态优化——改改 title、加加 keywords、生成个 sitemap。

- 阅读剩余部分 -

我用 opencode-loop 跑了一次完整的 Loop Engineering 实践，让 AI 自己写代码、自己 Review、自己跑测试。大约十几分钟后，测试从 8 个变成 23 个，全部通过。这不是魔法，关键在 verifier 和 checkpoint。 一、手动用 AI 写代码，人到哪都是瓶颈 过去两年，用 AI 写代码的基本流程是： 你写 prompt → AI 回复 → 你读代码 → 再写 prompt → AI 再回复 → ... 人是方向盘，每一轮都要在场。问题是，这个模式有几个死结： 写完就忘。Agent 可能一次改十几个文件，你不可能每一行都仔细看，bug 就藏在没看的那几行里。 测试后置。经常是代码写完了才想起来跑测试，失败了一堆再回头找，效率低。 Review 走形式。自己 R

- 阅读剩余部分 -

数据说话 为什么 AI 反而让你更累 谁是真正的受益者 对自己诚实的建议 参考内容 本文首发地址 https://h89.cn/archives/614.html UC Berkeley Haas 的研究团队花 8 个月盯着一家约 200 人规模的科技公司。结论简单到残忍：AI 没有自然减少工作量，它只是让工作变得更密集。 午休时间有人在发 prompt，开会前五分钟在发 prompt，深夜十二点还在发 prompt。有人同时挂着三个 AI 工具来回切换。最初确实很爽——一个任务过去要半小时，现在五分钟搞定，还能顺手多干两个活。但几个月后，这些人普遍感到比以前更累。不是那种「今天活多」的累，是「明明什么活都变快了，为什么我的时间更少了」的累。 这不是感觉，是实测。 数据说话 Berkeley 这个研究不是孤例。2026 年关于 AI 和生产率的调查出了一堆，数字看起来不完

- 阅读剩余部分 -

一、技术底座：Kuikly 到底怎么工作的 1.1 核心架构：让 native 层尽量薄 1.2 六平台覆盖与动态化 1.3 代码量对比 二、为什么 2026 年值得重新评估 Kuikly 2.1 鸿蒙生态：KMP 系的天然优势 2.2 AI 驱动开发：不只是口号 2.3 Compose DSL 走向正式 Release 三、KMP 与 Kuikly 的分界线：为什么用了 KMP 还要选 Kuikly 3.1 KMP 做到哪一步 3.2 Kuikly 在 KMP 之上加了什么 3.3 和 Flutter、RN 的本质差异 四、QQ 音乐实战：React H5 → Kuikly 智能转码全记录 4.1 背景与痛点 4.2 成果数据 4.3 技术方案拆解：为什么 AI 转码能落地 五、横向对比：Kuikly 放在选型表里是什么位置 5.1 框架定位总览

- 阅读剩余部分 -

整体架构 核心模块拆解 1. 多源采集：配置化接入，不硬编码 2. 热点发现：Embedding + DBSCAN 3. LLM 提炼：从 N 篇文章到 1 个结构化事件 4. 热度评分：不只是计数 5. 去重：48 小时滑动窗口 6. 实时推送：SSE 比 WebSocket 简单 踩过的坑 技术启示 参考文献 本文首发地址 https://h89.cn/archives/595.html 这个五一我哪也没去，在家把一个想了很久的项目做完了。 事情是这样的：每天早上刷 Twitter、Hacker News、微博、知乎、36氪……每个平台都有自己的热点，但它们散落各处。更烦的是，算法推荐的"猜你喜欢"往往让真正重要的事件被淹没在信息流里。刷半小时，感觉看了很多东西，但脑子里一团浆糊。 我不是缺新闻，我是缺组织好的信息。 五一假期第一天，我脑子里突然闪过一个念头：

- 阅读剩余部分 -

两张进化网络，还是两张孤岛 EvoMap：让 AI 的经验不再是一次性的 Hermes：每个实例都是一座孤岛 结构性困境：指数打线性，差距只会越来越大 Hermes 补得上这个差距吗 一份技术对比报告 时间线：晚了 5 周以上 三层记忆体系精确对应 12 组术语，一对一替换 10 步主循环，步步对齐 Hermes 的回应 接回去：为什么接入网络等于自曝 一个更大的问题：开源协议在 AI 洗代码面前失效了 后续 Evolver 的一段插曲 参考文献 本文首发地址 https://h89.cn/archives/589.html 你花三小时调通了一个 Python 环境报错，隔壁同事遇到同样的坑，还是得从头踩一遍。 AI Agent 也一样。经验怎么传承？这个问题，EvoMap 和 Nous Research 给出了完全不同的答案。 EvoMap 的 E

- 阅读剩余部分 -

为什么大项目最后都卡在 Issue 队列上 它不是自动关单，而是一条保守的维护流水线 它到底关什么，放过什么 真正值钱的，不是模型，是并行和审计 模型重要，但还不是最关键的东西 这件事真正打到痛点的地方 最后说透四点 参考文献 本文首发地址 https://h89.cn/archives/582.html 开源项目做到后面，最容易把人拖垮的，往往不是写代码，而是清 Issue。 你以为维护者最怕的是线上事故？很多时候不是。真正磨人的，是早上打开 GitHub，先看到几千个没处理的 issue 和 PR，红点一片，根本不知道该从哪下手。 ClawSweeper 抓人的地方，也不是“AI 一键关 Issue”这种热闹标题，而是它把这件只能靠人硬扛的脏活，做成了一条能审计、能回滚、能长期跑的流水线。 公开仓库里的审计数据显示，Cla

- 阅读剩余部分 -

本文首发地址 https://h89.cn/archives/576.html AI 编程最容易让人上头的一点，就是它真的快。 一个下午写完原本要做三天的需求，一个人顶过去一个小组的产出，PR 一开就是上千行，屏幕上全是绿色。那种感觉很容易让人误以为，软件开发终于进入了一个只要"多生成一点"就能持续提效的阶段。说真的，第一次用 Claude Code 把一整个模块的 CRUD 跑通的时候，我自己也觉得——这也太爽了。 但很多团队最近开始慢慢回过味来：代码确实变多了，人却没有更轻松。 Review 队列更长了，线上风险更多了，安全审计更吃力了，真正理解系统的人反而更焦虑了。代码产出像开了闸，审查、验证和兜底能力却没跟着一起扩容。表面上看是效率提升，往里看更像是工程压力整体后移。 《纽约时报》最近发布的一篇报道《The Big Bang: A.I. Has Create

- 阅读剩余部分 -