跳转至

第四章： 从空目录搭起第一个可运行的LLM Wiki

1. 工程目标与完整Prompt

上一模块结束时，DSH Studio 中已经存在一个“空白但就绪”的开发环境：课程开发 Session 指向独立 Workspace，已经选中 “LLM Wiki全栈工程师” Preset，产品代码尚未创建，模型、访问模式和视觉增强也已经完成核对。此时不需要重新安装 Preset、Skills 或 Plugins，也不应把最终源码复制进项目目录。真正需要解决的问题，是把 “从零建设企业LLM Wiki” 这个过于宽泛的目标，收敛成一轮边界清楚、结果可观察、失败可继续处理的工程任务。

第一轮只建立工程底座，而不同时实现资料解析、Wiki编译、知识图谱和问答。原因并不是这些能力不重要，而是后续功能都依赖一组共同边界：前端与后端放在哪里，共享数据结构由谁定义，项目怎样统一启动与验证，后端暂时不可用时页面怎样如实降级。若这些边界尚未建立就直接堆叠 RAG、图谱算法和模型调用，任何错误都可能同时跨越数据、服务与界面三层，学员既难以定位原因，也无法判断某个页面究竟来自真实服务还是预置展示。

1.1 发送前确认任务位置

主 Prompt 应发送到上一模块已经核对过的同一个课程开发 Session。课程实操只有一个执行口径：继续使用该 Session 已经选中的 “LLM Wiki全栈工程师” Preset，不切换到“标准模式”；发送前只需复查 Workspace、模型、工作区写入和视觉增强仍与上一模块的就绪状态一致。后文截图中的 “标准模式” 属于历史 STAGE-01 开发回放状态，用于识别当时的界面与过程，不是需要照抄的课程设置。

历史过程中的Workspace名称是 LLMWikiReproduction，输入区同时显示 “标准模式”、“工作区写入”、“视觉增强”和 DeepSeek-V4-Pro。这些宿主选项各有独立职责：Workspace 决定文件写入位置，工作区写入限制可修改范围，模型决定当前执行者，视觉增强供后续界面观察使用。它们不是 Prompt 的组成部分，也不能互相替代。

发送前重点观察输入框和它周围的宿主状态：Prompt 的末段应保留 typecheck、build、禁止实现项以及完成后报告要求；工作区名称必须仍指向空白课程项目；访问模式必须允许当前Workspace写入。若工作区指向资料包、旧项目或最终源码，应先切换到正确目录并新建课程 Session，再粘贴 Prompt。若访问模式不是 “工作区写入”，应先修正模式，而不是发送后再让 Agent 猜测可写范围。

图中可以直接确认历史开发时的 Workspace、标准模式、工作区写入、视觉增强和模型选择，也能看到 Prompt 的第3～7项及末尾执行要求已经进入输入区。它证明的是 “历史任务已在当时的入口准备发送”，不能由此推出 Agent 已经读取需求、创建文件或运行验证。课程学员只需参照这些宿主选项的位置，不应根据图中的 “标准模式” 切换当前 Preset。输入框中出现完整任务文本，也不等于任务已经执行。

1.2 用一条Prompt同时限定工程与验收

下面是 STAGE-01 唯一发送的主 Prompt。复制时应保留全部段落、编号、接口路径、尺寸要求和禁止项，不要把它改写成若干短消息，也不要只复制技术栈列表。

我们现在从零开始建设一个面向企业资料的“LLM Wiki工业知识库”系统。先不要一次性堆叠所有AI能力，这一轮只把工程底座和第一个可运行页面搭稳，为后续资料处理、知识编译、图谱和问答模块建立可扩展边界。

技术约束：
1. 使用 pnpm workspace, Node.js 24+；目录至少包含 apps/web、apps/api、packages/contracts。
2. Web 使用 Next.js 16、React 19、TypeScript、Tailwind CSS； API 使用 Fastify、TypeScript；本地数据层预留 SQLite。
3. 根目录提供统一的 dev、build、typecheck、test 脚本，以及 `.env.example` 和中文 README。
4. 首页先做成可用于日常运营和阶段验收的深色知识工作台：左侧产品导航，顶部项目标题和状态，主区域包含 “文档数、知识条目、关系数、今日问答” 四张统计卡、最近文档列表和处理进度。先使用来源统一、可追溯的预置业务数据，确保系统首次启动即可验证完整信息架构。
5. 同时创建文档、Wiki、知识图谱、智能问答四个路由入口，但这一轮允许后三个使用清晰的阶段占位页。
6. API 先提供 `/health` 和 `/api/overview` 两个接口；前端首页优先读取API，API 不可用时用同结构预置数据兜底，并清楚标识当前数据状态。
7. 页面要有工业感但不沉闷，使用蓝紫色高光、半透明面板、细网格背景和克制的动效；响应式至少覆盖 1440px 桌面和 768px 平板。

请你直接在当前工作区创建和修改文件，安装依赖，实际执行 `typecheck` 与 `build`，遇到错误要修到通过。不要在这一轮实现文件解析、RAG、
知识图谱算法或真实模型调用。完成后停下来，告诉我：创建了什么、验证命令和结果、启动方式、当前阶段还没有做什么。

这条Prompt包含五层彼此配合的约束。

第一层是工程结构。pnpm workspace 把 apps/web、apps/api 与 packages/contracts 放进同一个 monorepo，即单一仓库中的多包工程。它要求Web、API 和共享数据合同从第一轮就拥有稳定位置，避免后续阶段把三个临时项目再拼接起来。Node.js、pnpm、Next.js、React、Fastify 与 TypeScript 的版本和选型也被直接写入，Agent不需要自行决定另一套技术栈。

第二层是可观察的第一屏。Prompt 没有接受 “空白首页已启动” 作为阶段结果，而是指定导航、项目状态、四张统计卡、最近文档和处理进度。预置业务数据的职责是让首次启动即可检查信息架构，不是冒充已经完成真实资料处理。这里的“来源统一、可追溯”约束数据应从同一处维护；它并未声称这些统计数来自 SQLite 持久化数据或 API 响应。 第三层是服务与降级边界。/health 用于表达API的健康状态，/api/overview 提供工作台概览；首页先请求 API，失败后才使用相同结构的预置数据，并且必须向用户标明数据状态。相同结构使页面在两条路径下读取一致字段，明确标识则防止兜底数据伪装成实时结果。