联系页增加详细需求入口时，应先列出原来需要保留的内容与操作，再定义新增入口的位置和打开方式。新增功能验收通过，不意味着旧表单、地图、底部行动入口和页脚仍然完整。局部修改也需要一份明确的回归范围。
先保存原页，而不是凭记忆恢复
开始前保留页面内容、关键链接和必要截图，标出原有快捷表单、联系方式、互动模块、底部入口与页脚。保存的是当前确认版本，不是从旧设计稿挑一张相似画面。
若页面包含动画或拖拽，截图无法完整说明行为，应另外记录操作。表单则需要注明字段、提交反馈与后续结果核对方式。对于涉及实际发送的测试，使用经授权的测试流程，不把演示预览当成真实提交。相关操作可参阅《网站开发测试清单：功能、设备、浏览器、性能与安全》。
清单的价值在于定义保留范围。不是所有旧内容必须永远不变，但删减和替换应作为明确决定，而不是制作新入口时顺手省略。内容负责人能据清单说出哪些保留、哪些调整、哪些需要确认。
假设制作预览时只关注表单区域，省略了页尾模块。预览看起来紧凑，不代表这些删减已经得到确认。进入正式修改前应对照原页，补回保留部分或取得清楚的范围结论。
JVDS自身入口调整中的具体边界
JVDS 的需求页面记录明确了联系页新增入口，同时保留原来的互动模块、底部行动入口和完整页脚。历史预览还记录了对文字、图片及链接的逐块比对，并恢复了曾在预览中省略的区域。
这些记录说明新增入口与原内容保留需要分别验收。它们不是外部客户案例，也不支持推断咨询增长。记录中的交互核对属于对应版本的制作范围，不应写成今天所有浏览条件已经再次通过。
对类似工作，可以借鉴“新增位置”和“保留区域”两个清单。新增清单包括文字、位置、目标、打开规则与手机表现；保留清单包括原字段、原操作和页面结构。两份清单对应同一最终页面。
如果新详细表单与原快捷表单并存，还要说明分别适合什么任务。访客能简短联系，也能准备完整项目资料，入口表达应有差别。不能让两处按钮看起来相同，却进入完全不同的填写流程。
把一条新入口拆成可验收条目
第一项是位置。描述在什么模块、哪一段内容之后，不只写“放下面”。第二项是文案，让用户知道将进入详细需求填写。第三项是目标，实际打开对应页面，不指向旧地址或无关栏目。
第四项是打开方式。是否保留原页，是否请求独立页面，需要按流程决定并测试。第五项是显示，中文、英文和手机条件下是否完整、是否遮挡原按钮。第六项是状态，键盘与触摸能够激活，不依赖装饰效果。
意见中还应写清哪些原样式需要复用，哪些只属于新入口。若只改新链接，却影响了原提交按钮颜色或点击范围，就超出了预期边界。维护者需要判断共用规则是否造成连带变化。
成功标志是使用者能找到入口，理解与快捷联系的区别，点击后到达正确目标，同时原流程继续完成。每个条件都能通过实际页面核对，不以“新增链接已出现”结束验收。
按原任务做回归，而不是只看模块还在
原表单先检查字段与校验，再按授权流程检查保存和反馈。只看到表单外框，无法证明提交仍然有效。新增入口如果调整了事件或页面结构，也可能影响原操作，需要真实复查。
互动模块检查其原有任务。如果原本允许拖拽，就实际操作；如果只是展示，不必凭空增加新功能。底部行动入口检查目标与点击，页脚检查导航及必要信息。回归应围绕既有用途，不是重复截图数量。
联系方式也要核对。复制页面制作预览时，可能替换或遗漏真实内容，正式版本需要由负责人确认。不可因为新表单可用，就把电话、邮件或地址视为不需要检查的装饰。相关操作可参阅《联系我们页面怎么设计？表单、电话、地图和隐私提示》。
手机页面尤其要看新入口与原按钮的距离和顺序。新增一行文字可能使旧按钮、说明或固定内容互相遮挡。复查从页面开始一直到页脚，而不只在修改处截一张图。
新增样式如果与原按钮共用类名，需要特别核对影响。维护者可在技术记录说明规则范围，运营验收则观察原按钮默认、经过与点击。局部需求通常不需要知道样式如何实现，但需要确保改动只作用于已确认对象。
如果详细入口使用独立页面，目标页需要有清楚标题与联系背景，不应让访客误认为跳到另一家公司或无关工具。品牌名称、任务说明与返回路径由内容负责人确认，实际访问由测试者核对。目标清楚以后，再决定视觉细节。
某些联系页模块依赖外部或本地资源。制作预览时即使形状还在，互动可能因为资源缺失而停止。回归记录应区分可见内容与实际行为，必要时注明未加载或无法测试的部分，不以截图数量推断功能完整。
对原有图片与链接的比对，也应看用途是否继续成立。数量相同但目标被替换，不能算保留；模块仍在但内容变成占位，不能算完整。清单需要能指出关键对象，数量只是辅助核对。
维护交接还应写明以后新增第三种入口时如何检查。通常先判断是否与现有路径重复，再写清用途和目标，最后走原有任务。这样联系页可以持续扩展，而不会每次增加一行就重新猜测旧内容是否还有效。
新旧流程的结果分开确认
详细需求和快捷联系可能记录不同字段、使用不同处理流程。测试时分别标识，不把一条详细需求成功，当成快捷表单也成功。后台记录、页面反馈和通知到达也应按实际范围分别核对。
JVDS 自身需求通知曾通过后台记录与邮件实收共同检查。这个事实适合说明结果链需要多层确认，不代表新入口的每一项改动都自动包含相同通知能力，也不应披露内部邮箱或配置。
测试记录区分演示预览与正式页面。预览可能为了安全关闭真实提交，只能检查排版和操作外观。正式结果则需在正式范围内确认。不能将两种材料混在一起写成一次完整线上通过。
若发现某个旧流程原本就存在问题，记录为已有问题，不在新增入口完成后掩盖，也不把它无依据归因于本次修改。时间与版本记录能帮助判断范围，避免责任讨论取代事实核对。
管理修改意见和版本
所有意见汇总到同一条任务记录，标明本次新入口、原内容保留和发现的问题。若有人提出同时重做联系页，应重新说明扩大的范围，不能在原局部任务里悄悄完成整页重构。
每次预览注明对应版本，确认者检查同一个地址和同一份内容。截图上的入口位置若与最终页面不同，应更新记录，避免开发依据旧批注修改。
对明确保留的区域，说明检查结果和差异。可以写文字一致、链接目标已测、交互待测；不必为了表面完整把所有状态都填通过。待测项目有对象和下一步就能继续推进。
如果修改后回到原版本，应再次确认新旧资源对应，避免新入口消失但相关样式仍影响旧按钮。局部回退也有影响范围，不能只替换一个文件就推断页面恢复。
交付给运营的最终记录
交付时列明新增入口、目标页面、维护位置、原流程保留范围与已测结果。运营应能修改入口文字，知道详细需求与快捷联系的用途，遇到失败时能指出是哪条路径。
现场走一遍快捷联系和详细需求进入流程，核对页尾与手机布局。成功标志是两条任务各有清楚结果，保留模块可以按原用途使用，未覆盖项明确可追溯。
以后调整联系页时继续使用这份基线。新增入口的价值不只在它出现，而在整个联系过程仍能顺利使用。把局部变化与回归范围一起记录，才不会每加一个功能就丢一块已有能力。
常见问题
只加一个文字链接，需要回归这么多内容吗？
范围可按实际改动选择。至少检查相邻操作与共用规则影响，涉及页面重构时再扩大。关键是说明依据，不是每次机械测试全部网站。
原模块在截图里，还需要操作吗？
需要按用途确认。截图证明外观存在，不能证明表单提交、链接和互动仍可用，两类结果应分开记录。
详细表单能代替原快捷表单吗？
可以讨论，但这是流程变化，需要明确决定。原本只是增加入口时，不应自动删除较短联系路径。
预览中关闭了提交，怎么验收？
预览先验排版和入口，正式结果按授权流程另测。记录清楚环境，不用演示状态冒充数据保存和通知成功。
新入口完成后，旧问题怎么办？
保存发现时间与原始情况，明确属于本次修复还是另列任务。不能因为入口新增完成就忽略，也不无依据判定是新改动造成。
链接复制成功
