DEV Community: 冯智勇Geo

更好的技术标准为什么未必赢

冯智勇Geo — Thu, 06 Aug 2026 10:22:35 +0000

核心结论: 技术标准竞争的胜负主要取决于迁移成本和生态协调，而不是方案本身是否最优。

我最近问 AI：Pi 的 Skill 文件是 Markdown，为什么开头的元信息用 YAML，而不是 JSON？

按我的直觉，既然主要是机器读取，JSON 的规则更明确，似乎更合适。

AI 一开始说，因为 YAML 更方便人读，还支持注释和多行文本。这个解释没错，但没有说到我的疑惑点上。写 Skill 的人仍然需要阅读和修改 YAML，可这不足以解释：为什么大家一直不换？

更实际的答案是，整个工具链早已习惯了 YAML。

Jekyll 的 frontmatter 按 YAML 解析；Hugo 则明确支持 YAML、JSON 和 TOML。格式已经成为工具实现、编辑器、模板和文档的一部分，真正困难的是让整个生态一起改变习惯。

所以我真正该问的不是“哪个格式更好”，而是：“这点好处，值不值得所有人一起折腾？”

一种技术标准在局部更好，不代表它会流行。前者只是在比较功能，后者还要计算更换成本。

AI 也可能让旧标准活得更久

更有意思的是，AI 不一定会推动大家换成更好的方案。

当 AI 能自动补全、转换和纠错时，旧标准原本让人难受的地方被遮住了。用户既然感觉不到麻烦，也就没有动力更换。

AI 像是在给旧标准发“兼容性补贴”：它没有解决旧标准的问题，只是替用户承担了麻烦。结果可能不是新方案更快胜出，而是旧方案活得更久。

以后再做技术选型，我会先问：大家现在用什么？更换需要谁配合？新方案带来的好处，真的值得所有人一起折腾吗？

这些问题，可能往往比“谁更先进”更重要。

参考

Pi Skills 官方文档：https://pi.dev/docs/latest/skills
YAML 1.2.2 规范：https://yaml.org/spec/1.2.2/
Jekyll Front Matter：https://jekyllrb.com/docs/front-matter/
Hugo Front Matter：https://gohugo.io/content-management/front-matter/

把思维导图接进 Agent 输入框

冯智勇Geo — Wed, 05 Aug 2026 05:43:24 +0000

核心结论: 将思维导图变成 Agent 的外部编辑器，可以形成“快捷键唤起—结构化编辑—直接发送”的完整输入链路。

为了结构化表达，我做了一个 Agent 外部编辑器。

这个想法来自我使用 OpenMarkdown 时，通过 ctrl+g 切入外部编辑的体验：写到一半时按下快捷键，进入更适合编辑的环境，完成后再回到原来的输入框。我想把类似的体验放进 Agent，让用户不必一直挤在单行或多行输入框里组织复杂问题。

为什么是思维导图

我选择的不是普通文本编辑器，而是树状思维导图。

核心原因有：

编辑层面：对我来说，拖拽节点比在文档里重新调整层级更高效。
思考层面：我能同时看到内容的整体结构，更容易发现缺失或错位的分支。
内容层面：树状结构迫使我在发送前明确哪些是前提、补充和从属关系，而不是把这些关系留给 AI 猜。

如果内容本身的逻辑基本正常，那么经过思维导图整理后，发送给 AI 的文本也会天然带有结构。结构不是提交之后由 AI 猜出来的，而是在输入阶段就已经形成。

我打通了什么

目前，我在 AI 编程助手 pi 中安装了一个 mindmap-edit 扩展，并把入口绑定到 ctrl+g。

按下快捷键后，扩展会读取当前输入框中的文字，写入临时的 prompt.md，再调用 pmind-browser，用 Chrome 打开基于 MindElixir 的思维导图编辑器。

用户可以在导图里拆分、移动和重新组织内容。点击提交后，只要内容不为空，它就会通过 pi.sendUserMessage 自动作为用户消息发送，并清空原输入框；如果取消，输入框仍然保留原来的内容。

至此，一条完整链路已经跑通：

ctrl+g 唤起 → 外部编辑 → 思维导图整理 → 点击提交 → 直接发送给 Agent。

它解决不了什么

思维导图能让表达形式结构化，但结构化的格式不等于有逻辑的内容。

如果输入本来就是一团没有逻辑的想法，工具最多提供拖拽和分层，不能替用户完成判断。它可以约束表达、提示用户整理，却不能凭空补上因果关系和清晰观点。

当前实现还不够顺滑。从输入框切到浏览器再切回来，会带来摩擦和割裂感。这也让我更确定：真正需要优化的，不是思维导图的编辑能力，而是它进入 Agent 输入框的方式。

最终要消失在输入框里

我理想中的形态，是按下 ctrl+g 后，一个类似 uTools 的悬浮窗口直接出现在当前输入框之上。用户在里面用思维导图编辑，点击一次就提交并发送，AI 随即回答整理后的内容。

外部编辑器虽然叫“外部”，体验上却不应该让人感觉离开了对话。真正值得保留的不是思维导图这个形式，而是它所形成的输入链路：在发送之前给复杂想法一次整理结构的机会，然后无缝交给 Agent。

这个项目还在继续优化。如果后续把交互和稳定性打磨到可以公开使用的程度，我会整理代码和使用说明，并发布到 GitHub。

GEO 原文需要放在开放网络

冯智勇Geo — Tue, 04 Aug 2026 12:08:43 +0000

核心结论: 国内内容平台可以承载 GEO 文章的删减分发版，但需要保留完整引用关系的 GEO 原文，应该放在开放网络（如自建网站）上。

这段时间里，我把个人网站的文章分发到国内内容平台时，都有一个固定动作：删掉文末的参考链接。

这个动作让我不舒服。我做的是面向 AI 发现、理解和引用而优化的 GEO 内容，但为了让内容顺利上线，却要先删掉便于信源核验的部分。

一开始我只当它是分发时的小麻烦。直到后来把个人网站原文和平台版本放在一起看，我才意识到这暴露了一个更深层的矛盾：内容平台希望链接留在站内，GEO 原文却需要保留通往原始证据的路径。

参考链接不是装饰

GEO（生成式引擎优化）的目标，是让内容能被 AI 发现、理解和引用。参考链接不能保证一篇文章一定会被引用，但它提供了最直接的核验路径：这个数据来自哪里，这个说法由谁发布，原文究竟说了什么。

这条路径同时服务读者和需要检索公开信息的 AI。参考链接不只是文末的一行 URL，而是文章证据链的一部分。

三组文章，七条来源

我找了三组已经发布的文章对照。

第一篇讲 Agent Commerce。个人网站原文有 3 条官方来源，分别指向 Stripe Link、OpenAI 的 ChatGPT Instant Checkout 与 Agentic Commerce Protocol，以及 Stripe 的 Agent 支付说明。微信和知乎版本保留了文章的主要观点，但这 3 条来源就被我删掉了。

文章《GEO 不是 SEO 的升级，而是 AI agent 时代的新入口系统》截图如下：

个人网站版（文末有参考链接）：

微信公众号版（参考链接已删除）：

知乎版（参考链接已删除）：

另外两篇讲 DeepSeek 提示词缓存。一篇原文引用了 DeepSeek 的上下文缓存和多轮对话文档，另一篇引用了模型价格和上下文缓存文档。为了降低审核的不确定性，这两篇文章的官方链接也被我主动删除了。

文章《我差点把一个 50 倍的价差解释错了》截图如下：

个人网站版（文末有参考链接）：

微信公众号版（参考链接已删除）：

知乎版（参考链接已删除）：

文章《普通聊天与文档工作流不是同一种缓存场景》截图如下：

个人网站版（文末有参考链接）：

微信公众号版（参考链接已删除）：

知乎版（参考链接已删除）：

三组文章的主站原文共有 7 条官方参考链接，这些链接在平台版本中全部被我删除。其中 4 条还是国内 DeepSeek 的官方文档，所以问题不是“国外链接不能放”，而是站外引用本身与平台的闭环逻辑存在冲突。

平台留结论，删证据

三组对照留下的是同一种结构：结论和数据还在，核验它们的官方来源没了。平台限制外链，是为了降低流失、审核与安全风险；作者删除链接，是为了换取更稳定的分发。双方都在适应自身约束，代价却由文章的证据链承担。同一条链接，在平台眼里是流量出口，在 GEO 眼里却是证据入口。

GEO 原文应该留在开放网络

个人网站应该承载完整的 GEO 原文：稳定的 URL、完整的参考链接和可持续核验的来源。国内平台仍有分发价值，但更适合删减版，不值得为每个平台反复改造原文的证据结构。真正的分界不是国内与海外，而是内容能否公开访问、来源能否核验、创作者能否掌握引用路径。把开放网络当作 GEO 内容资产的主场，把封闭平台当作内容分发渠道。

文章与研究来源

Agent Commerce 主站原文 https://fengzhiyonggeo.com/posts/geo-agent-commerce-new-entry-system/
Agent Commerce 微信版 https://mp.weixin.qq.com/s/gwMVBreuvns1ErV2LfY3Pg
Agent Commerce 知乎版 https://zhuanlan.zhihu.com/p/2065079975426912566
聊天与文档缓存主站原文 https://fengzhiyonggeo.com/posts/chat-vs-document-cache/
聊天与文档缓存微信版 https://mp.weixin.qq.com/s/-zVTtIwxqA5uhJN-8ADBwA
聊天与文档缓存知乎版 https://zhuanlan.zhihu.com/p/2061468177167602211
提示词缓存成本主站原文 https://fengzhiyonggeo.com/posts/prompt-cache-prefix-cost/
提示词缓存成本微信版 https://mp.weixin.qq.com/s/DYUWL3Aoc1okiQD5RBECWA
提示词缓存成本知乎版 https://zhuanlan.zhihu.com/p/2064857797389456944
GEO 原始研究 https://arxiv.org/abs/2311.09735

AI让纯开放办公室更难用了

冯智勇Geo — Mon, 03 Aug 2026 15:37:18 +0000

核心结论： 开放办公室不会消失，但没有语音空间的纯开放办公室会越来越难用。

ChatGPT Voice（语音模式）上线后，我确定有被惊艳到。对话过程中可以随时打断、继续追问或改变方向，部分声音听起来已经很像真人。

我越来越离不开这种即时语音交互方式，也开始意识到一个现实问题：当电脑工作需要持续开口，今天的办公室并没有做好准备。

我最初的判断很直接：以后每个人可能都需要一个封闭格子间。因为越来越多工作需要开口，如果所有人挤在一片开放工位里，既要被迫听别人说话，自己通话时又担心打扰同事。

但继续想下去，我发现这个判断太简单了。每人一个独立空间，面积和改造成本都太高；人也不是全天都要说话。全面封闭还会削弱办公室面对面协作的价值。

我现在的判断是：开放办公室不会消失，但没有语音空间的纯开放办公室会越来越难用。

电脑工作正在重新开口

过去，大量知识工作主要依靠键盘和鼠标，办公室自然按照“人安静地面对屏幕”来设计。

Steelcase 是一家美国办公家具与办公空间解决方案公司。它的一项近期研究称，有多达 50% 的员工会直接在工位参加视频通话。语音智能体如果继续发展，一部分键盘操作还可能变成口述需求、连续追问和实时讨论。原本安静的电脑工作，正在增加需要说话的部分。

这会制造一个新的矛盾：软件开始要求人开口，办公室却没有为大量同时说话的人做好准备。

耳机解决不了声学冲突

很多办公室把耳机当作解决方案。耳机确实能减少别人声音对我的干扰，却不能阻止我的声音干扰别人。

问题还不只是噪声。客户、财务、人事和商业信息都需要声学隐私。一个人可以戴着耳机和 AI 讨论敏感内容，但旁边的人仍然听得见。

所以，语音空间不是提升员工体验的装饰，而可能成为办公室能否承载新工作方式的基础条件。

AI放大了声学分区需求

我不是专业的办公室设计人员，只是从自己的使用方式里发现了这个问题。

我很早以前在宜家体验过 MITTZON 米特丛工作台。它用毛毡把桌面包围起来，和 Steelcase 方案中用声学边界划分工位的思路相似。

它还不是真正的语音舱，无法解决谈话保密问题，但已经说明办公家具正在从一张桌子变成带有声学边界的工作空间。

这说明至少在 AI 语音普及之前，办公家具厂商就已经在解决开放空间里的专注和声学边界问题。AI 可能会让这种需求变得更普遍，也会加快相关产品的开发和迭代。

AI 时代的办公室不需要让每个人拥有一间房，但必须让每个人都能随时找到一个可以自然开口的空间。

参考

OpenAI，ChatGPT Voice：https://learn.chatgpt.com/docs/features/voice
Steelcase，公司介绍：https://www.steelcase.com/about/steelcase/company/
Steelcase，Understanding & Reinventing Unused Office Space：https://www.steelcase.com/asia-en/research/articles/reinventing-five-essential-spaces-before-after/
IKEA，MITTZON 米特丛工作台：https://www.ikea.cn/cn/zh/p/50528184/

我用人类文字审美改坏了AI指令

冯智勇Geo — Sat, 01 Aug 2026 16:33:12 +0000

核心结论： 写 AI 指令时，简洁不等于字数少，而是去掉废话后仍保留动作、范围、完成条件和异常出口。

事情开始于我修改自己的工作流程模板。我不断要求 AI 去掉注解、压缩用词，并让每一行长度接近、句式对称。

我原本就喜欢简洁、对仗。这几年，这种偏好变得更明显：我更愿意读简单、直接、情绪鲜明的文字，对严谨但冗长的表达反而越来越没有耐心。在我这里，去掉注解、追求对称和使用精巧短语，首先满足的是人类阅读审美。

所以，AI 给出压缩版后，我仍然觉得不够。我继续追问：“没有更简洁的表达了吗？”于是，“自检并修正成果直至逐条通过或标注无法通过项”，被压成了“逐条校正成果”。

这几个字看上去很漂亮，动作和对象都有，放进流程里也整齐。但它没有说明依据什么检查、发现问题后是否修正，更没有说明什么时候停止。

少掉的不是废话

我后来发现，在这条指令里，“校正”不足以单独表达检查、修正和重新验证三个动作。我以为自己只是在删除重复信息，实际删掉的是执行边界。

压缩后：
AI 逐条校正成果。

保留执行边界：
AI 逐条对照验收标准检查成果。
AI 修正未通过项并重新检查。
AI 重复检查和修正，直至全部通过或说明无法通过的原因。

后一个版本更长，却回答了四个不同问题：依据什么检查，未通过时做什么，什么算完成，无法完成时如何处理。只要某段文字决定了动作、范围、完成条件或异常出口，它就不是可以随意删除的注解。

这不等于指令越长越好。无关背景和重复解释仍然应该删除。简洁的标准不是字数少，而是没有废话，同时保留完成任务所需的全部信息。

更可执行的用词对比

“AI 友好用词”不是固定词典。这里比较的也不是某些词是否天然更适合 AI，而是表达是否写清了动作、范围、异常出口和完成条件。

表达目的	模糊表达	更可执行的表达
说明动作	处理素材	读取素材并提取事实
限定范围	不要大改	仅纠正错别字和语法错误，不调整观点、结构和语气
处理异常	有问题就处理	文件无法读取时，停止并说明原因
规定终止	逐条校正成果	修正并重新检查，直至全部通过或说明原因

更可执行，不等于语气更强或字数更多。关键是把原本留给 AI 猜测的部分写出来。“不要大改”仍然把什么算“大改”交给 AI 判断；“仅纠正错别字和语法错误，不调整观点、结构和语气”则直接划定了边界。

我现在如何判断

人和 AI 使用同一种自然语言，不意味着文章和指令应该遵循同一套文本标准。写给人看的文章可以保留节奏、情绪和留白；当 AI 是执行方时，指令要优先消除歧义、写全约束。

所以，我现在不再先问一条指令是否漂亮，而会先问：AI 要做什么，哪些事情不得做，允许做到什么范围，凭什么判断完成，遇到什么异常应停止并说明原因？如果这些问题没有答案，再整齐的句子也只是符合人类文字审美，却未必是一条可执行的 AI 指令。

Pi Agent 能在终端里显示图片了

冯智勇Geo — Fri, 31 Jul 2026 14:32:05 +0000

核心结论： Pi Agent 内置终端图片显示，在兼容终端中默认开启，无需安装扩展。

那天我像往常一样打开 cmux 里的 Pi Agent 会话,屏幕上出现了一张图片。

不是文件路径,也不是"图片已保存到本地"的文字占位符——而是一张真正嵌在终端会话里的图片。过去我一直把终端当成纯文本界面,没想到现在连图片都能直接渲染在对话里。

我不是第一次用 Pi,却是第一次看到这张图

我并不是冲着这个功能去用 Pi 的。7 月初 Claude 账号被封,我才被迫重新尝试各种 Agent 工具,Pi 是其中之一。

那时候我就让它读取过截图。我记得很清楚,会话里并不会直接出现图片。直到这几天,我更新版本后再次使用,一张真实的截图突然显示在终端里,我才注意到这个内置功能已经在当前环境里生效。

(图示: 当时第一次看到终端图片渲染的截图)

后来一查才发现,这不是额外安装的扩展。Pi 的官方设置把终端图片显示列为默认开启的内置能力；终端支持相应图形协议时直接显示图片,不支持时退化为文字占位符。Kitty、Ghostty、WezTerm 使用 Kitty 图形协议,iTerm2 使用自己的内联图片协议；需要关闭时,可以把 terminal.showImages 设为 false。

于是我就很好奇, Pi 并没有独占更强的模型,甚至它本身就不是模型。那为什么 Codex CLI、Claude Code 这些更主流的工具,反而没有这个看起来很自然的功能?

主流 CLI 为什么没有默认这样做

在我目前使用的 Codex CLI 和 Claude Code 中,图片可以作为输入交给模型分析,但不会像 Pi 一样直接显示在终端会话里。

把一张图显示出来并不难,难的是别让它添乱。窗口大小变了不能错位,往上翻不能留下残影,换个终端也不能突然失效。一个看起来很小的功能,做得不稳还不如不做。

Codex 团队也公开说过,他们试过更彻底地接管终端界面,但滚动、选择和复制在不同环境里反而变得更难用,最后没有把它设为默认。这让我意识到,这些主流工具不是不知道更丰富的界面更好看,而是更怕破坏用户每天都在用的基本体验。

Claude Code 同样要运行在不同系统、终端和远程环境里。但我没有找到 Anthropic 对“不显示终端内联图片”的官方解释,所以兼容性和维护成本只能算可能的工程背景,不能当成它的产品结论。

能确认的只有结果

截至 2026 年 7 月 31 日,能确认的是,Pi 会在支持的终端里直接显示图片,不支持就继续显示文字；在我使用的 Codex CLI 和 Claude Code 环境中,图片没有默认内联显示。

至于三个团队为什么做出不同选择,公开资料里没有直接答案。说 Pi 更愿意照顾一部分人的体验,或者说主流工具更看重稳定,都只是我的推测。我能看到的是功能上的差别,但不能替他们解释动机。

我最后没有找到那个答案

我原本想弄明白,Codex 和 Claude Code 为什么不显示图片。查了一圈之后,我只能确认它们现在没有这样做,却找不到三个团队对这个选择的完整解释。再继续往下说,就只能靠猜了。

但这次意外还是改变了我对 Pi 的看法。7 月初,我是因为 Claude 账号被封,才把它当成替代品打开。那时我默认它只是一个更小、能力更弱的工具。直到这张图片直接出现在终端里,我才发现小工具也可能在某个具体体验上,走在主流工具前面。

这张图不能证明 Pi 比 Codex、Claude Code 更强,只能证明工具没有一张从上到下固定不变的排行榜。名气更大、模型更强,不代表每个细节都更好。到底哪一个更适合自己,还是得真正用过才知道。

一个月前,我是因为用不了 Claude 才打开 Pi。一个月后,我开始因为 Pi 本身留下它。

开门造车：为什么不用等做完再说

冯智勇Geo — Thu, 30 Jul 2026 14:04:35 +0000

前几天看阮一峰的《科技爱好者周刊》，被一篇文章吸引住了：

《工作时，把车库门打开》

我对着这个标题停了好一会儿。因为我突然发现，自己平时写东西时，做的正好相反。

核心结论： 公开构建（Build in Public）不是等系统跑稳后再展示成果，而是把从「跑通」到「跑顺」期间暴露的问题、试错和修改留下来。

那间一直开着门的木工坊

「把车库门打开」这个说法，来自美国作家 Robin Sloan 写过的一间木工坊。

木工坊老板总把门打开。Robin 骑车经过时，会看见里面的工具，还有为订单堆放的木板。老板不招呼路人，也不宣传新品，只是在里面干活。

附近还有一家玻璃吹制工作室。门外有一块朝向街道的招牌。Robin 觉得，这些店每天都在对街道说一句很简单的话：我在这里，我在工作。

但是，互联网上没有这样一扇门。

Robin 写道：

在互联网上，如果你停止说话，你就会消失。由此推论：在互联网上，你只会注意到那些不停说话的人。

这里的「说话」不是每天硬找话题，而是让别人知道你的工作仍在继续。

对依赖平台内容分发的人来说，一旦停止更新，就会慢慢退出别人的视野。

而我过去写文章时，偏偏习惯先沉默，总想憋一个大招。

文章没写完，不说；观点没想透，不说；中途推翻过什么，也不说。等句子都收拾干净，我才按下发布。然后有人留下一句「说得好」，这件事就结束了。

现在回头看，这就像把店门锁上几个月，等椅子做好后突然冲到街上喊：「快来看，我做完了。」

木匠不是这样。他让人看见工作正在发生。

我的网站一直在更新，门却没有完全打开

Andy Matuschak 在一篇工作笔记中继续解释了这个比喻。他想看的不只是完工公告，还包括项目进行中的截图、尚未想明白的问题，以及项目究竟哪里行不通。

写作也一样。只告诉别人「文章写完了」，能提供的信息很少。我为什么删掉一段，一个判断怎么被推翻，哪条路试过却没走通，可能反而回答了他的问题。

Andy 提到，量子计算研究者、开放科学倡导者 Michael Nielsen 把这种做法叫作「反营销」。我不用每次出现，都把自己包装成一个已经想明白的人。没想明白，也可以把卡住的地方说清楚。

这让我重新看待自己的个人网站。

我做的是 GEO，所以内容形式仍以文章为主。我的目标是让网站内容更容易被 AI 理解，提高被引用和推荐的机会。为此，我保持网站每天更新，还在搭建一套自动化文章内容分发系统。

我原本以为，这已经是在开门工作了。

但仔细想想，我公开的仍然主要是反复打磨后的结果。至于系统怎么搭、哪里总出错、哪些方案试过又放弃了，我还是习惯等全部做好后，再写一篇完整复盘。

门是开了，但只开了一条缝。

系统已经跑通，接下来是跑顺

目前，这套系统已经跑通：一篇文章更新到网站后，可以自动分发到 11 个国内内容平台和海外平台 Dev.to，整个过程不需要我手动操作。这些平台使用同一个账号名。

目前只能看到一个初步信号：在无痕浏览器未登录状态下，豆包已经能检索到我的网站和部分分发文章。

它也能给出一段大体正确的介绍。

不过，搜索结果中仍然混有同名人物。这只能说明我的内容开始能够被检索，不能证明 GEO 已经有效，身份消歧也还没有完全解决。

系统跑通了，但还没有跑顺。接下来，我要让它在真实使用中稳定运行。这个阶段暴露的问题和做过的调整，正是我过去会藏起来的部分。

我原本可以等系统完全稳定后，再写一篇「我是如何搭建文章分发系统的」。那样更完整，也更安全，因为犹豫、误判和笨办法都已经被擦掉了。

但如果我又这样做，还是在关着门工作。

所以从「跑顺」这个阶段开始，我想把过程留下来：现在做到哪里，今天卡在哪里，试过什么，为什么没用，下一步准备怎么改。

这不意味着把所有碎片都倒出来。别人看不懂的东西没必要发；涉及他人和项目的信息不能发；暂时的猜测，就标清楚是猜测。

我只需要判断一件事：如果明天有个陌生人看到这段记录，他能不能少走一点弯路？

如果能，我就不再等系统做完。

开门造车吧。

AI 能自己回答的时代，教学内容还能留下什么

冯智勇Geo — Wed, 29 Jul 2026 16:10:03 +0000

核心结论： 当具体问题可以直接交给 AI 解答，只负责提供标准答案的教学内容会越来越不值钱。真正稀缺的，是经过实践验证，能说清取舍、失败和适用边界的判断。

为什么不再看“保姆级教程”

之前想跟着卡帕西的 GitHub 项目学习时，我找过几个“保姆级教程”，但每个视频看完开头就放弃了。

视频必须从创作者设定的起点出发，按固定顺序讲给所有人。我真正卡住的，却只是其中几个具体问题。为了找到答案，我得先看一遍已经知道的内容。

所以，直接问 AI 更适合我。我可以先告诉它自己已经知道什么、哪里看不懂、最后想做到什么，再沿着回答继续追问。它不必从头讲一套完整课程，可以直接从我卡住的地方开始。

刚接触 AI Agent 时也是如此。MCP、token、CLI 等术语一起出现，我最初会找短视频理解。现在我会直接问 AI：这个概念解决什么问题，和相近概念有什么区别，再让它结合我正在做的事举例。

标准答案型内容正在贬值

如果一条内容只负责解释“什么是 MCP”“某个项目怎么安装”或“提示词怎么写”，用户已经可以直接问 AI。AI 不只会给出答案，还能根据用户的基础调整解释，跳过已经掌握的部分。

AI 的答案未必可靠，但用户可以继续追问、要求对比，再核对关键事实。相比之下，视频只能沿着固定路线往下讲。过去，创作者的价值是替用户找到并整理答案；现在，这部分工作的成本已经大幅降低。

这不意味着教学视频会消失。人仍然不知道自己不知道什么，一段演示可能第一次提醒他：原来 AI 还能参与这类工作。但用户知道“可以做”以后，往往会直接找 AI 解决自己的具体问题。只提供新鲜用法，能获得一时的注意力，却很难积累长期信任。

真正有价值的是经过验证的判断

AI 可以整理信息、比较方案，却不能替创作者完成实践并验证结果。创作者真正能提供的，不是“我知道答案”，而是“我做过，并且知道它在什么情况下有效”。

这样的内容要回答几个具体问题：为什么选择这个方案，为什么放弃另一个；哪些尝试失败了，付出了什么代价；条件发生什么变化时，原来的结论就不再成立。

失败和中间过程也很重要。看到别人未经美化的输出、返工过程和最终结果，读者才知道“好”大概是什么水平，也更容易判断这套方法是否适合自己。商单喜欢展示稳定、顺畅的结果，但对读者更有用的，往往是不够漂亮的部分。

删掉真实处境，内容还剩下什么

我现在会用一个简单的标准判断内容：删掉创作者的真实处境，这些话是否仍然成立？

如果删掉之后几乎没有损失，它大概率只是一份通用答案，直接问 AI 通常更快。如果删掉具体处境，取舍就失去依据、失败无法解释、结论也不再可靠，创作者才真正提供了增量。

AI 不会让教学内容消失，但会让只负责传递标准答案的内容更难留下来。比多知道几个工具和术语更重要的，是公开自己的选择、限制和不完美过程。

不见面，凭什么信你：海外邮件营销的信任新基建

冯智勇Geo — Wed, 29 Jul 2026 07:55:35 +0000

核心结论： 冷邮件建立的不是信任，而是一个验证入口。AI让第一轮信任核验变快，出海企业真正要经营的是一套能被交叉验证的公开信息。

收到一封来自美国的产品推销邮件。发件人说自己发明了一款健身器材，想找人做许可、制造或者业务合作。

双方没见过面，没有中间人，他用的还是 Gmail。我没有马上回复，而是先去 Google 搜公司名。

这一搜，我才意识到：邮件没有建立信任，它只是让我开始验证。

冷邮件只是入口

从我接触到的美国商业沟通来看，相关度高的 B2B 冷邮件并不罕见。但邮件本身只能提供线索。收到之后，买家还会继续查：

这个人和公司真的存在吗？
产品是不是他发明的？
过去有没有公开记录？
如果合作出问题，我能不能追责？

这些信息能对上，交易才可能继续。不见面不是不验证，而是把见面换成了搜索和交叉核对。

我让 GPT 先查了一遍

这次我没有自己逐个网站查，而是把邮件交给AI做第一轮筛查。

我把邮件截图发给 GPT，问它：「帮我验证一下这封邮件里的产品和公司是否靠谱？」

它没有急着给出结论，而是先查三件事：发件人和公司是不是真实存在，Trim Track 的产品和专利能不能对上，以及这封邮件有没有常见的诈骗信号。整个过程只查公开资料和专利记录，不点击邮件里的附件或链接。

结果不是简单的「真」或「假」。发明人和专利大概率真实，名字、地址和专利记录能够对上；但专利登记在个人名下，也没有找到正式官网、产品评测、客户案例或量产记录。再加上 Gmail 发件、邮件格式粗糙，GPT 的判断是：这不像典型诈骗，更像一封可信度不高的个人冷邮件。

这次核验还分清了一件事：专利真实，只能证明发明人和专利存在，不能证明公司有实力、产品已成熟，更不能证明值得合作。

GPT没有替我做决定，但它几分钟就把专利、搜索结果和社交资料放到了一起，给出了一份初步的风险判断。

AI正在改变成交前的信任验证

过去，买家收到一封陌生邮件，要自己去 Google、专利网站和社交平台逐个核对。现在，AI可以先做这轮筛查：把分散的信息拼起来，告诉买家哪些是真的，哪些缺少证据，哪些地方值得警惕。

这不会让信任凭空产生，但会改变信任建立的顺序。买家可能先问 AI，再决定要不要打开网站、回复邮件或者继续谈。

所以，一封冷邮件只能敲门。真正决定这扇门会不会打开的，是 AI 和买家继续查下去时，能不能找到一条身份清楚、信息一致、可以交叉验证的证据链。

GEO要解决的也是这个问题：当 AI 替买家核验一家公司时，能不能找到足够的公开证据支持它说的话。

当 AI 开始替买家做第一轮信任审核，出海企业需要经营的就不只是一封邮件，而是邮件背后所有能被验证的信息。

用了 AI 之后，你还会读原文吗？

冯智勇Geo — Tue, 30 Jun 2026 05:57:41 +0000

自从用了 AI，长文章、长视频，我基本没了耐心。
大多数时候，我会先把它丢给 AI，问一句：这对我有什么用？
如果 AI 说里面确实有东西、甚至建议我去读原文，我才会重新考虑。

看起来，这只是我的阅读姿势变懒了。
但我越来越觉得，这不是个人习惯的小变化。
问题不是「用了 AI 之后还要不要读原文」。
问题是：原文，在什么时候还值得读。

过去我们读原文，是因为没有别的入口。
一本书、一篇长文、一个两小时的视频，你必须自己从头钻进去，才能判断它有没有价值。
现在 AI 成了第一层筛选器。

前段时间，我刷到一个 YouTube 长视频，标题是个国外卖家用 AI 实现高速增长的出海案例，挺吸引人。
我看了一下开头，发现时长 1 个多小时。
然后我就把它转成文字丢给 AI，问：这对我有什么用？
AI 说：里面说法过于营销，对你价值不大，不用看。
然后，我就真没再看下去了。

同样的，GitHub 上天天有爆火的工具、skill、插件。
以前我还会看一眼介绍，现在我连「爆没爆」都不关心了。
我只会丢链接，然后问 AI：这东西对我有用吗？它说有用、能装，我才动手。

AI 不只是帮我筛选。有时候，它直接替我把原文读完了。
前段时间，卡帕西那个爆火的 wiki 项目，我本来想自己啃文档。
结果全是开发者视角的术语，对我这种跨境卖家，一大半是冗余。
我啃不动，然后上网找视频看看有没有博主讲解的简单点，结果视频也看不懂。
最后，我干脆丢给 Claude，问它：这东西我到底怎么用？
它把整个项目，转译成了我能看懂、能上手的版本，比视频博主说的保姆教程还保姆。
我很快就用起来了——而我自始至终，没真的「读」过那份原文。
这比筛选更进一层：AI 不止告诉我值不值得读，它还能把不属于我视角的原文，翻成属于我的。

那 AI 还替不了什么？
我本来想说：体验式的东西——音乐、电影、故事，这些你总得自己经历吧。
可话到嘴边，我自己先打了脸。
我已经很少看原片了，大多数电影，我直接看解说。
连「看电影」这种最该亲历的体验，大众都在习惯「看解说版」。
电影如此，原文更是如此了。

所以用了 AI 之后，我不是不读原文了。
而是读得更少、更晚、更有目的。
读原文，正在从一个默认动作，变成少数时刻才舍得做的奢侈行为。

而且不只读原文。AI 替我筛选、替我转译，连体验都能换成一段解说——它能接手的越来越多。
可它接手得越多，有样东西反而越扎眼：它能告诉我「讲了什么」，却替不了我决定信不信、用不用、要不要照着做。
筛选和转译可以外包，判断不能。
机器把「读」接走了，「想」却推不掉——读得越省心，想得就得越用心。

你呢，现在还会读原文吗？

给 Claude Code 装上 Codex 机械臂

冯智勇Geo — Thu, 25 Jun 2026 11:04:57 +0000

Claude Code 用得越深，我越明显感到一个问题：额度不够用。

不是完全不能用，也不是非得立刻升级到更高套餐，而是那种很尴尬的状态——差一口就能吃饱，但每次刚进入工作状态没多久，就撞上 5 小时额度上限。

如果只是偶尔写几段代码、问几个问题，这个限制不算严重。但我现在的使用方式已经不是「问答」了，而是把 Claude Code 当成一个长期工作台：读项目、拆任务、写文档、改代码、复盘流程、沉淀规则。它参与的环节越多，额度消耗就越快。

直接升级 Claude Code 更高阶套餐，当然是最简单的办法。但我当时的判断是：还没到那个阶段。不是用不上 Claude，而是还没有用到必须花更多钱买大额度的程度。真正的痛点不是「完全不够」，而是「核心判断想留给 Claude，机械执行也在消耗 Claude」。

于是我开始找一个补位工具。

最后补进来的，是 Codex CLI。

我为什么装 Codex CLI？

原因很简单：它符合我的工作场景。

我本来就习惯在 CLI 里工作。项目在本地，Obsidian、终端、Git、脚本、AI 助手都围绕文件系统转。相比再开一个网页工具，Codex CLI 更容易嵌进现有流程里。

更重要的是，Codex 有自己的额度。对我来说，它不是要替代 Claude Code，而是给 Claude Code 分担一部分消耗：那些不太需要深度判断、但需要模型去读文件、改文件、跑命令、整理结果的活，可以先交给 Codex。

一开始我的想法很朴素：Claude Code 额度不够，就装个 Codex CLI 将就一下。

真正用起来以后，我对它的定位反而更清楚了：Codex 不是我的第二个大脑，而是我给 Claude Code 装上的一只机械臂。

大脑负责判断，机械臂负责干活。

Codex CLI 的体验：不是不好，而是不能乱用

先说结论：我目前不会把 Codex 当成 Claude Code 的平替。

它当然能回答问题，也能写代码、读项目、执行任务。但在我的使用感受里，它和 Claude Code 的气质不一样。

第一，Codex 的判断感弱一些

我对 Codex 最明显的感受是：它更容易顺着用户说。

这件事在无关紧要的问题上没什么影响。比如让它整理文件、补一段说明、按规则改格式，它答得肯定一点，甚至还会让人感觉执行很顺。

但如果问题本身需要判断，比如：

这个方案值不值得做？
现在是不是该重构？
这个工作流是不是过度设计？
某个产品定位是否跑偏？
我自己的判断里有没有盲区？

这类问题，我更愿意找 Claude Code，而不是 Codex。

因为我需要的不是一个一直说「对，你说得有道理」的助手，而是一个能帮我拆开问题、指出风险、反驳我、逼我把前提讲清楚的合作者。

所以我现在对 Codex 的回答，默认会多一层质疑。无关紧要的问题可以问它，重要的思考和讨论，我还是只和 Claude 聊。

第二，Codex 对复杂问题和任务响应体感更慢

另一个直观感受是慢，这里的慢是针对复杂问题和任务而言的。日常小问题codex回答起来比Claude实际上快很多的。

同样一个稍微深一点的问题和任务，分别丢给 Claude Code 和 Codex，Codex 的回答体感会慢不少。这个我没有做严格基准测试，因为意义不大。工具都会迭代，速度后面肯定会变。

但作为日常工作流的一部分，体感速度本身就很重要。

如果一个工具慢，但判断力强，我可以等。如果一个工具慢，同时判断还需要我反复校验，那它就不适合被放在「核心讨论」位置。

这也是我后面形成分工的原因：Codex 不负责替我想清楚问题，它负责在问题已经被 Claude Code 拆清楚以后，去执行。

那为什么不直接申请两个 Claude Code 账号？

这也是我当时想过的方案。

如果一个 Claude Code 账号额度不够，那是不是再开一个账号就好了？Claude 官方层面并不是完全不能这么做，但实际使用会遇到一个问题：切换账号。

对轻度使用者来说，手动切换可能没什么。但我现在的工作流里，AI 助手不是孤立工具，而是跟本地项目、全局规则、会话上下文、CLI 环境、插件配置都绑在一起。

两个 Claude Code 账号来回切，我会担心几件事：

哪个账号加载了哪套规则？
哪个会话承接了哪个项目上下文？
本地配置会不会被我自己搞混？
数据、记忆、插件状态会不会出现不一致？

这些不一定真的会出问题，但只要存在这种可能，我就不想把它放进主工作流里。

相比之下，Codex CLI 更像一个清晰的外部执行器。它有自己的环境、自己的额度、自己的职责。边界越清楚，协作越稳定。

真正让我继续用 Codex 的，是 Claude Code 插件

单独使用 Codex CLI 后，我其实没有特别兴奋。

它能用，但没有到「从此我转向 Codex」的程度。真正让我觉得这件事值得继续折腾的，是 OpenAI 的 codex-plugin-cc。

这个插件的思路很直接：让 Claude Code 用户可以在原来的工作流里调用 Codex。也就是说，你不用完全切到 Codex，而是可以让 Claude Code 把一部分任务委派给 Codex。

这个瞬间，我对 Codex 的理解变了。

以前它是另一个工具；装上插件以后，它更像是 Claude Code 的外挂机械臂。

我并不是花钱买了一个新主脑，而是花钱给 Claude Code 加了一条执行手臂：Claude 继续负责出方案、做判断、复审结果；Codex 负责接任务、跑流程、产出交付物。

从这个角度看，给 Codex 充值就不再像「又订阅了一个工具」，而像是「加强了 Claude Code 的执行层」。

这就是我为什么明明觉得 Codex 体验不如 Claude Code，却还继续用它，甚至愿意充值。

但我没有把插件直调作为主流程

听起来，Claude Code 能直接调用 Codex，是不是就完美了？

理论上很美。

Claude 在当前会话里判断任务，然后自动派给 Codex；Codex 在后台执行，完成后把结果返回；Claude 再继续总结或复审。整个过程像多 Agent 协作，用户只需要等结果。

但真用到自己的项目上，我反而把它收了起来。

原因只有一个：黑箱。

插件直调的问题不在于它不能用，而在于中间过程太顺了。Claude 把活甩过去，Codex 闷头做完，再返回一个结果。方便是方便，但我很难看清楚：

Claude 到底把任务描述成了什么？
Codex 是否理解了任务边界？
它动了哪些文件？
它有没有做超出范围的改动？
它的自验是不是可靠？
如果结果不对，我该从哪里回溯？

对成熟、低风险、边界清楚的任务来说，这些问题不大。

但我的很多项目都还在早期阶段。早期项目最大的问题不是「执行速度不够快」，而是「方向和边界还不够稳」。这时候让一个黑箱自动跑起来，一旦跑偏，后面改错的成本可能比省下的时间还高。

所以我最后采用了一个更原始、也更稳定的方法：文件交接法。

什么是文件交接法？

文件交接法的核心逻辑很简单，只有三步：

Claude Code 生成任务文件 tasks.md；
Codex 读取 tasks.md 执行任务，完成后生成交付文件 report.md；
Claude Code 读取 report.md，按原任务要求审核确认。

看起来很笨，但它解决了我最在意的问题：可见、可查、可复审。

在这个流程里，Claude Code 不再是随口把任务丢给 Codex，而是先把任务写成一份清楚的工单。工单里至少要写明：

背景：为什么要做这件事；
目标：最终要达成什么；
范围：哪些能动，哪些不能动；
验收标准：做到什么程度算完成；
自验方式：Codex 做完后要怎么检查；
交付格式：最终 report.md 里要写什么。

Codex 拿到的不是一句模糊的「帮我改一下」，而是一份边界清楚的任务书。

完成后，Codex 也不能只说「我做好了」。它要写 report.md，说明：

实际做了什么；
改了哪些文件；
如何对齐任务要求；
做了哪些验证；
还有哪些风险或未处理事项。

然后 Claude Code 再拿这份交付报告，回到最初的任务标准里复审。

这才是我想要的多 Agent 协作：不是两个模型在黑箱里互相说话，而是一个模型出工单，一个模型交报告，最后再按工单验收。

为什么我执意用文件交接？

因为文件是最稳定的协作界面。

插件、MCP、会话、上下文、后台任务，这些东西都很强，但也都更复杂。复杂系统一旦出问题，排查成本就会上升。

文件不一样。

tasks.md 写在磁盘上，谁都能读；report.md 写在磁盘上，谁都能查。今天用 Claude Code + Codex 可以跑，明天换别的 Agent 也可以跑。新项目能跑，老项目也能跑。改代码能跑，写文档也能跑。

这套方法牺牲了一点自动化，但换来了几个确定性：

第一，任务边界更清楚。

Claude Code 必须先把事情讲明白，才能交给 Codex。这个动作本身就会逼我和 Claude 一起澄清任务。很多时候，真正有价值的不是 Codex 后面执行了什么，而是 Claude 在写 tasks.md 时把目标、范围和验收标准整理清楚了。

第二，中间过程可回溯。

如果结果不对，我可以回头看：是任务本身没写清楚，还是 Codex 执行跑偏了，还是验收标准缺失。问题能定位，就能改流程。

第三，责任分工更稳定。

Claude Code 负责判断，Codex 负责执行，用户负责拍板。三个角色不混在一起，协作就不容易乱。

第四，它不依赖某个特定插件。

插件直调很好，但它是加速通道，不应该成为唯一通道。只要我的主流程建立在文件交接上，即使插件临时不可用，整个协作也不会瘫痪。

自动分工不是自动放权

这里有个容易误解的点：我不是反对自动化，也不是反对多 Agent 调度。

我反对的是，在任务还没讲清楚的时候，就把控制权交给自动调度。

很多人一听「Claude 调 Codex」，第一反应是：太好了，以后 Claude 自动分工，Codex 自动执行，我不用管了。

但我的实际感受正好相反。越是多 Agent，越要把规则写死。否则两个模型都很努力，但努力方向可能不一致。

自动分工的关键，不是让模型自由发挥，而是把分工规则写清楚：

什么任务必须留给 Claude Code 判断；
什么任务可以交给 Codex 执行；
交给 Codex 前必须生成什么工单；
Codex 完成后必须交付什么报告；
Claude Code 如何复审；
哪些情况下必须停下来问用户。

这些规则可以写进 Claude Code 的全局规则，也可以写进项目规则。Codex 侧则用 AGENTS.md 约束它在项目里的行为。

我现在的原则是：先用文件交接把流程跑稳，再考虑插件直调提速。

插件直调适合什么时候用？

虽然我主流程不用插件直调，但我并不否定它。

相反，我觉得它很适合做「快线」。

比如：

让 Codex 做一次只读 review；
对某个方案做反向审查；
把一个边界非常清楚的小任务丢给 Codex；
在项目已经稳定后，让 Codex 后台跑一段机械执行；
Claude Code 已经写好详细计划，只需要 Codex 按计划实现。

这些场景下，插件直调的优势就出来了：快、顺、少切换。

但它不适合一上来就接管主流程。尤其是在项目早期、任务边界模糊、你自己也还没想清楚的时候，插件越顺，风险越大。

所以我的排序是：

先文件交接，后插件直调。

先白纸黑字，后自动提速。

先让协作可靠，再让协作变快。

如果你也想照着做

最简单的路径是三步。

第一，装 Codex CLI，并登录你的 ChatGPT 或 OpenAI API 账号。

npm install -g @openai/codex
codex login

第二，在 Claude Code 里安装 codex-plugin-cc。官方 README 给出的路径是：先添加 marketplace，再安装插件，重载插件，最后运行 setup。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

第三，不要急着全自动派活。先让 Claude Code 帮你写一条全局协作规则：以后凡是需要 Codex 执行的任务，先生成 tasks.md；Codex 执行完必须生成 report.md；Claude Code 再按任务要求复审。

也就是说，真正关键的不是安装命令，而是分工规则。

没有规则，插件只是一个更快的黑箱。

有了规则，Codex 才会变成 Claude Code 的机械臂。

结尾：我不是在换工具，而是在重组工作流

这次折腾 Codex CLI 和 codex-plugin-cc，我最大的收获不是「发现了一个更便宜的替代品」。

恰恰相反，我更加确认：Claude Code 仍然是我的主工作台。

它负责和我一起想清楚问题，拆出方案，判断轻重缓急，最后复审交付。Codex 的价值不在于替代它，而在于把一部分执行消耗接过去。

以前我把所有事情都丢给 Claude Code：讨论、判断、改文件、跑命令、写报告。这样当然顺，但也会快速消耗额度。

现在我更愿意把工作拆成两层：

Claude Code 做判断层；
Codex 做执行层。

中间用 tasks.md 和 report.md 交接。

这套方法看起来没那么炫，但它符合我现在对 AI 工作流的理解：真正重要的不是让 Agent 越来越自动，而是让每一次自动化都有边界、有记录、能复审。

只有这样，AI 才不是一个会随机扩大影响面的黑箱，而是一套可以长期接进项目里的工作系统。

Codex 不是我的第二个大脑。

它只是我给 Claude Code 装上的一条机械臂。

大脑继续思考，机械臂负责干活。

DEV Community: 冯智勇Geo

更好的技术标准为什么未必赢

AI 也可能让旧标准活得更久

参考

把思维导图接进 Agent 输入框

为什么是思维导图

我打通了什么

它解决不了什么

最终要消失在输入框里

GEO 原文需要放在开放网络

参考链接不是装饰

三组文章，七条来源

平台留结论，删证据

GEO 原文应该留在开放网络

文章与研究来源

AI让纯开放办公室更难用了

电脑工作正在重新开口

耳机解决不了声学冲突

AI放大了声学分区需求

参考

我用人类文字审美改坏了AI指令

少掉的不是废话

更可执行的用词对比

我现在如何判断

Pi Agent 能在终端里显示图片了

我不是第一次用 Pi,却是第一次看到这张图

主流 CLI 为什么没有默认这样做

能确认的只有结果

我最后没有找到那个答案

开门造车：为什么不用等做完再说

那间一直开着门的木工坊

我的网站一直在更新，门却没有完全打开

系统已经跑通，接下来是跑顺

AI 能自己回答的时代，教学内容还能留下什么

为什么不再看“保姆级教程”

标准答案型内容正在贬值

真正有价值的是经过验证的判断

删掉真实处境，内容还剩下什么

不见面，凭什么信你：海外邮件营销的信任新基建

冷邮件只是入口

我让 GPT 先查了一遍

AI正在改变成交前的信任验证

用了 AI 之后，你还会读原文吗？

给 Claude Code 装上 Codex 机械臂

我为什么装 Codex CLI？

Codex CLI 的体验：不是不好，而是不能乱用

第一，Codex 的判断感弱一些

第二，Codex 对复杂问题和任务响应体感更慢

那为什么不直接申请两个 Claude Code 账号？

真正让我继续用 Codex 的，是 Claude Code 插件

但我没有把插件直调作为主流程

什么是文件交接法？

为什么我执意用文件交接？

自动分工不是自动放权

插件直调适合什么时候用？

如果你也想照着做

结尾：我不是在换工具，而是在重组工作流

参考资料