这和把 Codex 开源了有啥区别啊，这也太牛了,直接把所有的模型接进 Codex 里....

Grok、Kimi、Claude、Gemini、DeepSeek、GLM、Qwen，甚至本地 Ollama

全部出现在 Codex 原生的模型选择列表里，和官方模型排在一起，切模型就跟切频道一样

这个项目就是opencodex，之前看到乌云推荐，就很想试下，现在实测已经非常舒服了

我之前就一直很肉疼一件事，我手里挂着四个订阅：Codex、Claude、Kimi 199、GLM

但我真正用掉的不到一半，月底全部作废，那我总不能每个客户端都用一下：kimi code用一下，claude code再切过去，然后再codex啊，每家都有自己的客户端

现在统一在 Codex 里切，真是爽翻了

三行搞定：

npm install -g @bitkyc08/opencodex ocx init ocx start

xAI、Kimi、Anthropic 都支持 OAuth 登录，key 都不用配

从今天开始，AI 可以接管你所有的网页浏览行为！

这句话不是我夸张，是 Codex 这次更新之后的真实状态

先说清楚一件容易被忽略的事，这个能力不是今天才有的，5 月份 Codex 出 Chrome 插件那波其实就已经能干这事了

但这次版本迭代之后，我实测体验上的差距是质变级别的
我去扒了一遍官方变更日志，挑出跟我们最相关的几个点：

1.支持你直接在codex app中导入cookie和密码

2.标签页不再乱了，以前它接管你已经打开的标签页会顺手开一堆 Tab Group，任务做完也不收拾，现在这个毛病改了，用完该还你的界面还是干净的

3.加了个开发者模式，本质是给了 Codex 一部分 Chrome DevTools 的权限，网络请求、控制台报错、页面运行时状态它都能看，写代码调 bug 这条路直接被打通

4.任务从本地草稿转到云端接着跑的时候，之前偶尔会丢标签页状态和你做的标注，现在这段过渡稳了很多

5.对 Google 文档、表格、幻灯片这类页面，读取上下文的准确度也专门做了优化

6.还新增了一个只读的 JS 沙盒，抓取页面结构化数据更快，也更准

这6点放在一起看，其实说明一件事，AI 浏览器这条赛道走到现在，拼的已经不是有没有这个功能，是这个功能用起来顺不顺手

但真正让接管浏览行为这件事成立的，还是底层那个更早就有的能力

以前的 AI 浏览器代理，能操作页面，但碰不了需要登录的网站，你的邮箱、后台系统、会员系统，它进不去

现在这个插件直接复用你 Chrome 里已经登录的会话状态，你不用把账号密码或者 token 交给它，它借用的是你当前的登录身份去干活

有朋友拿这功能扒同行素材，一句指令，链接全部列出来，一口气扒了小几十篇，理论上评论区互动数据也能一起打包

这只是冰山一角，真正的能力边界远不止抓帖子这么简单
它能在后台独立标签页跑任务，不占用你正在用的浏览器，你可以正常刷网页办公，它在旁边悄悄把活干完

多标签之间还能并行协同，配合刚才说的开发者模式，调试网页应用这种活它也接得住

这才是这次更新真正厉害的地方，不是能力从无到有，是从能用到好用

很多人觉得 AI 迭代够快，我就不用学了

等着 AI 喂饭吃就行

这是我见过最危险的想法

上个月和之前公司的 HR 朋友无意间聊天

我俩一致认为：现在招人的逻辑彻底变了，以前是招潜力股慢慢培养，现在直接要求上岗即价值产出

不会用 AI 的简历，连初筛都过不了，会用 AI 但不会萃取知识的，试用期就被淘汰

作为一个AI PM，我看到的真相是

AI 没有杀死工作，AI 其实杀死的是慢慢学的权利
2026年 AI 相关岗位需求暴涨74%，但入门级岗位反而在减少

为什么？
因为企业发现，培养一个新人的成本，够买三年 AI 工具订阅了
更关键的是AI 让老员工的生产力提升了30%以上，公司根本不需要那么多人

这意味着以后没有公司会花几年时间手把手教你，没有师傅会把踩过的坑整理成手册给你，你进来就得会干活，干不好就走人

职场的围城越来越严重了

这个时代既是时代红利，也是时代黑利的点在于：
会用 AI 武装自己、会萃取知识、会建知识库的人，会跑得比谁都快

等着公司给你铺路、等着别人喂饭的人，会被甩得连尾灯都看不见
AI 工具人人都能用，但能把 AI 变成自己认知杠杆的人，才是真正的超级个体

最近发现自己时常会出现一种“脑雾”状态

就是在某些事和某些场景缺乏最基础的逻辑认知，可能在别人看来就是你在这件事情上想的太少，或者你没有情商等等

当然别人说的这些我认为都是表象，这反而引发了我对于逻辑的思考

什么是逻辑思维呢？

细细想来，我们可以用尽量量化的角度思考这件事，我理解的逻辑思维：

通过遍历该事件所有的相关对象，遍历所有对象的相关属性，寻求多对象之间属性的因果连接

之所以会出现有些事情很有逻辑，是因为你之前有过类似的事件范围和对象

之所以出现有些事情没有逻辑，是因为之前从未预演过类似于该事件的范围和对象，还有因果连接

之所以对有些事一知半解，说的部分清楚部分含糊，是因为没有穷尽的思考这件事的对象和要素，但是对某些因果连接有体会

所以，想应用好逻辑思维

要么就有大量的实践

要么就有超绝的底层思考能力，能把对象，属性，因果思考清楚

何尝不像创业呢？一种是野路子，靠大量的试错

一种是顶尖人才，从一开始就很明确自己的目标和逻辑链

这个世界真是太有趣了，只不过只知其一不知其二的人会很痛苦

从今天开始，AI 可以接管你所有的网页浏览行为！这句话不是我夸张，是 Codex 这次更新之后的真实状态

先说清楚一件容易被忽略的事，这个能力不是今天才有的，5 月份 Codex 出 Chrome 插件那波其实就已经能干这事了

但这次版本迭代之后，我实测体验上的差距是质变级别的
我去扒了一遍官方变更日志，挑出跟我们最相关的几个点：

1.支持你直接在codex app中导入cookie和密码

2.标签页不再乱了，以前它接管你已经打开的标签页会顺手开一堆 Tab Group，任务做完也不收拾，现在这个毛病改了，用完该还你的界面还是干净的

3.加了个开发者模式，本质是给了 Codex 一部分 Chrome DevTools 的权限，网络请求、控制台报错、页面运行时状态它都能看，写代码调 bug 这条路直接被打通

4.任务从本地草稿转到云端接着跑的时候，之前偶尔会丢标签页状态和你做的标注，现在这段过渡稳了很多

5.对 Google 文档、表格、幻灯片这类页面，读取上下文的准确度也专门做了优化

6.还新增了一个只读的 JS 沙盒，抓取页面结构化数据更快，也更准

这6点放在一起看，其实说明一件事，AI 浏览器这条赛道走到现在，拼的已经不是有没有这个功能，是这个功能用起来顺不顺手

但真正让接管浏览行为这件事成立的，还是底层那个更早就有的能力

以前的 AI 浏览器代理，能操作页面，但碰不了需要登录的网站，你的邮箱、后台系统、会员系统，它进不去

现在这个插件直接复用你 Chrome 里已经登录的会话状态，你不用把账号密码或者 token 交给它，它借用的是你当前的登录身份去干活

有朋友拿这功能扒同行素材，一句指令，链接全部列出来，一口气扒了小几十篇，理论上评论区互动数据也能一起打包

这只是冰山一角，真正的能力边界远不止抓帖子这么简单
它能在后台独立标签页跑任务，不占用你正在用的浏览
器，你可以正常刷网页办公，它在旁边悄悄把活干完

多标签之间还能并行协同，配合刚才说的开发者模式，调试网页应用这种活它也接得住

这才是这次更新真正厉害的地方，不是能力从无到有，是从能用到好用

重磅来袭！我开源的这个skill，将使你的AI编程质量提升最起码1倍以上！！！

实测数据：我让它审计我自己的代码， 4 轮直接抓出 2 个 Claude Code 跑了几十遍都没发现的事实错误

一个 schema 字段读错了，一个文件位置引用指错了——这种藏在细节缝隙里的 bug，你让 Claude 自己 review 一百遍它绝对看不见，但是这种错误往往非常致命

为什么 Claude Code 自己抓不出这种错？

因为所有多模型协作方案（包括最近刷屏的 fable-advisor）都有同一个盲区：主模型调子模型的时候，上下文全靠塞 prompt 字符串，子模型看到多少全凭运气

相当于你给外包口头交代需求，10 句话有 9 句它听不明白
codex-bridge 走的是另一条路：

上下文不塞 prompt，外化成文件
Claude Code 调 Codex 之前，必须先把对话上下文、plan、相关文件、项目约定打包成结构化的 bundle 目录，调完拿回 JSON，用 jq 做机械校验

prompt 是口头交代，bundle 是签合同
角色分工也不一样：

大家都让子模型当打字工，我让 Codex 当细节补盲者——schema 字段、边界 case、测试覆盖、文档不一致、藏在代码里的隐藏假设，这些 Claude 单干必漏的东西，全交给它

四个场景开箱即用：
1️⃣ plan-review：Codex 审计你的 plan / 设计 / 代码
2️⃣ codify：Codex 真动手写代码
3️⃣ review-iteration：基于 review 让 Codex 改，硬上限两轮
4️⃣ verification-round：主轮 finding 提取成 pattern 再验证一遍

项目地址：github.com

装完说一句话就能跑，遇到问题评论区找我或者提 issue～

从使用AI到离开AI不会干活，已经四年了，说实话，用AI赚了不少钱
现在对于我来说最大的难题已经不是使用AI本身，而是如何用AI在有限的时间内，达到最好的效果
今年突然想明白了一件事：所有的生产力提升，本质上都是建立在agent循环之上的
作为一个从大厂 PM 转型的AI开发者，我过去两年一直在琢磨怎么让 AI 干活更快，直到最近我才意识到，方向可能一开始就偏了
我们之前讲 human in the loop，人在环中，人是质检员，AI 是实习生
但今年模型能力上来之后，完全不是这回事了，谁再提human in the loop，我只能说他不会用AI
真正能让你效率翻倍的杠杆已经不是人类在环中
而是你在同一件事上，设了多少个agent环
为什么多设几个环，就能把质量无限逼近你想要的效果？
因为今天的模型已经具备了相当强的反思能力，你把它上一轮的输出丢回给它，它是真的能看出问题的
但这里有个巨大的坑，我自己踩过
让一个 agent 自己反思自己，反思不了几轮就会开始摆烂
学术圈管这个叫思维退化：它明知道自己错了，还是会在同一个地方反复栽跟头
就像让你校对自己写的文章，你永远看不出自己的错别字，破局的方法简单：别让它一个人反思，给够它立场和角度
去年底有篇论文叫 Multi-Agent Reflexion，做法简单粗暴
一个 agent 干活，出错了不让它自己复盘，而是拉一群持不同立场的 agent 开批斗会
一个从逻辑挑刺，一个从事实挑刺，一个专门唱反调
就这么一改，推理和编程任务的准确率，直接把单模型自我反思甩在了身后
道理不复杂：反思的质量，取决于视角的数量
一个 agent 是员工，一群互相挑刺的 agent 才是组织
更狠的玩法是环上套环
前段时间两个香港学生，在 Karpathy 的自动研究框架上又套了一层循环
内环照常跑实验，外环只干一件事：反思内环的研究策略本身对不对
没换更强的模型，没加一分钱算力，效果直接翻了 5 倍
所以你看，同样的模型，同样的算力，产出的差距全在循环的设计上
以前 PM 的工作是给人排活
现在超级个体的工作，是给 agent 排立场：谁来干活，谁来挑刺，谁来验收，谁来反思整个流程
当然，这套机制起作用是有其要求的：
没有验收标准的循环不叫循环，叫原地打转，烧的是你的 token，攒的是一堆自我感觉良好
模型决定单次产出的下限，循环的设计决定最终结果的上限

不要用旧的 prompt 思维去套新的 Agentic Coding
作为一个用 Claude Code 跑了大半年项目的独立开发者，我最近越来越强烈地感受到一件事——模型不是瓶颈，我才是
以前模型弱的时候，输出拉胯你可以怪模型。现在 Fable 5 能自主跑几十步长任务，结果不对，问题大概率出在你给它的“需求文档”上
这个认知转变，可能是 2026 年下半年每个用 AI 干活的人最该搞明白的事

你和 AI 之间，隔着四层信息差（参考anthropic工程师的论文）
我把人和 AI 协作时的信息状态分成四层，搞清楚这个框架，后面所有方法论都能串起来：
第一层：已知的已知 — 你写在 prompt 里的东西，明确告诉 AI 要什么。这是大部分人唯一在做的事
第二层：已知的未知 — 你知道自己还没想清楚的部分，比如“这个交互逻辑我还没定”。至少你知道这里有坑
第三层：未知的已知 — 你觉得理所当然、根本不会写进 prompt 的东西，但 AI 不知道。比如你的项目从来不用 Redux，你不会特意说“别用 Redux”，但 AI 可能直接给你整一套上来
第四层：未知的未知 — 你压根没意识到的盲区。你不知道自己不知道什么
大部分人只覆盖了第一层。后面三层，AI 全靠猜
猜对了你觉得 AI 牛逼，猜错了你觉得 AI 垃圾。但问题从来不在模型身上
---

为什么现在这件事突然变得致命
因为模型能力到了一个临界点
以前模型本身能力有限，你给它一个模糊指令，输出质量的天花板本来就低，你的“信息差”造成的损耗被模型自身的弱鸡能力掩盖了——反正它也做不到多好
现在不一样了。Fable 5 一个 session 可能自主执行几十步决策。你开头埋下的一个模糊假设，会在后面几十步里像滚雪球一样被放大。Anthropic 内部研究了大约 40 万个 Claude Code session，覆盖 23.5 万用户，结论是人类主导了 70% 的规划决策
换句话说——你以为你在让 AI 干活，其实你在当产品经理。你的需求文档写得烂，再强的开发也救不了你
这跟我做 PM 那几年的认知完全一致：需求文档写得好的 PM，不是因为文笔好，而是因为他提前把模糊地带都想清楚了
---

落地 SOP：三个阶段，把你的盲区变成可控变量
阶段一：动手之前——做一次盲区扫描
在你开始让 AI 写代码之前，先问它一句：
> “我要做 X，但我对这块不太熟。帮我扫一遍我可能没意识到的盲区，找出那些我不知道自己不知道的东西，这样我能更好地给你下指令”
这一步的本质是承认自己不是全知的
大部分人不愿意做这一步，觉得浪费时间。但这恰恰是高手和普通人的分水岭——我观察到最强的那批 Agentic Coder，他们之所以强，不是因为 prompt 写得花哨，而是因为他们对自己要什么有极其清晰的认知，同时永远假设还有未知存在
另外一个我自己常用的方法是让 AI 反向面试你——告诉它你的大致想法，然后让它一个问题一个问题地问你，优先问那些“你的回答会影响整体架构”的问题。几轮下来，你会发现自己有多少东西是“以为想清楚了其实没有”
阶段二：实现过程中——让 AI 记录它的临场判断
再好的计划也会遇到意外。我的做法是让 Claude 维护一个 implementation-notes.md 文件，专门记录它在执行过程中遇到的边界情况和临时决策：
> “维护一个 implementation-notes.md。如果你遇到边界情况需要偏离计划，选保守方案，记录在‘偏离记录’下面，然后继续”
这招的精髓在于——你不需要预见所有问题，你只需要让问题可追溯。下次迭代的时候，这些记录就是你最好的学习材料。而且它还有一个隐藏好处：当你回头看这些“偏离记录”，你会发现很多都是你第三层和第四层的信息差导致的——这些就是你下次该提前写进 prompt 的东西
阶段三：完成之后——让 AI 考你
这是我觉得最反直觉但最有效的一招
代码写完了，diff 看完了，你觉得自己懂了。但我现在养成了一个习惯：让 Claude 针对这次改动出一份测验，只有我能答对才算真的理解了这次变更
> “我想确认我理解了这次改动的所有内容。给我生成一份报告，包含变更的上下文、直觉解释、具体做了什么，底部附一个测验”
为什么这有效？因为“看懂了”和“真懂了”之间差着一个数量级。你不测试自己，你就不知道自己的理解有多少是幻觉。而那些你答不上来的问题，恰恰就是你下一次协作时需要提前澄清的“未知”
---

底层逻辑：这不是 prompt engineering，是 requirement engineering
把上面三个阶段串起来，你会发现一个规律：
• 你越清楚自己要什么，AI 越能给你想要的
• 你越能预判 AI 会在哪里困惑，它越不会跑偏
• 你越愿意承认自己有盲区，AI 越能帮你补盲区
这套逻辑跟写 prompt 没有半毛钱关系。这是需求工程
模型能力的天花板已经高过大部分人的需求表达能力了。你的下一步不是学更花哨的 prompt 技巧，而是学会问自己一个问题：
我到底有多少东西，是我以为 AI 知道、但其实我从来没告诉过它的？
把这个问题想清楚，比换任何模型都管用

你觉得AI 开发真的快吗？

恕我直言，有时候我喜欢说点真话：

现在市面上90%以上的ai使用者用ai不光慢，而且还做的一坨，但是他们仍自诩自己为重度ai使用者/ai大神

当然我可能也包括在内

这句话反过来理解才对——AI 开发不快，快的是那些知道怎么驾驭它的人

今天上午我设计一个 loop 循环清洗数据计划，整个过程花了我全力运行的5个小时

5个小时，一个循环

不断纠错，不断补充细节，不断把 AI 拉回正轨

你以为 AI 开发的瓶颈是什么？是写代码慢？

不是，代码生成这件事，早就不是瓶颈了

Anthropic 自己也说了一句大实话——8倍代码产出不等于8倍生产力

传统开发为什么慢？两个原因

第一，产品开发本身就是手动完成产物，每一行代码都是人肉敲出来的

第二，沟通效率，跨部门沟通成本占项目总工时的30%到50%

现在换成 AI 开发，第一个问题解决了，代码生成的速度确实是指数级提升

但第二个问题不仅没消失，还换了一种形式卡住你

你的沟通对象从人变成了 AI

而 AI 开发真正的效率瓶颈是：AI 回复的等待时间，加上你不断让 AI 理解你想法的时间

这两个加在一起，就是你的新沟通成本

我今天上午那5个小时，在做的事情叫 Loop 工程——设计一个让 AI 自主循环执行的工作流，每一轮迭代自动清洗、校验、修正数据

听起来

但实际操作中，你会发现这件事对人的要求极高

我总结了三个核心能力，缺一个你都驾驭不了这个loop循环：

第一，你得知道 AI 最不擅长什么

你得清楚它会在哪里出错，什么情况下它能干好，什么情况下它一定会跑偏

这不是看几篇教程能学会的，这是你跟 AI 反复交手之后才有的判断力，一定是大量的实践迭代反馈总结

第二，你对目标和需求必须无比清晰

包括执行路径——不是“我大概想要什么”，而是“第一步做什么，第二步判断什么条件，第三步怎么兜底”

模糊的需求喂给 AI，AI 只会给你模糊的产出，然后你花三倍时间纠错

第三，你得有设计需求方案的能力

这是产品经理的底层功，也是 AI 时代最被低估的能力

你不是在写代码，你是在设计一个系统的运行逻辑

我现在越来越确信一件事：

AI 时代最值钱的能力不是 prompt engineering

提示词工程只是小范围的“正确”，需求工程才是一个人能力的体现，尤其是复杂架构下的复杂工程

这和我奉为圭臬的一句话是类似的：

真正优秀的产品经理一定具备能在复杂的业务环境下，抽丝剥茧找出最优解的方案，能以最小的代价置换最大的价值

ai时代同理，最重要的能力是：

你能不能把一个模糊的想法，拆解成 AI 可以执行的、颗粒度足够细的方案

传统开发时代，这个能力叫 B/M/P RD

工具从来不是瓶颈，驾驭工具的人才是

如果你没看懂这篇文章，那么请你直接喂给codex或者claude code

一位很有认知的粉丝留言，分享一下我的回复：

你好，简单回答下：

1.销售就是你离变现最近的地方，销售的本质就是你有别人没有，你可以好好思考一下自己现在有什么

2.决策标准得看你自己能不能耐得住寂寞，有没有定力，可惜大部分人是没有的

大部分人就应该遵循一个原则：应赚尽赚，找正反馈快，容易赚钱的事

3.交易本身确实是一条可以致富的路径，也是一个很好的曝光事件

但是这个和你的赛道没有必然联系
你在规划具体的落地方向的时候明显的颗粒度不够，没想清楚
真正执行的时候肯定需要再深入思考

4.思路没错，但是这样的事不多，很多时候我们往往陷入两难，这绝对是常见的事

面对这样的情况，一种视角能够很好的解决你的选择困难：把眼光放到10年后再看现在的你，你希望选择哪一个方向

短视未必是短视，任何选择都有其情景必然性，也会是多米诺骨牌的第一张第二张

最重要的就是，敢想敢干，想都是问题，做都是答案

起步最重要的事一定是：加快和外界建联的频率和深度，你能认真的写出你的问题，其实已经很棒了，加油！