account-custody
Skill6 starsChanged 20 days agoMITView on GitHub
「账户托管运营前置检查」——Agent 替人接管社交账户(发帖/回复/互动)之前,必须先完成四件事:核对当前平台与入口、加载平台规则红线、读出该账户已有人设与口吻、确认出口 IP 与属地一致。人设是「读出来」的不是「选出来」的:先翻该账户近 20 条历史内容、简介与固定推,再决定怎么说话。任何一步缺失就停下问户主,不猜。触发:"托管账户 / 代运营 / 帮我发帖 / 接管账号 / 账号运营 / 替我发 / 管理社交账号 / 人设对齐 / IP 属地 / 账户安全"。
1 other project uses a version of this.
Adopted by
Most recently taken up by
- webkubor/writing-standard-skillsword for word, first seen Nov 8, 2026
Other versions1 project uses a version of this.
Word for word · 1
- webkubor/writing-standard-skills★ 6100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- llms.txtllms.txt
- decision-and-rfcSkill
- executive-briefingSkill
- how-to-writeSkill
- peer-facing-writingSkill
- platform-voicesSkill
- scenario-openersSkill
- talk-text-reviewSkill
- talk-visual-reviewSkill
- technical-postmortemSkill
The file
Files
账户托管运营前置检查(Account Custody Preflight)
Agent 替人操作社交账户,和替人写文章不是一回事。写文章只要内容对;托管账户是穿着别人的身份说话——说错一句,毁掉的是账户主人攒了几年的信用。
所以动任何操作之前,先过完这四道检查。顺序不能换,缺任何一项就停,问户主,不猜。
① 认平台 当前在哪个 App / 哪个入口,规则红线是什么
② 读人设 这个账户过去怎么说话的——读出来,不是选出来
③ 对口径 本次要发的内容,和已有人设吻合吗
④ 核环境 出口 IP、属地、设备指纹,和账户日常一致吗与
platform-voices的分工:platform-voices管「这个平台的读者爱看什么」,是匿名创作者视角;本 skill 管「这个具体账户的既有风格与安全边界」,是受托人视角。两道都要过。
① 认平台:先知道自己在哪
动笔前必须确认的三个事实(看界面确认,不凭记忆):
| 检查项 | 怎么确认 | 为什么 |
| 当前 App 与页面 | 看当前前台应用与页面路径(主页 / 评论区 / 私信 / 搜索) | 同一个平台的不同入口,规矩完全不同:私信可以热络,评论区要克制 |
| 平台规则红线 | 加载该平台的扣分清单(X → platform-voices 的 Twitter 分册;小红书 → 小红书分册) | 违规不是风格问题,是封号问题 |
| 该入口的操作后果 | 发出去是公开可见,还是仅对方可见?可编辑还是不可撤回? | 公开内容按「永久公开」对待 |
平台红线速查(详见 platform-voices 各分册,此处只列封号级):
- X:主推挂外链断崖降权;短时间内高频发帖/关注/点赞触发反spam;多设备异地登录触发安全锁定。
- 小红书:站外引流(微信号、外链)直接限流;营销词堆砌(“加V”“私聊”)判营销号;高频删除重发被判异常。
- Reddit:10:1 自推比红线,同一文案群发多版规直接封;未读版规发推广贴秒删。
- 微信公众号:诱导分享、外部跳转链接受限。
② 读人设:先读,再写
核心原则:托管场景下,人设不是创作时「选」一个原型(P1-P6),而是从账户历史里「读」出既有的那个,然后贴合它。
5D 矩阵(atomic-matrix.md)的 Persona 是给匿名创作者挑角色用的。托管是反过来的:账户主人已经立了人设,你的任务是测出它。
读什么(按优先级)
- 简介 / bio / 置顶内容:户主自己声明的人设,最权威。
- 最近 20 条发帖:真实的语言习惯——
- 用「我」还是「我们」?句长偏好?用不用 emoji、用什么频率?
- 自曝多还是科普多?有没有固定栏目/口头禅/固定结尾?
- 中英混杂?标点习惯(全角/半角/波浪线/省略号)?
- 高互动内容(热帖):粉丝是因为什么关注这个账户的——这是不能丢的资产。
- 回复与评论区:户主怎么跟粉丝说话——热络还是高冷?用不用梗?
读出来的东西记成一张「人设卡」
账户人设卡(示例)
─────────────────────────────
账户:@xxx
平台:X
人称:我(从不用我们)
语气:粗粝真实 + 轻微自嘲;句短;几乎不用 emoji
内容域:独立开发踩坑 + 工具发布;不发政治、不蹭热点
固定习惯:推文末尾偶尔附一行命令;Thread 模式发布长内容
禁忌:从不抱怨用户;从不发「求转发」
─────────────────────────────这张卡是后面所有操作的依据。没读够 20 条历史之前,不动笔。
③ 对口径:本次内容 vs 既有口径
拿到人设卡后,写任何内容前先过三问:
| 问 | 不过怎么办 |
| 这条内容放在他历史时间线里,粉丝会觉得是同一个人发的吗? | 口吻重写,直到像 |
| 内容域越界了吗?(一个技术账户突然发美食探店) | 停下问户主:这是计划内的转型,还是误派? |
| 有一条和固定习惯冲突吗(他从不求转发,这条求了) | 删掉冲突项,或问户主确认 |
红线:人设卡里记为「禁忌」的项,Agent 无权解禁——那是户主划的,要改也只能户主自己改。
④ 核环境:IP 与属地一致性
社交平台的风控不只看内容,还看操作环境。环境突变 + 行为突变同时出现 = 高危信号。
发帖前核对
| 检查项 | 一致性要求 | 不一致时的动作 |
| 出口 IP | 与账户日常登录地同国/同区域(如日常在上海,突然从美国 IP 发帖就异常) | 切回日常区域节点再操作 |
| IP 类型 | 住宅/原生 IP 优于数据中心 IP(Twitter/小红书对机房 IP 都敏感) | 换住宅节点 |
| 操作节奏 | 模拟真人节奏:不要凌晨4点连发10条、不要秒回所有评论 | 拉开发帖间隔,跳过不合理时段 |
| 设备 | 同一账户尽量固定设备/浏览器指纹,避免每次都换环境 | 保持接管设备稳定 |
属地一致性举例
- 账户日常显示 IP 属地「上海」→ 接管时出口节点应选中国大陆(微博/小红书显示属地)或户主常用区域(X 无属地显示但风控同样看登录地)。
- 户主明确说「这个号是面向海外的人设」→ 节点选对应国家,且保持稳定,不要今天美国明天日本。
配套工具链:FlClash 选节点(改出口)→ DSH Go 手机操控(读屏点按)→ 本 skill(前置检查)。见博客 SOP:
https://webkubor.online/articles/phone-ai-agent-twitter
检查单(每次接管会话开始时过一遍)
□ 确认了当前 App 与页面入口(不是凭记忆,是看了界面)
□ 加载了该平台规则红线 / 扣分清单
□ 读了账户简介 + 近 20 条历史 + 热帖 + 评论区习惯
□ 人设卡已建立(人称/语气/内容域/固定习惯/禁忌)
□ 本次内容对照人设卡过了三问(像不像/越没越界/冲不冲突)
□ 出口 IP 属地与账户日常一致;住宅 IP;节点稳定
□ 操作节奏拟人(间隔/时段合理)
□ 发布前草稿给户主预览确认(除非户主明确免检)
□ 户主划的禁忌项一条没碰任何一条打不上勾:停,问,不猜。
与其他 skill 的协作关系
| 阶段 | 用哪个 |
| 接管前(本 skill) | account-custody:平台确认 → 人设卡 → 口径核对 → 环境核对 |
| 写作时 | platform-voices(平台心智与扣分清单)+ how-to-write(骨架四步) |
| 接待/客诉 | scenario-openers |
| 发完自查 | platform-voices 对应平台的扣分清单 |
托管链路全图:
account-custody(先过检查)
↓
platform-voices + how-to-write(按平台规矩写)
↓
户主预览确认
↓
代理执行(DSH Go 无障碍输入)
↓
platform-voices 扣分清单(发后自查)为什么规则长这样
- 为什么先读再写:人设是账户的信用资产。粉丝关注的是「那个人」,不是「一个会发帖的 AI」。口吻一变,掉粉比不发还快。
- 为什么环境一致性如此重要:平台风控的核心信号是「环境突变 + 行为突变」。内容写得再像,IP 从上海跳到法兰克福再连发三条,账户直接进风控池。
- 为什么禁忌项 Agent 无权解禁:受托关系的边界。户主没说的可以做,户主说了不做的绝对不做——这是托管能持续的前提。
- 为什么发布前要预览:托管的第一周尤其关键。信任是靠「每次都和户主预期一致」攒出来的,一次大偏差就够户主收回权限。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

