开题报告 / 任务书

先问清楚再写

动笔前向用户确认（缺什么问什么，不要自己编）：

1. 题目、专业、学校对开题报告的模板或字数要求（常见 3000–5000 字）
2. 系统类型（Web 管理系统 / 小程序 / App / 算法类）和技术栈
3. 已有的参考文献（没有就只给检索建议，不要编造文献）
4. 学校规定的进度节点（开题、中期、查重、答辩日期）

标准结构

1. 选题背景与意义：现实问题 → 现有做法的不足 → 本系统解决什么；理论意义、实际意义各 1 段，不写空话。
2. 国内外研究现状：按「方向/代表性系统或方法/不足」组织，每条观点对应一篇真实文献 [n]；最后一段总结现有不足，自然引出本课题。
3. 研究内容：列 4–6 个功能模块 + 关键技术点（如权限控制、数据统计、推荐算法），说明每个模块要做到什么程度。
4. 技术路线 / 研究方法：技术选型理由（为什么 Vue3 而不是 jQuery、为什么 MySQL）、系统架构一句话、开发方法（原型法/迭代）、测试方法。建议配一张技术路线图（用 mermaid 草稿，用户再画正式图）。
5. 预期成果与创新点：创新点要具体、可验证，1–3 条即可，不要夸大成「国内首创」。
6. 进度安排：表格，按周或按月，和学校节点对齐，留出查重和修改时间。
7. 参考文献：按 GB/T 7714-2015（见 thesis-writing 技能）。

任务书

任务书比开题报告短，通常包括：设计内容与要求、主要技术指标（如「支持 3 种角色」「列表页支持分页查询」）、进度、参考资料。技术指标写可量化、可验收的。

红线

• 不编造文献、数据、调查结果；用户没给的文献只能写「建议检索：知网关键词 xxx」。
• 不承诺论文能过查重；引用要标注。
• 遵守学校关于使用 AI 辅助写作的规定，提醒用户自己核对和改写。