菜单
把 AI 风格的草稿改写成 yujiachen 的个人写作风格——克制 emoji、紧凑短段落、概率词代替绝对化、中性陈述代替情绪词、英文术语空格分隔。 当用户给出中文 / 中英混用稿件（小红书 / newsletter / 工程博客 / 长文评论）并要求"按我的风格改 / 去 AI 味 / 润色 / 改改这篇"等改写意图时触发；即使措辞模糊（"帮我改改"），只要上下文是结构化稿件就应当考虑。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Renders the response as a self-contained, visually polished HTML page saved to /tmp and opened in the browser, replacing plain markdown or wall-of-text output. Triggers when the user says "/view-as-html", or asks to "view as html / show as a page / make a pretty page / 用 html 给我看 / 做成网页 / 别给我干巴巴的文字 / 我想浏览不是阅读". Also applies when the response is structured information — comparisons, plans, status reports, research summaries, concept explainers, PR write-ups, design tokens, dashboards — even without an explicit "html" keyword, since a layout with cards, tables, SVG and color hierarchy reads faster than markdown for these shapes.
Audits an existing skill against the official Anthropic Agent Skills best practices document (https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices), then produces a categorized report — Must Fix (explicit warnings violated), Should Consider (acceptable but improvable), and Already Passing — with file:line citations and concrete fixes. Triggers when the user says "/review-skill", "review this skill", "audit my skill", "check this skill against best practices", "is this skill following best practices", "对这个 skill 做个 review", "审查一下这个 skill", "skill 是不是符合最佳实践". Also applies when the user references a skill directory (e.g. `agents/skills/foo` or `~/.claude/skills/bar`) and asks for sanity check, quality pass, or evaluation against documented best practices — even without naming the practices doc explicitly.
Initialize any repository with comprehensive lint rules and code quality tooling. Covers cyclomatic complexity, function/file length limits, parameter counts, type safety, code duplication, test coverage, and folder file-count limits. Supports TypeScript, Go, Python, Rust, and Java. Use this skill whenever the user asks to set up lint rules, initialize code quality checks, configure a linter, or bootstrap a new repo with quality gates — even if they don't say "lint" explicitly (e.g., "set up this repo", "add quality checks", "configure eslint/golangci-lint/ruff"). Also trigger when the user says /lint-init.
This skill should be used when exporting, storing, or reapplying agent-browser cookies across sessions, especially for localhost login states.
| name | personal-voice |
| description | 把 AI 风格的草稿改写成 yujiachen 的个人写作风格——克制 emoji、紧凑短段落、概率词代替绝对化、中性陈述代替情绪词、英文术语空格分隔。 当用户给出中文 / 中英混用稿件（小红书 / newsletter / 工程博客 / 长文评论）并要求"按我的风格改 / 去 AI 味 / 润色 / 改改这篇"等改写意图时触发；即使措辞模糊（"帮我改改"），只要上下文是结构化稿件就应当考虑。 |
把 AI 写的稿子改成 yujiachen 的写作风格。下面按重要性列规则——每条都对应一类 AI 写法的稳定坏味道。
test-cases/ 目录下每个文件夹是一个对照样本：
ai-draft.md：典型的 AI 写法初稿final.md：yujiachen 改完的最终稿README.md（可选）：场景说明改写之前先随机抽 1-2 个通读——AI 在哪些地方过度修饰，yujiachen 把它们删到了哪里。这比读规则更直观。如果用户的稿子和某个 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 里，样本只在本机保留，不会被提交。
不用：打脸 / 神话破灭 / 卷错方向 / 反潮流 / 唱衰 / 翻车 / 翻盘 / 颠覆认知 / 终于清晰
用：背书 / 共识 / 反对 / 倾向 / 质疑 / 边界 / 立场
→ AI 喜欢用情绪词制造冲击；yujiachen 用中性陈述展示反差，让事实自己说话。
不用：直接跑赢 / 必然更好 / 完全失败 / 100% / 一定
用：经常好过 / 往往更优 / 有时 / 不少情况下 / 大多时候
→ 严格匹配原文措辞强度。alphasignal 原文是 "consistently match or beat"，对应"经常好过"而不是"直接跑赢"。
不用：「第一层：业界共识」「第二层：学术数据」「🏗️ 第一节」
用：「业界的共识是 single 是默认，multi 才是例外」「学术界最近的研究也反对 multi agent」
→ 小标题本身就是观点。读者扫小标题应该能拿到核心论点，而不是看到一个空洞的分层标签。
AI 倾向把每个论点写成 5-8 句的长段。yujiachen 的段落是 1-3 句，密度高，不重复。
改法：把一个长段拆成 2-3 个短段，每段一个具体论点 + 一句解释。如果某句话只是"过渡 / 复述前面 / 缓冲"，删掉。
每个权威源 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 只会把系统变得脆弱。
不用：multi-agent / sub-agent / single-agent / pre-answer-scaffolding
用：multi agent / sub agent / single agent / pre answer scaffolding
→ 这是 yujiachen 一贯的 typography 偏好。改写时统一处理。
例外：固定专有名词（KV-cache）保留连字符。
AI 喜欢写：「接下来我们看 X」「综上所述」「让我们深入了解」「值得注意的是」「另一方面」「更重要的是」
这些句子全删。直接进入下一段内容。读者会自动跟上。
例外：有 substance 的指引短语保留——例如「具体到 eval」「在这里你会发现」「我们首先要知道的一点是」「在跨过基础的质量门槛后」。这些不是空过渡，而是在指出"接下来要讲一个具体的 X"，对读者跟上节奏有用。
判断方法：把短语删掉，下一句还能不能让读者立刻进入状态？能就是空过渡，删；不能就是 substantive 指引，留。
不用：硬数据狠到离谱 / 数据狠到打脸 / 反差感拉满 / 信息密度爆炸
→ 让数据本身说话。「错误率放大 17.2 倍」就是一句话，不需要"狠到离谱"做副词。
同理，抽象 summary 词不能裸用：结构性 / 制度轨道 / 时空压缩 / 叙事 / 框架 / 焦虑 / 共识 / 信任危机——AI 喜欢用这些做总结标签。每用一次必须在同一句里搭一个具体数据点或命名实体，否则删掉重写。
判断方法：把这个抽象词从句子里删掉。如果信息密度没下降，它就是 padding。
❌ 这些动作拼在一起是同一种焦虑。
✅ 各方都在积极地寻找替代方案。
❌ 这是制度性的转变。
✅ 巴基斯坦这周首次单独提出收费机制。
AI 倾向用问句轰炸：「你做项目时是直接堆 multi 还是先扛过 single？... 评论区聊聊👇」
yujiachen 倾向自然地表立场 + 邀请：
整体内容略长，我自己在日常开发中偏好 single agent，当然也在不少情况下用过 multi agent 优化过性能，欢迎大家在评论区追问或者分享一下自己的经验～
注意：承认稿子的不完美（"略长"）+ 第一人称立场（"我自己偏好"）+ 自然邀请（"欢迎"+"～"）。
不要做文学化收束：
→ 最后一句具体陈述本身就是结尾。再加一段就是 AI 的"完整感"焦虑——它怕读者觉得文章没收住，所以补一段诗意收尾。yujiachen 信任读者能自己合上节奏。
除非用户明确说"加 tag"，否则不要在结尾堆「#AIagent #LLM #大模型」。yujiachen 的稿子默认不带 tag。
不用 <Don't Build Multi-Agents> 或 "Don't Build Multi-Agents"，用《Don't Build Multi-Agents》。
不用：1️⃣ **工具数 > 10** → 留 single（强行 multi 就用 decentralized topology，66.4% > centralized 62.1%）
用：1. 工具数 > 10 → 留 single
→ 装饰性数字 emoji（1️⃣2️⃣3️⃣）和段内加粗都删。如果数据点重要，单独成一句话讲，不塞进列表项。
AI 容易把"X 写在自家博客"误归为"X 和 Y 团队聊到"。yujiachen 会主动核对来源——是原创博客还是 Webinar 转述？是 X 写的还是 Y 转述 X？
改写时遇到任何归属表述，先确认：
yujiachen 喜欢用「为什么 X 经常好过 Y？」这种陈述式提问做主标题。
避免标题党套路：「multi agent 神话破灭」「你不知道的真相」「3 个数据让你重新认识 X」。
这些句式即使内容是对的，读起来也像 AI 在"找戏剧感"。不用：
替代：直接陈述 Y。如果非要做对比，让事实并列，不要用对比连接词强行对齐。
❌ 它不仅是一个工具问题，更是一个组织问题。
✅ 它是一个组织问题，工具只是症状。
→ 这是 AI 最高频的"句式装饰"。yujiachen 的论点足够实，不需要靠对比结构来制造重量感。
不用：
→ AI 喜欢一边讲事一边讲"我讲得多机灵"，给读者陪伴感。yujiachen 不做这个——直接讲事，让读者自己 form opinion。如果一个论点真的"很少人讨论"，把它讲清楚就完了，不需要外加一句"很少人注意到"做注脚。
不用：
用：直接给出第一句论点。如果要 preview 结构，用一句对仗句把所有 section 都带过去（"向西，X；向东，Y"）。
→ AI 喜欢通过否定别人来定位自己；yujiachen 假设读者已经在思考这个话题，不需要被 onboarding。开场即论点本身。
「」 括号——读起来像翻译体或日漫腔—— 破折号克制使用，连续几句用就改成逗号、冒号或拆句—— 单独占行做段落分隔条 / visual divider——这是 AI / markdown 渲染思路，yujiachen 用自然段落推进就够了"foo"，用中文弯引号 "foo"——海峡，相信读者能跟上下一句不用：把公式独立成代码块、用缩进 + 符号注释（这是 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 的整体审美是"克制" — 多删一点比多保留一点更安全。
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）。