AI 行业最近总给人一种“前两天还在卷参数今天突然开始卷应用”的感觉。但如果你真正参加过产业端的对接会再去看一场面向年轻开发者的辩论赛会发现一个更准确的信号大家争论的已经不是“大模型能不能行”而是“AI 到底怎么落到工程里才不翻车”。36氪从亦庄的对接会到杭州的辩论场把一道题交给了年轻人。这道题表面上是“AI 真问题是什么”实际上是在问当一个技术从 Demo 走向生产环境从炫酷的对话机器人变成业务系统里稳定运行的模块开发者的能力模型、技术选型和工程习惯到底要发生什么变化这篇文章不打算复述活动流程而是想接着这道题往下聊AI 工程化的真问题到底在哪作为一个普通开发者你可以沿着什么路径上手又会踩到哪些典型的坑。1. 为什么说 AI 的真问题正在从“模型”转向“工程”过去一年很多团队的状态是这样的模型能力一升级大家就忙着把新模型接进来跑几个测试用例。但真到了要上线的时候问题一个接一个地冒出来。回答质量不稳定、上下文缓存爆掉、接口超时、安全问题没人敢签字、评审会上被问“这个 Agent 的决策链路能不能解释”时全场沉默。这些问题的共同点是它们已经不属于算法问题也不全是模型能力问题而是标准的工程问题。从亦庄对接会上的产业需求来看企业要的不是一个能聊天的模型而是能够嵌入业务流程、支持权限控制、可观测、可回滚、可计费的 AI 模块。从杭州辩论场上的年轻开发者视角来看大家真正焦虑的也不是“我不会训练模型怎么办”而是“我会调 API但不知道怎么做一个合格的 AI 应用”。所以AI 真问题的重心正在转移。模型能力是底座但决定一个 AI 项目能不能活的是工程化能力。这意味着 Agent 开发、AI 应用开发、模型部署与评测、可观测体系、数据回流机制这些过去被忽视的领域会成为开发者真正的分水岭。对于开发者来说这其实是一个好消息。因为工程能力是可以系统学习和复盘的不像模型预训练那样依赖巨额算力。你不需要拥有自己的大模型集群也能在 AI 工程化链条里找到不可替代的位置。2. AI 工程化涉及的核心概念与容易混淆的点要进入 AI 应用开发这个领域有几个概念必须先把边界划清楚。2.1 Agent 不是“会对话的机器人”Agent 这个词现在被用得很宽泛。很多团队把一个带 Prompt 的聊天接口叫做 Agent这是不准确的。Agent 的核心特征在于它能够在给定目标下自主规划步骤、调用外部工具、根据中间结果调整策略直到完成任务。换句话说Chatbot 是“你说一句它回一句”Agent 是“你给它一个目标它拆解并执行”。对于工程实现来说这个区别非常关键。如果你只是做 Chatbot架构可以很简单前端接 API后端透传。但如果你要做 Agent你需要考虑工具注册机制、记忆管理、任务状态机、超时与重试、人工审批节点以及每一轮决策的可追踪性。这也是 Agent 开发比普通应用开发更容易踩坑的原因。2.2 “嵌入式”与“智能体工作流”的区别在实际企业落地中有两种常见的 AI 集成模式。嵌入式集成把大模型 API 嵌入现有业务系统作为一个能力组件。比如在工单系统里加一个“自动分类”接口。这种模式改动小、风险可控但 AI 的参与度有限。智能体工作流以一个自主 Agent 为核心重新组织业务流程。比如客服 Agent 对接工单系统、知识库、用户画像服务自主完成大部分服务流程只有遇到边界情况才转人工。两种模式没有绝对优劣但它们的工程复杂度差一个量级。如果你的团队刚接触 AI建议从嵌入式集成开始先把模型调用链路、质量评估、成本监控跑通再考虑 Agent 化改造。2.3 credits、token、上下文窗口这些单位怎么理解大模型应用的计费和资源管理经常涉及几个单位。Token 是大模型处理文本的基本单位。一个汉字可能对应 1 到 2 个 token不同模型的分词方式不同同样的汉字消耗的 token 数会有差异。这对成本估算很重要。上下文窗口是模型单次能接收的最大 token 数量。窗口越大的模型越能处理长文档但成本也越高。Credits 是部分平台使用的一种计费抽象单位它把不同模型、不同输入输出长度统一折算成一种额度方便用户跨模型管理预算。在做技术选型时不能只看单次调用价格还要结合上下文长度和输出 token 上限一起算。2.4 模型部署与 API 调用是两条路线训练好的模型要提供服务主要有两条路。一条是直接调用云端大模型 API。优点是不需要 GPU、上线快、维护成本低适合大多数业务场景。一条是私有化部署开源模型。优点是数据不出域、可控性强但你需要自己处理 GPU 资源、推理优化、高并发和模型更新。对大多数团队来说第一条路是主流但对数据敏感行业第二条路几乎是必选。理解这两条路线的差异能帮你在项目启动阶段就避开“架构选错”的硬伤。3. 环境准备与前置条件纸上谈兵没有意义下面我们用一个最小可用的 AI 应用来跑通 AI 工程化的基本流程。我们不做复杂的模型训练而是做一个“基于大模型 API 的测试用例生成助手”让它接收一段需求描述自动输出结构化测试用例。这个例子麻雀虽小但五脏俱全涉及模型调用、Prompt 设计、结构化输出、异常处理、结果验证覆盖了 AI 应用开发的主要环节。3.1 环境清单在开始之前先确认你的环境满足以下条件依赖项建议要求说明Python3.10 及以上具体以官方版本为准本文代码使用 Python 语法pip 包管理最新版 pip用于安装依赖网络可访问大模型 API 服务如果你使用本地模型则需要 GPU 资源API Key你需要一个可用的模型服务账号在环境变量中配置不要硬编码代码编辑器VS Code 或 PyCharm 均可本文以 VS Code 为例3.2 创建项目目录mkdir ai-testcase-generator cd ai-testcase-generator python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate3.3 安装依赖pip install openai python-dotenv这里使用openai库作为模型 API 的客户端。需要说明的是当前许多模型的 API 都兼容 OpenAI 的调用格式因此这份代码稍作配置即可适配不同类型的模型服务。如果你的服务商不兼容请以官方 SDK 为准。如果你的环境是本地私有化部署模型也可以通过兼容层方式把服务地址指向本地。3.4 配置环境变量在项目根目录下创建.env文件# 文件路径.env MODEL_API_KEY你的API密钥 MODEL_BASE_URLhttps://api.example.com/v1 MODEL_NAMEgpt-4o-mini注意这里的具体地址和模型名需要以你实际使用的服务商为准。不要把密钥提交到 Git 仓库.env文件应该加入.gitignore。4. 核心流程拆解一个完整的 AI 应用调用流程可以拆成五个环节。理解这个流程比直接写代码更重要因为后续所有调试都是围绕这五个环节展开的。4.1 输入处理用户输入往往是自由文本而自由文本不适合直接放进模型调用。第一步要做的是清洗和对齐。具体来说去掉无关字符如多余空行、表情符号。控制输入长度超长文本需要截断或摘要。将业务字段映射为结构化参数方便 Prompt 组装。这一步做得不认真后面的 Prompt 再好也容易出问题。因为模型对输入噪声非常敏感。4.2 Prompt 构建Prompt 是驱动模型行为的关键但它本身也是工程对象。一个合格的 Prompt 应该包含角色设定告诉模型它是什么身份。任务描述明确模型要完成什么。输出格式约束指定 JSON、Markdown 还是表格。边界条件告诉模型遇到不确定情况时怎么处理。4.3 模型调用这一环节的核心是设置合理的参数。temperature控制随机性对于测试用例生成这类偏向稳定输出的任务建议设低一点。max_tokens控制输出长度需要根据实际场景预留充足空间。4.4 输出解析与校验模型返回的内容不一定是合法 JSON。有时候会多出说明文字有时候会截断。输出解析必须做容错处理最好加上重试机制。4.5 结果结构化与展示把解析后的结果转成业务对象可以写入文件、插入数据库或者返回给前端展示。5. 完整示例与代码实现5.1 基础封装模型调用模块# 文件路径llm_client.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() class LLMClient: def __init__(self): self.client OpenAI( api_keyos.getenv(MODEL_API_KEY), base_urlos.getenv(MODEL_BASE_URL), ) self.model_name os.getenv(MODEL_NAME) def chat(self, messages, temperature0.2, max_tokens1024): try: response self.client.chat.completions.create( modelself.model_name, messagesmessages, temperaturetemperature, max_tokensmax_tokens, ) return response.choices[0].message.content except Exception as e: print(f模型调用失败: {e}) raise这个封装把模型调用的公共逻辑收敛在一个类里。后续如果要切换模型服务只需要改环境变量业务代码无需变动。5.2 测试用例生成器接下来是核心业务逻辑把需求描述转化为测试用例。# 文件路径testcase_generator.py import json import re from llm_client import LLMClient SYSTEM_PROMPT 你是一名资深的软件测试工程师擅长根据需求描述设计高质量的测试用例。 你的输出必须是一个 JSON 数组每个元素包含以下字段 - id: 用例编号字符串例如 TC001 - title: 用例标题字符串 - precondition: 前置条件字符串 - steps: 测试步骤字符串数组 - expected_result: 预期结果字符串 注意只输出 JSON 数组不要输出 Markdown 代码块不要输出任何解释性文字。 如果需求描述不完整请在最常见的业务假设下生成用例并在用例中标明假设条件。 def generate_test_cases(requirement: str) - list: client LLMClient() messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f需求描述\n{requirement}}, ] raw_output client.chat(messages, temperature0.1, max_tokens2048) # 清理输出兼容模型偶尔输出 Markdown 代码块的情况 raw_output re.sub(rjson|, , raw_output).strip() try: test_cases json.loads(raw_output) except json.JSONDecodeError: # 容错尝试截取第一个 [ 到最后一个 ] start raw_output.find([) end raw_output.rfind(]) 1 if start ! -1 and end start: test_cases json.loads(raw_output[start:end]) else: raise ValueError(模型输出无法解析为 JSON) if not isinstance(test_cases, list): raise ValueError(模型输出不是 JSON 数组) return test_cases if __name__ __main__: requirement 用户可以通过手机号验证码登录系统。 cases generate_test_cases(requirement) for case in cases: print(json.dumps(case, ensure_asciiFalse, indent2))这段代码里有两个关键点。一是 Prompt 里明确约束了输出格式并要求“只输出 JSON 数组”。这样能大幅减少解析失败的几率。二是代码对输出做了容错处理即使模型画蛇添足加了 Markdown 标记也能清理掉并完成解析。5.3 批量处理脚本实际应用中我们经常需要批量处理需求条目。批量场景里的关键问题是单条失败不能中断全流程而且要有失败记录。# 文件路径batch_generate.py import json import time from pathlib import Path from testcase_generator import generate_test_cases REQUIREMENTS_FILE Path(requirements.json) OUTPUT_FILE Path(testcases_result.json) ERROR_FILE Path(failed_items.json) def load_requirements(): with open(REQUIREMENTS_FILE, r, encodingutf-8) as f: return json.load(f) def save_result(data, path): with open(path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def main(): requirements load_requirements() results [] failed [] for item in requirements: req_id item.get(id) description item.get(description, ) try: test_cases generate_test_cases(description) results.append({id: req_id, test_cases: test_cases}) print(f[成功] {req_id} 生成 {len(test_cases)} 条用例) except Exception as e: failed.append({id: req_id, error: str(e)}) print(f[失败] {req_id} 错误: {e}) # 避免请求频率过高 time.sleep(0.5) save_result(results, OUTPUT_FILE) save_result(failed, ERROR_FILE) print(f处理完成成功 {len(results)} 条失败 {len(failed)} 条) if __name__ __main__: main()这里加入了一个 0.5 秒的间隔。这不是为了炫技而是为了防止高频请求触发服务端的限流也避免给自己带来不必要的成本压力。6. 运行结果与效果验证6.1 准备输入数据创建requirements.json[ { id: REQ001, description: 用户可以通过手机号验证码登录系统 }, { id: REQ002, description: 用户可以在个人中心修改自己的头像 } ]6.2 运行批量生成python batch_generate.py如果一切正常你会看到类似输出[成功] REQ001 生成 8 条用例 [成功] REQ002 生成 6 条用例 处理完成成功 2 条失败 0 条6.3 验证输出结果打开testcases_result.json检查生成的用例是否符合预期。一个合格的用例应该包含清晰的步骤和可验证的预期结果。一个关键判断标准是预期结果是否可以被自动化验证。如果预期结果写的是“页面显示正常”这类用例很难在 CI 流程中执行。更合理的写法是“页面上出现欢迎语文本为‘欢迎您XXX’”。如果输出中大量出现模糊表述应该调整 Prompt要求模型写出可断言的预期结果。6.4 失败时怎么看如果脚本运行失败第一步不要看业务代码先看错误信息属于哪一层如果是网络错误或认证错误检查.env中的 API Key 和 Base URL 是否正确。如果是解析错误在generate_test_cases函数里打印raw_output直接检查模型返回的内容。如果是超时错误适当增大客户端的超时时间或者减小单批请求数量。7. 常见问题与排查思路问题现象可能原因排查方式解决方案提示 API Key 无效环境变量未加载或密钥错误检查.env文件路径与变量名在代码中打印 os.getenv 结果确认密钥正确并重新加载环境变量模型输出无法解析为 JSONPrompt 约束不强或模型回复被截断打印原始输出内容加强输出格式约束调用时增大 max_tokens增加解析容错生成本地代码时出现网络超时网络环境不稳定或超时时间过短查看完整异常堆栈增大超时时间或改为异步调用生成的测试用例重复度较高输入需求描述相似度过高或 temperature 设置过低对比多条生成结果的文本相似度适当提高 temperature 到 0.3 左右增加输入差异化成本突然飙升循环中未添加请求间隔或输出 token 过长查看服务商账单和调用日志增加 sleep 间隔设置 max_tokens 上限增加缓存层本地模型部署后响应缓慢模型参数量大、GPU 资源不足、未开启推理优化查看 GPU 利用率和请求队列长度使用量化版本、增加并发处理、或用 vLLM 等推理框架部署8. 最佳实践与工程建议8.1 不要把 Prompt 写死在业务代码里Prompt 是最高频变动的配置项之一。把它分散写在多个 Python 文件中后续维护会非常痛苦。建议把 Prompt 统一放到prompts/目录下用单独的文件管理。prompts/ ├── system_testcase.txt └── user_requirement.txt代码中通过读取文件来加载 Prompt。这样调整话术不需要改代码不需要重新发版对非技术同学也更友好。8.2 建立质量评估机制AI 应用不能只看“能不能跑通”还要回答“生成的东西对不对”。建议每个迭代周期抽出部分典型输入人工标注结果质量形成一个小型评测集。评测维度可以包括格式正确率输出能否被安全解析。用例完整度是否覆盖正常、边界、异常三类场景。可执行性预期结果是否明确可断言。安全性是否生成了绕过权限验证等高风险操作。有了评测集每次调整 Prompt 或更换模型都能用数据说话避免“感觉变好了”的主观判断。8.3 始终处理异常与边界输入大模型应用中最常见的生产事故不是模型答错而是调用链偶发异常没有兜底。比如上游 API 超时代码抛异常整个批量任务中断。固定的兜底策略是所有调用入口统一 try-except失败数据落盘关键任务加手动重试队列对用户展示模块使用降级文案。8.4 安全与权限边界要前置如果你的 AI 应用会被企业内部系统调用要考虑以下安全点API Key 不落库、不写日志。对模型生成内容做敏感信息过滤。不让模型直接执行数据库变更、删除等高风险操作。Agent 类应用涉及工具调用时关键操作必须有人工审批节点。调用链路上增加审计日志记录每一轮模型输入和输出。这些安全机制应该在设计阶段就纳入架构而不是等上线前补课。等到评审会上被安全团队挑战再改方案就晚了。8.5 成本与性能要提前设限AI 应用的成本不像普通 API 那么可控。建议在项目初期就做三件事第一按接口维度记录 token 消耗和调用量。第二设置单用户单日配额。第三对相同输入的请求做缓存。没有成本意识的 AI 应用很容易在业务快速增长时吃掉整个项目的利润。这一点在团队内部要达成共识而不是等技术债积累到一定程度才补救。8.6 团队协作保持普通工程规范即使你的系统涉及大模型代码规范也不能例外。代码评审、单元测试、流水线、版本管理这些普通工程的流程AI 项目一个都不能少。一个常见误区是团队认为“AI 生成的代码没办法测试”于是放弃测试。这非常危险。恰恰相反AI 应用更需要测试至少要保证解析逻辑、异常处理、重试机制这几部分有自动化覆盖。9. 总结与后续学习方向回到 36氪在亦庄和杭州抛出的那道题。AI 真问题不是模型不够聪明而是工程化落地还不够成熟。对年轻人来说这恰恰是机会所在当模型能力的差异不断缩小工程能力的差异会成为竞争的核心。沿着这篇文章的示例继续走你至少可以把以下几条线作为下一步的学习方向第一Agent 开发。尝试用同样的思路把一个需求分解成多步工具调用的 Agent 流程并加入人工确认节点。第二模型部署与推理优化。研究私有化场景下如何用开源模型提供稳定的服务。第三RAG 与知识库。让 AI 应用能基于企业内部文档回答真实业务问题。第四评测体系。搭建一个小型评测集用数据驱动的方式持续改进应用效果。AI 应用开发并不是只有“调 API”这一件事它是一个完整的工程体系。如果你现在只会写 Prompt那就从今天开始试着把一整条调用链写出来输入处理、Prompt 管理、模型调用、输出解析、错误处理、结果保存。跑通一次胜过读十篇文章。把这个最小示例跑通之后你会发现所谓 AI 工程化并没有那么玄乎。它更像是在提醒每一个开发者技术越热越要认真做事。