# De-AI Style: Bilingual (Chinese and English) Writing Constraint Engineering as a Reusable Skill

1. Define the problem first: what “AI flavor” actually is

Before arguing about how to remove it, turn the vague sense of “AI flavor” into observable features. Without that step, a guideline can neither be implemented nor verified. Across common observations of generative-model output, AI flavor tends to appear as the following stable patterns:

• Low sentence-length variance. Sentences cluster between 20 and 30 characters, with little variation between long build-ups and short breaks. The result reads like a conveyor belt moving at a constant speed.
• High connector density. “First / second / however / therefore / in summary”, or “Moreover / Furthermore / However”, show up constantly. Logical relations are labeled explicitly instead of being carried by meaning.
• Piles of abstract nouns. Words like capability, value, closed loop, ecosystem, dimension and layer replace concrete actions and objects, which dilutes information density.
• Three-part structure and symmetry habits. Paragraphs almost always follow a “general-specific-general” shape. Contrastive patterns such as “not A, but B” and “not only … but also …” are favorites, and paragraphs often close with three parallel items.
• Missing, unverifiable detail. There are few specific numbers, dates, versions, boundary conditions or failure cases. Conclusions stay at the level of “usually”, “often” and “in most cases”.
• Flat tone and vague stance. Almost no preference is expressed, no difficulty is acknowledged and no trade-off is recommended. You finish reading without knowing where the author stands.

2. Root causes: why models are “flavored” by default

Understanding the cause tells you which stage the rules should act on.

1. A side effect of the training objective. A language model maximizes the probability of the next token, which is equivalent to pushing output toward high-probability, low-surprise phrasing. The “safest” wording wins, while idiosyncratic, risky and colloquial expression is systematically suppressed.
2. The direction of preference alignment. Alignment from human feedback usually rewards answers that are “clearly structured, polite and comprehensive”, which amplifies boilerplate and disclaimer-style phrasing even further.
3. The smoothing effect of decoding parameters. A low sampling temperature and a small candidate set compress lexical variety and make repeated structures more likely.
4. No anchor in personal corpus. The model does not know who “you” are, who the text is written for, or what tone is acceptable, so it falls back to generic written language.

The conclusion: de-flavoring should not rely on a brute-force “second rewrite” pass after generation, because that easily causes factual drift. Inject the constraints at generation time instead, so the model produces text close to the target style in one pass.

3. Modeling heuristics as a rule library

The community circulates about twenty such heuristics, and most of them are experiential judgments of the form “don’t write like this”. The key engineering step is to give every rule metadata so it becomes an object that machines can load, grade and evaluate.

3.1 Structure of a rule entry (illustrative)

{
  "id": "S-014",
  "layer": "structure",
  "scope": ["zh", "en"],
  "severity": "soft",
  "statement": "Control sentence-length variance; do not write three consecutive sentences of near-equal length",
  "detect": "sentence_length_stdev < 6 over 5 consecutive sentences",
  "fix": "Split or merge sentences, and insert a short sentence (for example, under 8 characters in Chinese) as a rhythm break",
  "counter_example": "The system offers complete capabilities, delivers stable service and meets every requirement.",
  "example": "The service exposes three endpoints. The auth endpoint is the easiest to misuse, because its default timeout is only 3 seconds."
}

severity sets the strength of the constraint: hard for outright bans (such as inventing data or fabricating citations), soft for style preferences (such as sentence-length rhythm), and hint for optional suggestions (such as moderate use of the first person). layer supports tiered management so the rule list does not turn into an unmaintainable flat list.

3.2 Five layers of rules

• Structure layer. Paragraph-length variance, no boilerplate openings, no information-free summaries at the end, and uneven heading depth is allowed.
• Lexicon layer. Maintain banned and restricted word lists, require abstract nouns to be replaced with concrete verbs and objects, and require proper nouns, version numbers and parameter values to be verifiable.
• Semantic layer. Information-density constraints (at least one verifiable fact per 100 characters) and uncertainty constraints (distinguish “verified” from “inferred”).
• Rhetoric layer. Limit metaphor density (no more than one per document), ban stacked parallelism, and ban exclamation marks and emotional emphasis.
• Pragmatics layer. Require a clear stance and explicit trade-offs, allow admission of difficulty and limits, and ban ingratiating openings such as “That’s a great question”.

3.3 Rule conflicts and priority resolution

De-flavoring conflicts with accuracy. The most typical failure mode is inventing details to satisfy an information-density rule. Fix the priority in this order:

factual correctness > logical consistency > actionability > style features > rhetorical preference

No style rule may trigger a relaxation at the fact level. Writing this priority chain explicitly in the prompt noticeably reduces the chance that the model “makes up a story in order to sound human”.

4. Bilingual implementation: the “flavor” differs between Chinese and English

This is why many single-language guidelines fail. Language-agnostic rules (sentence-length variance, information density, fact-first priority) can be shared, but word lists and sentence-pattern bans have to be maintained per language.

• Frequent Chinese-side features: piling up four-character idioms and set phrases, absolute-sounding parallelism, jargon such as “empowerment / grip point / closed loop / granularity”, forced “not … but …” contrasts, closings built on “in summary” or “in a word”, overuse of the em dash, and nested modifiers produced by chains of “de” (的) structures.
• Frequent English-side features: inserting explanatory clauses between em dashes, overused words such as “delve into / landscape / tapestry / testament to”, sentence-initial “It’s not just X, it’s Y” constructions, sweeping era-level background at the opening, and closing with three parallel items that elevate the point.

In practice, organize the asset as “core guidelines + language packs”. The core file holds only language-agnostic constraints, while each language pack supplies three kinds of data: banned_phrases, preferred_alternatives and sentence_pattern_rules. That makes it easy to review each pack separately and update it incrementally.

5. Loading it as a reusable asset

This kind of guideline works best as a “skill package”: a document with metadata, plus layered rule files and an example library, loaded on demand by an AI coding assistant or a conversational development environment. The key is controlling the context budget. Do not stuff every rule into the prompt at once; use progressive disclosure instead.

name: bilingual-de-ai-style
description: >
  Use when writing Chinese or English technical documentation, blog posts or explanatory material.
  Removes templated phrasing, boilerplate and low-information paragraphs
  according to layered writing constraints.
  Not suitable for scenarios that require strict official document formats or legal clauses.
version: 1.3.0
entry: rules/core.zh.md
languages:
  - zh: rules/zh-pack.yaml
  - en: rules/en-pack.yaml
budget:
  max_tokens_on_load: 1200
  lazy_sections: [rhetoric, pragmatics]

On load, only core and the current language pack are injected; the rhetoric and pragmatics sections are read by the model only when needed. Together with an example set of 10 to 20 contrasting good and bad cases, the model can calibrate its style within a very short context, without depending on a long list of prohibitions.

In Baidu AI Cloud model services, the same asset can be injected directly as a system prompt plus rule files, with no changes to application code. It is also easy to configure per team and per scenario, and to roll back to a previous version.

6. Quantified acceptance: make “de-flavoring” measurable

Without acceptance criteria, a guideline degrades into personal preference. Land at least these four automatically computable metrics:

• Sentence-length standard deviation. A value that is too low signals monotonous rhythm.
• Connector density. The number of explicit logical connectors per 100 characters. A value that is too high means the structure is over-annotated.
• Banned-phrase hit rate. Match against the word lists in the language pack. The rate should approach zero.
• Concrete-information ratio. The share of concrete tokens (numbers, proper nouns, code identifiers, version numbers) among content words. A value that is too low means the content is vague.

def metrics(text):
    sents = split_sentences(text)
    lens = [len(s) for s in sents]
    return {
        "sentence_len_stdev": stdev(lens),
        "connector_per_100": count_connectors(text) / len(text) * 100,
        "banned_hit": match_banned(text),
        "concrete_ratio": count_concrete_tokens(text) / count_content_words(text),
    }

Wire these four metrics into a regression example set and run them after every change to the rule files. That shows at a glance whether a given ban has side effects, for example when information density passes but the sentences become stiff and choppy.

7. Five common mistakes

1. Synonym replacement instead of rewriting. Swapping “empower” for “assist” leaves the flavor intact. Real de-flavoring changes the information structure: object, action, condition and result.
2. Overdoing casualness. Adding filler particles, typos and off-the-cuff asides only turns “AI flavor” into “cheap filler flavor”. The target is credible professional speech, not chat-room talk.
3. Brute-force post-processing. Removing flavor with a second rewrite pass easily loses numbers and qualifiers. Constraints belong before generation.
4. Unbounded rule growth. The longer the list, the lower the model’s compliance. Keeping it under 30 rules and lazy-loading them by layer usually beats a hundred rules laid out flat.
5. Ignoring genre differences. The bar for “human feel” is not the same in technical documentation, internal status reports and product descriptions. Ship switchable style profiles (formal / neutral / casual) instead of one profile for everything.

8. Recommendations

Treat the rule files like code: put them under version control, put them through code review, give every rule a set of positive and negative examples, and validate them periodically with the regression example set. A guideline shared by the whole team is what makes output from different people and different models stylistically consistent, and what turns “removing the AI flavor” from personal instinct into a transferable engineering capability.