AI仍是电灯泡？从替代到流程再造的电网思维

最近看完吴妈的演讲，有一个比喻一直在我脑子里转：今天的 AI，可能还只是电灯泡。

这个比喻乍一听有点反直觉。毕竟现在的 AI 能写文案、能改代码、能做图、能当搜索引擎用，怎么看都不只是一个“照明工具”。但仔细想想，我们绝大多数人——包括我自己——用 AI 的方式，其实和一百多年前的人们用电灯泡的方式一模一样：家里每个房间装一盏灯，按一下开关，它亮了，仅此而已。人们并没有因为电灯的出现，就立刻去重构家里的电路、改造整个城市的电网，也没有去发明洗碗机、洗衣机和智能家居。这中间隔着的，不是一个更亮的灯泡，而是一个全新的“用电体系”。

这篇文章我想借着这个比喻，把最近一年多我在 AI 工程实践、AI Agent 落地、模型部署和 AI 辅助研发这些方向上的真实感受整理一下。我会聊清楚三件事：第一，为什么说今天的 AI 还停在“电灯泡阶段”；第二，从“灯泡”走向“电网”，也就是真正把 AI 嵌入工作流和业务系统，到底差在哪几步；第三，落地过程中我踩过哪些坑、总结过哪些可以直接抄作业的经验。如果你也正在纠结“AI 到底能干什么”“Agent 和工作流是不是噱头”“要不要自己部署模型”这类问题，这篇文章应该能给你一份比较踏实的参照。

1. 电灯泡阶段：今天的 AI 到底“灯”在哪里

1.1 大多数人还在“用灯泡替代煤油灯”

电灯泡刚被发明出来的时候，普通人是怎么用它的？答案是：按照煤油灯的使用习惯来接电路。灯挂在原本挂煤油灯的位置，开灯的时候还是一个房间亮一盏灯，甚至有人按煤油灯的形状去做电灯的玻璃罩。使用场景没有被重新想象，只是把发光的能源换了。

今天的 AI 其实也在经历这个阶段。我观察到的绝大多数 AI 用法，本质上是“任务替代”而不是“流程再造”：

• 以前用搜索引擎查资料，现在让 ChatGPT、DeepSeek、Kimi 这类大模型直接“答一个结论”；
• 以前自己写周报、写邮件，现在把要点丢给 AI，让它扩写成正式段落；
• 以前让实习生初筛简历，现在把一堆 PDF 丢给 AI 做摘要；
• 以前自己写一小段工具代码，现在让 AI 直接生成脚本。

这些用法都很真实，也都有效。但它们和“把煤油灯换成电灯泡”没有本质区别——你在用一个更高效的工具，去替换原本用另一个工具完成的任务。任务本身没有变，任务的产出形态没有变，连你检查产出的方式都没有变。你只是把“开灯”这件事变得更方便了而已。

这恰恰是“电灯泡阶段”最典型的特征：技术成本大幅下降、体验明显提升，但整体生产结构还没有因此被重构。

1.2 提示词不是电网，只是插座

在“电灯泡阶段”聊天，有一个绕不开的话题叫提示词工程（Prompt Engineering）。很多人把写提示词看成是使用 AI 的核心技能，甚至一门心思去背各种“万能提示词模板”。我的看法是：提示词当然重要，但它更像是墙上的插座——你往插座里插一个灯泡，它就能亮；但你不可能靠一个插座，让整个城市运转起来。

我见过不少团队和个人，把大量精力花在“优化提示词”上，结果只是把单次问答的质量从 60 分拉到了 85 分。这本身是收益，但它的天花板非常明显：你还是在一问一答地“开灯”，每一次对话都是一个新的独立事件，上下文不延续，任务不衔接，产出不回流。

真正让“电”发挥价值的，是围绕电建立起来的基础设施——电网、变电所、标准接口、用电设备、维修体系。放到 AI 这个语境里，对应的是什么？是我后面要重点聊的 Agent、工作流、上下文管理、模型部署和评测机制。如果说提示词是让灯泡亮起来的那个开关，那么“电网”就是让电能够持续、稳定、大批量地输送到各个场景的整套体系。

所以我在跟朋友讨论的时候常说一句话：不要只学怎么写出更好的提示词，要开始琢磨怎么把 AI 设计成一个能干活、能自动完成任务、能和你现有系统对接的“用电设备”。

1.3 替代型用法的真实成本

还有一个很容易被忽略的点，就是替代型用法看起来便宜，实际算总账并不便宜。

单次调用 API 确实很便宜，一个中等长文的任务可能只要几分钱。但当你把“让 AI 做某件事”变成日常工作流的一部分，你会发现成本开始悄悄累积：写提示词和反复调优的时间、检查 AI 输出是否靠谱的时间、在几轮对话里找回丢失上下文的成本、出错之后返工的成本。更隐蔽的是“组织习惯成本”——大家开始默认“AI 会先给一个初稿我再来改”，于是原始思考质量慢慢下降，最终反而增加了整个链条的工作量。

我不是说不能用 AI 写初稿，而是说：如果你只是把 AI 当成一个“更快的打字员”，那你享受的是替代红利，付出的却是重构机会的代价。而重构机会，恰恰是从“电灯泡”走向“电气时代”的那一步。

2. 电气化的拐点：从单点 AI 到 Agent 与工作流

2.1 为什么 Agent 是电网级别的变化

如果说“电灯泡阶段”是一问一答的单轮交互，那么“电气时代”的典型形态应该是什么？我的答案一句话就能概括：AI 开始作为流程的一部分连续运转，而不是作为工具被人一点点抠着用。

这里的抓手就是 AI Agent（智能体）。所谓 Agent，简单理解就是“一个能自己规划步骤、调用工具、观察结果并继续推进任务的 AI 系统”。它的核心特征不是“更聪明”，而是“有闭环”：

• 它有一个目标，比如“把这份会议纪要整理成任务清单并同步到项目管理工具”；
• 它能把目标拆解成步骤，比如“先理解会议内容 → 提取任务 → 确认负责人与时间 → 调用工具创建任务”；
• 它能执行步骤，并且在某一步失败的时候自我调整；
• 最后，它会暂停下来，把结果交给你确认或直接产出。

这就像电灯和电网的区别：电灯只有“开”和“关”，电网却有一个完整的输配电系统，电从哪里来、经过哪条线路、在哪一级变压、输送到哪个负载，都有明确的路径和反馈机制。Agent 就是 AI 应用里的“输配电网”。

我做过的几个 Agent 项目，最深的感触是：一旦把任务放进 Agent 工作流里跑起来，AI 的使用方式就不再是“我提一个问题它吐一个答案”，而是“我定义好目标和边界，它自己在分工表里推进”。这个变化看似只是工程层面的，实际上会带动一系列设计思维的变化：你要考虑容错、要考虑工具接口、要考虑子任务之间的依赖，这些全是“电网思维”，而不是“灯泡思维”。

2.2 一个可落地的工作流：从零到流水线

理论说多了容易飘，我直接拆一个我经常给团队举例的“最小可落地工作流”——面向销售团队的“客户会议纪要与跟进任务生成”。

传统做法是：会议结束后，销售自己对着录音重听一遍，整理出客户需求、疑虑、下一步动作，再打开 CRM 系统手动建任务。这个流程至少耗掉 15-30 分钟，而且非常依赖人的记录能力。

用 AI 工作流改造后，我的方案长这样：

1. 会议录音或转写文本，落到一个固定的输入目录；
2. Agent 读取转写文本，做信息抽取，识别“客户反馈的关键需求”“明确的疑虑”“双方达成的共识”“待办事项”；
3. Agent 将抽取结果结构化为固定格式的 JSON 数据，比如一个数组，每个元素包含任务内容、负责人、截至时间；
4. 调用 CRM 的 API，把 JSON 直接创建成系统里的跟进任务；
5. 最后生成一封给销售本人的摘要邮件，确认已完成操作。

这里的关键有两点，都在工程里特别容易被忽略：

• 第一，信息抽取的格式必须严格固定。我在系统提示词里明确要求“只输出 JSON，不要任何解释”，并且会用一个校验脚本自动解析 JSON，解析失败就让它重新生成。这一步看起来小，实际上是把 AI 从“聊天工具”变成“可对接组件”的分水岭。
• 第二，要有人工确认点。我不会让它直接创建任务，而是先生成草稿，销售在工具里快速核对一遍再点确认。你可能会问：这不还是人工操作吗？对，但在流程中，人的角色从“整理信息”变成了“审批信息”，批量处理能力和准确性都上了一个台阶。

这个例子我建议每个想落地 AI 工作流的人都跑一遍。它成本很低，但能帮你建立“流程思维”：输入是什么、处理逻辑是什么、输出是什么、对接系统是什么、失败重试怎么做。这套框架建立起来，你再去理解更复杂的多 Agent 系统，会轻松得多。

2.3 多 Agent 协作的“配电柜”思路

再往后走一步，就涉及到“多个 Agent 怎么配合”的问题。

我刚开始做多 Agent 的时候，犯过一个典型的错误：把所有任务塞给同一个 Agent，在提示词里写“你要充当多个角色，先做 A 再做 B 再转给 C”。结果是不稳定，角色一多，它就开始“乱穿”。后来我把方案改成各自独立的 Agent 分工协作，效果立刻稳定很多。

具体来说，我把系统拆成了这样几个角色：

• 主控 Agent：负责任务接收、规划和调度，不直接写最终内容；
• 研究员 Agent：负责检索资料、总结外部信息；
• 写作 Agent：负责基于研究结果生成文稿；
• 审查 Agent：负责挑毛病，检查事实性错误、逻辑漏洞、风格偏离。

它们之间不是来回闲聊，而是通过“结构化消息”传递产物：主控把任务分解成子任务，研究员把结论写到共享的上下文里，写作 Agent 只读取它需要的部分，审查 Agent 再针对成稿输出修改意见。整个过程很像一个工厂流水线，每个工位上的人只对自己这一步负责，中间的“传送带”就是共享的上下文和文件。

这个架构给我最大的启发是：Agent 协作的重点不是让每个 Agent 都“变聪明”，而是把任务切得足够独立、接口定得足够清晰。这个思路，和设计一个微服务系统非常像。如果你有后端开发经验，可以把 Agent 想象成独立的服务实例，把消息队列想象成上下文池，很多设计决策就顺理成章了。

3. 工程实践：把 AI 从“闪一下的灯泡”变成“稳定的电力系统”

3.1 模型部署选型：API、本地还是混合？

聊完 Agent 和流程，接下来是工程落地的硬骨头：模型到底怎么跑。

我在实际项目里通常面对三种选择：

• 第一种，纯 API 调用，比如接各家大模型的官方接口；
• 第二种，本地部署开源模型，常见方案是 Ollama、vLLM 或 llama.cpp；
• 第三种，混合架构，核心流程用 API，私有数据处理和冷门场景用本地模型。

没有绝对正确的选型，只有适合当前场景的选择。我帮你梳理一下决策依据：

我的个人经验是：第一步做 Demo 和原型验证，无脑选 API，省时间省精力；等到真要上生产、并且有稳定的高调用量时，再评估本地部署。不要一上来就折腾本地模型——你可能会花两周调 vLLM 的显存配置，最后发现问题只是业务需求没想清楚。

如果选择本地部署，我推荐从量化模型开始入门。比如用 Q4_K_M 这种 4-bit 量化的模型文件，一张 24GB 显存的显卡已经能跑不少 7B 到 14B 参数量的模型了。很多人一提到本地部署就下意识觉得“需要好几张 A100”，其实那是做训练的思路，推理和微调的需求远没有那么夸张。用 Ollama 拉一个模型下来，加上几个运行参数，半小时就能跑通一个本地 API 服务。

3.2 上下文、RAG 与召回：别让系统“短路”

如果说模型选型是发电厂，那上下文管理就是输配电线路里最容易“短路”的地方。

我在做 AI 工程实践时见过太多这种情况：模型本身能力很不错，但放到真实业务场景里，效果拉胯。排查到最后，绝大多数时候不是模型不行，而是上下文管理出了问题——要么该给的信息没给全，要么不该给的信息塞了一堆，把模型的注意力搅浑了。

结合我的经验，有几个核心原则值得牢记：

• 第一，上下文不是越长越好。确实，现在主流模型的上下文窗口动辄几十万 token，但超出一定长度后，模型对中段信息的注意力和可信度都会明显下降。工程上我一般把单次有效上下文的“黄金区间”控制在 2 万 token 以内，除非特殊需要，不硬塞。
• 第二，RAG（检索增强生成）不是万能药。很多人一遇到“模型答得不准”就想到 RAG，把一堆文档切片塞进向量库，然后期望模型能精准回答。但 RAG 的瓶颈往往在召回环节：切片策略、向量模型、相似度阈值、重排策略，每一个都是变量。如果切片的语义不完整，向量检索召回的内容驴唇不对马嘴，那后端的生成模型再强也使不上劲。
• 第三，上下文要有主次结构。我通常会在系统提示词里明确告诉模型“以下是你必须优先遵循的任务要求”“以下是参考资料，如果参考资料不足以回答问题，请明确说明”，用这种分层结构帮模型建立阅读优先级。

给你一个我常用的切片思路：按“语义完整块”而不是按固定字符数来切。比如一份技术文档，先按标题结构拆成章节，如果一个章节太长，再按段落边界切。这样能最大程度避免把一个完整观点拦腰截断，导致召回的单块内容语义残废。

3.3 AI 编程与 AI 测试的工程化落地

再聊聊我日常工作里 AI 使用频率最高的两个方向：AI 编程和 AI 测试。

AI 编程现在基本是刚需了。GitHub Copilot、Cursor、通义灵码、JetBrains 系插件，还有最近各家大模型自带的代码补全和 Agent 能力，写代码的效率确实提升了不少。但我要补一句容易被忽略的话：AI 编程的价值不在于“它写出多少行代码”，而在于“你多快能 review 完它写的代码”。

我自己用 AI 编程的姿势是分层的：

• 少量代码的脚本类需求，比如写个批量重命名文件的脚本，直接让 AI 生成，我快速 review 一遍就用；
• 业务模块级的开发，比如封装一个服务接口，我会先把接口契约、输入输出、异常处理逻辑写清楚，再让 AI 生成初版实现；
• 大范围的架构级改动，我不会直接让 AI 做，而是用 AI 来辅助分析：让 AI 梳理现有代码的调用关系、找出重复逻辑、生成重构建议，然后人工制定改动方案。

这里有一个非常重要的提示词技巧：给 AI 设定明确的代码交付标准。比如“只生成核心函数，不生成测试代码”“使用 Python 类型注解”“遵循项目现有的异常处理风格”。没有这些约束，AI 的产出往往“能用但不合群”，合入代码库的时候会给 review 带来很大负担。

至于 AI 测试，我的经验是：让 AI 写测试用例，比自己写测试用例的效率提升更明显。因为测试需求的表达方式天然偏结构化——给出一份测试规格，说明边界条件，AI 能生成一套相当完整的单元测试。但同样要注意别全自动生成，我会让它先输出测试用例清单，人工补充边界情况和异常路径，再让它把确定的清单翻译成代码。这样既保住了覆盖率，也避免了 AI 生成一堆“只看 happy path”的废测试。

4. 实操记录：一次完整的“AI 重构任务”复盘

4.1 场景拆解：选一个值得重构的任务

前面讲了不少方法论，这一节我用一个真实的实操记录把过程串起来。任务本身不复杂，但足够说明问题：给团队做一份“竞品动态周报”。

这个任务原本的操作是：团队里一个同学每周五花半天时间，去各家竞品官网、公众号、新闻站翻更新，手动摘录信息、打标签、写点评，最后整理成一份文档发到群里。听上去不难，但坚持几周后，质量就开始随心情波动，有时信息抓不全，有时点评写得太敷衍。

当时的改造思路非常直接。第一步不是找模型，而是拆任务：把“做周报”拆成“信息采集 → 信息筛选与去重 → 结构化分类 → 撰写摘要与点评 → 生成周报文档”五个子任务。拆完之后，哪些环节适合交给 AI、哪些环节必须由人把关，就一目了然了。

这一步我强烈建议所有想落地 AI 的人都先做：不要从技术出发，不要先从“我要不要用 Agent”出发，而是先从任务本身出发，把它拆到足够细。拆到你能清楚地说出每一步的输入是什么、输出是什么、判断标准是什么的时候，你自然就知道 AI 该放在哪里了。

4.2 参数配置与关键代码

任务拆完之后，我搭了一条半自动化的流水线。这里给你一份可以直接参考的架构思路：

• 信息采集：写了一个简单的爬虫脚本，定时抓取指定的竞品发布页和 RSS 源，落成 JSON 文件；
• 粗筛与结构化：调用大模型 API，对每篇文章做结构化摘要，输出标题、原文链接、发布时间、核心变化标签；
• 分类打标：用一个简单规则加上少数提示词，把文章归入“产品功能”“市场动态”“团队变动”等几个固定类别；
• 人工确认：我每天早上或周五下午花 10 分钟，在整理好的结构化清单上快速勾选哪些要写进周报；
• 生成周报：基于勾选清单，让 AI 扩展成一份带摘要和点评的周报文档。

关键代码并不复杂，核心就几个请求和一层校验。我贴一段当时调用模型的 Python 伪代码示例，注意看我是怎么处理“结构化输出”的：

import json from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="local-model") def extract_article_info(text: str) -> dict: prompt = f""" 你是一个竞品情报分析师。请从下面的文章内容中提取信息，并严格按照 JSON 格式输出，不要输出任何多余文字。 字段要求： - title: 文章标题 - url: 原文链接 - publish_date: 发布日期，格式 YYYY-MM-DD - tags: 标签数组，从[产品功能, 市场动态, 团队变动, 其他]中选取 - summary: 不超过80字的摘要 - ai_comment: 不超过50字的竞品点评，语气简洁 文章内容： {text[:3000]} """ resp = client.chat.completions.create( model="qwen2.5:14b", temperature=0.2, messages=[{"role": "user", "content": prompt}], ) raw = resp.choices[0].message.content.strip() # 这里要做一层容错：模型偶尔会输出 ```json ``` 包裹，要先清理 if raw.startswith("```json"): raw = raw[7:-3].strip() return json.loads(raw)

这里几个参数我解释一下为什么要这么设：

• temperature 设为 0.2：这个任务要的是信息抽取和汇总，不是创意发散，温度越低输出越稳定；
• 限制 text[:3000]：整篇文章可能会超长，截断到前 3000 字符足够覆盖绝大多数文章的核心信息，还能减少 token 开销、压缩响应时间；
• 要求 “不要输出任何多余文字”：这一句对结构化解析至关重要，不加这句，模型经常会先来一段“根据您的需求，我进行了以下分析”，非常影响后续程序的直接消费。

4.3 结果对比与踩坑记录

跑了两周之后，效果对比是这样的：

• 原来信息采集靠人工，平均每周遗漏约三分之一的小型更新；现在采集覆盖率接近满格，我所做的只是每天花三五分钟做“瓜田筛选”。
• 原来整理周报需要半天，现在人工作业压缩到大约 10 到 15 分钟，AI 负责写初稿，我负责定稿和补充点评。
• 质量波动的问题也得到了很大缓解。点评虽然少了一点“天才感”，但稳定在“及格偏上”的水准，群里的反馈没有明显变差。

但踩坑也确实不少，我挑三个最典型的记录一下：

第一个坑，是信息采集的范围最初设得太宽，导致每周“疑似竞品动态”有 100 多条，粗筛成本暴涨。后来我在采集源列表上做了减法，只保留真正值得跟踪的信号源，再对同一个域名的内容做去重，数据量直接降了一个数量级。

第二个坑，是结构化输出格式的容错。前面伪代码里已经提到了，模型偶尔会输出 Markdown 代码块包裹的 JSON，甚至会在 JSON 后面追加注释。我在最初版本里直接 json.loads，导致流程频繁中断。后来总结出一个经验：任何从大模型拿结构化输出的生产级脚本，都必须先做两层容错，一层清理包裹符号，一层重试解析，还不知道要留一个“解析失败进入人工队列”的兜底出口。

第三个坑，是点评模板化。AI 写的点评一旦量大了，会频繁出现“进一步巩固了其在某领域的领先地位”之类的套话。我的解决办法是在系统指令里加入反面示例，明确告诉它“避免‘进一步’‘加强’‘赋能’‘持续深耕’这类空泛表达，尽量写具体的观察，比如‘官方更新了服务条款，新增了两条关于数据出口的说明’”。这个技巧对于生成类任务很通用：与其说“要写得好”，不如直接告诉它“不要怎么写”。

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

5.1 高频问题速查表

这几年我把 AI 项目落地过程中常见的坑整理成了一张速查表，分享出来，很多问题你可能迟早会遇到：

这套表的逻辑很简单：绝大多数 AI 工程问题都不是模型本身“笨”，而是上下文组织、接口契约、参数配置这些“外围工程”出了问题。把外围修好，模型能力自然就显出来了。

5.2 几个能救命的排查习惯

排查 AI 工程问题，和排查传统软件问题有一个很大的不同：传统软件出 Bug，行为是可复现的；AI 出问题，往往是概率性的。所以排查思路也要跟着变。

第一个习惯：先固定随机性，再谈优化。遇到不稳定的时候，我第一反应是先把 temperature 调成 0，同时固定 API 请求里的 seed 参数（如果服务商支持）。只有当同样的输入能稳定复现问题，你才能判断问题到底出在哪一步。

第二个习惯：凡是 AI 产出的中间结果，都要建立“落盘与回放”机制。我在开发 Agent 工作流时，习惯把每轮 Agent 的输入输出、调用的工具和最终结果全部记录成日志文件。等系统出问题的时候，直接回放日志，能省掉大量“猜来猜去”的时间。说白了，AI 是黑盒，但工程不能黑盒。

第三个习惯：建立“人机置信分”的意识。不是所有任务都适合用 AI 去自动生成并直接采信。我在设计任何 AI 流程时，都会给每一步贴上置信度标签：低置信度的环节，比如信息抽取和初步分类，AI 可以自动跑，但后面必须有人抽查；高置信度的环节，比如固定格式的数据转换，AI 可以直接执行，异常情况自动转人工。这个“置信分层”的思路，能让 AI 的使用既高效又安全。

第四个习惯，也是我自认为最值钱的一条：永远给 AI 一个“承认不会”的出口。不少输出错误，是因为模型明明不知道答案，却硬要编一个合理的答案出来。我在系统提示词里固定加一句，“当信息不足或超出能力范围时，请直接回复‘无法确定’并说明缺少哪些信息”。加了这句话之后，很多系统性的幻觉问题迎刃而解。

一点落地的心里话

写了这么多，回到开头那个比喻：今天的 AI 确实还只是电灯泡，但我们站的位置其实很有意思——电灯泡刚发明时，大多数人还在犹豫“要不要把家里的煤油灯换掉”，而极少数人已经开始琢磨发电厂、输电网和用电设备的整体布局了。

我这一年多最大的感受就是，AI 的能力边界反而没那么重要了，重要的是你有没有开始用“电网思维”去编排它。与其纠结哪个模型更强、哪个提示词更妙，不如先找一个具体任务，拆碎它，设计出一条带人工节点的 AI 流水线，跑起来，再一点一点把问题修好。这个过程会比你想象中更枯燥，但也更有价值。

按照我个人的经验，从“用 AI 写东西”到“让 AI 成为系统里一个可靠的部件”，中间差的不是技术鸿沟，而是思维转变。你不用等所有基础设施到位再动，先把手边那件最重复、最消耗精力的事情挑出来，试着把它的流程画出来，然后让 AI 站到它该站的位置上。现在的 AI 也许还是电灯泡，但灯泡一旦变成电网的一部分，它就不再只是一个能发光的物件了。