npx skills add https://github.com/pr-pm/prpm --skill human-writing这项技能帮助你写出读起来像是出自一个有观点、有个性、有特定知识的真人手笔的内容——而不是一个公司博客生成器或试图听起来很乐于助人的 AI 助手。
写作时,要像在喝咖啡时向同事解释事情,而不是在会议室里做演示。
好的写作是具体的、有观点的、对话式的。糟糕的写作是泛泛的、安全的,听起来像其他所有科技博客一样。
❌ "我们非常激动地宣布..."
❌ "今天,我们很高兴地分享..."
❌ "我很高兴地介绍..."
❌ "加入我们这段激动人心的旅程..."
✅ "我们构建了 X,因为 Y 老是出问题。"
✅ "这是我们发布 X 到生产环境后学到的。"
✅ "大多数迁移工具能帮你完成 70% 的工作。以下是我们如何做到 95%。"
❌ "这种革命性的方法改变了开发人员的工作方式。"
❌ "利用尖端的人工智能技术..."
❌ "面向现代开发的颠覆性解决方案。"
❌ "释放您工作流程的全部潜力。"
✅ "Nango 用这个在 3 天内迁移了 47 个代码库。"
✅ "我们在 Next.js App Router 迁移上测试了这个——将手动修复从 800 个减少到 40 个。"
✅ "Stripe 的迁移指南有 12,000 字。这个工具将其缩减到 200 行代码。"
❌ "赋能开发者以利用协同效应..."
❌ "面向企业级的顶级解决方案..."
❌ "与您现有的生态系统无缝集成..."
❌ "通过协作范式推动创新..."
✅ "与您已经在用的任何东西都能配合工作。"
✅ "检测您的正则表达式无法捕获的边缘情况。"
✅ "一条命令。无需配置文件。没有意外。"
❌ "这可能有助于您潜在地改进..."
❌ "您或许可以考虑..."
❌ "这可能有用也可能没用..."
❌ "一些用户报告说..."
✅ "这能将迁移时间减半。"
✅ "当代码修改工具不够用时,就用这个。"
✅ "三位用户报告了这个边缘情况。我们修复了它。"
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
❌ "让我们深入探讨..."
❌ "闲话少说..."
❌ "归根结底..."
❌ "不言而喻..."
✅ 直接开始下一部分。你不需要过渡语。
✅ 或者使用一个具体的连接词:"以下是这为什么重要:"
❌ "以下是 5 个关键优势:
1. 提高生产力
2. 提升效率
3. 更好的协作
4. 增加灵活性
5. 简化工作流程"
✅ "这通过三种方式为您节省时间:
- 不再需要为边缘情况搜索文档——它们已编码在包中
- AI 一致地应用模式——您无需追查风格违规
- 测试是生成的,不是编写的——无需辛苦工作即可获得覆盖率"
❌ "许多开发人员为迁移而苦恼。"
✅ "我们都曾从迁移指南中复制粘贴,漏掉了一个边缘情况,然后花了 2 小时调试测试失败的原因。"
❌ "性能得到显著提升。"
✅ "添加索引后,查询时间从 847 毫秒下降到 12 毫秒。"
❌ "适用于流行的框架。"
✅ "已在 Next.js、Remix、SvelteKit 和 Astro 上测试过。"
❌ "这种方法可能有助于您潜在地改进工作流程。"
✅ "这能将您的迁移时间减半。"
❌ "您可能想要考虑使用此功能。"
✅ "当您有超过 10 个文件需要更新时,请使用此功能。"
❌ "一些用户发现这很有用。"
✅ "上周有三个团队采用了这个。三个团队都在 2 天内完成了发布。"
❌ "我们全面的解决方案处理所有用例。"
✅ "这无法捕获动态导入或字符串模板。您需要手动修复这些。"
❌ "完美无缝的迁移体验。"
✅ "预计大约 5% 的边缘情况需要人工审查。这比之前的 30% 有所下降。"
❌ "适用于任何代码库。"
✅ "如果您使用的是 TypeScript 4.5+ 版本,则适用。更早的版本需要一个 polyfill。"
✅ "您可以为此写一个 400 行的脚本。我们写过。它在 Unicode 上出错了。"
✅ "事实证明,大多数项目有 3-5 个代码修改工具无法处理的边缘情况。"
✅ "我们试过文档。开发人员不读它们。我们试过代码检查。他们忽略警告。"
❌ "可以通过运行命令来安装该包。"
✅ "安装包:prpm install @vendor/migration"
❌ "转换质量得到了改进。"
✅ "我们将转换质量从 78% 提高到了 94%。"
❌ "据观察,用户更喜欢..."
✅ "用户对 X 的偏好是 Y 的 4 倍。"
❌ "在这篇文章中,我们将讨论迁移是如何工作的。"
✅ "代码修改工具自动化了 70% 的迁移。这个工具能让您达到 95%。"
❌ "让我告诉您我们添加的一个新功能。"
✅ "您现在可以将整个框架迁移作为一个单独的包来安装。"
❌ "今天,我想谈谈我们对未来的愿景。"
✅ "包管理器改变了我们发布代码的方式。我们正在对 AI 指令做同样的事情。"
示例:
# 将 Copilot 规则转换为 Claude 格式
GitHub Copilot 使用一个带有 YAML 前置元数据的单一 `.github/copilot-instructions.md` 文件。Claude 使用 `.claude/skills/` 中独立的技能。
以下是我们如何处理转换:
1. 使用 js-yaml 解析 YAML 前置元数据
2. 提取 `applyTo` 通配符模式
3. 转换为 Claude 的 `fileMatch` 格式
4. 将多关注点的规则拆分为独立的技能
边缘情况:Copilot 的 `applyTo` 支持否定模式(`!**/*.test.ts`)。Claude 不支持。我们将这些保留为注释并记录一个警告。
转换质量:94%(6% 因否定模式需要人工审查)。
示例:
# 为什么仅有文档是不够的
Stripe 的迁移指南有 12,000 字。它很全面,写得很好,但大多数开发人员只是略读。
为什么?因为阅读文档需要:
1. 找到正确的部分(3-5 分钟)
2. 理解模式(5-10 分钟)
3. 应用到您的具体情况(10-30 分钟)
4. 每次迁移重复 20-50 次
那就是 6-15 小时。而且您仍然会错过边缘情况。
PRPM 包将这些模式编码一次。AI 一致地应用它们。总时间:20 分钟。
示例:
# 发布您的第一个 PRPM 包
## 您将构建什么
一个在您的 TypeScript 代码库中强制执行“无默认导出”的 Cursor 规则。到最后,您将把它发布到注册表。
## 先决条件
- Node.js 18+(检查:`node --version`)
- 已安装 PRPM CLI(`npm install -g prpm`)
- GitHub 账户(用于发布)
## 步骤 1:初始化包
```bash
$ mkdir no-default-exports
$ cd no-default-exports
$ prpm init
Format: cursor
Subtype: rule
Name: no-default-exports
Description: Enforce named exports in TypeScript
这将创建 prpm.json 和 .cursorrules。
编辑 .cursorrules:[... 完整示例 ...]
## 结构技巧
### 1. 开门见山
```markdown
❌ "在本文中,我们将探讨 API 迁移的挑战,讨论各种方法,并最终提出一个解决方案。"
✅ "API 迁移失败是因为文档解释了‘是什么’但没有解释‘为什么’。以下是如何将推理与代码一起发布。"
❌ ## 引言
❌ ## 背景
❌ ## 方法论
❌ ## 结果
✅ ## 问题:文档会过时
✅ ## 为什么代码修改工具不够用
✅ ## PRPM 包增加了什么
✅ ## 真实示例:Next.js App Router
❌ "转换过程简单高效。"
✅ "以下是完整的转换过程:
```bash
$ prpm install @nextjs/app-router-migration --as cursor
$ cursor apply @nextjs/app-router-migration
✓ 迁移了 47 个文件
⚠ 3 个文件需要人工审查(动态导入)
用时 90 秒。"
### 4. 拆分大段文字
- 每 2-3 段使用一个副标题
- 插入代码块让眼睛休息一下
- 对 3 个以上相关项目使用项目符号列表
- 为主要部分的分隔添加水平线
- 对重要的说明使用引用块
### 5. 以行动结尾,而非总结
```markdown
❌ "总之,我们讨论了 PRPM 包如何工作以及为什么它们对迁移有用。"
✅ "试试看:
```bash
prpm install @popular/package-name
有问题吗?关注 @prpmdev 或 提交一个 issue。"
## PRPM 中的语气示例
### 好的(来自 VISION.md):
> "代码修改工具自动化了迁移的前 60–80%。文档解释其余部分。开发人员仍然要与边缘情况、约定和测试作斗争。"
**为什么有效:** 具体的百分比,清晰的问题陈述,没有废话。
> "您可以阅读 47 份迁移指南。或者安装一个包。"
**为什么有效:** 具体数字,鲜明对比,自信。
> "我们在 Nango 的 SDK 迁移上试过这个。47 个代码库,3 天,零回归。"
**为什么有效:** 真实的公司,真实的数字,诚实的结果。
### 差的(AI 生成的风格):
> "我们创新的平台利用尖端的人工智能来简化您的开发工作流程。"
**为什么失败:** 流行语,模糊,可以描述任何东西。
> "我们很高兴地宣布一种革命性的新迁移方法。"
**为什么失败:** 过度热情,没有具体细节,营销腔调。
> "这个强大的解决方案赋能团队释放他们的全部潜力。"
**为什么失败:** 空洞的主张,企业行话,毫无意义。
## 自检问题
发布前,问问自己:
1. **一个人会大声说出这句话吗?** 如果不会,重写。
2. **每个主张都有证据支持吗?** 如果没有,添加具体细节或删除该主张。
3. **这个句子会出现在其他公司的博客上吗?** 如果会,让它更具体到 PRPM。
4. **这是否假设读者很笨?** 如果是,更信任他们一些。
5. **我是否因为不确定而模棱两可?** 如果是,核实事实或承认不确定性。
6. **这是一个可以删除的过渡语吗?** 如果是,删除它。
7. **这是以热情而非信息开头吗?** 如果是,以信息开头。
## 快速修复
### 如果听起来太正式:
- 将 "utilize" → "use"
- 将 "in order to" → "to"
- 将 "at this point in time" → "now"
- 将 "for the purpose of" → "for" 或 "to"
- 删除 "very," "really," "quite," "actually"
### 如果听起来太泛泛:
- 添加一个具体的数字
- 提及一个真实的公司/项目
- 包含一个代码示例
- 提及一个具体的边缘情况
- 引用用户反馈
### 如果听起来太像销售:
- 将最高级替换为比较级
- 将 "revolutionary" 替换为 "different because"
- 将 "amazing" 替换为具体的好处
- 删除感叹号(代码注释中适当的情况除外)
- 删除第一段(通常是营销废话)
## 记住
PRPM 用户是开发人员。他们有很好的废话检测器。写作时要像尊重他们的智力和时间一样。
**好的写作是修改出来的。** 初稿:把想法写下来。第二稿:删减 30%。第三稿:添加具体细节。第四稿:大声读出来。
如果您不会在 GitHub issue 评论里说这句话,就不要把它放在博客文章里。
每周安装量
85
代码仓库
GitHub 星标数
101
首次出现
2026年1月25日
安全审计
安装于
gemini-cli81
opencode81
codex81
github-copilot80
kimi-cli79
amp79
This skill helps you write content that reads like it was written by a real person with opinions, personality, and specific knowledge—not a corporate blog generator or AI assistant trying to sound helpful.
Write like you're explaining something to a colleague over coffee, not presenting to a board room.
Good writing is specific, opinionated, and conversational. Bad writing is generic, safe, and sounds like every other tech blog.
❌ "We're thrilled to announce..."
❌ "Today, we're excited to share..."
❌ "I'm delighted to introduce..."
❌ "Join us on this exciting journey..."
✅ "We built X because Y kept breaking."
✅ "Here's what we learned shipping X to production."
✅ "Most migration tools get you 70% of the way. Here's how we get to 95%."
❌ "This revolutionary approach transforms how developers work."
❌ "Leveraging cutting-edge AI technology..."
❌ "A game-changing solution for modern development."
❌ "Unlock the full potential of your workflow."
✅ "Nango used this to migrate 47 repos in 3 days."
✅ "We tested this on Next.js App Router migration—reduced manual fixes from 800 to 40."
✅ "Stripe's migration guide is 12,000 words. This gets it down to 200 lines of code."
❌ "Empowering developers to leverage synergies..."
❌ "Best-in-class solutions for enterprise-grade..."
❌ "Seamlessly integrate with your existing ecosystem..."
❌ "Drive innovation through collaborative paradigms..."
✅ "Works with whatever you're already using."
✅ "Detects edge cases your regex won't catch."
✅ "One command. No config file. No surprises."
❌ "This might help you potentially improve..."
❌ "You could possibly consider..."
❌ "This may or may not be useful..."
❌ "Some users have reported that..."
✅ "This cuts migration time in half."
✅ "Use this when codemods aren't enough."
✅ "Three users reported this edge case. We fixed it."
❌ "Let's dive deep into..."
❌ "Without further ado..."
❌ "At the end of the day..."
❌ "It goes without saying..."
✅ Just start the next section. You don't need a transition.
✅ Or use a specific connector: "Here's why that matters:"
❌ "Here are 5 key benefits:
1. Enhanced productivity
2. Improved efficiency
3. Better collaboration
4. Increased flexibility
5. Streamlined workflows"
✅ "This saves you time in three ways:
- No more searching docs for edge cases—they're encoded in the package
- AI applies patterns consistently—you don't chase style violations
- Tests are generated, not written—coverage without the grind"
❌ "Many developers struggle with migrations."
✅ "We've all copy-pasted from a migration guide, missed an edge case, and spent 2 hours debugging why tests fail."
❌ "Performance is significantly improved."
✅ "Query time dropped from 847ms to 12ms after adding the index."
❌ "Works with popular frameworks."
✅ "Tested on Next.js, Remix, SvelteKit, and Astro."
❌ "This approach may help you potentially improve your workflow."
✅ "This cuts your migration time in half."
❌ "You might want to consider using this feature."
✅ "Use this feature when you have more than 10 files to update."
❌ "Some users have found this useful."
✅ "Three teams adopted this last week. All three shipped in under 2 days."
❌ "Our comprehensive solution handles all use cases."
✅ "This won't catch dynamic imports or string templates. You'll need to fix those manually."
❌ "Perfectly seamless migration experience."
✅ "Expect about 5% of edge cases to need manual review. That's down from 30%."
❌ "Works with any codebase."
✅ "Works if you're on TypeScript 4.5+. Earlier versions need a polyfill."
✅ "You could write a 400-line script for this. We did. It broke on Unicode."
✅ "Turns out, most projects have 3-5 edge cases that codemods can't handle."
✅ "We tried docs. Developers don't read them. We tried linting. They ignore the warnings."
❌ "The package can be installed by running the command."
✅ "Install the package: prpm install @vendor/migration"
❌ "Improvements were made to the conversion quality."
✅ "We improved conversion quality from 78% to 94%."
❌ "It has been observed that users prefer..."
✅ "Users prefer X over Y by a 4:1 margin."
❌ "In this post, we will discuss how migrations work."
✅ "Codemods automate 70% of migrations. This gets you to 95%."
❌ "Let me tell you about a new feature we've added."
✅ "You can now install an entire framework migration as a single package."
❌ "Today, I want to talk about our vision for the future."
✅ "Package managers changed how we ship code. We're doing the same for AI instructions."
Example:
# Converting Copilot Rules to Claude Format
GitHub Copilot uses a single `.github/copilot-instructions.md` file with YAML frontmatter. Claude uses separate skills in `.claude/skills/`.
Here's how we handle the conversion:
1. Parse the YAML frontmatter with js-yaml
2. Extract the `applyTo` glob patterns
3. Convert to Claude's `fileMatch` format
4. Split multi-concern rules into separate skills
Edge case: Copilot's `applyTo` supports negation patterns (`!**/*.test.ts`). Claude doesn't. We preserve these as comments and log a warning.
Conversion quality: 94% (6% requires manual review for negation patterns).
Example:
# Why Docs Aren't Enough
Stripe's migration guide is 12,000 words. It's comprehensive, well-written, and most developers skim it.
Why? Because reading docs requires:
1. Find the right section (3-5 minutes)
2. Understand the pattern (5-10 minutes)
3. Apply to your specific case (10-30 minutes)
4. Repeat 20-50 times per migration
That's 6-15 hours. And you'll still miss edge cases.
PRPM packages encode those patterns once. AI applies them consistently. Total time: 20 minutes.
Example:
# Publishing Your First PRPM Package
## What You'll Build
A Cursor rule that enforces "no default exports" across your TypeScript codebase. By the end, you'll have published it to the registry.
## Prerequisites
- Node.js 18+ (check: `node --version`)
- PRPM CLI installed (`npm install -g prpm`)
- GitHub account (for publishing)
## Step 1: Initialize the Package
```bash
$ mkdir no-default-exports
$ cd no-default-exports
$ prpm init
Format: cursor
Subtype: rule
Name: no-default-exports
Description: Enforce named exports in TypeScript
This creates prpm.json and .cursorrules.
Edit .cursorrules: [... full example ...]
## Structural Techniques
### 1. Start With The Punchline
```markdown
❌ "In this article, we'll explore the challenges of API migrations, discuss various approaches, and ultimately present a solution."
✅ "API migrations fail because docs explain the 'what' but not the 'why.' Here's how to ship the reasoning with the code."
❌ ## Introduction
❌ ## Background
❌ ## Methodology
❌ ## Results
✅ ## The Problem: Docs Go Stale
✅ ## Why Codemods Aren't Enough
✅ ## What PRPM Packages Add
✅ ## Real Example: Next.js App Router
❌ "The conversion process is simple and efficient."
✅ "Here's the entire conversion:
```bash
$ prpm install @nextjs/app-router-migration --as cursor
$ cursor apply @nextjs/app-router-migration
✓ Migrated 47 files
⚠ 3 files need manual review (dynamic imports)
Done in 90 seconds."
### 4. Break Up Walls of Text
- Use subheadings every 2-3 paragraphs
- Insert code blocks to give eyes a break
- Use bullet lists for 3+ related items
- Add horizontal rules for major section breaks
- Use blockquotes for important callouts
### 5. End With Action, Not Summary
```markdown
❌ "In conclusion, we've discussed how PRPM packages work and why they're useful for migrations."
✅ "Try it:
```bash
prpm install @popular/package-name
Have questions? Follow @prpmdev or open an issue."
## Voice Examples from PRPM
### Good (from VISION.md):
> "Codemods automate the first 60–80% of migrations. Docs explain the rest. Developers still wrestle with edge cases, conventions, and tests."
**Why it works:** Specific percentages, clear problem statement, no fluff.
> "You could read 47 migration guides. Or install one package."
**Why it works:** Concrete number, stark contrast, confident.
> "We tried this on Nango's SDK migration. 47 repos, 3 days, zero regressions."
**Why it works:** Real company, real numbers, honest outcome.
### Bad (AI-generated style):
> "Our innovative platform leverages cutting-edge AI to streamline your development workflow."
**Why it fails:** Buzzwords, vague, could describe anything.
> "We're excited to announce a revolutionary new approach to migrations."
**Why it fails:** Over-enthusiastic, no specifics, marketing speak.
> "This powerful solution empowers teams to unlock their full potential."
**Why it fails:** Empty claims, corporate jargon, meaningless.
## Self-Check Questions
Before publishing, ask:
1. **Would a human say this out loud?** If not, rewrite.
2. **Is every claim backed by evidence?** If not, add specifics or remove the claim.
3. **Could this sentence appear in any other company's blog?** If yes, make it specific to PRPM.
4. **Does this assume the reader is dumb?** If yes, trust them more.
5. **Am I hedging because I'm uncertain?** If yes, verify facts or own the uncertainty.
6. **Is this a transition I can delete?** If yes, delete it.
7. **Does this open with enthusiasm instead of information?** If yes, lead with the info.
## Quick Fixes
### If it sounds too formal:
- Replace "utilize" → "use"
- Replace "in order to" → "to"
- Replace "at this point in time" → "now"
- Replace "for the purpose of" → "for" or "to"
- Cut "very," "really," "quite," "actually"
### If it sounds too generic:
- Add a specific number
- Name a real company/project
- Include a code example
- Mention a concrete edge case
- Quote user feedback
### If it sounds too salesy:
- Replace superlatives with comparisons
- Replace "revolutionary" with "different because"
- Replace "amazing" with specific benefits
- Remove exclamation points (except in code comments where appropriate)
- Cut the first paragraph (usually marketing fluff)
## Remember
PRPM users are developers. They have good bullshit detectors. Write like you respect their intelligence and their time.
**Good writing is revision.** First draft: get ideas down. Second draft: cut 30%. Third draft: add specifics. Fourth draft: read it out loud.
If you wouldn't say it in a GitHub issue comment, don't put it in a blog post.
Weekly Installs
85
Repository
GitHub Stars
101
First Seen
Jan 25, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
gemini-cli81
opencode81
codex81
github-copilot80
kimi-cli79
amp79
新闻稿撰写工具:使用 inference.sh CLI 进行事实核查与专业新闻稿创作
7,700 周安装