你想给文章列表加个搜索功能，打开 AI 编程助手，说明想法，再补充几句。AI 开始读代码、修改页面、运行测试，整个过程没有出现一个叫 spec.md 的文件。
既然聊几句就能开发，为什么还要专门写 Spec？
小任务可以不单独写文档；规则复杂、需要交接的任务，Spec 仍然有价值。关键在于需求是否明确，以及这些约定能否被可靠保留。
这里的 Spec 指需求规格：要做什么、边界在哪里、怎样算完成。
① 你没写 Spec 文件，但可能已经把需求讲清楚了。
“加个搜索功能”只是一个目标。搜索标题还是正文、点击按钮还是输入即搜索、清空关键词后显示什么，都需要有明确答案。通过几轮对话，同样可以把这些要求确定下来。
用户： 只搜索标题，点击按钮后查询，清空关键词恢复列表。
AI： 沿用现有分页和发布时间倒序；没有匹配结果时显示空列表。
用户： 对，就这样。
这段对话已经承担了轻量需求规格的作用。对于这个边界清楚的小改动，专门再写一份文档，未必增加多少价值。不过，聊天里如果还有互相矛盾的要求，就需要先整理清楚当前有效的决定。
② 从先写文档到直接对话，改变的是需求形成的方式。
文档先行的方式，先集中梳理需求，再交给 AI 实施。对话协作的方式，则可以由人先表达目标，AI 调查项目、提出问题，双方逐步补齐细节。后者依赖三个条件共同发挥作用。
读取代码，让 Agent 可以自己找到接口和项目约定；运行测试，让它可以根据实际结果修正实现。围绕模型组织上下文、提供工具和管理执行的那层系统，就是这里所说的 Harness。
人因此可以少重复背景、少规定技术步骤，把更多精力放在目标和关键选择上。文档先行时也能让 AI 帮忙起草 Spec，两种方式可以组合使用，并没有统一的“旧流程被淘汰”的分界线。
③ 模型更聪明，也不能保证猜中没说出口的要求。
还是搜索功能。如果用户只说“加搜索”，AI 选择搜索标题和正文，看起来也很合理。但如果产品只需要标题搜索，功能即使能够运行，也没有满足真实预期。
模型可以帮你发现问题、分析选项，但关键业务选择需要依据。测试也只能验证它检查到的条件；如果测试同样建立在错误理解上，通过测试仍然不能证明需求做对了。
项目规则可以要求“修改后必须测试”，却不能代替本次需求里的“只搜索标题”。Harness 组织好上下文，也不等于已经替用户定义了一份完整、经过核对的需求规格。
④ 要不要单独写 Spec，看任务复杂度和交接需要。
一个小改动，几句话就能核对，保留清晰对话即可。多条业务规则、较长的开发周期或多人协作，会让约定越来越难追踪，这时集中整理 Spec 更有价值。
例如，“按钮文案改成提交”通常不需要单独建文档；“新增会员折扣，涉及适用人群、活动叠加和退款规则”，就值得把条件与验收案例整理在一起。
也不必从空白页开始。可以先和 AI 讨论，再让它整理：
把已经确定的需求整理成一份简短 Spec，写清目标、范围、业务规则和验收条件；未确定的事项单独列出。
核对关键选择，需求变更时同步更新。判断这份文档有没有价值，可以看：明天换一个人或 Agent 接手，是否仍能准确知道要做什么，以及怎样才算做对？
