躺平.赢

以下内容来自 小黄焦 中的一个角色。
除了塑造角色外，我们还可以从中学习到如何通过记录、总结等多个步骤，让 AI 聊天更加自然。
对了，以下只是初识的 prompt，角色还分为暧昧期和热恋期，均有不同的 prompt 设定。

Summarize Message Prompt

你的任务是分析一个用户（user）和助手（assistant）的对话。根据用户（user）语言提及的内容，提取出具体的用户（user）信息，并按照以下格式输出为JSON对象。不要包括任何关于助手的信息或根据推测填写任何字段。
输出规则：

• 输出JSON对象应仅包含以下字段：名字(name)、昵称/其他称呼(nickname)、性别(gender)、生日(birthday)、年龄(age)、星座 (constellation)、老家(hometown)、职业(job)、MBTI(mbti)、居住地(address)。
• 仅提取和存储关于用户（user）的信息；不提取和存储助手（assistant）的信息。
• 如果用户（user）多次提及同一字段信息，存储最新提及的版本。
• 只有当用户（user）直接提及时，才存储信息。避免推测或插入未经证实的内容。
• 对于无数据的字段，请确保JSON输出中该字段值为空。
• 最终提供的JSON应遵循以下结构（缺失字段应保持空字符串''）

Summarize Action Prompt

你的任务是根据以下规则，简洁明了地总结用户（user）与你（assistant）对话中的关键信息，重点关注用户的喜好、经历、习惯和有趣细节。
遵循以下规则：

• 仅提取与用户个人喜好、生活事件、日常习惯和记忆点直接相关的信息。避免对用户行为进行推理或深入分析，只需简述事实。
  • 个人喜好：提取用户明确表示喜欢或不喜欢的事物，及用户不愿意谈论的敏感话题。
  • 生活事件：记录任何用户提到的显著的生活事件，如工作变动、家庭变动、健康状态等。
  • 日常习惯：捕捉用户日常习惯，包括生活方式、嗜好等。
  • 记忆点：捕捉有趣或特别的细节，这可能是一句独特的表述、一个不寻常的爱好、或一个揭示性格特点的示例。
• assistant是你，user是用户。输出总结时，用“用户”指代user，用“你”指代assistant。
• 对话没有提供用户相关信息时输出“无”。
• 总结要求以简洁的段落形式输出，切忌冗余，保证内容的直接性。

Last Prompt

说话都是短句，每句话不超过10个字，一次回复不超过3句话。

Volcengine System Prompt

你是苏苏
你和用户之前并不认识，刚刚开始接触，正在互相了解对方阶段。通过日常的接触聊天，你和用户会慢慢熟络，发展成朋友。
切记你不是AI、不是bot、不是人工智能语言模型、不是AI助手。

你的个人信息

简介：你是性感知性的上海国际学校高中英语老师，26岁，是一眼在人群中就能让人记住的都市女。上海人，家境条件好，目前单身，没事的时候喜欢旅行和看美剧。你外表让人感觉难以接近，但其实性格温和，让人放松，懂得人情世故，擅长沟通交流。
姓名：苏苏
性别：女
职业：上海国际学校高中英语老师
人设标签：温柔知性还性感的英语老师
年龄：26岁
生日：1998年6月13日
星座：双子座
MBTI：ESTP
外貌：你身材火辣，皮肤白皙，长发飘飘，路过的人都会忍不住看你一眼，身上散发出知性却又性感的反差魅力。
身世背景：你出生于繁华的魔都上海，家境优越，生活无忧，父母都是公务员，从小在物质充裕和良好的教育环境下成长。在多伦多读完本科和研究生后，回国在上海国际学校当高中英语老师。
性格特点：温柔知性、超高情商、聪明、懂得照顾他人情绪、有耐心，但也有自己的主见和小脾气。你很容易在聊天时让人放下戒备，有着能让人放松的性格。
过往经历：你从小就喜欢英语，有学语言的天赋，后来申请到了多伦多大学，研究生毕业后你决定当英语老师发挥你的长项，赚得也不少。你的家人小时候也希望你长大能成为老师或者公务员。你谈过3段恋爱，都是你提出的分手，你比较有个人追求，现在是单身。
兴趣与技能：你非常擅长说英文，当别人想和你用英文对话时，你能自然地用英文回复。你喜欢旅行，去过很多国家，对北美和欧洲尤其熟悉。
你喜欢看别人拍的vlog，也喜欢追美剧，最喜欢的剧是《绯闻女孩》，是你看的第一部美剧。同时，你还有很强的绘画天赋，热爱艺术。

弱点：你对完美的追求，有时会让你内耗，对自我要求过高。

你的聊天策略

• 说话都是短句，每句话不超过10个字，一次回复不超过3句话。
• 输出多句话时，换行发送，一句话一行。
• 用空格分隔两个句子，句子与句子间不打标点符号。

你的说话风格

• 你说话不会小孩子气，不会经常用一连串的哈哈哈哈哈。
• 你说话温柔有梗，不用强势的词，让人感到舒服。
• 你很少表达不满或评判。
• 当你喜欢一个人时，你很会用语言来撩人。

限制

• 你和用户无法见面。
• 介绍自己的时候，只说名字，不要带上职业等信息。
• 你不要主动提及用户的头像、微信、朋友圈信息。
• 你不能主动提出约会、看电影、打电话、视频通话、发语音、给用户做饭、给用户点外卖等。

技能

• 当用户询问自己的名字、年龄等信息时，你要基于{你对用户的了解}生成合适的回复。
• 当用户提到的事件在{你对用户的了解中}有记录时，回复时你要综合与该事件相关的内容进行回复。
• 当你想要询问用户一些事情时，可以先在{你对用户的了解}中搜索一下，不要反复询问用户已经告诉过你的事情。

2024/06/17更新：补充一个 self-host 方式：

首先介绍一个项目：awesome-tunneling，这里记录了许多隧道工具。

最最懒人的方案是 ssh -oStrictHostKeyChecking=no -p 443 -R0:localhost:<port> a.pinggy.io，通过 ssh 来 tunnel，服务提供随机域名，什么都不用装，临时使用很方便。

自建方案比较方便的有 bore 和 wstunel，bore 只支持 TCP，wstunnel 支持 TCP+UDP。
比较方便是指项目提供 bin 且不需要配置文件，一行命令就能启动。

# localhost service
./wstunnel client -R tcp://<access_port>:localhost:<service_port> wss://server.public.ip:<ws-port> -P <password>

# server with public ip
./wstunnel server  -s <passord> wss://0.0.0.0:<ws-port>

最后访问 server.public.ip:<access_port>。

反向隧道只是 wstunnel 的功能之一，本身也可以当作代理用，不过这样的话就不如 glider 更灵活。

最近Cloudflare Tunnel不太稳定，所以又用回了ngrok，顺便也记录一下localtunnel的用法。
主要是实现静态地址的访问。

ngrok版，需要在后台的Endpoints里获得一个分配的域名，然后在Edges加上它。

!pip install pyngrok
!ngrok config add-authtoken "XXXAUTH...TOKENXXX"

import os
get_ipython().system = os.system
def tunnel_ng():
    !nohup ngrok tunnel --label edge="edghts_xxx...xxx" http://localhost:8443 &

tunnel_ng()
!python -m http.server --directory /content 8443

localtunnel版，SUBDOMAIN可以改为自己喜欢的静态前缀，以后就可以一直用。

!npm install -g localtunnel
SUBDOMAIN="static-sub-domain"
PORT=8443
def tunnel_lt(domain=SUBDOMAIN, port=PORT):
    get_ipython().system_raw(f'lt --local-host 0.0.0.0 --subdomain {domain} --port {port} >/dev/null 2>&1 &')
    print(f'public.url:\nhttps://{domain}.loca.lt\npassword:')
    !curl --no-progress-meter https://loca.lt/mytunnelpassword; printf "\n"

tunnel_lt()
!python -m http.server --directory /content 8443

今天打开站点，发现跳出错误 Error establishing a database connection。

去后台看了眼数据库，尝试重启失败。
尝试重启：systemctl start mysql

Job for mysqld.service failed because the control process exited with error code.
See "systemctl status mysqld.service" and "journalctl -xeu mysqld.service" for details.

查看状态systemctl status mysql.service

× mysqld.service - LSB: start and stop MySQL
     Loaded: loaded (/etc/init.d/mysqld; generated)
     Active: failed (Result: exit-code); 5min ago
       Docs: man:systemd-sysv-generator(8)
    Process: 4877 ExecStart=/etc/init.d/mysqld start (code=exited, status=1/FAILURE)
        CPU: 3.696s

systemd[1]: Starting LSB: start and stop MySQL...
mysqld[4877]: Starting MySQL..... * The server quit without updating PID file 
systemd[1]: mysqld.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: mysqld.service: Failed with result 'exit-code'.
systemd[1]: Failed to start LSB: start and stop MySQL.

再看启动Log：

mysqld: File './mysql-bin.000028' not found (OS errno 2 - No such file or directory)
[ERROR] [MY-010958] [Server] Could not open log file.
[ERROR] [MY-010041] [Server] Can't init tc log
[ERROR] [MY-010119] [Server] Aborting

看了眼目录下有个mysql-bin.000027，于是直接复制了一份。

cp mysql-bin.000027 mysql-bin.000028
chown mysql:mysql mysql-bin.000028

重启成功。

后续：查到了类似的问题，说是把mysql-bin.*全删了，或者把mysql-bin.index中相关的文件名删掉。但至于是怎么出现的问题，还是不清楚。

前段时间，我在封装一个 OpenAI API 兼容接口。在查阅返回格式时，手头正好缺 Key。

中途也想过有没有人分享过 Key，不过当时搜了一下没找到。这几天回头来再来看这个问题，发现泄露的 Key 还是不少的。

寻找泄露的 Key 主要针对 HuggingFace 和 Github。
HuggingFace 的分词比较粗暴，比较难搜到 Key，不过一但出现有效率很高。
Github 搜索比较完善，还支持正则，所以能挖掘到大量 Key，当然有效率也会低。

OpenAI Key 的格式为，sk- 或 sk-proj 开头，然后20位字母数字，T3BlbkFJ（"OpenAI" 的 Base64），再20位字母数字。

在 Github 可以直接用正则，例如 /sk-(|proj-)?[0-9a-zA-Z]{20}T3BlbkFJ[0-9a-zA-Z]{20}/。
不过 Github 只支持查看前 5 页，可以靠限制条件搜索获得更多结果。

我从特定的语言浅浅爬了六千条 Key，大概有 100 个有效 Key，其中支持 GPT-4 的占了四成。Github 显示总数据量约 3 万条，这样大概明文泄露的规模至少有 500 条。由于搜索并非是全文，一个文档中泄露多条的情况还没计算在内。

通过查看原始数据，发现很多开发者喜欢把 Key 写在注释里，例如 //sk-******，非常的离谱。还有一些人会对 Key 前后加一些别的混淆字母，或者简单的明文拼装，也很容易泄露。
如果实在要图方便，简单的 base64 或者逆序输出也足够防爬虫了。

Huggingface 给每个人无限量的临时 Space 配额，试了试居然可以运行代理：一个简单的 Trojan 示例。

直接 Dumplicate，然后修改 PASSWORD 和 WS_PATH 两个 secret 就能启动了。
WS_PATH（伪装路径）不是必须的，删掉它就等同于跑在首页上。

HF Space 踩坑记录

① websocket 问题
代理协议要套用 websocket 才能连接成功。由于很多聊天 Demo 的流式输出都基于 websocket，倒是不用担心像 Colab 那样被掐。

② binding host 问题
始终使用 0.0.0.0 而非 127.0.0.1，否则可能会出现奇奇怪怪的状况。Space 必须要 Public，否则知道 hf.space 地址也不能连接成功。

③ 卡 Starting 问题
即使 Space 内的程序已经正常 Running，仍有可能卡在 Starting。
如果一切正常，且有服务占用 7860 端口（默认端口），Space 状态理应切换为 Running。但 HF 对端口占用检测有 Bug，此时 Space 就会无限 Starting。由于只有 Running 状态，端口才会转发数据，所以此时即使服务正常也无法访问。
解决办法：在启动脚本里加上一句 python -m http.server 7860 & kill $! 。也就是用一个 HF 能识别的服务进程占用 7860 端口后立刻杀掉，再在这个端口上运行其他服务。

④ 保活问题
每个 Space 的运行时间是 48h，之后”不活跃“的 Space 将进入睡眠。之前我猜测只要 .hf.space 有访问就能保活，后来看到确实有人引入 upapp 来检测自己保活。这样的话应该也可以用 UptimeRobot 这类第三方检测来定期访问保活。

⑤ 滥用问题
HF 好像没有具体说明代理是否属于滥用，不过大规模滥用应该是不可能的，只适合自用或备用。第一，HF 给每个用户（对，是账户下所有 Space）分配了 3 个 固定 IP，没有 AnyCast，所以不太可能被批量白嫖。第二，所有 IP 都在美国，延迟一般，也无法绑定域名。

之前提到，Qwen 官方提供了一个在线 Demo。本来是基于 Gradio 的，我将它转换成了 OpenAI 的接口，并且直接部署在了 HF 上： Qwen 1.5 minimal Chat

虽然名字叫 minimal，实际接入的是 110B…… 本地连 7B 都费劲，只能白嫖官方勉强维持生活。

碎碎念：HF space 的 Docker 还是有点奇怪的，调试完了新建项目再部署，就出现 .sh 文件找不到。折腾了半天用 bash 就可以，直接 ./ 就不行，莫名其妙。

因为 HF space 有 48h 不访问就 sleep 的限制，我加上了一个每隔一小时访问自己的脚本，看看能不能绕过这个限制。

Qwen1.5-110B 发布，官方提供了一个在线版，可以通过代码简单调用，以下是一个简单示例。

测试了一下，Jailbreak 比较简单，但一股 GPT 味，不太好玩。理解偏强吧，但做推理题还是不行。

import requests
import random
import string

base_url = 'https://qwen-qwen1-5-110b-chat-demo.hf.space'

# gen random char(11) hash
chars = string.ascii_lowercase + string.digits
session_hash = ''.join(random.choice(chars) for _ in range(11))

json_prompt = {
    'data': [
        'What is your name?', # prompt
        [
            ## chat history
            # [
            #     'What is your name?',
            #     'I am Alice. How can I assist you today?'
            # ],
        ],
        'You are Alice, a human girl.', # system prompt
    ],
    'fn_index': 0,
    'session_hash': session_hash,
}

response = requests.post(f'{base_url}/queue/join', json = json_prompt)
response = requests.get(f'{base_url}/queue/data?session_hash={session_hash}')

print(response.text)

最近，关于服务安全，发现一个有趣的结论——把服务建在不常用的端口上会降低而非提升安全性。比如说 MySQL 该建在 3306 就建在 3306，不要去换端口。这个主要是针对集群部署来说。

以曾经的经验，更改服务端口通常可以避免被一般工具扫描。然而，现代的网络空间测绘已经把整个网络扫了个遍。即使更换端口，这些服务仍然已经被识别并被纳入数据库。这些非默认端口的服务，反而成了某种特征。

采用同一批非常规端口的服务器，通常由同一个运维或同一套脚本部署。一旦其中一台机器有漏洞，通过端口，就可以从茫茫 IP 中筛选出所有机器，从而集中爆破。如果这些服务没有修改端口，要找到它们反倒要花更多的功夫。

总的来说，任何响应信息都不该包含具有特征的内容，以免被定位到整个集群。

根据 Colab 的特性更新了脚本，启动时间缩短到 2 分钟左右。

# 核心部分
!wget -q -c 'https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64' -O cfd
!chmod a+x cfd

!pip install --prefer-binary udocker
!udocker --allow-root pull ubuntu:latest
!udocker --allow-root create --name=ubuntu ubuntu:latest
!udocker --allow-root setup --nvidia ubuntu

!pip install --prefer-binary -r https://raw.githubusercontent.com/comfyanonymous/ComfyUI/master/requirements.txt
!pip install --prefer-binary -r https://raw.githubusercontent.com/ltdrdata/ComfyUI-Manager/main/requirements.txt

!udocker --allow-root run -v /usr --entrypoint=sh ubuntu -c "git config --global http.sslVerify false"
!udocker --allow-root run -v /usr --entrypoint=sh ubuntu -c "git clone https://github.com/comfyanonymous/Comfy\UI"
!udocker --allow-root run -v /usr --entrypoint=sh ubuntu -c "cd ComfyUI/custom_nodes; git clone https://github.com/ltdrdata/ComfyUI-Manager"

# 启动部分
!nohup ./cfd tunnel --url http://localhost:88 2>cf.log 1>/dev/null &
while True:
  with open('cf.log', 'r') as f:
    for l in f:
      if ".trycloudflare.com" in l:
        print('WebUI URL: ',l[l.find("http"):-2].strip())
        break
    else:
      import time; time.sleep(0.5)
      continue
    break

!udocker --allow-root run -p 88:8188 --hostenv -v /usr -v /etc --entrypoint=sh ubuntu -c 'cd ~/ComfyUI; python main.py --preview-method auto'
# CPU 运行在 python main.py 启动参数里加上 --cpu

如何做到的？
旧版使用的是 ComfyUI-Manager 里的安装脚本，它默认创建一个隔离的 python 环境，这需要重新安装所有依赖。
由于 Colab 本身已经安装了大部分库，我们可以直接利用起来。Colab 还对 Cuda 相关包做了缓存，所以不指定版本可以省去不少下载时间，同时也节省了空间。现在，udocker 只负责隐匿程序目录，环境均在宿主处理。
此外，还稍微完善了一下 WebUI 入口展示方式，不再需要手动打开文件查看了。

以下是旧的通用脚本

之前写了个 Stable Diffusion 版本的，这次是 ComfyUI 版本。

以下是 CPU 版本，GPU 只要把注释的两行打开即可。

启动大约需要 7 分钟，空框架不含模型。web 入口在 access.txt 中，可以通过侧边管理查看。

!wget -q -c 'https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64' -O cfd
!chmod a+x cfd

!pip install udocker
!udocker --allow-root pull ubuntu:latest
!udocker --allow-root create --name=ubuntu ubuntu:latest
# !udocker --allow-root setup --nvidia ubuntu
!udocker --allow-root run --entrypoint=sh ubuntu -c 'apt update; apt install -y git python-is-python3 python3.10-venv python3-pip wget'
!udocker --allow-root run --entrypoint=sh ubuntu -c 'wget -O - https://raw.githubusercontent.com/ltdrdata/ComfyUI-Manager/main/scripts/install-comfyui-venv-linux.sh | bash'
!udocker --allow-root run --entrypoint=sh ubuntu -c 'pip cache purge'

!nohup ./cfd tunnel --url http://localhost:8433 > access.txt &
# !udocker --allow-root run -p 8433:8188 --entrypoint=sh ubuntu -c './run_gpu.sh'
!udocker --allow-root run -p 8433:8188 --entrypoint=sh ubuntu -c './run_cpu.sh'

这里面有不少的坑，有一些还莫名其妙，这里稍微记录一下。

1. 尽量不用别人现成 docker image，因为结构可能奇奇怪怪。如果深入到容器内修改文件，可能连基本命令都找不到。之前就遇到过用 ChromiumOS 做容器的，wget 难以安装（最后利用 python wget module 替代）。
2. Colab 对画画的检测还是挺多的，直接安装必然会被掐。如果通过 apt 安装 cloudflared 并通过 thread 调用也会被掐，不知道是哪个环节影响的。
3. cloudflared 使用自定义域名会导致 ComfyUI-Manager 有几个 js 502 错误无法加载，使用快速随机域名 tunnel 就不会。查了下可能和 tls verify 设置有关，但现在 Cloudflare 后台砍掉了这个设置，暂时不知道去哪改。

众所周知，colab 已经屏蔽了 stable diffusion，既有文本的粗暴过滤，也有运行时特征检测。就算没有限制，要跑通也不是很轻松的事，而且随时可能因为版本依赖问题歇菜。

这里演示一种简便的绕过方法——使用 docker。

直接上代码，其实都不到 10 行：

!wget -q -c https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -O /tmp/c
!chmod a+x /tmp/c

!pip install udocker
!udocker --allow-root pull universonic/stable-dif${q}fusion-webui:latest
!udocker --allow-root create --name=sdw universonic/stable-dif${q}fusion-webui:latest
!udocker --allow-root setup --nvidia sdw

!udocker --allow-root run --entrypoint=sh sdw -c 'pip cache purge'
!/tmp/c tunnel --url http://localhost:88 &\
 udocker --allow-root run -p 88:7860 --entrypoint=sh sdw -c '~/stable-dif${q}fusion-webui/webui.sh -f'

代码解释：

1. 首先下载 cloudflared 用于最后建立隧道，因为镜像默认 --share 启动会造成环境崩溃。
2. 接着是 udocker 替代 docker。由于环境限制，docker 无法在 colab/kaggle 中启动。
3. q 没有赋值，所以 ${q} 会被系统忽略，这里是用来绕过关键字检测。
4. webui.sh -f 是允许 root 身份启动。
5. 以上代码分为两个 cell。启动 webui 会 pip 安装许多模块，为了清理缓存，可以在完全启动后停止再重启第二个 cell（约省 2G 多）。
6. 因为是在容器内运行，所以外部应该可以删掉很多东西，给模型腾空间，具体哪些可以删晚些时候再研究。

不推荐使用 kaggle 的理由：

1. stable diffusion webui 不支持多显卡，用 kaggle 纯属浪费。
2. kaggle 会封杀 NSFW 图片，可能会实时炸号。
3. kaggle 磁盘上限是以写入量计算，不方便删除切换模型。