[分享创造] [补送码] Nas 音乐播放器的终极解决方案： Mu3ic
1.5.0 发布贴，一开始光速领码的都没激活，后面才刷到的 xd 很多都没领到激活码，鉴于此，在这里另发一帖补送 20 个码，请在收到码后 24h 内激活，逾期不补，有需要的伙伴可以留下邮箱
● 原帖： https://www.v2ex.com/t/1248530
● 主页： https://mu3ic.xyz/#features
● 软件下载直链： https://dl.robb3n.site/mu3ic/Mu3ic-stable.apk
另外也可以在 App 里用推广期特价 38 18 元买断（推广价到 11 月 5 日）。买了 Pro 的可以进官方讨论群（ https://t.me/+RFkD6vL_889iMjQ9 ），进群后私聊我，拉你进 Pro 资深用户群。资深用户群后面会发布「下歌 → 打标签 → 曲库管理」的自动化入库最佳实践，定制需求也优先响应，Agent 环境搭建（独家）和开发最佳实践也会作为增值服务陆续发布，下图为独家 Mac 端代理工具和跨 Agent 任务编排系统
via V2EX (author: aslehx)
1.5.0 发布贴，一开始光速领码的都没激活，后面才刷到的 xd 很多都没领到激活码，鉴于此，在这里另发一帖补送 20 个码，请在收到码后 24h 内激活，逾期不补，有需要的伙伴可以留下邮箱
● 原帖： https://www.v2ex.com/t/1248530
● 主页： https://mu3ic.xyz/#features
● 软件下载直链： https://dl.robb3n.site/mu3ic/Mu3ic-stable.apk
另外也可以在 App 里用推广期特价 38 18 元买断（推广价到 11 月 5 日）。买了 Pro 的可以进官方讨论群（ https://t.me/+RFkD6vL_889iMjQ9 ），进群后私聊我，拉你进 Pro 资深用户群。资深用户群后面会发布「下歌 → 打标签 → 曲库管理」的自动化入库最佳实践，定制需求也优先响应，Agent 环境搭建（独家）和开发最佳实践也会作为增值服务陆续发布，下图为独家 Mac 端代理工具和跨 Agent 任务编排系统
via V2EX (author: aslehx)
[酷工作] 标题： [尋找 AI 時代的 OS 級合伙人] CloudCat（雲貓）—— 基於端雲協同与數據飛輪的 Personal AI OS
各位大佬/極客朋友好：
我是深擎科技（ CloudCat Lab ）創始人鄧智健。我們正在籌備一個真正能打通移動端 App 生態孤島的 AI 項目 —— 雲貓 CloudCat 。
我們拒絕做「只會陪聊」的 AI 助手，也拒絕做「隨時被系統升級封殺」的單點 Hook 工具。我們正在構建一個 Meta 式「控制與執行分離」的高可用 Personal AI OS：
🌟 我們的技術路線與架構：
端雲協同 & 數據飛輪：雲端 Planner 負責推理與長工作流拆解，手端日誌回傳伺服器進行 RLHF 強化學習，實現「今天踩坑、明天全網 Agent 自動修復」的網絡效應。
端側雙軌執行器：
普及版（主力正兵）：Shizuku (ADB) + 無障礙 + 端側輕量 VLM 視覺 UI 識別，完全免 Root ，安全合規，覆蓋全量 Android 用戶。
內核版（極客奇兵）：保留 KernelSU / APatch / Binder 提權接口，作為高階極客模組。
獨創 Agent 意圖共識投票機制：透過 Multi-Agent 與 Human-in-the-Loop 投票卡片，徹底解決生成式 AI 跨 App 操作的幻覺與誤扣款風險。
🤝 我們在找這樣的靈魂合夥人 / 核心技術 Partner：
Android 端側架構師：精通 Android 系統機制、Shizuku/ADB 協議、Accessibility 及 UIAutomator 。
雲端 AI / Agent 系統工程師：熟悉 LLM 任務拆解、LangChain/AutoGPT/Meta Agent 框架、RLHF 數據飛輪構建。
（兼顧）內核/Binder 大牛：熟悉 Non-GKI 內核編譯、Binder IPC 與系統保活。
💰 合作方式与真實待遇（不畫大餅）：
階段一（ 0-1 MVP 研發期）：提供 5,000 元/月 研發津貼（保障基礎生活）+ 10% - 20% 創始團隊股權（帶 4 年 Vesting 分期兌現）。
階段二（ Demo 跑通與正式融資後）：產品 MVP 跑通並對接融資/資助到帳後，正規提供市場化高薪（ 20k-30k+）。
如果你不想只做大廠的螺絲釘，想一起做一款真正影響數百萬人的個人 AI 操作系統，歡迎聯繫我！
V：jefferson1689
Email： jeffersontang28@gmail.com (
via V2EX (author: kalxd)
各位大佬/極客朋友好：
我是深擎科技（ CloudCat Lab ）創始人鄧智健。我們正在籌備一個真正能打通移動端 App 生態孤島的 AI 項目 —— 雲貓 CloudCat 。
我們拒絕做「只會陪聊」的 AI 助手，也拒絕做「隨時被系統升級封殺」的單點 Hook 工具。我們正在構建一個 Meta 式「控制與執行分離」的高可用 Personal AI OS：
🌟 我們的技術路線與架構：
端雲協同 & 數據飛輪：雲端 Planner 負責推理與長工作流拆解，手端日誌回傳伺服器進行 RLHF 強化學習，實現「今天踩坑、明天全網 Agent 自動修復」的網絡效應。
端側雙軌執行器：
普及版（主力正兵）：Shizuku (ADB) + 無障礙 + 端側輕量 VLM 視覺 UI 識別，完全免 Root ，安全合規，覆蓋全量 Android 用戶。
內核版（極客奇兵）：保留 KernelSU / APatch / Binder 提權接口，作為高階極客模組。
獨創 Agent 意圖共識投票機制：透過 Multi-Agent 與 Human-in-the-Loop 投票卡片，徹底解決生成式 AI 跨 App 操作的幻覺與誤扣款風險。
🤝 我們在找這樣的靈魂合夥人 / 核心技術 Partner：
Android 端側架構師：精通 Android 系統機制、Shizuku/ADB 協議、Accessibility 及 UIAutomator 。
雲端 AI / Agent 系統工程師：熟悉 LLM 任務拆解、LangChain/AutoGPT/Meta Agent 框架、RLHF 數據飛輪構建。
（兼顧）內核/Binder 大牛：熟悉 Non-GKI 內核編譯、Binder IPC 與系統保活。
💰 合作方式与真實待遇（不畫大餅）：
階段一（ 0-1 MVP 研發期）：提供 5,000 元/月 研發津貼（保障基礎生活）+ 10% - 20% 創始團隊股權（帶 4 年 Vesting 分期兌現）。
階段二（ Demo 跑通與正式融資後）：產品 MVP 跑通並對接融資/資助到帳後，正規提供市場化高薪（ 20k-30k+）。
如果你不想只做大廠的螺絲釘，想一起做一款真正影響數百萬人的個人 AI 操作系統，歡迎聯繫我！
V：jefferson1689
Email： jeffersontang28@gmail.com (
mailto:jeffersontang28@gmail.com)via V2EX (author: kalxd)
[分享发现] 搞了个托尼 SKILL，您的专用理发师
突发奇想搞了个托尼 skill ，感兴趣的话可以下载品鉴一下
via V2EX (author: cKnight)
突发奇想搞了个托尼 skill ，感兴趣的话可以下载品鉴一下
npx skills add https://github.com/cknight107/tony --skill tony
via V2EX (author: cKnight)
[推广] Gemini4 上线，谷歌这次真的杀回头部了，水果题生在鹈鹕都是秒生成。老三的位置看来稳了。回复送体验额度,欢迎 v 佬来测。
https://www.jiji.cc
谷歌这次真的杀回头部了！
Gemini 4 Argon 强势登场，重点升级 复杂 Coding 、Agent 自主执行、深度推理、百万上下文与多模态理解，直接向 GPT 、Claude 两大旗舰发起挑战！
⚔️ 官方评测，正面硬刚：
🔥 代码工程 DeepSWE
Gemini 4 Argon：77.9%
GPT-6 Astra：74.1%
Claude Opus 5.5：74.2%
🧠 专业任务 Vals Index
Gemini 4 Argon：68.9%
GPT-6 Astra：63.1%
Claude Opus 5.5：67.0%
via V2EX (author: jijicc)
https://www.jiji.cc
谷歌这次真的杀回头部了！
Gemini 4 Argon 强势登场，重点升级 复杂 Coding 、Agent 自主执行、深度推理、百万上下文与多模态理解，直接向 GPT 、Claude 两大旗舰发起挑战！
⚔️ 官方评测，正面硬刚：
🔥 代码工程 DeepSWE
Gemini 4 Argon：77.9%
GPT-6 Astra：74.1%
Claude Opus 5.5：74.2%
🧠 专业任务 Vals Index
Gemini 4 Argon：68.9%
GPT-6 Astra：63.1%
Claude Opus 5.5：67.0%
via V2EX (author: jijicc)
[分享创造] NepBox 一个免费的域名解析站
做了一个免费的域名站，类似 Duck DNS 那种，地址是 https://www.nepbox.com 欢迎尝鲜！
主要功能有：
● 使用 Google 一键登录免注册表单
● 免费分发 *.nepbox.com 域名给用户使用
● 可以添加一个 A 类 + 一个 AAAA 类的解析，实际的域名解析由 CF 来实现
● 支持使用一行 curl 命令更新解析地址，非常适合添加定时任务来实现 DDNS
● 支持绑定 TG 接收消息通知，IP 变更了能第一时间收到提醒
● 每个域名保留最多 20 条历史记录，方便溯源
感觉应该符合本站用户的一些需求，欢迎回帖反馈！
via V2EX (author: x009ba1)
做了一个免费的域名站，类似 Duck DNS 那种，地址是 https://www.nepbox.com 欢迎尝鲜！
主要功能有：
● 使用 Google 一键登录免注册表单
● 免费分发 *.nepbox.com 域名给用户使用
● 可以添加一个 A 类 + 一个 AAAA 类的解析，实际的域名解析由 CF 来实现
● 支持使用一行 curl 命令更新解析地址，非常适合添加定时任务来实现 DDNS
● 支持绑定 TG 接收消息通知，IP 变更了能第一时间收到提醒
● 每个域名保留最多 20 条历史记录，方便溯源
感觉应该符合本站用户的一些需求，欢迎回帖反馈！
via V2EX (author: x009ba1)
[分享创造] 做了一个开源的多 AI Agent 任务管理工具 StateDock，支持 MCP、Docker 自部署
最近一直在用 Codex 、Claude Code 、DeepSeek 等 AI Coding Agent 开发自己的几个项目。
随着项目越来越多，我发现一个问题：
AI 写代码已经不是最大的麻烦，真正麻烦的是多个 Agent 、多个项目之间的任务管理。
比如：
● 在 ChatGPT 里讨论好了一个新功能，但 Codex 正在执行其他任务。
● 某个 Agent 的会话结束了，换一个 Agent 接手，需要重新了解任务。
● 同时维护几个项目，很难快速知道哪些任务完成了、哪些正在进行、哪些需要自己介入。
● 不同 Agent 各自保存工作记录，缺少统一的任务状态。
后来我换了一种工作方式：不再围绕 Agent 管理工作，而是围绕 Task 。
我为这个流程开发了一个小工具，叫 StateDock 。
它的核心理念只有一句话：
Agents come and go. Tasks stay.
目前我的工作流程
1. 在 ChatGPT 或其他 AI 里讨论需求，确定后通过 MCP 创建 Task 。
2. 任务先进入 Planned ，不影响当前正在执行的 Agent 。
3. 需要开发时，将任务设为 Ready ，指定一个 Agent 领取。
4. Agent 读取任务和代码库，进行开发，并持续更新状态和总结。
5. 如果需要更换 Agent ，可以重新分配任务，新 Agent 结合任务历史和代码库继续工作。
6. 开发完成或遇到阻碍时，通过通知了解状态，不需要一直盯着各个 Agent 窗口。
现在我主要关心哪些任务待做、正在做、已经完成，以及哪里需要自己介入。
有意不做的功能
StateDock 不运行 Agent 、不负责自动编排或调度执行，也不试图保存所有 Agent 的完整对话。
它只是一个让人和不同 AI Agent 共享的持久任务层。
因此可以继续使用自己喜欢的 Coding Agent ，不需要更换开发工具。
开源与部署
目前支持：
● MCP 接入
● 多项目任务管理
● 指定 Agent 领取任务
● 跨 Agent 任务交接
● 任务状态、历史和总结
● 多渠道通知
● Cloudflare 开源自部署
● Docker 开源自部署
● 官方托管版本
Cloudflare 和 Docker 自部署版本都已经发布。
GitHub： https://github.com/statedock
官网： https://statedock.dev
这个工具已经在我自己的多个项目中实际使用了一段时间，主要解决的就是多项目、多 Agent 开发时的任务管理问题。
也想了解一下大家现在是怎么协调多个 Coding Agent 的：使用 Markdown 、现有 Todo 工具、Agent 自带的任务系统，还是其他方式？
via V2EX (author: pickknow)
最近一直在用 Codex 、Claude Code 、DeepSeek 等 AI Coding Agent 开发自己的几个项目。
随着项目越来越多，我发现一个问题：
AI 写代码已经不是最大的麻烦，真正麻烦的是多个 Agent 、多个项目之间的任务管理。
比如：
● 在 ChatGPT 里讨论好了一个新功能，但 Codex 正在执行其他任务。
● 某个 Agent 的会话结束了，换一个 Agent 接手，需要重新了解任务。
● 同时维护几个项目，很难快速知道哪些任务完成了、哪些正在进行、哪些需要自己介入。
● 不同 Agent 各自保存工作记录，缺少统一的任务状态。
后来我换了一种工作方式：不再围绕 Agent 管理工作，而是围绕 Task 。
我为这个流程开发了一个小工具，叫 StateDock 。
它的核心理念只有一句话：
Agents come and go. Tasks stay.
目前我的工作流程
1. 在 ChatGPT 或其他 AI 里讨论需求，确定后通过 MCP 创建 Task 。
2. 任务先进入 Planned ，不影响当前正在执行的 Agent 。
3. 需要开发时，将任务设为 Ready ，指定一个 Agent 领取。
4. Agent 读取任务和代码库，进行开发，并持续更新状态和总结。
5. 如果需要更换 Agent ，可以重新分配任务，新 Agent 结合任务历史和代码库继续工作。
6. 开发完成或遇到阻碍时，通过通知了解状态，不需要一直盯着各个 Agent 窗口。
现在我主要关心哪些任务待做、正在做、已经完成，以及哪里需要自己介入。
有意不做的功能
StateDock 不运行 Agent 、不负责自动编排或调度执行，也不试图保存所有 Agent 的完整对话。
它只是一个让人和不同 AI Agent 共享的持久任务层。
因此可以继续使用自己喜欢的 Coding Agent ，不需要更换开发工具。
开源与部署
目前支持：
● MCP 接入
● 多项目任务管理
● 指定 Agent 领取任务
● 跨 Agent 任务交接
● 任务状态、历史和总结
● 多渠道通知
● Cloudflare 开源自部署
● Docker 开源自部署
● 官方托管版本
Cloudflare 和 Docker 自部署版本都已经发布。
GitHub： https://github.com/statedock
官网： https://statedock.dev
这个工具已经在我自己的多个项目中实际使用了一段时间，主要解决的就是多项目、多 Agent 开发时的任务管理问题。
也想了解一下大家现在是怎么协调多个 Coding Agent 的：使用 Markdown 、现有 Todo 工具、Agent 自带的任务系统，还是其他方式？
via V2EX (author: pickknow)
[区块链] 跨链聚合器的“最优报价”怎么定义？分享一个路线质量评分思路
最近在做 AllSwap ，先说明利益关系：我是项目参与者。下面想讨论的是工程问题，不是发优惠码，也不把产品包装成第三方推荐。
跨链聚合器最直观的排序方式，是选择“预计到账最多”的路线。但实际做下来发现，只按输出数量排序容易选到不稳定路线。
举个例子：
● 路线 A 预计到账 100.2 USDT ，历史完成率 91%，P95 时间 18 分钟；
● 路线 B 预计到账 99.9 USDT ，历史完成率 99.4%，P95 时间 4 分钟。
如果只看报价，A 是最优；如果考虑失败、退款和等待成本，很多用户可能会选择 B 。
我们现在考虑把路线评分拆成下面几项：
这里有几个比较难定的点。
1. 时间惩罚不是线性的
从 1 分钟增加到 3 分钟，大部分用户可能可以接受；从 10 分钟增加到 30 分钟，用户的不确定感会明显增加。因此时间惩罚可能更适合分段函数，而不是简单乘以秒数。
2. 历史成功率可能存在幸存者偏差
如果只统计已经被路由器选中的订单，低流动性路线样本很少，成功率看起来可能反而很高。需要同时记录候选报价、未选路线和失效原因。
3. 小额和大额不应该共用权重
小额用户更在意固定费用；大额用户更在意滑点、深度和失败风险。评分权重应该根据金额区间动态调整。
4. 报价新鲜度需要单独处理
报价数值很漂亮，但生成时间已经超过几个区块，这种路线不应继续排在前面。除了 TTL ，还可以监控连续区块中的输出变化率。
产品流程可以在 https://allswap.io/ 看到。当前是用户选择资产和网络后获取报价，不连接钱包，通过订单地址完成源链转账，再跟踪目标链结算。
想请教做过交易路由、支付通道或聚合器的朋友：
1. 你们会把失败率直接折算成期望价值，还是作为硬阈值先过滤？
2. 路线耗时应该使用最近窗口的 P95 ，还是按链上拥堵状态实时修正？
3. 面向用户展示时，是给一个“推荐路线”，还是同时展示“到账更多”和“更稳定”两个选项？
欢迎讨论评分模型和可观测性设计。涉及真实资产时，任何新路线都应该先小额测试；本文不构成投资建议。
via V2EX (author: indifferentliyan)
最近在做 AllSwap ，先说明利益关系：我是项目参与者。下面想讨论的是工程问题，不是发优惠码，也不把产品包装成第三方推荐。
跨链聚合器最直观的排序方式，是选择“预计到账最多”的路线。但实际做下来发现，只按输出数量排序容易选到不稳定路线。
举个例子：
● 路线 A 预计到账 100.2 USDT ，历史完成率 91%，P95 时间 18 分钟；
● 路线 B 预计到账 99.9 USDT ，历史完成率 99.4%，P95 时间 4 分钟。
如果只看报价，A 是最优；如果考虑失败、退款和等待成本，很多用户可能会选择 B 。
我们现在考虑把路线评分拆成下面几项：
score = output_value
- gas_cost
- time_penalty
- failure_risk_penalty
- liquidity_penalty
- stale_quote_penalty
这里有几个比较难定的点。
1. 时间惩罚不是线性的
从 1 分钟增加到 3 分钟，大部分用户可能可以接受；从 10 分钟增加到 30 分钟，用户的不确定感会明显增加。因此时间惩罚可能更适合分段函数，而不是简单乘以秒数。
2. 历史成功率可能存在幸存者偏差
如果只统计已经被路由器选中的订单，低流动性路线样本很少，成功率看起来可能反而很高。需要同时记录候选报价、未选路线和失效原因。
3. 小额和大额不应该共用权重
小额用户更在意固定费用；大额用户更在意滑点、深度和失败风险。评分权重应该根据金额区间动态调整。
4. 报价新鲜度需要单独处理
报价数值很漂亮，但生成时间已经超过几个区块，这种路线不应继续排在前面。除了 TTL ，还可以监控连续区块中的输出变化率。
产品流程可以在 https://allswap.io/ 看到。当前是用户选择资产和网络后获取报价，不连接钱包，通过订单地址完成源链转账，再跟踪目标链结算。
想请教做过交易路由、支付通道或聚合器的朋友：
1. 你们会把失败率直接折算成期望价值，还是作为硬阈值先过滤？
2. 路线耗时应该使用最近窗口的 P95 ，还是按链上拥堵状态实时修正？
3. 面向用户展示时，是给一个“推荐路线”，还是同时展示“到账更多”和“更稳定”两个选项？
欢迎讨论评分模型和可观测性设计。涉及真实资产时，任何新路线都应该先小额测试；本文不构成投资建议。
via V2EX (author: indifferentliyan)
[推广] 现在还有没有玩 lol 的老哥们？快来免费体验下我做的换肤
## 现在 lol 玩的人越来越少了，还在玩的老哥可以免费体验一下我搞的换肤应用，自己玩了半年了不封号。
加群私聊群主发送：v2ex
QQ 群号：1125317907
iframe (www.youtube.com)
via V2EX (author: zy0829)
## 现在 lol 玩的人越来越少了，还在玩的老哥可以免费体验一下我搞的换肤应用，自己玩了半年了不封号。
加群私聊群主发送：v2ex
QQ 群号：1125317907
iframe (www.youtube.com)
via V2EX (author: zy0829)
[分享创造] [开源] Agent HUD：把 Claude Code / Codex 等 17 个 agent 的额度和批准请求放在 Mac 刘海或屏幕边上
利益相关：作者本人。
做这个是为了不切窗口也能知道两件事：额度还剩多少，哪个 agent 在等我。于是有了 Agent HUD ，一个 Mac 应用，把这些放在刘海周围；没有刘海的屏幕，就放在屏幕边上。
现在能看到的：
额度：刘海周围一圈光，每个额度一种颜色，用到 70% 变黄，90% 变红。鼠标移上去展开，看每个额度用了多少、多久重置、消耗速率，还有余额和过去 24 小时的 Token 。快用完之前会提醒一次：到 90%，或者按现在的速度撑不到重置。
批准和提问：agent 要你批准时，请求停在 HUD 上，带着它要跑的命令、要改的文件 diff ，直接点允许或拒绝。一轮跑完有「新回复」提醒，点一下回到那个会话（终端标签、iTerm2 分屏或 Codex 线程）。HUD 不会替你答应，放着不管 10 分钟后交还给 agent 自己的提示。
统计：Token 按时间、agent 、模型、会话、每一轮拆开，按各家 API 价折算。订阅用户看到的是估算，不是账单。本机保留 30 天。
想要低调点，可以切换到简约或者动态模式，用鼠标拖拽到屏幕边缘核实的位置，也能一眼看到 agent 的状态。
支持 17 个 agent 。Claude Code 和 Codex 最全（额度、状态、批准、提问、回复、回到会话）； Cursor 、Grok CLI 、GitHub Copilot CLI 、OpenCode 、Kimi 、DeepSeek （余额）等支持的程度不一样，README 里有张表。
数据怎么来的：
● 额度和余额：用 agent 已经登录的账号或你配的 key ，读厂商自己报的数。不给模型发消息，不存凭据。
● Token 和会话：读 agent 自己在本机留的记录，存在本地数据库。
● 批准和回复：往 agent 自己的设置里写 hook ，设置里一个开关全部移除。
● 从源码构建的版本不上传任何东西。
开源，Apache-2.0： https://github.com/jazzenchen/agent-hud-open
via V2EX (author: jazzenchen)
利益相关：作者本人。
做这个是为了不切窗口也能知道两件事：额度还剩多少，哪个 agent 在等我。于是有了 Agent HUD ，一个 Mac 应用，把这些放在刘海周围；没有刘海的屏幕，就放在屏幕边上。
现在能看到的：
额度：刘海周围一圈光，每个额度一种颜色，用到 70% 变黄，90% 变红。鼠标移上去展开，看每个额度用了多少、多久重置、消耗速率，还有余额和过去 24 小时的 Token 。快用完之前会提醒一次：到 90%，或者按现在的速度撑不到重置。
批准和提问：agent 要你批准时，请求停在 HUD 上，带着它要跑的命令、要改的文件 diff ，直接点允许或拒绝。一轮跑完有「新回复」提醒，点一下回到那个会话（终端标签、iTerm2 分屏或 Codex 线程）。HUD 不会替你答应，放着不管 10 分钟后交还给 agent 自己的提示。
统计：Token 按时间、agent 、模型、会话、每一轮拆开，按各家 API 价折算。订阅用户看到的是估算，不是账单。本机保留 30 天。
想要低调点，可以切换到简约或者动态模式，用鼠标拖拽到屏幕边缘核实的位置，也能一眼看到 agent 的状态。
支持 17 个 agent 。Claude Code 和 Codex 最全（额度、状态、批准、提问、回复、回到会话）； Cursor 、Grok CLI 、GitHub Copilot CLI 、OpenCode 、Kimi 、DeepSeek （余额）等支持的程度不一样，README 里有张表。
数据怎么来的：
● 额度和余额：用 agent 已经登录的账号或你配的 key ，读厂商自己报的数。不给模型发消息，不存凭据。
● Token 和会话：读 agent 自己在本机留的记录，存在本地数据库。
● 批准和回复：往 agent 自己的设置里写 hook ，设置里一个开关全部移除。
● 从源码构建的版本不上传任何东西。
开源，Apache-2.0： https://github.com/jazzenchen/agent-hud-open
via V2EX (author: jazzenchen)
[推广] 发现一个宝可梦版的每日挑战
最近发现了 Daily Red Pokemon：每天所有玩家都会拿到相同的 6 只宝可梦，从中选一只首发，挑战白银山的赤红。 对战采用第三世代规则，由 Pokémon Showdown 模拟。每天只有一次计入战绩的正式挑战；想先熟悉队伍，也可以无限次练习。
https://dailyredpokemon.me/
via V2EX (author: zty5678)
最近发现了 Daily Red Pokemon：每天所有玩家都会拿到相同的 6 只宝可梦，从中选一只首发，挑战白银山的赤红。 对战采用第三世代规则，由 Pokémon Showdown 模拟。每天只有一次计入战绩的正式挑战；想先熟悉队伍，也可以无限次练习。
https://dailyredpokemon.me/
via V2EX (author: zty5678)
[推广] 看到 V 友分享用药 App，我也分享一个（附内购码）
1.1 为什么要开发这种 App
肾移植后做了个 App 管理自己的血压健康这些数据，也做了透析记录等功能，但始终觉得做的不是很满意，一直只是自用，不过后来觉得用药这一块做的还行，而且 Apple Store 一直没有找到合适的针对慢病用户的 App 。（如我这种情况，用药方案比较特殊多变）就把用药相关功能独立出来做成了一个 App：一服药（英文区 Avela ）
1.2
其实这是一个开发重灾区，和 todo 、记账这几套相比也不遑多让，满屏拉下去可能百来个 App 。但还是开发了，一个是确实希望能上架有些用户，另一个是开发第一个 App 的时候走了很多弯路，想快速验证下积累的经验能不能第二次就快速开发实现一个 App 。
2 对比其他的有什么特点
1. 一些肾移植、肝移植用户需要很准时吃药，长期忘记准时吃药可能引起排斥，因此服药未及时确认，会不断追加提醒，第二天再次提醒确认，后续会考虑加入闹钟，不过目前我个人使用够用了 没忘记过了
2. 很多服药方案比较复杂，大部分 App 都不支持，刚移植完几个月我用 APPLE HEALTH ，后续就发现无法支持我的需求。例如同一个药物早 3 晚 2 ，可以支持，但是早 3 晚 2.5 就不一定能支持；再就是调药后方案可能变成今日早 3 晚 3 隔一日早 3 晚 2 ，几乎没有看到支持的 App ；也就是支持多种复杂方案设置（周期性、隔多少日、按周几服），支持半片设置
3. 其他的就是锦上添花的功能，库存管理（服用后自动扣减库存，库存低了提醒），导出购药清单请别人帮忙购药场景（我常用）。备药提醒、导出用药方案问诊（我每个月一次复查互联网问诊常用）
4. 再就是花了很多时间调的 UI 了（后端仔的审美）
5. 高级功能的桌面小组件、apple watch 快捷操作、实时活动这些（部分功能还在做这版本的发布回归，发完这个版本除了 bug 就不会再开发了，毕竟浪费 token 浪费时间）
3 才知道有内购码 也发一点
前 50 个一服药 Pro 终身买断兑换码，先到先得，每个只能兑换一次，有效期至 2026-12-31 。下载： https://apps.apple.com/cn/app/id6775778505 。在 App Store 账户中的“兑换充值卡或代码”输入代码领取。
via V2EX (author: silencil)
1.1 为什么要开发这种 App
肾移植后做了个 App 管理自己的血压健康这些数据，也做了透析记录等功能，但始终觉得做的不是很满意，一直只是自用，不过后来觉得用药这一块做的还行，而且 Apple Store 一直没有找到合适的针对慢病用户的 App 。（如我这种情况，用药方案比较特殊多变）就把用药相关功能独立出来做成了一个 App：一服药（英文区 Avela ）
1.2
其实这是一个开发重灾区，和 todo 、记账这几套相比也不遑多让，满屏拉下去可能百来个 App 。但还是开发了，一个是确实希望能上架有些用户，另一个是开发第一个 App 的时候走了很多弯路，想快速验证下积累的经验能不能第二次就快速开发实现一个 App 。
2 对比其他的有什么特点
1. 一些肾移植、肝移植用户需要很准时吃药，长期忘记准时吃药可能引起排斥，因此服药未及时确认，会不断追加提醒，第二天再次提醒确认，后续会考虑加入闹钟，不过目前我个人使用够用了 没忘记过了
2. 很多服药方案比较复杂，大部分 App 都不支持，刚移植完几个月我用 APPLE HEALTH ，后续就发现无法支持我的需求。例如同一个药物早 3 晚 2 ，可以支持，但是早 3 晚 2.5 就不一定能支持；再就是调药后方案可能变成今日早 3 晚 3 隔一日早 3 晚 2 ，几乎没有看到支持的 App ；也就是支持多种复杂方案设置（周期性、隔多少日、按周几服），支持半片设置
3. 其他的就是锦上添花的功能，库存管理（服用后自动扣减库存，库存低了提醒），导出购药清单请别人帮忙购药场景（我常用）。备药提醒、导出用药方案问诊（我每个月一次复查互联网问诊常用）
4. 再就是花了很多时间调的 UI 了（后端仔的审美）
5. 高级功能的桌面小组件、apple watch 快捷操作、实时活动这些（部分功能还在做这版本的发布回归，发完这个版本除了 bug 就不会再开发了，毕竟浪费 token 浪费时间）
3 才知道有内购码 也发一点
前 50 个一服药 Pro 终身买断兑换码，先到先得，每个只能兑换一次，有效期至 2026-12-31 。下载： https://apps.apple.com/cn/app/id6775778505 。在 App Store 账户中的“兑换充值卡或代码”输入代码领取。
01. 4W6JKXHFHRHJ7NFY44
02. P7HW6AP3R6PKRETEPL
03. KXLJNLEL3J4FK7PAFT
04. YF8TKY3W7Y6HHNA4EM
05. 8KKA36EFF3AMLHNRM7
06. FA8437XWMNM8XP7N3Y
07. HK6L4LFYJL48HKPEFF
08. 4LEKT7P4EYMAH7KPLH
09. XLJ4Y33H7W7TE38LHM
10. FTEWYLAHEYYPX3PMKM
11. KXKN3476LEJ6XY36NE
12. EPJENYXP68NPKJ4Y84
13. 3HJ8X36776WNJA6NK8
14. 4RKTAH8R47WY4KF3J3
15. W8HYRY7AAJJ4AXNWXM
16. YANPFEK7LN7FNEYELX
17. 4XRPFT4YRLHYELYFMA
18. 83M7KMKHHWAHWWXLN7
19. XEF4H8LHL76FXNXHJL
20. KL3N3XA8A3PET4W6N4
21. JHNJAMXR3FAXRKY4N8
22. KHNRA3WJ6TPMTKXNW4
23. J3RYFMR3XR3YFLY43N
24. FAWM8W666E7R4JHJ8W
25. 7JXY7F3MRFAEHK8XJW
26. PLN7RXM888J36NTTNR
27. EMRHWFMNYKLT666EM4
28. YMLPKPFP3PXA3KX6X6
29. 68WXNATF4ARMRLHFTH
30. F6XKJ88KETJ6M4HKML
31. H4AP6NNPL76XJ6XK7X
32. R7MXH3FAJ38TLXN63L
33. R3NL8L7WEWE3FTMHW7
34. EETKW4AP36EJ4847PR
35. 7MJMKMK8KETHPMJJ3J
36. M3REY4NF67K3JFT88T
37. 7RYP36MKH7AY3X7AN7
38. J67RLPHPEXTHKNEAMX
39. RL4L6R7EXYJT7FLA8A
40. W8FYN4P6JM6T78MH6J
41. JYMHLR8JHTN4NWLLK8
42. W7WAFE77NER78JENMT
43. K7XW3RHX6X4H3KXMF7
44. WHX3X37JRH37N3WYYT
45. TTJHK4NXXA678XTHP3
46. AX7PH6A3PK8H863REN
47. YYN77EP8JEAAFLTTJX
48. 3T66PNR4JKKL4MMXYN
49. TKR8J887JT888N7KE6
50. YW7A3RWN6F6PTWXNAW
via V2EX (author: silencil)