Vibe Writing 写作系统,用于创建高质量、低AI检测率的中文文章。适用于公众号文章、博客、Newsletter等内容写作,也可用于修改已有文章降低AI味,或审校内容质量。包含三遍审校机制、降AI味技巧和口语化写作指南。
npx skills add https://github.com/lornshrimp/Lorn.NovelWriteSkills --skill vibe-writing
系统化创建真实、人性化中文内容的方法论,确保通过 AI 检测同时保持高质量。
灵活流程 + 核心原则不妥协
writing-workspace/
├── drafts/ # 草稿和工作文件(Brief、协作文档等)
├── research/ # 调研知识库
├── published/ # 已完成的文章 ⭐
└── images/ # 文章配图
| 文件类型 | 存放位置 | 命名规范 |
|---------|---------|---------|
| Brief | drafts/ | 项目名-brief.md |
| 草稿 | drafts/ | 项目名-draft.md |
| 调研 | research/ | 主题-YYYYMMDD.md |
| 最终文章 | published/ | 文章标题.md |
| 配图 | images/ | 文章名-描述.jpg |
首次使用时询问用户:
> 「是否需要创建写作工作区目录?」
> - 是 → 创建 4 个文件夹
> - 否 → 使用现有目录
生成命令:
mkdir -p writing-workspace/{drafts,research,published,images}
开始前先判断任务类型:
| 类型 | 描述 | 行动 |
|------|------|------|
| A | 有完整 brief 的新文章 | 完整 9 步流程 |
| B | 无 brief 的新文章 | 先讨论 brief,再走流程 |
| C | 修改已有文章 | 读取 → 理解 → 修改 → 审校 |
| D | 文章审校/降AI味 | 应用三遍审校机制 |
| E | 快速咨询 | 直接回答 |
在开始写作任务前,询问用户:
drafts/、research/、published/、images/注意: 此步骤只在首次使用或用户明确要求时执行。
drafts/项目名-brief.md,包含:何时必须搜索:
信息源优先级:
保存调研内容到 research/主题-YYYYMMDD.md:
不要直接写!先讨论选题!
提供 3-4 个选题方向,每个包含:
等待用户选择,不要自己决定!
如果需要测试或特殊配图需求,保存到 drafts/项目名-协作.md:
阅读 references/写作风格指南.md:
降低 AI 味的方法:
使用原则:
如果创建了协作文档:
绝不编造数据!等待真实数据!
初稿保存到 drafts/项目名-draft.md
写作要点:
可以尝试不同的写作风格:
参考: references/降AI味审校清单.md
1. 删除 AI 套话(全文搜索,一个不留)
❌ 必删清单:
- 「在当今时代」「随着...的发展」「在...的背景下」
- 「值得注意的是」「需要指出的是」
- 「综上所述」「总而言之」「让我们来看看」
- 「从某种意义上说」「毋庸置疑」「不言而喻」
✅ 替换方案:
- 「值得注意」→ 直接说内容 / 「重点来了」
- 「综上所述」→ 「说白了」/「简单来说」
- 「显著提升」→ 具体数字 或 「涨了很多」
2. 拆解工整句式
❌ 过度对比:「不是A而是B,不是C而是D,不是E而是F」
✅ 最多用一次,或拆成独立短句
❌ 过度排比:「要么...要么...要么...」
✅ 独立短句 + 问号
3. 替换书面词汇
书面词 → 口语化:
- 「显著提升」→ 「涨了10倍」/「效果很好」
- 「充分利用」→ 「用好」/「用上」
- 「深入了解」→ 「搞清楚」/「弄明白」
- 「进行操作」→ 「操作」/「做」
4. 加入个人感受
中立表达 → 加入态度:
- 「成本较高」→ 「贵死了」
- 「门槛较高」→ 「门槛高到离谱」
- 「效果不佳」→ 「有点惨不忍睹」
5. 短句化处理
❌ 「这个功能不仅提升了效率,而且降低了成本,同时还改善了体验」
✅ 「这个功能提升了效率,降低了成本。用户体验也改善了。」
降AI味自查:
标点检查(必做!):
其他细节:
保存最终文章到 published/文章标题.md
配图流程:
images/(命名:文章名-描述.jpg)不要只写配图指南,要直接完成配图!
drafts/research/published/images/详细指南请查阅:
references/降AI味审校清单.md - 完整的降AI味审校清单references/写作风格指南.md - 写作风格指南和示例记住:Think Aloud + 真实素材 + 三遍审校 = 零 AI 味文章!
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementing any feature or bugfix, before writing implementation code
Use when you have a spec or requirements for a multi-step task, before touching code
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
| Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases.
Official Opentrons Protocol API for OT-2 and Flex robots. Use when writing protocols specifically for Opentrons hardware with full access to Protocol API v2 features. Best for production Opentrons protocols, official API compatibility. For multi-vendor automation or broader equipment control use pylabrobot.
Take lornshrimp/vibe-writing from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.