即刻App年轻人的同好社区
下载
我个人更倾向是生态追赶上了有底气了。
因为接口协议这块最先取得优势的就是OPENAI的/completions /chat，其对后面的LLM以及生态应用都有着很深的影响，目前的开源llm server、model或pipeline方案中仍有固定的适配接口。
甚至在Claude Code初期，主流的操作都是用ccr，让/completions接口"屈尊"适配到Claude Code中。但后期Anthropic靠模型+CC占领了生态应用层，OPENAI当时的CodeX纯demo质量，且模型能力和交流友好度远远不如Claude，OPENAI反追的时间比较晚，所以生态这一块当时OPENAI是非常吃亏的。
之后就是全力追赶，OPENAI先追模型，在gpt-5.2中证明了自己的能力，后面开始发力生态，让CodeX变成一个正经的TUI，后面又推CodeX APP，直到现在。
之前其实也可以将第三方provider接入CodeX TUI，但我了解到的反馈都是非常难用不如CC。而现在的CodeX APP已变成体验最好的AI GUI应用之一。界面设计，动画渲染，交互友好度都很OK。现在如果让我接入的话我是非常乐意的。
因为接口协议这块最先取得优势的就是OPENAI的/completions /chat，其对后面的LLM以及生态应用都有着很深的影响，目前的开源llm server、model或pipeline方案中仍有固定的适配接口。
甚至在Claude Code初期，主流的操作都是用ccr，让/completions接口"屈尊"适配到Claude Code中。但后期Anthropic靠模型+CC占领了生态应用层，OPENAI当时的CodeX纯demo质量，且模型能力和交流友好度远远不如Claude，OPENAI反追的时间比较晚，所以生态这一块当时OPENAI是非常吃亏的。
之后就是全力追赶，OPENAI先追模型，在gpt-5.2中证明了自己的能力，后面开始发力生态，让CodeX变成一个正经的TUI，后面又推CodeX APP，直到现在。
之前其实也可以将第三方provider接入CodeX TUI，但我了解到的反馈都是非常难用不如CC。而现在的CodeX APP已变成体验最好的AI GUI应用之一。界面设计，动画渲染，交互友好度都很OK。现在如果让我接入的话我是非常乐意的。
志达: Codex OSS Mode 这步挺妙。 OpenAI 直接让 Codex 接入开源模型、本地 Ollama，只保留 Responses API 协议入口。Dario 越想把 Claude Code 收进围墙里，OpenAI 越把门打开。 「每与操反，事乃可成耳。」
3 00
看到又有朋友说AI掌握焦虑症了，我说一下我的个人主观想法吧。
这种问题在古法开发里面也是会存在的，比如需要负责架构的大量模块，业务带来的错综复杂关系很难让人保持持续高度清晰的状态；又比如目前各种包的引入，高度信服SDK的问题就是难以定位的可能的依赖包问题；又比如一些不可靠的问题，前端的努力败给了nginx的缓存，后端的设计败给了乌班图的奇思妙想，运维的勤恳败给了运营商的QOS。
这种不可抗力或者是难抵抗力都是真实存在且比较常见的。我觉得目前可能就是AI的产出效能比过高以至于都可以从人的感官去刷新共识了，所以会有一种虚妄感。而在项目负责的情况下，这种虚妄感会让人感觉到无法掌控全然未知的感觉，强责任感和弱掌控感一结合，就导致心里就不是那么舒服。
----------
我觉得这种情况可以抽离出来，抽离成简单的工作+检查就行。
既然这是AI写的，AI当前场景的目的就是拟人，那我就可以把它和人类工作放到统一地位评判。那如果我自己评估AI可以达到70%的我的能力，如果我写的能力洞察力有时候甚至不如它，那么我就可以认为它可以完全替代成某段时间我的工作。
AI和我一样也会去查资料查文档查优秀实践，也会去实现脚手架，也会在遇到依赖包藏答辩的时候选择绕过，也会去写一堆能交差的文档，那感觉也没差？
而且在快节奏的开发进程且新颖内容更容易有奶吃的情况下，我个人认为实现的比重慢慢赶上甚至是要超过效率的比重，而且非vibe时代，大家遇到依赖适配都得费劲半天，更何况现在这种堪比流式更新的stable发版呢。
检查这部分的话我个人觉得就是全方位测试用例覆盖+模拟用户真实操作。这个的话我感觉就有一种唬人投资一样，笔试分值全对，面试表现良好就没问题了。但实际上的情况古法时代的时候大家也无法掌控全面，现在的话更不需要多考虑了。
--------
上面是我的理解，我认为这种事很正常且不需要难受的。但有这个情绪肯定还是希望缓解的，毕竟嘟嘟脸总是不好的。
那么如何缓解呢？我个人认为就是去将这些内容都景观化，你所做的工作的掌控感可以用周报月报技术文档类的载体去表示，你的测试可以以测试文档，视频，截图等载体去进行表示。
那么AI能否出这种载体呢？我觉得是可以的：
1. SVG+ASCII的图可以去实现业务逻辑的快速交流，mermaid图可以在技术文档里面实现更丰富的流程展示，开发过程中也可以使用类superpowers的web交互或html交互实现方向选择。
2. 测试过程中除了单元测试冒烟测试等常规方案，还可以提供E2E测试，直接模拟用户测试，借助chrome devtools mcp之类的模拟操作工具去实现测试流程上的操作+留痕，自动生成有截图有流程的测试文档。
3. 提问老板化，如果你觉得哪里不靠谱，你就让AI用它所有的可能表现可能解释的形式去给你讲，说的歪就让他换说的不懂就让他揉碎，直到让你理解+信服。
这种情况我觉得可以很快去弥补载体的信息表现力差而带来的不明晰感和弱掌控感。
其实这目前也是一个非常非常值得关注的点。目前的AI和人类沟通非常容易出现高度差异。opus4.5和gpt-5.2告诉我们AI的上限已经合格了，所以能力ok，为啥出岔子呢，大概率就是交流不OK了，因为用AI的话算是请了个不太熟的“大拿”，个人的语言逻辑和AI不一定对胃口，也就容易出现理解上的偏差。
AI：文明，科技，历史
我：早饭，午饭，晚饭
就很。。。😂
所以好用的基础上其实是业务场景的求共识，那么这需要AI给出足够多针对于场景的业务理解，也需要有交互性足够好的表现形式和人类交流想法。现实场景也差不多，如果甲方是一个嘉豪的话，相比沟通场景也是非常难受的吧。。。
（突然想到前几个月，有个甲方要让我用一块3090，高精度百分百解决业界难题，把某修理界全部替代。我当时为了国家就业不得不忍痛拒绝了，我真善良啊啧啧）
交互这一块其实还是有很大的空间，我之前和d佬有类似的工作，当然不出意外，俩人都没做完；；
-----------------
如果还是无法缓解的话，那我推荐一个法子，极端化，既然恐惧失去，那就全部掌控，精读代码启动！
如果你觉得是代码屎山的话，就让llm去进行模块化拆分，从目录结构入手，从代码解耦入手，我在4.5时期就用这个法子，还比较ok，当时的promp是：
```
请你完整地阅读整个项目，然后对代码结构进行优化：
1.要求每个功能所处文件目录结构鲜明，如果涉及到子功能尽可能解耦（但也不要拆的太碎）。
2.要求代码结构鲜明，可读性高。
3.如果是某些页面或api的话，如果里面有一些功能需要解耦且其他部分用不到的话。请不要都归到lib里面，在对应目录创建components或lib作为对对应页面或api的支持。
4.要求有些简单的功能不要过于复杂化，有些实现可能永远用不到，这种的话就去掉吧，这个和需求1可能也有贴合。
5.清理你在往期实现过程中生成的MD文档、临时文件、测试文件等等
6.最后给我一个完整的MD文档，用于介绍这个项目。
7.（这个是年前加的）运行时优先使用并行推进以提升效率（如agent teams, agents蜂群）
```
类似的方法再加上足够丰富的文档应该可以缓解阅读成本。
如果只是为了缓解这个情绪和项目无关的话，那我建议定个目标，每周阅读类似🦞风格的项目代码。
当你历尽千辛万苦，写尽万千书卷文档，终于读懂代码的时候，作者一个“嘿嘿，我vibe的”，想必会让你很挫败吧，会让你不得不感叹“绰，费这劲干啥！”，那可能会很好的转变思路吧大概。
-----------------
当然除了自己还会有外部的情况，这个就像“房子烧了也还能活下来”一样，需要有一定的风险预期和宽容空间。如果under control，那就都ok。如果需要你真的每一行代码都去看的话，那你就需要借助AI真的要精读代码了，不过这种工作还是非常少见的，一般都需要一笔不错的报酬去支撑你前行，如果没那么多钱的话，那建议跑路🏃。如果是你在进行创业军备竞赛，那不妨想象你现在在精雕细琢的时候人家已经拿到投资做出demo拥有用户了，那我感觉也不是特别好吧大概。
我这边习惯将测试这个工作包出去，如果有问题我可以修，但是如果测不出来那就不是我的问题了。 我确实尽我所能了，测试本身就不是我当前精力能做的事情，我交给别人也是出于对项目的负责，如果真不行，那就是没辙，就像古法时代一些奇奇怪怪的问题一样，没辙就按没辙的做，毕竟很难去做到完全控制。当然现在的老板在乎的也很少了，就这快节奏的时代，他喵了个咪的这领导恨不得吃饭的时候就得让人做东西，既然大家都爱速度不爱质量，而产出与我无高强度感情的话，那大家就过家家吧，我留出精力去做我的事情了。
-----------
与其纠结AI产出虚无，不如纠结token虚无，鼠鼠的gpt 20x pro和 claude 20x max plan都被击毙了，现在正在四处打野采集token。
且行且珍惜吧只能说，fable+workflow的组合拳一出，A➗这就摆明抢钱了；O➗的5.5涨价+429也是不干好事。国模受国产显卡影响也不太好破局，只能说开发者珍惜现在吧；；
这种问题在古法开发里面也是会存在的，比如需要负责架构的大量模块，业务带来的错综复杂关系很难让人保持持续高度清晰的状态；又比如目前各种包的引入，高度信服SDK的问题就是难以定位的可能的依赖包问题；又比如一些不可靠的问题，前端的努力败给了nginx的缓存，后端的设计败给了乌班图的奇思妙想，运维的勤恳败给了运营商的QOS。
这种不可抗力或者是难抵抗力都是真实存在且比较常见的。我觉得目前可能就是AI的产出效能比过高以至于都可以从人的感官去刷新共识了，所以会有一种虚妄感。而在项目负责的情况下，这种虚妄感会让人感觉到无法掌控全然未知的感觉，强责任感和弱掌控感一结合，就导致心里就不是那么舒服。
----------
我觉得这种情况可以抽离出来，抽离成简单的工作+检查就行。
既然这是AI写的，AI当前场景的目的就是拟人，那我就可以把它和人类工作放到统一地位评判。那如果我自己评估AI可以达到70%的我的能力，如果我写的能力洞察力有时候甚至不如它，那么我就可以认为它可以完全替代成某段时间我的工作。
AI和我一样也会去查资料查文档查优秀实践，也会去实现脚手架，也会在遇到依赖包藏答辩的时候选择绕过，也会去写一堆能交差的文档，那感觉也没差？
而且在快节奏的开发进程且新颖内容更容易有奶吃的情况下，我个人认为实现的比重慢慢赶上甚至是要超过效率的比重，而且非vibe时代，大家遇到依赖适配都得费劲半天，更何况现在这种堪比流式更新的stable发版呢。
检查这部分的话我个人觉得就是全方位测试用例覆盖+模拟用户真实操作。这个的话我感觉就有一种唬人投资一样，笔试分值全对，面试表现良好就没问题了。但实际上的情况古法时代的时候大家也无法掌控全面，现在的话更不需要多考虑了。
--------
上面是我的理解，我认为这种事很正常且不需要难受的。但有这个情绪肯定还是希望缓解的，毕竟嘟嘟脸总是不好的。
那么如何缓解呢？我个人认为就是去将这些内容都景观化，你所做的工作的掌控感可以用周报月报技术文档类的载体去表示，你的测试可以以测试文档，视频，截图等载体去进行表示。
那么AI能否出这种载体呢？我觉得是可以的：
1. SVG+ASCII的图可以去实现业务逻辑的快速交流，mermaid图可以在技术文档里面实现更丰富的流程展示，开发过程中也可以使用类superpowers的web交互或html交互实现方向选择。
2. 测试过程中除了单元测试冒烟测试等常规方案，还可以提供E2E测试，直接模拟用户测试，借助chrome devtools mcp之类的模拟操作工具去实现测试流程上的操作+留痕，自动生成有截图有流程的测试文档。
3. 提问老板化，如果你觉得哪里不靠谱，你就让AI用它所有的可能表现可能解释的形式去给你讲，说的歪就让他换说的不懂就让他揉碎，直到让你理解+信服。
这种情况我觉得可以很快去弥补载体的信息表现力差而带来的不明晰感和弱掌控感。
其实这目前也是一个非常非常值得关注的点。目前的AI和人类沟通非常容易出现高度差异。opus4.5和gpt-5.2告诉我们AI的上限已经合格了，所以能力ok，为啥出岔子呢，大概率就是交流不OK了，因为用AI的话算是请了个不太熟的“大拿”，个人的语言逻辑和AI不一定对胃口，也就容易出现理解上的偏差。
AI：文明，科技，历史
我：早饭，午饭，晚饭
就很。。。😂
所以好用的基础上其实是业务场景的求共识，那么这需要AI给出足够多针对于场景的业务理解，也需要有交互性足够好的表现形式和人类交流想法。现实场景也差不多，如果甲方是一个嘉豪的话，相比沟通场景也是非常难受的吧。。。
（突然想到前几个月，有个甲方要让我用一块3090，高精度百分百解决业界难题，把某修理界全部替代。我当时为了国家就业不得不忍痛拒绝了，我真善良啊啧啧）
交互这一块其实还是有很大的空间，我之前和d佬有类似的工作，当然不出意外，俩人都没做完；；
-----------------
如果还是无法缓解的话，那我推荐一个法子，极端化，既然恐惧失去，那就全部掌控，精读代码启动！
如果你觉得是代码屎山的话，就让llm去进行模块化拆分，从目录结构入手，从代码解耦入手，我在4.5时期就用这个法子，还比较ok，当时的promp是：
```
请你完整地阅读整个项目，然后对代码结构进行优化：
1.要求每个功能所处文件目录结构鲜明，如果涉及到子功能尽可能解耦（但也不要拆的太碎）。
2.要求代码结构鲜明，可读性高。
3.如果是某些页面或api的话，如果里面有一些功能需要解耦且其他部分用不到的话。请不要都归到lib里面，在对应目录创建components或lib作为对对应页面或api的支持。
4.要求有些简单的功能不要过于复杂化，有些实现可能永远用不到，这种的话就去掉吧，这个和需求1可能也有贴合。
5.清理你在往期实现过程中生成的MD文档、临时文件、测试文件等等
6.最后给我一个完整的MD文档，用于介绍这个项目。
7.（这个是年前加的）运行时优先使用并行推进以提升效率（如agent teams, agents蜂群）
```
类似的方法再加上足够丰富的文档应该可以缓解阅读成本。
如果只是为了缓解这个情绪和项目无关的话，那我建议定个目标，每周阅读类似🦞风格的项目代码。
当你历尽千辛万苦，写尽万千书卷文档，终于读懂代码的时候，作者一个“嘿嘿，我vibe的”，想必会让你很挫败吧，会让你不得不感叹“绰，费这劲干啥！”，那可能会很好的转变思路吧大概。
-----------------
当然除了自己还会有外部的情况，这个就像“房子烧了也还能活下来”一样，需要有一定的风险预期和宽容空间。如果under control，那就都ok。如果需要你真的每一行代码都去看的话，那你就需要借助AI真的要精读代码了，不过这种工作还是非常少见的，一般都需要一笔不错的报酬去支撑你前行，如果没那么多钱的话，那建议跑路🏃。如果是你在进行创业军备竞赛，那不妨想象你现在在精雕细琢的时候人家已经拿到投资做出demo拥有用户了，那我感觉也不是特别好吧大概。
我这边习惯将测试这个工作包出去，如果有问题我可以修，但是如果测不出来那就不是我的问题了。 我确实尽我所能了，测试本身就不是我当前精力能做的事情，我交给别人也是出于对项目的负责，如果真不行，那就是没辙，就像古法时代一些奇奇怪怪的问题一样，没辙就按没辙的做，毕竟很难去做到完全控制。当然现在的老板在乎的也很少了，就这快节奏的时代，他喵了个咪的这领导恨不得吃饭的时候就得让人做东西，既然大家都爱速度不爱质量，而产出与我无高强度感情的话，那大家就过家家吧，我留出精力去做我的事情了。
-----------
与其纠结AI产出虚无，不如纠结token虚无，鼠鼠的gpt 20x pro和 claude 20x max plan都被击毙了，现在正在四处打野采集token。
且行且珍惜吧只能说，fable+workflow的组合拳一出，A➗这就摆明抢钱了；O➗的5.5涨价+429也是不干好事。国模受国产显卡影响也不太好破局，只能说开发者珍惜现在吧；；
4 12
fable5可以，不赖，有巅峰opus4.5的感觉了。
写prd确实明晰很多，基于代码对UI的理解，还有一些业务上的考虑都比较明晰。
就是成本高速度慢，且套路比较多（比如降级，拒绝回答什么的），建议找个羊毛渠道尝试，不要投入太多米。
写prd确实明晰很多，基于代码对UI的理解，还有一些业务上的考虑都比较明晰。
就是成本高速度慢，且套路比较多（比如降级，拒绝回答什么的），建议找个羊毛渠道尝试，不要投入太多米。
3 00
尊贵的ChatGPT Pro 20x会员的一天：
1. 前一天提交的pro任务发现被分流到mini模型
2. CODEX生图429，不知道哪个倒霉孩子吧pro用户的并发限制改成free的了
3. gpt-5.5 xhigh的think block都不如dsv4 flash max的长
4. 无尽的降智，我不知道是在下指挥还是在带孩子
5. 敲了半天的倍率算盘，结果被team和free中转平推
6. Tibo没说重置额度
web app降智，5.5倍率不如中转，gpt-image-2稳定性不如中转
那么什么赢了呢，可能是我的拳头赢（硬）了
希望明天O➗做个人
1. 前一天提交的pro任务发现被分流到mini模型
2. CODEX生图429，不知道哪个倒霉孩子吧pro用户的并发限制改成free的了
3. gpt-5.5 xhigh的think block都不如dsv4 flash max的长
4. 无尽的降智，我不知道是在下指挥还是在带孩子
5. 敲了半天的倍率算盘，结果被team和free中转平推
6. Tibo没说重置额度
web app降智，5.5倍率不如中转，gpt-image-2稳定性不如中转
那么什么赢了呢，可能是我的拳头赢（硬）了
希望明天O➗做个人
1 21
