这次我们不看某个开源模型的跑分，也不聊平台新功能，先看一类最近非常常见的视频题材：标题写着“POV：今天早上，AI 取代了我的工作”。视频里通常是一个打工人刚打开电脑，把当天的工作全部丢给一个 AI 助手，几分钟后周报、会议纪要和客户邮件草稿全部生成完毕。画面很爽，弹幕在讨论“那我是不是明天就要失业了”。
但作为一个长期在做本地部署和工程化的人，我更关心的不是剧情，而是这件事的技术本质：视频里那套“AI 自动完成工作”的流程，拆开之后到底是什么？是简单的 LLM 对话，还是 Agent 工作流、工具调用、批量任务和 API 编排的组合？能不能在真实业务里复现？需要什么硬件和软件条件？如果我现在想在自己电脑上搭一个最小可运行的“AI 自动化助手”，应该从哪里开始？
这篇文章会把这个问题讲透。我会先拆解这类视频背后的技术栈，再给出一套通用的 AI 应用开发与本地部署验证路径：环境准备、Agent 工作流启动、功能测试、接口 API 调用、批量任务、资源占用观察和常见问题排查。内容偏工程实践，不渲染焦虑，不吹效果，目标只有一个：让你看完之后，能判断这玩意儿到底值不值得试，以及怎么用最小的成本开始试。
1. 核心能力速览：拆解“AI 取代工作”视频的技术栈
先不评价视频叙事，只看技术。一个号称“AI 取代了我的工作”的演示，通常在几分钟内展示这些动作：读取邮件、整理会议记录、生成日报/周报、草拟回复、汇总 Excel、做 PPT 大纲、安排日程、甚至自动发消息。这些动作看起来是“一个 AI 干的”，实际拆开后是多种能力的串联。
| 视频展示能力 | 背后对应技术 | 真实落地难度 |
|---|---|---|
| 理解任务指令 | 大语言模型（LLM）对话能力 | 低 |
| 读取文档、图片、PDF | 多模态模型 / OCR / 文档解析 | 中 |
| 自动操作软件或网页 | 工具调用（Function Calling）、RPA | 中高 |
| 连续多步完成任务 | Agent 循环：感知 → 决策 → 行动 → 反馈 | 高 |
| 按时间自动触发 | 定时任务 / 消息队列 / Webhook | 低 |
| 一次处理大量文件 | 批量任务脚本 + API 并发调用 | 中 |
| 回答基于私有知识 | RAG（检索增强生成） | 高 |
从这张表能看出关键结论：短视频里的“AI 取代工作”，本质不是某一个模型突然变强，而是工作流从“人在工具之间切换”变成了“程序在 API 之间切换”。真正值钱的部分不是单次对话的流畅度，而是任务拆解、工具打通和异常处理。
另外，输入材料里提到了一个开源项目 AI 小镇（my_ai_town）。这类项目把多个智能体放进一个模拟空间，每个智能体有独立的记忆、状态和行为逻辑。它和“取代工作”的视频有一个共同点：多个 Agent 之间的协作编排已经不再停留在论文里，而是逐渐变成可运行的工程代码。理解了这个背景，再看各类“AI 自动化”演示，你会更清楚地知道哪些可以复现，哪些只是剪辑效果。
2. 适用场景与使用边界：先分清“可自动化”和“不该自动化”
2.1 适合自动化的环节
从工程实践看，下面这些环节最容易先被 AI 自动化接管：
- 信息整理类：会议纪要转结构化文档、邮件分类与摘要、调研资料汇总。
- 文档初稿类：周报初稿、PPT 大纲、方案框架、代码 README。
- 数据清洗类：CSV/Excel 字段补充、格式统一、重复数据标记。
- 客服工单类：FAQ 匹配、工单优先级初判、标准话术草拟。
- 代码脚手架类：接口模板生成、单元测试占位、SQL 初步编写。
这些任务的共同特点是：输入和输出边界相对清晰，错误容忍度可控，而且最后都有人工复核节点。
2.2 不适合自动化的环节
- 需要法律或财务责任判断的决策。
- 涉及重大人事、薪酬、合规结论的最终输出。
- 面向真实用户且无人工审核的对外发布内容。
- 涉及敏感个人信息、未授权数据、版权素材的处理。
这里必须强调：如果你要把 AI 接进真实的业务数据流，请先确认三件事：是否有明确授权；是否对数据脱敏；是否有人工审批出口。尤其是处理邮件、客服会话、内部文档时，账号权限和数据隐私不是技术问题，是合规底线。别为了“演示效果”把真实客户数据直接喂给外部 API。
2.3 从“替代”视角切到“协作”视角
更合理的定位是：AI 负责完成“信息到信息的转换”，人类负责“定义任务、确认标准和承担结果”。视频里那种“早上醒来发现工作被做完了”的叙事，省略了前期的流程设计、测试和兜底机制。作为技术人，正确的姿势是把 AI 当做一个需要编排和治理的新同事，而不是一个魔法黑箱。
3. AI 模型部署与 Agent 工作流环境准备
如果你想自己搭一个最小可运行的自动化工作流，先按下面的清单准备环境。这里给的是通用检查点，具体版本取决于你选择的模型服务方式。
| 检查项 | 推荐配置 | 说明 |
|---|---|---|
| 操作系统 | Linux / macOS / Windows | Linux 相对省心，Windows 需注意路径和进程管理 |
| Python | 3.10 及以上 | AI 工程实践常用版本，建议用 venv 隔离 |
| 包管理工具 | pip / uv / poetry | 推荐 uv，安装快、依赖管理清晰 |
| Docker | 可选 | 部署模型服务或 Redis 队列时更方便 |
| 模型服务 | 本地部署（vLLM/Ollama）或云端 API | 首次验证建议直接用云端 API，降低环境复杂度 |
| GPU | 按本地模型需求选择 | 如果只调接口，CPU 也能完成流程测试 |
| 磁盘空间 | 至少预留 20GB | 本地模型普遍较大，还要留日志和测试素材空间 |
| 端口 | 8000、7860、8080 等 | 提前确认不被占用 |
基础环境验证脚本：
python --version pip --version nvidia-smi # 如果使用本地 GPU，观察驱动和显存状态如果你选择本地部署模型，常见思路是用一个 OpenAI 兼容接口服务，比如 vLLM 或 Ollama。这类服务会把模型包装成标准 HTTP 接口，后续所有 Agent 代码都走同一个协议，替换模型时不需要改业务逻辑。接口地址一般是：
http://127.0.0.1:8000/v1/chat/completions没有现成的本地模型服务时，先用云端 API 完成流程验证，再把 endpoint 切到本地，这是最稳妥的起步方式。不要一上来就追求全本地化。
4. 从“演示”到“工程落地”：搭建最小 Agent 工作流
4.1 场景设定
我们做一个很小的自动化流程，模拟视频里“AI 帮我写工作日报”的效果，但加一个很多人忽略的步骤：人工确认。流程如下：
- 定时读取一个目录下的原始工作记录（比如散装笔记）。
- 调用 LLM 把笔记整理成结构化的日报草稿。
- 输出 JSON 文件到
drafts/目录。 - 程序只负责生成草稿，不自动发送给任何人。
这样做既能体验 AI 自动化的效率，又不会踩“自动发消息给领导”这种危险 demo 的坑。
4.2 核心代码：调用 OpenAI 兼容接口
import os import json import httpx API_URL = "http://127.0.0.1:8000/v1/chat/completions" API_KEY = os.environ.get("AI_API_KEY", "EMPTY") SYSTEM_PROMPT = """ 你是一个职场助理。你的任务是把零散的工作笔记整理成结构化日报。 日报必须包含：今日完成事项、遇到的问题、明日计划。 输出必须是 JSON 对象，不要输出其他文字。 """ def generate_daily_report(note_text: str, model: str = "qwen2.5:7b") -> dict: payload = { "model": model, "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"请整理以下工作笔记：\n{note_text}"} ], "temperature": 0.3, "response_format": {"type": "json_object"} } headers = {"Authorization": f"Bearer {API_KEY}"} try: resp = httpx.post(API_URL, json=payload, headers=headers, timeout=120) resp.raise_for_status() content = resp.json()["choices"][0]["message"]["content"] return json.loads(content) except Exception as e: print(f"[ERROR] generate failed: {e}") return {"error": str(e)} if __name__ == "__main__": sample_note = """ 上午改登录接口 bug，原因是 token 过期判断写反了。 下午评审了订单导出需求，确认用异步任务实现。 明天跟进测试环境部署。 """ result = generate_daily_report(sample_note) print(json.dumps(result, ensure_ascii=False, indent=2))这段代码不需要改就能对着任意 OpenAI 兼容接口跑。如果你用的是 OpenAI 官方 API，把API_URL换成官方地址，把API_KEY换成真实 key 即可。
4.3 JSON 配置文件管理
把目录、模型、温度这类参数抽到配置里，避免在代码里写死：
{ "input_dir": "./notes", "output_dir": "./drafts", "model": "qwen2.5:7b", "temperature": 0.3, "max_retries": 3, "batch_size": 5 }import json with open("config.json", "r", encoding="utf-8") as f: CONFIG = json.load(f) INPUT_DIR = CONFIG["input_dir"] OUTPUT_DIR = CONFIG["output_dir"]4.4 启动方式
如果模型服务是本地部署的，先启动模型服务，再运行业务脚本：
# 启动本地模型服务（以 Ollama 为例，实际命令取决于你的部署方式） ollama serve # 另一个终端运行业务脚本 python daily_report_agent.py如果直接用云端 API，直接运行脚本即可。启动后能看到脚本生成drafts/目录，里面是格式化后的日报 JSON，这就是“AI 自动化工作流”的最简可运行版本。
5. AI 应用开发中的功能测试与效果验证
工作流跑通之后，重点不是看它生成得“像不像”，而是测试它的稳定性和边界。下面是一套可以直接照做的测试方案。
| 测试维度 | 测试方法 | 判断成功标准 |
|---|---|---|
| 指令理解 | 输入不同风格的工作笔记 | 输出结构基本稳定，不丢失关键事项 |
| 输出格式 | 连续调用 20 次，检查 JSON 能否被解析 | JSON 解析成功率 100% |
| 多轮稳定性 | 相同输入跑多次，对比结果差异 | 核心信息一致，表达差异可接受 |
| 长文本 | 输入一篇超过 3000 字的会议记录 | 不截断、不遗漏章节结构 |
| 异常输入 | 输入空文本、纯符号、乱码 | 不崩溃，返回可读的错误提示 |
| 批量任务 | 一次性处理 10 份笔记文件 | 全部生成结果，失败文件有记录 |
5.1 批量文件处理脚本
在真实 AI 工程实践里，单次调用只是第一步，批量处理才是常态。下面这个脚本会遍历notes/目录下的所有.md文件，逐条调用接口并保存结果到drafts/：
import json import time import pathlib from daily_report_agent import generate_daily_report def process_dir(input_dir: str, output_dir: str, batch_size: int = 5): input_path = pathlib.Path(input_dir) output_path = pathlib.Path(output_dir) output_path.mkdir(parents=True, exist_ok=True) files = list(input_path.glob("*.md")) total = len(files) success_count = 0 for i in range(0, total, batch_size): batch = files[i:i + batch_size] for file in batch: note_text = file.read_text(encoding="utf-8") result = generate_daily_report(note_text) out_file = output_path / f"{file.stem}_report.json" out_file.write_text( json.dumps(result, ensure_ascii=False, indent=2), encoding="utf-8" ) if "error" not in result: success_count += 1 else: print(f"[WARN] {file.name} failed") time.sleep(1) # 控制并发，避免触发限流 print(f"progress: {min(i + batch_size, total)}/{total}") print(f"done, success: {success_count}/{total}") if __name__ == "__main__": process_dir("notes", "drafts", batch_size=3)5.2 预期输出与失败排查
运行成功后，drafts/下会出现类似这样的 JSON：
{ "今日完成事项": [ "修复登录接口 token 过期判断问题", "评审订单导出需求，确认使用异步任务" ], "遇到的问题": [ "前期 token 过期判断逻辑写反，已修正" ], "明日计划": [ "跟进测试环境部署" ] }如果输出不是有效的 JSON，先检查两件事：
- 模型是否支持
response_format的 JSON 模式。不支持时，去掉该字段，改在 system prompt 里强制输出 JSON。 - 上下文是否过长。超长输入可能导致输出被截断，先缩短输入再测试。
6. 接口 API 与批量任务设计
6.1 通用 API 调用示例
无论你用的是本地模型还是云端 API，标准接口调用方式都类似：
curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer EMPTY" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "写一句话介绍你的功能"}], "temperature": 0.7 }'这是最通用的 OpenAI 兼容调用格式，适配大多数本地和云端模型服务。如果你的接口不是这个协议，需要按实际项目文档调整。
6.2 批量任务的队列与重试设计
当任务数量从 10 个涨到 1000 个，就不能再用简单的for循环了。建议至少做到：
- 任务列表持久化：把待处理文件记录到 JSONL 或数据库。
- 失败重试：对限流、超时、网络抖动做重试，一般重试 3 次。
- 幂等输出：同一次输入重复执行不产生重复结果，输出文件名固定即可。
- 日志完整：记录每个文件的调用时间、token 数、成功与否。
示例任务记录格式：
{ "task_id": "20250218_001", "input_file": "notes/meeting_0217.md", "status": "pending", "retry_count": 0, "created_at": "2025-02-18T10:00:00+08:00" }需要说明：这个格式是我在项目里常用的通用模板，并不属于某个固定平台规范。你在工程化时可以直接复制，再按自己的业务字段修改。
7. AI 工程实践：资源占用与性能观察
7.1 怎么观察资源占用
如果你跑的是本地模型，至少要看两样东西：GPU 显存和 CPU/内存使用。
nvidia-smi -l 2 # 每 2 秒刷新一次 GPU 状态也可以直接用 Python 在脚本里采样显存：
import subprocess def get_gpu_memory(): result = subprocess.run( ["nvidia-smi", "--query-gpu=memory.used,memory.total", "--format=csv"], capture_output=True, text=True ) print(result.stdout)具体显存占用取决于模型参数量、量化精度、上下文长度和并发数，我这里不写死某个数字，原因是同一个模型在不同推理框架下的占用差异很大。正确做法是：启动服务前记录一次空闲显存，跑一次长文本任务后再看一次，差值就是基础占用。
7.2 CPU 推理和 GPU 推理的差异
- GPU 推理：速度快，适合交互式 Agent 和批量并发，但显存有上限。
- CPU 推理：部署环境简单，适合小模型和低并发测试，但性能明显偏慢。
- 混合方案：小模型用 CPU 也能跑，大模型建议至少有独立 GPU。
7.3 影响性能的关键参数
- 上下文长度：输入越长，预填充耗时越长，也是显存占用的主要推手。
- 批量大小：
batch_size提高能提升吞吐，但显存占用会同步上涨。 - 温度采样：
temperature不影响速度，但影响结果稳定性。 - 并发请求：并发过高会触发限流或 OOM，第一次跑先并发 1，再逐步提。
7.4 降低资源占用的通用做法
- 用小模型做初筛，大模型做精修，形成两级流水线。
- 对超长文档先做切片，只把相关片段送到模型里。
- 减少不必要的 few-shot 示例，节省 token。
- 批量任务做好队列限流，不要一次性塞满所有并发。
8. AI 自动化工作流常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 接口调用超时 | 模型推理慢或网络延迟 | 查看服务日志和请求耗时 | 调长 timeout，缩小输入，换更小模型 |
| 返回内容不是 JSON | 模型不支持 JSON 模式 | 检查接口文档和 response_format | 去掉该字段，改为在提示词中强制指定 |
| 生成内容出现幻觉 | 长文本或上下文不足 | 对比输入和输出，检查信息是否多出 | 增强提示词约束，加入外部知识库，人工复核关键内容 |
| 批量任务中途卡住 | 其中一个文件异常阻塞 | 看日志找到卡住的文件 | 给每个任务加超时和异常捕获 |
| GPU 显存不足 | 模型过大或并发过高 | 观察 nvidia-smi | 降低 batch_size，换量化模型，减少上下文 |
| 端口被占用 | 本地服务冲突 | lsof -i:8000或netstat -ano | 换端口或杀掉旧进程 |
| 自动发送导致误发 | 流程缺少人工审批 | 检查代码中的发送逻辑 | 先输出草稿，人工确认后再发送 |
| 输出质量不稳定 | 提示词指令不清晰 | 多次测试同一提示词 | 固定 few-shot 示例，降低 temperature |
AI 幻觉是整个排查表里最值得注意的一项。工作流里只要有“自动把结果写进邮件/文档/工单”的环节，就必须加一层校验：让模型先输出可解析的数据，再写一份人工可读摘要，最后由人按下发送键。
9. 给技术人的务实建议：把 AI 改造成同事，而不是对手
看完这整条链路，你应该已经意识到：真正复杂的工作不是“让 AI 说一句话”，而是把“一句话”变成一个可靠的工作流。下面几条是我在做 AI 应用开发和模型部署时的通用原则，建议直接收藏。
9.1 先跑最小闭环
不要一上来就设计十个 Agent 的编排系统。先做单 Agent + 单脚本 + 单文件夹，跑通一个真实的日常任务。比如把“整理今日待办”做成脚本，核心代码不超过 50 行。跑通之后再加定时触发、加队列、加多工具调用。
9.2 输入、输出、日志分目录管理
project/ ├── notes/ # 原始输入 ├── drafts/ # 生成结果 ├── logs/ # 运行日志 ├── config.json # 配置文件 └── scripts/ # 脚本目录这个结构适用于绝大多数自动化任务，方便排查问题，也方便后续接入 CI/CD 或定时任务。
9.3 给关键流程加熔断
如果 AI 连续失败 N 次，应该停止批量调用，而不是继续把错误结果写进文件。最简单的做法是在脚本里记一个失败计数器，超过阈值就发一封告警邮件或打印明显错误。
9.4 用好 AI 编程，节省重复劳动
与其担心“AI 取代编程”，不如先把 AI 编程当作重构重复劳动的杠杆。通用代码模板、正则表达式、SQL 查询、配置脚本这类任务，交给 AI 写了之后做 code review，你会发现自己的注意力能更好地放在架构和边界设计上。
9.5 明确人机分工
所有 AI 自动化系统都建议遵守一个原则：AI 生成内容，人来做决策和发布。也就是说，输出存在drafts/和输出直接发到公司群，是两套完全不同的系统。前者是效率工具，后者是风险敞口。
10. 总结与下一步
回到标题：一个 POV 视频说“AI 今天早上取代了我的工作”。看完上面的技术拆解，你应该能得出自己的结论：AI 能取代的不是“你”，而是“信息在工具间搬运”这个环节。真正的工作不会消失，但工作流一定会被重新设计。
对你来说，最值得现在做的事很简单：找一个小而重复的任务，用文中第一节的能力拆解方法判断它属于哪一类，然后照着第二节到第六节的环境准备、代码启动、功能测试和批量任务方案，搭一个最小可运行版本。先验证输出格式，再验证批量稳定性，最后再考虑是否接入真实业务。
最容易踩的坑有两个：一是跳过人工审批直接全自动发布，二是一开始就想做多 Agent 大系统。避开这两点，AI 自动化工作流大概率能帮你省下不少重复劳动时间。
如果你已经开始搭自己的第一套 Agent 工作流，建议收藏这篇文章，把环境准备清单、批量任务脚本和排查表复制下来，跑完一个任务再回头看，会发现很多细节只有在真机测试里才能暴露出来。
