AI编程 on CHEN 的博客

停用 GPT 一个月后，我回来了

Tue, 08 Sep 2026 15:34:00 +0800

停用 ChatGPT 差不多一个月了。

原因挺杂的。政策层面的不确定性是一方面，费用是一方面，另一方面国产的 Agent 和 Harness 产品确实越来越多、越来越能打了，我想认真试一试它们到底能到什么程度。于是干脆把 GPT 暂时放下了，全面切换到国产智能体加国产模型的组合。

这一个月下来，体验其实没有想象中那么痛苦。但现在 GPT6 发布，各种强大的作品展示效果层出不穷，恰逢我的国内免费积分也快用完了，是时候回来再看看了。

切换的过程比想象中顺利

先说结论：从 Codex + GPT5.5 切换到国产智能体 + 国产模型，并没有太多的不适应。

这一点我是真心觉得不错。

说实话，一年前如果让我做同样的切换，体验落差可能会非常明显。但现在，无论是豆包、Kimi 还是其他几家，在代码理解、多轮对话、上下文保持这些方面，确实已经做到了一个相当可用的水平。

尤其是在一些标准化的任务上——比如写一段业务逻辑、生成测试用例、做简单的代码审查——国产模型的表现已经相当稳定。我日常用 Codex 做的事情，换成国产智能体以后，大部分场景都能接住。

从这个角度说，中美 AI 的差距确实在缩小。 这不是客套话，而是过去一个月里我最真实的体感。

具体用了哪些产品

先列一下这一个月用过的东西。

智能体方面，试了一圈：CodeBuddy、WorkBuddy、Trae、Qoder、千问办公。用下来的感受，一言以蔽之——都差不多。 界面设计、交互逻辑、任务完成度，没有谁拉开谁一个身位的感觉。各有各的小毛病，也各有各的亮点，但整体体验高度趋同。

基座模型方面就杂一些了：GLM5.2、GLM5.3、GLM5.3 Flash、Kimi-K3、HY4 Preview、HY3、DeepseekV4 PRO、DeepseekV Flash、QWEN 3.8，能排上号的几乎都跑了一遍。

体感上，推理能力和深度没有想象的差距那么大。 大家在逻辑推理、代码理解、方案生成这些方面的表现，说实话已经非常接近了。倒是执行速度和积分消耗，确实让几个 Flash 模型优势巨大——同样一个任务，Flash 模型可能 10 秒出结果还不怎么耗积分，换一个满血版可能要 30 秒还烧掉好几倍的额度。对于日常高频使用来说，这个差距比模型能力本身的差距更直接影响体验。

但信心是另一回事

话说到这里，但后面还有一个"但是"。

切换过去以后，我发现自己有一个很明显的变化：对国产产品产出的信心不足。

这种信心不足不是说它们回答得不好，而是一种隐隐的担心——会不会哪里有比较大的理解偏差？会不会有一个看起来很合理但实际上是谬误的答案？会不会在某个关键细节上自以为正确但其实是错的？

于是我养成了一个习惯：同一个问题，用多个国产产品交叉验证。

A 产品给了一个答案，我再问一遍 B 产品；B 产品说了一个方案，我再让 C 产品看看有没有问题。表面上看这是在充分利用各家的长处，但实际上，这背后是一种不太敢完全信任的心态。

反过来说，我几乎从来没有对 GPT 产生过这种需要交叉验证的冲动。不是因为它一定不会犯错——它当然也会幻觉——而是长期以来建立的使用信任，让我在大多数场景下愿意直接采纳它的结果。

这种信任不是一天建立起来的，而是在无数次使用中慢慢积累的。每一次它准确理解了我的意图，每一次它给出了合理的方案，每一次它在复杂问题上表现出的稳定性，都在为这种信任充值。

而国产模型目前还处在这个信任充值的早期阶段。

为什么信心差距这么重要

可能有人会觉得，多验证几次也不是什么大事，不就是多花几分钟嘛。

但实际使用中，这种信心差距的影响比看起来要大得多。

当你对一个工具的产出不够信任时，你的使用方式就会发生根本性的变化。你会更保守，更不敢尝试，更倾向于把 AI 的输出当成"参考"而不是"半成品"。你会花更多时间在检查和验证上，而不是让它帮你往前推进。

更关键的是，你不太敢让 AI 深度参与复杂任务。因为一旦涉及多步骤、多文件、需要连贯理解的场景，任何一个环节的理解偏差，都可能像蝴蝶效应一样放大到最后的结果里。

这种谨慎在很多场景下是对的，但它同时也意味着你没有真正释放 AI 的能力。

现在回来，看看 GPT6 到底有多强

GPT6 发布这几天，我看了不少作品展示，确实有一些让人眼前一亮的效果。

但看别人演示和自己实际使用，始终是两回事。所以我不想在没有深度使用之前就下结论。这次回来，我想认真对比几个方面：

维度	国产智能体 + 国产模型	GPT6 + Codex
标准化任务	表现稳定，可用	预期会更强，但待验证
复杂理解	够用，偶尔有偏差	需要验证
多步推理	基本可用，信心不足	需要验证
代码生成	质量不错	预期会有提升
使用成本	有免费额度，但开始收费	Plus 订阅 + API 按量
信任感	需要交叉验证	长期积累，相对更高

这个表格里的"待验证"不是我偷懒不想写，而是我真的觉得，在没有足够使用数据之前，给任何一个方向下结论都为时过早。

说说费用这件事

既然提到了费用，就多说两句。

国产产品的免费积分确实是我这一个月能全面切换的一个重要支撑。但正如前面说的，免费积分总有用完的时候，而一旦开始付费，价格差距就变得很现实了。

GPT Plus 每月 20 美元，这个价格虽然不便宜，但考虑到它能提供的能力上限和稳定性，对于把 AI 当成核心生产力工具的人来说，是一笔算得过来的账。

国产产品目前的定价策略还在探索阶段。有的免费额度给得很大方，有的已经开始收紧。这种不确定性本身也会增加使用时的心理负担——你不知道下个月还能不能像现在这样用。

最后

停用一个月 GPT，最大的收获不是发现国产产品已经能完全替代了，而是让我更清楚地看到了差距到底缩小了多少，以及剩下的差距到底在哪里。

国产模型在标准化任务上的表现已经相当不错，这是事实。但在需要深度信任、复杂推理和长期稳定性的场景下，要追上的路还有不少。

不过话说回来，信任这东西本来就是靠一次又一次的正确积累出来的。国产模型的充值才刚开始，未来的空间还很大。

现在 GPT6 回来了，我想先用一段时间再做更完整的对比。也许到时候会发现差距比想象中小，也许会发现有些差距比我想象中更难追。

无论如何，能有选择本身就是一件好事。 有竞争，才会有进步；有对比，才知道差距；有差距，才有追赶的动力。

做了两个 Skill 之后，我对“怎么写好 Skill”有了一些新理解

Tue, 23 Jun 2026 15:50:00 +0800

最近一方面是想让自己平时工作更顺手一点，另一方面工作上又正好有 Skill 比赛，我就连续做了两个自己的 Skill。做完以后回头看，技术细节当然有不少，但我现在最想先记下来的，其实是一些更偏方法论的感受。

因为我感觉，这两次折腾下来，自己对“Skill 应该怎么做”这件事，确实比之前想明白了一点。

第一个 Skill：做得太重了

我做的第一个 Skill，是一个辅助自己在同一个 workspace 里做前后端全栈开发的 Skill。

一开始的思路其实很自然：既然都做了，那不如尽量完整一点。于是除了前后端同步开发本身，我还往前扩了一层需求分析、影响范围分析，往后又补了一层四角色 code review，再加上一些我自己的开发习惯和细节偏好，慢慢全塞了进去。

从个人使用体验来说，体感其实还可以。但后面拿去参加比赛，先上传到 SkillHub 做自动化评测，我才比较明确地意识到问题在哪。

评测里有触发准确率、功能执行质量和 token 消耗量。前两项我的得分还行，第三项就比较难看。看到结果的时候我几乎立刻反应过来了：这个 Skill 确实还是包装得太重了。

很多时候我们会本能地觉得，功能更全一点总是好的。但 Skill 这种东西，可能恰恰不是这样。你塞进去的目标越多、流程越长、依赖越复杂，它就越容易变成一个看起来很强、但实际代价也很高的东西。

所以第一个 Skill 做完以后，我最大的反思不是“还不够强”，而是：我是不是一开始就想做得太大了。

比赛展示时，我又暴露了另一个问题

后面到了复赛 presentation 环节，我是第一个讲。现在回头想，那个过程也挺说明问题的。

我讲的时候就已经隐隐感觉到不太对。不是完全没内容，而是讲得有点太宏观了，不够落地，也没有把重点放在一个更关键的问题上：

评委到底想听什么，想了解什么。

我当时更像是在讲理念、讲覆盖面、讲整体设计，但评委显然更关心两件事：

有没有足够具体的示例和效果展示
这个东西是不是有较强的推广性

这两点，我觉得自己都做得不太好。展示不够具体，推广性也讲得不够扎实。现在看，估计得奖大概率是没戏了。

不过这件事对我也不是坏事。它至少让我意识到，做一个 Skill，不只是把东西做出来，还得想清楚：它到底解决了一个什么问题，这个问题是不是足够真实、足够具体，也足够容易被别人理解和复用。

第二个 Skill：开始收了

后来又有一个类似的比赛，我就不太想再闭门造车了。

有了上一次的经验之后，我这次最直接的想法就是：不要再试图一下子包太多东西，而是先专注地把一个问题解决好。

所以这次我的选题换成了自然语言转 SQL。

这个需求不是我拍脑袋想出来的，而是领导之前确实提到过，是一个真实存在的痛点。而且这种题目也天然比一个高度绑定我个人工作流的全栈开发 Skill，更容易讲清楚价值和推广性。

现在我已经先做了一个版本方案，准备后面继续往下做。

这次我也没有再完全闷头想，而是顺手研究了一下类似的产品，比如 vanna.ai。它整个盘子铺得比较大，功能也很多，但我还是找到了一点我觉得很值得拿来用的思路：在自然语言输入之后，先增加一层语义理解、抽取和标准化。

我觉得这一层挺重要的。很多时候，自然语言转 SQL 真正难的，不是最后那句 SQL 怎么拼，而是用户输入本身就很模糊。如果中间没有一层先把表达整理干净，后面直接硬转，其实很容易漂。

这段时间我总结下来的几点心得

除了看竞品，我也顺手看了一些关于怎么写好 Skill 的文章。边看边结合这两次实践，我现在大概有这么几个心得。

1. 做渐进式披露，`skill.md` 不要太胖

这是我感触最深的一点。

skill.md 如果一上来就什么都写，背景、流程、分支、细则全堆进去，最后往往就是又重又难读。对模型来说不一定稳定，对 token 来说也很浪费。

我现在越来越认同一种结构：中心短，辐射厚。

也就是 skill.md 本身只放最核心、最高信号的流程和判断，其他细节按需拆到别的文件里，需要的时候再读、再执行。这样既更省 token，也更不容易让主干被细节淹没。

2. 写完之后一定要测试

我现在会觉得，写 Skill 不能写完就算完，最好还是把它当成一种“程序”来看。

至少要验证几个问题：

能不能正常跑
能不能被正确触发
跑出来的结果稳不稳定
它到底是不是真的比不用 Skill 更好

前面几个都比较容易想到，但最后一个问题其实很关键。有时候你做了一套看起来很完整的 Skill，实际一用，却不一定真的带来了明显收益。它可能只是把原本就能做的事，换了一种更正式、但不一定更高效的方式重做了一遍。

所以测试不能只测“能不能跑”，还得测“值不值得用”。

3. 复杂逻辑一定要下沉到 `/scripts`

这一点我现在也基本确定了。

如果 Skill 里有复杂逻辑，尤其是固定判断、重复处理、半结构化数据加工之类的内容，最好还是写成脚本放到 /scripts 下面，不要硬塞在 skill.md 里。

原因也很直接：脚本更稳定、更容易复用、更容易测试，也更省上下文。很多本来可以交给程序去做的事情，如果非要用自然语言写得特别细，最后只会又长又重，还不一定稳。

4. 最后，真的要用 `skill creator`

这个结论我现在也挺明确。

以前可能会觉得，自己手写也不是不行，为什么非要用 creator。但真做了两次以后，我会觉得，skill creator 的价值不只是帮你生成一个壳子，而是能把结构、规范、拆分方式这些基础东西先拉到一个比较合理的起点。

很多时候，人自己写的时候，很容易想到什么塞什么，最后越写越散。用 skill creator，至少能让整个 Skill 的骨架一开始就更规整一点。

最后

如果现在让我总结，这两次做 Skill 最大的收获是什么，我大概会说，不是我学会了多少“高级技巧”，而是我慢慢开始意识到：

Skill 最怕的，可能不是做不大，而是收不住。

第一个 Skill，我更像是在证明“我能把很多东西包进去”；第二个 Skill，我开始尝试去证明“我能不能先把一个问题解决好”。这两种思路看起来只是收和放的区别，但最后做出来的东西，味道其实完全不一样。

至于这次新的比赛最后能不能拿到一个好成绩，我现在也不好说。能拿当然最好，但如果最后还是没拿到，我觉得也没什么关系。因为至少上一次比赛已经让我学到了不少东西，而这一次，我又比上一次更清楚了一点：以后再写 Skill，到底应该把力气花在哪。

当 Codex 当了丞相，朕终于看懂了 Understand Anything

Fri, 05 Jun 2026 23:02:00 +0800

前阵子我还专门写过一篇文章，喷 Understand Anything 喷得挺狠，核心观点就一句：这东西不配那么多星。

现在我准备给它平反一下。

不是因为它突然变强了，而是因为我的使用场景变了。最近我在这台服务器上连续用 Codex 做了两个项目，一个是这个博客，一个是 Godot 项目。整个过程里，我几乎没认真看多少代码，更多只是了解业务层面的东西，知道大概逻辑，然后让 Codex 去推进实现。

做到这里我忽然意识到一个问题：事情是能继续做，但我其实并不真的知道项目整体长什么样。

于是我重新跑了一次 understand，让它生成知识图谱。第一眼看上去还是很唬人，节点很多，结构铺得很开，很容易给人一种“系统已经被看透了”的感觉。但这次我细看之后，发现它确实补上了一块我原本缺的东西：让我对项目结构有了整体上的心里有数。

我现在更像皇帝，不像工匠

这段时间我的开发状态，越来越像站在上层看方向。

我知道项目要往哪走，知道最近要修什么、加什么、优先级怎么排，但真正深入到代码细节里，很多事情其实已经是 Codex 在处理。它去看文件、改实现、查问题、做汇报，我更多是在听汇报、拍板、再调整方向。

这种感觉有点像皇帝看帝国。

我不需要知道每个县衙今天具体发生了什么，但我需要知道疆域怎么分、哪里更重要、整个秩序大概是什么样。不然的话，虽然事情也能推进，心里其实是虚的。

在这个角度上，Understand Anything 给出的知识图谱就很像一份疆域图。它不能替代真正读代码，更不能替代排障和开发，但它能让我对整个项目的大致轮廓有感觉，这一点反而挺重要。

为什么我以前会觉得它没用

我之前拿它去理解的是工作里的后端项目。那个项目文件很多，但更关键的是，我本来就已经很熟了。模块怎么分、链路大概怎么跑、哪里是重点，我自己心里已经有一套模型。

所以它再给我生成一张知识图谱，我看到的就只是一大堆文件被更整齐地排了一遍。没有增量信息，自然也就感觉毫无用处。

这不是它完全没价值，而是那种场景本来就不适合它。对于一个你已经非常熟的项目，它很难超过你自己的脑内地图。

但对陌生项目，它确实有价值

这次不一样。最近这两个项目，无论博客还是 Godot，我对技术栈都不算熟。很多时候我能判断业务目标对不对，但如果让我只靠自己快速进入代码层面，其实并不现实。

在这种情况下，知识图谱的价值就出来了。它服务的不是“已经完全懂项目的人”，而是像我这种：

对项目还不够熟
对技术栈也不够熟
又在大量依赖 AI 推进开发

这时候它的意义就不是“替你理解代码”，而是帮你快速感知项目，建立一个全局印象。

这样一想，我反而有点理解它为什么会有这么多星。很多人未必真的了解自己手头的项目，或者至少没有一个稳定、清晰的整体印象。尤其在 AI 越来越占主导之后，大家更需要这种能快速生成总览图的东西。

最后

所以我现在对 Understand Anything 的看法，已经没有之前那么刻薄了。

它不是神器，也不是能让你从此不读代码的东西。如果你本来就非常了解项目，它大概率只会显得花哨。但如果你面对的是陌生项目、陌生技术栈，而且开发过程里 AI 已经承担了大量具体事务，那它确实能帮你建立一种“我至少知道这个帝国长什么样”的把握感。

这不一定直接帮你写出更多代码，但会让你心里踏实不少。

为了让博客更好刷一点，我认真模仿了一次小红书

Fri, 05 Jun 2026 15:10:00 +0800

最近我把博客做了一轮比较明确的改造，方向很简单：认真模仿了一次小红书。

当然，不是想把博客做成另一个小红书。我真正想借的，是它那套内容展示逻辑。原来的博客更偏传统文章站：列表是一篇一篇往下排，文章里的图片也只是正文的补充。这套方式适合认真读，但不太适合先刷一遍、再决定点开哪篇。

所以这次我主要动了两块：文章页里的图片展示，以及文章列表的浏览模式。

文章页先补上“小红书式”的图片集逻辑

这部分是整个改造的起点。

以前博客里的图片更像普通插图，放在正文里负责辅助说明。但后来写一些界面改造、部署记录、前后对比时，我越来越觉得，很多内容天然更适合用一组图连续展示，而不是几张图零散地插在正文里。

小红书在这件事上的逻辑很成熟：它默认把图片当成一个内容单元来处理，而不是几张附件。读者进入内容后，可以连续切换，知道自己看到第几张，也能随时点开看大图。

我把这套逻辑拆开之后，先对应成几个需求：

一篇文章要原生支持多图。
多张图要作为同一个组件展示，而不是简单堆叠。
图片之间要能切换。
要有当前位置提示。
要能点开看大图。

确定需求之后，我单独做了一套 gallery 结构。数据层增加了 gallery，模板层单独渲染图片集，交互层补了上一张、下一张、页码状态、圆点导航和大图预览。后面又继续收了几轮细节，让它更像一个完整的内容浏览组件，而不是正文里的轮播图。

这一部分本质上是在把博客原来偏静态的单图展示，改成更接近小红书那种“图片组优先”的方式。

列表页再补上“双列 feed”的浏览逻辑

图片集做完之后，第二个问题就出来了：如果文章内部已经开始强调图片和封面，那文章列表继续完全沿用传统博客排法，就有点不协调了。

原来的列表更像博客目录：单列、纵向、信息完整。小红书那种模式不一样，它更强调“先快速浏览，再决定点进哪篇”。要模仿它，重点不是单纯改成两列，而是把列表从“目录视图”改成“feed 视图”。

我把需求拆成了几条：

保留原来的单列模式，同时新增双列模式。
双列模式里，每篇文章都要有封面。
标题、摘要、元信息都要重新收紧。
双列模式不能继续强依赖传统分页。
用户切换过的布局要被记住。

对应实现上，我在侧边栏加了布局切换按钮，并用 localStorage 记住用户偏好。文章列表模板也改成了卡片结构，在双列模式下优先取文章 gallery 的第一张图当封面。样式层单独给双列模式写了一套规则，重新组织标题、摘要、meta 和封面的关系。脚本层则补了一套继续加载逻辑：进入双列模式后，隐藏传统分页，通过 sentinel 和 IntersectionObserver 继续加载后续文章，让浏览方式更接近 feed。

所以这部分模仿的也不是“小红书长什么样”，而是它背后的产品逻辑：先让内容更容易被扫到，再把完整阅读留给点击之后。

改完之后，我才更清楚这套方式为什么有用

真正做完之后，我才更明显地感觉到，这次改造不是单纯“更像某个平台”，而是把博客里原来混在一起的两件事拆开了：浏览和阅读。

双列模式让列表页更适合先刷一遍，先看最近有什么值得点开的内容；图片集则让文章内部的多图内容不再散，读者可以更顺手地切图、对比和放大查看。

结果就是，博客终于不再只有一种阅读姿势了。你既可以像以前那样按传统文章流慢慢看，也可以先像刷 feed 一样快速过一遍，再决定读哪篇。对我现在这种既写观点，也写折腾记录、界面改造和产品细节的博客来说，这种变化是成立的。

我后来越来越觉得，博客完全可以借一点平台的长处。不是抄外观，而是借那些已经被验证过的内容展示逻辑。

这次我做的，其实就是一次很小的产品化尝试：内容没变，我改的只是内容被看到、被浏览、被点开的方式。

结果还挺值。

AI 让写代码变容易了，但做产品为什么还是这么难

Mon, 01 Jun 2026 15:18:00 +0800

从 2024 年下半年开始，我就在比较激进地让 AI 帮我写代码。到现在为止，自己真正亲手敲代码的比例已经很低了，算是一个偏激进的 vibe coding 实践者。

这半年多下来，感想很多，而且很杂。但如果要把它们收束成一句话，我现在最深的感受其实不是“AI 好强”，而是：

AI 让写代码这件事越来越不难了，但把一个产品真正做出来、做对，依然很难。

这两天我给自己的 blog 做了一个欢迎页，灵感来自 Norris 的个人主页。现在回头看，这个需求本身其实一点都不复杂，无非就是想做一个看起来更完整、更有进入感的首页。

但真正折腾起来，从作图、改图，到写代码、改代码，再到反复调整视觉和交互细节，前前后后磨了很久，也消耗了不少 token。最后我很明显地体感到，问题并不在于 AI 不会写，也不在于它能力不够，而在于我自己对需求的描述还不够准。

很多时候，第一次描述不够清楚，出来的结果就会和预期有偏差；等你开始纠错时，如果纠得太猛，又很容易矫枉过正，直接偏向另一个方向。越改越歪，到最后甚至会觉得还不如推倒重来。

所以这篇文章我想写的，不是“AI 会不会取代程序员”，也不是“AI 编程工具哪个好”。我更想记录的是，在 AI 把开发能力快速拉平之后，真正难的东西到底还剩下什么。

写代码

第一层当然还是写代码本身。但现在我越来越觉得，AI 带来的变化，早就不只是“帮你实现一个 function”这么简单了。

它可以参与的层次非常多：表结构设计、模块拆分、程序层级设计、接口定义，甚至是更上层的系统设计和架构设计。很多过去要依赖高级工程师、架构师、甚至技术负责人长期积累的能力，现在都可以通过 AI 先给你一个相当像样的起点。

某种意义上说，它真的很像一个高级架构师，但又不止是架构师。因为它不只是站在上面画图，它还能顺手把底下那部分实现也一起补上。

所以如果你在让 AI 写代码的时候，不是把输出丢在一边自己去刷短视频，而是真的顺手看看它怎么拆问题、怎么组织代码、为什么这样设计，那其实是一个很高频、很廉价的学习过程。

你会看到它怎么命名，怎么分层，怎么补边界条件，怎么从一个模糊目标一步步落成可以执行的代码。这种学习未必系统，但胜在密度极高，而且贴着真实问题。

也正因为这样，我现在很难再把“开发”理解成单纯的体力活。至少在很多场景里，开发本身已经不再是最难的一环。真正的问题开始转移了。

理解需求

我刚上班那会儿，其实一直有一种很强的偏见：产品经理到底有什么用？

在当时的我看来，这个角色无非就是把用户说的问题整理成文档，再拉着大家开会，像是一个被强行安插出来的中间层。很多时候你甚至会觉得，需求如果直接给开发，不是更快吗？

现在回头看，我觉得当年的判断只能说对了一半。不是产品经理这个角色没用，而是某些产品经理没用，所以才让我长期没有真正感受到“理解并梳理需求”到底有多难，也有多重要。

这两年我的实际工作环境里，组内并没有一个强存在感的产品经理。很多需求最后都要靠自己去理解、去拆、去梳理。以前总觉得这部分只是开发前的准备动作，现在才发现，它本身就是非常核心的一段工作。

尤其是在 AI 参与开发之后，这种感受更明显了。因为 AI 可以帮你梳理需求，可以陪你反复讨论，也可以根据你的描述快速往下推进，但前提是你自己得先把问题理解到一定程度。

如果你连自己要解决的到底是什么都没搞清楚，那 AI 只会非常高效地帮你把坑挖得更完整一点。最要命的是，梳理完需求之后，下一个负责开发的人往往还是你自己。既然最后埋单的人还是自己，那前面就更不能随便给自己埋坑。

所以我现在越来越能理解，为什么一个好产品经理会稀缺。不是因为这个岗位门槛天然有多高，而是因为把一团模糊的想法真正整理成可执行、可验证、可落地的需求，这件事本来就很难。

描述需求

如果说理解需求，是先把事情在自己脑子里想明白；那描述需求，就是进一步把这件事准确地传递出去。

而这恰恰是我最近感受最深的难点。

欢迎页那次折腾就是一个很典型的例子。最后做出来的东西并不复杂，事后看甚至会觉得“这不就是个很简单的页面吗”。但真正麻烦的地方在于，我脑子里其实只有一种模糊的感觉：我想要它更完整一点、更有氛围一点、更像一个入口，而不是一打开就是普通博客列表。

问题在于，这种“感觉”对于人来说也许还能靠来回交流慢慢逼近，但对于 AI 来说，如果你不能把它拆成更具体的约束，它就只能根据自己的统计经验去猜。于是每一次输出都可能“差不多对”，但就是不完全对。

更麻烦的是，当结果偏了以后，纠错也不是一句“改一下”就能解决。因为你自己未必知道到底是哪一层偏了。是排版偏了，还是氛围偏了？是图不对，还是文案不对？是层次不够明显，还是你一开始就给了一个错误方向？

这时候如果只是不断局部修补，很容易出现另一种经典问题：把一个地方修正了，另一个地方又歪了。最后你会发现，真正稀缺的能力不是“指出哪里不喜欢”，而是准确描述自己到底想要什么。

这也让我重新想到那本之前很火的书：《人人都是产品经理》。

这个标题其实可以从很多角度解读。但我现在最新的个人感悟是：产品经理的门槛，不在于一个人是什么教育背景、学的什么专业、是不是科班出身，而在于他有没有能力去理解一件事，并把它描述清楚。

这个能力和 background 关系没有那么大，所以当然可以说“人人都能当产品经理”。

但换一个角度讲，既然这个能力几乎对所有人都开放，那也意味着：人人都很难把它当好。

写文档

还有一个我越来越想加进去的点，是写文档。

我现在会觉得，vibe coding 的时候，写文档不是可有可无，而是非常重要。以前常说“好记性不如烂笔头”，这句话放到 AI 协作里其实一样成立，甚至更成立。

因为你不是在跟一个始终稳定、永远记得上下文的人协作，而是在跟一个能力很强、但会幻觉、会遗忘、会随着上下文窗口变化而丢失细节的系统协作。很多你以为“刚才已经说过了”的前提，只要没有被稳定地落下来，后面就很可能再次漂掉。

所以文档的第一个作用，就是对抗 AI 的幻觉和上下文丢失。

你把关键约束、目标、术语、边界条件、设计取舍写下来，等于是在不断给 AI 立锚点。这样它后面无论是继续写代码，还是继续帮你分析问题，偏航的概率都会小很多。

第二个作用，是维持复杂系统里的逻辑一致性。

系统一旦稍微复杂一点，很多东西就不是某一个函数对不对的问题了，而是不同模块之间是不是还在遵守同一套规则。你脑子里当然可以暂时记住，但只靠脑子记，随着需求变动、文件变多、对话变长，迟早会乱。

这时候文档就不是“额外工作”，而是系统本身的一部分。它负责把那些高层规则固定下来，让你、也让 AI，都能反复回到同一个基准面上。

我自己这段时间总结下来，写好文档至少有两个很实际的经验。

第一，尽量写 Markdown 文档。

不是因为 Markdown 有什么神奇，而是因为 AI 对结构化信息的理解能力，明显强于一大坨没有层级的纯文本段落。标题、列表、编号、表格，这些结构会天然帮它理解“什么是主干，什么是补充，什么是并列，什么是从属”。

第二，文档要分层级写。

不要试图把所有东西都堆在同一篇长文里。目标、背景、核心原则、模块设计、边界条件、待确认事项，最好分层组织。这样不只是人看起来轻松，AI 在引用、总结、续写的时候也更稳定。

所以我现在的感受已经和以前完全不一样了。过去我会本能地排斥写文档，总觉得那是行政负担，是“真正写代码之前”或者“写完代码之后”才不得不补的一件事。

现在我越来越觉得，文档本身就是编程的一部分。不是因为流程要求你写，而是因为你如果想把 AI 真正用好，想让一个复杂系统在多轮协作之后还能保持一致，那你就必须主动把文档写好。

最后

所以如果今天再让我总结，AI 时代做产品最难的点到底在哪，我的答案大概不是“技术实现”，而是另外四件更靠前的事：

你能不能借助 AI 学会更高层次地思考代码
你能不能在开工之前先把需求真正想清楚
你能不能把自己想要的东西，描述到足够准确
你能不能把关键认知沉淀成文档，稳定地传递给未来的自己和 AI

开发门槛在下降，这几乎已经是一个越来越明显的事实了。但也正因为开发变容易了，过去那些被技术门槛遮住的问题，反而会越来越暴露出来。

以前做不出来，我们可以怪技术太难；以后做不好，很多时候就只能承认，是我们还没有想清楚、没有说清楚，也没有记清楚。

三箭齐发：Codex、Claude Code 与 OpenCode 的选型对比

Fri, 29 May 2026 15:50:00 +0800

最近我在同时用三个 AI 编程工具：Codex、Claude Code 和 OpenCode。它们看起来都是"AI 帮你写代码"，但定位和能力差别其实挺大。

这篇文章先把核心差异列清楚，再说说我目前是怎么分工用的。

一、三个工具的核心差异

直接上表格，只列事实：

维度	Codex	Claude Code	OpenCode
厂商	OpenAI	Anthropic	开源社区
开源	闭源	闭源	Apache 2.0
模型	GPT 系列	Claude 系列	多模型可选（OpenAI / Claude / Gemini / 第三方）
运行方式	云端	本地 CLI	本地 CLI / 服务端部署
插件机制	无	无	有
MCP 支持	不支持	支持	支持
CI 集成	有限	有限	原生支持
定价	API 按量计费	$20/月 + API 按量	开源免费，模型费用另计
国内访问	需代理	需代理	取决于所选模型
典型场景	IDE 内代码补全与生成	复杂重构 / 多文件协作	自动化 / CI / 服务端运行

几个差异展开说一下：

模型绑定：Codex 绑定 OpenAI 的 GPT 系列，Claude Code 绑定 Anthropic 的 Claude 系列。OpenCode 不绑定特定模型，可以自由切换。

运行形态：Codex 目前主要通过 ChatGPT / API 形态提供服务；Claude Code 是本地 CLI 工具；OpenCode 同时支持本地 CLI 和服务端部署，后者适合跑在服务器上做自动化任务。

开源程度：OpenCode 是三者中唯一开源的（Apache 2.0），可以看源码、改源码、自托管。Codex 和 Claude Code 都是闭源产品。

MCP 支持：Claude Code 和 OpenCode 都支持 MCP（Model Context Protocol），Codex 暂不支持。

二、我目前的使用分工

基于上面的差异，我目前的分工是：

写代码：用 Codex，GPT 模型的代码生成能力在补全场景下表现不错
复杂重构：用 Claude Code，适合跨多文件的 Agent 操作
服务端自动化：用 OpenCode，可以跑在服务器上做代码 review，模型选择灵活

三个工具不冲突，各自干各自擅长的事。这个分工以后可能会随着使用深入而调整。

三、关于深度使用

说实话，Claude Code 和 OpenCode 我目前都还没有太深入地使用。Claude Code 刚装上不久，OpenCode 也是最近才在服务器上跑起来，主要任务就是给代码做 review。

等以后有了更多实际使用心得，再单独写后续文章。这次先把差异点和分工逻辑理清楚，算是一个阶段性的记录。