一条网站修改意见，应让没有参加讨论的人找到同一个位置，看到同一种现象，并按同一条件判断完成。页面地址、使用条件、当前表现和预期结果比“更高级”“更紧凑”更有用。截图辅助定位，实际步骤与保留范围决定怎样修改和验收。
第一行先告诉对方去哪里看
写出具体页面和区域，例如联系页快捷表单下方的详细需求入口，而不只说“下面那个按钮”。如果页面有多个相似组件，指出标题、相邻内容或使用位置，避免开发改了另一处。
使用条件也要保留：中文或英文，手机或桌面，窗口大致范围，默认、滚动后或展开菜单时。一个问题如果只在英文窄屏发生，不应写成整站按钮都错。条件越清楚，修改范围越容易控制。
记录页面版本或预览地址。多人看着不同预览讨论，会出现一方已修另一方仍在旧页的情况。截图最好带上时间与页面说明，但不要公开账号、凭据和无关私有信息。
成功标志是另一位人员按这条记录能找到对象，不需要回到聊天里询问“你说的是哪一块”。定位还没清楚时，不急于争论解决方法，先对齐看到的页面与状态。
描述实际表现，再写预期表现
实际表现应具体，例如长标题挤压图标、页面返回后残留选中状态、填充动效快速再次进入时覆盖不足。不要直接写“前端做错”，原因尚未确认时，这只是待调查的现象。
预期也要可观察。例如标题完整显示，图标不与文字重叠，点击区域保持可用；返回后按已确认规则显示状态。这样的表述允许实施者选择合适方案，也让验收者知道看什么。
假设意见是“服务卡片太挤”，可以改成“当前手机宽度下，正式英文标题与图标相互挤压；请保留完整标题和说明，调整内部排列后复查”。它说明问题与目标，没有提前把字号缩小当成唯一方案。
审美偏好可以保留，但需继续转为规则。觉得留白太多，可以指出哪组信息关系松散、希望哪些内容靠近；觉得不够醒目，可以说明读者是否找不到主要动作。不是每个偏好都需要技术解释，但进入修改清单就应有对象。
写清保留内容，减少顺手扩大修改
局部意见应注明不希望受影响的任务。比如新增入口要保留原表单、页尾与联系方式；调整按钮动效要保留目标和点击范围；修改手机卡片不应自动删掉必要说明。
这里的保留范围不是要求所有东西永久不动，而是本条修改的边界。如果实施者发现需要共同调整，应反馈受影响项目，再由负责人确认。不能把一句“小改一下”悄悄变成整页重构。
JVDS 自身需求入口记录中，新增位置、原联系内容、按钮状态与手机排版被分别核对。这些记录说明细化意见能够转成检查对象，不代表所有文章中的方法已经在站点全面实现，也不支持推断业务增长。相关操作可参阅《项目中途新增页面或功能怎么办？变更评估与确认流程》。
共用组件的意见还要说明范围。只改当前页面，还是按统一规则更新所有调用？如果没有决定，记录待确认。开发提出共用影响时，负责人应确认哪些场景继续测试，不能由最后一张截图代替范围决定。
附件说明什么，还缺什么
截图适合标位置和静态差异，可以用明确标注说明对象。录屏适合说明状态变化与动作顺序。文字则保留前提、预期和完成条件，三者各有用途。
只发截图圈一个地方，会让开发不知道是颜色、间距还是点击的问题。只发录屏，也可能让人无法确认哪个时间点是异常。附件旁边补一句问题和触发方式，能减少来回解释。
如果问题需要滚动、移入移出或提交才出现，写出操作顺序。假设按钮第一次正常，快速第二次异常，截图最终画面无法还原这个条件，应保留连续动作。
附件来自历史版本时注明，不能用旧画面证明当前仍有同样问题。若无法稳定复现，就记录出现时间与当时条件，作为调查线索，而不是要求开发凭一张偶发截图立即判断根因。
把多人的意见汇总成可执行条目
不同人提出相近意见时，先确认对象与目标是否相同。一个人希望按钮更短，另一个希望信息更完整，可能需要共同决定文案与布局，不能分别执行后反复覆盖。
一条意见最好只承担一个明确问题。若涉及位置、文案和操作，可在同一任务下分别列完成条件；若是不同页面、不同目标，就拆开记录。这样某项已完成不会掩盖另一项仍待确认。
冲突意见保留确认者与最终结论，不要求开发判断谁说的更重要。旧批注标明已替换，避免实施时把多个版本全都照做。内容和业务规则由对应负责人确认，技术限制由维护者说明。相关操作可参阅《设计与网站项目怎么验收？阶段确认、上线验收与最终交付》。
优先级根据实际影响讨论。核心入口无法使用与非关键间距偏差，不宜都叫紧急。这里无需复杂分级系统，但应让实施者知道哪些阻断任务、哪些可集中处理，以及暂缓后谁继续确认。
如果问题只在一份具体内容里出现，附上正式标题或脱敏样本，不要只给理想占位文字。长名称、缺失字段和不同语言可能改变表现。维护者用相同内容复查，才能知道是否处理了原来的边界。
修改意见还可以区分必须达到的结果与可讨论的手段。比如文字必须完整可读，但可以通过调整排列或更自然表达实现。若把某一种未经验证的手段写死，可能限制专业判断；如果确有品牌或业务限制，则明确其来源与确认人。
多个页面共用同一模块时，不必重复贴几十条相同意见。可以建立一条共用规则问题，附调用范围和代表样本，再分别记录页面例外。这样既能核对影响，也避免开发逐页修补而遗漏底层关系。
复查未通过时，保留原条目和新的具体结果。若现象变了，说明变化后出现什么，不简单写仍不满意。比如溢出消失但关键对象被省略，这属于需要继续确认的表达问题，处理方向可能与原来不同。
对于暂缓意见，写明原因和后续负责人。排期暂缓不等于问题已解决，也不需要不断重复新建同一批注。清楚状态能够让下一轮工作继续，不使旧意见因聊天滚动而消失。
修完之后，回到原条件复查
先按原来的页面、内容和操作重做，确认实际表现达到预期。若原问题在英文手机发生，就回到这个条件，不用中文桌面截图关闭问题。
再看相邻或共用影响。按钮变宽后是否挤压次动作，文案缩短后是否仍准确，卡片重排后目标是否一致。回归范围由实际改动决定，不必每条都测全站，也不能完全不看关联。
结果写已通过、仍有差异或待测，并保留对应证据。开发说已修改说明工作完成到一个阶段，验收还需实际核对。未通过时指出剩余现象，而不是重新发一条无对象的“不对”。
如果方案本身改变，应更新预期与版本，再复查新结论。不要为了关闭问题临时降低条件而不记录，也不要让验收继续按已弃用方案执行。
一条可复用的反馈记录
可以按位置、条件、现象、预期、保留范围、附件和确认结果组织。字段不需要复杂，填写时只保留对该问题有用的信息。静态错字无需长录屏，连续动效则不能省略动作。
假设反馈联系页新入口，可以写它在原按钮下方的具体位置，说明手机排版与目标页面，保留原快捷表单和页尾，再按点击与返回确认。假设反馈旧文文字，可指出段落与背景，保留原信息层级，保存后检查实际阅读。
交接时保留最终条目与结果，不让关键决定散落在几段语音和聊天图片里。下一位人员应能知道为什么改、改了什么和怎样判断完成，无需重新猜测上下文。
写好修改意见的完成标志，是对象定位一致、现象可复现或有线索、预期明确、范围受控、同条件复查有结果。它不要求业务人员提前写技术方案，却能让专业协作从一句感受推进到具体工作。
常见问题
不懂代码，也能写准确意见吗？
可以。描述页面、条件、现象与目标即可，原因和实现方法由维护者核对。无需把技术猜测当成已确认事实。
一张截图是否足够？
静态内容问题可能足够辅助定位，但仍需预期说明。动效、返回或提交问题需要操作步骤，必要时附录屏。
开发提出另一种方案，可以接受吗？
按目标与限制比较。若新方案达到完成条件且范围清楚，可以确认后更新记录，不需要机械指定原来猜测的做法。
同事意见冲突，应该都放进任务吗？
先汇总再确认最终目标。冲突未解决的部分标待确认，避免开发分别执行互相覆盖的要求。
修复后看着正常，能直接关闭吗？
回到原条件复查，并检查实际关联范围。结果与预期一致且必要操作可完成，再记录通过，不能只用另一个条件的截图。
链接复制成功
