鸿蒙AICoding项目实践SDD运用

上一篇讲了 SDD 是什么、为什么需要它。这篇直接上干货，把我在一个鸿蒙图片处理项目里完整跑通的流程拆开讲。五步工作流、工具选型和跟 TDD 的配合方式

一、SDD 五步工作流：

GitHub 出的 Spec Kit 是目前最主流的 SDD 工具，开源免费，不绑模型。装完之后整个流程就是五步，每一步对应一个斜杠命令，产物都是 markdown 文件，存在项目仓库里。

SDD 本质上就是把"想清楚再动手"这件事流程化了。以前这个想清楚的过程靠人脑记，现在写成规格文档，让 AI 也能照着执行。核心就是那个五步循环：写规格、出计划、拆任务、跑实现、做验证。

第一步：写项目宪法

复制代码

/constitution

这一步 AI 会反过来问你一堆问题。项目用什么语言，代码风格有什么要求，测试框架用哪个，能不能加新的三方依赖。

它产出一个 constitution.md，存在 .specify/memory/ 目录。你可以理解成项目的家法。后面 AI 每次干活都会读一遍这个文件。

我那个图片项目定的规则是：用 ArkTS，不许引入新的图片处理三方库，所有异步操作必须有 loading 状态，错误必须弹提示。这些东西写下来之后，后面它就不会自作主张给你加个库。

第二步：写规格，然后必须做澄清

复制代码

/specify
/clarify

你跟它说要做什么功能，它生成 spec.md。这时候千万别直接往下走，一定要跑 /clarify。

这个命令会自己读一遍规格，然后问问题。它会问一堆问题，比如：压缩按文件大小压还是按分辨率压，压完覆盖原图还是存新文件，最大支持多大的图，压失败了原图保不保留。

这些问题不回答清楚，它写代码的时候全靠猜。回答完它会自动把答案折回规格里。

第三步：出技术计划

复制代码

/plan

这一步产出 plan.md，里面写架构怎么搭，数据模型长什么样，用哪些接口，文件放哪个目录。

这一步一定要多看几遍，不满意就直接说重来。改计划是几秒钟的事，改代码是几个小时的事。

我当时它计划里想把压缩逻辑直接写在页面组件里，我让它抽到 service 层。就这一个改动，后面整个项目都清爽了。

第四步：拆任务

复制代码

/tasks

它把计划拆成带复选框的任务清单，每个任务独立、能单独验证。每个任务后面写清楚要改哪个文件、验收标准是什么。

markdown 复制代码

- [ ] 1. 创建 src/service/ImageCompressor.ets
- [ ] 2. 实现 compressImage 方法，输入图片 uri，输出压缩后 uri
- [ ] 3. 在选择图片回调里接入压缩逻辑
- [ ] 4. 压缩失败时保留原图并弹提示
- [ ] 5. 编写单元测试覆盖压缩成功和失败两条路径

第五步：跑实现

复制代码

/implement

它照着任务清单一条一条干，干完一条打个勾，自动跑测试。跑完 review PR 就行。

我那个项目大概出了 8 个 commit，测试全绿。我 review 很快，因为规格和计划我都看过了，代码只是在执行已经定好的东西。

二、工具怎么选

现在做 SDD 的工具不少，我按场景给大家捋一下。

工具	特点	适合谁
GitHub Spec Kit	开源，不绑模型，Copilot/Claude/Cursor 都能用	大多数人，首选
AWS Kiro	自带 IDE，每次 Agent 操作后自动跑测试和 lint	已经在 AWS 上的团队
Cursor	Plan 模式加 AGENTS.md，不用装额外工具	已经在用 Cursor 的人
Claude Code	终端操作，配合 Spec Kit 最顺	喜欢命令行的人

我的建议特别简单：你平时用哪个 AI 写代码最多，就用那个加 Spec Kit。 别为了学个新工具换 IDE，那是本末倒置。

三、SDD 和 TDD 到底什么关系

这个问题争论很多，其实不复杂。它们干的根本不是一个层面的事。

TDD 是 Kent Beck 那套老方法，先写失败测试，再写代码让它过，红绿重构。它管的是单个函数、单个类对不对。你写一个金额计算逻辑，先把各种边界测试用例写好，让 AI 去跑绿。这个特别靠谱。

SDD 管的是功能层面。这个功能跨好几个文件，要做什么、不做什么、跟别的模块怎么配合。

打个比方。你让 AI 做一个订单列表页。SDD 告诉你这个列表展示哪些字段、分页怎么做、空数据长什么样。TDD 保证里面那个算总价的函数算得对。

维度	TDD	SDD
管的范围	函数、类、单个模块	整个功能、跨文件协作
回答的问题	这个单元行为对不对	这个功能是不是我要的
最佳时机	需求已经清楚了	需求还模糊的时候
主要产物	失败的测试用例	规格文档

实际用法是组合着来。功能层面先 SDD，把规格计划定好。到了写具体业务逻辑那一步，切 TDD，先写测试再让它实现。两头都不丢。

Vibe Coding 也不是没用。我平时验证一个技术方案行不行，还是直接跟 AI 聊，快速出个 demo。那个阶段别上 SDD，太重了。SDD 是给要长期维护的生产代码用的，不是给一次性实验用的。

容易踩过的五个坑

坑一，规格写得太细。 把规格写成了伪代码，连函数叫什么名字、参数怎么传都写进去了。后来发现不对，规格管的是行为，不是实现。你连函数名都定了，AI 就没空间选更好的写法了。

坑二，规格写完就不管了。 代码改了规格不更新，三个月之后规格就是废纸。每次改需求先改规格，再改代码。CI 里挂个检查，规格和代码对不上就报警。

坑三，把规格当更长的 prompt。 很多人理解错了，觉得 SDD 就是把提示词写长一点。真不是。规格是个活文档，有结构、有验收标准、有 out-of-scope，会跟代码一起演进。你写完一次扔那儿，那不叫规格，那叫注释。

坑四，什么项目都上 SDD。 让 AI 写个简单的文件重命名脚本，也走了一遍五步流程，前后花了一小时，纯纯浪费。判断标准就一条：这个东西你两周之后还要不要碰。不要就直接聊。

坑五，让 Agent 无视边界。 就算有规格，AI 有时候也会走捷径。这个要靠 CI 跑测试、人工 review、lint 规则一起兜。别指望一份规格就能管住一切。

最后给个判断标准。遇到下面这些情况，直接 vibe coding 就行，别折腾：

一次性脚本，写完就扔
验证一个技术方案行不行的 demo
改个按钮颜色、调个间距这种小改动
你自己还没想清楚要做什么的探索阶段

反过来，遇到这些情况就老老实实上 SDD：

要上线的功能，团队多人协作
跨好几个文件的改动
要维护半年以上的项目
你已经被 AI 改过两三轮还没改对的需求

代码这个东西，以前是我们一行行敲出来的，我们当然觉得它最重要。现在 AI 写代码比我们快十倍，那我们该花时间在哪？就在把需求想清楚、把规则定明白这件事上。