2026-07-27 23:19:19
我用了很长一段时间的 Bartender。
对于菜单栏里常驻着一大堆应用的 Mac 用户来说,Bartender 确实很好用:不常用的图标可以隐藏,需要时再展开,整个菜单栏看起来清爽很多。尤其是换到带刘海的 MacBook 之后,菜单栏空间更加紧张,这类工具几乎成了必需品。
不过最近升级到最新版 macOS Tahoe 26.5 后,我使用的 Bartender 5 开始频繁崩溃。重新启动应用只能暂时解决问题,没过多久它又会退出。菜单栏图标重新挤成一团,使用体验自然也谈不上愉快。
我本来打算直接升级 Bartender 6,结果发现还需要再付 20 美元。Bartender 当然是一款成熟的软件,开发者对大版本升级收费也可以理解。但对我来说,最核心的需求只是隐藏和整理菜单栏图标,为此再购买一次升级,多少有些犹豫。
于是我开始寻找替代品,并发现了 Thaw。

Thaw 是一款开源的 macOS 菜单栏管理工具,基于 Ice 项目发展而来。Ice 原本就是一个很受欢迎的 Bartender 替代品,而 Thaw 在它的基础上继续修复问题,并适配新版 macOS。
它提供了我最需要的几个功能:
Thaw 采用 GPL-3.0 协议开源,可以免费下载使用。通过 Homebrew 安装也很方便:
1 |
brew install thaw |
安装完成后,需要按照引导授予相应的辅助功能和屏幕录制权限。这类菜单栏管理工具需要识别并操作其他应用的菜单栏图标,因此这些权限基本无法避免。
Thaw 的使用逻辑和 Bartender 比较接近,所以迁移过程并不复杂。
安装后,我重新划分了可见、隐藏和始终隐藏的菜单栏区域,把输入法、电池、网络等常用图标留在外面,将网盘、更新程序以及一些偶尔才会打开的工具放进隐藏区域。
我还开启了自动重新隐藏。这样展开菜单栏并完成操作后,图标会再次自动收起,日常使用时几乎不需要额外操心。
如果菜单栏图标很多,或者使用的是带刘海的 MacBook,也可以启用 Thaw 的独立菜单栏。隐藏的图标会显示在主菜单栏下方,不会因为空间不足而被刘海挡住。这个功能很实用,也是它比较接近 Bartender 的地方。
用了几天之后,我对 Thaw 的整体感觉是:还不错,已经可以满足我的需求。
更重要的是,它免费、开源,并且仍在针对新版 macOS 持续维护,推荐给大家。
2026-07-23 15:50:00
最近,我看完了梁文锋面向投资人的四小时会议录音文字版。
相比那些经过高度提炼的公开演讲,这场交流里有更多关于成本、盈利、技术路线和行业节奏的具体判断。看完之后,我对大模型行业的一些看法发生了变化,也有一些原有判断得到了强化。
其中有五点,让我印象最深。
梁文锋提到,DeepSeek 使用的显卡,大约十个月就可以回本。
严格来说,显卡十个月回本,并不能直接等同于公司财务报表上的毛利率达到 87%。显卡只是大模型公司的成本之一,除此之外还有电力、带宽、研发人员、数据和运营等费用。
但即使不把它简单换算成毛利率,这个数字依然非常惊人。
按照最粗略的口径计算,一项资产十个月回本,意味着一年产生的收益可以超过其初始投入,所对应的资本回报率非常高。而且,DeepSeek 的模型价格在整个大模型行业里已经非常低。
这两件事放在一起,说明了一个问题:DeepSeek 并不是简单通过低价补贴市场,它很可能已经建立了非常强的成本控制和工程优化能力。
反过来看,其他大模型公司之所以价格更高,未必完全是因为模型能力更强,也可能是它们在推理效率、算力利用率和系统工程上,还有很大的优化空间。
过去大家讨论大模型竞争,往往更关注参数规模、榜单成绩和模型能力。但从商业角度看,谁能用更低的成本提供相近甚至更好的能力,可能才是真正决定长期竞争力的因素。
DeepSeek 最重要的优势之一,或许并不只是“模型做得好”,而是“用更低的成本把模型做得足够好”。
我的第二个感触,是梁文锋对盈利和理想之间关系的态度。
DeepSeek 之所以能够坚持一些长期目标,很重要的原因是梁文锋此前通过幻方量化积累了大量利润。这些利润为 DeepSeek 提供了更长的时间、更大的试错空间,也让它不需要过度迎合短期资本市场。
但即使拥有这样的基础,梁文锋依然明确承认:DeepSeek 首先是一家公司,公司首先要活下来,然后才有资格追求更长期的目标。
这句话听起来并不浪漫,却非常真实。
很多公司喜欢强调使命、愿景和长期主义,但如果一家公司没有稳定的现金流,也没有足够的利润,那么所谓长期主义很可能只是推迟面对现实。
真正的长期主义,不是不考虑商业回报,而是建立在商业回报之上。
公司只有先创造利润,才能用利润去支持那些短期内看不到回报、但长期可能产生巨大价值的事情。否则,长期目标最终仍然会受制于融资环境、投资人耐心和市场周期。
从这个角度看,利润并不是理想的对立面,利润反而是理想能够持续存在的前提。
第三点,是我对大模型技术上限的判断更加乐观了。
现在很多模型虽然总参数量已经非常大,但在一次推理过程中,真正同时被激活的参数通常只有几十 B。
这意味着,我们今天看到的模型能力,可能还不是大规模神经网络的真正上限,而只是当前算力、通信效率和模型架构限制下的阶段性结果。
假如未来模型能够在可接受的成本和延迟下,同时激活 100B,甚至几百 B 的参数,模型的能力可能还会再上一个明显的台阶。
当然,参数激活量增加并不必然等于能力同比例增长。模型架构、训练数据、推理方法和后训练技术同样重要。
但这至少说明,目前的大模型远没有进入“技术已经基本成熟,只剩下产品落地”的阶段。
基础模型本身仍然存在巨大的提升空间。
今天我们觉得模型已经很聪明,可能只是因为过去的软件太不聪明。站在更长的时间尺度上看,现在的大模型也许仍然处于非常早期的阶段。
第四点,对我来说更像是一次纠偏。
此前我对具身智能相对乐观,认为随着大模型能力提升,机器人和现实世界的结合可能会很快出现一批真正有价值的公司。
但梁文锋在谈到不同技术方向时,把具身智能的落地排在了相对靠后的位置。
这至少意味着,在他的判断里,具身智能距离大规模商业化,可能比很多人想象得更远。
原因也不难理解。
纯软件模型可以依靠算力、数据和算法快速迭代,但具身智能还需要面对硬件成本、传感器精度、机械可靠性、安全责任和现实环境复杂性等问题。
软件中的错误,可能只是生成了一段不准确的文字;机器人在现实世界中的错误,却可能直接造成财产损失甚至人身伤害。
这使得具身智能的产品迭代速度,很难完全复制大模型软件的发展速度。
因此,我开始重新考虑:现在是否真的应该过早押注具身智能公司。
具身智能长期可能仍然是一个巨大的方向,但“长期价值巨大”和“当前值得投资”是两件不同的事。方向正确,并不意味着进入时点也正确。
第五点,是关于中国和美国大模型公司的差距。
梁文锋认为,中国公司与美国领先公司的差距,大约只有一年。这个判断我基本认同。
更重要的是,他对这一年差距的来源给出了具体解释:主要是算力差距,以及高质量标注数据的差距,而不是人才差距。
这个判断非常关键。
如果差距主要来自人才,那么追赶会非常困难,因为人才培养、组织能力和科研文化都需要长期积累。
但如果差距主要来自算力和数据,那么它虽然仍然难以解决,却至少是一个相对明确的工程和资源问题。
中国并不缺优秀的算法工程师和研究人员。DeepSeek 本身的表现,也已经在一定程度上证明,中国团队有能力在有限算力条件下,通过架构创新和工程优化缩小差距。
当然,算力限制并不是一个小问题。高质量数据也不只是花钱就能立刻获得。但至少从底层能力看,中美之间并不存在不可跨越的人才鸿沟。
这意味着,中国大模型公司真正需要解决的,不是“我们是否有能力追上”,而是“如何在资源受限的情况下,以更高效率追上”。
没啥可说的,梁文锋很厉害,期待 DeepSeek 实现 AGI 时刻。
2026-07-19 05:31:21
黑洞足迹是我的第二个一人 APP。第一个是黑洞健身。
大家有没有想过,我们这辈子去了很多很多的地方,但是很多地方最后都忘记了。有些时候想找也找不到那个地方在哪儿了。
另外,在工作方面,我们需要记录大量的合作伙伴的地址,方便出差的时候拜访。但是这些地址并没有一个特别方便的地方保存和查询。
我之前是在高德地图上把相关的地址收藏起来,再加上相应的标签和备注。但是这些信息并不容易搜索,也不方便对我的 AI 大模型开放。
于是我做了黑洞足迹。这是一个 AI 时代的一人 APP。结合了 AI 大模型对自然语言理解的能力和向量检索数据库。
黑洞足迹有两个功能。
第一个功能是可以对一个地址添加相关的图片和文字描述。如下图:

AI 会根据你的描述对地址进行分类,打上相关的标签。如下图:

第二个功能是可以用 RAG 向量检索的方式查找之前索引的所有地址。比如我问它,我之前吃过的一家面馆很好吃,它就帮我找到了我刚刚记录的那条。

在未来,我还打算让它关联我的相册,自动把我的足迹与照片匹配,并且开放 MCP 接口。
这样,以后这些问题 AI 都可以帮我回答了:
“3 年前的大学同学聚会,我们在学校附近的餐馆聚餐,具体是哪家餐馆?”
“过去 5 年我去了哪些城市?”
“下周我要去上海拜访达人,帮我把达人 A、B、C 的地址都调出来,安排一下相关的行程,尽可能顺路。”
“我去年去新疆旅游的时候,吃过一家面馆,特别好吃。帮我找出来是哪家。”
“我 10 年前的小学地址现在不见了,你帮我找一下当时的地址上现在是什么建筑”
是不是很有意思?技术实现上,我用了 Deepseek v4 PRO 的 API 做语义识别,用 Cloudflare 搭的免费服务器和向量数据库,用高德地图 SDK 做的本地地图渲染和 POI 获取。
如果你感兴趣,你也去开发一个自己的一人 APP 吧。
2026-07-12 22:05:00
平台:macOS(Apple Silicon / Homebrew)· 版本:CLIProxyAPI 7.2.65
如果你手上有 ChatGPT/Codex 的订阅账号,却想在自己的脚本、IDE 插件或第三方工具里以「标准 OpenAI API」的方式调用它,CLIProxyAPI 就是干这件事的。它能把 Gemini CLI、Codex、Claude Code、Qwen Code 这类基于 OAuth 登录的 CLI 工具,统一包装成一个本地的、OpenAI 兼容的 HTTP 服务。
本文记录一次真实的安装与配置过程:从 brew install 到登录 Codex,再到起服务、验证,最后还踩了一个 Surge 代理拦截本地请求 的坑。
1 |
brew install cliproxyapi |
安装完成后,几个关键路径值得记一下(Apple Silicon 下的默认位置):
| 项目 | 路径 |
|---|---|
| 可执行文件 | /opt/homebrew/bin/cliproxyapi |
| 配置文件 | /opt/homebrew/etc/cliproxyapi.conf |
| 认证目录(存放 OAuth token) | ~/.cli-proxy-api |
| 默认监听端口 | 8317 |
看一下它支持哪些登录方式:
1 |
cliproxyapi --help |
输出里能看到一堆 -xxx-login 选项,我们关心的是这两个:
1 |
-codex-login Login to Codex using OAuth |
这是整个流程的核心。直接运行:
1 |
cliproxyapi -codex-login |
它会:
/opt/homebrew/etc/cliproxyapi.conf,把 token 存到 ~/.cli-proxy-api;登录成功后,你会在认证目录里看到一个以账号命名的 JSON 文件:
1 |
$ ls -la ~/.cli-proxy-api |
没有图形界面 / 远程服务器? 改用设备码流程或禁止自动开浏览器:
1
2 cliproxyapi -codex-device-login # 设备码,在别的设备打开链接授权
cliproxyapi -codex-login -no-browser # 不自动开浏览器,自己复制链接
打开配置文件 /opt/homebrew/etc/cliproxyapi.conf,默认的 api-keys 是一组占位符:
1 |
api-keys: |
这是客户端调用你这个代理时要携带的密钥(Bearer Token),和上面的 Codex 登录是两码事。建议换成你自己的一个强随机值。生成一个:
1 |
echo "sk-$(openssl rand -hex 24)" |
然后把配置改成(只保留你需要的即可):
1 |
api-keys: |
配置文件里其它值得留意的字段:
1 |
port: 8317 # 监听端口 |
用 Homebrew 的 services 管理,后台常驻 + 开机自启:
1 |
brew services start cliproxyapi |
确认状态和端口:
1 |
brew services list | grep cliproxy # 应显示 started |
如果只想临时前台运行、方便看日志,直接跑
cliproxyapi即可。
服务地址是 http://127.0.0.1:8317/v1,接口是 OpenAI 兼容格式。
1 |
KEY="sk-你的密钥" |
能返回一批模型(Codex 账号可用的 gpt-5.x 系列,如 gpt-5.5、gpt-5.4、gpt-5.4-mini、gpt-5.3-codex-spark、codex-auto-review 等)就说明 token 生效了。
1 |
curl http://127.0.0.1:8317/v1/chat/completions \ |
拿到类似下面的响应(content: "ok"、usage 有计费),就彻底打通了:
1 |
{ |
第一次 curl 验证时,我拿到的不是 JSON,而是一个 Surge 的错误页:
1 |
<h1>Connection Closed</h1> |
原因:系统里开着 Surge,curl 默认走了系统代理,发往 localhost:8317 的请求被 Surge 拦下并试图代理,结果失败。
临时绕过(命令行直连本地):
1 |
curl --noproxy '*' http://127.0.0.1:8317/v1/models -H "Authorization: Bearer $KEY" |
长期解决(在 Surge 配置里让本地环回直连)——把这条规则放在 [Rule] 的靠前位置:
1 |
[Rule] |
几点说明:
127.0.0.0/8 是整个环回段(IANA 保留),全部直连安全,涵盖 127.0.0.1;no-resolve 表示匹配这条规则时不做 DNS 解析,只对 IP 字面量请求生效——正好对应我们用 127.0.0.1 直连的场景,还能避免为域名请求触发多余解析;⚠️ 注意:因为加了
no-resolve,这条规则不匹配localhost这个主机名。如果你习惯用http://localhost:8317,再补一条:
1 DOMAIN,localhost,DIRECT
改完重载 Surge 配置后,curl 就不用再加 --noproxy '*' 了。
除了改 YAML + 敲命令,CLIProxyAPI 还内置了一个 WebUI 管理面板(CLI Proxy API Management Center,简称 CPAMC)。它由服务从 GitHub 自动下载并托管,不用单独安装。
http://127.0.0.1:8317/management.html
不过它默认是关闭的:配置里的 remote-management.secret-key 为空时,整个管理 API(/v0/management/*)会返回 404——面板页面能打开,但里面所有操作都用不了。这也是安全默认值。
1. 设置管理密钥(配置文件 remote-management 段):
1 |
remote-management: |
生成一个密钥:
1 |
echo "mk-$(openssl rand -hex 24)" |
2. 重启服务:
1 |
brew services restart cliproxyapi |
3. 打开面板并用这个 key 登录:
1 |
http://127.0.0.1:8317/management.html |
启用后可以验证一下:管理 API 会从 404(禁用)变成 401(启用并强制鉴权),带上 key 则返回 200:
1 |
SK="你的管理密钥" |
管理 OAuth 账号(登录 / 登出 / 多账号池)、增删 API key、编辑配置、查看模型与请求状态等——基本就是把前面手动改 YAML、跑命令的事图形化了。
⚠️ 两个坑要注意
- 明文密钥保存好:服务启动时会把配置里的
secret-key自动改写成 bcrypt 哈希($2a$10$...),之后配置文件里就看不到明文了。明文只有你自己留存的那份,弄丢就得重设一个再重启。- 访问前确认 Surge 规则生效:浏览器打开
127.0.0.1:8317同样会被 Surge 拦,先确保上一节那条IP-CIDR,127.0.0.0/8,DIRECT,no-resolve已生效。安全上
allow-remote保持false(仅本机)。真要跨机访问,务必配 TLS + 强 key,别把账号管理接口裸暴露到网络上。
由于是 OpenAI 兼容接口,绝大多数支持自定义 base_url 的工具都能直接接:
1 |
export OPENAI_API_KEY="sk-你的密钥" |
Python SDK 示例:
1 |
from openai import OpenAI |
1 |
brew services restart cliproxyapi # 改配置后重启生效 |
整套流程其实很短:
brew install cliproxyapicliproxyapi -codex-login 登录 Codexapi-keys
brew services start cliproxyapi 起服务curl 验证唯一容易卡住的地方,是本机开着 Surge 这类代理时,本地请求会被拦——一条 IP-CIDR,127.0.0.0/8,DIRECT,no-resolve 规则即可解决。之后,你就有了一个本地的、OpenAI 兼容的 Codex 网关,可以接到任何认 base_url 的工具里。
如果不想一直跟 YAML 打交道,别忘了还有内置的 WebUI 管理面板(http://127.0.0.1:8317/management.html)——设个 secret-key 重启就能用,账号、密钥、配置都能图形化管理。
2026-07-07 08:23:34
提示词:如何写一篇 AI 味很重的文章,给我一个范例。
希望大家都能借此识别 AI 生成的文章。
以下是成品。
在当今信息化、数字化、智能化浪潮风起云涌、日新月异的时代背景下,写作已经不再只是简单的文字表达,而是观点输出、信息传递、价值塑造和认知建构的重要方式。随着人工智能技术突飞猛进、方兴未艾,越来越多的文章开始呈现出结构清晰、逻辑严密、表达规范、内容全面的特点。如何写出一篇 AI 味很重的文章,已经成为一个值得深入探讨、系统梳理、持续优化的重要课题。
首先,要注重文章结构的完整性和层次感。一篇 AI 味很重的文章,通常需要具备清晰的开头、主体和结尾,做到有条不紊、层层递进、环环相扣。在开头部分,可以先从宏观背景切入,强调时代发展、技术进步、社会变革和产业升级等宏大主题。例如,可以使用“随着时代的发展”“在数字化浪潮的推动下”“在人工智能不断赋能千行百业的背景下”等表达方式,从而让文章显得高屋建瓴、立意深远、格局宏大。
其次,要善于使用抽象而全面的表达。AI 味较重的文章往往不会拘泥于某一个具体场景,而是会从多个维度进行系统分析。例如,在讨论写作方法时,可以从内容、结构、语言、逻辑、表达、传播、价值、生态等方面展开论述。这样不仅能够增强文章的完整性,也能够体现出系统化思维、全局化视角和综合性判断,给人一种面面俱到、滴水不漏、条分缕析的感觉。
再次,要合理使用连接词和过渡句。为了让文章看起来更加流畅自然、逻辑清晰,可以大量使用“首先”“其次”“再次”“最后”“与此同时”“值得注意的是”“从某种意义上说”“不可忽视的是”“综上所述”等表达。这些词语能够有效增强文章的秩序感和节奏感,使读者感受到内容之间循序渐进、由表及里、由浅入深的逻辑关系。
此外,AI 味很重的文章通常需要保持客观、中立、理性和全面。不要轻易表达过于鲜明的个人态度,也不要使用过于情绪化、口语化、个性化的语言。可以多采用“既有机遇,也有挑战”“既要看到积极意义,也要警惕潜在问题”“不能一概而论,需要具体问题具体分析”等句式。这样的表达方式能够让文章显得稳扎稳打、左右逢源、进退有据,既避免偏激,又显得成熟稳重。
在语言风格上,也应当尽量选择规范、正式、宏观的词汇。例如,可以多使用“赋能”“优化”“提升”“推动”“促进”“构建”“完善”“生态”“闭环”“路径”“机制”“体系”“抓手”“底座”“支撑”等词语。同时,还可以适当加入“与时俱进”“因地制宜”“统筹兼顾”“行稳致远”“久久为功”“精益求精”“守正创新”“多措并举”“协同推进”等成语和四字表达。虽然这些词语不一定能提供非常具体的信息,但能够有效提升文章的正式感、厚重感和时代感。
更进一步,想要增强 AI 味,还可以大量使用成对出现的排比句。例如,可以写道:“既要立足当下,也要着眼未来;既要脚踏实地,也要高瞻远瞩;既要守正创新,也要久久为功;既要统筹兼顾,也要精准施策。”这种表达方式节奏鲜明、朗朗上口、气势充沛,能够让文章呈现出一种庄重、规范、全面而又略显空泛的风格。
除了成语和四字词之外,类比也是写出 AI 味的重要方法。一个典型的 AI 味类比,通常并不追求多么新颖独特,而是追求通俗易懂、稳妥安全、看似形象。例如,可以把写作比作“搭建一座大厦”,结构是地基,观点是梁柱,案例是砖瓦,语言是装饰。也可以把文章比作“一棵大树”,主题是树根,逻辑是树干,论据是枝叶,结尾是果实。这样的类比虽然并不惊艳,但能够有效增强文章的可读性,让内容显得深入浅出、形象生动、老少皆宜。
举例来说,如果要说明 AI 味文章的写作方法,可以这样类比:“写一篇 AI 味很重的文章,就像搭建一套标准化样板间。开头是宽敞明亮的大门,负责营造宏观氛围;主体是分区明确的客厅、卧室和书房,负责承载不同维度的内容;过渡句则像走廊,将各个空间有机连接;结尾则像一盏明亮的吊灯,在最后时刻进行主题升华,使整篇文章看起来完整、协调、统一。”这种类比看似生动,实则安全,既不会过于锋利,也不会偏离主题,非常适合用于增强文章的 AI 风格。
在具体举例时,也要避免过于真实、尖锐和细节化的表达。比如,在教育领域,可以写道:“人工智能技术正在持续赋能教育场景,推动教学模式从传统化向智能化、个性化和高效化方向转变。”在医疗领域,可以写道:“人工智能有助于提升医疗服务效率,优化诊疗流程,推动医疗资源更加科学、高效、合理地配置。”在企业管理领域,则可以写道:“AI 技术正在帮助企业降本增效、提质增效、协同增效,推动组织管理从粗放式向精细化、智能化、体系化方向转型。”
这些表达虽然没有涉及具体的人物、具体事件、具体数据和具体矛盾,但能够体现出文章的广泛适用性、宏观概括性和高度稳定性。它们像万能钥匙一样,可以打开很多话题的大门;也像标准模板一样,可以被灵活套用到教育、医疗、金融、制造、零售、传媒等多个领域,做到举一反三、触类旁通、一通百通。
最后,文章结尾应当适当拔高主题,做到收束有力、余音绕梁、意味深长。可以从未来趋势、长期价值、社会意义和时代使命等角度进行总结。例如,可以写道:“总体来看,写出一篇 AI 味很重的文章,不仅需要掌握规范化的表达方式,也需要具备系统化、结构化和综合化的思维能力。未来,随着人工智能技术的持续发展,相关写作方式也将不断演进,并在更多场景中发挥不可替代的重要作用。”
综上所述,写一篇 AI 味很重的文章,关键在于结构清晰、表达全面、语言规范、观点平衡、成语丰富、类比稳妥、结尾升华。只要能够合理运用宏观背景、抽象词汇、标准句式、四字成语和安全类比,就能够有效写出一篇具有典型 AI 风格的文章。唯有如此,方能在内容表达中做到有章可循、有据可依、有的放矢,并在持续优化中实现从规范写作到高质量表达的稳步迈进。
2026-07-04 07:00:34
事情得回到三个月前,当时为了体验某个 AI 开发工具,我用它做了一个叫”黑洞健身”的 App(黑洞这个名字取自我家的黑猫)。
用了一段时间之后,我把 App 代码导出到 GitHub,开始用 Opus 来继续迭代它。
刚开始黑洞健身还是 Web 版本,以 PWA 模式安装到桌面。后面我又抽空让 AI 把它重写成 Android 原生版本。
下图就是这个 App 首页现在的样子:

这是一个典型的一人 App。下面说说这个 App 的进化和感受。
第一个形态:极简原型。 黑洞健身的第一版特别简单,只有一个极简地记录我的俯卧撑次数+组间休息倒计时的功能。它帮助我知道了,这是不是我想要的需求。
第二个形态:完善。 使用了一周后,我确定我需要它。所以我开始完善它。我加了运动项目管理,组间休息时间设定,每周和每日的数据统计,后面又加了运动计划。
第三个形态:数据同步和开放。 当我的数据变多,我增加了账号系统,提供了 MCP 接口。这是我想强调的进化阶段:未来每个一人 App 都必须开放数据接口。

有了 MCP 接口以后,我开始让我的 Agent 拉取数据,与我的体检报告整合,给我运动建议。这个 App 变成了我的个人 AI 助理的一个数据源。
第四个形态:自进化。 我把 GitHub 上面代码设置了相关的 hook,我或者其它授权的人只需要发 issue 就可以唤醒 claude 迭代代码,发出 pull request。其实我的 AI Agent 愿意,它也可以发 issue。

App 在这个阶段,可以自我进化,也可以被 Agent 通过 issue 进化,而我只需要确认即可。
Web 版本的详细进化 log 都记录在:https://fit-time.pages.dev/changelog,感兴趣的可以翻阅。
Web 版本虽然我不用了,但是网址还在,如果你想围观可以用 Chrome 打开:https://fit-time.pages.dev/
我个人定制的”黑洞健身”一人 App 帮助我在过去三个月坚持做到了锻炼,以下是刚刚过去的 6 月的健身记录(紫色🟣表示无氧运动,绿色🟢表示有氧运动):

AI 时代的一人 App 会经历:原型、完善、开放数据、自进化的演化过程。
如果你还没有一个自己的”一人 App”,赶紧用你的 AI 造一个吧。