我让一个本地代码智能体读了一张官方统计表，然后它把考研择校做成了能跑的平台。
这张表来自杭州电子科技大学，写的是 2025 年硕士研究生的报考与录取情况。
事情的起点是择校里最容易被忽略的一步。
搜到一个分数不难。难的是搞清这个数字到底代表什么。
它可能是国家线。也可能是学院复试线。还可能是已录取考生里的最低分。
招生人数里有没有包含推免。同一个专业代码，是不是同一个学院。
今年专业课改了，去年的分数还有多少参考价值。
2027 考研就有一个很具体的例子。
北京理工大学公布的调整信息里，软件工程专业的初试专业课从 885 换成了 408。
这是已经发布的科目调整信息，推不出 2027 年的复试线。
所以这次我选了一个边界清楚的方向。
在 TRAE Work 里用 Seed-2.1-pro 做一个叫「研途择校」的本地平台。
目标很朴素。把学校信息和考试科目连起来。再把历史统计与备考差距接上，让每个关键数字都能顺着找到原文。
这次我没有去证明「工具本身有多强」这种虚结论。它更像一次 AI工具 使用记录，值得看的只有过程和结果。
一、先把「非常全面」收成一个能交付的闭环
最初的产品愿景很大。
全国院校，全部专业课，历年录取情况，个性化选校，学习计划，甚至预测上岸成功率。
但「全国数据齐全」和「能做出一个完整案例」是两件工作量差很多的事。
前者要长期维护招生目录和学院调整，还要盯推免口径与失效链接。
后者应该先证明核心流程有效。
这次跑通的闭环只有五步。
找院校。看专业与年份。对比候选。核对历史门槛。记录下一步学习任务。
样本以北京和上海的计算机相关院校为重点。
另外保留杭州电子科技大学和深圳大学作对照。
平台上收了 11 所院校，15 项专业样本。
杭电公开的连续三年报考录取统计用来展示历史数据。
京沪院校用来对比考试科目和复试门槛，也对比学习方式与培养地点。
我没把没收到的字段补成「看起来完整」的数字。
未知就是待核实。原表留白就是空值。
全国覆盖、自动抓取后台和真实录取概率模型都属于后续路线，不写成已完成的功能。
这次的验收方式也很实在。先用一所学校的一项专业跑通。跑通了再按同一规则往外扩。
二、项目创建：先把验收条件交给模型
操作在 TRAE Work 的代码模式里进行。
选中本地目录 yantu-case，确认模型是 Seed-2.1-pro-0915。
界面上显示的 Max 是这次会话的模式标记。本文不据此推断额外的模型性能。
开头那句提示词，我没有只写「帮我做一个好看的考研网站」。
功能、数据约束和交付方式，是一起说清楚的。
提示词里写明，先读设计文档，再读本机的前端设计技能说明。
用原生网页技术。不装依赖。不提交仓库。不发布外网。产物放在 app 目录。
功能清单也不含糊。
院校探索与筛选。最多三项专业对比。专业详情里的历年统计与原文来源。模拟成绩的备考差距分析。证据中心。可保存的学习计划与报告导出。
数据约束写得更死。
禁止编造分数和人数。禁止编造 2027 年的考试科目。
未知显示待核实。总分和单科线都要核对。科目未知不得输出分差。不得输出上岸概率。
这次搭配的本机技能各有职责。
需求梳理用来收敛想法。写计划把交付拆成可检查的步骤。前端设计给出布局和视觉约束。
这里有一句话要说清楚。技能只是给开发智能体参考的工作说明。
它既不是考生使用平台时要装的插件，也不是保证输出正确的开关。
真正决定质量的还是那三件事。需求有没有说清楚。输入有没有证据。结果有没有验收。
三、先读懂表，再抽取数字
网页上的招生资料并不总是规整的文字。
它经常是跨列标题的表格，也可能是 PDF 或者截图。
杭电公开的统计表很适合验证视觉阅读。
表里有一志愿报考人数。也有录取总数和推免人数。还有一志愿录取与调剂，以及录取分数摘要。
这次我把官方统计表渲染成图片，作为附件交给模型。
要求它只观察图片。不许读取本地已经整理好的数据文件或者文本答案。
这样验证对象就明确落在图像阅读上，而不是让模型复述预先录入的数据。
提取任务只针对一行。
050 计算机学院里的 085404 计算机技术，全日制那一行。
要提取的字段有这些。一志愿报考人数。录取人数。其中推免。其中一志愿录取。最高分。最低分。平均分。
原图空格一律写空值，不要补成 0。
看完还要读表底说明。一是统计是否包含士兵计划。二是最低分能不能直接当成普通考生复试线。
用原文逐项核对，2025 年这一行的数值是这样的。
一志愿报考 1107 人。录取 215 人。其中推免 14 人。一志愿录取 201 人。
录取最高分 381。最低分 295。平均分 324。
数字本身只完成了一半工作。
表格底部写得很清楚。录取人数包含一志愿和调剂，也包含推免与士兵计划。
这三项统计同样包含士兵计划考生。平均分四舍五入取整。
所以 295 不能直接当成普通考生进复试的门槛。
这次验证也并非一次全对。
模型读对了七个目标数值里的六个。它把最低分 295 误读成了 296。
它还多做了一步推断，说指望调剂不现实。这超出了这张历史表能支持的范围。
我没有直接丢掉这次回答。我回到原文核对，再发起纠正。
数据表始终采用已核实的 295，调剂栏保持未知。
带明确反馈之后，目标行纠正过来了。但它附带描述的其他行又出现数值错误，没有被采纳。
原始回答和纠正版都作为过程记录留着。最终入库仍然依据官方原文。
这个失败样本也是实操的一部分，不该在文章里省掉。
这是一张表里一行数据加脚注的验证。它不是覆盖不同院校和版式的准确率测试。
真实建库仍然要人工复核。
四、数据结构：让每个数字带着自己的身份
平台用原生网页技术加本地数据文件。
没有装大型框架，也没有在运行时接入模型接口。
当前界面里的差距分析，是可检查的本地规则计算。
目录结构分得很开。
页面和样式一层。数据读取与索引一层。对比篮和成绩草稿一层。学习计划又是一层。
模型先定义数据接口，随后再接入整理好的真实资料。
这种拆法让页面开发和证据整理可以分别推进。
它也有代价。接口扩展以后，必须回头检查页面有没有真的展示新字段。
举个例子。完整的考试科目放在科目字段里。单独的科目调整公告放在另一个字段。
北理工那条约 885 改 408 的公告已经核实。
这不等于该校 2027 完整招生目录的所有字段都核实了。
分数也一样。
复试线是一条记录。录取分数摘要是另一条记录。招生计划和实际录取人数分别保存。
证据记录里有来源网址和发布机构，还有年份、核验日期与口径说明。
有几条看似琐碎的规则，直接影响用户会不会被页面误导。
按学院限定专业。同校同专业代码可能分布在不同培养单位，不能只按代码合并。
按年份记录科目。旧目录不自动继承到新年度，换卷以后不直接比较分数。
保留空白的含义。空值代表未获取或未核实，0 必须由原文写明。
人数要带口径。计划里的专项名额和推免人数，都要在对应记录旁边说清楚。
访问状态也算数据。官网页面可能临时受限，这时要说明复核状态。
不要把搜索摘要伪装成刚打开的原页。
目前数据文件是小规模逐项维护的。要扩到全国平台，主键还得纳入学院和培养方向。
后面还要建采集流程和审核流程。版本更新与冲突处理也少不了。
这些维护成本远大于多写几张页面。
五、用一个模拟考生走完择校流程
进入杭电计算机技术详情，可以对照 2023 到 2025 年的报考、录取和分数摘要。
2025 年一志愿报考 1107 人，实际录取 215 人。
这两个数属于不同口径。不能直接相除得到某个人的录取概率。
历史信息的价值是帮人形成问题，而不是替人给答案。
人数变化来自扩招、培养方向调整还是统计口径变化。这些都要继续读原文。
页面不该替用户编出原因。
对比篮最多放三项专业。避免横向表格挤成看不清的数字墙。
对比顺序是学院与专业。接着看科目组合和年份。最后看门槛与计划备注。
对备考的人来说，公共课组合通常比学校名气更早决定转向成本。
英语一和英语二不一样。数学一和数学二不一样。自命题和 408 也不一样。
总分过线也不等于单科过线。
演示用的是明确标注的模拟成绩。历史参照和目标入学年度分开选。
用户可以看 2026 已核实的门槛，但不能把它当成 2027 的承诺。
举个例子。
以北交 2026 已核实的复试门槛作历史参照，总分 322。百分制科目要求 35，150 分科目要求 53。
输入政治 70，英语 30，数学 120，专业课 120，总分 340。
总分比门槛高 18 分。但英语单科仍然差 5 分。
如果所选考试科目和该年官方目录不一致，直接分差就不该继续输出。
如果 2027 科目还没核实，页面应该停在「需要补充证据」。
不能填一个貌似精确的百分比。
发现差距之后，还得能接着做事。
学习计划用来保存目标专业、任务和进度。报告可以导出留存。
证据中心让用户集中检查原文和核验说明。
六、京沪院校怎么选
这个平台把京沪院校放在重点位置。
北京有六所。北航。北理工。北交。北工大。北科大。华北电力。
上海有三所。同济。华东师大。上海大学。
用户可以通过地区快捷按钮缩小范围，也可以直接输入习惯使用的学校简称。
检索只是入口。
真正影响选择的是具体学院和学习方式，还有考试科目与各类数字的含义。
平台界面共有 11 所院校，15 项专业样本，27 条来源记录。
地区分布是北京 6 所，上海 3 所，另外保留杭电和深大。
这些数量只是当前案例快照的覆盖范围。不代表这些学校只有这些专业。
最有用的恰恰是那些不能用一句「这所学校多少分」概括的差异。
北京科技大学这次录入的是 060 计算机与通信工程学院的 085404。
2026 年初试考政治、英语一，再加上数学一和 408。
复试方案里的普通计划门槛是总分 330，百分制科目 35，150 分科目 53。
初版目录和复试阶段的计划发生过更新。
所以页面采用复试阶段的拟招统考 37，并保留口径说明。
不把目录总数和统考名额混为一谈。
还有一个和真实选择有关的细节。
这份复试方案提到 2027 年 3 月起分批入住雄安校区。
所以按「北京院校」筛选，并不等于整个培养过程都在北京。
平台保留了地区筛选，同时把培养地点的核对提醒放进专业备注。
华北电力大学采用北京招生口径，录入 004 控制与计算机工程学院的两项专硕。
2026 年目录里这两项的科目一样，都是政治加英语二，数学二加 408。
计算机技术的目录计划是 35 人，含拟推免 16 人。软件工程是 20 人，含拟推免 5 人。
两项的历史复试总分分别是 332 和 274，单科要求 35 与 53。
这些是不同专业的历史门槛。不能据此推导未来的录取难易排序。
同济这次选的是 170 计算机科学与技术学院的 085404。
2026 年初试考政治、英语一，加上数学一与 408。
全国统考普通计划的复试门槛是总分 340。政治和外语各 55，两门业务课各 90。
不要因为搜索结果里还有同校其他培养单位的 085404，就把分数线拼到这条记录上。
华东师大采用 135 计算机科学与技术学院的全日制方向。
官方公布的该专业复试总分是 264，单科按国家线执行。
当前样本没有另行录入还没独立核验的单科数值。
复试实施细则里的普通全日制统考计划是 65 人，专项计划另列。
上海大学录入的是 008 计算机工程与科学学院的 085405 软件工程全日制。
2026 年科目是政治和英语二，再加数学二与 408。
普通计划复试要求是总分 358。政治 45，外语 40，两门业务课各 75，拟招统考 57。
其学院方案里的 085404 计算机技术是非全日制。
不能把非全日制和全日制软件工程拼成一条「上大计算机」。
这组三校样本至少提示两件事。
第一，都是 408，公共课仍然可能是英语一加数学一，也可能是英语二加数学二。
第二，总分门槛低不等于最后录取容易，也不等于复试没有竞争。
页面先把事实摆齐，用户才有条件继续判断。
资料核验和数据入库单独进行。模型的检索功能任务限定在应用层。
要求是先读项目里的院校探索页，再看数据加载和样式文件。
读完再完成检索功能。
实现全部地区和北京与上海三档快捷按钮，与地区下拉共用筛选状态。
展示总学校数和专业数。北京学校数、上海学校数与来源数同样从数据文件动态计算。
支持北科大和华电这类简称。华师大、上大与同济也都能搜到。
保留全名和专业代码搜索。没有数据时显示空态，不创造招生信息。
只改必要的应用文件。保持无依赖和本地运行，也保持现有设计风格。
不改资料。不改分差规则。不装依赖。不发布。不输出成功率。
模型通过探索页和样式文件实现了这些要求。快捷按钮复用了原有的地区状态。
概览从已加载的数据动态统计。简称表和数据里的别名字段配合工作。
原有全名和专业代码匹配继续保留。这些实现复用了已有的数据和筛选逻辑。
学校和专业样本分别统计，检索结果只展示数据集里实际收录的专业。
学校简称和专业代码都与地区条件一起参与筛选。
七、这个模型在真实任务里接住了什么
如果只写一句「模型很强」，很难判断强在哪里。
我更愿意把它放回真实任务里看。
这次它接住了几个环节。
带约束的需求执行。读取项目上下文。多模态资料阅读。多文件编码实现。还有连续需求迭代。
带约束的需求执行是看得见的。
功能和禁止事项同时写进提示词，数据缺失规则也在里面。
检索到对比再到分析，连成了完整流程。
但这不等于所有约束一次全对。
读取项目上下文也算清楚了。
它读了计划文档和现有文件，也读了本机的前端技能说明。然后沿现有目录创建和修改页面。
这是本地代码智能体的工作过程，不是单轮文本回答。
多模态资料阅读这一项，结果是输出结构化候选值和解释。
同时出现了数字与推断错误。所以我只报这次的具体表现，不报通用准确率。
多文件编码实现给出的是可运行网页和可保存计划。
成品里还包含后续协作修正，不能全算成一次生成。
连续需求迭代体现的是改既有项目的能力。
京沪筛选和简称复用了地区状态，动态统计保留原有功能。
反馈修复这一项也做了。它按具体错误定位相关逻辑并修补。
但修完必须重新执行对应测试。完成说明不等于通过证明。
这个案例的好处，是同一个开发过程里既有读需求和读文件，也有看图片、写代码与改代码。
这些动作之间有联系。图表字段影响数据结构，数据结构影响页面。用户追加的地区需求又要求保留已有状态。
模型创造价值的地方，是把这些工作接起来。
比如输入「华电」以后找到对应学校，需要简称映射和地区筛选一起生效，还要算上专业归属。
还要准确展示两项专业的不同门槛。
另外要把角色说清楚。模型负责了应用主体。公开图片阅读和多轮代码迭代也是它做的。
资料检索和逐项来源核验也参与了成品形成。补充数据与最终协作审查同样算在里面。
本文没有把这些工作全包装成模型独立完成。
更没有把开发过程中的模型调用，说成平台正在提供实时招生服务。
运行成品时不需要模型密钥。模型在开发阶段帮忙建工具。
工具在使用阶段执行透明的本地规则。
以后要接在线问答，那会是新增功能。
还要另行处理检索引用和上下文，费用与失败回退也得一并考虑。
这段过程里最像 AI编程 的地方，其实不是生成代码那几下。
真正难的是把一段模糊需求，拆成可以逐项验收的清单。
八、验收：能复查的结果才算完成
「网页能打开」只是验收的起点。
这次重点检查四类问题。
来源是否对应。科目是否可比。输入是否合法。缺失数据有没有被偷偷变成确定结论。
数据检查覆盖 15 项专业，27 条来源记录，58 处证据关联。
核对的约束包括记录与来源的学校和年份，还有分数范围与统计值之间的关系。
状态检查覆盖四项行为。
三项对比上限。刷新后保留状态。更新计划不重复。删除测试计划。
检查通过不代表数据永远有效。它证明的是当前快照满足这些检查条件。
实测里该看到的事情是明确的。
搜「北科大」定位到北京科技大学的一项专业。搜「华电」定位到北京招生口径的两项专业。
「华师大」「上大」「同济」各自定位到对应学校。
北京快捷筛选给出 6 所学校与 7 项专业样本。上海给出 3 所学校和 3 项专业。
搜索「同济」再选北京，应该得到 0 条匹配，并给出清空筛选的提示。
上海加专硕的组合保留 3 项专业，两个条件一起生效。
同样本的总分与单科校验里，340 分可以同时出现总分达线和英语不足。
科目不匹配或者年度缺失时，不能直接输出可比分差。
验收过程里也发现过几个具体问题。
空成绩被当成 0，用户没填完就收到分析。处理方式是先判断空值，再检查整数和分数范围，然后反馈模型修复。
切换历史年份后科目不更新，比较对象和试卷可能错位。处理方式是修正年份控件和同步逻辑，并复测详情页。
废弃选项覆盖了新选择，用户以为在分析 A，实际仍在分析 B。处理方式是修正目标状态优先级。
手机筛选栏撑宽了页面，输入框被挤出屏幕，无法完整操作。
实测 390 像素宽时页面达到 708 像素，反馈模型修复内联网格对媒体查询的覆盖。
最后一项尤其典型。模型的完成说明写了手机适配，浏览器实际测量仍然发现溢出。
反馈时应该给三个事实。视口 390 像素。页面宽 708 像素。内联网格覆盖了断点规则。
这比一句「手机端不太好看」更容易得到针对性修复。
修复后复测，探索页和证据中心的页面宽度都是 390 像素。
桌面 1280 像素下也没有整页横向溢出。
这也是我在案例里保留测试过程的原因。
模型的解释可以帮忙定位问题。实际界面和检查结果才决定这一轮是否结束。
这也说明 AI对话 式的单轮回答在这里不够用。必须配合可复查的实测动作。
九、从空文件夹做一遍同类平台
本文没有提供公开源码下载地址。
下面用「从零重建同类案例」的方式来写。
直接给出准备步骤和最小数据样例。可复制的提示词与验收标准也在下面。
不需要拿到我的项目目录，也不需要所谓复现包。
这里复现的是方法和核心行为。我不承诺模型每次生成完全一样的代码或像素级一致的页面。
先用一所学校的一项专业跑通，再按同一规则扩展，会更容易检查。
第一步，准备一个空项目。
需要一个本地代码工作环境。可选择的模型和 Python 3 也都要有。
实际用的是 Seed-2.1-pro-0915。复做时记录自己实际选到的完整名称。
如果界面里没有这个选项，用其他模型得到的结果要标明实际模型。
不能宣称是同型号复现。
新建一个文件夹，例如 yantu-demo，然后在工作环境里选中这个目录。
先建三个文件。一份项目说明。一份界面规则。一份最小数据。
Windows 上不熟悉终端的人，直接用文件管理器建文件夹也可以。
后面的命令都在项目根目录执行，不是在 app 子目录里执行。
第二步，把产品边界写进项目说明。
里面要写清楚用户流程和强制规则。
流程是找学校，看专业，对比，用模拟成绩核对历史门槛，最后保存学习任务。
初版只用一份最小数据。不抓全国数据，不自动补充缺失值。
院校和学院要一起展示。专业代码、学习方式与年份也不能省。
允许的功能有这些。搜索全名和简称。按地区筛选。最多三项专业对比。专业详情。四科模拟成绩分析。证据列表。浏览器本地学习计划。报告导出。
强制规则里有几条。
第一，未知显示待核实。原表空白是空值，不能当 0。
第二，必须先检查年份、科目组合和四科输入，再比较总分与单科门槛。
第三，复试线与录取最低分分别存储，分别命名。
第四，本地规则只能显示差距，不能输出个人上岸概率或者保证录取。
第五，先实现加载和空态，再实现错误与正常状态，最后才接更多学校。
运行方式写死为原生网页技术和静态服务。本轮不装依赖，也不发布。
这份文件相当于把「我要一个全面的平台」翻译成可以逐项实现的要求。
以后追加功能时，也能拿它判断有没有偏离原来的边界。
第三步，把设计要求写清楚，技能可以选用。
本案例调用了本机的需求梳理技能和计划技能，前端设计技能也用到了。
如果已经有这些技能，可以让模型读自己电脑上的实际路径。不要照抄我的用户目录。
没有相同技能也能继续。把设计说明保存成一份不依赖外部文件的规则。
暖白背景配深蓝导航，主按钮用橙色，正文用清晰的中文系统字体。
页面顺序是标题与说明，接着是覆盖范围，然后是筛选，最后是院校卡片。
数字旁边必须写年份和类型，例如「2026 复试线（非录取线）」。
未知字段用「待核实」这四个字，不要只用颜色区分。
每个输入都要有标签，按钮用原生控件，键盘能完成主要操作。
桌面用清晰网格，手机改成单列，390 像素宽不能整页横向溢出。
长对比表允许在表格容器内部滚动，不把整个页面撑宽。
空态要说明原因，并给出清空筛选按钮。资料访问受限时显示原文入口。
不要添加虚假招生宣传，也不要加全国覆盖数字与成功率仪表盘。
技能的价值是提供更成熟的工作方法。它不该变成拿不到就无法动手的隐藏依赖。
第四步，放一条有出处的最小数据。
样例用北交 2026 年计算机技术全日制，考试科目和门槛分别指向目录和复试办法。
数据格式里有几个关键字段。学校带别名和地区。专业带学院和代码，还有学习方式与年份。
科目按年份记录，复试线也按年份记录，各自挂一个来源编号。
计划列表先留空。最小闭环要验证的是同科目、同年份下总分与单科同时检查。
以后补计划，也必须注明是否含推免和专项，其他校区与调剂同样要说清。
复做之前，打开样例里的两条官方链接重新核对一次。
日期字段记录你真正完成核对的日期，不要只改日期而不检查内容。
如果页面失效或者信息更新，保持缺失并记录原因。
第五步，把文件交给模型生成应用主体。
提示词里先让它简述数据字段与页面的对应关系，再直接实现可运行应用。
技术要求是不引入框架和第三方运行依赖，从数据文件读取。
不要把学校数量硬编码在页面里。
路由用哈希方式，覆盖院校探索、专业详情，加上专业对比和备考差距，还有证据与学习计划。
基础细则要写十条左右。
关键词支持学校全称和别名，也支持专业名与专业代码。
专业详情把科目和复试线分开展示。计划与录取统计各占一块，科目变更也单独给。
每条历史事实显示年份，来源按钮通过来源编号关联来源列表。
成绩先检查非空和整数，再检查合法范围。前两科 0 到 100，后两科 0 到 150。
四科代码必须与所选历史年度完全一致，否则停止直接分差比较。
总分门槛和单科门槛分别检查，单科未知时不声称全部达线。
目标年度资料未知时显示待核实，不拿旧资料冒充新年度。
学习计划保存到浏览器本地，修改原计划不新增重复记录。
报告使用安全的文本转义，导出网页并保留来源链接和模拟数据标记。
对比上限三项，重复加入不重复，刷新后仍保留本地状态。
最后是禁止项。禁止虚构数据。禁止输出成功率。禁止接入收费服务。禁止安装依赖。禁止提交或者发布公网。
完成后要给出启动方式和待验证事项，不把还没实测的行为写成测试通过。
不要只看它回复「完成」。打开目录确认文件真的生成了，再检查入口有没有请求正确的数据路径。
第六步，启动，完成一次最小闭环。
先确认 Python 3 可用，再在项目根目录起一个本地静态服务。
然后在浏览器打开本地地址。保持终端运行，按控制加 C 停止服务。
不要直接双击页面文件，否则本地数据的读取可能被浏览器限制。
如果端口被占用就换一个，同时改浏览器地址里的端口。
浏览器的本地存储按站点来源隔离。换端口后看不到之前的学习计划是正常现象。
用最小数据样例时，概览应该是 1 所学校和 1 项专业，不是最终版的 11 所和 15 项。
先搜索「北交」，进入详情，再跑一遍这几件事。
历史参照选 2026，科目选政治加英语一，数学一加 408。
输入模拟成绩 70，30，120，120，合计 340。
应该看到总分比历史门槛高 18 分，英语比历史单科要求低 5 分。
把英语改成 40，总分随之变成 350。英语不再低于该年单科线，但不能出现「保证录取」。
清空任意一科，应该要求补全，不能把空白按 0 计算。
把英语代码改成 204，应该提示科目不一致，停止直接分差比较。
切到 2027，没有该年已核验科目和门槛，应该显示资料不足。
保存一份模拟计划，刷新确认还在。编辑它以后应该仍然只有一份。
这八步把搜索、详情和计算串起来，也把边界和保存串起来。比逐个按钮点一下更接近真实使用。
第七步，用官方资料逐步加入京沪学校。
每份资料可以要求模型先返回一张核验表。
表里有字段名和原文数值。还要给单位，以及页码或者表格位置。来源网址和口径说明同样不能少。
定位条目时先按学校和学院，再用专业代码加学习方式与年份，形成唯一标识。
人数要分总计划和拟推免。拟统考和实际录取也得分开，不同类别不能互相替换。
分数要分清复试线。录取最低分和最高分与平均分也不一样，不能混用。
原文空格写空值，原文打不开就写访问受限。
先给候选结果，不直接改正式数据，等核对之后合并。
遇到图片或表格时，保留列标题和目标行。脚注同样要留下，不要只截一个裸数字。
把原图作为附件提交，要求逐列对齐，必要时只处理一行。
这样更容易发现 295 和 296 这种细小但影响解释的差异。
录入新学校以前，先完成至少一项专业的科目与来源核验，再加入公开案例。
不要复制其他学校的数据当占位。
这里有一个要提前处理的技术点。不要只用专业代码当主键。
推荐用学校和学院加专业代码做记录标识，再带上学习方式，把年度数据放到记录内部。
如果不同方向规则不一致，还得继续细分。
这样可以避免同校多个学院的 085404 互相覆盖。
第八步，加入地区快捷筛选和简称。
在现有的院校探索页增加全部地区、北京和上海三档快捷按钮。
快捷按钮与地区下拉共用同一状态，同时保留关键词筛选和学习方式筛选。
优先使用数据里的别名字段，支持常见的几种简称写法。
统计从当前数据动态计算。学校入口数量和专业样本数量分别展示，来源记录数量也单独给出。
每所展示的院校都要包含实际收录的专业和来源，不创建虚构专业。
应用专业条件时，只返回真正匹配的专业。
先检查现有实现，复用原有组件和事件，不要重建整个项目。
注意简称存在歧义的可能。全国扩展时，同一种简称可能被不同用户理解成不同学校。
本文样本采用明确的映射写法，全国版本更适合显示候选学校让用户确认。
第九步，验收之后再截图。
先测试，再拍展示图。建议至少保留这几类画面。
项目创建与模型选择。设计说明读取。资料图片输入。模型结构化回答。院校探索。专业详情。横向对比。单科不足。学习计划。扩展迭代。
一张图只承担一个主要问题。
长表按完整逻辑分段，每一段保留列标题或者在图注里说明接续关系。
不要为了完整把整页缩到文字无法辨认，也不要裁掉决定含义的年份和专项计划。
脚注同样要留。
手机端除了肉眼看，还可以在浏览器控制台跑一个只读检查。
看看视口宽度和页面宽度谁更大。
390 像素宽下，如果整个页面宽度更大，就继续定位溢出元素。
常见原因有三种。内联网格列定义覆盖了媒体查询。固定最小宽度。长网址不换行。
对比表内部滚动和整页横向溢出要分开看。
反馈模型时可以直接写复现路径和实际结果，再写预期结果与已经定位到的原因。
再要求它只修这一部分。
第十步，常见问题排查。
页面打开但没有数据，先看服务是不是从项目根目录启动的。
请求路径对不对。数据文件有没有语法错误。
点击页面链接就 404，先看有没有把路由误写成真实服务器路径。
换了数据界面仍旧，多半是浏览器缓存。确认读的是当前文件再刷新。
搜简称没结果，先看数据里有没有别名字段。再看看有没有其他筛选条件还开着。
加了学校统计数没变，先看统计是不是写死了。数据层有没有成功加载新增记录。
保存计划后变成两份，先看更新用的是不是稳定标识。保存动作是不是每次都新建了一个。
模型说测试通过而实际界面不对，就要求它给出可重复的操作路径和结果。
以浏览器实测为准。
做完这些步骤，得到的是自己从空目录生成、逐项核验的同类项目。
代码可以和本文不同，但关键行为应该可解释、可检查。
十、下一步值得做的扩展
如果继续维护，我会优先考虑四件事，而不是先加一个看上去精确的成功率百分比。
第一件是专业课变更记录。
把旧科目和新科目连起来，再带上生效年度、公告与最终目录。
考生可以看到变化过程，不需要从零散截图里猜。
第二件是个人择校清单。
在用户自己选的学校里记录预算和地区。培养地点和学制也要留位置，考试组合与待核实事项同样要记。
对未知条件明确留空，避免用自动排名替代个人偏好。
第三件是证据更新记录。给每条来源保留发布时间，检查时间和版本也要留。
新公告不能悄悄覆盖旧口径。链接暂时打不开时提示复核，不直接删除历史说明。
当前案例还没有实现自动监控后台。
第四件是基于差距的学习反馈。
先把用户自己记录的模拟成绩积累起来，再记错题类别和任务完成情况，观察学习变化。
这些可以用于计划复盘。但不能因为收集了几次分数，就宣称得到了校准过的个人录取概率。
真正的概率模型需要明确预测目标，需要同口径样本。
还要时间外验证和概率校准，误差分析同样不能省。
它还要处理复试表现和招生调整，样本偏差也得考虑。
本案例没有这些条件，所以继续保留「备考差距分析」这个准确名称。
从工程维护看，新增页面并不是最重的工作。
更长期的成本在于目录更新和学院改名。同代码多口径和缺失字段也要管，来源失效更麻烦。
先把数据身份和核验流程设计清楚，以后扩展到十所、上百所学校时才不至于反复返工。
这次用 Seed-2.1-pro 的价值，是让一个带真实约束的想法变成了可以点、可以改的工具。
处理京沪检索需求时，它能沿着项目上下文继续完成代码任务。
模型输出经过原文核对和功能验收，才成为最终页面的一部分。
