两套系统的开发史

先说这一页的凭据

这不是事后回忆。下面的每一条，都对着四类材料交叉核对过：

第一天就定下的两件事

2026 年 6 月 5 日，两套系统的需求同一天拆开。那天定下的东西，后来几乎没变过。

第一件：先做最短的一条路

学情分析明确：先用 Excel 导成绩，拍照识别放到第三期。

磨课评课明确：排课系统先预留，这一期不做。原话是"预留，但不是这一期的核心"。

第二件：需求方自己划掉了"不做"的部分

这一点值得单独看。不是开发说"做不完"，是需求方自己先划掉的。

十七天与二十天：这条路长什么样

17 天与 20 天。两个项目的形状几乎一样：前五天做出能用的东西，中间五天需求变大，最后五到七天全在修。

三个最贵的时刻

一、导出 PDF，改了四版才发现问题不在样式

前三版都在改样式：版式塌了 → 换排版方式还是乱 → 把所有装饰删掉只留表格，还是乱。

第四版才反应过来：问题根本不在样式，在用来生成 PDF 的那个工具身上。换成用浏览器渲染，一次就对上了。

二、改一个评分维度的名字，要动六处

把「板书与多媒体运用」改成「激发兴趣与引导」——听起来一句话的事。实际要动： 系统里那份默认的维度清单、发给 AI 的评分标准、给老师的建议提示、网页上「关于」页的三处文字、示例报告的网页、示例报告的数据文件。

而且改的时候才发现，两边早就漂移了：代码里的默认清单写着 6 个维度，系统实际在跑 9 个。

三、一个班挂着三门课的考试

这一处最贵，也最值得讲。

业务方打开班级列表，看到「八年级平行C班」名下同时挂着数学、英语、语文三门课的考试。

可现实里不会这样——英语班和语文班是两个不同的班。

根子不在谁不懂业务，而在：系统里的「班」只是一个名字，没有"是哪一科的"这个属性。这个缺口从 6 月 16 日造演示数据起就长歪了，一直没被发现。

当时摆在面前两个选择：只把班级名字改掉（省事，当天能完），或者把班级按科目真正拆开。选了后者。

代价是真实的：当时库里 12 个班全部是混合科目，搬迁脚本第一次执行失败，重写一遍才跑通。

拆完的结果，生产库实测：48 个班，每个班都有科目，每个班只挂一门课的考试。

我把这段历史记错过三次

这一节保留下来，不是自曝其短——是因为它比结论本身更有用。

三次都错在同一个地方：从现成的文字里，推一个没有发生过的历史。

第一次从迁移脚本的措辞推（"from school model"说的是迁移前，不是最初）；第二次从看到的现象推；第三次从文件时间顺序推。 只有逐份读代码内容、并实测生产库，才站得住。

从这三次错误里拿出来的三条方法

1. 别从文件名和迁移脚本的措辞反推历史。「从 A 到 B」说的是迁移前后，不是"最初是 A"。
2. 看到"这个数据不对劲"，先问它是真实产生的还是人造的。演示数据的产物会引出并不存在的因果故事。
3. 核对"系统实际是什么样"时，唯一权威是生产数据。说明文档、会话总结、示例文件、本地开发库，四者都可能与生产不符。

两套系统的对照

给要引用这份记录的人

如果要引用，建议按这个粒度：

• 引用「17 天 / 20 天」——来自开发期时间戳与生产库内容交叉核对
• 引用「九个评分维度」——以生产库为准，不要引用示例报告文件（里面多一个线上不存在的维度）
• 引用「班缺少科目属性」——要区分根因（模型缺字段）与触发点（造演示数据时暴露）
• 引用「PDF 改四版」——前三版改的是样式，第四版才是根因（生成工具）