- 你有可供检查的当前页面、截图或源代码。
- 你能明确一类目标读者、他们的任务以及下一步行动。
- 你希望得到一份有证据的问题清单，以及一项范围明确的修改。
- 你能审阅修改，并在之后邀请相关人群测试理解情况。
使用场景中文
资格边界
先明确审查面向谁、要解决什么问题。
页面看起来精美，仍可能让不合适的访客不知道该做什么。在修改标题或布局之前，先写清谁应该采取行动，以及为什么。
- 你希望在没有真实实验的情况下获得转化预测、注册增长保证或 A/B 测试的胜出结论。
- 你想把 AI 审查当作对真实客户的访谈。
- 你需要安全、合规或生产就绪认证。
- 你期望自主浏览器审查、自动修复与复测，或未经审批的修改。
最小完整工作流程
从一个可见问题，走到一项通过检查的修改。
你可以自行使用工作表，也可以把页面背景带入 Soloop。先讨论发现；如果需要实施，再审阅一项单独界定范围的 Build 任务。
- 01
固定页面版本和目标读者
保存当前网址、带日期的截图或提交版本。说明读者是谁、目前采用什么替代办法，以及页面应当支持的一个行动。不要在一次审查中混合多个受众。
- 02
检查承诺、证据和下一步行动
开头的文案是否说明了具体任务和受众？每项重要主张是否有相关证据支持？行动按钮（CTA）的目标页面是否符合按钮文字的承诺？把对读者反应的判断标记为假设。
- 03
让每项发现都对应具体页面内容
针对每个问题，引用相关文案或指出具体元素，并写明观察到了什么。缺少解释、措辞含糊和链接失效是不同问题，需要分别检查。
- 04
选定一项修改和验收标准
优先处理最接近目标行动的问题。明确要改什么、必须保留哪些证据、哪些内容不在范围内，以及如何在桌面端和手机端检查结果。
- 05
审阅实施任务
如果希望 Soloop 修改页面，请提供受支持的代码仓库或项目背景，并审阅常规 Build 任务。在审批前确认文件与页面范围以及验收标准。仅有截图并不意味着拥有网站编辑权限。
- 06
先检查修改，再检验假设
按照验收标准检查返回的修改。另行询问相关人群理解了什么，并观察他们采取的行动。记录仍不清晰的部分。代码检查通过，并不能证明转化率提高。
可检查的控制
审批卡片示例：让一项页面承诺更具体
这是一张示意性的任务卡片，不代表已声称的客户结果或已完成的实验。
- 目标
- 帮助代理机构的客户经理理解客户项目交接产品已有的用途，同时不添加缺乏依据的效果承诺。
- 行动
- 修改所提供页面源代码中的首屏标题和解释语句。保留布局和行动按钮的目标页面。返回修改内容和验收检查结果，供审阅。
- 对象
- 一个由创始人持有的落地页及其提供的代码仓库。不涉及价格、注册流程、其他页面或外部账号。
- 验收标准
- 文案明确受众和已有的交接任务；不添加客户数量或性能主张；行动按钮的目标页面保持不变；文字在 390px 和 1440px 宽度下均不造成页面溢出。
- 停止条件
- 如果无法从提供的背景确认产品行为、代码仓库不可用，或修改需要扩大范围，则停止。本示例不包含部署。
修改拒绝按确切范围审批
可复制的问题与修改工作表
把证据放在修改建议旁边。
说明性示例：一个虚构的客户项目交接产品，已经支持代理机构团队分配负责人并追踪交付。下方的修改前后内容均为拟议文案，不是客户案例，也不是 Soloop 的执行结果。
- 客户与任务
- 协调客户项目交付的代理机构客户经理。预期下一步：查看产品演示。
- 修改前
- 标题：携手合作，更聪明地工作。说明：为现代团队打造的一体化工作空间。
- 可见证据
- 两句话都没有提及客户项目交接、客户经理或下一步由谁负责。读者是否会误解，仍然未知。
- 拟议修改后
- 标题：让每次客户项目交接持续推进。说明：为代理机构客户经理打造，在一处指定下一位负责人并追踪交付进度。
- 验收检查
- 确认产品确实支持这些操作。检查代码差异、桌面端和手机端的文字换行，以及未改变的演示链接。不要添加速度或营收承诺。
- 下一步证据
- 向担任目标角色的人展示页面，询问产品做什么、面向谁，以及下一步会发生什么。在决定是否保留文案之前，先记录原始回答。
决策记分卡
区分通过检查的修改与客户实际产生的结果。
每种信号回答不同的问题。一个阶段取得进展，并不能证明下一个阶段也已达成。
发现
审阅者可以在所提供的页面中定位问题，并将它与个人意见区分开。
通过检查的修改
约定的修改已经完成，所列验收检查均已通过。
理解
相关人群能够用自己的话说明产品任务、受众和下一步。
行动
真实访客尝试采取预期的下一步；需说明观察时间范围和流量来源。
首次价值
符合条件的用户进入产品后完成了产品任务。仅仅注册不等于获得首次价值。
决策
依据已有证据选择保留、修改或回退，并记录不确定性。
调研证据格式
为什么这个工作流程保持较小范围
来源核查于 2026 年 9 月 24 日。实践者的请求提供了问题实例；供应商说明展示了可获得的服务类型。两者都不能证明需求规模或 Soloop 的效果。
一位 SaaS 创始人在重建现有网站后，请求对包括子页面在内的文案和设计提供反馈。
从真实页面及其所有者需要回答的问题开始。单个请求属于定性证据，不能衡量市场需求。
RevGenius 创始人讨论 · 2026 年 2 月 23 日专门的 SaaS 审查产品会提供针对具体页面的问题发现和文案修改建议。
通用清单并不足够。应将原始证据、确切的修改建议和验收检查放在一起。这里不采纳供应商的效果主张。
Landing Doctor 的 SaaS 审查服务Soloop 文档说明了从项目、GitHub 仓库或 ZIP 开始，经审批后在沙箱中执行的 Build 工作。
在具备所需项目访问权限的前提下，界定一项常规、经审批的修改。本页面不能证明已有专门的审查服务或完成过产品演示。
Soloop 产品手册当前产品边界
按今天实际能运行的功能来规划。
这是一个使用所提供页面背景和常规经审批 Build 任务的审查与修改流程，范围明确，并非一键审查服务。示例仅用于说明；这里没有展示已完成的 Soloop 落地页审查全过程，也没有证明转化率提升。
页面背景
必需提供当前页面、目标客户和期望的下一步行动。如果页面无法查看，请提供截图或源代码。
Build
审批后可执行实施需要受支持的项目或代码仓库，以及经过审批的编码任务。请审阅确切范围和检查项。
客户测试
由创始人开展自行招募并与相关人群交流。AI 的评价不是真实参与者的回答。
转化率提升
尚未证实审查不会测量流量、开展 A/B 实验，也不能证明注册增长与修改之间的因果关系。
浏览器测试
不在本流程内本页面不提供自动注册或支付测试，也不提供自动修复与复测服务。
部署
单独界定范围通过审阅的修改不等于已经部署的页面。应明确发布审批和发布后的验证。
继续这个循环
当决策发生变化时，使用下一个资源。
常见问题
进行下一步之前的问题。
SaaS 落地页审查会检查什么？
从受众和任务、承诺是否清晰、支持证据，以及行动按钮的预期目标页面开始。让发现对应具体页面元素，再定义一项修改及其验收所需的检查。
流量还不多时，也能这样做吗？
可以。你可以检查文案、链接和布局，并询问相关人群理解了什么。没有适当的流量和测量时，不要把结果称为转化实验，也不要声称有转化提升。
Soloop 会自动审查并修复我的线上网站吗？
不会。请带上页面背景进行讨论；如果适合实施，再审阅一项单独界定范围的 Build 任务。代码仓库访问权限、审批和具体任务决定哪些操作可以运行。本流程不提供自动浏览器测试或修复与复测。
这和信息表达测试有什么不同？
页面审查检查页面本身并准备修改；信息表达测试观察真实的人理解了什么。后者可以参考相关的信息表达测试指南。这两项活动中的任何一项，单独进行都不能证明付费意愿。
带上你已有的产品
带上你的页面和一个问题。
复制这份简报，替换括号内容，在选择「从项目开始」后，将其粘贴到 Soloop 首页。此链接不会自动传递简报，也不会自动启动审查。任何拟定的 Build 任务都应在运行前由你审阅。
我的页面是［网址或截图］，面向想要完成［任务］的［具体客户］。下一步应当是［行动及目标页面］。请帮我检查页面的承诺、支持证据和行动按钮，区分可见问题与对用户的假设。提出一项修改，并写出确切的验收标准。如果适合实施，我的代码仓库是［仓库］；请先准备 Build 任务范围供我审阅，再开始编辑。不要部署，也不要根据审查声称转化率有所提升。从一个项目开始