第7篇：AI 驱动开发的方法论——从「会用」到「用好」

本文是「中华诗词知识库（KBCP）」系列技术文章的总结篇。前文我们逐一讲完了数据收集、数据结构、Web 设计、Web 实现、AI 应用的具体技术开发。本文不再展开任何代码，而是跳思考一个更根本的问题：

一个零基础诗词爱好者，借助 LLM，凭什么能做出一个支持语义检索、别名消歧、自然语言问答的完整知识库系统？

答案不在某一行代码里，而在一套可复用的「人机协作工作法」中。

Knowledge Base of Chinese Poetry (KBCP) — Chapter 7: AI ，“hello world” to “Be water, My Friend”.

🌟GitHub 开源地址：https://github.com/liang1057/Knowledge-Base-of-Chinese-Poetry
🌟 如果资源对你有帮助，欢迎 Star 支持！
📥 JSON数据下载：https://download.csdn.net/download/sdust_dx/92826598

---

---

一、人工智能在软件项目开发中的意义

1.1 从「手写代码」到「AI 协同」的范式转变

传统软件开发的隐含假设是：开发者既是需求的翻译者，也是全部代码的书写者。一个人（或一个团队）要把"用户想要什么"翻译成"机器能执行什么"，中间经历需求分析、方案设计、编码、测试、部署一整条链路，每一环都高度依赖人的经验与体力。

大语言模型（LLM）的出现，改变的不是某一行代码的写法，而是开发的根本逻辑：

开发者的角色从「全程书写者」转变为「架构师 + 审核者」。甚至说，我已经脱离了架构师，而成了一个 产品经理（只负责提形态需求、提功能想法）， AI 接管了大量"从零开始写"的体力活，而人把精力集中在"判断什么是对的、什么是有价值的"这类只有人能做的决策上。

这不仅是能力的替代，而是分工的重构。

1.2 AI 在软件工程全生命周期的渗透

人工智能并非只出现在"写代码"这一个环节，它贯穿了软件工程的整个生命周期。如果不是在烧Tokens，那么下图展示了一条 可行的参照性开发链路，以及 AI 在每个环节扮演的角色——注意，AI 始终是辅助，实线推进的主责仍在人身上。

需求分析阶段，AI 辅助梳理需求、生成用户故事；方案设计阶段，AI 辅助技术选型、画架构草图；数据结构阶段，AI 辅助表结构设计、字段建议……每一环都有 AI 参与，但每一环的最终责任都落在人身上。

1.3 本项目（KBCP）的 AI 驱动开发（重点）

如果说前面两节是"普遍的道理"，那么本节要落地到本项目，并提炼出一套可复用的方法论。

KBCP 的特殊之处在于：项目主导者是一名诗词爱好者，而非资深工程师。正是借助 LLM，才得以在零基础的前提下，完成一个包含 6.2 万首诗词、支持语义检索、别名消歧、自然语言问答的完整知识库系统。

这背后不是"让 AI 替我把项目写完"的侥幸，而是一套反复验证的人机协作工作法。我们将它抽象为「组织图 + 工作图」的双层结构——这一结构借鉴了现代 Agent 工程的思想，但我们用它来描述"人如何与 LLM 协作开发一个软件项目"。

上方「组织图」是稳定的——无论做什么功能，人永远在需求、架构、质量三个锚点上，（这也是人在人工智能冲击下的最后自留地吧）。下方「工作图」是动态的——每个具体任务都由"AI 出初稿 → 人审核 → AI 修正 → 人确认"四步循环推进（付费用户们，似乎可以摆脱这一步或者大大缩减这一步了）。实线（==>）表示长连接（人的方向贯穿全程），虚线（-.->）表示动连接（按需触发的反馈与升级）。

这套方法论在实际中凝练为三条铁律（做开发的时候，一定要写上）：

铁律一：先想清楚再问 AI（人定约束）
LLM 的能力上限取决于你给的上下文质量。KBCP 的每一步，都是人先把"我要解决什么问题、有哪些边界条件"想清楚，再交给 AI 出初稿。模糊的提问只会换来模糊的代码。

铁律二：AI 的输出必须校验（人不盲信）
从不直接执行 AI 生成的 SQL，从不直接采信 AI 给出的事实。所有 LLM 产物都要经过"规则校验 / 单元测试 / 人工核对"三重关卡。这是把 LLM 关在笼子里用的核心。

铁律三：迭代而非一次完成（闭环而非直线）
把 AI 当"实习生"而非"专家"：第一次输出只是草稿。人指出问题 → AI 修改 → 再审核，循环直到合格。项目的 5 张数据表、Text-to-SQL 校验器、Agent 中枢，都是这样迭代出来的。

一定要清楚：AI 驱动开发 ≠ AI 自动开发。

它的本质是——人把"判断力"留在自己手里，把"执行力"交给 AI，用一个稳定的组织层（人）去驾驭一个动态的工作层（AI）。

---

二、本项目中的人工智能应用：LLM 的技术点

本节不再重复"纯 RAG 的三个软肋"这类具体分析，而是从更通用的视角，看本项目如何把 LLM 与确定性系统组合，解决实际问题。

2.1 检索增强生成的两种范式

本项目对 RAG（检索增强生成）的应用，可以归纳成两种范式。它们不是"先进与落后"的关系，而是确定性与灵活性之间的权衡。

范式一：确定性检索（向量检索后直接生成）

用户提问 → 在向量库中做距离计算（如余弦相似度）→ 召回最相近的若干片段 → LLM 把片段组织成通顺答案。

其特点是检索过程完全确定：召回哪些内容，由固定的向量距离算法决定，与 LLM 无关。LLM 只负责"说人话"，不负责"找资料"。这保证了结果的可复现、可追溯。

范式二：LLM 辅助检索（先让 LLM 理解查询，再检索生成）

在检索之前，先用 LLM 对用户的原始问题做语义改写或扩展。例如用户问"写月亮的古诗"，LLM 可能把它扩展为"月 / 羁旅 / 思乡 / 望月怀远"等多个语义维度，再带着这些维度去向量库召回，最后由 LLM 生成答案。

其特点是查询阶段引入了 LLM 的语义理解能力，能弥补用户表达与知识库表述之间的鸿沟，召回更灵活、更贴合意图；代价是检索过程不再完全确定，需要额外的护栏防止 LLM 改写失控。

本项目实际采用的是双范式混合：能用确定规则（如别名映射、意图分类）直接定位的，走确定路线；需要语义理解的，走 LLM 辅助路线。二者互补，而非互斥。

2.2 本项目 AI 应用全景（组织图 + 工作图视角）

把本项目的各项 AI 技术点，也用「稳定层 / 动态层」的结构来看，可以得到一张全景图：

稳定层（确定性底座）——这些是护栏，完全由规则/算法实现，不调一次 LLM：

• 别名映射与实体消歧：用哈希索引把"子瞻"“东坡"映射到"苏轼”，毫秒级、零成本，且结果永远正确。
• 查询意图分类：基于关键词模式匹配，把用户问题归入 7 类意图（检索诗词、查作者、按标签找……），为后续路由做准备。
• SQL 校验器：Text-to-SQL 生成后，由校验器核对字段白名单、强制只读、拦截危险操作——这是 LLM 输出可信赖的关键闸门。

动态层（LLM 协作任务）——这些是真正调用大模型的环节：

• Text-to-SQL：把自然语言问题翻译成 SQL 查询。它的前提是稳定层已经把别名、意图、表结构都准备好，LLM 只做"翻译"这一件事，大幅降低幻觉。
• 向量检索 + RAG：把用户问题 embedding 后，在向量空间召回相似诗词/作者/赏析，再交给 LLM 组织答案。
• Agent 中枢与工具调用：LLM 只负责"选哪个工具、传什么参数"，具体执行交给 7 个结构化工具。LLM 不编造事实，只做调度。

2.3 多模型编排与降级

为了不把命运绑死在单一模型上，本项目对 Ollama（本地）、DeepSeek、智谱 GLM 做了统一接口封装，按可用性自动降级。这本身也体现了铁律二——不盲信单一来源，留出兜底。

---

三、LLM 辅助软件开发的实践：从写方案到写代码

本节把第一部分的「方法论」落到真实的开发流程上。下表展示了一个软件项目从想法到上线，LLM 在每个阶段能辅助什么、本项目对应的实际案例是什么。

开发阶段	LLM 辅助的内容	本项目实际案例
写方案	可行性分析、技术选型、范围界定	从"想做个诗词库"到确定 Flask + SQLite 的轻量技术栈
写设计	系统架构、模块划分、接口定义	5 张表联动的数据模型，经过两轮迭代重构
写数据结构	表设计、字段定义、索引策略	诗词表 40+ 字段的分层设计（原文/赏析/标签/作者）
写算法	算法思路、伪代码、优化方向	余弦相似度召回、TF-IDF n-gram、SQL 校验器
写 Web 实现	路由、前端组件、API 骨架	四栏布局、jsTree 懒加载、后台 CRUD 的初稿生成
写代码开发	逐模块编码、Bug 定位、重构	AutoTag 批量打标、RAG 检索、Agent 中枢的迭代实现
写测试	测试用例、端到端脚本、缺陷定位	烟测脚本、SQL 校验器的边界测试
写文档	README、API 文档、系列博客	本系列 7 篇 CSDN 技术文章（本文即第 7 篇）

可以看到，方法论的三条铁律贯穿始终：每个阶段都是"人定方向（方案/设计/边界）→ AI 出初稿（代码/SQL/文档）→ 人审核（测试/校验）→ AI 修正（迭代）"的循环。

例如「写数据结构」阶段，人先想清楚"诗词需要哪些维度可被检索"（这是约束），再让 LLM 给出字段草案，人审核后发现字段粒度不够、补充了标签与作者关联，最后让 LLM 生成建表语句并人肉核对——这正是"组织图定锚、工作图协作"的缩影。

方法论的通用性：这套流程并不专属诗词项目。换一个"图书管理库"“菜谱知识库”“法律条文检索”，只要把稳定层（规则/校验）和动态层（LLM 任务）重新填充，开发方式完全可迁移。

---

四、总结与展望

回到本文开头的两个问题：

人工智能对于一个软件项目意味着什么？
它不是"自动写代码的魔法"，而是对人机分工的重新定义——人负责判断与决策，AI 负责从零到一的体力执行。AI 渗透在软件工程全生命周期，但每一环的最终责任仍在人。

KBCP 的可复制经验是什么？
是一套「组织图 + 工作图」的 AI 驱动开发方法论：用稳定的组织层（人锚定需求、架构、质量）去驾驭动态的工作层（AI 出稿→人审→AI 改→人确认），并恪守"先定约束、必做校验、迭代闭环"三条铁律。

本项目的核心心法只有一句：LLM 要关在笼子里用——用确定性底座（规则引擎、字段白名单、只读执行）做护栏，用 LLM 做它擅长的事（语义理解、自然语言生成、代码初稿）。

下一步：

• 从"单 Agent 调度工具"走向"多 Agent 图协作"（规划 Agent + 检索 Agent + 校验 Agent 分工），正如现代 Agent 工程所倡导的组织图/工作图演进；
• 更精细的语义理解，让范式二的 LLM 辅助检索更加可控；
• 把本方法论沉淀为可复用的「LLM 辅助开发 Checklist」，惠及更多零基础的创作者。

AI 不会替代开发者，但会用 AI 的开发者，会替代不用 AI 的开发者。KBCP 正是这句话的一个小小注脚。

---

系列文章索引：

• 第1篇：数据收集 https://blog.csdn.net/sdust_dx/article/details/160376855?spm=1001.2014.3001.5502
• 第2篇：数据清洗 https://blog.csdn.net/sdust_dx/article/details/160961575?spm=1001.2014.3001.5502
• 第3篇：数据Schema设计 https://blog.csdn.net/sdust_dx/article/details/162350369?spm=1001.2014.3001.5502
• 第4篇：Web与AI智能化设计https://blog.csdn.net/sdust_dx/article/details/163087307?spm=1001.2014.3001.5502
• 第5篇：Web和AI智能问答的实现https://blog.csdn.net/sdust_dx/article/details/163297515?spm=1001.2014.3001.5502
• 第6篇：人工智能应用集成https://blog.csdn.net/sdust_dx/article/details/163299938?spm=1001.2014.3001.5502
• 第7篇：使用人工智能技术开发软件项目从「会用」到「用好」