企业官网建设流程全解析

1. 背景：当“会不会被 AI 替代”成为日常焦虑

最近在程序员社区（包括 Hacker News 这类技术论坛）里，一个话题反复被讨论：AI 时代，开发者如何保持自己的市场价值？

这个问题不是空穴来风。过去一年，AI 编程助手从“能补全代码”进化到“能理解整个仓库的上下文并生成跨文件改动”，大模型可以完成基础的代码生成、单元测试撰写、SQL 查询编写，甚至能根据一张截图生成前端页面。于是很多开发者开始产生两个极端想法：

• 一端是焦虑派：“既然 AI 都能写代码了，初级开发岗位会不会消失？”
• 另一端是乐观派：“AI 只是工具，掌握提示词就能躺赢。”

从我做技术落地和工程实践的观察来看，这两种想法都有问题。焦虑派低估了软件工程的复杂度，乐观派低估了工具化落地的门槛。AI 时代真正有价值的开发者，不是和 AI 比拼代码生成速度的人，而是能定义问题、拆解需求、评估结果、兜底错误的人。

这篇文章不打算贩卖焦虑，也不打算吹捧“AI 万能论”。我会从能力模型、技术栈选择、工程实践、常见误区几条线展开，整理一套在 AI 时代保持市场竞争力、可落地执行的思路。无论你是后端、测试、前端还是算法工程师，都能在其中找到自己的生态位。

2. 环境与能力准备：先盘点你的“AI 时代基本盘”

在讨论“学什么新技术”之前，先做一次能力盘点。很多人在 AI 时代感觉迷茫，不是因为新东西太多，而是因为不知道自己已经拥有哪些可迁移的能力。

2.1 基础工程能力依然是底盘

AI 再强，也需要运行在真实的工程环境里。以下这几项基础能力，在 AI 时代不仅没有贬值，反而变得更加重要：

• 代码阅读与调试能力：AI 生成的代码可能风格优美，但逻辑有隐性缺陷。你需要能读懂、能调试、能修正。
• 数据结构与算法：当 AI 帮你写出 O(n²) 的代码时，你需要能判断它该不该被优化。
• 数据库与事务思维：AI 可以帮你写 SQL，但不会帮你理解索引、锁、事务隔离级别对业务的影响。
• 基础网络与安全知识：AI 生成的接口代码可能没有鉴权、没有参数校验、存在注入风险。最终把关的还是人。

我见过不少新人，把大量时间花在“研究提示词技巧”上，反而忽略了基本功。这其实是本末倒置。提示词技巧的衰退周期非常快，而基础工程能力的半衰期是以十年计的。

2.2 工具链准备

在动手实践 AI 应用开发之前，建议先准备好下面的环境。不同项目的版本差异较大，重点理解思路，再按实际情况调整：

如果你所在的公司已有统一的 AI 平台或网关，优先使用公司内部的模型服务，这样可以避免数据出境和合规风险。个人学习则可以使用云厂商的模型 API 或者本地部署的小参数模型。

3. 核心能力拆解：AI 时代技术人需要掌握的 6 项硬技能

下面这六项技能，是我认为 AI 时代技术人最值得投入的方向。它们之间互相交叉，但侧重点不同。

3.1 AI 应用开发：从“调用 API”到“设计 AI 功能”

AI 应用开发不是简单地用openai.ChatCompletion.create()调一次接口就完事，而是需要你以“功能设计”的视角，思考：

• 用户的真实问题是什么？这些问题适合用大模型解决吗？
• 模型输出不稳定的情况下，如何设计兜底策略？
• 需要给模型多少上下文？哪些信息应该通过检索注入？
• 模型返回的结果如何和后端业务逻辑、数据库状态联动？

举一个最简单的例子：为一个客服系统增加“智能摘要”功能。初级做法是直接把历史工单文本塞给模型，让它生成摘要。但工程化做法会考虑：

• 工单文本过长，超出模型上下文窗口怎么办？
• 工单中包含用户隐私信息，能不能直接发送给模型服务？
• 摘要结果需要保存吗？保存在哪里？
• 模型超时了，是重试还是降级为抽取第一段文本？

这些问题，不是提示词能解决的，而是典型的工程问题。

# 文件路径：ai_summary_service.py # 示例思路：对长文本进行分块摘要合并，避免超出上下文窗口 def summarize_long_text(text: str, chunk_size: int = 2000) -> str: # 1. 判断长度，如果短文本直接返回 if len(text) <= chunk_size: return call_llm_summary(text) # 2. 长文本分块 chunks = [text[i:i+chunk_size] for i in range(0, len(text), chunk_size)] # 3. 每块单独摘要 chunk_summaries = [call_llm_summary(chunk) for chunk in chunks] # 4. 合并摘要并做二次摘要 merged = "\n".join(chunk_summaries) return call_llm_summary(merged)

上面这段代码的核心思路是：不要把模型的上下文窗口当作无限大，而是通过分治策略，把大任务拆解成模型能够处理的小任务。这个思路适用于很多 AI 应用场景。

当然，这只是一个演示片段。生产环境里你还需要加入超时控制、异常捕获、结果校验等逻辑。

3.2 提示词工程：不是“咒语”，而是“需求结构化”

提示词工程这两年被严重神化。很多人以为学会几个模板就能成为 AI 时代的赢家。实际上，提示词工程本质上是一种需求分析方法论：你如何把一个模糊的诉求，转变成模型能够理解并执行的结构化指令。

我认为值得掌握的提示词设计模式有三个：

模式一：角色 + 任务 + 约束 + 输出格式

你是一名资深 Java 开发工程师。 请审查下面的代码，指出潜在的内存泄漏风险。 约束：只列出风险点，不重写代码。 输出格式：Markdown 无序列表，每个风险点附上严重程度（高/中/低）。

模式二：示例驱动（Few-shot）

对于格式要求严格的任务（比如从文本中提取结构化信息），给出 2-3 个输入输出示例，效果通常比空泛的“请提取实体”要好得多。

模式三：思维链（Chain of Thought）

对于需要多步推理的任务（比如数学应用题、SQL 生成），让模型“先分析，再作答”往往能显著提升准确率。在提示词中加上“请先逐步思考，再给出最终答案”就属于一种简单的思维链引导。

这里要特别提醒：提示词属于强实践、强领域相关的知识，不同模型的提示词敏感度差异很大。同一个提示词在 GPT 上效果好，在国产模型上未必效果一致。方法论可以迁移，具体的模板需要你自己在测试集中反复调优。

3.3 RAG：让模型接入你的私有知识库

RAG（Retrieval-Augmented Generation，检索增强生成）是目前企业落地 AI 应用最主流的方式。它的核心思想是：在模型回答问题之前，先从企业知识库中检索相关内容，把检索结果作为上下文“喂”给模型，让模型基于真实资料生成答案。

RAG 的意义在于解决两个核心问题：

1. 大模型的训练数据有截止时间，不知道企业内部的实时信息。
2. 大模型在专业领域会产生“一本正经地胡说八道”（幻觉），需要限定答案范围。

RAG 的基本流程可以拆成五个步骤：

1. 文档加载：读取 PDF、Word、Markdown 等格式。
2. 文本分块：按固定长度或语义边界，把文档切成若干 chunk。
3. 向量化：把每个 chunk 通过 Embedding 模型转成向量。
4. 向量存储：写入向量数据库。
5. 检索生成：用户提问时，把问题向量化，在向量库中检索相似 chunk，拼接后交给大模型生成回答。

这个流程看起来不复杂，但每一步都有工程细节。比如文本分块的分块大小会影响检索精度，分块太小导致上下文缺失，分块太大导致向量检索不精准。向量数据库的选择涉及性能、运维复杂度、成本等多方面因素。

我建议每个做 AI 应用开发的开发者，都手动实现一遍 RAG 的完整流程。不是为了重复造轮子，而是为了理解每一步的输入输出和潜在瓶颈。

3.4 理解 AI Agent：从“问答”到“行动”

如果说 RAG 解决的是“让模型知道更多”的问题，那么 AI Agent（智能体）解决的是“让模型做更多事情”的问题。

一个简单的 Agent 至少包含以下要素：

• 大模型作为决策核心：理解用户意图，决定下一步动作。
• 工具集（Tools）：比如搜索、计算器、发送 HTTP 请求、操作数据库、执行代码。
• 循环机制：模型决定调用哪个工具 -> 工具返回结果 -> 模型根据结果决定下一步 -> 直到任务完成。

从工程视角看，Agent 开发的难度不在于让模型说出“我要调用工具”，而在于：

• 如何定义清晰、稳定的工具描述（Tool Schema）？
• 如何进行多轮工具调用的状态管理？
• 如何限制 Agent 的权限边界，防止它执行危险操作？
• 如何设置最大迭代次数，避免 Agent 陷入死循环？

比如下面这个极简示例展示了一个“查询订单并支持退款申请”的 Agent 思路：

{ "tools": [ { "type": "function", "function": { "name": "query_order", "description": "根据订单号查询订单状态和金额", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号" } }, "required": ["order_id"] } } }, { "type": "function", "function": { "name": "apply_refund", "description": "为指定订单提交退款申请，该操作不可逆", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号" } }, "required": ["order_id"] } } } ] }

这段 JSON 的作用是：向模型声明“我可以调用哪些函数”，以及“每个函数的参数结构是什么”。模型本身不执行函数，它只负责生成一个“调用请求”，真正执行业务逻辑的是你的后端代码。

在实际项目中，apply_refund这类敏感操作必须加权限校验、二次确认、操作日志，不能因为模型说“可以”就执行。

3.5 AI 模型部署与推理优化：从开发到上线

很多开发者会写 AI 应用，但一提到部署就头疼。这里说的“AI 模型部署”分两种情况：

• 使用厂商 API：不需要自己部署模型，只需要关注 API 网关、限流、成本控制。
• 私有化部署开源模型：需要用 vLLM、TGI 等推理框架，或者通过 Ollama 在本地运行小模型。

对于大多数业务团队，我建议优先考虑使用 API 的方式，因为模型迭代速度太快，自己部署一个开源模型，没过多久可能就落后了。但在以下场景，私有化部署是必要的：

• 数据敏感，不允许出域。
• 需要完全自定义模型行为，微调成本可控。
• 离线环境，无法访问公网 API。

如果你负责模型的私有化部署，需要关注：

• 显存与吞吐量：模型参数量不是唯一指标，通过量化（如 INT8、INT4）可以在降低显存占用的同时提升吞吐量，但会引入一定精度损失。
• 并发与排队：多个业务方共用模型服务时，需要设计排队策略和优先级。
• 监控与告警：记录推理延迟、输入输出 token 数、错误率。

3.6 AI 编程提效：把工具用成杠杆

AI 编程助手已经成了很多开发者的日常伙伴。但同样是用 AI 编程，不同人的效率差异巨大。关键差别在于：

会用的人，把 AI 当结对编程伙伴；不会用的人，把 AI 当搜索引擎。

高效使用 AI 编程工具的几个建议：

• 先想后问：在要求 AI 生成代码之前，先用自己的语言描述清楚问题、输入、输出和约束。
• 让 AI 解释代码而不是生成代码：遇到不熟悉的开源库，让 AI 逐段解释现有代码，比直接问“怎么写”更有价值。
• 用 AI 生成测试用例：让 AI 为你的核心函数生成边界测试，然后人工补充遗漏。
• 不要把 AI 的输出直接粘贴到生产环境：再好的代码生成工具也需要代码 review。

4. 实战案例：从零构建一个企业文档问答助手

下面用一到两个实战案例，把前面提到的 RAG、提示词工程、AI 应用开发串联起来。这个项目的目标是：输入一批企业内部的 Markdown 文档，用户可以针对文档内容提问，回答必须基于文档而非模型臆想。

4.1 项目结构设计

doc-qa/ ├── app.py # FastAPI 入口 ├── ingest.py # 文档导入与向量化 ├── retriever.py # 检索逻辑 ├── embeddings.py # Embedding 模型封装 ├── config.py # 配置项 ├── docs/ # 存放原始文档 └── requirements.txt # 依赖清单

4.2 核心流程

先看文档导入阶段。这里把文档按 Markdown 标题和段落拆分成块（chunk），并对每个 chunk 生成 embedding 向量。

# 文件路径：ingest.py # 说明：示例使用伪代码风格，需结合具体向量库 SDK 调整 from pathlib import Path from typing import List def split_markdown_by_heading(file_path: str) -> List[str]: """按一级标题和二级标题拆分 Markdown 文档，保持语义完整性。""" content = Path(file_path).read_text(encoding="utf-8") chunks = [] current_chunk = [] for line in content.splitlines(): # 遇到新的二级标题时，把前面的内容作为一个 chunk if line.startswith("## ") and current_chunk: chunks.append("\n".join(current_chunk)) current_chunk = [] current_chunk.append(line) if current_chunk: chunks.append("\n".join(current_chunk)) return chunks

这个简单的分块策略，比单纯的“按固定字符数切分”更能保留语义边界。实际的 RAG 项目中，分块策略的设计往往决定了检索质量的上限。

接下来是检索与生成阶段。用户提问时，系统需要把问题向量化，然后到向量库中检索相似内容，最后把检索结果和问题一起拼接给大模型。

# 文件路径：retriever.py # 说明：展示检索 + 增强生成的核心思路 def ask(question: str, k: int = 3) -> str: # 1. 问题向量化 question_vector = embedding_model.encode(question) # 2. 向量库相似度检索 related_chunks = vector_store.search(question_vector, top_k=k) # 3. 构建增强上下文 context = "\n\n".join(related_chunks) # 4. 构造提示词 prompt = f"""请基于以下资料回答问题。 如果资料中没有相关信息，请直接回答“资料中未找到相关内容”，不要编造。 资料： {context} 问题：{question} """ # 5. 调用大模型生成回答 response = call_llm(prompt) return response

这里的提示词设计有一个关键点：显式告诉模型“资料中没有就如实回答”。这个约束可以有效降低幻觉问题，但也要求检索质量足够高，否则用户问的问题明明存在，却因为检索不到而回答“未找到”，体验反而更差。

4.3 接入 Web 服务

为了让这个问答助手可以被前端页面或聊天工具调用，用 FastAPI 包一层 HTTP 接口非常方便。

# 文件路径：app.py from fastapi import FastAPI from pydantic import BaseModel import retriever app = FastAPI() class QueryRequest(BaseModel): question: str class QueryResponse(BaseModel): answer: str @app.post("/ask", response_model=QueryResponse) def ask_question(req: QueryRequest): answer = retriever.ask(req.question) return QueryResponse(answer=answer)

这样一个最小可运行的文档问答服务就完成了。你可以把它扩展为内部 Wiki 机器人、客服辅助系统、运维故障知识库等等。

4.4 运行验证

启动服务后，可以用curl做一次冒烟测试：

curl -X POST http://localhost:8000/ask \ -H "Content-Type: application/json" \ -d '{"question": "设备的保养周期是多少？"}'

预期返回：

{"answer": "根据资料显示，设备的保养周期为每三个月一次，具体步骤见第三章。"}

需要注意的是，不同的 embedding 模型、不同的向量库、不同的大模型服务，都会影响最终效果。上述代码更像是一个“脚手架”，需要替换成你实际使用的 SDK。

5. 常见问题与排查思路

在学习和落地 AI 应用的过程中，开发者容易踩到一些共性坑。下面整理成一份排查速查表：

在团队落地 AI 功能时，非常建议建立一套评估集（Eval Set）。准备几十条包含标准答案的测试问题，每次修改提示词、调整检索参数后，都跑一遍评估集，对比回答准确率。没有评估集的提示词调优，本质上就是玄学调参。

6. 最佳实践与工程化建议

6.1 代码与工程规范

• 结构化 AI 调用层：不要在每个业务代码里直接写模型 API 调用，封装一个独立的llm_client或AiService，统一处理 API Key、超时、重试、日志。
• 结果校验：模型返回的内容不能直接信任。对 JSON 格式输出要做解析校验和容错，必要时让模型输出后，再用代码做二次清洗。
• 可观测性：记录每次模型调用的输入、输出、token 消耗、耗时。这样出了问题可以回溯，同时还能做成本分析。
• 配置管理：模型名称、温度参数、最大 token 数、prompt 模板，都应该放入配置文件或配置中心，而不是硬编码在代码里。

6.2 数据安全与合规边界

这是所有 AI 应用开发中不可忽视的一条。

• 只向模型服务发送“完成任务所必需的最小数据”。
• 涉及个人隐私、商业机密的字段，脱敏后再传递。
• 严格遵循公司内部的 AI 使用规范和数据出境审查。
• 在测试环境中充分验证；生产环境的变更需要走评审、备份和回滚流程。

6.3 成本控制

AI 应用的边际成本比传统应用高得多。每一次模型调用都在花钱。以下几点可以有效控制成本：

• 缓存复用：对于相同或相似的问题，在缓存层命中后直接返回结果，不重复调用模型。
• 模型分级：简单任务用轻量模型，复杂任务才用大模型。
• 精简上下文：不要把所有历史记录都塞进上下文，做摘要或裁剪。
• 设置配额：为每个业务方设置 token 配额和告警阈值。

6.4 持续学习的策略

AI 技术迭代速度极快，与其追逐每一个新模型，不如关注不变的方法论：

• 每周：花时间阅读自己所在领域的大厂技术博客，了解 AI 工程实践的新趋势。
• 每月：亲手完成一个小的 AI 项目，比如做一个 Agent、做一个 RAG 应用。
• 每季度：复盘自己在用的 AI 工具，审视它们是否真的提升了效率。

7. 学习路线：AI 时代开发者如何循序渐进

最后，给出一条相对稳健的学习路线。不管你是后端、前端、测试还是运维，都可以参考这个顺序：

第一阶段：会用（1-2 周）

• 熟练使用一个 AI 编程助手，把它融入自己的开发流程。
• 学会阅读 AI 生成的代码，能判断其正确性。
• 掌握与模型高效对话的基础沟通原则。

第二阶段：能调（2-4 周）

• 调用大模型的 API 完成一个简单功能。
• 理解 token、temperature、system prompt 等基础概念。
• 完成一个包含提示词设计和异常处理的完整功能模块。

第三阶段：能应用（1-2 个月）

• 实现一个完整的 RAG 问答应用。
• 理解文本分块、向量检索、重排的基本原理。
• 尝试给班级或团队做一个内部知识的机器人，收集反馈并迭代。

第四阶段：能工程化（3 个月以上）

• 掌握 AI Agent 的开发模式，了解工具调用和循环机制。
• 关注模型评测、成本控制、安全和合规问题。
• 在自己负责的业务中，找到 1-2 个可以落地 AI 的场景，做出一个对团队有用的小工具。

回头看“如何保持市场价值”这个问题，我的答案其实很简单：不要把自己定位成“会写代码的人”，而是把自己定位成“能用 AI 解决业务问题的人”。

代码生成的下限已经被 AI 拉高了，但业务理解、系统设计、工程稳定性、数据安全意识、沟通协作能力，这些仍然是人类开发者不可替代的核心竞争壁垒。保持竞争力的方法，不是恐惧 AI，而是把它当成杠杆，把时间花在更高价值的思考和决策上。

如果你能亲手完成一个 AI 应用，从设计到上线都走一遍，那种“AI 也不过如此”的失控感就会慢慢消失，取而代之的是掌控感。希望这篇文章能帮你在 AI 时代找到一个清晰的方向。