thesis-risk-audit-writing

name

thesis-risk-audit-writing

description

Audit, rewrite, and risk-reduce Chinese undergraduate and adult-education theses across common domains for strict conservative advisors and reviewers. Use when a thesis is being rejected for being too academic, too AI-like, too engineering-like, too product-like, poorly structured, code-heavy, data-light, format-inconsistent, lacking field-specific conventional discussion rhythm, challenging reviewer authority, or not matching old-school bachelor-thesis expectations. Covers plagiarism/AIGC report handling, reviewer-aligned argumentation, chapter rhythm, domain-specific writing norms for software, mathematical modeling, data analysis, market research, management cases, education research, finance/accounting, code/data-to-prose conversion, figure/table support, DO/DO NOT rules, and final pass-oriented thesis audits.

Thesis Risk Audit Writing

Mission

Make the current thesis easier to pass a strict conservative reviewer. Optimize for reduced rejection risk, not originality signaling, technical flamboyance, or rhetorical ambition.

The target style is a conventional undergraduate thesis in its declared field: clear topic, ordinary chapter structure, enough field-specific evidence, restrained claims, no raw code/data dumps in正文, complete method/result support, and formatting that does not invite attention.

Core Principle

Do not challenge reviewer authority. If the reviewer expects an "八股" thesis, produce a disciplined "八股" thesis:

• familiar structure over novel structure;
• concrete system design over abstract theory;
• diagrams/tables over long unsupported prose;
• restrained claims over disruptive claims;
• verified references over impressive but unverifiable citations;
• pseudo-code,流程图,数据流图,ER图,截图,变量表,统计表,问卷维度表,指标体系表,分析框架图 over pasted source code or raw data dumps;
• local consistency over clever writing.

Default Workflow

1. Build context: read the thesis, task book/opening report if available, school template, accepted sample theses, domain type, and current reviewer complaints.
2. Audit risk: identify problems that may cause rejection, including structure, tone, claims, format, AIGC, duplication, missing figures, code-heavy正文, weak testing, and over-engineering.
3. Decide the pass strategy: preserve facts and research/materials, but downgrade risky claims and reshape the writing into conservative undergraduate thesis style for that field.
4. Rewrite by section, not randomly: fix chapter role, paragraph rhythm, diagrams/tables, citations, and transitions together.
5. Convert code to academic explanation: use algorithm description, pseudo-code, flowchart, data table, or figure instead of source code in正文.
6. Lower AIGC and duplication risk without inventing facts, citations, experiments, or data.
7. Verify final paper in rendered form: PDF/Word page layout, headings, captions, references, figure placement, table style, and section rhythm.

For the detailed end-to-end workflow, load references/audit-workflow.md. For non-software or hybrid papers, load references/cross-domain-writing-playbook.md.

Risk Categories

Authority-Challenge Risk

Rewrite anything that sounds like the thesis is trying to educate, overturn, or impress the reviewer:

• 首次提出, 颠覆, 革命性, 突破性, 完全解决, 显著优于, 理论创新;
• excessive criticism of existing tools, schools, teachers, templates, or traditional methods;
• over-selling AI, LLM, cloud-native, microservices, or trendy frameworks;
• claiming a large research contribution when the deliverable is a graduation system.

Preferred posture:

• 本文在现有技术基础上设计并实现...
• 系统主要面向...场景，完成...功能
• 该设计能够满足毕业设计阶段的基本应用需求
• 测试结果表明，系统主要功能能够正常运行

Structure Risk

Conservative reviewers expect chapter roles to be separated. For software/system-design papers:

• 绪论: background, significance, current situation, research content, paper organization.
• 相关技术: only technologies needed by the system; avoid long theory lectures.
• 需求分析: user roles, functional requirements, non-functional requirements, feasibility, use cases, business/data flow.
• 总体设计: architecture, module design, database conceptual design, data flow, deployment design.
• 系统实现: pages/modules, operation process, screenshots, key implementation explanation.
• 系统测试: test environment, test cases, functional tests, result analysis.
• 结论与展望: what was completed, limitations, future work.

If requirements analysis and overall design are merged, split them unless the school template explicitly does not.

For mathematical modeling, data analysis, market research, management case, education research, or finance/accounting papers, do not force this software chapter structure. Instead, follow the target field's conventional rhythm. Load references/cross-domain-writing-playbook.md.

Style Risk

Avoid writing that feels like a paper in a top conference or a product whitepaper. Use ordinary undergraduate thesis prose:

• explain what the system does;
• explain why this design is chosen;
• explain how modules cooperate;
• explain how data moves;
• explain how tests prove basic usability.

Do not over-theorize. Do not use fashionable terms as if they are the contribution.

Code-in-Body Risk

Do not paste source code in正文 unless the school explicitly requires it. Replace code with:

• pseudo-code table;
• algorithm/process description;
• flowchart;
• sequence/process diagram;
• database table;
• screenshot;
• appendix code fragment if absolutely needed.

For conversion rules, load references/code-to-prose.md.

AIGC and Duplication Risk

Use AIGC and duplication reports as audit input. Do not blindly rewrite the whole paper.

For AIGC reduction, follow the proven pattern from aigc-down-skill: locate high-risk paragraphs, preserve facts, break predictable AI patterns, reduce generic conclusions, avoid vague authority, and keep academic register.

For duplication reduction, rewrite around meaning and evidence:

• keep the cited fact or technical point;
• change structure, sentence order, and explanatory angle;
• add local system context;
• keep citation where the idea comes from;
• never fake references or data.

For detailed rules, load references/aigc-duplication.md.

Thesis DO

• Use a boring, complete chapter structure.
• Make each chapter answer one reviewer question.
• Put diagrams/tables near the prose they support.
• Use the field's traditional artifacts: software diagrams, modeling symbol tables, data-analysis statistics, market-research questionnaire tables, management frameworks, education survey/interview materials, finance/accounting indicator tables.
• Write section summaries with numbering if the thesis template uses numbered summaries.
• Keep claims proportional to the actual system.
• Prefer 设计与实现, 功能模块, 业务流程, 数据库设计, 测试结果 language.
• Cite real, relevant, verifiable references.
• Render the final PDF/Word and inspect actual pages.

Thesis DO NOT

• Do not paste large code blocks in正文.
• Do not paste raw datasets, raw statistical output, raw survey exports, or large code blocks in正文.
• Do not let code, Mermaid, TikZ, raw charts, or tool output look like development artifacts.
• Do not make the thesis sound like it is judging the teacher, school, template, or old methods.
• Do not write long abstract theory paragraphs that do not connect to the system.
• Do not rely on prose when a本科 thesis normally needs a figure or table.
• Do not overuse 首先/其次/再次, 综上所述, 具有重要意义, 前景广阔, 显著提升, 创新性地.
• Do not add unverifiable citations, fake test data, or invented deployment details.
• Do not keep a section only because it sounds advanced.

For a compact checklist, load references/do-dont.md.

Section Rewrite Heuristic

When rewriting a risky section, use this shape:

1. Purpose: what this section solves in the thesis.
2. System context: which module, user, data, or process it concerns.
3. Conservative explanation: what was designed or implemented.
4. Supporting evidence: figure, table, screenshot, test case, citation, or brief pseudo-code.
5. Limitation or boundary if needed: avoid overclaiming.
6. Transition: connect to the next section without repetitive summary.

Final Pass Criteria

A thesis is closer to pass-ready when:

• a conservative reviewer can recognize the expected thesis structure within one minute;
• requirements and design are clearly separated; -正文 has no distracting code blocks;
• every major system claim has a table, figure, screenshot, citation, or test result;
• AIGC/duplication high-risk paragraphs are targeted, not randomly rewritten;
• claims are modest and defensible;
• formatting does not draw attention;
• chapter rhythm feels like accepted undergraduate examples rather than an AI-generated technical report.