两件事,都到”看完”这个节点了:一边是 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 各改一遍,改到第三份就忘了第一份写的是什么——手改必然漂移。

所以我的做法是:先立口径,再生成材料

三步:

  1. 先做一份口径表当唯一真源。 题目、官方进度、官方文献、项目事实锚点,全部逐字固定下来,任何材料都以它为准。
  2. 四份材料由脚本从口径表生成,而不是手改。 生成完再跑一遍硬性检查:题目字符串对不对、日期字符串对不对、文献是否逐字一致、有没有残留占位符。
  3. 数字从仓库里数,不凭记忆。 表数量数 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 堆,但验证这一步没法外包——因为验证的前提,是你已经知道什么是对的。