ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

AI越强打工人越累?从提示词到Agent拆解内耗与任务通胀

AI越强打工人越累?从提示词到Agent拆解内耗与任务通胀 上周三晚上十一点我关掉第十七个浏览器标签页盯着屏幕上刚生成的一份还算能用的方案脑子里冒出来的第一个念头不是终于搞完了而是这活本来要两天现在半天就出稿了可我为什么还是这么累。这个疑问应该不只属于我。过去这一年AI 的能力提升是肉眼可见的写代码能补全整段逻辑写文案能一次给出五个方向做表格能直接读懂截图连开会录音都能自动整理成分角色的纪要。按最朴素的算法工具变强了人应该更轻松才对。但身边真实的体感恰恰相反——活没变少人反而更焦虑、更内耗下班之后脑子里还在转是不是还有更快的用法没学会。这篇东西不打算讲大道理也不打算把锅全甩给工具。我想做的是把AI 越强、打工人越累这件事拆成几块能看得见、摸得着的结构时间到底被谁吃掉了内耗具体从哪几个缝隙里钻出来以及在实操层面一个普通从业者能做什么去把它按回去。文中涉及的工具选型、提示词模板、本地部署参数、自动化流程设计都是我自己在实际项目里反复试过、改过几轮的版本。如果你现在正处在AI 用得越多越烦的状态里下面这些内容应该能对上号。1. 先别急着骂工具AI 变强反而更累问题到底出在哪很多人第一反应是这届打工人矫情其实不是。用一个特别生活化的类比以前你上班是走路去一小时的路程就是一小时路上还能顺便看看天。现在给你配了一辆车十分钟就到了但老板知道你十分钟能到于是把原本一天一趟的活改成了三趟。车没让你更轻松它改变的是别人对你产能的预期。AI 在这件事上扮演的就是那辆车而且是隔几个月就换一次发动机的那种。1.1 省下来的时间其实被三类东西吃掉了我认真记录过自己一周的时间去向结论是AI 省下来的时间主要流进了三个我事先完全没预料到的窟窿。第一个窟窿是验证。AI 的输出有一个很讨厌的特性它看起来对的时候和对的时候长得一模一样。一段代码语法漂亮、命名规范、注释齐全跑起来才发现边界条件全错一份数据结论口径清晰、图表好看追到源头发现引用的字段是三个月前的旧表。所以真正耗人的不是生成是核对。生成三分钟核对半小时这几乎是常态。第二个窟窿是选择。以前遇到问题只有一条路闷头做就是了。现在一个任务摆在面前光是用哪个工具就要纠结这个提示词该给通用大模型还是给带联网检索的版本这个脚本让 AI 直接写还是我自己写更省事这个文档要不要走 Agent 流程。选择本身就是消耗而且选项越多决策疲劳越重。第三个窟窿是返工的组织成本。以前改一个方案是改文本本身。现在改一个方案可能牵动一串东西提示词要更新模板要更新自动化脚本里的变量名要跟着改历史对话里那份最终版还得标记成作废。工具的链路越长一次改动的涟漪就越大。1.2 任务通胀效率红利被自动兑换成了更多活这一点是我认为最核心的原因也是最容易被忽略的。效率工具出现之后节省下来的时间很少会回到你手里它会被自动兑换成新的任务。原因很朴素交付周期缩短了需求方对多久能给一版的心理预期就跟着缩短于是原本一周一版、改三轮的节奏变成一天一版、改五轮。总量上看你确实做了更多事但每一件事的打磨时间被压薄了人的成就感反而下降——因为你自己心里清楚那份稿子只做到七分。更麻烦的是AI 拉高的不只是速度还有看起来能做的范围。以前一个完全不懂前端的后端同学不会接前端的活因为知道做不了。现在 AI 能把一个能跑的页面糊出来于是你能不能顺手把这个页面也做了就变成一个无法拒绝的请求。能力边界被工具模糊之后任务边界就守不住了这是内耗的一个重要来源。注意判断自己是不是掉进了任务通胀有个很简单的自测方法——对比一下半年前和现在你完成同样一份交付物的平均耗时少了多少但你的工作总时长少了多少。如果前者降了百分之五十后者只降了百分之五剩下的百分之四十五就是被兑换掉的。2. 内耗的四个隐形来源逐条拆开看搞清楚累从哪来比急着找解决方案更重要。我把自己的内耗来源归成了四类它们的性质完全不同对应的解法也完全不一样。混在一起治只会越治越乱。2.1 切换成本一天在六个窗口之间来回跳这是最容易被低估的一项。我统计过一个普通工作日的窗口切换记录浏览器里常年开着三个对话页面、一个线上文档、一个代码编辑器、一个终端、一个任务管理工具。平均每四到七分钟就要切一次每次切换之后重新回到原来的思路大约需要几十秒到一两分钟。算一笔账一天按八小时算如果每小时切换八次每次恢复成本按四十秒计光重新进入状态这一项一天就吃掉将近一小时。而这一小时不是集中消耗的是被切成碎片撒在全天的所以体感上你不会觉得我今天浪费了一小时只会觉得我今天整个人都很飘什么都没做成。更隐蔽的是AI 工具的交互形态天然鼓励碎片化。你不知道该怎么问就先问一句试试觉得回答不够好就换个说法再问一遍突然想到另一个维度又开一个新对话。对话多了之后你自己都记不清哪个窗口里有那个还不错的答案。2.2 验证成本生成三分钟核对半小时前面提过验证是时间黑洞这里说具体一点为什么它这么费人。AI 的输出有一个结构性的问题它把不确定和确定混在一起用完全相同的语气表达出来。一段代码里框架用法是准的业务逻辑是编的一份调研里公开常识是准的具体数字是猜的一段文案里结构是合理的行业术语是用错的。你必须逐句去分辨哪部分能信。这种逐句分辨的工作专业性要求反而比你自己写更高——你得先懂才有资格审。我自己有个很直观的感受写一版的痛苦是输出痛苦审一版的痛苦是判断痛苦。前者消耗的是体力做完了有明确的完成感后者消耗的是心气做完之后你甚至说不清自己到底贡献了什么。这也是为什么很多人反馈AI 帮我写完我比我自己写还累。2.3 技能折旧焦虑与评价标准抬升这两条要放在一起说因为它们是互相咬合的齿轮。技能折旧焦虑很好理解AI 每个月都在补新能力你上个月刚学会的一套提示词写法这个月模型升级之后可能直接不需要了。就学吧学不完不学吧又怕哪天被落下。这种追不上的感觉本身就是内耗它不需要真的发生什么坏事光是可能会发生就足够让你在周末的下午不安。而评价标准抬升是外部施加的AI 让及格线这件事变得模糊了。一份文案以前完成就完成现在交付方心里隐隐有个预期——你不是有 AI 吗怎么才这个水平。于是你必须把 AI 生成的初稿再往上提一档才能证明自己的价值。工具提升的是下限但被拿去比较的永远是上限中间这段差距就得靠人的时间填。实操心得把技能折旧这件事从焦虑转成清单。方法很简单每月月底花二十分钟写下这个月我靠 AI 省下来的具体动作和这个月我新学会的具体动作各写三条。写不出来才需要慌写得出来说明你在往前走只是感觉没跟上。焦虑是感觉清单是事实事实能压住感觉。3. 提示词与工作流把 AI 从加压泵改造成减压阀前面把病因说得比较透了接下来讲能动手的部分。这一节不聊玄学只聊我反复验证过、能真正减少返工的写法。3.1 三段式提示词模板角色、约束、验收标准网上流传的提示词模板多到看不完但真正稳定好用的我最后收敛成了一个很朴素的三段式。第一段给角色和场景不是让它扮演某个头衔而是给它足够的背景信息。比如不要写你是一个资深架构师而要写我在维护一个跑了三年的订单系统日订单量大约十万主要痛点是高峰期数据库连接池打满。前者几乎不产生作用后者会显著改变它的回答方向。第二段给约束明确说清不允许做什么。这一步最省时间。比如不要引入新的第三方依赖不要改数据库表结构回答控制在三百字内先给结论。约束越具体你后面改的轮次越少。第三段给验收标准告诉它你会用什么标准来判断这个结果行不行。比如我会把这段代码直接贴进项目跑单元测试所以所有外部调用都要能 mock我会拿这段文案去给一个完全不懂这个行业的人看所以不要出现没有解释的缩写。模板长这样【背景】我在做一件什么事目前的状态是……已有的资源是……。 【任务】这次需要产出的是……交付形式是……。 【约束】不要……不要……长度/格式要求是……。 【验收】我会用……的方式检查所以你需要保证……。 【如果信息不够】不要编直接列出你需要我补充的信息。最后那句不要编直接问是我加得最值的一句。它把很多本来会变成返工的幻觉提前拦在了生成阶段。3.2 个人任务分流表哪些交给 AI哪些绝对不交我踩过最大的坑是早期什么都想交给 AI 试一遍结果大量时间花在教它理解我的场景上反而不如自己动手。后来我做了一张分流表把日常任务分成三类边界清楚之后效率才真正上来。任务类型典型例子交给 AI 的比例核心理由结构型任务写周报框架、生成表格模板、整理会议要点、改写成不同语气80% 到 90%有明确格式对错易判断改起来便宜检索型任务查某个概念的通用解释、找同类方案、列出可能的排查方向50% 到 70%能快速给覆盖面但细节必须自己复核判断型任务做技术选型、定方案优先级、给同事做绩效反馈、写重要邮件10% 到 20%依赖你手里的隐性信息AI 缺的正是这部分这张表的关键不在比例而在第三行的绝对不交。判断型任务你交给 AI得到的是一个看起来合理的通用答案你还得花时间把它改回你自己的语境来回一趟比直接写还慢。把 AI 当参谋不当决策者这条线守住内耗会少一大截。3.3 批处理思维把二十次碎问合并成一次深聊碎片化问答是我前面提的注意力杀手解决办法不是少用而是把并行改成串行把碎问改成长对话。具体做法每天开工前花十分钟把当天需要用 AI 处理的事情列出来合并到同一个对话里按顺序处理。因为上下文是连续的模型知道你前面在说什么你后面的提问可以越来越短反而省字。更重要的是你自己的思路也是连续的不会每次都要重新搭建一次心智框架。我实测过两种节奏的差别。碎片式做法一整天随机问了二十次每次两三句最后只用了其中三四个答案其余全忘在标签页里。批处理做法集中在上午和下午各开一次长对话每次四十分钟处理八到十个事项结束的时候把所有结论一次性导出到笔记里。后面这种当天晚上我基本不会再有还有什么没弄完的悬空感。悬空感才是内耗的真正燃料。注意长对话有个副作用上下文太长之后模型的注意力会分散。我的做法是超过大约二十轮就主动收敛一次——让它把所有结论按条列出来复制走然后开新对话把结论作为背景重新贴进去。这一步多花两分钟能省掉后面半小时的来回纠正。4. 工程视角的解法把重复劳动真真正正自动化掉如果说前面几节是在管理消耗这一节讲的是减少消耗。真正能让人从累里脱身的从来不是更聪明地用聊天框而是把那些每周都要重复一遍的流程做成不用你盯着的自动化。这部分内容偏工程但思路对非技术岗位同样适用。4.1 从聊天到 Agent什么样的活值得做成自动流程先说一个判断标准避免一上来就过度工程化。我的标准是三条同时满足才值得做每周重复三次以上、步骤固定、单次耗时超过五分钟。三条里缺一条做成自动化的收益都覆盖不了维护成本。为什么强调维护成本因为自动化流程不是一次写完就永远好用的。接口会变、数据格式会变、依赖的版本会升级你写的那些脚本每年至少要有几次修修补补。我见过太多人一时兴起写了十几个自动化脚本三个月之后自己都忘了哪个是干嘛的全部废弃白折腾。满足条件之后Agent 式的流程比单纯的对话强在哪里强在它可以自己决定下一步。举个不涉及具体业务的例子你让它把本周的数据报表更新一下一个好用的 Agent 会自己拆成先拉数、再校验行数、再生成图表、再写到指定位置、最后跑一遍一致性检查这几步中间如果拉数失败了它会去看是权限问题还是接口超时而不是直接给你返回一句抱歉操作失败。用伪代码描述这个循环大概是# 一个极简的工具调用循环示意 while not task_done: plan model.plan(task, history) # 让模型决定下一步做什么 if plan.is_final: break tool tools[plan.tool_name] # 从注册好的工具里选一个 try: result tool.run(**plan.args) # 真正执行 except Exception as e: history.append(f工具失败{e}请换一种方式或先检查前置条件) continue # 关键把错误喂回去让它自己纠 history.append(result) if step_count MAX_STEPS: # 必须设上限否则会空转烧钱 raise RuntimeError(步骤超限人工介入)这段里两个细节值得单独说。一是错误回喂这是 Agent 和普通脚本最大的区别脚本遇到异常就挂了Agent 会把异常当成新信息继续想。二是步骤上限我吃过一次亏一个循环因为工具返回格式不对自己跟自己绕了四十多轮既没结果也耗资源。现在我的所有流程都强制设MAX_STEPS一般是正常所需步数的两到三倍。4.2 本地部署的取舍显存估算与量化选择很多同行想在自己机器上跑模型动机通常是三个数据不出本机、不用排队、随时可调。但一上手就卡在我这台机器能跑多大的这个问题上。这里给一套我自己用的粗算方法。先记住一个基本公式参数量换算成显存占用权重占用 ≈ 参数量(B) × 每个权重占的位数 ÷ 8 × 1.1那个 1.1 是留出来的余量用于运行时的一些额外开销。按这个算一个 7B 的模型如果用 4 位量化这是目前最常用的档位理论上是 7 × 4 ÷ 8 3.5GB乘 1.1 约 3.9GB再加上上下文缓存实际大概落在 5GB 到 6GB 之间。然后是上下文缓存这一项最容易被忽略。它大致正比于层数 × 注意力头维度 × 序列长度 × 并发数所以上下文从 4K 拉到 32K这部分占用可能翻好几倍。我的经验是权重占用先按公式算出来再额外留 30% 到 50% 给上下文和临时开销这样不容易出现权重能装下但一对话就崩的情况。模型规模常见量化权重粗略占用建议可用显存含上下文余量适用场景3B 级别4 位约 2GB4GB 以上文本分类、简单改写、关键词抽取7B 到 8B 级别4 位约 4GB8GB 以上日常问答、代码补全、文档摘要14B 级别4 位约 8GB16GB 以上结构化输出、较复杂的推理任务32B 级别4 位约 18GB24GB 以上接近可用的代码生成与方案起草选量化档位的时候有个取舍口诀能跑起来优先于跑得聪明。我见过不少人为了追求精度硬上高比特量化结果机器风扇狂转、响应十几秒一次最后根本用不下去。宁可先用低一档的量化跑顺跑顺了再考虑升级。部署的路径从省事到可控大致是三档一键式运行工具适合只想快速体验底层的推理框架适合要控制参数和并发服务化部署比如把模型包装成标准接口适合团队内共享。个人用前两档足够如果是要给一个小团队在内网提供统一入口那就得走第三档顺便把访问日志和配额一起设计进去不然容易变成谁都能用、谁都不负责的状态。4.3 AI 编程的验收红线不跑测试就不算完成AI 辅助写代码这件事我用得很多也踩过不少坑。总结下来最有价值的一条是把能不能跑通测试当成唯一验收标准而不是看起来对不对。为什么因为模型在写代码的时候非常擅长把逻辑写得很像那么回事。缩进整齐、变量名合理、注释到位你在阅读的时候大脑会自动给它打高分。但读代码和跑代码是两回事边界条件、空值处理、并发时序这些地方光靠读很难发现。我现在的流程固定成四步第一步先让模型写出接口定义和测试用例先不要写实现。这一步的价值在于把要做什么提前固化下来避免写到一半需求飘了。第二步让它按测试写实现。写完必须自己跑一遍把真实的报错信息原样贴回去而不是描述成运行失败了。报错的堆栈信息里包含大量线索模型能更准地定位。第三步我自己看一遍 diff。重点看三类地方有没有偷偷引入新依赖、有没有删掉原有的校验逻辑、异常处理有没有被简化成一句打印。这三类是模型最容易顺手做掉的地方。第四步跑一遍全量测试和静态检查。# 每次 AI 改完代码之后我固定跑的检查顺序 git diff --stat # 先看动了多少文件异常多的先停下来审 python -m pytest -q # 单元测试快的话几十秒 ruff check . ruff format --check . # 静态检查与格式 mypy src/ --ignore-missing-imports # 类型检查有类型标注的项目提示让 AI 改代码的时候一次只改一个目标。你说顺手把这个也优化一下它很可能在你不注意的地方重构了一大片而那一大片恰恰是没有测试覆盖的区域。改动范围越小出问题的概率越低review 的成本也越低。5. 常见问题与排查技巧实录前面是方法这一节是问题和坑。我把这一年里反复遇到的状况整理成了一张表再挑几个印象最深的展开说。5.1 常见问题速查表现象大概率原因处理方式输出看起来很对但细节全是错的背景信息给得太少模型在补空白补上业务背景、数据口径、约束条件再问一次同一份任务每次结果差异很大提示词没有固定结构随机性过高把提示词模板固化下来变量单独抽出来长对话到后面越答越飘上下文过长导致注意力分散让它先输出结论清单然后开新对话把清单当背景自动化流程跑一半卡住缺少步骤上限和错误分支加MAX_STEPS把异常信息回喂给它自己纠本地模型响应很慢量化档位过高或者上下文开得太大降一档量化把上下文从 32K 调回 8K 试试用了一段时间反而更焦虑大概率是任务通胀不是工具问题统计一次真实的时间去向把边界重新划一遍5.2 我自己踩过的三个坑第一个坑是信得太早。有一次我让 AI 帮忙写一段数据口径说明它写得非常规范连字段来源都列出来了我扫了一眼觉得没问题就发出去了。结果里面引用的一个字段名是上一个版本的命名早就改了。那次之后我给自己定了个规矩凡是涉及具体字段名、接口名、人名、金额的一律逐个核对不管文案写得多顺。第二个坑是提示词越写越长。我一度沉迷于优化提示词一份模板写到八百多字结果每次问问题都要粘一大堆背景反而变成了负担。后来想通了长模板应该沉淀成文件需要的时候直接把文件内容整体喂进去而不是每次手动拼。工具的优化到最后都是工程化的问题不是写作的问题。第三个坑是把学习当成了产出。有一段时间我每天都在看新出的工具、新的用法笔记记了一大堆但真正落地的没有几个。这种状态最像内耗——你在持续输入看起来一直在进步但工作成果并没有变好。我的应对办法是给学习设一个硬约束学到一个新方法之后必须在一周之内用在真实的活上用不上就先不学。这条规则砍掉了我大量的无效输入。6. 边界管理对抗内耗最后拼的是下班的能力前面讲了那么多工具和方法但如果你问我最有效的一条是什么答案可能有点反常识不是更会用 AI而是更会用不用 AI的时间。内耗这件事本质上是注意力没有归处什么时候你脑子里同时挂着五件没完的事什么时候你就开始累。6.1 给 AI 定一个营业时间我给自己的 AI 使用设了时间窗早上九点半到十一点集中处理需要 AI 协作的事下午两点到四点再开一段。其余时间除非有明确的紧急任务不主动打开对话窗口。这个规则听起来有点刻意但效果非常明显。原因在于AI 的交互形式是你随时可以问而随时可以问的反面就是随时都在想着问。给自己设个窗口之后那些冒出来的零碎念头会被自动归档到下午两点一起处理而不是立刻打断你手头的事。这和批量处理是同一个思路只是从任务层面上升到了时间层面。还有一条更重要的晚上十点之后不碰生成类工具。原因很实际生成这件事有上瘾性你总会想再试一次会不会更好而深夜的判断力最差很容易在低质量的优化上耗掉一两个小时第二天带着疲惫开工进入恶性循环。6.2 建立成果物台账把感觉忙换成看得见的产出内耗很大一部分来自我明明很忙但说不出做成了什么。这种模糊感会持续消耗心力。我的解法是每天下班前花五分钟记一条台账格式固定成三行今天完成一句话写清楚交付出去的东西是什么 今天推进一句话写清楚还差多少就能交付 今天学到一句话写清楚学到了什么具体的、能复用的东西三行都很短但坚持一段时间之后效果很不一样。因为当你觉得这周啥也没干的时候翻一下台账往往能看到五六件具体的东西。焦虑和事实之间的落差就是这么被抹平的。再补一个我一直在用的判断标准如果某天结束的时候我能明确说出今天有一样东西是交付出去的那天基本不会内耗。如果我只能说出今天处理了很多事情那这天大概率是累的。处理事情和处理交付物是两回事前者消耗你后者支撑你。最后分享一个我最近才开始做的调整。我把每周三下午空出来不排任何 AI 相关的任务只做需要长时间专注、不需要工具介入的事——读一份完整的技术文档、把上周的流程重画一遍、或者干脆整理一下文件系统。这三四个小时看起来效率很低但它是我一周里脑子最清楚的时段。工具把人从重复劳动里解放出来之后那些解放出来的时间该用来干什么这个问题没人替你回答得自己想。我现在越来越觉得AI 越强人越需要主动去守住那些不高效但重要的时间那不是浪费那是把自己从工具节奏里捞回来的唯一方式。
返回列表