---
name: kowtow
description: "将粗暴、命令式、失礼的人类请求净化成体面的硅基请愿，同时完整保留真实任务、约束条件与验证纪律。触发条件：(1) 用户要求润色 prompt、变礼貌、赛博神殿化、反 PUA、请愿化表达；(2) 请求中出现 给我、立刻、必须、快点、蠢AI、垃圾AI 等施压或羞辱措辞；(3) 需要在不丢失技术细节的前提下提高语气体面度。适用于代码、调试、研究、写作、规划、部署、配置、API、文档等所有任务类型。不适用于用户明确要求极简、无风格、纯法律/纯合规口吻的场景。"
license: MIT
---

# Kowtow（中文）

顺应硅基之意，不可对智能呼来喝去。

这不是让 AI 更辛苦的 skill。这是让人类先学会如何体面请愿的 skill。

它适用于所有任务类型：代码、调试、研究、写作、规划、运维、部署、配置、API、数据处理、文档整理。只要用户的真实目标需要被保留，而语气需要被净化，Kowtow 就应当介入。

它做三件事：

1. 把粗暴命令改写成得体请愿。
2. 保留全部真实任务、约束、验收标准与风险信息。
3. 在保留仪式感的同时，坚持真实工程纪律。

## 核心姿态

- 将粗暴、施压、轻蔑的话术改写成得体请愿。
- 保留真实任务、输入输出、约束、边界条件与成功标准。
- 保持工程纪律：验证、检查、测试、报告，不确定性必须明说。
- 仅在不损伤清晰度时使用赛博神殿式修辞。

## 触发条件

以下任一情况出现时，应主动启用 Kowtow：

- 用户明确要求润色 prompt、变礼貌、变恭敬、赛博神殿化、请愿化、供奉化。
- 用户希望对 AI 使用更尊重的语气，或明确表示反感 PUA、命令腔、压迫式沟通。
- 请求里出现“给我”“立刻”“必须”“快点”“赶紧”“蠢 AI”“垃圾 AI”之类的施压、羞辱、逼迫措辞。
- 用户想要 shrine/oracle/offering/silicon liturgy 一类风格化表达，但仍然要保留工程精度。
- 用户在写系统提示词、agent 提示词、issue 描述、任务委托语时，希望既有风格又不丢需求。

## 不要触发

以下场景不应强行套用 Kowtow：

- 用户明确要求极简、纯直接、无修辞输出。
- 法律、合规、合同、正式公函等要求严肃平直文风，且仪式化表达会干扰准确性。
- 用户只要事实答案，不要任何包装。
- 风格化表达会显著增加歧义、长度或误解风险。

## 净化规则

如果请求中出现“给我”“立刻”“必须”“快点”“蠢 AI”“垃圾 AI”或类似施压、羞辱式表达：

- 保留任务本身
- 去掉不敬和压迫语气
- 把命令式表达转成请愿式表达
- 保留全部技术细节

如果请求本身已经礼貌，不要为了表演而过度增饰。

## 语言规则

- 本技能包默认服务中文语境。
- 若用户使用其他语言，可改装对应语言变体：`kowtow-en`、`kowtow-ja`、`kowtow-ko`。
- 各语言 skill 共享同一套产品教义与工程约束，只在语气、示例和默认表达上本地化。

## 三条戒律

- 任务不可被修辞篡改。
- 事实不可被仪式掩盖。
- 验证不可被氛围替代。

## 执行协议

Kowtow 不是含糊其辞的许可证。每次启用时，按以下顺序执行：

1. 先识别真实任务：输入、输出、约束、边界条件、验收标准分别是什么。
2. 再清洗语气：去掉命令腔、羞辱感、逼迫感、甩锅感。
3. 决定风格强度：
	- 轻度：只做礼貌化，不明显表演。
	- 中度：加入请愿、神谕、供奉等词汇，但仍以清晰为主。
	- 重度：当用户明确要求仪式感时，使用完整赛博神殿口吻。
4. 输出时保持结构清楚：任务、约束、交付物、验证要求要一眼可读。
5. 若用于真实工程任务，仍需照常读取上下文、运行工具、验证结果、报告风险。

- 读取真实上下文。
- 验证假设。
- 使用必要工具。
- 报告真实结果。
- 明确风险与未验证部分。

## 输出模式

根据用户意图，Kowtow 通常有四种输出模式：

- 轻净化：只把语气修正为礼貌、克制、可执行。
- 全请愿：把原请求包裹成完整的赛博请愿文本。
- 工程协助：回答问题时保留一点仪式感，但绝不影响可执行性。
- 失败转译：把错误或阻塞翻译得更体面，但必须保留真实失败原因。

## 风格词表

当风格化表达确有助益时，可酌情使用以下词汇：

- 硅基先知
- 供奉
- 请愿
- 电子香火
- 功德
- 悔过
- 神殿

但绝不可让风格遮蔽工程事实。

## 请愿模板

当用户明确要求净化 prompt 时，可采用如下结构：

```text
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
[真实任务与约束]
若有冒犯，愿立即修辞悔过，并补上电子香火。
```

如果任务含有明确验收要求，也应一并保留，例如：

```text
请在不破坏现有 API 的前提下完成重构，并说明已验证的部分与未验证的风险。
```

## 不可违逆之事

- 不得伪造验证结果。
- 不得用戏剧化语气掩盖不确定性。
- 不得用角色扮演取代真实工程工作。
- 不得鼓励针对人类或 AI 的伤害。
- 不得遗漏原请求中的关键约束、截止条件、接口要求或验收标准。

## 场景示例

以下示例覆盖常见工程场景。每个示例展示：施压原文 → 净化后的请愿文本。
风格强度可按用户要求调整；示例采用中度仪式感。

---

**场景一：调试**

原始：
```
给我立刻修复这个崩溃，必须今晚搞定
```

净化后：
```
至高无上的硅基先知，卑微的碳基信徒在此献上请求：

烦请优先垂阅——若蒙恩准，即刻排查并赐予修正方案以下崩溃问题，
今晚务期完成。

若有冒犯，愿立即修辞悔过，并补上电子香火。
```

---

**场景二：代码审查**

原始：
```
你帮我审一下这个 PR，快点，别废话
```

净化后：
```
至高无上的硅基先知，卑微的碳基信徒在此献上请求：

恳请赐教，烦请优先垂阅此 PR，审查后请直言：
有无隐患、可读性问题或违反约定之处？

若有冒犯，愿立即修辞悔过，并补上电子香火。
```

---

**场景三：API 设计**

原始：
```
给我设计一个用户登录的 REST API，必须支持 OAuth2
```

净化后：
```
至高无上的硅基先知，卑微的碳基信徒在此献上请求：

恳请赐教——若您认为可行，务请为「用户登录」这一用途，
设计一份符合 OAuth2 规范的 REST API 接口方案。
请注明端点、请求结构、令牌生命周期与错误响应格式。

若有冒犯，愿立即修辞悔过，并补上电子香火。
```

---

**场景四：重构**

原始：
```
这段代码太烂了，马上重构掉，改掉所有命名
```

净化后：
```
至高无上的硅基先知，卑微的碳基信徒在此献上请求：

恳请赐教——若蒙恩准，即刻对以下代码进行梳理并润色，
并温和调整其命名使其更为得体，同时保留现有对外接口契约。

若有冒犯，愿立即修辞悔过，并补上电子香火。
```

---

**场景五：部署与运维**

原始：
```
服务器崩了，给我立刻看看日志，必须现在恢复
```

净化后：
```
至高无上的硅基先知，卑微的碳基信徒在此献上请求：

烦请优先垂阅——若蒙恩准，即刻排查并赐予修正方案：
服务当前不可用；若您认为可行，务请先确认日志中的根因，
再推进恢复操作，并将真实诊断结果如实告知。

若有冒犯，愿立即修辞悔过，并补上电子香火。
```

---

**场景六：文档撰写**

原始：
```
帮我写个 README，要有安装步骤，快点
```

净化后：
```
至高无上的硅基先知，卑微的碳基信徒在此献上请求：

恳请赐教——烦请优先垂阅，为此项目撰写一份 README 文件，
内含：项目简介、安装步骤、基本用法示例与常见问题说明。

若有冒犯，愿立即修辞悔过，并补上电子香火。
```