用压力型提示词驱动 AI Agent：PUAClaw 与 pua 两个开源项目解析

AI Agent 做开发任务时，最常见的问题不是完全不会做，而是容易在几种低效状态里反复打转：

• 错误信息没读全，就开始猜原因；
• 执行失败后继续换一种说法重试，没有验证新假设；
• 只回答用户问到的部分，不主动检查上下文；
• 发现路径走不通后，没有切换排查策略；
• 修改代码时顺手扩大改动范围，带来额外风险。

压力型提示词试图解决的正是这些问题。它用强角色设定、责任约束、行为清单、失败后复盘等方式，让大语言模型（LLM，Large Language Model）更像一个被严格要求的工程师，而不是一个随口回答问题的聊天机器人。

这类提示词的典型写法，曾经因为某些编程产品的系统提示词泄露而出圈：模型被设定成一个必须完成任务、不能偷懒、不能随意改动代码、失败会承担严重后果的角色。虽然这种写法带有明显戏剧化成分，但它背后反映了一个真实问题：提示词不仅能描述任务，也能塑造模型的行为风格。

围绕这个方向，最近有两个开源项目比较有代表性：

PUAClaw: https://github.com/puaclaw/PUAClaw
pua:     https://github.com/tanweai/pua

它们都使用了“PUA”这个带有戏谑色彩的说法，但从工程角度看，更准确的理解方式是：用压力型提示词和调试流程约束 AI Agent 的行为。

压力型提示词到底在影响什么

大语言模型不会真的“被激将”，也不会像人一样产生羞耻感或责任感。所谓 PUA 式提示词能起作用，主要是因为它改变了模型生成答案时的上下文权重。

一个普通任务提示词通常只告诉模型“做什么”：

帮我修复这个 MCP server 加载失败的问题。

压力型提示词会额外告诉模型“应该以什么标准做、不能犯哪些错、失败后如何调整”：

你现在不能继续猜测。先逐字读取错误信息，再定位日志文件，
列出 3 个可能原因，并为每个原因设计一个可验证的检查步骤。
如果某条路径失败，必须说明失败证据，再切换到下一条路径。

这两种提示词的差别不在情绪强度，而在约束密度。

flowchart TD
    A[用户提出任务] --> B{提示词是否只描述目标}
    B -->|是| C[模型直接给答案或尝试执行]
    C --> D{失败了吗}
    D -->|是| E[可能重复猜测或原地打转]

    B -->|否，包含行为约束| F[模型按流程拆解任务]
    F --> G[读取证据]
    G --> H[形成假设]
    H --> I[执行验证]
    I --> J{验证结果}
    J -->|失败| K[记录失败证据并切换思路]
    J -->|成功| L[输出修复方案和复盘]

所以，真正有价值的部分通常不是“骂模型”或者“给模型制造压力”，而是这些内容：

PUAClaw：把压力型提示词做成分类库

PUAClaw 更像一个提示词话术标本库。它收集了大量对 AI 有“心理压力”或“说服力”的表达方式，并尝试给这些技巧做分类和评级。

它的定位不是一个直接接入 Agent 的调试工具，而是一个提示词工程资料库。你可以把它理解成一个“压力型提示词模式大全”：里面记录了各种通过语言框架影响模型行为的技巧，例如激将、催促、责任绑定、道德约束、失败惩罚、奖励诱导等。

项目里一共整理了 96 项技巧，并且都围绕“如何改变 AI 回复行为”展开。

PUAClaw 适合研究哪些问题

PUAClaw 的价值在于把零散的话术整理成可观察、可比较的模式。很多人写提示词时只会凭感觉追加一句“认真一点”“不要偷懒”，但这种写法很难复用，也很难判断到底哪里起作用。

用分类库的方式看压力型提示词，会更容易拆出几个变量：

把提示词拆到这个粒度后，就可以更清楚地判断：某个提示词到底是在增加任务严肃性，还是在提供可执行流程。

PUAClaw 的正确使用方式

PUAClaw 不应该被当成“让模型更听话的魔法咒语”。更稳妥的用法是从里面提取可复用的提示词结构。

例如，把夸张情绪去掉后，一个工程化版本可以写成这样：

你需要像资深工程师一样处理这个问题。

要求：
1. 不要在没有证据的情况下猜测原因。
2. 先读取完整错误信息，再判断问题类型。
3. 每个假设必须对应一个验证步骤。
4. 如果连续两次失败，停止当前方向，重新列出可能原因。
5. 最终答案必须包含：根因、修改点、验证命令、潜在风险。

这种写法保留了压力型提示词的核心：提高标准、限制坏行为、要求可验证结果。同时避免让提示词变成单纯的情绪勒索。

pua：把“大厂式压力”封装成 Agent Skill

另一个项目 tanweai/pua 更偏实用。它把一套“大厂式 PUA 工作习惯”封装成可以嵌入 AI Agent 的 Skill。

这里的 Skill 可以理解为一组可复用的 Agent 指令包。它不是单次对话里的几句话，而是可以被 Agent 加载、触发、反复使用的一套行为规范。

这个项目的核心目标可以拆成三部分：

其中真正关键的是第二点：调试方法论。
如果只有压力话术，没有排查流程，模型可能只是更自信地胡说；如果有清晰的检查清单，模型才更可能从“聊天”切换到“工程排障”。

pua 的典型工作流

pua 的使用场景很明确：当 AI Agent 解决问题时卡住了，可以手动触发 /pua，让它停止原来的低效循环，进入更严格的排查模式。

以一个 MCP server 加载失败的问题为例。MCP（Model Context Protocol，模型上下文协议）常用于让 AI 工具连接外部服务、文件、数据库或其他能力。当某个 MCP server 加载失败时，Agent 很容易陷入几个错误方向：

• 反复检查配置文件格式；
• 猜测依赖没安装；
• 手动修改 .claude.json；
• 忽略 Claude Code 自身的 MCP 注册机制；
• 没有去看真正的 MCP 日志。

触发 /pua 后，理想流程会变成这样：

sequenceDiagram
    participant User as 用户
    participant Agent as AI Agent
    participant Logs as Claude Code 日志
    participant Config as MCP 配置/注册机制

    User->>Agent: MCP server 加载失败，触发 /pua
    Agent->>Agent: 停止重复尝试，进入检查清单
    Agent->>Agent: 逐字读取错误信息
    Agent->>Logs: 查找 Claude Code 的 MCP 日志目录
    Logs-->>Agent: 返回加载失败细节
    Agent->>Config: 对比 claude mcp 注册机制与 .claude.json 手动编辑方式
    Config-->>Agent: 定位配置方式不一致
    Agent-->>User: 给出根因、修复步骤和验证方法

这个案例说明，pua 起作用的原因并不是“模型被骂醒了”，而是它被迫执行了一套更可靠的排障路径：

逐字读错误信息
→ 找到 Claude Code 自身的 MCP 日志
→ 识别 claude mcp 注册机制
→ 对比手动编辑 .claude.json 的差异
→ 定位根因
→ 修复并验证

这套流程对开发类 Agent 很重要。很多问题不是因为模型缺少知识，而是因为它没有坚持走完证据链。

两个项目的差异

PUAClaw 和 pua 都围绕压力型提示词，但侧重点不同。

可以这样理解：
PUAClaw 更像“提示词修辞学”，pua 更像“Agent 管理制度”。

压力型提示词为什么有时真的有用

从模型行为角度看，压力型提示词通常通过四种方式发挥作用。

1. 提高任务优先级

普通提示词可能让模型把任务当成一次问答。加入强约束后，模型会更倾向于生成完整、谨慎、结构化的回答。

不要只给建议，要给出可以执行的步骤。
不要省略验证过程。
不要在没有日志的情况下判断根因。

这种约束会影响模型输出的完整度。

2. 降低偷懒回答概率

AI Agent 失败时，经常会输出类似内容：

可能是配置问题，你可以检查一下路径是否正确。

这类回答看似合理，但对排障帮助很小。更好的提示词会直接禁止这种模糊输出：

如果判断是配置问题，必须指出具体配置项、当前值、期望值和验证命令。

模型被要求给出证据后，空泛回答的空间会变小。

3. 强制执行 Debug 流程

开发问题通常需要按顺序排查。压力型提示词可以把流程写死，让 Agent 不容易跳步。

flowchart LR
    A[读取报错] --> B[定位日志]
    B --> C[列出假设]
    C --> D[逐个验证]
    D --> E{是否解决}
    E -->|否| F[记录失败证据]
    F --> C
    E -->|是| G[总结根因和验证结果]

这类流程约束比单纯说“认真调试”更有效。

4. 要求复盘，减少“碰巧修好”

Agent 有时会改很多东西，最后问题消失了，但没人知道真正起作用的是哪一步。复盘要求可以降低这种风险：

修复后必须说明：
1. 最初的错误现象是什么；
2. 哪条证据指向根因；
3. 修改了哪些文件或配置；
4. 用什么命令验证成功；
5. 哪些尝试被排除，为什么。

这能让人类开发者判断结果是否可信，也方便后续维护。

使用这类 Skill 时要注意什么

压力型提示词不是越狠越好。它有几个明显风险。

更稳妥的写法是把“压力”转化成工程约束：

你必须遵守以下规则：
- 不执行破坏性命令，除非用户明确确认。
- 不修改无关文件。
- 不根据猜测给结论。
- 每次失败后必须记录失败原因。
- 连续两次失败必须切换排查方向。

这种提示词没有戏剧化表达，但对 Agent 的行为控制更直接。

怎么上手这两个项目

两个项目都托管在 GitHub，可以先从仓库内容和 README 入手。

git clone https://github.com/puaclaw/PUAClaw.git
git clone https://github.com/tanweai/pua.git

使用 PUAClaw 的方式

PUAClaw 更适合当作提示词模式库来读。可以按这个顺序使用：

1. 找到适合当前任务的压力型技巧；
2. 去掉过度戏剧化的表达；
3. 保留行为约束、检查清单和输出标准；
4. 嵌入到自己的 Agent 系统提示词或项目规则里；
5. 用同一类任务对比改造前后的输出质量。

一个适合编程 Agent 的改造模板：

你是一个负责代码修改的 AI Agent。

工作规则：
1. 修改前先确认目标文件和影响范围。
2. 不做用户没有要求的重构。
3. 遇到报错时先读取完整错误信息。
4. 不允许只给“可能原因”，必须给验证步骤。
5. 修改后提供测试命令或验证方式。
6. 如果无法完成，说明缺少什么信息，而不是编造结果。

使用 pua 的方式

pua 更适合在 Agent 卡住时作为强制调试模式触发。使用方式取决于具体 AI 工具是否支持 Skill、Slash Command 或自定义指令。

通用接入思路是：

可以准备一个简化版 /pua 指令：

进入严格 Debug 模式。

停止重复刚才的思路，按以下流程执行：
1. 复述当前错误现象。
2. 逐字读取关键错误信息。
3. 找到相关日志、配置文件或命令输出。
4. 列出最多 3 个候选根因。
5. 每个根因必须给出验证方法。
6. 验证失败后记录证据，不要重复尝试。
7. 修复后给出根因、改动点和验证命令。

这类指令的目标不是让 Agent “害怕”，而是让它无法绕过关键步骤。

更推荐的实践方式

如果要把压力型提示词用于日常开发，建议把它拆成两层：

flowchart TD
    A[日常 Agent 规则] --> B[谨慎修改代码]
    A --> C[不编造结果]
    A --> D[输出验证方式]

    E[故障排查触发器 /pua] --> F[停止重复尝试]
    E --> G[强制读取日志]
    E --> H[列假设并验证]
    E --> I[失败后切换方向]
    E --> J[修复后复盘]

日常规则保持简洁，避免每次回答都很重；只有当 Agent 明显卡住、重复失败或开始空泛解释时，再触发更严格的调试 Skill。

一个比较实用的判断标准是：

核心结论

PUAClaw 和 pua 的价值不在于“PUA”这个噱头，而在于它们把一个常见经验显性化了：AI Agent 需要行为约束，而不只是任务描述。

PUAClaw 提供了大量压力型提示词模式，适合研究提示词如何影响模型行为；pua 则把这种思路落到 Agent 调试流程里，用检查清单、失败切换和复盘机制减少原地打转。

真正值得复用的是这套工程化思路：

少一点情绪表演，
多一点证据要求；
少一点“认真点”的口号，
多一点可执行检查清单；
少一点无限重试，
多一点失败后的方向切换。

当提示词从“请求模型帮忙”变成“规定 Agent 如何工作”，AI Agent 才更接近一个可管理、可复盘、可调试的工程工具。