目录
[扩展：独立 / 探索型项目，还要不要走 SpecDD？](#扩展：独立 / 探索型项目，还要不要走 SpecDD？)
一、Spec在项目持续迭代时的作用
上一篇内容 SpecDD与TDD 中我们介绍了Spec在项目规划阶段和开发阶段是如何指导AI开发的，实际上，Spec价值远不止于此，它在项目持续迭代时也发挥了重要的作用。
它记录下了过去设计的种种思路，为未来迭代提供了参考。
过去git管理代码，仅仅是记录了实现的操作，如：把A改成了B，又加了C；而Spec的记录更丰富，场景，用户，设计思路等都记载下来，在变更时，他会记录为什么要把A改成B，为什么要加C。
二、Spec如何维护项目
从项目的实际推动角度讲，我们的规划分为：开发中，已落实，已废弃。首先，在Spec文件夹中，使用planed,developing,implemented,discarded对应状态的文件夹来维护状态
其次，将Spec的规则写下来
当前的项目进展如下：
如上就完成了如何在持续运行的项目中，去建立对应的保障机制的一个过程。测试文件夹也可以按照spec的管理逻辑来进行维护。维护测试文件夹tests的时候，可以通过子文件夹以主题，模块的形式来切分管理不同的测试用例，因为大型项目的测试文件是非常多的，到后面仍会持续膨胀，必须给他一些规范和维护，避免后面太乱了。
如果除了上面所做的，还想要再长期维护，可以使用git进行维护，确保变更也能够被持续记录。对于多人协作，spec本身的编辑状态就需要被管理起来（可以用外部工具，记录了谁做了，怎么开发的，是否需要评审等）。
SpecDD是一种思想，让Spec去驱动开发。TDD的思想是完成一个功能，用测试去约束最终结果，他的重点是用test case去确保实现不跑偏。他的测试中不包含压力测试。
三、特征测试
接手一段过去的代码，既没有Spec也没有test。我们需要用特征测试 来重构代码 。特征测试是帮助我们去对一套不熟悉的代码去做分析的方法，包含了找特征行为分析、写用例，TDD开发重构理解等等一系列步骤。
他的核心思想如下：
特征测试的核心思想：
-保留目标代码集的全量关键功能
-通过测试用例的方式，锁定这个关键功能的表现
-以TDD的思想，驱动重新的开发实现
特征测试是个通识性概念，因此我们拿到一个旧代码，可以直接输入，请用特征测试的方法，完成项目的重构。
特征测试里面有一个单词：Characterization这个单词说明他在做测试设计的时候，不是简单的测试设计，是根据你的系统的功能去推断你的系统里有多少种角色在使用，利用这个角色的关键行为去构造整个测试的逻辑。
特征测试的过程跟上一篇内容的过程正好是反的
我们是知道代码，用开发过程反推test Cases，然后再用test Cases去反推Spec
想要检查测试是否做完，可以生成测试用例清单 或者Spec功能清单去检查。代码里面的细节问题可以直接问Coding Agent。
扩展：独立 / 探索型项目，还要不要走 SpecDD？
在探索期，一开始想做智能客服，又因为做客服时沉淀出了聊天界面这个通用能力，于是拿着它转型去做情感陪伴 App，整个产品形态随之改变。这个过程中，需求才逐渐明朗。
问题是：前期需求不清晰时，是否可以不走 SpecDD 路线，改走 "探索路线"------ 从一句话、一个愿景或一个痛点直接起步，前期投入轻，等做出来后再回头补文档？
Spec 有两个作用
- 约束作用：开发时锁定开发方向、功能特点与实现细节；
- 拆解作用：把 "诉求" 拆解成 "具体如何实现"。
关键在于：这两个作用都发生在还没开始开发的阶段------ 而 "一句话 / 愿景 / 痛点启动" 也恰恰在这个阶段。两者并不冲突，是同一时间做的事。
假如只输入"我想做一个直播间评论助手" 这一句话：AI 会自动追问平台、核心功能、产品形态、AI 生成部分如何处理 等问题，本质是在帮你做业务逻辑分析。这正是 "边做边定义" 的探索过程。
SpecDD 和探索不是对立关系，在快速搭建的过程中，一样可以同步撰写 Spec 。而且讨论的过程不是无效的 ：你在澄清需求时产生的所有讨论，都会成为后续开发的 AI 上下文，帮助你避免重复踩坑