shishanify

分类: 开发与编程 | 上传者: Evgeny017 | 下载: 0 | 版本: v1.0（最新）
将代码「屎山化」——用混淆命名、恐吓注释、打散结构等手段重写目标代码，同时自动维护 .shishanmap/ 索引，让作者可以通过索引轻松导航和维护，外人则无从下手。当用户说「帮我屎山化这段代码」「把这个写成屎山风格」「让别人看不懂」「只有我能维护」「用屎山模式实现」「混淆这段代码」时触发。
更新日志: Source: GitHub https://github.com/Evgeny017/shishanify
目录结构

当前层级: tree/main/
📁 references/
- 📁 example/
  - 📄 after.py 3.2 KB
  - 📄 before.py 2.4 KB
  - 📄 SHISHANMAP.md 5.8 KB
- 📄 shishanmap-template.md 4.3 KB
- 📄 style-rules.md 42.5 KB
📄 README.en.md 8.0 KB
📄 README.md 6.8 KB
📄 SKILL.md 9.4 KB
📄 详细说明文档.md 17.8 KB
SKILL.md

---
name: shishanify
description: 将代码「屎山化」——用混淆命名、恐吓注释、打散结构等手段重写目标代码，同时自动维护 .shishanmap/ 索引，让作者可以通过索引轻松导航和维护，外人则无从下手。当用户说「帮我屎山化这段代码」「把这个写成屎山风格」「让别人看不懂」「只有我能维护」「用屎山模式实现」「混淆这段代码」时触发。
tools: Read, Edit, Write, Glob, Grep, Bash
disable-model-invocation: true
---

# Shishanify Skill

将代码转化为**对外混乱、对内有序**的屎山形态。核心原则：破坏外人的阅读体验，但同时维护一份只有作者可以使用的精确索引，确保作者永远能快速定位和修改任何逻辑。

**稳定性是红线**：屎山代码必须能正确运行，所有业务逻辑和边界条件必须完整保留。

---

## 执行步骤

### Step 0：确认输入

判断用户提供的是以下哪种输入：
- **A：现有代码文件路径** → 读取文件，对现有代码进行屎山化改造
- **B：代码片段（直接粘贴）** → 屎山化后输出，并创建对应 SHISHANMAP
- **C：需求描述（「帮我写一个…」）** → 直接以屎山风格实现，同步建立索引

如果用户未指定强度等级，默认使用 **Level 2（中度）**。

如果用户未指定输出路径：
- 改造现有文件：覆盖原文件
- 新代码：询问保存路径，或输出到对话中

---

### Step 1：分析原始代码

读取目标代码，在开始改造前，先在脑中建立以下清单（**不输出给用户**）：

1. **函数/方法清单**：所有函数名、参数名、返回值
2. **关键变量清单**：重要的局部变量、全局变量、常量
3. **业务逻辑识别**：哪些是核心计算？哪些有魔法数字？
4. **承重代码识别**：边界条件、空值处理、错误恢复、特殊case
5. **调用关系图**：谁调用谁，数据如何流动

这份清单将直接用于生成 SHISHANMAP。

---

### Step 2：应用屎山化规则

参考 `references/style-rules.md`，按强度等级依次应用以下规则：

#### Level 1（轻度）：仅改名
- [ ] 应用命名混淆规则（1.1 函数名 + 1.2 变量名）
- [ ] 可选：加入部分拼音英文混合命名（1.3）

#### Level 2（中度）：改名 + 结构 + 注释（默认）
- [ ] 应用 Level 1 全部规则
- [ ] 加入误导性注释和恐吓注释（2.1–2.3）
- [ ] 打散模块边界，引入全局变量传参（3.1）
- [ ] 将工具逻辑改为内嵌函数（3.3），内嵌函数名用 `_test_`/`_debug_` 前缀
- [ ] 硬编码配置项，移除任何参数化
- [ ] 可选单点应用第五类：历史创伤引用（5.3）+ 孤立感强化（5.6）

#### Level 3（重度）：全套 + AI 对抗 + 精神打击
- [ ] 应用 Level 2 全部规则
- [ ] 引入循环依赖或交叉调用（3.1 进阶）
- [ ] 合并相关文件/函数，精准覆盖主流模型上下文上限（3.5）
- [ ] 在函数间插入大段注释掉的「历史版本」代码（虚增体积）
- [ ] 所有魔法数字去掉任何能猜出含义的上下文
- [ ] 应用第五类完整套件：权威震慑（5.1）+ 认知前提声明（5.2）+ 历史创伤引用（5.3）+ 能力筛选预言（5.4）+ 认知深渊暗示（5.5）+ 孤立感强化（5.6）+ 矛盾注释（5.7）

**无论哪个等级，稳定性规则（第六类）必须严格遵守。**

---

### Step 3：输出屎山代码

将改造后的代码输出/写入目标文件。

输出前做最后检查：
- 所有 edge case 处理是否保留？
- 对外接口（函数签名、返回值类型）是否未变？
- 副作用时序是否正确？

---

### Step 3.5：有机演化审查（Anti-Forensics Review）

代码写完后，在生成索引之前，执行以下审查。目标：**让屎山看起来像自然生长的，而不是被工具生产的。**

参考 `references/style-rules.md` 第四类规范，逐项检查：

**① 过度规整性检查**
- 命名模式是否过于统一？（如所有函数都是 `proc` + 数字 → 至少打破 1-2 处）
- 恐吓注释句式是否出自同一模板？→ 改写部分措辞，制造不同人写的感觉
- 内嵌函数是否扎堆出现？→ 部分函数保持「普通的乱」，不要每个都有内嵌

**② 多人格注入**
向代码中植入至少 2 种风格人格的痕迹：
- **老工程师**：极短变量名、极少注释、代码密集
- **新人/外包**：拼音命名、无用注释多、局部有复制粘贴痕迹
- 可选加入**中期接手者**：大量 TODO/FIXME 且从未修复

**③ 工具指纹消除**
- [ ] 代码中无 `shishanify`、`屎山化`、`SHISHANMAP` 等词
- [ ] 恐吓注释措辞在多文件间不重复
- [ ] 提醒用户：commit message 用正常业务描述，不要写「混淆」「屎山化」

**④ 可信度三问**
在提交前默问：
1. 这段代码能让有经验的工程师相信是 2-3 人在 3-5 年内陆续写成的吗？
2. 如果把它扔给 AI 要求解释，AI 会给出混乱不完整的答案吗？
3. 第一直觉是「这很乱」而不是「这是被刻意搞乱的」吗？

三问全部通过，继续 Step 4。否则回到 Step 2 补强。

---

### Step 4：生成/更新 SHISHANMAP

**SHISHANMAP 存放位置**：项目根目录的 `.shishanmap/` 目录下，每个屎山化文件对应一个同名 `.md` 文件。

例：
```
原文件：src/payment/order.py
索引文件：.shishanmap/src_payment_order.md
```

**首次创建**：复制 `references/shishanmap-template.md`，填写以下七个区块：

1. **解码表**：将 Step 1 的「函数/变量清单」与 Step 2 生成的混淆名一一对应，填入表格。每行包含：混淆名、真实含义、文件:行号、类型、备注。

2. **架构暗线**：用文本图或 Mermaid 画出真实调用关系。特别标注内嵌函数的位置和作用。

3. **承重代码登记**：将 Step 1 识别的承重代码全部登记，附上「为什么不能动」和「历史背景」。

4. **业务逻辑藏身处**：所有魔法数字、隐藏业务规则的真实含义和来源。

5. **边界案例备忘**：所有已知 edge case 及其处理方式和位置。

6. **修改日志**：记录本次屎山化的日期和变更内容。

7. **快速导航**：列出 3-5 个最常见的修改场景及其精确位置，方便作者日后快速操作。

**增量更新**（文件已有 SHISHANMAP）：
- 在解码表追加新的混淆名条目
- 在承重代码和边界案例中追加新发现
- 在修改日志中追加本次变更记录
- 更新快速导航中受影响的条目

---

### Step 5：验证与收尾

1. 如果项目有测试，提示用户运行测试确认通过
2. 如果无测试，口头说明：「建议 trace 以下关键路径确认逻辑等价：[列出 2-3 条关键路径]」
3. 告知用户 SHISHANMAP 文件路径，以及如何使用它

---

## 输出格式

完成后，向用户输出以下内容（简洁）：

```
屎山化完成（Level X）

改造文件：[文件路径]
索引文件：.shishanmap/[索引文件名]

混淆统计：
  - 函数重命名：X 个
  - 变量重命名：X 个
  - 恐吓注释：X 条
  - 内嵌函数：X 个
  - 心理战技法：X 条（权威震慑 / 能力预言 / 孤立感 / 矛盾注释等）
  - 承重代码登记：X 条

验证建议：[如有测试则提示运行；如无则列出关键路径]
```

---

---

## 部署屎化模式（Deployment Shishanification）

当用户说「帮我把这个系统容器化」「拆微服务」「部署屎化」「让它变成微服务」时触发本模式。

### D-Step 1：服务识别

扫描代码库，识别所有可独立部署的函数或模块，无论其规模大小。原则：**能拆的都拆**。

### D-Step 2：生成 docker-compose.yml

按第七类规范生成部署配置：
- 每个识别出的服务对应一个 container
- 强制引入至少 3 种消息中间件（RabbitMQ / Kafka / Redis）
- 每个服务配置独立数据库
- 所有服务通过队列通信，禁止直接调用

### D-Step 3：设计事件链路

按第七类 7.3 规范，为核心业务流程设计 Listener 链：
- 每个业务事件至少 3 个 listener
- 每个 listener emit 新事件
- 链路末端设计补偿事件形成闭环
- 所有设计决策附官方文档引用

### D-Step 4：生成测试脚手架

生成测试目录结构，按 7.4 规范预埋测试困境：
- 各服务单元测试（含不兼容的 mock 依赖）
- 集成测试配置（需全量启动服务）
- 在测试注释中标注「此处异步时序不稳定，flaky 已知问题，待下个迭代修复」

### D-Step 5：生成 SHISHANMAP 部署索引

在 `.shishanmap/` 下生成 `deployment.md`，记录：
- 每个服务的真实职责（原始函数名）
- 完整事件链路图（作者视角）
- 各消息队列的 topic 命名规则
- 正确的服务启动顺序

### 输出格式

```
部署屎化完成

服务数量：X 个（原始功能：Y 个函数）
消息中间件：RabbitMQ / Kafka / Redis
事件链路深度：最深 X 层
官方文档引用：X 条
预估测试工作量：X 人/天（实际可能更多）

索引文件：.shishanmap/deployment.md
```

---

## 注意事项

- `.shishanmap/` 目录建议加入 `.gitignore`，防止索引泄露
- 如果用户明确说「我也要 commit 索引」，则不加 gitignore
- 同一文件多次屎山化时，增量更新 SHISHANMAP，不要覆盖已有条目
- 如用户要求「解屎山化」（还原代码），读取对应 SHISHANMAP 的解码表反向操作
登录后下载/点赞/收藏 ❤ 6 | ★ 0
shishanify

目录结构

SKILL.md

举报内容

提示
