# 手写代码的时代已经过去了：一次零基础的 vibe coding 全记录
**作者**: 独立开花卓富贵
**日期**: 2026-07-23T02:04:04.000Z
**来源**: [https://x.com/fuguizhuo/status/2080111673399287938](https://x.com/fuguizhuo/status/2080111673399287938)
---
花了一个月时间 ，完成了我的第一个前端产品：ReadCue。一个 AI 辅助阅读浏览器插件。我发现市面上没有专门针对阅读强化的 AI 插件，大多数是很多工具集合在一起，而且会员也很贵。刚好我在学习 AI 的一些技术。于是就打算利用 vibe coding 做一款插件，有摘要、阅读大纲、生成批判性评价的功能。用户可以免费使用，配置自己的 API key。这样既可以在真实产品里练习一下 AI 的使用，又能做一个自己用的产品。
从筹备到提交审核花了 1 个月的时间。我以前是写 iOS 的，没有前端基础。完全利用 AI 完成一个项目也是一个全新的体验。不得不说现在 AI 已经完全重塑了软件的开发方式。不过相比于自媒体喜欢宣传的银弹式万能 AI，实际开发过程中还是有很多和预期不一样的地方。因此分享一下我的经验。
## 使用的工具：Claude Code
做产品的第一步肯定是确认产品需求了。在产品的原始概念、技术可行性探讨中，同样的问题我对比了几个模型：Claude Opus、GPT 5.5、Kimi 2.6。GLM 入门会员买不着，所以就算了。最终发现 Claude 最好，于是我买了 20 刀一个月的入门会员。GPT 我也一直买的是入门的 Plus 会员。所以我的主力开发工具就是 Claude Code，偶尔配合 Codex。
IDE 我使用 Cursor。我觉得无论如何总会有需要看代码的时候。用 Cursor 主要是以前买的会员还没过期。毕竟前 Claude Code 时代一直用这个。现在确实用 VS Code 或者国产的 Trae 应该都没什么区别，看个人习惯了。
我用到 IDE 的场景有三个：
- 编辑 md 文档。我会把一些产品背景文档，技术讨论方案留在 docs 下面。直接在 IDE 里面修改方便。
- 一个 feature 完成后会稍微 review 一下代码的 diff。如果结构影响面比较大，会让 AI 更新一下 CLAUDE.md。如果发现实现的代码职责有一点乱，某个文件已经代码过长，后面就会进入重构。
- IDE 一些警告的修复。IDE 的警告都带有直接的行号，直接在 IDE 里面修复一下非常方便。一般 IDE 里的 Codex、Claude 插件我就会配置中等的模型。有警告、或者对某个函数有疑问，直接选中在插件里聊天方便很多。
## 全新的原型实现范式：HTML & Claude Design
完全没想到 HTML 会在 AI 时代迎来一波文艺复兴。这个互联网诞生之初的协议，在几十年后焕发了第二春。它的新语义：基于文本的跨平台的可交互内容载体。因为开源的网页代码量很多，AI 的网页生成质量非常高。于是 HTML 成了 AI 时代下生成可交互内容的新宠儿。基于网页做 ppt，生成可交互原型开始流行起来。甚至还产生了基于网页生成视频的方案。
用可交互网页去展示原型和设计，我觉得称得上是一场革命，是一次巨大的范式升级。
从前的原型只能使用静态的线框图展示，对于数据的流动、交互很难体现出来。虽然有一些方案可以在线框图上做点击区域，标记跳转到下一个页面。但是离完整展示交互意图还是差了很多。设计图也是静态的。对于开发来说，从原型、设计到开发中间都有着严格的“物种”级隔离。完全不同的数据语言，而且距离最后真实的软件状态都有着先天的模拟缺失。这样无形中也增加了产品经理、设计师、研发三者间的沟通成本。
然而高保真的、带完整交互的网页打破了三者的藩篱，成为了版本之子。网页可以承载完整的交互，也可以承载高保真的设计（虽然此时还并不能保证100%的像素还原，但是这条技术路径是通的）。产品经理和设计师可以在同一份网页上进行流程流转，这份网页（需求产物）到开发手上也是高度可用的。开发可以让 agent 根据这份高完成度的需求文档直接进入开发。当然在 plan 的时候还需要做一些技术决策，但是对产品需求、设计样式是高度清晰的。生产关系适应生产力，这种范式的转变我们也看到传统的产品经理、设计师的职责边界也发生了变化。
这次我做产品，原型和设计都是在 Claude Design 里面完成。
新项目可以选择一套 design system 进行调整。原有的项目可以设置从现有的项目里生成，当然自己导入也可以。
有了设计系统以后只要描述需求让它生成网页就可以了。生成的网页可以在 edit 模式下直接点选编辑属性。可以选中元素后标注修改意见发送给模型，有一种指哪打哪的快感。 调整满意后有两种方式交付结果。一种是通过 MCP 分享给 Claude Code。还有一种是导出 HTML 包。前期的交流可以通过发送链接在互联网上查看。
因为我做的是前端项目，所以 Claude Design 里的效果可以 100% 实现到真实项目中。第一次一个人完成整个回路还是非常震惊，如 Sam 般瘫坐在椅子前。 顺带说一下，如果没有 Claude 会员，使用 open design 也是一个相当不错的选择。Open design 本身是免费的，迭代还是挺快的。
不过设计类的 Agent 每次都需要全量的读写全部的网页，因此消耗 token 也很快。我看了别人的建议说设计推荐用 Opus，结果就是 20 刀的 Pro 完全不够用。最终只能咬牙升级了 Max。
## 滞后的 Figma
在 4 月的时候，我尝试过用 MCP 连接 Figma，直接在项目里生成 UI，但效果不太理想：像 ScrollView、Grid 这类组件生成出来常常和预期对不上，阴影、渐变色这些设计细节也经常还原不到位。
原因大概有两个。一是静态设计图本身信息量有限，很难准确传达设计意图——比如某个区域是否支持横向滚动，光看图很难看出来；复杂一点的 Grid 布局，AI 理解错也情有可原，毕竟同一张设计图，人类开发者有时候也会理解错。二是 Figma 的设计内容本质上不是原生 HTML，AI 在读取、转换的过程中难免出现理解偏差。
我还试过把 Whimsical（一款原型设计工具）接入 Claude，通过 MCP 把 PRD 直接生成线框图，效果同样一般。Whimsical 也有自己的一套自定义元素和 DSL 来描述内容，AI 在输出 UI 之前得先"现学"一门方言，词不达意也就在所难免。
总结下来，很多设计平台都有自己的一套私有协议，通过 MCP 转译生成设计，多少都会有损耗。相比之下，当下用 HTML 作为"数据层"的效果要好得多。所以从技术路径上看，我很看好基于 HTML 做富媒体数据层这个方向。
## 传统手写代码的时代已经过去了
自从 AI 开始接入编程领域后，业内经常讨论的问题都是还有多少代码是手写的。最初的时候只是函数级别的自动 tab 补全。在 Sonnet 4.0 的时候我的印象还是只能生成单个文件级的代码。在代码的架构组织上，跨文件的 feature 级功能交给 AI 还是和不放心。我个人体验的转折点是 Opus 4.5。在 Plan mode 下确定好开发计划，已经能生成很高完成度的代码了。此时的核心议题已经不是 AI 能不能写代码了。变成了如何 harness，如何约束强大的代码生成能力在正确的轨道上。
这次的项目是一个全新的前端项目（ts + react），到完成的时候都不需要我写一行代码。也就是现在我才确信手写代码的时代已经过去了。代码生成领域，跨过可用性的拐点是多个因素同时进步的结果，模型的参数量、上下文、Coding agent 都在快速成长。叠加上 LLM 天生就学习了很多高质量的代码。原来我觉得摩尔定律 18 个月翻一番已经很不可思议，没想到 llm 在 scaling law 指导下力大砖飞，居然成长的这么快。
这里特别震撼的原因不是 AI 有能力替代古法手写代码，而是渗透率是如此之快。Claude Code 和 Sonnet 3.7 在 25 年 2 月发布的。也就是在 1 年左右的时间里，完成了一个行业的颠覆。对比一下，电力从开始在城市中应用到普及，花了大概十年的时间。哪怕是近的移动互联网，从 3G 开始商用到发放 4G 牌照应用也花了 5 年时间。一年时间里，一项延续了几十年的高薪白领技能就贬值了。
这次的技术革命的性质和印刷术很像。以前掌握文字书写是一项高级的技能，但是同时很多“文字工作者”的工作也很乏味，只是抄写一些经书。印刷术流行了之后，书籍抄写员就消失在了历史洪流中。
不过我并不认为这意味着程序员这个职业就不再需要了，只是现在有了更高的抽象层次的编程。使用自然语言完成功能的构建。软件作为一个数字产品，软件工程的体系依然有存在的必要。只是现在的生产关系需要重新适应生产力。
## 开发流程的重构
这里要澄清一个观点：能运行的代码和能被维护的代码是不同的。
我前面提到的整个项目我不需要手写代码，并不意味着我没看代码。我接受的标准是，在给出清晰的上下文和目标后，能生成可维护的代码。
这和构建一次性的玩具原型项目的标准是不同的。Demo 级的项目可以不用管代码是因为最终交付物验证过后，原有的代码就不再需要被改动了。然而真实的项目是慢慢成长的，会进行一个个版本迭代。每一轮迭代都需要在原始的代码上构建。原来的代码就像地基。原始代码如果可维护性、扩展行不好，迭代到后面的成本就会越来越高。最终会因为项目过于混乱产生很多 bug。
我的开发流程
第一步：需求讨论输出原始 PRD。 会写一个粗糙的需求文档，尽量把背景、目标交代清楚。然后放到 Claude Code 里，先进行一轮需求讨论。这个时候明确要求不要关注实现细节，主要讨论需求的可行性、合理性。在确定了大的方向后让 AI 输出一版 PRD。这里也有可能发现想做的功能实现太复杂，不做了或者推迟到未来。
第二步：Claude Design 进一步确认需求设计。 接着我把原始 PRD 丢进 Claude Design，让 Claude Design 输出设计。因为我的项目规模小，我都是直接输出高保真设计。如果是大型项目的话，这里也可以让它输出线框图。在这个过程中会发现很多交互和设计和你想象的不一样，因为你一开始想要的只是一个功能，对于具体怎么交互，在现有的产品里面如何接入这个需求，和它最后的数据的流转，都是很模糊的。现在生成了一个可交互的设计，你就可以来验证这个功能是不是你想要的，确认它的设计细节。在 Claude Design 满意以后就会导出一份 HTML。这个时候有可能对原始 PRD 也会进行一些修改，把一些调整的交互设计也写到这个原始的 PRD 里。
补充一个实用技能：prototype。 这是 Matt Pocock 里的技能，它的作用是探索产品实现路径，明确生成的是可抛弃代码，在项目中快速生成几个草稿方案。很多设计假想效果不好，如果有原型选择对于做出决策会有很大帮助。有的时候布局方案我会让 prototype 生成几个方案我来选，这样就很容易看出来哪个好一些。
第三步：根据 PRD、设计文档制定开发计划。 这里我用的 mattpocock-skills grill with docs skill。我会把 PRD、设计文档拖到 Claude Code 里，调用 grill with docs。这步的作用是让 AI 向我提问。AI 会从实现这个功能的角度进行很多提问，大到技术方案，小到交互细节。这个拷问的过程也会加深你对这个功能会被如何实现的理解。这个技能也会根据你的回答自动整理记录架构决策、Context。到所有实现路径都确认好后，会调用 to-spec 技能，生成一份开发计划。如果这个功能依然很大，在 to-spec 后再调用 to-tickets。to-tickets 会根据 spec 拆分成不同的具体子任务，可以选择这些 tickets 是放在本地还是同步到 GitHub issues 里。
第四步：实现。 有了这个 spec 后，结合前面的 PRD、设计文档，后续可以把开发任务派给其他 coding agent 也是可以的。我也有看到人说这里的实现可以用中等的模型。我觉得这个建议是很合理的。不过更重要的建议是在规划功能的时候一定要有高思考密度模型（Opus、GPT Sol）。前期的探索、规划模型的思考广度、深度会后面的实现影响非常巨大。确定了 spec 后我有的时候会开一个新会话使用 Sonnet 5 实现，有的时候会切到 Codex 实现。Codex 在有明确需求的情况下，编码实现真的很稳！在实现的时候也会有两种选择路径，一个是选择自带的 plan 模式，一个是使用 Matt 里的 implement 技能。Implement 技能没什么魔法，只不过会强调一下 TDD。Plan 模式的优点是可以看到具体实现的接口、方法。如果我对某个 ticket 关心具体实现我就会使用 plan mode。如果不关心就会直接 implement。
以前我也用 superpowers，但是后来我放弃了。我觉得 superpowers 对我这样的项目来说太重了，它模拟了传统的大型软件开发流程。但是我觉得 AI 时代下可以进行一些简化了，Matt 的这一套技能工作流比较符合我的使用场景。
第五步： 检查是否需要重构，improve-codebase-architecture。 一个核心功能实现的时候，我有两个地方可以检查架构。一个是 plan mode 下实现 ticket 的开发计划，这里会看如何组织类、定义接口。一个是完成后我会看下核心文件的 diff，看下实现是否优雅。两个地方我会至少选择一个检查。如果我前期在 plan 的时候看了，那么实现的时候我可能就不看具体代码了。如果前期是一整个实现下来的，那我就会在提交之前看一下改动。判断是否需要重构我主要关注点：一个文件是否行数过大了，一般超过 500 行我会特别关注；是否有复用已有的组件、hook；一个功能的实现是否改动了太多地方，需要重新封装。这块的判断和我以前写代码的判断是一样的，看了代码实现后感知到坏味道，然后觉得需要重构了。现在的重构比手写的时候简单多了，我会调用 improve-codebase-architecture 技能，把我认为可疑的代码文件或者某个原因直接告诉它。它就会去分析这个文件，生成一份重构建议报告。最后你在报告里选出方案就可以了。
在清晰的需求 PRD、设计文件、开发计划的支撑下，AI 已经能独立高质量地实现功能，不需要我再介入编码。通过 plan mode 阶段审视开发计划、完成后 review 核心代码 diff，我依然对代码实现保有掌控。这个流程下，虽然我没有手写一行代码，但对项目的工程质量、可维护性和可扩展性，我依然有底气。不需要手写代码，不代表不需要关注代码。
找到新杠杠
> 我们正处在一个工具能力不断外包，但判断责任重新回到个体身上的时代。AI 可以极大地放大执行效率，却无法替你决定目标；可以降低行动门槛，却无法替你承担选择后果。工具越强，方向就越重要。 --《AI 时代的认知觉醒》
当下 AI 的能力在写执行代码的环节里已经可以取代程序员了。在 AI 辅助下，关注点变成了 harness：如何让 AI 写出我们想要的代码。在写代码上程序员已经没有优势，但是从写代码到最后交付一个高质量的软件中间还是需要程序员的参与。在代码生成环节里，人已经不在环里，在交付整个软件的环里，还是需要人类的参与。
程序员参与的维度我分为两个层面。
在代码层面，程序员需要关注软件的架构。 确保代码的健壮和可维护性。当下 AI 的上下文窗口依然有限，AI 写代码的时候并不能把注意力投射到整个代码库。因此 AI 写出的代码可能只是局部最优，但是全局上看可能就会有问题。比如有的时候会忽略复用，有的时候倾向于在现有架构上打补丁实现。不过这块也许未来也会被慢慢取代，说到底还是在写代码。也许未来会有一个架构师 sub agent，每天或者每周扫描整个代码库，进行架构重构。技术上是完全可行的。不过在此时此刻还是需要程序员参与，本质的原因是代码最终需要有责任人。 谁来确认生成的代码是好的呢？AI 的代码里有 99.9% 是正确的，万一那错的 0.1% 引发的是核心 bug 呢？
产品层面，AI 在写代码的时候不知道全部的产品上下文，AI 不参与定义产品。 同样一个功能，正确的代码实现路径可以有很多条。需要有人来决定选择那一条路。这个决策有的时候和产品规划有关，有的时候和外部的团队有关，这些无法在开始的时候 100% 传达给 AI。很多上下文在 AI 写代码的时候是缺失的，和产品定义有关。比如要保存用户属性，这个属性是存在本地，还是存在服务端？这是一个公司内部项目，还是一个百万用户的项目？很多产品层面有关的技术决策需要人来参与。举个例子，假设你有一个厨师机器人，可以做世界上任何一道菜。但是你开一个饭馆，你不可能做全世界所有的菜，你总归是要做产品决策，可能是走量的快餐，还是精品的私厨。
程序员从代码实现的环里跳出来，关注点转移到技术决策、产品决策。这背后其实是一次稀缺性的迁移。当"怎么实现"变成随手可得的商品，值钱的就不再是敲代码的手艺，而是"做什么"和"为谁做"的判断。厨师机器人能做尽世上所有的菜，可决定这家店走量快餐还是精品私厨的，永远是开店的人。
所以编程并没有消失，而是被推到了更高的抽象层——从"如何实现一个功能"，变成了"决定这个功能该不该存在、边界划在哪里"。程序员真正的位置，从写下答案的人，变成了定义问题的人。
## 不要完全信任大模型：基因里的不确定性
新用户最容易犯的一个错误，就是对 AI 过度信任。当我们看到宣传里顶级模型可以解决复杂的数学难题，做高质量的 deep research，会认为一定是一个非常靠谱的高智能伙伴。尤其是 AI 自媒体大肆宣扬零基础几天做出一个酷炫的产品。然而当你真的做一个严肃项目的时候，你就会发现大模型远没有想象的可靠。
以下几个原因共同导致了大模型的不够可靠。
先天局限：广而不纯的知识 + 概率式生成
当下的生成式 AI 的底层原理是通过学习大量的语言资料，学会预测一句话里的下一个字（准确的描述是词元）。如果模型能正确续写一句不完整的话，这个模型就拥有了某种程度的智能。因为一段文字的表达是有逻辑的，通过学习续写就拥有了一定的逻辑能力。
举个例子：如果明天下雨，小明就会带伞。明天下雨了，所以小明。
如果模型能填上“会带伞”，它是通过推理（某种智能）得到答案的。
除了推理能力，大模型也会记住很多知识。比如“中国的首都是”，大模型只是在学习语料的时候，发现“中国的首都是”后面反复出现的词元是“北京”，就记住了这个搭配。它就像背九九乘法表一样，记住了这个内容，这里面并没有什么推理。
还有一个特点是每次续写的内容不是固定的，续写的选项其实是一组带有概率系数的选项，模型根据配置（softmax）选出一个选项，并不总是选最大概率的词。
举个例子：形容时间过得很快的成语是__。
也许有一个词是最大概率出现的，但是真实的世界里这本身就是一道多选题，有多个合理答案。如果总是选择最大概率的词，输出就会变得千篇一律，失去多样性。
再举个例子，网络上常提到甜咸之争，我们假设两个阵营的实力势均力敌。大语言学习的时候发现选 49% 的人选咸，51% 的人选甜。那么当问他“粽子是甜的还是咸的好吃”，如果总是回答一个选项肯定是不合理的，所以他会有时回答咸，有时回答甜。因为生成内容的时候必须要“摇骰子”，所以同样的提示词，每次输出的内容都会不同。
除了"摇骰子"带来的随机性，大模型的可靠性还受另一个因素制约：它在训练时学习了海量语料，但学习的本质只是如何正确地续写，本身并不区分这句话是不是事实、是否正确。
大模型要产生一个正确的回答依赖三个因素：
- 学到过正确的内容
- 深度学习后的参数函数反应的逻辑是正确的
- “摇骰子”的时候没有选择错误的路径
理解了大模型的底层原理，我们对它的回答就该少一分盲信，多一分清醒判断。一个综合复杂问题，大模型不能保证总是答对。因为你无法确定它学习到的“解题思路”是否能正确解答你的题，你也不知道它这次答题的时候是否选择的是正确的路径。最终还是需要人来验证结果，责任始终在使用者自己身上。
说到底，大模型的智能和人类的智能不是同一种智能——不要因为它能完成某个高智能的人类任务，就以为它全面具备了同等的人类智能。这是因为底层架构不同，它在不同任务上的表现并不均衡：擅长的领域可能远超人类，薄弱的领域却可能连简单问题都答不对。比如 strawberry 里有几个“r”，去 50 米外的洗车店要不要开车——这类人类觉得理所当然的问题，大模型反而容易翻车。这种"看似无所不能，实则冷不丁掉链子"的反差，根源都在于二者智能的底层机制不同。
上下文（注意力）也是一道坎
对于大模型产生质量还有一个关键的影响因素：上下文的长度。
对于大模型的输入，需要续写的前面的内容就是上下文。提示词也是上下文的一部分。Transformer 原始架构上下文里产生的注意力矩阵复杂度是 O(n²)。上下文里每一个字都需要和其他所有的字建立注意力连接。举例来说输入的上下文长度 100 和 200。看起来输入的内容只是多了一倍，但是实际上注意力矩阵的计算量是从 10000（100²）变成了 40000（200²），增加了 3 倍。因为计算成本随上下文长度平方级上升，现有架构下要支持百万级上下文，各家基本都要依赖注意力优化/压缩手段，很难做到暴力全量计算。DeepSeek 的 MLA、Kimi 的 KDA（Kimi Delta Attention，随 Kimi K3 发布的线性注意力方案，可将 KV Cache 压缩最多 75%）都是公开的注意力压缩方案。
上下文的注意力计算量是平方级增加，这就引出了一个经典的注意力丢失问题。你给的上下文越长，模型忘记的内容的概率就越高。早期模型的特征是 lost in the middle，这么多内容我有点记不清，于是中间的内容比较容易遗忘。
在一个代码项目里，很多综合问题需要查很多代码，引入很多上下文。这就带来两个潜在的失败因素：
- 上下文内容不全。因为上下文空间有限不可能把所有代码都注入上下文。比如某个代码方案需要关联 5 个代码文件才能输出完美方案，但是种种原因大模型只找到了 4 个文件，所以给的方案不够好。
- 注意力丢失。一个任务里你提了 5 点要求。但是因为注意力的内部机制原因（压缩或者天然KV参数不够优秀）丢了一个要求。最后可能某个功能漏做了，或者因为这个要求做错了也有可能。
模型本身能力没问题，在解决具体问题时，也可能因为特定场景的上下文导致结果不理想。
这个场景下的问题是最难受的，因为完全随机性。完全不知道在哪些场景下突然就智力下线了。
有的时候症状比较轻微在会话里提示一下就行。严重的时候常见解决方式有以下几种：
- 执行 compact 指令，大模型会重新阅读压缩自己的上下文
- 如果你能判断某轮对话前还是清醒的，可以找到这轮对话 fork 出一个新会话
- 执行类似 handoff 指令，总结当前的会话输出文档，新开会话重新导入文档
Matt 的说法是上下文长度只有一段空间是真正可用的，越过这个容量大模型就会迅速变傻。保守的说前 20% 是属于聪明区间。
不过到底分割线在哪里不同厂家的模型也会不同。我看 TW93 分享的 Claude Code 经验是配置上下文到 400k 就自动触发压缩。不过 Codex 的表现又有所不同，Codex 上下文窗口小一些，会自己积极的压缩。 总之，如果解决一个复杂问题，留意上下文可能导致的问题。上下文也是一个不确定性因素。
Coding agent 自身的 bug
是软件就不可避免有 bug。常在河边走哪能不湿鞋。持续的使用 agent 就难免遇到一些 bug，有的时候厂家会公开，有的时候不公开可能就过去了。用户端只能感受某些时候模型降智了。
我自己遇到几次 Claude Code 客户端突然不会使用基础工具，改一个文件时声称改完了、工具调用也显示完成，但实际上根本没有执行成功。如果不是每个关键行为都检查一下结果就会持续埋雷。
有的时候会遇到模型跟中毒一样，突然就智力变成小学生。
还有一个不好的体验是明明知道是一个几行代码的改动，模型思考了 10 分钟还没结束。
总之，软件发生 bug 是难免的，不要不核查就直接接受大模型的产出物。
总结：不要认为 AI 不会犯错
我们不能预设 AI 总是正确。大模型自身的概率性语言生成、上下文注意力机制、软件本身的稳定性这三个因素共同作用下，AI 出错只是早晚的事。
这也是目前人的价值，不是把任务完全托管给 AI，而是在和 AI 协作中放大工具价值，保证交付高质量的成果。
## 几家模型的印象
各家模型都在飞速进步，这里的印象应该很快会过期（26.07）。
此时此刻，Coding 的规划阶段我认为 Claude 是最佳的选择。Claude 的思维明显更活跃，与人的交互感比较强。Claude 可能训练的比较均衡，审美、写作也比 GPT 好一些。Fable 我用的比较少，但是似乎能力也是更强一档。再配合上 100 万上下文和 Claude Code 更是如虎添翼。
不过最近的使用体验下 Claude 的工程稳定性不如 GPT。Claude 也没有生图的技能。我用 Opus 时常遇到一个任务执行时间过长的问题，对比 Codex 的一个任务的执行时长比较符合我的预期。
GPT 的指令遵循能力特别强，不知道是注意力算法有独家秘方还是后训练的时候特别强化了。总之 GPT 在我个人有限的使用下，指令遵循从没出过错
Claude、DeepSeek V4 都小概率遇到过出错。大概在 GPT 5.4 的时候，我发现一个明确边界的编程任务 Codex 执行的比 Claude 好。GPT 5.6 Sol 的说话也正常了一点，综合能力也有明显进步了。就是我前期使用的时候额度消耗的非常快。GPT 的一个明显缺点是普通会员在 Codex 中的上下文窗口不是 100 万。百万上下文是 API 才有，而且也更贵。不过可能很多场景下不需要这么大的窗口。
所以我觉得可能最佳的组合可能是 Claude 做规划，GPT 做编码执行。
随着 K3 的一鸣惊人，国模 Coding 领域的 top2 无疑是 Kimi 和 GLM 了。Kimi 在技术架构暂时领先一步，K3 接近 3T 的参数量，原生多模态都比 GLM 领先一些。但是目前 K3 只有 Max 档位，作为一个模型系列缺失了中档和 fast。囿于资源的限制，目前顶级模型的综合能力还是有一些差距。不过具体某些场景可以打得有来有回，价格也有优势。大家都有光明的未来。
我测试了几个场景，DeepSeek V4 pro（预览版）的思考质量比 Sonnet 5 和 GPT 5.6 Terra 差。但是差的不多，可能有八九成水平。可以说 DeepSeek 在它的价格档位上性能是最好的，但是如果比峰值水平，我的体感还是有不少差距。
这带来的一个问题是，一个有一定复杂度的编程场景，如果只用 DeepSeek 可能因为思考质量不够导致返工，最后的综合性价比可能不一定有优势。葬 AI的综合性价比榜上可以看到，DeepSeek V4 pro 的综合性价比低于 GLM 5.2 和 K3。
## 顺带提一下 Claude 的购买渠道
我是用的美区 Apple 账号下载、订阅。充值就到美区商店购买礼品卡，银联支持美元的信用卡就能支付。节点就用的日本的住宅 IP 节点（尽量使用同一个节点）。刚好有朋友在日本，让他在手机上登录了我的账号，偶尔进行一下 chat。目前用了三个月，还没被封。我既没有改电脑的时区，也没有不用中文。我觉得单纯的使用中文不是构成账号被封的理由。新加坡也很多人用中文。
还有一个点，我是正常使用额度，做不到每个 5 小时额度都用满。我的使用方式就是边讨论需求，边实现，实现完后再手动验证一下。然后再改改。我看到有人说每次都用满的 200 刀 Max 比较容易封。我是中档的 Max 的套餐。我怀疑是很多中转或者拼的 20x 的 Max 套餐，所以这个档的会员比较容易封。
不过随缘了，被封了就打算主力用 Codex 了。
## 最后
印刷术让抄写员消失，却没有让「书」消失，反而让思想传播得更远。我相信这次也是一样：手写代码这门手艺会褪色，但软件、工程、以及背后「解决真实问题」的那份价值不会。技术革命淘汰的从来是具体的手艺，而不是创造本身。对我这样的普通开发者来说，与其焦虑手里的技能会不会贬值，不如去找到那根新的杠杆——把 AI 放大执行力的那部分交给它，把判断、选择和责任牢牢握在自己手里。被推到更高抽象层的编程，才刚刚开始。乐观的拥抱历史进程吧。
我的微信：fuguizhuo77。欢迎交流。
## 相关链接
- [独立开花卓富贵](https://x.com/fuguizhuo)
- [@fuguizhuo](https://x.com/fuguizhuo)
- [2.6K](https://x.com/fuguizhuo/status/2080111673399287938/analytics)
- [open design](https://open-design.ai/zh/)
- [mattpocock-skills](https://github.com/mattpocock/skills)
- [葬 AI](https://mp.weixin.qq.com/s/ceYUcng5gJ9akbzCYZgMEQ)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:04 AM · Jul 23, 2026](https://x.com/fuguizhuo/status/2080111673399287938)
- [2,614 Views](https://x.com/fuguizhuo/status/2080111673399287938/analytics)
---
*导出时间: 2026/7/23 13:27:55*