近期大模型

最近两个月，我变得越来越重度使用AI，做 vibe coding 。

可以说，AI生成的代码已经占到 99% 以上。现在哪怕是一个很小的改动，我也倾向于让AI代劳，因为有不少情况下一个看似小的改动，背后都可能牵涉其他几个地方，特别是一些文档和注释，所以与其冒险手写，不如让AI完整看看上下文环境，做彻底的修改。或者要么就忍一忍干脆不改了，一些小的问题，其实客观来说可以算是一种代码洁癖，如果只是一些表层的语法表达方式不那么优秀，但只要里层蕴含的信息量是正确且足够的，那就够了，没必要硬改。当然也有少数情况确实需要人工介入，这部分的占比估计在百分之一到千分之一范围内吧。

跟朋友们聊天的时候很感慨。看看我以前的博客文章，去年这时候我还觉得AI不值得信任、只能做行内补全，而到今年上半年开始觉得可以氛围编程，再到现在完全依赖氛围编程，短短一两年时间，变化如此巨大。

本质原因是大模型的智能水平已经突破了一个瓶颈，达到了可用阶段。而且现在即使是经济实惠的国产开源模型，其智能也跨过了这个瓶颈。因此从今以后的研发工作流程中，可以放心地将大模型作为地基。

近期有许多新的大模型推出，但我目前的主力模型依然是 Fable-5 。即使后来的 GPT-5.6-Sol, Opus-5.0 等模型在评测中取得了更高的分数，但我在使用过后逐渐相信，评分也许可以约等于智力，但绝不等于生产力。这就有点类似于，在古法编程时代，一个名牌大学毕业生，即使他带着竞赛金牌、熟练各种算法八股，也并不意味着他能写好代码（甚至我倾向于认为这类人更容易写出“烂代码”）。同理，AI也不是越聪明就能写出越好的代码。

举一个例子，我有一个skill描述了修改代码后执行本地测试的流程，其中有一条 playwright 运行命令。当我用 Opus-5.0 来执行时，它先花了4轮对话来检查本地环境中的playwright是否好用，这是完全没有必要的，也是我在skill中完全没有提及的。正确的做法应该是默认本地环境可用，或者即使要检测也最多是 playwright -v 这类基础指令做简单的检查，先按skill流程执行，如果遇到故障再来 troubleshooting 。相比之下，Fable-5 就几乎不会出现这种问题。

如果只能用一个词来形容，那么我对 Fable-5 的描述是：「老练」。目前只有这一个模型能让我承认它是一个“经验丰富的老工程师”。

我在 X 上看到一个说法：Fable 是 A社 内部最后一个还在被人类员工所训练和使用的模型，而 Sonnet/Opus 则像是被 Fable 调教训练出来的二级产物，后者它们缺少“人味”，很多情况下更像是为了“不犯错”而行动。当然这种说法几乎可以肯定是谣言，但不得不说还挺符合我的实际感受的。

另一个让我血压升高的例子。Sonnet-5.0 刚推出的时候我试用过。用它执行一次任务，在最后阶段，它例行做代码检查和测试。然而即便我的项目中完全没有 Prettier 和 Biome ，我也从未在对话或代码中提及，但它还是擅作主张地调用本地的 Prettier 执行格式化，甚至是对整个项目执行格式化，导致工作区出现了巨量的变化；它倒是发现自己闯祸了，然后想要执行一些命令回滚，却又因为“命令过于危险”被 Claude Code 的安全审查拦下，然后卡在那循环了好几轮无法解决。从此我再也不敢用这个模型，即便是非常简单的任务。按理说 Sonnet-5.0 的评分表现已经离 Opus-4.8 差不太多了，可是实际执行表现却仍有巨大差异，甚至可能比 Sonnet-4.x 还差，更加证明了评分完全不能等价于工作能力。

也正是因为有这个结论，因此后来推出的那几个评分极高的国产模型，GLM-5.2, deepseek-flash-v4-0731 等模型，我都没有兴趣再去尝试了。更别说它们还有涨价、限流等问题，更加不值得了。

AI让人讨厌编程

我从小就喜欢编程。

这不是面试环节的自我修饰，而是事实。我在小学起，那还是零几年、连家用pc还未普及的时代，就参加过编程竞赛（虽然只得到“重在参与奖”）。后续的学生时代也多次自学并写了一些小东西。虽然我大学并不是计算机专业，但在进入社会工作两年后，我还是选择了自学转行。而即使编程成为工作，我的兴趣也丝毫未减，甚至可以说，比起加班费，编程本身的快乐更加吸引我让我工作到深夜。

但自从开始氛围编程后，我的乐趣消失了。编程不再是一种类似数独一样的解谜小游戏，而是化身管理者，分析需求、拆解任务、指挥手下（AI）工作、验收……如此循环往复的一次次管理任务。工作内容从数学推理变成了项目管理。

更可怕的是，在等待AI交付的短暂空隙里，我似乎无事可干。我也曾试过两个项目并行开发，一边AI在写代码时，我就切到另一边去写提示词或者验收——但是，你可以想象的，这太累了。管理本身就是被严重低估的脑力劳动，甚至比编程还要累，毕竟编程当确定了方案，之后的实现经常可以放空大脑凭肌肉记忆完成，可管理不是，AI反馈给你的每一个小决策都是浓缩版，每一个都要全神贯注才能理解它的意思并给出准确的答复。所以我放弃了，宁愿工作效率低一点，或者工作时间长一点，我也不太愿意两个项目并行开发，宁可在一个项目工作期间去摸鱼。

那这些碎片化的休息时间，我在干嘛？可耻的说，我在刷B站，刷X，刷朋友圈，刷淘宝……

其可怕之处在于，虽说是间歇时间，但人是走不开的。因为我不知道Agent这次探索需要5分钟还是15分钟，也不可能依赖手机app远程操作因为必须要看代码验证，所以我只能被禁锢在工位上，用最没有营养的方式消磨时间。（当然也不完全是消磨，B站有很多长视频也富含知识）

于是像这样，工作内容变化 + 高负荷工作 + 被锁在工位 等等因素相加，上班 aka 氛围编程，竟然变成了一件有点难受的事情，这我以前是无法想象的。AI竟然以一种歪打正着的方式负面影响了我的职业生涯。

项目代码重构心得

我们项目的前端代码已经有五六十万行的规模。随着时间的推移，各种各样的技术债务正在不可避免的产生和暴露。

我在过去的2个月时间里，重构了其中的13万行代码。首先感慨效率高得惊人，相比古法手工编程，速度快了有10倍。其次质量也高得意外，上线之后几乎没有oncall。

在这个过程中，我总结了一些心得：

1.从模式开始

我们都知道，软件工程没有银弹，任何技术架构都有取舍，没有完美解决方案。在过去，我很讨厌所谓的“模式”，觉得一板一眼的很僵硬，很容易过度设计，而且“属于八股的主要成分”这点也很让我讨厌。随后当我操盘项目架构几年之后，我虽然渐渐意识到“模式”的价值，但在实践中我依然对它保持冷静中立甚至偏悲观的态度，认为它很难落地，因为架构设计一定是落后于业务需求的，等做出一套“更好的”架构之后往往也无法再应用到旧的代码基础上去了。

而现在，AI打破了这一禁锢。如果只论代码吞吐量，AI的速度是人类的百倍以上。

AI在提供了对庞大代码库重构的可能性的同时，也带来了全新的挑战——如何保证AI生成的代码的质量。

最好的办法就是“模式”。AI不怕麻烦，不管是多么啰嗦多么抽象的架构设计，它都能很好地遵照执行——前提是，你要给他可以“遵照”的范例。

如果说以前受制于抽象成本，人们偏好于“轻模式”；那么以后在AI主导代码产出的情况下，更合理的选择将是“重模式”。

架构设计先从一段prompt或者一份skill开始，然后是一个Demo，然后对着这个Demo反复打磨，融入新的业务、发现新的问题、为解决新的问题而重构、再融入新的业务……如此循环多次，一份适合你项目的好架构就诞生了。之后要做的，就是按照现有的代码形成的“习惯”去生成新的代码，不仅是AI要遵守，更要注意的是人类也必须遵守，绝对不要带入“特例”，保持这个模式的整洁性。

大量遵从相同模式的代码所形成的一种抽象的“习惯”，是比任何prompt/skill都更好的约束。围绕着这份“习惯”，持续做人与人的对齐，再由人来做人与机器的对齐。

在这个重构过程中，有想法的“架构师”的价值将被持续放大，而老黄牛式的“码农”的地位将快速降低。

2.维护信息而不是实现

当代码可以被AI工业化的大批量生产，代码本身的价值已经大量蒸发。我们应该意识到，一个软件产品的价值也会随着AI的发展而挥发，直到剩下那些挥发不了的干货——业务逻辑。

代码是廉价的，但是信息是昂贵的，日复一日年复一年积累下来的海量业务规则是极其昂贵的。

程序员的价值也不再是写代码，而是维护那些隐含在代码中的抽象的“信息”。每次迭代，本质上是把文字、语言、图片、表格等形式的需求转化为用于AI生成代码的prompt，程序员的工作是保证这些信息干净有效，同时剔除工作过程中意外引入到代码的污染信息。只要这些信息是完整的，无论代码如何重构，都能准确快速地重建软件产品。

人类的精力不能与机器相比，因此人类必须把有限的精力用于优先维护那些在代码中看不出来的东西：产品期望实现的效果、技术方案取舍、特殊约定等等。

信息最浓缩的地方，典型的有 skill、markdown、注释等，还有很容易被忽视的一点：测试用例。程序员需要手动维护的就是这些东西。

3.测试是AI的眼睛

「Harness」是一门理论，之前有介绍过这里不再重复。当 Codex、Claude Code 这些产品费尽心思地提升Agent能力的同时，各位一般程序员们也应该意识到，Harness 并不只局限于 Agent 内部。

千言万语浓缩成一句话就是：要想办法提高AI的感知能力。而测试，包括单元测试、集成测试，也包括人工系统测试之后给出的反馈，都是AI感知能力的一部分。能在自动化测试环节做越多的事，AI就能获得更强的感知能力，也就意味着AI能够自动产出越高质量的代码。

前端、后端搭建测试各有各的麻烦，不过总体来说，我认为还是前端更难。因为后端至少在验证环节是简单的，往往只要验证JSON的正确性。而前端还涉及到视觉、交互、动画，还要考虑复杂的客户端环境，确实麻烦很多。但是即使麻烦也要想办法上，因为它太有用了。

由于AI生成代码的速度太快，因此现在实际工作中，生产率的瓶颈一直在人类这一侧，人类总是要花大量的时间去验证。程序员也应该习惯，或者说做好心理准备，未来的工作流程就是开发和测试一半一半，甚至用于测试的时间比“开发”还多，放在以往，这样的岗位其实叫做“测试开发岗”。把屁股挪个位置，从研发负责人的角度来说，以后的招聘需求和人才培养计划应该大量地改成“测试开发岗”。

4.小团队微服务

在古法编程时代，人们尝试过一些项目拆分的实践，后端有“微服务”，前端有“微前端”。它们确实都存在一些问题，但它们本身也是为了解决另一些更大的问题而被提出的。

在AI时代，格局将会有所变化。以前一个人大约只能管理一个几万行代码的小仓库，而如今在AI的辅助下一个人可以维护几十万行代码。而几十万行这个规模，往往已经开始接近硬件设备的瓶颈——无论是开发阶段的编译打包，还是在生产环境的运行时，都会逐渐显露出一些性能问题。所以按这个规模做项目的拆分，其合理性会比以前更高一层。

另一方面的合理性来自于“人-人协同”的高昂成本。前面已经论述过，无论是“模式”、还是“信息”，这都是抽象的，人和人之间想要对齐头脑中的思维，其成本是远比人与机器、机器与机器之间的协同更高的。

所以，在人均代码生产率空前提高的当下，要么选择人员规模不变，代码规模提升，“微服务”以新时代的“大服务”形式体现，同样的团队规模维护多个大型仓库，每个仓库只对应一个人或者一个小组；要么如果产品遇到天花板，代码规模有限的条件下，就只能选择降低人员规模。

以更少的人参与维护同一个项目仓库，可以说这是软件架构一直在追求的目标之一，在如今AI的帮助下，巧妙地推动到了另一个更加理想的平衡点。归根结底，“1个独裁者好于10个民主者”。

5.新的挑战

在氛围编程的实践过程中，也遇到了一些挑战。

第一，各类文档很容易产生漂移。以前我们围绕着代码工作，而基于git分支的工作模式早已成为业界标配，代码本身一定是最新的。但文档不是，而且麻烦的是，文档如果与代码产生了漂移，是很难直观地看出来的，毕竟文档不能运行，只能靠每次工作的时候顺带更新。而如果只依赖AI来更新文档，那会导致一种文档越来越臃肿的倾向——这本身没“错”，因为每个新增的信息都是“有价值”的，而具体价值多少，是不是每一项都要事无巨细地记录下来，这是一门没有标准答案的艺术，绝大多数情况下都依赖每个人各自的审美偏好。AI如果被训练为不犯错的性格，那就必然会它更倾向于保留更多的文档，从而导致文档快速膨胀。

而且除了注释，还有 md、 skill、甚至 memory 等形式的文档，包括AI在内没“人”能保证每次更新都能完整覆盖。

第二，各类缰绳的效果很难评定。代码是死的，单元测试、集成测试、人肉测试……总是有许多方法可以约束。发现一个问题，只要弄清楚了原因，就一定能够稳定复现，就一定能设计一套评价标准来判定某个修复是否真的解决了某个问题。然而，AI，即大语言模型则截然相反。它是一个完全的黑盒，同样的输入，每次都会得到不同的输出，甚至不同的输出之间可以差别很大。你说你写了一个 skill，它效果到底如何，增加了多少token成本/上下文占用，起到了多少实际效果，这类问题，也许理论上能够设计一套方案来评价，但是对于绝大多数软件开发从业者来说，几乎不可实现。

这些截止目前，我也还没有得出比较有把握的解决方案，只能说摸索着前进。

正式告别Jetbrains

几个月前我就在一篇文章中说过，由于 Jetbrains 在国内只能提供国产模型效果实在拉跨，并且它本身的 Agent 能力也不如更流行的 Codex，Claude Code 之类，在AI编程的时代浪潮之下，我已经很少亲手写代码了——虽然还需要大量看代码，但是「看」对于IDE的要求显然要比「写」低很多——因此我已经决定停止订阅 Jetbrains 了。

不过我实际上没有完全狠下心来。我没有完全停止订阅，而是把全家桶订阅降级为了Webstorm订阅。

理由是：JB 的 git插件 实在太好用了。假设我对 git UI工具的需求是100分，那么 jb 的 git插件 我可以给99分，几乎我能够想象到的所有git操作它都提供了非常好用的图形界面，并且运行稳定。可是 VS Code 的 git插件，原本自带的我只能给30分，打上免费插件如 graph 之类的可以给 40分，需要付费订阅的 gitlens 我可以给 50分，远远达不到 JB 的使用体验。因此实际工作中，我大部分时间氛围编程在 VS Code 中进行，而当需要做一些复杂的 git操作的时候，我会打开 Webstorm 。

这里顺便吐槽，gitlens 的订阅费居然高达 CN¥22.80/月（年订），这个价格再添一点都够订阅 Webstorm 了，却依然只能拿出一个半成品来，只能说他们这定价勇气可嘉。

然而Webstorm也有问题。第一，它依然需要钱，不算便宜，我只用git插件，很亏。第二，它加载了大量的功能插件，我只用git插件，也很浪费电脑性能。

直到我了解了这个项目：Rebased ，它响应了包括我在内的很多程序员的呼声（心声），从 IDEA社区版 分叉出来，删减掉了所有不必要的功能插件，只保留git及其所需依赖，并且免费开源。可以说是当今最强git软件没有之一。

香，太香了。谁用谁知道。

这下我是真可以彻底退订 jetbrains 了。

后续：然而退订并不顺利。已经付钱的订阅，只有很短暂的时间范围内可以退款，过了时间后就无法退款了。所谓“退订”，只是停止下一个周期的扣费。这让我心情有些糟糕，因为我有一笔相当可观的金额还在这些剩余的订阅时间里。也许从法律上说 JB 制定的这套退费政策是合法的，但在实践中这是一种很强硬的客服姿态，在互联网行业非常少见。而完全相反的、作为正面典型代表的 Github Copilot ，我的年订计费甚至可以完全按时间等比例退款，甚至不用扣除月订与年订的优惠差。对比之下高下立判，虽然我已经不再使用 Copilot ，但我这段时间也算尽量给它说些好话；可从此刻起我对 Jetbrains 就已经是彻底的“路转黑”了，我再不会帮它说话，只会落井下石。

说到这里我有些感慨。这些年来，微软的计费政策是真挺厚道的。想想自己从小到大用的都是盗版windows，虽然网传一些阴谋论，但并不妨害我没有受太大干扰地用了很长时间的盗版软件。以至于当我经济独立，手头比较宽裕后，毅然决定通过微软商店官方渠道买了一份“天价”的windows系统授权许可，作为这些年使用盗版的补偿和忏悔。当然微软也存在不少问题，但至少我个人这么多年打交道下来，没踩到什么很大的坑。

显示器的选择

前阵子，趁着更新了显卡的契机，我也同时买了一台新的显示器。

新显示器是 Mini-LED 背光，HDR 1400，4K高刷，纸面参数很高。但是用下来实际体验一言难尽。

Mini-LED 最大的问题就是它的分区背光，即使是现在市场上最顶级、分区数量最高的 Mini-LED 产品，其背光分区情况依然非常不理想。典型是电影字幕场景，即全屏大范围黑色+少量文字留白，此时文字周围会有明显的光晕，且文字本身亮度不均匀、看不清楚，这种场景下几乎不可用。

另一方面，Mini-LED 产品往往会以HDR指标作为卖点，然而为了达到很高的HDR标准，其最大亮度也要做得很高，这会给人类的眼睛造成很大的压力。特别是遇到一些情况，例如屏幕校正、或者某些游戏没做好适配导致出现全屏最大亮度白色闪烁等情况，简直就像一颗闪光弹，闪得人情不自禁地眯起眼睛甚至转过头去。此外，HDR的兼容性在如今依然是个很大的问题，首先windows桌面的hdr完全是负面效果，一般只有在玩大型游戏、或者高清影音的场景才会对HDR有支持。

其实它这种高亮度的特性，最适合的使用场景还是用作客厅电视，因为在客厅里人坐得离电视比较远，且容易受到阳台阳光的干扰，此时高亮度的收益很大。这与我踩过的另一个坑：投影仪，是截然相反的。但它不适合用作电脑显示器，因为人离屏幕太近了。

如果只是日常办公、写代码、普通观影场景，真的不需要很高配的显示器，就选择最常见、最实惠的 LCD液晶IPS面板 款式就足够了，4K 60HZ 价格也就一千元左右，好点的一千多，完全够用了。它没有明显的短板，皮实耐操，开箱即用，综合使用体验是最好的。

OLED 是第三种选择。它的最大优势是色彩逼真、鲜艳，特别是“黑色”可以显示为“绝对的黑”这是其他显示器材料做不到的，综合显示效果是最好的。但它有两个问题，第一是贵，第二是它有寿命，由于其材料是有机物质存在寿命限制，特别是如果在日常办公场景，有很多显示元素长期不变的情况，更会加速伤害面板材料的寿命，每使用几个小时之后需要休息一段时间或者运行特定的屏幕保护程序。

如果让我再选一次，我会给我自己的电脑配两块屏幕：一块主屏幕就普通的LCD液晶，负责日常桌面、办公、浏览器等场景；另一块OLED专门用来游戏、影音，平时只开纯黑色桌面背景以保护屏幕。