企业官网建设流程全解析

这两个月，我一直在折腾同一件事：把手头一个原本需要三个人才能维护的全栈小项目，压缩成“一个开发者 + 两条 AI 编程工作流”的形态。最后复盘，真正让这件事跑起来的，不是哪个特别聪明的模型，也不是越写越长的 prompt，而是给 AI 编程流程补上了规格驱动这套规矩。所谓规格驱动，就是让 AI 在写业务代码之前，先把“要做的功能、验收标准、任务拆分”作为文件落地到仓库里。OpenSpec 负责这件事，Superpowers 负责在 AI 拿到规格之后，用一套完整的工作流防止它跑偏。

这篇文章想把我跑通后的完整打法复盘一遍，适合正在用 Claude Code、opencode 这类工具写全栈项目或业务系统的人。如果你现在的状态是“AI demo 写得飞起，项目一复杂就翻车”，那这篇内容大概率能帮上忙。

1. AI 编程在长流程任务上失控：问题不在生成，而在约束

1.1 一次让我印象深刻的“AI 越帮越忙”现场

先说个反面教材。我之前在做一个订单系统，第一天让 Claude Code 加了个“会员积分”功能，生成速度很快。用户下单、订单完成、积分入账，链路一次跑通，我当时觉得 AI 编程也就这样了。

问题出在半个多月后。需求方又说“退款的时候要把积分扣回来，但已经用掉的积分不能扣成负数”。这是个合理需求，于是我又打开会话让 AI 改。结果它为了满足这个新规则，直接改了积分账户表的数据结构，还顺手把之前“订单完成入账”的逻辑也改掉了。

关键问题是：它并不知道自己改坏了。测试用例没有覆盖到旧链路，AI 也不记得我当初为了“防止重复入账”在代码里留了什么特殊约定，它只盯着最近一轮对话里的需求，觉得把所有相关代码统一改掉就完成了。最后我花了一个晚上查数据，才发现老用户积分被多扣了一轮。

这次经历让我意识到一个本质问题：AI 生成代码的能力早就不是瓶颈，瓶颈在于它做长流程任务时的“行为一致性”。它没有一个稳定的项目记忆，也没有一套硬性的执行契约。指望每一轮对话都靠上下文把之前所有设计决定“记住”，本来就是反人性的做法——对人不行，对 AI 更不行。

1.2 长上下文、多轮对话与“语义稀释”

很多人会问：Claude 这类模型的上下文窗口不是很大吗？为什么还会忘？

窗口大，不代表它会一视同仁地利用上下文。当对话轮次多、文件内容杂、需求反复修改时，AI 对早期信息的权重天然会降低。尤其是用户在最后几轮给了新指示，模型很容易倾向于“以最新指示为准”。这在心理学上叫近因效应，在 AI 推理里其实也非常明显。

我自己的体感是：AI 在单次会话的前 20 轮表现通常是最好的，超过某个临界点后，它开始频繁出现“前面已经定过的方案突然被推翻”“某个边界条件反复确认”“同一个字段在不同文件里出现两套命名”这类现象。不是模型变笨了，是它的注意力被过长的上下文稀释了。

打个比方：你对着一个新人连续口述交代三周的工作，他当然会越听越乱。真正靠谱的项目交接，靠的是需求文档、设计文档、任务列表这些“物件化”的东西。AI 也一样，它需要一个外置记忆系统。最便宜的方案不是给它更大的上下文，而是把关键结论从对话流里抽出来，写进文件。

1.3 对话式开发与规格驱动开发的本质差异

我整理了一张对比表，基本能说明为什么越大的项目越需要规格驱动：

但这不意味着所有项目都该上规格驱动。如果你只是让 AI 写个一次性的 CSV 处理脚本，那规格驱动纯属浪费。真正需要用到这套打法的是“明天还要继续长”的项目——它会在未来几周甚至几个月里持续迭代，多个人或多个 AI 会话会反复走进来改代码。

2. OpenSpec 的规格驱动思路：先定义“什么是对的”，再让 AI 写代码

2.1 OpenSpec 到底是一个什么东西

OpenSpec 是一套围绕规格驱动开发设计的工具链。它不绑定某个模型，也不绑定某个编辑器，核心是一组命令行工具加上一套固定的目录/文件约定。

你可以把它理解成一套“AI 时代的变更管理协议”。以前我们做需求变更，靠的是 Jira 工单、PR 描述和 Wiki；OpenSpec 则把这些东西压缩成一个当前变更目录，里面主要分三类文件：

• proposal：记录这个变更为什么存在，背景是什么，要解决什么问题。
• specs：记录功能做出来之后“应该满足什么规则”，里面尽可能写可验证的条款。
• tasks：把这个变更拆成的具体落地任务，AI 照着做即可。

每个新需求进来，不是先讨论代码，而是先为这个变更创建一个 OpenSpec 目录。这个目录会成为后续所有实现的唯一依据。AI 实现完功能后，再来更新对应的任务状态。整个过程跟传统的“用户故事 + 验收条件 + 任务拆分”很像，但它被设计成了 AI 可以顺畅读懂的文件结构。

2.2 我用下来的核心命令流：创建、校验、执行、收尾

下面这组命令是我当前环境里在用的。需要注意，OpenSpec 迭代速度不慢，命令名在不同版本里可能叫new也可能叫create，所以千万不要背死命令，重点是懂流程：

# 在 git 项目根目录初始化规格仓库 openspec init # 为一次新变更创建规格骨架 openspec create "会员积分系统" # 如果实现过程中你发现规格描述不完整，可以用 update 同步 openspec update # 校验 spec 是否完整、任务是否有遗漏 openspec validate # 查看这次变更的进度，还差哪些任务没完成 openspec status # 变更完成后收尾，关闭这次 change openspec complete

我自己的习惯是：接到一个需求后，先用openspec create把变更骨架拉出来，然后立刻去编辑 proposal 和 specs 文件。等 specs 里的规则写得差不多，再让 AI 补 tasks。这个顺序很重要——如果 tasks 先于 specs 被写出来，AI 很容易把任务拆得跟需求对不上。

openspec validate是我最常用的一条命令。它相当于在正式写代码之前做一次“需求体检”：功能有没有验收条件，任务列表有没有和规格对应，变更描述里的影响范围是否清晰。这些问题在体检阶段暴露，总比代码写完再返工要便宜得多。

2.3 什么才算“好规格”：可验证规则优先

很多人第一次接触规格驱动时会犯同一个错误：用写博客的方式写规格。比如：

- 系统要具备良好的积分管理能力 - 用户体验要流畅 - 注意并发和数据安全

这种规格我称之为“伪规格”，因为它每一句都正确，但没有任何一句可以被执行或验证。AI 读了之后可以写出一百种实现方式，你根本没法判断它到底有没有满足需求。

真正好用的规格长这样：

## 规则：积分发放 - 触发条件：订单状态进入 `completed` - 积分计算：按实付金额向下取整，每 1 元发 1 积分 - 可验证样例：一笔实付 99.9 元的订单，发放 99 积分 - 边界情况：退款成功后，对应积分在同一事务内扣回

AI 看到这样的规则，不会对“什么是对”产生理解分歧；测试工程师照着最后一条“边界情况”就能写出回归测试；你自己过一周回来看，也能快速理解当初为什么这么设计。

我在实际项目里给团队定的标准是：一条规格如果没有配套的“可验证样例”或明确边界，就不允许进入开发阶段。宁可前面多花半个小时打磨规则，也不让 AI 后面多花半天猜需求。规格驱动真正的价值不是“写文档”，而是把模糊的需求翻译成 AI 和测试都能执行的判断标准。

3. Superpowers 在做什么：把 AI 的一次性聪明变成可复用的干活流程

3.1 一个 skills 技能库在 AI 编程里的角色

OpenSpec 解决了“做什么”的问题，但 AI 拿到规格后具体怎么干活，还是会乱。这时候就需要 Superpowers 出场。

Superpowers 本身是一套开源技能库，面向支持 Skills 机制的 AI 编程客户端。Skills 机制可以简单理解为：把一套成熟的工作流打包成 AI 能读取的 Markdown 指令文件。AI 一旦识别到当前任务匹配某个技能，就会按里面的步骤走，而不是自由发挥。

我以前始终觉得 AI 写代码有一个明显缺陷：它对“怎么开始一件事”没有固定章法。同一个需求，今天心情好它先写文档再写代码，明天换个会话，它可能上来就改数据库表结构。Superpowers 解决的就是这个问题。它给 AI 装上了一套类似“肌肉记忆”的行为准则，让推理过程稳定、可复现。

3.2 从 brainstorming 到 debugging 的完整动作拆解

我在实战中用到的 Superpowers 工作流，大致包含四条主流程：

第一条是 brainstorming。需求方抛出问题时，AI 不会马上写代码，而是先进入澄清状态，把涉及的业务背景、边界条件、异常情况一项项问清楚。以前我总觉得这一步浪费时间，后来发现，这里多问五个问题，后面能少改十次代码。

第二条是写计划。需求澄清完之后，AI 会把实现思路落成一个计划文档，列出准备改哪些文件、涉及哪些数据模型、接口怎么调整。这个计划不是为了给你看的，是为了让 AI 自己有一个可以反复参照的执行基准。

第三条是执行计划。它会根据计划生成任务清单，一个任务一个任务地做，而不是一口气把所有代码全倒出来。每完成一个小任务，它会停下来确认测试状态，再进入下一个任务。

第四条是 debugging。遇到问题时，AI 会先做假设、再设计验证方案，而不是东改一行西改一行。

这套流程看起来不复杂，但如果你用过原生状态下的 AI 编程工具就会知道，没有这套约束时，AI 太容易在第一步就冲进代码堆里，等它把关键文件改得面目全非，再回头解释“我为什么这么改”。

3.3 为什么它比“精心写一段 prompt”更靠谱

经常有人问我：Superpowers 不就是一组更长的 prompt 吗？我自己写一个“你必须先规划再写代码”的 system prompt 不就行了？

问题在于：prompt 是一次性的。你今天写一段“请先规划再写代码”，它只能约束当前会话当前任务；明天换一个需求，你又要重新叮嘱一遍。而且 prompt 写长了，AI 到后面很容易忽略里面的某些条款，因为那些内容对它来说只是“背景信息”，不是“操作指令”。

Superpowers 这类技能库的本质区别在于：它把工作流拆成了一个个可以被独立调用、组合、复用的技能块。收到需求时，AI 先识别场景，再调用对应的技能流程。技能内容可以跨会话、跨项目被反复使用，也可以根据项目特点增删。比 prompt 更结构化，也比 prompt 更扛得住长任务。

用公司管理来类比：prompt 像领导开会时口头说一句“大家干活仔细点”，Superpowers 像给每个岗位发了一份标准作业手册。口头叮嘱的效果看运气，手册的效果相对稳定。

4. 组合打法：OpenSpec 划边界，Superpowers 定流程，AI 照单执行

4.1 两套工具为什么能无缝拼在一起

OpenSpec 和 Superpowers 不是同一层的东西，所以它们不冲突，反而高度互补。

OpenSpec 的核心产出是“规格文件”，本质是给 AI 划定问题和验收的边界；但规格文件不会自动告诉 AI“你应该先澄清需求再写代码，写完代码要跑测试”。后者是 Superpowers 的活。

Superpowers 的核心产出是“流程纪律”，但它的流程不能凭空产生业务规则。它做 brainstorm 时，需要从某个变更上下文出发；写计划时，也需要知道究竟要覆盖哪些功能边界。这些内容正好来自 OpenSpec 的 proposal 和 specs 文件。

两者都认定同一件事：文件系统是人和 AI 之间最可靠的协作接口。聊天窗口是易失的，模型记忆是不可信的，只有落在仓库里的文件可以被反复读取、 diff、评审。顺着这个共识，二者就自然可以拼出一套稳定打法。

下面这张表是我在项目里划分的责任边界：

4.2 一套可以直接照抄的七个步骤

我现在的项目流程基本是固定的七步，你们可以直接照搬：

第一步，让 AI 先读项目里的 AGENTS.md 或 CLAUDE.md，把工作协议加载进来。

第二步，告诉它新需求进来后先进入 Superpowers 的 brainstorming 流程，不写代码，先澄清边界。比如“会员要分等级吗”“积分会过期吗”“退款怎么处理”，这些问题在 brainstorming 阶段就要问完，而不是边写边猜。

第三步，把澄清后的结果用openspec create落成变更骨架，再编辑 proposal 和 specs，把业务规则写清楚。

第四步，执行openspec validate，确认规格没有含糊其辞的地方。

第五步，让 Superpowers 进入 planning 流程，OpenSpec 提供变更约束，它负责生成计划文档和详细任务清单。

第六步，AI 按任务清单逐项实现，每完成一个任务跑一次相关测试，再进入下一个任务。所有代码改动都关联到这次 OpenSpec change 的范围内，不允许顺手改无关文件。

第七步，所有任务完成后，跑openspec status看剩余项，再跑一遍完整测试，最后用openspec complete收尾，关闭这次变更。

这套流程最大的好处是：中途即使你换了客户端，甚至把任务交给另一个 AI 工具继续做，只要仓库里的 OpenSpec 目录还在、计划文档还在，新 AI 读一遍就能无缝衔接。它不需要你重新把项目背景从头讲一遍。

4.3 一个具体的落地样例：给订单系统增加“会员积分”

为了方便理解，我模拟一个真实需求：给一个商城订单系统增加会员积分功能。

需求刚抛出来时，AI 可能会表现得很兴奋，准备直接改订单模块。我会先拦下它，告诉它按 OpenSpec 流程走。于是它先生成 proposal，里面写清为什么要做积分、影响范围是什么：

# Change Proposal: 会员积分体系 ## 背景 用户下单完成后没有任何