skill的选择以及如何让ai更高效完成论文撰写与ai降重与毕设实现

skill的选择
skills准备（已完成直接下一步）
https://github.com/the-shy123456/thesis-docx
https://github.com/DQXCJ-a11y/thesis-skill-hub

材料准备
“E:\基xxxxxxx.docx” 这是之前ai跑的初稿，但是需要结合现在毕业设计修改
“E:\1本科任务书.docx”
“E:\2本科开题报告.docx”
“xxxx”这是初步生成的毕业设计的新方案，如果有新的功能你觉着可以加也列出来供我参考
“E:\（论文）格式模板.docx”

注意事项：
1.论文必须按照最后决定的毕业设计来生成
2.论文必须真实，所用技术必须得是真实的
3.毕业设计的节点规划已经是我笔记本最大上限，如果有更好的修改方案也能向我提供，但是我的节点数得是4个
4.”E:\（论文）格式模板.docx”
按照模板上的要求来修改论文

AI助手的工作方式
工作流程
整个项目我遵循了一套固定的工作模式：

理解需求：先问清楚要做什么，为什么做，约束条件是什么
收集信息：扫描项目目录，读取现有文件，了解当前状态
方案对比：给出2-3个可选方案，说明每个方案的优缺点
细化执行：确定方案后，分解为可执行的步骤
生成产物：代码、脚本、文档、配置——每个都有明确的用途
写代码的习惯
一个文件只做一件事：7个部署脚本各司其职，不是一个大而全的all-in-one
参数化设计：03-system-init.sh接受hostname参数，一份代码适配所有节点
文档即规范：README.md先行，确定架构和接口后再写代码
可重复执行：部署脚本可以反复运行，不会因为重复执行而出错
写文档的习惯
用表格对比方案：可视化降低用户的决策成本
先给结论再给原因：节省阅读时间
关键数字精确：IP地址、内存分配、端口号——不能含糊
Markdown优先：纯文本、可版本管理、可转为任何格式
项目的文件组织哲学
E:/
├── shulian-zhidiao/ # 应用代码——独立可运行的项目
├── openstack-deploy/ # 部署脚本——独立可复用的工具包
├── openstack-deploy-history/ # 讨论记录——决策过程的归档
├── *.docx # 论文文档——最终的交付物
└── *.md # 知识笔记——平时的积累
这个组织方式的核心思想：代码、配置、文档、讨论四个维度完全分离，互不干扰但通过路径引用关联。

经验总结与反思
做得好的地方
方案对比先行：每次技术选型都给2-3个方案，用户做选择题而非填空题
硬约束优先处理：16GB内存是硬上限，所有方案都在这个约束下展开
文档与技术同步：部署文档、使用手册、论文在同一周期内完成
工程化思维：论文用Markdown+Python构建而非纯手工排版
可以改进的地方
版本控制：项目代码和论文源文件应该用Git管理，可以追溯每版修改
自动化测试：部署脚本缺少自动化验证环节，依赖人工检查
更多交互确认：某些技术决策（如前端框架选择）可能应该给用户更多选项
给后来者的建议
如果你的毕业设计也涉及类似的工程实践，建议：

先确定硬约束（硬件资源、时间、技术要求），再展开方案
每个技术决策都要有”为什么选这个而不选那个”的记录
把部署脚本当作代码来写，而不是临时的一次性脚本
论文写作和工程实践同步推进，不要等代码写完再动笔