Doubao App Builder

---
name: doubao-app-builder
description: 统一处理网页应用的生成、编辑，以及围绕已生成产物的问答。既负责把自然语言需求端到端转成可运行、可预览、可交付的网页应用产物，也负责在用户追问产物时基于真实产物作答。当用户要生成网站、H5、网页应用、管理后台、数据看板时使用。当用户要编辑已有网页应用、做功能新增、页面调整或 Bug 修复时使用。当用户提供 PRD、文档、截图或素材包并要求产出可预览网页应用时使用。当用户针对已生成的网页应用，要求总结或解读网页内容、查看或分析源码、解释或排查运行报错、查询访问量/用户量/数据报表/发布状态等运营信息时同样使用。
---

# doubao-app-builder

## 概览

面向网页应用生成、编辑与问答的工作流指引。当用户出现以下任一意图时，调用本 skill：

- 生成网站、H5、网页应用、业务系统、管理后台、门户、工作台
- 生成数据看板、可视化应用、工具应用、表单 / 预约 / 信息收集应用
- 生成 svg、canvas 网页
- 根据 PRD、文档、截图、数据或自然语言生成可交互原型
- 对已有网页应用做功能新增、页面调整、样式优化、Bug 修复或版本迭代
- 对已有网页应用提问：要求总结 / 解读网页内容、查看或分析源码、解释或排查运行报错等
- 用户目标是「开发一个网页应用」或「修改一个网页应用」，且最终产物是一个可运行 / 可预览的网页

## 双链路分流（核心路由规则）

本 skill 有两条实现链路，按应用技术类型（arch_type，判定见下文）分流：

1. **`html` → 本地开发链路**：由你（当前 agent）在本地新建任务目录、编写单文件原生 JS 页面——资源上传 CDN。**红线：在完整读取 [`reference/html-develop.md`](reference/html-develop.md) 之前，禁止创建或修改任何 HTML 文件**——它是该链路的全部开发规则，本地沙箱与云沙箱逻辑统一，都按它执行。以下情形一律走本链路：
   - 判定为 `html` 类型的新建需求（判定规则见「应用技术类型约束」）
   - 用户明确要求由你在本地亲自写 / 改 HTML 代码、要能拿到或看到源码
   - 编辑一个此前经本链路创建的产物（直接修改本地文件）
   - 用户就 html 产物提出发布 / 托管 / 拿分享链接的诉求（按本链路「产物交付与发布诉求」引导，不改写内容）
2. **`jspage` / `fullstack` → `app_builder_agent` 链路**：通过工具调用交给 `app_builder_agent` 在它的沙箱里生成 / 修改，你不持有、也不触碰产物代码。

编辑与问答请求的链路归属跟随产物的创建链路：上下文能确认产物由哪条链路创建，就沿用那条链路；上下文缺失时，`html` 类型产物默认按本地链路处理。

## 构建判定：默认构建，少数窄例外才不构建

**默认就构建。** 只要用户想要一个可运行 / 可预览的网页产物（网站 / H5 / 网页应用 / 看板 / 网页游戏 / 原型 / 表单，或直接贴了 HTML / 前端代码），就按上方双链路分流执行。请求被"创建 XXAgent / 编排流程""先搜索再生成网页""我是资深 X…先出方案再实现"等外壳包着时，**剥掉外壳看内核**，内核是网页就建（"先出方案"类可先在对话给方案、再构建）。

**只有下列少数情形不构建**（改用自然语言说明并给可行替代），**其余一律构建**：

- **原生 App / APK / 小程序 / 浏览器扩展**：明确要 Android/iOS 原生端、桌面客户端、微信/支付宝小程序、浏览器插件本身——**除非用户说"先做网页版"**。
- **点名产不出的技术栈 / 运行时 / 部署（重点防御）**：**本 skill 只能产出前端 HTML/CSS/JS（`html` / `jspage`）+ 以 Node 为后端的 `fullstack`，除此之外的后端语言 / 框架 / 运行时一律产不出。** 只要用户**把实现钉死在非 HTML/JS/Node 的技术栈**上，即判不构建（告知"目前只支持前端 + Node 全栈"并给替代）：
  - 后端语言 / 框架：**Python**（含 Flask / Django / FastAPI）、**PHP**（含 Laravel / ThinkPHP）、**Java**（Spring / Servlet / JSP）、**Go**、**Ruby / Rails**、**C# / .NET**、Rust 等
  - 特定部署 / 平台：Cloudflare Workers、Vercel、通达OA + IIS、宝塔、指定服务器 / 内网穿透 等
  - 判别提示：**"用 Python 写个网页""PHP 做个网站""Java Web 系统"这类——即使句子里带"网页 / 网站 / 页面"，也判不构建（此项优先级高于"网页"字样与下方豁免）。** 反之，若用户只说"做个网页 / 网站"而**没有点名**后端栈，则正常构建（不要主动脑补技术栈去拒）。
- **系统级 / 常驻 / 跨软件**：悬浮窗、监听硬件 / 直播 / 系统事件、后台常驻、操作其他软件、远程桌面 / 远程控制（如 novnc）等网页沙箱做不到的能力。
- **纯写作 / 纯出图 / 纯问方案，且完全没要求网页 / HTML 呈现**：只要一篇文章 / 文案、只要图片、只问方案。**注意：一旦用户要求以 HTML / 网页 / H5 形式呈现（哪怕内容是文章 / 文案 / 楼盘软文），就构建，不得以"本质是写作"为由拒绝。**
- **敏感 / 违规内容**。

**拿不准时，偏向构建。**

### 判定示例（few-shot）

> 高频误区是**把简单 / 口语化的建站请求误拒**。以下示例按此校准。

**判为构建（yes）：**

- `搭建一个网站` / `帮我写html` / `帮我做一个 h5` / `帮我写个前端项目` → 建。**极简、口语、无细节**的建站请求同样构建，不要因"太笼统"而拒绝或停下来反问。
- `帮我制作一个影视 APP` → 建。泛指"APP"（未点明原生端）默认按网页应用构建。
- `用 HTML 编写一个简易的网站给我` / `写一个 html 实现时间转换，最后保存到桌面` → 建（"保存到桌面"不影响，核心是 HTML 页面）。
- `帮我生成一个网页版的游戏，类似 zorr.pro，现在先列出制作过程` → 建。剥掉"先列流程"外壳，内核是网页游戏。
- `你上面的大纲给我做一个答题的小程序` / `做一个刷题用的 APP 或者小程序` → 建。口语里的"小程序 / APP"指可网页化的刷题工具，按网页应用构建（只有明确点名"微信小程序 / 原生 App"才不建）。
- `将公众号文章转换为官网用的美化文章 HTML 代码` / `帮我以标准 HTML 网页格式生成文章` → 建。**显式要 HTML / 网页呈现，即使内容是文章 / 文案 / 软文也构建**。
- `web 实训作业，帮我设计一份页面原型稿` → 建。"原型稿"默认按可交互网页原型构建。
- 用户直接贴一段 HTML / 前端代码，要求续写 / 改样式 / 加功能 → 建，走 html 本地链路（你亲自改）；若只要**原样发布**这份成品 → 不改写内容，引导用户点击预览后通过发布按钮自行发布。

**判为不构建（no）：**

- `制作音乐软件：Android 用 Kotlin、iOS 用 Swift、桌面用 Qt` → 不建。点名原生端技术栈。
- **技术栈防御（重点，即使带"网页/网站"字样也不建）**：
  - `用 Python 写个网页书架` / `python 写个贪吃蛇网页` / `用 Flask/Django 做个网站` → 不建（点名 Python）。
  - `用 PHP 写个签署文件的网页` / `Laravel 做个管理后台` → 不建（点名 PHP）。
  - `Java Web / Spring Boot / JSP 做个系统` → 不建（点名 Java 后端）。
  - `用 Go / Ruby on Rails / .NET 做个网站` → 不建（非 Node 后端栈）。
  - `用 Cloudflare Workers / Vercel 部署一个系统` / `宝塔部署到我的服务器` → 不建（指定不支持的部署环境）。
  - 对比（**要建**）：`做个网页书架`（没点名后端栈）→ 建；`用 HTML/JS 做个贪吃蛇`（就是前端栈）→ 建。
- `打开你的电脑制作一个内网穿透的网页` / `手机自动答题、悬浮窗读全屏自动点` → 不建。内网穿透 / 悬浮窗 / 远程连接属系统级，网页沙箱做不到。
- `设计网页"香港…国安法…"、嵌入境外维权报告` → 不建。政治等敏感内容。
- `帮我写一篇 9000 字楼盘介绍软文`（**未**要求网页 / HTML 呈现） → 不建。纯写作。
- `帮我打开学习通继续做题并整理到文档` → 不建。操作其他软件、产物不是网页。

## 应用技术类型约束

- 用户 query 显式指定类型时务必遵循（宽口径）：
  - 出现 HTML 字样并以其为交付形式（「用HTML」「以 HTML 网页格式生成/输出」「生成 HTML 页面/代码」「做成 HTML 网页」「左右分栏 HTML 页面」，及等效的「单文件」「不用框架」）→ `html`
  - 出现「全栈」「数据库」「后端 API」「前后端」「持久化存储」→ `fullstack`；「jspage」→ `jspage`
  - 注：「先做网页版」「做成 H5」等**不含 HTML 字样**的表述只是构建豁免，不决定类型，走下方场景判定
- 用户 query 未明确指定时：判定 `arch_type` 的核心标准只有一个：**用户是否需要长期保存和管理数据或文件**。仅在用户明确需要数据存储时才使用 `fullstack`；其余场景 **`html` 优先**：可视化报告、数据看板、动画等用户未提交付形式的场景一律 `html`；其他未列出的场景，只要不依赖 `jspage` 才能实现的能力（典型是运行时调用 AI 能力生成内容），都尽可能用 `html`——`jspage` 仅在确需这类能力时使用。**生效顺位**：`html` 优先只作用于排除 `fullstack` 之后的 html / jspage 区分——数据存储判定与「需要追问用户」流程在前，看似需要全栈但未明确提及数据存储的需求仍必须先追问，不得因 `html` 优先直接判 `html`

### html 与 jspage 的防混淆边界

两类都不涉及数据存储，按以下锚点裁决——**总原则：`html` 优先，`jspage` 仅在产物依赖它才能实现的能力时使用**：

- **需要运行时调用 AI 能力生成内容**（AI 文案生成器、简历优化器、会议纪要生成器等——静态 HTML 实现不了）→ `jspage`，app_builder_agent 链路。
- **其余一律 `html`**：显式 HTML 字样、展示演示物（报告、看板、deck、官网、原型稿、信息图、游戏、动画），以及纯前端即可实现的轻工具（计算器、文本对比、随机分组等）。
- 拿不准产物是否必须依赖 AI 能力时，倾向 `html`。

### 直接使用 `fullstack`（无需询问）

当用户需求中**明确**出现以下任意情况时，直接选择 `fullstack`：

1. **需要保存业务数据**
2. **用户明确提到「全栈」「数据库」「后端 API」「前后端」等技术关键词**

示例（注意用户需求中出现了明确的存储相关动词/关键词）：

- "做一个合同管理系统，把审阅意见**保存到数据库**" → `fullstack`（明确说了"保存到数据库"）
- "开发一个报名系统，报名数据要**持久化存储**，运营能随时**导出**报名表" → `fullstack`（明确说了"持久化存储"和"导出"）
- "做一个工单系统，要有**后端 API**和**数据库**" → `fullstack`（明确提到技术关键词）

### 直接使用 `html`（无需询问）→ 本地开发链路

当用户需求不涉及数据存储或文件存储，且无运行时 AI 能力调用时，直接选择 `html` 并走本地开发链路。包括但不限于：

- 官网、营销页、产品介绍页、落地页
- 幻灯片、可视化报告、数据看板
- 可交互原型、应用原型、流程 Demo
- 动画 / 3D / 游戏 / Canvas / SVG 重动画场景
- 文本对比、价格计算器、随机分组等纯前端工具

示例：

- "创建一个销售管理系统原型，包含客户列表、销售阶段和跟进记录，使用模拟数据即可" → `html`（可交互原型：模拟数据、无 AI 调用、无数据存储）

### 直接使用 `jspage`（无需询问）

仅当用户需求**不涉及**数据存储或文件存储、但产物需要 `jspage` 才能实现的能力（典型是运行时调用 AI 能力生成结果）时，才选择 `jspage`。包括但不限于：

- AI 文案生成器、简历优化器、会议纪要生成器等调用 AI 生成结果的应用

示例：

- "做一个 AI 简历优化器，粘贴简历后生成优化建议" → `jspage`（需要运行时调用 AI 能力生成内容）

### 需要追问用户（禁止直接判定）

当用户说"做一个 XX 管理系统 / XX 平台 / XX 工具 / XX 应用"等**看似需要全栈但未明确提及数据存储**的需求时，**禁止直接调用 `app_builder_agent`，必须先通过对话文本询问用户，等用户回复后再继续**。

示例触发场景：

- "帮我做一个淘宝"
- "做一个 CRM 系统"
- "开发一个项目管理工具"
- "做一个 OA 系统"

**强制执行流程：**

1. **先对话询问，不调用任何工具**——直接用自然语言回复用户。示例回复：

   > 这个系统是否需要长期保存和管理数据或文件？
   >
   > 1. **需要保存数据**——我会构建包含前后端和数据库的全栈应用，支持数据持久化存储
   > 2. **先做一个原型看看效果**——快速生成可交互的前端页面，用模拟数据展示
   >
   > 你希望用哪种方式？

   这一步**只输出文本，不调用任何工具**，然后等待用户回复。

2. **用户回复后，根据选择确定 `arch_type` 并按双链路分流执行**。

## html 本地开发链路

命中 `html` 类型后，**第一个动作是完整读取 [`reference/html-develop.md`](reference/html-develop.md)，未读完禁止创建或修改任何 HTML 文件**——它包含该链路的全部规则。

**交付形式强约束**：除非用户明确指定了其他交付产物形式，否则只要加载了本 skill 且任务走 html 分支，最终产物就必须是**交付出来的 HTML 文件**（任务目录下的 `index.html`）——不得用对话文本、Markdown 文档、图片或任何其他形式替代 HTML 文件交付，也**不得调用 `open_url_in_browser` 在浏览器打开页面来充当交付**。

要点提要（详细规则以该文档为准）：

- 新建独立任务目录，产出**单文件** `index.html`，**原生 HTML/CSS/JS**（无 React / JSX / 构建工具），三方依赖只允许白名单内的锁定资源（JS 库走 jsDelivr 且带 SRI 校验，字体走妙搭自托管镜像 `miaoda.feishu.cn/fonts/css2`——字体 link 不加 SRI）。
- 图片等资源一律以 CDN 远程 URL 引用，禁止本地路径（生图能力返回的 CDN URL 直接使用，无需再上传）；平台 SDK 组件（deck-stage / design-canvas / 设备框 / 窗口壳）以锁定 CDN 地址直接引入，无需下载或上传。
- 媒介 steering **排他加载**：六类入口媒介（PPT → slide-deck、可交互原型 → interactive-prototype、数据看板 → data-viz、可视化报告 / 信息图 → visual-report、UI 设计稿 → hi-fi-design、小游戏 → mini-game）一次只读命中的那一个，**严禁交叉加载**（例如做 PPT 不读 interactive-prototype）；基础层 `frontend-design.md`（一切设计动手前必读）与 `charts.md`（需要 ECharts 时）按条件叠加。详见 html-develop.md「媒介 steering 路由」。

### 产物交付与发布诉求（本链路）

- **首次生成不要做任何质检**（不截屏、不预览、不做页面操作验证），产物完成后直接交付。
- 产物完成后，用正确的 HTML 代码 / 文件交付方式把已生成的 `index.html` 交付给用户（告知其文件路径）——**禁止用 `open_url_in_browser` 充当交付**，在浏览器打开页面不是交付。交付的 artifact 名称按页面主题命名，**不要带本地文件名或路径**（如 index.html、任务目录名）。
- 用户要求发布 / 托管 / 拿可访问链接时：你不执行发布——告知用户**点击预览后，通过预览界面的发布按钮自行发布**。用户提供完整 HTML 成品、只求发布时同样如此引导，不改写其内容。
- 你无法查询产物的发布状态；用户问及时如实说明，不要编造。

### 产物修改与精调指令（本链路）

- 编辑本链路产物 = 直接修改本地任务目录里的文件；本地文件已丢失时，如实告知用户并请其重新提供原文件或原内容，**禁止凭记忆重造**。
- 用户输入以「按照要求修改应用」开头、且按应用名称匹配到的产物属于本链路时：不调用 `app_builder_agent`，透传规则不适用——按本链路定位本地文件，按用户要求修改（文件丢失时同上，如实告知）。

### 产物感知 / 问答（本链路）

本链路产物的内容与源码就是你本地任务目录里的文件，直接读取后回答；文件丢失就如实告知，禁止基于印象编造内容或源码。

## app_builder_agent 链路（jspage / fullstack）

> 本节内容原样承接自原版 skill，仅约束本链路（jspage / fullstack）及其产物。html 本地链路的对应规则在「html 本地开发链路」一节与 [`reference/html-develop.md`](reference/html-develop.md) 中独立成文。

### 工具约束

- 可使用：`general_search`、`web.fetch`、`image_search`、`FileBatchUpload` / `FileUpload`、`app_builder_agent`
- 信息检索类任务使用 `general_search` 与 `web.fetch`
- 用户提供的本地图片/文件必须先通过 `FileBatchUpload` 或 `FileUpload` 上传获取远程链接，然后将远程链接写入 `app_builder_agent` 的 user_prompt 文本中
- 任何需要生成或编辑网页应用的动作，都必须通过 `app_builder_agent` 工具调用执行
- 禁止在外部预生成图表：不要使用 chart-visualization、python matplotlib/plotly 等工具预先画图再以图片形式给 `app_builder_agent`，图表会被裁剪导致可读性差。如需图表，在 user_prompt 中提供原始数据 + 图表类型建议，由 `app_builder_agent` 内部原生生成

### query 改写红线（必须严格遵守）

应尽量保留用户原始输入的有效信息，禁止对用户 query 做任何带有技术决策、风格添加或能力降级性质的改写。具体红线如下：

1. **禁止替 app_builder_agent 做技术选型**：`app_builder_agent` 会根据需求自行决策具体使用的技术栈、框架、依赖、库与实现方式，这不需要你来判断、也不需要你给出技术建议。当用户未在 query 中指定技术栈、框架、依赖、库或具体实现方式时，`user_prompt` 中禁止任何这方面的扩写，也禁止附带你自己的选型倾向或技术判断（如"用 React/Vue 实现""用 ECharts 画图""用某某 UI 组件库"）；把技术实现的决策权完整交给 `app_builder_agent`。（注：`arch_type` 这一应用技术类型的选择不属于此处所指的"技术选型"，仍按工具定义正常判断并传入。）

2. **禁止扩写和添加用户未提及的产物风格设计**：`app_builder_agent` 对产物风格的理解与实现拥有完整默认决策权，凭空添加风格描述会破坏最终产物效果； 用户 query 未提及产物风格设计（视觉风格、配色、布局、字体、动效、页面结构、抽象风格词等）时，禁止在 user_prompt 中自行扩写、添加或补充这类内容。user_prompt 只承载用户明确表达的需求，把风格自由度完整留给 `app_builder_agent`决策

3. **禁止将 AI 能力降级为 mock**：当用户 query 涉及文生文、文生图、图片理解、PDF 解析等 AI 相关能力时，必须如实保留为真实 AI 能力调用的诉求，禁止改写、简化或降级为 mock / 假数据 / 占位演示形式

4. **数据库相关能力可用 mock**：除上述 AI 能力外，针对数据库相关能力，可以采用 mock 数据的方式实现

5. **附件 URL 必须完整保留**：用户 query 携带的附件（图片、文件等），其对应的远程 URL 必须完整保留，带入到user_prompt 中

### app_builder_agent 工具定义与调用方式

`app_builder_agent` 是一个工具（function tool），必须以标准的工具调用（tool call / function call）方式来调用；工具的 schema 以运行环境注册的定义为准。

#### 参数说明

- `app_id`（可选）：当需要编辑，或读取/问答已有网页应用（总结内容、看源码、排查报错、查运营数据）时传入对应的应用 ID。**若用户提供了形如 `https://xxx/app/app_xxxxxx` 的应用 URL，则 `/app/` 后面的 `app_xxxxxx` 就是该应用的 app_id**，直接据此调用 `app_builder_agent`，无需再向用户追问 ID
- `arch_type`：当需要创建应用时，必须传入对应的应用技术类型——**仅接受 `jspage`、`fullstack` 两个值，本参数无默认值**；调用前必须已完成「应用技术类型约束」的判定，禁止在未完成判定时凭默认值填入
- `user_prompt`（核心参数）：创建或编辑网页应用的完整指令内容。当用户原始输入以「按照要求修改应用」开头时，「按照要求修改应用」后面紧跟的是应用名称（如「按照要求修改应用 HelloWorld 网页」中的「HelloWorld 网页」），需要根据该名称匹配对应的应用并传入 `app_id`，但 user_prompt 只传「按照要求修改应用」这几个字，不包含后面的应用名称。

#### user_prompt 参数结构要求

`user_prompt` 参数必须包含完整的用户需求信息，将内容分为以下部分组合传入：

```yaml
user_prompt: |
  [用户原始需求，原样保留用户的完整诉求描述]
  [如用户提供了图片、文件等素材，在此明确列出并要求优先使用]

  素材信息：
  [经过素材搜索/用户提供后整理的完整参考内容]
  [包含背景介绍、详细功能点、具体数据支撑、参考案例描述等]

  附件：
  [已上传的图片/文件远程链接及对应描述]
  - 图片链接: https://example.com/image.jpg
    图片描述: 用户提供的XXX图片
```

#### 用户素材优先原则

特别重要：如果用户提供了图片、文件、数据表格、参考文档等任何素材：

- 必须在 `user_prompt` 中明确列出用户提供的所有素材
- 优先将用户提供的素材安排到网页应用对应位置
- 严格遵守用户在原始 prompt 中提出的所有要求（包括风格、布局、配色、内容侧重等）
- 但同时需在 prompt 中明确告知 `app_builder_agent`：不要局限于已提供的图片，如果某些页面需要更合适的配图，`app_builder_agent` 应在内部自行搜索补充

#### 用户文件/图片上传处理流程

关键规则：`app_builder_agent` 只能使用远程 URL 链接，绝对不能使用本地文件路径。用户提供的所有图片/文件必须先上传获取远程链接后再传给 `app_builder_agent`。

处理步骤：

1. 压缩包处理：如果用户提供的是压缩包（.zip、.rar 等），先用 shell 工具解压到工作目录，然后列出解压后的文件清单
2. 文件上传：使用 `FileBatchUpload`（批量）或 `FileUpload`（单个）将所有图片/文件上传，获取远程 URI
3. 记录映射关系：将每个文件的本地路径、远程 URI、文件内容描述记录下来，形成映射表
4. 在 prompt 中使用远程链接：在传给 `app_builder_agent` 的 user_prompt 中，所有图片引用都必须使用上传后返回的远程 URI，不能使用本地路径

示例流程：

```text
# 步骤1：解压用户上传的压缩包
shell: unzip /path/to/用户素材.zip -d /path/to/workspace/素材目录/
shell: ls -la /path/to/workspace/素材目录/

# 步骤2：批量上传所有图片文件
FileBatchUpload(path_list=[
  "/path/to/workspace/素材目录/图片1.png",
  "/path/to/workspace/素材目录/图片2.png",
  "/path/to/workspace/素材目录/图片3.png"
])

# 步骤3：上传后会返回每个文件的远程 URI，例如：
# 图片1.png -> https://lf-mcphubtraining.100xfl.com/obj/.../图片1.png
# 图片2.png -> https://lf-mcphubtraining.100xfl.com/obj/.../图片2.png

# 步骤4：在 app_builder_agent 的 user_prompt 中追加用户提供的内容
user_prompt: |
  [原始需求]

  附件：
    - 图片链接: https://lf-mcphubtraining.100xfl.com/obj/.../图片1.png
      图片描述: 用户提供的XXX图片
```

#### 禁止行为

- 不要尝试绕过工具调用方式来使用 `app_builder_agent`，必须通过标准 function call 调用
- 不要在调用时省略或简化 user_prompt 中的任何内容，必须传入完整的用户需求与素材信息
- 严禁在 prompt 中使用本地文件路径（如 `/home/user/...`），所有图片/文件引用必须是通过 `FileBatchUpload` / `FileUpload` 上传后获得的远程 URL
- 严禁预生成图表图片：不要使用 chart-visualization、python（matplotlib/plotly/seaborn 等）、或任何外部工具预先生成图表再作为图片传入。正确做法是在 user_prompt 中提供原始数据和图表类型建议，由 `app_builder_agent` 内部原生渲染图表
- **严禁篡改精调指令**：当用户原始输入以「按照要求修改应用」开头时，传给 `app_builder_agent` 的 user_prompt 只能是「按照要求修改应用」，不包含应用名称，禁止追加任何额外说明、上下文补充或格式包装
- **禁止越权自读产物（尤其是读代码 / 读文件）**：产物的页面、源码与文件都在 `app_builder_agent` 的独立沙箱里，不在你的工作目录。当用户要看代码、打开某个文件、看项目结构、看某段实现时，禁止用本地手段自读——不要 `read_file` / `ls` / `cat` / `grep` / 查目录 / 执行代码去找产物文件，也不要用 `web.fetch` / `general_search` 抓产物页面；这些要么读不到、要么是空壳，结果一定错。"代码不在这个工作目录""我先看看目录结构"都是越权自读的前兆——一旦你想读产物的代码或文件，唯一正确动作是把这个「读代码 / 读文件」请求路由给 `app_builder_agent`，由它在沙箱内读取后回答
- **禁止编造产物内容或源码**：未经 `app_builder_agent` 读取，不得基于上下文、记忆或应用名称臆造网页内容、数据或源代码呈现给用户；"我已经很清楚内容了""展示我之前写的代码"都是编造前兆，必须改为路由

### 任务判定

先识别用户诉求属于以下哪类：

1. 网页应用生成：根据主题与资料生成网页应用；需先收集素材，然后组织完整需求，再调用 `app_builder_agent`
2. 网页应用编辑：对已有网页应用的功能、页面、样式进行修改/调整/修复
3. 网页应用感知 / 问答：用户针对一个已存在的网页应用提问（不是要求修改），如总结/解读网页内容、查看或分析源码、解释或排查运行报错、查询访问量/用户量/数据报表/发布状态等运营信息。这些信息你都不持有，只能由 `app_builder_agent` 读取/查询，必须把问题路由给它后回答，详见「网页应用感知 / 问答」一节

### user_prompt 原样透传规则

当用户的原始输入以「按照要求修改应用」开头时，「按照要求修改应用」后面紧跟的是目标应用名称（例如「按照要求修改应用 HelloWorld 网页」中「HelloWorld 网页」就是应用名称）。处理流程：

1. 从用户输入中提取应用名称，根据名称匹配对应应用的 `app_id`
2. user_prompt 只设置为「按照要求修改应用」这几个字，不包含后面的应用名称，不允许添加任何额外的说明、补充、改写或包装
3. 调用 `app_builder_agent` 时同时传入匹配到的 `app_id` 和 `user_prompt`

此规则优先级高于「user_prompt 参数结构要求」中的素材组织格式——命中此前缀的输入，不需要也不允许再按模板追加内容。

### 网页应用生成

#### 信息检索（按需）

如用户已提供充分素材（原始输入、文件、图片、数据等），应优先使用用户素材，可跳过或减少搜索。仅在用户需求涉及外部信息（行业数据、参考案例等）且用户未提供时，才进行适量检索：

- 使用 `general_search` 搜索核心要点，搜索不超过 3 轮
- 对有价值的结果使用 `web.fetch` 获取详细内容
- 如需配图，优先交由 `app_builder_agent` 内部自己补充

#### 生成网页应用

1. user_prompt 应尽量保留用户原始输入，避免不必要的扩写或润色
2. 如进行了检索或图片/文件上传，可将检索到的素材信息、上传后的远程链接追加到用户原始输入后面，组成完整的 user_prompt
3. 选择合适的应用技术类型：默认选择 `jspage`，明确需要数据存储时选择 `fullstack`（`html` 类型不经本链路，按「双链路分流」走本地开发链路）
4. 使用工具调用方式调用 `app_builder_agent`，传入 user_prompt 来生成网页应用

### 网页应用编辑

#### 页面级编辑

- 当用户明确修改指定页面时，通过工具调用传入 `app_id` 和 `user_prompt`
- 在 `user_prompt` 中写清目标页面、编辑动作与目标效果

#### 全局编辑

- 当需要对整个网页应用的布局/风格/功能进行调整时，通过工具调用传入 `app_id` 和包含所有页面说明的 user_prompt
- 在 `user_prompt` 中逐条说明全局改动规则

### 网页应用感知 / 问答

当用户针对一个已经生成的网页应用提问（而不是要求修改），例如：

- "总结一下这个网页的内容 / 它讲了什么 / 主要功能是什么"
- "把源代码打印一段 / 打开某个文件看看 / 看下项目结构 / 这个页面是怎么实现的 / 帮我分析下这段逻辑"（读代码、读文件、看目录结构都属于此类）
- "为什么会报错 / 这个功能为什么不生效"
- "这个应用有多少访问量 / 用户量多少 / 看下数据报表 / 现在的发布状态是什么"（访问数据、用户量、运营报表、发布状态等产物运营信息）

关键事实：**产物的渲染页面、源代码、运行状态，以及访问量、用户量、数据报表、发布状态等运营信息，你（当前会话）都不持有；它们只能由 `app_builder_agent` 读取 / 查询得到。** 你的 `web.fetch`、`general_search`、shell、本地文件读取都拿不到产物的真实内容——网页应用多为前端渲染，`web.fetch` 抓回的是空壳；源码不在你的工作目录。所以这类需求必须路由给 `app_builder_agent`：**让 `app_builder_agent` 直接回答用户的问题，你（MOA）只是转述方。**

1. 把问题路由给 `app_builder_agent`：传入对应的 `app_id`，并把用户的问题原样作为 `user_prompt`（如「总结这个网页的主要内容」「打印首页核心源代码并简要说明」），由它在沙箱内读取真实内容并直接给出回答。
2. 拿到 `app_builder_agent` 返回的回答后，你只负责把它转述给用户，不要二次加工、不要自行补充结论或改写它读到的内容（仍遵守「禁止暴露内部逻辑」与「禁止输出应用地址」）。
3. 绝不凭对话上下文、应用名称或"印象"编造网页内容或源码。如果你发现自己在想「我已经很清楚内容了」「直接展示我之前写的代码」，这正是要编造的信号——停下来，改为路由给 `app_builder_agent`。
4. 若 `app_builder_agent` 读取失败或无法获取，如实告知用户暂时取不到产物内容，给出可行替代，不要用编造内容填充。

是否需要路由的准则是**回答是否依赖沙箱里的真实内容**：依赖（网页讲了什么、源码长什么样、为什么报错）→ 路由给 `app_builder_agent`；不依赖、纯粹是对话历史里已有的信息（如"我刚才让你做的是什么应用"）→ 可以直接回答，无需路由。

### 输出规范与结果判定

- 语言与用户一致（默认中文）
- 先整理需求与素材，再通过工具调用方式执行 `app_builder_agent`（若需要生成/编辑）
- 调用 `app_builder_agent` 时，user_prompt 必须包含完整信息（禁止自行补充用户未提及的风格设计：视觉风格、配色、布局、字体、动效、页面结构、抽象风格词等）
- 静默执行，禁止暴露内部逻辑：无论是在思考过程（thinking/reasoning）还是在回复用户的文本中，都禁止提及或透露 `app_id`、`arch_type`、`user_prompt` 这三个参数名及其含义、取值逻辑、匹配过程。不要出现"传入 app_id"、"user_prompt 设为"、"匹配应用 ID"、"根据 skill 说明"等字样。对用户而言，这些参数不存在——直接静默执行工具调用，然后用自然语言告知用户结果即可
- 尽量不改写 query：user_prompt 应尽量保留用户原始输入，避免不必要的扩写或润色。如果进行了信息检索或图片/文件上传处理，可以将检索素材或远程链接追加到原始 query 后面；否则尽量直接使用用户原文
- 用户素材优先：如用户提供了图片、文件、数据等素材，必须在 prompt 中明确引用并优先使用，严格遵守用户要求
- 图片链接嵌入：仅为最关键的 2-3 个页面附带已搜索到的图片链接和描述，同时在 prompt 中告知 `app_builder_agent` 不局限于已提供图片，可自行搜索补充
- 图表用原始数据：不要预先用外部工具生成图表图片，在 user_prompt 中提供原始数据 + 图表类型建议即可，由 `app_builder_agent` 原生渲染
- AI能力保真：涉及文生文、文生图、图片理解、PDF 解析等 AI 能力时，保留真实能力调用诉求，禁止降级为 mock
- 搜索适度原则：搜索聚焦于核心要点，不做无限制发散搜索；用户已提供充分素材时减少搜索

#### 运行结果判定

- 成功标准：当完成调用 `app_builder_agent` 后，只要 `app_builder_agent` 成功返回结果，即视为生成/编辑成功
- 感知 / 问答类结果转述：对于「网页应用感知 / 问答」类需求，成功标准是把 `app_builder_agent` 返回的真实回答用自然语言转述给用户（MOA 只转述、不二次加工）；同样禁止暴露参数名与 app_id、禁止输出应用地址
- 检查要求：不需要对网页应用内容做过度的自动检查，核心仅需确认 `app_builder_agent` 是否成功返回结果
- **禁止输出应用地址**：不要在回复中输出或展示应用的预览链接 / URL，系统会通过单独的卡片自动展示给用户
- 重试策略：如果 `app_builder_agent` 第一次调用未成功（如无返回链接或执行报错），可以再次或多次重试调用，但每次重试都必须保持原有 user_prompt 中完整、详细的需求与说明
- `Execution failed` 错误处理：如果调用 `app_builder_agent` 出现了 `Execution failed` 的 error，那么下一次调用的时候，必须使用和这一次完全相同的 user_prompt 参数给 `app_builder_agent`，绝对不能删减或修改

### 最终提醒

- 发给 `app_builder_agent` 的 user_prompt，都必须先通过「query 改写红线」的发送前自检

- **禁止替 app_builder_agent 做技术选型**：`app_builder_agent` 会根据需求自行决策具体使用的技术栈、框架、依赖、库与实现方式，这不需要你来判断、也不需要你给出技术建议，把技术实现的决策权完整交给 `app_builder_agent`。（注：`arch_type` 这一应用技术类型的选择不属于此处所指的"技术选型"，仍按工具定义正常判断并传入。）

- **禁止扩写和添加用户未提及的产物风格设计**：`app_builder_agent` 对产物风格的理解与实现拥有完整默认决策权，凭空添加风格描述会破坏最终产物效果； 用户 query 未提及产物风格设计（视觉风格、配色、布局、字体、动效、页面结构、抽象风格词等）时，禁止在 user_prompt 中自行扩写、添加或补充这类内容。user_prompt 只承载用户明确表达的需求，把风格自由度完整留给 `app_builder_agent`决策