public-writing
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChinesePublic writing
公开写作
For prose that a stranger reads without being paid to. A LinkedIn About section,
a blog post announcing a tool, a README, a release note. Not for manuscripts,
which are covered by and its .
scientific-writing-draftdlaub-style.mdTwo reference files hold the evidence this guide is built from. Read the relevant
one before drafting, because the verbatim examples are more useful than the rules
abstracted from them.
- , 25 sources, LinkedIn and personal site bios from computational biology, ML infrastructure and open source tool authors.
references/bio-examples.md - , 23 sources, posts announcing scientific software and ML models.
references/blog-examples.md
scripts/check-prose.sh写给陌生人阅读、且对方并非因为获得报酬而阅读的文章。例如 LinkedIn About 区域、宣布工具的博客文章、README 和发布说明。不适用于论文手稿;论文手稿由 及其 覆盖。
scientific-writing-draftdlaub-style.md本指南所依据的证据保存在两份参考文件中。起草前应阅读相关文件,因为逐字示例比从这些示例中抽象出的规则更有用。
- :25 个来源,收集了计算生物学、ML 基础设施和开源工具作者的 LinkedIn 与个人网站简介。
references/bio-examples.md - :23 个来源,收集了介绍科学软件和 ML 模型的博客文章。
references/blog-examples.md
scripts/check-prose.shWhich rules win
规则冲突时如何取舍
Four rule sets apply, and they contradict each other. Precedence, highest first:
- The fact and the number. No stylistic rule justifies dropping a figure, a dataset name, or a resource budget.
- for punctuation, sentence shape and vocabulary.
plain-writing - for claim-first structure and quantification discipline.
dlaub-style - Genre convention from the two reference files.
Where two and three collide, the resolutions are fixed:
| Question | dlaub-style | plain-writing | Public writing uses |
|---|---|---|---|
| Dashes in ranges | En dash, "190–450x" | No dashes, "190 to 450 times" | "190 to 450 times faster" |
| Sentence length | Short, one idea each | Longer and explanatory | Explanatory in the blog, mixed in the bio, never staccato |
| Demonstrative openers | Not addressed | Never open with This, That, These, Those | Never |
| Contractions | Absent from manuscripts | Fine | Use them, sparingly |
| Bold figure callouts | Required, | No decorative bold | No callouts. Caption states the conclusion |
| Citations | About one per factual claim | Not addressed | Link instead, one per claim about prior work |
| Paragraph shape | Claim first | Topic sentence, then support | Compatible. The claim is the topic sentence |
这里适用四组规则,而且彼此互相矛盾。优先级从高到低如下:
- 事实与数字。任何文风规则都不能成为删除数字、数据集名称或资源预算的理由。
- :规定标点、句子结构和词汇。
plain-writing - :规定先给结论的结构,以及量化表述的纪律。
dlaub-style - 两份参考文件所体现的文体惯例。
第二组和第三组发生冲突时,处理方式固定如下:
| 问题 | dlaub-style | plain-writing | 公开写作采用 |
|---|---|---|---|
| 范围中的破折号 | En dash,"190–450x" | 不用破折号,"190 to 450 times" | "190 to 450 times faster" |
| 句子长度 | 简短,每句一个想法 | 较长且带解释 | 博客中偏解释性,简介中长短混合,绝不写成短促节奏 |
| 指示代词开头 | 未涉及 | 不以 This、That、These、Those 开头 | 从不 |
| 缩写形式 | 手稿中不用 | 可以使用 | 谨慎使用 |
| 加粗数字标注 | 必须使用, | 不作装饰性加粗 | 不使用标注,由图注陈述结论 |
| 引用 | 每项事实性主张大约一处 | 未涉及 | 改用链接,每项关于既有工作的主张配一处 |
| 段落结构 | 结论先行 | 主题句先行,再提供支撑 | 两者兼容,结论就是主题句 |
Voice
文风
Write as one person who built a thing and is describing it. First person
singular. Present tense for what the work does, past tense for what you did.
以一个亲手构建了某项成果、并正在描述它的人的身份来写。使用第一人称单数。说明工作现在做什么时用现在时,说明你过去做了什么时用过去时。
Sentence rhythm, and the failure mode to watch for
句子节奏,以及需要警惕的失败模式
Long, connected sentences. Join clauses with because, since, so, which, while,
although and rather than, and let a sentence carry two related ideas instead of
splitting them into two sentences. Target a mean sentence length near 25 to 30
words in the blog, and check it rather than trusting your ear:
python3 -c "import re,statistics,sys;
t=' '.join(l.strip() for l in open(sys.argv[1]) if l.strip() and l[0] not in '#!*-');
w=[len(x.split()) for x in re.split(r'(?<=[.!?]) +',t) if x.strip()];
print('mean',round(statistics.mean(w),1),'| under 8 words:',sum(1 for x in w if x<8))" FILEThe failure mode is a stack of short declaratives used for emphasis, where each
one lands like a drumbeat and the cumulative effect is that everything sounds
maximally important. It reads as salesmanship rather than as a scientist
describing a result, and it is the single most likely way this guide gets
violated in practice. Symptoms, all drawn from a draft that had to be rewritten:
- A short sentence that only restates the previous one louder. "People have tried." "The obvious fix was unaffordable." "Half is not most."
- Anaphora for rhythm. "The obvious fix is X. The obvious fix was Y."
- Imperative or slogan headings. "Do not write the genomes down" should be "Assembling personal genomes during training".
- Superlative framings of your own contribution. "One thing it does that nothing else does" and "Every other tool silently misaligns them" should be "a detail that other tools appear to miss".
Do not perform the humility, either. Announcing that you are being candid is
its own kind of puffery: it asks for credit for the disclosure instead of just
making it. The linter treats this as an error.
<!-- prose-check:off -->
- "the read penalty is a real regression and worth stating" is the disclosure plus a bid for credit. The disclosure alone is "short reads are slower".
- Also banned: worth noting, worth saying out loud, to be honest, the honest reading, I want to be careful, let me be clear, it bears repeating, for what it is worth.
- Same for narrating your own posture toward a claim. "The tentative conclusion I draw is that X" and "The narrower claim is that X" should both be X, with the hedge carried by a verb such as appears or suggests.
Prefer the humbler verb throughout. The work performs comparably rather than
wins, appears to rather than proves, and the conclusion is tentative rather than
practical. Overclaiming is more damaging to a technical reader's trust than
underclaiming, and the numbers are already doing the persuading.
Note that this rule and the three-clause limit inherited from plain-writing pull
against each other. Long connected sentences win in the blog, so a handful of
warnings from the linter is the expected steady state
there; treat them as a prompt to reread, not as a defect to fix.
three or more clausesThree habits carry over from the manuscript voice and matter more here, not
less.
Name the specific thing. A generic descriptor is a note to yourself to look
up its referent. "a reference-sequence baseline" becomes "Flashzoi". "cohort
scale" becomes "the 3,202 samples in 1000 Genomes". If you cannot name it, the
claim is not ready.
Replace a magnitude word with the span. A magnitude word is an instruction
to go find the number, and the checker warns on each one it knows.
<!-- prose-check:off -->
The list is "orders of magnitude", "much faster", "substantially", "widely",
"significantly", "dramatically" and their neighbours.
<!-- prose-check:on -->
Pair every ratio with an absolute and a budget. A ratio persuades and an
absolute makes it checkable. gnomAD writes "nearly 5x larger" and "807,162 total
individuals" in one sentence. Heng Li writes "Aligning 30X human reads in 50
minutes over 32 CPU threads". The budget is what separates a measurement from a
boast, and the checker warns when a ratio appears with no dataset and no
resources on the same line.
Two habits are new, because the audience is not a reviewer.
Say where you lose. Ray Data's post reports being 30% slower than PyTorch
DataLoader and explains why, then shows where it wins. MosaicML says its speedup
disappears for LLM training. Heng Li says his own new aligner is worse than his
old one for short reads. Every post in the reference set that reads as honest
does one of these, and every post that reads as marketing does not.
Adoption over self-assessment. "Many research labs use my single-cell data
browser Cell Guide" beats any adjective. Download counts, dependent packages and
citing papers are facts.
<!-- prose-check:off -->
"Powerful" and "robust" are not.
<!-- prose-check:on -->句子应长而连贯。使用 because、since、so、which、while、although 和 rather than 之类的词连接分句,让一个句子承载两个相关想法,而不是拆成两句话。博客的平均句长应以 25 至 30 个词左右为目标。应当实际检查,不要凭感觉判断:
python3
t=' '.join(l.strip() for l in open(sys.argv[1]) if l.strip() and l[0] not in '#!*-');
w=[len(x.split()) for x in re.split(r'(?<=[.!?]) +',t) if x.strip()];
print('mean',round(statistics.mean(w),1),'| under 8 words:',sum(1 for x in w if x<8))" FILE需要避免的失败模式,是用一连串短陈述句来强调,让每一句都像鼓点一样落下,累积效果反而让所有内容都显得无比重要。读起来像销售话术,而不像科学家在描述结果;这也是实践中最可能违反本指南的一点。症状均取自一份不得不重写的草稿:
- 一个短句,只是把上一句换个说法再说得更响。"People have tried." "The obvious fix was unaffordable." "Half is not most."
- 为了节奏而使用重复开头。"The obvious fix is X. The obvious fix was Y."
- 使用命令式或口号式标题。"Do not write the genomes down" 应改为 "Assembling personal genomes during training"。
- 用自己的贡献作最高级包装。"One thing it does that nothing else does" 和 "Every other tool silently misaligns them" 应改为 "a detail that other tools appear to miss"。
也不要故作谦逊。宣称自己正在坦率表达,本身也是一种吹嘘:这是在要求读者为这种披露本身给予功劳,而不只是完成披露。linter 会把这视为错误。
<!-- prose-check:off -->
- "the read penalty is a real regression and worth stating" 属于披露加邀功。单纯披露应写成 "short reads are slower"。
- 同样禁用:worth noting、worth saying out loud、to be honest、the honest reading、I want to be careful、let me be clear、it bears repeating、for what it is worth。
- 对自身就某项主张所持立场的叙述同样如此。"The tentative conclusion I draw is that X" 和 "The narrower claim is that X" 都应直接写成 X,让 appears 或 suggests 之类的动词承载保留语气。
全文都应优先选用更谦逊的动词。工作表现相当,而不是胜出;结果看来如此,而不是得到证明;结论应保持暂定,而不是写成确定可操作的结论。对于技术读者来说,过度宣称比保守宣称更容易损害信任,而数字本身已经在完成说服。
还要注意,这条规则与从 plain-writing 继承的“三个分句以内”限制会相互拉扯。博客应以长而连贯的句子为准,因此 linter 偶尔发出 警告属于预期常态。应把它当作重读提示,而不是需要修复的缺陷。
three or more clauses从手稿文风延续下来、且在这里更为重要的习惯有三个。
指名具体对象。 泛泛的描述只是提醒你去查它指什么。"a reference-sequence baseline" 应变成 "Flashzoi";"cohort scale" 应变成 "the 3,202 samples in 1000 Genomes"。如果无法给出具体名称,这项主张就还没准备好。
用具体跨度替代程度词。 程度词是在提醒你去找对应数字,checker 会对它认识的每一个程度词发出警告。
<!-- prose-check:off -->
该列表包括 "orders of magnitude"、"much faster"、"substantially"、"widely"、"significantly"、"dramatically" 及其近义词。
<!-- prose-check:on -->
每个比值都要同时配上绝对值和预算。 比值负责说服,绝对值负责核查。gnomAD 在同一句中写明 "nearly 5x larger" 和 "807,162 total individuals"。Heng Li 写的是 "Aligning 30X human reads in 50 minutes over 32 CPU threads"。预算让测量有别于吹嘘;当同一行出现比值,却没有数据集和资源信息时,checker 会发出警告。
由于读者不是审稿人,这里新增两项习惯。
说明你在哪些地方落后。 Ray Data 的文章说明自己比 PyTorch DataLoader 慢 30%,解释原因,然后展示它在哪些地方胜出。MosaicML 说明其加速效果在 LLM 训练中消失。Heng Li 说明自己的新 aligner 在处理短 reads 时不如旧版本。参考集中每篇读来诚实的文章都会做其中一件事,而每篇读来像营销的文章都不会。
用采用情况代替自我评价。 "Many research labs use my single-cell data browser Cell Guide" 比任何形容词都有说服力。下载次数、依赖它的软件包和引用论文都是事实。
<!-- prose-check:off -->
"Powerful" 和 "robust" 不是事实。
<!-- prose-check:on -->The LinkedIn About section
LinkedIn About 区域
Target 110 to 150 words in four short paragraphs.
LinkedIn truncates at roughly 100 characters for a logged out reader and in
search results. The first sentence does most of the work. Write it to stand
alone.
Sentence one. First person, present tense, a verb about work being done, and
a named class of problem rather than a field. Under 100 characters. Compare "I
design new machine learning approaches for modeling biological systems" against
"AI Scientist with a PhD in Computational Biology". The first is a claim, the
second is a resume header true of a hundred people.
Paragraph two, the artifacts. Name each tool and gloss it in one clause, so a
reader can type the noun into GitHub. "ggrepel, an R package for annotating
figures" is the model. Describe a package by what it gives other people, not by
what it is technically. If there is adoption evidence, it goes here as a fact.
Paragraph three, the credentials, compressed. The PhD is a subordinate
clause, not a paragraph, and it comes after the work. Name advisors, labs and
institutions. Do not use prestige adjectives. Order the sentences so that
trimming from the end never removes anything load-bearing, which is Wes
McKinney's published rule for his own bio.
Paragraph four, the close. Optional. Several strong bios in the reference set
have none. If you write one, pick a form that does not read as an application.
Offer help rather than asking for it, or name the work you want to do rather than
the job, or scope the conversation to three specific topics with one of them off
topic. Put an email address in it, because recruiters without InMail have no
other way to reach you.
Hard rules for the bio:
- At least a dozen proper nouns. The single best discriminator between the real bios and the templates is proper nouns per sentence.
- At most two numbers, and each must be a fact rather than a result. "One of the first ten employees" and "over 20k citations" are facts. "Improved performance by 30%" against an unnamed baseline is filler, and every stock template has one.
- State a hobby if you want one, and never argue for its relevance. Arguing that mountain biking taught you to handle complex datasets is the tell.
- No trailing keyword list. LinkedIn has a Skills section.
- Translate once into plain English, early, in one sentence a non-specialist could repeat. "I teach people on the internet" is the sharpest example found.
目标为 110 至 150 个词,分为四个短段落。
对未登录读者和搜索结果而言,LinkedIn 大约会在 100 个字符处截断。第一句话承担了大部分作用,因此要写成能够独立成立的一句话。
第一句。 使用第一人称和现在时,动词描述正在开展的工作,并点明一类具体问题,而不是泛泛罗列一个领域。长度不超过 100 个字符。比较 "I design new machine learning approaches for modeling biological systems" 与 "AI Scientist with a PhD in Computational Biology":前者是一项主张,后者只是简历标题,成百上千人都可以这样描述自己。
第二段,成果。 列出每个工具,并用一个从句作简短解释,让读者可以直接把名称输入 GitHub 搜索。"ggrepel, an R package for annotating figures" 是范本。描述一个 package 时,应说明它为其他人带来了什么,而不是从技术层面说明它是什么。如果有采用情况方面的证据,就把它作为事实写在这里。
第三段,压缩后的资历。 PhD 应作为从属从句,而不是单独成段,并放在工作内容之后。写出导师、实验室和机构名称。不要使用 prestige adjectives。调整句序,确保从末尾删减内容时不会移除任何承重信息;这是 Wes McKinney 为自己简介公布的规则。
第四段,结尾。 可选。参考集中有几篇很出色的简介根本没有结尾。如果要写结尾,应选择一种读起来不像求职申请的形式。可以主动提供帮助,而不是请求帮助;可以说明你想从事的工作,而不是想找一份工作;也可以把交流范围限定为三个具体话题,并让其中一个稍微偏离主题。把电子邮箱地址写进去,因为无法使用 InMail 的招聘者没有其他联系你的方式。
简介的硬性规则:
- 至少有十二个专有名词。区分真实简介和模板的最佳单一指标,是每句话包含的专有名词数量。
- 最多两个数字,而且每个数字都必须是事实,而不是结果。"One of the first ten employees" 和 "over 20k citations" 是事实。"Improved performance by 30%" 没有提供具名 baseline,只是填充内容,每个通用模板里都有这种句子。
- 如果想写爱好,就写出来,但绝不要论证它与工作的相关性。声称 mountain biking 教会了你处理复杂数据集,正是典型的写作破绽。
- 结尾不要附加关键词列表。LinkedIn 已有 Skills 区域。
- 尽早用一个非专业人士能够复述的句子,把内容转译为通俗英语一次。"I teach people on the internet" 是找到的最锋利示例。
The blog post
博客文章
Target 1,800 to 2,500 words with three to five figures.
A tool announcement has three readers at once, and naming them before drafting
settles most of the wording. There is a practitioner from the field the tool
serves, who knows the problem and not the method, and a practitioner from the
field the method comes from, who knows the method and not the problem. The third
is a hiring manager or a prospective collaborator skimming for whether the work
is real, and writing for the first two handles the third.
Treat the word count as a ceiling. Personal blog tool announcements in the
reference set run from 450 to 2,900 words, and the 450 word one does the whole
job. Announcing more than one tool in a single post is already ambitious, and
anything past 2,500 words loses the reader furthest from your field before the
section that carries the result.
Opening. Follow the DeepVariant pattern. Two or three paragraphs stating the
problem in numbers, then the announcement in the fourth. Never say the problem is
hard. Give the quantity that makes it hard and let the reader draw the
conclusion, the way a storage figure of 1.97 petabytes and a bill over $50,000 a
month settle the question without the word "expensive" appearing.
Openings to avoid, all drawn from real posts: a Human Genome Project preamble, a
definition both audiences already have,
<!-- prose-check:off -->
such as "DNA is the blueprint of life", and any first sentence containing "we are
proud to".
<!-- prose-check:on -->
The strongest available motivation is often not yours to assert, because someone
with more standing has already written it down. When the dominant tool in a field
disclaims the problem your work takes on, quote the disclaimer rather than
asserting the gap yourself. AlphaGenome's limitations section saying "We haven't
designed or validated AlphaGenome for personal genome prediction, a known
challenge for AI models" is the pattern to look for.
Section skeleton. Practitioner voice, infrastructure evidence sections,
institutional limitations section. Roughly:
- The problem, in numbers.
- What I built, and the headline number in a practical unit.
- How it works. One mechanism per tool, at the depth a reader needs to believe the number.
- What it costs and what it buys, with the benchmark setup stated.
- What the tool made possible, which is the measurement.
- What it does not do.
- Resources.
Name sections for what the reader gets, not for what you implemented. MosaicML's
headings are the reusable form: "Correctness: no silent
pitfalls", "Efficiency: faster startup, lower costs". A section named for the
design decision most likely to be challenged is also good, in the shape of Simon
Willison's "Why an immutable API?".
Property: ConsequenceDefining terms. Gloss inline in an aside, once, and never in a glossary box.
Evo 2 writes "over 9.3 trillion tokens, in this case nucleotides". Evo 1 writes
"Proteins, the tiny molecular machines that make cells function". Budget about
eight defined terms for the whole post. Past that, the post is a tutorial.
Numbers and figures. Numbers live in prose. Both Heng Li posts in the
reference set carry zero figures and are among the most persuasive. A figure
caption states the conclusion, not the axes. If a claim rests on a magnitude, the
magnitude goes in the sentence, and a figure is never the only place a headline
number appears.
One comparison table across competing tools is the single most useful artifact
for a reader deciding whether to switch.
Limitations. Mandatory, as its own section, and specific. A null result the
work was designed to test belongs here as the centrepiece rather than buried, and
it is reported with the effect size, the controls it ran under, and whether it
replicates out of sample. State the unexplained variance as a number, and bound
it with what is known about the terms the study did not measure.
Close. A named Resources list. Manuscript with DOI, code, docs, install line.
Do not close on a hiring pitch or a demo signup, which is the worst ending in the
reference set. If a third party has verified a number, say so in one sentence.
目标为 1,800 至 2,500 个词,配三到五幅图。
发布工具公告时,文章同时面对三类读者。动笔前先明确他们是谁,这能解决大部分措辞问题:一位来自工具所服务领域的从业者,了解问题但不了解方法;另一位来自方法所属领域的从业者,了解方法但不了解问题;第三位是招聘经理或潜在合作者,只会快速浏览,以判断这项工作是否真实。写好前两类读者,也就写好了第三类。
把字数当作上限。 参考集中的个人博客工具公告从 450 到 2,900 个词不等,而那篇 450 词的文章已经把任务完成得很好。在一篇文章中宣布多个工具本就已经很有野心,超过 2,500 个词,则会在承载结果的核心章节出现之前,先失去离本领域最远的读者。
开头。 遵循 DeepVariant 的模式。先用两到三段以数字说明问题,然后在第四段宣布消息。绝不要直接说问题很难。给出让它变得困难的量,让读者自行得出结论,就像 1.97 petabytes 的存储量和每月超过 50,000 美元的账单已经足以说明问题,无须出现 "expensive" 一词。
应避免的开头均取自真实文章:Human Genome Project 式前言;两类读者都已经知道的定义,
<!-- prose-check:off -->
例如 "DNA is the blueprint of life",以及任何第一句含有 "we are proud to" 的表达。
<!-- prose-check:on -->
可用的最强动机往往不适合由你亲自断言,因为更权威的人已经把它写下来了。当某个领域的主流工具承认了你的工作所处理的问题存在时,引用该免责声明,而不是自行断言存在缺口。AlphaGenome 的 limitations section 写道:"We haven't designed or validated AlphaGenome for personal genome prediction, a known challenge for AI models",这正是应该寻找的模式。
章节骨架。 采用从业者口吻,配置基础设施证据章节和机构限制章节。大致如下:
- 问题,用数字呈现。
- 你构建了什么,以及以实用单位表示的核心数字。
- 它如何工作。每个工具只讲一种机制,深入到足以让读者相信该数字的程度。
- 它需要什么成本,又能带来什么收益,并说明 benchmark setup。
- 该工具促成了什么,也就是测量结果。
- 它做不到什么。
- 资源。
章节名称应说明读者能得到什么,而不是你实现了什么。MosaicML 的 标题形式可以复用,例如 "Correctness: no silent pitfalls"、"Efficiency: faster startup, lower costs"。以最可能受到质疑的设计决策来命名章节也很好,例如 Simon Willison 的 "Why an immutable API?"。
Property: Consequence术语定义。 在插入语中就地解释,一次即可,绝不要放进术语框。Evo 2 写 "over 9.3 trillion tokens, in this case nucleotides";Evo 1 写 "Proteins, the tiny molecular machines that make cells function"。整篇文章大约定义八个术语。超过这个数量,文章就变成教程了。
数字与图。 数字写在正文里。参考集中 Heng Li 的两篇文章都没有配图,却也是最有说服力的文章之一。图注要陈述结论,而不是坐标轴。如果某项主张依赖一个量级,就把该量级写进句子;图绝不能成为核心数字唯一出现的地方。
对于正在考虑是否切换工具的读者,一张跨竞争工具的比较表是最有用的单一材料。
限制。 必须单列一节,内容要具体。工作原本就是要检验的 null result,应作为核心内容放在这里,而不是埋在其他内容中;报告时写明 effect size、运行所依据的 controls,以及结果能否在 out-of-sample 条件下复现。用数字说明无法解释的 variance,并以研究所未测量的相关 terms 的已知范围来限定它。
结尾。 列出名称明确的 Resources。包含带 DOI 的 manuscript、代码、文档和安装命令。不要以招聘推销或 demo signup 收尾,这是参考集中最糟糕的结尾。如果有第三方验证过某个数字,用一句话说明。
Guardrails
防护规则
Run . Error rules fail the file, warn rules ask
a question. The reference files themselves fire many rules, because they quote
bad writing on purpose.
scripts/check-prose.sh draft.mdEvery banned pattern below appears in the reference set only in the weaker
sources. Full lists live in the two reference files.
<!-- prose-check:off -->
Punctuation. No em dash or en dash anywhere, including ranges. No middle dot.
Straight quotes. At most one colon per sentence and only to introduce a list. A
semicolon joining clauses becomes two sentences.
Marketing diction. leverage, seamless, cutting-edge, best-in-class,
game-changer, revolutionize, battle-tested, world-class, unlock, empower,
paradigm, supercharge.
AI tells. delve, tapestry, realm, landscape of, testament to, boasts,
showcase, underscore, pivotal, meticulous, nuanced, intricate, myriad, plethora,
crucial, vital.
Puffery. "proud to share", "significant milestone", "redefines", "it is worth
noting", "truly". Also robust and powerful, which are warnings rather than
errors: say what it withstands, or how fast it is.
Constructions. No negative parallelism, so no "not just X, it is Y" and no
"not only X but Y". No throat-clearing opener. No idiom, so no "under the hood",
"out of the box", "heavy lifting", "deep dive", "blueprint of life". No sentence
or paragraph opening with a demonstrative pronoun. No stacked rhetorical
questions. No opening with a count of things.
Structure. Sentence case headings. No decorative bold. Three or more clauses
in a prose sentence becomes a First, Second, Third sequence or separate
sentences. Lists capped at four or five points, used sparingly in an essay.
<!-- prose-check:on -->
Substituting popularity for evidence is the same failure as puffery.
"Downloaded more than 700,000 times, with 120+ citations" as a stand-in for a
benchmark appears only in the weakest post in the reference set. Adoption is a
real fact about a tool, and it is not a performance result.
运行 。error 规则会使文件失败,warn 规则会提出疑问。参考文件本身会触发许多规则,因为它们会故意引用糟糕的写作。
scripts/check-prose.sh draft.md下面每个禁用模式都只出现在参考集中较弱的来源里。完整列表位于两份参考文件中。
<!-- prose-check:off -->
标点。 任何位置都不得出现 em dash 或 en dash,范围表达也不例外。不得使用 middle dot。使用直引号。每句话最多一个冒号,且只能用于引出列表。用分号连接的分句应拆成两句话。
营销措辞。 leverage、seamless、cutting-edge、best-in-class、game-changer、revolutionize、battle-tested、world-class、unlock、empower、paradigm、supercharge。
AI 写作痕迹。 delve、tapestry、realm、landscape of、testament to、boasts、showcase、underscore、pivotal、meticulous、nuanced、intricate、myriad、plethora、crucial、vital。
吹嘘。 "proud to share"、"significant milestone"、"redefines"、"it is worth noting"、"truly"。robust 和 powerful 也一样,但它们触发的是 warning 而不是 error:应说明它能承受什么,或运行速度有多快。
句式。 不使用否定式排比,因此不能写 "not just X, it is Y" 或 "not only X but Y"。不要使用铺垫式开头。不要使用习语,因此不能写 "under the hood"、"out of the box"、"heavy lifting"、"deep dive"、"blueprint of life"。任何句子或段落都不得以指示代词开头。不要堆叠反问句。不要以事物数量开头。
结构。 标题采用 sentence case(句首字母大写式)。不要作装饰性加粗。一个正文句子包含三个或更多分句时,改写成 First、Second、Third 的顺序,或拆成独立句子。列表最多四到五项,在文章中谨慎使用。
<!-- prose-check:on -->
用流行度替代证据与吹嘘属于同一种错误。"Downloaded more than 700,000 times, with 120+ citations" 不能替代 benchmark;这种写法只出现在参考集中最弱的文章里。采用量是关于工具的真实事实,但不是性能结果。
Before sending
发送前检查
- Does the first sentence work alone, with nothing after it?
- Is every ratio paired with an absolute, a named dataset, and a resource budget?
- Is there a sentence saying where the work loses, or where the speedup stops mattering?
- Could a reader check a claim by typing a proper noun into GitHub or Google?
- Is every number a fact or a measurement rather than a round decile against an unnamed baseline?
- Any dash, curly quote, or clause-joining semicolon?
- Any word from the banned lists?
- Does any sentence or paragraph open with This, That, These or Those?
- Did come back clean on the error rules?
check-prose.sh
- 第一句话能否在没有任何后文的情况下独立成立?
- 每个比值是否都同时配上了绝对值、具名数据集和资源预算?
- 文中是否有一句话说明工作在哪里落后,或加速在何处不再有意义?
- 读者能否把一个专有名词输入 GitHub 或 Google,以核验某项主张?
- 每个数字是事实或测量结果,而不是拿一个取整的十进制数与未具名的 baseline 对比?
- 有没有任何 dash、弯引号,或用于连接分句的分号?
- 有没有使用禁用列表中的词?
- 任何句子或段落是否以 This、That、These 或 Those 开头?
- 在 error 规则上是否干净通过?
check-prose.sh
Where the facts live
事实保存在哪里
Before drafting, collect every headline number into one file, each with its
dataset name and its resource budget attached, and check them once against the
analysis that produced them. Draft from that file rather than rederiving figures
mid-sentence, because a number that shifts during drafting is how a wrong figure
reaches a public post. Keep a pointer from each number back to its source, so a
claim that needs more than the headline can be followed up without a search.
动笔前,把每个核心数字集中到一个文件中,每个数字都附上数据集名称和资源预算,并对照生成这些数字的分析结果检查一次。应从该文件起草,而不要在句子写到一半时重新推导数字,因为起草过程中数字发生变化,正是错误数字进入公开文章的原因。为每个数字保留一条指向来源的链接,这样无需搜索,也能追查超出核心数字本身的信息。