文墨共鸣项目实践：基于.NET框架构建企业级知识管理智能门户-编程阁

文墨共鸣项目实践：基于.NET框架构建企业级知识管理智能门户

最近和几个做企业级应用开发的朋友聊天，大家普遍有个头疼的问题：公司内部的知识文档越堆越多，技术手册、会议记录、项目报告，全都散落在不同的系统里。新员工想找个资料，得问一圈人；老员工想回顾某个技术细节，得翻半天聊天记录和邮件。知识明明就在那里，但就是“找不到”、“用不好”。

我们团队之前也深受其扰，直到我们尝试将“文墨共鸣”这个AI能力，集成到我们基于.NET技术栈的内部知识门户里。效果出乎意料的好——现在同事们可以直接用大白话提问，比如“上次讨论的微服务网关熔断策略是怎么定的？”，系统就能从海量文档里精准找出相关段落，甚至生成一个简洁的摘要。

今天，我就以一个.NET开发者的视角，和大家分享一下我们是怎么做的，把那些看似复杂的AI能力，变成企业内部触手可及的生产力工具。

1. 为什么是“.NET + 文墨共鸣”？

在决定技术栈时，我们主要考虑了三点：团队技术储备、系统集成复杂度，以及长期维护成本。我们团队主力是C#和.NET Core，现有的知识管理系统也是基于ASP.NET Core MVC和Entity Framework Core构建的。如果引入一个全新的、技术栈迥异的AI系统，学习成本和集成风险会很高。

“文墨共鸣”这类大模型服务，通常通过标准的HTTP API提供能力，这和.NET生态里调用任何其他Web服务没有本质区别。这意味着，我们不需要让后端工程师去学Python，也不需要重构现有的用户认证、权限体系。我们只需要在现有的业务逻辑层，新增几个服务类，去调用AI接口，然后把结果优雅地呈现到前端页面上。

这种“微服务化”的集成思路，让整个项目变得非常可控。我们可以先从一个核心功能点切入，快速验证效果，再逐步扩展。比如，我们先做了最急迫的“智能文档检索”，看到大家用得很顺手，再接着做了“会议纪要自动摘要”。

2. 核心场景与解决方案设计

我们的目标不是做一个炫技的AI演示，而是解决实实在在的效率痛点。经过内部调研，我们锁定了三个最高频、最痛的应用场景。

2.1 场景一：告别“关键词”搜索，用自然语言找文档

过去，我们公司用的全文搜索引擎，必须输入准确的关键词。如果你记不清文档里确切的术语，很可能就搜不到。比如，你想找“如何配置数据库连接池”，但文档里写的是“连接池参数优化指南”，用传统搜索就可能漏掉。

我们的解法：我们利用“文墨共鸣”的语义理解能力，构建了一个“语义检索”层。当用户输入一个问题时，我们不是去匹配关键词，而是先将用户的问题和所有文档的段落，都转换成高维的向量（可以理解为一种“语义指纹”）。然后，在向量空间里计算它们之间的相似度，找出语义上最相关的文档片段。

对于.NET开发者来说，这听起来复杂，但实现起来很清晰。后端主要增加两步：

文档预处理与向量化（后台任务）：新文档上传后，用一个后台服务（如BackgroundService）调用AI接口，将文档分块并生成向量，存入数据库（如PostgreSQL的pgvector扩展或专门的向量数据库）。
查询处理：用户提问时，先将问题向量化，然后在向量数据库中进行相似度搜索（如余弦相似度），返回最相关的几个文本片段。

// 示例：一个简单的语义检索服务类 public class SemanticSearchService { private readonly IKnowledgeVectorStore _vectorStore; private readonly IAIService _aiService; public SemanticSearchService(IKnowledgeVectorStore vectorStore, IAIService aiService) { _vectorStore = vectorStore; _aiService = aiService; } public async Task<List<SearchResult>> SearchAsync(string naturalLanguageQuery) { // 1. 将用户自然语言查询转换为向量 var queryVector = await _aiService.GenerateEmbeddingAsync(naturalLanguageQuery); // 2. 在向量库中搜索最相似的文档片段 var relevantChunks = await _vectorStore.FindSimilarChunksAsync(queryVector, topK: 5); // 3. 可选：将Top结果交给大模型进行精炼和重组，生成更连贯的答案 var refinedAnswer = await _aiService.RefineAnswerAsync(naturalLanguageQuery, relevantChunks); return new List<SearchResult> { new SearchResult { SourceChunks = relevantChunks, DirectAnswer = refinedAnswer } }; } }

2.2 场景二：从冗长会议录音到一分钟摘要

技术评审会、项目复盘会，动辄一两个小时，产生的会议纪要文字版很长。很多人没时间细看，导致决议项跟进不力。

我们的解法：我们开发了一个“会议纪要智能摘要”功能。行政助理上传会议录音转写的文字稿，或者直接粘贴文字纪要，系统可以自动生成一份包含“核心结论”、“待办事项”、“争议点”的结构化摘要。

这里的关键是设计好的“提示词”（Prompt），引导“文墨共鸣”按照我们想要的格式和重点来总结。我们通过几次迭代，找到了一个比较稳定的提示词模板：

你是一个专业的会议纪要助理。请根据下面的会议记录，生成一份简洁的摘要。 要求： 1. 提炼出不超过5条核心结论。 2. 列出所有明确的待办事项，包括负责人（如有提及）和截止时间（如有提及）。 3. 指出会议上存在的主要分歧或待决议点。 4. 使用中文输出，语言风格正式、清晰。 会议记录： {{这里是完整的会议文本}}

在.NET后端，我们只需要把用户上传的文本和这个提示词模板拼接，发送给AI接口即可。

public async Task<MeetingSummary> GenerateSummaryAsync(string fullTranscript) { var prompt = BuildSummaryPrompt(fullTranscript); // 构建上述提示词 var aiResponse = await _aiService.CallCompletionAsync(prompt); // 解析AI返回的文本，可以按行或特定标记解析为结构化的MeetingSummary对象 return ParseAISummaryResponse(aiResponse); }

前端展示时，摘要部分清晰明了，旁边附上“查看完整纪要”的链接，满足了不同深度的阅读需求。

2.3 场景三：技术文档的“活”助手

公司有大量的API文档、架构说明、部署手册。新人阅读时，常有疑问，但文档作者可能不在身边。

我们的解法：我们在每篇技术文档的页面，嵌入了一个“智能问答”小部件。它只针对当前文档的内容进行回答，不会“胡言乱语”。

实现原理和语义检索类似，但范围限定在当前文档。当用户提问时，系统：

将当前文档内容向量化并存储（通常在文档发布时完成）。
将用户问题向量化，并在当前文档的向量片段中搜索最相关的部分。
将找到的相关片段和用户问题一起，提交给“文墨共鸣”，要求它“基于以下上下文回答问题”。
最后，AI生成的答案会明确标注其依据的原文段落，增强可信度。

这个功能相当于给每份文档配了一个7x24小时在线的作者，答疑体验非常顺畅。

3. 在.NET项目中的关键实现步骤

如果你也想在自己的.NET项目中尝试，可以沿着这个路径走，我们踩过的坑你可以避开。

3.1 第一步：服务抽象与依赖注入

首先，不要将调用AI API的代码散落在各个控制器里。我们抽象了一个IAIService接口，封装了所有与“文墨共鸣”API的交互。

public interface IAIService { Task<string> GenerateEmbeddingAsync(string text); // 生成文本向量 Task<string> CallCompletionAsync(string prompt); // 调用文本生成 // ... 其他AI能力 } public class WenmoAIService : IAIService { private readonly HttpClient _httpClient; private readonly string _apiKey; public WenmoAIService(HttpClient httpClient, IConfiguration config) { _httpClient = httpClient; _apiKey = config["AIService:ApiKey"]; // 配置BaseUrl等 } public async Task<string> CallCompletionAsync(string prompt) { var request = new { model = "wenmo-model", prompt = prompt, max_tokens = 1500 }; var response = await _httpClient.PostAsJsonAsync("/v1/completions", request); // ... 处理响应，返回生成的文本 } }

然后在Startup.cs或Program.cs中将其注册为单例或作用域服务。

builder.Services.AddHttpClient<IAIService, WenmoAIService>();

3.2 第二步：异步处理与后台任务

文档向量化和生成摘要可能是耗时操作，不能阻塞HTTP请求。我们大量使用了BackgroundService和IHostedService。

例如，有一个DocumentProcessingBackgroundService，它监听一个通道（Channel）或消息队列。当有新文档上传时，控制器只是发布一个处理任务，立即返回响应给前端。后台服务异步地消费这个任务，完成向量化和初始摘要的生成。

public class DocumentProcessingBackgroundService : BackgroundService { private readonly Channel<DocumentProcessTask> _channel; private readonly IServiceProvider _serviceProvider; protected override async Task ExecuteAsync(CancellationToken stoppingToken) { await foreach (var task in _channel.Reader.ReadAllAsync(stoppingToken)) { using var scope = _serviceProvider.CreateScope(); var processor = scope.ServiceProvider.GetRequiredService<IDocumentProcessor>(); await processor.ProcessAsync(task.DocumentId); } } }