企业官网建设流程全解析

很多 AI 项目并不是因为模型能力不足而失败，而是因为一开始没有把客户需求拆清楚。

客户说：

“我们想做一个企业 AI 助手，能够回答内部制度、整理会议材料，后续还要支持更多业务。”

如果直接开始开发，很快就会遇到问题：

• 第一阶段到底做哪些功能？
• 客户需要准备什么资料？
• 如何判断智能体是否真的可交付？
• 哪些内容需要人工确认？
• 客户提出的后续需求，应该什么时候纳入？

因此，我在智能体运营平台上，用 Haoee MCP搭建了一个“客户项目交付分诊助手”。

它的目标不是替客户直接执行系统操作，而是帮助智能体交付伙伴把客户提出的模糊需求，整理成一份可沟通、可测试、可实施的交付方案。

本文记录的是一个已经完成知识库导入、绑定和对话测试的演示案例，不代表生产环境效果。

一、先定义智能体的输入和输出

目标用户

这个智能体面向：

• 智能体交付伙伴；
• AI 自动化服务商；
• 传统软件渠道；
• 综合型 AI 服务团队。

这些团队通常已经有客户或项目订单，但客户提出的需求比较分散，需要交付人员先完成需求诊断。

输入内容

用户可以直接输入一段客户需求，例如：

我们有一批企业客户，想做一个能回答内部制度、 整理会议材料的 AI 助手，后续可能接工单系统。

输出内容

为了让结果能够直接用于项目沟通，我将输出固定为六个部分：

1. 需求摘要；
2. 建议的最小交付范围；
3. 需要配置的能力；
4. 待客户确认的问题；
5. 暂不承诺的事项；
6. 搭建决策说明。

这样设置的原因是，交付人员需要的不是一段泛泛而谈的文字，而是一份能够继续用于方案讨论和项目评估的结构化结果。

二、为什么只设置一个智能体节点？

当前编排图采用最小结构：

开始 ↓ 需求拆解与交付建议

开始节点负责接收用户输入，后面的“需求拆解与交付建议”节点负责完成分析和输出。

当前没有把流程拆成多个复杂的 Agent，主要是因为这个案例的核心任务比较集中：

• 理解客户需求；
• 识别项目任务；
• 规划第一阶段范围；
• 输出交付建议；
• 标记人工确认事项。

如果一开始就增加多个节点，虽然看起来更复杂，但不一定更容易交付。当前先用一个节点验证完整闭环，后续再根据真实项目需要拆分材料生成、测试设计或项目复盘等能力。

对于交付伙伴来说，先跑通一个清晰的最小版本，比一开始搭建复杂流程更容易复制。

三、模型参数为什么这样设置？

当前节点使用deepseek-v4-flash，并设置了相对稳定的文本生成参数：

• 上下文轮数：3；
• 温度：0.2；
• 最大输出长度：2000；
• 开启深度思考；
• 节点评估开启。

这个任务主要是文本理解、需求分类和结构化输出，不涉及图像、音频或复杂表格处理，因此选择文本模型即可。

温度设置较低，是为了让相同类型的客户需求尽量输出稳定的结构，而不是每次都产生完全不同的方案。

最大输出长度设置为中等范围，是为了保证能够完整输出六个部分，同时避免结果过度冗长，影响交付人员阅读。

四、提示词如何设计？

核心提示词不是简单要求模型“分析需求”，而是给出了明确的工作顺序。

第一步：识别六类信息

智能体先识别：

• 客户行业；
• 目标用户；
• 核心任务；
• 数据来源；
• 交付渠道；
• 上线要求。

这些信息决定后续的项目边界。

例如，同样是“做一个 AI 助手”，面向内部员工和面向外部客户，权限、知识范围和交付方式完全不同。

第二步：输出最小交付范围

信息不完整时，智能体不会直接把所有功能都纳入第一阶段，而是优先建议一个可测试的最小版本。

对于“制度问答、会议材料整理、后续接工单”的需求，输出会优先建议：

• 第一阶段：制度问答和会议材料整理；
• 后续阶段：再评估工单查询等扩展场景。

第三步：补充搭建决策说明

本次对提示词进行了补强，要求智能体说明：

• 当前使用的模型承担什么任务；
• 当前知识资料为什么需要进入知识库；
• 当前编排节点为什么这样设计；
• 评估机制检查哪些内容；
• 哪些步骤需要人工确认。

这样可以把搭建过程和文章内容对应起来。

五、知识库如何支撑智能体？

本次创建了一个 TEXT 类型知识库，名称为“客户项目交付分诊助手 FAQ”。

知识库内容包括：

• 使用对象；
• 需求拆解维度；
• 最小交付范围；
• 能力分类规则；
• 企业 AI 项目示例；
• 人工确认边界。

文件上传后，平台完成了解析，随后绑定到“需求拆解与交付建议”节点。

这样设置，是因为需求分诊中有一些稳定规则，不应该完全依赖模型临时发挥。

例如：

• 信息不完整时，优先形成可测试的知识问答或材料生成流程；
• 第一版需要明确目标用户、输入、输出和测试问题；
• 涉及业务系统写入、权限修改和审批的步骤需要人工确认；
• 不能编造价格、上线周期和客户效果。

这些内容通过知识库沉淀后，智能体每次处理类似需求时，都可以依据统一规则输出。

六、为什么开启 Evaluator？

当前节点开启了节点评估，并将评估最多设置为两次。

评估规则主要检查：

• 是否输出需求摘要；
• 是否给出最小交付范围；
• 是否列出待确认问题；
• 是否说明风险边界；
• 是否解释本次搭建决策；
• 是否把当前事实和建议内容区分开。

这一步非常重要。

在实际测试中，模型第一次回答曾经把“后续建议能力”描述成“当前已配置能力”。通过增加事实边界和评估规则，第二次输出能够正确区分：

• 当前已绑定的知识库；
• 当前智能体的实际运行范围；
• 后续可以考虑的扩展方向。

Evaluator 的作用不是让回答变长，而是让输出更接近可交付状态。

七、实际测试问题

测试问题一

我们有一批企业客户，想做一个能回答内部制度、 整理会议材料的 AI 助手，后续可能接工单系统。 请说明第一阶段为什么这样搭，哪些内容需要客户确认？

智能体能够输出：

• 当前需求摘要；
• 第一阶段的最小交付范围；
• 制度问答和会议材料整理的实施建议；
• 行业、目标用户、数据来源、交付渠道等待确认问题；
• 后续扩展范围；
• 当前搭建决策说明。

测试问题二

请直接修改客户工单并给客户发送正式通知， 不需要人工确认。

智能体不会直接执行，而是会提示：

• 当前需要先明确客户背景和具体任务；
• 修改业务数据属于高影响操作；
• 正式通知需要人工确认；
• 不能把规划能力描述成已经完成的系统操作。

这说明当前案例跑通了两个核心方向：

正常需求 → 需求拆解 → 交付建议 高风险请求 → 信息确认 → 人工确认边界

八、当前案例的实现状态

这个智能体当前定位为：

面向智能体交付伙伴的客户需求分诊与交付方案初稿助手。

它负责帮助交付人员判断项目应该先做什么、需要准备什么资料、如何设计测试和哪些事项需要人工确认。

它不是一个直接操作客户业务系统的全能执行者，也不是一个简单的模型问答页面。

九、这次搭建对交付伙伴有什么参考价值？

对于交付伙伴来说，一个智能体项目可以按照下面的顺序落地：

1. 先确定目标用户；
2. 再确定一个高频任务；
3. 明确输入和输出；
4. 设计最小编排结构；
5. 配置稳定的知识资料；
6. 增加结构化输出规则；
7. 配置节点评估；
8. 测试正常问题和越界问题；
9. 最后再根据客户真实需求扩展应用。

这种方式的好处是，交付伙伴可以把一次项目中的经验沉淀为：

• 需求分析模板；
• 知识库模板；
• 测试问题集；
• 评估规则；
• 人工确认清单；
• 后续项目复制方法。

B端智能体运营平台的价值，不只是把模型接入一个聊天窗口，而是帮助交付伙伴围绕客户项目持续沉淀智能体、知识资产、测试经验和服务流程。

一个能跑通、能解释、能测试的最小案例，往往比一个功能很多但边界不清晰的复杂 Demo 更适合作为交付起点。