从对话式探索走向规范驱动开发的主题封面

“帮我把文章卡片改得好看一点。”

AI 很快更新一版：圆角更大，封面比例统一，标题可以显示两行，页面背景也有了一层渐变。

但卡片太高，日期和分类挤到两行，侧栏为了和文章列表对齐被拉出了空白。于是回滚再补一句新要求。

这类过程很适合讨论 AI 编程中的一个变化：当生成代码变得越来越容易，我们需要更认真地管理“到底要改成什么”和“怎样证明已经改对”。

本文把 Spec Coding 用作“围绕明确规范进行 AI 辅助开发”的简称，对应通常所说的 Spec-Driven Development，规范驱动开发。它不是一个所有工具都严格统一使用的产品名称。

1. Vibe Coding 的吸引力：先把想法做出来

在本文的讨论范围内，Vibe Coding 指一种偏向对话和即时反馈的开发方式：描述想法，让 AI 生成实现，运行看看，再根据结果继续调整。这里讨论的是工作方式，不把所有使用 AI 写代码的行为都归入这个词。

它适合解决“我还不知道想要什么，但想先看到一个版本”的问题。

例如，准备做一个个人博客，你可能暂时无法回答卡片的精确尺寸、页面的信息密度或导航的交互细节。先做一个能打开的页面，比对着空白文档讨论两小时更容易形成判断。

这个阶段可以允许尝试，也可以接受推翻。原型的价值，是帮助人发现真实需求。

问题出在：原型不断叠加功能之后，开发方式却没有变化。

“加一个分类”“更新时间”“改一下侧栏”逐渐变成会影响多个页面、数据文件和维护脚本的操作。如果仍然只看当前页面是否顺眼，很容易漏掉别的地方。

2. 为什么越改越乱？要求散落在对话里

以静态博客为例，发布一篇文章不只是生成一个 HTML 文件。

首页卡片要增加，超过页容量的文章要后移；归档要登记，搜索索引要补条目；分类和标签要同步，侧栏统计和最新文章也要更新。

这些要求如果只存在于聊天记录中，会出现三个问题。

第一，最新要求与旧要求混在一起。

上一轮说“侧栏底部和文章对齐”，下一轮又说“取消对齐，恢复原布局”。如果旧约定仍然留在文档里，后续维护可能把已经撤销的方案重新做回来。

第二，视觉结果掩盖了数据问题。

首页能够正常打开，不代表搜索能找到新文章；卡片看起来正常，也不代表网站文章数已经从 43 更新成 44。

第三，实现和完成标准由同一个模糊描述决定。

如果要求只是“优化一下”，AI 可以通过自己选定的标准宣告完成。代码可能符合它的理解，却没有符合你的预期。

把这些问题全部归结为“提示词不够长”，并不准确。真正需要补充的是：可定位的需求、明确的范围，以及能独立检查的完成条件。

3. Spec Coding 把哪些事情提前了？

Vibe Coding 的迭代探索与 Spec Coding 的规范、实现、验证流程对比

两种工作方式可以衔接：先探索需求，再明确规范和验收条件。

一份有用的 Spec，至少能回答四个问题：

  1. 谁在什么场景下遇到了什么问题？
  2. 本次需要出现什么行为？
  3. 哪些限制必须满足，哪些内容不在本次范围内？
  4. 用什么证据判断已经完成？

GitHub 的 Spec Kit 将需求描述、澄清、技术计划、任务拆解和实现验证组织成显式流程；其文档也强调在需求阶段先说明要做什么及原因，再处理技术方案。GitHub Spec Kit 官方指南

这给我们的启发是：把“目标是什么”与“准备怎样实现”分开。下面的文件划分是本文建议的轻量实践，不要求安装特定工具。

材料 回答的问题 博客示例
Spec 最终应该有什么行为？ 每页最多 18 篇，发布后文章无重复遗漏
Plan 如何实现？ 按时间排序，依次生成分页并更新链接
Tasks 分成哪些可执行步骤？ 登记文章、更新分页、同步搜索、校验
Evidence 实际做成了什么？ 数量检查、链接检查、浏览器截图和部署结果

这里最容易忽略的是最后一项。任务清单打满勾，不代表测试真的运行过；测试通过，也不代表页面已经在线上部署成功。

4. 把“卡片排紧一点”写成一份小 Spec

不必一开始就建立复杂流程。一个具体的小功能，可以从这样的说明开始：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 文章卡片时间与分类单行显示

## 问题
首页部分卡片的日期和分类换行，导致信息区不整齐。

## 范围
首页及其分页的文章卡片。
不调整文章正文中的发布时间，不改变每页文章数量。

## 预期行为
- 日期格式为 YYYY/MM/DD HH:mm:ss，使用北京时间。
- 日期与分类在同一行。
- 完整时间不截断，分类仍然可以点击。
- 空间确实不足时，分类名称允许省略号截断。
- 卡片只出现一个分类图标。

## 约束
- 保留现有主题、配色和圆角。
- 不通过横向溢出页面来强行放下一行。
- 不修改原始 datetime，不编造时间。

## 验收
- 在 360px、768px、1024px、1440px 宽度检查布局。
- 覆盖最长分类名和完整时间组合。
- 浅色、深色模式均可读，分类链接可访问。
- 首页分页链接和文章总数与修改前一致。

这份 Spec 没有规定必须使用 Flex 还是 Grid，也没有提前指定每一处 CSS。它给实现留出空间，同时结果写清楚。

上面的视口宽度是示例验收范围，不是宣称这些页面已经完成了对应测试。需要亲自记录实际验证情况。

如果这些条件无法同时满足，应当暴露冲突。例如，为了完整显示最长分类，字号是否会小到难以阅读？这时需要调整规则，而不是把文字缩得越来越小后宣告成功。

5. 再进一步：把发布文章变成可验证流程

视觉调整可以用轻量 Spec。涉及多个数据源的发布操作，更适合补上明确的不变量。

下面仍然以静态博客为例，假设每页 18 篇，发布前共有 43 篇。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 发布新文章

## 输入
- 已审核的正文、标题、摘要和封面
- 唯一 slug
- 含时区的发布时间
- 一个分类及若干标签

## 完成条件
- 文章页面、分类登记、搜索索引均包含新文章。
- 发布后总数为 44：首页分页分布为 18/18/8。
- 各分页按发布时间倒序，无重复、无遗漏。
- 总归档及对应年月归档包含新文章。
- 作者卡与网站资讯显示相同的文章总数。
- 最新文章按发布时间选取最近 5 篇。
- sitemap 包含新文章的规范 URL。
- 原有文章正文没有意外改动。

## 异常处理
- slug 重复：停止写入，报告冲突。
- 搜索条目缺失或重复：校验失败，不标记为发布完成。
- 部署未完成：报告已推送、待部署，不宣称已经上线。

这个例子里的 44 和 18/18/8 是针对一次发布的具体预期。长期维护的检查应尽量从真实文章集合推导总数，再独立验证分页中实际出现的链接；不要每次靠手动修改一串散落的常量。

同时，测试不能只比较两个都由同一个错误变量生成的数字。否则源数据少了一篇，两边仍然可能相等。可以交叉检查文章文件、登记表、搜索索引和分页链接集合，并明确哪个集合应当包含哪些文章。

6. 一个适合个人项目的工作循环

规范、计划、实现、验证及反馈修订组成的开发循环

SPEC：规范；PLAN：计划；BUILD：实现；VERIFY：验证；REFINE：反馈修订。

我更倾向于把流程控制在六步，而不是要求每次改颜色都写一套长文档。

先调查现状

让 AI 阅读相关代码、文档和已有检查，确认当前行为与问题位置。已有项目尤其要注意：仓库里有没有源工程？哪些文件是生成结果？哪个脚本会覆盖当前修改？

不了解这些边界，写出来的 Spec 可能建立在错误前提上。

写下本次目标和验收

复杂功能可以单独建立 spec.md；小修改在任务说明中写几条就够了。区分已经确定的要求、暂定假设与尚未回答的问题。

选择最小可行方案

检查主题原有能力和现有脚本，再决定是否增加代码。方案应说明主要改动点和影响范围，避免为了一个小效果引入新的框架。

按小块实现

优先完成一条能验证的路径，再扩展到全站。批量 HTML 修改尤其要先确认替换边界，不能因为一个正则在单页有效，就认定所有页面都安全。

按验收条件收集证据

数据问题用数量、集合和链接检查；视觉问题用实际浏览器；部署问题看部署结果和线上页面。没有运行的检查要明确标记，不能用“应该没问题”替代证据。

同步最终规范

实现过程中发现更合适的规则，应当更新 Spec。已经取消的方案移到变更记录中，现行规范只保留当前有效要求。

在博客项目里，docs 可以保存长期约定，功能 Spec 保存一次改动的边界，变更记录解释为什么变更。三者职责不同，避免把所有历史对话原样堆在同一个文件里。

7. Spec 也会出问题

规范不会自动让 AI 变得可靠。写得不好，它只是把模糊需求换成了更正式的排版。

常见问题包括：

  • 不可验证： “更高级”“性能更好”“体验更流畅”，没有场景和可判断的结果。
  • 过早限定实现： 还没确认问题，就要求换框架、重写模块或引入新服务。
  • 只覆盖正常路径： 没考虑空数据、重复输入、错误时间、失败部署和既有数据兼容。
  • 规范与代码脱节： 功能已经变了，文档还保留旧行为。
  • 测试复述实现： AI 按错误理解写代码，再按同样的理解写测试，两者一致但都不符合真实需求。

应对方式不是继续增加文档长度，而是使用具体案例、边界输入和独立审查。对于权限、数据迁移或外部副作用，尤其需要核对失败时会发生什么，以及如何恢复。

8. 什么时候用哪一种方式？

场景 建议做法
探索一个尚未成形的想法 快速原型，尽早看结果，允许推翻
改一处文案或局部样式 几条目标与验收即可，不必写完整方案文档
改动多个页面或数据文件 轻量 Spec、影响范围与自动检查一起做
长期维护、多人协作的功能 持续维护规范、接口约定及回归证据
涉及权限、数据迁移或重要业务 明确失败行为、审查责任与恢复方案

探索与规范可以连续发生。先用原型发现需求，再把已经确认的行为固定下来，后续实现围绕这些行为展开。

也不必把 Spec Coding 等同于某一个工具。GitHub Spec Kit 和 Kiro 都提供了围绕规范组织 AI 开发的能力，但个人项目可以先从仓库中的 Markdown 和现有测试开始。工具值得关注的地方，是它能否帮助需求、任务与实现保持一致。Kiro Specs 官方文档

9. 可以直接使用的任务提示词

1
2
3
4
5
6
7
8
9
10
11
12
请先阅读相关代码和项目约定，概括当前行为及本次问题。

基于以下目标整理一份轻量 Spec，包含：
用户场景、范围、非目标、约束、异常情况和验收条件。
已有明确答案的事项直接使用；只列出会影响实现的未知问题。

然后提出最小可行实施方案，指出需要同步的数据和文件。
实现过程中如果需求与现状冲突，说明冲突并更新方案。

完成后逐项给出验证结果：
哪些检查实际运行、结果如何、哪些尚未验证。
最后同步现行规范，避免保留已经撤销的要求。

这段提示词只是起点。真正有价值的部分，是你为当前任务填入的场景、边界和判断标准。

AI 可以很快写出一个看起来可用的版本。让它在几周之后仍然容易修改、能够验证、不会反复踩同一个坑，需要把需求和证据也放进开发过程里。

从 Vibe Coding 到 Spec Coding，值得保留的是探索的速度，值得补上的，是对“完成”更清楚的定义。

参考资料

本文中的博客 Spec、验收样例和工作流程建议为结合静态博客维护场景整理的示例，并非上述工具的默认配置。工具命令与支持能力可能变化，实际使用以官方文档为准。