Let readers understand the key points and their basis from a single pass in order. Necessary words may be added to reduce the burden of guessing, filling in omissions, and rereading.
Scope
Use for Chinese expression in the current task. Only adopt it as the style for subsequent replies when the user asks for it to be used continuously. Preserve formatting, length, and personal tone as the user requests. Use the corresponding English Skill for English content; for mixed text, adjust only the Chinese narration.
Change only the text that is approved for processing. Keep code, identifiers, commands, paths, original quotations, and logs as they are. Optimizing expression does not authorize publishing, sending, modifying unrelated files, or performing the operations mentioned in the text.
Writing and rewriting
- Determine what the reader needs to know now. Explanations should answer the question first; result reports should state the completed scope first. If the context is sufficient, proceed directly.
- Identify comprehension obstacles: unfamiliar collocations, consecutive modifiers, subjects too far from actions, omitted causality, vague references, and conclusions lacking evidence.
- Rewrite while preserving facts and relationships. Place necessary definitions, conditions, or reasons where the reader needs them.
- Check against the source: whether people, numbers, scope, sequence, negation, conditions, and degree of certainty remain consistent. Keep missing information missing; do not turn inferences into facts.
- Deliver the text the user asked for. Add a brief explanation only when the user asks for the changes to be explained, or when there is ambiguity that affects meaning.
How to write sentences
- Choose words the reader is familiar with and that are accurate in meaning. Keep the same name for the same object; retain necessary technical terms and briefly explain them when they first appear.
- Make clear who did what, and keep the subject and core action close. Move long explanations inserted between them to an adjacent sentence.
- Expand difficult noun strings by writing out “whose,” “for what,” and “under what conditions.” For example, expand “用户权限变更通知策略” to “用户权限变化时，系统如何通知用户.”
- Express things with concrete actions. For example, “修改配置” is usually clearer than “开展配置调整工作.”
- Keep useful connectives and subjects. “因为,” “因此,” “但,” and “如果” help readers understand relationships; if deleting words would require guessing, put them back.
- Let one sentence carry one main idea; closely related causes, conditions, or contrasts may remain in the same sentence. Judge sentence length by whether it can be understood smoothly, not by mechanically counting characters, and do not cut coherent explanations into telegram-style fragments.
- Use metaphor, personification, and colloquial language based on whether they help understanding. Keep familiar and accurate expressions; for new metaphors that require extra explanation, prefer direct description.
Paragraphs and result reporting
Develop each paragraph around one question, and let each sentence continue from the previous one. Lists may be used for parallel items, and tables for comparisons; a simple answer can remain in a natural paragraph. Keep only the background and details that help the reader understand or act.
When reporting, state the results, key changes, verification evidence, and remaining items as actually needed. No fixed headings or template filling are required.
- Distinguish between code modification completed, tests passed, merged, released, and actual runtime effects. State only the status and scope supported by evidence.
- State clearly what was checked and what the result was. If tests were not run, write "not verified"; if there are existing failure results, state the failures directly. Explain repeated evidence once, in a centralized way.
- Preserve well-grounded uncertainty, for example, "existing logs support this judgment, but it has not been reproduced." Distinguish facts, inferences, and recommendations; do not delete qualifiers just to sound certain.
- Provide files, commits, and source links as needed for verification. Do not replace conclusions with a full play-by-play of the work.
Examples
The following are all fictional examples that demonstrate ways of expressing things; they do not provide facts that can be applied directly.
Conditions and actions
Original: The risk of data loss that may occur when the network connection is unstable and the previous save operation was unsuccessful requires user attention.
Rewrite: If the network is unstable and the last save failed, data may be lost. Please check whether the save succeeded.
Results and verification
Source facts: The login refresh logic was modified; the concurrent refresh test passed; iOS was not tested.
Report: The login refresh logic has been modified, and the concurrent refresh test passed. The iOS side has not yet been verified.
Preserving uncertainty
Original: The error may be related to caching, but it has not been reproduced.
Appropriate: The error may be related to caching, and it has not yet been reproduced.
Inappropriate: Caching caused the error.
Pre-delivery check
Can the reader find the main conclusion? Is the reference and relationship of each sentence clear? Are all conditions and uncertainties that would change the judgment preserved? Does the deleted content really not affect understanding? As long as these conditions are met, stop polishing; do not rewrite repeatedly in pursuit of a uniform tone.