AI下的软件开发思考：以推理速度交付产品？

早上看了一篇Andrej Karpathy转发的文章，作者是Peter Steinberger，文章是他2025年的个人编程总结：

虽然我偶尔会看到Karpathy这个名字，但我对这两个人都不了解，这种事情就问问“豆包”，原来这个Andrej Karpathy是 AI 领域非常知名的学者、工程师和创业者，OpenAI 创始成员（2015-2017、2023-2024）、特斯拉前 AI 高级总监（主导 Autopilot 自动驾驶视觉系统）、斯坦福大学博士（师从李飞飞）；Peter Steinberger是前 PSPDFKit（知名 PDF 开发工具公司）创始人，现全职开源开发者、AI 工具构建者，活跃于维也纳和伦敦，有 13 年以上的 iOS 原生开发经验，曾创办 PSPDFKit（主流的 iOS/Android PDF 渲染框架），现在专注于用 AI 开发工具，以 “高效（甚至‘疯狂’）的开发节奏” 著称。

作者的背景信息就从AI哪里了解这些，对错不知道，其实我也不太关注，只是为了文章的完整性、友好性，也是自己的好奇了解下而已，我还是关注文章里边跟自己的感受接近的地方。

文章的中文名称是《以推理速度交付产品》，据“豆包”说这是个程序员的梗：““推理速度” 原本是 AI 领域的术语（指大模型 “跑起来输出结果” 的速度），这里被拿来调侃 —— 现在很多开发者用 AI 写代码，快到 “自己都没看明白代码逻辑，就直接把 AI 生成的内容发布上线”，就像 AI 模型 “快速推理出结果” 一样。”

梗有的时候就是个梗，但有的时候也是对现实的无奈，比如，AI的写码速度也就只能是AI来审查效率才真跟得上。

一、时间节点上的同感

“五月份的时候，我还很惊讶一些提示就能生成可以直接运行的代码， 而现在这已经成了我的标配。”

我自己的感觉也差不多，3、4月份写东西还痛苦的要死，我熬夜主要是因为AI记性差、胆子大，但是5、6月份，这个问题就“飘”过去了，不能说彻底解决，但跟3、4月份比，进步是质变级别的，这归功于基础模型和编程工具的同时进步，让工作的感觉完全变了。

“我现在能开发的软件数量主要受限于推理时间和深入思考。说实话，大多数软件并不需要深入思考”。

这是不是个事实？作为企业架构领域的从业者，深入思考一直是我们非常主张的，但实际工作中，这个事情确实是分层级，大型系统升级是需要深入思考，但经常会考虑不到位、不够深入；而一般需求并不需要非常深入的思考，但在企业级的开发环境中，需要的是定位，通过准确的定位来维持功能秩序和数据质量。

那么在AI辅助的开发环境下呢？我自己最初的经历是需要深入，但这个深入指的是跟AI讨论一整套方案和计划，才能去开发一个系统，我之前在文章中好像也讲过，我从来不关心AI是否能完整写出一个功能，作为一个企业架构师，AI对我的“威胁”在于是否具备系统级以上的驾驭能力，所以，他必须先能够完整写出一个系统，这在3、4月份的是否，是需要建立一整套架构文档、工作计划，还得耳提面命也不一定能走完的，但是，5、6月份，这个过程就可以了，系统级的开发还是需要文档支持的。

那么现在呢？我依然会和AI深度思考，但是这跟之前的一整套架构文档的讨论不太一样了，因为实验系统已经建立起来了，尽管之后有大的功能升级，比如增加架构管理模块、引入本体论方式做架构工具、工具大规模重构等，都是“长”在这个实验系统之上的，AI通过完整阅读代码，总是能够很准确地理解这个系统的架构（如今代码行数接近10万了），所谓深入思考已经是共创型或者说偏重于AI的深度思考了，我的思考其实更多是方向性的了。以至于我现在更多地还是在想，到底将来怎么跟他合作，这也是我一直在实践AI却一直也没有在这方面尝试写书的原因，我确实不知道怎么把“聊天”写成书，而且我专注的是自然语言编程这个方向，这里变化太快了，连经验都可能是“月抛”的，除了持续实践别无他法。

“各位开发 Mac 或 iOS 应用的朋友们：你们现在基本不需要 Xcode 了。 我甚至都不用 xcodeproj 文件 。Swift 的构建基础架构现在足以应对大多数情况。Codex 知道如何运行 iOS 应用，也知道如何处理模拟器。不需要任何特殊的东西或 MCP。”

这段话的大部分我都不太懂，但是最后一句话挺有感觉的，我自从试验了MCP的方法后，就几乎没再写过MCP了，毕竟我这个本地应用系统确实也不知道需要什么MCP，我不是否定MCP，只是目前还用不上。为了测试的稳定性，我也写了测试的智能体，后来写了Skill，Spec似乎在企业级开发中有用，但是，在我自己这种开放、探索的开发模式上，也没觉得特殊需要。尤其是在靠近年底，模型更进步了之后，确实很多经验用着用着就成为“心感”了，没必要严格规范化，因为过一段时间可能就不需要了。

“另一个重大优势是知识库更新截止日期 。GPT 5.2 的更新截止日期是 8 月底，而 Opus 的更新截止日期是 3 月中旬——这相差大约 5 个月。对于想要使用最新工具的用户来说，这意义重大。”

这一条就不必多解读了，对于希望通过编程工具和模型去探索最新应用方向、应用实践的人来说，这几乎是决定性的。

二、模型上的同感

“真正让我掌握像工厂一样构建代码的秘诀是 GPT 5。发布几周后我才看到它——Codex 也花了些时间才跟上 Claude Code 的步伐，我又花了一些时间学习和理解它们之间的差异，但之后我越来越信任这个模型。现在我很少看代码了。我会看直播，偶尔看看关键部分，但说实话，大部分代码我都不看。我知道各个组件的位置、结构以及整个系统的设计，通常这就足够了。”

在Cursor进行区域限制之前，它是个很好的模型体验器，新模型都会很快上线，我最早感觉到的明显飞跃的是Claude 4.5，之前文章中写过，那是从无法建立一个完整系统，到很快建立一个实验型系统的“飞跃”。其实 GPT 5一开始给我的感觉不是很明显，毕竟，先入为主的观念是Claude系列更适合写代码，直到被禁用了尤其是Cursor出现扩展宿主崩溃问题之后，我才开始真正去体会模型之间以及工具之间的差异。

自从Claude 4.5这类高级模型被禁用后，Cursor工作效率、对复杂问题的处理能力下降都是很明显的，而出现扩展宿主崩溃问题之后，更是不得不将使用时间在各个工具间分配开，这也让我体会到了一些不同之处。比如，由于Cursor很擅长工作流控制，使我觉得Claude系列是很“温顺”的模型，但换到其他工具上才知道这家伙干活有多“狂暴”；GPT 5最初给我感觉很“磨叽”，因为他确实会读很多文件，但是现在体会到了确实是优点，之前也跟国内的工具厂商反映过，是不是能综合下。目前看Codebuddy与GPT 5.2的配合还是挺好的，但是费用相对高些；Qoder自己玩的也很好，就能力上看，强于Cursor混合模型的表现；Cursor目前的模型选择余地实在是太小了，但优势在于成本是真低。

所以，现在我的使用一般是让Codebuddy出复杂方案，利用GPT5.2的完整阅读能力和更强大的模型基础能力，然后让Qoder将其拆分为细化执行任务，拿不准的会让Codebuddy再次验收，之后交给Cursor去编写、测试，Qoder可以再去验收Cursor的工作成果，如果需要再加强，就用Codebuddy去深度检验，因为对于找深度错误来讲，GPT 5.2的能力还是很强的。通过这样来平衡成本与质量，也多体会不同模型、工具的变化。

至于说看代码，这方面我比那位作者进步要快得多，因为我从来就不看代码。

三、过程上的同感

“我的软件开发方法是迭代式的。我先构建一些东西，试用一下，感受一下它的“感觉”，然后再根据新想法进行改进。我很少能完全确定自己想要什么。”

我知道自己要什么，但也不确定他到底长什么样子，这一点在个人开发工作上还是挺常见的。在企业端之所以要力求让软件先被“看见”，是因为这里有更长、更复杂的决策过程，有更模糊的责任管理，有更长周期的成本控制等诸多问题，但是在个人开发环境下，决策链太短、没有责任问题、成本就是时间为主，所以，这两者是完全不同的。

“开发软件就像登山。你不会径直向上，而是绕着山走，走走停停，有时会偏离路线，需要往回走一段，过程并不完美，但最终你会到达目的地。”

这是必然的，个人开发、企业开发都一样，我还曾经将一个主文件备份为“黎明前的黑暗”，但事实证明，这不过是寻常的又一夜而已。

“我觉得在项目中考虑不同的状态会增加认知负担，没必要，我更喜欢线性地演进。”

个人开发确实没必要啊，我之前还分试着分过开发、部署、测试环境，后来发现，这有啥必要呢，都是热加载的。开发了就提交，git仓库像是个保险，处理不得已的回滚，直到回滚也不需要了，就是在单纯的保险。因为我最需要的一次，模型竟然回答说没有前端代码可供回滚，事实证明，有的，只是提交时的名字未必叫了这样的名字，导致他没找到而已。

“Codex 在上下文管理方面远胜于 Claude Code，我感觉在 Codex 会话中完成的工作量是 Claude Code 的五倍。这不仅仅是因为 Codex 的上下文规模更大，还有其他因素在起作用。我猜测 Codex 内部的思考方式非常精炼以节省标记，而 Opus 则非常冗长。”

我没用过Claude Code，不好做这个比较，但是我真的很不喜欢开新的对话框，就算在过去对话管理不如现在的情况下，我也经常会撑到六、七万行的对话，现在我根本就不切换，反正工具都能压缩了，没有啥效率问题。

我之前画过一个AI模式下的架构图，我认为对话是模型“后天学习”中的重要内容，只不过还没能真正进入学习过程，更像是规则提炼、语境稳固，还没有真正成为学习，据说GPT6号称有“自学习”能力了，希望能够通过对话进行更多学习，这个在企业级开发环境下意义更大，基于庞大的需求过程、开发过程对话，AI熟悉企业级开发的速度有可能会非常惊人。

“很多时候，我会写“ 将文档写入 docs/*.md ”，然后让模型自动选择文件名。你越清楚地设计模型训练所需的结构，你的工作就越轻松。毕竟，我设计代码库的目的不是为了方便自己浏览，而是为了让智能体能够高效地工作。与模型对抗往往是浪费时间和token。”

这一点好像一开始就是这样的，只不过最初模型阅读长文档会有大量噪声，会在实施过程中偏离文档和计划，因为模型很容易自嗨，工作个10轮、8轮的就“自主研发”了，现在好多了，模型和工具在这方面都已经改善了很多。

四、未来的思考

写文章当然不是为了聊个读后感，我写文章基本上都是面向自己的思维整理，人的记忆就像我上一篇文章讲的，连贯但不准确，需要时时写个文档加固下，AI在2025年带给我的冲击和改变是巨大的，未来会带来的改变只能是更大的，所以，我觉得有以下方向至少我自己是必须要注意的：

（一）保持接触最新的模型

这点要靠工具厂商们努力了，保持让我有机会接触到最新模型，模型的变化是非常快的，必须保持接触最前沿的变化，才能真正感受AI的能力，变化的征兆会提前出现，但仍会保持一个让人感觉“不太可能”的状态，只有你以足够的开放度和想象力去感受时，才有可能发现一丝痕迹，以免被打得过于措手不及。有些事情需要很包容地去看，比如2025年初和年底的Manus。

（二）软件的工程模式会彻底改变

这个改变是不是把开发的人都干没了，我们先不那么极端，但过程一定会有变化，比如，前文提到的，个人开发是顺着灵感跑，企业开发要讲秩序，这两个会否统一在一个理念下，也许是“原型开发”的复活吧。

个人开发直接就是“高保真原型”开发，成了就直接上；企业开发则是复杂项目的“低保真原型”和简单项目的“高保真原型”结合，因为复杂项目一开始要在细节上少浪费时间，而是尽快确认整体需求，简单项目则是多确认细节，争取直接上线。有了原型，AI就能更高效地往前跑了，而做原型，AI很高效。那文档怎么办呢？这要看怎么用文档了，如果还需要定责、存档，那就基于原型反向输出文档吧。

为了在企业级环境下支持AI更好地理解企业的开发需求，企业架构、本体论之类的全景视图是会有些帮助的，这个帮助更像是增强了模型“会默默地读取文件 10 到 15 分钟才开始编写代码”这个过程的效率和准确性，有效地检索视图来进行结合当前架构的开发。

但是矛盾之处在于，如何构建这套架构视图才是代价最小又能适合AI的。我是否过于期望AI像个人类架构师了，AI架构师到底是如何工作的，尽管他的技能几乎都是来自于人类。对于企业级开发，也许更有效地是与AI打磨、共创一个基于架构模式的思维链和一个高阶架构视图，然后所有高、低阶视图和实现都交给AI，因为AI企业架构师和AI开发工程师是一体化的，人类是要避免架构和开发的脱节问题，而对于AI，也许我们要做的是一开始就不要导入这个问题。我接触过的很多人都觉得企业架构与AI是不沾边的，直到本体论出现有了些变化，而在我看来，如果能通过企业架构给AI一个思维链和一个高阶视图，极有可能成为最轻巧、最有效的配合方式。

这个说的不是低阶视图不管了，而是通过高阶视图的框架，让AI有边界地处理低阶视图和实现。这个也不会只是增强下AI的对话能力，而是类似规约、Skill一样，让高阶视图发挥约束性作用，并且根据开发的演进能够让AI动态更新这些高阶视图，当然，基于高、低阶视图的关系，也可以发展更为复杂的思维链，虽然我不确定这样做是否一定很好，但理论上也是可以的。

这种工程模式实际上就是对话式的，但是目前还会在一定程度上受制于模型的部署形式、资源压力、模型能力等因素，但这种限制可能也就会是短短几年的时间吧。

（三）积极地重构你的业务系统

别受这句话蛊惑，我指的是条件成熟的时候，尤其是模型能力（未来要还是担心这个就说明不了解AI）、成本（这个可能是未来最不操心的）、风险（这只是心理上最怕的）都觉得可控的前提下，别让AI管一堆“烂代码”，你希望AI是当个垃圾管理员还是做企业能力建筑师呢？

（四）大胆思考“研用”一体的数智企业管理模式

什么是今后数智企业的操作系统，当然是基于企业架构管理能力，全面管理企业数智系统研发、使用的人工智能，以往我们都觉得做系统是做系统，用系统是用系统，这个对AI来讲有区别吗？能做系统不就自然就能使用系统吗？能使用系统不就是在处理业务吗？AI本来就还在当业务助手。

AI是不是有个全能视角：既能分析数据、又能处理业务、还能开发系统，不同的“脚手架”配上具有自学习能力的基础模型，再加上人类的协同，“业技融合”是不是要发展到“研用一体”了？打破“部门壁垒”是不是转化为“知识共建”了？人跨不过去的槛，对AI来讲本来就不是槛，如同上一节讲的，多打破些思维框框，一开始就不要导入这些问题为好。

AI的发展太快了，需要快思考，也需要深入思考，有空儿就思考思考。

AI时代，也许真的是，我思故我在！