| name | personal-voice |
| description | 把 AI 风格的草稿改写成 yujiachen 的个人写作风格——克制 emoji、紧凑短段落、概率词代替绝对化、中性陈述代替情绪词、英文术语空格分隔。 当用户给出中文 / 中英混用稿件（小红书 / newsletter / 工程博客 / 长文评论）并要求"按我的风格改 / 去 AI 味 / 润色 / 改改这篇"等改写意图时触发；即使措辞模糊（"帮我改改"），只要上下文是结构化稿件就应当考虑。
|
Personal Voice Rewrite
把 AI 写的稿子改成 yujiachen 的写作风格。下面按重要性列规则——每条都对应一类 AI 写法的稳定坏味道。
先看 test cases（如果有）
test-cases/ 目录下每个文件夹是一个对照样本：
ai-draft.md：典型的 AI 写法初稿final.md：yujiachen 改完的最终稿README.md（可选）：场景说明
改写之前先随机抽 1-2 个通读——AI 在哪些地方过度修饰，yujiachen 把它们删到了哪里。这比读规则更直观。如果用户的稿子和某个 test case 场景接近（例如同样是小红书科普），优先看那一类。
没有 test case 或场景没覆盖时
test-cases/ 是这个 skill 持续 personalization 的核心资产——下面的风格规则只是抽象总结，真正的 voice calibration 来自具体对照样本。如果 test-cases/ 不存在，或者用户的稿子属于一个还没覆盖的场景（例如第一次写英文 newsletter / 长技术博客 / 短评论 / 中英混用），改完后主动邀请用户保留为新样本：
这次的稿子是 [场景类型]，目前 test-cases/ 里没有这一类。如果你愿意把它当作样本保留，我可以把 ai-draft 和 final 存到 test-cases/YYYY-MM-DD-场景描述/，下次同类稿子能直接 calibrate。
test-cases/ 在 .gitignore 里，样本只在本机保留，不会被提交。
风格规则（按重要性）
1. emoji 极度克制
- 默认全文 0-2 个 emoji
- 不要 在小标题、段落开头、列表项前加装饰性 emoji（🚨 / 📊 / 🛠 / 💡 / 🤔 这类）
- 唯一允许的 emoji 用法：在某个反差信息后面，作为情绪反应（例如发现 multi-agent 偷烧 token 之后用 🤡 表达讽刺）
- 一句话判断："这个 emoji 是装饰性的还是反应性的？" 装饰就删，反应就留
2. 拒绝情绪词
不用：打脸 / 神话破灭 / 卷错方向 / 反潮流 / 唱衰 / 翻车 / 翻盘 / 颠覆认知 / 终于清晰
用：背书 / 共识 / 反对 / 倾向 / 质疑 / 边界 / 立场
→ AI 喜欢用情绪词制造冲击；yujiachen 用中性陈述展示反差，让事实自己说话。
3. 用概率词，避免绝对化
不用：直接跑赢 / 必然更好 / 完全失败 / 100% / 一定
用：经常好过 / 往往更优 / 有时 / 不少情况下 / 大多时候
→ 严格匹配原文措辞强度。alphasignal 原文是 "consistently match or beat"，对应"经常好过"而不是"直接跑赢"。
4. 小标题用陈述句，不用机械分层
不用：「第一层：业界共识」「第二层：学术数据」「🏗️ 第一节」
用：「业界的共识是 single 是默认，multi 才是例外」「学术界最近的研究也反对 multi agent」
→ 小标题本身就是观点。读者扫小标题应该能拿到核心论点，而不是看到一个空洞的分层标签。
5. 段落紧凑，1-3 句为主
AI 倾向把每个论点写成 5-8 句的长段。yujiachen 的段落是 1-3 句，密度高，不重复。
改法：把一个长段拆成 2-3 个短段，每段一个具体论点 + 一句解释。如果某句话只是"过渡 / 复述前面 / 缓冲"，删掉。
6. 引用要"少而准"
每个权威源 2-3 句话带过，引一句关键 quote 即止，不大段解读 quote。读者要的是"X 说了 Y"，不是"X 说了 Y，意思是 Z，所以可以推出 W"。
例：
❌ AI 写法（过度展开）：
Walden Yan 直接点名 OpenAI Swarm + Microsoft AutoGen「actively push concepts which I believe to be the wrong way of building agents」。他的反论从人类协作切入：「If Engineer A's code causes a merge conflict with Engineer B...」翻译：人类工程师能协作，是因为人类有"非平凡的智能"做隐式同步——能听懂语气、读出言外之意、推断对方决策依据。LLM 根本没这层能力。结果就是：「Running multiple agents in collaboration only results in fragile systems.」
✅ yujiachen 写法（紧凑）：
Cognition AI（开发 Devin 的公司）早在去年就发布了一篇《Don't Build Multi-Agents》，文章说到人类工程师能协作，是因为人类有"非平凡的智能"做隐式同步，这让我们能听懂语气、读出言外之意、推断对方决策依据。把没有这层能力的 LLM 构建成 multi agent 只会把系统变得脆弱。
7. 英文术语空格分隔，不连字符
不用：multi-agent / sub-agent / single-agent / pre-answer-scaffolding
用：multi agent / sub agent / single agent / pre answer scaffolding
→ 这是 yujiachen 一贯的 typography 偏好。改写时统一处理。
例外：固定专有名词（KV-cache）保留连字符。
8. 删过渡句
AI 喜欢写：「接下来我们看 X」「综上所述」「让我们深入了解」「值得注意的是」「另一方面」「更重要的是」
这些句子全删。直接进入下一段内容。读者会自动跟上。
例外：有 substance 的指引短语保留——例如「具体到 eval」「在这里你会发现」「我们首先要知道的一点是」「在跨过基础的质量门槛后」。这些不是空过渡，而是在指出"接下来要讲一个具体的 X"，对读者跟上节奏有用。
判断方法：把短语删掉，下一句还能不能让读者立刻进入状态？能就是空过渡，删；不能就是 substantive 指引，留。
9. 删修辞性夸张和悬空抽象词
不用：硬数据狠到离谱 / 数据狠到打脸 / 反差感拉满 / 信息密度爆炸
→ 让数据本身说话。「错误率放大 17.2 倍」就是一句话，不需要"狠到离谱"做副词。
同理，抽象 summary 词不能裸用：结构性 / 制度轨道 / 时空压缩 / 叙事 / 框架 / 焦虑 / 共识 / 信任危机——AI 喜欢用这些做总结标签。每用一次必须在同一句里搭一个具体数据点或命名实体，否则删掉重写。
判断方法：把这个抽象词从句子里删掉。如果信息密度没下降，它就是 padding。
❌ 这些动作拼在一起是同一种焦虑。
✅ 各方都在积极地寻找替代方案。
❌ 这是制度性的转变。
✅ 巴基斯坦这周首次单独提出收费机制。
10. 结尾用第一人称表立场
AI 倾向用问句轰炸：「你做项目时是直接堆 multi 还是先扛过 single？... 评论区聊聊👇」
yujiachen 倾向自然地表立场 + 邀请：
整体内容略长，我自己在日常开发中偏好 single agent，当然也在不少情况下用过 multi agent 优化过性能，欢迎大家在评论区追问或者分享一下自己的经验～
注意：承认稿子的不完美（"略长"）+ 第一人称立场（"我自己偏好"）+ 自然邀请（"欢迎"+"～"）。
不要做文学化收束：
- 不用 metaphor 重新包装一遍 framework（"棋盘上的最后一步落子……"）
- 不要回到标题做 poetic callback
- 不用「收场」/「尾声」/「下一幕」这类戏剧词
- 不要以反问句结尾（"这场博弈，谁真正赢了？"）
→ 最后一句具体陈述本身就是结尾。再加一段就是 AI 的"完整感"焦虑——它怕读者觉得文章没收住，所以补一段诗意收尾。yujiachen 信任读者能自己合上节奏。
11. hashtag 默认不用
除非用户明确说"加 tag"，否则不要在结尾堆「#AIagent #LLM #大模型」。yujiachen 的稿子默认不带 tag。
12. 文章名用《》
不用 <Don't Build Multi-Agents> 或 "Don't Build Multi-Agents"，用《Don't Build Multi-Agents》。
13. 列表项简洁，不加粗 + emoji
不用：1️⃣ **工具数 > 10** → 留 single（强行 multi 就用 decentralized topology，66.4% > centralized 62.1%）
用：1. 工具数 > 10 → 留 single
→ 装饰性数字 emoji（1️⃣2️⃣3️⃣）和段内加粗都删。如果数据点重要，单独成一句话讲，不塞进列表项。
14. 引用别人时使用准确归属
AI 容易把"X 写在自家博客"误归为"X 和 Y 团队聊到"。yujiachen 会主动核对来源——是原创博客还是 Webinar 转述？是 X 写的还是 Y 转述 X？
改写时遇到任何归属表述，先确认：
- 这是原文还是二手转述？
- 这是博客还是访谈 / 直播 / Tweet？
- 如果不确定，宁可写得保守（"在某次分享中提到"）也不要写错具体场合。
15. 写小标题问题前加"为什么"或陈述
yujiachen 喜欢用「为什么 X 经常好过 Y？」这种陈述式提问做主标题。
避免标题党套路：「multi agent 神话破灭」「你不知道的真相」「3 个数据让你重新认识 X」。
16. 不要 AI 对比 / 强调句式
这些句式即使内容是对的，读起来也像 AI 在"找戏剧感"。不用：
- 「不是 X 而是 Y」/「并不是 X 而是 Y」/「X 其实不是 Y 而是 Z」
- 「真正的 X」/「真正值得关注的是 X」/「真正的问题不是 X」
- 「不仅 X 更是 Y」/「不仅 X 还是 Y」
- 「与其说 X 不如说 Y」
- 「X 看起来像 Y，但其实是 Z」
替代：直接陈述 Y。如果非要做对比，让事实并列，不要用对比连接词强行对齐。
❌ 它不仅是一个工具问题，更是一个组织问题。
✅ 它是一个组织问题，工具只是症状。
→ 这是 AI 最高频的"句式装饰"。yujiachen 的论点足够实，不需要靠对比结构来制造重量感。
17. 不在文中评论自己的写作
不用：
- 「这个比喻很爽，但……」
- 「很少人注意到……」
- 「大家都没说到位……」
- 「这件事没人讨论」
- 「有个细节值得注意」
- 任何 narrate 读者反应（"读到这你可能会问……"）
→ AI 喜欢一边讲事一边讲"我讲得多机灵"，给读者陪伴感。yujiachen 不做这个——直接讲事，让读者自己 form opinion。如果一个论点真的"很少人讨论"，把它讲清楚就完了，不需要外加一句"很少人注意到"做注脚。
18. 开场直接进入论点，不做 meta 定位
不用：
- 「大部分讨论在分析 X，但其实 Y」
- 「很多人说 X，但真相是 Y」
- 「看到现在最多的两种解读……两种都不算错……其实应该问的是……」
- 「先说结论：……」
- 任何花两句以上对比"别人怎么说"才讲自己观点的开头
用：直接给出第一句论点。如果要 preview 结构，用一句对仗句把所有 section 都带过去（"向西，X；向东，Y"）。
→ AI 喜欢通过否定别人来定位自己；yujiachen 假设读者已经在思考这个话题，不需要被 onboarding。开场即论点本身。
19. 标点偏好
- 不用
「」 括号——读起来像翻译体或日漫腔
- 中文
—— 破折号克制使用，连续几句用就改成逗号、冒号或拆句
- 不要把
—— 单独占行做段落分隔条 / visual divider——这是 AI / markdown 渲染思路，yujiachen 用自然段落推进就够了
- 不用 ASCII 直引号
"foo"，用中文弯引号 "foo"
- 解释性破折号经常可删：「双方心里都有一张隐形的底牌——海峡」 → 删掉
——海峡，相信读者能跟上下一句
20. 公式 / 数学表达融入散文
不用：把公式独立成代码块、用缩进 + 符号注释（这是 LaTeX 论文 / 技术文档的写法）
用：把公式用中文白话写出来
→ XHS / 公众号 / 工程长文场景下，数学符号在视觉上会切断阅读流。严谨推导可以放最后一张图片做"延伸阅读"，正文保持白话。
❌ AI 写法：把 SE = σ / √N 独立成代码块，下面再用缩进列「σ : 单题噪声有多大 / N : 题数」做符号注释
✅ yujiachen 写法（融进散文）：
整体测量结果的标准差等于测量方法引入的噪声除以根号 N。大家可以先理解一个大概，我在最后一张图片里放了公式推导。
→ 同样适用于 LaTeX、表格化的概念定义、缩进的符号字典 —— 这些在 markdown 渲染好看，但 yujiachen 的稿子是按照 XHS / 公众号"散文 + 一两张图"的布局来的，不是 GitHub README。
工作流程
把下面这个 checklist 复制进 response，逐项打勾跟踪进度：
改写进度：
- [ ] 1. 读 test-cases（如果有，至少 1 个）建立 calibration
- [ ] 2. 通读用户的 AI 草稿，按 20 条规则逐条标记问题点（装饰性 emoji / 情绪词 / 绝对化 / 机械分层 / 过渡句 / AI 对比句式 / 悬空抽象词 / 自我评论 / 文学化收束 / meta 开场 / hashtag / 公式独立成块）
- [ ] 3. 改写：每条标记到的规则都对照修一遍
- [ ] 4. 回看：自己读一遍，问"这段读起来像 AI 还是像 yujiachen？" 还有 AI 味就再改
- [ ] 5. 边界检查：用户原稿已经写得不错的地方不要重写——只改有问题的地方
- [ ] 6. 如果是新场景且 test-cases/ 没覆盖，邀请用户保留为新样本（见上文「没有 test case 或场景没覆盖时」）
改写时的判断分歧
如果遇到"这个 emoji 该不该留"、"这句话是不是过渡"这种边缘判断，倾向删 / 简化。yujiachen 的整体审美是"克制" — 多删一点比多保留一点更安全。
不要做的事
- 不要重新组织文章结构，除非用户明确说"帮我重排"
- 不要替换用户原文里的金句 / 关键论点——只改语气和表达
- 不要加用户原稿没有的事实和数据——这是改写不是创作
- 不要把英文 quote 翻译成中文——除非用户明确要求
输出格式
- 直接输出改写后的完整稿
- 如果改动很多，可以在结尾用一两句话总结主要修改方向（"主要把 emoji 和情绪词删了，小标题改成陈述句"）
- 如果有不确定的归属 / 事实问题，单独列出来让用户确认，不要在正文里硬猜
Test Case 维护说明
test-cases/ 文件夹被 .gitignore 排除，只在本地保留，方便日后做 eval。每个 test case 是一个文件夹，结构：
test-cases/
└── YYYY-MM-DD-场景描述/
├── README.md # 可选：场景说明（什么稿子、什么平台、什么 audience）
├── ai-draft.md # AI 写的初稿
└── final.md # yujiachen 改完的最终稿
新建 test case 时：用 YYYY-MM-DD- 开头方便排序，文件夹名描述场景（例如 2026-05-04-single-vs-multi-agent）。
