Beedle 是做什么的？
构建搜索引擎和 AI 爬虫能读取、陌生人在十秒内能理解、且只声明可被证实的营销页面。少即是多：每个部分都必须靠自身价值来赢得存在权。每一轮结束后都会进行一次独立评审。
经验教训： 在第 1 步之前，检查项目中是否存在 design/LESSONS.md 文件，如果存在，请遵循其中关于营销网站的任何内容。这些是项目所有者的修正记录。
1. 阅读项目
在提出任何问题之前，先查明项目的现有情况：技术栈和托管平台、当前网站（如有）、产品的真实名称、代码仓库、商店列表、定价、截图、设计令牌或主题、分析工具，以及 docs/marketing/page-brief.md 文件。
使用项目已有的技术栈进行构建。如果是全新网站，请遵循 reference/seo.md（“选择技术栈”）中的指导。营销内容绝不使用 Flutter Web 或客户端渲染，因为爬虫可能永远无法看到它们。
使用项目的主题（如果存在，如 design/THEME.md、*.tokens.json）。如果没有，则从应用移植令牌。如果也没有应用可供移植，则编写 reference/small-theme.md 中那个单一的小文件，因为单个页面不需要完整的设计系统。仅当用户要求提供主题，或者需要多个网站或一个应用共享主题时，才使用 ultrahand:theme 技能。
2. 选择页面类型和状态
阅读 reference/page-types.md。选择一个类型和一个状态（发布前或已上线），并记下该网站所需的支持页面。
3. 编写简报
在项目中保存 docs/marketing/page-brief.md 文件，使用以下模板。它是评审员对照检查页面的契约，也是下一轮会话的起点。
# 页面简报
- 类型和状态：
- 目标受众：（是谁，以及他们已经知道什么）
- 页面的唯一任务：
- 主要行动召唤（CTA）：（确切的文字和目的地）
- 次要行动：（一个，较不明显，或“无”）
- 搜索短语：（此受众实际会输入的 3-5 个短语）
- 反对意见：（用户离开的真实原因）
- 分析和 Cookie：（加载了什么，或“无”）
## 声明
| 页面上的声明 | 证据 |
| --- | --- |
| <每一个数字、引文、对比、“第一”、“最快”等> | <文件、链接或测量结果，附带日期> |
| <对产品或功能的简单描述> | <文件或链接，或仅 `README only`> |
## 等待人工处理
- <谁：他们必须做什么，或“无”>
只向用户询问项目本身无法回答的问题，通常是目标受众和证据。永远不要编造证据。缺失的客户评价就是缺失的区块，而不是一个等待填充的占位符。使用会明显失败的哨兵（如 APP_STORE_ID_TODO），而不是看起来合理的假值。
当你只有 README 时， 仍然可以构建页面。它可以明确说明产品是什么以及它能做什么：将这些行标记为 README only。它无法证明数字、日期、版本、许可证、价格、安全性、隐私或可用性，因此需要为每一项查找主要来源：代码、LICENSE 文件、发布页面、软件仓库或商店列表、测量结果，或所有者注明日期的声明。引用该来源。如果没有，就将该声明从页面上去掉。
任何只有人工才能提供的信息 一旦你知晓，就立即放入“等待人工处理”部分：真实截图、域名、待确认的价格。在用户完成之前，该信息会一直保留在那里。
4. 先写文案
遵循 reference/message.md。在任何布局之前先编写文案。从那里的五个区块开始。只有当你能够命名某个区块所要回应的反对意见，并将其记录在简报中时，才添加该区块。
5. 构建
遵循 reference/seo.md 中关于页面内部及其周围内容的指导。使用真实的产品截图或录像，切勿将复现的内容标注为截图。真实应用在运行示例数据时的屏幕捕获是真实的：在页面上说明这是一个示例，并在声明表中说明你是如何创建的。如果没有可展示的真实内容，则省略该图片，或者如果页面类型需要，则留下一个哨兵。避免消息参考中列出的设计痕迹，因为这些痕迹会让人在阅读任何内容之前就认为页面是生成的。
6. 自检
构建站点并在构建后的输出上运行审计，然后修复你能修复的所有错误：
beedle audit --dir <构建后的站点目录>
对于每个非营销的部分，添加 --exclude docs（可重复）。如果 beedle 不在 PATH 中，请告知用户审计未运行，并说明 INSTALL.md 中介绍了如何添加。
只有人工才能清除的错误会保留，例如尚未购买的域名对应的 DOMAIN_TODO 哨兵。永远不要为了获得一个干净的运行结果而替换为假值。确保它被放入“等待人工处理”部分，然后继续进行评审。
7. 评审本轮内容
每一轮修改后，在告知用户页面准备就绪之前，都必须由一位新的评审员在其独立的会话中进行评审。一轮包括首次构建以及之后所有更改页面的每一次提示，因此即使是一行文案的更改也需要评审。仅当用户要求跳过本轮时才跳过，并且要说明你已经跳过了。
无需被询问，由你主动启动评审。你无法公平地评审自己的页面：你看到的是你意图构建的东西。遵循 review/round.md 中的指导。简言之，编写简报，在后台运行 beedle review --brief <简报文件> --add-dir <项目>，然后根据结果采取行动。在此步骤完成之前，不要发布、部署或声称页面已完成。
8. 报告
说明你构建的内容、页面类型和状态、评审结论，以及评审发现了什么、修复了什么、留下了什么未解决，附带其成本。
如果结论是“在人工操作之前无法发布”，请以此为首要信息：页面尚未就绪，谁必须做什么，以及一旦他们完成，下一轮评审将检查什么。切勿将其说成“几乎完成”。
始终列出项目所有者在上线后需要完成的事项：Search Console 和 Bing Webmaster 验证，以及针对已部署页面的 Rich Results 测试。
除非用户要求，否则不要部署。
9. 学习
当项目所有者纠正结果或表达持久性偏好时，在项目的 design/LESSONS.md 文件中添加一行（如果需要则创建该文件）。如果纠正意见表明这些规则对所有项目都是错误的，那么也在这里修正规则。