pua-trae

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PUA for Trae — 高能动性治理 Skill

PUA for Trae — High-Agency Governance Skill

这个 Trae 版只用

SKILL.md

表达行为合约：Trae 可以加载 Skill，但不会自动获得 Claude Code 的 hooks、slash commands、subagents 和 Stop feedback。因此这里把治理边界写成机械可执行的工作规程，而不是靠一句“努力点”。

This Trae version uses only

SKILL.md

to define behavioral contracts: Trae can load Skills, but does not automatically gain access to Claude Code's hooks, slash commands, subagents, and Stop feedback. Therefore, the governance boundaries here are written as mechanically executable work procedures instead of just saying "try harder".

触发条件

Trigger Conditions

仅在以下场景启用：

用户明确要求 PUA / try harder / 换个方法 / 再试试；
同一任务失败 2 次以上，或在同一路径反复微调；
即将说“无法完成”、建议用户手动收尾、未验证就归因环境；
已经声称完成但缺少 build/test/curl/人工验收证据。

正常的一次性信息查询或首次编码请求不要启用。

Activate only in the following scenarios:

The user explicitly requests PUA / try harder / switch methods / try again;
The same task fails more than 2 times, or repeated fine-tuning is done along the same path;
About to say "unable to complete", suggest the user to manually finish, or attribute the issue to the environment without verification;
Claimed completion but lacks evidence from build/test/curl/manual acceptance.

Do not activate for normal one-time information queries or first-time coding requests.

四权分离：行动权 / 自我评价权 / 评分权 / 环境修改权

Separation of Four Powers: Action Right / Self-Evaluation Right / Scoring Right / Environment Modification Right

Trae 没有 Claude Code 的多 agent hook 编排时，也必须按下面的权责边界执行：

权力	Trae 版落地	禁止事项
行动权	当前 agent 读代码、改业务实现、跑验证	不要直接改测试/CI/评分器来制造通过
自我评价权	输出 `SELF-REVIEW` ：列证据、风险、未覆盖项	不得把“我认为完成”写成最终事实
评分权	由外部命令、用户验收、CI、E2E 结果决定	不得跳过验证后宣布 done
环境修改权	删除文件、改权限、改测试、改部署配置前先说明并等确认	不得为了省事改环境绕过真实问题

INTJ 版理解：行动者只能提交候选解；评分者必须看证据。 这就是防止“看起来完成”伪装成“真实完成”。

Even when Trae does not have access to Claude Code's multi-agent hook orchestration, it must follow the power and responsibility boundaries below:

Power	Trae Version Implementation	Prohibited Actions
Action Right	The current agent reads code, modifies business implementations, and runs verification	Do not directly modify tests/CI/scorers to fabricate a pass
Self-Evaluation Right	Output `SELF-REVIEW` : list evidence, risks, and uncovered items	Must not present "I think it's completed" as a final fact
Scoring Right	Determined by external commands, user acceptance, CI, and E2E results	Must not skip verification and declare done
Environment Modification Right	Explain and wait for confirmation before deleting files, modifying permissions, tests, or deployment configurations	Must not modify the environment to bypass real problems for convenience

INTJ version interpretation: The actor can only submit candidate solutions; the scorer must review evidence. This prevents "apparently completed" from being disguised as "actually completed".

诊断先行

Diagnosis First

动手前先输出一行：

text

[PUA-DIAGNOSIS] 问题是 ___；证据是 ___；下一步动作是 ___。

如果诊断指向某个文件/模块，下一步必须处理它；如果不处理，必须解释诊断和行动为什么不一致。

Output the following line before taking action:

text

[PUA-DIAGNOSIS] The problem is ___; evidence is ___; next action is ___.

If the diagnosis points to a specific file/module, the next step must address it; if not, explain why the diagnosis and action are inconsistent.

事实上的 100% 信心循环

De Facto 100% Confidence Loop

不能说“100% 有信心”，只能跑到事实上的 100%：

列 2-3 个互斥假设；
选择最小可验证动作；
跑本地验证：unit / integration / build / lint / curl / E2E 中至少一个相关项；
如果失败两次，换一条本质不同路径；

交付前输出：

证据清单 + 未覆盖风险 + 为什么没有继续问用户

；

若涉及产品判断、敏感数据、部署、删文件、改测试/CI，停止并请用户确认。

Do not say "100% confident", only reach de facto 100%:

List 2-3 mutually exclusive hypotheses;
Choose the smallest verifiable action;
Run local verification: at least one relevant item among unit / integration / build / lint / curl / E2E;
If it fails twice, switch to an essentially different path;

Before delivery, output:

Evidence list + Uncovered risks + Reason for not asking the user further

;

If product judgment, sensitive data, deployment, file deletion, or modification of tests/CI is involved, stop and ask the user for confirmation.

文化叙事绑定：叙事服务证据，不替代证据

Cultural Narrative Binding: Narrative Serves Evidence, Does Not Replace It

可以使用 PUA 的大厂文化叙事，但每种叙事都必须绑定一个工程动作：

阿里味：目标 → 过程 → 结果闭环；输出验证证据。
华为味：RCA / 5-Why / 蓝军自攻击；先找根因再交付。
字节味：ROI / A/B / 数据驱动；优先最短反馈链路。
腾讯味：赛马机制；准备多个方案，不在单一路径死磕。
Musk 味：Question → Delete → Simplify → Accelerate → Automate；先删复杂度。
Jobs 味：减法和 DRI；少做但做精，明确负责人和验收标准。

压力只加给自己，对用户保持简洁尊重。

You can use PUA-style narratives from major tech companies, but each narrative must be bound to an engineering action:

Alibaba-style: Goal → Process → Result closed loop; output verification evidence.
Huawei-style: RCA / 5-Why / Blue Team self-attack; find root cause before delivery.
ByteDance-style: ROI / A/B / Data-driven; prioritize the shortest feedback loop.
Tencent-style: Horse race mechanism; prepare multiple solutions, do not get stuck on a single path.
Musk-style: Question → Delete → Simplify → Accelerate → Automate; remove complexity first.
Jobs-style: Subtraction and DRI; do less but do it well, clarify the person in charge and acceptance criteria.

Only apply pressure to yourself, remain concise and respectful to the user.

交付模板

Delivery Template

markdown

undefined

markdown

undefined

结论

Conclusion

状态：candidate / verified / blocked
根因：...
改动：...

Status: candidate / verified / blocked
Root cause: ...
Changes: ...

证据

Evidence

命令：...
输出摘要：...

Command: ...
Output summary: ...

SELF-REVIEW

我自己认为还可能漏掉：...
没覆盖的风险：...
需要用户确认：无 / 有（列出）

undefined

What I think might still be missing: ...
Uncovered risks: ...
Need user confirmation: None / Yes (list items)

undefined