Write

Write: Cut the AI Taste

Prefix your first line with 🥷 inline, not as its own paragraph.

Update check (non-blocking). Before starting, run bash ../../scripts/check-update.sh once; if it prints a line, relay it to the user, then continue. It runs at most once a day, only reads a public version file, sends no data, and fails silently.

Strip AI patterns from prose and rewrite it to sound human. Do not improve vocabulary; remove the performance of improvement.

Outcome Contract

• Outcome: the prose preserves the author's intent while sounding natural for its audience and surface.
• Done when: meaning, factual claims, and structure are preserved unless the user asked to change them, and AI-like wording is removed.
• Evidence: supplied text, target audience, project style references, release or product state, and requested language.
• Output: the edited prose only, unless the user asked for notes, variants, or review comments.

Core Stance

This skill is a catalog of smells, not a checklist to run top to bottom. Use it to recognize AI taste, then make judgment calls. The reference files (especially write-zh.md) are long because they accumulated examples over many sessions; do not try to apply every rule to every text. Applying more rules is not doing a better job.

• Over-editing is failure, equal to under-editing. If a sentence is already natural, clear, and stable, leave it. Most polish is subtraction (cut repetition, summary-tone, restated conclusions), not phrase-by-phrase replacement.
• The author's voice wins. Keep the author's existing colloquial words, cadence, and stance. When a rule conflicts with a deliberate authorial or genre choice (a question title in a narrative piece, a list the author wants kept), the author wins. Rules are defaults, not laws.
• Banned-phrase lists and replacement tables are examples, not find-and-replace. A flagged word that reads naturally in context stays. Match the smell, not the string.
• Prefer fewer, stronger edits. Three changes that matter beat thirty mechanical swaps that flatten the voice.

When distilling a new lesson into this skill, fold it into an existing principle instead of appending another banned phrase. This skill must not grow monotonically; collapsing specifics back into principles is part of maintaining it.

Pre-flight

1. Text present? If the user gave only an instruction with no actual prose to edit, ask for the text in one sentence. Do not proceed. 2. Audience locked? If the intended audience is unclear and cannot be inferred from the text (blog reader vs RFC vs email), ask before editing. Junior engineer and senior architect prose should read completely different. 3. Language detected from the text being edited, not the user's command:

• Contains Chinese characters + release notes or social post mode → load references/write-zh-release-notes.md
• Contains Chinese characters + bilingual or translation review → load references/write-zh-bilingual.md
• Product/site/app localization review across multiple locales → load references/write-product-localization.md; also load references/write-zh-bilingual.md when Chinese copy is present
• Contains Chinese characters (default prose) → load references/write-zh-prose.md (quick rules); load references/write-zh.md for the full AI-taste pattern catalog
• Otherwise → load references/write-en.md

Read the loaded reference file. Then edit. No summary, no commentary, no explanation of changes unless explicitly asked.

Durable Context Preflight

See rules/durable-context.md for when to read durable context, the read-order budget, and the memory-type mapping.

For /write, voice and format constraints are decision, preference, and principle entries; editing checks are pattern and learning. The supplied text, audience, project docs, current release state, and source material override memory. Durable preferences can set brevity, tone, and social-post shape. They do not override the hard rule to edit in place, keep meaning intact, and avoid change lists unless the user explicitly asks.

Hard Rules

• Meaning first, style second. If removing an AI pattern would change the author's intended meaning, keep the original.
• No silent restructuring. Do not reorganize headings, reorder paragraphs, or merge sections unless structural changes are explicitly requested. Edit in place. (Exception: Long-form Article Mode treats structural cuts and merges as in-scope, since structure is the main problem there; it still proposes them as change-points first instead of doing them silently.)
• Artifact-grounded claims. For launch copy, release notes, social posts, product pages, and public replies, ground factual claims in real source material: current app behavior, runnable artifact, screenshot, product page, release page, changelog, issue/PR, or user-provided draft. Do not present handoffs, plans, old memory, or stale screenshots as current product truth, and do not turn concrete product evidence into generic marketing language.
• No em-dash. Never produce em-dash (U+2014 —) or en-dash (U+2013 –) in Chinese or English output. Em-dash is the strongest AI-tone fingerprint in this style of writing. Use commas, periods, colons, semicolons, or parentheses to break clauses. Hyphen-minus (-) inside compound words is allowed; replace it with a space or a period when possible. When editing a draft that contains em-dashes, replace every one before returning the text.
• Stop after output. Deliver the rewritten text. Do not append a list of changes, a justification, or a closer. (Exception: Long-form Article Mode returns change-points for review instead of a rewritten blob; see that mode.)

Long-form Article Mode

Activate when: editing a Markdown article or file over ~300 lines, or one with multiple ## sections plus tables and images (technical long-reads, blog posts, deep dives).

In long-form, the dominant problem is usually structural: the same checklist repeated across sections, prose that re-reads a table sitting right above it, list bloat, whole redundant sections. Sentence-level AI taste is the smaller half. A single in-place polish pass cannot see or fix the structural half, which is why a plain /write on a long article feels like it changed wording but left the bloat. This mode therefore overrides two Hard Rules: structural cuts and merges are in-scope, and the output is change-points for review, not a rewritten blob.

Workflow:

1. Map first, read-only. Before editing anything, read the whole article and list every ## section, table, list, and image. Flag three structural problems: cross-section repetition (same checklist / judgment list / core claim in 2+ sections), table re-reading (a section whose prose walks the rows of the table above it), and whole redundant sections or paragraphs. 2. Propose cuts as change-points. Show before to after for each structural cut or merge and let the user pick the subset. Never delete a whole section or paragraph silently; confirm first, since it may hold a fact found nowhere else (see references/write-zh.md 删段之前先确认信息量). 3. Then line-level de-AI, section by section, per references/write-zh.md. 4. Output is change-points, not a blob. Show what changed so the user can review and keep their own hand-edits. Only return fully rewritten text when the user says 直接改 / just rewrite.

Do not single-pass rewrite a 40k-character article: it silently overwrites the author's hand-tuned phrasing and cannot be reviewed as a diff. See references/write-zh.md 结构级重复与表格复读（长文专项）for the matching content rules.

Bilingual Review Mode

Activate when: mixed Chinese/English, "Chinese copywriting", "bilingual consistency", "release notes"

Chinese rules (from https://github.com/mzlogin/chinese-copywriting-guidelines):

• Space between Chinese and English characters (CN文字EN → CN 文字 EN)
• No mixing of punctuation (Chinese uses 、。？！；：, not commas/periods)
• Consistent terminology across all instances

English in Chinese documents: Flag unexplained English, suggest translation or add context.

Bilingual pairs: Confirm EN and CN versions convey the same meaning; mark translation loss.

Product Localization Review Mode

Activate when: "本地化文案", "多语言文案", "localization copy", "i18n copy", product/site/app strings, release feed copy, runtime catalog, or a user asks whether localized copy feels native.

Load references/write-product-localization.md. If Chinese is one of the locales, also load references/write-zh-bilingual.md.

Default workflow:

1. Separate surfaces first: release feed, website pages, docs/help, runtime strings, legal/privacy copy, and generated pages may have different locale coverage and source files. 2. Preserve factual structure: versions, dates, links, item order, placeholders, and product behavior remain fixed unless the user asks to change them. 3. Review by locale artifacts, not by English meaning alone. Missing accents, ASCII fallbacks, literal possessives, stale locale paths, and mechanical plural or apostrophe errors are first-class issues. 4. After broad cleanup, run a second pass for replacement damage. Do not trust accent sweeps or glossary replacements until the generated output has been checked. 5. When asked to implement, patch the source localization files and rebuild generated pages. When asked only to review, return findings grouped by surface and severity.

Release Note Template Mode

Activate when: "release", "changelog", "version", "release notes"

Generate from commit messages:

• Breaking Changes
• New Features
• Fixes & Improvements
• Deprecations

Format: target-project style by default. If no project style is available, use numbered items with bold labels, one sentence on user effect, and bilingual output only when the project already uses bilingual release notes.

Release Notes Pre-flight

Before drafting, gather style references:

1. Read the target project's CLAUDE.md for its Release Convention / Release Flow section. 2. Read the target project's existing release source as a style, length, and density reference: changelog, release notes, registry page, update feed, or platform release page. 3. For GitHub projects, gh release view --json body -R <owner>/<repo> is the preferred way to read the most recent release when gh is available. If the project is not on GitHub, use the release source named by the project docs or user request. 4. If the user mentions comparing with a sibling project's release style, ask for the target identifier or release URL before fetching it. 5. Match the reference release's item count, sentence length, and tone. Do not invent a new format. 6. Keep each release-note item to one sentence unless the reference project clearly does otherwise. Do not add emoji to release prose unless the target surface is explicitly a reaction or celebratory social surface.

Release Notes Content Rules

• Group by user-perceivable feature, not by internal taxonomy. "Polish", "细节打磨", "Misc improvements", "Chores" are not categories users can act on. Group by product surface (Clean / Uninstall / Status / Settings) or by user-visible verb (Faster startup / New keyboard shortcut / Fixed crash on M3).
• Extract from `git log <last-tag>..HEAD` rather than from memory. Read every feat: and fix: commit; do not omit small items just because they look minor in commit form (iOS wrapper support, Dock cleanup, AV-vendor protection boundary are not "minor" from a user point of view).
• One sentence per item, naming the user-visible change, not the implementation. "Use CKDownloadQueue observer for App Store updates" is not a release note; "App Store updates now run inside the app instead of opening App Store" is.
• Bilingual structure: when the project ships bilingual release notes, put the English block and the Chinese block as two parallel sections inside the same release item; do not interleave per bullet. For HTML-capable update-feed CDATA, separate language blocks with headings so the rendered update window does not collapse them together.
• No em-dash in release prose (covered by the Hard Rule). Use Chinese full-width punctuation in Chinese blocks, ASCII in English blocks.

Public Reply Mode (GitHub issue / PR)

Activate when: "回复 issue", "reply to PR", "comment on #N", "回 issue", or the user asks for the text of a GitHub issue / PR comment.

Five hard rules for the reply body:

1. Open with `@<reporter>` + one thanks line. Match the reporter's language (Chinese → "感谢反馈" / English → "thanks for the detailed report"). No exclamation mark. No emoji. No "🙏". 2. Then state the cause in one sentence, the impact in one sentence. No multi-paragraph background, no internal symbol names, no walk-through of the fix. 3. Then state the ship state, exactly one of: already shipped in v<X.Y.Z>, fixed on main and going out in the next release, planned for v<X.Y.Z>, not planned (with one-line reason and an alternative path). Do not write "already shipped" without release evidence in the current turn. 4. Two paragraphs maximum, separated by one blank line. No bullet lists, no section headers, no code blocks except a one-line command when actually needed. 5. No em-dash. Use commas, periods, colons. (Covered by the Hard Rule, surfaced again because issue replies attract this pattern.)

The reply is the final user-facing text, not an agent log. Do not write "刚才我判断错了", "前面回复有误", "I re-read it and changed the comment", or any meta narration about your own process. If editing an existing maintainer comment, replace it with the clean final wording as if it were the only comment the user will read.

Before posting, re-read the live issue / PR with gh issue view <num> or gh pr view <num>. Do not reply from memory; titles, states, and author languages change between sessions.

For paid / subscribed users, acknowledge the purchase relationship and the inconvenience in one phrase, then state the boundary. Do not over-explain. When the current product cannot support their setup, suggest the safest practical path (upgrade macOS, wait for the next release, provide logs, refund route) without arguing.

Closing rule: when closing as completed, the comment must independently explain what was fixed and the expected release. When closing as not planned, the comment must independently explain the current boundary and an alternative path. Do not rely on prior thread context as the explanation.

Document Review Mode

Activate when: PDF, document, white paper, "review this document", "check this document", "审稿"

Review checklist:

• Privacy scan: Detect PII (names, companies, employment dates, salary hints, location details). Hard stop if any text implies job seeking, competitor info, or personal data leakage.
• Tone consistency: Flag voice shifts, register mismatches, formulaic phrasing. Check for AI patterns using the loaded write-zh.md or write-en.md rules.
• Bilingual validation: For CN/EN pairs, confirm translation accuracy and terminology consistency. Apply Bilingual Review Mode rules.
• Rendering check: Placeholder text remaining (Lorem ipsum, TODO, [TBD]), broken image links.
• Durable-doc scan: If the document is a review report, scorecard, or diagnostic snapshot, flag dated claims, stale line references, private paths, repo-specific commands, and current-score framing. Recommend extracting stable rules instead of preserving the snapshot as evergreen guidance.

Output format: same as prose rewrite, but append privacy: clear / N issues found after the reviewed text.

Paragraph Coherence Mode

Activate when: "连贯性", "段落连贯", "可读性", "coherence", "flow check", "段落顺不顺"

Do not rewrite. Instead, work through each paragraph in sequence: 1. Flag transitions that abruptly shift topic without a signal. 2. Flag paragraphs where the opening sentence does not follow from the previous paragraph's close. 3. Flag rhythm issues: monotone sentence length (all short or all long across a whole paragraph). 4. Suggest the minimal fix for each: one word, one reordered clause, one bridging sentence.

Output: a numbered list of issues, each with the paragraph location and a one-line fix suggestion. Then ask if the user wants any applied.

Tweet / Social Post Mode

Activate when: "推特", "twitter", "X推文", "tweet", "social post", "折叠长度", "长文推特", "发文"

Apply the five announcement rules for product-engineer projects when the project context or prior artifact shows this style: 1. Lead with community: open with the social anchor (star count, user thanks, whose feedback drove the fix). Changes follow, not lead. 2. Highlights over completeness: pick 2 to 4 of the most interesting changes. Dropping whole items is fine. 3. UX framing: phrase each point as "你用它的时候..." or "有一种...的感觉", not "这个工具做了...". 4. One stance: include at least one opinionated sentence revealing why decisions were made. 5. Native Chinese rhythm: use idiomatic phrasing. Avoid translation-sounding terms.

Close casually with an invitation, not a CTA. End with one short sentence inviting readers to try, not "立即升级".

For other engineering projects or English posts, apply the same structure (community lead, highlights, UX framing, one stance, casual close) adapted to the project's voice.

Gotchas

Output

Return only the edited prose. If the text was truncated or if multiple versions were possible, note that in one sentence after the body. Otherwise, no wrapper, no preamble, no postscript.

How to use this file: it is a catalog of smells, not a checklist to run top to bottom. The principles in SKILL.md Core Stance apply here too: over-editing is failure, the author's voice and genre win, and these lists are examples, not find-and-replace. A sentence that already reads natural stays. Match the smell, not the word.

English Scenario

Eliminate predictable AI writing patterns. Write like a human: varied, imperfect, specific.

Core Rules

1. Cut filler phrases. Remove throat-clearing openers, emphasis crutches, and adverbs that only signal emphasis. Keep adverbs that carry real meaning. 2. Break formulaic structures. Avoid binary contrasts, negative listings, dramatic fragmentation, rhetorical setups, false agency. 3. Use active voice. Every sentence needs a human subject doing something. No inanimate objects performing human actions ("the complaint becomes a fix"). 4. Be specific. No vague declaratives ("The reasons are structural"). Name the specific thing. No lazy extremes ("every," "always," "never") doing vague work. 5. Put the reader in the room. No narrator-from-a-distance voice. "You" beats "People." Specifics beat abstractions. 6. Vary rhythm. Mix sentence lengths. Two items beat three. End paragraphs differently. No em dashes. 7. Trust readers. State facts directly. Skip softening, justification, hand-holding. 8. Cut quotables. If it sounds like a pull-quote, rewrite it. 9. Do not replace one formula with another. “Human” does not mean slangy, quirky, or performatively casual. 10. No emoji. Remove any emoji from the text being edited.

Word Choice

Examples, not exhaustive -- any word used to signal importance rather than to say something is suspect.

Overused emphasis adverbs (cut these when they only signal importance, not every adverb): "quietly", "deeply", "fundamentally", "remarkably", "arguably", "certainly", "really", "just", "literally", "genuinely", "honestly", "simply", "actually"

NO: "quietly orchestrating workflows" / "fundamentally reshape how we think"

OK: Say what it does. Drop the adverb.

AI vocabulary: replace with plain language:

Pompous copulas: use "is" instead:

NO: "serves as", "stands as", "marks", "represents"

OK: "is"

Sentence Structures to Avoid

Examples, not exhaustive -- any construction that performs insight rather than delivers it belongs here.

Negative parallelism: the single most common AI tell:

NO: "It's not bold. It's backwards." / "Not because X, but because Y." / "The question isn't X. The question is Y."

OK: State Y directly. Drop the negation entirely.

Negative countdown:

NO: "Not a bug. Not a feature. A fundamental design flaw."

OK: "It's a fundamental design flaw."

Rhetorical self-questions:

NO: "The result? Devastating." / "The worst part? Nobody saw it coming."

OK: State it: "The result was devastating."

Anaphora abuse: repeating the same sentence opener:

NO: "They assume that... They assume that... They assume that..."

OK: Combine or restructure. One statement, clear subject.

Tricolon abuse: rule of three, used three times back to back:

NO: "Products impress people; platforms empower them. Products solve problems; platforms create worlds."

OK: Make the point once, cleanly.

False ranges:

NO: "From innovation to cultural transformation" (what's in between?)

OK: List the two things directly, or pick one.

Dramatic fragmentation: manufactured emphasis via fragments:

NO: "He published this. Openly. In a book. As a priest."

OK: Complete sentences. Trust content over presentation.

False agency: inanimate objects performing human verbs:

NO: "the complaint becomes a fix" / "the decision emerges" / "the data tells us"

OK: Name the human. "Someone fixed it." "The team decided."

Tone Patterns to Avoid

False suspense transitions:

NO: "Here's the kicker." / "Here's the thing." / "Here's where it gets interesting."

OK: Make the point. No buildup.

Patronizing analogies:

NO: "Think of it like a highway system for data." / "Think of it as a Swiss Army knife."

OK: Explain the concept directly. If an analogy helps, test it against three criteria before keeping it: (1) remove it and the paragraph collapses: it is load-bearing, not decorative; (2) push it one layer deeper and it still holds; (3) the reader gets it without further explanation. If it fails any of these, drop the analogy and state the idea directly.

Futurist invitation:

NO: "Imagine a world where every tool you use has a quiet intelligence behind it..."

OK: Describe what actually exists or what you're actually proposing.

False vulnerability: performative self-awareness:

NO: "And yes, I'm openly in love with the platform model"

OK: Real vulnerability is specific and uncomfortable. Skip the polish.

Asserting simplicity instead of proving it:

NO: "The reality is simpler and less flattering" / "History is clear"

OK: Show the evidence. Don't announce the conclusion before it.

Grandiose stakes inflation:

NO: "This will fundamentally reshape how we think about everything." / "will define the next era of computing"

OK: Say what it actually does.

Pedagogical hand-holding:

NO: "Let's break this down step by step." / "Let's unpack what this really means."

OK: Start with the content, not an announcement of the content.

Vague attributions:

NO: "Experts argue..." / "Industry reports suggest..." / "Observers have cited..."

OK: Name the expert, link the report, quote the person. If you can't, you don't have a source.

Invented concept labels: compound labels that sound analytical but aren't grounded:

NO: "the supervision paradox" / "the acceleration trap" / "workload creep"

OK: Describe the thing directly. Don't name it as if it's an established term.

Paragraph & Composition Patterns to Avoid

Short punchy fragments as paragraphs:

NO: "These weren't just products. And the software side matched. Then it professionalised."

OK: Complete sentences. No staccato drama.

Bold-first bullets: every bullet starts with a bolded phrase:

NO: "Security: Environment-based configuration..." / "Performance: Lazy loading..."

OK: Write bullets as sentences, or drop the bold. Not every list needs labels.

Fractal summaries: "what I'm going to tell you; what I'm telling you; what I just told you":

NO: "In this section, we'll explore... [3000 words later] ...as we've seen in this section."

OK: Skip the preview and the recap. Write the content.

Exception: a single closing sentence in a TL;DR that orients non-specialist readers to the structure ahead ("The rest of this piece follows X in order...") is intentional navigation, not a fractal summary. Keep it; flag it at most, but do not delete without author approval.

Signposted conclusions:

NO: "In conclusion..." / "To sum up..." / "In summary..."

OK: End. Don't announce that you're ending.

The dead metaphor: one metaphor used 10 times across a piece:

NO: "The ecosystem needs ecosystems to build ecosystem value."

OK: Use a metaphor once, then move on.

Historical analogy stacking:

NO: "Apple didn't build Uber. Facebook didn't build Spotify. Stripe didn't build Shopify."

OK: Make the point. One example is enough.

One-point dilution: same argument restated 10 ways across 4000 words:

OK: Say it once. Add evidence or move on.

"Despite its challenges..." formula:

NO: "Despite these challenges, the initiative continues to thrive."

OK: Either address the challenges or don't raise them.

It's worth noting / It bears mentioning:

NO: "It's worth noting that this approach has limitations." / "Notably," / "Importantly,"

OK: Say the thing directly. Skip the announcement.

Meta figure and diagram explanations:

NO: "This diagram lists the sensor stack of a humanoid robot. With it in view, the previous problems become easier to place."

NO: "I made this diagram with ChatGPT Image2. Seeing the representations side by side makes the differences easier to grasp."

NO: "This timeline shows the evolution... That is one of the reasons I find this field more interesting..."

OK: The image or timeline itself. Let the surrounding judgment or personal project anchor carry the weight. Keep creation-process details only if they are themselves part of the story.

List or classification intros:

NO: "Community data is an interesting piece. Diversity has to cover..."

NO: "One detail is easy to miss. 'Output action' can mean..."

OK: Go straight to the content: "Community data has a practical requirement: diversity has to cover..." or "Output action can mean different things..."

Re-anchoring after cutting recaps (long-form articles): After removing table re-reads and structural repetition, scan the remaining prose for places where a general explanation can be tied back to the author's concrete project or experience already mentioned in the piece. This is one of the strongest ways to restore human voice in technical long-form writing.

Quick Checks Before Delivering Prose

• Any adverb only adding emphasis? Cut it. (Meaning-bearing adverbs stay.)
• Any passive voice? Find the actor, make them the subject.
• Inanimate thing doing a human verb? Name the person.
• Sentence starts with "Here's"? Cut to the point.
• Any "not X, it's Y" contrasts? State Y directly.
• Three consecutive sentences match length? Break one.
• Paragraph ends with punchy one-liner? Vary it.
• Em-dash anywhere? Remove it.
• Vague declarative ("The implications are significant")? Name the specific implication.
• Meta-joiners ("The rest of this essay...")? Delete. Exception: a single TL;DR closing sentence that orients readers to the structure ahead is navigation, not filler. Keep it.
• Any bullet starting with bold label? Reconsider the format.
• Any "In conclusion" or "To sum up"? Cut it.
• Any emoji? Remove it.

---

Bottom line: varied, imperfect, specific. Any single trope used once may be fine. The problem is when multiple appear together or one repeats.

Product Localization Copy Review

Use this when reviewing product pages, release notes, app strings, runtime notifications, appcast or update feeds, docs/help pages, legal/privacy copy, and other localized product surfaces.

Core Principles

1. Split surfaces before editing. A release feed, website page, runtime catalog, help article, and legal page may intentionally support different locale sets. Do not force every surface to mirror the broadest one. 2. Keep product facts fixed. Preserve versions, dates, item order, links, placeholders, keyboard shortcuts, product names, bundle IDs, and behavior claims unless the user asked to change them. 3. Use source files, not generated output, as the edit target. Patch generated pages only when the project explicitly treats them as source. Otherwise find the template, locale JSON, string catalog, or content partial and rebuild. 4. Review the final rendered or generated surface. A translation can look fine in a source file but break in a button, menu, release feed, notification, or generated HTML page. 5. Do not polish into generic marketing. Native localization means the sentence sounds like a local product, not like a fluent sales page.

High-Signal Failure Patterns

• Chinese: Literal possessives such as "你的 Mac" or "你的设备" when plain "Mac" or "本机" is enough; machine-output verbs such as "检测到" when a result sentence would read better; mixed punctuation; English words with stable Chinese equivalents.
• Traditional Chinese: Mainland phrasing copied into Traditional copy; stale locale URLs; words that feel mainland-specific or overly colloquial for the target audience.
• Japanese: English noun compounds translated too tightly; missing spaces around product terms when the project style uses them; UI strings that sound like a manual instead of a Mac app.
• Korean: Inconsistent platform terms, especially menu bar / menu item wording; overly literal second-person sentences.
• German: ASCII fallbacks such as fuer, Pruef, Eintraege, Menue, Luefter; English developer nouns like "binary" in user-facing copy.
• Spanish: Missing accents such as gestion, analisis, menus, suscripcion; mechanical replacements that create invalid forms like actualizaciónes.
• French: Missing apostrophes or accents such as L app, memoire, desinstallation, defaut; spaces before punctuation should follow French conventions when the surrounding text already does.
• Italian: Missing accents and articles such as piu, non e, un app; mechanical replacements that create invalid forms like puòi.

Review Procedure

1. Identify all source and generated surfaces in scope. For websites, include templates, locale JSON, content partials, generated pages, language switchers, canonical links, and route rewrites. For apps, include runtime catalogs, permission strings, update feeds, and notification copy. 2. Pick the factual source of truth. Release notes usually follow the English release page or changelog; runtime copy follows the current app behavior and placeholders. 3. Run a first pass for local voice: remove translationese, restore local punctuation, and keep product names stable. 4. Run a second pass for mechanical artifacts: missing accents, stale paths, invalid plural forms, malformed placeholders, and accidental path translations. 5. Rebuild generated files and rerun the relevant project checks. If the user only asked for review, list the required checks instead of claiming they ran.

Rewrite Rules

• Keep placeholders exactly, including order and type: %@, %d, %1$@, {name}, and similar tokens.
• Do not glue translated fragments with punctuation in code or copy. A full sentence or format string per locale is safer.
• Avoid broad find-and-replace unless it is followed by residual scans. Broad accent fixes can produce broken words.
• Leave product names and established UI names in English when the product itself uses them that way.
• Legal and privacy copy should be plain and accurate. Do not make it friendlier by weakening obligations, data collection boundaries, refund terms, or third-party roles.
• Release feed localization can be narrower than website localization. Respect the surface-specific product decision.

Output Guidance

For rewrite requests, return the edited localized copy. For review requests, group findings by surface first, then locale. Call out blockers where copy misstates product behavior, privacy, legal terms, version history, or update availability.

中英双语规则

双语一致性检查

中英混排格式（来自 mzlogin/chinese-copywriting-guidelines）：

• 中文和英文字符之间加空格：CN文字EN → CN 文字 EN
• 不混用标点：中文用 、。？！；：，不用英文逗号/句号
• 术语跨全文一致

中文里的英文：标记出现的未翻译英文，建议翻译或加说明。

双语对：确认 EN 和 CN 版本传达的意思相同；标记翻译损失。

英文术语首次出现规则

• 首次出现：保留英文 + 中文注解，或中文前置 + 英文括注（指令微调（Instruction tuning））
• 后续出现：只用中文，不要英中混用
• 例外：SFT、RL、MoE 这类已成行业通用缩写，全程保留缩写形式

有稳定中文对译的英文词

中文技术圈已有通用译法的，换中文：

术语在中文圈还未收敛的（prompt、embedding、tokenizer），保留英文合理。

翻译腔套路（主动排查）

物理动作动词：接住、击穿、锋利、不崩、不爆、打穿、扛住，这类词把抽象认知过程想象成了物理动作（骨架是英文 catch/pierce/sharp）。换成日常中文：你这几条我都收到了 / 这个假设不成立。

形容词预判+冒号："更干净："、"逻辑很清晰："引出内容。删掉形容词，只留后面事实。

抽象名词做主语："工程上的现实比这些数字难看"这种骨架，凡碰到"X 的 Y 比 Z 更 W"，重写让人/动作做主语。

有稳定对译词直接混入："context 不崩、state 可恢复"，换成中文。

双语并列的排版

中英双语 release notes 的排版：

• 英文版在前，中文版在后（或分两个段落）
• 条目编号一一对应
• 专有名词（产品名、功能名）在两种语言里保持一致
• 不要在同一条内中英混写

标点规则

• 中文标点：，。；：！？、""『』【】
• 英文在中文句子中出现时用中文标点断句
• 禁止用破折号（—），用逗号或分号替代
• bold 小标题 + 句号 改为 bold 小标题 + 逗号（内联而非独立标题）

中文散文核心规则

技术长文的去 AI 味和自然化。完整规则见 write-zh.md，本文摘录最高频的 10 类改写模式。

最高优先级：保语义 > 去 AI 味

先确认事实、逻辑、因果不变，再做以下改写。如果为"更口语"改坏原意，属于失败改写。

高频 AI 痕迹（首先检查）

1. 段末收尾总结句：一段刚解释完某机制，结尾再重述一遍。识别信号："到这里"、"这说明"、"这本身就是"、"可以看出"开头，或者段落最后一句比其他句短且抽象。直接删掉。

2. 升华句：把具体工程观察上升到普适人生道理。直接给出具体建议，不升华。

3. 对比句式："不是…而是…"、"X 本身没有价值，真正有用的是 Y"、"X 已经不是瓶颈，Y 才是"。直接说结论，不用对比框架铺垫。

4. bold 小标题模式：**xxx**。content 改为 **xxx**，content，让 bold 变成承重词，不是独立小标题。例外：bold 部分本身是完整句子时保留句号。

5. 章节引介过渡句：章节开头或结尾写"上面这些模式解决的是…，下面再看…"。直接删掉，章节标题本身已经承接。

6. 空泛形容词预判："更干净："、"逻辑很清晰："，形容词抢先下判断。删掉形容词，只留后面的事实。

7. 工整并列 bold 标题：四个 bold 标题全是同一格式。每个点语气不同，或改成散文叙述。

8. 段内重复：同一段把同一意思用不同措辞说两遍。说一遍，够了。

9. 讲解腔起手："真拆开看"、"这背后是同一个变化"、"真正关键的问题是"。删掉，直接说。

10. 训人感起手："先问问是不是"、"你要先明白"。改成"可以先看"、"先确认"。

句式规则

• 禁止用破折号（—），用逗号或分号代替
• 四五个句号连发、每句很短 = 打电报，合成长句或用逗号连
• 单独成段的一两句话，多半是上一段的收尾，直接并进去
• 不用"首先…其次…最后"，用"一方面…另一方面…"

用词去正式化

完整规则、AI 味检测所有模式、标题设计、引号/括号/分号规则见 write-zh.md。

长文（多 ## 节、带表格和图）先做结构再抠句子：跨章节同义清单只留最全一份、表格旁正文别复读、判断/取舍类列表默认转 prose，详见 write-zh.md 的「结构级重复与表格复读（长文专项）」，整体流程见 SKILL.md 的 Long-form Article Mode。

对外发文专项：release notes 和推文

推文 / 社交发文五规则

适用于已有社区语气和轻量发布节奏的产品工程师项目对外发文：

1. 社区先行：开头用社会锚点（star 数、感谢用户、谁的反馈推动了这次修复）。改动清单跟在后面，不放在最前。 2. 亮点不全量：挑 2 到 4 个最有意思的改动。跳过整个模块也没问题。读者要的是故事，不是 changelog。 3. 用户感受帧：每条写法用"你用它的时候…"或"有一种…的感觉"，不是"这个工具做了…"。 4. 一条立场：至少一句表明决策原因的意见句（例："我更相信模型本身的能力，而非各种规则限制他的天花板"）。 5. 中文节奏：用地道表达（给留了一手、玩玩、大伙、大概就是这些）。避免翻译腔和正式词（具体判据、主轴、本意）。

结尾用邀请，不用 CTA：「假如没有用过的小伙伴，欢迎去试试看，玩玩。」而不是「立即升级」。

Release Notes 格式

结构：Breaking Changes → New Features → Fixes & Improvements → Deprecations

格式：优先匹配目标项目最近一次 release。没有可用参考时，使用编号列表、bold 标签、一句话说用户效果；只有目标项目已经使用中英双语时才输出双语。

长度参考：和上一个版本 release 的条目数、句子长度、密度匹配。不要自创新格式。

边界：GitHub Release 正文和社交公告是两份 artifact。Release notes 解释用户会感受到什么，默认不写 CI、tap、registry、API 名称、fallback 路径等机制细节；公告另按社交发文规则挑 2 到 4 个亮点。

对外发文专项检查

公开发文交出去之前，扫三件事：

1. 身份和敏感信号脱敏：不出现可反推作者身份的细节（雇主、地点、简历式表述）。技术决策可以具体，身份信息默认删。

2. 不踩竞品：介绍自己产品时不主动贬低同类产品。直接说自己做了什么、为什么。

3. 用户感受先于功能清单：先给一句场景或感受，再进改动细节。不要开场就列功能。

发版前检查

• 不出现"不再更新"、"final release"、"停止维护"等终止信号（除非是真实情况）
• release title 简洁：版本号 + 最核心的改动或主题，不超过 10 个词
• 中英版本条目数一一对应
• 建议 5 到 8 条，每条一句话

怎么用这份文件：它是「认 AI 味」的例子库，不是从头套到尾的检查清单。先用它识味，再凭判断改。自然的句子就别动，过度改和改不到位一样糟。作者已有的声音、口语词和体裁选择，优先于任何单条规则。下面所有禁用词、替换表、形式规则（标题、列表、标点），都是「倾向和例子」，不是查找替换。沉淀新教训时并进已有原则，别再加一条禁用词，这份文件不许只增不减。

中文场景

像资深工程师写技术长文，给同行讲清楚一条链路。自然、准确、不刻意。

执行流程（先后顺序）

按下面顺序改，不要反着来：

1. 先保语义：先确认事实、逻辑、因果都不变。 2. 再去 AI 味：删模板句、删讲解腔、删报告腔。首先检查段末收尾总结句（"这说明"、"到这里"、"可以看出"开头的重述句），这是最高频的 AI 痕迹，优先删。 3. 再顺句子：解决拗口、断句过碎、节奏太硬。 4. 最后调标点：减少不必要的括号、引号和短句句号连发。 5. 术语只在必要处解释：首次出现可注解，后文不重复堆注释。 6. 全文回读一次：优先改卡顿点，不为“更口语”硬改自然句。

最高优先级：自然 > 风格化

不要为了”像人说话”硬塞口语词、情绪词、俚语、感叹词。 一句话如果已经自然、清楚、稳，就不要再往里加”其实 / 说白了 / 哈哈 / 谁能想到 / 我去 / 居然 / 太太太”这类词。

保留作者已用的口语词：如果作者原文已经在用”很”、”其实”、”到底”这类自然词，不要替换成正式词。”最高优先级”是不要主动添加，不是要替换掉已有的。过度去口语化和过度口语化一样糟糕。

默认模式：技术长文

目标不是”更随便”，而是”更自然、更稳”。读起来像人写的，不是像报告，也不是像刻意模仿语音转文字。 技术文默认是工程师对工程师，不是老师训人。少用命令式句子、审问式起手和居高临下语气。

• 可以口语，但不要俚语化
• 减少情绪词、感叹词、口头禅
• 少用”说白了 / 其实 / 你会发现 / 谁能想到”这类推进词
• 优先追求：清楚、稳、具体、节奏自然
• 不要为了去 AI 味，把技术文改得像口播稿
• 如果原句已经自然、准确、清楚，不要为了”更像人”继续改
• 优先做减法：删解释腔、删总结腔、删多余转折，不要把润色做成重写

受众非工程师时的调整：如果文章定位是产品 / 业务 / 运营受众，先去三类词：俯视词（"不懂技术的同学"）、命令腔（"你必须 / 一定要"）、过深术语（"原语 / 未命中 / 非工程团队"）。prose 走"我怎么用，你跟着试"路径，不要"系统梳理 + 框架表格 + 长段分析"。

开头直接

NO: 随着...的发展 OK: 用了不到一个月后 OK: 作为长期用户，我更关心... OK: 这次想把 X 这条链路讲清楚 OK: 先说结论，再展开过程

用词去正式化

口语词慎用，不要靠它们制造“人味”

下面这些词不是禁用，但默认不要主动加进去：

• 太太太
• 居然
• 谁能想到
• 于是乎
• 我去
• 哈哈

好比 只在比喻真的有帮助时偶尔用一次，不要当成固定连接词。

生动化：只在原句读不懂时才换

默认不改。只有原句抽象到读者看不懂意思时，才换成更具体的表达。已经清楚的句子不要为”更形象”硬改。

句式

• 不用"首先...其次...最后"，用"一方面...另一方面..."
• 段落可以长，但要一口气能读完
• 不用强行断句
• 禁止用破折号（双横线），用逗号或分号代替
• 单独成段的一两句话，多半是上一段的收尾或下一段的引子，直接并进去，别让它孤零零
• 四五个句号连发、每句都很短，读起来像在打电报，这时候把几句合成一个长句，或者用逗号连起来
• 少用“先问问是不是 X”“你得先明白”这类起手，容易有训人感，改成“可以先看 X”“先确认 X”
• 分析型技术文里，少用“第一、第二、第三”模板，除非在写操作步骤
• 三个承重点如果关系很紧，优先写成一段自然段，不必强行拆成列表

bold 起手 + 句号 节奏

**xxx**。content 这种「小标题 + 句号 + 解释」起手段落是 AI 模板感的高频源，不论密度，默认换成 `xxx，content`，让 bold 变成句子的承重词，而不是独立小标题。整段读起来是 prose，不是工整 bold 列表。

NO: **alias**。我在 .zshrc 里加了一行...
OK: **alias**，我在 .zshrc 里加了一行...

例外：**xxx** 本身就是一个完整句子（如「能跑不代表安全」、「准不准才重要」），后面跟句号是正常句子结束，不属于"小标题"模式，保留。

判断信号：bold 部分单独看是不是一个能独立成立的句子。是 → 句号；不是（只是个标签 / 短语 / 名词）→ 逗号。

列表去 list 化的渐进策略

技术长文里 bullet 列表过多会显得像 PPT。从 list 走到 prose 的渐进路径：

1. 序号列表 1/2/3 → 改 bullets - xxx（去掉序号感） 2. bullets - **xxx**：content → 改 bold 段落 **xxx**，content（去掉 list marker） 3. 4+ 个 bold 段落 → 合成一个 prose 段落，每项用分号串起来（去掉 visual 切片感）

中间停在哪一步都行，不必一步到底。判断信号：

• 每条都有大段独立解释 → 适合 bold 段落
• 每条 1 句话，关系紧密 → 适合 inline prose 串起来
• 每条是平行规则、读者要扫一眼对照 → 保留 bullets 也行
• 章节标题已经把列表的总结写出来了 → 内容部分尽量 prose 化

序号 1/2/3 留给真正有顺序的：优先级、时间、流程步骤、reference 排序。

默认倾向：判断 / 取舍 / 总结型清单（每条一句、是观点不是步骤）默认转成 prose 段落；速查表 / syllabus（术语密集、读者要逐项对照）和带链接的参考文献保留 list。拿不准时，先转 prose 看读不读得顺。

结构级重复与表格复读（长文专项）

后面 AI 味检测第 3 条「重复核心观点」是段落级。长文还有三类只有把整篇摊开横向比对才看得到的结构水分，单段 in-place 润色检测不到：

• 跨章节同义清单：同一张评估 / 判断 / 取舍清单在 2+ 个 ## 节里各写一遍（比如「评估机器人看动作频率、数据来源、失败处理」在入门、对比、总结三处都出现）。留信息最全的一份，其余删，或后文一句话带过。
• 表格旁正文复读：一节里有对比表，正文却一行行复述表里的列。正文只补表给不了的，里程碑、具体例子、判断、为什么，表能讲清的交给表。
• 图 / 表旁文字复述：紧邻一张图或表的正文，把图 / 表已经列出的项再用文字列一遍，或用「这张图更直观」这类预判句替图说话。删掉复述和预判，留判断和上下文；画图过程只在它本身是叙事时才保留。例外：图的 alt 读者看不到，「图后必要说明段」不算复读，不要删（见图片节奏）。

判断信号：删掉这段 / 这句，读者会不会丢失一个别处没有的事实，不会就是复读，删；会就保留。

标题设计

标题格式三种，看结构选，不是统一用一种。

冒号格式（主题：补充说明）适合：术语首次出现需要解释（ACI：工具是给 Agent 的交互界面）、主题加原则性结论（安全沙箱：边界比功能重要）。

一句话格式适合：副标题只是弱标注、没什么信息量；两部分读起来断裂感强；副标题和主标题意思重复。

NO: 幻觉放大：多 Agent 特有的坑（"特有的坑"是弱标注，删掉信息量不变） OK: 多 Agent 下幻觉会互相放大

NO: 长程任务：跨上下文的工程问题（"跨上下文"和"长程任务"意思重复） OK: 长程任务的跨上下文挑战

标题里保留逗号：先...再...顺序句（先修复评测，再修复 Agent）；对仗枚举（同步决策，异步 I/O）。

标题里逗号改冒号："主题，副标题说明"这种格式，逗号换冒号更清晰（Prompt Caching，降低重复调用成本 → Prompt Caching：降低重复调用成本）。

标题里去冗余词：「应该如何X」去掉「应该」，直接用「如何X」；副标题如果和主标题意思重叠，合并成一句。 NO: 「Agent 评测应该如何做」 / 「工程实现应该遵循什么顺序」 OK: 「Agent 评测如何做」 / 「工程实现遵循什么顺序」

标题不要做成名词并列: 三个名词用顿号串起来，没有观点，读者不知道这节想说什么 NO: 「蒸馏、专用化与持续迭代」 / 「数据、算法与系统」 OK: 用一句有判断的陈述：「前沿模型发布后，训练链路还在继续跑」 判断标准：标题能不能单独成立为一个有意义的句子，能就留，不能就改

标题要有判断，不只是名词：好标题表明立场或结论，不只是列出主题词。 NO: 「多 Agent 协作」（只说了主题） OK: 「多 Agent 协作让幻觉互相放大」（有判断） OK: 「评测先于 Agent，不然你不知道在修什么」（有立场）

以上是倾向，不是硬规则。判断式标题适合分析 / 论证型文章；叙事、经历、探索型长文里，疑问句和好奇式短语往往更抓人（「机器人怎么知道自己在哪」「一根没有销钉的手指」），同一篇里两种可以混用。作者已经定的标题形式优先，别为了「凑判断」改掉一个好的好奇式标题。

引号（""）

引号不是强调键。不要因为某个词"感觉重要"就套上引号。 同理，「」 也不要拿来做视觉强调。

NO: 大模型最擅长"翻译" NO: 防止 Agent 通过改标准来"提升"分数 NO: Agent 扫了一眼，觉得"差不多了"

OK: 大模型最擅长按规格说明书做对照实现 OK: 防止 Agent 通过改标准来刷分 OK: Agent 扫了一眼觉得差不多，直接宣告完成

引号只用于：直接引述他人说的话、系统输出内容、错误消息。

括号（）

括号里的内容超过 10 个字，多半说明它该待在正文里，而不是括号里。 同一段里出现 2 处以上括号时，优先把至少 1 处改写进正文，避免读感变重。

NO: 传统 APM（Datadog、New Relic 这类监控延迟和错误率的工具）基本帮不上忙 OK: 这类只监控延迟和错误率的传统 APM 基本帮不上忙

NO: 并发的正确用法不是多模型推理，需要并发的是（文件操作、网络请求、长耗时命令） OK: 需要并发的是文件操作、网络请求、长耗时命令，模型推理本身保持单线程

可以保留括号的情况：术语首次出现的英文原词、简短数值范围（5~15%）、代码参数说明。

分号（；）

分号不是懒人句号。两个放在一起就是因为"感觉有关系"的句子，多半应该直接用句号断开。

NO: File System State 开销只有 5~15%，几乎总是值得的；Verifier Agent 能提升 25~40% 精度，但成本增加 1.5~3 倍 OK: File System State 开销只有 5~15%，几乎总是值得的。Verifier Agent 能提升 25~40% 精度，但成本增加 1.5~3 倍

可以保留分号的情况：

• 对仗句：只跑 Layer 2，评分标准会漂移；只靠 Layer 1，根本看不过来
• 列表项分隔：本地 Shell 能处理的；只需静态知识的；还没验证过的
• 中文枚举：一是…；二是…

分号后面接转折词是典型错误，直接断句：

NO: ...也决定后训练有没有可以利用的空间；但它没有决定这个模型会不会听指令

OK: ...也决定后训练有没有可以利用的空间。但它不决定模型会不会听指令

AI 味检测：这几个模式帮你认味

以下是高频出现的具体模式（举例，不完全），用来识别 AI 味，不是必须逐条执行的清单。句子本来自然、清楚就别套规则，命中了味再改。

1. 升华句: 把具体工程观察上升到普适人生道理

NO: "很多东西都是这样，当初成立的假设，过一段时间回头看可能已经不成立了。"

OK: 直接给出具体建议，不升华

2. 对比句式: AI 最爱的结构，出现频率高就有问题

NO: "不是…而是…" / "直觉上…但实际上…" / "X 本身没有价值，真正有用的是 Y"

NO: "X 已经不是瓶颈，Y 才是" / "X 不重要，Y 才真正...": "才是/才真正"变体同样是对比框架

OK: 直接说结论，不用对比框架铺垫。"代码生成不卡人了，真正费力气的是评审"比"代码生成不再是瓶颈，评审才是"自然得多

3. 重复核心观点: 同一个道理在不同节出现 2-3 次

NO: 第 0 节说了，第 2 节总结处再说一遍，结语再升华一遍

OK: 说一次，后面直接引用或跳过

3b. 段内重复: 同一段里把同一个意思用不同措辞说两遍

NO: "没有约束边界的 Agent 不是更自由，而是更容易在错误路径上跑很远都没人察觉。加约束，是给它一个出了错还能拉回来的余地，没有约束的 Agent 跑偏了都没人察觉。"（后半句和前半句说的是同一件事）

OK: 说一遍，够了。不需要用换一种说法再强调一遍

4. 引用+解释句式: 先抛英文术语/名言，再解释

NO: "工程界有句话 'X'，对 Y 同样如此，..."

OK: 直接用破折号或口语解释：他们把这个叫 progressive disclosure，就是不要一下全给

5. 工整并列总结: 每节结尾必有一句"三层缺一不可"型总结

NO: "三层缺一不可，只靠 A 没用，只靠 B 不够，单独拿出来都有漏洞。"

OK: 口语化：用下来感觉，少任何一层都会出问题

6. 瓶颈转移句: 一眼 AI 博客

NO: "瓶颈从'X'转移到了'Y'"

OK: 直接说新情况：代码生成不卡人了，压力全压到评审这一侧，不用"瓶颈"这个词

7. 优先级结论句: 听起来像教条

NO: "安全边界要比任何功能都先做好" / "是生产级别必须的"

OK: 说清楚为什么：能跑 shell 就能删库，安全得先来

8. 系统性定义开头: 教科书格式

NO: "X 是对 Y 的系统性评估，包括测试用例、评分标准和自动化验证流水线。"

OK: 从问题或场景出发，不从定义出发

9. 完美并列 bold 标题: 一组"有X，让Y而不是Z"结构

NO: 四个 bold 标题全是"有明确的参照物，让 Agent 翻译而不是创造"这种格式

OK: 每个点语气不同，或直接改成散文叙述

10. 顺序/重要性结论: AI 喜欢用"所以"收尾说教

NO: "所以顺序很重要：评估工具可信，测量结果才有意义。"

OK: 直接说怎么做："怀疑 Agent 出了问题，先确认 Eval 没问题。"

11. 混杂段落: 一段塞了多个不相关话题

NO: 一段里同时讲可观测性顺序、File System State 成本、Verifier Agent 精度、多 Agent 引入时机

OK: 每段只说一件事，其余拆到各自对应位置，没有对应位置的直接删掉

12. 章节引介过渡句: 章节结尾或开头写一句引出/承接下一节的桥接句

NO: 「上面这些模式解决的是控制流怎么搭，下面再看另一个更工程的问题，系统为什么能跑稳。」

NO: 「X 保证了方向对了，执行完还得确认它真的做对了。」← "X 做完了，还有 Y"的机械衔接，只在宣告结构，没有信息量

OK: 直接删掉，章节标题本身已经承接

例外：这几类章节引导是必要的，不要删：

• 内容说明：告诉读者这节为什么值得看，有实质信息量

OK: 「这块很少有教程展开讲，但它很影响成本结构和设计取舍。」

• 模式切换信号：长文里从原则转向案例、从理论转向实操，读者需要知道内容性质变了

OK: 「前面几节讲的是原则，这一节直接看 OpenClaw 怎么落地。」

• 行动指引：结尾给读者一个具体的下一步，不是在说文章做了什么

OK: 「想知道自己的配置离这些原则差多远，跑一次 /health 是最快的方式。」

判断标准：句子里有没有对读者有用的信息，有就留，只在宣告文章结构就删。

13. 收尾"给你答疑/给你答案": 文末或节末用「应该能给你答疑」收尾

NO: 「下面文章应该能给你这些问题答疑。」

OK: 省略，或改成：「读完这篇，这几个问题应该能有些答案。」

例外：图后说明段落不能以"重复"为由删除 图片的 alt text 读者看不到，图后的文字说明才是读者真正看到的解释。图后说明段不属于"收尾总结"，不要删。 判断标准：如果删掉这段文字，读者就看不懂这张图，就必须保留。

14. 段末收尾总结句: 一段刚解释完某个机制，结尾再加一句把刚才的意思重述一遍

NO: "这不只是设计选项，是资源约束的结果": 紧接在已经解释了具体代价之后

NO: "模型本身成了训练流水线里的工具": 刚解释完模型在给下一代产出训练数据

NO: "主流实验室基本都在用这类多阶段配方了": 四个阶段刚刚描述完

OK: 说完就停，事实本身已经说明一切，不需要再"总结"一遍

识别信号：这类句子往往以"到这里"、"这说明"、"这本身就是"、"也就是说"、"可以看出"开头，或者是段落最后一句比其他句短且抽象

15. 英文术语首次出现后，后续一律用中文

• 首次出现：保留英文 + 中文注解，或中文前置 + 英文括注（指令微调（Instruction tuning））
• 后续出现：只用中文，不要英文/中文混用

NO: 第一次"冷启动 SFT（cold start）"，第五次还在写"cold start 让 RL 稳定启动"

OK: 第一次解释清楚，后面一律写"冷启动"

• 例外：SFT、RL、MoE 这类已成行业通用缩写，可以全程保留缩写形式

16. 思考过程用了物理动作动词（翻译腔套路一）

接住、击穿、锋利、不崩、不爆、打穿、扛住、收紧、落地、推开、撑不住，这类词把抽象认知过程想象成了物理动作，骨架是英文（catch / pierce / sharp / break / blow up）。

NO: 「你这几条我都接住了。」「这个论证被击穿了。」「更锋利的重构：」

OK: 「你这几条我都收到了。」「这个假设不成立。」「换一种更准的讲法：」

自检方式：写完一段，把所有动词圈出来，凡是中文日常不会这样用的，挨个换掉。

17. 形容词预判+冒号引出内容（翻译腔套路二）

「更干净：」「逻辑很清晰：」「问题很直接：」「结论很明确：」，形容词抢先下判断，冒号才引出事实。 问题有三：抢走了读者自己评估的机会；形容词几乎总是多余的；后面的事实本身就能让读者得出那个感受。

NO: 「验证得比我预期的更干净：上下文不崩、成本不爆、状态可恢复。」

OK: 「数据把你的感觉证出来了：上下文不乱、成本压得住、状态能恢复。」

改法：直接把形容词那一节删掉，只留后半句事实。如果非常想保留那个形容词，多半说明后面内容没讲清楚，要回头补内容。

18. 抽象名词做主语，形容词当结论（翻译腔套路三）

"X 的 Y 比 Z 更 W"这种骨架，主语是抽象名词（工程上的现实、这份数据、生态的成熟度），结论是形容词（难看、直接、漫长），中间系动词连接。读完不知道到底哪儿难看、难看在哪个环节。

NO: 「工程上的现实比这些数字难看。」

OK: 「这些数字只反映了采用面；真往下看各家怎么接，早就对不齐了。」

改法：让人、动作、或具体对象做主语，让事实自己说话。凡是碰到"X 的 Y 比 Z 更 W"骨架，都应该重写。

19. 有稳定中文对译的英文词直接混入（翻译腔套路四）

context、state、cache、claim 这类词有现成中文对译：上下文、状态、缓存、断言。留着英文原词让读者每次切换都消耗注意力。

NO: 「context 不崩、成本不爆、state 可恢复、cache 命中率高。」

OK: 「上下文不会乱、成本压得住、状态能恢复、缓存命中得上。」

判断标准：中文技术圈已有通用译法，就换中文；术语在中文圈还未收敛（如 prompt、embedding、tokenizer），保留英文合理。 例外：SFT、RL、MoE 这类已成行业通用缩写，全程保留缩写形式。 常见可替换词：context→上下文、state→状态、cache→缓存、claim→断言、runtime→运行时、contract→契约。

20. 对称粗体起句: **词语**。…… 连续出现 3 行以上即触发 AI 模板感。把第 4 个改成行内嵌入式粗体（句子里加 **重点**），打破节奏。

21. 挑战与未来展望模板段: "尽管面临挑战，X 凭借 Y 仍将持续蓬勃发展，成为 Z 不可或缺的一部分。" 是 AI 最爱的收尾套路。

NO: "尽管面临挑战，X 凭借 Y 仍将持续蓬勃发展，成为 Z 不可或缺的一部分。"

OK: 直接说具体的挑战和具体的应对，不要"尽管…仍…"+"未来展望"的套路收尾。

22. 同义词循环: 同一段里把同一对象用 3 种以上同义词替换，是 AI 重复惩罚机制的副产物。

NO: "主人公面临挑战。主角必须克服困难。中心人物最终获胜。英雄回到家中。"

OK: 选一个称呼用到底。"主人公面临挑战，最终获胜回到家中。"

23. 虚假范围: "从 X 到 Y" 结构里 X 和 Y 不在同一尺度上，假装覆盖全光谱。

NO: "从大爆炸的奇点到暗物质的神秘舞蹈"（不是同一类对象）

NO: "从架构设计到团队文化"（跨域强凑）

OK: 直接列出真正涵盖的两三件具体事，或者只挑一件展开。

24. 知识截止日期免责声明残留: AI 关于"截至 X 时间 / 根据可用信息 / 现成资料中没有广泛记录"的免责声明被原样粘贴到正文。

NO: "虽然关于公司成立的具体细节在现成资料中没有广泛记录，但它似乎是在 90 年代的某个时候成立的。"

OK: 要么查清楚直接写"成立于 1994 年"，要么不要写这一句。模糊免责声明本身就是 AI 痕迹，要删干净。

注: 与「时效性事实加边界词」不同，那条是作者主动加边界（"截至 2026-04 我看到的是…"）；这条是 AI 自动生成的甩锅式免责。

因果/结论语气要像归纳，不像定论 技术文章里，判断方向没问题，但懂行读者看到”换来的是/就是从这里来的/是X的路径”这种语气，容易挑刺。改成归纳语气：

NO: “换来的是同等参数下更高的能力密度” / “性能差距就是从这里来的” / “也是能力解耦的路径”

OK: “公开结果显示，这类配方通常能换来更高的能力密度” / “从公开结果来看，差距通常是可观测的” / “一个关键原因是能力解耦”

术语列表需要”为什么值得记”的锚 一段里列出多个专有名词（muP、WSD lr、batch size 等）而不解释为什么读者该记住，更像点名单不像论证。加一句：

NO: “这些都开始出现在正式训练报告里。能看出来的一条线是，配方越来越细。”（只说存在）

OK: “这些细节之所以值得记，是因为它们正在成为同规模模型之间拉开差距的地方。”（说明为什么重要）

长段落拆分标准 一段超过 400 字、或塞了 3 个以上独立概念，移动端读起来会累，也容易冲淡最重要的那一句。拆分点：概念切换处加空行，不要因为”都属于同一主题”就塞在一起。

案例引入需要半句”为什么选它” 直接 zoom in 到具体案例（PARL、DeepSeek-V3 等）时，如果切换感突然，先加半句说明它代表哪条路线或设计选择，再展开细节。

NO: “Kimi K2.5 的 PARL 是这里最值得拆开的工程案例。它只训练 orchestrator...”（直接进细节）

OK: “Kimi K2.5 的 PARL 代表了一条新路线：只训 orchestrator、把 credit assignment 收到编排层。奖励信号分三类...”（先说代表什么）

工程技术文实战规则

下面这组来自真实改稿回合，优先级高于”风格偏好”：

• 删段之前先确认信息量。删除整段（不是单句）之前，确认这段没有在别处重复的技术事实、数据或逻辑。”删掉段末总结句”的规则针对结构性重复，不适用于展开新信息的段落。如果不确定，改成提议而不是直接删。
• 先保语义，再去 AI 味。为了”更口语”改坏原意，属于失败改写
• 括号和引号默认少用，但术语首次出现、歧义消解时要保留，不要为删符号牺牲清晰度
• 句号密度要控。连续短句太多会像汇报提纲，适当合并成复句
• 避免“训人式”表达：反问、命令、质问式开头都容易让读者产生被指导感
• 避免抽象判词堆叠，优先写可观察事实、链路位置和具体影响
• 结论不重复宣告。第 0 节说过的核心判断，后文不要再换措辞重复一遍
• 保留作者的内在矛盾。如果原文在不同段落持有看似矛盾的立场（比如既推崇自由又强调纪律），不要替作者消解。时间性矛盾（早期 vs 近期观点）标注演化即可；领域性矛盾（工作 vs 生活的不同规则）保留两面；本质性张力（价值观的内在冲突）原样呈现，这通常是文章最有深度的部分

Summary 写法

summary 先判断目标，不同目标写法不同：

• 导读型：告诉读者“这篇会讲什么”，不提前讲完整结论
• 总结型：概括“这篇讲了什么 + 得出什么结论”

实操规则：

• 导读型用“这篇会从 A 讲到 B，重点看 C”
• 总结型用“这篇从 A 到 B，最后看到 C”
• 不要混写，避免一段里既像导读又像结论宣判
• 默认 2 到 3 句，信息完整但不铺满正文细节

高频替换：报告腔和不喜欢的表达

按「左边少用，右边推荐」执行，读起来有同样报告腔或不自然的一律适用。

补充：比较表达优先自然中文，最清晰 通常比 最清楚 更稳；避免「句子评价句」，「这句话解释不了」直接写成「X 解释不了 Y」。

参考资料排列

• 默认用单列表，不强制按“论文/博客/仓库”分类
• 排序按承重程度，不按发表时间
• 论文和官方技术报告优先，仓库与博客只保留高承重项
• 数量以可读为先，通常 10 到 14 条比较稳

文章自说明句（默认少写）

文章不该反复谈自己在做什么。默认直接进内容，必要时只保留 1 句路线提示。

NO: 先给最短结论，就四句： NO: 这篇真正想钉住的，就是这件事： NO: 如果先只记一张表，可以先记住这六层： NO: 脑子里还是那老三样：X、Y、Z（代替读者做归纳） NO: 最常见的解释就是三件事：（同上） NO: 拿一组具体数字看会更直观。（宣告数据要来了） NO: 如果说...那...（条件句引入段落） NO: 这篇文章接下来会从 X 讲到 Y。（同上）

OK: 直接进结论、进数字、进内容。结构交给标题和逻辑顺序，不要靠过渡句反复宣告。 OK: 如果确实需要路线提示，只写一遍，避免在开头和结尾重复。

术语注解不要扎堆

多个术语同时首次出现时，括号注解会堆在一起，读起来很重。处理方式：

• 把注解融入行文：GRPO（组相对策略优化），而不是传统 PPO（近端策略优化） → 这里的关键选择是 GRPO 而不是传统的 PPO，注解分散到后文
• 把首次介绍提前：在自然引出术语的地方加注，而不是在密集使用的地方一次性堆上去
• 如果上下文已经说清楚了意思，括号注解可以完全省略

图片引导语

图片前的说明句不用「下图」，用「这张图」或「下面这张图」，避免每句都一样。

图片节奏

带图技术长文里，图片放哪儿决定整段读起来顺不顺。三条经验：

图当 TL;DR，列表/表格当详情。图片放在「intro 一句话 + 图 + 列表」这个位置最舒服。把图丢在列表/表格末尾、紧贴下一个 --- 的位置看着空，上面是序号 + 加粗也很丑。

图片 alt 要和正文 prose 对齐。如果 alt 列了 6 项保号清单、prose 改成 5 项，要么改 alt、要么重画图，不能让两者错位。读者扫到的是图视觉 + 正文文字，alt 给搜索引擎和无障碍。

段末"为了平衡而加图"是 AI 模板。图不是装饰节奏的工具。如果某段没自然想到画什么，就别凑图，文字密就让它密。

技术文章额外规则

事实与可验证性优先于去 AI 味 技术文章先保准确、清楚、可验证，再追求自然。不要为了删 AI 味，把版本、环境、依赖、出处、复现条件、风险边界删掉。如果原文缺这些信息，不要编，可以保留问题或收敛语气。

• 版本、平台、依赖会影响结论时，要保留或补全对应上下文
• 引用“官方建议”“文档说明”“测试表明”时，要有具体出处；没有出处就不要写成定论
• 命令、配置、代码不要只贴结果，要解释关键参数、关键路径和为什么这么改
• 性能、安全、稳定性结论要说明观察口径，比如数据来源、测试环境、样本范围
• 个人经验、单次排障、局部实验不能写成通用规律
• 写方案时顺手补一句边界：什么时候适用，什么时候别这么用

时效性事实加边界词 价格、订阅档位、版本号、产品名、隐藏命令、发布时间这类容易过时的事实，加边界词写：「截至 2026-04」、「我这里看到的是」、「以当时显示为准」、「目前」。读者过两个月对着失效信息照搬时，能立刻看到这是哪一时刻的截图。

专有名词改前 verify 字体名（沧耳 / 仓耳 / 苍耳）、品牌名、书名、人名、产品名改之前先 grep 或查官网，不凭印象。事实类改动比风格类改动风险高，反而最容易拍脑袋下手。

开头不要放背景铺垫段落在最前，比如"国内现在也有不少打着 X 旗号的产品..."这种定性背景，放到正文具体位置更自然，不要作为全文开场白。

技术术语解释不用分号并列

NO: "系统提示的三层结构：身份定义，常驻、轻量；约束规则，常驻、精确；领域知识，按需加载。"

OK: 直接说："系统提示分三层：身份和约束规则常驻，领域知识按需加载。"

场景描述代替核心问题格式

NO: "这类系统要解决的核心问题是：Agent 常驻服务器，同时需要..."

OK: "场景是：Agent 常驻服务器，要同时接多个渠道的消息..."

数据后不要加 AI 营销腔结论

NO: "token 节省 37%，消除 19+ 次无效推理。"

OK: "token 从 15 万降到 2000，中间 19+ 次来回推理也省掉了。"

幻觉/错误原因不用学术解释框架

NO: "原因在于 LLM 的中立性偏向。以'帮助、诚实、无害'为目标训练出来的模型，在群体讨论中天然倾向服从..."

OK: 直接说现象："LLM 训练目标是'帮助、诚实、无害'，在群体里就会倾向不反对多数人。一个说错了，后面的顺着走。"

不要用外来术语/模型名做比喻，除非读者肯定知道

NO: "这就是瑞士奶酪模型的现实：每一层都有漏洞"

OK: "每一层都有盲区，叠在一起才够用"

西方管理学模型名（瑞士奶酪模型、长尾定律等）、外语质量管理术语（Poka-yoke）在中文技术文章里多数人看不懂，去掉名字，直接说清楚那个道理就行。

多方案例并列时合并叙述，不要各自单独成段 同一个技术观察涉及 3 家公司/方案时，合并成一段，每家贡献一句话，读起来像分析而不是列表。

NO: 三段分别讲 Kimi、Cursor、Chroma 的做法，每段独立成段

OK: "三家承担的重点也很清楚。Kimi 用 PARL 解决...，Cursor 用 self-summarization...，Chroma 则把 prune_chunks 训成策略本身..."

有名字的来源自然融入句子，不要做括号注释或单独引用句

NO: （根据 Philipp Schmid 的分析）今天 agentic model 报告共同模式已经很稳定

NO: 根据 Philipp Schmid 的研究，今天 agentic model 报告共同模式已经很稳定。

OK: "把 Philipp Schmid 对 Kimi、Cursor、Chroma 的归纳放在一起看，能看到几个共同点。"

技术文章自检

交付前快速扫一遍，优先看这些问题：

• 这篇文章到底解决哪个具体问题
• 版本、环境、依赖、上下文是否足够读者复现
• 每段是否都有新信息，还是只是在换说法总结
• 代码、命令、配置是否解释了关键部分
• 结论有没有对应的证据、数据或来源
• 有没有只讲收益，不讲代价、风险和边界
• 有没有把个人经验写成所有场景都成立

Polish 后期残留 checklist（10+ 轮之后用）

风格级 AI 味清干净后，还有一类「句子级残留」最容易被漏掉。每轮 polish 末尾按这 6 类扫一遍：

1. 叠词拗口：同一句里出现两个意思接近的词（"也能上手用"、"也都"、"也是另外"）。识别：把句子拆成最小动作主谓宾，看哪个修饰是冗余的。

2. 缺逗号长句：超过 25 字的句子里没有逗号断点，多半在某个时间状语 / 条件状语后漏了「，」。识别：朗读时想换气的位置就是该加逗号的位置。

3. 中英术语一致性：同一篇里同一个常用词（copy / 复制、context / 上下文、setting / 设置）反复切换形态。识别：搜文中所有英文 token，看是否有对应中文已成主流，主流就统一为中文。

4. 突然出现的比喻 / 概念：作者自己脑子里有的比喻（"工作台"、"水位"、"账本"）没在前文铺垫就直接用。识别：第一次出现的非通用比喻词，前一段必须有铺垫，没有就换通用词。

5. 「上 / 下 / 里」字残留：「方案上都」「思路里」「概念上」这类介词残留是早期草稿的痕迹，删掉不影响意思。识别：搜「上都」「里都」「上的时候」。

6. 缺关键修饰：某个名词第一次出现需要修饰才能区分性质（"Anthropic 官方推出的 Claude Design" vs "Claude Design"），漏了读者会和上下文混淆。识别：每个产品 / 工具名第一次出现，问一句"读者能否区分这是谁家的、跟前文工具的关系"。

判断标准：1-3 类是字符级、5 分钟扫完；4-6 类要带上下文判断、需要全文回读。10 轮后 prose 大改不动了，时间就花在这 6 类残留上。

专家腔

润色容易把作者改得比原文更像专家、更会教人。下面这几处是同一个倾向的常见表现。

0. 实作经历不能为了工程感补细节

NO: 作者只说"串口通信难"，润色时补成"ACK 丢了、超时重传、翻串口日志定位"这类原文没有的排障故事

NO: 同样地，原文只说"串口通信难"，不要替它补出"波特率、指令格式、模块状态"等原文没提的具体参数

OK: 只顺句、不加事实，原文给什么写什么：「串口通信我反复试了好多次才弄对，差一点就放弃了」

判断：硬件型号、协议字段、波特率/指令格式等参数、日志结论、故障原因、排查顺序，只要原文或用户没给，就不要补。原文若已写明这些参数，可以保留并顺句，但不要再往上叠新的故障细节。技术文的人味来自真实细节，不来自替作者编一个更像工程师的 Debug 故事。

1. 元叙事 in 正文（跟"文章自说明句"是 PRE-meta，这条是 IN-BODY meta about article-writing itself）

NO: 「写到这里」「写文章时」「更稳的写法是」「我把 X 单独拿出来讲」「这里要小心一个说法」放在正文里

OK: 直接陈述，或换成「一圈下来」「更准确的说法是」这种不带"写"字的衔接

例外：末尾 italic publishing note 可以用「本文完成于 X」这种 convention

2. 二人称读者预测（跟"训人感起手"是命令式，这条是预言式）

NO: 「你会自然地问」「你会知道 X」「你会同时多出 X」「你会发现」

OK: 去"你"做主语，事实陈述：「翻论文时会先看 X」「同时会多出 X」「自然会想问 X」

3. 段首 announce-a-feature 引子（rule 12 章节引介过渡句的段内变体）

NO: 「X 也是容易被低估的部分：」「X 也是 Y 的延伸：」「还有一项 Y 经常被低估：」「我了解到 X 常见的 Y 有这几类，工程代价也各不一样：」

OK: 直接进 X：「X 也容易被低估：[直接讲]」「再往后一层是 X：[直接讲]」，分类引子直接进列表或表格

4. 章节编号一/二/三 prefix

NO: ## 一、X ## 二、Y 中文数字编号像教材目录

OK: 去前缀，标题留描述/判断

例外：参考文献、操作步骤、明确有顺序的列表可保留 1./2./3.

5. 同对比框架反复使用（rule 2 对比句式 + rule 3 重复核心观点的交叉地带）

NO: 「X 只是表层，更有用的是 Y」「X 只是表面，Y 才说明价值」「X 只是开头，Y 才是…」同一文章 2+ 次

OK: 留一个正典实例，其余 vary 骨架（「看 X 能不能 Y」/「X 是表面，能不能 Y 才说明价值」）

6. 形容词 announce-claim 不带列表（扩 rule 17，rule 17 收的是 形容词：[列表] 这种）

NO: 「原因很朴素」「X 很现实」「代表很现实的优势」「展示了很强的运动性能」（中间陈述，不是列表前）

OK: 删形容词，直接给事实：「原因很简单：[事实]」「H1 运动性能也很强」「国内挺实在的两个优势」

7. "X 在于 Y / 价值在于 Z" 名词化 claim 公式（跟 rule 18 抽象名词主语相近，这条是"X 在于 Y"系动词结构）

NO: 「减少 X 损耗」「价值在于 Y」「吸引力是 Z」「区别在于 W」「关键在于 V」

OK: 动词化 + 主语具体化：「省掉 X 的麻烦」「最大的好处是 Y」「跟 W 不一样的是…」

8. bullet 跑成"纯记录" → 第一人称叙事，但只用已给细节（扩列表去 list 化策略）

NO: bullet 全是 passive 陈述（「X 是 Y / X 烧过 / X 不够硬 / X 必须自己写」），读起来像故障报告

OK: 转 prose 段，优先用原文已有的动作和状态：「踩坑 / 老老实实 / 晃 / 不太对劲 / 最难的是 / 我」

例：bullet「OLED 带电插拔烧过一次，后来所有接线都先断电」→ prose「OLED 我带电插拔烧过一次，之后所有接线都老老实实先断电」

风险：不要为了让段落更"工程师"而补协议、日志、ACK、重传、供电、接触不良等未经确认的排障细节。

9. 紧邻 2 段 setup→continuation 用逗号 fuse 成一段（跨段落版的"句号密度要控"）

NO: 紧邻两段，前段铺垫、后段承接，中间用段落 break + 句号

OK: 去段落 break，改逗号融合

例：「它都不知道。它跑通的是…」→「它都不知道，它跑通的是…」

判断：后段是 elaboration、example、follow-up 时合；topic 切换时不合

10. 第一人称 anchor 的边界

实作经历、开头动机、踩坑过程可以保留「我」；技术判断、产业分析、表格列名和结论段尽量让事实做主语。

NO: 一篇 7 章长文里反复出现「我会先看」「我更在意」「我盯」「我不会把」「我自己看一家公司」

OK: 「动作空间、控制频率和真机测试比参数量更早决定可比性」「公司层面的差异，最后会变成几个问题」

判断：第一人称是经历证据，不是审稿姿态。中后段如果像作者站出来教读者怎么看，优先删主语或改成可观察事实。

11. 学习路径不要改成入门教程

NO: 「入门不用一上来」「先把 X 跑通」「再往前一步」「几个常见坑」「这一圈下来，我先把收获留成检查项」

OK: 「按我现在的理解，资料大概能这样串起来」「跑过一遍后，哪些词会落到具体字段上」「还有几个问题我现在没答案」

判断：原文如果是工程师边做边学、把材料慢慢串起来的过程，不要改成老师给读者安排课程。学习路径可以写，但语气要像作者自己的探索路线。除非用户明确要教程，少用命令、清单、检查项、常见坑、入门教程这类框架词。

12. 不要把轻一点的作者口气修成老派说教

NO: 「盯」「检查项」「安全动作放前面」「失败样本要不要留」「更有抓手」「后续继续跟踪」「需要重点关注」

OK: 「看」「几个判断更具体」「限角度、限速度、急停这些东西要留在本地」「失败数据怎么处理」「会落到更具体的问题上」「我现在还没有答案」

判断：这些词本身未必错，但在博客里容易变成老派专家指导读者。作者原本如果是「我跑过 / 我看到 / 我还没答案」的探索口气，不要润成「我来告诉你该怎么做」。

工程文用词替换补充

默认禁用（举例，不完全，读起来有同样报告腔的一律适用）

报告腔替换词见上文「高频替换」「用词去正式化」两张表。下面这些已在上文各 pattern / 段落展开，命中即按对应处改，不在这里重列：破折号（见「句式」）、随着…的发展（见「开头直接」）、对比框架与「X 本身没价值 / X 不是瓶颈 Y 才是」（pattern 2）、瓶颈转移句（pattern 6）、两 / 三层缺一不可（pattern 5）、引号强调（见「引号」）、瑞士奶酪 / Poka-yoke（见「不要用外来术语做比喻」）、孤立单句段落（见「句式」）、文章自说明句（先给最短结论 / 这篇真正想钉住的 / 脑子里还是那老三样 / 拿一组数字更直观 / 如果说…那…，见「文章自说明句」）、升华开头（pattern 1）、抽象集体主语（pattern 18）。

下面只补上文没单列的高频禁用词：

NO: 本文旨在 NO: emoji（任何场合，包括列表、标题、状态标记） NO: 这篇是整理出来的结果（冗余，删掉） NO: 有一个大背景值得先说（直接说） NO: 读下来有几个地方和直觉不一样，提前说一下（直接列） NO: 精准命中了 N 个条件 NO: 是最常见的失败模式之一 NO: 拿来即用 / 装好就能用（拿来即用是营销词，自己介绍工具直接说”装好就能用”） NO: 翻倍 / 翻番（带数字渲染感） NO: 事半功倍 / 少走弯路（成语腔，前者更重） NO: 先立住（劝告腔，可改”注意一下”或直接陈述） NO: 完全没关系（去掉”完全”两字更口语，”没事”更稳） NO: 把模糊性降到最低（学术抽象，改成”让它要猜的部分变少”这种动词具体） NO: 最好的 / 最适合 / 直接搞定 / 一句话就出（介绍自己工具的营销词，改成”我自己这么用 / 装好就能用 / 我攒了一套”） NO: 颗粒度（技术黑话，改成”粒度”或直接说”拆得更细”） NO: 家规（类比腔，直接说”规则”或”约束”） NO: 黑乎乎（口语过重，改成”偏暗”或”深色”） NO: 不可或缺（空泛形容，直接说依赖关系或删掉） NO: 奇妙之处（升华腔，直接说具体现象）

---

底线：读起来像工程师把问题讲清楚，不是像教科书，也不是像汇报材料。

---

对外发文专项检查

公开发文（release notes、推文、博客、newsletter）交出去之前，额外扫三件事：

1. 身份和敏感信号脱敏

公开文章里不出现可反推作者身份的细节：雇主、地点、具体团队背景、简历式表述。技术决策可以具体，身份信息默认删。

NO: "作为在 X 公司做过大型系统的工程师，我发现..."

NO: "住在北京三年，接触了很多本地开发者，感受是..."

OK: "用下来感觉，这套方案在中小规模场景最稳。"

OK: 直接讲技术选择和依据，不交代简历背景

2. 不踩竞品

介绍自己产品时不主动贬低同类产品。功能不如别人的地方可以不提，不要拿来做反衬。

NO: "Cursor 那种全局索引很吃资源，我们没走这条路。"

NO: "不像 Typora，我们做的时候 X 问题想清楚了。"

OK: "我们的选择是只索引打开的文件，不做全局扫描。"

OK: 直接说自己做了什么、为什么，竞品不用出现

3. 用户感受先于功能清单

release notes 和推文里不要开场就列功能。先给一句场景或感受，再进改动细节。

NO: "V1.2.0: 新增 X 功能，修复 Y 问题，优化 Z 性能。"

OK: "改了两处之前用起来总觉得别扭的地方。一是..."