企业官网建设流程全解析

我最近在重读自己用 Cursor 写的几个项目，发现一个明显的分水岭：早期就是“你一句、它一改”，代码量上去了，项目反而乱成一团；后来改成 spec-driven 的做法，才真正把 Cursor 从“即兴生成器”变成“带着图纸施工的团队”。这篇就聊聊我对 spec-driven 的理解，以及在 Cursor 里落地这套流程时踩过的坑、沉淀下来的步骤。如果你最近也在用 Cursor 做稍微正式一点的项目，或者总觉得 AI 写出来的东西“差点意思”，这篇应该能帮你找到问题在哪。

1. Spec-Driven 开发到底解决了什么问题

在展开操作之前，先讲清楚“规范驱动”这个思路的出发点。我用一个最直白的比喻：以前用 Cursor 写功能，像请一位临时帮手，你口头描述一下要什么，他发挥想象力直接写；但一旦这个功能涉及十个文件、三十个函数，他就开始“发挥过度”了——写了多余的东西、漏了你没说但以为他懂的东西，回头想改需求，前面所有上下文又得重新讲一遍。spec-driven 的核心，就是把“要什么”沉淀成一份可反复读取的规格文件，让 Cursor 每次动手前都先读一遍这份文件，而不是听你临时一两句话。

1.1 为什么这不是“写一段更长的 Prompt”

很多人听到规范驱动，第一反应是：那不就是把需求写详细点，丢给 AI 吗？我之前也是这么想的，后来发现差别很大。

Prompt 是给某一次对话用的，用完即弃，离开了那个聊天窗口它就什么都不是了。而 spec 文件是给整个项目生命周期用的，它是项目的“唯一事实来源”。你可以今天开一个会话让它实现前三个功能，明天再开一个新会话让它实现后两个功能，只要 spec 文件还在，两个会话之间就凭空多出了“记忆”。

举个实际的例子。我做过一个某图像处理 Demo，功能包含图片上传、滤镜调节、批量导出。以前的做法是每次对话都把自己对项目的理解重新打一遍：“我们是一个图片处理工具，支持上传、滤镜、导出……”AI 听了半天才进入正题。换成 spec-driven 之后，我在项目根目录放了一份SPEC.md，新会话只需要说“请阅读 SPEC.md，继续实现功能 5”，AI 自己读文件，自己把上下文拉起来，根本不用我复述。这个差异在连续开发三五天后尤其明显。

1.2 规范驱动适合什么样的项目

不是所有项目都适合上 spec，我用下来，下面几类收益最大：

• 功能边界清晰、状态多的项目。比如管理后台、表单系统、自动化工具，这类需求能枚举，能写清输入输出，AI 照着规范做就不容易跑偏。
• 需要跨多次会话迭代的项目。今天做一半，明天继续；或者同一个项目给 AI 开过好几个会话，每次都从零开始聊需求，会非常痛苦。
• 有明确验收标准的任务。比如“三个角色权限不同”“上传文件大小不能超过 10MB”，这种能写进验收清单的需求，规范驱动特别合适。

不适合的是纯探索性场景。临时调一个样式、写个小脚本跑数据、问某个 API 怎么用，这些直接对话反而灵活，没必要上 spec，上了反而拖节奏。我自己现在会在项目开始时多问一句：“这个需求是探索性的，还是需要让我长期维护的？”如果是后者，就花半小时写 spec。

2. 规范文件怎么写才有用

核心中的核心，就是 spec 文件的内容质量。我见过不少人的 spec 就是把需求文档原样搬进 Markdown，字数不少，但 Cursor 照着做还是跑偏。问题基本都出在写法上——spec 不是给人写需求文档，是给 AI 当可执行蓝图用的，所以要按 AI 的读取习惯来组织。

2.1 最小可用结构

一个能用的 spec 文件不需要多复杂，但最好包含下面几块。我项目的SPEC.md通常长这样：

# 项目规范（SPEC） ## 1. 背景与目标 为什么要做这个项目，它最终要解决什么问题。 ## 2. 功能范围 功能清单，每项一个编号，描述输入、处理、输出。 ## 3. 用户流程（核心路径） 用户从进入到完成操作的关键路径，按步骤写。 ## 4. 数据模型 核心实体、字段、关系。如果是 API 项目，写接口定义。 ## 5. 技术约束 语言、框架、依赖、性能指标、兼容范围。 ## 6. 验收标准 逐条列出可验证的条件，一条功能对应一条或多条。 ## 7. 非目标（明确不做） 明确列出这个版本不做的功能，防止 AI 自作主张。

每个部分都不要写废话。“背景与目标”两句话足够；“功能范围”是重中之重，尽量拆成原子化的条目；“非目标”这一节很多人会忽略，但实际上特别能救命。AI 最大的问题不是能力不够，而是太爱加戏，你不明确告诉它“不做”，它就会给你补一堆你以为它懂但其实根本没讨论过的功能。

2.2 五条写作原则

我写了几十份 spec 之后，总结出五条硬性原则，供你直接抄：

1. 每条功能都可测试。不要写“支持图片上传”，要写“支持上传 JPG/PNG 格式，单文件不超过 5MB”；AI 就能自查，你也能验收。
2. 每条规范一个编号。比如F-01、F-02，后面让 AI 实现时直接说“实现 F-03”，它就能精确锁定需求，不用来回翻。
3. 给量化基线。“响应要快”这种话等于没说，写“接口 P95 响应时间小于 800ms”才有约束力。
4. 负面约束写清楚。把“不做用户注册”“不做移动端适配”直接写进非目标，效率立竿见影。
5. 消灭模糊词。“等等”“之类”“尽量”“合理”全部禁止出现在 spec 里，它们一旦出现，AI 就会选它自己觉得合理的方向，而那个方向大概率和你脑子里想的不一样。

2.3 一份真实示例

我用一个迷你场景演示一下“功能范围”怎么写才算合格。假设做一个待办清单工具的删除功能：

## 2. 功能范围 F-01: 删除单条待办 - 输入：待办 ID - 处理：删除对应记录，若 ID 不存在返回“记录不存在” - 输出：操作成功或失败提示 F-02: 批量删除已完成待办 - 输入：无 - 处理：删除所有 status=completed 的记录 - 输出：返回删除条数

同样的功能，含糊版可能就一句话“支持删除待办”，AI 可能做成软删除、加个二次确认弹窗、顺手清空所有数据，你都不知道它是怎么想的。编号 + 输入 + 处理 + 输出，既方便 AI 执行，也方便你写自动化测试去验证。

3. 实操：在 Cursor 里跑通 Spec-Driven 流程

规范文件写好了，下一步就是在 Cursor 里把流程跑起来。我会分四步：挂载 spec、拆里程碑、写强制规则、做验收检查。这套流程我实际跑过好几个项目，稳。

3.1 第一步：把 spec 挂在 Agent 上下文里

最关键的一点：让 Cursor 在动手前先读到 spec。我见过有人把 spec 写在文档目录里，然后在对话里让 Cursor “去看一下项目说明”，它经常不看，或者看了没当回事。

正确做法是把SPEC.md放在项目根目录，并在对话中显式引用。在 Cursor 的 Agent 模式里输入框敲@SPEC.md，文件就会作为上下文挂进去。你也可以直接说：

请先阅读项目根目录下的 SPEC.md 文件，然后基于规范开始实现。

如果不放心，补一句“阅读后先向我复述 F-01 到 F-05 的内容，等确认后再动手”，能有效避免 AI 假装看了。这个方法尤其适合新开一个会话、忘了上下文的情况。

3.2 第二步：把规范拆成里程碑

一份几十个功能的 spec 直接丢给 AI，让它一口气干完，后果通常是前几个功能是精品，后面开始敷衍。因为对话越长，模型注意力越分散，早期规范里的细节会被冲淡。

我现在的做法是拆里程碑执行。在对话里明确边界：

请阅读 SPEC.md，按功能编号顺序，先实现 F-01 到 F-03。每完成一项，对照验收标准自查一次，然后停下来等我确认。

要求它“停下来等我确认”特别重要。一次让 AI 干太多，跑偏了不好定位；拆小步走，每一步都收到确认，它就一直能被拉回正轨。我自己一般一次最多让它做三到五个相关功能，做完跑一遍测试，再继续下一批。

3.3 第三步：写强制规则，让 Agent 没法跳过 spec

这里有一个很多人不知道的细节：SPEC.md本身只是“建议”，Agent 偶尔会忽略。要让它变成“强制约束”，得在 Cursor 的项目规则里挂一条规则。

Cursor 支持项目级规则文件，放在.cursor/rules/目录下。命名随意，内容用 Markdown 写清楚即可。我常用的一个规则文件长这样：

--- description: 项目级规则，所有会话都必须遵守 globs: ['**/*.md', '**/*.ts', '**/*.py'] --- - 在修改任何代码文件之前，先阅读项目根目录的 SPEC.md。 - 每次修改完成后，逐条对照 SPEC.md 第 6 节“验收标准”进行自查。 - 如果某条验收标准无法满足，必须在这个会话的回复开头声明“未满足”，并说明具体原因和影响范围。 - 禁止在非目标清单中出现的功能进入实现。

这个规则文件的好处是，只要你在该规则描述的范围里操作，Cursor 每次都会自动加载它，不需要你反复提醒。实测下来，“先阅读 SPEC”和“主动声明未满足”这两条，能挡住八成以上的跑偏问题。注意 globs 的写法，如果项目里既有前端又有后端，建议把规则范围扩展或拆成多个规则文件，避免路径不匹配导致规则没生效。

3.4 第四步：验收标准转成自动化测试

规范里写了“验收标准”，但如果不转化成可执行验证，它就只是文档。Cursor 的 Agent 再怎么“自查”，本质上都是概率性的，必须有真实测试兜底。

我通常在实现功能时，直接要求 Agent 顺带补测试：

在实现 F-04 的同时，为它编写单元测试，覆盖 SPEC.md 验收标准中的全部条件。

比如需要验收“删除不存在的记录时返回错误提示”，就让它写一条对应的测试用例，跑通。这样一来，每次改完代码，我只要执行测试命令，所有功能是否达标一目了然，根本不用靠肉眼去翻代码。

4. 高频踩坑与排查思路实录

这部分是真正从实战里踩出来的坑。每个问题我都自己撞过，后来才逐渐摸清楚原因和应对方法，值得你收藏。

4.1 spec 写太粗，一执行就跑偏

现象：让 Cursor 实现某个功能，结果实现出来的“很像但不完全是我要的”。比如我让实现“上传头像”，结果它搞了一套完整的多文件上传组件，带了进度条、缩略图，甚至远程存储。

原因：spec 里功能范围写得不够细，AI 按自己对“头像上传”的默认理解补齐了一堆你不需要的东西。

对策：把功能条目拆细，明确输入、输出、边界条件。最有效的一句话是：“当前版本只支持单文件，不做进度条，不做批量上传。”写进非目标，它就不会自由发挥了。后来我把这块教训固化成了写作原则：宁可多写一条“不做”，也不要让 AI 猜。

4.2 spec 太长，上下文被稀释

现象：spec 文件有几千行，Agent 读取后，前面几条功能执行得很好，越往后越敷衍，甚至会用“参考 F-01 的实现”这种话偷懒。

原因：模型上下文有窗口限制，长 spec 被压缩或截断后，后面的细节丢失。

对策：把超长 spec 拆成主文件 + 子文件。主SPEC.md只保留总纲、规则、验收总览，详细功能文档放在specs/目录，每个功能一个文件，比如specs/F-01.md。让 Agent 需要实现某个功能时再按编号加载对应文件。这样上下文里始终是高信噪比的内容，不被无关细节干扰。

4.3 多轮对话后代码越改越偏

现象：一开始严格按 spec 实现，但和 Cursor 来回改了四五轮之后，某个功能开始背离最初设计，加了一堆过度设计的东西，或者把接口签名改得和 spec 不一致。

原因：对话本身会“污染”模型的判断，越聊越容易偏；早期的 spec 指令被用户在对话中无意给出的新指令覆盖了。

对策：每轮修改之前，都让 Agent 重新读一遍SPEC.md，并明确告诉它“只改我指定的部分，其余保持和 spec 一致”。配合前面说的.cursor/rules/强制规则，让“重读规范”成为每轮变更的默认前奏。我还会定期对比代码中的接口签名和 spec 的技术约束部分，一旦不一致，立刻让 Agent 对齐。

4.4 Agent 说“做完了”但实际缺功能

现象：AI 回复“已按验收标准完成”，但你一跑，功能根本没实现，或只写了一半。

原因：这是“自我评估幻觉”，AI 容易在生成的回复里高估自己的完成度，尤其是你催它“弄好了吗”的时候。

对策：别信口头结论，只信测试结果。把验收标准全部转成自动化测试，让 Agent 必须在回复里附上测试命令的运行输出。没跑过的测试，默认等于没做。我还有一条额外规则：Agent 声称完成时，必须贴出关键代码位置和对应验收标准，便于我快速核对，而不是丢一句“完成”就收工。

4.5 常见问题速查表

4.6 一个复盘：从混乱到可控的转变

我印象很深的一次是给某团队做一个小型内部工具，需求大概三十多个功能点。第一次做的时候没有用 spec，全靠在同一个窗口里不停对话，做到第七天代码已经乱了，我甚至分不清某个函数是不是还在被使用。后来我推倒重来，花了一下午写 spec，把三十个功能拆成带编号的清单，重新开会话让 Agent 按编号逐批实现。那之后整个项目突然就变得可控了——需求变更只需要在 spec 里改对应编号的描述，再让 Agent 重新执行那一条，其他代码基本不需要动。这也是我为什么坚持把 spec 放在项目根目录：它成了我和 Cursor 之间唯一的“合同”。

5. 写在最后的几条个人经验

如果你看完前面这些，准备拿一个小项目试验一下，我再补三个实际体验中会用到的小技巧。

第一，规范文件也要版本管理。我刚用 spec-driven 时，直接改SPEC.md，结果历史需求说没就没了，想回退只能靠聊天记录。后来我把SPEC.md纳入版本管理，每次改动写一句变更描述，需求演化一目了然，哪天 AI 做得不对也能对照历史快速定位是规范变了还是实现偏了。

第二，写 spec 的时间和开发时间不是浪费关系。刚开始你会觉得“半小时写规范太奢侈”，但实际是帮你省下后面几十轮的返工对话。我自己现在的比例大约是一小时的 spec 规划能省下大半天调试时间，很划算。小项目十分钟写完有个雏形就行，不用一上来就搞几十页。

第三，最后再分享一个小技巧：给 Agent 开新会话时，第一句话别急着让它干活，先让它“读 SPEC.md，然后列出本批次要实现的功能清单和验收标准，等我确认”。这一步能让你在动手前就知道它是不是真的读懂了规范。如果复述得不对，你还能及时改，总比它写完全错了再推翻强得多。

Spec-driven 不是银弹，它不会因为多了一份 Markdown 就让代码自动变好。它真正的价值是把“本来要靠人反复沟通、盯细节”这件事，变成“一次写清楚，后面按章办事”。我试过几个中型项目之后，最大感受是改需求时终于不用把上下文给 AI 从头讲一遍——改一行 spec，重新执行，剩下的它自己会跟上。如果你还在纯聊天式地写代码，试试把要做的功能先落到文件里再说。那种可控感，确实不一样。