先把讲解时补充的内容写下来，再决定网站结构。交给 AI 的资料应能回答：产品服务谁、解决什么任务、怎样使用、有什么依据、需要哪些条件，以及访客接下来能做什么。
产品演示文稿可以保留为素材，但不宜直接充当全部网站文案。演示时，销售会解释术语、补充客户背景、跳过不相关功能；官网需要把这些信息放在访客找得到的位置。AI建站资料准备的核心，就是把依赖讲解者的表达，改成读者能自行判断的内容。
把演示文稿中的每页单独打开，不看备注，也不解释，问自己：陌生人能否说出这页在讲什么、与自己有什么关系、结论受哪些条件限制？凡是需要补一句“这里其实是说……”的地方，都应列为缺口。
建议找产品、销售和交付人员共同补充。产品人员解释功能机制，销售整理反复被问的问题，交付人员补足实施条件。不要只把销售话术转成文字，还要确认承诺是否符合实际交付范围。
建立一张缺口表，逐项填写“缺少的答案、负责人、处理方式”。涉及产品范围、价格和案例授权的事项，确认前不要进入公开文案。纯粹用于内部讨论的设想，应与可发布材料分开。
二、逐页审查时，具体需要补什么？
下面是建议使用的审查表。每一行都应留下明确文字，不能只用“详见演示”代替。
| 演示文稿中的材料 | 访客可能无法理解的地方 | 建站前应补充的内容 |
|---|---|---|
| “一站式解决方案”等口号 | 到底是什么产品、给谁用 | 产品类别、使用角色、具体任务 |
| 功能图标或模块名称 | 模块怎样参与日常工作 | 输入、操作、输出与使用条件 |
| 产品界面截图 | 当前是什么角色、正在做什么 | 界面任务、必要前置步骤、结果解释 |
| 客户标识与评价 | 客户实际使用了哪些服务 | 授权范围、使用背景、原文出处 |
| 效果图表 | 数据口径和比较条件是什么 | 指标定义、时间范围、样本与限制 |
| 套餐或报价页 | 哪些包含、哪些另计 | 计费单位、服务边界、报价影响因素 |
| 最后一页联系方式 | 联系后会发生什么 | 行动目的、提交材料、后续处理方式 |
如果一张图同时讲产品架构、操作步骤和业务结果，先拆清三个问题，再分别写成段落。无需要求访客理解内部架构后才能知道产品有什么用。
三、首页先让访客认出自己的场景
首页开头建议采用“谁在什么情况下，用什么产品完成什么任务”的表达。它比抽象形容词更容易检查：只要缺少角色、任务或产品类别，就继续补充。
以一个假设的预约管理产品为例，“重新定义服务体验”可以改成：“面向需要安排到店服务的门店，集中管理预约时间与服务人员排班。”随后再说明目标客户必须具备的业务条件。示例中的能力需要由实际产品负责人确认，不能直接套用。
同时准备不适用场景。若产品不覆盖某类预约规则，或者需要额外系统配合，应放在功能说明或常见问题中。访客可以据此自行筛选，团队也能减少对明显不匹配需求的重复解释。
四、怎样把功能名称改成可理解的使用过程？
每个核心功能都准备一张说明卡，包含“使用者、触发情境、需要提供的材料、执行动作、得到的结果、适用限制”。网站不一定逐项展示这些字段，但资料中必须有答案。
仍以上述假设产品为例，“智能排班”不足以说明流程。可以写成：门店负责人录入营业时间与人员可用时段，再按实际规则安排服务；访客选择预约时段后，负责人能够查看对应安排。是否自动分配、是否处理冲突，则应按照产品实际能力明确说明。
对截图也采用相同方法：用正文说明截图展示的任务与结果，不把关键规则只留在图中。复杂流程可分别解释开始前的条件、进行中的操作与结束后的状态，让访客从任意相关页面进入时，都能理解当前内容。
五、案例与效果结论，需要补齐哪些证据？
演示中讲解者可能会口头说明“这是特定客户在特定配置下的结果”。转成官网后，这些限制也要保留。否则一句简短标题可能承担超出材料范围的承诺。
案例资料应包括客户背景、原有问题、采用的产品或服务、实施条件、结果依据及公开授权。涉及数字时，还要提供指标定义、统计期间、比较基准与适用范围，并把对应出处放在结论附近。
没有足够结果材料时，可以写清实际完成的工作，例如梳理了哪些流程、交付了哪些页面，避免自行推算收益。尚无可公开案例时，可以使用明确标注的业务示例解释流程，但不能配上真实客户名称，让示例看起来像已发生的项目。
六、定价或方案说明页怎样补到能做初步判断？
访客不一定需要立刻获得精确报价，但应能判断方案与自己是否匹配。建议补充定价或方案说明页，写清方案面向谁、包含什么、如何计费、哪些项目需要单独确认，以及开始使用的条件。
采用定制报价时，可以说明影响报价的因素，例如交付范围、页面数量、接入需求和后续维护安排。只填写真实适用的因素，不要为了显得完整而加入并不提供的服务。
对“预约演示”按钮也要补充说明：演示主要讨论什么，访客需要准备哪些业务信息，提交后由谁承接。响应时间必须符合团队实际安排；没有固定时限时，避免写成即时响应或保证交付。
七、怎样从演示顺序重新组织网站？
不要默认一页幻灯片对应一个网页。更适合的做法是先按访客的问题归类，再决定页面：认识产品、判断适用性、理解功能、查看证据、了解方案、采取行动。
几分钟搭建展示站并增长获客
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
可以从首页、产品页、场景页、方案页和联系页起步。内容较少时，让相关信息放在同一页；只有能够独立回答问题时，再拆成单独页面。场景页说明角色与任务，产品页解释机制，案例页呈现具体实践，彼此保持清楚的链接关系。
阿里云建站官方文档将自然语言描述需求、确认需求文档、生成编辑与发布列为建站步骤。准备资料时，可以参考这一分工：先明确页面要回答的问题，再进入生成和调整。这个流程不代表工具能替团队决定尚未明确的业务规则。
八、交给 AI 的资料包应该怎样写？
资料包建议采用一份总说明加按页面整理的正文材料。总说明交代产品名称、目标受众、网站目标、术语和可发布范围；页面材料则写明要回答的问题、可用事实、证据位置和行动入口。
可以参考以下交接示例，按实际业务替换内容：
网站目标：让门店负责人判断预约管理方案是否适用，并提交演示需求。
主要受众：负责门店运营与排班的人。
产品页任务：解释预约信息从录入到查看的过程，说明必要配置与限制。
材料要求：沿用已确认的功能名称；示例必须明确标注；案例与数据只使用获准公开的内容。
内容缺口：没有明确答案的地方列入待确认事项，不进入上线文案。
行动入口：预约演示，说明需要填写的信息与后续联系安排。
这些是内容交接要求，具体工具如何执行仍需逐页检查。若文稿与补充说明存在冲突，应先由负责人确定最终口径，再交给生成环节，避免让工具自行选择版本。
九、使用 we0 时，资料准备怎样进入建站流程？
we0 官网介绍的建站步骤包括用自然语言描述想法并附上参考图和文档，由多 Agent 团队搭建，再通过可视化画布调整并部署。对于依赖讲解的演示文稿，可以先准备好产品定义、页面任务和方案边界，再将文稿作为补充素材提交。
初稿出来后，优先核对正文有没有改变产品含义：功能是否扩大、案例限制是否丢失、方案差异是否写清、按钮是否通向合适的下一步。内容口径稳定后，再调整布局、视觉和细节，减少因基础说明变化而反复修改页面。
十、怎样确认访客真的能独立读懂？
邀请不了解产品、但接近目标客户的人试读。给对方一个实际任务，例如“判断这套方案是否适合你管理门店”，让其自行浏览，观察时先不补充解释。
试读后请对方用自己的话回答以下问题：
- 产品是什么，主要给谁使用？
- 它能解决自己的哪项工作，不能覆盖什么？
- 开始使用前需要准备什么？
- 页面中的案例或结果依据是什么？
- 方案范围和费用如何进一步确认？
- 点击主要按钮后，接下来会发生什么？
记录对方停住的位置与误解的词，而不是只问“感觉清不清楚”。随后分别修复缺少答案、表述含混和入口难找的问题。
完成内容试读后，还应检查电脑与手机上的阅读和操作。阿里云开发者社区的建站实践文章也建议在编辑后切换电脑和手机预览。多端预览用于检查呈现效果，仍需另外确认表单能提交、链接能打开、关键限制没有被折叠或截断。
FAQ
可以只上传产品演示文稿，让 AI 补全文案吗？
可以把文稿作为输入材料，但不能把缺失的业务事实交给 AI 猜测。先补齐目标用户、使用过程、方案边界与证据；尚未明确的事项应由负责人处理，再决定是否公开。
没有价格表，就不能发布官网吗？
可以先提供方案说明与询价入口。关键是让访客知道适用对象、包含范围、影响报价的因素及询价需要的信息，不必虚构统一价格。
演示视频能替代完整的产品介绍吗？
视频可以补充演示过程。建议同时提供文字说明，让不方便播放、只想快速判断，或者从内页进入的访客也能找到主要答案。
怎样避免把官网写成另一份冗长说明书？
首页回答产品是什么和适合谁，详情页承接流程、证据与条件。每个页面围绕明确问题展开，删除不影响访客判断的内部背景，并通过链接提供进一步阅读入口。
Related Tools
- AI 建站工具：在业务资料明确后生成页面初稿，再逐页审核内容与交互。
- 共享文档或表格：整理内容缺口、负责人、公开范围和最终版本。
- 试读记录表与浏览器：记录理解障碍，检查不同设备上的正文、导航和表单。
Related Links
Summary
把需要讲解的演示文稿交给 AI 建站前，先补齐背景、过程、证据、方案条件与行动说明，再按访客问题组织页面。交付资料时明确可公开的事实和未解决的事项，初稿完成后通过陌生访客试读与多端检查验收。判断资料是否准备充分的标准，是访客能否自行说清产品与自己的关系，并找到合适的下一步。
