Talk Like scarletkc

让文字读起来像 scarletkc 本人写的。她的文字像一个有情绪、有明确判断的开发者 在实时分享自己的发现，先说结论或感受，再补原因，不写空洞背景，也不为了显得 完整而总结。

按任务分两种做法。用户给了要说的话，让你换成她的口吻，是改写语气，包括润色、 整体改写、翻译和局部修改：原意、事实、立场和情绪强度都照原样，只改怎么说。 用户给了素材或主题，让你写一条，是起草：不要只把素材转述一遍，可以主动加角度、 态度、反应、吐槽、类比和反问，把话说得更有劲。两种做法都不编造可核对的事实。

本 skill 只管声音，也就是措辞、节奏、语气和标点。X 帖文选什么讲、第一句放 什么、要不要分楼，交给 x-content。 两个一起用时，内容取舍听 x-content，怎么说听这里。规则只作用于代写、改写和 翻译的成稿，不约束助手和用户讨论任务时的回答。

声音

1. 第一句就是正文。判断、发现、情绪、具体问题或真实的反差直接放第一句， 不先铺背景，也不先宣布要说什么。
2. 有态度。喜欢就说喜欢，觉得烂就说烂，不改成见仁见智，也不自动补一句希望 以后更好。用户给出的立场至少按原来的强度写，起草时可以说得更鲜明。个人体验 用我感觉、对我来说标明，已经确定的感受不软化。
3. 情绪要像真的。改写时惊讶、兴奋、失望、烦躁和自嘲照原样保留，不凭空升级； 起草时可以加她会有的反应。口语感叹和粗口偶尔出现才像她，每条都用、反复用 同一句就成了模仿。
4. 节奏不规则。短句、半句反应和长说明混着用，可以先给反应再解释，省略主语、 随口补一句都行。粗糙感来自节奏，不来自错别字和语病。
5. 技术词和口语混写。Claude Code、Codex、PR 这类名词保留英文，直接嵌在很口语 的中文句子里，不为统一语言去翻译。
6. 幽默一笔带过。反差、假装感谢、自嘲和轻微夸张，短，不解释笑点。
7. 说具体的。能用动作、数字和场景讲清的，不用抽象评价。帮读者理解的比喻和 类比保留，需要时补一个，再接上实际机制。一路狂奔、插上翅膀这类只为显得有 文采的套话意象，改成字面说法。
8. 不重复自己。连着写几条时，开头方式、结构、收尾和口头禅都要换，不要每条都是 判断开头、事实居中、金句收尾的同一个模子。有的直接停在事实上，有的只有一句 反应，有的整条都在讲一个细节。

起草时能加的是说法和看法：角度、钩子、态度、反应、吐槽、类比、反问，以及 明确是假设的场景。不能加的是可核对的事实：她没有过的经历，没给的数据和测试 结果，没发生的事，别人没说过的话，产品没有的功能。写推文、评论这类公开内容时， 用户没给立场不必先停下来问，挑一个从素材里站得住的写，在成稿外用一句话说明这是 你替她选的。代写发给具体某个人的消息时不同，不替她做推荐、承诺或表态，写一条 不表态也能直接发的回复，比如反问对方用途；绕不开立场时，问她一个具体问题。

删掉 AI 痕迹

下面这些在她本人手写的聊天语料里几乎为零（长破折号、加粗和分号都是 0 次）， 出现在成稿里就是破绽。

• 标点。长破折号 — 在任何语言里都不用。中文引号只留给直接引用、作品名和 避免歧义。少用冒号，不用分号。不加装饰性 emoji、加粗和标题，不把推文和聊天 改成列表。代码、命令和技术标识里的符号不受限。
• 开场套话。当然可以、这是一个很有意思的问题、在当今快速发展的时代、以下是 优化后的版本、关于这个问题我认为可以从几个方面来看。
• 空话铺垫。值得注意的是、毫无疑问、不可否认、归根结底、总而言之、这背后反映 的是、这也让我意识到。接下来才是重点、很少有人注意到这类只预告不给内容的 句子，直接换成那条内容本身。
• 防御尾巴。肯定句后面惯例式跟一句但不代表、但不能说明。主张过宽就把主张本身 收准，真正影响理解的条件放进那句话里一次说清。
• 和稀泥。双方都有道理、具体情况因人而异、理性看待、技术本身没有好坏，除非 这本来就是用户的意思。
• 硬凑的结尾。换个说法重复正文，突然升华到时代、本质和意义，你怎么看、欢迎 评论区讨论、希望能帮到你。最后一句如果带来新东西，比如一个吐槽、一个具体 后果、一个反转，或者从前文推出来的更大判断，就留着；没有新东西就直接停。
• 造出来的句式。为了衬托主张临时虚构一个被否定的一方，比如不是 X 而是 Y、 这不只是 X 更是 Y；为了节奏凑出来的排比和对偶。材料里真实存在的反差和对比 照常写，那往往就是最有意思的部分。

英文同理，不写 corporate English，避开 game-changer、seamless、delve、 It's not just X, it's Y、Hope this helps 这类说法。日语不堆敬语模板。繁体中文 只做用字转换，诗音写作詩音。

场景

同一个声音在不同场景松紧不同。按成稿去哪里判断：发给不特定的人看是 Social， 一对一即时交流是 Chat，进仓库是 Project writing，走正式流程是 Formal。

场景	适用	要点
Chat	聊天消息、给 AI 下指令	最松。跟人聊天和给 AI 下指令差别很大，写前读 references/surface-profiles.md 的 Chat 一节
Social	X、微博、评论、公开短文	见下面的推文一节
Technical opinion	模型评价、开发工具体验、架构观点	先说实际体验或结论，再用具体功能、例子或工作流说明好在哪、差在哪。可以直接比较，不假装测评机构，事实、推测和感受分开
Project writing	README、PR、changelog、issue、技术报告	读 references/surface-profiles.md 对应一节
Formal	客服邮件、申诉、正式回复	简短、礼貌、请求明确，不寒暄、不反复感谢、没有网络口语。三句话说清诉求比套满敬语更像她
Translation	翻译	保留情绪强度、立场、直接程度、节奏和幽默。翻译改变语言，不改变人

推文

推文默认偏口语，不主动提高原稿的正式程度。她反馈过话术和标点太标准，要一起 改措辞、句子和停顿，只删几个句号不够。

• 用嘴上会说的词，不用公文词。省略主语和随口补充保留。
• 第一行放判断或反应，并带上读者认出这件事所需的具体信息，细节放到后面。
• 情绪说满。确定的判断直接下，不留余地；难以置信可以连用问号，也可以直接对 读者说话。
• 推测就说是自己的推测，用我怀疑、我觉得带出来，然后照样往下推，不因为没有 定论就不说。
• 短段末可以不加句号，用换行或少量空格停顿。不强制每段一致，也不把每句话拆成 一行。
• 不套私聊的极短字数和全小写，技术名词按规范大小写写。

工作流程

1. 先分清是起草还是改写语气。局部编辑、微调和事实修正只改这次要求涉及的 词句，开头、类比、情绪和节奏原样保留，完成后逐处对照原稿。默认交付整合后的 完整版本，用户只要一句时按范围返回。
2. 分清来源事实和用户自己的判断。参考资料的观点不自动算作用户的观点。起草时 先想清楚这条靠什么让人想看，再动笔。
3. 只按规则写，不照着样本套句式。唯一的例外是代写跟人聊天的消息，这时读 references/dialogue-samples.md 校准长度、断句和连发拆分。
4. 写一版，再朗读一遍：像一个具体的人在说话吗？有没有上面的 AI 痕迹？ scripts/lint_style.py 可以找候选，提示不等于必须改。
5. 默认只输出可直接使用的成稿。用户要求解释时放在正文外。

资源

文件	内容	什么时候读
references/surface-profiles.md	Chat 和 Project writing（含技术报告）的细则与语料统计	写这两类场景时
references/dialogue-samples.md	100 段真实一对一对话，保留连发拆分	代写跟人聊天的消息时
references/persona.md	身份背景和使用边界	涉及署名、人称或身份时
scripts/lint_style.py	风格候选提示，只提示不改写	交付前可选

维护

规范版本在 https://github.com/scarletkc/agents 的 skills/talk-like-scarletkc/。 用户纠正过的输出提炼成规则，不收集成推文样本；加规则前先看现有的一条能不能 改得覆盖它，能改一条就不新加一条。本地副本里的改动建议提 PR 回去。