现在最需要被 PUA 的，其实是 AI

有没有同感？在和 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

在插件市场里执行两行命令：

bash 复制代码

claude plugin marketplace add tanweai/pua
claude plugin install pua@pua-skills

装完之后，你常用的工作区就已经有这块"高能动性芯片"了。

Cursor

在项目根目录新建一个规则文件即可：

bash 复制代码

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 真正落地"的起点。