诤略参谋 | 工作分析,实现想法,阶段规划(长期更新)

记录一下完成的工作以及接下来的规划

要写至少八篇博客,稍微想一下内容:
第一篇:git✅
第二篇:后端业务复习(demo实现增删改查)✅
第三篇:上下文策略的初步想法,LLM知识的学习✅
第四篇:后端业务 文件传输功能的实现(demo实现文件上传)✅
第五篇:项目计划,想法以及推进记录(长期更新)✅
第六篇:上下文策略的实现✅(需完善)
第七篇:前后端实现,文件上传❌
第八篇:文档解析❌
第九篇:前端OCR,语义审查
第十篇:工作总结,我所负责的前后端的结构以及具体实现

项目推进记录

开发阶段(5.11 - 5.17)

五月十一:
目前后端实现了项目管理中的增删改查,主要需要注意下面几点
1.每个人只能看到自己的项目
2.为了统一规范,在Controller层都使用了StdResponse
3.异常处理

目前前端来说在组长的帮助下回忆起了一些知识 稍微走通了一些流程:
1.理清了vue的一些基本知识(细节方面后续还是要进行复习)
2.大致上了解了各个组件的作用以及组件该如何去使用(细节方面后续还是要看组件教程文档进行学习)
3.复习了一些关于http请求以及路由的知识(细节方面后续还是要进行复习)
4.把项目前端的结构熟悉了解了一下
5.初步写了一下项目列表的前端:
(1)现在能搜索项目了,
(2)能显示项目了

五月十二:

后端:
完善了项目管理中的增删改查,特别是增,主要需要注意下面几点:

1. Project实体类新增了几个字段
2. 新建了个DTO类用来实现新建项目的功能(为请求体使用数据传输对象)
   一开始写的时候,getCurrentUserId()方法能获取到用户id,但是创建项目的时候显示userid不能为空
   在排查过程中找到了问题:当 Spring 尝试将传入的 JSON 映射到 Project 对象时，如果 JSON 中缺少 userId 字段或该字段明确为 null，那么 Project 对象中的 userId 字段在反序列化后默认为 null。随后，@Valid 注解触发校验，发现 userId 为 null，违反了 @NotNull 约束。
   这个错误发生在Controller方法体（其中调用了 getCurrentUserId() 和 projectService 的 setUserId()）执行之前。
   CreateProjectRequestDTO这个类只包含客户端应该发送的字段（如 projectName、projectDescription、projectGoal、coreContext）。然后，在Controller中，将这个 DTO 映射到 Project 实体，并从认证用户那里设置 userId
3. 记得"改"项目的功能后续也要改(第二阶段)

前端:
实现了新增项目的初步(无OCR和语义审查),主要需要注意下面几点:

1. 新建项目的按钮现在用的是Btn,后续加入语义审查之后要改成TaskBtn
2. 一开始写createProjectAction 方法的时候，虽然新建了项目,后端数据库也能正常写入,但是toast组件显示有点问题
   
   在排查后发现问题:http.post 工具在请求成功后，返回的 response 对象直接就是后端的核心数据（即项目对象 {projectId: 7, ...}），而不是一个包含 code, msg, data 等属性的包装对象。
   然而，在 plan.js 中的 createProjectAction 方法的 if 条件判断逻辑是基于 response.data 来获取 code, msg 和真正的项目数据。由于 response.data 是 undefined，这个逻辑自然会失败。
   解决方案:调整 createProjectAction 方法，使其能够正确处理 http.post 返回的实际数据结构。

第二阶段

(1)确定项目和计划的关联,以及怎么才能通过项目把他所属的计划全部获取与显示出来等等✅

(2) 后端与前端：完善项目管理增删改查功能，包括在项目列表,项目细节界面显示与项目所关联的计划
增✅删✅查✅
改: 后端✅ 前端(项目细节里)(5.13✅)

有一个小问题:当搜索项目之后 再点击新建项目或者其他操作的时候,再次点击项目列表,现在不会显示用户的所有项目,而是刚刚搜索的项目
在路由进入时重置数据✅

五月十三:

完成了项目详情界面 以及修改项目✅
目前有几个小问题要解决:

1. 创建完项目后应该跳转到ProjectDetail界面(有点小问题 back键回到的不是列表了 是新建项目了 因为·router.go(-1)` 等之后再看看新建项目之后跳到哪个界面比较好吧 然后back的地方也注意一下)
2. 在ProjectDetail界面删除项目后应该返回到项目列表界面✅

第三阶段

(1) 后端与前端：实现上下文管理的B1-B3,能成功新建上下文
后端✅前端✅

(2)后端与前端:实现文件上传功能
后端✅ 前端(5.14已实现✅)
(3) 后端与前端：实现删除已上传文件的功能(B6中的一部分)
后端✅ 前端(5.14已实现✅)
(4)后端与前端：实现查看上传文件列表功能(B4)
后端✅ 前端(5.14已实现✅)

五月十四：
文件上传前端✅
OCR：
前端OCR:新建项目界面和管理上下文界面支持图片 OCR 追加文本(文本不保存到数据库)✅
后端OCR:次级上下文文件上传后,后端接收到文件(txt,doc,docx,pdf,png,jpg,excel),使用百度OCR识别(看一下百度能不能做到:不只是识别,而且能识别出信息,比如图片是张表格,能转换成描述表格信息的文本),然后存到后端该文件的extractedText字段中,用户可以删除以前上传的文件，那样那个文件的内容就不会被加入到之后对 LLM 的请求的 messages 里了。❌

和组长梳理 确认了一下上下文策略
上下文策略:
提取后的输出格式整理为:
［文件 1 文件类型
百度ocr提取的信息］

当用户上传文件时
会将该文件保存到后端数据库
然后将此文件通过百度OCR识别 保存到extractedText字段中

然后会通过deepseek官方分词器计算每个文件的extractedText所用token量的函数
然后每加入一个文件就通过一个函数判断 按照时间排序 传入时间最早的文件为文件一
编写函数计:算文件一.extractedText.gettoken()+文件二···

更具体的 如果删除文件
比如先传入文件A 然后文件B 文件C
此时应该是计算
文件A.extractedText.gettoken()+文件B.extractedText.gettoken()+文件C.extractedText.gettoken()
如果这个时候删除了文件A 应该计算
文件B.extractedText.gettoken()+文件C.extractedText.gettoken()

如果结果超出了阈值 就标记是哪个文件加入后导致超出的阈值 标记该文件
在策略一中 提醒用户上传文件已超限 标记出从哪个文件开始 超出了阈值 如果继续加入文件 可能后续会被丢
在策略二中 提醒用户上传文件已超限 后续会被精简

但是用户可以继续加文件(如果超出上下文阈值 不会限制用户上传文件 只会做出提醒,但是用户不能上传不符合要求(比如最大20MB)的文件)

当结束后
用户点击ai生成计划:此时会进行判断

如果文件没超限制 直接把拼好的输出格式 以及项目目标等字段给ai

如果超限:
策略一 判断超出的部分 删掉超出的部分 标注

策略二 精简（具体实现:貌似可以通过先分块给"提炼内容ai" 如果分的块没超阈值就把所有块分别给ai 最后让ai根据这些 给出精简后的信息 如果单块就超出阈值了 递归调用刚刚的描述） 给用户说精简后的内容

五月十五：
通过VO类优化前后端数据传输:✅

1. 点击项目列表时 只需要传下面几个属性:
   每个项目的id
   每个项目名
   项目概要
   每个项目的最后更新时间
   每个项目下的计划数 (创建VO类的时候再计算该项目的计划数 就不在Project实体里面增加计划数这个字段了)
   每个项目下计划的计划id
   每个项目下计划的计划名
   每个项目下计划的计划最后更新时间等等

2. 点击项目列表中的ProjectItem时 同理 只需要传需要的信息即可

完善了未保存拦截机制

五月十六:
把后端OCR方法改成了阿里云文档解析✅
粗略的说 现在整个流程是:
在管理上下文界面中:上传文件->将文件存到数据库中->使用阿里云解析文件->将解析结果整理格式并进行拼接->每个文件拼接后的内容存入其extractedText (Context实体类的一个属性) 中->通过估算计算每个文件的extractedText 所用token量->计算当前上传文件与文件列表中目前上传的文件的总占用token量->判断总量是否超过阈值 (50K)->如果超过的话: 记录在哪个文件上传后超出了阈值, 并且在前端界面上提醒用户类似于"上传第x个文件后导致超出阈值"的消息
还有删除文件更新阈值判断等功能

具体到之后再细说

正在劲爆尾杀♿

五月十七：
实现上下文策略✅
目前的策略流程与细节 如下图所示:

总结 整理一下这篇博客
计划一下写其他博客

临门一脚🤓
把侧边显示和置顶做了

记录一下(感叹):

五月十八:

水完其他课的实验

Back!

完善&总结阶段(5.19 - )

加油吧

关于前端:

我主要负责了五个页面

为了先尽快使项目管理能正常使用,关于置顶,侧边栏显示,项目设置的功能暂时不去开发,等完成这个阶段之后再回来做,所以下面讨论到的目前的工作没有包括置顶,侧边栏显示,项目设置

1.项目列表(ProjectList)(初版已实现✅)

目前来说已经实现了搜索项目✅和显示项目✅了，从某种程度上讲可以正常使用了

需要完善的是:

1.每个项目中显示的信息以及各个组件

2.此页面的样式与布局

2.新建项目(ProjectCreator)(初版已实现✅)

对于前端来说，此页面的工作有:

1.Field与Txt组件的创建与使用 ✅已实现

2.OCR的实现(已实现✅)

3.新建项目(初版已实现✅):需要用TaskBtn,因为在创建项目前,会进行一次语义审查,通过之后才能成功创建 ❌但是目前新建项目用了Btn组件 实现了新建项目的功能 只需要后续实现语义审查功能后调整为TaskBtn按钮

(当然,为了尽快先把项目创建出来,我决定先使用Btn按钮组件,绑定后端的新建项目的方法,等后续再进行改进)

4.此页面的样式与布局✅目前布局与样式比较满意,后续完善即可

3.项目细节(ProjectDetail)(初版已实现✅)

对于前端来说，此页面需要做的工作有:

1.显示上方的项目信息✅

2.置顶 设置 编辑 删除的组件 (编辑 删除已实现✅, 置顶和设置后续再说)

3.管理项目上下文的Btn ✅

4.下方的显示计划 (已实现✅)

5.此页面的样式与布局 (初版已实现✅ 后续完善)

4.上下文页面(初版已实现✅)

1. 项目目标(Field),核心上下文,次级上下文(Txt)的开发 (初版已实现✅)

2. OCR组件(已实现✅)

3. 保存键(初版已实现 用的是Btn✅)(后续应该为项目目标 核心上下文 次级上下文各加一个保存按钮❌)

4. 次级上下文文件✅

5. 拖拽文件的样式✅

6. 此页面的样式与布局 (初版已实现✅ 后续完善)

7. 需要改善的一点:现在是把一切数据都传过去，很方便，但……未来有空还是最好改一改，projects 对应的请求就是概况，不要把上下文和所有计划的详情都写上去。

5.项目设置页面

(等下个阶段再去仔细想)

关于后端

1.项目管理

同样的,A1,A6,A7在下个阶段再去仔细想

目前关于A2-A5

1.项目实体类✅

首先,对于项目这个实体类
需要有的字段有
projectId主键
projectName
projectDescription
userId
createdAt
updatedAt等

我觉得后续还需要添加的字段有:

1. 项目目标✅已添加

2. 关于上下文✅已添加

3. 关于项目设置的字段
   (1)严格等级
   (2)创造力等级
   (3)人格
   (4)上下文策略
   或许这些不一定要用项目的字段,或许还有一些属性需要用项目的字段,但这对目前的开发来说都是无关紧要的,所以都留在下一个阶段再去想

4. 关于计划✅已添加
   新建一个计划实体类,和项目的映射关系为一对多✅

2.关于增删改查的细节(初版已实现✅ 后续新增项目中加入语义审查)

关于删,改,查,目前这个流程还是比较完整的

解答:项目概要不需要语义审查，因为那个是用户写给自己当备忘看的。只有会被扔进 messages 里作为上下文的一部分的内容有可能需要语义审查；

主要是增

在新建项目时,创建项目前会进行一次语义审查,通过之后就会创建项目,将相关参数的值一一赋给相应的属性

解答:项目目标和核心上下文在“新建项目”和“上下文管理”面板里都出现了，出现在“新建项目”里的意义侧重于“给这些必要的信息赋一个初始值”，出现在“上下文管理”里的意义侧重于“用户在日后可以不时地、反复地查看和修改这些值”。比如，一种可能的行为链条是，用户输入这些东西，创建新项目 → 直接点击“生成计划” → 生成计划后对新建时输入的上下文不满意，去上下文管理中修改 → 修改后再点击“生成计划”。

2.上下文管理

B1-B3本质上就是修改项目实体类的三个属性(已实现✅)
B4-B6:
首先完成B5,也就是说,目前我实现的,就是能把用户的这个文件接收到,并保存到数据库,
下一步需要做的:后端OCR:次级上下文文件上传后,后端接收到文件,如果是txt/pdf/doc/docx则提取文本,如果是图片(jpg/png)则使用OCR提取文字,然后存到后端该文件的extractedText字段中,用户可以删除以前上传的文件，那样那个文件的内容就不会被加入到之后对 LLM 的请求的 messages 里

解答:文件上传后，AI分析的流程和职责分工:这个我理解的有些偏差,目前团队初步考虑的是通过OCR将文件中的文字提取出来(文件格式限定为txt doc pdf),然后再将这些文件中的文字放入一个属性,比如"次级上下文(文件提取文字部分)",接着这些文字会和上下文一起提交给ai,让ai提出计划

B4(已实现✅)
B5(已实现✅)
B6(初版已实现 后续完善✅)

3.上下文策略以及在上下文超过阈值时给出提醒

在之前的博客里有提到过初步想法了

应对 LLM 上下文瓶颈：双策略设计 + DeepSeek 精炼实践

4.贡献一个LLM人格

写提示词(ez)

5.一些后续设想功能

“自动”搜索网络资料

LLM (不)输出 markdown (貌似通过提示词就可以实现 很简单)

同样的,也是等下一个阶段再说

阶段规划

开发阶段

1. 第一阶段:✅

尽快完成项目管理增删改查功能,其中:
(1)确定项目实体类中的必要字段
(2)后端:实现新建项目的初版(无语义审查)
(3)前端:实现新建项目的初版(无语义审查)

2. 第二阶段✅

(1)确定项目和计划的关联,以及怎么才能通过项目把他所属的计划全部获取与显示出来等等
(2) 后端与前端：完善项目管理增删改查功能，包括在项目列表,项目细节界面显示与项目所关联的计划

3. 第三阶段✅

(1) 后端与前端：实现上下文管理的B1-B3,能成功新建上下文
(2)后端与前端:实现文件上传功能
(3) 后端与前端：实现删除已上传文件的功能(B6中的一部分)
(4)后端与前端：实现查看上传文件列表功能(B4)

4. 第四阶段✅

(1)实现OCR功能：
前端OCR:新建项目界面和管理上下文界面支持图片 OCR 追加文本(文本不保存到数据库)✅
后端OCR:次级上下文文件上传后,后端接收到文件(txt,doc,docx,pdf,png,jpg,excel),使用百度OCR识别(看一下百度能不能做到:不只是识别,而且能识别出信息,比如图片是张表格,能转换成描述表格信息的文本),然后存到后端该文件的extractedText字段中,用户可以删除以前上传的文件，那样那个文件的内容就不会被加入到之后对 LLM 的请求的 messages 里了❌
(2)实现处理OCR异常，文件上传异常，超限异常 (初版已完成 后续完善✅)

5. 第五阶段

(1) 实现两种上下文策略✅
(2)实现在上下文超过阈值时给出提醒✅

6. 第六阶段

(1) 实现侧边栏显示项目(A1)
(2)实现置顶和取消置顶功能(A6)
(3)实现配置项目设置功能(A7)
(4)贡献一个LLM人格提示词

7. 第七阶段

(1) 完善新建项目 (加入语义审查)
(2) 我所负责的前端页面的布局和样式的调整和美化
(3) “自动”搜索网络资料
(4)LLM (不)输出 markdown (貌似通过提示词就可以实现 很简单)

完善&总结阶段

重构代码,完善代码

上下文策略:

1. 截断策略，提炼策略那里的具体细节完善
2. 目前是 1000 token
3. 没和"AI代写计划集成"
   ……

文件处理等地方的异常判断

文档解析那里的在上下文超过阈值时给出提醒有一点显示问题 以及完善

……

编写博客

收尾

把项目设置页面写了
贡献一个LLM人格
LLM (不)输出 markdown (貌似通过提示词就可以实现 很简单)

加油吧♿!