#AI编程

2周前
Cursor 的终极野心:不当“副驾”,要重塑“驾驶”本身 当所有 AI 编程工具都满足于成为程序员的“副驾驶”(Copilot)时,Cursor 的创始人迈克尔·特鲁尔(Michael Truell)宣告了一个更宏大的目标:他们的使命,不是辅助编程,而是用一种更高级的方式,彻底取代编程。 他认为,我们正处在一个过渡期。AI 目前帮助人类编写了 40-50% 的代码,但这只是“量”的提升。真正的未来,是一场“质”的革命——开发者将从繁琐、晦涩的编程语言中解放出来,只需通过更接近自然语言的方式描述“意图”,软件即可被构建和修改。 今天的 Cursor 是最好用的 AI 编码工具,但这只是通往终局的路径。其最终愿景,是引领这场从“编码”到“意图表达”的范式革命。 二、工程师的未来:当 AI 负责实现,你的“品味”将无可替代 当 AI 越来越多地接管“如何做”的实现细节后,工程师最核心的价值是什么? 特鲁尔的答案只有一个词:品味(Taste)。 这里的“品味”,远不止是视觉审美。它是一种对软件更高维度的判断力,一种深刻的直觉,关乎: - 应该构建什么?(对产品方向的洞察) - 它应该如何运作?(对系统逻辑的优雅设计) 他将大量繁琐的编码工作比作“人工编译”——费力地将高层次的想法,翻译成机器能懂的低级语言。当 AI 自动化这个过程后,决定产品成败的,不再是精通语法细节,而是你头脑中那个高层次的构想和设计能力。 未来,平庸的工程师会被 AI 取代,但拥有顶级“品味”的工程师,将变得前所未有的强大。 三、关键战略:宁做独立的“编辑器”,不做受限的“扩展” 在产品形态上,Cursor 做了一个在当时备受争议的决策:构建一个独立的编辑器,而不是一个依附于 VS Code 的扩展程序。 这个选择源于一个核心预判:AI 将彻底改变编程的交互形态。 如果只是做扩展,你将永远被宿主平台的 API 和界面所限制,无法实现颠覆性创新。为了完全控制用户体验,为了给未来更高级的交互范式(如直接操作 UI、更高阶的逻辑语言)铺平道路,你必须拥有属于自己的“画布”。 事实证明,正是这个“不走捷径”的决策,为 Cursor 的快速迭代提供了巨大的自由度,使其能超越众多竞争者。 四、AI 时代的护城河:不是算法,而是“数据飞轮” 在模型日新月异的今天,如何构建持久的护城河? 特鲁尔认为,AI 时代的竞争,像极了 90 年代末的搜索引擎大战。真正的护城河不是某个单点技术,而是由大规模分发驱动的数据飞轮。 - 分发: 通过服务海量用户,获取产品的使用权。 - 数据: 收集关于 AI 生成代码的最宝贵反馈——用户接受了什么?拒绝了什么?以及,他们是如何修正的? - 优化: 这些真实世界的反馈数据,是优化产品体验和底层定制模型的最佳养料。 - 循环: 更好的产品吸引更多用户,从而获得更多数据,形成一个正向飞轮。 同时,公司的核心战略必须建立在一个信念之上:顺应发展曲线。你必须坚信 AI 模型将持续变得更强大,并基于这个预判去布局产品,才能在技术浪潮的变革点上,抓住颠覆性的机遇。
4周前
AI 编程越来越厉害了,我要怎么提升自己的系统架构能力? 现在 AI 写代码真的是越来越厉害了,一些小的模块让 AI 写,又快又好。慢慢的,对程序员写代码的能力要求会降低,但是对系统架构能力反而会要求更高。而且这部分能力不会轻易被 AI 取代,因为 AI 还不能像人类一样看到一个复杂项目的全貌,无法完整理解项目的业务上下文和约束条件,所以需要人去把任务拆分,一次只执行一个小任务。 那么问题来了,新人要怎么才能提升系统设计能力呢? 作为一个过来人,我觉得提升系统设计能力这事,可能有没有 AI 都差不多,都离不开多看、多练和多复盘。AI 的好处就是可以更方便地帮你查资料,以及更容易地理解项目,但它不能代替你去动手实践。 什么是系统设计? 在讨论如何提升系统架构能力之前,需要先搞清楚:什么是系统设计? 想想看,如果你做一个简单的网页,或者一个小脚本,需要系统架构吗?基本上是不需要的,因为足够简单,有没有架构都能写出来。那如果是要做一个 ChatGPT 这样的应用呢?那是一定要有很好的系统设计的,因为太复杂了!而且一个人也是做不出来的,需要很多人甚至很多团队协作才能完成。 但即使是 ChatGPT 这么复杂的系统,在开发团队工作的每一个人,工作职责并没有非常复杂。比如有的人只负责实现模型的 API 封装、部署,有的人只负责 Canvas 这样的文本编辑组件,有的人只做 iOS 客户端上的某个功能。一个复杂的系统,通过系统设计,把复杂系统层层分拆,变成了一个个小的模块,最终这些模块组合在一起就可以运行起来,让用户可以稳定地使用 ChatGPT 的服务。 所以系统设计,就是把一个复杂的系统拆解成容易理解、容易实现、容易维护的小模块,再清晰地定义好这些模块之间如何相互协作、相互沟通的过程。 通俗点讲,就好像你盖一栋大楼,系统设计就是设计图纸。图纸上详细说明了楼的结构,比如地基、钢筋框架、墙体、管道和电线,明确告诉施工人员每一部分怎么盖,哪些部分先盖,哪些后盖,哪些部件之间是如何连接起来的。 如何做系统设计? 系统设计这件事看起来很神秘,系统架构师似乎都是传奇般的存在,但做系统设计这事也没你想的那么复杂,因为绝大部分系统设计都有成熟的方案可以参考。作为架构师,可以灵活应用成熟的架构模式,一般是不需要去发明新的架构模式的。 但系统设计也没有那么容易,否则人人都是架构师了。系统设计难在哪呢? • 要充分理解需求和团队:我把理解需求和团队放在了第一位,因为系统设计是为需求服务的,你不理解需求做出来的设计那可能都是错的;同时系统设计要和组织架构匹配,毕竟你的系统设计出来,还是需要团队去实施的。如果你就两三个人整几百个微服务显然是有问题的,反过来你几百个人的团队还是单体应用也可能是有问题的。 • 要面对不确定性:系统设计不像写代码是一个确定性很强的事,代码模块的输入和输出都是固定的,只要去实现算法就好了。但是系统设计面对的是不确定性:需求不确定、未来的发展不确定、技术选型的影响不确定。你需要在这种不确定中做出相对稳健的决策。 • 要权衡取舍:在系统设计中,几乎不可能有绝对完美的方案,通常都是在多个选项之间权衡。例如要兼顾性能和成本、扩展性和开发复杂度、安全性和用户体验等等。这就要求设计者能做出合理的决策,并理解每个选择背后的得失。举个例子,选择微服务架构可能带来更好的扩展性,但也会增加运维复杂度和网络开销。 • 要沟通说服:系统架构不仅仅是给自己看的,更重要的是要让团队的所有成员都理解你的设计,甚至是非技术人员也能大致明白整体结构。这需要架构师具备良好的文档编写和表达能力,用清晰的语言、图表、流程来传递设计意图。不仅如此,在做系统设计时,并不是你做个设计别人就能认同的,你需要去说服别人认同你的设计,有时候也必须做出一些妥协。 当然到了 AI 时代,有些地方还是有些改善的。比如你资源不够就可以用 AI 凑,不善于表达就让 AI 帮你写原型写文档,不知道如何取舍就用 AI 分别实现一套 POC(概念验证),再对比看效果。 新人如何提升系统设计能力? 系统设计并没有快速通道,更多的是长期积累的过程,这个时间通常是以年计的。总结下来关键是三点:"多看"、"多练"和"多复盘"。 "多看":积累架构模式 就是学习经典的架构案例,知道有哪些架构设计的方法。网上有很多系统设计面试题和分析,都是很好的学习素材。另外还可以看开源项目,看看复杂的开源项目是怎么运行的,多关注: • 这些系统是如何拆分功能模块的? • 模块之间又是如何通信的? • 为什么他们选择了某种特定的技术或架构方案? • 在实际中遇到了哪些挑战,又是如何解决的?比如微博是怎么 8 明星并发出轨的? 推荐一些学习资源: • System Design Interview Alex Xu 写的这本系统架构设计面试书,系统地介绍了常见的架构模式 • High Scalability 网站,收录了大量真实系统的架构案例 highscalability[.]com • 开源项目如 Kubernetes、Kafka、Elasticsearch 的架构文档 "多练":从模仿到创新 除了理论学习,更重要的是主动去练习。系统设计这种事,哪怕你像 AI 一样训练了所有公开的系统设计方案,但你不试试仍然不会知道它们在不同的应用场景下的优缺点是什么。就像微服务从来不是个技术问题,而是一个和组织架构相关的问题。 新人的话,最好是从模仿开始,先照葫芦画瓢,然后再去按照自己的思路去改进。 一些你可以练习的方式: 1. 架构还原练习:选择一个你熟悉的系统或产品,试着去拆分架构,画出架构图;写下每个模块的功能定义,明确模块之间如何通信;再去找懂这个系统的人请教对比。 2. 对比学习:去看看类似功能的开源系统,看设计方案有什么不同,各自的优缺点是什么。比如对比 Redis 和 Memcached 的架构差异。 3. 设计先行:在做一个相对复杂的功能时,先去做一下设计再开始写代码。哪怕是个人项目,也要画架构图、写设计文档。 4. AI 辅助验证:尽可能把要实现的模块,用自然语言描述清楚,让 AI(推荐 Claude、Gemini、DeepSeek 等模型)去实现,看结果和你期望的差距在哪里。如果不是你想要的,去反复调整你的描述或者继续分拆,直到 AI 能实现你想要的效果。这个过程其实是在训练你的模块化思维。 5. 重构现有系统:去重构现有系统,在稳定性、代码重用、性能这些方面去改进。重构的过程会让你深刻理解原有设计的问题。 6. Side Project 实战:去做 side project,先尝试基于开源项目二次开发,再尝试从头搭建一套相对复杂一点的系统。比如做一个简化版的分布式消息队列、一个迷你版的容器编排系统。 只有在真实项目中踩坑、解决问题,你才真正能理解系统设计中各种取舍的意义。 "多复盘":从经验中提炼智慧 每次做完项目或者完成一段设计后,都要回顾总结一下过程: • 当初做决策的依据是什么?这些决策后来验证效果如何? • 如果再做一次,哪些地方会做不同的选择? • 遇到的困难和挑战是什么?分别是如何克服的? • 是不是有更好的技术或架构选择当时被忽略了? • 团队成员的反馈如何?他们是否理解并接受了你的设计?如果不接受,原因是什么? 复盘是让你从具体实践中提炼出通用方法论的重要环节。只有反复总结和不断优化,你的系统设计能力才能逐渐提高。 AI 时代更要用好 AI 帮你提升系统设计水平 在学习系统设计的过程中,AI 虽然无法替代你完整地设计架构,但可以成为你提升能力的重要工具,助你快速成长: • 快速查资料与案例:让 AI 帮你迅速搜集和整理系统设计的案例与最佳实践,大大节省学习成本。比如你可以问 AI:"给我解释一下 Circuit Breaker 模式在微服务中的应用场景"。 • 辅助实践:你可以把自己设计的模块先让 AI 尝试实现,以检验你的设计思路是否清晰合理,从反馈中不断优化设计。这就像有了一个永远在线的结对编程伙伴。 • 辅助沟通:你可以先把复杂的设计和思路告诉 AI,由 AI 帮助你简化表达,生成易于团队沟通和理解的文档。甚至可以让 AI 帮你生成架构图的描述文本。 • 辅助决策:当你在不同架构方案间犹豫时,让 AI 帮你分析每种方案的优劣势和适用场景,帮助你快速做出选择。AI 可以快速给你列出各种方案的 trade-off。 • 模拟场景:你可以让 AI 模拟不同的故障场景,帮你思考系统的容错设计。比如"如果数据库挂了,我的系统会怎样?" 架构设计能力的提升关键还是在人,而 AI 则能帮助你更高效地学习、更快速地试错和迭代,加速你成为合格系统架构师的步伐。 写在最后 原本只是打算简单写写的,不小心还是扯多了。没办法,系统设计这种事是真的没什么捷径好走,只有坚持学习。当然方法得当还是能加速一点。 在 AI 时代,架构师的价值不是被削弱了,而是被放大了。因为 AI 让实现变得更容易,所以设计的好坏会更加明显地影响最终结果。一个好的架构设计,配合 AI 的实现能力,可以让你的生产力提升十倍甚至百倍。 希望你早日掌握好架构设计,不用担心被 AI 替代,反而可以利用系统设计能力让 AI 更好地为你效力。毕竟,AI 再厉害,也需要有人告诉它要造什么样的房子,不是吗?
1个月前
图1 是我这两天用 ClaudeCode (Claude 4)Vibe Coding 的成果,一个复杂的视频编辑器,有基本功能,能加入元素,能播放。但我不是在这里吹 Claude 4 编程多厉害的,恰恰相反,我无法基于这个项目继续开发维护,不是代码不厉害,而是一个仅仅靠 AI 开发的负责系统,几乎是不可维护的! 首先说一下我是怎么开发这个项目的: 1. 找到个视频编辑器网站,Vue 开发的,下载它编译好的js脚本 2. 使用 ClaudeCode,让它把脚本反编译成 VUE + TypeScript 代码,完成的相当好,几乎完整的还原了原始代码(图2) 顺便说一下,编译后的 js 文件有 6 万多行,但是它能通过关键字查找,找出来相关的内容,并反编译 3. 继续使用 ClaudeCode,让它把 VUE 代码用 React 代码重写(因为我不会 VUE),使用 jotai 作为状态管理,它完成的相当相当好,帮我把 VUE 代码用 React 重写了,包括重新使用了新的状态管理框架(图3) 但是刚开始的结果,它无法直接运行,需要凭借我的专业知识解决一些问题,这些问题完全靠 AI 是无法解决的,因为你甚至很难描述清楚是什么问题,当你能描述清楚问题,其实你就可以自己解决了。 花了几个小时让它可以运行了,但是问题来了,测下来 Bug 一大堆,这些 Bug 都是牵一发而动全身,人很难修改。 让 AI 修改 Bug 的问题在于: 1. 你无法准确描述这些 Bug,如果你都无法描述 bug,AI 没法帮到你 2. 很多 bug 是相互关联的,AI 可以修复单个 Bug,但是可能修了一个又会冒出更多的 Bug,准确来说 AI 没有全局概念(受上下文窗口长度限制),它一次只能读取一部分代码。 那么人类是怎么解决这个问题的呢? 复杂系统通常是从简单系统演化而来的,大部分系统一开始并不复杂,并且是一点点迭代而来,这个过程中,工程师能了解这个系统的各个细节,有问题能及时处理。 人类有架构师的角色,复杂的系统会有先有系统的设计,把复杂系统拆分成小的系统,小系统再拆分成小的模块,最终构成一个复杂系统。 一个稳定的复杂系统中的小问题是好维护的,但是一个复杂系统中一堆小问题,那么几乎是不可维护的,现实的复杂系统,通常都是反复迭代慢慢稳定下来的,要么是一个稳定的小系统逐步演化成大系统,要么是一个大系统有很多小系统,这些小系统都是稳定的。 那么 AI 能复制这条路或者找到新的解决方案吗? 首先想要复制这条路,目前制约的不是编程能力,我觉得 Claude 4 单纯编程能力已经是高级程序员的水平了,超过绝大部分程序员,制约的是工程能力。 什么是工程能力呢? 工程能力就是对整个项目的掌控能力,不仅仅是编程能力,涉及方方面面: - 需求的理解 - 架构的设计 - 编码 - 测试 - 运维 举例来说,要做一个视频编辑器,你得先想清楚要做成什么样子,有什么功能,然后你得把它变成 UI/UX 设计,变成架构设计,架构设计要做好技术选型、要拆分成模块,还得设计好模块之间是怎么通信的,最后要把模块整合在一起变成一个完成的系统。 这里面模块级别的,AI 是足够胜任的,但是系统层面,模块一多 AI 就不行了,因为 AI 上下文窗口长度制约了 AI 从全局上理解、更新维护整个项目。虽然限制上下文窗口长度越来越大,但是大了后幻觉就厉害,短期内如果没有大的突破还是挺难解决好的。 另外就是 AI 对环境的感知能力还是不够强,比如这个 AI 做好的视频编辑器,它无法自己测试(其实 ClaudeCode 真的有测试,不过是基于网页抓取分析),对测试结果无法甄别,最多能根据错误日志去做一些修改,像 UI 上各种错误,根本感知不到问题。 所以现阶段来说,模块级别(千行以内)的编程开发, AI 已经非常强了,但是涉及到系统层面,AI 还帮不上太多。 对于普通程序员来说,不要再浪费时间去刷 leetcode 搞算法了,多提升系统设计能力和使用 AI 能力会更有前途。 不要被各种“炸裂”误导,比如有人说通过 Vibe Coding 做了一个复杂的视频编辑器,他们不会说的是这个视频编辑器只能用来 Demo 而且几乎无法维护。 现在 AI 编程,提升编程效率已经毋庸置疑了,如何提升工程能力还有很多挑战。
2个月前
小红书独立开发者大赛今天颁奖,其中有几款获奖App还是我当评委时选出来的,很有感触。 之前和orange聊AI编程时,就说过AI这波对于生产力的解放,有机会顾及到以前那些因为规模不足而被放弃的长尾需求。 说人话就是,终于可以做一些取悦少数人、甚至是取悦自己的产品出来了,去他妈的DAU。 这次在小红书上获客无数的那些App,共同点是都很小而有趣,比如测算每天要晒多久太阳的SunAlly,只为航班上断网场景服务的专注飞机,分享宠物友好路线的考骨地图,等等。 有种回到了十多年前、iPhone出现「iBeer」时刻的错觉。 2007年上市的第一代iPhone其实不怎么好用,因为没有应用商店,除了屈指可数的几个官方App以外,用户并不能拿它做太多事情。 是App Store的上线,才让iPhone真的实现了「可以揣进兜里的一台小型电脑」这个愿景,而「iBeer」又是让App Store大获成功的神级助推。 现在来看,「iBeer」这个App简直可以说毫无用处,它唯一的功能就是是把屏幕变成一杯啤酒🍺的横截面,然后倾斜手机就能模拟喝酒的动效。 但那是2008年,没人知道能用iPhone做些什么,App Store里也只有几百个陌生的App——软件大厂都还在观望——「iBeer」的出现,让大家意识到原来能够这么使用陀螺仪和触控系统,而且用户都玩嗨了,直接让「iBeer」成了当年下载次数最多的App之一。 所以后来苹果开发平台的负责人才说,「iBeer」不是计划内的产物,却为App Store奠定了更为广泛的认知基础,人们头一次发现原来还能有这样离谱的应用可以下载,而App Store也就成了一个天天都能发现新产品的入口。 怎么讲呢,现在的小红书,就给我一种十多年前App Store的氛围感,这不夸张,我那会儿Google Reader里订阅了好几个限免网站,每天不下几个新App就浑身难受。 这一年来肉眼可见的,活跃在小红书的独立开发者越来越多了,而且普遍很真诚,真诚到会把小红书当成开发日志来用,不是甩个文案就走的那种,而是会和用户在评论区讨论下个版本要怎么做改进。 这固然有幸存者效应的影响——不真诚的也拿不到足够的正反馈,更留不下来让我看到——但所谓真诚是必杀技的实际台词是,你要当个人,才能获得人。 App Store里上架的应用,已经有几百万之巨了,Android那边更是只多不少,以前的分发模式,无论是编辑精选还是搜索找寻,都失去了绝大多数价值,用户也难得会再频繁下载新的App,再多的「iBeer」,都卡在了被看到这个最致命的环节上。 于是买量几乎成了所剩无几的解法,但这种ROI至上主义天然就和孤身作战的独立开发者无缘,你要么买不过专业的投放团队,要么只能买来流量,买不到活人。 而这也是小红书顺水推舟办了这么一场独立开发者大赛的原因——作为跟了全程的场外参与者,我应该有资格这么来做总结——「能找到App」和「App被发现」的双向奔赴每天都在社区里上演,才让小红书成了这个时代的国民级应用商店。 啊,不应该再叫商店了,应该叫应用集市。 说到底,这倒不是因为小红书对App相关内容有多优待——扶持当然是有的,但小红书的运营在各条赛道都有扶持动作——而是开发App这件事情,和OOTD一样,都属于生活片段的分享,可被小红书无限容纳。 应用集市、传搭集市、游记集市、八卦集市⋯⋯有人的地方,就会自然产生集市,这是无需指导的社交本能。 前面说了,AI放大了Build的能力,但在一个程序员过剩的互联网大国,Build的供给并不是卡点——或者说唯一的卡点——更稀缺的,是Sell的能力。 都说小红书能让产品出圈,这个所谓的圈到底是什么? 其实就是开发者们的能力圈,在技术社区里聊实现方案可以聊出几十页来,但挤进人流去感知用户到底想要什么,却在某种意义上违背了训练记忆,以致于「记账日记Todo」成了独立开发三件套,只有做自己也要用的产品才能确定需求。 一些开发者跟我说用多了小红书的体验,获客反而在其次,更重要的是说多了没压力,这里的沟通和他们在以前推广时强迫自己沟通是不一样的,不需要在文案措辞上抓破脑袋唯恐表达不周,就像写开发文档一样,把做的事情摊开讲完就好,用户自己会在评论区提出新的话题。 当在能力圈之外也能自处,原本的圈当然就成了画地为牢的虚无之物了。 我也看到一个独立开发者的新两件套概念,很是合理::Cursor+小红书,一个解决Build的问题,一个解决Sell的问题,合作起来天衣无缝。 过去十几年来,独立开发这个行当的韧性还挺足的,在中文互联网几无生存空间后,出海赚美金的开发者倒是越来越活跃了,但是现在小红书能够重新指明一条路,那就是在国内市场开发应用依然是有价值的,这个价值未必和出海场景一样直接变现,但它把人设和产品绑定的一体化表达模式,可以涌现出更多的非标准化玩法。 小猫补光灯的开发者花叔就是很好的例子,我一直认为,他这个人的活跃,是比App更好的一款产品。 产品会过气、会下架、会出Bug,但人不会,人的想象空间,比任何产品都大,要理解集市和商店的差别,小红书没有货架,亦不存在价签,自我介绍和打招呼的勇气,才是最关键的,而这是每个人都具备的能力。 人成事则成,希望明年继续参加小红书的独立开发者大赛。