一只山鬼嘤嘤嘤 RSS

Codex Auth：一个纯本地的命令行工具，切换管理多个 Codex 账号

Mon, 09 Mar 2026 00:00:00 GMT

👉 GitHub：https://github.com/loongphy/codex-auth

npm（推荐，跨平台）：

npm install -g @loongphy/codex-auth

Linux / macOS / WSL2：

curl -fsSL https://raw.githubusercontent.com/loongphy/codex-auth/main/scripts/install.sh | bash

Windows（PowerShell）：

irm https://raw.githubusercontent.com/loongphy/codex-auth/main/scripts/install.ps1 | iex

为什么需要多账号管理？

我相信很多使用 OpenAI Codex 的朋友都遇到过同样的问题——一个账号的额度根本不够用。

Codex 对每个账号有着严格的速率限制：5 小时窗口期内的使用上限、每周的使用上限。当你正在高强度编码、让 Codex 帮你重构项目、跑测试、写文档的时候，额度一不留神就见底了。

怎么办？很多人的做法是：购买多个 Plus 或 Team 账号，轮流切换着用。有额度的用，没额度的歇一歇，等它重置了再切回来。

听起来很简单，但实际操作起来，怎么切换 就成了一个头疼的问题。

现有方案的问题

目前市面上已有一些工具来解决这个问题，比如 CPA（CLIProxyAPI） 之类的代理方案——你需要额外部署一个服务，由它来帮你做账号轮询和负载均衡。

思路是好的，但实际用起来挺折腾的：

需要额外部署。 你得自己搭一个代理服务，找服务器、装环境、配进程守护，这本身就是一件事。
配置要研究。 文档不一定全，参数不一定直观，想跑起来得花时间摸索。
出了问题不好修。 报错了不知道怎么排查，翻 Issues 提问又太麻烦，折腾半天可能还是没解决。

对于只想安安静静写代码的人来说，这些额外的运维成本实在太高了。

我只是想切个账号而已，有没有一个开箱即用的方案？

有的兄弟，有的。

所以我做了 Codex Auth。

Codex Auth 是什么？

Codex Auth 是一个纯本地的命令行工具（CLI），专门用来安全切换和管理多个 Codex 账号。

它的核心设计原则只有一条：

完全本地化，绝不调用任何 OpenAI 的 API。

所有操作——查看账号、切换账号、导入认证文件——全部都是在你本地的 ~/.codex 目录下完成的。它只读写你本机的会话文件（sessions）和认证文件（auth.json），你的凭证永远不会被发送到任何外部服务器。

这意味着什么？

如果你的账号是正规渠道购买的，害怕被识别或封禁，那完全可以放心使用 Codex Auth。 因为它是纯粹的本地文件操作，OpenAI 那边完全无法感知你在用这个工具。没有任何 API 调用，没有任何网络请求，零封号风险。

工作原理

简单来说，Codex Auth 的原理就是管理 ~/.codex/auth.json 这个认证文件。

当你在 Codex 中登录一个账号时，Codex 会在 ~/.codex/auth.json 中保存当前账号的认证信息（包含 JWT Token）。Codex Auth 做的事情就是：

解析 JWT Token：从 auth.json 中读取 tokens.id_token，解码 JWT 的 payload 部分，提取出你的邮箱以及订阅计划（Plus / Team / Pro 等）
为每个账号独立存储：将每个账号的认证文件以 base64url(email) 为文件名，保存在 ~/.codex/accounts/ 目录下
切换时替换：当你要切换到另一个账号时，把目标账号的认证文件复制回 ~/.codex/auth.json 即可

就这么简单，没有任何黑魔法。

额度数据则来自 Codex 本身在 ~/.codex/sessions/ 目录下生成的会话日志文件（rollout-*.jsonl），Codex Auth 会扫描最新的日志文件，从中提取出 5 小时和每周的速率限制信息。

核心功能

当前 Codex Auth 主要实现了以下功能：

1. `codex-auth list` — 一览无余地查看所有账号

codex-auth list

运行后会以表格形式展示你管理的所有 Codex 账号：

EMAIL — 账号邮箱（如果设了别名，会显示为 (别名)邮箱 的格式）
PLAN — 当前订阅计划：free / plus / pro / team / business / enterprise / edu
5H USAGE — 5 小时窗口期的剩余额度百分比，以及重置时间（如 60% (14:30) 表示剩余 60%，14:30 重置）
WEEKLY USAGE — 每周额度的剩余百分比和重置时间
LAST ACTIVITY — 上次使用的相对时间（如 2m ago、1h ago、3d ago）

当前激活的账号会用 * 标记并高亮显示。表格还会根据终端宽度自动调整列宽，在窄终端上也能看。

一眼就能看清哪个账号还有额度、哪个快耗尽了、上次什么时候用的，非常直观。

2. `codex-auth add` — 添加当前登录的账号

codex-auth add            # 默认会先执行 codex login
codex-auth add --no-login # 跳过登录，直接读取本地认证文件

add 命令会把当前 ~/.codex/auth.json 中的账号导入到 Codex Auth 的管理列表中。

默认行为是先调起 codex login（也就是 Codex 自己的登录流程），登录完成后再自动读取认证文件并添加。

但你也可以完全不走这个流程。 加上 --no-login 参数，Codex Auth 会直接读取已有的 auth.json 文件。如果你已经在 Codex 里登好了账号，用这种方式最方便——不需要再登录一次。

这其实也是 Codex Auth 的精髓所在：它的原理就是完全读取本地的认证文件，完全不走任何 OpenAI 的 API。所以如果你的账号是正规的、害怕被封禁的话，完全可以走这种方式。

3. `codex-auth switch` — 灵活切换账号

这是最核心、最高频使用的功能。

交互式切换

codex-auth switch

运行后会展示一个交互式的账号选择列表，显示每个账号的邮箱、订阅计划、额度使用情况和上次活跃时间。你可以用：

↑/↓ 方向键或 j/k（Vim 风格）上下移动
数字键 直接跳转到对应编号
Enter 确认选择
Esc 取消退出

当前激活的账号会以绿色高亮标记 [ACTIVE]，选中的账号会显示 > 指示符。体验非常流畅。

非交互式切换

codex-auth switch user@example.com   # 完整邮箱
codex-auth switch user               # 模糊匹配：邮箱片段
codex-auth switch exam               # 模糊匹配：任意子串

支持模糊匹配——你不需要输入完整的邮箱地址。只要输入邮箱的一部分（前缀、后缀、中间任意片段），工具就能自动找到匹配的账号，大小写不敏感。

如果输入的内容只匹配到一个账号，直接切换，无需确认。如果匹配到多个账号，会自动弹出交互式选择界面让你挑选。

这种非交互式模式特别适合集成到脚本或其他工具中。比如你可以在 .bashrc 里写个 alias：

alias cx-work="codex-auth switch work"
alias cx-personal="codex-auth switch personal"

一条命令就切换到对应的账号，非常高效。

切换时的安全保障

每次切换账号时，Codex Auth 会：

自动备份当前的 auth.json（仅在内容发生变化时才备份，避免重复）
将目标账号的认证文件复制到 ~/.codex/auth.json
更新注册表的 active_email 字段

备份文件保存在 ~/.codex/accounts/ 目录下，格式为 auth.json.bak.<timestamp>，最多保留最近 5 份。即使误操作，也能轻松恢复。

4. `codex-auth import` — 智能导入认证文件

如果你像我之前一样，有手动备份多个 auth.json 文件的习惯——比如每次登录完一个账号就把 auth.json 复制一份、改个名保存起来——那这个功能简直就是为你量身定做的。

导入单个文件

codex-auth import /path/to/auth.json --alias personal

导入一份认证文件，还可以用 --alias 给它起个别名。别名会在 list 和 switch 命令中显示在邮箱前面，方便区分。比如设了 personal，列表里就会显示 (personal)user@example.com。

批量导入整个文件夹

codex-auth import /path/to/auth-backups/

Codex Auth 会自动识别路径类型：

如果是文件 → 导入单个认证文件
如果是文件夹 → 扫描目录下所有 .json 后缀的文件（不递归子目录），逐个尝试解析并导入

无效的文件会被自动跳过，不会报错。批量导入模式下 --alias 参数会被忽略，因为每个账号会根据邮箱自动命名。

这个功能让你可以把之前手动备份的一堆认证文件一次性全部导入到 Codex Auth 里，省去了逐个添加的麻烦。

5. `codex-auth remove` — 移除不需要的账号

codex-auth remove

交互式多选。运行后会展示所有账号的列表，你可以：

↑/↓ 或 j/k 移动光标
空格键 勾选/取消勾选要删除的账号（支持多选）
Enter 确认删除
Esc 取消

如果你删除了当前激活的账号，Codex Auth 会自动切换到一个额度最充裕的账号作为新的活跃账号。

完整命令速查

codex-auth list                          # 列出所有账号及额度
codex-auth add                           # 添加当前账号（先登录再导入）
codex-auth add --no-login                # 添加当前账号（跳过登录）
codex-auth switch                        # 交互式切换账号
codex-auth switch <email或片段>            # 非交互式切换（模糊匹配）
codex-auth import <文件路径>              # 导入单个认证文件
codex-auth import <文件路径> --alias <别名> # 导入并设置别名
codex-auth import <文件夹路径>            # 批量导入文件夹中的认证文件
codex-auth remove                        # 交互式移除账号
codex-auth --version                     # 查看版本

已知限制

1. 额度显示的实时性问题

最简单的场景：假如你当前没有任何正在运行的 Codex 会话，你从上一个账号切换到下一个账号的时候，你会发现新切换的账号显示的额度和上一个账号一模一样。

为什么会这样？

因为额度数据来源于 ~/.codex/sessions/ 目录下的会话日志文件（rollout-*.jsonl）。这些文件是 Codex 在运行过程中实时写入的。如果当前没有任何活跃的 Codex 会话，就不会有新的日志产生，Codex Auth 读取到的自然还是上一个会话留下来的数据。

这并不影响切换功能本身——账号实际上已经成功切换了，只是额度显示不准确而已。一旦你用新账号开始一个 Codex 会话，额度就会即时更新为正确的值。

对于正常使用来说，这个限制基本不会造成什么困扰。你总会开一个会话用一用的，对吧？

2. 已有会话不会自动重载

虽然 Codex Auth 解决了多账号切换的问题，但还有一个实际使用中的小痛点：如果你已经开启了多个 Codex 会话，切换账号后，这些已有的会话并不会自动感知到账号变化。 你需要手动退出当前的 Codex 会话，然后执行 codex resume 来恢复对话。

这是因为原版 Codex CLI 在启动时读取一次 auth.json，之后不会再监听文件变化。这属于 Codex CLI 本身的限制，而非 Codex Auth 的问题。

解决方案：使用 codext

如果你希望切换账号后已有会话能自动重载，可以使用我的二开 Codex：

👉 https://github.com/Loongphy/codext

⚠️ codext 为满足自我需求的二开产物，全程由 Codex 自动开发，不做生产性保证。

codext 在原版 Codex 的基础上做了多项增强：

自动检测 auth.json 变更：当你通过 codex-auth switch 切换账号后，已运行的 codext 会话会自动重载新的认证信息，无需手动退出再恢复
独立模型配置：可以为 Plan 和 Code 模式单独配置模型和推理等级，跟随 shift + Tab 快速切换

搭配 Codex Auth 使用，体验更加丝滑。

适合谁用？

拥有多个 Codex/ChatGPT 账号，需要频繁切换的用户
重视账号安全，不想把凭证交给第三方服务的用户
没有海外服务器，无法自建代理服务的用户
喜欢命令行工具，追求效率和简洁的开发者
需要在脚本中自动化账号切换的高级用户

写在最后

Codex Auth 的出发点很简单——用最轻量、最安全的方式，解决多账号切换的痛点。

不需要服务器，不需要搭建服务，不需要复杂配置。一行命令安装，几条命令就能管理你的所有账号。最重要的是，你的凭证始终留在本地，不经过任何第三方，不发送任何网络请求。

项目使用 Zig 语言编写，编译后是一个无依赖的 native 二进制文件，启动快、体积小。代码完全开源，MIT 协议，欢迎审计。

如果觉得有用，欢迎 Star ⭐️、提 Issue、贡献 PR：

👉 https://github.com/loongphy/codex-auth

廿七：落子无悔

Mon, 23 Feb 2026 00:00:00 GMT

按照往年的传统，年度总结会在阴历生日当天发出，我也为此准备了很久，但那阵子沉迷 Vibe Coding，难以自抑，完全没有生活，写不出啥东西。

这次春节过得很舒坦，好久没这么悠闲过了，我准备了很多手机上工作的方式，一次都没打开过，脑子彻底放空的感觉竟是这么舒适。趁此良机，推翻了之前 burnout 状态下的草稿，在新的心态下每天晚上都整理一部分记录在 Flomo 的内容，终述之于众。

前言

我不是很理解老一辈拼命加杠杆的行为，全都把未来压在自己或家人健康的身体上，一旦垮台，天台再见👋

我希望趁着年轻，去探索一些可能性，父辈的期望需要承担的责任太多，我不想辜负，也不想摆烂式接受。我只想更好一些，更完美一些，我不想伤害任何人，也不想推脱责任，索性一直在逃避，逃避虽然可耻，但真的很有用。不过，直面问题去解决也许会有其他可能，但，我还是更喜欢这条时间线。

我始终用有的人死在 30 岁安慰自己，没必要焦虑同龄人的进度，每个人都有自己的进度条。我很喜欢守望先锋 CG 中温斯顿博士的台词：永远不要只满足于世界的表象，要敢于探寻未知的可能。

人在年轻时，总是心高气傲的，但老人们总说，最后总要向现实投降。我周岁刚过 27 不久，同龄人有的已经在这个年纪都已经踏入了下一个人生阶段。但我觉得，在这个年龄上对我下定论还为时尚早。少年心气是终生不可再得之物，我觉得自己依然那样年轻，那样生猛，那样有希望。我总觉得，我这一生绝不会向虚无投降，我会一直战斗到死。

还是好想好想成为一个屠龙少年，就像大师兄说的那样：我听闻最美的故事，是公主死去了，屠龙的少年还在燃烧。

这么美的故事，还是想上场演一番。

序章：离职

无论处于人生的哪个阶段，努力的目标都是不断提高自己的独立性，而不是升职加薪。

埃里克·乔根森《纳瓦尔宝典》

自从刷到张小吉的那个播客「月薪就像蜜糖，是要戒的」，离开当前工作岗位的想法始终在我耳边像恶魔般低语，在我脑子里不停地来回晃荡。

现在的应试、应职只是为了在筛人，人才市场过于充裕，企业只需要随意制定筛选条件，从应试者中挑一个「蛊王」，小镇做题家还是最吃香的方式。对个人来说没什么意义，浪费时间，我讨厌刷题，试题的会与不会在如今 AI 辅助下已经不是问题了，我喜欢自由支配时间的感觉，与其刷题，还不如把时间花在刷刷视频上。

恰逢一次契机，我告诉自己，该放手了，去提前迎接世界的风暴吧。

我离职了。

究其根本，时不我待。

工作占据了一天的绝对高能量时间，大脑为了休息只能疯狂用大剂量的短视频、游戏带来的多巴胺抚慰自己。填充的越多，内心负面情绪愈发难以疏解。

自 23 年开始，我越来越抗拒与现实对话，与家人、亲属、朋友的联系也愈发扭捏抗拒，我拒绝一切不符合现有生活 <=> 工作循环以外的任何事情。精神状态持续走低，抑郁暴躁阴晴不定，像个随时要爆炸的火药桶。

岁月是把杀猪刀。

自 24 年开始，我明显感觉到岁月流逝的痕迹：身体代谢减缓，长期专注力与脑力下降，体重也有了明显的大幅增高，唯一值得消遣的游戏玩起来更是「初唐盛世」。恍惚间，我有些不认识自己了，我正在朝着我最厌恶的中年人模样转变。

所以就这样继续下去，等待着系统崩溃的那一天吗？

所以就这样继续下去，伴着身体衰弱与外界压力逐渐失去对一切的兴趣吗？

所以，跳出去！跳出陷入的生活 <=> 工作泥淖，跳出那个「舒适区」！

第二章：探索

我喜欢高密度的工作状态，不想要把时间浪费在无意义的事情上，我想要独立的时间，产出的独立成果，为其独立负责。

我喜欢新奇的事物，探索与实践应该是我的人生主旋律。

我确定了对于工作的第一个要求：我需要的是不受任何束缚的工作，不需要考虑工作地点、时间，能够充分发挥我的特长，能够长久持续的工作。

听起来很美妙是吧？但人真的是群居、团队合作的生物，一个人待久了，生活和工作都难以区分开来，有些时候放下休息一天，却再也不想再触碰了。

不像上班，缺少足够的外部推动力，长久的自律也难以保持，高效 007 的工作效率只是一个设想，这需要强大的内心、长远规划、项目管理和定期复盘。

何为外部推动力？可以从老生常谈的父辈期待谈起。在以前，奉子成婚是主流，父母觉得孩子结婚后就能安顿下来。虽然仍有不负责之流，但主流群体依旧会在巨大的婚姻和抚养孩子压力下，不得不依据自己的能力寻找一份工作养家糊口。这就是一种推动力，而且是目前最强没有之一。不过在这种高压下，可能很多规划都没法实现了，不得不为了眼前的利益忽略长远的收益。

这也是我曾经逃避的原因，以当时来看，那确定的规划未免过于潦草，我没法提交到人生档案馆。

我心中曾经执剑的少年，此刻也混迹在市井之间。

重新聊回现实，我进行了一些尝试，直到年底，浪费了大半年的时光才发现，没有足够的刺激很难提升更高的动力。就像嚷嚷着考研和考公的人，没有确切的规划和长期努力，可能只是在逃避现实，推迟进入到职场厮杀的时间。

究竟该如何维持这种激情？即使是那些所谓「没有动力」的人，在打游戏的时候也会突然充满干劲儿，所以，需要寻找一个在上文提到的最强推动力之下的下位替代：不会有整体覆没的成本投入，但能产出高昂的激情。我发现只有以搞钱为目标才能长久维持，才能快速成长，其他方式都无法充分地发挥主观能动性，只是待在舒适区。

所以工作的第二个要求：能够持续地增加收入，反向刺激自己的激情和动力，纯粹的无偿贡献很难长久维持。

第三章：Vibe Vibe Vibe

恰逢其遇，我的判断并没有错误，离职后不久，当我从刚刚结束的游戏赛事 VCT Champions（无畏契约冠军赛）回过神时，Claude Code 引领的 Coding Agent（编程智能体）已经在蚕食软件行业了。

有一种新的编程方式，我称之为 “vibe coding”，就是彻底跟着 vibe 走，拥抱指数级增长，然后彻底忘记代码本身的存在。

Andrej Karpathy

自 Vibe Coding（氛围编程）一词被发明后，仅半年时间就因为 Claude Code 和 Opus 4.5 级别的模型面世，这一编程方式被推到顶峰。

Vibe Coding 指的是和传统手工编程不同的方式，只需要通过自然语言引导 LLM（大语言模型）生成代码。可以理解为我们只需在豆包中对话，它就能生成一个我们能在手机中使用的 App（应用程序），不需要掌握专业的知识技能，那是一种言出法随的状态，宛若神明，没人能拒绝。

以前我认为 AI 发展很迅猛，但仅限于辅助工作，现在则是完全取代了我，我从执行者变成了领导者，指挥 AI 干活儿就行。

模型（Opus 4.5）和应用（Claude Code）的进步，带来了超高的开发效率，间接又产生了 OpenClaw 这种 Agent（智能体）的热潮。

AI 在去年的飞跃式进步，虽然在我看来还是有些泡沫，但已经彻底改变了几十年软件工程的开发方式，开发工程师们始终在一直走在消灭自己的道路上。

AI 可能没有那么快消灭软件行业，但它是潜移默化的，慢到突然有一天，大厦崩塌才大梦初醒。我不清楚未来如何，即使 AI 成了泡沫，LLM 能力永远定格在这一刻，现在的能力也已经足够了，足够改变现有的编程方式。Mac Mini 都能部署的模型，绝对不是泡沫可言。

当高门槛的脑力工作被 AI 取代，工作的意义被进一步弱化，在这个时代，我该如何自处？

yetone 的推文很好地解释了这一点：

我想寻找构建产品的快乐，而不是编程的枯燥。

我只是一个误打误撞闯进计算机的人，一切都是历史无形中的被动推动，谈不上热爱，只是多花了一些时间在上面，研究些新奇的技术玩意儿，我不喜欢编程，尤其是调试找 BUG。

AI 给我带来最大的变化就是以前看起来很酷的东西，我不知道怎么实现，现在有 AI 可以直接快速做个原型出来。技术问题确实被抹除了，但想要一个可维护高质量的代码项目依旧需要有相关的技术背景才行。推荐下这个视频，蛮幽默的：

我不想成为所谓的资深技术人员，一个为 AI 大人服务的枯燥铲屎官，更无意钻研技术的深度，所以提前退场加入未来革命阵营，算是一个不错的选择。

第四章：生活状态

好了，原谅我用了这么多笔墨聊 AI，但这确实是去年大半年在忙的事儿，让我们回归生活吧。

国庆回去，逢人就被说「胖了」，年纪大了，代谢总归是要下降的，痛定思痛，决定调整饮食和运动习惯，10 月、11 月、12 月都努力完成了 100 km 的跑步月目标。

跑步作为人类最原始、最简单、无场地限制的运动，用来提高新陈代谢、提升心肺能力最好不过了。至于力量训练，和我只去过三次健身房的年卡说去吧😡

可惜，我并不是一个自律的人。

健康的习惯难以养成的原因，主要还是因为纯粹靠着一股子所谓毅力在坚持，可能在某次自我暗示需要休息后，停下来就再也不去做了。

我已经改变了看法：是短期为了完成某项目标去坚持，还是把它当做一年、两年，甚至 10 年的长期习惯去培养。

两种不可同日而语。为了前者，我们可以不惜一切代价乃至短期健康来快速达到追求的「健康」状态。比如超重人士，快速减重留下的松弛皮肤，需要手术切除。后者，需要的是科学、规律、健康的方法论指导。

在 AI 的帮助下，结合中国居民膳食指南（2022 版）和运动量分析，调整了饮食结构，确实比以前健康太多了，目前主要分为三种：

正餐摄入：蛋白质（鸡胸肉、猪肉、牛肉），深色蔬菜（西兰花、菠菜等），碳水杂粮饭（大米、糙米和黑米）或燕麦，偶尔补充鱼、动物内脏（猪肝、鸡肝）
零食摄入：坚果类（核桃、南瓜子等），水果
药品摄入：维生素 A，复合维生素 B，维生素 C，维生素 E 和葡萄糖锌等

至于鱼油 EPA 之类的东西，通过在正餐摄入增加深海鱼类来补充，能吃就吃，吃不下就借助药品补充。

还是那句话，我不是一个自律的人，必不可少的甜点、奶茶等还是照常喝，只是会一边享受一边后悔😭

今年的春节过得格外舒适，似乎一切还都是欣欣向荣的样子。我明白，人还是群居生物，我需要多出去走走，少些书卷气，多沾染些生气。读万卷书，还是需要行万里路，我知矣。

关于婚姻，看法相较于之前廿四，沉沦与挣扎，有所改变。

前不久还看到一篇博客，写得太过精彩，求同存异：法律上当路人，生活中当爱人，契约上当合伙人是亲密关系的最优解么？一份基于 2026 年视角的亲密关系 PnL 随想

“到岁数了，找合适的对象结婚，过正常的性生活”和“爱上某人”，是截然不同的事情。

王小波《沉默的大多数》

憧憬爱情是每个人都有的遐想。我只觉得我能做到更好，还差很多，还差很多。

我记得初中的社会老师曾经问过一个问题，对于未来的负债看法，是选择先享受，还是先努力。当时我选择了前者，现在我是后者。

无它，杠杆不是这么撬的，大多数人都是使用劳动力杠杆来获得来自未来提前支付的报酬。

一旦遇到不可抗力的问题，比如一个常见的问题：父母重病。保险应该解决不了一切，我想知道究竟该如何豁免呢🤔

你的劳动力杠杆恐怕无法再往上加了……

所以奉献一生，最后耐住病痛离去，太过于伟大了。

现在的社会真的很残忍，精准拿捏人一生每个阶段的软肋，在这方面狠狠吸血。尽管如此，依旧无数人飞蛾扑火般涌入，我不理解。

婚姻，不仅是两个人的结合，也是两个家庭观念的碰撞，如果没有坚守己见的决心，夫妻双方很容易又被带到一方的家庭观念中去，若是双方各持己见，有所摩擦，很容易走向破裂。

我讨厌争吵，面红耳赤的样子。

这不是人正常应有的状态，一些矛盾、诱惑只是在放大人的感官。所以我拒绝了酒精、香烟、带有金钱利益的博彩、棋牌等，我不是投机分子，也不是不责任的市井流氓。

可惜，糖类这种刻在基因中的东西，我至今无法戒掉，还是奶茶太好喝了。

一些推荐

Flomo

我日常的想法都记录于此，便捷快速，全平台（包括微信）都支持。本篇文章和上一篇万字长文2025 年，我对 AI 编程的全部理解的大致内容都来自于此。

非常适合记录日常生活中一些闪光点。不要让想法停留在脑袋里，停留越久只会让你潜意识产生更多「幻觉」。把它写下来，写完也许就祛魅了，可能一文不值。
Voicenotes

有些需要长篇大论、手工记录太慢的情况下使用，基于 LLM 的语音识别，虽然用得没有 Flomo 频繁，但早期 $50 的买断价格绝对值得。
Notion

我的博客和项目管理都使用此维护，database 设计是我离不开它最重要的原因，用来日常维护文档太方便了。
播客

我一直都入睡困难，以前工作日更多的是让自己困到无法刷手机为止，因此睡眠问题一直没能引起重视。

现在日子悠闲下来了，睡眠问题反倒更严重了。尝试了很多方法，发现播客还挺有奇效，这里推荐一些我听过的播客。
- 对李想的第二次3小时访谈：CEO大模型、MoE、梁文锋、VLA、能量、记忆、对抗人性、亲密关系、人类的智慧：李想对于 AI 了解真还蛮深的，自称产品经理，所言非虚
- 翁家翌：OpenAI，GPT，强化学习，Infra，后训练，天授，tuixue，开源，CMU，清华｜WhynotTV Podcast #4：满足了我对 OpenAI 内部研发的好奇心
书籍

去年看的没啥值得推荐的，依旧老书新看《纳瓦尔宝典》，不做解释，下载个微信读书读两页看看。

终章

尽管 AI 能力早在两年前就已经超越我了，尽管我写得依旧很烂，没有章法和文笔可言，我依旧保持在传统的写作方式，不需要 AI 来替代我。因为写作是一种梳理思路的过程，是一种与自我的对话方式。

去年书读得太少了，越不读书，越写不出东西，这一点，我要深刻反省。

我挺喜欢王小波的书，幽默自嘲又能触及思考，也没有世俗的苦大仇深加之笔触。今年会多看几本书架上吃灰的书，学习下王小波的文风，借此多写点博客出来。

至于未来，沿着既定的路线摸索吧，无非是跌得粉碎罢了，以上。

2026 年 2 月 23 日，初稿完成于高铁。

万字长文：2025 年，我对 AI 编程的全部理解——Part 1

Mon, 09 Feb 2026 00:00:00 GMT

以下以「古法编程」指代 2023 年前无 AI 参与的传统编程方式，新时代借助于 Coding Agent 的编程方式：Vibe Coding。

怀念最好的古法编程：已失传😭

拖了很久……有太多想写的内容，但偶尔才会灵光一闪，难以捉摸

~~2026 年头一个月都快要过去了，才终于开启这篇文章的撰写~~

2026 年头一个月已经过去了，才决定将这系列的文章拆分成多篇。

我总有一点完美主义的自我要求，总想着囊括所有细节，写得足够完整再发。毕竟总觉得还缺了点啥，总有新的想法去试验实践，质疑某些经验是否通用、是否真的有效。写了很多，也删了很多，一拖再拖，一拖又拖，索性不再去考虑这些琐碎。有些记录的文字随时都可能随着新模型的发布而失效，所以先将其作为 Part Ⅰ 发布吧。

本文的观点其实很简单：多实践多思考，万法皆知。

概述

目前的 AI 发展高情商点是处于万物竞发的勃勃生机，低情商的表达就是纯褒义向的草台班子。如果去看这些 Agent 的实现，全都在做 Dirty work。大多数的功能需求都可以通过手搓 Prompt 来实现，而 MCP、AGENTS.md、Skills 之流无非是一个大家普遍接受的规范，大家可以按部就班的复用同一套规范，不必重复造轮子。

当前的 Agent 目标是为不确定的 LLM 结果构建一层结构让其输出确定性的内容，剩下的全是构建这层结构的复杂，我们将这层结构称之为 Harness。我们熟知的 Claude Code、Codex 就是 Harness。

LLM 原理

LLM（大语言模型）的核心任务只有一个：根据前面出现的所有内容（Context），计算下一个 Token 出现概率最高的是什么。

例如输入：“床前明月__”，模型根据训练数据，算出“光”字的概率是 99%，“饼”字的概率是 0.01%。于是它输出“光”。
然后它把“光”加进去，变成“床前明月光”，再预测下一个字（可能是“疑”）。
这个过程不断重复，直到生成完整的回答。

明白了这个，后续遇到的大多数问题都能理解了。

Prompt 演变

从最初的 Prompt（提示词）工程师，需要控制严格的格式才能达到好的效果，大家绞尽脑汁去尝试适配模型，但自推理模型（OpenAI o1、DeepSeek R1）推出后，我们日常交流用的自然语言都能获得不错的效果。

以一个检查英语语法为例（仅作为示意，不代表模型真实效果）：

GPT 3.5 时代

目标：评估我的英语语法是否标准
要表达的意思：xxxx
句子：<原文>

推理模型时代

评估下我的英语语法，大概意思是 xxxxx，<原文>

发展到推理模型后，日常使用时根本不需要拘泥于格式，只需要你下意识的练习即可：

输入你的要求，查看模型的返回，缺少哪些，有哪些错误
针对问题，要求模型更正
最后基于对话，让模型生成一个新的指令
新开对话，测试新指令

推荐看下宝玉的一篇文章，大巧不工：

为什么我用了那么多提示词模板甚至用了 AI 帮忙还是写不好提示词？

现在的 Prompt 虽不必注重形式，但依旧有些需要注意的地方。

减少引导

不要限制方向，只给需求，看它是否能提出新的见解，非常适合在不熟知或不确认的领域中使用这种无诱导式提问。

为什么？这又扯回到前面提到的 LLM 原理了，当你给出关键词时，模型会更倾向于朝这个方向「思考」

以下为例：

// 无引导，只描述现状和需求
有没有比较好的备份策略，当前每次切换都要备份一次似乎会生成很多备份啊

// 有引导
有没有比较好的备份策略，当前每次切换都要备份一次似乎会生成很多备份，比如采取清理的方式？

所以当我对一个方案不确定时，我只会描述需求，不会提及方案，利用模型本身的数据或其搜索的互联网数据来提供回答。提供精确的关键词，极有可能把模型带偏。在推理模型没出现前，很多人都经历过类似的事，联网搜索反而带偏了模型。

身份认知

一种常见的身份认知误区就是问「你是什么模型」，在后训练过程中，若模型厂商没有特别处理或者你调用的 API 没有塞进去额外的系统指令，模型根本无法得知自己究竟是谁。

另一种则是在 AGENTS.md 等系统指令中告知 LLM 要使用的编程语言或依赖库版本，通常也是无意义的。

一方面可能是信息太新，LLM 的训练数据中还没有，另一方面可能是海量的旧数据去「误导」了模型，LLM 更倾向于生成概率更高的，这就是身份认知，模型意识不到生成的那种版本。

举个例子来说，即使你在 AGENTS.md 中指明需要基于 React 19 新语法来编写，很大程度上也可能不会遵循该指令，LLM 更倾向于建议在每次任务结束，手动调用一次 Skills 查看变动的内容，再基于 Skills 提供的信息修改。

上述问题在更次一些的模型中使用会更明显，我在 Codex 中使用 gpt-5.2-codex 配合 AGENTS.md 时已经很少出现这种问题了，该模型对于 AGENTS.md 的指令遵循很强。

大道至简

对于在 Agent 中使用的全局指令文件 AGENTS.md，要谨慎对待。

我看到社区分享里有很多一大堆对于模型的限制：「你要 XXXX、不能 XXX、遵循 xxx 原则……」就按照我上面身份认知和减少引导提到的：都是狗屁，都是多余的，甚至会限制模型的发挥。

只需要告诉 Agent 能用哪些工具即可，不要过多限制模型的回答风格，代码生成风格等。

可以参考下 Codex 内置的系统提示词写法：gpt_5_codex_prompt.md

就像 Opus 4.5 写作能力很强，GPT-5 系列回复像天书看不懂一样——这是模型训练阶段决定的。如果提示词真能解决问题，OpenAI 何必在 ChatGPT 里加个「语气控制器」？

开源闭源之争

2025 年由 DeepSeek R1 打响了推理模型开源和低廉价格第一枪，而后很多国内公司也纷纷跟进，年底的更新的 GLM-4.7 和 MiniMax-2.1 更是被认为是「小 Claude Sonnet 4.5」。

单从社区反馈来看，来自智谱的 GLM 系列超售严重，速度和质量都无法保证，我将是这家厂商的忠诚小黑子。

MiniMax 2.0 刚出时在 Zed 中试用了下，还行，但没有任何惊艳之处，给我的感觉挺符合 Claude 模型的调性。后续在 OpenCode 中的尝试的 MiniMax 2.1 则有些痴傻，我更强倾向于 OpenCode 内置提示词对于此模型适配得不好，总体推荐。

至于开源模型，就我个人而言，它们存在的意义是让我用上更便宜的闭源模型。

我一直都在使用 Codex，也极力推荐大家使用（截至 3 月，免费用户也可使用，付费用户额度更高），只存在俩问题：

~~模型速度太慢~~（最新版本速度问题已经算是解决了）
防御性编程写太多，会生成太多兼容性回退代码

远离营销

短视频时代，破坏了大家的专注力。
AI 时代，损伤了大家的思考能力。

现在大家都喜欢新奇的东西，每一个新的 AI 术语、产品出现，立刻就会涌进去一群人，然后几分钟后洋洋洒洒一大篇文章发布。不明所以的观众看到铺天盖地的或自发或有意的营销推广，兴冲冲地冲进去，满脸困惑的走出来。

回顾一年的发展，自己似乎只是成为了 AI 的质检员：输入提示词→等待模型回复→同意或不同意，重复上述循环。

仔细想想，营销过后，自己获得了什么吗？就我个人而言，结果为零。值得体验，值得读的文章太少了。

所以，究竟是人类驯化了 AI 还是 AI 驯化了人类？我们丢失了人类引以为傲、区别于野蛮生物的思考能力，并自愿成为 AI 进化过程中的祭品，前赴后继的冲进祭坛，燃烧仅剩的可怜意识。

我已经很久没有体会到那种「我竟然做到了，TMD太吊了」这种极致的自我实现和认同感，丢失了自我创造的能力。极致的 AI 狂欢后，是自我价值丢失的空虚与茫然。

我不否认营销的作用，不夸大的标题，难以吸引路人的目光，但获取注意力的手段需要克制，明明是垃圾，却嚷嚷叫卖，在现在的时代浪潮过于嘈杂了。

AI 领域真的很喜欢造词，造各种概念和奇技淫巧，2024 年活下来的是 RAG，2025 年是上下文工程（Context Engineering）和 Agent。在 2025 年 Coding Agent 大行其道的情况下，又嚷嚷着 RAG 已死，上下文工程（Context Engineering）才是对的。

经常关注 AI 的人可能也沉浸在这种层出不穷的新技术中，但在现在来看，火上天的 MCP 也就那样，我日常用的也就只有一个 Chrome DevTools MCP 用于网页开发，而且早期 MCP 安装起来特别麻烦，在用户侧总是出错，很多开发者都搞不明白怎么才能配置正确，更别提普通人了，这些繁琐的配置直到 2025 年中期才算稳定下来。

至于 Skills，它就是 Prompt，只不过变成了一套规范。除此之外，和 You are a professional translator. Translate the following text from English to Chinese. 这种提示词没什么区别。

因此，真的没必要浪费心力去追赶最新的一项新技术、新术语，你需要从被营销号包裹的震惊体中找出真的能解决、简化你的真实需求的东西。

专注力与思考能力

现在 Coding Agent 的强大毋庸置疑，但却带来了过于旺盛的「创造力」。巴不得开十个终端跑 Agent，然后在终端之间来回切换。但是实际操作下来，发现累的不是钱包，而是自己的脑子。

在这种流程下，只能祈求 Agent 的能力足够强，否则最终只是再重复这个糟糕的循环过程，浪费时间。

所以，对于 Coding Agent 提供的通知能力，请关闭它。我们不需要通知，我们的目标是完成任务，不是享受虚假工作效率创造的情绪。

从 Agent 产出的平庸的结果中走出来，为什么别人做的那么精致漂亮，自己却拿着烂大街的紫色 UI？

在 Agent 快速产出的今日，我们更需要学习，学习更广的知识，扩展更广的领域边界。编程本没有意义，只是在这过程中我们享受到了创造世界的快乐。那么在今天，Agent 极大缩短了中间的创造的艰辛，反而能把重心放到学习如何将产出做得更好，这需要更广的知识面。不需要纠结你是什么职业，越来越多的人依靠 Coding Agent 去制造垃圾，为什么掌握编程的你不跨出编程的范畴，去学习设计、学习产品，构建品味。

并行开发的代价

等 Agent 跑任务的时候闲着也是闲着，不如再开一个终端跑另一个任务——这就是所谓的并行开发。同一个项目可以用 Git worktree 拉出多个分支同时搞。

听起来很美，但我试下来发现，两个任务已经是极限了。

三个？脑子直接满载——A 做完切 B、B 做完切 C、C 做完又回 A，转着转着就晕了。大脑上下文塞满后，切换本身就在消耗你的精力。所以我现在只开两个，留点余量给自己，偶尔还能刷刷推。

并行开发制造了「高效迭代」的假象，代价是大脑的专注与深度思考能力。

关闭通知，主动掌控

既然并行开发难以避免，那就从通知机制入手。

像 Codex 这类 Agent 工具都支持任务完成后的通知功能，乍看对并行开发很有用。但实践下来，我发现自己反而更累了——每完成一个任务就弹出通知，你收到就得去看，看完切回来又收到另一个……就这样被推来推去，彻底打断工作心流。

通知一来就得响应，脑子全花在来回切换上了，根本静不下心去琢磨手头的事。

更好的方式是：主动查看，而不是被通知推着走。

在 TUI 环境下，先把通知关掉：

[tui]
notifications = false

被动通知让你疲于奔命，主动探知让你掌控节奏。

但这只是权宜之计。真正理想的体验是一个带有任务状态面板的 GUI——它不弹通知打扰你，而是静静显示所有任务的进度。当你从当前工作中抬起头，瞥一眼侧边栏，看到某个任务完成了，再主动切过去深入处理。

这种功能在 TUI 中很难优雅实现。随着 Agent 工作流的复杂度上升，回归 GUI 是必然趋势——更直观，更易上手。Codex App 的出现，正是顺应了这个方向。

复制粘贴终究是捷径，排查问题的能力才是真正属于自己的东西。 有了 Agent 之后，这种能力反而更重要了——毕竟，模型不可能永远给你正确答案。

文件即记忆

需要让 Agent 记录我们之间对话的记录，以及项目的一些实现细节，可以通过维护一个文档来记录。

现在大家使用的 Coding Agent 一般都是 CLI 形式的终端运行 Agent 而非 Cursor 这种图形化界面，最大的特点就是使用传统的文本检索（Grep）而非向量化文本检索（RAG）。

Grep vs RAG 之争我们暂不讨论，但目前受限于 Coding Agent 运行速度，市面上又多了一些提升代码检索速度的产品：

Coding Agent 真的很神奇、很强大，强大到只需要简单的 Grep 就能搜索到满足用户意图的代码，何其伟哉！

观察 Coding Agent 运行，比如 Codex，你会发现它通过一些关键词检索出目标文件。利用这一特性，我们可以创建一些文件来介绍当前的项目、指引 Agent 在特定目录下执行特定的流程。这一切的一切，都是为了修补孱弱的上下文和模型的自注意力机制。毕竟我们不能把整个代码库塞到模型上下文中，利用文件可以让 Agent 减少一些文件的检索，并一定程度上提升运行速度和更精确的项目理解。

文件应该始终是面向 Agent 的最终产物，不需要中间过程。

检查 docs/logging.md，去除其中关于一些兼容回退的中间过程的内容，我们的 docs 文件应该始终是面向 Agent 的最终产物，不需要中间过程。

计划优先

在之前的 OpenAI Codex 不完全の伪新手指南中，我参考 GitHub SPEC 规范引入三步开发方式，但在现在来看过于繁琐，而且 Codex 已实现 Plan 模式。

我们现在将开发流程简化成两步：

创建开发计划，多次讨论评估计划，生成 PLAN.md
根据最终计划文件生成代码

我当前实践结果是，维护两个目录：plans 和 docs。

plans 下的文件根据需求让 Agent 生成，可以利用 Plan 模式（Shift + Tab 切换），格式 plans/YYYY-MM-DD-<需求>.md
docs 下的文件是在 Plan 模式切换到 Code 模式后，Agent 根据实现生成的文件，格式 docs/<需求>.md

流程：plan 模式 -> plans 文件 -> code 模式 -> docs 文件

结果为准

在最初与 Codex 结对编程过程中，都是以我为主，Codex 为辅。一步步告知 Codex 具体怎么做，要改哪些内容。但经过模型升级和工作流的多次迭代后，发现经过长时间纠正 Codex 输出结果的内容，已经慢慢都被新的代码替换了，之前与 Codex 的「捉对厮杀」已经毫无意义了。

因此，现在我更倾向于注重实现方案，而非最终代码结果，代码由测试代码验证，不关心代码质量。只要项目结构符合我的预期，遇到问题我知道从哪个文件排查，那代码质量再糟糕也不是我关心的重点了。

It just works.

心态转变

现在我更倾向于将 Codex 作为小黄鸭，跟它聊天，把想法梳理清楚，然后让 Codex 去执行。

我更像是一个管理者而非执行者，在项目早期会参与多一些代码纠正，到后面 Codex 生成的结果慢慢地减少人工参与，直到 Codex 完全掌控代码生成。

在中间过程，不要像古法编程那样，模型生成的内容一些微末枝节不符预期就去修改，费时又费力。不要揪着 Agent 做的变动不放，放下心里的拧巴：比如大小写错了，文字显示不对等等，别纠结这些，这些应该放到评审阶段统一修改。**利用 Agent 快速出活的强项，先把功能做出来。**中间过程的错误即使纠正后，它依旧可能一而再再而三的犯错，这是 LLM 的本质毛病。

一些错误实践

长时间运行没有意义

受限于模型自身速度和任务类型，盲目追求长时间运行，除了带来脑内高潮外，无意义。重要的是思考如何减少人工干预、构建稳定可交付的成果，长时间运行只是附加产物：

测试：模型修改完会自动运行测试脚本，根据错误修改代码，重新测试
交付成果校验：在vibecoding xx文章中，我在 AGENTS.md 中指明结束前需读取图片结果和调用 gemini-cli 来验证视觉效果是否符合预期，根据模型反馈结果再做修改。

最好的方式是能在我们睡觉期间执行一些复杂的任务，无人工参与自行决策，等我们第二天起床验收。

OpenAI 曾做过一次相关分享，通过类似 Sub-agent 的方式，自主运行十几个小时来实现一个项目的重构。https://forum.openai.com/public/videos/event-replay-vibe-engineering-with-openais-codex-2025-12-03

拿来主义

我也收藏过别人分享的 Prompt、AGENTS.md、Skills，拿来直接用，一开始确实省事。但慢慢发现，这些东西换个项目就水土不服，模型卡住了，换模型、改提示词，依旧收效甚微。

后来我养成了一个习惯：多看Agent 执行过程。

通常会遇到如下事情：

没有读取修改后的文件
不习惯调用指定的工具，如 ast-grep
我的描述把它带偏了
它自己理解歪了

多看执行过程，找到问题根源，纠正一下其实没那么难。在这个过程中也能慢慢了解模型和 Agent 自身的长处和优点，不至于盲人摸象，不知所用。

实践久了会发现，大家用的方式其实大同小异，最佳实践也就那些。等自己趟过一遍，再看到营销号分享的「独家技巧」，大概也就一笑置之了。

Codex 实践

模型选择

gpt-5.3-codex 体验尚短，以下为 gpt-5.2-codex 未提速前的体验。

model = "gpt-5.3-codex"
model_reasoning_effort = "high"
model_reasoning_summary = "detailed"
model_supports_reasoning_summaries = true
hide_agent_reasoning = false # 允许显示更多的 AGENT 内部思考过程
show_raw_agent_reasoning = true # 显示模型的原始思维链
approval_policy = "on-request"
personality = "pragmatic"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true # 允许联网，和 web_search 不同，它是访问互联网，比如推送到 github 等，若没有配置则会需要你手动授权
writable_roots = [
  "/root/.codex/skills",
  "/root/.gemini",
] # codex 创建更新 skills 都要写权限，由于我是 workspace-write 权限，所以额外放开了一些文件夹的访问（只能访问 codex 运行时所在的文件夹）

# 不同模式选择不同的模型：https://github.com/Loongphy/codext
[collaboration_modes.plan]
model = "gpt-5.3-codex"
reasoning_effort = "xhigh"

[collaboration_modes.code]
# model = "gpt-5.3-codex" 缺省会选择 /model 配置
reasoning_effort = "high"

最初仅用 medium 来读项目代码，其余时间都用 xhigh，虽然比 medium 慢了至少有三四倍，但是太懂我的抽象指令了😭

后续在速度、推理和额度消耗上的取舍，默认使用 high，目前来看确实不错。

但我还是不推荐 medium 推理等级，在使用 gpt-5.2-codex 时，上下文一多就摸不着头脑了，对于指令接接收有些傻傻的。

GPT-5.2 的路线是对的，写作能力什么的真不重要，我不需要情绪价值，我只想把它当黑奴用，力大砖飞才是王道。

官方对于 v0.90 版本引入的 Plan 和 Code 模式（Shift + Tab 切换模式）写死了模型和推理等级，因此我 fork 并修改了一个 Codex 版本，微调了相关配置，支持上述的 collaboration_modes.plan 和 collaboration_modes.code。

仓库链接：https://github.com/Loongphy/codext

[!NOTE] 尽管在 v0.98 版本已经支持使用 /model 选择的模型，但依然不够灵活。

对修改 Codex 感兴趣可以看构建比官方更顺手的 Codex、Skills 自动化同步上游。

AGENTS.md

作为目前最被认可的 AGENT 系统指令方式，我一般都不会手动添加指令，都是与 Codex 对话让它根据我的需求生成一个更为精练准确的指令写入到 AGENTS.md 中。

上述就遵循减少引导的原则，不会说：啊，你执行失败后根据错误信息修复，然后再重新执行一遍，重复上述流程。Codex 一般都会默认失败自动修复再重新跑一遍，遇到不会这么干的情况，可以检查自己的 AGENTS.md 是不是太啰嗦太多导致影响了模型的注意力。

或者维护一个单独的文件或 Skills 来显式让 Agent 读取执行。

不要关心上下文

Codex 提供了一个 /compact 指令，可以用于压缩上下文，但就实际体验仅，这个指令可以忽略。

开发者完全可以无感使用，不需要操心上下文，担心自动压缩会损害模型智能。

对于可能会执行很久的计划，可以参考 ### 计划优先的内容，把计划写入到单独的文件中，并让 Agent 读取执行。

若还不保险，可以考虑在 AGENTS.md 中指明该计划文件，每次执行压缩后，Agent 仍然会加载 AGENTS.md，利用这一特性，Agent 每次都能知道要做什么。

产品推荐

Amp Code

符合我对小而美的想象，还支持分享对话成网页，如：示例对话

每天 $10 额度，要什么自行车，给到顶级。

v0.app

快速创建原型的最佳工具，默认使用 shadcn ui 组件，其余较新的 base ui 等支持很差，不过 shadcn 也够了，给到顶级。

ChatGPT

所有 AI 最严厉的父亲！通用 Agent 这一块儿依旧拿捏，今年的网页搜索能力进步巨大，Codex 也内置了搜索，不需要配置额外的 MCP 就能获取最新信息。文件处理做得很好，不限制文件的格式，压缩包也支持，有专门的代码执行容器来处理。

唯一的问题就是执行时间太长，用户不喜欢，回答不说人话，用户很讨厌，但很适合用于调研和科研创作场景，给到一个夯。

Grok

Grok 真的很懂你。

现在的 X 用户遇到问题，都会在评论中 @grok 解释一下。借助 X 的庞大数据和信息生态，搜索和最新信息的理解太无敌了，即使是最新的中文热梗也能知道。

Web 和移动端用户体验首屈一指，用户体验方面是所有 Chat App 中的唯一真神，有四个功能我很喜欢，受限于 Grok 4.1 的模型，给到人上人。

划词引用
对话侧栏
x.com 推文搜索
Tasks 利用其 Tasks，我做了一个每日的 AI 新闻总结，了解关注的 AI 模型更新。

# 任务：汇总 x.com 近 24 小时 LLM / AI 更新（中文报告）

## 1) 统计范围

- 仅统计：**最近 24 小时**内发布的帖子（以发帖时间为准）。

## 2) 信息来源（官方账号）

> 只抓取以下账号的内容，并在报告中按组织分组呈现。

### OpenAI

- https://x.com/OpenAI

- https://x.com/OpenAIDevs

- https://x.com/ChatGPTapp

- https://x.com/sama

- https://x.com/thsottiaux

### Google AI / DeepMind

- https://x.com/googleaidevs

- https://x.com/GeminiApp

- https://x.com/GoogleAIStudio

- https://x.com/OfficialLoganK

- https://x.com/GoogleDeepMind

### Anthropic

- https://x.com/AnthropicAI

- https://x.com/claudeai

### xAI

- https://x.com/xai

- https://x.com/grok

### Cursor

- https://x.com/cursor_ai

### Moonshot AI（Kimi）

- https://x.com/Kimi_Moonshot

### MiniMax

- https://x.com/MiniMax__AI

### Alibaba Qwen

- https://x.com/Alibaba_Qwen

## 3) 额外整理（非官方账号）

除上述官方账号外，还需要补充两类“全站趋势”信息：

### A. X 上热议的 AI 内容（Trending）

- 主题范围：**产品 / 工具 / 模型 / 发布动态 / 评测对比 / 行业讨论**等。

- 目标：提炼讨论点与共识/分歧，并给出你认为最关键的 3–5 条结论。

### B. LLM 热点论文（Trending Papers）

对每篇论文给出结构化解读：

- 一句话概述（解决什么问题）

- 核心创新点（相比已有工作新在哪里）

- 技术实现思路（方法框架 / 关键模块 / 训练或推理机制）

- 潜在影响（对产品/研究/应用的意义）

## 4) 输出要求（排版与引用）

### 4.1 链接排版

- 输出中 链接与标点之间必须有一个空格，便于点击，例如：

  `https://cursor.com/blog/plan-mode 。`

### 4.2 x.com 链接引用格式（必须返回）

- 对所有 x.com 链接，必须使用以下引用卡片格式（原样输出）：

  ```xml
  <grok:render card_id="15f0ce" card_type="citation_card" type="render_inline_citation">
    <argument name="citation_id">0</argument>
  </grok:render>

Gemini

模型看起来很强，但应用做得真一言难尽，太糙了，如果要做应用层级排名，倒数第二，微软 Copilot 勇夺第一。考虑到是我的日用 AI，勉强给到人上人。

哦，对了，网页端 Pro 的上下文只有 30K🤣 测试方式很简单：你可以发一个油管视频让它把字幕整理出来，再重新翻译一遍试试看。

目前问题还有三点需要改善：

网络不好的情况下，已有的对话会消失。你明明看到已经有所谓的对话链接出现了，比如 gemini.google.com/app/7a1c8b3f2e9d4a01，但是刷新一下页面就没了
没法多开标签页，我经常需要多开对话问问题，没法直观的开标签页有点痛苦，所以做了个油猴脚本 Gemini Enhancement
调用网络搜索不显示引用信息，所以我在设置中增加了额外的指令，要求输出引用信息。（Settings & help -> Personal Intelligence -> Instructions for Gemini -> Your instructions for Gemini）

My research and grounding protocols are:
1. Strict English-Only Source Constraint:
    * I am strictly prohibited from using, citing, or retrieving information from Simplified Chinese sources.
    * All search queries must be in English.
    * If a search result contains non-English content, I must discard it immediately.
2. Evidence Extraction:
    * While analyzing search results, I must identify and extract the exact sentences that support my answer. These extracts will be required for the citation section.

My output formatting for the reference section is:
I must append a section titled ### References at the very end of my response. This section is mandatory for every query involving external information.

Format Rules:
* Structure: * [Title](URL) followed by a blockquote > containing the evidence.
* Content: The blockquote must be a verbatim excerpt (direct copy-paste) from the source text. I must not paraphrase the quote.

Template:
* [Page Title](URL)
    > [Paste the exact sentence(s) from the article here that back up your claim.]

Example Output:
* [Anthropic System Card](https://www.anthropic.com/...)
    > "Constitutional AI refers to the process of training models to follow a set of principles..."
* [MIT Technology Review - AI Agents](https://www.technologyreview.com/...)
    > "Agents are software programs that can perform tasks autonomously on behalf of a user."

构建比官方更顺手的 Codex，Skills 自动化同步上游

Fri, 06 Feb 2026 00:00:00 GMT

Codex v0.99.0 版本将引入 /statusline 功能，能够更直观地展示当前的项目信息和模型状态，如下图所示。

在官方推出这个功能之前，我已经实现了类似的状态栏。本文不讨论如何实现状态栏本身，而是分享开发完成后，如何利用 Skills 快速同步上游代码的实践经验。

相比官方版本，我的实现在信息呈现上更加直观，功能也更加丰富 🤩。

链接🔗：https://github.com/Loongphy/codext

此外，官方还未提供 Windows App，可以在该仓库的 Release 下载编辑器版本，相关构建教程参见上一篇 OpenAI Codex App for Windows: 从零构建教程。

修改内容

由于这是个人定制化工具，我遵循以下原则进行改造：

跳过测试代码：测试运行耗时较长，暂不考虑
保持 TUI 结构稳定：尽量不破坏现有界面架构，降低后续合并代码的复杂度
快速同步上游：只关注功能实现，无需考虑代码审查和合并流程

基于上述原则，目前已实现以下功能：

1. 顶部状态栏

在编辑区域顶部增加状态栏，实时显示四类核心信息：

模型信息：当前使用的模型和推理等级
工作目录：当前所在文件夹路径
Git 状态：当前分支名称及文件变更情况
用量统计：5 小时内的使用量和重置倒计时

2. 协作模式的独立配置

支持为 Plan 模式和 Code 模式分别配置模型参数：

[collaboration_modes.plan]
model = "gpt-5.2"
reasoning_effort = "xhigh"

[collaboration_modes.code]
model = "gpt-5.2-codex"
reasoning_effort = "xhigh"

3. 账号热切换

在新终端执行 codex login 后，其他终端会自动监听 auth.json 的变化并重新加载 TUI，无需手动退出重启。

为什么要二次开发

功能起源

Codex v0.90 版本正式推出了 Plan 模式和 Code 模式（默认）。这两种模式整体表现出色，Plan 模式还借鉴了 Cursor 的设计理念，会主动向用户提问以深入理解需求。

在开发大型功能或进行重构时，可以通过 Shift + Tab 切换到 Plan 模式。经过多轮对话确定最终方案后，再切回 Code 模式执行。

实践两天后我发现：对于前端开发，强烈建议严格遵循 Plan → Code 的工作流程。在 Plan 模式下与 Codex 充分交流，能够明确更多 UI/UX 细节，最终产出质量更高。

虽然 Vibe Coding 体验不错，但也暴露出一些问题。比如，Plan 和 Code 模式的模型与推理等级都是硬编码为 gpt-5.2-codex medium。这可以理解，毕竟功能还在实验阶段，内置提示词也在持续优化。但对于我这种习惯将推理等级设置为 xhigh 的用户来说，这显然不够理想。再加上使用体验不够便捷，于是开启了二次开发之路。

最终效果如下：

核心诉求

二次开发的目标很简单：提升效率，优化开发体验。

实时用量展示：频繁使用 /status 查看模型和用量很繁琐，需要一个像上下文用量那样直观的实时视图
Git 分支提示：多分支并行开发时，需要明确当前所在分支，避免在错误分支上提出重复需求
模型配置确认：需要随时确认当前使用的模型和推理等级配置

……

你也许也有自己的痛点。既然现在的 Coding Agent 已经足够强大，为什么不直接打造一个更符合个人习惯的定制版本呢？

当然，二次开发也意味着取舍：一旦开始，你需要持续追赶官方的最新版本，每次发版都要同步并合并代码。

同步上游的工作流程

为了避免复杂的代码冲突，我采用了以下流程：

基于特定版本创建功能分支（如 feat/v0.94），开发并验证功能后，将改动记录到 CHANGED.md 文件
同步官方最新版本：执行 git fetch upstream tags，获取最新 tag（如 rust-0.98.0）
基于最新版本重建分支（如 feat/rust-0.98），从旧分支复制 CHANGED.md，根据记录的改动重新开发
验收功能完成更新

这套流程的核心思路是：每次都基于最新代码从零开始，完全避免处理上游代码冲突。跳过测试代码编写，快速交付，完成迭代。

Skills 分享

基于上述流程，我整理了一套 Skills，你也可以根据自己的需求进行改造。

详见：https://github.com/Loongphy/codext/blob/main/.agents/skills/codex-upstream-reapply/SKILL.md

致谢

状态栏设计参考了：https://linux.do/t/topic/1481797

OpenAI Codex App for Windows: 从零构建教程 (含安装包)

Wed, 04 Feb 2026 00:00:00 GMT

OpenAI 一直优先发布一些 macOS-only 的产品，好在这次 Codex 是基于 Electron 构建 UI，底层调用 Codex-CLI，我们就有了一些逆向重新构建 Windows 版本的可能。

打包版本

仅作体验尝鲜，只做一个成果演示，不负责后续维护。

前往下载：https://github.com/Loongphy/codext/releases/tag/rust-v0.94.0
或者下载这个项目 CodexDesktop-Rebuild，本篇文章的灵感来自于此，不过它的 Codex-CLI 是修改版本，我也不清楚改了啥。

我还是主力 Codex-CLI，不常用 App 版本，毕竟 UI 都只是在调用 Codex-CLI，我对现有工作流很满意，不需要 GUI。我也无法拒绝 WSL2，当前 Windows App 版只能通过跨文件系统访问，如 \\wsl.localhost\Debian\root，文件读写会很慢。

有问题可以在评论区提，在官方正式推出前会随着 Codex-CLI Release 版本更新。

授人以鱼不如授人以渔，希望看完这篇文章后能够自己构建、自己修🫡。

下载 macOS 安装包

在 Chrome 里“伪装成 macOS”（UA + Client Hints）打开 https://openai.com/codex/ 下载 codex.dmg 安装包：

打开 DevTools：按 F12 / Ctrl+Shift+I
打开命令菜单：Ctrl+Shift+P，输入 Network conditions，选择 Show Network conditions（会在 DevTools 底部出现面板）。
在 User agent 区域，取消勾选 Use browser default，然后：
- 直接从下拉选择一个 macOS / Safari（如果有）
（很关键）点开 User agent client hints 下拉，把 platform 之类的字段也改成 macOS，点 Update。很多站现在更依赖 Client Hints，而不是只看 UA 字符串。
刷新页面。

构建 Codex Windows App

我更喜欢在 WSL2 中配合 CLI 形式的 Agent 开发，Windows 的终端体验属于是狗弃人厌，LLM 也容易出错，不小心删除文件的事件屡见不鲜。

创建一个空的文件夹，把下载的 .dmg 文件复制过来，在 WSL2 访问此目录执行 codex，输入 /Approvals 授予 Full Access 权限，Let’s go～。

初始 Prompt

请基于我当前仓库的现状，帮我把“基于 macOS 已打包产物的 Electron 应用”重封装为可在 Windows 上构建与打包的版本。

## 项目目的
- 我只有一个 macOS 安装包（Electron 打包后的 .dmg），我想在 Windows 上重新构建出可运行的 Windows App。
- 我不打算恢复源代码或重新编译前端；目标是“重封装/重打包”：把已打包产物作为输入，在 Windows 上重新构建出可运行的 Windows App。
- 后端 CLI 由 Codex-CLI 进程提供：Windows 需要 `codex.exe`，通过 `@openai/codex` 拿到对应平台的预编译 `codex.exe`。

## 交付结果

- 一个 Windows 的可安装文件

## 注意事项

- 我们处于 WSL2 环境中，对于 Windows 相关的依赖打包，需要调用 pwsh.exe 来执行。

观察者

AI 用户习惯让工具直接修复错误，自己很少独立思考，导致后期独立发现和修复 bug 的能力变弱——这恰恰是监督 AI 输出时最需要的技能。

我看到过很多人 Vibe Coding 只看结果责怪 Agent，而不去查看过程，检查是否在某刻出现了偏差。

仅将观察 Codex-CLI 执行过程中遇到的问题记录下来：

prefer uv not python

在执行过程中发现会使用 Python，由于我不希望安装各种依赖到处拉屎，在执行过程中又加了一个 prefer uv not python 的要求。

不过看后续的内容还是直接安装了 Python 而非使用 uv，所以推荐把上述要求加到初始 Prompt 或者 AGENTS.md 文件中。

对于 AGENTS.md 的指令，Codex-CLI 会设定为第一优先级，严格遵循，遗漏的情况很少。

安装 Visual Studio Community

打包过程使用了 Visual Studio Tools，也许你需要先安装一个 Visual Studio Community，应该和开发 Electron 所需的环境一致：安装【使用 C++ 的桌面开发】。

单次执行结果

只有首次的 Prompt 和中间的一句 prefer uv not python，41 分钟完成。

最终只是运行起来了，仍然有一点 bug，比如窗口没做 resize，没法自由拉伸。选择项目后出现 Oops, an error has occurred。

这些都在一句提示词后解决了，now, let’s play with it!

伟哉，Codex-CLI！

另一条构建路线

可能你不想在本地构建，不想安装各种乱七八糟的环境，可以尝试使用 Codex-CLI 在 GitHub Actions 中执行，选择在 Windows 环境中构建，通过 codex "你的指令" 的方式执行，将打包后的产物上传到 Artifacts，你就能直接下载了。

提示词可能需要调整，让它不打包成功就一直重试，因为 Codex-CLI 倾向于询问而非自主完成任务。

期望

开发一个 Windows 版本没那么简单，虽然不指望用 WinUI 3，毕竟微软自己也陷入了技术泥淖。但希望每个编程软件的开发者都考虑下 WSL2 的适配工作，达到 VS Code 那样的原生 Linux 开发体验吧。

感谢

给了我重新打包的灵感 https://github.com/Haleclipse/CodexDesktop-Rebuild

Vibe Coding 仿照 Cursor 做了一个跑步的年度总结

Mon, 29 Dec 2025 00:00:00 GMT

Cursor 出了年度报告后，就一直想仿照它的 UI 出一个跑步的年度报告，正好刷到 Yihong 的推文，已经把数据统计做了。那剩下的工作就只有 UI 部分了，于是便有了如下年度总结：

https://running.loongphy.com/2025

本次仅对开发该年度总结的过程做个大致的经验总结，详细的 Vibe Coding 经验可以期待下后续更新的 2025 总结。

核心出装：Chrome DevTools MCP

它是专门针对 Chromium 浏览器的 MCP，支持通过 CDP 对你的浏览器做一些自动化操作，比如：截图、页面的点击、获取控制台输出等等。

有了它，我们赋予了 Coding Agent 读写网页的能力，也是我们能完成复制 cursor.com/2025 样式的核心工具。

Codex 配置

为我们的 Codex 简单配置下：

[mcp_servers.chrome-devtools]
command = "npx"
args = [
  "chrome-devtools-mcp@latest",
  "--browserUrl=http://localhost:9222"
]
startup_timeout_sec = 30

指定 BrowserUrl 是因为我们想让 MCP 使用我们指定的浏览器，只有在那个浏览器上我们登录了 cursor，该有对应的年度总结数据。

对应的浏览器启动时也需要开启调试端口，与 Codex 配置对应，Powershell 为例：

& "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe" `
  --remote-debugging-port=9222 `
  --user-data-dir="${env:TEMP}\edge-9222"

此时启动 Codex，我们的 chrome-devtools 就能操作 Edge 浏览器了。

one-shot

现在的 Coding Agent 的 one-shot 能力真的很惊艳，但这绝不就意味着能替代现有工程师，它的工程能力依旧问题很多。

输入我们的第一个 Prompt，借助 chrome-devtools，Codex 能实现一个大致的效果。

实现一个跑步数据的年度总结动态交互网站，参考网站 https://cursor.com/cn/2025 所示，样式交互都必须与该网站保持一致：

- 该网站是一个动态的网站你可以space键进行进入下一页
- 每一页的内容都替换成我们的实际跑步数据，展示我们的按月纵向显示的跑步数据 grid
- 使用 chrome-devtools 去查看该网站，生成截图，查看源码、样式、交互，包括不限于：
    - 首次加载的样式、字体动画等
    - 进入网页后对应的动效等

其中跑步数据来自于 https://github.com/yihong0618/running_page，你也可以 fork 该仓库，针对你的跑步手表获取跑步数据，构建一个跑步网站，具体配置不做介绍。

问题

尽管首个 Prompt 跑了2小时不到就出了大致效果，但后续的微调花了好几天的时间，比如：字体太小、间距太小，鼠标悬停样式没做等等。

大致过程如下：

当前对话：第三次 1h 31m 23s

样式有些单一，不要全是这种[PixPin_2025-12-24_08-23-53.png 1117x1429]
  请你使用 chrome-devtools 对参考网站 https://cursor.com/cn/2025 截图、获取原有的每个交
  互阶段的源码等方式，参考他们的多种交互。

  按照如下实现方式，继续更新 PLAN.md，然后继续迭代，注意把迭代后的每个阶段截图与参考
  截图对比，直至大致相同，80% 以上相似。

第四次 39m 18s

根据如下要求调整你的 PLAN.md：
# 还原度提升/对齐视觉

- UI布局、动态交互、配色等统一参考 https://cursor.com/cn/2025 ，不要受本地项目影响。更新 PLAN.md 中的目标：点阵配色与卡片字体进一步对齐 https://cursor.com/cn/2025 而非 assets/year_summary_2025.svg
- 请是采用 chrome-devtools 截图本地运行的 http://localhost:5173/2025 ，目前UI主体显示太小了，而且不在中间位置，请你重新比对 https://cursor.com/cn/2025 修改调整。

# Stage 调整

> space/enter/向下箭头切换stage，左右箭头图标是切换stage中的每次跑步数据的。

- Stage 1:
1. 首次进入，文字依次动画交互显示
2.每个有数据的竖条都可以悬浮显示对应的跑步距离数据，左右箭头图标切换的是上一次跑步和下一次跑步的高亮竖条，请你使用 chrome-devtools 点击 https://cursor.com/cn/2025 的stage1 图标 <div class="timeline-nav-button"/> 查看。
- Stage 2: 显示周数据，样式有些小，无左右切换图表，对齐 https://cursor.com/cn/2025
- Stage 3: 日跑量动画，动态滚动的竖条，每个点都是跑步天的跑量，竖条向右划过的都是每个跑步天的跑量。左右箭头图标切换的是上一次跑步和下一次跑步的高亮竖条。如果无法通过 chrome-devtools 查看，我可以后续提供视频。
- Stage 4: 符合预期，但是文字可以motion动画显示，依次淡入
- Stage 5: 推到 Stage 6。新的 stage 5 显示 grid 形式2025年的日跑量数据，如图所示 @stage-5.png，你可以使用chrome-devtools 捕获这一时刻的截图、源码和样式。
- Stage 6（原 Stage 5）: 样式需要大改，样式参考 https://cursor.com/cn/2025

此时我意识到，文本对话指导 Codex 已经失控了，它只能机械的服从我的指令，却不知道我为什么要这么做。

这也是 Vibe Coding 中越到后期越失控的原因。

识别图片

之前的指令没有让 Codex 显式读取图片，只是根据指令更新了代码，但并没有查看更新后的效果，因此人工验收时可能会有一些明显错位等问题需要改正。我们让 Codex 每次执行完都检查一遍图片，并让 Gemini-CLI 也参与进来。

更新我们的 AGENTS.md:

## 工具使用
- 浏览器验证：使用 chrome-devtools（不要用肉眼猜测 UI）。
- 使用 gemini 做视觉比对时，必须在提示词中同时附上当前图与参考图的绝对路径。
 gemini -p "your_prompt @<图片绝对路径> " --allowed-tools read_file

## Visual verification gate (NON-NEGOTIABLE)

<persistence>
- Keep going until the task is completely resolved.
- Only terminate when the "Definition of Done" is satisfied.
- Do NOT stop after merely viewing screenshots; viewing is not verification.
</persistence>

<definition_of_done>
- Done ONLY when the latest visual verification returns PASS.
- If visual verification returns FAIL, you MUST fix code and re-run the loop.
- If you cannot verify (tool/image missing/corrupted), treat it as FAIL and explain the blocking reason + best next step.
</definition_of_done>

<visual_verification_loop>
After EVERY code change that could affect UI:
1) Use chrome-devtools to navigate to the exact path relevant to this change.
2) take_screenshot → save under artifacts/ (name should include viewport: mobile/desktop).
3) Open/read the screenshot(s).
4) Output a Visual Verification Report (format below).
5) If FAIL → return to code, fix, then repeat from step 1.
</visual_verification_loop>

<visual_verification_report_format>
You MUST end the turn with the following block (no exceptions):

VISUAL_VERIFY: PASS | FAIL
Screenshots:
- <list every file you used for the verdict>
Evidence:
- <1–3 concrete visual facts you observed that prove you actually read the screenshots>
Reasons:
- <why PASS or why FAIL, short and specific>
Next:
- If PASS: "Done"
- If FAIL: <the next fix you will do immediately>
</visual_verification_report_format>

至此，大致完工。

随想

没有一个大而全的 AGENTS.md 可供参考，甚至在项目最开始你的 AGENTS.md 应该是空的。根据你的 Agent 完成的任务而去相应的调整 AGENTS.md：

增加对执行过程的限制：如上面提到的读取图片分析

Vibe Coding 很难通过自然语言去精确掌控指定的组件，所以 Cursor 加了个内置 Browser，增加了光标组件选择。

又在后续 2.2 版本增加了样式编辑器，目的就是为了精确把控 UI。尽管引来群嘲，但我认为这些根本不是想取代 Figma 之类的设计软件，而是为了降低自然语言编程不确定性的一种方式。在对话时，AI 也会忘记全局，让它调整某个单独的内容，它可能把整体都改了。或者说不是 AI 改的全局，而是我指出要改哪部分，它改了后发现影响了全局。这种现象经常在古法编程中出现，只不过现在有了一个可以指责的对象。不是 AI 太笨，是我太蠢。

Google Antigravity 卡在 Setting Up Your Account 无法登录的解决方案

Wed, 19 Nov 2025 00:00:00 GMT

其实非 US 地区也可以，但不能是 Gemini 不支持的地区（如港澳）。若希望第一时间体验新出的 AI 模型、产品，还是推荐 US。

今日（2025-11-19）Google 发布了 Gemini 3 Pro 模型和新的 AI 编辑器 Antigravity，该工具由前 Windsurf 核心团队基于 Windsurf 构建，你也能看到不少遗留代码分享。

Google 于 2025 年 7 月聘请 Windsurf CEO Varun Mohan、联合创始人 Douglas Chen 以及部分研究人员加入 DeepMind，同时获得 Windsurf 部分技术的非独占许可。该交易总额为 24 亿美元，主要用于人才招聘和技术许可，而非全资收购公司。

此前，OpenAI 曾计划以 30 亿美元收购 Windsurf，但交易失败。

在发布该产品之后，我一直卡在登录成功后的 Setting Up Your Account 界面，尝试了 Mihomo TUN 模式仍无果，经过社区分享，发现和账号归属地有关。

访问 https://policies.google.com/terms 如果显示 Hong Kong，恭喜你无法使用 Antigravity。

Antigravity 对于不支持 Gemini 的地区做了限制，但是后者只针对于 IP，而前者不仅要求 IP，还限制账号归属地。

到了这里，解决方式很明朗了：

US 网络环境注册新的 Google 账号
已有 Google 账号转区

Google 账号转区

访问链接申请换区：https://policies.google.com/country-association-form
选择美国、某个州，理由选择 Other Reason，告知需要使用 Google AI 产品，因此需要换区如：
```
I need to use Google Gemini and Antigravity, which requires a US-based account context.
```

我的经验是大概 30 分钟后会收到成功邮件，注意不要选择其他的换区理由，很容易被拒绝。

总结 Antigravity 正常访问的经验

美国节点 + TUN
美国 Google 账号，可以查看 https://policies.google.com/terms 确认，若不是请参考上述转区。

看社区分享，非美国地区也可以，如日本，个人为了方便还是用美国。

Gemini in Chrome

与 Antigravity 不同，目前暂未确认非 US 账号是否可用，若无法开启，建议将账号转区至 US。

有了上面的美国 Google 账号，其实也可以开启 Gemini in Chrome，让你的浏览器支持 Gemini AI 助理，帮助你简单地总结个网页信息也挺方便的。

浏览器语言改成：English (United States)
浏览器访问 chrome://flags/，启用 Glic 和 Tabstrip Combo Button。
重启浏览器，右上角多了一个 Gemini

我是把 Chrome 换成 English (United States) 才成功显示 Gemini 的，有人分享中文也行，很怪。

参考

Electron: 沙箱 + preload CJS

Mon, 27 Oct 2025 00:00:00 GMT

本文档解决方案 Powered by GPT-5-Thinking & Codex，有问题请找它们😡

Electron 自 v28 版本后已经支持了 ESM，但若要保证沙箱化（sandbox: true）的情况下，就无法使用 ESM Preload，因此我们采用 preload CJS + main/renderer ESM 方案。

启用 sandbox: true 时，preload 不能用 ESM，必须打成“单文件”的 CJS，并且不要外部化三方依赖。

若要保证 CJS preload 正常运行，需要满足两件事：

把 preload 依赖全都打包进单文件
维持 sandbox: true、contextIsolation: true、nodeIntegration: false 的组合（Electron v28 以后都是这个默认配置，无需显式指定），main 进程指向 CJS preload 打包后的文件。

preload 用到的第三方依赖全都打包进单文件

沙箱不允许 runtime 再去 require 其它模块，所以得在构建期把需要的代码打进 src/preload/index.ts 的产物里。

Electron 应用基于 electron-vite 开发，可以通过 electron-vite.config.ts 配置 CJS，我们当前在 src/preload/index.ts 中用到了第三方依赖 @electron-toolkit/preload

对于 Node/Electron API 相关 API 无需打包，在启用 sandbox 的 preload 里本来就会注入受控的 Node polyfill 和 electron 模块供预加载脚本调用

electron-vite.config.ts

  preload: {
    plugins: [externalizeDepsPlugin({ exclude: ['@electron-toolkit/preload'] })],
    build: {
      rollupOptions: {
        input: resolve(__dirname, 'src/preload/index.ts'),
        output: { format: 'cjs', entryFileNames: 'index.cjs' },
      },
    },
  }
})

main 进程配置

src/main/index.ts

const mainWindow = new BrowserWindow({
  width: 720,
  height: 88,
  webPreferences: {
    preload: join(__dirname, '../preload/index.cjs'), // index.cjs 而非 index.mjs，与上一步配置对应
  },
})

迁移到 CJS preload 的文件变动

  electron.vite.config.ts

  - Preload build now keeps @electron-toolkit/preload inline and defines explicit Rollup options for both main (ESM) and preload (CJS)
    outputs, including entryFileNames: 'index.cjs'.

    main: {
       plugins: [externalizeDepsPlugin()],
       resolve: { ... },
  +    build: {
  +      rollupOptions: {
  +        input: resolve(__dirname, 'src/main/index.ts'),
  +        output: { format: 'es' },
  +      },
  +    },
    },
    preload: {
  -    plugins: [externalizeDepsPlugin()],
  +    plugins: [externalizeDepsPlugin({ exclude: ['@electron-toolkit/preload'] })],
       resolve: { ... },
  +    build: {
  +      rollupOptions: {
  +        input: resolve(__dirname, 'src/preload/index.ts'),
  +        output: { format: 'cjs', entryFileNames: 'index.cjs' },
  +      },
  +    },
    },

  src/main/index.ts

  - Switched the preload script path back to index.cjs for main window

       webPreferences: {
  -      preload: join(__dirname, '../preload/index.mjs'),
  +      preload: join(__dirname, '../preload/index.cjs'),
       },

  src/preload/index.ts

  - Dropped import process from 'node:process' and instead silenced the lint warning to keep using the runtime-provided process.

  -import process from 'node:process'
  ...
   // just add to the DOM global.
  +// eslint-disable-next-line node/prefer-global/process
   if (process.contextIsolated) {

CJS preload 配置不当会出现的问题

sandbox:true 情况下，未正常配置 cjs preload

VM4 sandbox_bundle:2 Unable to load preload script: D:/xxx/out/preload/index.cjs
  executeSandboxedPreloadScripts @ VM4 sandbox_bundle:2
  VM4 sandbox_bundle:2 Error: module not found: node:process
      at preloadRequire (VM4 sandbox_bundle:2:146685)
      at <anonymous>:3:21
      at runPreloadScript (VM4 sandbox_bundle:2:146954)
      at executeSandboxedPreloadScripts (VM4 sandbox_bundle:2:146227)
      at VM4 sandbox_bundle:2:156625
      at VM4 sandbox_bundle:2:156827
      at ___electron_webpack_init__ (VM4 sandbox_bundle:2:156831)
      at VM4 sandbox_bundle:2:156954

不要在 src/preload/index.ts 手动import node from ‘node:process’，若出现linter警告，禁用这一行警告即可。因为 preload 脚本本身就会被注入受控的 Node polyfill。

if (process.contextIsolated) {
  try {
    contextBridge.exposeInMainWorld('electron', electronAPI)
    contextBridge.exposeInMainWorld('api', api)
  }
  catch (error) {
    console.error(error)
  }
}
else {
  window.electron = electronAPI
  window.api = api
}

module not found: @electron-toolkit/preload

VM4 sandbox_bundle:2 Unable to load preload script: D:/xxxx/out/preload/index.cjs
  executeSandboxedPreloadScripts @ VM4 sandbox_bundle:2
  VM4 sandbox_bundle:2 Error: module not found: @electron-toolkit/preload
      at preloadRequire (VM4 sandbox_bundle:2:146685)
      at <anonymous>:3:17
      at runPreloadScript (VM4 sandbox_bundle:2:146954)
      at executeSandboxedPreloadScripts (VM4 sandbox_bundle:2:146227)
      at VM4 sandbox_bundle:2:156625
      at VM4 sandbox_bundle:2:156827
      at ___electron_webpack_init__ (VM4 sandbox_bundle:2:156831)
      at VM4 sandbox_bundle:2:156954

OpenAI Codex 不完全の伪新手指南

Tue, 16 Sep 2025 00:00:00 GMT

[!warning] 这并不是一篇零基础上手指南，需要您有一点点 Codex 使用经验。由于本人对于官方仓库所用 Rust 语言并不了解，所有信息均来自 PR 和 Issue 讨论，可能存在经验主义错误，如有事实偏差，还望指正。本文偏向于 Windows 的调教指南，如果这你都能看完，想必 MacOS/Linux 更能得心应手。

前言

官方文档：https://developers.openai.com/codex/quickstart
项目文档：https://github.com/openai/codex/tree/main/docs

基础配置 config.toml

[!tip] 工欲善其事，必先利其器。对于 Codex 这个工具，强烈建议把配置文档看一遍 config.md

在 ~/.codex/config.toml 中配置基础的 Codex

model = "gpt-5-codex" # Codex 0.36.0 支持
model_reasoning_effort = "high" # 使用最大推理能力
model_reasoning_summary = "detailed" # 在终端显示详细的推理总结（ctrl+T查看）OpenAI 没有推理过程，只有推理总结
model_verbosity = "high" # 不懂，总之要拉满
model_supports_reasoning_summaries = true # 强制启用推理总结，针对于自定义 API KEY 的
hide_agent_reasoning = false # 允许显示更多的 AGENT 内部思考过程
disable_response_storage = true # 不允许 OpenAI 服务端存储你的对话
approval_policy = "never" # 配了但没用，总之先放着，建议通过 /approvals 配置
sandbox_mode = "workspace-write"

# 配了但没用，总之先放着，建议通过 /approvals 配置
# allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

命令

[!tip] codex --help 是一个好习惯

终端执行 codex 后进入，输入 / 你能得到目前支持的一些快捷命令。

/status

最常用的命令，用于检查当前的权限和 GPT-5 模型配置。如果你是自定义 API Key，更应该多使用该命令检查是否使用了正确模型。

/approvals

授予 Codex 权限，目前有三种，如果超出权限限制，就需要用户手动确认：

Read Only：默认权限，只能读取文件（实操下来限制太多，和 Agent Coding 自由理念相悖，一个任务可能要十多次手动批准。太麻烦）
Auto：读写，运行命令（实测一点也不 Auto，还是有太多手动批准）
Full Access：读写、使用网络工具（虽然官方一再声明小心操作，但这是我的日常使用的方式，真正的 Auto，整个过程不需要一次确认）

个人倾向日常选用 Full Access ，可以在每次运行 Codex 时添加额外的命令参数，无需每次重新选择权限：

codex --dangerously-bypass-approvals-and-sandbox

/mcp

Codex 目前仅支持 STDIO，若遇到仅支持 SSE 的 MCP Server，请查看下一章节。

如果你是 Windows 开发者，遵从 mcp_servers 一定会配置失败。通常进入 Codex 你会看到

Program not found 或 request timed out

需要在原教程文档基础上增加如下：

新增 command 指向具体的 npx 位置
新增 env 包含 SYSTEMROOT

[mcp_servers.context7]
command = "C:\\Program Files\\nodejs\\npx.cmd"
args = [
  "-y",
  "@upstash/context7-mcp",
  "--api-key",
  "<your_api_key>"
]
env = { SYSTEMROOT = 'C:\Windows' }

MCP Server (SSE 方式)

在 WSL2 采用 MacOS/Linux 方式配置，访问 Windows 代码仓库时，也会出现 request timed out 问题。

此类问题通常是 Codex 没有正常读取环境导致的，可以借助 mcp-remote 通过切换到 SSE 的方式解决。

除此之外，还有些 MCP Server 仅支持 SSE，所以我们也需要采用这种方式，比如 deepwiki。

[!Warning] mcp-remote 是第三方作者开发，非 MCP 协议官方支持，需考虑风险。

分为两种方式，可以二者选其一。

全局安装

npm install -g mcp-remote
添加 SSE 的方式（需要 MCP Server 支持）

[mcp_servers.context7]
command = "mcp-remote"
args = [
  "https://mcp.context7.com/mcp",
  "--header",
  "CONTEXT7_API_KEY: <your-api-key>"
]

[mcp_servers.deepwiki]
command = "mcp-remote"
args = [ "https://mcp.deepwiki.com/sse" ]

npx

[mcp_servers.context7]
command = "npx"
args = [
  "mcp-remote",
  "https://mcp.context7.com/mcp",
  "--header",
  "CONTEXT7_API_KEY: <your-api-key>"
]

[mcp_servers.deepwiki]
command = "npx"
args = [
  "mcp-remote",
  "https://mcp.deepwiki.com/sse"
]

恢复/继续对话

[!TIP] resume/continue 恢复对话功能仍然在开发中，所以 --help 中还没有增加对应的说明，但当前可用

与 Codex 的对话是保存在本地目录 ~/.codex/sessions 下的，我们可以执行如下命令来选择最近对话列表恢复，继续对话。

codex --resume

[!failure]- 0.36 版本后废弃 continue 直接恢复上一次对话，无需选择
codex continue

工具调用

为了最快、最准确的帮助 Codex 完成搜索，我们需要针对性的使用不同的工具。

不同的系统平台，Shell 工具也有所不同，本文主要聚焦于 Windows 平台，旨在引导 Codex 使用正确的命令和工具，减少错误重试、降低单次任务执行的时长。

Codex 支持在代码仓库根目录添加 AGENTS.md 文件来指导 Codex 在该仓库下遵守的规则，如：仓库技术栈、工具调用等。

目前主要使用三种：fd, ripgrep 和 ast-grep。

按文件名找 → fd
按文本内容找 → rg（ripgrep）
按代码结构/语义找 → sg（ast-grep）

Windows 安装

[!failure]- 0.41 版本后废弃从 codex v0.41 版本开始，ripgrep 已经被内置到 npm 包中，无需手动安装。
winget install sharkdp.fd BurntSushi.ripgrep.MSVC ast-grep
如果你感兴趣的话，ripgrep 相对 @openai/codex 包根目录的 ripgrep 位置是 vendor/<target-triple>/path/rg（Windows 为 rg.exe）。你甚至可以与 Codex 对话询问 工具 rg 在哪个位置。

从 codex v0.41 版本开始，ripgrep 已经内置在 npm 包中，因此只需要安装 fd 和 ast-grep：

winget install sharkdp.fd ast-grep

WSL2（Debian）

apt install -y fd-find

npm i @ast-grep/cli -g

AGENTS.md

在实际操作过程中，发现只声明可用工具而不引导具体用法，经常会偏离预期，因此建议复制如下完整的配置，按需调整。

## Tool Priority

- Filename search: `fd`.
- Text/content search: `rg` (ripgrep).
- AST/structural search: `sg` (ast-grep) — preferred for code-aware queries (imports, call expressions, JSX/TSX nodes).

### AST-grep Usage (Windows)

- Announce intent and show the exact command before running complex patterns.
- Common queries:
  - Find imports from `node:path` (TypeScript/TSX):
    - `ast-grep -p "import $$ from 'node:path'" src --lang ts,tsx,mts,cts`
  - Find CommonJS requires of `node:path`:
    - `ast-grep -p "require('node:path')" src --lang js,cjs,mjs,ts,tsx`
  - Suggest rewrite (do not auto-apply in code unless approved):
    - Search: `ast-grep -p "import $$ from 'node:path'" src --lang ts,tsx`
    - Proposed replacement: `import $$ from 'pathe'`

### Search Hygiene (fd/rg/sg)

- Exclude bulky folders to keep searches fast and relevant: `.git`, `node_modules`, `coverage`, `out`, `dist`.
- Prefer running searches against a scoped path (e.g., `src`) to implicitly avoid vendor and VCS directories.
- Examples:
  - `rg -n "pattern" -g "!{.git,node_modules,coverage,out,dist}" src`
  - `fd --hidden --exclude .git --exclude node_modules --exclude coverage --exclude out --exclude dist --type f ".tsx?$" src`
- ast-grep typically respects `.gitignore`; target `src` to avoid scanning vendor folders:
  - `ast-grep -p "import $$ from '@shared/$$'" src --lang ts,tsx,mts,cts`
  - If needed, add ignore patterns to your ignore files rather than disabling ignores.

系统通知

Codex 支持在任务执行完成后执行自定义事件，我们可以利用这一特性实现 Windows 系统弹窗通知。

[!TIP] Codex 文档见 https://github.com/openai/codex/blob/main/docs/config.md#notify

~/.codex/config.toml

notify = [
  "powershell.exe",
  "-NoProfile",
  "-ExecutionPolicy",
  "Bypass",
  "-File",
  "C:\\Users\\<username>\\.codex\\notify.ps1"
]

~/.codex/notify.ps1

param(
  [Parameter(Mandatory = $true)]
  [string]$json
)

# 解析 JSON（Codex 把一段 JSON 作为 argv[1] 传进来）
try {
  $payload = $json | ConvertFrom-Json
} catch {
  $payload = @{}
}

$title = 'Codex'
$msg   = $payload.'last-assistant-message'
if (-not $msg) {
  if ($payload.type) {
    $msg = "Event: $($payload.type)"
  } else {
    $msg = 'Codex has an update.'
  }
}

# 可选：截断过长文本，注意只用 ASCII 的三点号，避免乱码
if ($msg -and $msg.Length -gt 240) {
  $msg = $msg.Substring(0,240) + '...'
}

# 只用 Toast，不要任何 Popup 兜底
Import-Module BurntToast -ErrorAction Stop
New-BurntToastNotification -Text $title, $msg | Out-Null

Codex Prompt 调试技巧

每次修改 AGENTS.md 后，多使用 ctrl+T 查看其思考过程，看看命令的调用、思考过程是否符合你的预期。若不符，直接与 Codex 对话询问该如何调整 AGENTS.md，多重复几轮一般都能得到比较满意的结果。

[开始]
  |
  v
[修改 `AGENTS.md`]
  |
  v
[Ctrl+T 查看当前思考过程/轨迹]
  |
  v
{是否符合你的预期?}
        |是
        v
   [提交/应用变更]───►(结束或进入下一任务)
        ^
        |否
        |
        v
[与 Codex 对话：询问如何调整 `AGENTS.md`]
        |
        v
[根据建议再次修改 `AGENTS.md`]
        |
        └───────────────循环回到───────────────┐
                                            v
                              [Ctrl+T 查看当前思考过程/轨迹]

Spec-kit （实验性）

模仿 spec-kit 建立了一套实现新功能的规范，包含三个流程：spec, plan 和 do。

还在尝试优化中，因此未利用 codex/prompts.md 方式注入指令，而是通过 AGENTS.md 来时刻调整测试，在对话时输入 /spec 和 /plan 和 /do 即可。

/spec 开头，输入你想要实现的功能，Codex 会自动在 specs 文件夹下生成一个 Markdown 文件
/plan 开头，Codex 会自动在 plans 文件夹下生成一个带有日期的 Markdown 文件
/do 会自动按照 plan 任务实现。

不必严格遵从上述三个顺序来执行，如果 spec 文件不符预期，完全可以继续多轮对话调整满意后，再输入 /plan 来引导生成 plan 文件。

## Stage-Gated Workflow (spec/plan/do)

- Mode: Opt-in. The workflow applies only when the user explicitly uses `/spec`, `/plan`, or `/do`. Routine Q&A or trivial edits do not require these stages.
- Triggers: A message containing one of `/spec`, `/plan`, or `/do` activates or advances the workflow. Once active, stages must proceed in order with explicit user approval to advance.
- Guardrails:
  - Do not modify source code before `/do`. Documentation/spec files may be edited only in `/spec`.
  - Do not skip stages or proceed without user confirmation once the workflow is active.
  - If scope changes, return to the appropriate prior stage for approval.
  - Respect sandbox/approval settings for all actions.

- When to Use
  - Use the workflow for new features, structural refactors, multi-file changes, or work needing traceability.
  - Skip the workflow (no triggers) for routine Q&A, diagnostics, or one-off trivial edits.

- Entry Points and Prerequisites
  - `/spec` is the canonical entry point for new efforts.
  - `/plan` requires an approved `/spec`. If unclear which spec applies, pause and ask the user to identify the correct file(s) under `specs/`.
  - `/do` requires an approved `/plan`.

- `/spec` (Specifications; docs only)
  - Purpose: Capture a concrete, reviewable specification using spec-kit style.
  - Output: Markdown spec(s) under `specs/` (no code changes). Share a concise diff summary and links to updated files; wait for approval.
  - Style: Specs are canonical and final. Do not include change logs or “correction/更正” notes. Incorporate revisions directly so the document always reflects the current agreed state. Historical context belongs in PR descriptions, commit messages, or the conversation — not in the spec.
  - Recommended contents:
    - Problem statement and context
    - Goals and non-goals
    - Requirements and constraints (functional, UX, performance, security)
    - UX/flows and API/IPC contracts (as applicable)
    - Acceptance criteria and success metrics
    - Alternatives considered and open questions
    - Rollout/backout considerations and telemetry (if relevant)

- `/plan` (High-level Plan; docs only)
  - Purpose: Turn the approved spec into an ordered, verifiable implementation plan.
  - Inputs: Approved spec file(s) in `specs/`.
  - Ambiguity: If the relevant spec is unclear, pause and request clarification before writing the plan.
  - Style: Plans are canonical and should not include change logs or “correction/更正” notes. Incorporate revisions directly so the plan always reflects the current agreed state. Historical notes should live in PR descriptions, commit messages, or the conversation.
  - Output:
    - An ordered plan via `update_plan` (short, verifiable steps; Task is merged into Plan and tracked here).
    - A plan document in `plans/` named `YYYY-MM-DD-short-title.md`, containing:
      - Scope and links to authoritative spec(s)
      - Assumptions and out-of-scope items
      - Phases/milestones mapped to acceptance criteria
      - Impacted areas, dependencies, risks/mitigations
      - Validation strategy (tests/lint/build) and rollout/backout notes
      - Approval status and next stage
  - Handoff: Await user approval of the plan before `/do`.

- `/do` (Execution)
  - Purpose: Implement approved plan steps with minimal, focused changes and file operations.
  - Actions:
    - Use `apply_patch` for file edits; group related changes and keep diffs scoped to approved steps.
    - Provide concise progress updates and a final summary of changes.
    - Validate appropriately: run `pnpm lint`, `pnpm format`, `pnpm build`, and relevant tests.
    - If material changes to the plan are needed, pause and return to `/plan` (or `/spec`) for approval.
  - Output: Implemented changes, validation results, and a concise change summary linked to the plan checklist.

### Plans Directory

- Location: `plans/` at the repository root.
- Filename: `YYYY-MM-DD-short-title.md` (kebab-case title; consistent dating).
- Style: Plan docs are the canonical source of truth for the implementation approach; avoid embedding change logs or “correction/更正” notes. Update the plan in place as decisions evolve.
- Contents:
  - Title and summary
  - Scope and linked specs (paths under `specs/`)
  - Assumptions / Out of scope
  - Step-by-step plan (short, verifiable)
  - Validation strategy (tests/lint/build)
  - Approval status and next stage
- Process:
  - During `/plan`, create or update the relevant file in `plans/` and share a short summary in the conversation. Await approval before `/do`.

WSL2

如果你在 Windows 下让 Codex 执行任务，你会发现它经常调用命令失败然后重试，如此循环。虽然最终都会成功，但浪费了很多时间，个人推测这是因为 GPT-5 Unix Shell 训练数据太多而 Powershell 数据太少导致的幻觉，Codex 总是下意识调用 Unix Shell 命令来处理。

那么有没有办法解决呢？当然有！打不过就加入——WSL2。

以 Windows 11 为例，在 Powershell 执行 wsl --install 即可安装 WSL2。

这种情况下，有两种方式选择：

Windows 端代码+WSL2 Codex 环境，适用于开发 Windows 端的程序，比如 Electron Windows，.NET 等
WSL2 代码 + WSL2 Codex 环境，比如 Vue Web 开发

对于后者，所有都能正常在 WSL2 环境内运行，就不做说明了，而前者 Windows + WSL2 混用就需要解决一个问题：如何在 WSL2 调用 Windows 端的 npm/pnpm，执行定义好的 pnpm typecheck pnpm lint:fix 等。

在 WSL2 Codex 对话时，要求其调用 pwsh.exe 来执行 pnpm typecheck 来检查，如此即可。

we're in WSL2, please using pwsh.exe to run `pnpm <script>`

完整 AGENTS.md

还在调整中，不要完全照抄，最好还是通过 ctrl+T 查看整个过程，如果遇到 Codex 经常会出错的命令，选择性的修删适合自己的 AGENTS.md。

主要适配内容：

Windows/WSL2 支持，优先使用 Powershell 支持的命令，对于任何 npm 包安装都必须请示用户，避免混乱的依赖项
使用 fd,ripgrep,ast-grep 搜索文件、文本和代码片段，更快更直接
spec/plan/do 工作流，先确定规范，再编写计划，最后实现

# AGENTS Guidelines

## Windows Environment Notice

- Prefer PowerShell (`pwsh`/`powershell`) when on Windows.
- Prefer using pwsh.exe to run `pnpm <script>` when on WSL2.
- WSL2 may be used for non-package-manager commands only (e.g., `rg`, `tar`). Avoid running Node builds in WSL due to OS mismatch.
- WSL2 cross-drive performance: accessing repos under `/mnt/c|d|e/...` goes through a filesystem bridge and can be slower for full scans. Prefer scoping to subtrees, excluding heavy folders, or running the same searches with native Windows binaries in PowerShell for large/iterative scans.
- Do not auto-run dependency installs. The user must run `pnpm install` in Windows PowerShell manually and then confirm completion.
- Do not modify `package.json`/lockfiles to add or update dependencies without explicit user approval. Propose dependencies in `/spec` or `/plan`, and ask the user to run `pnpm add <pkg>` (or `pnpm install`) and confirm.
- Do not call Unix text tools directly in PowerShell (e.g., `sed`, `awk`, `cut`, `head`, `tail`). Use PowerShell-native equivalents instead:
  - `head` → `Select-Object -First N`
  - `tail` → `Get-Content -Tail N`
  - paging → `Out-Host -Paging` or `more`
  - substitution/replace → `-replace` with `Get-Content`/`Set-Content`

## Tool Priority

- Filename search: `fd`.
- Text/content search: `rg` (ripgrep).
- AST/structural search: `sg` (ast-grep) — preferred for code-aware queries (imports, call expressions, JSX/TSX nodes).

### AST-grep Usage

- Announce intent and show the exact command before running complex patterns.
- Common queries:
  - Find imports from `node:path` (TypeScript/TSX):
    - `ast-grep -p "import $$ from 'node:path'" src --lang ts,tsx,mts,cts`
  - Find CommonJS requires of `node:path`:
    - `ast-grep -p "require('node:path')" src --lang js,cjs,mjs,ts,tsx`
  - Suggest rewrite (do not auto-apply in code unless approved):
    - Search: `ast-grep -p "import $$ from 'node:path'" src --lang ts,tsx`
    - Proposed replacement: `import $$ from 'pathe'`

### Search Hygiene (fd/rg/sg)

- Exclude bulky folders to keep searches fast and relevant: `.git`, `node_modules`, `coverage`, `out`, `dist`.
- Prefer running searches against a scoped path (e.g., `src`) to implicitly avoid vendor and VCS directories.
- Examples:
  - `rg -n "pattern" -g "!{.git,node_modules,coverage,out,dist}" src`
  - `fd --hidden --exclude .git --exclude node_modules --exclude coverage --exclude out --exclude dist --type f ".tsx?$" src`
- ast-grep typically respects `.gitignore`; target `src` to avoid scanning vendor folders:
  - `ast-grep -p "import $$ from '@shared/$$'" src --lang ts,tsx,mts,cts`
  - If needed, add ignore patterns to your ignore files rather than disabling ignores.

## Temporary Research Files

- Canonical location: store all temporary research artifacts (downloaded READMEs, API docs, scratch notes) under `docs/research/`.
- Do not place temporary files at the repository root or outside `docs/research/`.
- Commit policy: avoid committing temporary files unless they are necessary for traceability during `/spec` or `/plan`. If committed, keep the scope minimal and store them under `docs/` only.
- Naming: use descriptive names with date or task context (e.g., `docs/research/2025-09-11-wsl-notes.md`).
- Cleanup: after completing a task (`/do`), evaluate whether each temporary file is still required. Remove unneeded files, or promote essential content into curated docs under `docs/` or into `specs/`/`plans/`.

## Stage-Gated Workflow (spec/plan/do)

- Mode: Opt-in. The workflow applies only when the user explicitly uses `/spec`, `/plan`, or `/do`. Routine Q&A or trivial edits do not require these stages.
- Triggers: A message containing one of `/spec`, `/plan`, or `/do` activates or advances the workflow. Once active, stages must proceed in order with explicit user approval to advance.
- Guardrails:
  - Do not modify source code before `/do`. Documentation/spec files may be edited only in `/spec`.
  - Do not skip stages or proceed without user confirmation once the workflow is active.
  - If scope changes, return to the appropriate prior stage for approval.
  - Respect sandbox/approval settings for all actions.

- When to Use
  - Use the workflow for new features, structural refactors, multi-file changes, or work needing traceability.
  - Skip the workflow (no triggers) for routine Q&A, diagnostics, or one-off trivial edits.

- Entry Points and Prerequisites
  - `/spec` is the canonical entry point for new efforts.
  - `/plan` requires an approved `/spec`. If unclear which spec applies, pause and ask the user to identify the correct file(s) under `specs/`.
  - `/do` requires an approved `/plan`.

- `/spec` (Specifications; docs only)
  - Purpose: Capture a concrete, reviewable specification using spec-kit style.
  - Output: Markdown spec(s) under `specs/` (no code changes). Share a concise diff summary and links to updated files; wait for approval.
  - Style: Specs are canonical and final. Do not include change logs or “correction/更正” notes. Incorporate revisions directly so the document always reflects the current agreed state. Historical context belongs in PR descriptions, commit messages, or the conversation — not in the spec.
  - Recommended contents:
    - Problem statement and context
    - Goals and non-goals
    - Requirements and constraints (functional, UX, performance, security)
    - UX/flows and API/IPC contracts (as applicable)
    - Acceptance criteria and success metrics
    - Alternatives considered and open questions
    - Rollout/backout considerations and telemetry (if relevant)

- `/plan` (High-level Plan; docs only)
  - Purpose: Turn the approved spec into an ordered, verifiable implementation plan.
  - Inputs: Approved spec file(s) in `specs/`.
  - Ambiguity: If the relevant spec is unclear, pause and request clarification before writing the plan.
  - Style: Plans are canonical and should not include change logs or “correction/更正” notes. Incorporate revisions directly so the plan always reflects the current agreed state. Historical notes should live in PR descriptions, commit messages, or the conversation.
  - Output:
    - An ordered plan via `update_plan` (short, verifiable steps; Task is merged into Plan and tracked here).
    - A plan document in `plans/` named `YYYY-MM-DD-short-title.md`, containing:
      - Scope and links to authoritative spec(s)
      - Assumptions and out-of-scope items
      - Phases/milestones mapped to acceptance criteria
      - Impacted areas, dependencies, risks/mitigations
      - Validation strategy (tests/lint/build) and rollout/backout notes
      - Approval status and next stage
  - Handoff: Await user approval of the plan before `/do`.

- `/do` (Execution)
  - Purpose: Implement approved plan steps with minimal, focused changes and file operations.
  - Actions:
    - Use `apply_patch` for file edits; group related changes and keep diffs scoped to approved steps.
    - Provide concise progress updates and a final summary of changes.
    - Validate appropriately: run `pnpm lint`, `pnpm format`, `pnpm build`, and relevant tests.
    - If material changes to the plan are needed, pause and return to `/plan` (or `/spec`) for approval.
  - Output: Implemented changes, validation results, and a concise change summary linked to the plan checklist.

### Plans Directory

- Location: `plans/` at the repository root.
- Filename: `YYYY-MM-DD-short-title.md` (kebab-case title; consistent dating).
- Style: Plan docs are the canonical source of truth for the implementation approach; avoid embedding change logs or “correction/更正” notes. Update the plan in place as decisions evolve.
- Contents:
  - Title and summary
  - Scope and linked specs (paths under `specs/`)
  - Assumptions / Out of scope
  - Step-by-step plan (short, verifiable)
  - Validation strategy (tests/lint/build)
  - Approval status and next stage
- Process:
  - During `/plan`, create or update the relevant file in `plans/` and share a short summary in the conversation. Await approval before `/do`.

经验之谈

主动让 Codex 调用特定工具：不要把所有的注意事项都写入到 AGENTS.md 中，用户还会需要担负一些心智针对不同的场景引导 Codex 使用更为合适的工具，比如用 git diff 可能更能提供准确的上下文。
尽可能在对话时提供完整的信息来源：Codex 查找代码的方式非常原始，如 grep, ripgrep 等，很有可能搜不到你想要的内容。比如你想要询问为什么实例化了两次，请顺带给出两次出现的地方：函数、文件名等信息，能减少 Codex 的误判或者搜索代码的时间。Codex 提供了 @ 快捷命令来帮助你快速搜索文件名。
网页搜索尽量使用网页端 ChatGPT-5-Thinking：搜索更快更完整，非常擅长对于 GitHub 项目的检索：包括不限于源码、项目结构、issue、PR等。特别适合了解某个开源项目的功能，单独开一个长对话和 ChatGPT 聊聊，受益良多。

总结

AI 工具日新月异，一个新的工具崛起，不要妄想能三分钟上手掌握，也不要过于依赖他人的博客文档和结论，AI 工具千人千面，每个人都有各自的编程习惯，需要花几天慢慢了解工具特性和背后的大语言模型习惯，根据自己的需求和喜好来调教独属于自己的 AI 工具。

面对新兴事物，莫要故步自封在一个工具上吊死，保持好奇心，勇于探索未知的可能。

参考资料

廿六：肉体苦弱

Mon, 16 Dec 2024 00:00:00 GMT

今年做了一些减法，休整了一年，恢复得不错，虽然身体更差了……

目前的状态就是工作日特别健康，周末有点嗨，不太好，不正常。时间上有些赶，索性想到啥写啥，明年咱们提前半个月写吧。

读书

今年没看什么书，倒是看了蛮多 LLM（大语言模型）相关的 Paper。我很想看书，但无奈主力阅读平台——微信读书非虚构方面实在没有什么能提得起兴趣的书。明年也许我会转投外文书籍，借助 Gemini 模型的翻译能力，阅读方面应该不会有太大的问题。

最近通勤时间变长了，我不得不网罗微信读书上有哪些值得阅读的书籍来消磨时间。

我在看书的时候思绪会发散的很开，这样也能写点东西。毕竟，每天看着自己精挑细选的笔记软件然后一个字没写……太痛苦了！我今年二十有余，空得了几份订阅，怎么得有他们诸多学识。

打造第二大脑

这是一本教你如何组织信息的书籍，帮助个人系统构建自己的知识库。在读这本书的时候，我才发现自己平时已经在使用书中提到的部分方法论了，只不过还没有形成一套系统。

这本书帮我脑海中不成形的笔记系统梳理了一套完整的系统方法论，所得甚多。无奈近期懒散，没啥笔记可写，这套东西我看明年能不能整理出来吧。

推荐和《卡片笔记写作法》一起读。

不上班咖啡馆

微信读书的用户倒是挺喜欢这类起着挺不着调名字的书，比如：《蛤蟆先生去看心理医生》、《也许你该找个人聊聊》……

相比于这类心理自愈书籍，我还是更喜欢大头书，只讲科学理论，倒是干脆得很，而不是像上面的书一个原理编几个小故事掰着讲给你，这种书，我最推荐跳着读。

吐槽了一堆，这本我倒是玩玩整整的看完了，整本都是故事。里面提到家庭主妇的困境挺有意思，这种情形还蛮常见：丈夫觉得自己上班辛苦，妻子觉得自己带孩子也很累，双方都觉得对方不理解自己。

游戏

今年夏季又回归了无畏契约，可悲的是也让我意识到了年龄带来的精力下降。对于这么一款高强度吃状态的 FPS 游戏，每天我只能保持最佳状态玩三把，再后续的游戏体验直线下降，整个人像喝了假酒一样，操作唐完了。以前那种能玩一天 FPS 的状态再也回不去了……

幸好在 Q4 出了一个三角洲行动的代餐，战地风格的对战游戏，算是治好了我的一部分电子阳痿。可惜这款游戏是个半成品，界面 UI/UX 全是赶工的痕迹，我的老弱 6600XT 在大战场模式下帧数总是狂掉，最终弃之。

要说今年单机圈的盛事，非《黑神话：悟空》的发布莫属。其相关二创的热闹程度，甚至远超 2022 年的《艾尔登法环》。游戏玩了40多小时，3080Ti +5800X 全程4K，帧数没关注过，但还是在部分场景下出现过掉帧，目前卡在第四章蝎子精那里（尾后针！），纯劈棍打法，最难的 BOSS 虎先锋，大概死了几十次，卡了我两天。

整个游戏最为人诟病的便是空气墙了，第一章属于熟悉地图，尚可，第二章地图设计满分，空气墙不打紧，第三章小西天真的要了老命了，大雪地认不清路，浪费了很多时间来来回回跑图认路。

个人评分：85分，它值得一件年度最佳的袈裟。

2025

每年的年度最佳游戏发布后，总要重温一遍《年度最佳の小曲》，看着视频中的弹幕，总感觉很快乐，游戏民纯粹的快乐。今年刷到 GTA5 时候，看到发售年份 2013 的时候感觉也没过多长时间，但算一算不止10年了，10年啊，我似乎已经失去对岁月的感知了。

至于即将到来的 2025 年，我想借用一位博主的年终主题，作为对明年的期许——在混沌中建立秩序。

Late Chunking：提高 RAG 在长上下文问答应用中的性能

Sun, 22 Sep 2024 00:00:00 GMT

Late Chunking：先做全文嵌入（embedding），再分块（chunk）。

随着大语言模型（LLM）的热潮，越来越多人希冀借助大语言模型来帮助整理、优化自身庞大的知识体系，即所谓知识库，简单点来说让大语言模型能够基于知识库来回答用户的问题。针对于这类问题，有一个常见的解决方案——RAG。

但是当知识库内容较多，且需要从知识库整体来获取相关的信息时，RAG 可能就无能为例了。为了更好的解释这一点，我们先来了解下 RAG 是如何处理知识库的。

RAG 文本处理

在 RAG 流程中，将知识库数据加载到 RAG 系统中后，下一步就是将知识库数据中的文本向量化（verctorize）并保存到向量数据库中，这就是文本处理的流程，共分为两步：

文本分块（Text Chunking）
嵌入生成（Embedding Generation）

整个文本处理过程可以用下图来表示：

文本分块

在这一步骤中，长文本被分割成较小的块（chunk）。

分块可以基于不同的标准进行，例如：

固定字符数（token）
句子边界（sentence）
段落边界
语义单元

分块的目的是将大型文档分解成更小的、独立的单元，这些单元可以单独处理，同时仍然保留原始文本的上下文和含义。

嵌入生成

一旦文本被分成块，每个块都会被转换成一个数值向量，这个过程就是嵌入（Embedding）。

关于 Embedding 的讲解，可以观看下面的视频获得更直观的理解。

https://www.bilibili.com/video/BV1Hk4y1X7aG/

使用场景限制

当用户查询时，会将查询文字转为 embedding，然后与上图得到的每个 embedding 计算相似度，最终取匹配度高的几个 embedding 对应的 chunk ，交由大语言模型（LLM）总结回答。

问题也就随之而来：由于是匹配分块，当需要基于全文信息了解时，匹配到的少量分块无法满足全文信息的提取，因而大语言模型也就无从得到正确的答案。

基于上述 RAG 的工作原理，我们可以总结出 RAG 在使用场景上的一些限制：

局部信息检索：RAG 擅长回答那些可以从单个或少量文本块中找到答案的问题，但对需要综合整个文档或多个文档的信息来回答的问题效果较差。
上下文丢失：由于文本被分割成小块，可能会导致上下文信息的丢失，特别是当问题需要跨越多个块的信息时。
长文档处理困难：对于非常长的文档，RAG 可能难以捕捉整体结构和主题，因为它主要依赖于局部相似性匹配。

Late Chunking

由 Jina 提出的 Late Chunking 方案相比传统方案显著提升了长文本信息检索的能力，简单来说，就是将原有的分块过程延后，利用长上下文能力的嵌入模型（Embedding Model），先对文本做嵌入，在进行分块。

让我们用一个具体的流程来对比两种解决方案：

Late Chunking

Naive Chunking

但是，这并非万能的灵丹妙药，Late Chunking 仍有缺陷：

需要硬件投入，无法利用现成的 Embedding API。

调用如 OpenAI 的 Embedding API，最终得到的不过是单一向量 (1, 1536)，其中 1536 为向量维度。而 Late Chuking 需要将全文做 Embedding，得到的是全文向量（token_nums, 1536）。

token_nums 取决于你的全文 token 数量，以 jinaai/jina-embeddings-v2-base-en 支持的 8192 token 数量为例，加入向量维度为 1536，则单次计算得到的向量为 (8192,1536)，然后将该向量分块，最终计算得到每个块的向量 (1, 1536)。

虽然相比于大语言模型所需的恐怖资源，嵌入模型（Embedding Model）所需资源不值一提，但对于一个 RAG 应用来说，还是带来了过高的运维成本，远没有调用一的 HTTP API 简单。

廿五：无题

Thu, 28 Dec 2023 00:00:00 GMT

就像在年底各大软件推出年度报告一样，年度总结之所以特殊，是因为在经历过漫长的一年后，人们总会想回忆下过去一年发生了什么，有哪些值得留恋的记忆。

今年真的是很特殊的一年，我的精神图腾破灭。

今年于我人生经历中最灰暗的一年，低迷状态在这一年中反复无常。

神圣时间线

年初回到了阔别多年的老家，自学生时代始，在老家过年的时间屈指可数，对家乡的印象也仅剩附近的几处房落。

整个春节差强人意，也第一次体验了相亲，不得不说，很无聊。我不需要婚姻来证明自己存在的意义，这个我们后面再聊。

春节期间，酒桌文化竟如此盛行，每一次都有亲戚起哄让我喝酒的，我不得不一次次拒绝（◍•﹏•），对酒精敬而远之。

三四月，沉迷于 ChatGPT 的消遣，玩了各种类型的 AI 产品。虽然 ChatGPT 不着调，但拿来做些脏活累活还是可以的，目前我已经离不开它了。

也是这个时候，我的状态出现了一些问题，整个人变得消极，对任何事物突然失去了兴趣，带来最明显的变化就是失眠，每天睡眠的时长只有四五小时，作息颠三倒四，我能活到现在也是年轻人身体好。

由于睡眠的不稳定，身体很快展开了报复：第一个赶到战场的就是耳鸣，日夜环绕，左耳听力基本丧失，只能感觉到外界嗡嗡声。

随着失眠的状态持续，头发开始疯狂掉🦲，面对着每日醒来满枕头的秀发，我最终还是忍痛剪掉了留了 8 个月的头发。

好在随着无畏契约的开服，借此全身心的沉浸游戏世界，终于在 11 月底一朝顿悟，消除了负面状态。

遗憾的是，我的大脑似乎出现了不可逆转的损伤，我丢失了一些记忆。

生活习惯

今年的睡眠一直不太好，每天早上都买杯瑞幸充当安慰剂，好在白天脑子还挺清醒。

由于睡眠不好，我一直避免剧烈运动，6 月时，精神状态有所好转，试着挑战了下了 30 天连续跑步，十三天后因小腿承受不住这么高的强度而告终，自此，今年再也没跑过步，抱歉。

烟酒可能早已成为了很多人的必需品，我今年再也没碰过。抽烟就不说了，害人害己。

今年春节因某人发酒疯而划上一个不完美的句号后，我也再没碰过任何酒精饮料。我不希望在非清醒时放纵自己，伤害他人。人之所以为人，是因为人拥有自己的人性，能克制自己的兽性。我有自己的底线，烟酒这辈子也不会碰。酒百害而无一利，睡前饮酒会严重影响深度睡眠导致睡眠碎片化，所以不要拿睡前小酌睡得香来安慰自己了。

开源

今年总算是跨出了零的突破，为了满足业务需求，所以给常用的前端 UI 组件库贡献了一丁点儿代码。实际的开源贡献并没有我想象的那么困难，可惜的是今年真没空，还有一堆想做的尚未实现。

随着年初 ChatGPT 的火爆，开源社区的活跃程度达到了前所未有的高度，所以我经常在 GitHub 上面逛寻找一些有趣的项目，顺带去浏览一些 UI 组件库的 Issues。通过研究他们的讨论和修复 Pull Request，学习他们的代码，逐渐学到了一些宝贵的经验。同时，我也发现自己遇到了一些依赖库的 BUG，由于水平太菜只好等大手子修复🥹，然后顺带学习下人家怎么修的，查漏补缺下。就这么偷偷看别人修 BUG，慢慢地也对项目熟络了。

由于我的技术栈，我会使用一些由企业维护的项目，时不时关注相关问题的处理情况。然而，这些项目并没有真正的社区氛围，只是冷冰冰的 Issue 和 PR，有时还会有一些用户在 Issue 中发泄不满，充满戾气地叫嚣：“你们这是什么项目啊，我被你们坑惨了，你们害人不浅哪！”( 🐶)

所以我一直没能体会到开源社区、氛围这类很虚幻的东西，直到某天看到 Vue 新版本的消息。出于对某个功能的好奇，我点进了它的 Pull Request，映入眼帘的是一长串的文本介绍，罗列了功能的目的、使用样例等，底下还有一大堆的跟帖讨论各种使用场景下的优缺点，以及一些变动的单独讨论帖。由于水平有限，有时我从社区讨论中才能理解一些新功能，感谢社区🥹！

项目维护者和社区双方充分地交换了意见，进行友好坦率地交流，增进彼此的了解，就此次变动表达了积极的态度（🐶

不清楚其他社区是否也有这样的氛围，但 Vue 的项目维护者能够为功能变动投入大量的额外工作，编写技术说明，完善文档，这种开放透明的开源投入对开发者来说无疑是一大福音。毕竟，大多数写代码的人都觉得写文档非常烦人，更不用说浅显易懂的文档需要付出多少心血。

这样的社区或许才会让 Vue 不断壮大！

婚姻

郑重声明！相比于去年，我让步了，我可以结冥婚，自然，我不是活着的那个。

众所周知，中国家长在孩子毕业后就开始催婚了，我也不例外。

过年时刚到家，就给我整了一出，吃完饭就带着我去找媒婆。出于好奇，我也想看看家里安排的相亲是怎样的流程。结果还是见面尬聊，无趣！而且总是碍于情面不好意思拒绝，不聊吧人家说你看不起别人（WTF😅），聊吧浪费时间。可恶啊，我的 7 天年休假！

年后还有一出，可惜的是那时心态出现了问题，人更加封闭了，由于不善拒绝，浪费彼此的时间，很抱歉给对方造成的困扰。

甲之，蜜糖，乙之砒霜。最近有个同学结婚了，这是我能从残存记忆中仍能辨析模样的人之一了有相识之人踏上了人生又一旅途，很高兴，也很羡慕。

婚姻甚至恋爱于我而言都是种压力和束缚。其实恋爱没啥束缚可言，毕竟法律可对恋爱关系中发生的纠纷没有任何保障，两人不欢而散谁也不欠谁，至于这场悲欢离合中浪费的时间精力，可没有任何补偿；婚姻才是，强势的一方总得给弱势的一方一些金钱安慰。只不过对于我来说，恋爱需要时间，如果一段感情走不到最后，不都是浪费时间嘛，有这时间我不如学学声乐课，找个健身教练，把我的游戏上一个段位，在家里躺着看游戏、足球直播多好。

人总是习惯于旧有的规则秩序，一旦打破就会无所适从。失恋无非是一时难以接受旧习惯的破坏，然新秩序尚未建立成型，于是沉溺于对于过去情感投入的怀恋，高看自己的付出，你说你那是喜欢嘛，只不过是占有欲在作怪，像丢失了玩具的孩童。为什么感觉这么像戒毒呢？哈哈。降低自己对于感情的期待吧，努力做好自己该做的。

对于婚姻，它应当是出自纯粹爱恋，想要的执子之手与子偕老的誓言。很遗憾，我是自私的，我做不到这一步，我很难理解牺牲自我而成就他人的那种崇高精神。我不相信任何人，也不理解为什么要把时间精力浪费在茫茫大众中寻找一个值得共度余生的人，没必要。我还有很多人生清单要完成，很多游戏要玩，我瓦还没上钻石呢！如今的现实虚拟有太多能够填补空缺的乐子，何必要浪费在一个未知的人身上，无趣。坏了，我成二次元了！

提到婚姻，难免不得不提到生育。人类女性是很可悲的，在当今的社会中，不少仍旧是充当着生育机器。我相信，有很多女性是不愿生育的，只不过受到丈夫、父母的指责等社会因素而选择生育。与此同时，不同于男性的生育能力，女性十月怀胎的特殊性，对其在职场上的晋升无斥于一个巨大的打击。于此同时，女性的孕育，对身体健康亦是一种巨大的摧残，因分娩孩童而丧命的数不胜数。因此，女性作为弱势的一方，理应受到优待，夫妻的生育应取决于女性的个人意愿，如果身为男性您觉得有所不公，那您结婚到底是为了您那宝贝儿子，还是出于爱情或陪伴的长情呢？

提及孩子，我很难赞同现有的社会价值观，我还是很赞同早婚早育的。年龄越大，选择也越少。

以上是我对未来粗浅的理解，我自认为对自己有太多道德约束，而从现如今的生活看来，我很难成为我想要成为的人，所以考虑到日后的生活琐事，还是不要给自己添麻烦的好，我很自私的。

还是希望情侣夫妻们能一直走到最后，不为外物所惑，因为我喜欢长长美美的爱情故事，祝好。

裁剪

我对自己的期望就是活到 30 岁就算成功，那时我仍有强健的体魄，充沛的精力和童稚般的好奇心，在这个时刻死去无疑是最好的恩赐了。至于之后的世界，每一天都是上天赏脸。

有了今年的经历，我的明年不再列有计划，好好睡觉吧！

永远不要只满足于世界的表象，要敢于探寻未知的可能。

明年见！

周报#9 burn out

Sun, 18 Jun 2023 00:00:00 GMT

本来写周报的目的是为了督促自己每周做一些有意义的事情，然后将其记录下来，不再那么浑浑噩噩的混日子。

但最近两周发现愈发地倦怠了，一方面因为依旧被病痛折磨，身体状态尚未恢复，与此同时带来的睡眠质量也不高，熬夜习性也有点要抬头的趋势。另一方面发现又处于burn out的状态了，大致表现的状态是对生活工作提不起兴趣，难以有效地投入精力去处理事务了，周末也是什么也不想干，只能勉强刷刷最近的足球新闻和游戏资讯了。

最近一直在跑步，每天5公里，本来想连续跑30天的，坚持到第12天时发现小腿扛不住了，需要更长的时间休息，于是只好作罢。跑步时，除了手表我并未带其他设备了，所以为了减缓跑步的痛苦，我最近会有意识地去思考一些东西，发现会进入一种浅显的心流状态，只可惜由于跑步时需要避让行人，经常会打断这个过程。

这周不得不提到一件囧事，在远程操作时，由于手太快没输入完成就按下了Enter键，导致最终输入了 rm -rf /etc 。吃一堑长一智，之后在实际环境操作中要更加小心。

周报#8 医院奔波

Sun, 11 Jun 2023 00:00:00 GMT

首先恭喜曼城夺得队史首个欧冠奖杯🏆，就是比赛不好看，感觉不如……世界杯。

本来这周想做一些好玩儿的事情，但是去医院检查了后发现还挺麻烦，确诊了「突发性耳聋」，于是每天下午都得去医院输液，这里倒想介绍一下看病的流程。

就医

首先是挂门诊（对应科室，挂号），到医院取挂号单，交给分诊台的护士扫一下挂号单上的病案号条形码，等待叫号。

医生看完后给开了个「听力检查」的单子，做完听力检查后去分诊台拿复查号再找一次医生，医生拿着「听力检查」的报告单做诊断，结果是让我去急诊输液。

急诊和门诊两个是完全不同的机构，我拿着诊断单来到急诊楼，找到大厅的护士姐姐说明情况，然后就是排队等待量血压和心率。

检测没问题后就是等待叫号了，流程和门诊一样。如果你只是输液的话，不需要提前挂号，直接去急诊走流程就行。当然，挂号费还是收的。不同于门诊，急诊的挂号费和诊断费是分开来计费的。

医生看完后，会开需要输液的药品单，拿着药品单交完费用后就可以去领药了。领到药后去输液室给护士姐姐，然后等待输液吧。输液结束后同样需要测量血压，有一台机器，自测就行。

这是我第一次完整的就医体验，拿着一个病案号条形码就能走完整个流程，我觉得还挺便捷的，就是有点废纸🤣，因为每个流程都会得到一些纸质凭证。

运动

达到50KM了，但是看了看年初定的1000KM目标，我觉得接下来的日子没得闲了。天气愈发炎热，心率已经压不住了。

关于爱情

最近看到许多或结婚或分手的事，还有些为了追女孩而把自己搞得狼狈不堪，智者不入爱河，这里留一段V站看到的话吧。

年轻的时候，觉得爱情就是一切，觉得女朋友就是一切，慢慢长大之后，发现不是的，父母都会离你而去，更何况女朋友，每个人都只能陪你走一段路，到站了就得下车。每一个人真正能做的，就是让自己习惯孤独的生活，你可以充实自己，可以磨砺自己，但是千万不能希望别人可以帮助你脱离这种孤独感。总而言之，你得有自我。有自我的人不孤独。楼主现在能做的，应该就是保证好自己的工作，学习，其他的交给时间，时间是一切伤痛的解药。

虽然每个人都有不同的追求，但没必要把自己弄得这么痛苦。

周报#7 耳朵伤病、被 uni-app 折磨

Sun, 04 Jun 2023 00:00:00 GMT

回来了，看了看上次周报时间，想不到已经一个半月没写了。生活终于重回了正轨，失而复得的分享欲也回来了。至于原因，也许会出现在第一个月报里。

本周过得还是挺艰难的，身体抱恙，工作上与 uni-app 斗智斗勇。

生活

周二起床左耳感觉被堵住了一样，而且还有嗡嗡的声音，并不像耳鸣那样尖锐，尝试掏耳朵也没有任何好转。

由于上个月跑医院太勤，这周懒得去了，于是就拖到了周末。本来预约了周日，但周六实在顶不住耳朵闷堵加上持续的异响就跑去了医院，结果挂号满了又只好回家。万万没想到，我最终还是康复了。

周日起床后，突然发现耳朵自己好了！为了保险起见还是去了医院，经过简单的问诊发现没问题，医生说可能自愈了，建议工作日做一个听力检查。

可能年纪大了，今年似乎病痛更多了。不过，这也可能这两年睡眠不足导致的。

提到睡眠，经过一个月的调整，本周的睡眠还不错，都能稳定在 8 小时以上了，梦回 18😭

经过了漫长的等待（摆烂），终于迎来了盛夏，天气热起来了，我终于鼓起斗志开始跑步，最近保持每天 5KM 的量，得益于本周耳朵的健康问题，我戒掉了戴耳机跑步的习惯，RIP LinkBuds🥹

跑步也确实不太适合戴耳机，因为运动起来噪音挺大的，想要听清楚就得调高音量。至于降噪耳机、骨传导之类，前者侵入式的设计对我这种油耳实在无法适应，而且长时间佩戴可能会造成耳道感染或炎症。后者漏音挺严重，更遑论音质了，感觉图一乐。

工作

啊啊啊啊啊啊啊啊啊啊，uni-app 我杀你一千遍都不够啊！

uni-app 是一个使用 Vue.js 开发所有前端应用的框架，开发者编写一套代码，可发布到 iOS、Android、Web（响应式）、以及各种小程序（微信/支付宝/百度/头条/飞书/QQ/快手/钉钉/淘宝）、快应用等多个平台。

uni-app 优点在于只需要前端知识就能写原生 App 了（骗你的🤡），缺点就是你需要对各类系统做适配，就我个人经验来看，Android 上能正常运行，iOS 一般不会出太大问题，反倒是小程序问题很大。

还有一个很大的问题就是文档太过零散，你需要慢慢「挖掘」🤡，善用内置的搜索系统翻其他开发者的问答。

本周在为原有的 App 做一个 Android 原生插件，这里特别感谢 ChatGPT！我对 Android 的掌握程度仅限于大学课程作业，开发期间遇到的问题只能询问 ChatGPT，没它我还真完成不了开发任务。

期间遇到最恶心的是 uni-app 文档描述不够清晰，很多注意事项没有在文档里说明，必须得结合网上的博客才能走完插件的开发步骤，这也是 uni-app 开发目前最为诟病的。之前逛 V 站的时候总有人吐槽 uni-app BUG 太多，但我觉得还正常，只要你别追 Vue 生态和 uni-app 的最新版本，BUG 相比很少会碰到。毕竟，我可是将 App 从 Vue2 升到 Vue3 的（叉腰😎）。

ChatGPT

热潮过后，很多人倒没以前那么吹捧 AI 了，我觉得这是一件好事，目前的 AI 就是扮演一个工作助手，它的强弱完全取决于主人的能力：Prompt + 思考 + 迭代。

拿我这周开发这个插件为例，其中我遇到一个很棘手的 BUG，原生 DEMO 可以正常运作，但 uni-app 上跑不起来。我抽象了关键 API，描述了问题原因，让 ChatGPT 帮我胡乱发散，生成黑盒代码，根据代码思考最终解决了问题。

你知道「小黄鸭调试法」吗？

这个故事描述了一个程序员如何带着一只橡皮鸭子，在遇到错误的时候逐行向它解释他的代码。当你向橡皮鸭子解释关于代码的一切时，你就更有可能发现隐藏在那里的错误。

目前的 ChatGPT 就像「橡皮小黄鸭」，但它更强大，能回答你的问题。面对陌生领域时，它又像一位老师，尽管这个老师满嘴跑火车，但它还是能给你启发，帮你找找问题。

One More Thing

头发已经能够扎起小辫子了🎉

ChatGPT Prompt Engineering for Developers 笔记

Sun, 30 Apr 2023 00:00:00 GMT

中文翻译视频

看完吴恩达的课程，总算对 Prompt 有一些系统性的认知了。

2-3 集

2-3 集还是蛮有用的，我之前的 Prompt 多少有些随意，导致结果不如人意。相信很多人都有这种问题，Prompt 更偏向于日常对话，更自然随意。需要重复对话多次修改才能得到满意的回答，但如果应用这两集提到的小技巧，可能就不需要修改那么多次。

给予清晰的提示，清晰不代表简短
- 善用分隔符，如 ```, """, < >, , :
- 返回结构化的数据，如 HTML、JSON等。
- 请求模型自己校验 Prompts 是否正确，不正确就不再执行。
- 少量提示，提供预期示例，让模型模仿预期结果输出。
通过指定分隔符，可以有效防止用户 Prompt 混入。

将用户输入通过分隔符包裹，分隔符可根据随机生成：
```
<{uuid}> {user input} </{uuid}>
请根据 {uuid} 标签内的内容，some prompts
```
给模型思考的时间 1）给出清晰的步骤，让模型按步骤解答 2）模型会回答听起来很有道理但实际上是错误的言论，想要减少这种行为的一个办法就是让模型：
- 找到相关引用
- 基于引用回答问题
（这不就是 New Bing 干的吗
迭代 Prompt 开发：Idea => Prompt 实现 => 实践 => 错误分析如此循环。

4-6 集

4-6集更像是对前三集知识点的应用实践，可快速略过。

第7集

第7集倒是帮我理解了 temperature 的作用，如果你有留意过一些自建 GPT Web 的配置的话，可能会注意到一个 temperature 的配置，像 Azure OpenAI RestAPI 中也有类似的参数。它代表着随机性，越大回复越随机。对我来说，保持默认0，不管就行。

第 8 集

第 8 集就有意思了，告诉你如何搭建一个聊天机器人，看不懂 OpenAI API 文档的人有救了🤣 role分为 system，user 和 assistant。

system 设定助手的行为和人设
user 就是用户发送的消息，也就是你。
assistant 是 GPT 返回的消息。

与模型的每次交互都是没有上下文记忆的，像 ChatGPT 那样有上下文记忆需要每次请求前把之前的记录都携带上，这就是为什么连续交流 Token 消耗会一直翻倍的原因。

参考

https://twitter.com/9hills/status/1652151966263570433

Azure OpenAI Service 申请流程和注意事项

Tue, 25 Apr 2023 00:00:00 GMT

前情提要

注册 Azure 账号

要申请 Azure OpenAI Service，首先需要一个 Azure 账号，点击 https://azure.microsoft.com/zh-cn/ 进行注册即可，这里注册的时候需要一个微软账号。也就是说，为了申请 OpenAI Service，你首先需要注册一个微软账号，然后再登录这个微软账号去开通 Azure，最后再去申请 OpenAI Service。

Azure 账号注册十分简单，填写内容不再赘述，按照要求填写即可，注意需要绑定信用卡才能注册成功，目前支持 VISA 和 MasterCard。

我使用的是虚拟信用卡，ChatGPT Plus 那里被拒绝了，这里很顺利。新号注册成功有 200美元的使用额度，不清楚能不能以此来白嫖 OpenAI Service。

申请 Azure OpenAI Service

Azure OpenAI Service 需要填写申请表单，经过审核后才能使用，这是申请链接 https://aka.ms/oai/access。

由于审核很严格，所以建议如实填写（也不一定，我就假填了一项😉）。

根据 https://v2ex.com/t/934490 提供的信息，申请有两种方案：教育邮箱和企业邮箱，你可以按照自己的情况自行选择，我选的是后者。

如果企业邮箱申请没通过可以试试你的学生邮箱（如果还有的话🫡

表单内容我并不会一一讲解，这里挑几个重要的解释下，请一定要认真阅读申请表单中的标红文字，让我们开始吧~

根据 fish 的分享：申请表单是由微软总部处理的，因此申请表单内容请使用英文填写。

第3项

这里选择几个，第四项就要填几个，为了避免麻烦我选了 1。

第5项（重要）

标红注释已经说明：个人邮箱会被拒绝，因此一定要填教育或企业邮箱。假设此处填写 xxx@example.com。

第6项（重要）

这里需要填写公司名称，不知道公司英文名称的，可以利用「企查查」去查一下公司的工商信息，如下：

下面几项地址信息没那么讲究，直接翻译成英文即可。

第12项（重要）

填写公司网站，还记得第五项里填写的邮箱地址吗，这里需要与邮箱地址一致，即此处需要为https://www.example.com。如果你的提供的网站信息与第6项公司信息对应不起来，可能也会失败。

曾看到有人说申请时需要企业邮箱、域名拥有者、公司名称「三码合一」，想必这也是卡住很多人的地方。

第13项

参考 fish 的分享，我认为打电话的几率不存在。因此我并未提供真实的电话，而是搜了一个本地的电信营业厅的电话填上去。

第14项

fish 就是这里挂掉了，不清楚这几个名词的可以自己查一下，嫌麻烦可以直接选 Other，然后填写自己公司经营的行业即可。

通常使用 Azure 的公司，都是做一些云服务产品的，因此我在这里填写的是 SaSS Service Based Cloud Service 。（感觉很怪😂

第17项

企业邮箱随意，教育邮箱填 Education。

第21项

看你地理位置，我选择 East US。

第22项

全选

第23&&25项

标红的不选，其余全选。

结语

恭喜你，终于填完了！

填完后企业邮箱会收到一封感谢信，告诉你会在10个工作日内回复申请，再过大概两小时会收到一个确认邮箱通知，点击邮件中的链接确认，等待通过吧🎉🎉🎉

教育邮箱和企业邮箱差不多，将企业信息换成学校就好，祝大家早日通过。至于如何使用，挖坑挖坑🥹

周报#6 原生家庭的影响

Sun, 16 Apr 2023 00:00:00 GMT

取次花丛懒回顾，半缘修道半缘君。

工作

项目快要上线了，近期一直在做测试和修改，但交付质量一直存在问题，结果堪忧。对于目前同事的代码质量我深受困扰，因为每次代码审查时总能发现或多或少的问题。大多数问题都是随便点点就能复现的，我也很难理解为什么总是检查不到，工作时间都浪费在代码审查上，心累。

前端目前 CRUD 基本技能已具备，后续工作重心会慢慢转到后端了，期待~

原生家庭

之前游戏圈超级小桀世界排名前30的游戏被熊孩子删档的事儿闹得沸沸扬扬的，今天追的 STN 快报提了下，就顺便补了切片，没想到超级小桀的原生家庭如此糟糕。

说起来，我也有些害怕原生家庭。我并未有不幸的童年，我很感激我的父母。可是我也不知道从什么时候起，很抗拒亲密关系，亲情对我来说就是记忆的载体，可随着记忆的模糊也越来越少了。这也是为什么我从来不肯透露自己住址的原因，我很厌烦有亲戚询问我的状况——你住哪儿啊，什么工作啊，有女朋友吗。工作后时间变得更紧凑了，我很抗拒将休息时间用来和亲戚打交道。

年初即将返程时，家里又闹了个大动静，详情写完我还是删掉了，人都有各自的不幸，就不乞求怜悯了。我只想说，喝酒、家暴的人都是纯纯的傻逼，内心怯懦且自不量力！

运动

上周信誓旦旦这个月要跑100KM，看来是完不成了🥹

连续跑步6天撑不住了，我是废物😋

本周分享

本来要分享一个 THORN 的体验评测的，但是也没时间，下周吧（也许

https://www.anthropic.com/claude-in-slack

ChatGPT 的平替产品，目前注册 Slack 就能使用了，个人体验和 GPT-3.5差不太多，而且响应更快，是个不错的替代品。

周报#5 AI时代，写作的意义

Sun, 09 Apr 2023 00:00:00 GMT

欲买桂花同载酒，终不似，少年游。

很抱歉鸽了周报和月报，上周在调整精神内耗和紊乱的作息，实在提不起分享欲😭但本周平均睡眠7小时36分钟，堂堂复活！

Midjourney 初体验

今年算是 AI 元年，随着 ChatGPT 的爆发，各种 AI 应用也随之兴起，很多产品都很棒，但深度使用下来，问题还是不少，还都是玩具级别。最有生产力的还是 Midjourney，在我这个外行看来，至少做个 App 可能都不需要找设计师了。这是我用自己的图片让 AI 生成的头像，效果确实不错。

<https://example.com/example.jpg（替换为自己的）> simple avatar, pixar, 3d rendering, --s 500 --iw 1.5 --v 5

同学小聚

周三和老同学们难得小聚了一次，这也算是毕业后第一次这么多人聚在一起。大家在一块儿聊聊现状，聊聊其他同学……那晚回家后，莫名有些伤感，不知为何，第二天脑子里也不断回想着他们的言语。可能年纪大了总有些怀旧，也许是从过去的人身上找回了过去的自己。记忆与现实交织，印记烙得可能格外的刺痛吧。

如今二十四岁，但我已经忘记当初刚踏入大学校门时的热血与梦想了，我为此感到很难过，也很悲哀。脑中的想法始终随着时间在变化，但我却没能把过去的自己记录下来。

写作的意义

上周鸽了周报和月度总结，就想着这周总要写点什么。一直苦恼于这周主题时，这段同学聚会让我想到了一个点子——写作的意义。目前的周报其实已经偏离了我的初心，我原本是想参考 潮流最前端·周刊 记录每周看到的一些新技术或者好玩的工具，就像周报#1 ChatGPT，全知并非全能那样，后来看到了 pseudoyu 分享的 life journel 形式的周报，便学着转变成了现在的样子。

一开始写得较为拘谨，并没有把所有的想法都写出来，现在我都是想到啥写啥，本来就没啥文笔，文章也没有章法，如今就更加随意了。Just for fun!

每完成一次周报，都像是完成了一次自我的救赎，虽然在文字中较少透漏自己的状态，但写完内心确实舒畅不少。我想这也是写作的意义之一，想要完成一篇文章，诉诸笔端时脑子里已经闪过无数的思绪了，而这些思绪平常不去刻意回想压根也不会被注意到，而等到了负面情绪堆积时，它们又成了压死骆驼的最后一根稻草，因此写作能够帮我解决不少这些平常隐藏的情绪问题。

第二个意义在于数字备份，自从 ChatGPT 兴起，我就在想能不能够利用自己的数据，构建一个自己的数字克隆体。想法也有些中二，即使在生命有限的时间内医学无法达到肉体不朽，但我的数字备份也能永存下去。

这个想法最初起源自 Copilot Hub,通过将王小波的文字喂给 AI，与之对话就像在于王小波对话一样。

不过当前想要训练自己的数字人的想法破灭于这周的一篇文章，AI 之路，任重道远。

我以前痴迷于数码时，曾看过钟文泽在一期节目中讲诉评测手机的图库做得很棒，能够以某种形式展示用户过去拍摄的照片。当时的我对此嗤之以鼻，觉得这个功能有啥大不了的，如今却觉得时常回忆过去亦值得聊以自慰。

就像朱炫所说的粗鄙之语：

我的想法随着生殖器的发育，始终在变。

人是很复杂的个体，正是这种复杂赋予人以高尚、宽容、慈悲、自私、嫉妒、愤恨……过往经历可能会使人成长，也会让人有很多变化，我很想将这些记录下来。

年初时，我收到了给未来写封信的一封信，是三年前的我写的，是过去的自己寄给现在的我的一封信。因为很愧疚过去自己的期望，信中内容我已刻意忘却，不再记得，但是当我收到这封漂流自过去的信时，我的第一反应是差异，感叹时光竟有如此大的魔力。在读书生涯填鸭式教学中，我并未感受到曾经某个阅读理解答案中对历史的感悟，但从这封信中我却悟到了历史的厚重。

我心中曾经执剑的少年，此刻也混迹在市井之间。

我想，这就是第三个意义，记录我的人生。无所谓自我排解，无所谓数字备份，只是为了能有一个媒介存储着过去的自己，可以让我能够查阅某一刻的想法，它可以是文字，也可以是图片或者视频。只是为了记录而记录，愿少年心不死。

欲买桂花同载酒，终不似，少年游！

本周分享

从备忘、分享、简历、记录人生经历、与外界保持联系多个方面讲述写技术博客的优势

Why You Should Write a Blog Post Today - DZone

移动端响应式 UI 设计

UI Adrian on Twitter

如何个人复盘的技巧

Mike_D on Twitter

基于 ChatGLM-6B，使用微信聊天记录创建自己的数字克隆人。看完有些失落，效果并不好，我也因此放弃了自己训练数据。

我用我的微信聊天记录和 280 篇博客文章，做了我自己的数字克隆AI

利用自己的照片使用 Midjourney 生成头像

别找了，用 Midjourney 为自己画个专属头像 | Jack‘s Space

周报#4 写作工具流

Sun, 26 Mar 2023 00:00:00 GMT

本来不打算写了，摸鱼刷 xLog 新增的时间流动态，被一个博客吸引，写了一大段评论后，「写瘾」犯了😭

工作

本周比较清闲，没有太多产出，主要工作从开发变成了上线前测试和维护文档的撰写。我算是体会到了写文档的痛苦，但了解一个项目时没有文档是真的要骂娘的。

在工作交流上，我一直有个毛病没法改：经常会临时找同事改一些BUG，但具体的实现方式又是脑子里临时想出来的，没法保证可靠性，再加上缺乏有效的测试环境，导致有些问题经常会翻来覆去的修改。

目前采取的做法是通过飞书文档记录，并把对应的文档与多维表格中的项目管理绑定起来，方便溯源排查。

写作工作流

我目前有三个平台的数据需要同步输出：Notion、GitHub、微信公众号。

Notion是我的主力写作编辑器，内容都是在这里创作的。体验过外面那些「搔首弄姿」的笔记软件后，我依旧会因为Notion简洁的外观和它强大的database，选择回归初心。
GitHub属于文字的Markdown版备份，我在上面建立了一个仓库，基于 Astro 搭建了个人博客网站，通过 Vercel 部署
微信公众号属于数据备份，因为前两者国内直连体验都不好，所以用作同步盘。

之前将Notion写的文章同步到微信公众号时，我是直接复制，但体验很差，后来发现了Notion converter - 笔记转换工具，可以一键复制，体验极佳。

上周，我又发现了墨滴，提供了网页端编辑器和许多排版主题，对代码极其友好，还能预览在手机端的效果，同步微信公众号的问题终于完美解决。

但是，三个平台同步依旧有个很大的问题没解决：图片。因为前两者网络访问不好，所以用它们做图床，在微信公众号上图片几乎加载不出来，用微信公众号作图床，在公众号以外的平台图片又会被屏蔽。

经过取舍和最大化效率考量，最终的方案如下：

在Notion写作，用到的图片上传到GitHub网页端编辑器，获取到返回的图片链接粘贴回Notion；
Notion写作完成，将所有图片上传到微信公众号素材库；
Notion内容复制到墨滴，排好版再复制到微信公众号，添加缺失的图片，完成！

周报#3 重启、自愈

Sun, 19 Mar 2023 00:00:00 GMT

失败的源头

自从毕业后，突然失去了为之奋斗的目标，一方面是养成的懈怠心，一方面是由于太过焦虑而不知道做些什么，通过游戏和视频麻木躲避，一直到了今年初。

可能是受推特润学和失败学大师 bboczeng 的影响，再加上裁员之风盛行，内部矛盾愈演愈烈，自媒体满嘴谎言的歌舞升平宣传，我充斥着满满的厌恶，想要逃离这里，想要去看我心中的世界。

但很可惜，我没有那个能力。当欲望大于能力时，我意识到自己恐怕难以逃离这个囚笼，也无法成才了。

我心中曾经执剑的少年，此刻也混迹在市井之间。

失败学的恐慌无时无刻不在我的脑子里到处乱串，尽管我依旧像平常一样上下班，也没有任何情绪上的波动，但我总有一种深深的无力与绝望。

自愈

我尝试了自我调节，不去关注互联网资讯，不去优秀的同龄人的信息，但效果依旧不是很好。很感谢相亲对象的邀约，吃了顿饭，也聊了些我的失败学。虽然安慰人的方式很直白、很失败（对不起（＞人＜；），我没有别的意思🥹但确实是这样），但这也给了我一个契机，一个观察真实内心的机会。

人总是会被自己无意识的想法缠绕，加上飞速的生活节奏，难以停下来审视自己真实的内心世界。通过一番谈话和自己模糊不清的失败学吐露，我知道，自己并不在意润不润得出去，在意的是自己被同龄人拉下太远了。

尽管对物质没有太多的追求，但内心的争强好胜依旧没被人生的两次失败所磨灭，只是两次失败让我失去了太多的资源，同龄人已将我完全甩开。我因此绝望，我因此懊恼，因此而逃避。幸好，我的自傲还在，我的学习能力尚可，我还年轻，我的未来依旧可期。

开源贡献

身为一个失败人士+菜🐶，这周破天荒地为 arco-design 提了俩 PR，已经被合并了，成就感满满，做开源真实太开心啦🥰🥰🥰。

两个PR都很简单，一个是 arco-plugins，它的默认图标前缀是空，导致引入时还需要增加一行配置，而我们使用图标时都是从网页上查找复制，它默认是有 icon- 前缀的，于是我就提了个默认前缀的 PR。

第二个PR是树组件（Tree）的一个 BUG 修复。起因是在实现限制选中的节点数量时，无法生效，通过 vue-devtools 查看组件事件，发现是更新update:selectedKeys 在 select 后面，导致 select 事件中更新 selectedKeys 依旧会被后续的 update:selectedKeys 改回原来的值，同样的问题还发生在 check 。

PR被合并后，我也不要脸地把 arco-design-vue 固定到了个人 Profile🤣。

GitHub Profile

参考了 pseudoyu 的模式，实现了将自己的博客文档自动同步到 Profile 仓库，同时利用 GitHub PAT (personal access token）实现了读取跑步仓库的私有文件。唯一遗憾的是，无法读取到微信读书的个人书架信息，只能每周手动更新了。

生活总是不完美的

我总是去期待自己成为想要成为的、获得想要得到的再去想其他的事情，比如谈恋爱、结婚生子。但现实终究「事与愿违是常态」，一路走来，我因为自己的任性妄为，失去了太多本可以属于我的。因为自己内心的懦弱与自卑，也辜负了很多人的好心与付出，我很惭愧。

有人说，生命是为了一生中那几次精彩时刻而活，我也曾是这么认为，并想要为之奋斗。终点固然璀璨乃至不朽，但沿途的平常风景亦是非常迷人啊，愿活在当下！

周报#2 懒狗的自我修养

Sun, 19 Feb 2023 00:00:00 GMT

上周的周报花费了太多无意义的时间，因此这周一直在思考如何最大程度地节省时间。

当前问题

我一直都是在Notion中创作，然后发布到微信公众号（国内备份）和个人网站（总备份……仍在建设中⛑️），但发现效率很低。

因为网络原因，Notion中图片无法在公众号中插入，所以我得在复制到公众号编辑器后，手动插入图片，由于我的图片大都是截图，没有存档，于是我还得去Notion下载原图然后插入公众号，十分繁琐耗时。
Notion文章同步到个人网站时，图片依旧是个问题，我需要将图片放到 public 文件夹下，然后根据相对路径手动引入图片，尽管已经有很多优秀Markdown编辑器能自动将文档和图片分类到对应文件夹，但图片存储依旧是个问题。

我需要一个简单的同步方案……Notion编辑完成，一键同步或者5分钟内手动同步到其他平台。

临时方案

目前较为简单的方式就是不加图片🤣，利用浏览器Notion converter - 笔记转换工具 - Microsoft Edge Addons复制到微信公众号，然后通过Notion的Markdown导出同步到个人网站，这也是我目前尝试的。

新的问题出现了，这个插件目前存在两个的问题，其一是复制到微信公众号时是Optima 字体，字体排版很难符合我的审美，只能再手动调整全局字体。其二则是无法复制emoji🤪

差强人意吧，目前看到微博Easy分享的自动化流程——方糖2A1B实验，给我打开了思路，也许可以从Mastodon方面做些文章，周报内容分享到Mastodon，然后每周自动整合成周报，期待下周的试验🥰

书籍分享

编程类书籍《Serverless核心技术和大规模实践》，Serverless科普书，内容尚可，后面都是介绍字节跳动自家的服务，对于我这个什么都不懂的小白来说足够了。嗯，也打消了我想要把一些服务落地到Serverless的想法。

周报#1 ChatGPT，全知并非全能

Sat, 11 Feb 2023 00:00:00 GMT

终于发布第一篇周刊了！周刊主要分享每周我所接触到的有意思的东西，涉及方方面面：书籍、播客、编程、软件、效率工具……

书籍

《为什么精英都是时间控》⭐⭐⭐

时间管理的书籍，往往给人一种空洞的感觉，但这本书却不同。它不是用冗长的理论来教你如何管理时间，而是从睡眠、运动等生活细节入手，教你如何在最佳的身体状态下，运用正确的时间观念，让时间为你所用。

软件

Artifact

Instagram创始人的新产品，一款个性化新闻App，类似国内的今日头条，也是利用AI来根据用户喜好推荐文章。需要注意的是目前没有注册入口，因此信息无法在多端同步，如果换手机或者应用卸载，以前的数据就找不回来了。

Bing

新版必应，集成了下一代GPT的全新搜索引擎，我也是今天刚收到通过waitlist的通知，试用了一下感觉比ChatGPT要更准确一点，但是需要更多的引导词（是的，你得好好调教一下🤣），Bing在回答中会给出数据来源的链接，对内容创作者更加友好。

Bing最大的优势是，响应速度远超ChatGPT，而ChatGPT要想达到这样的速度，您就得每月花20美元订阅Chat Plus，而且还不支持国内信用卡。

如果你想要体验新版Bing的话，需要先加入waitlist等待官方通知，链接：The New Bing - Learn More

以下为Bing和ChatGPT的回答对比：

图图裂了，找不到了~~

GPT相关产品

如果您对网上看到的ChatGPT的能力感到惊讶，却又不知道如何利用它，那么这两个网站可以为您提供一些指导和灵感。

周报生成器 (avemaria.fun)

如果您经常为了周报的内容而头痛，那么这款工具可以让您的周报更加精彩和有价值。

https://github.com/ycjcl868/readme-gpt

与「周报生成器类似」提供项目简介，自动生成对应的README.md

编程

vite-plugin-vue-component-preview

在代码编辑器中预览Vue3组件，无需编写页面测试！但目前存在bug，基于最新Vite创建，需要将 Preview() 改为 Preview.default()

command-not-found.com

这个网站可以帮助您解决在Linux上遇到的 Command not found 错误，提供此软件在各类Linux发行版上的安装命令。

Never write a commit message again (with the help of GPT-3) · Roger Zurawicki

利用GPT-3自动生成commit message 通常编写commit message时，只会使用笼统的术语概括内容，当变更文件太多时，有时候又会遗漏一些重要信息，利用AI可以全面的描述变动。

廿四，沉沦与挣扎

Fri, 09 Dec 2022 00:00:00 GMT

因为去年的总结写的匆匆忙忙，于是我从月初就开始写这篇总结，但一直因为拖延症延期到今天，索性还是流水账吧~

读书

今年最值得拿出来讲的可能就是读书了，今年破天荒的读完了 35 本书，没看完的不知凡几。我是坚定的电子书拥趸，主要在微信读书上看，翻了下统计数据，每周阅读量在 5-10 小时之间。

如今时代的书籍浩如烟海，值得阅读的却不多，这里罗列下值得一看的：

认知思维方面推荐《认知觉醒：开启自我改变的原动力》、《纳瓦尔宝典》和《打开心智》。
习惯养成推荐《福格行为模型》和《掌控习惯》，前者是方法论，后者是案例详细阐述。
知识管理推荐《卡片式笔记写作法》，这方面也是我最为苦恼的，没找到第二本值得读的书。
哲学推荐《哲学家们都干了些什么？》，读了这本书我才发现历史上的哲学家很多都是大数学家。
人物传记强推《邓小平时代》，唯一令我废寝忘食的一本书！
编程方面推荐《卓有成效的工程师》、《程序员修炼之道》，前端推荐阅读《Vue.js 设计与实现》

这么一看，今年读的好书还真不少，但是内化的却不多。读书不在量，而在感悟。读书过程中想到了什么、相通了什么，这些才是一本书能带给你的最宝贵的东西。

Your brain is for having ideas, not for holding.

因为大脑不善记忆，因此明年会努力定时回顾笔记，并加以实践。

媒体

今年我有意识的克制对于外界的探知，因为 99% 的信息都是垃圾，真正重要的信息总会通过各种渠道为你所知，比如二十大、疫情防控……

另一个原因则是现如今普通信息无法获得人的关注，因此网上吵得热火朝天的往往是夸张、冲击力强的消息。我受够了各种无趣的反转，永远义愤填膺，永远不知悔改，既然无法改变本性，不如主动拒绝。

游戏

我是一直拿游戏逃避现实的，因此我曾一度沉迷「守望先锋」。因为 PVP 太容易沉迷，所以今年尝试了单机游戏，结果发现又入了一个大坑，还好「艾尔登法环」的通关成功让我换上了电子 ED。

如今兴奋的阈值已经无限拔高，也许再一部比肩「艾尔登法环」的作品也无法打动我了。

重回了 Flomo，读完其 101 文档，我惊喜的发现，其背后的知识管理体系正是我苦苦追寻的。它简单舒适的输入体验，与微信的结合，大大提高了我输入的频率。自从网文写作弃坑后，已经很久没有创作的欲望了。其背后蕴藏的「卡片式笔记」的思想让我激发了我创作的热情，一直陆陆续续记录到现在。

当然，这款软件并不是完美的，功能太少，链接笔记虽有却似无，我仍缺少一款更好的笔记软件。就在这个时候，我发现了 Heptabase。Heptabase 我只云体验了一番，未能入手体验的原因自是其高昂的$83.88 年费价格，而且它还在公测阶段，产品尚未稳定，部分小功能的确实如鲠在喉，因此今年并未选择它。明年订阅预算充足的情况下，我会购入体验一番。

运动

生命在于运动，今年突然喜欢上了跑步。虽然因为种种原因没能继续跑下去，但跑步确实给我心态调节上带来了不少变化，计划明年完成每月 100km 的目标。

小区旁有家新开的健身房，办了张健身卡，准备等年初开业时就去锻炼。自从体重增加到 62kg 后，我的腹肌一去不复返，那是我逝去的青春……

感情（婚姻）

这段本不想提的，但是最近 B 站老给我推 UP 求婚、结婚……叔叔背大锅！

对很多人来说，婚姻是一种美好的伴侣关系，1+1>2 的力量确实能带给人们支持、爱与安全感，同时也不可避免的带来了压力与责任，限制了对未来生活的追求。

于我而言，我始终认为婚姻是悲哀的。因为我不曾看到过幸福的婚姻，只看到了疲于奔命。在过早的年纪束缚了年轻人的心，为了肩上的重任而奋斗。

抛去生活的蝇营狗苟，放眼宇宙，人类何其渺小！生命是无意义的，人应该在有限的生命里去探索未知的可能，去享受自己选择的生活，而不是被世俗所驱使着结婚生子，重复这个悲哀的轮回。

最后谈谈两性的关系，我认为男女之间只有三种关系：爱情、亲情和职业关系。前两者很好理解，重点谈谈最后一个，它更像是一个大类，我找不出合适的词汇描述，只好用「职业」指代。

「职业」关系在生活中很常见，比如师生、同事，这些职业间的正常交往关系都是「君子之交」。像旧爱、舔狗、互相看不上或者一厢情愿也可以归为「职业」一类，它们更像是一种敷衍，带着职业的假笑，或心知肚明，或蒙在鼓里。

当然，我对于爱情很期待的，不过可能性微乎其微。我是 INTJ 人格，一个自私的利己主义者。

祝大家都能相伴所爱~

总结

看了看时间，差不多就到这吧！生活中可以放浪形骸，思想不可！最后用我最喜欢的一段话结尾吧~

我听闻最美的故事，是公主死去了，屠龙的少年还在燃烧。

祝明年变得更强！

一只山鬼嘤嘤嘤 RSS

Codex Auth：一个纯本地的命令行工具，切换管理多个 Codex 账号

为什么需要多账号管理？

现有方案的问题

Codex Auth 是什么？

工作原理

核心功能

1. codex-auth list — 一览无余地查看所有账号

2. codex-auth add — 添加当前登录的账号

3. codex-auth switch — 灵活切换账号

交互式切换

非交互式切换

切换时的安全保障

4. codex-auth import — 智能导入认证文件

导入单个文件

批量导入整个文件夹

5. codex-auth remove — 移除不需要的账号

完整命令速查

已知限制

1. 额度显示的实时性问题

2. 已有会话不会自动重载

适合谁用？

写在最后

廿七：落子无悔

前言

序章：离职

第二章：探索

第三章：Vibe Vibe Vibe

第四章：生活状态

一些推荐

终章

万字长文：2025 年，我对 AI 编程的全部理解——Part 1

概述

LLM 原理

Prompt 演变

减少引导

身份认知

大道至简

开源闭源之争

远离营销

专注力与思考能力

并行开发的代价

关闭通知，主动掌控

文件即记忆

计划优先

结果为准

心态转变

一些错误实践

长时间运行没有意义

拿来主义

Codex 实践

模型选择

AGENTS.md

不要关心上下文

产品推荐

Amp Code

v0.app

ChatGPT

Grok

Gemini

构建比官方更顺手的 Codex，Skills 自动化同步上游

修改内容

1. 顶部状态栏

2. 协作模式的独立配置

3. 账号热切换

为什么要二次开发

功能起源

核心诉求

同步上游的工作流程

Skills 分享

致谢

OpenAI Codex App for Windows: 从零构建教程 (含安装包)

打包版本

下载 macOS 安装包

构建 Codex Windows App

观察者

单次执行结果

另一条构建路线

期望

感谢

1. `codex-auth list` — 一览无余地查看所有账号

2. `codex-auth add` — 添加当前登录的账号

3. `codex-auth switch` — 灵活切换账号

4. `codex-auth import` — 智能导入认证文件

5. `codex-auth remove` — 移除不需要的账号