SDD落地实战、从0构建一个AI助手，以及如何绕过那些技术深坑
在AI应用蓬勃发展的今天，智能客服已成为各行各业的基础设施。虽然Coze等平台让搭建客服助手变得容易，但这些方案存在一些局限：难以本地部署、依赖第三方平台、存在数据安全风险。
基于这些考虑，我决定尝试一种不同的路径：使用SDD（规范驱动开发）方法，配合AI编程助手，独立搭建一个完全可控的客服聊天系统。
2个目的：
1： SDD 的效果验证
2： 建设一个我完全可控的智能助手
前天晚上，我打开Cursor编辑器，给自己设定了一个目标：能否在两个晚上的业余时间里，从零开始构建一个功能完整的客服聊天智能体？
我当时的预期并不乐观——我要打造是一个包括前后端的完整的系统，应该算一个小型的应用了。但结果，却完全出乎我的意料。
一、基于SDD：用规范驱动开发流程
我的起点很简单：给Cursor一个清晰的指令。
“开发一个客服支持的智能体，包括前端和后端，前后端分离。支持的功能包括：
聊天会话管理（新增、删除等），
聊天界面，设置（包括模型设置、知识库设置，模型可以选择，知识库支持多个知识库的知识导入、查看等）。
用户通过前端和智能体沟通，智能体查询相关的知识库，然后给用户适当的反馈，支持流式和非流式。”
接下来，我启动了SPEC KIT框架的标准化流程：
**第一步：需求规范（spec.md）**Cursor将我的自然语言描述转化为结构化的功能需求文档。24个具体需求点，10项可衡量的成功标准，每一个用户故事都配有明确的验收条件。 我对生成的需求进行了部分检查和修订
**第二步：技术方案（plan.md）**我补充了唯一的技术栈要求：“使用LangChain框架"
基于LangChain要求，Cursor设计了完整的架构方案：
-
后端：FastAPI + LangChain + LangGraph + ChromaDB
-
前端：React + TypeScript + Vite
-
模块化分离：agent、tools、prompt、api等各司其职
第三步：任务分解（tasks.md）这是最令人印象深刻的部分。Cursor生成了97个具体开发任务，每个任务都精确到文件路径：
- [ ] T024 实现向量搜索工具：backend/src/tools/vector_search_tool.py
- [ ] T034 创建聊天界面组件：frontend/src/components/ChatInterface.tsx
自动分析了任务依赖关系，标注了哪些可以并行开发——前端界面与后端API可以同步推进，极大提升了开发效率。
第四步：一致性检查运行/speckit.analyze命令后，系统自动发现了8个潜在问题：术语不一致、定义模糊等。这步预防性检查，可能在后续开发中节省了数小时的调试时间。
完成产品的第一版展示如下：
设置页面：
二、遇到的问题：即使顺风顺水也难免偶尔逆流
开发过程并非完全一帆风顺，2个遇到的挑战是：
挑战一：Embedding模型
这是RAG系统的核心。
Cursor最初使用OpenAI的Embedding模型，但这对于国内和本地部署都不理想。
然后我选择使用Ollama 本地模型，但Ollama模型也不能下载下来
最后选择了最简单的langchain 自身携带的embedding 模型
挑战二：python环境问题
python包依赖问题还是比较复杂，出现几次pyhon包依赖版本的问题。例如使用的函数在安装的版本中已经不存在等。 不过解决问题不大。直接丢给Cursor即可
反思 环境和环境依赖管理是软件管理复杂度的一个核心和关键。 Cursor这类工具也难以解决的。
三、变更与迭代：氛围编程的流畅体验
项目开发完成后，变更难以避免。
Cursor体现了强大的能力，没有考虑使用OpenSpec等流程，直接将问题反馈给Cursor
示例一：增加聊天记录导出功能
我简单描述：“用户应该能够导出某个会话的完整聊天记录为文本文件。”
Cursor不仅添加了后端导出端点，还生成了前端导出按钮组件，并自动更新了相关API文档。
示例二：增加支持md文件导入知识库
我简单描述：“当前知识库加载仅仅支持pdf，txt等，需要支持md文件”
详细截图展示一下：
然后直接进行结果检查：
进行功能验证也完全正常
这种氛围编程的体验异常流畅：我不需要知道具体哪些文件需要修改，只需要关注功能需求本身。
这点应该是Cursor的核心能力，确实使用起来非常的丝滑。
四、核心收获：不只是代码，更是方法论
两个晚上后，我收获包括：
✅ 完整可用的智能客服核心
-
基于知识库的精准问答（RAG架构）【知识库的效果需要继续打磨】
-
流式/非流式双响应模式
-
直观的聊天界面与会话管理
-
可扩展的多模型支持框架
-
知识库上传与管理功能
✅ 完整的开发资产包【SPEC】
-
97个任务的详细开发清单
-
清晰的技术架构文档
-
模块化、可维护的代码结构
-
随时可查的API规范
✅ 可复用的SDD工作流程
-
从需求到实现的标准转化路径
-
自动化的一致性检查机制
-
支持后续迭代的文档基础
结语：从代码工人到系统架构师
这次SDD开发经历，让我体验到了一种全新的工作模式：我不再是那个埋头解决语法错误和调试细节的“代码工人”，而是更像一个系统架构师和产品设计师。
我的核心工作变成了：
-
定义清晰的需求目标和成功标准
-
设计合理的系统架构和模块划分
-
制定明确的接口规范和数据流
而具体的代码实现、细节处理、错误修复，则交给了AI助手在SDD框架的约束下高效完成。
两个晚上的时间，我不仅构建了一个可用的客服系统，更重要的是验证了一种面向未来的开发范式：
人类专注于高层设计和规范制定，AI负责细节实现和代码生成。
这种分工协作的效率，远超出我最初的想象。
AI和工具能力持续快速增强，我们唯一要做的是： 认识到当前AI的能力边界，跟上AI能力的发展
或许，这就是下一代软件开发的样貌：更智能的工具、更严谨的方法、更高效的协作。
也许：想到就可以实现并不遥远
而我们，正站在这场变革的最前沿。
完整代码（包括SDD的全部命令）已经归档到github：github.com/renhonglian…
我是AI时代原住民，欢迎关注我的公众号，一起在不确定的AI时代寻找确定性：
1：AI重构研发范式：
AI重构软件研发全流程走向落地！亚马逊发布「AI驱动开发」全新方法论，完整解读十大核心原则
AI开发新范式——规范驱动开发（SDD）【第三篇】：通过OpenSpec实现增量开发
一图介绍清楚基于Spec Kit 框架的SDD(规范驱动开发）的详细过程【SDD第二讲]
五分钟带你理解AI时代的软件研发新范式——SDD(规格驱动开发) 【SDD第一讲】
华为《智能世界2035》揭示软件未来：人机协同编程重塑软件开发格局
2：AI重构软件组织：
AI组织是什么样子？来自微软的最新分析 – The Year of the Frontier Firm:
3：软件工程本质思考：
4： 模型本质的认识：
5： 软件智能测试：
