lieflat-less-ai-tone: a corpus study that decides which AI-tone rules survive
一个基于 283 万字语料统计的去 AI 味 skill · An AI-tone removal skill grounded in a 2.83-million-character corpus study
At a glance
- What is it?
- A Chinese-language Agent Skill built from a 2.83-million-character comparison of model output and human writing. Eleven of twenty-six popular AI-tone markers held up; the rest did not.
- Who is it for?
- Adopt this if you write or edit Chinese prose and want a rule set whose markers were measured against a human control corpus rather than repeated from social media. Do not adopt it if you need English rewriting, semantic judgement about whether a metaphor works, or any change to facts, numbers or hedged claims, because the rule set excludes all three.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the project actually measures, and who it is for
Most advice about removing AI tone is a list. Lieflat Less AI Tone treats the list as a hypothesis. The README states that the study assembled 629 articles, 2,826,972 Chinese characters, 95,551 sentences and 45,721 paragraphs, with 300 articles generated by five models under controlled conditions and 329 written by humans. It then tested 26 candidate markers that circulate in public discussion as signs of AI writing, computing a frequency ratio between the generated side and the human side.
Eleven passed. Fifteen did not, and some point the other way. That reversal is the reason to read this project rather than another writing guide. The README reports that human writers use metaphor markers 2.4 times as often as generated text, and use rhetorical questions in body text 17 times as often. A rule that says delete the rhetorical question makes Chinese prose less human, not more.
The audience is narrow and specific. It is for people producing Chinese text who want a mechanical, auditable cleanup pass, and for people who want to see how a style claim can be tested at all. The repository ships README.md, README.en.md, RESEARCH.md, RESEARCH.en.md and SKILL.md, so the evidence and the rules are separate artifacts.
How the frequency ratio works and why the denominator decides the answer
The core statistic is R, the generated-side frequency divided by the human-side frequency. The README gives four bands: R at or above 2.0 is included, 1.25 to 2.0 is conditional on cross-group consistency and sufficient absolute volume, 0.8 to 1.25 has no discriminating power, and below 0.8 means the human side is higher, which the study treats as unusable for deletion rules.
The denominator is chosen per feature, and the README is explicit that a wrong denominator flips the sign. Question-form subheadings look like a 32-fold AI marker when counted per thousand characters. Counted as a share of all subheadings, generated text sits at 2.7 percent and the highest human group at 3.6 percent, and the difference disappears. The first denominator was measuring that generated articles have more subheadings, not that they prefer question-form ones.
Two further conditions gate inclusion. A feature must be locatable as a concrete string or sentence position, which rules out anything requiring semantic judgement. And it must be actionable without adding information. Material density is 2.8 times higher on the human side, a clear direction, but the README keeps only the executable half of it: do not overwrite data already present with a summary phrase.
Segmenting the corpus: the bug that produced a 51x claim
Sentence splitting is where this study nearly went wrong. The README describes the original procedure as splitting on 。！？ only, which counted Markdown tables and long unpunctuated lists as single sentences. One group's sentence-length standard deviation came out at 27 times its mean, and the study reported that generated text was 51 times more uniform in sentence length than human text.
The corrected procedure splits on lines first, drops heading rows, table rows, code blocks, block quotes and list items, then breaks on 。！？； and keeps fragments of at least four characters. Paragraphs are split on blank lines with the same exclusions and a minimum of eight characters. After the fix the ratio is 0.87, meaning no difference at all.
This matters beyond one number. Sentence-length uniformity is one of the most repeated AI-tone claims, and here it was an artifact of the parser. The README draws the operational rule from six such failures: before trusting any operator's frequency output, sample 20 matched instances by hand.
Installing the skill and running a first pass
The rule set ships as an Agent Skill. The README recommends opening `lieflat-less-ai-tone` in MoxtHub, and documents one local install path:
npx skills add larashero3-dotcom/lieflat-less-ai-toneAfter that, the README states that you submit text and it is processed according to the rule set. There is no server, no API key and no configuration file described in the README; the skill is a set of instructions plus the scripts directory in the repository.
The README also notes that `SKILL.md` can be used directly as a system prompt. That is the lighter path if you already have a chat setup and only want the rules, not the packaging. The rule text itself is in SKILL.md at the repository root, alongside README.md, RESEARCH.md and the assets and scripts directories.
What you should see after either route is the same behaviour: sentences that match none of the eleven rules come back unchanged, and heading levels, paragraph order, lists, tables and code block positions stay where they were. If your output has reordered sections or dropped a table, the skill is not being applied as documented.
The eleven surviving markers and the structural bias in the results
The strongest marker is not a punctuation habit. It is 段首零回指评论, a paragraph-opening comment with no backward reference, measured at 0.61 percent of non-first paragraphs on the generated side against 0.14 percent on the human side, an R of 4.4. The README's example is a paragraph that opens with an evaluation before naming what is being evaluated, so the reader has to look back to find the referent. Connective density overall is nearly identical on both sides, 14.4 percent against 15.1 percent. The difference is the missing demonstrative, and adding one restores the link.
The rest of the list clusters in the same region. Contrastive 不是 A 而是 B constructions at R 3.4. Adjacent-sentence structural isomorphism at 2.0. Em dashes at 3.0. Colon misuse at 3.8 for lead-ins and 9.4 for empty sentences that introduce a list. Ordinal subheadings at 3.1. Personified vehicles at 7.3. Five translated-syntax patterns between 2.6 and 5.3.
The pattern is worth stating plainly: the survivors are discourse and structure features, not vocabulary or punctuation features. Every lexical candidate the public list favors, including single-character function words and colloquial connectives, failed. That is a real finding, and it also means the skill will not fix a text that sounds off because of word choice.
Model-to-model spread makes single-model evidence useless
The README reports that em dash frequency per thousand characters is 5.16 for DeepSeek, 4.25 for Claude, 2.32 for Kimi, 0.51 for Gemini and 0.11 for GPT. That is a spread of roughly forty times on one feature. Question-form subheadings run 0.173 for Gemini and 0.000 for Kimi. Contrastive constructions peak on GPT at 1.26.
The study's own history is the argument. An early round used 30 articles from two models and concluded em dashes were a Claude-specific habit. Expanding to five models found a higher rate elsewhere, and most of the early conclusions did not replicate. The README states this directly as a limitation of single-model sampling.
There is a counterargument in the same section that the project answers rather than hides. GPT's em dash rate is so low that it has been used to argue the feature is dead. The study keeps it anyway, because Claude's rate is more than five times the human side and Claude is widely used for writing. That is a judgement call, not a measurement, and it is stated as one.
Where the rule set refuses to act, and why that is the right boundary
Three constraints limit what the skill will do. The whitelist principle means only the eleven markers are touched; anything else is preserved character for character. Information conservation means no new names, numbers, dates, quotes, sources or causal claims, and no deletion of the original's positions, conclusions or qualifiers. The README gives a sharp test for the second: changing 可能提升 to 提升 is falsifying the strength of a judgement, not cleaning style, and every content word in the rewrite must be traceable to the source.
The third constraint excludes semantic judgement entirely. Whether a metaphor is apt, whether a rhetorical question answers a real reader question, whether a set of parallel examples is padding: all three require understanding, cannot be written as an executable operator, and are therefore out of scope. The README says including them would only invite the operator to rewrite by feel.
This is a genuine limitation, not a modest one. A text can be free of all eleven markers and still read badly. The skill is a filter for measured surface habits, and it will not tell you whether the argument holds.
The rejected list is the more useful half, and the honest alternative
Fifteen candidates failed, and the README publishes them with their numbers. Sentence-length uniformity at 0.87. Adjacent sentence length difference at 1.00. Single-character 就 at 0.45. Colloquial connectives at 0.26. Question-and-answer pairs at 1.03. Metaphor markers at 0.42. Nominalization at 0.52. Body-text rhetorical questions at 0.05.
The translated-syntax screening is the clearest example of the method working. Eighteen candidates were drawn from the idea of English syntax transplanted into Chinese. Five survived. Three of the rejected ones were in the project's own first rule set: 以一种…的方式, 使得…能够, 扮演…角色. All measured below 0.03. The README's explanation is that these are genuinely translated constructions but not distinguishing features, because modern written Chinese has absorbed them.
The alternative to this project is a style linter or a general-purpose rewrite prompt. A linter matches patterns you configure, with no control group and no evidence about whether the pattern separates AI from human text. A rewrite prompt has no whitelist and will happily change your claims. The difference here is not the output format. It is that every rule carries a measured ratio and a stated rejection threshold, and the project shows you the rules it threw away.
Editorial conclusion
Adopt this if you write or edit Chinese prose and want a rule set whose markers were measured against a human control corpus rather than repeated from social media. Do not adopt it if you need English rewriting, semantic judgement about whether a metaphor works, or any change to facts, numbers or hedged claims, because the rule set excludes all three. Verify first that the SKILL.md whitelist matches the eleven surviving markers and not the fifteen rejected ones, and read section 5 of RESEARCH.md on the six measurement errors before trusting any frequency ratio you intend to act on.
Frequently asked questions
What is an AI tone?
The project treats it as a set of measurable textual features rather than a vibe, and tests each candidate against a human control corpus. Of 26 markers in circulation, 11 separated generated from human text; the strongest was a paragraph-opening comment with no backward reference, at 4.4 times the human rate.
How do I make this sound less like AI?
Apply the eleven surviving markers rather than the full public list, because the README reports that deleting rhetorical questions moves text further from human writing, since the human side uses them 17 times as often. The skill installs with npx skills add larashero3-dotcom/lieflat-less-ai-tone and leaves unmatched sentences unchanged.
Does lieflat-less-ai-tone work on English text?
The corpus and the rules are Chinese. The README describes segmentation on 。！？； and counts Chinese characters, and the repository ships README.en.md and RESEARCH.en.md as English translations of the documentation, not as an English rule set.
Will lieflat-less-ai-tone add data or citations to my text?
No. The README states an information conservation constraint: no new names, numbers, dates, quotes, sources or causal claims, and no removal of the original's conclusions or qualifiers. The only rule touching data density says not to overwrite existing data with a summary phrase.
Why does lieflat-less-ai-tone reject some well-known AI writing markers?
Because they did not separate the two corpora. The README lists sentence-length uniformity at 0.87, colloquial connectives at 0.26 and metaphor markers at 0.42, and notes that three translated-syntax patterns from the project's own first rule set measured below 0.03.
Community notes