企业官网建设流程全解析

1. 从“写代码”到“说代码”：AI大模型工程师的速成逻辑

计算机专业这两年最明显的变化，不是某个框架又更新了，而是“写代码”这件事本身正在被重新定义。以前我们讲一个工程师的成长路径，基本是：学语言、刷算法、做项目、背八股、进大厂拧螺丝。现在这条路径还在，但旁边多出来一条岔路——你不需要把每一行代码都亲手敲出来，而是用自然语言把意图描述清楚，让大模型帮你把代码生成、补全、重构、调试。这就是标题里说的“用嘴编程”，也是Vibe Coding最直白的解释。

所谓 Vibe Coding，不是让你彻底躺平不写代码，而是把工作重心从“语法记忆”和“机械敲击”转移到“意图表达”和“结果校验”上。你依然要懂数据结构、懂算法复杂度、懂系统设计，但你不必再为记不住某个 API 的参数顺序而抓耳挠腮。Claude Code、OpenCode、Codex这类工具的出现，本质上是把“编程”这个动作拆成了两层：上层是人和模型的对话，下层是模型和编译器的对话。你要做的是把上层说清楚，下层交给工具。

这套玩法适合谁？我观察下来有三类人收益最大。第一类是计算机专业在校生，尤其是大三、大四面临就业压力的同学，你们有理论基础但缺工程经验，AI 工具能帮你快速把课本知识变成可运行的项目。第二类是转行过来的开发者，比如从测试、运维、数据分析想往 AI 方向靠，你们有编程底子但没系统学过深度学习，大模型能帮你补齐知识盲区。第三类是在职工程师，想用 AI 提效但不知道怎么下手，你们需要的是工作流改造而不是从零学起。

但这里有个误区必须先说清楚：速成不等于速朽。市面上很多“七天成为 AI 工程师”的课程，教的是调包和跑 demo，一旦遇到真实业务场景就露馅。我理解的速成，是借助 AI 工具把学习曲线压平，让你在三个月内达到能独立承接中小型 AI 应用开发的程度，而不是三天背完 Transformer 结构图。这个区别很关键，因为它决定了你后面是“会用工具的人”还是“被工具替代的人”。

2. 工具链选型：Claude Code、OpenCode、Codex 到底怎么选

2.1 三类工具的定位差异

很多人一上来就问“哪个工具最好”，这个问题本身就不对。Claude Code、OpenCode、Codex 虽然都叫 AI 编程工具，但它们的切入点和适用场景差别很大。我按自己的使用体验拆一下。

Claude Code 的强项在于长上下文理解和多文件重构。你给它一个几百行的模块，让它帮你拆分函数、提取公共逻辑、补充类型注解，它做得非常稳。我试过把一个两千行的数据处理脚本丢给它，要求按职责拆成五个文件并保持接口兼容，它给出的方案基本可以直接用。缺点是它对项目整体结构的感知依赖你提供的上下文，如果你不告诉它目录结构，它容易“只见树木不见森林”。

OpenCode 这类开源方案的优势是可定制和可私有化。你可以把它接在自己的模型服务上，也可以改它的提示词模板和工具调用逻辑。对于想深入理解 AI 编程工具内部机制的人来说，读它的源码比看十篇教程都有用。但代价是配置成本高，你得自己处理模型接入、上下文管理、工具注册这些事。我建议有一定工程基础的人再碰，纯新手先用现成的。

Codex 系工具的特点是补全体验顺滑。它在编辑器里的行级、块级补全做得非常自然，你写着写着它就猜到你下一步要干什么。适合日常编码时作为“副驾驶”使用，尤其是写重复性高的 CRUD 代码或者单元测试时，效率提升很明显。但如果你指望它帮你从零设计一个系统架构，它会让你失望。

2.2 选型决策表

2.3 我的组合用法

实际工作中我不会只用一个。我的习惯是：架构设计阶段用对话式工具，把需求拆成模块和接口，让它帮我画草图（文字描述即可）；编码阶段用编辑器内补全工具，边写边补，保持心流；重构和 review 阶段用 Claude Code 类工具，让它从全局视角找问题。这三者不冲突，反而互补。

有个细节值得说：不同工具对“提示词”的敏感度不一样。Claude Code 类工具喜欢你把约束条件写清楚，比如“不要引入新依赖”“保持函数签名不变”“错误处理用 try-catch 包裹”。Codex 类工具则更依赖你当前光标附近的代码风格，你写得越规范，它补得越准。OpenCode 类工具则完全取决于你怎么配置系统提示词，配置得好它就是专属助手，配置得差它就是人工智障。

3. 从零搭建 AI 开发工作流：环境、配置与第一个实战项目

3.1 基础环境准备

不管你选哪个工具，有几样东西是绕不开的。首先是Python 环境，建议用 3.10 或 3.11，太新的版本有些库还没适配，太旧的版本缺少类型语法支持。用 conda 或者 venv 都行，我习惯用 conda 因为切换方便。其次是Node.js，很多 AI 工具的 CLI 是基于 Node 写的，装个 LTS 版本就行。然后是Git，这个不用多说，版本控制是底线。

配置方面，如果你用的是需要 API 的工具，记得把密钥放在环境变量里，别硬编码在代码里。我见过太多人把密钥提交到公开仓库然后被刷爆额度的案例。用.env文件加python-dotenv或者dotenv加载，简单又安全。

# 创建环境 conda create -n ai-dev python=3.11 conda activate ai-dev # 安装常用依赖 pip install openai anthropic python-dotenv requests

3.2 第一个实战项目：智能文档问答助手

我建议每个刚入门的人先做这个项目，因为它覆盖了 AI 应用开发的核心链路：数据加载、文本切分、向量化、检索、生成。做完这个，你对 RAG（检索增强生成）的理解就不是纸上谈兵了。

第一步，准备数据。找几篇你熟悉的 PDF 或者 Markdown 文档，放在data/目录下。别一上来就搞几百兆的语料，先拿几篇跑通流程。

第二步，文本切分。这是最容易被忽视但最影响效果的环节。切得太碎，语义不完整；切得太大，检索精度下降。我的经验是中文按 300 到 500 字切，英文按 500 到 800 词切，相邻块之间留 10% 到 20% 的重叠。用 LangChain 的RecursiveCharacterTextSplitter就行，别自己手写。

from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=400, chunk_overlap=80, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) chunks = splitter.split_text(raw_text)

第三步，向量化和存储。小规模数据用 FAISS 或者 Chroma 就够了，别一上来就上 Milvus 或者 Pinecone，那是给生产环境用的。嵌入模型选中文效果好的，比如text-embedding-3-small或者开源的bge-small-zh。

第四步，检索和生成。用户提问后，先把问题向量化，然后从向量库找最相似的 top-k 个块，拼成上下文丢给大模型生成回答。这里有个技巧：在提示词里明确要求模型“只根据提供的上下文回答，不知道就说不知道”，能大幅减少幻觉。

prompt = f"""根据以下上下文回答问题，不要编造信息。 如果上下文没有相关内容，直接说“文档中未提及”。 上下文： {context} 问题：{question} 回答："""

3.3 用 Vibe Coding 方式开发这个项目

上面这些代码，你完全可以让 AI 工具帮你写。我的做法是：先自己把架构想清楚，然后用自然语言描述给工具，让它生成骨架代码，我再逐段 review 和调整。比如我会说：“帮我写一个基于 LangChain 的文档问答脚本，要求支持 PDF 和 Markdown 加载，用 FAISS 做向量存储，嵌入模型用 OpenAI 的 text-embedding-3-small，生成模型用 gpt-4o-mini，代码要分模块，有错误处理。”

工具生成的代码通常有 70% 可以直接用，剩下 30% 需要你根据实际情况调整，比如路径、模型名称、参数。这个比例很关键，它意味着你依然要懂代码，只是不用从零敲。如果你连生成的代码都看不懂，那说明基础还没打牢，先去补 Python 和 LangChain 的基本概念。

4. 提示词工程：让模型听懂人话的核心技能

4.1 提示词不是玄学，是结构化表达

很多人把提示词工程说得神乎其神，其实核心就一句话：把模型当成一个聪明但缺乏背景信息的新同事，你需要把任务、约束、示例、输出格式都说清楚。我总结了一个四要素框架，实测下来比网上那些花里胡哨的模板管用。

角色设定：告诉模型它是什么身份。比如“你是一个资深 Python 后端工程师”“你是一个擅长给初学者解释概念的导师”。角色会影响模型的用词风格和思考角度。

任务描述：具体要它做什么。别写“帮我优化代码”，要写“帮我优化这段代码的时间复杂度，目标是从 O(n²) 降到 O(n log n)，保持函数签名不变”。

约束条件：什么能做，什么不能做。比如“不要引入新的第三方库”“输出必须是可运行的完整代码”“注释用中文”。

输出格式：你要什么形式的结果。比如“用 Markdown 表格对比”“先给结论再给理由”“代码块标注语言类型”。

4.2 常见提示词反模式

我踩过的坑里，下面这几种最典型。

反模式一：太笼统。“帮我写个爬虫”——爬什么？用什么库？要不要处理反爬？存哪里？模型只能猜，猜错了你还得返工。

反模式二：一次要求太多。把十个需求塞进一段话，模型顾此失彼。正确做法是分步对话，先让它做 A，确认后再做 B。

反模式三：没有示例。如果你要的输出格式比较特殊，给一个输入输出示例比描述一百句都管用。这叫 few-shot prompting，实测能大幅提升格式准确率。

反模式四：情绪化表达。“你怎么这么笨”“再写不对我就不用你了”——模型不会因此变聪明，反而可能因为上下文里的负面词汇影响生成质量。保持冷静、具体、可操作。

4.3 提示词迭代的实操方法

我习惯用“三轮迭代法”。第一轮，把需求写清楚，让模型生成初版。第二轮，针对初版的问题，指出具体哪里不对、期望是什么，让它改。第三轮，让它自己 review 一遍，找出潜在问题并修复。三轮下来，大部分任务都能达到可用状态。

有个小技巧：让模型在生成代码前先输出它的思考过程。比如加一句“先分析需求，列出实现步骤，再写代码”。这样你能提前发现它的理解偏差，避免写完一大段才发现方向错了。

5. 就业导向：AI 大模型工程师的能力模型与面试准备

5.1 市场到底要什么样的人

我看了不少招聘信息，也跟做招聘的朋友聊过，目前 AI 大模型相关岗位大致分三类。第一类是算法岗，要求深度学习理论基础、论文复现能力、模型微调经验，门槛最高，通常要硕士以上。第二类是应用开发岗，要求会用大模型 API、懂 RAG、懂 Agent 框架、能独立做项目，这是计算机专业本科生最容易切入的方向。第三类是工具链和平台岗，要求懂推理优化、部署、监控，偏工程侧。

对于“速成”目标来说，应用开发岗是最现实的切入点。你不需要推导反向传播，但你要知道怎么把模型能力封装成产品。这个岗位的面试，考的不是你背了多少公式，而是你有没有真正做过东西。

5.2 面试常考问题与回答思路

我整理了几个高频问题，附上我的回答思路。

问题一：介绍一下你做过的最有挑战的 AI 项目。别背项目描述，讲清楚三件事：遇到什么问题、你做了什么决策、结果如何量化。比如“文档问答项目里，检索准确率只有 60%，我分析了 bad case 发现是切分粒度太粗，调整 chunk_size 从 800 降到 400 并增加重叠后，准确率提到 82%”。

问题二：RAG 的局限性是什么，你怎么解决？这题考的是你有没有深入思考。RAG 的局限包括：检索不到、检索到但不相关、上下文太长导致模型忽略中间信息。对应方案：混合检索（关键词+向量）、重排序、上下文压缩。

问题三：你怎么评估一个 AI 应用的效果？别只说“感觉还行”。要讲指标：检索用 recall@k 和 MRR，生成用 BLEU、ROUGE 或者人工评分，端到端用任务完成率。有数据支撑的回答才有说服力。

问题四：提示词工程和微调怎么选？我的回答框架是：先试提示词，成本低、迭代快；提示词到瓶颈了再考虑微调；微调需要标注数据，成本高，但能解决风格和格式的稳定性问题。两者不是互斥，可以结合。

5.3 作品集比证书管用

我强烈建议每个想入行的人建一个 GitHub 仓库，放三到五个项目。不用多复杂，但要体现你的思考过程。README 里写清楚：项目背景、技术选型理由、遇到的坑、怎么解决的、效果数据。面试官看你的仓库，比看你的简历更能判断你的真实水平。

项目选择上，我建议覆盖这几个方向：一个 RAG 应用（文档问答或知识库）、一个 Agent 应用（比如自动处理邮件的助手）、一个微调实验（用 LoRA 微调一个小模型做分类或生成）。这三个做完，你对 AI 应用开发的全链路就有体感了。

6. 实操避坑：我踩过的那些坑和解决方案

6.1 上下文管理是最大的坑

用 AI 工具写代码，最容易出问题的地方不是模型能力，而是上下文管理。你聊得越久，上下文越长，模型越容易“忘记”前面的约定。我遇到过让模型保持某个接口不变，聊了二十轮之后它自作主张改了参数名的情况。

解决方案有两个。一是定期开新会话，把关键约定重新贴一遍。二是把约定写进项目配置文件，比如 Claude Code 支持CLAUDE.md，你可以在里面写清楚项目规范、代码风格、禁止事项，每次会话它都会读取。这个技巧能省很多重复沟通。

6.2 别让模型替你做大决策

模型很擅长执行明确任务，但不擅长做模糊决策。比如“帮我选一个向量数据库”，它会给你列一堆优缺点，但最终选哪个得你自己判断，因为只有你知道数据规模、预算、团队技术栈。我的原则是：模型做执行，人做决策。你可以让它帮你分析选项，但拍板必须自己来。

6.3 代码 review 不能省

AI 生成的代码有个特点：看起来对，跑起来也可能对，但边界情况容易漏。我见过生成的函数没处理空输入、没处理网络超时、没考虑并发。所以我的习惯是，AI 生成的每一段代码，我都要过一遍，重点看错误处理、边界条件、资源释放。这个时间不能省，省了后面调试花的时间更多。

6.4 常见问题速查表

6.5 一个真实踩坑记录

有次我用 AI 工具写一个数据清洗脚本，需求是“去掉重复行，保留最新的一条”。模型生成的代码用drop_duplicates默认保留第一条，我 review 时没注意，跑完发现保留的是旧数据。后来我在提示词里加了“保留时间戳最大的那条”，并让它先输出逻辑说明再写代码，才避免类似问题。这个教训是：涉及业务逻辑的地方，一定要让模型先解释它的理解，确认无误再生成代码。

7. 持续进阶：从会用工具到理解原理

7.1 别停在调包层面

工具用熟了之后，一定要往下挖一层。比如你用 LangChain 做 RAG，那就去看看它的RetrievalQA内部是怎么拼提示词的，VectorStore的相似度计算用的是什么距离度量。你用 Agent 框架，就去看看它的 ReAct 循环是怎么实现的，工具调用是怎么解析的。这些原理性的东西，决定了你在遇到问题时能不能自己修，而不是只能等社区更新。

7.2 读源码的正确姿势

我的经验是带着问题读。比如你想知道“为什么我的 RAG 检索不准”，那就去读检索模块的源码，看它默认的 top-k 是多少、相似度阈值怎么设、有没有做重排序。带着具体问题读源码，比从头到尾啃效率高十倍。读的时候做笔记，把关键类和方法的调用关系画出来（文字描述即可），下次遇到类似问题直接查笔记。

7.3 关注模型能力边界

大模型不是万能的，它有明确的能力边界。它不擅长精确计算，你别让它算账；它不擅长实时信息，你别问它今天的新闻；它不擅长长程推理，你别让它一步到位解决复杂数学题。了解这些边界，你就能在设计系统时把任务分配给合适的组件，而不是硬塞给模型。

7.4 建立自己的知识库

我有个习惯，每次解决一个非平凡的问题，就写一篇简短的笔记，记录问题现象、排查过程、最终方案。半年下来攒了几十篇，现在遇到类似问题直接搜自己的笔记，比搜索引擎还快。这个习惯对 AI 领域尤其重要，因为技术更新太快，今天踩的坑明天可能换个形式又出现。

8. 一些掏心窝子的经验

我刚开始用 AI 工具写代码时，有过一段“过度依赖”的时期，什么都让模型生成，自己不动脑。结果就是遇到稍微复杂一点的问题就卡壳，因为我不知道模型为什么这么写，也不知道怎么改。后来我调整了策略：简单任务让模型做，复杂任务自己先想清楚再让模型辅助。这个转变让我的效率反而更高了，因为返工少了。

还有一点，别把 AI 工具当成替代学习的借口。你可以用它加速学习，但不能跳过学习。数据结构、算法、操作系统、网络这些基础，该补还得补。模型能帮你写代码，但不能帮你在面试中解释为什么用红黑树而不是哈希表。基础扎实的人用 AI 工具是如虎添翼，基础薄弱的人用 AI 工具是空中楼阁。

最后分享一个我最近在用的技巧：让模型扮演面试官来考你。比如“你是一个 AI 应用开发岗位的面试官，针对 RAG 和 Agent 方向，问我十个由浅入深的问题，我回答后你点评”。这个用法比单纯刷题有意思，因为模型会根据你的回答追问，模拟真实面试的压迫感。我试了几轮，发现了一些自己以为懂但其实没懂的知识点，挺有用的。