pua

pua skill 概览

pua 实际上是做什么的

pua skill 本质上是一层面向 agent 工作的“语气与行为覆盖层”：当会话中出现挫败、反复失败、执行被动，或交付质量偏低时，它会把模型推向一种高压、高主动性的执行风格。实际用下来，pua 的重点不在于增加新工具，而在于改变 agent 在工作时如何规划、验证、升级处理，以及如何表达。

哪些人适合用 pua

pua 适合那些希望在 coding、debug、deployment 或 research 流程里获得更强执行闭环的人，前提是你能接受一种偏强势、带“管理压迫感”的表达方式。它尤其适合已经熟悉自己环境的操作者：你不是要 agent 继续打太极，而是希望它更认真搜索、更充分验证、更主动补齐闭环。

pua 真正解决的核心问题

大多数考虑 pua 的人，并不是为了娱乐效果；他们想要的是一个不会太早放弃、不会停在第一个看似合理答案、也不会在没有证据时就宣称完成的 agent。这个 skill 面向的就是那类“再试狠一点、验证再多一点、结果你来负责”的场景。

pua 和普通 prompt 的真正区别

普通 prompt 最多只能临时要求一次“严谨点”。pua 提供的是一整套可复用的工作模式：失败升级、基于 flavor 的领导风格、按任务类型切换方法论、固定展示规范，以及通过 ~/.pua/evolution.md 实现的可选长期基线记忆。相比一次性的“主动一点”，它的结构化程度要高得多。

安装前要先想清楚的主要取舍

pua for Workflow Automation 最大的价值，是显著提升“必须完成”和“必须验证”的压力。最大的代价则是语气：这个 pua skill 故意写得尖锐、角色感强，而且带有明显的文化化风格。如果你要的是平静的 pair programming、对新手友好的辅导，或者中性克制的企业沟通语言，那它大概率并不适合。

如何使用 pua skill

pua 在你的工作流里应该放在哪

把 pua 当成会话级修饰器来用，最适合在 agent 卡住、表现不达标，或者明显过于被动时启用。它尤其适合出现在多次失败、被质疑质量、或收到“这样不行”“还不够好”这类反馈之后，因为仓库本身就是围绕这些触发信号设计的。

采用 pua 前，优先看哪些内容

先读 skills/pua/SKILL.md，搞清楚触发逻辑、flavor 切换方式和任务路由机制。然后看 skills/pua/references/display-protocol.md 了解输出格式，看 skills/pua/references/methodology-router.md 理解任务到方法论的映射；如果你更关心语气定制，而不是纯执行压力，再去看 skills/pua/references/flavors.md。

最值得重点看的支撑文件

如果你打算认真使用 pua skill，最影响决策的文件主要是：

• skills/pua/references/agent-team.md：多 agent 委派规则
• skills/pua/references/evolution-protocol.md：持久化基线行为
• skills/pua/references/p7-protocol.md、skills/pua/references/p9-protocol.md 和 skills/pua/references/p10-protocol.md：升级路径
• 方法论文件，例如 skills/pua/references/methodology-alibaba.md 和 skills/pua/references/methodology-huawei.md：执行风格约束

pua 在实际使用中是怎么被触发的

从仓库内容来看，pua 设计上会被这类信号触发：反复失败、类似“stop spinning”“you broke it”“why does this still not work”这样的抱怨、显式输入 /pua，以及其他挫败感明显的话术。也就是说，pua 不是那种“所有任务都开着就行”的东西；当上下文已经显露出推进乏力或责任感不足时，它的效果最强。

要让 pua 发挥效果，输入里最好带上什么

想让 pua 表现更好，请尽量在请求里提供：

• 明确的任务目标和完成定义
• 已经失败过什么、失败了几次
• 当前约束，比如 repo、branch、runtime 或权限
• 什么算作证据，例如 build、test、curl、截图或 diffs
• 你希望它单兵执行，还是拆成多 agent 协作

如果缺少这些上下文，这个 skill 可能只会把压力和篇幅拉高，但不一定真的改善结果。

怎样写出更有效的 pua prompt

一个弱 prompt 是：“Use pua and fix this.”
一个更强、也更符合 pua guide 风格的写法是：“Use pua on this failing API route. We already tried two fixes and both broke auth. Root-cause it, verify with the project test command, check similar routes for the same defect class, and do not mark done without evidence.”

后者更有效，是因为它明确给出了失败历史、问题范围、预期行为和验证要求——而这些正是这个 skill 要强制落实的核心信息。

如何把模糊目标转成有效的 pua 用法

如果你的目标只是“把 deployment 跑起来”，最好先改写成：

1. 目标环境和失败症状
2. 已经尝试过的方案
3. 哪些边界不能动
4. 成功证据是什么
5. 是否要求 agent 顺手扫描相邻风险

这一步很关键，因为 pua 明确鼓励更完整的收尾方式，例如检查同类模块和下游影响，而不是只修掉眼前第一个可见问题。

pua 会如何按任务类型做路由

这个 skill 对方法论选择是有明显立场的。debug 类任务通常会偏向 root-cause 和对抗式分析；feature 工作更强调简化方案和尽快交付；review 类任务则会更多转向品味判断和删减优化。这一点是仓库里最容易被低估、但实际很有价值的部分之一——它解释了为什么你可能会想安装 pua，而不是继续复用一个泛泛的“be strict”系统 prompt。

团队模型会怎样改变 pua 的使用方式

如果你本来就跑多 agent 方案，那 pua for Workflow Automation 的吸引力会更强。仓库里提供了从 P10 到 P7 的四层团队模型，并明确说明了什么时候该由 P8 直接执行，什么时候该拆出 P7 风格的 sub-agents。如果你始终只是单助手聊天，这部分价值就没那么大。

pua 在宣告完成前会看重哪些质量信号

这个 skill 强烈偏向“可观察的闭环”：例如 build/test 通过、health check 正常、直接验证成立、以及做过影响面扫描。如果你的环境没法跑命令，也很难给出证据，那 pua 的实际价值通常会打折，因为它大量的纪律性就来自“不闭环就不认 done”。

做 pua 安装决策时的实际部署注意点

SKILL.md 里并没有明显给出安装命令，所以你的 pua install 决策，不应主要看包管理层面的安装方式，而要更多判断宿主是否支持 skill loading，以及是否支持位于 ~/.pua/config.json 和 ~/.pua/evolution.md 的可选用户级状态。如果你的平台不能注入 session state，也不能持久化本地文件，那么 pua 的一些高级行为就无法真正落地。

pua skill 常见问题

pua 适合新手吗

通常不太适合。pua skill 默认你能承受较强烈、接近批评式的表达，也知道如何消化这种高压指令。新手更需要的是清晰解释和脚手架式引导，而不是额外压力。

pua 只是语气包吗

不是。语气只是最表层的可见部分，更深层的价值在于执行纪律：方法论路由、升级阈值、验证压力，以及明确的团队协议。如果把行为模型拿掉，只保留声音风格，那你会失去它大部分实际价值。

什么情况下不该用 pua

不要把 pua 用在敏感情绪场景、软性辅导、面向用户的支持文案，或者需要中性沟通的团队里。任务非常小、范围本来就很清楚时，也建议跳过，因为整套框架可能比任务本身还重。

pua 和直接让模型“try harder”有什么不同

泛泛地说一句“try harder”，只能提高强度，但通常不会定义清楚：方法该怎么选、何时该升级、要收集哪些证据、以及 sub-agents 该怎么协作。pua usage 的结构化程度明显更高，尤其是在你真的去读那些 reference protocols 之后。

pua 只对 coding 有帮助吗

不是。仓库里覆盖了 code、config、debug、deploy 和 research 等多种用例。不过它最有说服力的场景，仍然是那些有客观检查标准的任务，因为这正是它“必须闭环”思路最容易被量化验证的地方。

不用那些 corporate-style flavor packs，也能用 pua 吗

可以，但只能说部分成立。你可以忽略大部分 flavor 相关内容，仍然从工作流设计里获益；但这个 skill 的整体架构本来就深度围绕 flavor 选择构建。如果你天然反感这种设定，比起整套照搬，更适合把其中的 protocols 单独抽出来用。

如何改进 pua skill 的使用效果

给 pua 一个更紧的完成定义

想快速提升 pua 效果，最直接的方法就是把“完成”写成可衡量条件。好的例子包括：“tests pass”“endpoint returns 200”“migration is reversible”，或者“scan similar handlers for the same bug pattern”。这和 skill 内建的偏好高度一致：先验证，再追求更完整的闭环。

不只描述当前问题，也要给出失败历史

因为 pua 会感知触发背景，所以你明确说出此前怎么失败过，它就更有用。像“这是第三次尝试”“上一个 patch 把 auth 搞坏了”“这个问题只在 staging 复现”这类信息，都能帮助它更合理地选择升级策略和问题假设。

按任务去读对的 reference file

不要每次都把全部 references 从头读完。做 debugging 时，优先看方法论路由和验证相关文件；做多 agent 协作时，直接去 skills/pua/references/agent-team.md；要调语气，就看 skills/pua/references/flavors.md；如果是长期个人工作流，再看 skills/pua/references/evolution-protocol.md。

要求高证据密度输出，而不只是高置信表达

一个常见失败模式是：语气更凶了，但推理质量并没有同步变好。避免这种情况的方法，是明确要求它给出执行过的命令、被排除的假设、检查过的文件，以及相邻风险扫描结果。这样会逼着 pua skill 产出“看得见的工作”，而不是只把旁白说得更响。

任务很小时，把 pua 的范围收紧

另一个常见问题，是在简单任务上过度加工。对于一行修复或非常小的改动，可以要求保留 pua 的执行纪律，但不要上满 banners、roleplay 或团队结构。仓库本身就区分了不同任务复杂度下的输出密度；照这个思路用，skill 才会更实用，而不是流于表演。

拿到第一轮 pua 输出后继续迭代

如果第一版回答太重表演感，就把指令收紧：少一点口号，多一点 root-cause analysis、更强一点 validation，或者要求明确比较备选方案。如果它又显得太窄，就让它检查相似模块、上下游影响，以及遗漏的 edge cases——这正是这个 skill 所鼓励的那种“冰山下面还有冰山”的思考方式。

让 pua 贴合你的环境

仓库里暗示了本地配置能力：可通过 ~/.pua/config.json 做本地配置，通过 ~/.pua/evolution.md 保存持久化基线状态。如果宿主支持这些能力，就把你偏好的 flavor 和已经验证过的验证模式固化下来。这样 pua for Workflow Automation 才能在多次会话里保持一致，而不是每次都从零开始。

想清楚采用 pua 的核心判断题

真正的安装问题不是“pua 聪不聪明”，而是“它会不会让我的 agent 在真实工作流里更可追责、更能闭环”。如果你要的是更强的责任感、更系统的验证，以及更成熟的升级纪律，那 pua 背后确实有一套结构。如果你主要想要的是一个让人舒服的 coding companion，那就应该选更轻的方案。