何幻

Programming is about ideas,
languages are just a way to express them.


  • 首页

  • 归档

  • 分类

程序员如何克服思维定式

发表于 2026-03-12 | 分类于 AI

背景

2026 年开始后,AI 的发展越来越快了。

导火索是从 Cowork 开始的(2026.01),是由 Anthropic(Claude)公司开发的。

Cowork 把 AI 的应用场景,直接从写代码扩展到了日常办公。


顺着这个思路,杀手级项目 OpenClaw 出现了(2026.02),

然后就是病毒式的传播,OpenClaw 迅速登顶 Github 历史星榜第一。


再就是中国的春节了。

春节后,国内所有大厂几乎全都 All in Claw(龙虾)。

每时每刻都有新闻在发布,数以百计的 xxxClaw 出现。

前言

AI 的发展确实非常快,但除了我们能看到 AI 产品如雨后春笋一样冒出来之外,

我还能感受到自己的成见,也每时每刻被打破销毁。


所以我想整理下,当 AI 突然变得这样强大的时候,

我们应当如何看待「编程」这件事情。

古法编程

行业内把仍然采用人工编写代码的方式,戏称为「古法编程」。

在今年春节之前,我对这种说法,还很不在意。直到加入公司内「龙虾」相关的项目之后。


在 AI 编程盛行的前几个月,很多人都感受到,

使用 AI 写代码是要区分场景的,要求越严格越苛刻的项目,AI 就越难写完善。

但是对于新项目、自己发挥的创业项目,AI 写代码的效率就非常之高。


这是为什么呢?是因为自己作为项目的需求方,当指导 AI 编程遇到困难时,可以随时调整需求。

就不用跟 AI 频繁对话,把项目做成跟「被要求」的一模一样了。

做成一模一样,与允许 AI 自由发挥,是完全不同的两种问题。


这就是为什么之前在行业内,会有截然不同的两类认识了。

有些人认为 AI 编程很费劲,总是出问题;

而另一些则开着数十个终端,指挥着一个 AI 军团在写代码了。

SaaS 落幕

这件事本来已经告一段落了。因为除非提供「脑机接口」,否则 AI 肯定无法跟我们想的一模一样。

那些旧项目的开发者们,也不得不持续经历痛苦,更多的采用「古法编程」或者「AI 辅助编程」才行。


但 AI 的发展状态持续发酵,人们发现当 AI 可以应对办公场景后(例如使用 Cowork),

就不再需要那些定制化的 SaaS 软件了。

于是 SaaS 类软件公司的股价大跌,随之而来的影响是,维护旧 SaaS 应用的开发者们「没需求」了。


这意味着什么?意味着「古法编程」彻底告一段落。

新起的这些项目,会全都采用 AI 原生(AI Native)的方式编写和构建。


所以从根本上,让人们必须手动编写代码的原因,不是因为 AI 写不了代码,

而是因为让 AI 理解定制化的需求太费劲了,很难描述完整。

现在没有类似这样的需求了,反而解放了生产力。


当然 SaaS 软件肯定还会有它的适用场景,这里说的是对开发者的影响。

AI Native

AI 原生(AI Native)是一个很早就被提出来的概念,

跟云原生的概念一样,其实最早是一个产品形态方面的划分方式。


但随着 AI 编程越来越普及和场景适用之后,人们发现 AI 原生其实并不只是产品这么简单,

还会影响人们编写和设计软件的方式,甚至影响「程序员写代码时思维方式」。

1. 代码形态

考虑着「AI 原生」的程序员,应该时刻提醒自己,任何环境下都有 AI 存在。

比如说,我写的代码何必是代码。

因为程序「被执行的环境」有 AI 了,是不是直接给它用「人话」写业务逻辑就行了。


各种编程工具 Claude/Cursor 都已经支持 Skills 了,

OpenClaw 同样也支持 Skills 扩展。

这些 Skills 可不是纯编程语言了,而是用「人话」(中英文)编写的逻辑单元。


以前我想编写一个自动化任务,可能要写一段脚本,然后发布为一个 npm 包(或者其他的)。

现在只需要用「人话」讲清楚这个任务应该怎么做就可以了(用人话说,第一步干什么,第二步干什么)。

所以,从这个角度来讲的话,Skills 就是代码。

2. 返回值

除了这个影响之外,还有很多。

既然代码的执行环境中有 AI 了,以前的代码返回的信息,又何必是代码。

我只要让代码返回「人话」,AI 看到后就能按照我说的人话执行了。


比如说,以前 http 接口的响应值,通常是一个结构化的 JSON。

现在只要返回人话即可,比如说:操作成功了,帮我接着执行 xxx。

或者说:操作失败了,给我向 xx 群发消息通知。


而不是根据返回值,自己编写下一步、或者群发消息的代码了。


更有甚者,我们又何必改以前的代码,让 AI 把 JSON 翻译成人话也就行了。

或者它如果能理解 JSON,何必需要翻译。

3. 动态代码

还有另外一个问题,因为 AI 是可以自己写代码的。

那么当我需要执行一个任务的时候,何必让它跑已经写好的代码呢?

让它当场写个代码来执行,是不是也行。临时代码用完即走。


这种「动态生成代码」的技术其实早就有,但是在 AI 原生时代被充分放大了。

比如说,以前我想编写一个在各种操作系统中,都兼容能用的程序。

肯定免不了一些判断,甚至在代码执行的过程中,也要判断。


现在大可不必这样做了。我们可以先用「人话」让 AI 判断下当前的环境(动态代码)。

然后让 AI 直接「生成」当前这个操作系统可用的代码就行了。别的系统的不用生成。

大大简化了实际被运行的代码量。


类似的问题还有很多,不过整体思路都是,在逻辑的执行过程中,让 AI 自己写代码做事情。

甚至最后生成的代码,都可以让 AI 写出来就行了。

4. 小结

其实 AI 原生的影响,还远远没写全。

但我们已经可以大致看出端倪了,AI 原生对开发习惯的影响非常大。

  • 我写的业务逻辑何必是代码

  • 代码返回的信息,又何必是代码

  • 何必执行提前写好的代码


所以在 AI 原生时代,程序员除了要写代码之外,还要仔细权衡。

哪些逻辑应然需要以代码(编程语言)的形式存在,哪些可以用人话描述就够了。


随着 AI 原生思想的渗透,我想这个边界会越来越模糊。

比如说,我现在让 AI 写代码时,都会让它自己先把「小本本」准备好。


先通读项目中的所有代码,然后整理成文档。

文档中写清楚,以后 AI 看到这个项目后,先看文档。更新项目后,立马更新文档。

以后 AI 就是这个项目的负责人了,我只负责告诉它怎么改。

这个不用记,以后每个 AI 都会自己学会这么做的,不用我们说。

未来已来

我经常在社区中发现很多「新颖」的 AI 用法。

除了上文提到的让 AI 自己拿个「小本本」记着之外。还有太多太多了。


比如说,以前你想让 AI 理解上下文,是需要给它输入很多内容的。

现在你能想到的是不是,给它复制粘贴进去就行了。

然而,又何必给它讲那么多呢,直接给它贴某个博客地址就行,让它自己打开学。


然而又然而,你有何必给它贴博客地址呢,你让它先把某个站点的内容都学一遍。

固化到 AI 自己的记忆里,以后都不用学了。


然而又然而又然而,你有何必跟他讲学什么呢,让它搞个定时任务,自己去学「新技术」就好了。

学到了什么,跟你同步下。你只需要点头或者拒绝就行了。


…… 等等等等,这个链路还可以无限延伸。


AI 时代,给我们最大的启示就是,真的要把 AI 当人看。

它就是一个完整的人,你能做的它都行,你不能做的它可能也行。

结语

本文主要内容是想谈论「思维定式」。

我们看到,AI 不但从产品功能层面影响了人们的认知,

还进一步在「如何构建产品」层面,影响了「开发者的认知」。


软件行业的门槛,已经大幅度降低了。所覆盖的人群,已经从能编写代码,扩展到了整个知识工作者群体。

程序员脑海中的,总是想用「编程语言」解决问题的「习惯」应该改改了。

我觉得更重要的反而是之前开发过程中,所积累的一些「工程和架构」思维。


如何管理复杂度,如何把事情描述清楚,如何保障质量和提高稳定性。

如何管控项目。

如何带领一个团队赢得商业竞争。


由于家里的环境还没准备好,但我感觉这很可能是我最后一篇「古法编写」的博客了。

12…315>

315 日志
12 分类
知乎 简书
© 2026
由 Hexo 强力驱动
主题 - NexT.Pisces