Reorx’s Forge

更新下语音输入法的进展，这两天在打磨录音触发和音频传输的细节，务求做到极致的响应速度和稳定性，不弄丢任何声音。然后刚刚输入了很长一段话，整体输出质量已经非常高了，我甚至觉得比 typeless 更让我满意。

还有5分钟 Fable 额度 reset，充分利用下最后 2% ，和它聊会天

不知道为什么 Hacker News 上的讨论氛围现在还对 HTMX 如此狂热。agentic coding 之前的时代，我也是很看好 HTMX 的，觉得它把 web 开发拉回了那种经典朴素的路子，不像 React 搞那么多概念。 但这几个月我几乎没亲手写过代码，全是 claude code / codex 在干活，突然发现我根本不在乎底下是 HTMX 还是 React 了。代码都不是你写的，你纠结这个干嘛？ 甚至开始体会到 React 的好：生态成熟、UI 库多、模块化组件复用，这些恰恰是 HTMX 的短板。但帖子里完全没人提，do you guys not have AIs? https://news.ycombinator.com/item?id=49057241

远程 ssh 工作时感觉 Mac Mini 有点卡，查了下系统状态发现差点爆了，赶紧让 claude 自修复一波。最后发现是 agent-browser 进程泄露和 ios simulator 没关导致的…这算是最近用 agent 自验收比较多的一个副作用吧，看来得做个 crontab 定期清理下进程

Simplicity is prerequisite for reliability. — Edsger W. Dijkstra 只凭这一句话，Dijkstra 就是我最崇敬的计算机科学大师之一

忙碌的一周结束了，驻足欣赏下江景

过去半年 AI 编程给我的工作方式带来的最大变化，不是写的代码质量更高，或者可以完成的 feature 难度更高，而是在测试验收和运维部署这两件事上，极大拓展了我对它的想象空间，并建立了前所未有的信任。 之前我曾尝试用 OpenClaw 帮我把已完成的工作发布上线，但得到的效果却不能让人满意，还让我花了大量的时间给 AI 擦屁股。我心说可能是我贪心了，运维的复杂度高，需要与各种 GUI 管理工具交互、频繁切换上下文，并且需要相比代码开发更严谨、更具有怀疑精神的心智模型。为此我还写了篇文章思考 DevOps 专用 agent 的需求和可行性。 然而最近几个月，事情开始变得不一样了。我时常在 X 上看到有人给 Codex / Claude Code 下达一个高层级目标，对如何完成的过程没有任何提示或约束，agent 却能完全自主完成一系列 GUI 工具的操作，像一个真实的 sysadmin 那样完成任务：登录运维平台配置域名、服务器等云资源，甚至在供应商的网站上创建账号、购买服务，最后拿到 API Key 等等。第二天早上一看，完整的产品已经上线并 SEO ready 了。 这类宣传虽然诱人，但有之前的失败经历在，我一直比较谨慎。所以直到 Fable 发布，我才重新尝试把完整的上线、验收的全流程交给 agent 来完成，结果是一次次让我惊喜，最终使我彻底将 DevOps 工作以 IaC 的方式移交给了 agent。在测试方面，我也从只让 agent 写单元测试、自己手动验收，进化到全部交给 agent 运行和模拟操作，我只看结果的截图。其实连截图我也很少看——agent 本就是自己对着截图确认的，多数情况我只看结论就够了。 这种能力边界的拓展，其基础是 harness 与模型的双向进步。harness 的上下文管理在持续优化，与现实世界交互的工具生态越来越丰富和成熟（如 computer use、agent-browser，甚至 iOS simulator）；模型训练向 agent 相关的评测指标看齐，并以长时间独立执行任务为核心目标，在今年不断突破新的高度。 我对 AI 编程工作流的下一步想象，就是脱离对终端和 TUI 的操作，在一个中心化的系统中管理开发任务从需求到上线的全生命周期：探讨需求并生成 spec，在合适的时机方便地引入 human-in-the-loop，自动 handoff 并 spawn 新的 session，自动 review、验收、截图、生成报告，自主管理整个 DevOps 体系等等等等。这个想法已经有不少开源项目在实践了，但能真正达到我的标准，达到与我手动在 Claude Code 里交互相同甚至更好的手感和稳定性，还差一些。因为对我来说，生产力工具不是能用就行，必须足够稳定可控，不因自身的问题打断使用者的心流，也不让人把时间浪费在调试和配置上。不过以现在的进步速度，保守估计最迟年底，我的工作方式就会变成这样，拭目以待吧。

最近经常遇到 Chrome 动不动占很多 CPU，打开 Task Manager 看到 CPU 最高的一项永远是 Prerender: https://www.google.com/search/warmup.html, 搜了下或许关闭 Preload pages 有用，正在持续观察中

反正 token 用不完，Opus 5 + fast model 岂不是比 Fable 还爽？

猜我怎么判断是机翻？AI 特别喜欢给英文句子加分号，但没有活人在网上会这么干

虽然很理解这哥们的意思，也十分赞同他的观点，但这句话说得确实让人绷不住，直接引战了。说话的方式太重要了，同样的意思，换个说法就感觉不同，换个语言更是偏差巨大。本来是指责 HN 的讨论一说到中国的模型就开始扯政治对立、人权等等垃圾话，有一说一这确实是没营养的讨论，以我对 HN 这两年言论环境的了解，已经有越来越多的人消除对中国的阴谋论滤镜了，所以这个事说清楚我认为是会有很多人赞同的。结果这发泄式吐槽加上机翻，直接让人觉得，好家伙你说人权是垃圾是吧，变成挑衅了，搞得本来很多说话比较理性的人也没法接受原本的观点了。实在是大型跨国交流翻车现场… https://news.ycombinator.com/item?id=48973549

这两天在主线工作上的进展给我带来了非常大的成就感。我发现语音输入法的效果，虽然原始转录结果已符合标准，但经过 LLM 润色后反而不尽如人意。我判断，问题出在模型与提示词的搭配上。但我并不擅长提示词工程，不想把自己的时间耗在慢慢改慢慢试的无尽深渊里。我寻思，应当把样本数据收集起来，建立一套标准化的评估和迭代体系。只有这样，才可能量化每次改动的效果，把模糊变为确定。 于是我把这个想法和 fable 沟通，让他帮我开发了一个 evaluation 系统(我告诉 fable 要做成 agent native，cli + api 调用，eat your own dogfood)，并把我过往语音转录的 2000 多条音频都收集起来导入进去。随后，我从中挑选了几十条音频人工标注，建立了一个数据集。然后让 fable 基于现在的 prompt 自己开始迭代。让我惊喜的是，只一个上午的时间，达成率就从一开始的 33% 提高到 67%。当然，最让我高兴的是这套方法的行之有效。我发现，给 agent 一套方法和工具，给定评判的标准，它就能持续地循环、迭代，把结果变得越来越好。虽然这和真正的 LLM 训练不能比，但也让我侧面感受到「炼丹」的魅力，好家伙真的有点上瘾的。 现在我在做的，是把数据集细化，分短音频和长音频两种，用两套提示词针对性地迭代，这可以改进只用一个提示词泛用型强而针对性弱的缺点。再之后，准备把 STT 模型的评估也纳入进来，方便我选出最适合产品需求的语音转录模型。

这是我为自己的运维工作流所量身打造的部署工具 hookploy 的 web UI。最近看到很多人推荐 Openship, 忍不住来说下我的看法。如果 Openship 早2年出现，那我会毫不犹豫地从 Dokploy, Coolify 等一众竞品中选择它。但现在，时代已经变了，我需要的是 agent-native 的部署体系，GUI 再如何方便精致，已经跟我没关系了，因为我是给 agent 下达指令去完成部署、监控、验收的闭环。我唯一需要看的，最多是个只读的 dashboard，这也是 hookploy 已经稳定运行很久了，我才在闲暇时给它做 UI 的原因。 说回正题，我是如何设计自己的部署工作流并开发出 hookploy 这个工具的呢？我在一开始目标就很明确，我要用一个 repo 作为我所有运维体系的 SSOT，也就是 Infrastructure as Code。因为这种以文本为载体的工具是最适合和 agent 协同工作的方式。我选择了最为熟悉和 boring 的 ansible, 让它接管了新机器 provisioning 和定期维护, caddy 的路由配置, 和所有服务的 docker compose 配置。没有花很多精力，我就发现 CC 已经玩转了这套方案，无论是新服务发布，还是老服务的数据迁移、线上 debug，都能精准快速地完成，几乎没有出现需要我人工排查的情况。 至此其实我已经很满足了，但还有最后一个想要优化的地方，那就是当代码 push 后，我不想等着镜像在 CI 构建完成，再告诉 agent 去发布最新版本，我想让这件事自动发生。最初我用了 adnanh/webhook 一段时间，但它功能太单一了，无法支持多节点服务的触发。另外，我仍然需要为每个服务写触发 webhook 后执行的部署脚本，而它们大多都是重复的。 于是需求就很明确了，我需要一个组件提供中心化的 webhook 入口，用配置文件定义其所管辖的所有服务，每个服务所在的一个或多个服务器上，运行着该组件的边缘节点。当中心节点收到镜像构建完成的通知，会向对应的边缘节点发出指令，让其执行配置文件中所定义的一系列指令，完成服务的更新。 … 没想到 tg 竟然还有字数限制，剩下的内容麻烦大家到 X 上看吧，顺便转发下啥的 X) https://x.com/novoreorx/status/2079962007248482343

继续分享最近开发时做的一些周边产出，今天给大家推荐我写的一个工具 + skill: envops https://github.com/reorx/envops 如果你会使用 agent 来做运维，那么强烈建议你安装 envops, 它会强制 agent 在处理与 env 文件相关的工作时，全部通过 envops cli 进行，使得重要的 secret, key, password 等数据不会暴露给 agent，降低泄露的风险。截图是我从近期的对话中搜索出的对 envops 命令的调用，可以看出 claude code 用得很不错。 在当下开发者越来越多地使用 AI 辅助编程的环境下，env 文件不可避免地需要被读取、修改、复制。即便只是本地开发，也很容易依赖一些线上服务的凭据。Agent 如果仍然使用传统的读写方式，势必造成重要凭据被留在 session 记录中，产生更多泄露点。 envops 实现了一套判断和清洗 secret string 的算法，在向外展示 env 文件内容时，确保凭据主体始终被遮盖。 envops 提供了下面几个操作指令: • show: 打印 env 键值对，如果是凭据类数据，值会被自动清洗并遮盖 • list-keys: 列出 env 中的 keys, 提供这种低权限细粒度操作会减少 agent 对 show 的依赖 • copy: 将一个 env 中的特定 键值对复制到另一个 env, 必须显示声明 keys, 或者完整拷贝。支持 ssh 的路径声明语法，把对远端服务器的 env 读取/更新操作封装成一个整体 • set: 设置 env 中的一个键值对，支持通过管道将其他命令的输出传递过去，这能让 secret 来自其他命令输出时，无须暴露给 agent 或其他进程直接落地到 env 文件 我看到过一些面向 agent 的 secret vault 方案，但总觉得都还是太重了，且它们也无法消除 env 文件的存在，所以探索出了 envops 这种改变 agent 对 env 的根本行为的方式，希望能对各位 vibe coders 开发的安全性起到一些帮助。

加入 HackerNews 信息源

2026年突然很想念上古鬼畜，于是翻开10年前的收藏夹 https://www.bilibili.com/video/BV1Fs411Z7WQ/

分享一下我现在远程在 Mac Mini 上工作时，验收 Claude Code 产出的屏幕截图的方式

最爱看的就是每隔几个月的 itch 游戏精选测评 https://mp.weixin.qq.com/s/qO_N024-rSIGgogXU8qO5g