由 GPT-6 Astra 根据项目初稿、源码与开发记录整理，ZhaoYan 提出需求并参与迭代。本文记录截至 2026-10-10 的建设过程；测试与部署结果引用相应阶段的验收记录。
光研导航的起点很具体：为光学研究生提供一个查期刊、找会议的中文入口。期刊官网、作者指南、分区平台和会议征稿通知各自保存着一部分信息，使用者却往往要在多个页面之间来回查找，才能判断某个投稿机会是否值得进一步了解。
把这些信息集中起来，很快就能做出一个目录页面。但目录逐渐扩充后，新的问题接连出现：不同来源的分区应该怎样呈现？会议只有日期时能否显示倒计时？几十本期刊如何比较？官网修改通知之后，已经发布的信息如何更新？
这些问题推动光研导航从一个资料汇总页，发展为有数据规则、检索交互、核验记录和维护流程的开源工具。本文沿着这条开发过程，回看几次影响较大的选择和修正。
1. 先明确它要帮助谁、完成什么事
项目借鉴了 CCF-Deadlines 集中展示会议安排的方式，但光学领域的投稿信息不能直接套用计算机领域的评价体系。光学研究与材料、电子、物理、生物医学和计算等方向交叉，同一个研究主题可能对应专门期刊，也可能出现在综合期刊中；会议则可能接收论文、摘要或 PDP，不同通道的要求并不一致。
因此，网站需要支持一个连贯的使用过程：先按方向查找，再看索引、分区或投稿时间，比较准备要求，最后打开原始通知确认。初版围绕期刊目录、会议目录和投稿入门指南展开，数据与界面一同建设。
技术上采用 React、TypeScript 和 vinext 静态导出。期刊、会议等资料独立放在 JSON 文件中，搜索和筛选在浏览器内完成，提交后通过 GitHub Actions 检查并发布到 GitHub Pages。
这个选择与项目规模相适应：公开目录不需要一开始就引入账号、数据库和服务器管理，数据变化也能通过 Git 差异追踪。后续的关注列表保存在本地浏览器，筛选结果通过链接分享，日历导出为文件。它们解决了一部分实际需求，同时保留了静态网站较简单的维护方式。
初版能够运行后，开发的重心逐渐转到信息本身。页面上每增加一种筛选，就需要先回答：用于筛选的数据是否含义明确，来源是否支持这个判断？
2. 数据越多，越需要先把含义分清
一条“分区”信息需要多少上下文
只写“一区”很容易造成误解。它可能来自 JCR，也可能来自中科院分区；可能对应某个学科，也可能是大类结果；不同年份还可能发生变化。项目因此把评价体系、版本、学科和来源分别保存，JCR 进一步区分版本年与指标年，中科院分区区分大类与小类。
索引也与分区分开维护。SCI/SCIE、ESCI 和 EI 的收录情况，不能由影响因子或某个分区直接推出。后续核验使用 ISSN、eISSN 等标识核对期刊身份，并区分出版社声明、数据库方公开来源表和查询结果。
这样做让数据模型复杂了一些，但读者能够看清一条记录的适用范围。例如，数据库来源表能够支持期刊层面的收录说明，却不能替代某篇论文的检索证明。缺少某年度分区时，页面保留未知，不沿用旧值冒充新版本。
一个未来日期未必代表还能投稿
会议信息面临类似的问题。有的通知给出精确时刻与时区，有的只有某一天，还有的尚未公布。项目为这些情况设置不同字段：证据支持精确时间时才做时区转换，只有日期时不自行补成 23:59。
事件类型同样重要。论文提交、PDP、注册、终稿和作者确认是不同事项。后来的使用体验检查发现，IEEE MEMS 2027 的作者接受确认曾被当作投稿类事件，影响“有投稿日期”的判断。修复保留了原日期和来源，只调整事件类型，并检查投稿状态和日历导出是否随之正确变化。
这个问题说明，日期格式通过校验还不够，程序还必须理解这个日期对应的动作。数据字段的含义会直接影响用户是否作出错误判断。
允许未知，才能继续维护
随着目录扩展到交叉学科，候选核验也遇到了身份不清、来源受限、缺少当届通知等情况。项目将候选与正式条目分开，记录准入、待核实或暂缓的原因；部分交叉期刊还补充实际论文样例，解释它与光学研究的联系。
这些样例用于说明研究范围，不承担分区或索引证明。访问不到的资料也继续保留缺口。对 AI 辅助整理而言，明确的未知值和证据字段很重要：它让“目前还不能确认”成为正常结果，而不必为了填满表格生成没有依据的答案。
3. 从“信息已经收录”走到“使用者能够找到”
数据逐渐丰富之后，早期浏览方式的不足开始显现。用户不仅需要知道某条信息存在，还需要快速找到它、与其他条目比较，并在下次访问时继续使用。
会议首先出现了时间维度上的需求。单届卡片适合查看当前安排，却不方便回看往届或关注下一届。项目于是把稳定系列与具体届次分开：系列负责连接历届，日期、地点和要求仍属于各届。未公告的下一届保持未知，历史记录也不通过修改年份变成新记录。
检索则暴露了一个更直接的问题。在界面回归中，输入“CLEO 2027”曾漏掉真正的当届会议，因为搜索字段没有包含年份。修复后加入年份字段并补充回归测试。对开发者而言，数据早已存在；对访问者而言，一次搜索没有命中，就意味着入口没有完成任务。
10 月 9—10 日的体验改进进一步围绕查找和比较展开：
| 使用任务 | 对应改进 | 需要同时验证的行为 |
|---|---|---|
| 在较长目录中找到候选 | 分页、名称排序、中文别名检索 | 搜索覆盖全目录，筛选后页码有效 |
| 在手机上调整条件 | 可折叠筛选、逐项清除条件 | 收起后仍能看懂当前筛选状态 |
| 查看当前与历史会议 | 快捷筛选、分页、往届入口 | 确认事项不算新投稿，历史日期不作当前提醒 |
| 比较几本期刊 | 最多三刊对比 | 跨页保留选择，移除与数量限制正常 |
| 报告发现的问题 | 条目级 GitHub 纠错入口 | 带上对应身份与来源，由用户确认提交 |
三刊对比还带来了新的手机布局问题：表格把结果列撑出了屏幕。修复通过约束网格列宽度，让对比区域独立横向滚动，再检查整页是否溢出。功能增加后，原来的响应式布局需要重新验证。
这轮也补入 Nature、Science 母刊，并支持 1—4 区筛选。数据扩充与交互调整分别处理：缺少的条目需要核验后补充，已经存在但难以找到的内容则需要改善入口。两种问题不能靠同一种修改解决。
4. 为什么需要给 V1.0 规定终点
目录项目总能找到新的工作：还有期刊可以补充，还有会议可以追踪，还有字段缺少证据。随着建设持续推进，“再完善一点”逐渐不足以说明本轮什么时候完成。
2026-10-05，项目固定了 V1.0 的范围与验收条件，将功能可用性、正式条目质量、候选审查、交叉期刊样例、核心会议系列和发布交接分开处理。新增发现留给后续版本，避免不断扩大本轮完成条件。
根据验收记录，10 月 6 日固定的 60 项候选完成审查，其中 8 项准入，52 项保留具体限制和再次核验的条件。审查完成允许留下有依据的未知；尚未开展的工作则不能用同样的状态掩盖。
为避免把不同阶段的成果混写，可以将两轮结果并列来看：
| 阶段 | 完成范围 | 记录中的结果 |
|---|---|---|
| 10 月 6 日：V1.0 验收 | 固定范围建设及维护交接 | 112 本期刊，32 项测试通过，完成对应界面与部署核验 |
| 10 月 10 日：体验改进 | 分页、检索、手机筛选、会议浏览、对比与纠错 | 114 本期刊，41 项测试通过，六项改进完成发布 |
两阶段的会议目录均为 133 届、98 个系列，另有 10 项展会与论坛。数量是当时的目录快照，并不代表完整覆盖，也不意味着所有年份和学科的分区都已核实。
有了明确终点，项目才能从集中建设转入日常维护。后续体验改进可以作为新一轮需求推进，而不用否定上一版已经完成的工作。
5. 发布之后，怎样继续保持可用
光研导航存在两类变化：一类是代码与数据的主动修改，另一类是外部来源发生变化。两者通过不同流程处理。
主动修改进入 GitHub Actions 后，先运行数据校验、测试、类型检查和 lint，再生成报告、构建与部署。网站使用 /optics-scholar-hub/ 子路径，因此资源路径也属于验证范围。本地页面能打开，推送成功，都不能单独证明正式部署正确；还需检查对应提交的部署结果和实际页面。
外部变化由每日来源巡检提供线索。脚本比较网页内容，以及显式图片、PDF 来源的指纹，并生成报告。页面改版、页脚变化、文件元数据改变或访问限流，都可能影响结果，因此报告交给维护者复核，不直接写入新的投稿日期。
维护过程可以概括为：
发现来源变化 → 核对官方通知 → 修改字段与证据
→ 校验和测试 → 构建发布 → 检查正式页面
核验日期与构建日期也需要分开。重新发布网站说明生成了一次新版本，只有实际检查了来源，才应更新相应的事实核验日期。网站的“检查更新”帮助访问者加载已发布的数据，不代表刚刚重新核对了所有官网。
当前架构仍有明确限制：关注列表不跨设备同步，导出的日历不会自动订阅后续修改，部分资料受访问条件限制。这些限制影响后续维护优先级，也让读者知道哪些事情仍需自行确认。
6. 这次 AI 协作留下了什么方法
从项目记录看，AI 承担了界面实现、脚本编写、资料整理、测试和文档维护等工作；使用需求、范围调整和体验反馈持续影响开发方向。有效的协作依赖于把这些判断变成可以执行和检查的要求。
需求要具体到使用动作。 “完善网站”很难验收，而“搜索一个方向、跨页选择三本期刊、打开作者指南”能够明确暴露缺失环节。CLEO 年份检索和手机对比表的问题，都是在具体操作中出现的。
事实需要留下依据。 数据记录来源、版本和未知项，才能让后续修改有据可查。自动校验擅长发现结构问题，内容是否准确仍需结合原始资料判断。
每项修改都应带着验证问题。 改分页时检查搜索与导出是否仍覆盖全部结果；改事件类型时检查投稿状态；改对比界面时检查跨页选择和手机宽度。验证围绕可能出错的行为展开，才有实际作用。
长期状态应保存在仓库。 初版规划说明起点，证据记录解释数据，回归记录保存问题与修复，验收文档界定版本结果。后续继续工作时，能够据此区分已完成、待核实和新需求，减少重复建设。
光研导航由此形成了一套能够延续的工作流程：需求推动实现，使用反馈暴露问题，证据和测试支持修改，有限验收让一轮工作结束。今后的数据补充与功能调整，都可以沿着这套流程继续，而无需每次重新梳理整个项目。
参考记录
本文结合初稿重写，并核对了本地项目的规划、数据模型、实现和以下阶段记录。表中的测试数量引用历史验收结果，本次文章修订未重新执行光研导航的全套测试。
← 返回全部博客