企业官网建设流程全解析

之前看到不少人转发一句话：“People who tell you 'AI is changing everything' are lying.”（那些告诉你“AI正在改变一切”的人在撒谎）。这句话放在社交平台上很吸睛，也容易引发站队。但作为一个长期做后端开发、也持续跟进 AI 应用落地的工程师，我想换个角度聊这个话题：AI 确实没有“改变一切”，但它在某些具体场景里，确实提供了过去很难实现的效率提升。

这篇文章不是口水文，我想从工程视角拆解三件事：

1. AI 在真实业务里的能力边界到底在哪；
2. 从“能聊天的 Demo”到“能上线的 AI 应用”，中间缺哪些环节；
3. 一个最小可运行的检索增强生成（RAG）示例，和一个极简 AI Agent 工具调用示例。

如果你正准备把大模型接入自己的项目，或者正在评估“AI 能帮我们团队做什么”，这篇文章会给你一套相对务实的判断框架和可直接参考的代码思路。

1. “AI 改变一切”的说法错在哪里

1.1 宣传中的 AI 和现实中的 AI

我们先承认一件事：大模型在 2022 年之后，确实让很多曾经不可想象的事情变成了可能。比如：

• 直接输入一段自然语言描述，生成可运行的代码；
• 把几万字的技术文档丢给模型，让它提炼要点；
• 让模型扮演客服/HR/面试官，进行多轮对话。
• 自动把一段产品需求拆成开发任务。

但宣传物料往往忽略了下半句：这些能力只在特定条件和边界内成立。你看到的“AI自动编程”视频，背后可能是精心挑选的题目、预先调好的 Prompt、以及人工修正后的剪辑。真实的代码仓库里，AI 生成的代码可能因为依赖版本问题直接无法编译，也可能把过时的 API 用法当成标准答案输出。

所以问题不在于“AI 能不能改变一切”，而在于“在哪些约束条件下，AI 能稳定地产出可用结果”。工程实践的核心工作，就是把边界找出来，然后在边界内设计流程。

1.2 被严重高估的场景

结合我自己和身边团队的经验，以下几个场景被舆论高估得最明显：

注意，这里说的“高估”不是“没用”。恰恰相反，我正是因为认可 AI 的价值，才建议把预期调回合理区间。一个能帮你把周报草稿写好、把重复性代码生成出来的工具，已经能节省不少时间；但如果你指望它自动维护好整套系统，大概率会失望。

1.3 真正已经被改变的场景

哪些场景是已经稳定落地的？

• 信息摘要和初步整理：长文档、会议纪要、邮件分类，AI 的优势非常明显。
• 代码生成和补全：在 IDE 插件辅助下，样板代码、单元测试、正则表达式、脚本开发效率提升显著。
• 非结构化数据抽取：从合同、简历、工单中提取字段，过去需要写正则和维护模板，现在用大模型 + 少量示例就能完成。
• 自然语言转 SQL / 转 API 参数：在有明确 schema 和权限控制的前提下，能降低非技术人员使用数据的门槛。

这些场景有一个共同点：输入和输出的边界相对清晰，容错率可控。AI 被塞进一个明确的流程节点里，而不是被要求“改变一切”。

2. AI 工程落地前必须理解的概念

在动手写代码之前，有三个概念如果没想清楚，后面很容易踩坑。

2.1 大模型不是数据库

很多人第一次用完 ChatGPT 后，会把它当成“什么都知道的百科全书”，然后直接问业务数据。结果模型一本正经地给出一个编造的答案。

大模型的训练目标是“根据上文预测下一个 token”，它没有权限访问你的数据库，也没有能力实时查询外部系统。它能“记住”的是训练阶段见过的高频知识，而不是你的项目私有数据。

所以，如果业务场景需要回答私有数据相关的问题，必须引入检索增强生成（RAG）或微调。RAG 是目前最适合快速落地的方案：先把文档切块并向量化，用户提问时先检索相关片段，再把“问题 + 相关片段”一起交给大模型生成回答。

2.2 AI 幻觉是特性，不是 Bug

“幻觉”指的是模型生成了看似合理但事实错误的内容。严格来说，这不是可以通过调参彻底消除的 Bug，而是生成式模型的内在属性。

工程上的应对思路是：

1. 减少幻觉空间：通过 RAG 把答案限制在检索到的文档片段内；
2. 要求模型给出依据：Prompt 中明确“请先引用文档原文，再给出结论”；
3. 人工兜底：对高影响场景设置审核节点，AI 只出草稿，人来做最终判断；
4. 评估与回归：建立评测集，每次更换模型或 Prompt 后跑一遍，观察准确率变化。

2.3 从模型能力到产品能力之间的工程链路

一个普通开发者拿到的大模型 API，只是“模型能力”。要变成稳定的“产品能力”，中间至少还需要：

• 数据接入：文档清洗、格式转换、切块策略；
• 检索服务：向量库选型、索引更新、相似度阈值；
• 生成链路：Prompt 模板管理、上下文长度控制、流式输出；
• 安全控制：内容过滤、权限校验、敏感信息脱敏；
• 观测评估：日志、耗时、Token 消耗、Bad Case 收集。

下面我们就用代码把其中一条链路串起来。

3. 最小可运行的 RAG 知识库问答实战

这一节的目标不是做一个生产级系统，而是让你用最少的代码，跑通“文档切块 -> 本地检索 -> 拼接 Prompt -> 调用大模型 -> 输出回答”的完整流程。

3.1 思路与流程

整个流程可以用一句话概括：

用户提问 -> 从本地文档中找到最相关的内容 -> 把内容和问题一起交给大模型 -> 大模型基于给定内容回答。

检索环节我为了减少依赖，没有使用高并发的向量数据库，而是用“关键词重合度 + 简单评分”的方式做演示。你可以在理解后再替换成sentence-transformers做语义向量检索。

3.2 环境准备与依赖

本文示例使用 Python 3.9+，核心依赖如下：

• requests：用来调用大模型 HTTP 接口；
• openai：如果你使用 OpenAI 兼容的 SDK，也可以用它；
• 一个可用的模型 API（可以是任何提供 OpenAI 兼容协议的平台）。

安装依赖：

pip install requests openai

说明：版本请以你实际安装时的最新稳定版为准。不同平台的 API 地址和模型名称不同，下面代码已把关键配置抽成变量，方便替换。

3.3 实现一个轻量检索模块

先建立知识库的数据结构。为演示方便，我把知识库存成一个 Python 列表，每一条是一个字典，里面有title和content。

# 文件路径：knowledge_base.py KNOWLEDGE = [ { "title": "项目部署环境说明", "content": "生产环境使用 Linux 服务器，JDK 版本为 17，Spring Boot 版本为 3.2.x。" "部署前需要确认环境变量 APP_ENV 已设置为 prod。" }, { "title": "数据库备份策略", "content": "每天凌晨 2 点执行全量备份，备份文件保留 7 天。" "恢复操作必须在测试环境验证通过后，才能在生产环境执行。" }, { "title": "用户登录流程", "content": "用户输入账号密码后，系统先校验验证码，再查询用户状态。" "密码使用 BCrypt 加密存储，禁止明文保存。" } ]

接下来实现检索函数。这里用最简单的“分词后统计重合词数”作为相关性打分，适合理解原理。实际项目建议替换为向量检索。

# 文件路径：retriever.py import jieba from knowledge_base import KNOWLEDGE def tokenize(text: str) -> set: """ 简单分词，生产环境请使用更好的分词器或直接使用向量模型。 依赖 jieba 可以用：pip install jieba """ return set(jieba.lcut(text)) def search(query: str, top_k: int = 1): """ 根据用户问题，返回最相关的知识片段列表。 """ query_tokens = tokenize(query) scored = [] for item in KNOWLEDGE: content_tokens = tokenize(item["content"]) overlap = len(query_tokens & content_tokens) scored.append({ "title": item["title"], "content": item["content"], "score": overlap }) scored.sort(key=lambda x: x["score"], reverse=True) return scored[:top_k] if __name__ == "__main__": results = search("密码怎么存储？") for r in results: print(r["title"], r["score"]) print(r["content"])

运行后你会看到，得分最高的片段是“用户登录流程”，因为它包含了“密码”“存储”等关键词。

提示：这里用jieba只是为了演示方便，真实项目可以直接用向量相似度。如果你不想引入额外依赖，也可以换成简单的字符 n-gram 重叠，思路是一样的。

3.4 实现生成模块

接下来把检索到的内容和大模型 API 接通。这里我以 OpenAI 兼容接口为例，你只需要把api_base、api_key、model替换成你自己的配置。

# 文件路径：generator.py from openai import OpenAI # 请替换成你的实际配置 client = OpenAI( api_key="your-api-key", base_url="https://your-api-endpoint/v1", ) SYSTEM_PROMPT = """你是一个严谨的客服助手。请只根据提供的资料内容回答问题。 如果资料中没有相关信息，请明确回答“资料中未找到相关信息”，不要编造。 回答时先说明依据，再给出结论。""" def generate_answer(query: str, context: str) -> str: user_content = f"""### 用户问题 {query} ### 参考资料 {context} 请基于参考资料回答问题。""" resp = client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_content}, ], temperature=0.3, ) return resp.choices[0].message.content if __name__ == "__main__": answer = generate_answer("密码怎么存储？", "用户输入账号密码后，系统先校验验证码，再查询用户状态。密码使用 BCrypt 加密存储，禁止明文保存。") print(answer)

这段代码有两个关键点：

1. temperature=0.3：把生成随机性调低，让回答更稳定；
2. System Prompt 中强调了“不要编造”：这是缓解幻觉的重要提示词策略。

3.5 串联完整流程

把检索和生成串起来，就是一个最简单的 RAG 应用。

# 文件路径：rag_demo.py from retriever import search from generator import generate_answer def main(): query = input("请输入你的问题：") contexts = search(query, top_k=2) if not contexts: print("未找到相关资料") return print("检索到的资料：") for idx, ctx in enumerate(contexts, 1): print(f"{idx}. {ctx['title']}") combined_context = "\n".join([f"标题：{ctx['title']}\n内容：{ctx['content']}" for ctx in contexts]) print("\n正在生成回答……\n") answer = generate_answer(query, combined_context) print("AI 回答：") print(answer) if __name__ == "__main__": main()

运行流程：

python rag_demo.py

输入“密码怎么存储？”，预期会先打印检索到的资料标题，再输出大模型生成的回答。整个链路已经很接近生产环境的最小原型。

3.6 生产落地还需要做的事

上面的例子能跑通，但离生产还有距离。你需要补齐：

• 切分策略：长文档不能整段塞进上下文，需要按标题、段落、长度进行合理切分；
• 向量化检索：把关键词重叠替换为sentence-transformers或云厂商的向量模型，支持语义相似；
• 向量数据库：导入chromadb、milvus、elasticsearch或云数据库，支持千万级数据；
• 内容更新与删除：索引需要随文档更新同步，防止回答过时内容；
• 权限控制：不同角色只能检索到权限范围内的文档，这一步必须在检索阶段完成，不能依靠 AI“自觉”保密。

4. AI Agent：比聊天机器人复杂在哪里

RAG 解决的是“让模型知道更多信息”的问题，而 AI Agent 解决的是“让模型能操作外部工具”的问题。

4.1 Agent 的组成

一个完整 Agent 通常包含：

• 规划能力：把复杂任务拆成多个步骤；
• 工具调用：调用搜索引擎、数据库、API、代码解释器等外部能力；
• 记忆：保存历史信息和中间结果；
• 反思与修正：发现结果不对时，重新规划或重试。

搜索引擎热词里频繁出现“ai agent开发”“ai agent”，说明这个方向关注度很高。但真正开发过 Agent 的人都知道，复杂 Agent 最难的环节不是“让模型调用工具”，而是让模型在错误发生时能够自我修正。

4.2 一个极简工具调用示例

这里展示一个最小框架：模型输出结构化的 JSON 指令，程序解析后执行本地的 Python 函数。

# 文件路径：agent_demo.py import json from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://your-api-endpoint/v1", ) # 定义工具函数 def add(a: float, b: float) -> float: return a + b def multiply(a: float, b: float) -> float: return a * b TOOLS = { "add": add, "multiply": multiply, } SYSTEM_PROMPT = """你是一个计算助手。如果用户需要进行数学计算， 请输出 JSON 格式的调用指令，例如： {"tool": "add", "args": [1, 2]} 如果用户没有要求计算，请直接回答用户问题。""" def run_agent(user_input: str) -> str: resp = client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_input}, ], temperature=0.2, ) content = resp.choices[0].message.content.strip() # 尝试解析 JSON 指令 try: tool_call = json.loads(content) tool_name = tool_call.get("tool") args = tool_call.get("args", []) if tool_name in TOOLS: result = TOOLS[tool_name](*args) return f"执行 {tool_name}{args} 的结果是：{result}" else: return f"未找到工具：{tool_name}" except json.JSONDecodeError: return content if __name__ == "__main__": while True: question = input("请输入问题（输入 exit 退出）：") if question.lower() == "exit": break print(run_agent(question))

运行效果示例：

请输入问题：请计算 3 乘以 4 执行 multiply[3, 4] 的结果是：12

这只是一个玩具版 Agent。生产环境中，你会遇到：

• 格式不稳定：模型可能不按约定输出 JSON，需要引入函数调用（function calling）或强约束解码；
• 参数错误：模型给出的参数类型不对，需要校验和重试；
• 安全风险：如果工具函数包含删除文件、更新数据库、调用线上接口的能力，模型一旦被 Prompt 注入，会造成严重事故。

4.3 为什么工程化 Agent 很难

工程化 Agent 最大的难点是可靠性。聊天可以容忍随机性，但操作数据、操作线上系统的 Agent 必须保证决策正确。任何一个环节出现幻觉，都可能带来业务故障。

所以，务实的做法是：

• 先限定 Agent 的工具范围和操作边界；
• 高危操作必须经过人工确认；
• 保留完整的执行日志，方便回溯；
• 设计最大重试次数，超过后转人工。

5. 常见问题与排查思路

把大模型接入项目时，有几个高频问题，我整理成了一张速查表。

排查时可以按照“数据 -> 检索 -> Prompt -> 模型参数 -> 输出校验”的顺序逐层排查。大多数问题都出在数据和检索，而不是模型本身。

6. 最佳实践与工程建议

6.1 评估先行：为 AI 写测试用例

传统开发有单元测试、集成测试，AI 应用同样需要“评测集”。

具体做法：

• 准备 100~200 条有标准答案的问题；
• 每次调整 Prompt、更换模型、修改切块策略后，跑一遍评测集；
• 记录准确率、召回率、Token 消耗、平均耗时；
• 用数据决定是否上线，而不是靠感觉。

6.2 降级与兜底设计

AI 不是每次都能成功。线上系统必须考虑降级方案：

• 调用失败时，返回固定话术或转人工；
• 对 AI 输出做规则校验，比如“如果回答里没有引用任何资料，标记为低置信度”；
• 设置最长等待时间，超时后进入人工处理流程；
• 对敏感操作，坚持“人在回路”（human-in-the-loop）。

6.3 成本与性能控制

大模型 API 是按 Token 计费的，控制成本就是控制上下文长度。

推荐做法：

• 检索结果只取 Top 1~3 条，而不是把整个知识库塞进去；
• 使用流式输出提升首字响应体验；
• 对高频问题使用缓存，相同问题直接返回缓存结果；
• 长对话定期做摘要压缩，替换历史消息。

6.4 数据与权限安全

这块是 AI 应用最容易出问题的部分，也是我特别建议团队重视的部分。

• 调大模型 API 前，对文档做敏感信息检测与脱敏；
• 不在 Prompt 中传入密钥、Token、个人隐私信息；
• 检索阶段就做权限过滤，而不是生成阶段依赖模型自觉；
• 记录完整的调用日志，并对日志中的用户信息做脱敏处理；
• 如果有条件，私有化部署开源模型，保证数据不出内网。

7. 写在最后

回到开头那句话：“那些告诉你 AI 正在改变一切的人，在撒谎。”我觉得更准确的理解是：AI 确实在改变软件系统的交互方式、开发方式和信息处理方式，但它没有改变“工程需要严谨”这件事。

真正务实的 AI 工程师，不会把大模型当成无所不能的神器，而是会去定义边界、设计流程、建立评测、做好兜底。RAG 解决知识来源问题，Agent 解决操作能力问题，评测和治理体系解决稳定性和安全问题。想清楚了这些，AI 才能在你的项目里真正产生价值。

下一步建议你动手做两件事：

1. 把文中的 RAG 示例跑通，替换成你自己的文档；
2. 给项目里一个高频问题写一份评测集，跑一次“模型回答准确率”的基线数据。

当你亲自跑完整个流程，你对“AI 到底改变了什么、没有改变什么”的判断，会比任何观点文章都更准确。