我一直觉得，“AI工程”听起来特别高大上，但实际上它离我们普通开发者的日常特别近。今天想聊的，就是这个从零开始的完整过程：怎么从只会写几个Python脚本，到能独立搭出一个有数据、有模型、有测试、能上线的AI工程。我自己走这条路时踩过不少坑，最开始以为是要去啃一堆算法论文，后来才发现，真正的门槛根本不是算法，而是你能不能把一整套流程管起来。
如果你正打算做AI项目，或者已经在做但总觉得乱，这篇文章应该能帮上忙。我会从最基础的项目骨架讲起，一路聊到数据清洗、Prompt Engineering、AI Agent、测试评估和上线监控。核心目标只有一个：让你能复现、能迭代、能上线，而不是永远停留在“能跑通”的阶段。
1. 先想清楚：AI工程到底是“工程”还是“算法”
很多初学者一听到“AI工程”，第一反应就是学PyTorch、学Transformer，然后疯狂调参。我自己踩过这个坑。第一个项目是一个文本分类任务，我在模型上花了两周，反复调学习率、层数，效果一直卡在80%左右。后来把原始数据翻开看了一眼，发现标注错误率超过10%。那一刻我突然意识到，AI工程的第一关键不是模型，而是你和数据的关系。模型只是把数据里的规律抽取出来，如果数据本身就是乱的，再强的模型也只能学到乱规律。
AI工程和算法研究的区别，可以类比成盖房子和做装修。算法研究可能是在实验室里打磨一种新型材料，而AI工程是从地基到水电，再到软装，把整个系统稳稳当当地搭起来。用户反馈、线上数据回流、成本控制、版本迭代，这些都属于工程问题，任何一个环节没跟上，项目都会翻车。
1.1 大多数人的误区：把AI工程当成炼丹
这里说的“炼丹”，就是那种不断改参数、跑实验，指望模型效果突然变好的状态。我以前也这样：没有弄清楚问题是什么，就开始选模型、调参，最后结果不好只能怪硬件不行、数据不够。后来我明白了一个道理：如果你不能用规则或者简单方法把问题描述清楚，那你大概率也不会用AI解决它。
举个例子，假设你要做一个客服工单自动分类。你连“工单类型有哪些”“什么算支付问题，什么算退费问题”都没定义清楚，就直接丢给模型，那模型给你乱分是很正常的。反过来，如果你先把问题拆细，再在提示词或者模型输入里把这些约束表达清楚，效果会立刻稳定不少。
我个人的习惯是，做任何AI功能前，先强迫自己写一段伪代码或者业务规则。如果这段规则写得出来，后面的模型方案基本能成；如果写不出来，那先别急着上AI，回去把需求问清楚。
1.2 从零开始前要补的三个基本功：数据、评估、流程
如果真要从零开始，我不会让大家先冲模型，而是先补三样基本功：数据、评估、流程。
数据是AI项目的粮食。这里说的数据不只指训练集，还包含测试集、验证集、用户实时反馈。数据能力包含怎么收集、怎么清洗、怎么做标注规范、怎么防止数据泄漏。我见过太多项目，模型在测试集上准确率到了95%，上线后直接掉到70%，很大概率就是测试集和训练集混在一起了。这种问题特别隐蔽，因为报错不会报，你只能通过效果对比去怀疑。
评估是这个项目能不能继续迭代的标尺。很多人说“效果感觉不错”，但感觉不能作为标准。你需要把它拆解成准确率、召回率、F1、人工抽检通过率这些指标。而且评估集一定要从真实业务场景里抽，不能只在网上找现成的公开数据集，因为公开数据和你业务里的实际数据分布差太远，测出来的数字根本不是真实水平。
流程是AI工程的骨架，包括需求分析、数据准备、建模或提示词开发、评估、上线、监控、迭代。看着像废话，但绝大多数失败项目死就死在流程缺失。比如上线前才发现没有日志，出了问题根本无从排查；又比如没有配置管理，代码改到哪一版都不知道。
从零开始，我的建议是：先拿一个能出效果的小项目，把整个流程跑通一遍，哪怕只是一个简单的规则分类器。关键是让你脑子里产生那条完整链路，后面的模型再复杂，也只是在替换链条里的某个环节而已。
2. 从零搭建一个可复现的AI项目骨架
项目骨架的作用，是让所有东西都有地方放、有迹可循。很多人写AI代码喜欢把所有逻辑塞进一个notebook里，跑完就丢。这种方式做实验可以，做工程绝对不行。因为两周后你根本记不住哪里调了参数、哪里改了数据处理逻辑。
我自己的做法是，从第一天就按照工程标准来搭目录。这样看起来麻烦，但一旦项目进入迭代期，回报会非常明显。
2.1 项目目录怎么设计才不后悔
下面这个结构是我多次调整后留下的习惯版本，适合大多数组件化的AI项目：
ai-engineering-from-scratch/ ├── data/ │ ├── raw/ # 原始数据，只读，不改动 │ ├── processed/ # 清洗后的数据 │ └── samples/ # 小样样本，用于调试 ├── src/ # 项目核心代码 │ ├── data_processing/ # 数据清洗、转换 │ ├── models/ # 模型封装、调用逻辑 │ ├── agents/ # Agent相关代码 │ ├── prompts/ # 提示词模板 │ └── evaluation/ # 评估逻辑 ├── configs/ # 所有配置文件 ├── tests/ # 单元测试、回归测试 ├── scripts/ # 训练、评估、上线脚本 ├── notebooks/ # 探索性分析 ├── logs/ # 运行日志 ├── models/ # 本地模型文件（占位） └── reports/ # 评估报告、实验记录为什么要把data/raw单独放？因为原始数据是唯一不可再生的资产，任何清洗、转换都不应该覆盖它。哪怕你后来清洗逻辑写错了，只要原始数据还在，就能重来。反之，如果直接对着原始文件改，出错后就再也找不回来了。
cuisines/这类目录名我用过一段时间，后来发现太容易引起歧义。干脆叫configs/，里面放dev.yaml、prod.yaml、default.yaml，简单直接。配置和代码分开是工程里的老规矩，AI项目也一样。
2.2 环境与依赖管理：虚拟环境、版本锁定
Python项目第一步永远是创建虚拟环境。我见过太多人图省事，直接在全局环境里pip install，结果不同项目之间包版本互相冲突，最终只能重装系统。正确做法是给每个项目单独建一个环境：
python -m venv venv source venv/bin/activate pip install -r requirements.txt这里的requirements.txt只写顶层依赖，比如openai>=1.0、transformers>=4.0。等你确定某个版本跑起来没问题，再执行一次pip freeze > requirements.lock，把完整版本锁住。为什么要锁？因为AI生态变化太快，今天transformers 4.30能跑的代码，换到4.50可能就因为API改动直接报错。版本锁定是你保证“昨天能跑的代码今天还能跑”的唯一办法。
我在实际项目里常用这样的对比：
| 文件 | 作用 | 更新时机 |
|---|---|---|
| requirements.txt | 顶层依赖，给人看 | 添加新依赖时 |
| requirements.lock | 完整依赖，给机器看 | 每次环境稳定后 |
如果项目里用到了模型权重文件或者大的数据文件，别塞进Git仓库。用.gitignore把models/、data/raw/、logs/过滤掉，依赖和代码才适合进版本管理。
2.3 配置管理和实验记录：把每次调试变成可回放的历史
配置管理是AI工程里最容易被忽略、但最值钱的一环。我的第一个正经AI项目因为没有记录配置，出现过一种很尴尬的情况：模型效果不错，但准备上线时，怎么都复现不出同样的效果。原因是中间某次调参改了学习率，代码里却没保存对应版本。最后只能靠回忆，白白浪费了好几天。
所以现在我一定会用一个配置文件来集中管理所有可变参数。最简单的做法是config.yaml加一个 dataclass 加载：
model: name: gpt-4o-mini temperature: 0.2 max_tokens: 1024 data: raw_path: data/raw/orders.csv processed_path: data/processed/orders_clean.csv eval: golden_set_path: data/samples/golden_set.jsonl然后在代码里加载：
from pydantic import BaseModel class ModelConfig(BaseModel): name: str = "gpt-4o-mini" temperature: float = 0.2 max_tokens: int = 1024 # config.yaml -> config对象 import yaml with open("configs/dev.yaml") as f: raw = yaml.safe_load(f) model_config = ModelConfig(**raw["model"])别小看这个步骤。有了配置文件，你调参时只用改YAML，不用动代码。每次实验还会额外记录一个文件，比如experiment_log.csv，每次改动都往里面追加一行，字段至少包括：时间、Git commit、数据版本、模型名称、关键指标。这样两周后你回来看，每个数字都有出处。
经验：哪怕懒得用MLflow或者Weights & Biases，也一定在项目里留下一个
experiment_log.csv。这可能是你做过的最划算的工程投资。
3. 核心环节：数据、模型选择与提示词工程的交接
项目骨架搭好之后，接下来就是实打实的业务逻辑了。这个阶段最核心的活，其实不是“写模型代码”，而是把数据和模型之间的交接处理好。交接不好，后面全是窟窿。
3.1 数据清洗与构建：没有好数据，模型就是花瓶
数据清洗这件事，听着不酷，但它决定AI项目的生死。我见过有人拿到数万条用户评论，直接丢给模型做情绪分类，结果准确率惨不忍睹。后来发现，数据里有一堆HTML标签、重复文案、乱码，模型学到的全是噪音。
我的清洗流程一般是这样：
- 去重：
df.drop_duplicates(subset=['text'])，防止同一条数据反复出现影响分布。 - 格式统一：全角半角、大小写、换行符统一处理。
- 噪音过滤：去掉URL、无意义符号、过长或过短的文本。
- 抽样统计：随机看几百条，确认标注质量。
- 切分数据：按时间或ID哈希切分，保证测试集不泄露。
有个细节特别容易翻车：数据切分。如果你直接train_test_split(random_state=42)，把同一个人或者同一个用户的多条文本同时分进训练集和测试集，那模型其实已经“见过”测试数据了。正确的做法是先按用户ID分组，再把用户分成训练组和测试组。这时候模型面对的是完全没见过的人，效果才真实。
在LLM时代，数据清洗的意义其实被很多人低估了。你以为模型自己啥都能处理，但它处理不了你给它的上下文里全是重复、矛盾、格式混乱的内容。清洗后的数据，不仅喂给微调模型有用，喂给Prompt模板也一样重要。干净的数据会让输出稳定不少。
3.2 模型选型：什么时候该调模型，什么时候该调提示词
很多人上来就问“该用哪个模型”。我的回答通常是：先想清楚你是要“解决问题”还是“追求前沿”。如果是前者，能用提示词解决的，就别急着微调；能用小模型解决的，就别上大模型。
可以看这个对照表：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 简单分类、抽取，数据量不大 | 提示词 + 中/小模型 | 成本低、迭代快 |
| 需要固定输出格式、强逻辑 | 提示词 + 结构化解码 | 稳定可控 |
| 领域数据丰富，开源模型可用 | 微调开源模型 | 数据隐私和成本有优势 |
| 任务极其复杂，需要深度推理 | 大模型API + Agent | 能力上限高，但成本高 |
我个人的经验是，优先用现成API跑一个Prompt版本，哪怕效果差点，也能把你对任务的理解固化下来。等业务跑通了，再评估要不要换模型、要不要微调。千万不要一开始就想着训练一个专属模型，那个成本极高，而且最后效果往往没比好好写提示词好多少。
选型时还有几个工程指标必须看：时延、吞吐、成本、上下文长度。有时候大模型效果确实好，但线上用户等不了三秒才看到回复，那就得考虑模型蒸馏或者在关键词场景用小模型先顶一版。
3.3 Prompt Engineering实战：从零把提示词调到可用状态
提示词工程不是玄学，它有很清晰的套路。我常用三段式结构：角色、任务、约束。再加一到两个示例，效果立刻不一样。
拿客户评论分类举例，一个能用的Prompt长这样：
你是一个电商客服质检助手。 任务：把下面的用户评论分类为“物流问题”“质量问题”“退换货需求”“其他”四类。 约束： - 只返回分类名称，不要解释。 - 如果评论包含多个问题，选择最核心的一个。 - 如果无法判断，返回“其他”。 示例： 评论：快递三天没动，客服也不回话。 -> 物流问题 评论：收到的衣服拉链坏了，想换一件。 -> 退换货需求 请分类： 评论：这个杯子颜色和图片有色差，不过客服态度很好。这个Prompt看起来普通，但每一项都有目的。“角色”给模型一个定位，“任务”明确要做什么，“约束”把输出的边界框死，“示例”则是少样本学习，让模型明白你的格式偏好。如果缺少约束，模型很可能输出成一段话而不是简单分类，解析起来就很麻烦。
复杂任务还能再加一步“思维链”提示。比如让模型先列出推理过程，再给结论。不过要注意，启用思维链会增加Token消耗，如果业务场景只要快速结果，没必要每次都让它慢慢推理。
温度参数也很关键。分类、抽取这类确定性任务，我基本设到0；需要创意文案或者头脑风暴，才会调到0.8左右。很多不稳定的输出，其实不是Prompt写得差，而是温度太高导致模型随机性太大。
4. AI Agent与工作流：从单次调用到多步任务
现在做AI项目，单次模型调用往往不够用。真实业务里经常要模型“调用工具”“记住前文”“完成多个步骤”，这就需要Agent。从工程角度看，Agent不是魔法，它就是一个可控的任务调度系统。
4.1 Agent的基本结构：模型、工具、记忆
可以把Agent想象成你请的一个实习生。实习生很聪明，但需要你给他任务目标、办公工具和会议记录。对应到技术上就是三件事：
- 模型：负责决策，判断下一步该做什么。
- 工具：模型可以调用的函数，比如搜索、查询数据库、发邮件。
- 记忆：保存对话上下文和历史操作，让模型不会忘记前面说了什么。
工程上，你需要定义一个“工具清单”，让模型只能调用白名单里的函数。比如：
def get_weather(city: str) -> str: """查询城市天气""" return f"{city}今天阴天，最高22度。"Agent拿到用户问题“北京天气怎么样”，先规划调用get_weather(city="北京")，拿到结果后再组织回答。这个过程可以用while循环实现：模型输出函数名和参数 -> 代码解析 -> 执行工具 -> 把结果再喂回模型 -> 判断是否结束。
这个循环看起来简单，但隐藏着很多工程细节。比如模型可能乱编参数、可能陷入死循环、可能在工具调用几次后忘记原始任务。所以工程上必须给Agent加上“最大迭代轮数”“单次超时”“Token预算”这些硬约束。这也是AI工程和单纯聊天的最大区别：你要为失控做准备。
4.2 一个完整案例：用CodeBuddy实现Harness Engineering思路
Harness Engineering，可以理解为给AI应用装上“安全护栏”和“控制机制”。核心思想是：只给模型有限的工具和权限，并且在每一次调用前后都做校验。这个思路特别适合用AI编程工具来实现，我自己就用CodeBuddy辅助写过一版。
举个例子，我想要一个能查天气和订单状态的Agent。先明确工具白名单，只允许查天气和查订单，不允许访问其他数据。然后让CodeBuddy帮我生成一个简单的Harness框架：
import json from typing import Callable, Dict TOOLS: Dict[str, Callable] = { "get_weather": get_weather, "get_order_status": get_order_status, } MAX_STEPS = 5 def run_agent(user_query: str): messages = [{"role": "user", "content": user_query}] for step in range(MAX_STEPS): response = model_chat(messages) if response.is_final_answer: return response.content tool_call = parse_tool_call(response.content) if tool_call.name not in TOOLS: return "Error: 工具不在白名单内" if not verify_args(tool_call.args): return "Error: 参数校验失败" result = TOOLS[tool_call.name](**tool_call.args) messages.append(response) messages.append({"role": "tool", "content": json.dumps(result, ensure_ascii=False)}) raise TimeoutError("Agent达到最大轮次")粗看可能觉得代码多，但有几个点特别关键。MAX_STEPS避免模型无限循环；verify_args避免模型传明显非法参数；工具白名单意味着即使模型“想”调用别的功能，也没有对应的入口。这些就是Harness Engineering的实践：你不依赖模型自觉，而是用代码把行为边界焊死。
用CodeBuddy辅助的好处是，这类重复的工程模板生成很快。你可以直接告诉它：“我要一个Agent，只能调用这两个函数，最大迭代5次，输出必须是JSON格式”，它就能给你一个可复用的骨架。然后你再根据自己的业务逻辑去改。
4.3 多AI协作与工作流的编排：别让Agent变成脱缰野马
单个Agent能力有限，所以现在大家喜欢让多个Agent协作。比如一个Agent负责理解用户意图，一个负责检索资料，一个负责写初稿，一个负责审核。这个想法很好，但工程复杂度成倍上升。
多Agent协作最怕什么？最怕级联失败。A Agent输出乱了，B Agent基于乱输出继续处理，结果越来越离谱。所以编排层必须做到：每一步都有超时、每一步都有校验、每一步都写日志、每一步都有预算。
我给你推荐一个务实的做法：先把Agent之间的“接口协议”定义清楚，比如都用JSON传输，字段包含status、data、error。这样任何一个Agent出错，上层都能立刻感知并中断。千万不要让Agent之间直接传自然语言，那样你根本没法做断言和测试。
另外，多AI协作里一定要有人类审批的关键节点。比如在自动回复用户之前，加一道“置信度低于阈值则转人工”的规则。这不是不信任模型，而是工程上的风控意识。很多线上事故，都是在最后一个环节缺了人为开关导致的。
工作流编排工具方面，LangGraph、LangChain、自研状态机都可以。我的建议是，如果团队小、业务简单，自己写一个状态机反而最清晰。外部框架虽然灵活，但出了问题排查起来特别费劲。
5. 测试、评估与上线：工程化的分水岭
代码写出来能跑，不等于能上线。AI工程和普通后端开发最大的区别，就是模型输出的不确定性。普通函数你写return 1+1，永远得到2；模型你让输出JSON，它某天可能多给一段解释。所以测试和评估，才是AI工程的分水岭。
5.1 离线评估：用评测集给模型打分
离线评估的道理很简单：准备一批标注好的输入输出对，每次改动后让模型跑一遍，用固定指标衡量效果。和训练好的模型相比，这更像是一个针对Prompt和工具链的“期末考”。
我习惯先做一个Golden Set（黄金评测集），规模不需要大，50到100条就够。关键是覆盖面要广：典型场景、边界场景、易错场景都要有。比如客服分类里，“申请退款”和“投诉并退款”必须同时存在，不然模型很可能把第二种也归成单纯投诉。
每次改动Prompt、换模型、加工具，都在Golden Set上跑一遍，记录准确率变化。这个过程要自动化，最好一个脚本能出结果：
python scripts/run_eval.py --config configs/dev.yaml输出类似：
Accuracy: 0.92 Precision: 0.90 Recall: 0.93 F1: 0.91有了这个脚本，你就不怕“感觉变好了但不知道变好多少”。在AI工程里，没有数据的评价都是耍流氓。
生成式任务的评估会更难一点。除了人工打分，可以用关键词命中、相似度计算等辅助指标。如果预算允许，也可以用更强的模型当裁判，但要注意自己的模型可能存在偏好。核心是：评估要和业务目标对齐，你要的是用户满意，不是单个指标好看。
5.2 测试开发：给AI应用写单元测试和回归测试
很多人觉得测试是传统开发的事，AI项目不用测。这是大错特错。AI项目的测试不仅要做，还要做得更细。因为你不仅要测业务逻辑，还要测模型输出结构。
最典型的例子是解析模型返回的JSON。模型偶尔会返回带前后缀的文本，比如json ...，如果你直接json.loads，就会抛异常。正确的做法是用一个健壮的解析函数，把杂讯剥掉。然后给这个解析函数写测试：
import pytest def test_extract_json_with_code_block(): raw = '```json\n{"status": "success"}\n```' assert extract_json(raw) == {"status": "success"} def test_extract_json_with_extra_text(): raw = '好的，结果是：{"status": "success"} 请查收' assert extract_json(raw) == {"status": "success"}这种测试价值极高。因为AI工程的坑往往不是一次性的，而是模型每次输出都有微小变化。如果你没有一个“契约测试”帮你在源头拦截，等到了下游再发现解析失败，定位成本会非常高。
另外，给Prompt模板也要建版本。我见过一个项目，某次同事顺手改了一个字，整体效果掉了5个点，但没人发现。后来把Prompt模板纳入版本管理，并且每次修改都强制跑一遍Golden Set，才止住这个风险。
5.3 可观测性：日志、追踪和成本监控
上线前必须做可观测性。AI应用和普通服务一样，需要日志、指标、追踪。但AI项目多了一个特别重要的指标：Token消耗。
每次请求，都应该记录类似下面的结构化日志：
{ "request_id": "req_20250101_abc", "timestamp": "2025-01-01T12:00:00Z", "model": "gpt-4o-mini", "prompt_tokens": 320, "completion_tokens": 180, "latency_ms": 850, "status": "success", "error": "" }有了这些日志，出问题时你能立刻回答三个问题：调用了什么模型？花了多少钱？用了多久？
成本监控尤其重要。很多人上线前只看模型效果，上线后才发现成本超出预算。算笔账：假设每天1000次请求，每次输出500个token，不同模型价格不一眼，但API按千万token计费时，这个量级可能一天也要几十上百元。如果Agent内部还循环调用了好几次，成本就不是线性增长，而是成倍上涨。
所以我建议给Agent设置“单次会话最大Token预算”，比如3000。达到预算就强制中断，让用户简化问题或者转人工。这既保护成本，也保护用户体验。
6. 常见问题与排查技巧实录
AI项目上线后，大概率会遇到一些反复出现的坑。我整理几个最常见的问题，附上排查思路，应该能帮你节省不少时间。
6.1 模型输出不稳定：是温度参数还是提示词问题？
模型输出不稳定的现象很典型：同一个问题，隔几分钟问一次，答案变了。第一步先检查温度参数，如果它大于0，先把温度改成0，再看输出是否稳定。如果稳定了，就是随机性问题；如果还不稳定，大概率是提示词里给了模型太多自由裁量空间。
我之前遇到过一个客服机器人，经常在长回复里莫名插入Markdown格式，断断续续。排查半天发现，系统消息里写的是“可以使用Markdown”，模型把它当成了一个可选动作。改成“必须使用纯文本，不要Markdown”后，问题立刻消失。所以提示词里要尽量用“必须”“禁止”，而不是“可以”“最好”。
如果你的输出是结构化数据，务必启用JSON模式或者正则约束。不要指望模型自己记住“只输出JSON”，它会被上下文带跑。工程上要双保险：提示词约束加上解析层兜底。
6.2 效果突然变差：数据漂移与缓存失效
线上效果变差，先别急着怀疑代码。我看过太多人调试了半天模型，最后发现是上游数据接口的字段名变了。所以排查顺序应该是：先看输入数据，再看依赖服务，然后才轮到模型本身。
数据漂移在AI项目里很常见。比如你训练时用户评论都是中文，线上突然涌进来一批英文评论，模型没见过，自然表现差。这时候你需要监控输入数据的分布变化，比如关键词频次、文本长度分布，一旦偏离基线就自动告警。
缓存失效也是一个隐性问题。如果你的Agent在每一步之间用了Redis缓存，前段时间缓存命中率高，响应很快；后来数据量大增或者缓存过期，命中率下降，外部调用变多，表现为响应变慢。这时候查日志里各个调用耗时，很快就能找到瓶颈。
6.3 工程调试清单：十分钟定位问题
这里放一个我实际用的速查表，排查时可以对照：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 响应超时 | 模型API慢、网络波动、重试过多 | 看追踪耗时，增加超时与熔断 |
| 输出乱码、JSON解析失败 | 模型输出格式漂移 | 增强提示词约束，加解析兜底 |
| 成本飙升 | 单次会话Token超预算、循环调用 | 设置最大轮次和Token上限，看日志统计 |
| 效果下降 | 数据分布变化、Prompt被改 | 对比Golden Set，检查配置变更记录 |
| Agent卡死 | 循环调用、工具无返回 | 加最大迭代，给工具加超时 |
还有一个个人技巧：给项目准备一个“一键烟测脚本”，把核心场景的输入输出写死，每次改动上线前先跑一遍脚本，确认整体流程没断。这个脚本不要和你正常的评估脚本重叠，它只做连通性检查，能快速暴露环境、配置、依赖问题。
一些最后的体会
从零开始做AI工程，真正改变我的不是某一次模型效果突破，而是一种习惯的养成：不管上下游多复杂，都要让每次实验可复现、每次结果可衡量、每次问题可追踪。这个过程确实平淡，远没有“训练出个大模型”听起来刺激，但它才是工程落地最有价值的部分。
最后再分享一个小技巧：如果你还在“从零”阶段，不要一次性追求完美架构。先做一个能跑通的最小版本，哪怕就是玩一个分类、写一个输出模板，也把它放到项目骨架里走一遍完整流程。你会发现，当流程成为习惯时，后面加Agent、加测试、加监控，都只是往里填东西而已。
