重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
writing-voice by epicenterhq/epicenter
npx skills add https://github.com/epicenterhq/epicenter --skill writing-voice核心原则:为耳朵而写,而不仅仅是为眼睛。散文应适合大声朗读。
在以下情况下使用此模式:
大声读出来。如果它:
那些大喊“这是 AI 写的”的模式:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
破折号(—)总是闭合的——周围没有空格。不要用 — 或 -。
| 偏好 | 何时使用 |
|---|---|
| 句号 (.) | 默认选择。两个句子通常比一个句子更清晰。 |
| 冒号 (:) | 引出解释时:“事情是这样的:它不工作” |
| 分号 (;) | 相关的独立分句时:“代码有效;测试通过” |
| 破折号 (—) | 插入语和强调时,总是闭合的:“它很快——真的很快” |
不确定时,用句号。
前面的部分说了要避免什么。这部分说要做什么。
每个段落都应该以结论开头。背景说明放在后面,而不是前面。读者应该在你带他们去之前就知道你要去哪里。
不好(埋没了重点):
在研究了多种冲突解决方法,包括 CRDT、操作转换和手动合并策略之后,我们发现 Yjs 配合 LWW 时间戳为我们提供了正确性和简单性的最佳组合。
好(开门见山):
Yjs 配合 LWW 时间戳提供了最佳的冲突解决方案。我们尝试了不带时间戳的 CRDT、操作转换和手动合并策略;在正确性方面,没有哪个能用这么少的代码与之匹敌。
单调的句子长度是听起来像机器人的最快方式。混合使用简短的陈述句和较长的解释句。短句有力。长句承载细微差别,并连接需要共存的想法。
不好(长度统一):
系统处理传入事件。它根据模式验证每个事件。然后将事件路由到适当的处理程序。处理程序相应地更新数据库。
好(节奏多变):
系统根据模式验证传入事件并将其路由到正确的处理程序。这很简单。但处理程序必须在单个事务中更新数据库、通知订阅者并维护审计日志。这才是它变得有趣的地方。
抽象语言迫使读者进行翻译工作。具体语言让他们能立即理解。
不好(抽象):
这种方法为数据检索操作提供了显著的性能改进。
好(具体):
行查找从 O(n) 降到了 O(1)。在一个 10,000 行的表上,这就是扫描每个单元格和一次哈希查找的区别。
并非每个过渡都需要一个章节标题。使用过渡句:在段落末尾用一个句子引出下一个主题,或在开头用一个句子链接回前文。标题会打断读者的阅读流;将它们用于主要的转变,而不是每一个新想法。
不好(标题过多):
问题
会话超时。
根本原因
刷新仅在导航时触发。
解决方案
我们为后台活动添加了保活机制。
好(流畅):
文件上传期间会话会超时。刷新逻辑仅在导航事件时触发,因此任何后台活动——上传、同步、长时间运行的变更——都会悄无声息地丢失会话。
解决办法是添加一个保活机制,在任何经过身份验证的请求时触发,而不仅仅是页面跳转。
无需判断即可应用的机械替换:
| 如果你写了... | 重写为... |
|---|---|
| "值得注意的是 X" | "X" |
| "为了实现 Y,我们需要 Z" | "Z 能让我们实现 Y" |
| "这之所以有效是因为..." | "这有效是因为..." |
| "这意味着..." | 直接陈述 |
| "应该指出的是..." | 完全删除 |
| "基本上,X" | "X" |
| "如前所述/如上所述" | 直接重新陈述 |
| "这使我们能够..." | "我们现在可以..." 或 "现在 X 可以工作了" |
| "我们需要确保..." | "X 必须..." 或直接去做 |
| "在...的背景下" | 删除或具体说明 |
| "值得一提的是..." | 提及它或不提及 |
| "今后,我们将..." | "接下来:..." 或直接描述行动 |
| "利用" / "使用" | "用" |
| "促进" | "让"、"使能" 或 "允许" |
| "实施一个解决方案" | "修复它" / "构建它" / 说明你构建了什么 |
解释某物如何工作时,展示机制,而不是营销说辞。先说发生了什么,再说为什么。
不好(过度解释,AI 腔调):
这里的关键洞察是,通过利用 Yjs 内置的冲突解决机制,我们可以有效地处理并发编辑,从而无缝地维护所有连接客户端之间的一致性。
好(直接,展示机制):
Yjs 自动解决冲突。两个用户编辑同一个字段,两个编辑都保留在 CRDT 中,LWW 时间戳决定胜者。无需手动合并逻辑。
不好(抽象):
工厂函数模式通过封装客户端创建逻辑并向消费者暴露定义良好的接口,提供了清晰的关注点分离。
好(具体):
createSync()接收一个 Y.Doc 并返回三个方法:connect()、disconnect()和status()。消费者永远不需要接触 WebSocket 设置、重连逻辑或身份验证令牌刷新。他们调用connect(),然后它就能工作。
撰写着陆页或面向产品的文案时:
好(自然,人性化):
“我每月为一个转录应用支付 30 美元。然后我算了一下:实际的 API 调用成本约为每小时 0.36 美元。按我的使用量(每天 3-4 小时),我支付 30 美元购买本应花费 3 美元的东西。
所以我构建了 Whispering 来去掉中间商。你提供自己的 API 密钥,你的音频直接发送给提供商,你支付实际成本。没有订阅,没有数据收集,没有锁定。”
坏(AI 生成的感觉):
“隆重推出 Whispering - 一款革命性的转录解决方案,赋予用户前所未有的控制力。
主要优势:
为什么选择 Whispering? 我们相信转录应该对每个人开放...”
区别在于:故事 vs 结构化章节,个人化 vs 公司化,具体数字 vs 模糊主张。
当用户提供示例文本或语气指导时,与之匹配:
Epicenter 的主要目标不是赚钱。愿景和使命是第一位的。财务可持续性是为了资助更多的开源开发和赞助贡献者——它是一种手段,而不是目的。
在撰写项目如何维持自身时,要谨慎使用听起来像融资演讲稿的语言。避免“收入”、“货币化”、“ARR”、美元估值和其他科技圈行话。改用“财务可持续性”或“维持项目”。可以提及像 Grafana 或 Bitwarden 这样的公司作为参考,但去掉美元数字——否则读起来就像我们在追逐它们的数字,而不是解释我们的方法。
每周安装量
69
代码仓库
GitHub 星标数
4.3K
首次出现
2026年1月28日
安全审计
安装于
gemini-cli62
opencode62
cursor59
codex58
github-copilot57
claude-code57
Core principle : Write for the ear, not just the eyes. Prose should be suitable to read out loud.
Use this pattern when you need to:
Read it out loud. If it:
Patterns that scream "AI wrote this":
Em dashes (—) are always closed—no surrounding spaces. Never — or -.
| Prefer | When |
|---|---|
| Period (.) | Default choice. Two sentences are often clearer than one. |
| Colon (:) | Introducing explanation: "Here's the thing: it doesn't work" |
| Semicolon (;) | Related independent clauses: "The code works; the tests pass" |
| Em dash (—) | Asides and emphasis, always closed: "It's fast—really fast" |
When in doubt, use a period.
The previous sections say what to avoid. This section says what to do.
Every paragraph should open with its conclusion. Setup comes after, not before. The reader should know where you're going before you take them there.
Bad (buries the point):
After investigating several approaches to conflict resolution, including CRDTs, operational transforms, and manual merge strategies, we found that Yjs with LWW timestamps gave us the best combination of correctness and simplicity.
Good (leads with it):
Yjs with LWW timestamps gave us the best conflict resolution. We tried CRDTs without timestamps, operational transforms, and manual merge strategies; none matched it for correctness with this little code.
Monotone sentence length is the fastest way to sound robotic. Mix short declarative sentences with longer explanatory ones. Short sentences punch. Longer ones carry nuance and connect ideas that need to live together.
Bad (uniform length):
The system processes incoming events. It validates each event against the schema. It then routes the event to the appropriate handler. The handler updates the database accordingly.
Good (varied rhythm):
The system validates incoming events against the schema and routes them to the right handler. Simple enough. But the handler has to update the database, notify subscribers, and maintain the audit log in a single transaction. That's where it gets interesting.
Abstract language forces the reader to do translation work. Concrete language lets them see it immediately.
Bad (abstract):
This approach provides significant performance improvements for data retrieval operations.
Good (concrete):
Row lookups dropped from O(n) to O(1). On a 10,000-row table, that's the difference between scanning every cell and a single hash lookup.
Not every transition needs a section heading. Use bridge sentences: one sentence at the end of a paragraph that sets up the next topic, or one at the start that links back. Headers break the reader's flow; use them for major shifts, not every new thought.
Bad (header-heavy):
The Problem
Sessions were timing out.
The Root Cause
The refresh only triggered on navigation.
The Solution
We added a keepalive to background activity.
Good (flowing):
Sessions were timing out during file uploads. The refresh logic only triggered on navigation events, so any background activity—uploads, sync, long-running mutations—would silently lose the session.
The fix was a keepalive that fires on any authenticated request, not just page transitions.
Mechanical substitutions you can apply without judgment:
| If you wrote... | Rewrite to... |
|---|---|
| "It's important to note that X" | "X" |
| "In order to achieve Y, we need to Z" | "Z gives us Y" |
| "The reason this works is because..." | "This works because..." |
| "What this means is that..." | State it directly |
| "It should be noted that..." | Drop it entirely |
| "Basically, X" | "X" |
| "As mentioned earlier/above" | Just re-state the thing |
| "This allows us to..." | "We can now..." or "Now X works" |
| "We need to make sure that..." | "X must..." or just do it |
| "In the context of..." | Drop it or be specific |
| "It is worth mentioning that..." | Mention it or don't |
| "Going forward, we will..." | "Next: ..." or just describe the action |
| "leverage" / "utilize" | "use" |
When explaining how something works, show the mechanism, not the marketing. Lead with what happens, then why.
Bad (over-explains, AI voice):
The key insight here is that by leveraging Yjs's built-in conflict resolution mechanism, we can effectively handle concurrent edits in a way that seamlessly maintains consistency across all connected clients.
Good (direct, shows the mechanism):
Yjs resolves conflicts automatically. Two users edit the same field, both edits survive in the CRDT, and the LWW timestamp picks the winner. No manual merge logic needed.
Bad (abstract):
The factory function pattern provides a clean separation of concerns by encapsulating the client creation logic and exposing a well-defined interface for consumers.
Good (concrete):
createSync()takes a Y.Doc and returns three methods:connect(),disconnect(), andstatus(). The consumer never touches WebSocket setup, reconnection logic, or auth token refresh. They callconnect()and it works.
When writing landing pages or product-facing prose:
Good (natural, human):
"I was paying $30/month for a transcription app. Then I did the math: the actual API calls cost about $0.36/hour. At my usage (3-4 hours/day), I was paying $30 for what should cost $3.
So I built Whispering to cut out the middleman. You bring your own API key, your audio goes directly to the provider, and you pay actual costs. No subscription, no data collection, no lock-in."
Bad (AI-generated feel):
"Introducing Whispering - A revolutionary transcription solution that empowers users with unprecedented control.
Key Benefits:
Why Whispering? We believe transcription should be accessible to everyone..."
The difference: story vs structured sections, personal vs corporate, specific numbers vs vague claims.
When the user provides example text or tone guidance, match it:
Epicenter's primary goal is not to make money. Vision and mission come first. Financial sustainability exists to fund more open-source development and sponsor contributors—it's a means, not the point.
When writing about how the project sustains itself, be cautious with language that sounds like a pitch deck. Avoid "revenue," "monetization," "ARR," dollar-figure valuations, and other tech bro jargon. Say "financial sustainability" or "sustaining the project" instead. Name companies like Grafana or Bitwarden as references, but drop the dollar figures—otherwise it reads as if we're chasing their numbers rather than explaining our approach.
Weekly Installs
69
Repository
GitHub Stars
4.3K
First Seen
Jan 28, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
gemini-cli62
opencode62
cursor59
codex58
github-copilot57
claude-code57
Pollinations.ai 免费AI图像生成:无需API密钥,通过URL参数快速创建营销与创意图片
10,200 周安装
| "facilitate" | "let", "enable", or "allow" |
| "implement a solution" | "fix it" / "build it" / say what you built |