企业官网建设流程全解析

过去半年，我陆续把团队的AI项目从"跑通Demo"推进到"线上稳定运行"，中间踩过的坑，比过去五年做传统后端加起来都多。每次和人聊起"AI工程"这个词，我发现大家基本分成两派：一派觉得它就是个营销概念，把Prompt包装成工程；另一派觉得它高不可攀，好像得先读完全部机器学习论文才能动手。今天想借这个"ai-engineering-from-scratch"的话题，把这段从零开始的真实经历摊开讲讲，包括我自己对Harness Engineering、Loop Engineering这些新词的理解，以及普通人如何一步步构建自己的AI工程能力。

先给个结论：AI工程不是把模型跑通，而是在模型输出天然不确定的前提下，设计一套系统让它稳定产出业务价值。它和传统软件工程最大的不同，在于"需求—设计—实现—测试"的线性流程失效了，你需要换成"设计—试验—观察—加固"的螺旋循环。这篇文章适合两类人：一类是刚接触AI开发、想系统构建知识体系的初学者；另一类是已经在用API写业务代码、但经常被模型输出搞到崩溃的开发者。下面我会从最底层的Prompt能力一路讲到Agent协作，尽量把每个环节的原理、代码和坑都讲透。

1. 先搞清楚：AI工程到底在工程化什么

1.1 从"调接口"到"构建系统"：我们对AI工程的误解

很多人觉得AI工程就是调用大模型的API，把OpenAI或者国产模型的SDK装好，传几句提示词，解析一下返回结果，这不就是一个工程了吗？真这么想，上线不到一周就会被用户骂回来。为什么？因为单个接口调用只是零件，工程化是把零件组装成有容错、有监控、有迭代闭环的系统。

举个例子。我最早给内部工具写过一个"自动总结会议纪要"的功能，第一版代码极其简单：把会议录音转文字，然后把文字扔给模型，让它输出摘要，最后把摘要存到数据库。看起来天衣无缝，实际跑起来问题一箩筐：有时候模型输出一大堆废话，有时候摘要里混入幻觉信息，有时候格式不是纯文本而是Markdown，前端渲染直接崩。这些问题都不是"模型不好"导致的，而是我根本没有考虑模型输出是一个概率分布，而不是一个确定性的JSON对象。

真正的AI工程，要处理的是不确定性。传统前端后端面对的是明确的输入输出，最多担心一下边界情况。AI工程要面对的是"同一个Prompt，模型今天可能给你A结果，明天给你B结果，换了温度参数又给你C结果"的随机性。所以工程化的第一步，不是写更多的代码，而是转变思维模式：把模型当成一个"极度聪明但经常说谎、偶尔发癫"的同事，你要做的事情不是信任他，而是给他一整套流程约束。

1.2 AI工程与传统软件工程、机器学习工程的分工

这张边界曾经也让我困惑了很久。软件工程处理确定逻辑，机器学习工程处理模型训练和部署，AI工程处理的则是"已经训练好的模型如何接入业务系统"。它横跨三者，但有自己独特的问题域。

我个人的体会是，AI工程在这个体系里更像是"翻译器"——把业务需求翻译成模型能理解的指令，再把模型输出翻译成业务能使用的数据。这个过程里，你最好既懂点软件工程（知道怎么设计接口、怎么处理并发），又懂点机器学习（至少知道温度、采样、上下文窗口是什么意思），更重要的是，你还要具备一种"跟随机性共事"的工程嗅觉。

2. 地基：Prompt Engineering可不只是写提示词

2.1 大模型的输出不确定性与可控性从哪里来

先说原理。大语言模型本质是一个概率函数：给定一段文本（token序列），它预测下一个token的概率分布。所谓"生成结果"，其实是反复从这个分布里采样。温度参数就是在采样时放大或缩小概率差距——温度越高，高概率token和低概率token之间的差距越小，输出就越随机。

这带来两个工程上必须接受的现实：第一，非确定性是模型的内在属性，不可能通过Ping一个"降温"参数彻底消除；第二，我们虽然不能百分之百控制输出，但可以通过改变输入的概率分布，把输出推向我们想要的方向。Prompt Engineering的核心，就是通过设计输入文本，改变模型内部的概率权重。

很多时候你觉得模型"理解"了你的话，其实它只是在高维空间里找到了一个与你文本相关的概率路径。这意味着，Prompt里的每个词语都在影响这个路径的走向。你写"请用专业的方式回答"，和写"请用初中生能听懂的话解释"，模型走的是完全不同的路径。这不是玄学，这是概率计算。

2.2 一套可复用的结构化Prompt模板

我自己从零开始摸索出来的Prompt结构，后来发现和很多开源项目的思路基本一致。给大家一个可以直接拿去用的模板框架，用Markdown组织未必是最好的，但比零散的一段话稳定得多：

# 角色 你是一位{角色定义}，擅长{领域}，具有{特质}。 # 任务背景 {描述当前场景，提供足够的上下文信息} # 用户目标 你要完成的具体任务是什么，用一句话说清楚。 # 输入数据 {用户提供的内容，或从系统读取的数据} # 输出要求 - 格式：{JSON / Markdown / 纯文本} - 结构：{需要哪些字段，用示例说明} - 风格：{正式/口语/简洁/详细} - 长度：{字数或行数限制} # 约束与禁区 - 不得编造数据 - 如果信息不足，请明确说"信息不足" - 必须使用繁体中文（或简体字） - 如果遇到法律问题，不要给具体建议 # 思维步骤 1. 先分析输入里的关键信息 2. 再对照输出要求规划结构 3. 最后生成内容

这个模板不是花架子。它解决的是"提示词原子化"的问题。一旦你养成了写结构化Prompt的习惯，就能把"上一段话下同一个指令"变成"在系统里维护几套不同场景的模板"，后续做Harness Engineering才有基础。

我强烈建议你把Prompt当作代码一样去管理：用版本控制，记录每个版本在测试集上的表现，不要用记事本存提示词。这个习惯会救你很多次——当线上效果变差时，你能快速回滚到上一个稳定版本，而不是对着聊天记录翻来覆去地回忆。

2.3 思维链与少样本示例的真正用法

思维链（Chain of Thought）这个词你可能听腻了，但我还是要说一个容易踩的误区：思维链不是让模型"把思考过程写出来"这么简单，它的真正作用是诱导模型把复杂问题分解成多个中间步骤，从而把"一步到位的概率估计"拆成"多个小步的概率连乘"，每一步的置信度都比直接输出答案更高。

实操中我的经验是：对于逻辑推理类任务，在Prompt里明确加上"先一步步分析，再给出答案"；对于数据提取类任务，最好在思维链之后再要求"以JSON格式输出"，这样既保留推理质量，又方便代码解析。

少样本示例（Few-shot）同样需要注意：示例不是越多越好，而是越代表真实输入分布越好。你给三个示例，实际上是在告诉模型"我期望的输出长这样"。如果示例本身质量不高，模型会学歪。我曾经试过给一组带明显偏见的示例，结果模型输出也跟着带偏，后来换了三个干净、典型、覆盖边界的示例，效果立刻回升。

3. 让AI"听话"的关键：Harness Engineering与Loop Engineering

3.1 Harness Engineering到底是什么意思

最近圈子里流行两个词，一个是Harness Engineering，一个是Loop Engineering。我第一次看到Harness的时候以为跟测试框架里的"测试夹具"有关，后来才理解它的核心含义：给模型加装一套"约束装置"，就像给马套上缰绳和鞍具，让它在预设轨道上跑，而不是漫山遍野地撒欢。

Harness Engineering研究的就是"如何设计这套约束装置"。它不是单指某个工具，而是一整套工程手法：

• 结构约束：通过Function Calling或JSON Schema约束输出格式。
• 内容约束：通过系统提示词和内容过滤规则限制主题范围。
• 流程约束：通过代码控制"模型必须在某个业务规则允许的范围内作答"。
• 外部上下文：通过RAG检索把知识边界锁死在你的数据源里。

我记得有人打过一个比方：大模型是一个超强但不懂规矩的新人，Harness就是给他准备的《员工手册》和审批流程。你当然可以不给他任何流程直接下命令，那他一定会自作主张地搞出一堆你不想看到的操作。有了Harness，他只能在授权范围内发挥聪明才智。

3.2 用代码构造内部脚手架：校验、重试、降级

Harness不是只在Prompt里做文章，很多时候要靠代码缝合。下面是我做的一个最小可用的内部Harness示例：用带格式约束的调用方式，让模型返回结构化数据，再在代码里做一次严格校验。这一步非常关键——永远不要把模型输出直接当业务数据使用，必须经过校验。

import json from pydantic import BaseModel, ValidationError from openai import OpenAI client = OpenAI() # 定义预期的输出结构 class MeetingSummary(BaseModel): title: str key_points: list[str] action_items: list[str] risk: str = "none" def summarize_meeting(transcript: str) -> MeetingSummary: prompt = f""" 你是会议纪要助手。请根据下面的会议转录生成结构化摘要。 输出必须是合法JSON，不要包含除JSON外的任何文字。 JSON的schema示例如下： {"title": "会议标题", "key_points": ["要点1", "要点2"], "action_items": ["行动项1"], "risk": "风险描述或none"} 转录原文： {transcript[:12000]} """ for attempt in range(3): try: resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.2, response_format={"type": "json_object"}, # 强制JSON ) raw = resp.choices[0].message.content data = json.loads(raw) # 用Pydantic校验 return MeetingSummary(**data) except (ValidationError, json.JSONDecodeError) as e: print(f"第{attempt+1}次输出校验失败: {e}, 重试...") continue # 降级策略：返回一个带错误标记的默认结构 return MeetingSummary(title="解析失败", key_points=[], action_items=[])

这段代码里做了四件工程化的事：强制JSON格式、结构校验、失败重试、降级返回。别小看这四步，它们构成了整个Harness的骨架。你可以根据业务需要加入更多校验逻辑，比如检测关键字段是否为空、判断输出内容是否触及敏感词、用规则表达式验证格式等等。

3.3 Loop Engineering：从"生成一次"到"循环闭环"

Loop Engineering是另一个让我茅塞顿开的词。它指的是把AI从"一次通话"变成一个"持续循环的认知过程"。很多AI应用之所以给人"智障"的印象，是因为它们只做了单次推理——问一句答一句，没有反馈回路。而真正好用的AI应用，内部是有一到多轮循环的。

一个典型的Loop包含四个环节：

1. 生成：模型产生初步输出。
2. 评估：用规则或另一个模型检查输出质量。
3. 反馈：把检查结果喂回给模型，要求它修正。
4. 再生成：模型根据反馈优化输出，然后再次评估。

这个循环在学术上有另一个名字叫"Self-Critique"或"Reflexion"，但在工程上，我更愿意把它理解为"写代码时的断点调试"——模型生成一份答案，你让它自己检查一遍甚至两遍，质量会显著提升。

下面是我常用的一个自反思循环示意（不是完整代码，逻辑供参考）：

def generate_with_self_reflection(query: str, model="gpt-4o-mini"): # 第一轮生成 draft = call_llm(query) # 自我批评 critique_prompt = f"""以下是你的回答。请扮演一个严格的审核员，指出其中的错误、模糊、缺少逻辑的部分，并给出修改建议。不要修改原文，只输出批评意见。 回答内容：{draft}""" critique = call_llm(critique_prompt) # 根据批评重新生成 refine_prompt = f"""用户的原始问题：{query} 你之前的回答：{draft} 审核员的批评：{critique} 请根据批评意见重新写一份高质量回答，保留有效部分，修正错误和不足。""" refined = call_llm(refine_prompt) return refined

这个例子非常简单，但已经构成了一个完整的"生成—评估—反馈—再生成"闭环。你完全可以根据成本预算决定循环次数。我个人的经验是：高价值任务循环2轮，普通问答任务1轮就够，超过3轮边际收益会快速下降，因为模型有时候会把自己的正确内容改成错误内容。

3.4 一个完整的Harness+Loop的Demo设计

光说不练假把式。很久之前我做了一个"简历信息提取器"，输入一份简历文本，输出候选人的结构化档案。这个项目麻雀虽小五脏俱全，完整展示了Harness和Loop的配合。

流程设计是这样的：

输入简历文本 → Prompt模板组装（角色、输出格式约束） → 调用模型提取JSON → 校验JSON结构（Pydantic） → 如果校验失败：自动重试，并在重试的Prompt里附带上一次的错误信息 → 如果校验通过：进入"信息完整性检查"阶段 → 用规则检查关键字段（姓名、电话、邮箱）是否为空 → 如果关键字段缺失：触发修补Loop，只让模型补全缺失字段 → 输出最终结构化档案

其中第二轮的"修补Loop"是最有价值的部分。因为第一轮通常能提取出大部分信息，但因为格式问题漏掉一个字段，如果全量重新跑一遍，成本和耗时都翻倍。更好的做法是：只在Prompt里提示模型"上次漏掉了电话字段，请只补上这个字段，不要修改其他内容"，这样既省token又避免模型把原本正确的数据改坏。

这个Demo教会我一件事：Harness和Loop不是两种互斥的选项，而是同一个系统的两个层次。Harness在输入和输出端做约束，Loop在推理过程中做质量控制。对一个生产级AI应用来说，两者缺一不可。

4. 从单次任务到自主决策：AI Agent的构建思路

4.1 Agent的三大核心部件：记忆、规划、工具

上面的内容讲的都是"接一个任务、出一份结果"的脚本模式。但如果你想让AI系统完成更复杂的、需要多步骤决策的活儿，就得用到Agent。业界对Agent的分解比较统一，它通常由三部分组成：

• 记忆（Memory）：包括短期记忆（当前会话的上下文窗口）和长期记忆（向量数据库或文件存储）。没有记忆的Agent是金鱼，聊完就忘，无法处理多轮任务。
• 规划（Planning）：把大目标拆分成子步骤，决定调用哪些工具、按什么顺序调用。最原始的规划方式就是"ReAct"模式：推理（Reason）→ 行动（Act）→ 观察（Observe）。
• 工具（Tools）：Agent通过工具与外部世界交互。什么算是工具？搜索、计算器、发HTTP请求、执行SQL查询、读写文件，甚至调用其他AI模型。工具拓展了Agent的能力边界。

从工程角度，我认为记忆是最容易被做砸的部分。很多初学者把所有对话历史都塞进上下文，结果很快超过上下文窗口，或者花掉巨额token。正确的做法是：对记忆分层。当前对话用窗口缓存，重要信息抽取到长期记忆，无关信息直接丢弃。我见过不少团队没做记忆分级，项目一上线成本就爆表。

4.2 从零实现一个最小可用的Agent

跟着教程写过几个框架之后，我觉得即使不用LangChain，只用一个循环加几个工具函数，也能构建一个能用的Agent。关键在于理解"循环"。

from typing import Callable class MinimalAgent: def __init__(self, tools: dict[str, Callable], max_steps=5): self.tools = tools self.max_steps = max_steps def run(self, user_request: str): messages = [{"role": "user", "content": user_request}] for _ in range(self.max_steps): # 1. 让模型决定下一步动作（ReAct） response = call_llm( system_prompt=( "你是一个Agent。请根据用户的目标，决定执行哪个工具。" "输出必须包含: action工具名和args。" "如果任务已经完成，输出final_answer。" f"可用工具: {list(self.tools.keys())}" ), messages=messages ) messages.append({"role": "assistant", "content": response}) # 2. 解析模型输出 action, args, final = parse_agent_response(response) if final: return final if action in self.tools: # 3. 执行工具并观察结果 observation = self.tools[action](**args) messages.append({"role": "user", "content": f"观察结果: {observation}"}) else: messages.append({"role": "user", "content": "工具不存在，请重新选择。"}) return "达到最大步数，任务未完成。" # 工具示例 def search_web(query: str): return f"搜索结果前3条: ..." def calculate(expression: str): return str(eval(expression)) agent = MinimalAgent(tools={"search_web": search_web, "calculate": calculate}) print(agent.run("查一下今天的日期，并计算一周后的日期"))

这个代码有个陷阱：eval在真实项目里极度危险，我只是为了演示才用。真实项目中，工具函数必须做严格的参数校验和权限控制，否则Agent就是给攻击者递刀。但它的核心逻辑是通用的：模型只是决策头，真正的能力和风险全在工具层。

Agent最容易翻车的点，是模型决定调用工具的步骤是随机的。今天它可能先搜索再计算，明天可能先计算再搜索。你的工具层必须设计成"无论以什么顺序调用，都能得到安全结果"。这也意味着，不要给Agent开放没有幂等性、没有权限限制的工具。

4.3 多Agent协作的两种模式

单Agent的能力终究有限，所以现在很多项目开始搞"多Agent协作"。我不建议上来就上多Agent，那是给自己找麻烦，但理解两种常见模式能帮你判断什么时候该上。

模式一：编排者模式（Orchestrator Pattern）

一个"管理者" Agent负责拆解任务，然后把子任务分发给不同的"专家" Agent，最后汇总结果。优点是职责清晰，缺点是大佬Agent成了瓶颈，被骂的对象。

模式二：对等协作模式（Peer-to-Peer Pattern）

多个Agent地位平等，通过共享消息通道互相协作，各自独立处理一部分，遇到问题互相求助。典型场景是"主持人Agent + 发言人Agent + 批评者Agent"的开会形式。这种模式能激发创造力，但容易陷入无休止的互相扯皮。

从我的实践看，绝大多数业务场景用编排者模式就够了。把"多Agent"当作营销话术可以，但当工程架构，先掂量一下你的系统有没有复杂到需要一个"Agent议会"。

5. 实战：我为什么建议从"AI编程助手"开始

5.1 用AI编程暴露工程化短板

如果你想找一个人门级项目来实践上面的所有概念，我会非常推荐"AI编程助手"。为什么？因为编程任务自带明确的正确性标准——代码能不能跑、测试过不过、回答是否解决了问题——这些都是天然的质量信号。相比之下，你写个"AI情感分析"很难判断模型到底对不对，但AI编程的反馈清晰得多。

另外，编程任务本身有大量现成的工具链可以接：编译器、执行器、Git、测试框架。你不用自己造测试集，只需要让Agent把"运行测试"当作一个工具，就能实现非常完整的Harness+Loop闭环。

我们团队做的第一个AI编程助手项目，结构是这样的：

用户输入需求 → 需求澄清Agent（Loop: 提问-确认） → 任务规划Agent（将需求拆解为改动清单） → 代码生成Agent（按清单逐文件生成diff） → 编译检查工具（Harness: 自动编译） → 测试执行工具（Harness: 跑单测） → 失败反馈Loop（把报错信息喂给生成Agent修复） → 生成最终PR描述

你发现了吗，整个过程就是一个巨大的Loop，每个环节都有对应的Harness。它不是"聊天+写代码"，而是一个有明确输入、输出、校验、纠错的工程系统。

5.2 数据流设计：从需求描述到Pull Request

具体的落地步骤，我认为设计好"任务状态机"比让Agent写代码更重要。我把一次AI编程任务的状态定义成这样：

• 初始：用户提交自然语言需求。
• 澄清：Agent判断需求是否足够清晰，不够则提问。
• 规划：需求清晰后，将改动拆成文件级别的子任务。
• 实施：逐个文件生成代码改动。
• 验证：执行编译、单元测试、静态检查。
• 修复：验证失败时，将错误信息回传，生成修复补丁。
• 交付：所有验证通过，生成PR摘要。

状态之间的切换逻辑，完全可以用代码写死，而不是让Agent随便乱跳。把AI的能力限制在"状态内部"而非"状态流转"上，这是AI工程和纯Prompt玩法最本质的区别。状态机是你的Harness，Agent只是其中处理数据的引擎。

5.3 AI测试开发：你需要的不是"跑通"而是"可回归"

很多做AI应用的朋友最头疼的就是测试。传统测试断言输入输出，但AI输出是随机的，怎么断言？

我的答案是：不要断言模型的最终答案，要断言工程系统的行为。也就是说，你要测试的不是"模型是否说出了正确答案"，而是：

• 输出是否符合JSON Schema；
• 关键字段是否为空；
• 是否包含敏感内容；
• 在固定回归集上，模型输出的核心语义是否保持稳定；
• 重试机制是否在模型宕机时正常工作；
• 降级方案是否在超时时被触发。

这个思路被称为"AI测试开发"。它要求你把测试重点从"结果正确性"转移到"行为鲁棒性"和"系统可用性"上。我甚至会用两个不同的模型做交叉评估：A模型生成答案，B模型为A的答案打分。虽然会增加成本，但对于那些"错误代价高昂"的业务，多花一次调用的钱换来稳定的质量，完全值得。

我们团队的回归测试集大概有几百条带标签的典型输入，每次修改Prompt或流程后，脚本自动跑一遍，统计"合法输出率""关键字段缺失率""语义一致性评分"。有了这个回归集，我就敢放心迭代Prompt了——因为在AI工程里，Prompt的每一次改动都是一次可能引入回归的风险操作，必须用回归集兜底。

6. 项目落地过程中的十一个高频坑与我的处理方案

一路从零走到现在，我把踩过的坑整理成一张对照表。每一条都是真金白银换来的，希望你在设计系统时可以提前规避。

这十一个坑不是严格的顺序，但多数项目至少会踩中其中五个。我在前几个项目里几乎全踩了个遍，后来才慢慢形成一套固定的"AI工程检查清单"：写代码前先决定输出Schema，调用模型前先想好校验规则，上线前先跑一遍回归集。这套清单就像飞机起飞前的检查表，虽然繁琐，但每次都能拦住几个致命问题。

从零开始的最后一段路：把AI工程当系统工程，而不是"咒语"

聊了这么多，回到"ai-engineering-from-scratch"这个话题本身。我最后想分享的体会是：AI工程真正难的地方，从来不是模型或算法的数学原理，而是你是否愿意把它当成一个严肃的系统来对待。很多人学了很久Prompt技巧，却做不出能稳定运行的应用，根本原因是缺少"工程化精神"——总觉得模型输出不好是模型的问题，而不是自己的流程没约束好。

多想一想：如果模型的每个输出都不是确定的，我的系统是否依然可控？如果模型偶尔撒谎，我的业务是否会因此受损？如果模型供应商明天涨价，我的成本架构是否能支撑？这些问题的答案，不在那些铺天盖地的"AI速成课"里，而是在你亲手把一个微小功能点反复打磨、校验、测试、加固的过程中。

如果你现在准备开始，我的建议是：先挑一个非常窄的、有明确输入输出的场景，比如"从一段简历抽取联系人信息"或"从会议记录生成待办清单"，然后老老实实把Prompt模板、结构化输出、Pydantic校验、重试降级、回归测试这五个步骤走一遍。不要贪多，不要一心想着做全能Agent。把这五步走顺了，你会发现后面所有复杂系统，拆开看都是这些基础单元的排列组合。

记住一个朴素的道理：模型就像驾驶性能极佳的跑车，而你是赛道工程师。你能跑多快，不取决于发动机参数，而取决于你铺设的赛道有多平整、护栏有多结实、维修站有多及时。从零开始做AI工程，重要的不是"跑起来"，而是"摔不坏"。共勉。