AI原生开发的真相：为何「一次性软件」只说对了一半

在当下搜索"AI-native development"，首页的每一个定义都出自平台厂商之手。IBM、DevOps.com、七八家咨询公司，它们描述的都是同一个范式："智能 Agent 作为主要实现者"，"平台强制执行护栏"。读起来像是未来按时抵达，干净而必然。

然后你打开 Reddit 帖子——那些真正活在这种范式里的人——画风就变了。在一篇标题为"Is demand for new software decreasing?"的帖子下，最热的评论只有三个词，说了两遍：software is now disposable。底下的回复是："我太讨厌这种感觉了。"

同一个范式。两种截然不同的情绪。厂商把 AI-native 当解放来卖。真正在做这件事的人感受到的更接近悲伤。两边说的都是真实的，而他们之间的差距，恰好是理解软件走向的最有用的切入点。

这篇文章要验证的假设是这样的：AI-native 开发是真实存在的、值得采用的；"一次性软件"在更窄的范围内才是真的，悲伤背后掩盖的真相远比这复杂；而区分一次性与持久性的关键，不是 Agent，而是——在产生代码的对话结束之后，plan 和 acceptance criteria 能否存活下来。

诚实地定义 AI-native 开发

剥掉厂商的光环，AI-native 开发只意味一件事：你构建时假设 Agent 会写大部分代码，然后围绕这个假设来组织工作，而不是与之对抗。

这是一个真实的转变，不是营销话术。在旧模式里，AI 是你肩上的顾问。你写代码，遇到卡点就问 ChatGPT。AI-native 把默认值倒转了过来。Agent 写出几乎所有东西的第一版，而你的工作上升了一个层级——决定要构建什么，把需求描述得足够精确让 Agent 能执行，然后验证返回来的东西确实能解决问题。

Patrick Debois——在命名这场转变上做得比任何人都多——把它归纳为四种模式：

从生产者转变为管理者，通过 spec-driven 开发聚焦意图而非实现，从交付转向发现，以及管理 Agentic 知识。

把这份清单读两遍，注意它上面没有的东西。四种模式里没有一个是"写出更好的代码"。四种全都是关于代码周围的工作：意图、管理、发现、记忆。这个框架重新排序了整个工作。你曾经被付费做的事情——产出代码——现在是第零种模式，Agent 处理的部分，而每一种命名模式都位于它之上。

这就是 AI-native 开发诚实的核心。写代码变得廉价了。代码周围的一切才是真正的工作。如果你感觉到自己的角色悄悄从打字变成了描述和检查，那你已经以这种方式工作了，不管你有没有一个词来形容它。

旧方式与 AI-native 方式，对比着看

差异在一单个功能上最容易看清楚。

旧方式：你拿到一张工单，写着"添加密码重置"。你了解自己的代码库，所以打开 auth 模块，写 endpoint，接入 email，处理 token 过期，边写边测。"完成"意味着什么全程存在你脑子里，因为所有碎片都在你手里。

AI-native 方式：你告诉一个 Agent"添加密码重置"，它四分钟就产出了一个看起来能用的流程。以前存在于你脑中的知识，现在必须存在于 Agent 能看到的地方，否则根本不会被应用。Token 用过一次后过期了吗？request endpoint 做限流了吗？重置时让旧 session 失效了吗？除非有人写下来，否则 Agent 会开心地跳过所有这些，因为"添加密码重置"不是一个规格说明，只是一个愿望。

这就是全部的游戏规则。在旧模式里，spec 可以保持隐式，因为写代码的人就是掌握需求的人。在 AI-native 模式里，写的人和知道的人是两个不同的实体，任何你不明确说出来的东西，都是 Agent 可以自由出错的东西。这就是 vibe coding 和 agentic coding 的实际区别：前者接受 Agent 产出的任何东西，后者先写下来"正确地生产出来"意味着什么。

"一次性软件"真正成立的场景

现在认真审视一下一次性软件这个说法。

说"软件现在是一次性的"的那些构建者没有错。确实有一大块而且在持续增长的软件类别现在真的是可丢弃的，装作不是这样是不诚实的。每个季度重新格式化一次 CSV 的内部脚本。只跑两周的发布 landing page。你在一次会议上为回答一个问题而构建的原型，截图，然后就再也打不开了。爬取一份报告的一次性工具，这样你就不用手动去看了。

对于所有这些，一次性不是损失，而是意义所在。以前构建这些东西要花一个开发者一个下午的时间，这意味着它们大多数根本不会被构建。现在它们只需要十分钟，所以会被构建、使用、然后丢弃，世界因此变好了一点点。如果软件的寿命以天计，影响范围恰好只有一个人，那 spec-driven 的严谨就是你应该跳过的 overhead。Vibe 过去然后继续。

那些帖子里的悲伤是真实的，但它很大程度上被错误归因了。"所有软件现在都是一次性的"这种感觉，通常其实是"一次性这个类别变大了很多、可见度也高了很多"。这是另一个不同的、没那么令人担忧的说法。

超越边界的那一刻——变成 bug，而非 feature

界限被跨越的时刻是——有其他人依赖这个东西的时候。

只有你会运行的 demo 可以是一次性的。它变成的面向客户的 app 不行。格式化你自己 CSV 的脚本可以是一次性的。格式化每个客户发票的账单任务不行。证明一个想法的原型可以是一次性的。你收钱的产品、保存着别人数据的产品、六个月后你还得继续编辑的产品不行。不是因为严谨是美德，而是因为"一次性的"和"承重的"是对立面，你不能同时是两者。

这是 AI-native 开发设置的陷阱，值得直说，因为几乎没人警告过你。一次性版本和持久版本诞生时看起来一模一样。Agent 产出的都是同样干净、自信、看起来能用的输出。这就是完整性的幻觉：看起来完成了和真正完成了是两个不同的属性，Agent 只保证第一个。只跑一次的 demo 和要跑多年的 app，从同一个 prompt 出来时看起来同样完成了。你无法通过外观区分它们，这意味着你的可丢弃物悄悄变成承重的那一刻——它会的，因为有用的那些总是会——你就继承了一个从未被规格说明过、从未被验证过、从未被设计成要存活下来的代码库。

一次性软件没事，直到它不再是一次性的那一天。而那一天永远不会自己宣布。

什么让软件不可丢弃

那么是什么把一次性的构建转化为持久的一个？不是更多的代码。代码现在是便宜的部分，加更多只会给你更多不信任的理由。

让软件不可丢弃的是代码之上的那一层：一个 plan，说明这个东西应该做什么；以及一套 acceptance criteria，Agent 可以真正通过它们来验证，你怎么知道它做到了。这两个 artifact 是让你下个月能无畏地修改软件的东西，因为它们告诉下一个 Agent 和下一个你，什么必须保持为真。没有它们的代码是一个你不敢碰的黑盒。有了它们的代码是一个你能持续演进的系统。这就是"你丢弃的东西"和"你构建其上的东西"之间的全部差别。

这正是 BrainGrid 要弥合的差距，也是践行 agentic 工程而非只是更快地 prompt 的全部意义所在。你描述你想要什么，Planning Agent 把它转化为真正的需求，包含 acceptance criteria、你没想到要问的问题、以及一个能存活过对话的 spec。然后 Builder Agent 写代码，在我们的云上或者在你的自有仓库里，用 Claude Code、Cursor 或 Codex。没有任何东西算完成，直到它对照那些 criteria 被验证过，有证据表明它做了你意图做的事。Agent 在会话结束的瞬间忘记一切。Plan 和 criteria 不会。这种持久性让产出变成你可以依赖的东西，而不是你以后不敢打开的东西。

它以循环的方式运行：Plan 然后 Build 然后 Verify 然后 Repeat，循环的意义在于：持久版本几乎不花你任何额外的前期成本。你通过描述想法免费获得 plan，然后你可以保留它。AI-native 开发的税从来不是写代码。它是继承没人写下来意图的代码。循环在开始时一次性付了税，而不是在你每次因为害怕改动而回头时支付。

如果你现在正在构建，这意味着什么

如果你现在正用 Agent 发版，务实的做法不是"规格说明一切"也不是"规格说明 nothing"。而是在开始之前知道你当前的构建落在线的哪一边。

问一个问题：现在或以后，会有除我以外的人依赖这个吗？如果诚实的答案是否定的、并且将一直是，那就 vibe 过去，享受速度。那是 AI-native 开发正如宣传那样工作的方式，一次性是一份礼物。如果答案是肯定的，或者一个可丢弃物有真正的可能性变成人们依赖的东西，那你花在写下"完成"意味着什么上的十分钟，是你将买到的最便宜的保险。你不是在增加流程。你是在拒绝继承一个承重的黑盒。

关于这个假设的判决

AI-native 开发是真实的，一次性软件是真实的，而悲伤主要来自于不知道界限在哪里。界限是依赖。在它之下，一次性是 feature。在它之上，plan 和 criteria 把 Agent 自信的产出变成你真正可以信任的东西。Agent 免费给了你代码。意图才是你需要保留的部分。

什么是 AI-native 开发？

AI-native 开发是一种构建软件的方式，假设 AI Agent 会写大部分代码，然后围绕这个假设组织你的工作。不是 AI 在你写代码时偶尔担任助手，而是 Agent 产出几乎所有东西的第一版，而你的工作上升一个层级：决定构建什么、精确地规格说明它、验证结果确实做了你意图做的事。四种反复出现的模式是：从生产者转变为管理者，通过 spec-driven 开发聚焦意图而非实现，从交付转向发现，以及管理知识使上下文跨越会话存活。

AI-native 开发的四种模式是什么？

Patrick Debois 命名的四种模式是：（1）从生产者转变为管理者，你操作和审查 Agent 输出而不是自己写每一行；（2）通过 spec-driven 开发聚焦意图而非实现，活着的规格说明比细粒度代码更重要；（3）从交付转向发现，工作从交付已知功能转向探索应该存在什么；（4）管理 Agentic 知识，来自代码、工单和事件的反馈持续更新你的 Agent 工作时的上下文。四种都是关于代码周围的工作，不是代码本身。

AI-native 和 AI-first 有什么区别？

AI-first 通常意味着 AI 是你工作中的优先项或默认工具，螺栓接到现有流程上。AI-native 意味着流程本身从底层设计时就假设 AI 做核心工作，就像"cloud-native"意味着为云设计而不是把旧应用迁移上去一样。在实践中，一个 AI-first 团队给现有工作流加一个 Agent；一个 AI-native 团队围绕 Agent 重建工作流，这就是为什么意图、规格说明和验证成为承重的技能而非打字速度。

AI-native 开发等同于 vibe coding 吗？

不，虽然有重叠。Vibe coding 意味着 prompt 一个 Agent 并接受它返回的东西，没有书面 spec 或验证，这对于一次性工作是合理的模式。AI-native 开发是围绕 Agent 构建的更广泛实践，对于需要持久的东西，它增加了 vibe coding 跳过的纪律：一个 plan、acceptance criteria 以及对照它们的验证。当软件是一次性的，vibe coding 是可以的；当它变成人们依赖的东西的那一刻，vibe coding 就是危险的。

AI-native 开发是否意味着软件现在是可丢弃的？

只对其中特定的一小部分。个人短期使用的软件、一次性脚本、短命的 landing page、可丢弃的原型，现在真的是可丢弃的了，而且这个类别增长了很多。但当其他人开始依赖这个软件，或者一个可丢弃物悄悄变成承重的那一刻，一次性就从 feature 变成了负债。分界线是依赖，而保持被依赖的软件不可丢弃的，是超越代码存活的 plan 和 acceptance criteria。

BrainGrid 是 plan-first 的应用构建平台：它在构建之前做 plan，然后对照 acceptance criteria 验证每一个变更，所以你依赖的软件永远不必是一次性的。在 braingrid.ai 试用。

最初发表于 BrainGrid 博客。