yuwen-publish-precheck: a pre-publish compliance checker for Douyin, Xiaohongshu and WeChat Channels

What yuwen-publish-precheck checks, and for whom

Platforms do not tell you in advance which sentence will be flagged. The README frames the core problem as a loop: a bland topic gets no traffic, a spiky topic gets a violation notice. Its claim is narrower than "avoid all risk". It says platforms mostly block a way of expressing something rather than the subject itself, and that for almost any aggressive topic there is a compliant popular post already collecting views. The tool's job is to find phrasing that keeps the punch and drops the violation.

It targets text, not footage. The stated scope is spoken scripts, articles, image-text copy, subtitles and titles for Douyin, Xiaohongshu and WeChat Channels. The README lists three industry packs: general, medical health, and finance. Education, mother-and-baby, and beauty are named as roadmap items, not shipped coverage. Kuaishou is also roadmap only.

The audience is a creator or operator who writes the copy themselves and wants a second pass before publishing. It is not a moderation system for a platform, and it is not a filter for user-generated content at scale.

Two-layer detection: word hits are clues, context decides

The architecture is a pipeline. Your draft goes through a script-based lexical pre-check that locates candidates in seconds, then an AI semantic pass that reads the surrounding context and returns a verdict. If the verdict is "can publish", you get a pre-publish checklist. If it is "needs changes", the tool produces meaning-preserving rewrites with sentences you can paste, and then re-checks the rewrite.

The README is explicit about why the lexical layer alone is not the product: a word hit is a clue, not a verdict. Its example is the phrase for earning over ten thousand a month. In a personal story it is fine; attached to a course sales link it is a violation. A banned-word list cannot separate those two cases.

The rules behind the semantic layer are 42 in total, anchored to the Advertising Law, special documents from the Cyberspace Administration and the health authority, platform rule centers and community conventions. Those map to 72 quoted passages with links and verification dates. The README also states that the judgment scale was calibrated against 38 real spoken scripts that platforms actually let through, and that these average 0.8 lexical candidates per script.

One design choice is worth flagging. The calibration set is 38 scripts that passed. That reduces false positives on ordinary personal content, but it is a small sample for a judgment scale, and the README does not describe how those scripts were selected or whether they cover the medical and finance packs.

Installing the skill and running a first review

The README offers two install paths. The first is to send an instruction to an agent that supports Agent Skills, such as Cursor, Codex or Claude Code. The second is a manual clone into the tool's skills directory. The README gives this line, meant to be pasted into the agent's chat rather than run in a shell:

请安装这个 skill：https://github.com/yuwen-cool/yuwen-publish-precheck.git

For the manual route the README gives a clone target under `~/.cursor/skills/`:

git clone https://github.com/yuwen-cool/yuwen-publish-precheck.git ~/.cursor/skills/yuwen-publish-precheck

The README states the project has zero dependencies beyond Python 3 and runs entirely locally, with drafts and personal data not uploaded to any third party. After installation, the first prompt is a review request. The README suggests this one:

用 yuwen-publish-precheck 审一下这篇口播稿能不能发抖音：（贴上稿子）

On first use the README says the skill spends about a minute building a profile: which platforms you post on, your industry, and your business model. Later reviews do not ask again. If you do not know where to start, the README lists a simple "what can you help me with" style opening prompt among its suggestions.

The worked example shows what a rewritten draft looks like

The README walks through a product-selling spoken script. The original claims the speaker lost eight jin in two weeks eating a enzyme plum, calls the price the lowest on the whole internet, says official channels cannot get that price, and asks viewers to add a WeChat ID.

The verdict rejects the draft for Douyin and Xiaohongshu. Three findings are marked as must-fix. The weight-loss claim is a food product claiming a slimming effect with a time-bound result, tagged M02 at very high risk. The price claim is an absolute term plus an unverifiable price assertion, tagged R01, R02 and R15. The WeChat ID is off-platform diversion, tagged R05 and described as the red line with the highest penalty rate on Xiaohongshu.

The tool also separates a note from a violation. It states that the word WeChat itself is not a violation and does not need to be avoided; what violates is the act of adding an ID and directing traffic off-platform. That distinction is the kind of thing a banned-word list gets wrong in both directions.

The rewrite keeps the hook and the two-week time frame, drops the guaranteed weight result, replaces the absolute price claim with a group-buy price the speaker considers good value, and points to the product link below instead of a personal account. The README says the rewrite returns zero lexical hits on re-check and comes with a per-platform pre-publish checklist covering cart links, marketing labels and the Pugongying reporting process. The README also states plainly that changing the wording while keeping the claim is skin-swapping and will not be done.

Your local rule library, and the survivorship-bias guard

The second half of the design is a feedback loop stored on your machine. You tell the AI one sentence, and it writes to a `data/` directory as plain text that you can read and edit. The README describes four behaviors. A phrase you want watched goes into a blacklist and is scanned next time. A phrase that is normal in your niche goes into a whitelist to cut noise, while commercial scenarios are still judged normally. A phrasing that got blocked versus one that passed goes into a safe-expression library marked as field-tested, and is consulted first when rewriting. An existing banned-word list you have can be imported in bulk. There is also a review flow for a throttled post: four categories of attribution, a stored case, and a lesson turned into a rule.

The guard against copying big accounts is the part worth reading twice. When you say a large account posts the same thing without being banned, the tool first tries to explain the case using the rules. If the explanation holds, the case can be stored as a reference. If it does not, the tool tells you the risk tolerance of a large account is not yours, and copying it means testing on their behalf. That is a reasonable stance, though it is a judgment call by the model rather than a deterministic check, so the quality of that explanation is only as good as the underlying rule set.

Where it stops: no guarantee, no evasion, no rollback docs

The README's boundary section is unusually direct. It does not promise a 100 percent pass rate, and says platform decisions depend on internal models and account state that no outside tool can see. "Can publish" means no blocking issue was found within the scope of that check. The project also refuses to provide homophone substitutions, character splitting, obfuscation or any other review-evasion technique, on the argument that those trade a small risk for a larger one. It also debunks common self-censorship myths, stating that official sources have clarified that words like "earn money" do not need to be written as a homophone, and that homophone variants are instead watched separately by platforms.

Two gaps are worth naming. The README does not document rollback for an upgrade that goes wrong; it describes conflict handling in which git aborts the update and prompts you, but not a procedure for undoing a pull that succeeded. And the repository's last push was on 2026-08-11, so the rule quotes and their verification dates are as current as that commit, not as current as today. If a platform rule center changes text, nothing in the README says how quickly the quotes are refreshed.

How it differs from a banned-word scanner

The obvious alternative is a static banned-word list, the kind sellers distribute as a spreadsheet. The difference is architectural, not a matter of list length. A word list matches strings and returns hits; it has no way to know that the same phrase is fine in a personal anecdote and a violation next to a sales link. It also cannot tell you that a word you were told to avoid is actually fine, which is why self-censorship myths survive: a list has no mechanism to remove a false entry once it spreads.

yuwen-publish-precheck puts a semantic pass after the lexical pass and attaches a cited rule to each finding, so a finding can be argued with. The trade-off is speed and determinism. A script scan is fast and reproducible; a model reading context is slower and can be wrong in ways a string match cannot. The README's 38-script calibration is the project's answer to that, but it is a calibration, not a guarantee, and the README does not publish a measured false-positive or false-negative rate.

A second alternative is manual review against each platform's rule center. That is more authoritative but you have to read the rule text yourself and remember which clause applies. This project's value is that the 72 quotes and their verification dates sit next to the finding, so a human can check the source instead of trusting the verdict.

Editorial conclusion

Adopt it if you publish Chinese short-video or image-text content on Douyin, Xiaohongshu or WeChat Channels and want a rule-cited second pass before you hit publish. Skip it if you need coverage for Kuaishou or a vertical such as education or beauty, which the README lists only as roadmap items, or if you want a tool that guarantees approval. Before relying on it, open references/ and confirm that the cited rule text and its verification dates still match what the platform rule centers currently say.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yuwen-cool/yuwen-publish-precheck on GitHub