网站设计流程：页面标题与正文怎样对应-协作交付不返工
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /55a89c4695b2.html
📄
网站设计流程：页面标题与正文怎样对应-协作交付不返工
页面标题与正文的对应关系，指的是标题承诺什么，正文就交付什么。在网站设计流程里，这属于内容结构环节：标题决定这一页要解决哪一个问题，正文按同一个问题展开，不能中途换成别的话题。多人协作时，把这种对应关系写进交付说明，能减少文案、设计、前端之间反复确认的成本。判断是否对应，只看一件事：把标题遮住，正文是否仍然指向同一个具体问题；把正文遮住，标题是否已经说清这页给读者什么。
观察：先找出标题与正文脱节的位置
拿到一份页面稿，按下面顺序看，不要一上来就改文字。
- 看标题里的核心名词，是否在正文第一段就出现，并且被解释或展开。
- 看正文每个小节，是否都在回答标题提出的那个问题，有没有整段跑题。
- 看正文结尾给出的下一步，是否和标题承诺的方向一致。
- 看同一批页面之间，标题是否互相重复，导致正文内容也跟着重复。
如果标题写的是“安装步骤”，正文却在讲选型理由，这就是典型脱节。脱节不一定错，但必须决定：改标题，还是改正文。
判断：用两个问题决定改哪一边
第一个问题：这页要服务的读者任务是什么。第二个问题：现有正文里，哪部分内容最完整、最值得保留。两个答案一致，就改标题去贴合正文；不一致，就改正文去贴合标题。
协作场景里更常见的做法是以标题为准改正文，因为标题往往已经写进页面清单、导航文案和推广素材，改动成本更高。但如果正文来自更可靠的信息源，比如已确认的操作步骤，那就反过来改标题，并同步通知用到旧标题的环节。
判断结果分三种：
- 标题和正文指向同一问题，只是详略不同——保留结构，补足正文缺失的部分。
- 标题指向A，正文主要讲B——先确认哪个是读者真正需要的，再决定保留哪一个。
- 标题过大，正文只覆盖其中一小块——缩小标题范围，或拆成多个页面。
处理：把对应关系写成可交付的约定
在网站设计流程的交付文档里，每个页面至少写清三项：标题、标题要回答的问题、正文必须覆盖的要点。示例（假设）：
标题：发票信息怎么修改
要回答的问题：已提交的发票信息能否改、在哪里改
正文要点：可修改的范围、操作路径、改不了时的处理方式
这样写的好处是，文案、设计、前端拿到的是同一个判断依据。设计排布时可以据此决定哪段内容需要突出，前端也能判断哪些内容是主体、哪些是补充说明。标题里出现的词，正文应自然使用，不必刻意堆叠，但也不能换成完全不同的说法，否则读者会觉得进错了页面。
如果是历史页面改版，注意不要把旧版面的入口位置、按钮名称当成现在仍然有效的信息写进正文。没有核实过当前状态时，只描述读者要完成的任务和判断方法，具体界面以实际核对为准。
复查：交付前用一份清单过一遍
复查不需要复杂工具，按清单逐项确认即可：
- 标题是否只讲一件事，正文是否也围绕这一件事。
- 正文第一段是否直接回应标题，而不是先铺垫背景。
- 每个小节是否都能挂回标题，挂不回去的考虑删除或另开页面。
- 标题里的关键说法，正文是否有对应解释，没有就补上或改标题。
- 同一批页面的标题是否重复，重复的合并或区分开。
复查发现的问题，记录在交付文档里并标注处理方式：改标题、改正文、拆分页面或合并页面。多人协作时，这类记录比口头说明更可靠，下一轮修改可以直接对照。
下一步：挑出当前项目里标题与正文最容易脱节的两个页面，按上面的三项约定补写交付说明，再让另一位协作者只看标题猜正文内容，猜不中说明对应关系还需要调整。
