交给设计前的B2B网页内容底稿，不能只有“首屏大图、三项优势、案例区、联系我们”这样的版式占位。它应该是一份已经能够独立工作的页面文本：读者是谁，为什么会打开，这页帮助他完成什么，每一节说什么，哪些事实支撑，图片展示什么，各链接去哪里，以及行动后会发生什么。
设计负责把内容关系转化为清楚的视觉与交互，不应替产品决定能力、替市场发明证据或替销售承诺结果。越早把内容和事实写完整，越能减少原型、视觉和开发阶段的大范围返工。
先写一句页面任务，而不是先写标题
页面任务至少包括目标读者、进入情境、已有知识、要完成的判断和不讨论范围。例如：“这页给正在考虑统一多销售团队跟进记录的市场负责人看，帮助他判断现有数据是否具备开始条件，并理解首次整理会完成什么；本页不承诺自动补齐历史缺失数据。”
这句话不会全部显示在页面上，却能约束后续内容。若团队成员对读者和结果理解不同，应先解决分歧，再画页面。一个页面同时想说服老板、培训操作员、回答技术接口和发布公司新闻，通常需要主次路径或独立页面。
页面任务也决定CTA。初步理解页适合进入流程、案例或检查表，不一定立即要求咨询；服务评估页则可以说明预约沟通需要准备什么。
盘点材料并标记事实状态
把公司PPT、产品文档、销售材料、客服问题、合同范围、案例授权和现有网页集中起来。每条材料标记为已确认事实、需要补充解释、已过期、存在冲突、尚不能公开或需要授权。
记录来源、版本、负责人和核对日期。“支持数据导入”可能来自旧PPT，但当前只支持部分格式；“某客户提升三倍”可能缺少口径或公开授权。编辑和AI不能选择更好听的一版，应把冲突交给有权限的人确认。
旧资料仍有价值，可以帮助发现客户曾经问过什么，但历史说法不能自动成为当前产品事实。底稿中把已确认内容写进正文，未知项留在内部问题清单。
一份完整底稿需要哪些部分
先写页面标题和开头答案，让读者迅速判断相关性；再按客户任务安排章节，解释概念、过程、条件、角色、输出、证据、限制和下一步。每一节应有真正正文，不用“此处补充优势”占位。
图片需求也要写清：需要真实产品截图、流程示意、人物照片还是摄影作品；图片要证明或帮助理解什么；是否需要脱敏和授权；替代文本怎样客观描述。没有合适图片时先完成文字，不用无关装饰代替证据。
链接表要列出锚文本和目标URL。概念链接到概念页，方法链接文章，服务链接服务主页，证据链接来源，下一步链接对应动作。不要让设计完成后才发现目标页不存在。
用“问题—过程—结果—边界”写服务或产品
客户问题要使用客户能理解的语言，不只写内部项目名。过程说明企业或产品在哪些步骤参与、客户要提供什么、双方怎样协作。结果写可交付、可观察的变化，不把期望包装成必然。边界说明不适合情况、依赖条件和不能承诺的事项。
例如“线索历史查询”可以写：先统一联系人编号，跟进时保存问题、回应、时间和负责人，授权角色按编号查看历史；若旧记录没有时间或负责人，导入不会自动创造缺失事实。这个说明比“全生命周期智能闭环”更长，却能支持真实判断。
涉及数字时写明对象、周期、分母和来源。教学数字明确标注为示例；公司数据、行业结论和客户效果没有可靠依据就不写。
把协作和核对写进底稿
为每一段标明信息提供者和批准者。产品核对能力与限制，交付或客户成功核对实施过程，销售提供客户原话与常见异议，法务或安全核对敏感事项，品牌负责人核对名称与公开表达。
内容负责人负责组织事实、保持语言一致、发现缺口和记录版本，但不替专业人员承担真实性。不同人提出相互冲突的说法时，正文暂不发布，问题进入决策记录。
批准不能只发生在最终截图上。正文完成后先做事实审校，结构稳定后再做视觉；重要改动重新核对受影响段落，不因为已经进入开发就降低标准。
设计交接具体交什么
交付包应包含页面任务、最终文案、标题层级、模块顺序、图片与授权清单、链接清单、CTA说明、表单字段、错误与成功状态、SEO标题描述、Canonical、Schema所需事实、移动端优先级和待确认项状态。
原型需要表达页面关系、交互和跳转，不只是灰色方框。设计稿应显示真实文字，因为占位文本无法暴露标题过长、表格溢出、证据位置和阅读节奏问题。开发获得的是可实现的组件与状态，不再从截图猜交互。
若内容变化会改变页面结构，先回到内容和原型确认，而不是让开发在代码里临时拼接。网站建设步骤可参照课程关于先内容、再原型、后设计开发的原则。
让陌生人只看底稿完成任务
选择未参与项目、知识水平接近目标读者的人。请他复述页面给谁、处理什么问题；指出一次完整过程；找到开始条件、证据和限制；说出点击CTA后预计发生什么。测试中不要解释，只记录停顿和误解。
若他能读完却无法说明产品怎样参与，补过程；把教学示例误认成客户案例，补性质说明；找不到下一步，修链接与CTA；术语看不懂，在首次出现时解释或链接概念页。
测试不是让所有人喜欢文案，而是检验目标任务是否能完成。非目标读者提出的需求可以记录，但不必全部塞进当前页。
发布后仍要保留来源与责任
底稿、来源、批准记录和已发布URL放在共同位置，标明生效日期和负责人。产品或服务变化时，根据字段与页面关系找到受影响内容，重新核对，不从旧PPT重新搜索。
上线后观察搜索词、阅读路径、表单故障、客户问题和销售反馈。数据说明哪里需要调查，不能直接代替原因；修订时保留版本和更新时间。信息架构与内容字段的长期治理可继续阅读B2B官网信息架构怎么规划。
底稿也应为SEO与GEO保留明确实体和关系：页面唯一主题是什么，企业、作者、服务、案例和来源怎样连接，标题、可见正文与Schema是否表达同一事实。结构化数据只能复述页面已有内容，不能在代码里补一个正文没有的能力、评价或日期。
内容负责人最后还要检查复用边界。销售摘要、活动课件和社交内容可以从主页面提炼，但不得改变产品事实；多个渠道发现错误时应回到主底稿修订，再同步受影响版本。这样页面不是一次性交付，而是组织可持续维护的内容母版。
如果页面涉及表单，还要把成功、失败、重复提交、通知和隐私提示写进交付。只画一个默认状态，真实用户遇到错误时就没有解释；表单后的负责人、响应范围和数据去向也应由业务与合规共同确认。
页面底稿还应写明哪些信息必须在首屏或首个完整段落出现，哪些可以延后展开，防止视觉取舍把适用对象、核心答案或关键限制移到读者很难发现的位置。
合格底稿的判断很简单：没有设计图，陌生人也能看懂；进入设计后，每个人知道自己在表现什么；上线以后，团队知道事实来自哪里、由谁维护。