月度归档:2026年01月

太原之旅

2026 年的第一次出游,我们去了山河四省中的山西,来到了山西省会太原。

来到山西,则一定要吃面;不过,作为一个河南人,其实我也没少吃面,很多面的品类我在河南也没少吃(我家是焦作的,旁边60 公里就是晋城,所以对山西还挺熟悉的;爬山手机信号都有可能漂到山西),所以这次我们就更加聚焦在一些山西特有,在河南没有的东西上。

到太原的时候是早上 10 点,所以先去试了试太原的特色早餐 —— 「头脑」,顺便还吃了清和元的「稍梅」(其实就是烧麦啦,叫法不同)。头脑这个东西还是挺有意思,是一种药膳,里面还加了黄酒。不过,我在现场吃的时候,以为是把中药熬成了糊糊,结果后面看视频才发现,其实是中药煮出来的水配合面变成这样的,并不是中药糊糊🤣,眼中营养价值下降了一大截。

除了头脑之外,还在清和元吃了「醋椒羊肉」,这个说是太原特色,不过作为一个新天津人,我其实想到的是天津的马砂 ——醋椒豆腐。你别说,味道还是有那么一点点相似之处的。

太原 – 清和元 – 头脑
太原 – 清和元 – 稍梅(我觉得就是烧麦,叫法不同)
醋椒羊肉
太原 – 清和元 – 醋椒羊肉

在太原,有一个小吃是非常有特色的 —— 沾串;基本上非本地人看到这个的时候,都会觉得,一堆人围在一起吃,共用蘸料,非常的不干净;我们在逛太原的许西夜市的时候,看到了沾串,但奈何现场的环境看起来颇为劝退,我们就没能吃成沾串(过不去心里的关)。

原本第二天是想早点起来,去沾串店里吃第一轮,这样会干净一点。但突然灵机一动,我意识到 —— 沾串是有外卖的,而外卖的沾串,是不太可能从别人正在吃的酱料里给你挖出来的,肯定是从旁边的暖壶里给你倒出来的,这个是干净的啊!于是就点了外卖,在酒店吃了沾串。

为了更进一步模拟沾串的环境,我特地选择了 —— 站着吃沾串。不得不说,沾串我觉得还是在店里吃比较好,主要的原因还是送过来的蘸料容易凉,而这些素菜本地就是凉的,会导致吃起来可能不那么舒服,不过,考虑到安全问题,我觉得还不错啦!而且吃过一次,后续就知道这玩意怎么搞了,也可以试着自己在家里搞了。

这里我比较推荐大家多几个人一起点,主要是沾串这玩意主要吃的是不同的料,正常情况下美团的套餐一般就带个一两种料,你加料的话,还是挺贵的….

太原- 沾串

太原也是一个历史名城,所以,我们这次规划的行程主要就是逛博物馆;我们逛了 —— 晋祠博物馆、山西博物院、北齐壁画博物馆、中国煤炭博物馆。

如果让我自己评价的话,晋祠是必去的 —— 里面有很多 86 版西游记的参考来源,比如下面这个水镜台,86 版西游记里孙悟空和二郎神打斗中间变的庙的原型就是他。

北齐壁画博物馆的话,如果对壁画感兴趣可以去看看,如果不感兴趣的话,这个馆很小,可能也没啥特色。

不过我在北齐壁画博物馆发现了个好玩的墙,是从壁画中摘出来的北齐人的画像,感觉很适合组团当头像玩(

山西博物院有很多展品,适合对于山西历史感兴趣的人去看看,我还拍了一个蠢萌蠢萌的展品。

这里我相比于一般的人多去了个中国煤炭博物馆,主要还是因为作为焦作人,一个曾经的煤城的孩子(我的两个舅舅都是在煤矿体系工作),还是要来看看中国的煤炭历史。不过因为时间的原因,没尝试他们的下煤矿的玩法,下次再试。

我还专门拍了一张河南的煤炭工业布局,你能在里面找到焦作么?

意外之喜

从太远飞回天津时,我坐了个 —— 巴航 ERJ190 的客机,让我开拓了眼界。我之前只坐过空客和波音的飞机,没坐过巴航的飞机,然后还专门查了一下,巴航的全称是巴西航空工业。

从坐的体感来说,我觉得巴航 ERJ190 的舒适度是高于波音和空客的小飞机的,给巴航点赞👍。

总结

这次来太原,因为时间缘故,我也没有安排的特别满,希望尽可能轻松的玩一玩,所以,只去了几个核心的地方,不过,太原,我觉得还是可以再来的。

后面再来!

从“代码补全”到“全托管 Agent”:我的 2025 AI Coding 进化论

本文有一个 Online 的 Sample 版本。如果你对于「我具体是怎么做的」感兴趣,可以直接看这个 Twitter Threads

2025 年,我的工作习惯彻底被 Claude Code / Cursor / Codex 改变了;这一年给我带来的改变,不亚于当年我用易语言写出第一个应用程序的时候。这句话不仅适用于我的产品经理身份,同样适用于我的工程师身份。这不仅是软件开发效率的提升,更是软件开发方式的重构。

AI Coding?到底是什么?

在社交媒体上讨论 AI 编程的时候,很多时候大家其实没有对齐在讨论的 AI 编程的范畴和适用领域,使得大部分时候,大家在鸡同鸭讲,公说公有理,婆说婆有理。所以,在我们真正讨论 AI 编程之前,我们需要先澄清一下,我们到底在讨论什么「AI Coding」?

目前来说, AI Coding 有几种不同的产品形态和用户交互形态,他们包括:

  1. L1:古典的直接问 ChatGPT:有问题直接问 ChatGPT、Gemini、Claude 等 AI 助手,借助 AI 助手给出的信息,自行 Debug 和修改代码。
  2. L2:使用 IDE / 插件中提供的补全功能:直接写函数名,然后 AI 会帮你补全函数的细节,你再自己微调或者不微调。这种能力其实过去也有,只是没有这么强悍。大家使用 IDE 来开发,很大程度上就是 IDE 提供了极好的补全能力。
  3. L3:使用本地的 AI Coding 工具的 Agent 模式,全托管或半托管式的编程:你只描述需要做什么,具体做动作由 AI 来完成;这里还有几个细分的方式,包括完全托管(比如 claude code 开 –dangerously-skip-permissions ; codex 开 –dangerously-bypass-approvals-and-sandbox)和半托管(用户手动确认行为,只是由 AI 来完成具体修改的动作)。L3 操作的是你的本地环境,有破坏的风险,但也有无限的可能。
  4. L4:使用网页端的 AI Coding 工具,直接出 Demo:你不需要在本地有任何开发环境的配置,直接在网页端使用一个应用,来完成 Coding,你只需要描述你想要的东西,剩下的完全交给 AI(虽然这往往意味着难以与复杂的本地业务流集成)。

大家在社交媒体上和别人讨论 AI Coding 的时候,需要注意,很有可能你在聊的是 L3 ,但别人在聊的是 L4 ;你们看似聊的都是一个东西,但实际上是完全不同的东西。我们这篇文章讨论的,则主要是 L3 —— 即使用本地的 AI Coding 工具的 Agent 模式,全托管或半托管式的编程。

到底谁在用 AI Coding 工具的 Agent 模式?为什么是 Agent 模式?

说完了大家眼中不同的 AI Coding 工具,我也必须再强调一下,即使大家聊的都是【AI Coding 工具的 Agent 模式】,因为身份的不同,每个人的用法也会有很大差异,大家对他的预期也完全不同。因此,不同的人对其的评价也千差地别:其中大体也可以拆分为三个大类:

  1. 传统的软件工程师:使用 AI Coding 工具完成自己工作过程中的一些辅助性工作,对于自身的能力和工作的要求有较高的要求。
  2. 有一定研发概念的产品工程师(称之为产品工程师是因为他们有一些基础的软件工程概念):使用 AI Coding 工具拓展自己的能力圈,去做一些之前必须依赖软件工程师才能做完的事情(比如做个小 Demo,或是上线一个软件产品)。
  3. 被媒体上的文章忽悠进来的小白(他们基本上没有太多的软件工程经验和基础):跟着网络上的信息了解到了 Coding Agent,然后尝试在不同的软件上使用(不局限于 Claude Code,Cursor 的 Agent 模式也算),经常会卡在一些软件工程的基础问题上。(我特别推荐这类人去看《计算机教育中缺失的一课》,看完以后,会让你很快理解你所遇到的问题,并能够快速处理 AI Agent 所给你的信息,进行下一步操作)。

这三类人因为工作的要求、对于软件工程的理解的不同,会导致他们使用 AI Coding 工具的 Agent 产出完全不同的体验,从而有不同的评价。

而之所以是 Agent 模式,是因为相比于补全模式需要你现有一段代码;Chat 模式往往不指引你完成所有的工作或需要你现有互联网软件的基础才能完成工作;Agent 模式自带的环境操作能力,使得你即使完全不懂 AI 和 Coding,也可以做一个像模像样的小应用出来。这打破了过去需要软件工程师才能做出一个 Demo 的限制,同时也极大的鼓励了新手小白,试着去做一些有意思的事情。

Agent 模式也是 AI Coding 最出圈的一个 Feature;

我和 AI Coding 工具的 Agent 模式的缘分

在这条上,我提到,我其实经历过三种不同的状态,这源自于我过去一年的体验。

在过去这一年里,我从一个「以补全为主,抗拒 AI Coding Agent」的工程师,转变为了一个「好好利用 AI Coding Agent」的工程师。这其中,离不开我身边的朋友们和小伙伴们,和他们的协作,让我真的意识到了 AI Coding Agent 的价值。

这里要感谢刘超、杨鼎睿、岳增五,和你们的协作让我极大的改变了自己对于 AI Coding 的认知和看法。

作为一个写了十数年代码的工程师,我拥有一些自己平时写代码的脚手架,可以帮助我快速完成一个项目,而同时,作为工程师的自我要求,我希望我自己写的代码能够拥有不错的代码质量和性能,从而可以提供一个稳定的软件质量。所以在一开始,我对于 AI Coding Agent 的能力是持怀疑态度的,虽然依然会使用,但整体信任度没有那么高,往往只让它处理细枝末节,基本上是让 AI 去写一个完整的功能的细节,或者是让 AI Coding Agent 去进行 Code Review,而不是让他去动业务代码;直到 Claude Sonnet 3.7 的时候,我才发现 Claude Code 已经能完成不少的工作,甚至很多小的 Feature,不再需要我先行规划,再让他自己去做细节,我可以非常坦然的交给他一些功能,让他自己去完成我只做关键验收。

而从这个时刻开始,我对于 AI Coding Agent 的使用开始与日俱增,我开始使用 AI Coding 去完成越来越多的功能和效果,然后,我开始对 AI Coding 放权;开启了 --dangerously-skip-permissions ,让 Claude Code 自己去写代码,去实现效果;

也和所有的使用 AI Coding Agent 的人一样,我也经历过 AI Coding 工具将代码整的一团糟,然后放弃的时刻。不得不说,Claude 有些时候的过度设计,真的让人觉得无语。或许这是最佳实践,但最佳实践不仅仅要配合着实践用,也要配合着项目的时间节点和周期,以更好的完成项目的目标 —— 你要记得,Coding 只是完成目标的手段,而不是目的。

不过,随着对于 AI Coding Agent 的逐步使用的深入,我对于 AI Coding Agent 的使用越来越了解也越来越多的在不同的场景下去使用 AI Coding Agent ,去完成自己的工作。

如今的我对于 AI Coding Agent 模式的观点

首先,我旗帜鲜明的说所有的软件工程师都应该试着使用 AI Coding Agent,放弃、逃避、蒙头装鸵鸟都是没有意义的,熟练掌握 AI Coding Agent 已不再是加分项,而是生存技能。 AI Coding Agent 正在切实的改变着我们的行业。诚然,AI Coding Agent 不会影响我们这些「老」工程师的工作,但这个问题如同被熊追着我们一样 —— 淘汰你的从来不是熊,而是比你跑得更快的人。 AI 不会淘汰工程师,但会淘汰那些拒绝进化的“手动操作员”。优秀的工程师不会消失,我们的职责正从“手写逻辑”转变为“选择方案、设计架构、验收质量”。

其次,我依然相信大家的软件工程经验是有价值的,就像上面我提到,最佳实践本身没有问题,但每个人所面对的项目的节奏是完全不同的。软件工程师的价值从手写代码,变为了选择 AI 提供的解决方案,Review AI 提供的解决方案,可以帮助我们更好的完成自己的工作。优秀的软件工程师只是工作职责变了,但他们不会消失,甚至会获得更多的加成

我现在怎么用这些 Coding Agent?

我目前自己同时在使用的包括 Claude Code、OpenAI Codex、和 Gemini Cli;其中前两者是我自己花钱买的,后者是 GDG 赠送的。

我强烈建议大家自己花钱购买。如果公司买了最好,如果公司没买,自己买也是划算的。 Claude Code 5X 已经满足日常使用了,如果你用量大,再升级 Claude Code 20X 即可;$100 其实就是大家聚餐吃一顿价格,并不贵,但给你带来的提升是远超这个价格的。

我对于 Coding Agent 的使用会包含两块:

  1. 本地使用
  2. 云端使用

以及,一些质量守卫。

本地使用

本地使用时,我会使用 Claude Code 的 Plan Mode 来设计一些需求,通过和 Coding Agent 的几轮交互,约束需求的范围,并让 Claude Code 去完成相关的功能;

同时,我会使用 Codex 来为我的项目补全测试 —— 过去我自己很多时候懒得写测试,现在有了 AI 来帮助我们完成测试的基础覆盖,大大提升了我的效率。或许 AI 无法保证测试的如一个专业的测试同学,但却可以让我先完成从 0 到 1 的建设,让我自己可以变的更好。

Gemini Cli 则会在一些时候,我会让其作为项目的补充,主要也是 GDG 赠送的 Plan 额度有限,所以用的不多。

之所以会同时使用三个不同的 Coding Agent,主要还是考虑到模型本身的能力是有差异的;不同的模型可以给我提供不同的视角,从而可以确保对于一个问题有更全面的思考,规避可能的思维漏洞。

云端使用

除了本地的使用,我还会在云端使用 AI Coding Agent,但并不是使用网页端的 Coding 工具,而是在 CI 工具链中集成 AI Coding Agent,使用 AI Coding Agent 对于我的每一次提交、每一次 PR 进行 Code Review ,通过这样的方式,帮助我更好的发现代码中的问题,既可以确保自己对于问题的思考没有漏洞,同时可以进一步的发现自己的经验不足,补全对于问题的思考维度。

特别是,集成多个 Coding Agent 可以明显看到不同 Coding Agent 对于问题的思考角度和深度不同,对于自我提升非常有帮助。

质量守卫

由于AI Coding Agent 本身存在的问题,往往会在大规模编辑代码的时候,存在一些编辑错误、无用代码、不符合规范的问题,因此我在深度使用 AI Coding Agent 的项目中,都会引入大量的质量守卫,来确保不符合规范的代码无法提交到云上。我们应当保持对 AI 的信任,但必须坚守 「信任,但要核实 (Trust, but Verify)」 的原则,确保 AI 提交的代码每一行都可信、可控。

具体包括:

  1. 引入静态检查的准入机制,扼杀低级错误:借助 git hook,在提交前进行 code format
  2. 引入质量红线,控制确保逻辑不出错,没有改错之前的代码:借助 git hook 和单元测试围栏,要求提交到代码库中的代码必须测试覆盖率满足要求(强 AI Coding Agent 介入的项目会要求测试覆盖率到 100%;并包含集成测试和端到端测试)。
  3. 引入 AI Agent 的自愈能力,闭环问题的修复:借助 git hook 和一些 linter 工具,发现代码中的问题,并让 AI Coding Agent 自己去修复他。
  4. 引入代码复杂度分析工具,让 AI 写出人和 AI 都易于维护的代码:常见的编程语言基本上都提供了圈复杂度检查工具,你可以在你的项目中引入圈复杂度检查工具,让 AI 提交之前确保所有代码的复杂度不会太高,从而既可以借助 AI 的能力快速迭代,同时又保留自己随时介入的可能性。

当你有充足的围栏检查的时候,你就可以放心让你的 AI 去完成工作,并要求他自行提交 commit,这样可以让其自动执行 git hook ,并修复 git hook 中所配置的工具检查出来的问题,从而确保提交到代码库中的代码不会有一些基础问题。

如果你还没有开始使用 AI Coding Agent ,你要怎么开始(工程师篇)

如果你是一个工程师,想要试试 AI Coding Agent ,但不知道怎么做?

  • 我能理解你对于代码质量的要求和你的工作对于你的要求;
  • 我也知道你担心引入 AI 导致你的项目复杂度快速提升,无法维护,最后导致项目彻底崩盘,你反而被干掉;

所以,我推荐你这么干:

  1. 在现有的 CI 工具链中加入 AI Coding Agent 进行 Review,从而让 AI 先从 Review 代码开始,给你提供更多的建议,帮助你先变成一个更好的工程师;
  2. 在习惯让 AI Coding Agent 参与到你的工作流里后,可以先让 AI 帮助你补全测试,建立起单元测试围栏,从而让你放心的使用 AI Coding Agent 参与到你的项目里;
  3. 使用 AI Coding Agent 完成你的工作(记得加入各种围栏),让你自己获得进一步的解放。

当你完成了上述三步后,你已经熟悉了 AI Coding Agent,就可以除了做一些你熟悉的工作,还可以让他带着你,去做一些你所不熟悉的事情,比如你是前端,让他带着你搞后端;或者你是后端,让他带着你搞 iOS。

总结

到了 2026 年,你依然可以 Happy Coding,不过你要学会意识到,我们除了做体力劳动的 Coding,我们更应该用好 AI Coding 工具,将体力劳动托管给 AI Coding Agent,让自己的工作越来越具有「创造性」,做一个「创造者」。

AI 来了,你还要写 Blog 么?

最近在 V2ex 上看到一个帖子,AI 是不是基本杀死了 blog,我在帖子里回了一嘴:「blog 是自己写给自己的。不是写给别人的」,基本表达了我的观点。今天我来详细的阐述一下我的观点。

Blog 到底是什么?

贴中原贴主提到的是 CSDN 等 Blog,所以在他的观点当中, Blog 主要是以 CSDN 这样的技术 Blog 为主。但实际上,Blog 是一个极大的分类,Blog 是 Web Log 的缩写,你约等于可以理解为这是一个「个人网络日记」,与之对应的是本地的、线下的、纸质的日记。

Blog 真的会被杀死么?

Blog 的杀死与不被杀死,其实只由「Blog 主」来决策;AI 所能提供的,是帮助 Blogger 更快的识别出这个问题。

在过去的很多年里,CSDN 上充斥着大量的低质量的技术文章,基本上都是 Copy & Paste 某些技术条目(坦诚的讲,我也写过类似的内容,你在这个 Blog 上也能看到一些),然后就结束了,不加任何的思考和想法。如果将 Blog 的领域缩小到这个范围,我认为,这个答案可能是基本上是的。我们确实不太需要那么多 Copy & Paste 的技术文章,因为这些内容 AI 其实已经都学习了,他的记忆中已经有相关的内容,能够提供给你。

但,技术类型文章,是无法被杀死的,也是需要更多的 Blogger 来去创作的。AI 大模型的原理决定了,他只能做「训练数据中有的部分」,没办法去做「训练数据中没有的部分」。而技术领域的信息不是停滞不前的,我们每时每刻都有新的开源代码被提交(当前,里面可能有一部分是 AI 生成的,但如果这个生产过程中有人在其中辅助,你都不应该视为这部分信息是模型天然已知的内容,因为人在其中加入了额外的变量)。这些内容从他们出现在技术领域中,到被大模型学习到再到被大家使用,中间的周期可能长达数月。我们不可能在这数月期间,不对这个领域做任何的学习、改造和迭代。

所以,Copy & Paste 的 Blog 是会消失,但更多的新的、原创的内容,会越来越多。唯一的问题是:你是否是那个原创 Blog 的作者?

回归本心写 Blog

除了从数据的层面去分析来看,我一贯的观点是 —— Blog 是写给自己的。写作是我若干年来非常重要的一个技能,这个技能帮助你理清自己纷乱的思绪,让你脑海中的无需信息变成了有序的知识,所以,我热衷于记录、热衷于写 Blog,本质上是我在不断的通过写 Blog 来优化我的大脑,优化我脑海中的信息。

如果你认可这个假设,那么这件事,就不言自明 —— 你会因为 AI 的到来就停止思考么?如果是的,那么你确实不需要 Blog;但如果不是,Blog 依然要写,还要持续写。可能是写到生命的尽头。