早上好!以下为昨日摘要:
SOL - $76.64 PUMP - $0.0020 V2EX - $0.0019





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.16M | 4.82% | - | -0.13M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | -3.60K |
| #12 | Meteora (V2EX-PUMP) Market | 4.26M | 0.43% | - | +22.86K |
| #13 | hackerwgf | 3.67M | 0.37% | - | +2.67K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。

近期几个Frontier Models都很给力,实测下来几个Models都能承担日常任务。我目前持有的Subscription plans如下:
实际常用的Models及effort为:
基于上述额度,我的主观体感如下:
综上所述,基于我持有的Plans的来说,我目前的主观优先级是:
这三个都不错,我一般会三个同时跑不同的项目。Fable最好用于All in最重要的项目,因为单项目的卡点其实在人,所以消耗不会特别快,目前20x的weekly limit 50%足够。Codex 5.6 Sol Max基本万能而且很耐用,基本啥都能干,虽然不如5.5耐用但也比剩下两家好多了。Kimi K3智商不错但算力不行,要等官方未来升级。
如果说Codex 5.6的追及还在预期之中,那么Kimi K3的出现确实令人意外。这样看来,在Coding领域Anthropic一家独领风骚的时代就快过去了,希望早日看到百家争鸣的时代出现。

最近看了 Matt Pocock 的一段视频:
视频只有 15 分钟,讲的却不是某个新模型或提示词技巧,而是一个更基础的问题:让 AI 参与一个已有代码库时,怎样避免每次都从头解释业务名词和历史决定?
Matt 之前的 /grill-me 会持续追问,把模糊的想法问到可以执行。它并没有失效;问题在于,单靠一轮轮问答,已经确认过的概念不会自动成为项目的一部分。下一次会话里,人仍可能要解释“独立视频”到底指什么、某个对象之间是一对一还是一对多、这个状态能否随意切换。
他现在在编码场景中改用 /grill-with-docs。它保留追问,但把共同语言和不容易看懂的决策写进仓库。这样,聊天记录不再是唯一的上下文。
视频中的例子是一项新功能:在一个管理课程和视频的应用里加入 pitch。这里的 pitch 不是代码里的通用术语,而是视频的“包装”——标题、描述和对外呈现方式;团队会先想出多个 pitch,再选择其中一些制作成视频。
人一听就能根据上下文补全很多含义,AI 却没有这种默认背景。例如:
standalone video 是不属于课程或课时的视频,还是“尚未关联 pitch 的视频”?idle、scheduled、shipped 是强制流转的状态机,还是可以手动修改的标签?这些不是措辞洁癖。它们会影响数据库关系、删除规则、变量名、文件名、界面分组和后来的人怎样理解代码。若定义只存在于某次聊天里,之后每一次让 AI 修改相关部分,都会重新产生猜测空间。
context.md/grill-with-docs 借用了领域驱动设计(DDD)中的“通用语言”思路。它会先寻找 context.md,读取其中的术语和定义;在对话中发现概念不清、用词冲突或新规则时,再要求人确认并更新这份文件。
在视频里,context.md 至少承担三件事:
它不需要写成一份覆盖全部实现的百科全书。视频里的建议更接近 DDD 的 bounded context:一个大型 monorepo 可以有 context map 和多个上下文;如果一个仓库内大家说的是同一种业务语言,一份放在根目录的 context.md 就够用。
关键不在文件名,而在约束:产品、代码和与 AI 的对话尽量用同一个词。否则,文档里叫“已投递视频”,数据库表叫 standalone_videos,界面又叫“提案视频”,AI 很难判断它们到底是不是同一个东西。

共同语言需要在每次新需求中核对和更新;它不是一次写完就不再变化的说明书。
/grill-with-docs 不会读完文档就直接生成代码。它会先把新需求同既有术语表对照,指出含义不清或冲突的地方,并通过具体场景把问题问出来。
视频的演示依次确认了:
这些回答随后写回 context.md。作者也展示了一个很现实的细节:写入后产生了 pitched standalone video、unattached standalone video 之类别扭的名称。他没有假装第一版术语一定正确,而是提醒自己在“足够清楚”时停止讨论,后续需要时再重构。
这条边界很重要。共同语言的目的不是无限讨论命名,而是让接下来的实现少一点误解。
词汇表能定义“是什么”,却不总能解释“为什么”。视频把这类信息交给 ADR(Architecture Decision Record,架构决策记录)。
ADR 适合记录那些不看背景会觉得奇怪、又难以轻易撤回的选择:它面临过什么取舍、会带来什么后果。库选型这类容易替换的决定未必值得专门写 ADR;删除策略、数据关系或会影响多个模块的业务定义,通常更值得留下理由。
这也避免 AI 看到一个非直觉的实现时,自作主张把它“优化”掉。它能先读到决策背景,再判断当前需求是否真的要求改变它。

context.md 保存“是什么”,ADR 保存“为什么这样选”。
Matt 的观察是:定义稳定后,AI 不必反复解释同一个概念,回复会更简洁;代码中的命名和规划文档也会更容易互相检索。这是他在工作流中的经验,而不是对所有模型和项目都成立的性能测试结果。
确认过的业务含义不必停在对话记录里。把它记录到仓库后,下一位开发者、下一次会话和后续生成的代码,都从同一份上下文开始。
从视频可以整理出一套小而可用的做法:
这里的重点不是复制某个斜杠命令。即使不用这两个 skill,团队也可以建立同样的习惯:把 AI 提出的关键歧义当作待确认的产品或技术问题;确认后更新共享文档,而不是只在聊天窗口里回答一次。
/grill-me 并没有被淘汰视频最后给出了一条很清楚的使用边界:有代码库时,优先用 /grill-with-docs;没有代码库的开放式任务,则继续用 /grill-me。作者还举了非工程场景的例子:有人用后者整理为母亲写悼词时的回忆,价值就在于耐心追问,而不是建立术语表。
项目刚开始时,作者仍倾向 /grill-with-docs,因为这恰好是最需要建立共同语言的阶段。差别不在于有没有足够多的代码,而在于这次对话是否要留下能被后续工作复用的领域知识。
让 AI 写代码之前,把项目里的词说清楚,看起来比直接输入需求慢一点。但当这些词会进入表名、组件名、接口和用户界面时,早一点确认往往比之后在许多文件里改名更便宜。
来源:
。本文基于该视频的英文字幕和演示整理;其中的实施步骤为对视频方法的归纳,不代表作者提供的性能保证或通用工程结论。
两个账号应各自使用独立的本地状态目录;它们可以同时工作,但不共享认证和会话。
一个人同时有个人和工作两个 OpenAI 账号时,最容易踩的坑不是登录,而是登录之后。默认情况下,Codex CLI 把认证、配置、会话和本地状态都放在同一个目录。后一次登录会让下一次启动的 CLI 使用新的身份;MCP、插件和会话历史也混在一起。
我在 macOS 上用 codex-cli 0.145.0 核对过这个行为。Codex 的配置源码把 CODEX_HOME 定义为全部本地状态的根目录:默认是 ~/.codex,设置后会改用指定目录。源码中的说明 也说明日志和 SQLite 状态会随这个目录变化。
这意味着可以把“个人”和“工作”当成两套独立的 CLI 环境,而不是在同一套配置里反复登录、退出。
先把边界说清楚。Codex CLI 还没有类似 --account work 的正式账号选择器;官方仓库中相应的功能请求仍是开放状态。该请求 本身也把现状描述为:默认只有一个本地状态目录,多账号只能换目录、换认证文件或重新登录。
所以 CODEX_HOME 的作用不是把两个账号放进一个账号列表里。它做的是把两套状态彻底分开:
这比手动替换 ~/.codex/auth.json 稳妥得多,也更容易查清一条会话究竟用了哪个身份。
下面示例用两个目录保存状态。目录名只表示用途,不会把账号名称传给 OpenAI:
mkdir -p "$HOME/.codex-profiles/personal" "$HOME/.codex-profiles/work"
# 首次使用个人环境时登录个人账号
CODEX_HOME="$HOME/.codex-profiles/personal" codex login
# 首次使用工作环境时登录工作账号
CODEX_HOME="$HOME/.codex-profiles/work" codex login
以后从相同的入口启动即可:
# 个人环境
CODEX_HOME="$HOME/.codex-profiles/personal" codex
# 工作环境
CODEX_HOME="$HOME/.codex-profiles/work" codex
登录完成后,分别检查状态:
CODEX_HOME="$HOME/.codex-profiles/personal" codex login status
CODEX_HOME="$HOME/.codex-profiles/work" codex login status
如果日常经常在两个环境间切换,可以给终端写两个别名或两个很短的启动脚本。关键不是别名的名字,而是每个入口固定指向一个目录。涉及外部操作,例如创建 PR、发消息或使用带权限的 MCP 工具时,先看当前终端来自哪个入口。
auth.json看上去最快的做法,是先在默认目录登录一次,再把 auth.json 复制到另一个目录。这个方法不可靠。

复制的认证文件可能在另一个副本刷新 refresh token 后失效;两个目录应分别登录。
Codex 使用的 OAuth refresh token 可能是一次性的:当一个副本刷新 token 后,另一个副本里的旧 token 会失效。官方仓库已有复现说明:复制认证文件后,第一次可能还能使用缓存的 access token,之后可能出现 401。问题 #15410 还明确指出,用软链接或复制文件来共享 ChatGPT 订阅认证都不是稳定方案。
每个目录各自执行一次 codex login。不要从另一套环境复制认证文件,也不要把认证文件纳入 Git、网盘同步或备份脚本。
账号隔离不是只多两个 auth.json。新目录一开始没有你原来配置过的 MCP server、插件、Skills、偏好设置或历史会话。这既是代价,也是这个办法有用的原因。
我通常会把配置分成两类:
这样做的好处是,工作账号不会意外加载个人的高权限工具,个人会话也不会写进公司的历史记录。代价是第一次使用时要分别安装或配置真正需要的工具。
要注意,本文只讨论从终端启动的 Codex CLI。桌面端、IDE 扩展和其他 GUI 进程未必会继承终端环境变量;不能因为 CLI 被隔离,就假定它们也已经切换到同一账号。它们应单独核对登录状态和凭据位置。
这个办法适合把合法且明确授权的身份分开,例如个人订阅与公司账号、两个客户提供的独立账号,或需要避免配置互相污染的测试环境。
它不应用于自动探测额度、在账号受限后自动切到下一个账号,或把多个账号的额度当作一份可轮换的资源。OpenAI 的服务条款禁止规避速率限制、使用限制和保护措施;个人账号也不应与他人共享凭据。OpenAI Terms of Use
如果目标只是让日常开发时的个人、工作上下文互不干扰,两个目录、两次独立登录和两个固定启动入口已经够用。它没有魔法,也不会扩大任何一个账号的权限或额度;它只是把本来会混在一起的本地状态分开保存。
来源与核验范围:本文基于 codex-cli 0.145.0 在 macOS 上的本地检查,以及 OpenAI 公开的 Codex 配置源码、多账号需求讨论、认证文件复制问题 和 服务条款。Codex 的行为和条款可能更新;实际配置前请以本机 codex --help 与当前条款为准。
早上好!以下为昨日摘要:
SOL - $74.47 PUMP - $0.0018 V2EX - $0.0018





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.29M | 4.83% | - | +0.30M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | -1 | +3.96K |
| #12 | Meteora (V2EX-PUMP) Market | 4.24M | 0.42% | -1 | -7.17K |
| #13 | hackerwgf | 3.66M | 0.37% | -1 | +2.68K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $73.88 PUMP - $0.0018 V2EX - $0.0018





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.01M | 4.80% | - | +21.98K |
| #8 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | +1 | -0.037275 |
| #11 | Meteora (V2EX-PUMP) Market | 4.25M | 0.42% | +1 | +8.46K |
| #12 | hackerwgf | 3.66M | 0.37% | +1 | +5.26K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $75.85 PUMP - $0.0018 V2EX - $0.0019





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 47.99M | 4.80% | - | -67.21K |
| #12 | Meteora (V2EX-PUMP) Market | 4.24M | 0.42% | - | -3.10K |
| #13 | hackerwgf | 3.66M | 0.37% | - | +5.15K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
如果大家都在使用 AI Agent 写代码, 或许我想要的是一位眼高手低的人, 只有这样的人才能用好 AI Agent.
早上好!以下为昨日摘要:
SOL - $77.95 PUMP - $0.0019 V2EX - $0.0019





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.06M | 4.81% | - | -26.46K |
| #12 | Meteora (V2EX-PUMP) Market | 4.24M | 0.42% | - | -20.10K |
| #13 | hackerwgf | 3.65M | 0.37% | - | +5.15K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
2015 年,我做过一款很小的 iOS App,中文名叫「闪印」。它只解决一件事:把旅行、采购或工作清单整理好,预览,然后打印到纸上。
旧版用 Objective-C 和 Storyboard 开发,后来陆续支持了 iPad、iPhone Xs Max 和 iCloud。它没有复杂的账号系统,也不试图成为项目管理工具。清单建好,纸张打出来,任务就完成了。
十一年后,我重新打开这个项目,决定用 SwiftUI 把它重写一遍。新版项目叫 PrintableCheckList-SwiftUI,代码已经开源。
这次重写不是给旧界面换一层 SwiftUI。我要保留原来的用途,也要回答一个新问题:如果 AI 能帮人省掉大量录入工作,一份「可打印清单」今天应该怎么做?
PrintableCheckList 仍然可以完全手动使用。你可以创建多份清单,一次粘贴多行内容,编辑、删除或拖动排序,再生成带方框的打印预览,通过 iOS 系统打印控制器输出。
AI 是可选的快捷入口。比如输入:
生成一份带孩子去北海道旅行 7 天的冬季行李清单,需要考虑滑雪和儿童常用药。
App 会返回清单标题和项目。结果不会立刻写入数据,而是先进入编辑页;你可以改标题、删掉不需要的内容、补上个人物品,确认以后再保存。AI 也能给现有清单补充遗漏项,不必每次从头生成。
整个过程可以概括为:
输入主题
↓
按需联网搜索
↓
模型返回结构化 JSON
↓
去重、限长、清理序号
↓
用户检查和修改
↓
保存到本地 → 预览 → 打印
这里最重要的一步不是「生成」,而是生成后的确认。模型负责减少输入,用户仍然决定最后打印什么。
接入 AI 时,我很快遇到一个看似简单的问题:用户说「全球票房前十名」时,他要的是十部电影,不是「查询票房」「核对排名」之类的十个任务。
因此,内置提示词会区分两类内容:
模型必须返回固定的 JSON 结构。App 还会清理 Markdown 围栏、编号和重复内容,限制标题与项目长度。补充已有清单时,已经存在的项目也会被过滤掉。
这些处理不显眼,却决定了 AI 生成的内容能不能真正进入一个普通 App,而不是停留在聊天窗口里。
旅行行李清单通常不需要搜索,但「最新票房排行」「最近发布的产品」或「当前汇率」不同。只靠模型已有知识,很容易得到过期答案。
PrintableCheckList 提供三种搜索模式:
目前 GLM 通过 Web Search API 搜索,OpenAI 通过 Responses API 的 Web Search 搜索。搜索结果会先整理成一段带来源的材料,再交给清单生成器。结果页显示来源链接,但来源不会混进最终的清单项。
DeepSeek 和自定义 OpenAI 兼容服务仍可生成清单,只是不启用这条原生搜索路径。这样没有假设所有 /chat/completions 服务都支持同一种联网工具。
新版采用 BYOK(Bring Your Own Key)模式。用户可以选择 GLM、OpenAI、DeepSeek,或填写自己的 OpenAI 兼容服务地址和模型名称。
API Key 存在 iOS Keychain,访问级别为 WhenUnlockedThisDeviceOnly。普通配置存入 UserDefaults,但不会包含 Key。生成请求和必要的搜索请求由设备直接发给用户选择的服务商,不经过开发者服务器。
没有配置 AI 也不影响手工创建、编辑、预览和打印。我坚持保留这条边界。AI 应该缩短输入时间,不应该变成打开清单 App 的通行证。
每次编辑都会先保存到设备的 Application Support/PrintableCheckList/projects.json。没有网络时,清单的创建、修改和打印都能继续使用。
可选的 iCloud 路径使用 NSUbiquitousKeyValueStore,沿用旧版的 keyProjects。代码也保留了原来的 bundle identifier,并实现了 NSKeyedArchiver 迁移:旧 Objective-C 里的 Project 和 Item 会转换成新的 Codable Swift 模型;旧 ID 不是 UUID 时,则生成稳定的 UUID。
这部分比重新画界面麻烦得多,却是一次真正的 App 更新必须承担的责任。重写代码不应该等于让用户重新输入数据。
需要说明的是,未签名模拟器不能代替真实 iCloud 环境。仓库已经覆盖旧数据导入和同步逻辑测试,但签名真机上的 iCloud 端到端验证仍然是发布前检查项。
虽然新版加入了 AI,项目名称里的 Printable 没有变。
预览页使用 SwiftUI 显示标题、项目和空白方框;真正打印时,App 生成一段经过 HTML 转义的排版内容,再交给 UIPrintInteractionController。iPad 上还单独处理了打印弹窗的锚点,避免 popover 因缺少来源视图而崩溃。
测试中还会把默认中文旅行清单交给打印格式化器,确认它能排在一张 A4 纸内。相比「按钮能点」,这更接近 PrintableCheckList 真正要完成的事情。
新版最低支持 iOS 17,使用 SwiftUI 和 Swift Concurrency。工程文件由 XcodeGen 根据 project.yml 生成,.xcodeproj 不进入版本库。生成、构建、测试、模拟器运行和归档分别有独立脚本,日常开发不必手动维护 Xcode 工程里的文件引用。
截至 2026 年 7 月 22 日,我在 iPhone 16 Pro / iOS 18.5 模拟器上执行了完整测试:42 个测试用例中,41 个通过,1 个 Keychain 用例因为无签名模拟器缺少 entitlement 而按预期跳过。覆盖范围包括:
需要 macOS、Xcode、iOS 模拟器和 XcodeGen。克隆后运行:
git clone https://github.com/terryso/PrintableCheckList-SwiftUI.git
cd PrintableCheckList-SwiftUI
./Scripts/generate.sh
./Scripts/build.sh
执行完整测试:
./Scripts/test.sh
安装并启动模拟器版本:
./Scripts/run-simulator.sh
AI 配置不是运行项目的前提。你可以先把它当作一款普通的本地清单 App,之后再决定要不要填入自己的 API Key。
软件重写很容易让人只关注新框架、新界面和新功能。但回到 PrintableCheckList,真正不能丢的只有两件事:旧数据还在,清单还能顺利打印。
SwiftUI 让界面和状态管理简单了很多,AI 让创建清单更快,联网搜索让时效性内容有了核对来源。不过这些能力最后都服务于一个很朴素的动作:拿起一张纸,照着清单去做事。
早上好!以下为昨日摘要:
SOL - $78.08 PUMP - $0.0020 V2EX - $0.0019





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.08M | 4.81% | - | -51.97K |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +30.7662 |
| #12 | Meteora (V2EX-PUMP) Market | 4.26M | 0.43% | - | +2.3453 |
| #13 | hackerwgf | 3.65M | 0.36% | - | +5.17K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $77.83 PUMP - $0.0020 V2EX - $0.0019





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.13M | 4.81% | - | -0.79M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | -7.90K |
| #12 | Meteora (V2EX-PUMP) Market | 4.26M | 0.43% | - | -627.86 |
| #13 | hackerwgf | 3.64M | 0.36% | - | +13.11K |
| #14 | Livid | 3.60M | 0.36% | - | +10 |
| #17 | crocoBaby | 2.62M | 0.26% | +2 | +0.69M |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
如果你是 Swift 开发者,又想把自己 Mac 上的能力(本地文件、Shortcuts、Xcode 项目、Core Data 数据……)暴露给 Claude、ChatGPT 这类 AI 助手,那么 MCP Server 就是你要的东西。而目前主流的 MCP 教程几乎都是 Python 或 TypeScript,Swift 版本极少——这也让 “swift mcp server” 成为一个几乎无人竞争的关键词。
本文用一个能跑通的最小示例,带你从零构建一个 Swift MCP Server,并接入 Claude Desktop。
Model Context Protocol (MCP) 是 Anthropic 在 2024 年底提出的开放协议,用来标准化 “LLM 应用 ↔ 外部工具/数据源” 之间的通信。你可以把它理解成 “AI 应用的 USB-C”:
tools、resources、prompts协议本体是基于 JSON-RPC 2.0 的双向消息,通过两种传输承载:
| 传输 | 场景 | 特点 |
|---|---|---|
| stdio | 本地进程,Host 直接 spawn | 简单、零配置、无网络暴露 |
| Streamable HTTP / SSE | 远程或跨机器 | 需 Accept: application/json, text/event-stream |
对本地 Mac 工具来说,stdio 是默认选择。
多数教程默认 Python/Node,但用 Swift 有几个独特优势:
swift build -c release 产出一个静态二进制,Claude Desktop 直接 spawn,无 Python 环境依赖。Codable + enum 建模,工具 handler 天然并发安全。Package 里既能被 App target 用,也能被 MCP server target 用。一个最小可用的 Swift MCP Server 包含四层:
┌─────────────────────────────┐
│ Claude Desktop (Host) │
└──────────────┬──────────────┘
stdio │ JSON-RPC 2.0
┌──────────────▼──────────────┐
│ Transport (stdin/stdout) │ 按行读、按行写
├─────────────────────────────┤
│ JSON-RPC Dispatcher │ method → handler
├─────────────────────────────┤
│ MCP Protocol Layer │ initialize / tools/list / tools/call
├─────────────────────────────┤
│ Your Tools │ echo / read_notes / run_shortcut ...
└─────────────────────────────┘
新建一个 Swift Package:
mkdir SwiftMCPDemo && cd SwiftMCPDemo
swift package init --type executable
编辑 Package.swift(macOS 13+,用到 AsyncStream 与 Foundation 的 JSON 编解码):
// swift-tools-version:5.9
import PackageDescription
let package = Package(
name: "SwiftMCPDemo",
platforms: [.macOS(.v13)],
targets: [
.executableTarget(name: "SwiftMCPDemo", path: "Sources/SwiftMCPDemo")
]
)
MCP 的每条消息都是 JSON-RPC 2.0。用 Codable 把请求 / 响应 / 错误建模一次,后面所有 handler 都复用:
import Foundation
struct RPCRequest: Decodable {
let jsonrpc: String
let id: JSONValue? // 可能是 number / string / null(通知无 id)
let method: String
let params: JSONValue?
}
struct RPCResponse: Encodable {
let jsonrpc = "2.0"
let id: JSONValue?
var result: JSONValue?
var error: RPCError?
}
struct RPCError: Encodable {
let code: Int
let message: String
var data: JSONValue?
}
/// 一个能表达任意 JSON 的枚举,避免到处写 [String: Any]
enum JSONValue: Codable {
case null
case bool(Bool)
case int(Int)
case double(Double)
case string(String)
case array([JSONValue])
case object([String: JSONValue])
init(from decoder: Decoder) throws {
let c = try decoder.singleValueContainer()
if c.decodeNil() { self = .null; return }
if let v = try? c.decode(Bool.self) { self = .bool(v); return }
if let v = try? c.decode(Int.self) { self = .int(v); return }
if let v = try? c.decode(Double.self) { self = .double(v); return }
if let v = try? c.decode(String.self) { self = .string(v); return }
if let v = try? c.decode([JSONValue].self) { self = .array(v); return }
if let v = try? c.decode([String: JSONValue].self) { self = .object(v); return }
throw DecodingError.dataCorruptedError(in: c, debugDescription: "Unsupported JSON")
}
func encode(to encoder: Encoder) throws {
var c = encoder.singleValueContainer()
switch self {
case .null: try c.encodeNil()
case .bool(let v): try c.encode(v)
case .int(let v): try c.encode(v)
case .double(let v): try c.encode(v)
case .string(let v): try c.encode(v)
case .array(let v): try c.encode(v)
case .object(let v): try c.encode(v)
}
}
}
MCP over stdio 用 换行分隔的 JSON(每条消息一行)。关键点:
actor StdioTransport {
private let stdin = FileHandle.standardInput
private let stdout = FileHandle.standardOutput
func readLines() -> AsyncStream<Data> {
AsyncStream { continuation in
Task.detached {
var buffer = Data()
while let chunk = try? self.stdin.read(upToCount: 4096), !chunk.isEmpty {
buffer.append(chunk)
while let nl = buffer.firstIndex(of: 0x0A) {
let line = buffer.subdata(in: 0..<nl)
buffer.removeSubrange(0...nl)
if !line.isEmpty { continuation.yield(line) }
}
}
continuation.finish()
}
}
}
func send(_ response: RPCResponse) throws {
var data = try JSONEncoder().encode(response)
data.append(0x0A) // '\n'
try stdout.write(contentsOf: data)
}
}
func log(_ msg: String) {
FileHandle.standardError.write(Data("[mcp] \(msg)\n".utf8))
}
定义一个 Tool 协议,让每个工具自描述 schema 并处理调用:
protocol Tool: Sendable {
var name: String { get }
var description: String { get }
var inputSchema: JSONValue { get } // JSON Schema
func call(arguments: JSONValue) async throws -> JSONValue
}
struct EchoTool: Tool {
let name = "echo"
let description = "Echo the input text back to the caller."
let inputSchema: JSONValue = .object([
"type": .string("object"),
"properties": .object([
"text": .object([
"type": .string("string"),
"description": .string("Text to echo back.")
])
]),
"required": .array([.string("text")])
])
func call(arguments: JSONValue) async throws -> JSONValue {
guard case .object(let obj) = arguments,
case .string(let text) = obj["text"] ?? .null else {
throw NSError(domain: "echo", code: 1,
userInfo: [NSLocalizedDescriptionKey: "missing `text`"])
}
// MCP tool 返回的是 content 数组
return .object([
"content": .array([
.object([
"type": .string("text"),
"text": .string(text)
])
])
])
}
}
MCP 一次会话至少要处理三个方法:initialize、tools/list、tools/call。
final class Server {
let transport = StdioTransport()
var tools: [String: any Tool] = [:]
func register(_ tool: any Tool) { tools[tool.name] = tool }
func run() async {
for await line in await transport.readLines() {
await handleLine(line)
}
}
private func handleLine(_ data: Data) async {
guard let req = try? JSONDecoder().decode(RPCRequest.self, from: data) else {
log("bad json: \(String(data: data, encoding: .utf8) ?? "?")")
return
}
var resp = RPCResponse(id: req.id)
do {
switch req.method {
case "initialize":
resp.result = .object([
"protocolVersion": .string("2025-06-18"),
"capabilities": .object([
"tools": .object([:])
]),
"serverInfo": .object([
"name": .string("swift-mcp-demo"),
"version": .string("0.1.0")
])
])
case "tools/list":
let list = tools.values.map { t in
JSONValue.object([
"name": .string(t.name),
"description": .string(t.description),
"inputSchema": t.inputSchema
])
}
resp.result = .object(["tools": .array(list)])
case "tools/call":
guard case .object(let p) = req.params ?? .null,
case .string(let name) = p["name"] ?? .null,
let tool = tools[name] else {
throw NSError(domain: "mcp", code: -32601,
userInfo: [NSLocalizedDescriptionKey: "tool not found"])
}
let args = p["arguments"] ?? .object([:])
resp.result = try await tool.call(arguments: args)
case "notifications/initialized":
return // 通知无需回复
default:
resp.error = RPCError(code: -32601, message: "method not found: \(req.method)")
}
} catch {
resp.error = RPCError(code: -32000, message: "\(error)")
}
if req.id != nil {
try? await transport.send(resp)
}
}
}
main.swift 里把它跑起来:
@main
struct App {
static func main() async {
let server = Server()
server.register(EchoTool())
log("swift-mcp-demo starting on stdio")
await server.run()
}
}
编译:
swift build -c release
# 产物路径
echo "$(pwd)/.build/release/SwiftMCPDemo"
编辑 ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"swift-demo": {
"command": "/绝对路径/SwiftMCPDemo/.build/release/SwiftMCPDemo"
}
}
}
重启 Claude Desktop。在对话框输入框左下角的 🔌 图标里应能看到 echo 工具。让 Claude 调用:
用 echo 工具回显 “Hello from Swift MCP”。
如果一切正常,Claude 会把返回内容展示回来。
print 都会破坏 JSON-RPC 帧。所有日志一律走 stderr。notifications/initialized**:Host 发来的通知没有 id,如果你也回一个响应会让客户端报协议错。判断 req.id != nil 再发送。inputSchema 里声明的 required 字段必须真的能从 arguments 里拿到,否则 Host 会跳过工具或报错。Accept: application/json, text/event-stream,否则官方 SDK 直接 406。stdio 走不通再考虑升级到 HTTP。Q:Swift MCP Server 能跨平台跑吗?
可以。核心代码只依赖 Foundation,Linux 上的 Swift 5.9+ 也能编译;要触达 macOS 专属 API(EventKit 等)时才会被平台绑定。
Q:需不需要自己实现 JSON-RPC,社区有没有现成库?
有官方 Swift SDK(modelcontextprotocol/swift-sdk)。生产项目直接用它;本文手写是为了把协议讲透。
Q:MCP Server 支持流式返回吗?
支持。工具可以在长任务里通过 notifications/progress 推进度,但要小心:客户端普遍有 30~60 秒左右的调用超时,超长任务应拆成 “创建 job → 查询结果” 两个工具。
Q:怎样调试?
最简单的办法:用 mcp-inspector(npx @modelcontextprotocol/inspector /path/to/SwiftMCPDemo)在浏览器里逐条查看请求与响应。
Q:MCP 会不会被 CLI 工具替代? 围绕 CLI vs MCP 有过一场讨论,但对于强类型、需要 schema 的 macOS 原生能力,MCP 仍然是最合适的封装。
Swift + MCP 是被严重低估的组合:一份 Swift Package 就能把 macOS 原生能力干净地暴露给任何符合 MCP 的 AI 客户端,无 Python、无网络、类型安全。这篇教程的完整代码可以直接复制运行;下一步建议:
EchoTool 换成 RunShortcutTool,用 Process 调 shortcuts run;read_notes 工具走 AppleScript / EventKit;.pkg 或 Homebrew tap,让别人一键装。如果你在做类似方向的实验,欢迎订阅本站 RSS 或看看姊妹项目 Open Agent SDK (Swift),那边把 “Agent Loop + MCP 集成” 完整跑通了。
这周有几件事放在一起看,会比单独看更有意思。
mcp-inspector 1.0.0 进了 formula,这是 MCP 官方的调试工具。 Logseq 在去年圣诞夜另起了一个叫
og的仓库,本周 1.0 进了 Cask。 arcbox 在官网的产品描述里,把"给 AI agent 跑的隔离沙箱"当做头号卖点。 三件事,三种方式,都在回答同一个问题:这个生态正在往哪里分。
工具在打标签——哪些是给 agent 的,哪些是留在本地文件的,哪些是"调试用的"。
| 名称 | 中文说明 |
|---|---|
| qobine-tui | Qobuz 流媒体的终端播放器 |
| qobine-web | Qobuz 流媒体的 Web 界面播放器 |
| utiluti | macOS 命令行工具,管理默认应用关联 |
| ovh-ttyrec | OVH 改进版 ttyrec,终端会话录制工具 |
| 名称 | 中文说明 |
|---|---|
| perplexity | Perplexity AI 桌面客户端,含 Personal Computer agent |
| step-agent | Smallstep 的证书管理 agent |
| arcbox | 容器、Linux VM 和 AI agent 沙箱的运行时(Apple Silicon 专属) |
| vorssaint | 本地优先的 AI 写作助手 |
| logseq-og | Logseq OG — Logseq 的本地文件版本,独立维护 |
| siliconscope | Apple Silicon 系统监控,含 ANE、Media Engine 和带宽追踪 |
| juicy | 菜单栏电池监控,支持自定义充电告警和健康追踪 |
| willow-voice | AI 语音听写和写作助手 |
| markdown-preview | Markdown 文件预览工具 |
上周写 smithery-cli 和 toolhive-studio 同时进 Homebrew,说的是"MCP server 的安装体验被认真对待了"。这周 mcp-inspector 到 1.0,是这条线的下一段。
mcp-inspector 是 MCP 协议官方出的调试工具——一个 React Web UI + Node.js 代理的组合,你本地起一个 MCP server,用它来连、测、看请求响应、检查 tool 列表、验证 prompt 模板。10k+ stars,是 MCP 生态里目前最被引用的开发工具之一。
到 1.0 这件事值得记的不是功能变化(版本 notes 就四个字"OG rocks!"),而是时间点。三周内,homebrew 里先进了安装器(smithery-cli)、管理器(toolhive-studio)、agent 专用终端(otty),现在是官方调试工具的 1.0。MCP 的开发者工具链,正在按顺序补齐。
写第一个 MCP server 的人,以前得自己 console.log 调试。现在有了一个带界面的工具。
Logseq 的主线在走向数据库模式——把笔记从 Markdown 文件迁移到结构化数据库,支持更复杂的查询和同步。这件事不是秘密,但也不是所有人都愿意跟。
2025 年 12 月 25 日,logseq/og 这个仓库出现了。仓库名叫 og,描述是"Logseq og (file version)"——"og"通常是"original"的缩写。简单说:这是 Logseq 官方维护的、坚持基于本地 Markdown 文件的那条线,和主线数据库版本分开走。
本周,logseq-og 1.0.0 进了 Homebrew Cask。
这件事让我想的不是该装哪个版本。我想的是:一个产品同时维护"现代化路线"和"给不想跟的人留的入口",这是一种什么状态? Vim 和 Neovim、Python 2 和 Python 3、现在是 logseq 和 logseq-og。每次这种分叉出现,都意味着原来那条路积累了足够多不愿意走新路的人。
1.0 进 Homebrew,说明这条线有人认真对待,不是放着慢慢死的。
arcbox 是 Docker Desktop 的 Apple Silicon 替代品——容器、Firecracker 微虚拟机、完全开源,macOS 15+ 专属。光是这几点,放两年前就可以写一节了。
但它的产品页头号卖点不是"比 Docker Desktop 快",是:**"AI agents are powerful — and unpredictable. ArcBox Desktop runs your local agents in fully isolated Firecracker microVMs."**
这是第一次我在一个容器工具的官方文档里,看到"AI agent 是危险的,所以我们给它造了一个笼子"被写成产品核心功能。不是"支持运行 AI 应用",是"我们假设你跑的 agent 会做不可预测的事,所以每个 agent session 有独立 microVM,你能看到它的每一个 syscall、网络请求和文件写入"。
这个叙事变化比工具本身有意思。**agent 沙箱从"偏执用户的自选配置"变成了"负责任的工具该有的默认设计"**,这个转变正在发生。
# 查询当前默认浏览器
utiluti get browser
# 设置默认 PDF 阅读器
utiluti set com.apple.Preview pdf
# 列出某种文件类型的所有可用应用
utiluti list html
这个问题比看起来麻烦:macOS 的"默认应用"管理散在 LaunchServices 框架里,没有官方 CLI,要改就要去 System Settings 点,或者写十几行 Swift 调用私有 API。
utiluti 是 scriptingosx(macOS 脚本圈的老人,写过《Shell Scripting with Zsh》)写的。它把这件事包了一层,给出了可以在终端里用的命令。用途不花哨,就是**"我想在脚本里切换默认浏览器"这个具体需求,现在有工具了**。
perplexity 的 cask 描述写的是"AI-powered answer engine with Personal Computer agent"——Perplexity 把 PC agent 功能放进桌面客户端,这件事今年发生,但进 Homebrew 比我想象的要快。它的 formula 名字叫 perplexity,没有加 ai 后缀,这种命名置信度很高,代表他们认为产品本身就是品牌。
willow-voice 是这周第四个或第五个进 Homebrew 的本地语音工具(上两期有 muesli、macparakeet、subtitle-studio)。每周都有,但它们不一样:muesli 做的是"会议记录",subtitle-studio 做的是"视频字幕",willow-voice 做的是"写作时的语音输入"。本地语音这个品类在分化,不是在重复——每个工具找到了不同的"这段声音不该上传"的具体场景。
siliconscope 监控 ANE(Apple Neural Engine)使用率,这个指标我以前看不到。以前 Activity Monitor 里没有 ANE。现在有了工具,才发现自己不知道那块芯片在什么时候、被谁用。
btcli(Bittensor CLI)这周被标记 deprecated——理由是"repo archived"。Bittensor 11.0.0 这周也进了,但 CLI 工具就这么退场了。
mcp-inspector 到 1.0 的同一周,logseq 在自己家里给"不想跟"的人留了一扇门,arcbox 在卖 AI agent 的笼子。这三件事不是同一件事,但它们都在说:某些方向已经走远了,走得够远才需要有人站出来说"我不走那条路"或者"走那条路要装防护"。
不是浪潮,是分叉出现了。
早上好!以下为昨日摘要:
SOL - $76.36 PUMP - $0.0020 V2EX - $0.0018
| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.92M | 4.89% | - | -14.81K |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +11.1535 |
| #12 | Meteora (V2EX-PUMP) Market | 4.26M | 0.43% | - | +68.78K |
| #14 | Livid | 3.60M | 0.36% | - | +2.91K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $75.48 PUMP - $0.0017 V2EX - $0.0018
| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.94M | 4.89% | - | +40.07K |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +19.478 |
| #12 | Meteora (V2EX-PUMP) Market | 4.20M | 0.42% | - | -14.71K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $74.99 PUMP - $0.0016 V2EX - $0.0018
| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.90M | 4.89% | - | +1.65K |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +41.5064 |
| #12 | Meteora (V2EX-PUMP) Market | 4.21M | 0.42% | - | -22.07K |
| #14 | Livid | 3.60M | 0.36% | - | +3.31K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $75.26 PUMP - $0.0017 V2EX - $0.0018





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.90M | 4.89% | - | -0.18M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +16.5914 |
| #12 | Meteora (V2EX-PUMP) Market | 4.23M | 0.42% | - | +0.12M |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $77.23 PUMP - $0.0017 V2EX - $0.0018





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 49.07M | 4.91% | - | -0.24M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +3.1125 |
| #12 | Meteora (V2EX-PUMP) Market | 4.11M | 0.41% | - | +75.92K |
| #50 | JoeJoeJoe | 0.70M | 0.07% | - | +20 |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $77.80 PUMP - $0.0015 V2EX - $0.0018





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 49.31M | 4.93% | - | +69.55K |
| #7 | ares001 | 5.83M | 0.58% | - | -10.00K |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +32.1086 |
| #12 | Meteora (V2EX-PUMP) Market | 4.04M | 0.40% | - | -7.52K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
