LLMentor 进度,和毕设进度
两件事,都到”看完”这个节点了:一边是 LLMentor 的文档和代码,一边是毕设的材料下发。
但”看完”只是个逗号。这篇文章想记的是:看完之后,怎么验证自己真的看懂了。
一、LLMentor 进度:文档和代码都过了一遍
先摆现状。
| 部分 | 文档 | 代码 | 现在的位置 |
|---|---|---|---|
| dodo | 看完 | — | 可以开始被提问 |
| WebSearchAgent | — | 看完 | 等 AI 出题自测 |
| PPTAgent | — | 看完 | 同上 |
| DeepSearchAgent · Plan-Execute | — | 扫了一遍 | 只是凑进度,今天重读 |
前三个是真的看进去了:dodo 的文档逐节过完,WebSearchAgent 和 PPTAgent 的代码从入口一路跟到落库,主链路能画出来。
但这次我不敢说”看懂了”。原因很具体:读代码有一种很强的熟悉感。 顺着作者的思路往下走,每一步都觉得”对,应该这样”,可那是作者的思路在带着我走。一合上代码,让我自己从空文件写,大概率卡在第一个接口签名上。
所以下一步不是继续读,是让 AI 反过来问我。
具体做法:把某个模块的代码丢给 AI,让它当面试官,针对设计取舍、边界条件、异常路径出题,我口头回答。答不上来的地方,就是没懂的地方。比如我会拿这几个问题去试自己:
- WebSearchAgent:一次搜索从 query 改写 → 检索 → 重排 → 摘要,哪一步最容易丢上下文?并发搜索的结果怎么合并、去重?
- PPTAgent:版式决策发生在哪一层?模型返回的 JSON 少一个必填字段,链路是报错还是降级?
- Plan-Execute:为什么先规划再执行,而不是边想边做?计划的粒度由谁决定?
能答上来,再谈手写。手写的标准也不是”能跑”,是不查原代码能写出来——先挑最小的那块开始。
关于 Plan-Execute,说句实话
DeepSearchAgent 下的 Plan-Execute,我看完了,但只是凑进度。
能讲出流程长什么样,讲不出为什么这么拆。这种状态最危险:进度条上打了勾,脑子里没有东西。今天上班第一件事就是回去重读这一段——不是重看一遍流程,是逐行看它怎么决定计划粒度、怎么处理执行失败。
把”没懂”标出来,比假装懂了有用。
二、毕设进度:材料下发,真正的价值是”有口径了”
毕业设计的材料和示例这几天基本下发完了。拿到之后我做的第一件事,是让 AI 按材料里的结构把项目搭起来,然后修了几轮、测了几轮。
现在的状态是能跑:六个 Maven 模块、17 张表、143 个 Java 文件约 8.9 千行,前端 11 个页面。
修复的过程不太好意思细说,但有个数字值得记:三轮评审下来,累计 90 多条编号缺陷,其中 8 条是 P0(权限校验、事务缺失、状态机竞态这一类)。第一轮集中修了 65 条,第三轮又新发现 16 条。
这说明一件事:AI 能把项目搭得像模像样,但它不知道自己哪里写错了。 分层、状态机、迁移脚本都能一次成型,可”少了一个归属校验””事务没提交就去发异步事件”这种问题,只有人顺着数据流读一遍才能发现。跟上一篇说的一样——AI 修 bug 的前提是我能判断它修得对不对。
材料下发真正解决的是口径问题
一开始我以为材料下发就是”有模板可套了”。真用起来才发现,最值钱的是它有口径。
在这之前,同一件事在四份材料里有四种说法:
| 维度 | 现在的统一口径 | 之前的坑 |
|---|---|---|
| 题目 | 基于 RAG-Agent 的计算机专业课智能出题系统(论文题加”设计与实现”) | 旧名写的是”智能组卷系统”,跟教务口径对不上 |
| 进度 | 官方 8 个日历区间 | 自拟 14 周排期,开题、中期、定稿全错位 |
| 文献 | 官方指定 10 条,逐字照抄 | 16 条,其中 3 条是”待补”占位 |
| 项目事实 | 17 张表 / 6 模块 / 5 个技能点共 6 次模型调用 / A0–A2 三档 | “16 张表””5.5 处调用点””SOP 加工具链” |
| 署名信息 | 学校 / 学院 / 姓名 / 指导教师 | “XXXX 大学”、信息栏空白 |
这些数字看起来无关紧要,但答辩时被问一句就露馅:表到底几张?调用点几处?A2 档到底挂的是什么?答不上来,前面写得再漂亮也白搭。
更麻烦的是手改。四份 docx 各改一遍,改到第三份就忘了第一份写的是什么——手改必然漂移。
所以我的做法是:先立口径,再生成材料
三步:
- 先做一份口径表当唯一真源。 题目、官方进度、官方文献、项目事实锚点,全部逐字固定下来,任何材料都以它为准。
- 四份材料由脚本从口径表生成,而不是手改。 生成完再跑一遍硬性检查:题目字符串对不对、日期字符串对不对、文献是否逐字一致、有没有残留占位符。
- 数字从仓库里数,不凭记忆。 表数量数
CREATE TABLE,调用点数数callJson,代码行数用脚本统计。写”16 张表”的时候我以为自己记得,实际数出来是 17——第三轮修复加了一张关联表。
这份口径表还顺手解决了一个隐性问题:论文里的数字必须能对得上代码。 比如”5.5 处 LLM 调用点”这种说法,代码里根本不存在——是 5 个技能级调用点、6 次物理调用(质检被拆成独立求解和五维评分两次)。数字说不清,方法章节就站不住。
材料规划
按官方节点倒排,要交的东西其实就这些:
| 时间 | 交付物 | 依赖 |
|---|---|---|
| 2026-10-31 | 任务书 | 口径表(题目、进度、文献) |
| 2026-11-29 | 文献综述 | 官方 10 条文献 + 自己补的外文 |
| 2026-12-29 | 开题报告 | 任务书 + 研究内容 + 进度表 |
| 2027-03 中旬 | 中期检查表 | 系统实现进度 |
| 2027-04-15 ~ 04-25 | 论文编排、查重、修改 | 论文全文 + 查重报告 |
| 2027-05-01 前 | 论文定稿 | 查重结果 |
| 2027-05 上中旬 | 答辩材料 | 论文 + 演示 + PPT |
最紧的是任务书,两天内要交。之后是文献综述,一个月;开题报告,再一个月。真正的大头是 12 月底到 3 月初那段系统开发和论文撰写——现在项目能跑,这段时间主要用来补文档、补测试报告、补评测数据。
三、接下来的顺序
LLMentor 这边:
- 今天:重读 Plan-Execute,重点看”为什么这么拆”,不是”拆成了什么”
- 本周:让 AI 对 WebSearchAgent / PPTAgent 出题,把答不上来的点记下来
- 下周:挑最小的一块手写,标准是不查原代码
毕设这边:
- 先交任务书(10-31)
- 把实测数据落成正式报告——覆盖率、质检通过率、检索消融那几组数据现在只留在会话记录里,得变成能引用的文档
- 按口径表把开题报告和论文初稿过一遍,重点核数字和日期
小结
两件事其实是同一件事:从”看完”到”能交付”,中间隔着一次验证。
代码要能被提问、能手写,才算懂;材料要能逐字核对、数字对得上仓库,才算齐。前者靠别人问,后者靠自己列清单。
之前那篇《自我审视》里我写过一句话:”进步的是知识库,不是我。” 这一周的感受更具体了一点:知识库可以靠 AI 堆,但验证这一步没法外包——因为验证的前提,是你已经知道什么是对的。