DevTang | 唐巧修改

2026-07-27 23:19:19

我用了很长一段时间的 Bartender。

对于菜单栏里常驻着一大堆应用的 Mac 用户来说，Bartender 确实很好用：不常用的图标可以隐藏，需要时再展开，整个菜单栏看起来清爽很多。尤其是换到带刘海的 MacBook 之后，菜单栏空间更加紧张，这类工具几乎成了必需品。

不过最近升级到最新版 macOS Tahoe 26.5 后，我使用的 Bartender 5 开始频繁崩溃。重新启动应用只能暂时解决问题，没过多久它又会退出。菜单栏图标重新挤成一团，使用体验自然也谈不上愉快。

我本来打算直接升级 Bartender 6，结果发现还需要再付 20 美元。Bartender 当然是一款成熟的软件，开发者对大版本升级收费也可以理解。但对我来说，最核心的需求只是隐藏和整理菜单栏图标，为此再购买一次升级，多少有些犹豫。

于是我开始寻找替代品，并发现了 Thaw。

Thaw 是什么

Thaw 是一款开源的 macOS 菜单栏管理工具，基于 Ice 项目发展而来。Ice 原本就是一个很受欢迎的 Bartender 替代品，而 Thaw 在它的基础上继续修复问题，并适配新版 macOS。

它提供了我最需要的几个功能：

• 隐藏和显示菜单栏图标
• 设置“始终隐藏”的图标区域
• 自动重新隐藏已经展开的图标
• 使用快捷键控制菜单栏
• 将隐藏的图标显示在独立的第二菜单栏中
• 搜索菜单栏项目
• 调整菜单栏的外观和图标间距

Thaw 采用 GPL-3.0 协议开源，可以免费下载使用。通过 Homebrew 安装也很方便：

1

brew install thaw

安装完成后，需要按照引导授予相应的辅助功能和屏幕录制权限。这类菜单栏管理工具需要识别并操作其他应用的菜单栏图标，因此这些权限基本无法避免。

从 Bartender 迁移

Thaw 的使用逻辑和 Bartender 比较接近，所以迁移过程并不复杂。

安装后，我重新划分了可见、隐藏和始终隐藏的菜单栏区域，把输入法、电池、网络等常用图标留在外面，将网盘、更新程序以及一些偶尔才会打开的工具放进隐藏区域。

我还开启了自动重新隐藏。这样展开菜单栏并完成操作后，图标会再次自动收起，日常使用时几乎不需要额外操心。

如果菜单栏图标很多，或者使用的是带刘海的 MacBook，也可以启用 Thaw 的独立菜单栏。隐藏的图标会显示在主菜单栏下方，不会因为空间不足而被刘海挡住。这个功能很实用，也是它比较接近 Bartender 的地方。

使用感受

用了几天之后，我对 Thaw 的整体感觉是：还不错，已经可以满足我的需求。

更重要的是，它免费、开源，并且仍在针对新版 macOS 持续维护，推荐给大家。

2026-07-23 15:50:00

最近，我看完了梁文锋面向投资人的四小时会议录音文字版。

相比那些经过高度提炼的公开演讲，这场交流里有更多关于成本、盈利、技术路线和行业节奏的具体判断。看完之后，我对大模型行业的一些看法发生了变化，也有一些原有判断得到了强化。

其中有五点，让我印象最深。

一、DeepSeek 的单位算力经济性，可能比外界想象得更好

梁文锋提到，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 下的默认位置）：

看一下它支持哪些登录方式：

1

cliproxyapi --help

输出里能看到一堆 -xxx-login 选项，我们关心的是这两个：

1
2

-codex-login          Login to Codex using OAuth
-codex-device-login   Login to Codex using device code flow

二、登录 Codex

这是整个流程的核心。直接运行：

1

cliproxyapi -codex-login

它会：

1. 自动读取默认配置 /opt/homebrew/etc/cliproxyapi.conf，把 token 存到 ~/.cli-proxy-api；
2. 自动打开浏览器，跳转到 OpenAI/ChatGPT 的 OAuth 授权页（回调端口是 1455，确保没被占用）；
3. 你用 拥有 ChatGPT 付费订阅（Plus/Pro/Team）的账号 登录并授权；
4. 授权成功后，token 落盘到认证目录。

登录成功后，你会在认证目录里看到一个以账号命名的 JSON 文件：

1
2

$ ls -la ~/.cli-proxy-api
-rw-r--r--  1 you  staff  4152  codex-你的账号@xxx.com-pro.json

没有图形界面 / 远程服务器？ 改用设备码流程或禁止自动开浏览器：

1 2	cliproxyapi -codex-device-login # 设备码，在别的设备打开链接授权 cliproxyapi -codex-login -no-browser # 不自动开浏览器，自己复制链接

三、配置访问密钥

打开配置文件 /opt/homebrew/etc/cliproxyapi.conf，默认的 api-keys 是一组占位符：

1
2
3
4

api-keys:
  - "your-api-key-1"
  - "your-api-key-2"
  - "your-api-key-3"

这是客户端调用你这个代理时要携带的密钥（Bearer Token），和上面的 Codex 登录是两码事。建议换成你自己的一个强随机值。生成一个：

1

echo "sk-$(openssl rand -hex 24)"

然后把配置改成（只保留你需要的即可）：

1
2

api-keys:
  - "sk-你生成的随机字符串"

配置文件里其它值得留意的字段：

1
2
3
4

port: 8317                      # 监听端口
auth-dir: "~/.cli-proxy-api"    # OAuth token 存放目录
proxy-url: ""                   # 上游代理，需要时填 socks5:// / http://
debug: false                    # 排障时可开

四、启动服务

用 Homebrew 的 services 管理，后台常驻 + 开机自启：

1

brew services start cliproxyapi

确认状态和端口：

1
2

brew services list | grep cliproxy      # 应显示 started
lsof -iTCP:8317 -sTCP:LISTEN            # 应看到 cliproxyapi 在 LISTEN

如果只想临时前台运行、方便看日志，直接跑 cliproxyapi 即可。

五、验证

服务地址是 http://127.0.0.1:8317/v1，接口是 OpenAI 兼容格式。

1. 列出模型

1
2
3

KEY="sk-你的密钥"
curl http://127.0.0.1:8317/v1/models \
  -H "Authorization: Bearer $KEY"

能返回一批模型（Codex 账号可用的 gpt-5.x 系列，如 gpt-5.5、gpt-5.4、gpt-5.4-mini、gpt-5.3-codex-spark、codex-auto-review 等）就说明 token 生效了。

2. 发一次真实对话（端到端验证）

1
2
3
4
5
6
7

curl http://127.0.0.1:8317/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "reply with exactly: ok"}]
  }'

拿到类似下面的响应（content: "ok"、usage 有计费），就彻底打通了：

1
2
3
4
5

{
  "model": "gpt-5.5",
  "choices": [{"message": {"role": "assistant", "content": "ok"}, "finish_reason": "stop"}],
  "usage": {"prompt_tokens": 307, "completion_tokens": 15, "total_tokens": 322}
}

六、踩坑：Surge（或其它系统代理）会拦截本地请求

第一次 curl 验证时，我拿到的不是 JSON，而是一个 Surge 的错误页：

1
2
3

<h1>Connection Closed</h1>
访问的 URL 不可用: http://localhost:8317/v1/models
Policy: Reality  ·  错误描述：Read stream EOF

原因：系统里开着 Surge，curl 默认走了系统代理，发往 localhost:8317 的请求被 Surge 拦下并试图代理，结果失败。

临时绕过（命令行直连本地）：

1

curl --noproxy '*' http://127.0.0.1:8317/v1/models -H "Authorization: Bearer $KEY"

长期解决（在 Surge 配置里让本地环回直连）——把这条规则放在 [Rule] 的靠前位置：

1
2

[Rule]
IP-CIDR,127.0.0.0/8,DIRECT,no-resolve

几点说明：

• 127.0.0.0/8 是整个环回段（IANA 保留），全部直连安全，涵盖 127.0.0.1；
• no-resolve 表示匹配这条规则时不做 DNS 解析，只对 IP 字面量请求生效——正好对应我们用 127.0.0.1 直连的场景，还能避免为域名请求触发多余解析；
• Surge 自上而下、首个命中生效，所以要放前面。

⚠️ 注意：因为加了 no-resolve，这条规则不匹配 localhost 这个主机名。如果你习惯用 http://localhost:8317，再补一条：

1	DOMAIN,localhost,DIRECT

改完重载 Surge 配置后，curl 就不用再加 --noproxy '*' 了。

七、WebUI 管理面板（可选）

除了改 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
2
3

remote-management:
  allow-remote: false        # 只允许本机访问，保持 false 最安全
  secret-key: "生成一个强随机串" # 启动时会自动哈希

生成一个密钥：

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
2
3
4
5
6

SK="你的管理密钥"
# 两种鉴权头都支持
curl --noproxy '*' -H "Authorization: Bearer $SK" \
  http://127.0.0.1:8317/v0/management/config
curl --noproxy '*' -H "X-Management-Key: $SK" \
  http://127.0.0.1:8317/v0/management/config

面板能做什么

管理 OAuth 账号（登录 / 登出 / 多账号池）、增删 API key、编辑配置、查看模型与请求状态等——基本就是把前面手动改 YAML、跑命令的事图形化了。

⚠️ 两个坑要注意

1. 明文密钥保存好：服务启动时会把配置里的 secret-key 自动改写成 bcrypt 哈希（$2a$10$...），之后配置文件里就看不到明文了。明文只有你自己留存的那份，弄丢就得重设一个再重启。
2. 访问前确认 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
2

export OPENAI_API_KEY="sk-你的密钥"
export OPENAI_BASE_URL="http://127.0.0.1:8317/v1"

Python SDK 示例：

1
2
3
4
5
6
7
8
9
10
11
12

from openai import OpenAI

client = OpenAI(
    api_key="sk-你的密钥",
    base_url="http://127.0.0.1:8317/v1",
)

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "你好"}],
)
print(resp.choices[0].message.content)

九、常用管理命令

1
2
3
4

brew services restart cliproxyapi   # 改配置后重启生效
brew services stop cliproxyapi      # 停止服务
cliproxyapi -codex-login            # 重新登录 / 换账号
cliproxyapi --help                  # 查看所有登录方式与参数

小结

整套流程其实很短：

1. brew install cliproxyapi
2. cliproxyapi -codex-login 登录 Codex
3. 改配置里的 api-keys
4. brew services start cliproxyapi 起服务
5. 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 造一个吧。