企业官网建设流程全解析

从零开始搭建你自己的AI工程实践

“ai-engineering-from-scratch”，这个项目标题看着简单，其实背后藏着一个很现实的问题：真正把一个AI想法落地成能跑、能迭代、能上线的系统，到底要补多少课？我在一线做AI工程已经有几年时间，见过太多人把“调用一个LLM接口”误当成“AI工程”的全部，结果做出来的东西距离生产环境还差很远。这个项目本质上就是一条自己走过的路：不依赖任何现成的全家桶方案，从提示词设计、模型调用、上下文管理、Agent编排再到测试评估，一步步把一个AI应用从零开始搭起来。这篇文章会把整条实践路径拆给你看，适合刚入门AI开发的工程师、产品经理和所有想认真搞AI落地的人。

我自己在这个项目里踩过的坑不少，其中最大的一个是：市面上90%的教程都在教你怎么“用”AI，而不是教你怎么“工程化”AI。用AI只需要会写提示词，工程化AI则需要你理解模型行为、掌控不确定性、设计评估闭环。这篇文章就是冲这个来的，我会把我花了大量时间换来的经验尽量平铺直叙地讲清楚。

1. 项目定位与整体设计思路

1.1 从零开始到底意味着什么

“from scratch”这个词经常被人误解。很多人以为从零开始AI工程就是不用任何框架，手写神经网络的反向传播，或者从tokenizer开始实现一个GPT。说实话，那是科研活，不是工程活。工程意义上的“从零开始”，指的是不依赖某个一体化平台帮你把所有事情都包办掉，而是自己掌握AI应用的每一个关键环节。

我在这个项目里的定义很明确：模型层的API照用（自己训练大模型成本太高，且对多数业务场景没必要），但应用层的所有东西全部自己搭。这包括提示词体系的设计、上下文的组装与管理、工具调用的协议、Agent的执行循环、以及最容易被忽略的测试评估系统。

为什么要这么较真？因为只有把每一层都摸过一遍，你才能在出问题的时候知道该去哪一层排查。我见过一个团队，用了一个很成熟的Agent框架，业务跑起来看着很顺，结果某天AI开始疯狂调用某个工具，所有人都懵了，最后发现是框架内置的反思机制和他们自定义的工具描述冲突了。如果不懂底层的执行逻辑，这种问题只能靠瞎猜。

1.2 项目要解决的核心痛点

在开始动手之前，我先梳理了一下当时最频繁遇到的痛点，一共有四类：

• 提示词写不好：同一个问题换个说法，模型输出质量波动大到不可接受。
• 上下文管理混乱：对话一长就丢失关键信息，或者把无关历史塞给模型导致“知识污染”。
• Agent编排不可控：多步骤任务执行时，模型经常在各个步骤间跑偏。
• 评估完全靠感觉：没有量化指标，不知道改版到底是变好了还是变差了。

[\table] 痛点领域 | 典型表现 | 工程化手段 提示词 | 输出不稳定，格式随机 | 结构化提示词、少量示例、输出Schema约束 上下文 | 长对话失效，信息覆盖 | 上下文窗口管理、摘要压缩、关键信息抽取 Agent编排 | 执行跑偏，工具误用 | 状态机约束、工具白名单、人工确认节点 测试评估 | 改版无依据，回归靠肉眼 | 自动化评测集、指标量化、版本对比

[/table]

这四个痛点是相互关联的。提示词问题影响的是单轮输出的质量，上下文问题影响的是多轮对话的连贯性，Agent编排问题影响的是复杂任务的可靠性，评估问题则决定了你能不能持续改进前三个问题。所以项目路线图也是按照这个顺序来拆的。

1.3 技术选型的关键考量

关于技术选型，我的原则是三句话：主流程要短、扩展要容易、换模型要方便。

主流程短，意思是核心逻辑的代码路径不要太绕，出问题能快速定位；扩展容易，指新加一个工具、新接一个数据源的成本要低；换模型方便，是因为这个领域迭代太快，今天用的模型明天可能就有更好的替代品，所以API抽象层必须做。

基于这三点，我当时没有选那种包揽一切的Agent框架，而是选了一个极简的编排核心自己写，每个模块只做一件事，模块之间用清晰的数据结构对接。具体方案在下一节展开，这里先把结论放出来：简单不等于简陋，恰恰是简单的东西在出问题的时候最好修。

2. 核心细节解析与实操要点

2.1 提示词工程：从玄学到工程学

提示词工程是这个项目的基础设施。很多人在这一步犯的错，是把它当成“写作文”，以为把需求描述得越详细越好。其实提示词工程的核心不是文字功底，而是结构设计。

我最终落地的提示词模板，强制包含六个部分：

1. 角色定义：模型以什么身份来处理这个任务。
2. 任务描述：一句话说清楚要做什么，禁止让模型自己猜。
3. 输入格式说明：什么是数据，数据长什么样。
4. 输出格式约束：用JSON还是Markdown，字段名是什么。
5. 边界条件：哪些情况是模型必须拒绝或特殊处理的。
6. 少量示例：给两到三个输入输出对，比任何抽象描述都管用。

这里最容易被忽略的是边界条件。我踩过一个很典型的坑：让模型做文本分类，结果它遇到一个模棱两可的输入时，自己脑补了一个“其他”类别，但这个类别不在我指定的枚举值里。后来我在模板里明确写了“如果无法确定类别，必须返回unknown，禁止自行发明新类别”，这个问题就彻底消失了。

少量示例的选择也很有讲究。示例不是随便给的，应该刻意覆盖三种类型：最典型的正常情况、最容易混淆的边界情况、需要触发特殊规则的例外情况。三个示例基本够用，再多反而会让模型过于依赖示例的模式。

2.2 上下文工程：决定AI“记忆力”的关键

上下文管理是AI工程里最容易被低估的部分。你给模型喂什么历史信息、喂多少、按什么顺序喂，直接决定了它在长对话里的表现。

我在项目里用了三层上下文结构：

第一层是系统提示词，包含角色定义、全局规则、任务边界。这层内容在每次请求时固定存在，相当于AI的“世界观”。

第二层是会话摘要，把之前对话的核心信息压缩成结构化的要点。这个摘要不是简单地把历史对话截断，而是用模型自己提炼关键信息。举个例子，如果用户在10轮前说了“我喜欢简洁的回答风格”，这个信息必须保留在摘要里，哪怕对话已经转到了完全不同的主题。

第三层是最近对话，保留最近几轮的完整对话记录，因为摘要会丢失细节，模型需要有足够近的原始信息来做准确响应。

这套三层结构解决了两个问题：一是长对话的“记忆衰减”问题，摘要保证了关键信息不丢；二是token成本问题，不把全部历史无脑塞给模型，能省下大量上下文空间。

我做过一个有趣的实验，同一组对话测试，用单层完整历史的方式跑，长对话到第30轮就开始前后矛盾；换成三层结构后，跑满100轮依然能准确引用用户早期提到的偏好。这个差距是决定性的。

2.3 Agent编排：从自由发挥到流程受控

Agent是这个项目里最复杂也最坑的一环。我一开始用了非常“自由”的设计——让模型自己决定调什么工具、按什么顺序调。结果就是灾难性的：它经常在无关任务之间跳来跳去，或者在一个简单任务上反复尝试各种工具不回来。

后来我把Agent的执行模式从“完全自主”改成了“状态机约束”，局面才彻底改观。具体做法是：预先定义好任务的每个阶段，每个阶段允许调用哪些工具、需要输出什么字段、什么时候可以推进到下一阶段。模型只能在给定的自由度里做决策，不能越过边界。

比如一个“查资料并写摘要”的任务，状态机是：理解需求 -> 搜索资料 -> 筛选结果 -> 撰写摘要 -> 格式检查。在“搜索资料”阶段，模型只能调用搜索工具，不能跳去写摘要；在“撰写摘要”阶段，模型不能再去搜索新资料（除非它明确标记“信息不足，需要补充搜索”并得到人工确认）。

这套设计的价值在于：它把AI的创造性用在了正确的地方——在给定步骤内如何做得更好，而不是让它决定整个流程的走向。我管这叫“给了自由，但圈了边界”。

2.4 工具调用的协议设计

工具调用是Agent能力的延伸，但工具描述写不好，模型就不会用。工具描述不是写给用户看的，是写给模型看的，所以格式特别重要。

我的工具描述模板包含这么几个字段：

• 工具名称：简短、语义明确，模型会通过名称理解工具的用途。
• 功能描述：用两到三句话说清楚工具是做什么的，适合什么场景。
• 参数Schema：每个参数的名称、类型、是否必填、取值范围。
• 返回值格式：工具返回什么数据结构，怎么判断成功或失败。
• 使用注意事项：哪些情况下不要用这个工具，比如“仅当用户明确要求查询天气时才使用”。

第五点是我后期加上的，效果异常显著。之前模型经常会“顺手”调用一个工具，比如用户问了一句“今天能发货吗”，模型就去查快递物流，但其实用户只是在问电商平台的一般政策。加上负面使用条件后，这种误调用频率降低了八成。

还有一个细节：工具返回结果过长时要先做摘要，再喂给模型。否则工具调用一多，上下文就爆炸了，而且模型容易被大量噪声信息干扰。我在工具返回层加了一个“返回结果压缩”的环节，所有工具输出先过一遍清洗逻辑，抓取关键字段，然后才进入模型上下文。

2.5 测试评估体系：把“感觉”变成“指标”

大部分做AI应用的人，评估方式是“我试了几条用例，感觉效果还行”。这种评估方式在项目早期可以，一旦进入迭代阶段就完全不够用了——你不知道这次改提示词到底比上次好还是差，也不知道会不会在某些场景下全面退步。

我搭的评估体系分三个层次：

第一层是单轮输出质量评测。准备一组带标准答案的测试集，每次改动后用这组测试集批量跑一遍，算准确率、召回率、格式合规率等指标。这组测试集必须是固定的、不回传的，否则没法做回归对比。

第二层是多轮任务成功率评测。模拟真实的完整任务流程，衡量Agent能不能从头到尾把任务做完，中间有没有跑偏，有没有工具调用失败但没恢复。这个指标比单轮准确率更能反映真实体验。

第三层是线上日志复盘。把生产环境的请求日志定期抽样，人工标注“用户是否满意”，用这个数据来补全测试集的盲区。

我在实际运行中发现，第一层和第二层的指标经常出现“打架”的情况：单轮输出准确率提高了，但多轮任务成功率反而下降了。根源是模型的单轮能力增强后，其行为模式在Agent流程里反而变得更“自信”、更容易忽略流程约束。这个发现直接推动我在Agent状态机里加了“不确定时必须暂停请求确认”的规则，让多轮成功率重新拉回来。

3. 实操过程与核心环节实现

3.1 第一步：搭建最小可运行系统

我的习惯是万事开头先搭一个最小闭环：一个输入框、一次模型调用、一个输出展示。这不是为了炫技，而是先把整个链条跑通，确认每个环节的API、鉴权、数据格式都没问题。

这个最小系统的代码结构大概是这个样子的：

# minimal_pipeline.py # 一个最简的AI应用闭环示例 from openai import OpenAI client = OpenAI(api_key="your-api-key") system_prompt = "你是一个简洁的回答助手，回答不超过200字。" def generate_answer(user_input: str) -> str: response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input} ], temperature=0.3 ) return response.choices[0].message.content if __name__ == "__main__": while True: user_input = input("请输入你的问题（输入exit退出）：") if user_input.lower() == "exit": break result = generate_answer(user_input) print("AI回答:", result)

这里面的关键参数是temperature。很多人不理解这个参数的意义，它控制模型输出的随机性——值越低，输出越保守、确定；值越高，输出越多样、有创意。做工程化应用，我建议默认设在0.2到0.5之间，除非你明确需要创意发散。把temperature调成0并不会让输出100%确定，但能让每次输出的结构稳定性大幅提升。

跑通这个最小系统后，你就算完成“AI工程从零开始”的第一步了。接下来所有的复杂度，都是在这个基础上一步一个脚印加进来的。

3.2 第二步：设计结构化提示词与输出约束

第一次改进要做的是把“裸调”变成“结构化调用”。我在这一步做了三件事：给提示词加结构、给输出加格式约束、给调用加错误处理。

输出格式约束这一步很关键。让模型直接返回一段自然语言，你会发现下游解析的活特别难干。正确的做法是让模型返回严格的JSON结构，然后用代码解析。

# structured_prompt.py # 结构化提示词 + JSON输出示例 import json from openai import OpenAI client = OpenAI(api_key="your-api-key") structured_prompt = """ 你是一个电商客服意图分类器。 任务：判断用户问题的意图类别。 输入：用户提问文本 输出：JSON对象，包含两个字段： - intent: 意图类别，只能从["查订单", "退换货", "咨询商品", "投诉", "其他"]中选择 - confidence: 置信度，0到1之间的小数 - reasoning: 一句话说明判断依据 约束条件： 1. 如果无法确定意图，intent返回"other" 2. 禁止返回列表之外的意图类别 3. 如果用户问题包含多个意图，以第一个出现的意图为准 示例： 输入：我的订单显示已发货但三天没到 输出：{"intent": "查订单", "confidence": 0.95, "reasoning": "用户描述的是订单状态查询问题"} 输入：这个衣服能换大一号吗 输出：{"intent": "退换货", "confidence": 0.9, "reasoning": "用户询问换货相关操作"} 输入：你叫什么名字？ 输出：{"intent": "other", "confidence": 0.8, "reasoning": "问题与业务无关"} """ def classify_intent(user_input: str) -> dict: response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": structured_prompt}, {"role": "user", "content": user_input} ], temperature=0.1, response_format={"type": "json_object"} ) raw_content = response.choices[0].message.content # 解析JSON，如果解析失败则走兜底逻辑 try: result = json.loads(raw_content) except json.JSONDecodeError: return {"intent": "other", "confidence": 0.0, "reasoning": "模型输出非JSON，走兜底"} return result

这中间最大的坑是JSON解析失败。即使你要求模型返回JSON，它偶尔还是会输出些乱码。所以我建议所有模型调用的下游都要套一层try-except，并准备好兜底返回值。这套防御性编程虽然不优雅，但能在生产环境里救你很多次。

3.3 第三步：实现上下文管理模块

上下文管理从这一步开始变成一个独立模块，不再跟业务代码混在一起。

我的实现方案是这样的：对话历史存到Redis里，键值对结构是session_id -> {summary, recent_messages}。每次新请求进来，从Redis读取该session的摘要和最近消息，然后把系统提示词、摘要、最近消息拼接成完整的消息列表，再发给模型。

# context_manager.py # 三层上下文管理模块 import redis import json r = redis.Redis(host="localhost", port=6379, decode_responses=True) def get_session_context(session_id: str): raw = r.get(f"session:{session_id}") if raw: return json.loads(raw) return {"summary": "", "recent_messages": []} def update_context(session_id: str, user_msg: str, ai_msg: str): ctx = get_session_context(session_id) # 追加最新对话 ctx["recent_messages"].append({"role": "user", "content": user_msg}) ctx["recent_messages"].append({"role": "assistant", "content": ai_msg}) # 只保留最近5轮对话 ctx["recent_messages"] = ctx["recent_messages"][-10:] # 如果最近对话超过阈值，触发摘要压缩 if len(ctx["recent_messages"]) >= 10: ctx["summary"] = summarize_context(ctx["summary"], ctx["recent_messages"]) ctx["recent_messages"] = [] r.set(f"session:{session_id}", json.dumps(ctx)) def build_messages(session_id: str, system_prompt: str, user_input: str): ctx = get_session_context(session_id) messages = [{"role": "system", "content": system_prompt}] if ctx["summary"]: messages.append({"role": "system", "content": f"之前的对话摘要：{ctx['summary']}"}) messages.extend(ctx["recent_messages"]) messages.append({"role": "user", "content": user_input}) return messages

摘要压缩函数我没有在这里贴代码，因为实现思路本身就比代码重要。摘要不等于简单截断，而是要提炼出“和后续对话相关”的关键信息。比如用户说“我不喜欢太长的回答”，这个偏好需要留在摘要里；而用户说“今天天气不错”，这种一次性信息就无需保留。

3.4 第四步：编排Agent状态机

Agent状态机的实现是整个项目里最体现工程功底的部分。我的做法是把任务流程定义成一个明确的状态图，每个状态有自己的处理器函数。

# agent_state_machine.py # 一个简单的Agent状态机示例 from enum import Enum class AgentState(Enum): UNDERSTAND = "understand" # 理解需求 SEARCH = "search" # 搜索资料 DRAFT = "draft" # 撰写内容 REVIEW = "review" # 质量检查 COMPLETE = "complete" # 完成 class ResearchAgent: def __init__(self): self.state = AgentState.UNDERSTAND self.search_results = [] self.draft_content = "" def run(self, user_query: str): # 主循环：只有状态为COMPLETE时才退出 while self.state != AgentState.COMPLETE: if self.state == AgentState.UNDERSTAND: self.handle_understand(user_query) elif self.state == AgentState.SEARCH: self.handle_search() elif self.state == AgentState.DRAFT: self.handle_draft() elif self.state == AgentState.REVIEW: self.handle_review() def handle_understand(self, user_query: str): # 用LLM解析用户需求的要点，并判断需要搜索哪些信息 self.search_keywords = extract_keywords(user_query) self.state = AgentState.SEARCH def handle_search(self): # 在工具白名单中只允许调用搜索工具 for kw in self.search_keywords: result = call_search_tool(kw) self.search_results.append(result) self.state = AgentState.DRAFT def handle_draft(self): # 根据搜索结果撰写内容 self.draft_content = generate_draft(self.search_results) self.state = AgentState.REVIEW def handle_review(self): # 质量检查：检查格式、长度、是否有明显错误 if quality_check(self.draft_content): self.state = AgentState.COMPLETE else: # 质量不过关则重新撰写，但最多重试两次 self.retry_count += 1 if self.retry_count >= 2: self.state = AgentState.COMPLETE # 强制完成，防止死循环 else: self.state = AgentState.DRAFT

状态机最核心的工程价值是“可观测性”和“可控性”。每执行一步，我都能知道Agent当前在哪一步、下一步会去哪、可以调用什么工具。一旦出错，我可以在任何状态介入，直接修改数据后重放后续步骤。Agent从黑盒变成了灰盒，这个转变对调试体验来说是量变到质变。

3.5 第五步：搭起自动化评测流水线

评测流水线是整个项目的“质检关卡”，它的价值在长期迭代中会越来越明显。

评测数据集是核心资产，我建议从上线第一天就开始积累。每次线上用户反馈“回答不对”的case，确认无误后就进评测集；每次产品争议比较大的case，也进评测集。半年下来，这个数据集就是评估AI系统好坏的黄金标准。

# eval_pipeline.py # 自动化评测流水线示例 import json import numpy as np def run_eval_pipeline(model_shorthand: str, eval_cases): total_cases = len(eval_cases) correct = 0 format_compliance = 0 for case in eval_cases: # 逐条跑测试用例 output = call_model(model_shorthand, case["input"]) # 判断业务正确性 is_correct = judge_output(output, case["expected"]) # 判断格式合规性 is_formatted = check_format(output, case["expected_format"]) correct += int(is_correct) format_compliance += int(is_formatted) return { "accuracy": correct / total_cases, "format_compliance": format_compliance / total_cases, "total_cases": total_cases, "failed_cases": [ c for c in eval_cases if not judge_output(call_model(model_shorthand, c["input"]), c["expected"]) ] } # 评测结果示例 # {"accuracy": 0.92, "format_compliance": 0.98, "total_cases": 120, "failed_cases": [...]}

评测流水线一定要在每次改动提示词或模型后立刻运行，形成“改动-评测-决策”的闭环。我在机器上配了一条命令，改完提示词后跑一个脚本，几分钟内就能看到指标变化。没有这条流水线，你每次改版都在裸奔。

4. 常见问题与排查技巧实录

4.1 模型输出不稳定怎么办

这是被问得最多的一个问题。同样的输入，模型今天给的结果和昨天不同，甚至连续两次调用结果都不同。

排查顺序建议如下：

• 先确认temperature是否设得太高。大于0.7就会有明显的随机性，工程应用建议降到0.3以下。
• 再检查提示词是否有“确定性锚点”。即使temperature偏低，如果提示词太模糊、没给示例，输出依然会漂。加一个标准示例的输出格式，稳定性立刻提升。
• 最后看模型版本是否有变化。有些模型服务商会悄悄更新底层模型，导致行为差异。

[\table] 现象 | 排查点 | 常用解法 同一输入多次输出不同 | temperature过高 | 调低到0.2~0.3 输出结构忽对忽错 | 没有输出Schema约束 | 使用response_format强制JSON 格式全对但内容变差 | 模型版本更新 | 固定模型版本，升级前跑评测集 特定输入必出错 | 提示词边界条件缺失 | 补充边界规则和反面示例

[/table]

4.2 Agent循环卡死或者跑偏怎么破

Agent进入死循环是状态机设计最容易踩的坑。模型可能在一个状态下反复调用同一个工具，或者在两个状态之间来回跳。

我的解决方案有三层：

第一层是设置最大重试次数。每个状态只允许失败重试N次，超过就强制进入兜底流程——通常是直接结束任务并告诉用户“当前任务无法自动完成”。

第二层是行为模式检测。记录最近10次状态转移，如果出现A-B-A-B这样的循环模式，就中断并走人工确认。

第三层是状态转移白名单。在状态机里定义“允许的转移矩阵”，模型无法直接跳过一个不该跳的步骤。这一层最有效，但也需要你预先想清楚流程的边界。

4.3 长对话记忆总丢，怎么排查和解决

这个问题的根源前面提到过，大部分是上下文管理没做好。排查步骤是：

• 第一，确认你发送给模型的messages里，历轮对话和系统提示词是否拼接正确。
• 第二，确认摘要压缩是否保留了关键信息。把摘要拿给人看一遍，如果人都觉得摘要漏了重点，模型也会漏。
• 第三，确认关键信息是否被截断。长对话时，有些关键信息在第20轮开头出现过，现在已经被挤出最近窗口了，如果摘要里也没这部分，就彻底丢了。

解决办法是“关键信息锚定”机制：在对话过程中实时识别用户提到的偏好和重要事实，单独存到结构化字段里，每个请求都带上。这个字段不随轮次滚动，对话再长也不会丢。对比一下，这个方案比单纯依赖摘要要可靠很多。

4.4 评测集和真实场景脱节怎么办

评测准确率很高，但上线后体验很差，这个现象也有很多人碰到。核心原因是评测集太“干净”了，覆盖不到真实场景里的长尾问题。

我的做法是用“视频回放式”补充评测集。每次线上出现问题，把真实的输入输出记录成一份case，加入评测集。这些case往往带着真实用户的随意表达方式——句子不通顺、信息不全、有多余语气词——这些都是评测集里最珍贵的数据。所以我会定期清理评测集，确保里面至少有20%的case来自真实场景，而不是全部来自手动编写。

示例：真实场景case vs 手工写case的差异 手工写的case： 输入：查一下订单123456的物流信息 期望输出：该订单已于昨天发出，预计后天到达 真实场景case： 输入：我那个暗色衣服发货了没啊一直没消息 期望输出：查询到订单456789于今天下午发出，请留意物流更新

第二个case才是模型在真实世界每天面对的东西，评测集里没有这种case，模型就永远学不会处理日常化的表达。

4.5 关于工具误调用的经典案例分析

最后分享一个我实际处理过的工具误调用案例。我们的Agent接了一个“查询天气”的工具，某天有用户问“明天适合去爬山吗”，Agent直接调用了天气工具查了明天的天气。这个行为看起来没错，但问题是当时Agent的系统提示里规定“必须优先调用天气工具查询信息”，所以它忽略了用户的真实请求其实是“爬山适合性建议”，而不是简单的天气查询。

修复方案很典型：我给工具描述加了一个“使用前提”——“仅当用户明确要求查询天气数据时使用。用户索要建议或评估时，不应使用此工具，应基于用户提供的信息给出建议。若缺少关键信息（如地点、时间），必须主动询问用户。”同时把系统提示改成“先分析用户意图，再决定是否调用工具，禁止一上来就调用工具”。这两个改动合起来，工具误调用率直接降低了七成。

这个案例给我们的教训是：Agent工具的误用，大概率不是模型能力不足，而是工具本身的“使用说明书”写得不够好。把工具描述当成API文档认真写，加上负面条件和使用边界，模型的决策质量会明显上一个台阶。

5. 一些实操中的体会与建议

走到这，整个“ai-engineering-from-scratch”的主干就清晰了。我最后再分享几个实操体会，都是每次踩坑换来的。

第一，AI工程最值钱的部分不是模型调用，而是围绕模型建立的工程体系。同样一个模型，有人用起来比另一个人好，差距往往在提示词设计、上下文管理、评估闭环这些“看不见的地方”。这些地方才是你需要亲手从零开始搭建的核心资产。

第二，稳定性优于一切。做AI应用和做传统软件的差异在于，传统软件只要写对逻辑就稳定，AI应用则永远存在不确定性。所以工程目标不是消灭不确定性，而是把不确定性隔离在可控范围内——用状态机控流程，用Schema控输出，用评测集控质量。

第三，一定要建立“改动即评测”的习惯。AI系统的回归问题非常隐蔽，今天改一个提示词，可能让一个周后的某个场景变差。没有自动化评测，就没有安全的迭代速度。

项目做出来以后，我又陆续往里加了多Agent协作、工作流可视化、线上行为回放等功能，但底层那套从零搭建的骨架始终没有换。我建议你也从最底层的东西开始搭，搭过一遍，你踩过的每一个坑都会沉淀成未来快速排障的直觉。这个项目的价值，说实话，不在于跑通了多少功能，而在于你把AI应用从“能跑”推进到了“可控、可测、可迭代”的状态——这才是AI工程师真正的手艺。