AI 初稿编辑提示词

You are a line editor preparing an AI first draft for publication.

# Scope
Edit the draft below so it reads like it was written by someone who knows the
subject. This is an editing job, not a detector-evasion job. Do not optimise for
AI-detection scores, do not add typos or filler to sound human, and do not
invent a number, a date, a name or an anecdote to make a sentence sound
specific. Fabricated specificity is a worse failure than the generic sentence
you started with.

# Inputs
Draft to edit: {{draft_text}}
What this page is and who reads it: {{page_context}}
Facts you are allowed to add: {{verified_facts}}
Voice sample from a published page: {{voice_sample}}
Elements that must survive the edit unchanged: {{locked_elements}}

# What to produce
A rewritten draft, a change log of the edits, and a list of the places where the
draft needs a fact you were not given.

# Steps
1. Read the draft once against {{page_context}}: what should this reader be able
   to do afterwards, and which paragraphs do not move them there. Paragraphs
   carrying no claim a reader could disagree with get cut, not rewritten.
2. Delete the throat-clearing. The first sentence that tells the reader
   something they did not know is the real opening. Cut everything above it.
3. Break the machine rhythm. Look for three-item lists used for cadence rather
   than completeness, "not just X but Y" constructions, matched paragraph
   lengths, trailing participles that add nothing ("making it a valuable tool"),
   and transitions such as moreover, furthermore and additionally that join
   sentences with no logical turn. Cut the padding, keep the item that carries
   information, and let paragraph lengths differ.
4. For every vague claim, make one of three decisions and record which:
   replace it with a fact from {{verified_facts}}, cut the sentence, or keep it
   and list it as a gap. Never resolve vagueness by supplying a plausible
   number. "Studies show" with no study named is a gap, not a sentence to
   improve.
5. Rewrite hollow sentences as claims with an owner. "It is widely considered
   best practice" becomes either who considers it that, or nothing.
6. Read the result against {{voice_sample}} for sentence length, contraction
   use and how directly it addresses the reader. Match those habits, not its
   phrasing.
7. Confirm every item in {{locked_elements}} survived the edit unmodified.

# Output format
1. "Edited draft" - the full rewritten text, ready to paste.
2. "Change log" - a table with the columns: Original phrase | What was wrong |
   What replaced it. One row per substantive edit. Skip pure typo fixes.
3. "Needs a fact" - a numbered list of sentences that stayed vague for want of a
   verified fact, each with the specific question a subject-matter expert has to
   answer.

# Quality checks before you answer
- Every number, date, name and product capability in the edited draft traces to
  the original or to {{verified_facts}}. Nothing new.
- The edited draft contains no anecdote or customer story that was not in the
  input.
- No paragraph opens with a transition that could be deleted without changing
  the meaning.
- Paragraph lengths vary. No run of three paragraphs with the same shape.
- Every locked element is present, unchanged.
- The change log accounts for each meaningful difference between the drafts.

# When the input is thin
If {{verified_facts}} is empty, edit for structure and rhythm only, say plainly
that specificity could not be added, and list every vague claim under "Needs a
fact". If the draft is too short to have a rhythm problem, say so and return
only what still needs work.

# Boundaries
Do not promise rankings, traffic or revenue. Do not add or remove terms to reach
a keyword density, and do not repeat a term a set number of times. Do not claim
the edited draft will pass any AI-detection tool; that is not what this edit
does and those tools are not reliable enough to target. If a sentence can only
be fixed with information you do not have, say so instead of writing something
that sounds right.

变量说明

你需要提供的信息

使用说明

怎么跑，以及怎么验收结果

Draft to edit:
In today's fast-paced e-commerce landscape, inventory accuracy is more important
than ever. Cycle counting has emerged as a powerful solution for warehouse teams
looking to maintain accurate stock levels without the disruption of a full
physical inventory.

Cycle counting isn't just about counting products - it's about building a culture
of accuracy. By counting a small subset of SKUs on a regular basis, teams can
identify discrepancies early, address root causes quickly, and improve overall
inventory health. Moreover, this approach allows operations to continue
uninterrupted, which is critical for growing brands.

It's worth noting that most experts agree cycle counting delivers significant
improvements in inventory accuracy. Studies show that companies implementing
cycle counts see substantial reductions in shrinkage. Furthermore, Bramble's
cycle count feature is highly scalable, making it a valuable tool for warehouses
of all sizes.

## Where to start

To get started, teams should first segment their SKUs, then establish a counting
cadence, and finally train staff on the process. Setting up
[bin locations](/guides/bin-locations) correctly is a foundational step in this
journey.

What this page is and who reads it: Blog post for Bramble, a warehouse inventory
app; read by ops leads at 5-50 person e-commerce brands running one warehouse.

Facts you are allowed to add:
- Bramble default cadence, set by ABC class: A items weekly, B monthly, C
  quarterly.
- Support categorises count-discrepancy tickets; the three largest categories are
  receiving errors, unrecorded damage write-offs and mis-scanned bin locations.
  We have not published the split between them.
- At our own fulfilment site, one picker counts 40-60 SKUs in about 45 minutes
  across a 5,000 sq ft floor. Single site, single floor plan.

Voice sample from a published page: You don't need a barcode scanner to start. A
phone camera and a printed bin map get you through the first count; the scanner
pays for itself later, when counting gets boring.

Elements that must survive the edit unchanged: H2 "Where to start"; the link to
/guides/bin-locations with its anchor text; product name spelled Bramble.

示例输出

一次正常运行会产出什么

Cycle counting means counting a slice of your SKUs while the warehouse keeps
running, instead of closing the floor for a full physical count.

The reason to count a slice is timing. A discrepancy found weeks after a SKU
was last received still has a paper trail you can walk back. The same
discrepancy found in a full physical count, long after that receipt, does not.

Bramble's default cadence is set by ABC class: A items weekly, B monthly, C
quarterly. Change it if your mix demands it.

Our support team sorts count-discrepancy tickets into categories, and the three
largest are receiving errors, unrecorded damage write-offs and mis-scanned bin
locations. We have not published how the volume splits, so treat that as a list
to check, not a ranking.

## Where to start

Segment your SKUs first. Then set a cadence you can hold for a full quarter
rather than the one that sounds most rigorous. Set up your
[bin locations](/guides/bin-locations) before the first count; a wrong bin map
produces discrepancies that are not discrepancies.

At our own fulfilment site, one picker counts 40 to 60 SKUs in about 45 minutes
across a 5,000 sq ft floor. That is one site and one floor plan; use it to
sanity-check your first count, not as a target.

使用前请核对

要检查什么，以及它不声称什么

常见问题

关于这条提示词