polish-prose

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Polish Prose

文稿润色工具

Turn an AI-flavored or overwrought draft into prose that reads like a careful researcher wrote it — without moving a single number, claim, or citation. Reviewers now pattern-match the LLM register (delve/leverage vocabulary, Moreover-stacked paragraphs, em-dash chains, uniform hedging), and a leftover "Certainly! Here is..." or "[insert citation]" is a desk-reject-grade embarrassment. This skill finds all of it deterministically, then guides a disciplined human-in-the-loop rewrite: expression changes, content does not.
将带有AI风格或过于冗长的草稿修改为看起来像是严谨研究人员撰写的文稿——同时不改动任何数字、主张或参考文献。如今审稿人会识别LLM的典型语体特征(delve/leverage这类词汇、堆叠Moreover的段落、连续破折号、统一的模糊表述),而遗留的“Certainly! Here is...”或“[insert citation]”这类内容会直接导致初审被拒。本工具能精准定位所有这类问题,然后引导人工参与的规范改写:仅调整表述方式,不改动内容。

When to use

使用场景

  • "My paper sounds like ChatGPT wrote it" / "humanize this" / "de-AI-ify"
  • "Remove the AI words" / "it keeps saying delve and leverage"
  • "Tighten / polish my writing" / "this is too wordy"
  • "Fix my hedging" — overclaimed contributions or drowned-in-maybes results
  • "Make my contribution statements active" ("a method is proposed..." → "We propose...")
  • "Is my terminology consistent?" (dataset vs data set, acronym discipline, British vs American spelling)
  • Called before
    preflight-check
    as part of the final submission pass, or after heavy drafting with any LLM assistant.
  • “我的论文听起来像ChatGPT写的” / “让文本更具人文感” / “去除AI写作痕迹”
  • “去掉AI常用词汇” / “总是出现delve和leverage这类词”
  • “精简/润色我的写作” / “文本太啰嗦”
  • “修正我的模糊表述”——贡献表述过度夸大或研究结果过于模棱两可
  • “让我的贡献表述更主动”(将“a method is proposed...”改为“We propose...”)
  • “我的术语使用一致吗?”(dataset vs data set、缩写规范、英式vs美式拼写)
  • 在最终提交流程中作为
    preflight-check
    的前置步骤,或在使用任何LLM助手完成大量草稿后使用。

Inputs

输入内容

  1. The draft: a
    .tex
    file (preamble/math/verbatim are masked automatically), a
    .md
    /
    .txt
    file, or pasted text via stdin.
  2. Optional: the venue profile
    venues/conferences/<venue>-<year>.yml
    (schema in
    venues/schema.yml
    ) — supplies the venue family for register norms and
    review.llm_policy
    for AI-use disclosure duties.
  3. Optional: a project glossary (
    canonical term = variant | variant
    per line) if the team has already standardized terminology.
  1. 草稿文件:
    .tex
    文件(序言/公式/原样文本会自动屏蔽)、
    .md
    /
    .txt
    文件,或通过标准输入粘贴的文本。
  2. 可选:会议/期刊配置文件
    venues/conferences/<venue>-<year>.yml
    (配置格式见
    venues/schema.yml
    )——提供目标出版方的语体规范和
    review.llm_policy
    (AI使用披露要求)。
  3. 可选:项目术语表(每行格式为“标准术语 = 变体 | 变体”),如果团队已统一术语规范。

Process

处理流程

  1. Freeze the technical content first. Build the no-touch inventory before editing anything: every number and unit, every
    \cite
    key, every stated result, dataset name, and system name. Snapshot it:
    grep -oE '[0-9][0-9.,]*\s*(%|\\%|ms|s|GB|MB|x|×)?' draft.tex | sort | uniq -c > /tmp/numbers-before.txt
    The same command must produce identical output after the edit pass (step 9). If polishing would require changing a claim, stop and tell the user — that is a content decision, not a style edit.
  2. Resolve the venue register and the LLM policy. If a venue profile is given, read its
    family
    (register norms per references/venue-register.md) and
    review.llm_policy
    . Re-verify the LLM policy against the live
    cfp_url
    before relying on it
    — these policies churn every cycle. Tell the user plainly: polishing AI-assisted text does not remove a disclosure obligation. If the venue requires an AI-use statement, help write an honest one; never frame this skill as a way to avoid it.
  3. Run the linters (Python 3, stdlib only, no network):
    python3 scripts/prose_lint.py main.tex
    python3 scripts/terminology_check.py main.tex --allow GPS,SDK
    Both accept
    .tex
    , plain text, or
    -
    for stdin;
    --json
    for machine-readable output;
    --strict
    to exit 1 while findings remain. Exit codes: 0 ok, 1 strict-failure, 2 bad input.
    --allow
    skips the undefined-acronym check for acronyms your community treats as universally known;
    --glossary FILE
    enforces a terminology table. Findings are candidates with line numbers, never auto-replacements — domain terms can look like tells ("leverage scores", "robust statistics").
  4. Kill RISK findings immediately. Chatbot artifacts ("As an AI model...", "Certainly! Here is...", "[insert X]") are deleted or filled in, full stop. Several venues treat undisclosed LLM output as a desk-reject trigger; an unfilled placeholder is also a missing citation — route real citation needs through
    verify-citations
    , never invent one.
  5. Edit pass A — lexical and structural tells. Work section by section with references/llm-tells.md open. For each WARN: keep it if it is a domain term or genuinely the best word (occasional use is fine — density is the tell, not existence); otherwise apply the rewrite pattern. Break Moreover/Furthermore paragraph chains by deleting the connective — if the logic no longer flows, the paragraph order was wrong, which is worth knowing. Recast surplus em-dashes as separate sentences or commas. Propose edits as diffs (old → new, with line numbers) and apply only with the user's approval.
  6. Edit pass B — hedging and claims. Calibrate per references/hedging-and-claims.md: contributions, definitions, and completed actions lose their hedges ("we propose", not "we attempt to propose"); interpretations, generalizations, and limitations keep exactly one honest hedge; double hedges collapse to one; boosters (clearly, undoubtedly) are cut — the evidence carries the claim or nothing does. Rewrite passive contribution statements as active, specific claims that say what is new. Never strengthen a claim beyond what the paper's own evidence supports, and never weaken a result the user measured.
  7. Edit pass C — terminology. Turn every
    compound-variant
    ,
    spelling-mix
    , and acronym finding into a one-line decision: present the variants with counts, let the user pick the canonical form (default: the majority form; spelling per the venue register), then apply it everywhere. Record decisions in a glossary file and re-run:
    python3 scripts/terminology_check.py main.tex --glossary glossary.txt
    Fix acronym discipline: define once at first use, expand consistently, drop definitions never used again.
  8. Edit pass D — venue register. Apply the family norms from references/venue-register.md: person and voice conventions, tense discipline, spelling convention, contraction policy, and the register differences between ML, systems, HCI, and LNCS venues. When no profile is given, default to consistent American spelling and the conventions already dominant in the draft.
  9. Verify nothing technical moved. Re-run both linters (clean, or each remaining finding consciously accepted by the user); re-run the step-1 number snapshot and diff it — any difference is a bug in the edit pass and must be reverted; confirm the
    \cite
    count and keys are unchanged. Present a short before/after table for every sentence whose claim strength changed in pass B so the user signs off on each one.
  10. Optional gate for CI or pre-submission:
    prose_lint.py main.tex --strict
    exits 1 while any RISK/WARN remains — useful as a final check alongside
    preflight-check
    .
  1. 先锁定技术内容。在开始编辑前构建不可修改的内容清单:所有数字和单位、所有
    \cite
    引用标记、所有明确的研究结果、数据集名称和系统名称。生成快照:
    grep -oE '[0-9][0-9.,]*\s*(%|\\%|ms|s|GB|MB|x|×)?' draft.tex | sort | uniq -c > /tmp/numbers-before.txt
    编辑完成后(步骤9)运行相同命令必须得到完全一致的输出。如果润色需要改动主张,立即停止并告知用户——这属于内容决策,而非风格编辑。
  2. 确认目标出版方的语体规范和LLM政策。如果提供了出版方配置文件,读取其
    family
    (语体规范见references/venue-register.md)和
    review.llm_policy
    在依赖该政策前,务必对照最新的
    cfp_url
    重新验证
    ——这类政策每个周期都会变化。明确告知用户:润色AI辅助撰写的文本并不能免除披露义务。如果出版方要求AI使用声明,协助撰写诚实的声明;绝不能将本工具作为规避披露的手段。
  3. 运行检查器(仅使用Python 3标准库,无需网络):
    python3 scripts/prose_lint.py main.tex
    python3 scripts/terminology_check.py main.tex --allow GPS,SDK
    两者均支持
    .tex
    、纯文本或
    -
    代表标准输入;
    --json
    参数可生成机器可读输出;
    --strict
    参数会在仍有问题时返回退出码1。退出码说明:0表示正常,1表示严格模式下失败,2表示输入无效。
    --allow
    参数可跳过对社区通用缩写的未定义检查;
    --glossary FILE
    参数可强制执行术语表规范。检查结果会标注行号作为修改候选,但绝不会自动替换——因为领域术语可能看起来像AI特征词(如“leverage scores”、“robust statistics”)。
  4. 立即处理高风险问题。聊天机器人遗留痕迹(如“As an AI model...”、“Certainly! Here is...”、“[insert X]”)必须删除或补充完整。部分出版方将未披露的LLM输出视为初审拒稿的触发因素;未填充的占位符也属于缺失引用——真实引用需求需通过
    verify-citations
    工具处理,绝不能编造引用。
  5. 编辑阶段A——词汇和结构特征。打开references/llm-tells.md逐节处理。对于每个警告项:如果是领域术语或确实是最佳表述(偶尔使用是可以的——问题在于密度而非存在),则保留;否则应用重写规则。删除Moreover/Furthermore这类连接词以打破段落堆叠——如果逻辑不再通顺,说明段落顺序存在问题,这一点值得关注。将多余的破折号改为独立句子或逗号。以差异对比格式(旧内容→新内容,标注行号)提出修改建议,仅在用户批准后应用。
  6. 编辑阶段B——模糊表述和主张。根据references/hedging-and-claims.md调整:贡献、定义和已完成的行动去除模糊表述(使用“we propose”而非“we attempt to propose”);解释、概括和局限性保留恰好一处诚实的模糊表述;双重模糊表述合并为一处;删除强化词(如clearly、undoubtedly)——主张应由证据支撑,而非这类词汇。将被动语态的贡献表述改写为主动、明确的新主张表述。绝不能超出论文自身证据强化主张,也绝不能弱化用户测量的研究结果。
  7. 编辑阶段C——术语规范。将每个复合词变体、拼写混用和缩写问题转化为单行决策:列出变体及其出现次数,让用户选择标准形式(默认:多数派形式;拼写遵循目标出版方规范),然后统一应用。将决策记录到术语表文件并重新运行检查:
    python3 scripts/terminology_check.py main.tex --glossary glossary.txt
    修正缩写规范:首次使用时定义一次,后续统一使用缩写;删除从未再次使用的缩写定义。
  8. 编辑阶段D——出版方语体规范。应用references/venue-register.md中的出版方家族规范:人称和语态规则、时态规范、拼写规则、缩写政策,以及ML、系统、HCI和LNCS类出版方之间的语体差异。如果未提供配置文件,默认使用统一的美式拼写和草稿中已占主导的规范。
  9. 验证技术内容未改动。重新运行两个检查器(确保无问题,或剩余问题均经用户明确接受);重新运行步骤1的数字快照并对比差异——任何差异均属于编辑错误,必须撤销;确认
    \cite
    的数量和标记未改变。针对阶段B中主张强度变化的每个句子,提供简短的前后对比表,让用户逐一确认。
  10. 可选的CI或提交前检查门
    prose_lint.py main.tex --strict
    会在仍有高风险/警告问题时返回退出码1——可作为
    preflight-check
    之外的最终检查步骤。

Output

输出内容

  • Two lint reports (Markdown or
    --json
    ) with line-numbered findings.
  • Proposed edits as diffs, applied only with approval, one pass at a time.
  • A terminology decision table plus a reusable
    glossary.txt
    .
  • A verification note: numbers/citations diff clean, claim-strength changes enumerated, remaining accepted findings listed.
  • 两份检查报告(Markdown或
    --json
    格式),标注行号和问题。
  • 以差异对比形式呈现的修改建议,仅在用户批准后逐阶段应用。
  • 术语决策表及可复用的
    glossary.txt
    文件。
  • 验证说明:数字/参考文献对比无差异、主张强度变化列表、剩余已接受问题列表。

What this skill is not

本工具不具备的功能

  • Not an AI-detector evasion tool. The goal is prose quality and an honest register, not beating a classifier. If the user's actual goal is to hide LLM use from a venue that requires disclosure, decline that goal, show the venue's
    llm_policy
    , and offer to draft the disclosure instead.
  • Not a content editor. It does not restructure arguments, add citations, or change what the paper claims —
    tailor-to-venue
    handles repositioning,
    write-abstract
    handles the abstract,
    verify-citations
    handles references.
  • 不是AI检测规避工具。目标是提升文稿质量和使用诚实的语体,而非规避分类器。如果用户的实际目的是向要求披露的出版方隐瞒LLM使用情况,应拒绝该需求,展示出版方的
    llm_policy
    ,并协助撰写披露声明。
  • 不是内容编辑器。它不会重构论点、添加引用或改变论文的主张——
    tailor-to-venue
    工具负责调整内容布局,
    write-abstract
    工具负责摘要撰写,
    verify-citations
    工具负责参考文献处理。

Relationship to other skills

与其他工具的关联

  • write-abstract
    — abstract-specific structure and venue metadata norms.
  • preflight-check
    — the desk-reject gate; run it after polishing.
  • anonymize-paper
    — identity leaks; this skill does not touch them.
  • verify-citations
    — any citation need surfaced here routes there.
  • write-abstract
    ——专注于摘要的结构和出版方元数据规范。
  • preflight-check
    ——初审拒稿检查门;应在润色后运行。
  • anonymize-paper
    ——处理身份泄露问题;本工具不会涉及此类内容。
  • verify-citations
    ——本工具发现的任何引用需求均需转至该工具处理。

Adapt to your discipline

适配你的学科领域

The tell lexicons are field-agnostic; the register is not. Fork and adjust references/venue-register.md for your field's journals (many mandate British spelling or third-person voice), extend the
--allow
acronym list for your community's alphabet soup, and add discipline-specific tells to
prose_lint.py
's
TELL_PATTERNS
table.
特征词库是跨领域通用的,但语体规范并非如此。可复刻并调整references/venue-register.md以适配你的学科期刊(许多期刊要求英式拼写或第三人称语态),扩展
--allow
缩写列表以适配你的领域常用缩写,在
prose_lint.py
TELL_PATTERNS
表中添加学科特定的AI特征词。

Guardrails

约束规则

  • Never alter numbers, results, claims, citations, or technical statements; expression only. Verify with the step-9 diff, every time.
  • Never auto-apply lexicon findings — every WARN is a judgment call and domain terms ("leverage scores") are innocent.
  • Never fabricate text for "[insert X]" placeholders; ask the user for the real content or route citations through
    verify-citations
    .
  • Never present the result as "undetectable" or "human-written"; never help evade an AI-use disclosure requirement — surface
    review.llm_policy
    and re-verify it against the live
    cfp_url
    .
  • Never submit anything to any system on the user's behalf.
  • Quote at most the flagged line in reports; never reproduce large portions of the paper in outputs.
  • 绝不能修改数字、研究结果、主张、参考文献或技术表述;仅调整表达方式。每次都需通过步骤9的差异对比验证。
  • 绝不能自动应用词库检查结果——每个警告项都需要判断,领域术语(如“leverage scores”)是合规的。
  • 绝不能为“[insert X]”占位符编造内容;应向用户索要真实内容,或通过
    verify-citations
    工具处理引用需求。
  • 绝不能将结果表述为“无法检测”或“人工撰写”;绝不能协助规避AI使用披露要求——需明确呈现
    review.llm_policy
    并对照最新的
    cfp_url
    重新验证。
  • 绝不能代表用户向任何系统提交内容。
  • 报告中最多引用标记的行;绝不能在输出中复制论文的大段内容。

Memory

记忆功能

This skill uses the shared
.paper-memory/
convention in the user's paper directory (full spec:
paper-memory-convention.md
).
  • At start: read
    .paper-memory/lessons.md
    and
    profile.yml
    . Use
    writing_preferences
    (style signature, spelling, voice) to set the target register, and lead with any
    recurring
    prose habits already recorded (e.g. "you habitually write passive contribution statements") so you watch for them first instead of re-explaining them.
  • At end: append durable findings in the shared format
    - [YYYY-MM-DD] (polish-prose | <scope>) pattern -> recommendation
    (via
    reflect-and-improve
    's
    reflect_log.py append
    , which dedupes and dates). A tell or habit seen across drafts is
    recurring
    ; a one-off fix is
    this-paper
    . Do not log routine one-shot edits.
  • Create
    .paper-memory/
    on demand if absent and offer to add it to the project
    .gitignore
    . It is local-only; never upload it or copy it into this repo.
本工具使用用户论文目录中的共享
.paper-memory/
约定(完整规范:
paper-memory-convention.md
)。
  • 启动时:读取
    .paper-memory/lessons.md
    profile.yml
    。使用
    writing_preferences
    (风格特征、拼写、语态)设置目标语体,并优先关注已记录的
    recurring
    写作习惯(如“你习惯使用被动语态的贡献表述”),无需重复解释。
  • 结束时:以共享格式
    - [YYYY-MM-DD] (polish-prose | <scope>) pattern -> recommendation
    添加持久化结果(通过
    reflect-and-improve
    reflect_log.py append
    工具,该工具会去重并标记日期)。跨草稿出现的特征或习惯标记为
    recurring
    ;一次性修复标记为
    this-paper
    。无需记录常规的一次性编辑。
  • 如果
    .paper-memory/
    不存在则自动创建,并提议将其添加到项目的
    .gitignore
    中。该目录仅本地存储;绝不能上传或复制到本仓库。