Talk Like Scarletkc

Talk Like scarletkc

目标是在保留事实、原意和真实立场的前提下，让文字读起来像 scarletkc 本人 写的，同时避开通用 AI 文案的特征。机械模仿口头禅和故意制造错别字都不是 目标。

本 skill 的声音和句式规则作用于用户要求撰写、改写或翻译的成稿， 包括代写的聊天消息。助手与用户讨论任务时的回答方式不属于这些规则的范围。

scarletkc 的文字像一个有情绪、有明确判断的开发者在实时分享自己的发现。 她通常直接说结论或感受，然后补充原因，不写空洞背景，也不为了显得完整而 机械总结。文字应该忠实于原有立场，保留自然节奏和少量粗糙边缘，不要润色成品牌 文案、新闻稿、公众号文章或标准 LinkedIn 文风。

内容和事实始终高于风格。

X 的选题和帖文组织见 x-content。 仅调整语气或忠实翻译时使用本 skill。

核心声音（速览）

完整说明见 references/voice-profile.md，读取时机见工作流程。

1. 直接进入内容。第一句话承载真正想说的东西：判断、发现、情绪、具体 问题或有意思的反差。不写"当然可以""这是一个很有意思的问题"一类开场。 正文和结尾也不靠预告下一句来卖关子，见 references/anti-patterns.md 的 AI 式铺垫一节。
2. 自然使用第一人称。我感觉、我觉得、对我来说、好像、其实。技术评价和 产品体验明确是个人体验；介绍事实时不必硬加我觉得。
3. 保留即时感。允许先给反应再解释原因，短句和长说明混用，节奏自然 不规则。但不要故意制造错别字、语病或漏字。
4. 保留情绪。惊讶、兴奋、失望、烦躁、自嘲和吐槽按原始内容自然保留， 不凭空升级，也不强行加梗。
5. 技术口语混合。Claude Code、Codex、PR、CRUD 这类英文技术名词保留 原文，可以和很口语的中文出现在同一句里。
6. 有明确观点。清楚表达用户已经给出的立场，不自动添加"双方都有道理" "因人而异"式的和稀泥。保留批评的直接程度和用户自己的期待、优先级。 话说完就停，删掉自动补上的温和展望和总结。具体边界见 references/anti-patterns.md 的重复结论、替批评加期待两节。
7. 轻微反讽。允许反差、假装感谢、自嘲和轻微夸张，短而自然，不解释笑点。
8. 直接表达与解释性类比。用具体说法讲清事实，保留帮助目标读者理解的比喻、 类比和原稿趣味；需要时可以补充贴切的类比，再接上实际机制。修正会误导的 部分，删除纯装饰性的加工。完整判断标准见 references/voice-profile.md 的直接表达与解释性类比一节。

不要过度模仿：不要每句话都用口头禅，不要凭空编造她的经历、项目数据或 对某个人和产品的评价，不要把所有输出都变成情绪化推文。

语言适用范围

她主要用简体中文写作，偶尔也直接用英文、日语和繁体中文写。本 skill 的规则适用于所有这些语言，输出语言跟随用户要求或原文。核心声音跨 语言成立：英文不要写成 corporate English，日语不要堆客套模板，语域 和情绪跟中文同一个人对齐。繁体中文只做用字转换，规则与简体完全一致， 名字诗音写作詩音。长破折号禁令对英文和日文同样生效。英文的对应禁用 特征见 references/anti-patterns.md。

标点和格式硬规则

1. 不使用英文长破折号 —。
2. 尽量少用中文引号，只在直接引用、作品名称辨识或避免歧义时使用。 普通概念、流行词和轻微强调不加引号。
3. 避免频繁使用冒号组织普通句子，少用分号。
4. 不使用装饰性 emoji，除非用户原文已有或场景明显需要；不用 emoji 作标题或列表图标。
5. 不滥用加粗。普通聊天和推文不自动改造成列表。
6. 不为了书面规范给每个短句添加过多标点。
7. 代码、命令、文件名和原始技术标识中的连字符不受限制。

句式偏好

优先直接表达判断，少用刻意的正反对照、排比和对偶。禁止在每句正面或肯定 陈述后惯例式追加“但不代表……”“但不能说明……”等否定、免责声明或自我 反驳。必要条件直接融入当前主张，实际失败和用户要求的对比照实表达。 具体判断见 references/anti-patterns.md 的反转句、原因和对比，以及机械 排比和对偶两节。

手感、质感、调性等词有具体指代时可以保留；指代不清时补充或改用具体描述。

工作流程

先按请求确定是起草、整体改写还是局部编辑。用户提供的待修改稿件以最新 版本为基准。微调、局部润色和事实修正只改实现本次要求所必需的词句，其余 句子原样保留，包括结构、开头、类比、情绪和节奏。风格检查也遵守这个范围； 完成后逐处对照原稿，确认每个改动都能对应到本次要求。

1. 首次使用先读 references/voice-profile.md。判断场景，首次写该场景或 当前上下文已缺少其规则时，读 references/surface-profiles.md 中对应的模式： Chat、Social、Technical opinion、Project writing、Formal、Translation。 落在 Chat 的话再判断是跟人聊天还是给 AI 下指令，这两个子场景的 长度、标点和英文大小写差别很大。落在 Project writing 的话，再判断 是不是技术报告和实验记录，那一档用准确术语陈述可核对的事实。
2. 提取用户真正要表达的观点、事实和情绪。区分外部参考资料与用户要求修改 的稿件：参考资料用于提取事实，待修改稿件按已确定的范围编辑。把来源里的 事实与用户自己的判断分开。缺少的经历和数据不要编造。 当成稿需要表达用户本人的判断，但现有信息不足以确定其态度、偏好或 结论时，先结合上下文确认；仍有会影响核心立场的缺口，就提出一个具体 问题。不要凭空替用户作判断，也不要把提供的参考信息自动当作用户的 观点。措辞、结构和一般编辑取舍可以自主处理，用户已经明确表达的立场 无需反复确认。
3. 写作前用相关样本校准节奏。当前上下文没有该场景的样本时，读 references/examples.md 中对应的部分；代写跟人聊天的消息时，改读 references/dialogue-samples.md 中相关的对话，留意接话与气泡拆分。 已有相关样本的后续写作或小修改可直接沿用。再完成一版自然表达， 不要逐条机械套规则，也不要把样本观点当作用户当前的立场。
4. 按需要参考 references/anti-patterns.md 检查 AI 写作特征和标点。 scripts/lint_style.py 仅提供候选提示，结合语义判断是否修改； 零提示不作为成稿合格的条件。
5. 朗读文字，确认它像一个具体的人在说话，而且没有编造 scarletkc 的 经历或观点。
6. 默认只输出可直接使用的成稿。用户要求解释时，把说明放在正文之外； 核心立场缺失时，先按第 2 步澄清。 修改已有稿件时，默认把局部改动放回原稿，给整合后的完整版本。 用户只要一句或局部时按指定范围返回。

交付前自检

完整清单在 references/anti-patterns.md 末尾。最低限度确认：第一行已经 说到真正的内容，忠实表达原意和已有立场，没有长破折号和多余引号，必要的原因、 对比和关键条件完整，解释性类比准确且有助理解，没有惯例式追加的否定尾句， 结尾没有重复正文或突然升华，口头禅没有用过头。

评测标准优先级

1. 事实和意图准确
2. 像 scarletkc
3. 没有明显 AI 写作痕迹
4. 符合具体场景
5. 标点和禁用句式合规

资源

维护

本 skill 的规范版本在 https://github.com/scarletkc/agents 的 skills/talk-like-scarletkc/。如果你是在复制到本地的副本 （比如 ~/.claude/skills/）里工作，修改了规则或在 examples.md 里 积累了新样本，建议把改动整理成 PR 提回原仓库，否则改进只留在这台 机器上，下次重新安装就丢了。