AI取代的是任务而非岗位：技术人借势提升竞争力指南

各位读者朋友大家好。今天想和大家聊一个最近在国内外技术圈和社交媒体上都很有热度的话题一个短视频标题是这么写的“POV: An AI replaced your job this morning”视角今天早上一个 AI 取代了你的工作。虽然这只是一个几秒钟的“视角”短视频但它精准地踩中了几乎所有脑力劳动者的焦虑点AI 大模型发展得这么快会不会有一天早晨打开电脑发现自己已经不需要坐在工位前了这篇文章不会贩卖焦虑也不会盲目吹捧 AI。作为长期在一线写代码、做架构、带项目的工程师我更想把这个话题拆解成几个实际的问题AI 到底取代了什么哪些工作是它真正能干的哪些工作它目前只是“看起来能干”以及最重要的——我们这些靠技术吃饭的人应该怎么调整自己的技能树和职业策略才能在 AI 时代保住饭碗甚至借势提升竞争力。文章会从 AI 能力的真实边界、AI 对不同岗位的冲击对比开始讲然后重点落在“ AI 编程助手、Agent、模型本地化部署”这三件和开发者最相关的事情上。最后给出一个适合工程师的 AI 学习路线和项目落地建议。全程干货希望能给正在焦虑或正在观望的你一些参考。1. 先看清现实AI 替代的是“任务”不是“岗位”1.1 短视频背后的心理冲击先来解释一下这个 POV 视频为什么能火。POVPoint of View视角是短视频平台常见的叙事手法它让观看者代入第一人称视角。这个视频模拟的是你像往常一样起床、洗漱、打开办公软件然后发现系统提示“您的岗位已被 AI 接管今日起无需到岗”。这种叙事之所以传播力极强是因为它在一个极短的时间内击中了三个心理开关职业不安全感每个人都曾担心过自己的工作会被自动化取代。黑箱恐惧大多数人并不清楚 AI 现在到底能做到哪一步只能靠想象放大它的能力。时间压力感“早上”这个时间设定暗示了取代过程是瞬间发生、毫无征兆的放大了无力感。作为技术从业者我们要做的第一件事就是把这层情绪外壳剥掉去看 AI 在真实世界中的能力边界。1.2 AI 能替代的是高度标准化、可复现的“任务”从计算机科学的角度来看当前主流的大语言模型LLM本质是一个“根据上下文预测下一个 Token”的概率系统。它擅长的是从海量数据中学习统计规律然后完成模式复现。这就决定了它是“任务级”的替换工具而不是“岗位级”的替换工具。一个岗位通常由多个任务组成例如后端开发工程师这个岗位至少包含需求分析、接口设计、数据库表设计、业务代码编写、单元测试、代码审查、性能调优、线上故障排查、与产品经理沟通、跟运维协同发布。AI 能高效完成的往往是其中高度标准化、输入输出边界清晰的部分根据接口文档生成 CRUD 代码。将一段 Python 代码翻译成 Java。根据 SQL 表结构生成基础的查询语句。为现有函数补充单元测试用例。将自然语言描述转化为配置模板。而一个岗位中真正不可替代的部分恰恰是 AI 目前最薄弱的环节需求识别产品经理口中的“优化用户体验”到底是什么意思需要在什么业务约束下转化为技术方案方案权衡缓存数据库一致性、分布式事务、消息队列顺序性这些技术选型不是“写代码”而是“做决策”。跨系统协同老系统没有文档、离职员工没交接、线上环境与测试环境不一致这些都是 AI 无法从训练数据中获知的“局部上下文”。责任兜底代码上线后出了 P0 事故最终要有人承担责任AI 无法被追责也无法在凌晨三点被叫起来排查故障。所以第一个核心结论是AI 取代的是某个岗位中的“任务组合”而不是岗位本身。谁的工作内容包含大量可标准化任务谁的风险就更高谁的工作包含大量决策、协同、兜底责任谁的抗风险能力就更强。2. 技术人视角AI 编程从“玩具”到“生产力”2.1 AI 编码能力的真实水平有一些没实际使用过 AI 编程工具的朋友可能会被 POV 类短视频吓到认为“AI 已经完全能写代码了还要程序员干嘛”。这种误解的根源是把“生成代码片段”等同于“完成软件开发”。我们不妨从软件工程的角度给 AI 编码能力做个相对客观的分级任务类型AI 完成质量举例生成独立函数/算法较高接近中级工程师水平写一个快速排序、实现 JWT 工具类根据已有代码风格补充模块中等取决于项目结构清晰度仿照现有 Service 层写新接口实现跨模块重构偏低容易遗漏调用方影响把同步调用改成异步消息、拆分大服务系统架构设计极低缺乏真正的业务判断力微服务划分、数据库分库分表策略线上故障根因分析较低只能提供排查方向无法直接定位内存溢出、死锁、CPU 飙升的根因处理历史遗留代码偏低对隐含规则和废弃逻辑无感知修改一个十几年前的老模块且不影响历史数据这个表格说明两件事第一AI 编码能力确实已经进入了工程化实用阶段它能让具备编程基础的人以更高效率产出代码第二AI 目前仍然只是一个“高级补全工具”它对项目的整体理解远远达不到一个合格的资深开发者的水平。2.2 开发者采用的三种姿势不同开发者对 AI 编程工具的采用方式完全不同基本上可以分为三类。第一类抗拒型。担心 AI 生成代码质量不可控觉得代码审查 AI 写的东西比自己写还累所以干脆不用。这种心态的代价是会逐渐失去对新技术栈的敏感度效率上也会落后。第二类盲目信任型。把 AI 当成“外包程序员”需求描述一句话AI 返回什么代码就复制什么代码完全不做审查。这种做法非常危险因为大模型存在“幻觉”Hallucination问题它可能生成一个看起来无比正确、但实际调用了一个不存在 API 的代码。第三类协同型推荐。把 AI 当成一个“思维速度极快、但需要严格约束的初级协作工程师”。你负责拆解任务、设计接口、审查产出和兜底业务正确性AI 负责快速填充模板代码、写重复性测试、做初步代码审查。我现在的日常工作流已经切换到第三种模式大概的协作流程如下1. 我先画出模块的接口设计明确输入输出和异常边界 2. 把设计描述发送给 AI让它生成基础实现 3. 我对 AI 代码做逐行审查修正业务逻辑遗漏点 4. 把高频出现的修正反馈重新告诉 AI逐渐形成团队专属的编码规范 5. 用 AI 来生成单元测试的“输入边界用例”我再补充业务断言。这样做的收益非常明显重复性编码时间大约减少了一半但我的代码审查责任和工作量并没有减少甚至因为要检查 AI 的输出而变得更重要了。3. AI Agent从“回答问题”到“执行任务”3.1 Agent 这个概念为什么关键如果说大模型是“大脑”那么 AI Agent智能体就是“大脑加上手和脚”。一个 Agent 在拥有大模型的理解和生成能力之外还可以调用外部工具、访问系统 API、读取数据库、操作浏览器甚至自主决定下一步执行什么动作。这也是为什么“AI Agent 开发”会成为最近工程领域最热门的方向之一。因为它真正触及了“AI 如何进入工作流”的核心。比如传统 AI 编程助手你提问它回答一段代码你自己复制粘贴到文件里。基于 Agent 的 AI 编程助手你描述一个任务比如“给登录接口增加防暴力破解功能”Agent 会自动读取项目代码、找到登录 Controller、定位密码校验逻辑、生成修改方案、执行代码修改甚至运行测试来验证改动是否正确。从这个角度看Agent 确实比单纯的“聊天机器人”更有“取代感”。因为它不再只是给出建议而是直接执行完整流程。3.2 一个最小 Agent 的工程结构要理解 Agent 的能力边界必须先理解它的工程结构。一个典型的 Agent 系统通常包含以下核心模块LLM 核心负责语义理解、意图识别、任务规划。工具注册表ToolsAgent 能调用的外部能力集合比如“查天气 API”“执行 SQL”“读取本地文件”“调用 Git 命令”。记忆模块Memory分为短期记忆当前会话上下文和长期记忆向量数据库存储的历史经验。规划与决策模块Planner把大任务拆解成多个小步骤并根据每步执行结果动态调整后续计划。执行与反馈模块执行工具调用读取结果判断是否完成或需要修正。下面是一个极其简化的 Python 示例模拟一个 Agent 如何判断自己“是否需要调用工具”。它虽然不能直接用于生产但能帮你理解 Agent 的工作链路# 文件路径simple_agent_demo.py # 说明这是一个演示 Agent 工作链路的最小示例请根据实际需求扩展 import json # 模拟一个外部工具根据城市名查询天气 def weather_tool(city: str) - str: # 实际项目中这里会调用真实天气服务 API weather_data { 北京: 晴25℃, 上海: 小雨22℃, 深圳: 多云28℃ } return weather_data.get(city, 暂不支持该城市天气查询) # 工具注册表 TOOLS { get_weather: { description: 查询指定城市的当前天气, function: weather_tool } } # 模拟 LLM 的意图识别结果 # 实际项目中这里是大模型根据用户输入返回的 JSON def parse_user_intent(user_input: str) - dict: # 极简关键词匹配仅用于演示 if 天气 in user_input and 城市 in user_input: # 假设模型识别出城市参数 city user_input.split(城市)[-1].replace(怎么样, ).strip() return { tool: get_weather, args: {city: city} } return None # Agent 主流程 def agent_run(user_input: str): print(f[用户输入]: {user_input}) # 第一步意图识别 intent parse_user_intent(user_input) if intent is None: # 模型直接回答不需要工具 print([Agent] 无需调用工具直接由 LLM 回答) return # 第二步从工具注册表查找工具并执行 tool_name intent.get(tool) tool_info TOOLS.get(tool_name) if not tool_info: print([Agent] 未找到可用工具) return # 第三步执行工具函数 result tool_info[function](**intent[args]) print(f[工具执行结果]: {result}) # 第四步LLM 将工具结果组织成最终回复 print(f[Agent最终回复]: {intent[args][city]}今日天气为{result}) if __name__ __main__: agent_run(帮我查一下城市北京天气怎么样)运行这个脚本输出大致如下[用户输入]: 帮我查一下城市北京天气怎么样 [工具执行结果]: 晴25℃ [Agent最终回复]: 北京今日天气为晴25℃真实生产环境中的 Agent 要复杂得多但基本链路是一致的理解意图 → 规划任务 → 调用工具 → 结构反馈 → 生成最终结果。一个 AI 能不能取代某个岗位本质上取决于这个岗位的工作流是否能让 Agent 完整地跑通。4. 哪些岗位正面临“早上被取代”的真实风险4.1 高替代风险岗位的共同特征结合前面的分析高替代风险岗位通常具备以下特征输入输出明确任务描述清晰结果容易量化验证。依赖显性知识工作主要靠阅读文档、检索资料和执行标准流程而不是依赖大量线下人际沟通和“隐性知识”。重复性占比高日常工作中有大量结构相似的模板任务。出错成本相对较低错误可以被快速发现和修正不需要承担巨大的业务或安全责任。按这个标准看以下几类岗位受到的冲击最值得关注。初级内容生产者包括基础稿件撰写、产品说明生成、翻译润色、日报周报汇编等。大模型在文本生成、改写、摘要方面的能力已经非常成熟只要人类提供清晰的框架和素材AI 可以快速生成初稿。标准报表与数据录入人员如果工作主要是从 Excel 中读取数据、按固定模板生成图表、录入信息系统这类任务非常适合通过 RPA机器人流程自动化 AI 的方式替代。初级测试执行者编写重复性测试用例、执行回归测试、提交 Bug 报告这些工作正在被 AI 测试工具逐步覆盖。AI 可以自动分析代码变更生成针对性测试数据甚至自动执行 UI 自动化脚本。初级客服与技术支持基于知识库的问答式客服是目前 AI Agent 落地最成熟的场景之一。大模型已经可以做到理解用户意图、检索知识库、生成回答并在无法解决时转人工。初级数据分析师如果日常工作是“取数 → 清洗 → 做可视化 → 写 PPT”那么这部分流程现在可以通过自然语言直接操作数据分析工具完成人类的角色更多转向“提出正确的问题”和“验证结论的合理性”。4.2 中低替代风险岗位的特征与之相对以下类型的岗位在可预见的未来里相对安全。需要复杂人际协调的岗位比如项目经理、产品经理、客户成功经理。AI 能生成会议纪要和项目周报但无法替代人与人之间的信任建立、冲突调解和利益博弈。需要现场操作和感知的岗位比如运维工程师在处理物理服务器故障、硬件排障、网络割接时不仅需要知识还需要现场感知能力和应急判断力。需要深度业务判断的岗位比如资深架构师、技术专家、合规风控人员。他们的核心价值不是“知道怎么做”而是“知道在特定业务约束下什么方案最合适、什么风险不可接受”。需要承担最终责任的岗位比如医生、律师、财务负责人。AI 可以提供辅助判断但最终签字的依然是人。4.3 从“岗位”拆解到“任务”再拆解到“技能”所以与其焦虑“我的岗位会不会消失”不如换个更工程化的思路把岗位拆成任务清单拿出笔和纸列出自己最近一个月每天都在做的任务。给每个任务打三个标签是否输入输出明确、是否依赖显性规则、是否允许试错。如果三项都是“是”那么这个任务大概率可以被 AI 自动化。找到自己工作中“三项都是是”的任务占比就能得到一个大致的风险评分。然后针对性地调整工作重心把更多时间投入到决策、沟通和复杂问题解决上。这一套方法本身就是一个典型的“任务拆解”思维也是 AI 时代每位技术人都应该内化的底层能力。5. 对抗“被取代”的钥匙工程化提示词写作5.1 为什么提示词能力越来越重要很多人以为“提示词工程”Prompt Engineering只是教会 AI 说话其实不然。提示词工程的核心是把模糊的人类意图转化为机器可执行的结构化指令。这个能力在 AI 时代之所以重要是因为它和传统软件工程中的“需求分析”本质上是一样的。当企业想要引入 AI 提升效率时最大的瓶颈往往不是模型能力不够而是业务人员/研发人员无法准确描述需求。谁能够把“帮我提高客户转化率”这样一个模糊需求分解成“分析用户行为数据 → 识别高流失风险人群 → 生成个性化营销话术 → 通过短信渠道触达”这样的结构化任务谁就掌握了 AI 落地的关键能力。5.2 一个实用的提示词模板这里给出一个适用于“任务型 AI 编程”的提示词模板核心思路是约束 AI 的输出范围减少幻觉和无效内容# Role角色 你是一名资深的 Java 后端开发工程师熟悉 Spring Boot 3.x 和 MyBatis-Plus。 # Task任务 请在现有项目中新增一个用户积分变更记录的 Mapper 接口。 # Requirements需求 1. 数据表名为 user_points_log字段包括 id、user_id、change_type、points_change、create_time。 2. 需要支持按 user_id 分页查询积分变更日志按 create_time 倒序。 3. 只生成 Mapper 接口和对应的 XML 文件不需要生成 Service 和 Controller。 4. 遵循项目现有的代码风格使用 Lombok。 5. 不加多余注释除非代码逻辑有歧义。 # Constraints约束 1. 不要修改其他任何已有文件。 2. 不要引入新的依赖。 3. 如果信息不足请先列出需要补充的问题再生成代码。 # Output Format输出格式 请以两个代码块分别输出 Java 接口文件和 XML 文件并在开头简述你的实现思路。这个模板看起来并不复杂但它背后包含几个关键工程思想角色约束让 AI 在特定领域内作答、任务边界避免越权修改、输出约束控制产物形式、反馈循环信息不足时先提问。这些思想直接可以迁移到任何与 AI 协作的场景中。5.3 打造你自己的“需求拆解”能力提示词工程的本质不是“背几个模板”而是“需求拆解能力”。一个优秀的技术人应该能做到把大目标拆成小步骤。明确每一步的输入、输出和验收标准。识别哪些步骤可以交给 AI哪些必须自己完成。对 AI 的输出设定质量门槛不合格的重写或打回。这套方法论不仅适用于 AI 协作在带团队、写方案、做架构设计时同样有效。换句话说学提示词工程并不是为了“调教 AI”而是为了提升自己作为技术人的底层抽象能力。6. AI 应用开发的工程实践6.1 从“使用 AI”到“开发 AI 应用”如果不想只做一个“AI 工具用户”而是想在职业赛道上更进一步可以考虑转向 AI 应用开发。这里的“ AI 应用开发”不是去训练大模型而是利用现成的模型能力结合私有数据和业务系统打造解决特定问题的应用。一条相对清晰的工程路径如下掌握大模型 API 调用这是入门成本最低的一步。选择一家主流大模型服务商学习它的 API 调用方式、参数含义、鉴权机制和计费规则。你需要弄清楚 Temperature温度控制随机性、Top P、Max Tokens 这些基础参数的实际影响。学习 Prompt 工程设计掌握系统提示词System Prompt、少样本提示Few-shot、思维链Chain of Thought等主流提示技巧并能应用到具体场景。掌握 RAG检索增强生成技术RAG 是目前企业私有知识库问答最常用的方案。它的核心思想是当用户提问时先从向量数据库中检索最相关的文档片段再把这些片段作为上下文输入给大模型最终生成回答。这样可以减少幻觉也能让模型回答基于企业内部专有知识。开发 Agent 应用学习如何让模型能够调用外部工具解决单一模型无法完成的复杂任务。关注模型微调与本地化部署当通用模型在特定领域效果不佳或者数据安全要求不允许调用外部 API 时就需要考虑开源模型本地化部署和微调。6.2 本地化部署数据安全场景的刚需在不少企业场景中内部数据如源代码、客户数据、财务数据不允许发送到外部 API因此本地化部署大模型成为一个刚性需求。这也是“AI 模型部署”相关岗位热度持续上升的原因。本地化部署的技术栈通常包括开源基座模型如 Qwen、LLaMA 等允许商用或研究使用的开源模型。推理加速框架如 vLLM、Ollama 等用于提升模型推理速度和降低显存占用。向量数据库如 Milvus、Chroma、FAISS 等用于存储文档向量支撑 RAG 检索。应用框架如 LangChain、LlamaIndex、Spring AI 等用于编排模型调用与业务逻辑。下面是一个使用 Python 伪代码实现的 RAG 检索思路方便大家理解整体流程# 文件路径rag_demo.py # 说明演示 RAG 应用的核心链路实际项目中需要替换为真实模型调用 def build_document_index(documents: list[str]): 将文档切分并向量化存储到向量数据库。 此函数省略了具体的切分与向量化实现。 for doc in documents: chunks split_document(doc) # 1. 切分文档 embeddings embed_texts(chunks) # 2. 生成向量 vector_store.add(chunks, embeddings) # 3. 存入向量库 def answer_with_rag(question: str) - str: 根据用户问题执行 RAG 检索增强生成。 # 1. 问题向量化 question_vector embed_texts([question])[0] # 2. 在向量库中召回最相关的文档片段 related_chunks vector_store.search(question_vector, top_k3) # 3. 拼接上下文 context \n\n.join(related_chunks) # 4. 构造带上下文的提示词 prompt f 请基于以下资料回答问题如果资料中没有相关内容请直接回答“资料库中未找到相关信息”。 资料 {context} 问题{question} # 5. 调用大模型生成回答 response llm_call(prompt) return response这几段代码的思路非常清晰RAG 并不是一个高不可攀的技术只要掌握文本切分、向量检索和提示词组装三个基础步骤就能快速搭建一个企业内部文档问答应用。6.3 从开源项目入手对于想上手的读者我建议不要一上来纠结于理论而是找一个真实项目跑通整个流程。比如有很多开源的个人 AI 助手项目、AI 小镇模拟项目、企业知识库问答项目它们一般都会包含前端界面、后端服务、模型调用、向量数据库这几个模块。拿到开源项目后建议按以下顺序阅读代码先跑通项目。按照 README 配置环境启动服务观察效果。理解项目整体架构。画出数据流用户输入 → 前端 → 后端 → 模型/向量库 → 响应。找到核心代码文件。重点看 Prompt 是如何设计的、上下文是如何管理的、工具调用是如何实现的。尝试修改一个小功能。例如把回答风格改成更正式的公文风格增加一个“引用来源”输出等。复盘如果换一个业务场景这套架构需要改动什么哪些模块可以复用。7. 常见问题与应对策略7.1 开发者的 AI 焦虑来自哪里技术圈里最常见的问题大概是这几类问题现象应对思路担心 AI 编程工具取代初级岗位看到 AI 写 CRUD 很快觉得自己没优势尽快往“架构设计、复杂调试、跨团队协作”方向转型初级编码减少后评审和兜底需求反而更多AI 生成的代码质量不稳定代码能跑但边界条件全无或用了不存在的 API把 AI 当初级开发管理明确验收标准建立 Code Review 流程必要时用单元测试兜底不确定该用哪个 AI 产品工具太多不知道学什么关注主流模型 API选一个常用的编程助手再结合公司技术栈选择开源模型避免同时学太多工具模型和数据安全问题公司不允许代码上传到外部服务转向本地化部署 RAG 私有向量数据库方案这也是企业落地的刚需不知道从何学起AI 方向太杂学不过来先学“Prompt 大模型 API RAG”这三项组合已经能覆盖 80% 的 AI 应用场景7.2 AI 生成代码中的“幻觉”问题这里想单独聊聊“AI 幻觉”。所谓幻觉是指模型一本正经地给出了错误答案。在编程场景中最典型的体现是AI 使用了一个根本不存在的类库方法或者编造了一个不存在的配置项但代码结构和注释看起来极其合理。面对这类问题建议养成三个习惯关键代码不轻信。凡是涉及文件操作、数据库事务、网络请求、加密解密等核心逻辑的代码必须逐行确认。先读官方文档再运行。当 AI 推荐某些依赖或配置时建议先查一下官方文档确认版本和参数而不是直接复制。让 AI 解释代码。如果对某段生成代码不理解直接问它“这段代码的每一步是做什么的”它能回答上来且逻辑自洽出错概率会低一些但还是需要自己验证。7.3 不会代码的人会不会更容易被取代这个问题经常被讨论。目前相对客观的答案是不会代码的人和会用 AI 的人之间的差距正在被急剧拉大但“AI 直接取代不会代码的人”暂时还没有全面发生。因为 AI 应用本质上仍然是一个“工具”工具的效力取决于使用者的判断力。一个不懂业务、不懂逻辑分析的人即使有了 AI也很难问出正确的问题、验证结果的正确性、判断哪些环节需要人工介入。反过来一个懂业务但不会写代码的人现在可以通过自然语言让 AI 完成大量数据分析、文档生成、报告撰写的任务效率提升非常明显。所以短期来看AI 更像是一个“能力放大器”——它放大了你原本就具备的业务理解力、逻辑能力、沟通能力。如果这些底层能力本来就很强AI 会成为你的超级杠杆如果这些底层能力较弱AI 也无法帮你从零建起一座大厦。8. 更适合技术人的 AI 学习路线结合前面的分析这里给出一条适合后端/全栈/运维工程师的 AI 学习路线按周来规划循序渐进。第 1-2 周熟悉大模型 API目标掌握一个主流模型 API 的调用、参数调优和基础场景应用。 实践调用模型完成文本摘要、情感分类、代码解释、SQL 生成等任务。了解 Temperature、Top P、Max Tokens 对生成结果的影响。第 3-4 周系统学习 Prompt 工程目标能够设计稳定的系统提示词应对复杂业务场景。 实践编写一个面向客服场景的 Prompt让模型基于你提供的知识库内容回答并在缺少资料时礼貌拒绝。第 5-6 周掌握 RAG 应用开发目标搭建一个本地知识库问答系统。 实践准备一批企业内部文档实现文档切分、向量化、检索、生成回答的全链路。这一阶段建议自己动手写代码不要只用现成框架才能理解细节。第 7-8 周学习 Agent 开发目标理解 Agent 架构掌握工具调用和任务规划。 实践开发一个简单的 Agent让它能根据用户需求查询数据库、调用内部 API、发送邮件并把每一步执行过程记录下来。第 9-12 周深入模型部署与微调目标理解开源模型的基本原理掌握本地部署流程。 实践在一台有 GPU 的服务器上部署一个开源模型用 vLLM 或 Ollama 提供推理服务再调用本地向量数据库构建一个完全离线的知识库应用。完成这些阶段后你已经具备独立完成企业级 AI 应用 MVP 的能力这在当前求职市场上是一个非常有竞争力的加分项。9. 最后的几点建议回到文章标题“POV: An AI replaced your job this morning”。作为一个在技术圈摸爬滚打了多年的老工程师我始终认为AI 真正带来的不是“失业潮”而是“职业分水岭”。同样是写代码有人可能在重复性任务中慢慢失去优势也有人会借助 AI 把产出效率提升到一个完全不同的量级。关键在于你把自己定位成一名“执行者”还是从一个更高的维度去规划自己的技能组合。与其每天刷短视频想象 AI 取代自己的场景不如今天就打开一个模型 API 文档写一个能真正解决自己工作痛点的 AI 小工具。当你亲手把一个重复性任务交给 AI 完成的那一刻你就不再把 AI 当对手而是把 AI 当队友了。希望这篇内容能给你带来一点启发如果你正在做一个有趣的 AI 应用也欢迎在评论区交流讨论。觉得有收获的话可以收藏备用顺手点个赞支持一下。我们下篇见。