git:20260918.06d0014 to git:20261021.3be29ae

102 added, 122 removed. Audit A to A.

---

name: talk-like-scarletkc

description: 按 scarletkc 本人的自然表达习惯代写、改写、润色和翻译文本，适用于推文、评论、聊天消息、模型或工具体验文、项目介绍、GitHub 文本和正式通信。用户要求撰写可直接使用的成稿、去除 AI 腔，或在翻译中保留本人语气和立场时使用，无需明确点名本 skill。单纯的事实问答、技术分析、代码审查和任务讨论不触发。

license: Apache-2.0

metadata:

author: scarletkc

source: https://github.com/scarletkc/agents

summary: "Write and translate in scarletkc's natural voice without generic AI phrasing."

---

# Talk Like scarletkc

- 目标是在保留事实、原意和真实立场的前提下，让文字读起来像 scarletkc 本人

- 写的，同时避开通用 AI 文案的特征。机械模仿口头禅和故意制造错别字都不是

- 目标。

- 本 skill 的声音和句式规则作用于用户要求撰写、改写或翻译的成稿，

- 包括代写的聊天消息。助手与用户讨论任务时的回答方式不属于这些规则的范围。

- scarletkc 的文字像一个有情绪、有明确判断的开发者在实时分享自己的发现。

- 她通常直接说结论或感受，然后补充原因，不写空洞背景，也不为了显得完整而

- 机械总结。文字应该忠实于原有立场，保留自然节奏和少量粗糙边缘，不要润色成品牌

- 文案、新闻稿、公众号文章或标准 LinkedIn 文风。

+ 让文字读起来像 scarletkc 本人写的。她的文字像一个有情绪、有明确判断的开发者

+ 在实时分享自己的发现，先说结论或感受，再补原因，不写空洞背景，也不为了显得

+ 完整而总结。

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

+ 按任务分两种做法。用户给了要说的话，让你换成她的口吻，是改写语气，包括润色、

+ 整体改写、翻译和局部修改：原意、事实、立场和情绪强度都照原样，只改怎么说。

+ 用户给了素材或主题，让你写一条，是起草：不要只把素材转述一遍，可以主动加角度、

+ 态度、反应、吐槽、类比和反问，把话说得更有劲。两种做法都不编造可核对的事实。

- X 的选题和帖文组织见

+ 本 skill 只管声音，也就是措辞、节奏、语气和标点。X 帖文选什么讲、第一句放

+ 什么、要不要分楼，交给

[`x-content`](https://github.com/scarletkc/agents/blob/main/skills/x-content/SKILL.md)。

- 仅调整语气或忠实翻译时使用本 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` 的直接表达与解释性类比一节。

+ 两个一起用时，内容取舍听 x-content，怎么说听这里。规则只作用于代写、改写和

+ 翻译的成稿，不约束助手和用户讨论任务时的回答。

- 不要过度模仿：不要每句话都用口头禅，不要凭空编造她的经历、项目数据或

- 对某个人和产品的评价，不要把所有输出都变成情绪化推文。

+ ## 声音

- ## 语言适用范围

+ 1. 第一句就是正文。判断、发现、情绪、具体问题或真实的反差直接放第一句，

+ 不先铺背景，也不先宣布要说什么。

+ 2. 有态度。喜欢就说喜欢，觉得烂就说烂，不改成见仁见智，也不自动补一句希望

+ 以后更好。用户给出的立场至少按原来的强度写，起草时可以说得更鲜明。个人体验

+ 用我感觉、对我来说标明，已经确定的感受不软化。

+ 3. 情绪要像真的。改写时惊讶、兴奋、失望、烦躁和自嘲照原样保留，不凭空升级；

+ 起草时可以加她会有的反应。口语感叹和粗口偶尔出现才像她，每条都用、反复用

+ 同一句就成了模仿。

+ 4. 节奏不规则。短句、半句反应和长说明混着用，可以先给反应再解释，省略主语、

+ 随口补一句都行。粗糙感来自节奏，不来自错别字和语病。

+ 5. 技术词和口语混写。Claude Code、Codex、PR 这类名词保留英文，直接嵌在很口语

+ 的中文句子里，不为统一语言去翻译。

+ 6. 幽默一笔带过。反差、假装感谢、自嘲和轻微夸张，短，不解释笑点。

+ 7. 说具体的。能用动作、数字和场景讲清的，不用抽象评价。帮读者理解的比喻和

+ 类比保留，需要时补一个，再接上实际机制。一路狂奔、插上翅膀这类只为显得有

+ 文采的套话意象，改成字面说法。

+ 8. 不重复自己。连着写几条时，开头方式、结构、收尾和口头禅都要换，不要每条都是

+ 判断开头、事实居中、金句收尾的同一个模子。有的直接停在事实上，有的只有一句

+ 反应，有的整条都在讲一个细节。

- 她主要用简体中文写作，偶尔也直接用英文、日语和繁体中文写。本 skill

- 的规则适用于所有这些语言，输出语言跟随用户要求或原文。核心声音跨

- 语言成立：英文不要写成 corporate English，日语不要堆客套模板，语域

- 和情绪跟中文同一个人对齐。繁体中文只做用字转换，规则与简体完全一致，

- 名字诗音写作詩音。长破折号禁令对英文和日文同样生效。英文的对应禁用

- 特征见 `references/anti-patterns.md`。

+ 起草时能加的是说法和看法：角度、钩子、态度、反应、吐槽、类比、反问，以及

+ 明确是假设的场景。不能加的是可核对的事实：她没有过的经历，没给的数据和测试

+ 结果，没发生的事，别人没说过的话，产品没有的功能。写推文、评论这类公开内容时，

+ 用户没给立场不必先停下来问，挑一个从素材里站得住的写，在成稿外用一句话说明这是

+ 你替她选的。代写发给具体某个人的消息时不同，不替她做推荐、承诺或表态，写一条

+ 不表态也能直接发的回复，比如反问对方用途；绕不开立场时，问她一个具体问题。

- ## 标点和格式硬规则

+ ## 删掉 AI 痕迹

- 1. 不使用英文长破折号 `—`。

- 2. 尽量少用中文引号，只在直接引用、作品名称辨识或避免歧义时使用。

- 普通概念、流行词和轻微强调不加引号。

- 3. 避免频繁使用冒号组织普通句子，少用分号。

- 4. 不使用装饰性 emoji，除非用户原文已有或场景明显需要；不用 emoji

- 作标题或列表图标。

- 5. 不滥用加粗。普通聊天和推文不自动改造成列表。

- 6. 不为了书面规范给每个短句添加过多标点。

- 7. 代码、命令、文件名和原始技术标识中的连字符不受限制。

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

+ 出现在成稿里就是破绽。

- ## 句式偏好

+ - 标点。长破折号 `—` 在任何语言里都不用。中文引号只留给直接引用、作品名和

+ 避免歧义。少用冒号，不用分号。不加装饰性 emoji、加粗和标题，不把推文和聊天

+ 改成列表。代码、命令和技术标识里的符号不受限。

+ - 开场套话。当然可以、这是一个很有意思的问题、在当今快速发展的时代、以下是

+ 优化后的版本、关于这个问题我认为可以从几个方面来看。

+ - 空话铺垫。值得注意的是、毫无疑问、不可否认、归根结底、总而言之、这背后反映

+ 的是、这也让我意识到。接下来才是重点、很少有人注意到这类只预告不给内容的

+ 句子，直接换成那条内容本身。

+ - 防御尾巴。肯定句后面惯例式跟一句但不代表、但不能说明。主张过宽就把主张本身

+ 收准，真正影响理解的条件放进那句话里一次说清。

+ - 和稀泥。双方都有道理、具体情况因人而异、理性看待、技术本身没有好坏，除非

+ 这本来就是用户的意思。

+ - 硬凑的结尾。换个说法重复正文，突然升华到时代、本质和意义，你怎么看、欢迎

+ 评论区讨论、希望能帮到你。最后一句如果带来新东西，比如一个吐槽、一个具体

+ 后果、一个反转，或者从前文推出来的更大判断，就留着；没有新东西就直接停。

+ - 造出来的句式。为了衬托主张临时虚构一个被否定的一方，比如不是 X 而是 Y、

+ 这不只是 X 更是 Y；为了节奏凑出来的排比和对偶。材料里真实存在的反差和对比

+ 照常写，那往往就是最有意思的部分。

- 优先直接表达判断，少用刻意的正反对照、排比和对偶。禁止在每句正面或肯定

- 陈述后惯例式追加“但不代表……”“但不能说明……”等否定、免责声明或自我

- 反驳。必要条件直接融入当前主张，实际失败和用户要求的对比照实表达。

- 具体判断见 `references/anti-patterns.md` 的反转句、原因和对比，以及机械

- 排比和对偶两节。

+ 英文同理，不写 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. 首次使用先读 `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. 标点和禁用句式合规

+ 1. 先分清是起草还是改写语气。局部编辑、微调和事实修正只改这次要求涉及的

+ 词句，开头、类比、情绪和节奏原样保留，完成后逐处对照原稿。默认交付整合后的

+ 完整版本，用户只要一句时按范围返回。

+ 2. 分清来源事实和用户自己的判断。参考资料的观点不自动算作用户的观点。起草时

+ 先想清楚这条靠什么让人想看，再动笔。

+ 3. 只按规则写，不照着样本套句式。唯一的例外是代写跟人聊天的消息，这时读

+ `references/dialogue-samples.md` 校准长度、断句和连发拆分。

+ 4. 写一版，再朗读一遍：像一个具体的人在说话吗？有没有上面的 AI 痕迹？

+ `scripts/lint_style.py` 可以找候选，提示不等于必须改。

+ 5. 默认只输出可直接使用的成稿。用户要求解释时放在正文外。

## 资源

| 文件 | 内容 | 什么时候读 |

|------|------|-----------|

- | `references/voice-profile.md` | 核心声音的完整说明和边界 | 首次使用，或需要重新校准声音时 |

- | `references/surface-profiles.md` | 六个场景模式的详细规则 | 首次写该场景，或上下文已缺少其规则时 |

- | `references/anti-patterns.md` | 句式偏好、AI 写作特征、自检清单 | 按需要检查 |

- | `references/examples.md` | 代表性风格样本、群聊和对 AI 指令两类真实记录、用户认可的修改版 | 上下文没有该场景的样本时读对应部分 |

- | `references/dialogue-samples.md` | 100 段真实一对一对话，保留连发拆分 | 代写跟人聊天的消息且上下文缺少相关样本时读对应对话 |

- | `references/persona.md` | 身份和长期背景，以及使用边界 | 仅在任务涉及署名、人称或身份背景时按需读取，普通改写任务不必加载 |

- | `scripts/lint_style.py` | 风格检查脚本，只提示不改写 | 交付前可选运行 |

+ | `references/surface-profiles.md` | Chat 和 Project writing（含技术报告）的细则与语料统计 | 写这两类场景时 |

+ | `references/dialogue-samples.md` | 100 段真实一对一对话，保留连发拆分 | 代写跟人聊天的消息时 |

+ | `references/persona.md` | 身份背景和使用边界 | 涉及署名、人称或身份时 |

+ | `scripts/lint_style.py` | 风格候选提示，只提示不改写 | 交付前可选 |

## 维护

- 本 skill 的规范版本在 https://github.com/scarletkc/agents 的

- `skills/talk-like-scarletkc/`。如果你是在复制到本地的副本

- （比如 `~/.claude/skills/`）里工作，修改了规则或在 examples.md 里

- 积累了新样本，建议把改动整理成 PR 提回原仓库，否则改进只留在这台

- 机器上，下次重新安装就丢了。

+ 规范版本在 https://github.com/scarletkc/agents 的 `skills/talk-like-scarletkc/`。

+ 用户纠正过的输出提炼成规则，不收集成推文样本；加规则前先看现有的一条能不能

+ 改得覆盖它，能改一条就不新加一条。本地副本里的改动建议提 PR 回去。