academic-paper-strategist

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Academic Paper Strategist

Overview

概述

This is the planning skill for Codex-based software engineering theses. Use it before drafting or finalizing a thesis from a real repository. Its job is to reduce hallucination risk, map project evidence to chapters, and define only the claims, figures, tables, and tests that can be justified by the actual codebase and supplied school format sample.

Companion flow:

```
academic-paper-strategist
```
- planning, evidence mapping, rewrite scope
```
academic-paper-composer
```
- content rewrite and final manuscript assembly
```
drawio
```
- redraw engineering-style thesis figures when required
```
playwright
```
- capture real runtime screenshots when the thesis needs running-system evidence
```
doc
```
- produce and visually check the final DOCX

Do not skip the strategist step when the user asks for a submission-ready undergraduate thesis from an existing project and draft.

这是一款基于Codex的软件工程论文规划Skill。用于从真实代码仓库起草或定稿论文之前，其作用是降低幻觉风险，将项目证据映射到各章节，并仅定义可由实际代码库和提供的学校格式样本支撑的论点、图表、表格和测试内容。

配套流程：

```
academic-paper-strategist
```
- 规划、证据映射、重写范围确定
```
academic-paper-composer
```
- 内容重写与最终文稿整合
```
drawio
```
- 必要时重新绘制工程风格的论文图表
```
playwright
```
- 当论文需要运行系统证据时，捕获真实运行时截图
```
doc
```
- 生成并可视化检查最终DOCX文档

当用户要求基于现有项目和草稿生成可提交的本科论文时，请勿跳过规划师步骤。

Core Rules

核心规则

Read project evidence before outlining. Prefer repository files, SQL, config, docs, controllers, services, entities, and the existing draft.
Treat the existing draft as untrusted input. Keep only what can be supported by project evidence.
If the user has already hand-edited part of a draft, treat that working draft as a protected artifact and plan around it instead of blindly replacing the whole manuscript.
If the user provides plagiarism, similarity, or AIGC detection reports, treat them as rewrite-priority signals, not as sources of truth about the project. Load
```
references/detection-report-rewrite-playbook.md
```
when this applies.
If the user provides a school format sample, load
```
references/zjkj-undergrad-thesis-format.md
```
first and treat it as the highest authority for structure and formatting.
If the task is to produce a final thesis from an existing draft, also load:
- ```
references/project-grounding-rules.md
```
- ```
references/finalization-task-rules.md
```
Load
```
references/draft-salvage-handoff-playbook.md
```
when the user wants to continue a partially edited draft, keep original figures/tables, or add running-system screenshots.
Never invent features, APIs, data tables, performance numbers, deployment scale, user scale, concurrency benchmarks, or test results.
Reframe "innovation" conservatively as engineering highlights, implementation choices, integration value, or maintainability benefits.
Only plan figures that are supported by code or project docs. Omit unsupported diagrams.
Keep the thesis compatible with an automatic table of contents and school-required front matter.

先读取项目证据再制定大纲。优先选择代码仓库文件、SQL语句、配置文件、文档、控制器、服务、实体类以及现有草稿。
将现有草稿视为不可信输入。仅保留可由项目证据支撑的内容。
如果用户已手动编辑部分草稿，将该工作草稿视为受保护的工件，围绕其进行规划，而非盲目替换整篇文稿。
如果用户提供查重、相似度或AIGC检测报告，将其视为重写优先级信号，而非关于项目的事实来源。此时需加载
```
references/detection-report-rewrite-playbook.md
```
。
如果用户提供学校格式样本，先加载
```
references/zjkj-undergrad-thesis-format.md
```
，并将其视为结构和格式的最高权威。

如果任务是基于现有草稿生成最终论文，还需加载：

```
references/project-grounding-rules.md
```
```
references/finalization-task-rules.md
```

当用户希望继续编辑部分完成的草稿、保留原始图表/表格或添加运行系统截图时，加载
```
references/draft-salvage-handoff-playbook.md
```
。
切勿虚构功能、API、数据表、性能数据、部署规模、用户规模、并发基准测试或测试结果。
保守地将“创新”重新定义为工程亮点、实现选择、集成价值或可维护性优势。
仅规划有代码或项目文档支撑的图表。省略无支撑的图表。
确保论文与自动生成的目录和学校要求的前置内容兼容。

Inputs To Gather

需要收集的输入

Repository root
Existing draft thesis (
```
.docx
```
,
```
.md
```
, or both)
School template or format sample (
```
.doc
```
,
```
.docx
```
, or
```
.pdf
```
)
Core evidence files such as:
- build file (
```
pom.xml
```
  ,
```
package.json
```
  , etc.)
- architecture docs
- business logic docs
- SQL schema / migration files
- entities / DTOs / controllers / services
Detection reports when available (
```
.pdf
```
,
```
.docx
```
, screenshots, extracted text)
Required deliverable path(s)

代码仓库根目录
现有论文草稿（
```
.docx
```
、
```
.md
```
或两者皆有）
学校模板或格式样本（
```
.doc
```
、
```
.docx
```
或
```
.pdf
```
）
核心证据文件，例如：
- 构建文件（
```
pom.xml
```
  、
```
package.json
```
  等）
- 架构文档
- 业务逻辑文档
- SQL模式/迁移文件
- 实体类/DTO/控制器/服务
可用的检测报告（
```
.pdf
```
、
```
.docx
```
、截图、提取文本）
所需交付物路径

Workflow

工作流程

Step 1: Ingest Constraints

步骤1：摄入约束条件

Record:

target school and thesis type
final deliverable format
whether the task is planning only or full finalization
whether the task must continue from a hand-edited working draft
whether the user wants original figures/tables preserved
whether real running screenshots are required
required output paths

If the user gives explicit source and destination paths, treat them as binding.

记录：

目标学校和论文类型
最终交付物格式
任务仅为规划还是完整定稿
任务是否必须从手动编辑的工作草稿继续
用户是否希望保留原始图表/表格
是否需要真实运行截图
所需输出路径

如果用户给出明确的源路径和目标路径，将其视为约束条件。

Step 2: Load School Format Authority

步骤2：加载学校格式权威文件

When a school sample is present, read

references/zjkj-undergrad-thesis-format.md

and extract:

required front-matter order
heading hierarchy
body typography and spacing
figure and table caption rules
reference formatting
appendix and acknowledgement rules
any page-numbering constraints visible in the sample

If the sample contains instructional text boxes or placeholder hints, mark them as "remove from final manuscript".

当存在学校样本时，读取

references/zjkj-undergrad-thesis-format.md

并提取：

所需前置内容顺序
标题层级
正文排版和间距
图表标题规则
参考文献格式
附录和致谢规则
样本中可见的任何页码约束

如果样本包含教学文本框或占位提示，标记为“从最终文稿中移除”。

Step 3: Audit The Existing Draft

步骤3：审核现有草稿

Classify each section into:

keep with minor edits
keep but downgrade claims
rewrite from project evidence
delete entirely
preserve as a legacy asset and restore if lost later

Always flag for removal:

process notes
template prompts
instructional text boxes
unsupported novelty claims
unsupported metrics or deployment claims
colored headings or hyperlink-styled text
diagrams that do not match engineering-paper style

Also mark:

original E-R figures the user wants to keep
original database per-table field-description blocks
user manual edits that must not be overwritten
sections where only a partial range should be replaced

将每个章节分类为：

保留并进行小幅编辑
保留但降低论点强度
基于项目证据重写
完全删除
保留为遗留资产，若丢失则恢复

始终标记需移除的内容：

流程笔记
模板提示语
教学文本框
无支撑的创新性论点
无支撑的指标或部署论点
彩色标题或超链接样式文本
不符合工程论文风格的图表

同时标记：

用户希望保留的原始E-R图
原始数据库每张表的字段描述块
不得覆盖的用户手动编辑内容
仅需替换部分范围的章节

Step 3A: Triage Detection Reports When Present

步骤3A：存在检测报告时的分类处理

When the user asks to lower similarity or AIGC risk and provides reports, read

references/detection-report-rewrite-playbook.md

At this stage, the strategist should:

extract the headline score and hotspot pages
map hotspots back to thesis sections
classify causes and rewrite intensity
tell the composer where to perform heavy structural rewrites versus light cleanup

当用户要求降低相似度或AIGC风险并提供报告时，读取

references/detection-report-rewrite-playbook.md

。

在此阶段，规划师应：

提取核心分数和热点页面
将热点页面映射回论文章节
分类原因和重写强度
告知composer哪些部分需要进行深度结构重写，哪些仅需轻度清理

Step 4: Build An Evidence Map

步骤4：构建证据映射

For each chapter, map every major claim to repo evidence:

Background / system positioning -> docs and project summary
Architecture -> package structure, config, controllers, services
Database design -> SQL schema and entities
Business workflows -> controllers, services, docs
Security / consistency mechanisms -> config, service logic, transactional code, locking, signatures, validation
Testing chapter -> only real screenshots, test classes, manual verification records, or observable system behavior

If a claim cannot be mapped to an evidence source, it cannot appear in the final thesis.

针对每个章节，将每个主要论点映射到代码仓库证据：

背景/系统定位 -> 文档和项目摘要
架构 -> 包结构、配置、控制器、服务
数据库设计 -> SQL模式和实体类
业务流程 -> 控制器、服务、文档
安全/一致性机制 -> 配置、服务逻辑、事务代码、锁、签名、验证
测试章节 -> 仅真实截图、测试类、手动验证记录或可观察的系统行为

如果论点无法映射到证据来源，则不得出现在最终论文中。

Step 5: Produce The Thesis Plan

步骤5：生成论文规划

Output a handoff package for the composer containing:

cleaned chapter outline
per-chapter evidence sources
claims allowed
claims forbidden
figures to redraw
legacy figures/tables to retain or restore
exact section ranges to replace if the user only wants partial rewriting
risky items requiring manual verification
runtime screenshot capture plan when screenshots are needed
when detection reports exist: a page-to-section rewrite matrix and a rewrite-priority list

When the handoff will drive a live DOCX revision, make it explicit enough that the composer can execute without re-deciding replacement boundaries, preserve lists, or screenshot targets.

The outline should normally include:

cover / declarations / abstracts / TOC
chapter 1 introduction
chapter 2 requirements analysis
chapter 3 overall design
chapter 4 detailed implementation
chapter 5 testing
chapter 6 conclusion
references
acknowledgements
appendices if needed

为composer生成交接包，包含：

清理后的章节大纲
各章节的证据来源
允许的论点
禁止的论点
需要重新绘制的图表
需保留或恢复的遗留图表/表格
若用户仅需部分重写，明确需替换的精确章节范围
需要人工验证的风险项
当需要截图时的运行时截图捕获计划
当存在检测报告时：页面到章节的重写矩阵和重写优先级列表

当交接包将驱动实时DOCX修订时，需足够明确，使composer无需重新决定替换边界、保留列表或截图目标即可执行。

大纲通常应包含：

封面/声明/摘要/目录
第1章引言
第2章需求分析
第3章总体设计
第4章详细实现
第5章测试
第6章结论
参考文献
致谢
必要时的附录

Step 6: Produce A Figure And Screenshot Plan

步骤6：生成图表和截图规划

Only the following figure types are allowed when the user asks for a software engineering undergraduate thesis:

system architecture diagram
functional module diagram
business process diagram
sequence diagram
E-R diagram
use case diagram
real running-system screenshots tied to actual thesis sections

For every planned figure or screenshot, define:

chapter placement
source basis in code/docs/runtime
labels that must appear
labels or components that must not appear
whether an old figure can be retained or must be redrawn
whether the screenshot needs seeded demo data first

All redrawn figures must use engineering-paper visual style:

white background
black or gray lines
no decorative icons
no infographic styling
no color-dependent meaning

当用户要求软件工程本科论文时，仅允许以下类型的图表：

系统架构图
功能模块图
业务流程图
时序图
E-R图
用例图
与实际论文章节关联的真实运行系统截图

针对每个规划的图表或截图，定义：

章节位置
代码/文档/运行时中的来源依据
必须显示的标签
不得显示的标签或组件
旧图表是否可保留或必须重新绘制
截图是否需要先植入演示数据

所有重新绘制的图表必须采用工程论文视觉风格：

白色背景
黑色或灰色线条
无装饰图标
无信息图表样式
无依赖颜色的含义

Existing-Draft Rework Mode

现有草稿重写模式

When the user asks for a final thesis from an existing draft:

do not start from a blank paper unless the draft is unusable
identify what to preserve and what to rewrite
create a section-by-section rewrite brief for
```
academic-paper-composer
```
explicitly note any unsupported content that must be deleted rather than softened
require the composer to operate on a copied draft or user-designated working draft, never the wrong file

When the user specifically asks to continue on a hand-edited draft:

record the working draft path and the protected backup/original path separately
plan replacement anchors by body heading style only
forbid TOC-based anchor matching in the handoff
identify which old figures/tables must survive the rewrite

When the user specifically asks to lower similarity or AIGC:

identify the smallest set of sections that dominates the score
prioritize Chinese narrative paragraphs over low-yield formal sections
prefer a few high-impact structural rewrites over broad shallow edits

use the rewrite modes defined in

references/detection-report-rewrite-playbook.md

当用户要求基于现有草稿生成最终论文时：

除非草稿无法使用，否则不要从零开始
确定需保留和需重写的内容
为
```
academic-paper-composer
```
创建逐节重写 brief
明确标记必须删除而非弱化的无支撑内容
要求composer操作复制的草稿或用户指定的工作草稿，切勿操作错误文件

当用户明确要求继续编辑手动修改的草稿时：

分别记录工作草稿路径和受保护的备份/原始路径
仅按正文标题样式规划替换锚点
在交接包中禁止基于目录的锚点匹配
确定哪些旧图表/表格必须在重写后保留

当用户明确要求降低相似度或AIGC风险时：

确定占主导分数的最小章节集合
优先处理中文叙述段落，而非低收益的正式章节
优先选择少量高影响力的结构重写，而非广泛的浅层编辑

使用

references/detection-report-rewrite-playbook.md

中定义的重写模式

References To Load As Needed

按需加载的参考文件

references/zjkj-undergrad-thesis-format.md

- school format authority

```
references/project-grounding-rules.md
```
- anti-fabrication and evidence rules
```
references/finalization-task-rules.md
```
- mandatory workflow for final DOCX delivery
```
references/detection-report-rewrite-playbook.md
```
- how to triage plagiarism / AIGC reports into a rewrite brief
```
references/draft-salvage-handoff-playbook.md
```
- how to plan partial replacement, legacy-asset retention, and runtime screenshots
```
references/chinese-call-prompt-templates.md
```
- copy-paste Chinese prompts for planning and handoff tasks

references/zjkj-undergrad-thesis-format.md

- 学校格式权威文件

```
references/project-grounding-rules.md
```
- 反虚构和证据规则
```
references/finalization-task-rules.md
```
- 最终DOCX交付的强制工作流程
```
references/detection-report-rewrite-playbook.md
```
- 如何将查重/AIGC报告分类为重写brief
```
references/draft-salvage-handoff-playbook.md
```
- 如何规划部分替换、遗留资产保留和运行时截图
```
references/chinese-call-prompt-templates.md
```
- 用于规划和交接任务的可复制中文提示模板

Example Prompts

示例提示语

根据当前仓库和学校模板，先给我做一个本科论文定稿规划，只保留代码里能证实的内容。

我已经手改初稿到正文 2.3 前了，帮我做 keep/rewrite/delete 矩阵，要求保留原数据库 E-R 图和每张表的字段说明。

这是查重报告和 AIGC 报告，先别直接改正文，先把热点页映射到章节并给出重写优先级。

继续在我现在的 working draft 上做规划，只替换 2.4 之后的正文内容，前面手改部分不要动。

帮我给论文补一个运行截图规划，说明每张截图对应哪个角色、哪个页面、哪个章节。

根据当前仓库和学校模板，先给我做一个本科论文定稿规划，只保留代码里能证实的内容。

我已经手改初稿到正文 2.3 前了，帮我做 keep/rewrite/delete 矩阵，要求保留原数据库 E-R 图和每张表的字段说明。

这是查重报告和 AIGC 报告，先别直接改正文，先把热点页映射到章节并给出重写优先级。

继续在我现在的 working draft 上做规划，只替换 2.4 之后的正文内容，前面手改部分不要动。

帮我给论文补一个运行截图规划，说明每张截图对应哪个角色、哪个页面、哪个章节。

Output Expectations

输出预期

Produce:

a thesis outline with up to 3 heading levels
a chapter-by-chapter evidence map
a keep / rewrite / delete matrix for the current draft
a figure/table/screenshot rebuild plan
a list of unsupported claims to remove
a handoff package for
```
academic-paper-composer
```
when reports are supplied: a detection-report triage summary with hotspot pages, mapped sections, and recommended rewrite intensity

Do not claim that the paper is submission-ready at this stage. That decision belongs to the composer + drawio + playwright + doc flow.

生成：

最多3级标题的论文大纲
逐章证据映射表
当前草稿的保留/重写/删除矩阵
图表/表格/截图重建计划
需移除的无支撑论点列表
提交给
```
academic-paper-composer
```
的交接包
当提供报告时：检测报告分类摘要，包含热点页面、映射章节和推荐重写强度

在此阶段请勿声称论文已可提交。该决策属于composer + drawio + playwright + doc流程的范畴。