当前位置：首页 > news >正文

B2、进度汇报（— 25/06/16）

news 2025/7/11 6:18:39

本文档汇总了各成员在 2025 年 6 月 1 日 ~ 6 月 16 日（第十八周星期一，期末答辩）完成的工作。
我们在 6 月 16 日上午提交了全部检查材料，在当天下午完成了期末答辩。严格地说，诤略参谋项目已竣工。

图-B2.1_创新项目实训成绩

知识学习/项目管理上的进度

防不胜防

灾难级进度管理。在 6 月 9 日下午（第十七周星期一），我们收到了“2025年-创新实训结题答辩通知.pdf”，该文档要求我们在 6 月 13 日下午（第十七周星期五）、6 月 16 日上午或 6 月 16 日下午（第十八周星期一）中选一个时间段参加期末答辩。并且在参加答辩前通过邮箱向某位老师提交以下材料：

.pdf 格式的所有个人博客与项目博客。
软件操作手册。
软件演示视频。
作品的源代码等资源文件。
代码说明文档，“确保通过文档能完整查阅源代码，确定源代码的原创性和真实性”。
每个组员的分工说明。

在其他文档中自我反省前，我要批评——授课教师们顶着“项目实训”的课程名和授课经验，却未体现好的“项目”（项目管理）意识。我认为他们比我更需要参加同期的“软件项目管理”课。具体表现在：

发布的信息经常模糊不清、有误导性或有歧义。两个例子——
1. 每次提到博客检查要求时都说“不能集中在 17、18 周完成”，哪怕在最终的“2025年-创新实训结题答辩通知.pdf”通知中仍然说“请确保每个组员的个人博客数量不少于 8 篇，且 [a] 后期的博客不是集中在 17、18 周完成”。“不能集中”意味着“[b] 可以有少量博客在第十八周完成”，否则该直接说“所有博客在第 17 周及以前完成，且不能集中在第 17 周内完成”。因为一直说期末答辩之前会先检查博客数以判断小组能否参与期末答辩，又因为检查肯定发生在博客提交时限之后（也可能是部分并行，但检查结果出炉的时刻一定晚于博客提交时限），可以得出“[c] 期末答辩开始时刻 > 博客检查完成时刻 > 博客提交截止时刻”。根据历来经验，大事件的截止时刻通常也是某一天的 24:00，老师们也要上下班，新的大事件开始前要先布置、很难和其他大事件挤在一天里完成，可以得出“[d] 期末答辩开始日期 > 博客检查完成日期 ≥ 博客提交截止日期”。假设博客提交和博客检查（部分）并行，会出现一些问题，小概率事件是老师在 $t_1$ 时刻检查了 $s_1$ 的博客数，判定通过，但 $s_1$ 在 $t_2 > t_1$ 时刻把这篇博客删除了；更大的问题是这种情况下老师需要反复检查同一个人的博客数，增加了检查总耗时（ $t_1$ 时刻检查 $s_2$ 发现数量不足，提交截止后 $t_3$ 再度检查 $s_2$ 的博客最终情况，检查了两遍。如果完全串行、等到提交截止后再开始检查，对所有人都只需检查一遍）。根据教师们的偏好和过往体现的工作效率，其实可以断定会完全串行工作。就算并行也节省不了多少时间。所以“[e] 期末答辩开始日期 > 博客检查完成日期 ≥ 博客检查开始日期 > 博客提交截止日期”。又因为 [b]，写博客也需要时间（至少留一天吧），所以“[f] 期末答辩开始日期 > 博客检查完成日期 ≥ 博客检查开始日期 > 博客提交截止日期 > 第十八周星期一”。我们很想估算期末答辩开始日期，估算中最重要的参考值是博客提交截止日期。你确实可以说这个日期从来没明确声明过，完全可以是“第十八周星期二”，但是 [g] “18 周”这个字眼在一切通告内都与“17 周”并列出现，我们很清楚整个第 17 周都是可用时间，那么我们自然倾向于认为第 18 周与其等同。并且，[h] 通告内专门指出“不能集中在第 18 周内完成”，这暗示着其实没有这条硬性要求的话第 18 周的可用时间应该足够用于编写多份博客，那提交截止日期就不该是“第十八周星期二”这样早。而且 [i] 老师从未明确声明提交截止日期，只说第十八周截止，根据经验大家自然会倾向于认为提交截止日期是第十八周星期五或第十八周星期日。其实 [g] [h] [i] 很牵强，不是很有说服力的理由，但是与下图（[j]）结合、“互相印证”就要命了。下图说“[j] 第 19 周起全面进入《项目实训》环节”“所有专业课程都要在 18 周（含）之前完成考试”。虽然事后证明这里的意思是第 19 周起开始暑期项目实训（项目实训分为学期内的创新项目实训和暑期项目实训，我们参与的是学期内的创新项目实训），但我敢说所有参与创新项目实训的学生都会理解成“第 19 周开始专门留时间全面展开创新项目实训的期末答辩，为此学校要求在第 19 周前把期末考试都考完、腾出时间”。所以我们会理解成“[k] 期末答辩开始日期 ≥ 第十九周星期一”。我们现在有一条时间上较为严格的不等式“[l] 期末答辩开始日期 > 博客检查完成日期 ≥ 博客提交截止日期 ≥ 第十八周星期一”和引入了合理推测的不等式 [k]。然而“2025年-创新实训结题答辩通知.pdf”通知中提供的期末答辩开始日期只有“第十七周星期五”与“第十八周星期一”，无论是 [k] 还是 [l] 都不满足！因为 [j] 是教务处发的，所以不满足 [k] 勉强可以不归咎于授课老师，但不满足 [l] 反映的问题是绝对跑不了的。为什么不直接说“必须在第十八周前完成所有博客，并且不能集中在第十七周内完成”呢？
2. “2025年-创新实训结题答辩通知.pdf”通知中要求提交“作品的源代码等资源文件和代码说明文档”，说“确保通过文档能完整查阅源代码，确定源代码的原创性和真实性”。“完整查阅”的具体定义是什么？是“老师不需要看任何源代码文件，因为每一行源代码都在此文档里有副本”吗？

有时突然追加或变更检查标准，并且不留足够的反应时间。原因大概分两种，要么是教师们没有在定基线标准时仔细思考，没有像对抗网络和“诤略参谋”一样从对方的角度检查标准的质量、合理性与全面性；要么是这些突发新标准是教师拍脑袋临时起意，“这个加上好像也不错哎”“这个也加上吧”“这个看着像个样子/加上这个看上去更专业”。追加原因只是“觉得‘不赖’，‘挺好’”，没有思考这些新标准的必要性以及它们带来的新工作量。我的揣测确实偏恶意，这恶意来自我的愤怒，因为我认为不该犯这些问题，犯这些问题只能说明不用心——哪怕不是这两种原因。此外我完全无法解释为什么突然追加新标准时不留足够的反应时间。我认为任何一个人在向其他人突然追加新标准时都会预留反应时间，这就像呼吸一样自然，你在无意识中就会做好这件事。
1. 上面洋洋洒洒的“第十八周问题”也可以算作这里的例子。
2. 博客包括项目博客和个人博客两种，教师一直强调的是“在某个时限前提交至少多少篇个人博客”，从未在任何聊天记录或标准文件里提出对项目博客在数量和时间上的要求。然而在 4 月 29 日（第十一周星期二），老师在群里提醒同学们注意中期检查、之后与同学们交流时突然提出“项目博客相对宽松，只要不是全部发表在本周，就可以”——这句话、这个新标准是在第十一周星期二下午四点左右冒出来的、可这句话里的“本周”指的是“第十一周”。这个新标准说“必须在第十一周星期一 00:00 前至少发表一篇项目博客，否则项目中期检查不通过，直接被斩杀”，那这个标准不应该在第十一周星期一 00:00 前提出吗？我完全无法理解一个人怎么能做到在第十一周星期二约 16:00 的时候说出这句话同时不察觉到任何不对劲。这个新标准最终没有落实，如果落实了，教师留出的反应时间会是幽默的 $- 40$ 小时，没有在第十一周前发表任何项目博客可也没违反任何旧要求的项目组会在新标准出现的一瞬间被斩杀。我只感受到了恶意。

要求编写并提交的材料内容重叠或不合理，强行制造工作量。
1. 再聊聊“2025年-创新实训结题答辩通知.pdf”通知中要求的“通过文档能完整查阅源代码，确定源代码的原创性和真实性”的“代码说明文档”。首先，在距离答辩一周时突然追加这个文档要求，“完整查阅源代码”，源代码有几万行，这要求合理吗？就算不考虑工作量和时间问题，按照这个要求写出来的文档能有什么可读性？其次，如果目的是“查阅源代码、确定源代码的原创性和真实性”，为什么不看项目博客和个人博客呢？按照教师们的要求，个人博客就是核心代码、思路、过程的体现啊？这难道不能体现原创性和真实性吗？为什么又要写一份大合集呢？意思是说，哪怕教师们对个人博客提了一堆要求，实际上他们——因为耐心、时间、精力等限制——根本不会阅读这些个人博客？我希望不是因为他们连点开个人博客的链接的耐心都没有。总之，“源代码等资源文件”“代码说明文档”“项目博客”“个人博客”内容高度重合，我们在一遍又一遍地描述相同的事物，我们在浪费生命。我们的结果被提了一堆要求，可当结果真的出现，好像又无人在意……好歹是你要求的，你认真浏览一遍结果也行啊。这让我沮丧。
2. “作品的演示视频”“软件操作手册”“期末答辩演示”也是重的。答辩演示已经能保证软件完整运行。不想说了。这些冗余可能是为了留档和多重检查，但准备这些东西让人心累。

期末答辩

我们在 6 月 16 日下午参加期末答辩。一个小组至少要给四个老师完整演示一遍程序。老师的评价取平均，映射到不同档位，就得到了项目整体的和个人的成绩。其他课的老师临危受命，就成了答辩审查官。答辩出乎意料地宽松，老师不看任何具体代码，不问任何具体实现和设计思路，只需要演示一遍系统功能、每个人粗略说一下自己的分工。

挑灯幕僚

为了填任务书里的“小组名称”这个空，我们之前对着“诤略参谋”凑了个“挑灯幕僚”。6 月 9 日 ~ 6 月 16 日……真挑灯了。
图-B2.5_Gitee 提交日志
魂兮归乡：

在 25/06/16 发布了《烂尾极了的七》，介绍了语义审查与 Knowledge Cutoff 审查的设计思路。
在 25/06/16 发布了《搞笑极了的八》，列出了“诤略参谋”与“胡闹猴子”的人格提示词，简要介绍了结构化上下文、LLM 任务的执行骨架以及如何利用 store 管理全局状态实现前端共享数据的组件的同步无缝局部刷新。
在 25/06/15 编写了《六、软件操作手册》（06/16 尚未发布至 CSDN）。对诤略参谋 Web APP 给出了极详细的功能介绍和使用引导。
在 25/06/16 按照要求应付了《十一、代码说明文档》（不会发布至 CSDN，我都说了是“应付”了）。
汇总需要提交的项目材料。
在期末答辩中向四位老师演示系统的整体功能。

贝格拉夫：

在 25/06/15 ~ 25/06/16 录制和剪辑了项目演示视频。
在 25/06/09 发布了《Vue实现批注功能显示》，初步完成了“批注”可视化方案的开发与测试。这篇博客阐述了三个核心步骤：
1. 利用计算属性将 mainText 字符串和 suggestions 数组动态处理成一个分段对象数组，解决了普通文本与高亮批注的混合渲染问题。
2. 采用绝对定位的 SVG 覆盖层，实现了在不影响页面布局和交互的前提下动态绘制从原文高亮处到建议卡片的连接线。坐标换算通过 getBoundingClientRect API 完成。
3. 用 scrollIntoView API 实现点击定位，利用 requestAnimationFrame 对滚动事件进行节流优化，保证了滚动时连接线的平滑跟随，避免性能问题。
在 25/06/14 发布了《使用LLM API生成并分析计划》。
- 完成了使用 LLM API 生成并分析计划的核心后端逻辑开发，实现了从接收用户输入到调用 LLM 服务、再到处理和持久化结果的全流程，核心是对 generatePlan 和 generatePlanSuggestion 函数的设计。
- 在 Plan 实体类中设计了 planContent、planContentCopy、planContentModified 等字段，以此实现“版本控制”。
在 25/06/15 发布了《具体的LLM提示词》，分享了指导 LLM 完成对应工作所用的提示词。
在 25/06/15 发布了《项目实训实体类E-R图》。

dogdogw：

完善了在 25/05/20 发布的《前后端实现与文件上传：构建高效可靠的文件管理系统》。完成了项目系统下文件管理子系统的开发，实现了文件上传的前后端全功能。
- 前端开发了 ProjectFile，封装了 ContextFileManager 以处理复杂的交互逻辑、提供了包括文件选择、拖拽上传、文件列表展示和删除在内的完整 UI 界面。
- 后端：
  - 在 ProjectController 中定义了文件上传的 RESTful API 接口，负责接收前端请求并分发给服务层。
  - 在 ContextFileService 中实现了文件处理的核心业务逻辑：
    1. 同步处理部分（uploadFile）：负责完成文件上传的即时操作，包括权限校验、文件数量/类型限制、安全存储（使用 UUID 生成唯一文件名防止冲突）以及将文件元数据保存到数据库。
    2. 异步处理部分（processFileAsync）：实现了关键的异步处理机制。将耗时的操作——如调用 AliDocumentParsingService 进行文件内容解析和 token 估算——放入一个新的后台线程中执行。避免了阻塞 API 的 HTTP 响应，极大地提升了系统的响应速度和用户体验。
在 25/06/04 发布了《后端阿里云文档解析与前端 OCR：智能文本提取的实践》，为用户提供全面、高效的项目背景录入能力，既能满足即时性图片识别需求，也能识别复杂文件中的内容。
- 前端开发了 OcrInput 和 OcrBtn 两个核心组件，允许用户通过 OCR 快速将图片中的文字追加到指定的文本输入框，显著提升了用户输入效率。
- 后端利用阿里云文档解析大模型解析用户输入的各类文件的内容。
  - 实现了 AliDocumentParsingService，专门负责与阿里云文档智能服务进行交互，处理 PDF、Word 等复杂格式的文档。
  - 采用了异步轮询机制。parseDocument 作为入口，首先向文档解析模型提交解析任务并获取 jobId，随后通过 pollJobStatus 方法在设定的时间间隔和次数内轮询任务状态，任务成功后再由 getMarkdownContent 方法获取并格式化返回的文本内容。
在 25/06/15 发布了《应对 LLM 上下文瓶颈：双策略设计 + DeepSeek R1 精炼实践》，设计并实现了“截断”和“概括”策略。
截断策略：简单高效，完整保留所有未超限文件的内容和第一个超限文件的未超限段落，舍弃全部后续文件内容。处理速度快，保留了截断点前内容的原始性。
概括策略：利用轻量级 LLM（GLM-4-Flash）概括超限了的内容。使用 recursiveDistill 函数进行异步、并发、递归的概括。

epiphany狂人：

编写了《七、分工说明》（06/16 尚未发布至 CSDN）。
完善了 25/05/20 发布的《续记忆管理后端，与创造力提示词改善实现。》，开发了记忆管理的后端部分，细化了控制不同创造力等级的提示词。
完善了 25/05/30 发布的《完成项目下一级计划管理》，开发了 PlanDetail、PlanSettings 和 PlanItem 等组件，编写了相关 Controller 和 Service。
在 25/06/15 发布了《完结篇：完成流程图输出。》，完成了流程图生成功能的后端实现，核心是 launchPlanVizTask（generatePlanViz）。

w_x_yao：

完善了 25/05/20 发布的《项目功能实现全解析：从注册到个性化设置》，实现了注册、登录、自动登录、忘记密码、退出登录和修改密码等基础账户管理功能的代码，用邮箱验证码做了注册、忘记密码和修改密码的安全校验，还用了 JWT。此外他还实现了主题切换功能。
在 25/06/09 发布了《项目功能实现全解析:LLM 人格管理与选用功能的前后端实现》。
- 在后端编写了 PersonaService，封装了对 Persona 实体的人格添加、修改、删除和模糊查询等全部业务逻辑。在删除人格时，系统会检查并重置所有引用了该人格的全局、项目及计划设置，确保了数据的一致性。
- 实现了头像上传与管理，通过 UUID 保证了文件名的唯一性，并提供了默认头像作为 fallback。
- 实现了直观的人格管理页面，用户可以查看、搜索、添加和选择人格。
在 25/06/11 发布了《项目功能实现全解析:成本与风险分析功能的实现及 LLM 的使用》，调用 LLM API 为计划编写全面深入的成本与风险分析报告，辅助决策制定。/plan-analyze 收到请求后创建任务并异步调用 generatePlanAnalyze（经过背景提炼、上下文拼接、生成报告、检查格式、处理结果等步骤）。
在 25/06/14 发布了《项目功能实现全解析：统计数据页面的数据处理与可视化展示》，后端通过 getUserStatistics 方法获取当前用户的统计数据，前端通过 fetchStatistics 方法获取后端数据，用 ECharts 库渲染统计图。

主项目上的进度

这次大家完成的事情太多了，严格意义上诤略参谋项目已经竣工了！所以直接看《七、分工说明》吧！

注：

灰底带删除线的是在上一次或更早的汇报中就已完成的任务；
绿底带删除线的是在本次汇报中完成的任务；
红底带删除线的是未能按时完成的任务（严格来说，06/16 期末答辩结束即意味着整个项目的结束。之后再完成这些任务也无人检查）；
红底无删除线的是完成了大部分的任务（可以算作已完成但是按最初设想的话仍会被算作未完成的任务）。
下面这张表只是“二、分工与进度”里的表，这张表里少了一些工作……总之还是建议直接看《七、分工说明》。

魂兮归乡：

表-B2.1