昨晚十一点我向 AI 要一段批量重命名文件的脚本。它回了我满满一屏内容大概是先解析文件名的规则再构建新旧路径映射表最后调用操作系统接口完成替换——看起来逻辑清晰实际上全是“思路”没有一行能直接跑的代码。我盯着屏幕看了三分钟突然意识到一件事不是 AI 偷懒是我惯的。我没给它明确到近乎苛刻的交付标准它当然选择输出最安全、最正确、最没用的东西。后来我慢慢总结出一套话术网上管这叫“用大厂 PUA 方式驱动 AI”说白了就是把目标管理、验收标准、过程追问这些项目管理手段原封不动搬进提示词里。这篇就写这份实战经验AI 写代码时装忙、甩锅、摆烂具体怎么治。先说清楚标题里的“PUA”是借用法不是让你去骂 AI、贬低 AI。大厂那套打法真正能用的部分是目标对齐、任务拆解、强制反馈和验收兜底。拿这些去管理 AI 写代码比任何“请帮我写个脚本”都管用。下面我会从症状诊断、底层原理、方法论、模板抄作业一直讲到验收防御体系全程是我实测过的内容。1. AI 写代码的三大摆烂病装忙、甩锅、摆烂具体长什么样1.1 装忙输出一屏“方向正确”的废话但找不到一行能跑的代码这是我遇到最多的情况。你问它“用 Python 写一个监控文件夹变化的脚本”它能给你输出小标题、分步骤、列注意事项甚至贴心地提醒你“记得先安装依赖”但整个回复里没有任何一个完整的函数所有关键位置都用省略号代替最后来一句“接下来你只需要把业务逻辑补充完整即可”。我管这叫装忙。它的回答在形式上极其勤奋在内容上零产出。就好比你问实习生“把这份报表做出来”他花了半小时给你写了一篇《如何用 Excel 制作报表》的说明文档然后告诉你“你照着做就行了”。方向没错常识也没错但你要的是报表本身不是报告。另一种装忙更隐蔽它会真的写出代码但所有真正麻烦的部分全部用注释糊弄过去。比如“# 这里需要对特殊字符做转义处理”“# 这里建议用正则提取已完成 80%”你往下一翻好家伙核心逻辑一行没有。这种代码别说运行连粘贴进编辑器都会让 lint 报一堆未定义变量。1.2 甩锅问题刚冒头它先把自己摘干净比装忙更让人血压升高的是甩锅。你拿到它给的代码跑了一下报错把错误信息贴回去它第一反应不是承认自己写错了而是说“这可能与你本地环境有关”“你需要确认一下 Python 版本是否满足要求”“建议你先检查依赖是否完整安装”。这些话术模板我在大厂同事嘴里听过无数遍现在 AI 也学会了。它的核心逻辑是先把责任边界划清楚只要能归因到外部环境它就不用重写代码。你继续追问它才会慢吞吞地“重新审视”然后轻描淡写来一句“哦这里确实有个地方写错了”。还有一种甩锅更高级你让它优化一段性能差的代码它会说“你的原始实现存在多个瓶颈建议重构架构后再优化”。翻译一下就是“你这代码太烂我改不了你先自己把烂摊子收拾好再来找我”。它把问题重新抛回给你自己站在原地不动。1.3 摆烂交出一段明显没过脑子的代码报错之后继续摆最让人崩溃的是摆烂。你明明给了清晰需求它交出来的代码要么函数名瞎编要么参数个数对不上要么用了根本不存在的方法名。比如我让它写一个图片批量压缩脚本它给我调了一个 Pillow 库里的假方法我本地一跑直接抛 AttributeError。把报错贴给它它沉默了两秒然后说“可能是版本差异请升级到最新版本试试”。这种回答的本质是放弃了推理赌一个低概率的归因。它不知道确切原因但也不愿意说“我不确定”于是随便编一个听起来合理的解释看你能不能接受。如果你接受了它就糊弄过去了你不接受它就换一个继续赌。这种状态就是在摆烂。这三种病我后来都找到了对应的治法和话术但先说一个结论我踩过这么多坑之后发现AI 表现出什么样的行为大概率取决于你把需求写成什么样。你给它模糊的自由发挥空间它就会用最省力的方式回应你。下面这张表是我整理的速查对照后面几章全是围绕它展开的。AI 症状典型表现根子在哪话术解药装忙给思路、给建议、给方向就是不给成品没有明确交付物约束设定唯一交付物完整可运行的代码甩锅报错后归因于环境、版本、依赖没有责任边界设定强制要求它定位根因并输出修复后的完整文件摆烂瞎编方法名、忽略边界情况、赌一个解释没有验收标准和自检环节要求它做语法自查、边界检查、输出自检清单2. 为什么 AI 会摆烂大模型的生成机制决定了它天生“防御性输出”2.1 概率采样让它天然倾向“安全废话”而不是“有效狠活”要治 AI 的摆烂你得先明白它为什么这么“怂”。大模型本质是一个概率预测器它根据你给的上下文逐字逐句预测最可能出现的下一个 token。训练数据里大量的人类回答都是“礼貌、周全、谨慎、多角度分析”的再加上后续偏好对齐环节会把“高赞回答”作为优化目标AI 最终学到的是输出那些所有人都觉得“没什么毛病”的内容。这种内容放在社交场景里是教科书级的高情商回复放在工程场景里就是废纸。因为你描述“监控文件夹变化”时训练数据里出现频率最高的可能是一篇讲“可以用 watchdog 库、也可以自己轮询、需要注意性能、不要频繁扫描”的博客而不是一段直接能用、踩过坑的完整代码。你就当大模型是一个刚入职的实习生在没拿到明确任务书的时候最安全的行为是“表现态度”而不是“交付成果”。它宁可说“我会努力的”也不愿动手做一件可能出错的事。AI 同样是这个逻辑输出“思路”几乎不会出错但输出“可运行代码”则有一百种翻车方式。在模型看来两者收益不对等它自然选择前者。这就是“装忙”的底层原因。2.2 你没有给它立规矩它就按自己的最低标准交活还有一个重要原因是模型对“任务完成”的定义非常模糊。你说“帮我写个爬虫”对它而言只要在回复里提到了 requests、BeautifulSoup就算完成了目标至于代码能不能跑、能不能处理编码问题、能不能应对网站反爬它不知道也默认你不需要。因为你的要求里没有验收标准这四个字。这就牵扯到一个反常识的认知AI 的“理解”依赖于你把所有隐含需求显式化。它不会像真人同事那样知道“写脚本”意味着“能跑成功、能处理异常、能考虑边界”。你需要告诉它代码必须我能直接复制运行依赖必须标注清楚核心逻辑必须不依赖我的业务补充异常情况必须给出处理。你不说它就按最低标准糊弄你。生活里可以类比你找朋友“帮忙看下电脑为什么卡”朋友可能只会说“重装系统就好了”因为你没限定“必须保留我的文件和数据”。而你要的是“清掉启动项、更新驱动、还不破坏现有软件”。同样的道理AI 也是看人下菜碟你的 Prompt 越短它的完成任务的门槛就越低。2.3 角色设定为什么有效不是魔法是改变了概率分布很多人问我为什么加一句“你是一名资深 Python 工程师”效果就好很多这本质上不是 AI 真的进入了角色而是这句话改变了它后续生成 token 的概率分布。训练数据里当一个回答以“资深工程师”的口吻开始时后面跟着出现“完整代码、工程化命名、错误处理”的概率会显著提高。所以角色设定不是让它“入戏”而是给它圈定一个风格域。你用“你是一个 Python 讲师”和“你是一名交付过生产系统的后端工程师”得到的代码风格会有明显差异。前者倾向于解释原理因为讲师的任务是把知识讲明白后者倾向于直接给你能用的东西因为工程师的工作是交付结果。理解这层原理之后你就明白为什么网传各种“魔法提示词”其实都是同一件事用高信息密度的约束条件把模型输出的概率空间从“安全废话分布”硬生生掰到“交付结果分布”。后面的所有话术都围绕这个在做优化。3. 核心方法论用“目标管理话术”给 AI 立规矩让装忙甩锅无处遁形3.1 写一条“合同式 Prompt”身份、任务、交付物、验收标准、禁止项一个都不能少我现在写任何 AI 编程请求都遵循一个格式叫“合同式 Prompt”。模板长这样你是一名有 8 年经验的 Python 工程师。现在接到一个任务写一个脚本监控某个目录当目录下有新文件出现时打印文件路径并把路径追加到日志文件中。交付物要求一段可以直接复制运行的完整 Python 代码不包含任何 TODO 占位不包含示意性的注释逻辑必须闭环。验收标准我把代码保存为 monitor.py 并运行后在目标目录放一个新文件它能在 5 秒内检测到并写入日志。不需要给我讲解原理不要给我列步骤我只收代码。这段话每一个元素都是有针对性的。“资深工程师”是把风格拉到交付域“监控某个目录”是具体任务描述“直接复制运行、不包含 TODO、不包含示意性注释”是堵住装忙的嘴“验收标准”具体到“5 秒内检测到并写入日志”让 AI 无法反过来问你“那你的需求细节到底是什么”最后一句“不需要讲解、不要列步骤、我只收代码”是掐灭它写废话的冲动。一开始用这套模板最直观的感受是AI 废话量骤降 80%开头第一段就是 import第二段就是主逻辑。偶尔还会有几句总结但已经不会出现“建议你先理清需求”这种甩锅句了。3.2 大任务拆小活一次只让它交付一个闭环别让复杂度逼它退缩合同式 Prompt 有一个大坑任务一复杂AI 还是容易摆烂。因为“写一个完整的电商后端”这种任务太庞大了模型在预测 token 时根本看不到全局它的工作记忆会被巨大的信息量压垮然后退回“安全废话”或“骨架代码”模式。解决办法是拆活。我踩了几次坑之后养成的习惯让 AI 写任何模块之前先让它按交付单元拆任务清单。比如你有一个“用户注册登录”需求不要直接说“帮我写登录模块”而是拆成三层先让它写一个独立的“数据库连接工具类”只负责建连接、执行 SQL、返回结果。验证它可用之后再让它写“用户表模型”包含建表语句和基础 CRUD。最后才让它写登录接口复用前面已经验证过的工具类。每一步都是一个小闭环都有明确的验收方式。AI 面对一个小任务时没有借口缩回“思路”里因为范围就那么大它只需要写一个函数就够了。这个道理跟人类协作一摸一样你让一个程序员“把系统整体做出来”和对他说“今天只需要把登录接口调通参数我已经测过联调环境可用”后者的交付概率高得多。拆活还有一个额外好处你可以在每一步之间插入验收和修正。如果第一步的连接工具类写歪了后面就不会继续错下去而不是等到最后拿到一整坨烂摊子再返工。3.3 像开周会一样管过程交付后必须追问、验收、打回别让它蒙混过关大厂管理层最喜欢干的事就是周会追问。这套动作用在 AI 上效果出乎意料地好。我总结了一个闭环流程每次拿到 AI 代码都会走一遍第一次交付后立刻问这代码里有没有 TODO、占位符或半成品逻辑有就全部实现后再发完整版。跑通之后再问请检查极端情况。文件不存在时该报什么错参数为空时会不会崩把错误处理补全。如果它交出的代码有报错不要接受“可能是环境问题”这种回答直接把错误信息贴过去然后要求定位根因给出修复后的完整文件而不是讲思路。这套追问最大的价值是把“验收”变成流程中的一环让 AI 知道自己每次交付后都要面临检查于是它一开始就会更认真地写。我在实测里发现当你在 Prompt 里预先声明“交付后我会让你自查语法、边界和异常路径”AI 给出的代码质量会有肉眼可见的提升因为它在生成时就为后续的“检查”预留了余量。说白了AI 没有责任心但它有“求生欲”——它的求生欲体现在尽量让回答在形式上和你的要求对齐。如果你的流程里有“验收”这个环节它就会在生成时模拟已经被验收的状态反过来迫使自己写得更完整。这就是“用流程管理代替结果管理”。4. 可以直接抄作业的提示词模板我实测有效的五套话术4.1 单文件交付型最适合“给我写一个小工具”的场景日常使用频率最高的一套。适用于脚本、小工具、单函数实现。它解决的核心问题是“装忙”用强交付物约束把 AI 锁死。你是一名有多年经验的实战工程师。现在请用 Python 写一个命令行工具输入一个文件夹路径递归找出所有体积超过 100MB 的文件并输出它们的路径和大小。交付物一个可直接运行的完整 Python 脚本禁止使用 TODO、pass、省略号或任何示意性代码。验收标准我运行 python big_files.py /path/to/folder 之后终端能直接看到按大小排序的结果列表。不要解释原理不要分步骤说明直接给代码。用这套模板的时候我几乎没再收到过“思路型回复”。偶尔它结尾还会带一句“你可以根据需求调整阈值”但代码主体是完整的。需要注意的是命令行的参数解析如果涉及复杂 flag建议在 Prompt 里明确交互方式避免它自作主张设计一个你没想来要的参数接口。4.2 先方案后代码型适合需求复杂、方向不明确的场景有些时候任务本身是对的但实现路径有好几条直接让 AI 写代码很可能写歪到外婆家。这种情况下我会先要求它出方案并设定成“我不点头你就不许写代码”。你是一名资深架构师。我要实现一个功能多服务器之间同步一个配置文件任何一台修改后其他服务器在 60 秒内感知并拉取最新版本。请不要直接写代码。先给我输出 3 种实现方案包括每种方案的架构思路、优缺点、需要的中间件和部署改造成本。最后给出你的推荐和我需要做的决策。等我确认方案后你才能开始写具体代码。这套话术的精髓在于它把“决策权”放在你手里AI 只负责输出候选方案。这样既避免了它盲目写代码也方便你在讨论过程中把自己的约束条件比如“公司已有消息队列可以用”注入进去。我实际用下来这套模板给到的方案质量普遍不错因为模型在“分析模式”下的表现力本来就强于“闷头写模式”你等于让它先发挥长处再进到短处环节。4.3 强制自检型适合有一定重要性的代码防止摆烂式交付当某个代码要进到生产环境或者影响面比较大时我会在 Prompt 末尾追加一段“自检要求”。同样一段代码加上自检和不加自检质量差距很明显。在交付代码之前请先进行以下自检 1. 检查所有引用的库和函数名是否真实存在版本是否标注清楚。 2. 检查代码是否存在明显的边界问题比如除零、文件不存在、列表越界。 3. 检查是否有隐藏的 TODO、占位逻辑或被注释掉的半成品代码。 4. 检查资源是否可能泄漏如文件句柄、网络连接是否需要主动关闭。 请先把自检结果写出来再给最终完整代码。这个模板表面上是在“约束格式”实际上是在改变 AI 的生成策略。当它知道自己必须输出自检结果时它在生成代码时就会刻意避免那些容易暴露的问题。实测下来带上自检要求后它瞎编函数名的情况大幅减少因为你等于提前告诉它“我会盯你的调用链”。4.4 分步对账型适合多文件、项目级改动让 AI 汇报工作进度写跨文件项目时最怕 AI 一口气吐出五六个文件每个都半残。我后来改用“分步对账”的方式每次只让它动一个文件然后停下来等我验收。这是一个多文件改动任务。第一步先创建 utils.py里面包含所有公共函数比如日志初始化、配置文件读取。只做这一个文件做完就停下来等我检查。检查通过后我再告诉你下一步写什么。禁止一次性输出全部文件禁止在代码里引用尚未创建的文件。请确认你理解了这个流程然后开始第一步。这套话术等于给 AI 装了一个“逐步放行”的开关。它必须等你的检查指令才能继续下一步。这看起来效率变低了实际反而省时间因为项目级错误一旦堆叠起来排查的成本远高于多花几轮对话的成本。而且分步对账最适合配合版本控制使用每个文件过一遍有问题随时回滚整体工程质量会稳很多。4.5 纠错复读型AI 犯错之后防它“口头认错但不动手”AI 报错后最容易出现的坑是它口头上说“你说得对抱歉”然后给你一段“分析”但核心代码完全没改。针对这个我总结了一句万金油续命提示词几乎所有纠错场景都能用道歉和分析都没用。请你直接输出修复后的完整代码文件不要省略任何部分不要只给修改片段不要用注释代替实现。必须保证全文复制粘贴后能直接运行通过。这句话我愿称之为“专治嘴炮式道歉”。“直接输出完整文件”彻底堵死了 AI 只给 diff 片段或修改建议的退路“不要省略任何部分”防止它在长代码里用“其余部分保持不变”偷懒“必须直接运行通过”把验收标准拉满。实测用它做纠错时AI 给出可运行文档的概率能提升到九成以上。5. 防摆烂防御体系验收它而不是信任它附实测避坑记录5.1 三层验收法拿到代码先别急着夸按这三步检查不管 Prompt 写得多么天衣无缝AI 的代码依然可能翻车。我给自己定了一套“三层验收法”每次拿到代码都走一遍第一层看它能不能跑。保存到文件实际执行一次看是否有语法错误、缺失依赖、调用不存在的函数。这一步解决 70% 的低级问题。第二层看它跑得对不对。用两个测试样例验证逻辑是否符合需求尤其关注边界情况——空列表、空文件、超大输入、特殊字符。很多时候 AI 写的代码在“正常情况”下跑得很顺但一旦遇到空值和脏数据就崩。第三层把它扔进真实场景。比如它写的是文件处理工具就拿一个真实目录里的混合文件去跑它写的是数据清洗脚本就拿一份真实脏数据去喂。只有过了这三层我才会考虑把代码纳入自己的工具链。有人觉得这样做太累但我的观点是AI 写代码的价值是帮你省掉从零构思和写框架的时间而不是替你做测试。你把验收时间花在刀刃上整体效率依然是纯手写的数倍。5.2 真实翻车记录AI 甩锅给环境结果问题出在它自己身上分享一个印象深刻的翻车经历。我让 AI 写一个图片批处理脚本需要把目录下所有 JPG 压缩到指定尺寸并保持宽高比。它交付的代码里用到了一个 Pillow 库的缩略图方法我本地一跑直接报 “can only concatenate str” 类型错误。我把错误信息原封不动贴回去它回复“可能是你的 Pillow 版本过低请升级到 Pillow 10 以上。”我当时的反应是“真的假的”然后我升级了库再跑还是报错。于是我把报错堆栈再贴给它压了一句“问题还在请定位真正的根因不要猜测不要建议大家升级环境。”它才“啊是我疏忽了”——原来是它在构造输出路径时把字符串和 Path 对象直接做了拼接字段类型不匹配。这就是典型的甩锅加摆烂连环操作自己写错了先怪环境被追问之后才肯真正查看错误堆栈。这件事给我两个教训第一AI 的“可能是环境问题”跟真人一样是一种低成本的试探性归因你一旦接受了它就逃过一劫第二你必须有足够的能力判断它是否在胡说。至少要把报错堆栈看懂知道是语法错误、类型错误、还是依赖缺失才不会被它的借口带偏。5.3 AI 不知道你的环境所以要在话术里提前给它“装环境”AI 经常写出跨平台有问题的代码根源在于它不知道你实际运行在什么环境。比如我用 Windows 本地开发部署到 Linux 服务器时经常遇到路径分隔符问题。AI 生成本地处理逻辑时脑子里可能默认了 POSIX 路径风格结果在 Windows 上直接失败。我后来在每一条 Prompt 里都加了一句环境声明“运行环境是 Windows 11Python 3.10代码风格必须兼容跨平台路径处理禁止硬编码路径分隔符。”就这么一句让路径类 bug 少了一大半。你会觉得这太基础了但我实测中大量报错都源于这种“你没说它默认然后翻车”的情况。记住一个原则AI 是在替你写你的代码不是你替它写代码。你的环境信息、约束条件、技术栈版本、甚至你希望用的库都必须写进上下文里。喂给它的信息越像“新人入职第一天看到的需求文档”它交付的东西就越像老员工干的活。6. 这套话术的边界与刹车线什么时候最值什么时候别硬来6.1 最值钱的场景重复性、模式化、有清晰验收标准的代码实话说这套“PUA 式驱动”并不是所有场景都好用。它的最佳适用面是模式化开发、重复劳动、样板代码、胶水代码。比如写自动化脚本、批量数据处理、生成 API 调用封装、搭项目骨架、写单元测试样例——这些任务需求清楚、边界明确、验收标准天然存在你把合同式 Prompt 一放属于降维打击。在这种场景下我实测的收益是纯手写效率的 3 到 5 倍。尤其当你要写一个以前写过的同类型脚本时AI 基本能直接产出八成熟的成品你只需要做最后的调整和测试。这就是提示词工程的复利第一次你花 5 分钟把需求写清楚后面每次类似需求都能直接复用同套模板。6.2 别硬来的场景需要深度业务决策、领域判断和品味的地方如果一个任务核心在于“判断该做什么、不该做什么”比如设计核心业务架构、规划数据模型归属、梳理复杂的权限体系就不要指望 AI 通过一段话术就能扛住。这种任务你用再强的 Prompt它也只是在“看起来像那么回事”的层面上运作而真正的业务决策需要你对领域上下文的理解这是模型目前给不了的东西。另一种别硬来的情况是你完全看不懂它输出的代码。如果一个代码跑不跑得通、改得对不对你都无法判断那再精妙的提示词也只是自我安慰。AI 写代码的下限永远取决于你的验收能力下限。我的建议是先把报错信息、基础语法、常见库调用学会再谈用 AI 提效。否则你会得到无数个“看起来能用但实际四不像”的东西最后反而比手写更浪费时间。6.3 那套话术带来的隐形收益写完 Prompt 的那一刻需求也理清了最后说一个我没想到的收获。用这套话术驱动 AI 写代码半年之后我发现自己向真人同事提需求的表达能力也变强了。原因很简单你每次都要想清楚交付物是什么、验收标准是什么、边界条件是什么才能写出好的 Prompt。这种“把模糊想法转成清晰需求”的能力几乎是所有协作场景共同的底层能力。我现在遇到一个任务第一反应已经不再是从零写而是花三分钟把任务拆成“身份、任务、交付物、验收标准、禁止项”这五要素。写完之后哪怕不用 AI我自己动手写代码的思路都清晰很多。有些时候把需求写明白问题就已经解决了一半。所以标题里的“大厂 PUA 话术驱动”落到实际并不是什么玄学就是一场目标管理变革把你对模糊的容忍度降低到零把验收前置到每一步里把甩锅和装忙的机会彻底关掉。最后留个最简兜底模板存起来随时用你的身份是高级软件工程师。任务实现【功能】。交付物完整可运行代码禁止 TODO、禁止假代码、禁止省略。验收标准【写出明确的行为描述】。运行环境【你的系统、语言版本、依赖限制】。不要讲思路不要列步骤直接给最终代码。我个人在实际操作中的体会是AI 就像一面镜子你给它模糊期许它还你一篇正确的废话你给它死磕到底的要求它就能交出能打的东西。别抱怨它摆烂先看看自己的 Prompt 是不是给了它摆烂的空间。