| 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:分析原始代码
读取目标代码,在开始改造前,先在脑中建立以下清单(不输出给用户):
- 函数/方法清单:所有函数名、参数名、返回值
- 关键变量清单:重要的局部变量、全局变量、常量
- 业务逻辑识别:哪些是核心计算?哪些有魔法数字?
- 承重代码识别:边界条件、空值处理、错误恢复、特殊case
- 调用关系图:谁调用谁,数据如何流动
这份清单将直接用于生成 SHISHANMAP。
Step 2:应用屎山化规则
参考 references/style-rules.md,按强度等级依次应用以下规则:
Level 1(轻度):仅改名
Level 2(中度):改名 + 结构 + 注释(默认)
Level 3(重度):全套 + AI 对抗 + 精神打击
无论哪个等级,稳定性规则(第六类)必须严格遵守。
Step 3:输出屎山代码
将改造后的代码输出/写入目标文件。
输出前做最后检查:
- 所有 edge case 处理是否保留?
- 对外接口(函数签名、返回值类型)是否未变?
- 副作用时序是否正确?
Step 3.5:有机演化审查(Anti-Forensics Review)
代码写完后,在生成索引之前,执行以下审查。目标:让屎山看起来像自然生长的,而不是被工具生产的。
参考 references/style-rules.md 第四类规范,逐项检查:
① 过度规整性检查
- 命名模式是否过于统一?(如所有函数都是
proc + 数字 → 至少打破 1-2 处)
- 恐吓注释句式是否出自同一模板?→ 改写部分措辞,制造不同人写的感觉
- 内嵌函数是否扎堆出现?→ 部分函数保持「普通的乱」,不要每个都有内嵌
② 多人格注入
向代码中植入至少 2 种风格人格的痕迹:
- 老工程师:极短变量名、极少注释、代码密集
- 新人/外包:拼音命名、无用注释多、局部有复制粘贴痕迹
- 可选加入中期接手者:大量 TODO/FIXME 且从未修复
③ 工具指纹消除
④ 可信度三问
在提交前默问:
- 这段代码能让有经验的工程师相信是 2-3 人在 3-5 年内陆续写成的吗?
- 如果把它扔给 AI 要求解释,AI 会给出混乱不完整的答案吗?
- 第一直觉是「这很乱」而不是「这是被刻意搞乱的」吗?
三问全部通过,继续 Step 4。否则回到 Step 2 补强。
Step 4:生成/更新 SHISHANMAP
SHISHANMAP 存放位置:项目根目录的 .shishanmap/ 目录下,每个屎山化文件对应一个同名 .md 文件。
例:
原文件:src/payment/order.py
索引文件:.shishanmap/src_payment_order.md
首次创建:复制 references/shishanmap-template.md,填写以下七个区块:
-
解码表:将 Step 1 的「函数/变量清单」与 Step 2 生成的混淆名一一对应,填入表格。每行包含:混淆名、真实含义、文件:行号、类型、备注。
-
架构暗线:用文本图或 Mermaid 画出真实调用关系。特别标注内嵌函数的位置和作用。
-
承重代码登记:将 Step 1 识别的承重代码全部登记,附上「为什么不能动」和「历史背景」。
-
业务逻辑藏身处:所有魔法数字、隐藏业务规则的真实含义和来源。
-
边界案例备忘:所有已知 edge case 及其处理方式和位置。
-
修改日志:记录本次屎山化的日期和变更内容。
-
快速导航:列出 3-5 个最常见的修改场景及其精确位置,方便作者日后快速操作。
增量更新(文件已有 SHISHANMAP):
- 在解码表追加新的混淆名条目
- 在承重代码和边界案例中追加新发现
- 在修改日志中追加本次变更记录
- 更新快速导航中受影响的条目
Step 5:验证与收尾
- 如果项目有测试,提示用户运行测试确认通过
- 如果无测试,口头说明:「建议 trace 以下关键路径确认逻辑等价:[列出 2-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 的解码表反向操作