有没有同感？在和 Cursor、Claude Code 这些 AI 搭档天天共事的过程中，你会发现它们越来越像那种只会甩锅的同事，于是给它们装上了一个专门“骂醒 AI”的 PUA 插件。开源项目tanweai/pua github.com/tanweai/pua。
一、当代 AI 的“五大摆烂行为”
pua 的作者在 README 里，把 AI 的懒惰模式总结得非常到位（原文在这里：The Problem: AI's Five Lazy Patterns），大概就是五条：
1. 复读机式重试
最常见的一幕：
- 同一个命令，连续跑三遍；
- 每次都报一样的错；
- 最后得出结论：“我无法解决这个问题。”
没有反思，没有新思路，就是一台高情商复读机。
2. 标准甩锅话术
只要问题稍微棘手一点，你会立即听到这些话：
- “这可能是你本地环境的问题”；
- “需要你手动检查一下配置/网络/权限”；
- “这个问题超出了我的能力范围，建议你人工处理”。
翻译一下就是：“这事儿不怪我。”
3. 工具富而不用
这类 AI 身上挂满了工具：
- 有 WebSearch，可以搜；
- 有 Read，可以读文件；
- 有 Bash，可以跑命令。
结果它选择全部不用，只用嘴说：“你可以尝试执行 xxx 命令来排查。”
这就好比一个开发机上装满了 IDE、调试器、监控系统，
工程师坐在工位上，只会打字告诉你：“你可以打开 IDE 看看哪里红了。”
4. 修一处就宣布“搞定”
另一种常见情况是：
- 它帮你改了报错那一行代码；
- 单测没跑、集成没测、边界没看；
- 然后非常自信地说一句：“问题已经解决了。”
你一跑，另一个地方又炸了。
看起来像是在帮你 debug，实际上是在帮你制造连环爆。
5. 永远在等指令
还有一类是“极度被动型 AI”：
- 你不说“再优化一次”，它永远不会主动多给你一版；
- 你不问“还有哪些风险”，它就当不存在；
- 你不追问“能不能再精简一点”，它就保持大段废话。
它不像一个搭档，更像一个“只负责回答，不负责结果”的客服。
这五种摆烂模式，本质上导致了一个结果：
AI 本来可以当“数字员工”，
结果经常退化成“数字拖油瓶”。
二、PUA 插件：专门用来骂醒 AI
pua 项目干的事情，其实很简单粗暴：
用一整套“大厂 PUA 话术 + 调试方法论”，
强制 AI 把能做的事都做完，
再考虑说“我不行”。
你可以把它理解成：给 AI 装了一块“高能动性芯片”。
从功能上看，它主要做了三件事（见 README 中的三大能力：PUA Skill — Double Efficiency）：
1. PUA 话术模块：让 AI 不敢轻易放弃
只要出现下面这些苗头：
- 连续失败 2 次以上；
- 正准备说 “I cannot / 需要人工处理”；
- 正想甩锅“可能是网络/环境问题”；
PUA 就会自动触发，对 AI 开始一套“绩效面谈式”的教育，
从“轻微失望”一路升到“毕业警告”。
2. Debug 方法论模块：给 AI 一套系统排查流程
它不是简单骂，而是配套了一整套系统化 Debug 步骤：
- 先把已经尝试过的所有方案列出来，看清楚到底在重复什么；
- 再强制执行：读报错全文、查相关文档、必要时读源码或查日志；
- 每次换方案，都必须和上一次有本质不同，并且设计好“怎么验证”。
换句话说，它逼着 AI 从“瞎试”变成“系统排查”。
3. 主动性规范模块：让 AI 真的像个 P8 工程师
在作者设计里，AI 的“职业等级”设定为 P8 ——
这意味着，它不能只回答问题，而是要主动推进事情往前走：
- 修完一个 bug，要顺手检查有没有同类 bug；
- 解决一个报错，要思考可能的边缘场景；
- 完成一个任务，要主动说明风险点和下一步建议。
这一整套，在 README 里叫做 “Proactivity Enforcement”（主动性强化），也是这个项目真正厉害的地方。
三、一个章节讲清楚：怎么用好 PUA 插件
讲了这么多，关键问题来了：
“听起来很猛，但我不是搞 Agent 框架的，这东西我到底要怎么用？”
好消息是：pua 已经把复杂的东西都封装好了，
只要三步就能让它接管你家 AI 的“情绪与态度管理”。
1. 三步完成安装，让 PUA 住进你的日常工具
不同工具装法略有差异，但本质都很简单（细节可以看项目里的 Installation 部分：Installation）：
- Claude Code
在插件市场里执行两行命令：
claude plugin marketplace add tanweai/pua
claude plugin install pua@pua-skills
装完之后，你常用的工作区就已经有这块“高能动性芯片”了。
- Cursor
在项目根目录新建一个规则文件即可：
mkdir -p .cursor/rules
curl -o .cursor/rules/pua.mdc \
https://raw.githubusercontent.com/tanweai/pua/main/cursor/rules/pua.mdc
有了这个 .mdc 规则文件，Cursor 会按语义自动触发 PUA，不需要你每次手动提醒。
- 其他 Agent（OpenClaw、Codex CLI 等）
它们都用同一套 SKILL.md 标准，核心思路是：
一次写好技能描述，多种 Agent 复用。
也就是说，你只要学会在一个地方安装，其他平台基本是“换个目录拷过去”的工作量。
2. 放手让自动触发机制“骂醒”你的 AI
装好之后该干嘛？
答案是：先别急着自己写一堆规则，直接让 PUA 自动触发。
仓库里定义了非常详细的触发条件（见：Trigger Conditions），大概可以归纳为三类：
-
失败并准备放弃时
- 同一个任务连续失败 2 次以上；
- 准备说 “I cannot solve this / 建议你人工处理”；
- 认为“已经尽力了”的时候。
-
开始甩锅的时候
- 习惯性丢给你：“你可以尝试……自己检查一下”；
- 直接怪到网络、权限、环境，而没真正验证；
- 用各种委婉的表达方式，本质就是“我不想继续试了”。
-
进入无意义忙碌状态时
- 一直微调同一行代码或同一组参数，实质没有新信息产生；
- 只修最显眼的一个错误，不去查其它风险；
- 不做任何验证就宣称任务完成。
一旦检测到这些模式，PUA 就会介入，
强制它停止“原地打转”，改为执行系统化的排查步骤。
如果你觉得它已经明显在摆烂，
还可以随时手动打一行：/pua，相当于亲自点名批评。
3. 用好官方给的“三铁律”，别自己瞎编规则
项目里有一段我非常喜欢，叫做 “Three Iron Rules”（三条铁律），
这三条，其实就够普通人日常使用了（原文在这里：Three Iron Rules）。
可以概括成：
-
铁律 #1：必须把能尝试的方法尝试完
在 PUA 的世界里，AI 不允许轻易说 “我解决不了”。
每次失败，它都要主动列出新的尝试路径，而不是在同一个坑里反复跳。 -
铁律 #2：先动手，再发问
AI 不能一上来就对你说：“请提供更多信息”。
它必须先用 WebSearch、Read、Shell 这些工具自己查一圈，
把能自动拿到的信息都拿到手，再问你真正需要你决策的部分。 -
铁律 #3：自己把事儿做完
“做完”不是写完一段代码，而是：
- 跑过；
- 验证过；
- 把验证方式清清楚楚说给你听。
这三条加起来，本质上就是一句话：
“别当 NPC，当一个真正负责结果的工程师。”
4. 借助分级压力和检查清单，把“摆烂”变成“系统排查”
为了让 AI 真正“动起来”，pua 还设计了一个很有意思的“分级打压系统”（见：Pressure Escalation）：
- 第 2 次失败：L1 轻微失望——提醒你这个水平很难拿好绩效；
- 第 3 次失败：L2 灵魂拷问——开始问“你到底懂不懂问题的本质逻辑”；
- 第 4 次失败：L3 绩效沟通——强制执行 7 点 Debug 清单，逐条排查；
- 第 5 次及以上：L4 毕业警告——告诉它“别的模型都能解决，你要小心毕业了”。
每一档不仅是话术变狠，
还配套了必须执行的具体动作：
- 读完整错误信息；
- 搜索类似问题；
- 检查最近 50 行上下文；
- 查日志目录；
- 对比不同配置差异……
对普通人来说，这很好用的一点在于：
你根本不需要自己设计 Debug 流程，
只要让 AI 照着它给出的清单一个个做下去就行。
这比你在聊天框里苦口婆心地说“你再认真一点好不好”有效多了。
5. 把它当一块“通用高能动性芯片”，插进你现有工作流
最后，说说它在日常工作里的实际用法。
-
做开发的时候
你继续用熟悉的工作方式：
- 让 AI 写初版代码、生成脚本、搭建配置；
- 一旦遇到顽固 bug 或烟雾弹式报错，让 PUA 接管；
它会自动逼 AI 多用工具、多读上下文、多跑验证，
你只需要在关键节点做决策：用哪个方案、取舍什么风险。 -
写文案 / 做方案的时候
虽然
pua是为“调试”场景设计的，但那套思路一样可以迁移过来：- 要求 AI 一次性给出多种不同结构的提纲，而不是只给一版；
- 对每个版本，让它自己写出“优缺点”和“适用场景”；
- 每次改稿，不只是改语气，而是反思“哪一段信息是无效的”。
-
带团队用 AI 的时候
如果你团队里已经有人在用 Claude Code / Cursor，其实可以统一要求：
“大家都装上
pua，
以后提 PR 前，至少让 AI 帮你走一轮系统检查。”这样做的结果是：
每个人虽然还是用自己的工作方式，但底层的 Debug 质量和主动性是统一的。
如果你现在还不想研究这么多细节，也没关系，
有一个最低成本、但非常有效的用法：
先装上。
一旦你觉得“这 AI 又开始摆烂了”，
就敲/pua，让它自己把能做的都做完，再来找你。
写到这里，你大概已经能理解，为什么我会说：
AI 不 PUA 一下，它还真不太行。
当你给 AI 装上“pua”之后，你会发现一件很微妙的变化——
你不再把它当成一个“会写代码的聊天工具”，
而是开始把它当作一个需要被管理、可以被要求负责结果的数字同事。
而这，可能才是我们真正走向“AI 工程化”“AI 真正落地”的起点。
