从一句想法开始，而不是急着进入开发
我过去和 AI 协作开发时，经常会直接输入一句想法，然后让 AI 开始实现。这样的方式可以很快看到结果，但也很容易在后续迭代里暴露问题：目标没有完全说清楚，边界没有提前定义，验收标准也不够稳定。
这次我想练习另一种方式：不急着让 AI 写代码，而是先和 AI 一起把需求澄清出来。也就是说，从一句想法开始，先把背景、目标、约束、页面内容、实现清单和验收标准整理成 spec，再让实现围绕这份文档展开。
为什么需求文档会变成协作入口
AI 协作开发里，真正影响结果质量的不是提示词有多长，而是上下文是否清楚。需求文档就是上下文的载体。
当需求只停留在一句话时，AI 只能根据通用经验补全很多细节。它可能补得很快，但不一定符合我的真实目标。等我看到页面或代码后再一点点纠正，就会把协作变成反复返工。
如果先把需求写成文档，协作方式就会发生变化。AI 不再只是接收一个任务，而是和我一起围绕文档做澄清、发现缺口、补充验收条件，并把实现逻辑落到可追踪的结构里。
现在能做到什么
目前我已经可以写出比较结构化的 spec 文档。比如一份需求里会包含项目背景、目标、页面内容、数据结构、视觉要求、实现步骤和验收标准。
这已经比只写一句提示词更稳定。它能让 AI 更容易理解我要做什么，也能让我在验收时有依据，不只是凭感觉判断页面好不好。
但这个阶段还不是我理想中的可执行协作系统。它更像是一份结构化说明书，能帮助开发，但还没有形成一套完整的工作流。
可执行协作系统应该包含什么
我理解的可执行协作系统，不只是把需求写得详细一点，而是让需求本身可以推动项目迭代。
它至少需要包含几类内容：
- 模板：让每次新需求都有稳定的结构入口，不用从空白文档开始。
- 问题列表：让 AI 先暴露不确定点，而不是默认猜测。
- 验收标准：让实现完成后可以逐条确认，而不是只看主观观感。
- 实现清单：把任务拆成可以执行、可以复查、可以追踪的步骤。
- 复盘记录：记录这次协作哪里有效、哪里返工、下次要怎么调整。
- 多会话汇总：当需求跨越多轮 AI 会话时，仍然能保留上下文和决策历史。
这些内容组合起来，才会让 spec 从一份文档变成一个协作系统。
我希望 AI 在需求阶段承担什么角色
在需求阶段，我不希望 AI 只是把我的想法整理得更好看。我更希望它像一个协作伙伴，主动帮我发现模糊点。
比如，当我说“新增一个构建记录页面”时，AI 应该追问：这篇记录的标题是什么，关联哪个项目，发布日期是什么，是否需要 SEO 摘要，是否要在列表页置顶，是否要新增标签，是否有验收标准。
这些问题看起来很细，但它们能把隐藏的实现条件提前暴露出来。问题越早暴露，后面的开发越顺畅。
这次练习给我的启发
这次需求让我意识到，我真正要学习的不是单次把需求写完整，而是建立一套可以反复使用的协作方法。
直接让 AI 根据一句想法写代码，适合快速试错。但当我想长期维护一个官网、持续发布项目和构建记录时，就需要更稳定的系统。
spec 的价值不只是让 AI 看懂需求，也是在帮助我自己想清楚需求。它逼着我回答：为什么要做，做成什么样算完成，哪些信息必须沉淀，哪些决策以后还会被复用。
下一步要继续完善什么
下一步，我会继续把需求文档从“结构化记录”推进到“可执行协作系统”。具体来说，会继续完善需求模板、AI 提问清单、验收标准格式、实现任务清单和复盘记录方式。
我也会把这些实践继续沉淀到 YiForge Studio 官网里。每一次构建记录都不只是记录结果，也要记录协作方式本身如何进化。
对我来说，这就是 AI Native 开发里最值得长期练习的能力：不是只让 AI 更快地写代码，而是让我和 AI 一起把想法变成可以执行、可以复盘、可以持续改进的系统。