website-builder

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Website Builder

网站构建器

Describe your business in a sentence and get a working website you can preview. Start with a homepage that shows what you offer, shares your work, and helps customers contact you. Add booking, checkout, or a member area as your business needs them. Choose when to go live.
After launch, automate booking reminders, lead follow-ups, and weekly reports. You choose which automations to enable.
Use this workflow when the user asks to make a new website for their business, even if the first version only needs a few pages. Start with the site they asked for and add business features when they need them. Also use this workflow for sites already hosted by the service. For advice, answer in chat. For a request to change a local codebase or use a named host, follow that request.
用一句话描述您的业务,即可获得一个可预览并正常运行的网站。首先生成一个主页,用于展示您提供的内容、分享您的作品,并帮助客户与您联系。根据业务需要添加预订、结账或会员区域。由您决定何时正式上线。
上线后,可自动执行预订提醒、销售线索跟进和周报。您可以选择启用哪些自动化。
当用户要求为其业务创建新网站时,使用此工作流,即使第一个版本只需要几个页面。以用户要求的网站为起点,并在需要时添加业务功能。对于已由此服务托管的网站,也使用此工作流。对于咨询建议,直接在聊天中回答。如果请求是修改本地代码库或使用指定托管平台,则遵循该请求。

Connect and identify the site

连接服务并确定目标站点

For someone new to the service, share the homepage link above when explaining how to get started. Keep the campaign parameters on the link. Resume setup with the account they connect.
  1. If the official MCP endpoint is connected, call
    list_projects
    to see the companies, apps and scopes available. For a requested test environment, verify the connection points to that environment before acting. Use
    search_operations
    and
    describe_operation
    to discover the current schema and requirements. Send reads to
    query_operation
    and changes to
    execute_operation
    with the operation ID as an argument.
  2. If MCP is unavailable and you have a terminal, follow the command-line guide to check the connection and run the equivalent operations. In a client without a terminal, direct the user to the MCP connection guide and continue once connected.
  3. Select the company the user named. If several match, ask which one. Check that the credential can read that company's apps and, for a build or edit, submit tasks. Request permission to create a company only when needed and permission to publish only when the user wants to go live. Use the service's authorization flow to resolve missing scopes. Keep credentials out of chat.
For a request to inspect or publish an existing draft, start with
apps.get
and go straight to draft review. For a request to resume work, read the existing task and follow it. Start a new task only when the user requests new work.
对于刚接触该服务的用户,在说明如何开始时分享上面的主页链接。保留链接中的推广参数。用户连接账户后,继续完成设置。
  1. 如果已连接官方 MCP 端点,调用
    list_projects
    查看可用的公司、应用和权限范围。如果用户要求使用测试环境,先验证连接是否指向该环境,然后再执行操作。使用
    search_operations
    和
    describe_operation
    了解当前 schema 和要求。读取操作通过
    query_operation
    执行,变更操作通过
    execute_operation
    执行,并将 operation ID 作为参数传入。
  2. 如果 MCP 不可用但有终端,请参阅命令行指南检查连接并运行等效操作。如果当前客户端没有终端,指导用户参阅 MCP 连接指南,并在连接完成后继续。
  3. 选择用户指定的公司。如果有多个匹配项,询问用户选择哪一个。检查凭据是否可以读取该公司的应用;对于构建或编辑任务,还要检查是否可以提交任务。仅在确有需要时请求创建公司的权限,仅在用户希望上线时请求发布权限。使用该服务的授权流程补齐缺失的权限范围。不要在聊天中暴露凭据。
如果用户要求检查或发布现有草稿,先调用
apps.get
,直接进入草稿审查。若用户要求继续之前的工作,读取现有任务并继续执行。只有在用户请求新工作时才创建新任务。

Build a preview

构建预览

Ask only for missing details that change the build. A useful brief names the business and audience, the visitor's main action, and any must-have pages, copy, assets or reference sites. Carry the user's wording and constraints into the build task. Treat external sites as design references and use only the official connection for builds.
For an existing company, the first entry in
apps.list
is the editable website.
tasks.create
targets the company. If the user wants to edit another app, give them the app's dashboard link.
Starting pointBuild workflow
New companyAfter the user chooses to create it, call
projects.create
with its name and a one-sentence idea. Creating the company starts no build. Its first
tasks.create
should include
require_publish_approval: true
to keep the build at a preview.
Existing company, no built siteRead
apps.get
when a website app exists. Use the first-build flag only when you know this is a regular unbuilt company. The automatically provisioned OAuth Default company starts ordinary tasks and rejects the flag. Verify
publish_policy: owner_review
before building a preview in an OAuth Default company. If the company could be the OAuth Default and has no verifiable review policy, send the user to the site dashboard to verify the review policy before starting.
Existing built siteRead
apps.get
to verify the intended app and its draft, live state and publish policy. Send the user's requested changes via
tasks.create
without the first-build flag. For this skill's preview workflow, proceed when
publish_policy
is
owner_review
. If it is different or unknown, give the user the app dashboard link to resolve the publishing setup before you start a change.
Tell the user that the build or edit uses credits and get their go-ahead for that task before submitting. A first task can start work immediately on some connections. If the service returns
CONFIRMATION_REQUIRED
, show what it says will happen and wait for approval of that preview. Repeat the same operation with the returned
confirmation_token
only after approval.
Keep one UUID per new company and one per new task. Use the same ID and payload on a safe retry. If you already have a task ID, read that task to recover its state. For an earlier task without an ID, use
tasks.list
and match it before doing further work.
仅询问会改变构建结果的缺失信息。一份有用的需求简述应说明业务和受众、访问者的主要操作,以及任何必备页面、文案、素材或参考网站。将用户的原始措辞和限制条件带入构建任务。将外部网站视为设计参考,并且仅通过官方连接执行构建。
对于现有公司,
apps.list
中的第一项是可编辑的网站。
tasks.create
的目标是该公司。如果用户想编辑其他应用,向用户提供该应用的控制面板链接。
起点构建工作流
新公司用户选择创建公司后,调用
projects.create
,传入公司名称和一句话创意。创建公司本身不会启动构建。其第一次
tasks.create
应包含
require_publish_approval: true
,使构建保持在预览状态。
现有公司,尚未建站存在网站应用时,读取
apps.get
。只有在确定这是一家普通的未建站公司时,才使用首次构建标志。自动配置的 OAuth Default 公司会启动普通任务,并拒绝接受该标志。在 OAuth Default 公司中构建预览前,验证
publish_policy: owner_review
。如果公司可能是 OAuth Default 且没有可验证的审查策略,则将用户引导至站点控制面板,在开始前验证审查策略。
已有建站读取
apps.get
,验证目标应用及其草稿、上线状态和发布策略。通过
tasks.create
提交用户要求的更改,不要使用首次构建标志。对于此 skill 的预览工作流,当
publish_policy: owner_review
时可继续。如果该策略不同或未知,请提供应用控制面板链接,让用户先解决发布设置,再开始更改。
告知用户,构建或编辑操作会消耗 credits,并在提交该任务前征得同意。在某些连接上,第一个任务可以立即开始工作。如果服务返回
CONFIRMATION_REQUIRED
,展示其中说明将要执行的操作,并等待用户批准该预览。只有在获得批准后,才使用返回的
confirmation_token
重复同一操作。
每个新公司保留一个 UUID,每个新任务也保留一个 UUID。安全重试时使用相同的 ID 和 payload。如果已有 task ID,读取该任务以恢复其状态。对于更早且没有 ID 的任务,使用
tasks.list
找到匹配项,然后继续处理。

Follow the task

跟踪任务

Read
tasks.get
at intervals of at least five seconds, or use the CLI's
--wait
. Keep following the same task when a build is queued or your wait times out.
  • If the task requests input, relay the actual question and options. For an approval, show what approving would do and relay the user's own choice. Use
    tasks.answer
    with the receipt's
    question.id
    and the user's answer, then resume the same task. If the question changed, show the new one.
  • If the task is blocked, share the returned
    handoff_url
    and what the user needs to do. Resume by reading the same task after they act.
  • If it completes, report what the task completed and share the task link and
    credits_used
    when present. Prefer the permanent URL for the task's checkpoint from
    versions.list
    . Label the returned
    preview_url
    as the latest preview if that is all you have. Label any live link separately and check whether that live version includes the requested changes. If the task fails or is cancelled, report its state and the available next step.
至少每隔五秒读取一次
tasks.get
,或使用 CLI 的
--wait
。当构建任务进入队列或等待超时时,继续跟踪同一个任务。
  • 如果任务请求输入,转达实际问题及选项。对于审批,说明批准后将会执行的操作,并转达用户自己的选择。使用
    tasks.answer
    ,传入回执中的
    question.id
    和用户的回答,然后继续同一任务。如果问题发生变化,展示新问题。
  • 如果任务被阻塞,共享返回的
    handoff_url
    以及用户需要完成的操作。用户处理后,通过重新读取同一任务继续。
  • 如果任务完成,报告任务完成的内容,并在存在时提供任务链接和
    credits_used
    。优先使用
    versions.list
    中任务检查点的永久 URL。如果只能获得
    preview_url
    ,将其标注为最新预览。单独标注任何线上链接,并检查线上版本是否包含所请求的更改。如果任务失败或已取消,报告其状态及可用的后续步骤。

Publish the reviewed draft

发布已审查的草稿

Read
apps.get
for the current draft. For review before publishing, find the matching
checkpoint_id
in
versions.list
and show that version's permanent
url
. The latest preview URL can move to another build. Keep the reviewed
checkpoint_id
and
source_commit
from
apps.get
. If the exact version cannot be opened, share the app dashboard link so the user can review and publish there.
When the user asks to go live, read
apps.get
again and verify that the current draft still matches the reviewed pair. Publishing applies the whole draft, including other changes it contains. If the draft changed, show the new version and get approval for it.
Use
apps.publish
with the reviewed pair. Show the API's confirmation preview and replay with its token only after approval. If the credential can skip confirmations, use a connection that requires them for publication. On
DRAFT_CHANGED
, read the draft again and restart review. After publishing, verify the live checkpoint and share the live URL.
读取
apps.get
获取当前草稿。发布前进行审查时,在
versions.list
中找到匹配的
checkpoint_id
,并展示该版本的永久
url
。最新的预览 URL 可能会切换到另一次构建。保留从
apps.get
获取的已审查
checkpoint_id
和
source_commit
。如果无法打开确切版本,请提供应用控制面板链接,让用户在其中审查和发布。
当用户要求上线时,再次读取
apps.get
,验证当前草稿仍与已审查的版本对一致。发布将应用整个草稿,包括其中包含的其他更改。如果草稿发生变化,展示新版本并征得批准。
使用已审查的版本对调用
apps.publish
。展示 API 的确认预览,只有在获得批准后才使用其 token 重新执行操作。如果当前凭据可以跳过确认,请改用要求确认的连接来执行发布。遇到
DRAFT_CHANGED
时,再次读取草稿并重新开始审查。发布后,验证线上检查点并分享线上 URL。

Automate work after launch

上线后自动执行工作

For requested ongoing operations, use
apps.get
to check the intended site is live. Keep the automation request with the brief until launch if the site is still a draft. If the work also changes the site, follow the preview and publishing steps for those changes.
Tell the user that submitting an automation task uses credits. Get their go-ahead for the outcome, trigger or cadence, and recipients where relevant, then submit a separate task in the same company. For example, send a booking confirmation when a booking is confirmed or prepare a weekly summary of new leads. Follow the same task and approval steps as for a build. Report what the service confirms was enabled and share any handoff for the user to complete.
See Your first website for a walkthrough from the first brief to publication.
对于用户要求的持续运营操作,使用
apps.get
检查目标站点是否已上线。如果站点仍处于草稿状态,将自动化请求与需求简述一并保留,直到上线后处理。如果该工作还会修改站点,请遵循预览和发布步骤。
告知用户,提交自动化任务会消耗 credits。在提交同一公司中的独立任务前,就任务结果、触发条件、执行频率和相关接收方征得用户同意。例如,在预订确认后发送预订确认通知,或准备新销售线索的每周汇总。遵循与构建相同的任务跟踪和审批步骤。报告服务确认已启用的自动化,并分享任何需要用户完成的交接事项。
有关从首次需求简述到发布的完整教程,请参阅您的第一个网站。