1. 先还原一次真实的“顺序翻车”现场

上个月我用AI工具做一个库存管理后台，从零到一把页面、接口、数据库全串起来，只花了一个晚上。但接下来的两天，我全在拆自己埋的雷。起因很简单：当时我把四个关键指令的顺序跑反了，先让AI写功能，再补数据模型，最后才调接口约定。表面上看，每一段代码单独都能跑，一旦把前后端真正连起来，字段对不上、状态不同步、鉴权放在哪一层全乱套。无奈之下我删掉了一大半已生成的代码，老老实实按“蓝图—契约—实现—验收”的顺序重新跑了一遍，才算把项目救回来。

那次之后，我把这套流程固定成了四个指令：

• 指令一：项目蓝图与边界约束。先让AI产出业务目标、功能列表、页面结构、角色权限和技术栈建议，不写任何实现代码。
• 指令二：数据模型与接口契约。在蓝图基础上定义表结构、字段类型、API端点、请求响应示例和鉴权方式，把前后端的共同语言钉死。
• 指令三：模块化功能实现。基于前两个指令逐模块写代码，每个模块都附带可运行的测试与验证结果。
• 指令四：联调验收与交付配置。跑构建、修错误、补部署配置和运行手册，把项目从“能写”推到“能交付”。

这篇文章就围绕一个核心问题展开：为什么这四个指令必须按这个顺序跑？哪些依赖是硬约束，哪些是省Token的经验之谈，乱序之后会踩到什么坑，以及如果已经乱了，怎么把上下文重新理顺。

1.1 那次的完整事故链

先说那次翻车的具体经过。我当时急着做功能演示，第一道指令直接丢给AI：“给商品模块写增删改查接口，顺便把管理端页面也做了。”AI干得很快，接口、页面、数据库脚本一次性生成。我验收的时候发现，列表页用的字段名叫quantity，数据库表里却叫stock；创建商品的接口返回sku_id，前端却在读product_id。

我以为是偶然，继续让AI修。结果越修越乱：修完A接口，B接口的联调逻辑又变了；改了前端字段，后端又抛出一个没见过的枚举值。到第二天，项目里同时出现了三套字段命名规范、两套鉴权方案，连我自己都分不清哪部分是对的。

最后我静下来复盘，发现问题不在AI本身，而在于我跳过了“定契约”这道关键工序。AI在缺乏统一约束的情况下，天然会在每一次生成里自行补全缺失的信息。它补全的方式是“猜”，而猜的结果并不稳定——每次调用、每个模块之间，猜的结果可能都不一样。

1.2 复盘：问题不在AI，而在指令链断裂

如果把AI全栈开发看成一条流水线，那四个指令就是四个固定工位。工位一负责设计图纸，工位二负责零件标准，工位三负责加工，工位四负责总装质检。我那次等于直接跳到了加工环节，还要求机器一边加工一边自己定标准。短期看效率很高，长期看每个零件都不匹配。

这条流水线里，顺序绝不是形式主义。指令之间的产物存在严格的依赖关系：没有蓝图，契约就没有依据；没有契约，实现就会各自为政；没有实现，验收就是无米之炊。任何一步提前或滞后，都会让返工成本成倍放大。

2. 四条指令各自承担什么：从蓝图到交付的职责拆解

要理解“为什么必须按顺序”，先把每个指令的职责边界看清楚。这四个指令不是四条并列的Prompt，而是一条依赖链上的四级台阶。

2.1 指令一：项目蓝图与边界约束

指令一解决的是“做什么”和“不做什么”。它要求AI先输出一份项目蓝图，内容包括业务背景、目标用户、核心功能范围、页面与路由结构、角色与权限、技术栈候选方案、部署环境假设。

这条指令看起来最“虚”，实则是整条流水线的地基。它把模糊的产品想法翻译成可执行的工程语言，同时给后续所有指令设定边界。比如你做一个后台管理系统，蓝图里应当明确：是否需要多租户？是否需要审计日志？用户角色分几层？这些边界如果不在起点定下来，AI会在后续开发中反复替你做决策，而且每次都可能换一个方向。

我见过不少开发者嫌这一步啰嗦，直接让AI“帮我做个电商网站”，结果AI自由发挥出了五花八门的微服务架构、消息队列、分布式事务——没有说不行，但这个复杂度根本超出了需求本身。蓝图的作用，就是把AI的想象力约束在合理的跑道内。

2.2 指令二：数据模型与接口契约

指令二解决的是“共同语言”问题。它要求在蓝图完成后，AI输出一份完整的数据模型与接口契约，覆盖数据库表清单、字段类型与约束、枚举值定义、API端点列表、每个端点的请求与响应示例、鉴权方式、错误码约定。

这一步是整个全栈链路里最容易省、也最不该省的一步。前后端联调时的绝大多数冲突，根源都在于双方对“某个字段叫什么、某个接口返回什么”没有统一认知。人类开发者之间还需要接口文档对齐，AI开发同样需要——而且AI的“自由发挥”倾向更强，契约这道锁必须上在写代码之前。

契约还有一个实际价值：它是后续验收的基准。测试用例按契约写，字段校验按契约写，部署配置按契约写。没有契约，你无法判断AI写出来的代码是“对的”还是“看起来对的”。

2.3 指令三：模块化功能实现

指令三解决的是“怎么建”的问题。它基于蓝图的边界和契约的约束，让AI按模块逐步实现功能。比如第一个模块是商品管理，那就只写商品管理涉及的后端路由、数据库操作、前端页面和组件，不碰订单模块。

关键点是“模块化”和“一个模块一跑”。不要一次性把十个模块的需求全塞给AI，那不是高效，是把所有冲突同时引爆。每完成一个模块，让AI运行该模块的测试，并输出验证结果，你确认无误后再进下一个模块。

模块化的另一个好处是可控。一旦某个模块实现出现偏差，影响范围被限制在当前模块内，你不会面临“改一个字段引发全线崩溃”的连锁灾难。

2.4 指令四：联调验收与交付配置

指令四解决的是“能不能交”的问题。这一步让AI执行完整的验收流程：依赖安装与构建是否通过、核心业务链路是否端到端跑通、异常处理是否齐全、部署配置和环境变量是否整理好、运行手册是否完整。

这四条指令的分工差异，用一个表格来看更直观：

顺序的本质，就是前一级的产出成为后一级的输入。后一级的每一步都建立在前一级已经验收过的确定性之上。

3. 顺序为什么不可逆：三层依赖逻辑

有人会说：“我把四个指令一次性发给AI不行吗？聊天窗口里反正它都看得见。”不行，而且不行得很有道理。

3.1 产物依赖：下游指令不接受上游的空白支票

第一层是最简单的硬依赖。数据模型必须从蓝图中推导，API契约必须基于数据模型，功能代码必须遵守契约。如果跳过了蓝图，契约的“业务边界”就是AI猜的；如果跳过了契约，功能代码的“字段命名”就是AI自由发挥的。下游指令不能接受一张空白支票，否则它生产出来的东西，你没有任何依据判断对错。

我自己做过一次对比实验。让AI在无契约状态下写商品接口，再让它基于契约写同一个接口，生成结果连“可维护性”这个维度都比不了——无契约版本里有三个不同的字段命名策略，有契约版本每个字段都有出处、有注释、可追溯。这个差距不是AI的能力问题，是输入质量的差距。

3.2 上下文依赖：前面指令的产物是后一指令的注意力锚点

第二层依赖与技术原理强相关。LLM做的事，本质上是基于你给它的全部上下文预测下一个Token。上下文里的信息越多、越拥挤，每个独立指令被模型“记住并执行”的概率就越低。

如果你把四个指令一次性塞进同一个Prompt，表面上看AI什么都知道了，但在实际生成时，真正占据注意力的是最后一次出现的指令，以及上下文中离生成位置最近的内容。前面的蓝图约束、字段契约，很可能在数十轮对话之后被稀释掉，AI就会重新展现出它自由发挥的倾向。

顺序执行为什么有效？因为每个指令都是在干净、聚焦的上下文里进行的。指令二运行时，参考的是指令一刚产出的蓝图；指令三运行时，参考的是蓝图加契约。这相当于给模型一个稳定的注意力锚点，让它在每一次生成时都知道“当前到底要干什么、边界在哪里”。

3.3 验证依赖：每个指令结尾都是一个质量门

第三层是验证成本问题。顺序执行的最大好处，是每道指令结束都有一个验收点。蓝图错了，改蓝图；契约错了，改契约；实现错了，改实现。错误被拦截在离它最近、影响面最小的地方。

乱序执行最可怕的地方在于：错误会向后扩散，而且越扩散越难追溯。没有契约就写了功能，字段统一性错了；再基于错的功能做验收，验收结果也会失真；最后修的时候，你分不清这个错误到底是实现问题、契约问题还是蓝图问题。顺序跑，错误是单一来源；乱序跑，错误是全链路杂交。

4. 打乱顺序的三个故障复盘：每个都能对应一段查证过程

光讲理论不够，我把三次典型的乱序故障完整复盘一遍。它们不是编出来的场景，而是我在AI全栈开发中实际踩过、也帮朋友排查过的坑。

4.1 先跑功能指令：AI自造字段，前后端数据对不上

现象：我先让AI实现商品列表和创建功能。代码生成后，列表页读取stock，新增表单提交quantity，数据库里有quantity没有stock。更离谱的是，接口返回的字段名和数据库字段名之间没有任何映射规则。

排查链路：我首先对比了前端页面代码、后端接口代码和数据表DDL，发现三个地方各自维护了一套字段命名。然后我翻AI的生成记录，发现它在没有数据字典的情况下，每次都会自行推断字段名，推断结果受那次Prompt中的上下文影响，因此不稳定。最后我定位到根因：跳过契约指令，等于把字段命名权完全交给了生成语境。

修复方案：我补做指令二，让AI基于现有代码反向生成数据字典，再要求所有实现必须引用字典里的标准字段。改动量不小，但至少修复方向明确。

4.2 先跑契约指令：技术栈被擅自决定，返工一大片

现象：另一个项目里，我先把“接口契约”指令发给了AI。AI默认选了Express加MongoDB，因为这是它的主流偏好。但项目真实需求是内部管理系统，需要强事务和行级审计，我原计划用PostgreSQL加Prisma。契约跑完后，我发现所有生成的DAO、查询语句全部面向MongoDB。

排查链路：检查契约文档，发现AI在执行“接口契约”时自行推断出了技术栈选型。这个推断又反向约束了数据库表设计。也就是说，没有蓝图约束的情况下，契约指令自己给自己定了一个不合理的前提，然后在这个前提下做出一整份完整的错误决策。

修复方案：重置项目上下文，按顺序先跑蓝图，明确技术栈为PostgreSQL加Prisma，再让AI基于蓝图重新生成契约。通过这次经历，我彻底理解了“技术栈选型属于蓝图范畴，而不是契约范畴”。

4.3 四条指令一口气全发：上下文挤爆，输出只给了一半

现象：我试过一次把“蓝图、契约、功能实现、验收部署”全部写在一条Prompt里发给AI，附带一句“请按顺序完成”。AI前两部分完成得还算像样，到了第三个指令就开始偷工减料，第四个指令直接被忽略，结尾给出一个“如果你需要，我可以继续……”的敷衍话术。

排查链路：观察模型输出，发现它在长Prompt中自行降低了对后段指令的执行优先级。这和上下文窗口机制一致：前面指令已经消耗了模型的“注意力预算”，后续指令在生成时更容易被简化处理。再加上功能实现涉及大量代码，必然要优先满足前文需求的“形式完整”，结果后文需求的实质内容就丢了。

修复方案：把四个指令拆成单独对话，一次只跑一个。每个指令完成后，把决策要点保存成摘要，再在新会话中喂给模型继续下一个指令。

4.4 这三个故障说明的同一个道理

三个故障表面原因各不相同，内核只有一个：违背顺序会让AI的关键决策失去锚点。要么是字段名没有锚，要么是技术栈没有锚，要么是整个流程没有锚。AI全栈开发里的“锚”，就是前一道指令产出的那份文档。你跳过的工序越多，AI需要替你猜测的维度就越多，而猜测恰恰是失控的开始。

5. 把顺序固化进工作流：四套可直接抄的指令模板

理解了为什么，接下来是怎么办。我把四条指令经常使用的固定写法整理如下。这套模板的定位是“可运行的交互协议”，不是魔法咒语——你可以按项目实际情况调整，但骨架和顺序不要动。

5.1 模板一：蓝图指令的写法和交互技巧

你现在是一名全栈架构师。接下来我会分几步开发一个项目：[一句话描述项目]。 这是第一道指令：不要写任何实现代码，先输出《项目蓝图》。 蓝图必须包含以下内容： 1. 业务背景与目标用户 2. 功能范围：必须做、可选做、明确不做 3. 页面与路由结构 4. 核心角色与权限 5. 技术栈候选方案 6. 部署环境假设 输出蓝图之前，最多向我提10个澄清问题。待我回复后，再输出完整蓝图。

这里有个交互技巧：让AI先问问题。蓝图的价值在于做选择，而AI在没有信息时也会强行做选择——那些选择大概率不适合你的真实业务。提问环节相当于一次低成本的需求对齐，比我手动给AI补充八页文档高效得多。

5.2 模板二：契约指令的写法和验收项

基于刚才确认的《项目蓝图》，现在执行第二道指令：输出《数据模型与接口契约》。 要求覆盖： 1. 数据库表清单，每张表的字段类型、约束、默认值 2. 枚举值定义及取值范围 3. API端点列表，每个端点的路径、方法、鉴权要求 4. 每个端点的请求和响应示例 5. 错误码约定 6. 数据校验规则 注意：不要写controller实现，不要写页面代码，只输出契约。

契约完成后，你要检查的不是代码，而是“能不能基于契约直接写Mock服务”。如果前端能在后端还没开工时靠契约Mock出全部联调环境，这份契约就是合格的。做不到这一点的契约，说明它还不够具体。

5.3 模板三：功能指令的“一个模块一跑”模式

基于《项目蓝图》和《数据模型与接口契约》，现在执行第三道指令。 本次只实现第一个模块：[模块名称]。 要求： 1. 只实现该模块必要的后端接口、数据访问和前端页面 2. 字段命名必须与契约完全一致，不许新增未声明的字段 3. 为该模块编写可执行的测试 4. 实现完成后，运行测试并列出验证命令与实际结果

一个容易被忽略的细节：指令三后面跟着“验证命令与实际结果”这个要求。AI生成代码后，经常自我宣称“已完成”，但实际跑起来全是坑。要求它输出实际的测试运行结果，会强制它至少完成一个最小闭环，也能让你在下一次指令前发现显性问题。

5.4 模板四：验收指令的清单式写法

现在执行第四道指令：对当前项目做完整验收。 按以下清单逐项检查，每项给出结论，失败的项直接给出修复方案： 1. 依赖安装是否可复现 2. 项目构建是否通过 3. 核心业务链路是否端到端跑通（列出你验证的完整路径） 4. 异常分支是否处理，比如网络错误、空数据、权限不足 5. 部署配置和环境变量是否整理完成 6. 运行手册是否包含启动步骤、默认账号、注意事项 不要在这一阶段新增功能。

第四道指令的关键词是“不要新增功能”。验收阶段的AI会很有表演欲，看到一个小问题会顺手重构一个无关模块。加这句限制，是防止验收过程变成一次失控的二次开发。

5.5 四道指令之间的交接动作

每道指令跑完后，在进入下一道之前，我会固定加一句：

请把刚才对话中关于当前阶段最关键的结论，整理成10条以内的决策摘要，每条不超过50字。

这句话的作用是制造“交接文档”。AI对话的上下文是脆弱的，哪怕同一个会话跑到第30轮，早期结论也可能不再被准确引用。把每阶段的决策摘要单独提取出来，后续即使重置上下文、换模型、换电脑，这些摘要都能作为接力棒。

6. 顺序乱了之后的补救办法：上下文重置与项目记忆

如果已经乱序开跑了，有没有救？有。但别指望在原来那个混乱的上下文里“圆场”，那样只会越圆越糊。

6.1 彻底开新会话，而不是继续在旧会话里“圆场”

很多人在AI给出错误实现后，习惯继续追问“这里改一下”“那里再改一下”。改十轮之后，对话上下文里充满补丁和冲突，AI已经分不清哪个版本是最终想要的。这时候最理性的操作是停止修复，新开一个会话，把项目重新锚定一遍。

新会话开头不直接丢实现需求，而是先把已有的正确信息整理成“项目现状”给AI：项目目标是什么、当前完成了什么、已知的错误有哪些、接下来的计划是什么。这些信息就是新上下文的锚点。

6.2 用一份项目记忆文件完成跨会话接力

我强烈建议在项目目录下维护一个docs/context.md，内容结构大致如下：

# 项目记忆 ## 一、蓝图摘要 - 目标用户： - 核心范围： - 技术栈： ## 二、契约摘要 - 数据表清单： - 关键字段： - 核心接口： ## 三、当前进度 - 已完成模块： - 进行中模块： - 已知问题： ## 四、重要约定 - 命名规范： - 鉴权方式： - 错误码规则：

新会话开始时，把这份文件全文发给AI，然后说：“请先阅读项目记忆，确认你已理解项目上下文。接下来我会发布第X道指令。”这样即使对话清空，AI依然能借助外部记忆恢复全局认知。项目记忆文件是我实践里对抗AI“上下文失忆”最有效的土办法。

6.3 什么时候可以直接继续对话，什么时候必须重置

我给自己定了一个判断标准：

判断的核心原则是：上下文里“有效锚点”是否还在。如果AI还能准确引用蓝图和契约，就继续；如果开始反复猜测和自相矛盾，就重置。宁可多花一分钟同步记忆，也好过快进快出地拯救一个深层混乱的旧对话。

7. 团队协作时这四个指令就是四个门禁

当AI全栈开发从一个开发者的个人操作变成团队协作时，这四个指令的价值会进一步放大——它们天然可以用作四个质量门禁。

7.1 门禁的意义：评审只认契约不认感觉

门禁，每个阶段完成后必须要人工评审验收。

作为一个组织，在多人并行的情况下，最怕的就是“每个人都在用自己的真实体验测试AI接口”。如果团队中有一个人绕过契约，直接让AI实现功能，他带回来的代码一定与别人的模块对不上。而显式的顺序门禁给了团队一个共识：没有评审通过的契约，任何人不得开始新功能开发。后门关闭，前门才能打开。

7.2 多人并行时的顺序同步经验

团队里常见的问题是“分工太早”。让A写前端、B写后端，两个人在不同会话里各自支配同一个AI，结果生成的代码各说各话。合理的同步方式是：先安排一个人统一跑完指令一和指令二，把蓝图和契约作为团队共享文档，然后前端、后端、测试再基于同一套契约并行推进。

我自己带小团队时的经验是：前两道指令宁慢勿快，后两道指令可以适度并行。蓝图和契约是“磨刀”的环节，磨刀不误砍柴工；实现和验收是基于共同标准的分头施工。顺序背后的逻辑，放到团队层面更加明显——它不是限制效率，而是保护效率。

多花二十分钟把蓝图和契约钉死，可能省下后面一整个通宵。这个道理不只适用于AI全栈开发，也适用于所有试图用高效工具替代清晰思考的场景。我在项目里最值回票价的一步，永远是那两句看起来最不“酷”的指令：“先别写代码”和“把契约给我看清楚”。