第四周记录范围：2026 年 10 月 26 日至 11 月 1 日；整理于 11 月 1 日。文中配图均为本文新画的示意或虚构例子，不是原项目的页面、素材或数据。
有一次收到反馈，说手机上的菜单显示不全。
截图里只有那一处。我把后续检查扩到了整个手机端，不只处理截图里看到的地方。这一查又找出几处：页头挡住了目录标题；搜索框里一长串不断开的文字，能把整个手机页面撑宽；有些卡片和正文的换行也不对。表格可以保留内部滚动，其他内容都要收在屏幕宽度以内。
另一个演示页面里的"更多"菜单也一起看了：能不能用 Esc 关掉，Tab 键会不会在菜单里循环，关掉以后焦点能不能回到原来的按钮，菜单开着时背后的页面会不会跟着滚，横屏时菜单里面能不能自己滚动。输入框和筛选控件在窄屏下的空间也重新核对过。这些是在不同屏幕宽度下查的；模拟宽度能找出布局问题，代替不了真机上的完整检查。
这周我在推进网站交付：自己看预览、试入口，也把需要协作完成的修改、检查和发布接起来。演示看板和文案校对是同时推进的另外两条线。
交给别人用之前
新版先放在一个独立的预览环境里联调，旧版原样留作回退。
预览里首页正常，文章列表却报加载失败。接口返回的是成功状态，问题在于少了允许预览域名读取的响应头：浏览器收到了回应，却不让页面读取；表单提交前的预检请求也没通过。调整以后，预览和正式两个域名都能读到，文章卡片恢复了。
页面能在浏览器里显示出来，也还不够。直接打开一篇文章的地址时，服务器要能返回正文、正确的规范地址和状态码；旧链接要接到新位置；不存在的文章要真的返回 404，而不是一张看起来正常的空页面。预览站带着"不要收录"的标记，换到正式环境时，要再确认它没有被一起带过去。表单的错误路径单独检查，不能据此记为一次真实提交已经成功。
旧站的文件和数据先备份到不公开的位置，又在一个隔离的副本里恢复出来，打开首页、几个内页和一张上传过的图片对照。这验证的是"能恢复"，不等于在正式环境里做过一次恢复。
哪些检查必须通过、哪些问题不挡这一步、旧版留多久作为回退，这些由我来定。切换前，候选站的公开文件逐个核对过散列，路由、状态码和搜索相关的设置也查了一遍。
上一周那段可以自己转着看的交互展示，也出了状况。我的手机上，一开始一直停在加载中，后来能显示，但很慢；另一个测试用的浏览器里，报的是图形环境建不起来。这是两个不同的观察，不能并成一个原因。资源文件夹里模型和贴图有多大，也不等于手机实际下载了多少、花了多久。没有在手机上分阶段测过，就先不把问题归给服务器、后端，或者刚修过的菜单。我决定把加载速度单独记下，这轮先保留现有展示。
后台入口，地址之后还要查什么
网站上的后台入口，一开始指向的地址打不开，另一个地址下的后台却能用。我在那边自己登录过：文章、编辑页和版本列表都读得到，刷新以后也还保持登录。评估过影响以后，入口先改成跳到那个能用的地址。
可后台本来应该放在网站自己的地址下，跳到别处不符合这个要求。我指出入口位置仍然不对。这一处继续处理，已经做好的主站和交互展示也要保住。
之后，预期地址下有了登录页。到这一步，我把要核对的分成了三件事：页面打不打得开；页面发出去的请求，有没有到该到的地方、拿回该有的回应；登录以后，能不能真的读和写。登录页在，只回答了第一件。未登录时得到"需要登录"的回应，也只说明请求到了该到的地方，不说明登录以后能读能写。
另一个地址读得到文章，不能拿来证明这里的后台也写得进。
两边的公开内容一样，也不能说明背后写进的是同一套数据。登录以后的实际操作，仍需要在这个入口下单独核对。
回退安排也在这时定了下来：保留最早的旧站和数据，后面每次迭代不再各做一套回退包。旧站可以回到最初的版本，但每次只覆盖部分文件的更新包不是整站备份，不能写成每次更新都能一键撤销。
配色和合作机构页，先看预览
配色这一轮，我还是先看预览，再决定留下什么。
目标是更有层次、更有气场。第一版我觉得还不够；后一版颜色丰富了，首屏的文字、产品展示的构图和标志却一起变了，还多出一个原本没有的展示台。我指出配色调整不包括换内容：文字、首页视频、构图和原标志恢复，新加的展示台撤掉。留下来的是颜色、主题切换，以及交互展示里必要的颜色适配，原来的模型、动作和叙事不动。
之后比较两种视觉处理，各导出一张完整长图：同样的内容、同样的滚动顺序，连交互展示的过程也拼了进去，放在一起从头看到尾。我看过认可，之后再经过检查和发布。最后浅色是默认，深色可以切换，并且会记住选择。发布前，原来的文字、媒体引用、标志文件和链接也和旧版本逐项核对过，没有只凭截图判断"内容没变"。
合作机构页随后单独比较方案，方向是让画面更高级，现有文案和标志保留。讨论过左边放说明、右边几列标志、更轻的分隔线和手机单列；标志不能裁掉白边、加滤色或改比例，也不能为了缩短页面，把带小字的标志压成很小的横条。我同意做一版看看，不合适就不要。看了预览，我觉得没有原来好看，分栏试版撤回，恢复居中布局。
页面上还要加新的条目。素材有好几个版本，放在一起比较时，我还追问其中一家为什么选了白底、没有小副标题的那一版。按页面上实际的显示宽度，主标识要清楚，那行小字硬塞在图里只会看不清；对方的业务说明就放到下面，用正常字号写。另一家选了高清的白底原版，避开较小的深底图带来的压缩和底色色块。
介绍文字查了对方的公开信息再补。补完我又觉得新条目太长，和旧条目放在一起不协调，于是继续删短，跟原有条目的行数和标签位置对齐。介绍只写对方公开的业务范围，没有顺手写成已经合作落地。原有的条目和顺序都不动，只加新的条目和原样的标志图片。
合并的是这些，线上的是哪一版
页面认可以后，颜色和合作机构页这两件事进入了 PR。后来发现它们被整理进了同一个 PR。我追问为什么没有分批，决定撤回，再按交付范围重新拆：主题和切换一批，合作机构的内容和素材一批，各自检查再合并，最终内容与认可过的版本一致。
代码理顺了，线上跑的是哪一版还要另外记清楚，免得以后对不上。
发布时用的是一份独立快照，里面保留了此前的修复和一些附加文件；后来仓库里的提交历史，不一定等于当时构建用的来源，只记一个提交号，就可能漏掉那些附加文件。补记录时，把发布用的工作区和对应提交里的已跟踪文件逐个比较，确认文件一致。这说明来源对得上；页面行为对不对，另有功能检查的记录。
主题发布那次还遇到过一件事：带临时参数的地址已经是新版，普通网址还在返回旧页面。前后两个包里的页面内容逐字节相同，差别在归档信息上；修正归档信息以后，普通网址也显示了新版。只看带参数的地址，就会漏掉普通访问还没更新这件事。
最后的记录从实际用到的源文件和附加文件开始，接到构建产物、服务器上的文件，再到普通网址返回的页面。文件清单和散列留下内容比对，功能检查另外记录页面行为。不同部分各有各的发布范围，不拿一个编号概括全部。
最后留下的部署说明，写到了从哪里进、点哪个按钮、填什么、为什么要做这一步、怎样确认成功、出问题先看哪里，首次部署和日常更新分开。它和发布记录放在一起，以后我自己操作，或者交给别人，都有东西可查。
演示看板的数字要能对上
这周也在调整一个演示用的数据看板。上面的数字是演示数据，不代表实际效果，但概览、分析和报告不能各用一套数；一条记录被发现、被确认、处理完成、关闭，时间先后也得说得通。
时间指标调整了几轮，后来我进一步明确了要展示的过程：从系统发现问题，到使用者处理、系统判定事情已经处理完成，这一段才是我要的。按这个定义，终点落在"处理完成"，而不是有人按下确认按钮。
原来从发现到有人确认接手的用时仍然有用，单独保留；另外算一项到处理完成为止的时长。名称中途改过，最后我的选择是保留"响应时间"这个叫法，在旁边注明它的终点，详细定义放进提示和报告。还没到处理完成、缺少结束记录，或者以别的方式结束的记录，都要有明确的处理规则，不能混进这一项。数字、时间点和计入范围一起改，否则只是换了标签和单位，底下算的还是原来那一段。
比例也有类似的问题。一条记录可以同时带两个分类，分项各记一次，总体只能算一次。分项加起来不是总体；几个分项或几段时间的百分比直接平均，也可能忽略各自的分母不同。要先分别累计数量，再算比例；新加一条记录时，列表、分项和总体也要按同一套规则一起变。下面换成一组虚构的还书记录，可以切换几种算法看差别。
两周合计的比例怎么算？
分子分母数的都是记录：20 条里有 4 条带标签。
同一条记录可以带多个标签。选择规则，再看分子究竟数什么。
第 1 周 · 4 条
第 2 周 · 16 条
- 分子 · 带标签的记录
- 4
- 分母 · 记录总数
- 20
- 结果
- 20.0%
4 / 20 ≈ 20.0%
百分比显示保留一位小数，计算使用未取整的值。
标签次数：逾期 3、破损 2、缺页 1；共 6 次，涉及 4 条不同记录。
分子 4，分母 20，结果 20.0%。
报告最后的后续建议也改过。我指出，不同的问题需要不同的后续行动：有的做一件事就够，有的需要另一种处理，少数才需要几样一起做，不能把所有可选行动机械地挂在每一条后面。后来建议按每条记录的情况来选，挪到报告末尾，和前面的记录一一对应。读完要知道该做什么，而不只是多出一个"建议"标题。
页面上的问题，靠完整截图来看。我先指出右侧排版不协调：时间和名称挤在一起，行高也不齐；接着又指出侧栏背景只铺到半页。整理称呼时，去掉一个泛泛的称呼，一个需要保留的角色信息也跟着没了；我把这层身份信息重新说明，之后名称、身份和说明分开确认。截图不够清楚，就重新导出更清晰的版本，留着继续对照。
这轮调整还带出一项单独的研究：一套演示的数据从哪里来、在哪里运行、怎样更新、刷新以后还剩下什么，换成真实数据时又有哪些保证会变。通用的部分整理成了模拟系统的独立设计笔记，里面用的是一个虚构的会议室预约例子。
文案校对：先能找回原处
文字校对这一块，对外展示的文字配上中英文和它在网页上的位置截图，整理成了能逐条审阅的页面。每条记录都带着页面、区块和来源，从一句话能跳回它在画面里的样子。浏览器没截到的部分展示状态，从源文件补进来并单独标出，不当成逐个画面看过。
工具也按我实际审的方式改。原来的状态下拉框用起来太慢，后来换成一键按钮；重点问题旁边写上建议状态、下一步和待确认的事。状态和备注存在本地，刷新以后还在，可以导出、导入；工具以后更新，旧记录也要能继续用，已经写下的意见不能被清掉。AI 的初审建议单独放一栏，有了一个改法，也不会自动把这条标成"已审"。
问题要按性质分开处理。涉及数字依据、适用条件或事实状态的，要回到事实去确认，不能先润色成确定的说法；字面上的毛病，可以直接写修改意见；还有一类是提取本身造成的：网页上的换行在提取后粘成一句，装饰用的首字母被拆成单独一条，源码里的符号混进清单。这类得先回原页面看，照着清单改，反而会把本来正常的地方改坏。
这些材料留下的是覆盖清单、一轮初审，和一个能持续记意见的工具。逐条的人工校对还没全部做完；按钮记下的是处理意见，网站修改、事实确认和最后复核，各自还要接着做。
那张菜单截图，最后带出的是一整轮手机检查。其他几条线也留下了各自的记录：整页对照、审阅备注、发布来源和操作说明。后面再改，可以从具体那一处接着走。