从第一原理出发的 AI-first 软件设计：实践者指南
大多数团队采用了 AI，却没有修订它底下的任何一个假设——这正是产出变快而系统变差的原因。
这是大多数工程团队还没说出口的问题：如果模型能写代码，那我们现在究竟该擅长什么？
我听到的答案大多是防御性的。提示词工程。审查 AI 产出。知道该伸手去拿哪个工具。这些都是真实的技能，都在真正转变的下游，而且没有一个能解释我在实践中反复看到的现象——采用了同样工具、在同一个季度、用同样模型的团队，最后落在完全不同的地方。一组交付更快，而软件撑住了。另一组交付更快，然后花接下来一个季度弄清楚自己弄坏了什么。
同样的工具。相反的结果。这个差别不是关于模型的。
那个没人计入的放大器
DORA 的 2025 年《State of AI-assisted Software Development》给这件事标上了数字。90% 的技术从业者现在在工作中使用 AI，超过 80% 相信它提高了自己的生产力。这两条都不意外。真正重要的是第三条发现：更高的 AI 采用率同时与软件交付吞吐量的上升以及软件交付不稳定性的上升相关联。
再读一遍，因为这就是全部论点。这个工具让团队在交付上更快，在维持运转上更差。不是二者之一。是两者。
DORA 的表述是：AI 是一个放大器——它会放大它落到的任何一套做法。强的系统变得更强。弱的系统变得更快地弱。
也就是说，有趣的问题从来不是「我们该如何采用 AI」。而是「AI 在我们身上放大了什么」。而回答这个问题，需要回溯到比任何工具决策都更早的地方。
从问题出发推理，而不是从工具出发
第一原理思考是那种被重复到失去意义的说法之一，所以让我具体说明我指的是什么、不是什么。
类比推理，就是大多数 AI 采用的样子。我们有一套开发流程。一项新能力到来了。我们问这项能力嵌进流程的哪里，把它加在阻力最小的那一点——通常是写代码——然后其余一切照旧。站会、工单、sprint、评审，全部保留。流程被当作给定条件，工具被塞进去适配。
从第一原理推理会问一个更难的问题。把流程剥回到「关于造软件，究竟什么是真实的、物理上成立的」。然后问模型改变了这些真相中的哪些，又完全没有触碰哪些。从存活下来的东西重建。
诚实地做一遍，你会发现 AI 恰好改变了一件事——而且不是这个赛道一直在卖的那一件。
生产代码的成本降到了几乎为零。决定代码该是什么的成本一点没动。
一切有用的东西都从这一个不对称里流出。以下是我希望任何实践者都能凭记忆说出的四条后果。
一：数据模型就是产品
屏幕是任何应用中最易变的部分，也是最诱人的起点，因为它是你能看见的那部分。它同时也是本该最便宜就能扔掉的那部分。
数据模型正相反。它决定你能问什么、能索引什么、之后能改什么而不用做一次让所有人害怕的迁移。每一项下游能力，都被那一层上被做出——或即兴发挥出——的选择所限制。
当代码昂贵时，这个顺序自我强制。没人会对着一个自己没想过的 schema 手写一百块屏幕，因为手写一百块屏幕要花一个季度。生成移除了那道天然关卡。你现在可以对着一个从没有人类审查过的数据模型，产出一整套界面，而它看起来会像完成了。
所以这个顺序必须变成刻意的。先模型，再契约，最后界面。不是因为这样传统，而是因为这是唯一能让昂贵决策在「仍然便宜可改」时被做出的顺序。
二：被推迟的决策仍然会被做出
这是实践者低估的一条。
每一个你没有明确做出的决策，仍然会被做出。它由生成器在生成时做出，基于一个不包含你的业务、你的合规面、你的迁移历史或你下季度计划的上下文。模型不会拒绝决定。它挑一个看起来说得过去的，然后继续往下走。
一个订阅被取消的用户仍然能看到什么？两个人同时编辑同一条记录时会发生什么？邮箱地址是否唯一，以及在什么范围内唯一？没人给这些问题写过提示词，所以没人回答过——而应用现在对这三个都有了答案，是推断出来的，而且只能靠在生产环境里撞上它才能发现。
这就是开发者社群命名的 70% 问题背后的机制。进展停滞不是因为剩下的活儿难，而是因为剩下的活儿被几百代生成之前无声做出的决策挡住了，而那些决策不把整个东西拆开就再也改不动了。
修复这件事的做法现在有了名字：规范驱动开发。先把需求、约束和成功标准写下来。把那份文档当作事实来源。让 agent 对着它构建。GitHub 发布了 Spec Kit，AWS 发布了 Kiro，而这种收敛不是巧合。
三：当生成免费时，约束必须被写下来
几十年来，正确性部分是靠写代码的成本承载的。实现一条规则的开发者必须把那条规则记在心里。人脑里的隐性知识曾是一个可以接受的约束存放位置，因为人一直在循环里。
那个存放位置不再有效。如果一条约束没有被表达在某个机器可读的地方——一个 schema 约束、一个类型、一条校验规则、一个测试、规范里一行明确的文字——那么就生成器而言，它不存在。它只存在于「即将被惊到的那个人」的记忆里。
这是 AI-first 设计的实践内核，而且它毫无光彩。把不变量往下压到能强制执行它们的那一层。not-null 和 unique 放在数据库里而不是表单处理器里。类型放在边界上而不是代码注释里。授权作为系统会求值的策略，而不是某人记得写进某个端点的一个条件。
每一条你外化出去的约束，都是模型再也不可能弄错的一个决策。
四：你现在在为两类消费方构建
最后一条是最新的，也是大多数团队完全没有内化的一条。
你的应用现在有两类用户。一类是看着屏幕的人。另一类是调用 API 的 agent，它永远看不到你的界面，也无法被好设计说服。如果一项能力存在于你的界面里但不在你的 API 里，那么就 agent 经济而言，它并不存在。
这有一个设计后果：对等不是「有了更好」。任何人类能通过界面做的事，都应当通过一个被定义、被文档化、可发现的接触面可达。这也是为什么对 agent 消费来说，GraphQL 一直比 REST 更合适——一份自描述的 schema 是机器可以自行探索的东西，不需要先有人写好集成说明。
为 agent 构建，人类界面会作为副作用变得更简单。只为人类构建，你就会在期限压力下后加 API，而那是设计 API 最糟糕的时机。
跳过这些在数据里长什么样
GitClear 分析了 2023 到 2026 年间的 6.23 亿次代码变更，而可维护性的图景与上面所说的一切一致。
相对 2023 年基线，重复代码块上升 81%。提交内复制粘贴从 2022 年的 9.4% 攀升到 2026 年上半年的 15.7%。掩盖错误的结构上升 47%。同时跨文件函数调用——代码复用最清晰的可得信号——下降 35%，而重构活动从 2022 年占变更的 21% 崩塌到 2026 年至今的 3.8%。
开发者现在复制粘贴的可能性大约是重构的五倍。2022 年这个比例是反过来的。
这些都不是模型质量问题。用复制代替复用、吞掉而不是暴露错误的错误处理、不再发生的重构——这些正是当生成廉价、而结构不是任何人明确职责时你会得到的东西。产出在局部说得过去，在全局不自洽，而这恰恰是一个「从屏幕开局」的工作流无法察觉的失败模式。
如何从这周开始这样工作
这些都不需要一次组织重构。它需要改变四五个习惯的顺序。
- 在第一块屏幕之前先写数据模型。 实体、关系、基数、什么让一行唯一、删除时会级联什么。这里的一小时是整个项目里杠杆最高的一小时，也正是工具在主动邀请你跳过的那一小时。
- 让规范成为你评审的产物，而不是 diff。 如果规范正确、生成也忠于它，那么评审几千行生成的代码是演戏。评审产出它们的那份文档。趁争论还便宜时去争论规范。
- 把你能叫出名字的每一条约束都外化出去。 生成之前，列出绝不能被违反的规则，把每一条放到系统会强制执行它的地方。任何留在对话里的东西，最终都会被某个从未加入过那场对话的东西违反。
- 把 API 设计成产品的接触面。 然后把人类界面当作它的一个消费方。这更多是一个排序选择，而不是工程选择，而把它排到后面正是让它变贵的原因。
- 为不稳定性而不只是吞吐量埋点。 DORA 的发现是速度与脆弱性一起上升，所以只测速度只会给你看到自己趋势中好的那一半。变更失败率和恢复时间才是告诉你放大器是否在为你工作的数字。
这要付出什么
我想对这份取舍直说，而不是装作它不存在。
这样工作在项目的第一周更慢，在之后的每一周实质上更快。这是一份真实的、预先支付的代价，而且恰恰是在动能感觉最有价值、竞争对手正在交付某个可见东西的那一刻支付的。会有一些 sprint，让跳过这一切的团队看起来在赢。
它在纪律上也不免费。写下约束不如看着界面出现来得享受。评审一份规范不如评审代码那么令人满足。这些习惯在期限压力下腐化，而那正是让它们重要的同一份压力。
而其中有些确实不适用。如果你这个周末在验证一个想法并打算把结果扔掉，那就扔掉——对生命周期只有两天的软件，上面这些都不值得做。这里的论点是关于那些能活过自己演示的应用。
那个从来无法被自动化的部分
一些围绕代码生产建立起来的岗位会缩小。有些会消失。装作不会，不会帮任何人做准备，而那些告诉你每一份工程工作都安全的人，并不是在帮你的忙。
但看看这个不对称到底做了什么。它自动化了决策的表达，而完全没有触碰决策本身。造什么。不造什么。哪些不变量成立。系统绝不能做什么。边界在哪里，以及谁被允许跨过它们。
那份工作一直是难的那部分。它只是被打字这件劳动掩埋着，而打字曾经贵到看起来像是工作本身。
打字从来不是工作。
延伸阅读
这套做法的深入版本：规范驱动开发。如果你在挑工具：2026 年最好的 AI 应用构建器。
常见问题
「AI-first 软件设计」是什么意思？ 在这样的假设下设计应用：大部分代码将被生成而不是手写，而且一部分消费方会是 agent 而不是人。实践上这意味着数据模型、约束和 API 契约在前期被明确定义，因为那些正是生成无法替你做出的决策。
AI-first 设计与「只是用 AI 编码工具」有什么不同？ 使用 AI 工具是给一套没变的工作流添加一项能力。AI-first 设计改变工作流的操作顺序——模型和契约先于界面、规范作为被评审的产物、约束被压进可强制执行的层。DORA 的 2025 年研究发现 AI 采用同时抬高了吞吐量和不稳定性，而那正是工具变了、做法没变时会发生的事。
AI 时代软件设计的第一原理是什么？ 四条成立：数据模型是产品而屏幕是它的一个视图；任何你没明确做出的决策都会被生成器隐含做出；约束必须活在机器可强制执行的地方而不是某人的脑子里；而你的应用现在同时服务一个人类界面和一个面向 agent 的 API，两者需要对等。
这样设计会拖慢团队吗？ 它把工作前置，而不是增加工作。数据模型和规范里捕捉的决定，是无论如何都会有人做的决定——要么在开始时刻意做出，要么之后由模型在猜测中隐含做出。第二条路正是返工的来源，而返工并不更快。
规范驱动开发与 AI-first 设计是一回事吗？ 规范驱动开发是那套做法；AI-first 设计是更广的一组架构后果。规范驱动开发覆盖写规范并对之生成。AI-first 设计还覆盖数据建模的顺序、约束在哪里被强制执行，以及在人类消费方之外同时为 agent 消费方设计。
什么时候可以放心跳过这一切？ 原型、演示、内部一次性的东西，以及任何你打算丢弃的东西。这份开销只对那些必须经受真实用户、真实数据和长期变化的软件才值得承担。
