DevTang | 唐巧修改

2026-08-07 16:24:00

增长遇到瓶颈时，团队很容易把希望寄托在“多开一个渠道”上：找更多达人、进入更多平台、铺更多线下门店，或者接入一个看起来拥有大量用户的合作方。

但渠道越多，生意不一定越好。它可能带来增量，也可能只是把原来的订单重新分配一遍；可能提升收入，也可能因为价格竞争、重复补贴和履约成本，反而稀释利润。

因此，讨论渠道时，真正重要的问题不是“还能去哪里卖”，而是：这个渠道能否创造可持续利润？能否与现有渠道协同？能否形成一套长期有效的合作规则？

一、渠道的第一价值，是创造可持续利润

渠道最直接的作用是销售，但对一家产品型公司来说，它更深层的价值是创造利润。利润支撑研发、产品迭代和长期服务，最终又反过来提高产品竞争力。

所以，衡量一个渠道不能只看销售额，更要看完整的利润结构：

• 为获得订单投入了多少内容、广告和人力成本？
• 平台扣点、物流、退换货和售后占了多少？
• 促销之后还剩下多少贡献利润？
• 这种利润是否稳定，能否持续投入？

一个销售额很大的渠道，如果高度依赖补贴，或者需要持续投入大量人工维护，未必是好渠道。相反，一个规模暂时不大、但利润健康且具备复购潜力的渠道，可能更值得长期建设。

收入让业务看起来在增长，利润才让团队真正有能力继续增长。

二、投放渠道和成交渠道，本来就不会完全一致

今天的消费者很少在单一渠道内完成全部决策。他们可能在内容社区第一次认识产品，在短视频或直播中被种草，去电商平台比较价格，最后在私域、门店或另一个平台完成购买。

这意味着，营销费用发生在哪里，订单就一定在哪里成交，是一个不现实的假设。

常见的路径包括：

• 在内容平台完成认知，最终在综合电商平台下单；
• 通过达人活动产生兴趣，之后进入私域成交；
• 在线下门店体验产品，回家后在线上购买；
• 在效果广告中看到产品，经过多次搜索和比较后才完成交易。

如果只按“最后一次点击”评价渠道，就容易高估成交平台，低估前端的认知和种草渠道。反过来，如果只看曝光和互动，也可能把热闹误认为真实增长。

更合理的做法，是把渠道放在完整用户旅程中观察：它负责认知、种草、比较还是成交？它是否提升了整体转化？当这项投入减少时，总销售是否也会下降？

渠道评价的对象，不应只是最后一跳，而应是整条转化链路。

三、渠道重叠不可怕，边界不清才会造成内卷

只要渠道足够多，就一定会发生重叠。不同电商平台会争夺相同的用户，线上和线下会销售相同的产品，达人、私域和直营网店也可能触达同一批人。

重叠本身不是问题。问题在于，当各渠道没有明确边界时，它们会围绕同一批存量订单竞争：

• 为争夺成交不断压低价格；
• 在同一时间重复发券和补贴；
• 抢占彼此已经培育成熟的客户；
• 因归因不清而争夺业绩；
• 让合作伙伴逐渐失去投入动力。

最终，消费者可能买得更便宜，但公司并没有获得更多新客户，渠道伙伴也没有赚到合理利润。表面上销售繁荣，实际上只是利润在内部消耗。

解决办法不是消灭渠道重叠，而是建立边界。边界可以来自人群、区域、产品组合、服务内容、价格权限或活动时间。只要每个渠道清楚自己创造什么价值、服务什么场景，重叠就可以转化为协同，而不是冲突。

四、真正的渠道协同，是价格与节奏的协同

渠道不能各自为战。

例如，达人直播负责集中制造声量和转化时，主流电商平台需要维持稳定的价格环境，避免用户跨平台比价后发现价格混乱。到了大型平台促销季，达人活动则可以主动错峰，减少同一时间的价格碰撞。

这种协同至少需要三套共同规则：

第一，价格规则。 谁可以发券，优惠幅度如何设置，特殊活动如何报备，都需要提前约定。

第二，活动日历。 平台大促、达人直播、私域活动和线下促销应统一规划，避免多个渠道在同一时间争夺同一批用户。

第三，渠道角色。 有的渠道负责建立认知，有的负责体验和服务，有的负责高效成交。不能要求所有渠道都用同一方式证明价值。

好的渠道体系，不是每个渠道都做到最大，而是它们组合在一起时，整体利润最大。

五、判断一项合作，先过三道门槛

无论是内部团队合作，还是外部渠道合作，都应该先回答三个问题。

1. 它创造的是增量，还是重新分配存量？

如果合作只是把原本会在直营网店成交的订单，转移到另一个需要额外分成的渠道，那么收入归属发生了变化，整体利润却未必增加。

真正的增量通常来自新人群、新区域、新场景、新产品组合或新的服务能力。

2. 它能否达到最低有效规模？

合作有大量隐性成本：系统接入、商务沟通、物料制作、培训、库存、结算和售后。销量太小，即使单笔订单有利润，也可能无法覆盖组织成本。

因此，合作开始前就应约定分阶段的规模目标，并用短周期验证，而不是因为对方“看起来有资源”就长期投入。

3. 双方是否都能持续挣钱？

任何一方长期不挣钱，合作都难以持续。品牌方需要利润支持产品和服务，渠道方也需要合理收益来覆盖获客、运营和履约成本。

双赢不是一句态度表述，而是一张能够算清楚的利润表。

六、有资源，不等于有销量

曾有一家拥有大量内容用户的教育类平台，希望将自己的流量资源用于推广一款学习硬件。双方看起来非常匹配：一方有目标用户和内容场景，另一方有产品，还可以通过成熟的分销工具快速启动。

但合作上线后，销量始终没有形成有效规模。流量池确实存在，用户对内容也有信任，却没有自然转化为对硬件产品的购买需求。

另一次合作发生在教育服务渠道与文化零售场景之间。合作方拥有线下触点和品牌背书，但产品与用户当时的到店目的、决策周期和服务能力并不匹配，最终成交寥寥。

这两类案例的共同问题，不是“对方没有资源”，而是把资源存在误认为需求成立：

• 用户画像相似，不代表购买意图相同；
• 有流量入口，不代表有完整的转化链路；
• 能快速上线，不代表有人持续经营；
• 有品牌背书，不代表产品适合当下场景；
• 有少量成交，不代表商业模型能够规模化。

渠道合作最需要验证的，不是合作方有多知名，而是用户为什么会在这个场景购买、谁负责持续运营，以及单位经济模型能否跑通。

七、把渠道合作变成一套可管理的机制

对于内部渠道，也可以采用接近供应商管理的方式：给予清晰的供货和利润空间，同时设置相应的价格、销量与渠道责任。这样既能激励合作，也能避免内部关系替代商业判断。

一套基本机制可以包括四个部分：

做增量。 明确合作负责的人群、区域、场景或产品组合，不切走已有渠道的自然订单。

控价格。 建立统一价格体系、促销审批和违规处理机制，避免用低价换取短期销量。

要销量。 设定试运行周期和分阶段目标。达标后增加资源与供货支持，长期不达标则及时调整或退出。

控渠道。 约定销售范围、库存流向和客户归属，避免跨区域销售、未经授权的转售以及渠道之间相互抢单。

供货政策也不宜只靠一个固定折扣解决。更稳妥的方式，是让价格与销量承诺、服务责任、库存风险和回款条件挂钩。规模越明确、秩序越稳定，合作方能够获得的支持才越多。

机制的价值，不是把合作变得僵硬，而是把模糊的人情协作，转化为双方都能预期、衡量和复盘的经营关系。

结语

渠道不是一张平台名单，也不是越多越好。它是一套关于利润、用户旅程、价格秩序、合作边界和组织协同的系统。

在启动任何新渠道之前，不妨先问四个问题：

1. 它带来的究竟是不是增量？
2. 它能否形成足以覆盖组织成本的规模？
3. 合作双方是否都有可持续利润？
4. 它与现有渠道的价格、活动和客户边界是否清晰？

能够回答好这四个问题，渠道才不只是“多一个卖货的地方”，而会成为企业持续投入产品、服务用户和积累竞争力的利润系统。

说明：文中案例均经过匿名化和概括处理，具体组织、人员、销量及合作条件未予披露。

2026-07-30 21:30:00

过去，我们使用 AI，主要是在对话框里问问题。现在，AI Agent 开始读取邮件、管理日历、查询 Notion、处理 GitHub Issue，甚至操作企业内部系统。

这时，一个绕不开的问题出现了：怎样把外部账号交给 Agent，又不把账号的钥匙直接交给大模型？

最简单的做法，是把 API Key、OAuth Token 或邮箱授权信息写进 Agent 的配置文件。但这等于把所有钥匙放进同一个抽屉。一旦配置文件被读取、日志意外记录了 Token，或者 Agent 遭遇提示词注入，风险就可能从“回答错了”升级为“真的操作了你的账号”。

OpenConnector 想解决的，就是这层连接与授权问题。

OpenConnector 是什么？

OpenConnector 是一个面向 AI Agent 的开源 Connector Gateway，也可以理解为一个位于 Agent 和外部应用之间的统一连接网关。

它目前提供包含 近 1,000 个 Provider、10,000 多个预置 Action 的共享目录，覆盖 Gmail、GitHub、Notion、Slack、Google Calendar、Google Drive、Airtable、Supabase 等常见服务。

用户只需要连接一次账号，之后 OpenClaw、其他支持 MCP 的 Agent，或者普通应用程序，都可以通过统一接口发现和调用这些能力。

它的基本结构可以概括为：

1
2
3
4
5
6
7
8
9

OpenClaw / AI Agent
        │
        │  MCP、SDK、HTTP
        ▼
   OpenConnector
        ├── 凭据与 OAuth 边界
        ├── Action 与权限策略
        ├── 脱敏日志
        └── Gmail、GitHub、Notion 等外部服务

真正的 OAuth Token、API Key 和自定义凭据保留在 OpenConnector 的运行环境里。Agent 通常只能看到：

• 已连接账号的安全标签；
• 可调用的 Action；
• Action 的输入与输出 Schema；
• 所需 Scope 和权限；
• 本次调用的执行结果。

也就是说，Agent 获得的是“调用某项能力的权限”，而不是外部账号的原始钥匙。

它解决了传统 Agent 接入的三个麻烦

一、避免把原始凭据直接交给 Agent

如果直接把 GitHub PAT 或 Gmail OAuth Token 写入 OpenClaw 配置，Agent 进程往往具备读取这些信息的可能性。

使用 OpenConnector 后，OpenClaw 只需要持有一个受限的 Runtime Token。真正的 Provider 凭据由网关在执行 Action 时注入，原始 Token 不需要进入模型上下文。

这种设计不能消除所有安全风险，但至少缩小了凭据泄露的范围，也让权限可以独立撤销和轮换。

二、统一不同服务的授权与调用方式

不同 SaaS 的鉴权方式非常分散：

• 有些使用 API Key；
• 有些使用 OAuth2；
• 有些需要自定义凭据字段；
• 有些服务不需要鉴权；
• 不同 OAuth Provider 的 Scope 和刷新逻辑也不相同。

OpenConnector 把这些差异收敛到了同一套 Provider、Connection 和 Action 模型中。Agent 可以先搜索 Action、查看调用说明，再选择账号连接并执行。

从控制台可以看到，Google Sheets、Gmail、Slack、GitHub、Notion、Jira、Dropbox、Outlook 等服务都被放进了同一个连接目录。对于需要同时接入多个工作软件的 Agent，这种统一管理会比逐个维护 MCP Server 和 Token 清晰很多。

三、增加可观察性和策略控制

OpenConnector 不只是一个 Token 仓库，还提供了：

• Runtime Token；
• Action 允许和禁止策略；
• Provider Scope 展示；
• Connection Identity；
• 脱敏运行日志；
• 调用失败和趋势统计；
• 临时文件中转；
• OpenAPI 与 MCP Metadata。

这意味着，当 Agent 调用了某个外部服务时，管理员能够追踪它使用了哪个 Action、是否成功，以及近期是否出现异常调用。

为什么它特别适合 OpenClaw？

OpenClaw 的价值，在于让 Agent 从聊天走向真实行动。但能力越强，凭据越容易成为风险集中点。

OpenConnector 原生提供 MCP Endpoint：

1

http://localhost:3000/mcp

新版 OpenClaw 可以登记 Streamable HTTP MCP Server，因此可以直接把 OpenConnector 暴露的工具加载进 Agent。OpenConnector 的 MCP 主要提供以下发现与执行能力：

• list_apps
• list_connections
• search_actions
• get_action_guide
• execute_action

这种设计还有一个附带好处：OpenClaw 不必一次把成千上万个 Action 的完整 Schema 全部塞进上下文，而是先搜索，再按需读取 Action Guide，最后执行。

一个典型的 OpenClaw 配置可以写成：

1
2
3
4
5
6
7
8
9

openclaw mcp set openconnector '{
  "url": "http://openconnector:3000/mcp",
  "transport": "streamable-http",
  "headers": {
    "Authorization": "Bearer ${OPENCONNECTOR_RUNTIME_TOKEN}"
  }
}'

openclaw mcp doctor openconnector --probe

其中，Runtime Token 最好通过环境变量注入，而不是直接把明文写进配置文件。

四种使用路径

OpenConnector 提供了几种不同的部署选择。

这里有一个很现实的取舍：

• 自托管能更好地掌控凭据，但需要自己申请和配置各个平台的 OAuth App；
• OOMOL 托管更方便，但凭据会进入第三方托管的运行环境，企业使用前需要完成供应商和合规评估。

几分钟跑起来

项目已经提供预构建 Docker 镜像。最简单的启动方式是：

1

docker compose up

然后打开：

1
2

http://localhost:3000
http://localhost:3000/docs

也可以先调用一个不需要鉴权的 Hacker News Action，确认 Runtime 工作正常：

1
2
3
4

curl -s -X POST \
  http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

如果要连接 GitHub，可以使用 Personal Access Token；如果要连接 Gmail 等 OAuth Provider，则需要在自托管环境中配置自己申请的 OAuth Client。

需要特别注意：它不是“绝对安全保险箱”

OpenConnector 的宣传重点是“Agent 看不到原始凭据”，这个方向是成立的，但不能把它理解成：只要部署了 OpenConnector，Agent 就不会做出危险操作。

至少还要注意三点。

Runtime Token 本身也是一种能力凭证

如果一个 Runtime Token 可以执行“发送邮件”“删除文件”“修改仓库权限”等 Action，那么拿到这个 Token 的人虽然看不到 Gmail 或 GitHub 的原始凭据，仍然可以通过网关完成这些操作。

因此，关键不是只隐藏 Token，而是给 Runtime Token 配置尽可能小的 Action 白名单。

它不能自动消除提示词注入

恶意邮件或网页仍可能诱导 Agent 调用合法工具完成危险动作。OpenConnector 负责鉴权和执行边界，不负责判断 Agent 的意图一定正确。

发送、删除、转账、发布和权限修改等高风险操作，仍应增加人工确认。

同一主机、同一用户不等于真正隔离

如果 OpenClaw 可以读取 OpenConnector 的环境变量、SQLite 数据库、加密密钥或管理接口，那么凭据边界仍可能被绕过。

更稳妥的做法是：

• 使用独立容器、系统用户或虚拟机；
• 不向 OpenClaw 挂载 OpenConnector 的数据卷；
• 设置独立的管理 Token 和 Runtime Token；
• 开启凭据加密；
• 禁止不需要的 Provider Proxy；
• 固定正式版本，不在生产环境直接跟随 latest。

谁最值得尝试？

OpenConnector 比较适合以下用户：

• 使用 OpenClaw，并希望同时接入 Gmail、GitHub、Notion、Slack 等多个服务；
• 正在开发需要用户授权第三方账号的 Agent 产品；
• 希望统一管理 OAuth、API Key、Scope、Action Policy 和运行日志；
• 希望先使用托管 Connector 快速验证，再逐步迁移到自托管环境。

如果只需要连接一个服务，直接使用该服务的官方 MCP Server，通常更简单，攻击面也更小。

但当接入对象逐渐增加，OpenConnector 的价值会越来越明显：它把“每个 Agent 各自保存一堆 Token”，变成了“一套独立、可审查、可限制的连接基础设施”。

结语

AI Agent 的能力上限，很大程度上取决于它能连接多少真实工具；而 Agent 能否被放心使用，又取决于这些连接是否可控。

OpenConnector 给出的思路很清晰：

Connect Once. Use Everywhere.

连接一次，统一复用；凭据留在网关内，Agent 只获得完成任务所需的能力。

它仍是一个快速发展的年轻项目，不能代替最小权限、沙箱隔离和人工审批。但对于 OpenClaw 这类需要频繁调用外部服务的 Agent，OpenConnector 已经提供了一条比“直接把所有 Token 塞给 Agent”更合理的路径。

参考资料

• OpenConnector 项目主页
• OpenConnector 中文 README
• Runtime API 与 MCP
• 凭据与本地存储
• 配置与权限策略
• OpenClaw MCP 文档

本文界面图片来自 OpenConnector 官方 GitHub 仓库，相关商标和产品名称归各自权利人所有。

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 重启就能用，账号、密钥、配置都能图形化管理。