ethanjamescolez (李大为)

我的作品 YouTube to MP3 converter：我把进度、预览和下载路径单独做成了一页

ethanjamescolez — Sun, 10 May 2026 17:04:29 +0800

最近把一个反复出现的小问题单独做成了一页：YouTube to MP3 converter。

这个页面不是想做一个很大的视频工具集合，而是先把一条很具体的路径讲清楚：当我只需要从 YouTube 链接拿到 MP3 时，能不能看到进度、先预览结果，再决定要不要下载。

目前这页主要想把下面这条路径做顺：

粘贴 YouTube URL、youtu.be 链接、Shorts 链接或 video ID。
启动 MP3 转换任务。
在等待时查看任务进度。
在浏览器里先预览生成的 MP3。
确认结果可用后再下载 MP3 文件。

我自己遇到这个需求时，最不想看到的是页面只给一个按钮，然后让我等到最后才知道结果是否可用。对这种小工具来说，进度反馈和预览不是装饰，而是用户判断 “这个 MP3 值不值得保存” 的关键步骤。

边界也写得很明确：

MP3 转换依赖第三方转换服务，当前只适合 120 分钟以内的视频，并且只应该用于用户拥有版权或已获得下载权限的内容。

页面在这里：https://youtubetowav.io/youtube-to-mp3-converter

想听听大家建议：

这种小工具页面，第一屏应该先强调 “下载 MP3”，还是先解释进度和预览路径？
对转换类工具来说，你更在意最终下载直接，还是保存前能先确认结果？

我的作品 AI Vocal Remover：先预览 vocal 和 instrumental，再决定要不要下载

ethanjamescolez — Tue, 05 May 2026 10:05:05 +0800

最近做了一个很小的在线音频工具：AI Vocal Remover。

最开始关注的是一个很具体的点：去人声这件事本身不只是在等模型处理完，用户真正要判断的是分离出来的结果值不值得保存。

所以现在这版没有往重型音频工作台方向做，而是先把一条短路径走顺：

上传一个本地音频文件。
等 AI 做 vocal separation。
预览 vocal 和 instrumental 两个 stem。
听完以后判断结果是否可用。
下载需要的 MP3 输出。

我刻意把 “预览” 放在中间，而不是直接把下载按钮当成最终答案。因为练歌、剪辑、remix sketch 这些场景里，大家关心的 stem 不一样：有人更在意伴奏够不够干净，有人更在意人声能不能单独听清。

当前的边界也很明确：分离质量会受曲目、混音、源音频质量以及模型和第三方处理服务影响；用户也应该只上传自己有权处理的音频。我不想把它包装成 “完美去人声” 或者 “所有歌曲都能处理得很好” 的工具。

现在最想验证的是：这条 “上传 -> 分离 -> 预览 -> 下载 MP3” 的路径，对第一次打开页面的人来说是否足够清楚。

页面在这里： https://ai-vocal-remover.com/

想听听大家建议：

对这类小工具来说，把 vocal / instrumental 预览放在下载前，是否能降低试错成本？
第一屏应该更强调 “能做什么”，还是更早说明 “分离效果会因音源而变化”？

我的作品 AI YouTube Transcript：我把 YouTube transcript 下载成 TXT 这条小路径单独做成了一个页面

ethanjamescolez — Fri, 01 May 2026 21:02:57 +0800

最近把一个很小但经常出现的需求单独做成了一个页面：AI YouTube Transcript。

这个页面不是想做一个很大的视频工具集合，而是先把一条很具体的路径讲清楚：当我只需要 YouTube transcript 的纯文本时，能不能直接下载成 TXT，放进下一步工作里。

目前这页主要想把下面这条路径做顺：

粘贴 YouTube 链接或视频 ID。
打开页面能读取到的 transcript 文本。
确认这段文本适合继续使用，而不是只停留在视频页里。
下载成 TXT，把内容带到笔记、引用、提纲或草稿里。

我自己遇到这个需求时，通常不是为了继续在视频页面里看内容，而是想把文本拿去做笔记、摘引用、整理提纲，或者放进一个草稿里继续处理。所以 TXT 在这里不是 “多支持一种格式”，更像是把 transcript 交给下一个工具的出口。

边界也写得很明确：只有源视频暴露了可用的字幕或 transcript track，页面才可能加载并导出 TXT；如果没有可用 track，就没有内容可下载。

页面在这里： https://aiyoutubetranscript.com/

想听听大家建议：

这种小工具页面，第一屏应该先强调 “能下载 TXT”，还是先解释 transcript 来源和限制？
如果你要把视频内容转成笔记或草稿，TXT 这种最朴素的出口够不够用？

我的作品 AI Hermes Agent：我把一个重复出现的小问题单独做成了产品页

ethanjamescolez — Wed, 29 Apr 2026 18:08:21 +0800

最近把一个反复出现的小问题单独做成了一页：AI Hermes Agent。

最开始只是我自己在用，后来发现这个问题确实会反复出现，所以就想把它整理成一个更明确的产品入口，而不是继续藏在零散笔记里。

目前这页主要想把下面这条路径做顺：

先让用户知道它解决的到底是哪一个具体问题。
把核心使用步骤压缩到最短可完成路径。
把限制和边界说明白，而不是藏到最后。

现在这版我刻意做得比较克制，只保留最核心的能力。因为我发现一旦想 “顺手多做一点”，页面就很容易从一个好理解的小工具，变成一个什么都想管、但什么都不够清楚的入口。

当然，边界也有：

The site is independent, not the official Hermes docs. Exact support details, provider behavior, and runtime differences can drift and should be rechecked against official Hermes docs and GitHub when they affect a live setup decision. The comparison should not overstate Hermes as the right choice for every workflow.

页面在这里： https://ai-hermes-agent.com/faq

想听听大家建议：

你看到这种产品页时，最关心的第一屏信息是什么？
现在这类小工具，什么情况下你会愿意继续试下去？

我的作品 AI Hermes Agent：我把 “哪些工作真的适合自托管 AI agent” 单独整理成了页面

ethanjamescolez — Tue, 28 Apr 2026 07:38:54 +0800

最近把一个自己反复会解释的问题单独整理成了一页：AI Hermes Agent。

我发现很多人一提到 AI agent，讨论很快就会滑到模型、服务提供方、运行时和部署细节。但我自己真正会先问的，其实是更前面的判断：这件工作到底值不值得用自托管 agent 来接？

所以这页现在更想把这条判断路径讲顺：

先判断当前工作是不是会重复出现，而不是一次性的聊天或提问。
再看这项工作是否真的需要工具调用、记忆、消息入口或长期运行。
把典型场景拆开看，例如远程编码、消息助手、研究与网页操作、定时任务、自托管和重复工作知识沉淀。
如果看起来适合，再回官方文档和仓库确认部署、模型和运行细节。

我没有把它做成 “万物皆可 agent” 的展示墙，而是更想先把几个典型场景讲清楚，比如远程开发搭子、消息入口助手、调研与网页操作、定时任务、自托管边界、重复工作里的知识沉淀。

反过来，如果只是一次性聊天、轻量确认，或者主要工作都停留在编辑器和当前窗口里，我反而觉得不一定值得走到自托管 agent 这一步。

边界我也直接写在页里了：

页面里的公开 X 示例只能当作真实工作流的公开参考，不能当作已验证的客户案例、效果证明或背书。

页面在这里： https://ai-hermes-agent.com/use-cases

想听听大家两个建议：

你看这类使用场景页面时，最希望先确认的是场景分类，还是 “不适合” 的边界？
对自托管 AI agent 来说，你更在意长期运行和工具连接，还是先把搭建成本压低？

我的作品 AI YouTube Transcript：我把一个重复出现的小问题单独做成了产品页

ethanjamescolez — Sun, 26 Apr 2026 18:24:00 +0800

最近把一个反复出现的小问题单独做成了一页：AI YouTube Transcript。

最开始只是我自己在用，后来发现这个问题确实会反复出现，所以就想把它整理成一个更明确的产品入口，而不是继续藏在零散笔记里。

目前这页主要想把下面这条路径做顺：

Paste a YouTube URL or video ID.
Choose a language.
Open the transcript.
Search inside transcript text.
Click timestamps to jump back into the video.
Copy transcript text.
Download TXT, SRT, or VTT.

当然，边界也有：

Transcript availability depends on subtitle or caption tracks exposed by the YouTube video. If no usable track exists, there may be no transcript to load. Transcript quality depends on the underlying track.

页面在这里： https://aiyoutubetranscript.com/

想听听大家建议：

你看到这种产品页时，最关心的第一屏信息是什么？
现在这类小工具，什么情况下你会愿意继续试下去？

我的作品 YouTube to WAV：我把一个重复出现的小问题单独做成了产品页

ethanjamescolez — Sat, 25 Apr 2026 23:04:35 +0800

最近把一个反复出现的小问题单独做成了一页：YouTube to WAV。

最开始只是我自己在用，后来发现这个问题会不断重复出现，所以就想把它整理成一个更明确的产品入口，而不是继续散在零碎笔记里。

目前这页主要想把下面这条路径做顺：

粘贴 YouTube URL 或直接输入视频 ID。
发起转换任务。
查看进度直到 WAV 准备完成。
先预览音频结果。
确认后直接下载 WAV。

我这次刻意没有把它做成一个更大的下载器或视频处理平台，而是先把一个高频动作讲清楚：任务是不是在跑，结果能不能先预览，下载下来的 WAV 能不能直接进入下一步。

当然，边界也有：

这条 WAV 流程当前支持最长 120 分钟的视频，依赖第三方转换提供方，输出质量取决于源媒体本身，也只适用于用户拥有或获准下载的内容。

页面在这里： https://youtubetowav.io/

想听听大家建议：

你看到这种产品页时，第一眼最希望先确认的是什么？
对这种转换类小工具来说，你更在意进度、预览，还是最终的直接下载？

我的作品 AI Hermes Agent：把 Hermes Agent 安装路径整理成一页独立指南，想听听大家建议

ethanjamescolez — Fri, 24 Apr 2026 23:36:04 +0800

最近把一个自己反复会查的东西单独整理成了一页：AI Hermes Agent。

做这页的原因很简单，我发现很多人装 Hermes Agent 时，真正卡住的往往不是 “有没有安装命令”，而是安装之后那几步到底怎么接上。

我现在想先把这条路径讲清楚：

先判断自己准备把 Hermes Agent 装在哪个环境里，比如 macOS、Linux、WSL2 或 Termux。
按页面整理好的安装步骤跑完官方安装命令。
安装完成后把 shell 重新加载起来。
继续看首轮常用命令，比如 hermes、hermes model、hermes setup、hermes gateway、hermes doctor、hermes update。
最后回到官方 docs 和 GitHub 再核对时效性比较强的信息。

这页目前更像一个独立整理的安装指引，而不是官方文档镜像，所以我也刻意把边界写得比较清楚：一些时效性强的内容，还是应该回到官方 docs 和 GitHub 去确认。

当前这版还比较克制，想先把最核心的安装路径讲顺，而不是一上来把所有相关内容都堆进去。好处是更聚焦，坏处是可能会显得不够 “大而全”。

页面在这里： https://ai-hermes-agent.com/install

想听听大家两个建议：

这种安装类页面，你更希望它聚焦一点，还是把更多上下游信息一起放进去？
除了安装命令本身，你最希望在这种页面里先看到什么？