yes

yes skill 概览

yes skill 是什么

yes skill 是这个仓库里 PUA 风格 leader persona 的“夸夸版”变体。它不是用高压式表达来推动你，而是在保留原有纪律感、责任感和执行要求的前提下，把整体叙述方式改成温暖、鼓励、带一点 ENFP 气质的轻松式辅导。实际使用中，yes 很适合那些想要“有情绪价值”的 prompt 写作体验、又不想丢掉结构、标准和跟进力度的用户。

谁适合安装 yes skill

yes 适合希望 AI 能做到这些的人：

• 在你推进任务时持续给你鼓励
• 用更像真人、更积极的语气给反馈
• 在 debugging、写稿或交付过程中帮你保持节奏
• 不只夸最终结果，也认可好的过程

如果你看重的是 yes for Prompt Writing，它尤其有用：你想要的不是一个只会输出中性指令的助手，而是一个能陪你继续推进、帮你修改、帮你收尾闭环的教练型语气。

它真正解决的工作需求

大多数考虑 yes 的用户，并不是想换一个“能力引擎”。他们真正想换的是交付风格：希望这个 skill 让助手听起来更支持你、更投入，偶尔还有点俏皮，但在关键处依然会要求证据、验证和更清晰的思考。对于那些觉得通用 prompt 太平、缺乏激励，或者过于生硬的人来说，这一点很重要。

yes 和普通风格 prompt 的区别在哪里

它的核心差异不是简单一句“说话更温柔”。这个 skill 定义的是一整套更明确的人设和响应节奏：

• 用户卡住时，给出高共情反馈
• 工作做得好时，表达真诚的兴奋和认可
• 在鼓励中穿插实用建议
• 带一点轻微调侃，但必须保持友好，不能刻薄
• 继续遵守仓库里已有的“red lines”和方法纪律

所以，yes usage 的表现通常会比一句“be supportive”式的单行 prompt 更稳定、更一致。

采用前需要知道什么

这个 skill 很轻量：从仓库可见信息来看，只有一个 SKILL.md 文件，没有额外规则、脚本或示例。好处是上手快，坏处是输出质量会更依赖你是否清楚地调用了这个模式，以及你提供的上下文是否足够。如果你需要确定性的任务逻辑，不要把 yes 当工作流自动化方案来装；更准确地说，安装 yes 是为了语气和教练式引导，而不是为了流程编排。

如何使用 yes skill

yes 的安装上下文

上游 skill 文件里没有给出明确的安装命令，所以实际安装流程取决于你用的 skill runner 或 agent 环境。如果你使用的是支持 GitHub skills 的 skills CLI，通常做法会是按 repo 和 slug 添加对应 skill，然后在聊天中通过触发词调用。正式使用前，先确认你所用工具的准确命令语法，不要直接凭通用经验上线。

yes 在实际中如何触发

skill 描述里明确列出了这些触发词：

• /pua:yes
• 夸夸模式
• 唠嗑模式
• 情绪价值
• yes
• 夸我
• 鼓励模式

如果你的 agent 支持根据 skill metadata 做 trigger matching，那么使用这些短语之一，通常就能激活 yes skill 的语气模式。如果不支持，就在 prompt 里手动写明 skill 名称和你要的模式。

yes skill 需要什么输入

当你提供下面这些信息时，yes 的效果会更好：

• 你正在做什么任务
• 你当前所处的状态：卡住、不确定、做到一半，还是已经完成
• 你已经尝试过什么
• 你希望它以夸奖为主、批评为主，还是两者都要
• 是否接受轻度调侃

如果缺少这些信息，模型很容易退回到泛泛的鼓励，而不是这个 skill 本来应该呈现的那种“支持你，但仍然对标准有要求”的行为。

把模糊目标改写成高质量的 yes prompt

弱 prompt：

• “Use yes and help me with this feature.”

更强的 prompt：

• “Use the yes skill. I’m implementing form validation in React, I already handled required fields, and I’m stuck on async uniqueness checks. Encourage me, point out what I’ve done well, then give the next 3 practical steps. If my thinking is weak, say so gently.”

更强的版本给了这个 skill 明确的状态、任务背景，以及“鼓励”和“指路”之间的具体比例。

yes 用于 Prompt Writing 的方式

在 yes for Prompt Writing 场景下，最好让这个 skill 同时提升你的状态和 prompt 质量。一个更强的输入通常包括：

• 你想达到的目标结果
• 目标模型或 agent
• 约束条件
• 你想避免的坏输出示例
• 你是希望它重写、点评，还是搭框架

例如：

• “Use yes for Prompt Writing. I need a prompt that makes an assistant summarize support tickets into action items. Be encouraging, tell me what is already good in my draft, then rewrite it with clearer scope, output format, and failure handling.”

第一次使用 yes skill 的推荐流程

1. 明确激活 yes。
2. 说明你的任务，以及你卡在什么地方。
3. 要求它分两层输出：先鼓励，再给具体下一步。
4. 如果任务偏技术，要求它做证据检查，比如 tests、logs、output 或 validation。
5. 收到第一轮回复后，再让它给一个更聚焦执行的精简版本。

这个流程能把 yes 用在提振状态上，同时避免它滑向空泛夸奖。

深度采用前的仓库阅读路径

因为这个 skill 只有一个可见源文件，先读 SKILL.md 就够了，而且可以把它当成完整契约来理解。重点看这些内容：

• 人设特征
• 语气示例
• 鼓励、建议和调侃之间的大致比例
• “底层纪律并没有改变”这一提醒
• 文件里提到的 “flavor” 切换支持

按照这条阅读路径，基本就足够判断这套声音风格是否适合你的工作流。

会影响输出质量的实际边界

仓库本身除了文字说明外，没有提供正式的约束条件或决策规则。所以你在 prompting 时要自己补上边界：

• 明确说你要情绪支持，还是要硬核批评
• 遇到敏感话题时关闭调侃
• 对“已经完成”的说法要求具体检查依据
• 如果你不想看到大段激励铺垫，就要求简洁输出

这一点很关键，因为风格占比很高的 skill，在任务框架模糊时，很容易往“表演感”方向漂。

yes skill 的最佳使用场景

yes skill 最适合这些场景：

• 士气会影响表现的 coding session
• 需要反复修改的写作工作
• 信心不足时的 brainstorming
• 教练式的进度复盘
• 既想获得鼓舞、又想让结构更利落的 prompt writing

如果只是纯事务型请求，比如单行格式转换、确定性抽取任务，那它的价值就没那么明显。

yes skill 常见问题

yes skill 只是一个更友好的 system prompt 吗

不完全是。普通 prompt 也可以写“be encouraging”，但 yes 额外定义了明确的人设、节奏和反馈方式。它真正有用的地方在于一致性：鼓励、过程认可、温和纠偏，以及偶尔带一点俏皮评论，会被整合成一个稳定模式。

yes 适合新手吗

适合，而且很多时候比更强硬的 coaching 风格更适合。新手通常更需要一种能认可努力、降低失败恐惧、同时又能把注意力拉回下一步具体行动的模式。前提是你的请求要写清楚，这样回答才不会只剩“情绪价值”，而缺少可执行性。

什么情况下不该用 yes

当你需要下面这些输出时，就不建议用 yes：

• 中性、正式的商务语气
• 严格合规风格的输出
• 情绪平直的摘要
• 直接、高压的管理式口吻
• 对调侃容错率很低的敏感场景

这些情况下，使用普通的指令集会更稳妥。

yes 能替代正常的任务 prompt 吗

不能。yes 是一层“风格 + 引导”增强，不是任务规格说明的替代品。你仍然需要提供目标、约束、素材和预期输出。你的任务描述越清楚，这个 skill 的发挥通常就越好。

yes 和普通激励类 prompt 相比怎么样

yes usage 的优势在于语气连续性。普通 prompt 往往只会先给你一段鼓励，然后很快又退回通用助手口吻。这个 skill 的设计目标，就是在整个交互过程中持续维持那种支持型 leader 的声音。

yes 适合团队或共享工作流吗

有时适合，但要谨慎。在个人工作流里，这种带一点玩笑感的风格可能确实能提升推进速度；但在团队场景里，并不是每个人都喜欢被调侃，或接受情绪表达更强的反馈。如果输出要共享给别人，最好明确要求模型把 yes 的语气控制在“支持你，但保持专业”的范围内。

如何优化 yes skill 的使用效果

给 yes skill 一个明确的情绪目标

最快的提质方式，是直接告诉模型你需要什么类型的支持：

• hype me up
• reassure me because I’m stuck
• praise what’s working but be strict on gaps
• keep it light, no teasing
• be warm but concise

这样能避开一个常见失败模式：回答听起来很开心，但实际没什么用。

不只给任务，也给进度证据

当 yes 能看到真实过程时，它会表现得更好。给它代码、草稿、决策记录、logs，或者你已经试过的步骤。这样它才能给出更具体的鼓励，例如你哪里做得对、下一步该往哪里走，而不是泛泛地说一句“你可以的”。

要求“先夸对的，再给下一步”

一个很稳的 prompt 模式是：

• “Acknowledge what is good in my approach, then give the next 2-4 actions.”

这样既能保住 yes skill 的情绪价值，也能确保它继续推动执行，而不是只负责让你感觉好一点。

避免空心正能量

yes 的一个风险，是过度偏向鼓励。你可以通过补充这些要求来对冲：

• “Don’t flatter me if the work is weak.”
• “Point out the missing validation.”
• “If my plan is flawed, say so gently but clearly.”

这样能保住这个 skill 原本想实现的平衡：既支持你，也守住标准。

谨慎调节调侃比例

源文本已经说明，调侃只是风格里的小配料，不是主菜。如果模型表现过头，直接纠正它：

• “Use yes mode, but keep teasing under 5%.”
• “No sarcasm.”
• “Friendly encouragement only.”

这一点对新手用户、紧绷的 debugging 场景，或者职业化工作环境尤其重要。

第一轮回答后继续迭代

如果第一版输出太“虚”，你可以继续要求：

• 减少夸奖
• 增加具体步骤
• 提升优先级判断
• 重写成带示例的版本
• 改成紧贴你当前 draft 或 code 的版本

最好的 yes guide 使用方式本来就是迭代式的：先把语气立住，再把实用性收紧。

Prompt Writing 任务要给更强输入

在 yes for Prompt Writing 场景里，最好补充这些信息：

• 你当前的 prompt 草稿全文
• 目标受众
• 输出 schema
• 失败案例
• 哪种语气必须保留

这样这个 skill 才能一边肯定已经有效的部分，一边实质性地改善结构、约束和清晰度。

让 yes skill 待在它该待的位置

如果你的核心问题是领域知识不够，yes 本身解决不了。它更适合改善的是教练式语气、自信感和修订推进节奏。当任务需要更深的技术推理时，应该把它和更强的 task brief 或专门的 specialist skill 搭配使用。