feat(plugin): AI 审美批改 - 增加结构化视觉分析与精准标注 (#387)

* feat(portrait-clearance): 肖像排查 - 增加画布插件与本机检测链路 * fix(web): 插件中心 - 修复应用插件筛选与自动定位 * feat(plugin): AI审美批改 - 完成分析报告与问题标注闭环
2026-09-02 20:32:58 +08:00
parent 29f7a5c0e5
commit a6504c0e00
29 changed files with 4909 additions and 15 deletions
--- a/docs/content/docs/plugins/ai-art-critique.mdx
+++ b/docs/content/docs/plugins/ai-art-critique.mdx
@@ -0,0 +1,448 @@
+---
+title: AI 审美批改画布插件
+description: 面向图片创作的 AI 视觉分析、问题定位和修改建议插件设计。
+---
+
+# AI 审美批改画布插件
+
+> 状态：MVP 已实现，当前审美标准为 `2026-08-v1`。
+
+## 1. 先说结论
+
+这个节点的定位不是“图片生成器”，而是一个视觉老师：用户把图片接进来，它负责看图、指出问题、解释原因，并给出可以执行的修改方向。
+
+它的核心输出是一个结构化的 `CritiqueReport`（批改报告），不是另一张图片。
+
+| 输出层   | 内容                                           | 是否是默认产物         |
+| -------- | ---------------------------------------------- | ---------------------- |
+| 逻辑输出 | 总结、优点、问题、问题位置、严重程度、修改建议 | 是                     |
+| 展示输出 | 在原图上叠加的框、点、箭头和高亮               | 是，但只是报告的可视化 |
+| 图片输出 | 导出的标注图或按建议生成的修正版               | 否，作为后续操作       |
+
+因此，第一版可以把它设计成画布中的“分析终点”：图片节点连入批改节点，批改节点打开报告面板；暂时不要求它再连接到下游图片节点。
+
+## 2. 与原始架构文档的关系
+
+用户提供的 `ai-art-critique-architecture.md` 是产品和技术方案参考，不是本仓库的强制实现指令。它描述的能力方向可以保留，但工程落点需要适配当前项目：
+
+- 使用当前 `web/` 的 Vite、React、画布和插件系统。
+- 复用现有图片资源、模型渠道中转和 `ai.text` 能力。
+- 不另起一个 Next.js、Fastify、Postgres、Drizzle 或 R2 子项目。
+- 第一版不把第三方插件代码直接当作主应用 React 代码运行。
+- 先做一个受信任的内置插件，等协议稳定后再考虑开放给外部插件。
+
+## 3. 用户怎么使用
+
+典型流程如下：
+
+```text
+图片节点
+  -> 创建或连接“AI 审美批改”节点
+  -> 点击“开始批改”
+  -> AI 看图并返回结构化结果
+  -> 本地校验和整理结果
+  -> 在原图上绘制标注
+  -> 用户查看问题、原因和修改建议
+  -> 重新分析，或执行后续动作
+```
+
+第一版只支持一张输入图片。图片必须已经能被当前画布资源系统读取；如果输入节点没有可用图片，节点显示明确的空态和修复提示，不发起模型请求。
+
+## 4. 输入和输出合同
+
+### 4.1 输入
+
+输入是画布中一个可读取的图片资源，至少需要包含：
+
+- 图片资源引用或本地资源 ID。
+- 图片的宽高，或者能够在运行时读取到宽高。
+- 可读取的图片数据，例如资源 URL、blob 或 data URL。
+- 图片版本指纹，用于判断报告是否已经过期。
+
+输入不应该直接把任意网页 URL 原样交给模型。资源读取要继续遵守现有资源权限和媒体读取边界。
+
+### 4.2 核心输出：`CritiqueReport`
+
+建议把报告控制在一个适合保存到节点的大小，第一版最多保留 5 个重点问题；`0` 个问题是合法结果，可选的风格方向单独保存：
+
+```ts
+type CritiqueReport = {
+  schemaVersion: 1;
+  rubricVersion?: "2026-08-v1";
+  summary: string;
+  strengths: string[];
+  issues: CritiqueIssue[];
+  options?: CritiqueOption[];
+  sourceFingerprint: string;
+  createdAt: string;
+  modelLabel?: string;
+  scene?: SceneUnderstanding;
+  pipelineWarnings?: string[];
+  verificationSummary?: {
+    checked: number;
+    confirmed: number;
+    uncertain: number;
+    rejected: number;
+  };
+};
+
+type CritiqueIssue = {
+  id: string;
+  category: "composition" | "color" | "lighting" | "proportion" | "other";
+  title: string;
+  explanation: string;
+  severity: "low" | "medium" | "high";
+  confidence: number; // 0..1，表示模型对判断的把握
+  target: {
+    type: "box" | "point" | "points" | "polygon" | "global";
+    // 所有坐标都使用相对于原图的 0..1 归一化坐标
+    points?: Array<{ x: number; y: number }>;
+  };
+  targetDescription?: string; // Reviewer 给出的自然语言位置描述
+  targetSource?: "model" | "reference" | "global";
+  suggestion: {
+    goal: string;
+    actions: string[];
+    preserve: string[];
+    expectedEffect: string;
+  };
+  editPrompt?: string; // AI Prompt Writer 生成的局部编辑提示词
+  sourceCandidateIds?: string[];
+  groundingConfidence?: number;
+  verification?: {
+    verdict: "confirmed" | "uncertain" | "rejected";
+    confidence: number;
+    reason: string;
+  };
+};
+
+type CritiqueOption = {
+  id: string;
+  category: "composition" | "color" | "lighting" | "proportion" | "other";
+  title: string;
+  explanation: string;
+  confidence: number;
+  suggestion: CritiqueIssue["suggestion"];
+  sourceCandidateIds?: string[];
+};
+```
+
+这里要把两个概念分开：
+
+- `severity` 是问题有多严重。
+- `confidence` 是模型有多确定。
+
+不能用一个总分代替这两个字段。第一版也不把“审美分数”作为核心功能，避免用户把模型的主观判断误认为客观评分。
+
+### 4.3 标注图不是第二张原图
+
+报告里的 `target` 只描述“问题大概在哪里”。前端根据这些坐标生成 SVG overlay，叠加到原图预览上：
+
+- 原图像素不被改写。
+- 标注可以开关、筛选和重新布局。
+- SVG 可以根据窗口尺寸重新绘制。
+- 报告变更时，标注可以重新生成。
+
+如果用户点击“导出标注图”，才把原图和 SVG 合成为新的图片资源。这个动作应当是显式的，不能把查看报告自动变成生成图片。
+
+### 4.4 第一版不默认输出修正版图片
+
+“按建议生成修正版”属于下一阶段的图像编辑动作，需要用户确认并消耗图片生成额度。当前问题详情已提供“复制提示词”，内容由独立 AI Prompt Writer 根据问题和定位区域生成；生成中或生成失败时不使用本地拼接替代。未来可以继续扩展为三种显式出口：
+
+1. 复制修改提示词，粘贴到现有的图片生成/编辑流程。
+2. 导出标注图，创建一个新的图片资源或图片节点。
+3. 按建议生成修正版，进入现有图片生成/编辑流程。
+
+这些出口都不能覆盖输入原图。
+
+## 5. 处理流程
+
+当前实现采用“场景路由与四个窄 Reviewer 并行 + 保守聚合 + 报告初稿提前展示”的流程。场景路由只用于后续本地过滤和聚合；初稿只展示文字问题与建议，Grounding 和 Verification 完成后才显示最终矩形框。每个阶段都可以独立失败并降级继续，且不会为了凑数量制造问题：
+
+### 阶段 A：场景路由
+
+使用现有多模态文本模型能力，把图片作为 `image_url` 内容传入，只判断：
+
+- 图片类型、主体、视觉重点、可能的创作意图和空间深度。
+- 不输出问题，不输出批改候选。
+
+### 阶段 B：分维度 Reviewer
+
+场景路由与四个 Reviewer 同时启动；Reviewer 先依据原图和默认场景上下文工作，场景结果返回后再由本地过滤不适用的候选。四个 Reviewer 使用各自的 Rubric 子集：
+
+- Composition / Narrative：主体位置、视觉平衡、留白、动线、裁切和景深。
+- Color / Palette：主辅色、冷暖、明度、饱和度和色彩分离。
+- Lighting / Exposure：光源方向、曝光、局部对比、体积和主体光线分离。
+- Structure / Anatomy / Geometry：人物比例、物体尺寸、透视、遮挡和细节一致性；先并行检查，再依据场景类型、规则适用性和可见证据过滤候选。
+
+每个 Reviewer 只返回有证据的候选，允许返回空数组；候选必须明确区分 `issue`（确实值得修改的问题）和 `option`（可选的风格方向）。
+
+### 阶段 C：聚合和建议
+
+Aggregator 只能引用真实候选，负责去重、合并和排序，最多保留 5 个 `issue` 和 4 个 `option`。本地还会按来源和同根因关键词再做一次保守合并，避免“脸部受光不足”和“主体分离不足”这类重复问题同时占据名额。它不能凭空新增一个 Reviewer 没有支持的问题。每个 `issue` 生成：
+
+- 为什么这是问题。
+- 建议用户先做什么。
+- 哪些优点应该保留。
+- 修改后预期会有什么变化。
+
+`option` 不使用错误语气，也不计入问题数量。
+
+### 阶段 D：位置校准
+
+单独让 Grounding Reviewer 检查问题位置是否与图片内容匹配。连续的一块局部区域优先使用 `box`，单一离散位置使用 `point`，分散在多个位置的问题才使用多个 `points`。本地会拒绝零宽或零高的退化框，并根据问题描述改用带“参考区域”标记的矩形或参考点。如果定位服务不可用，先根据问题描述中的方位和对象词映射到固定的原图参考区域；没有足够线索时才降级为 `global`，不把参考坐标伪装成精确检测框。
+
+### 阶段 E：独立复核
+
+让没有参与前面判断的 fresh reviewer 查看全图和问题区域，返回 `confirmed`、`uncertain` 或 `rejected`。高置信度的 `rejected` 问题会从最终报告中过滤，复核失败则保留聚合结果并显示降级说明。
+
+### 阶段 F：AI 修改提示词
+
+Grounding 完成后，独立 Prompt Writer 与 Verification 并行，为每个已有问题生成 `editPrompt`。它只把最终问题、定位区域、修改建议和必须保留的内容转成可直接粘贴到图片编辑模型的提示词，不重新判断审美、不新增问题、不生成坐标。提示词生成完成后，详情页才允许复制；该阶段失败时保留问题和标注，但明确提示需要重新批改。
+
+### 阶段 G：本地绘制
+
+前端根据校验后的结构化数据绘制 SVG。`box` 使用矩形框，`point` / `points` 使用关键点，`polygon` 使用不规则边界；历史报告中的退化目标也会在显示时修复。碰撞处理、标签偏移、颜色和箭头位置由程序完成，不依赖模型返回 SVG 字符串。
+
+### 调用次数
+
+当前管线最多进行 9 次模型调用：1 次场景路由、4 次窄 Reviewer、1 次聚合、1 次定位、1 次复核和 1 次 AI 修改提示词生成。其中场景路由与四个 Reviewer 组成第一轮并行请求；Grounding 完成后，Verification 与 Prompt Writer 并行请求。聚合结束后先展示不带矩形框的报告初稿，定位与后续并行阶段完成后再替换为最终报告。如果没有候选，聚合、定位、复核和提示词生成会跳过。阶段调用共享同一个取消信号；任一 Reviewer、定位、复核或提示词生成失败时会保留已有结果并在报告中记录降级原因。
+
+### 当前审美 Rubric
+
+当前实现先把参考项目落成一套版本化的内部标准，而不是部署这些项目的模型或数据集：
+
+- 构图参考 CADB / SAMP-Net、CG-IAA 和 PhotoFramer，检查主体位置、视觉平衡、留白、视觉动线、构图模式、裁切和景深。
+- 色彩和光线参考 CG-IAA、AesExpert，检查色彩关系、冷暖、明度、饱和度、光源方向、曝光、体积和主体分离。
+- 人物与结构参考 HumanAesExpert，并结合 PhotoFramer 的构图判断，检查人物比例、物体相对尺寸、透视、遮挡和细节一致性。
+- 修改建议参考 PhotoFramer 的 shift、zoom/crop、view change 思路；问题定位参考 Grounding-IQA，无法可靠定位时使用 `global`。
+
+Rubric 会先要求模型判断画面意图，再应用规则。例如，居中构图或非三分构图本身不是错误，只有当它与画面意图冲突并造成可解释的表达问题时才应被报告。每次生成的报告会记录 Rubric 版本，方便后续比较规则变化带来的结果差异。
+
+当前 MVP 已使用分阶段结构化多模态调用完成“场景路由 → 四路并行批改 → 保守聚合 → 定位 →（复核 || AI 修改提示词）”，本地负责校验 JSON、规则适用性、候选来源、置信度、坐标、优先级和降级逻辑；定位服务不可用时使用参考区域坐标，并用 SVG 绘制标注。复制动作只读取报告中 AI 返回的 `editPrompt`。
+
+## 6. 画布节点形态
+
+节点建议名称为“AI 审美批改”，内部 ID 使用稳定的小写标识，例如 `ai-art-critique`。
+
+### 节点图标语义
+
+节点使用 `ScanSearch`（扫描并查找视觉问题的 Lucide 图标），不再使用通用的 AI 闪光图标。它表达的是“读取图片、扫描画面并定位问题”，而不是“生成图片”或“自动修改图片”。同一图标在以下三个位置保持一致：
+
+- 节点外层标题栏，帮助用户在画布上快速识别分析节点。
+- 添加节点菜单，避免插件入口仍显示为通用插件图标。
+- 节点卡片内部，和输入图片、报告摘要放在同一视觉语义下。
+
+图标由宿主前端静态渲染，使用现有主题色和节点尺寸；它不由模型返回，也不承担问题坐标、矩形框或 SVG 标注的生成。问题标注仍只来自结构化报告中的定位数据，并由前端绘制。
+
+### 节点状态
+
+- 未连接图片：提示“请连接图片”。
+- 已连接未运行：显示图片缩略图和“开始批改”。
+- 分析中：显示阶段和取消入口。
+- 已完成：显示问题数量或可选方向数量、最近分析时间和“查看报告”；没有可靠问题时明确显示干净状态。
+- 输入已变化：显示“报告已过期，需要重新分析”。
+- 失败：显示可读错误和“重试”。
+
+### 报告面板
+
+打开节点后使用“图片 + 报告”的双栏结构：
+
+- 左侧：原图、标注开关、问题类别筛选。
+- 右侧：总结、优点、重点问题、可选方向、严重程度和修改建议。
+- 点击问题列表中的一项，左侧聚焦对应标注。
+- 低置信度问题要明确显示“AI 不太确定”，不能和高置信度问题使用完全相同的视觉权重。
+
+建议默认显示“原图 / 批改标注”切换，不直接修改原图。面板关闭后，节点只保留摘要和状态，避免占满画布。
+
+## 7. 插件边界和当前项目的适配
+
+### 7.1 为什么先做内置插件
+
+当前通用插件节点主要适合声明式节点。AI 审美批改需要：
+
+- 读取连接的图片并处理资源引用。
+- 运行多阶段模型调用。
+- 保存和恢复报告状态。
+- 打开带 SVG 标注和交互问题列表的面板。
+
+所以第一版应采用类似肖像权排查插件的受信任内置实现，由宿主明确挂载节点和面板。不要把一段远程 React 代码直接注入主应用。
+
+### 7.2 建议的插件权限
+
+概念上需要以下权限：
+
+- `canvas.read`：读取当前节点和输入连接。
+- `canvas.write`：保存报告状态、创建后续节点或导出资源时使用。
+- `media.read`：读取输入图片内容。
+- `ai.text`：调用现有多模态文本模型。
+
+第一版只申请实际使用的权限。导出图片和创建后续节点可以放到后续版本，再增加对应写入能力。
+
+### 7.3 需要补强的通用协议
+
+当前画布插件节点协议对“输入类型”和“是否有输出端口”的表达还不够明确。为了支持这个分析节点，建议增加两个可选声明：
+
+```ts
+type PluginCanvasNodeContribution = {
+  // 现有字段略
+  acceptsInputKind?: "image" | "video" | "audio" | "text";
+  showOutputConnection?: boolean;
+};
+```
+
+`ai-art-critique` 设置 `acceptsInputKind: "image"`，第一版设置 `showOutputConnection: false`。这样用户能看出它只能接图片，而且不会误以为它默认产出另一张图片。
+
+如果暂时不扩展通用协议，也可以先像现有受信任内置节点一样做定向接入，但不建议长期依赖越来越多的节点类型硬编码。
+
+## 8. 数据保存和过期判断
+
+节点的 `pluginData` 保存当前可恢复状态，建议包含：
+
+```ts
+type ArtCritiqueNodeState = {
+  schemaVersion: 1;
+  status: "idle" | "running" | "completed" | "failed" | "stale";
+  analysisStage?:
+    | "preparing"
+    | "scene"
+    | "reviewing"
+    | "aggregating"
+    | "grounding"
+    | "verifying"
+    | "annotating"
+    | "completed"
+    | "failed";
+  sourceFingerprint?: string;
+  report?: CritiqueReport;
+  lastRunId?: string;
+  errorCode?: string;
+};
+```
+
+保存原则：
+
+- 节点保存当前报告和必要摘要，保证刷新后仍能查看。
+- 历史报告放到带用户 scope 的插件存储中，不把无限历史塞进画布节点。
+- 不保存图片二进制，不保存 API Key，不保存带敏感信息的临时 URL。
+- 原始模型响应只在调试需要时短暂保留，默认不落盘。
+- 输入图片指纹变化后，旧报告标记为 `stale`，不能静默当成最新结果。
+
+## 9. 建议的代码落点
+
+以下是预计的实现拆分，实际文件名可以随现有代码演进调整：
+
+```text
+web/src/lib/plugins/builtin/ai-art-critique.ts
+    内置插件清单、节点注册和能力入口
+
+web/src/lib/art-critique/contracts.ts
+    报告、问题、坐标和节点状态类型
+
+web/src/lib/art-critique/review.ts
+    批改入口、单阶段结构化解析和管线适配
+
+web/src/lib/art-critique/pipeline.ts
+    Scene / Reviewer / Aggregator / Grounding / Verification 多阶段编排
+
+web/src/lib/art-critique/annotation.ts
+    坐标转换、SVG 标注和标签碰撞处理
+
+web/src/components/canvas/nodes/ai-art-critique-node.tsx
+    画布节点外观和状态展示
+
+web/src/components/canvas/art-critique/ai-art-critique-modal.tsx
+    图片预览、SVG overlay、问题列表和操作按钮
+
+web/src/pages/canvas/project.tsx
+    弹窗挂载、输入连接解析、运行状态和报告保存
+```
+
+预计需要接入的现有位置包括：
+
+- 内置插件索引。
+- 画布节点内容分发和节点操作。
+- 图片节点的快捷操作或连接入口。
+- 画布项目页中的节点状态协调。
+- 插件宿主的媒体读取适配。
+- 现有 AI 请求和资源存储服务。
+
+模型请求应继续走现有渠道中转和模型协议适配，不在节点组件里新增一套 `fetch` 或直接拼装第三方密钥。
+
+## 10. MVP 范围
+
+### 必须有
+
+- 一张图片作为输入。
+- 场景理解、分维度 Reviewer、聚合、独立定位和独立复核。
+- 构图、色彩、光线、比例四类基础问题。
+- 0～5 个重点问题（5 是上限，不是目标）；可选风格方向单独展示。
+- 结构化报告、优点、修改建议和 AI 生成的局部编辑提示词。
+- 问题位置的 SVG 标注。
+- 报告保存、刷新恢复和输入变化后的过期提示。
+- 失败、取消和重试状态。
+
+### 暂不做
+
+- 自动修改输入图。
+- 默认生成修正版图片。
+- 把审美判断压缩成一个总分。
+- 无限 reviewer 或复杂后台编排。
+- 一开始就接入新的任务队列、SSE 或数据库表。
+- 把它做成可上传的任意第三方 React 插件。
+- 把 Codex MCP 插件当成画布节点的核心实现。
+
+## 11. 分阶段实现
+
+### P0：合同和节点壳
+
+先确定 `CritiqueReport`、坐标规范、节点状态、过期规则和权限；让节点能正确显示输入、空态和错误态。
+
+### P1：可用的批改闭环
+
+接入现有多模态模型能力，完成场景路由、四路并行 Reviewer、保守聚合、结构化校验、报告保存、独立复核和 SVG 标注。此阶段完成后，用户可以真正完成“图片 -> 批改报告”。
+
+### P2：可靠性和体验
+
+补充历史报告、局部重跑、低置信度处理、取消请求、耗时较长时的任务化执行和更完整的观测信息。
+
+### P3：后续动作
+
+继续加入“导出标注图”“按建议生成修正版”和重新分析对比。当前的“复制提示词”以及未来新增的动作都只创建新结果或复制文本，不覆盖输入。
+
+## 12. 验收标准
+
+一个用户拿到图片后，应该能在不阅读实现细节的情况下回答：
+
+1. 这张图整体有什么优点？
+2. 有没有需要优先修改的问题？如果有，最多是哪 5 个？
+3. 每个问题在图上的大概位置在哪里？
+4. 为什么这是问题？
+5. 我下一步可以怎么改？
+
+工程上还要满足：
+
+- 无图片时不发起模型调用。
+- 模型返回非法结构时不会把原始响应直接渲染到 UI。
+- 坐标始终限制在 0..1 范围，越界值要校验或裁剪；矩形还要满足最小宽高，退化坐标改用参考区域。
+- 原图不会因查看报告而被修改。
+- 刷新页面后，已完成报告仍可恢复。
+- 输入图片发生变化时，旧报告不会继续显示为最新。
+- 报告失败时保留可读错误，不吞掉底层失败原因。
+
+## 13. 关键风险
+
+- 模型的视觉能力和审美判断有主观性，因此需要同时展示解释和置信度。
+- 模型定位可能不准，位置校准失败时优先使用带明确提示的参考区域；没有位置线索时才降级为全局建议或不显示局部标注。
+- 模型可能把同一根因拆成多个问题；聚合后会按来源和语义主题做保守合并，避免重复占用问题名额。
+- 图片中的文字可能包含提示注入内容，必须把图片文字当作被分析的内容，而不是系统指令。
+- 多模态请求可能消耗较多额度，节点状态和重试策略必须清楚。
+- 标注图是派生视图，不应和原图混用资源 ID，也不应覆盖用户素材。
+
+## 14. 最终产品定义
+
+可以用一句话固定这个插件的边界：
+
+> 输入是图片，核心输出是结构化批改报告；标注图是报告的展示层，修正版图片是用户确认后的后续动作。
+
+这个定义能让节点的连接关系、数据结构、UI 和后续的生成能力保持一致，也能避免用户把“分析节点”误解成“图片生成节点”。
--- a/docs/design/ai-art-critique-solution.md
+++ b/docs/design/ai-art-critique-solution.md
@@ -0,0 +1,571 @@
+# AI 审美批改画布插件方案（评审稿）
+
+> 状态：方案评审稿。本文用于确认产品边界和后续实现顺序，不代表功能已经全部接通。
+
+## 1. 一句话定义
+
+AI 审美批改是画布里的“视觉质检员”：输入一张图片和可选的创作意图，输出结构化的批改报告、问题位置和下一步修改动作；它默认不修改原图。
+
+本评审稿新增一项核心技术取舍：**审美判断与区域定位分离**。审美仍由云端通用多模态模型负责；区域定位使用同一云端模型的独立 grounding 请求，只返回已有问题对应的矩形框或全局范围。第一版不部署本地定位模型，也不要求模型输出像素级 mask。
+
+推荐的长期闭环是：
+
+```text
+图片 + 创作意图
+  -> 视觉理解
+  -> 多维审美检查
+  -> 问题聚合与定位
+  -> 可靠性复核
+  -> 批改报告 + 下一步动作
+  -> 修改或重新生成
+  -> 新旧版本对比
+```
+
+第一版不追求“一次生成修正版图片”，而是先把“看懂、说清、定位准、建议能执行”做好。
+
+## 2. 调研结论：别人主要怎么做
+
+目前的参考项目大致分成五种模式。它们没有一个和影策的画布节点完全相同，但可以拼出一条比较成熟的产品路线。
+
+| 参考项目                                                                                                                                       | 实际做法                                                                                                     | 对影策的启发                                                                             |
+| ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
+| [AI Photo Critic](https://github.com/reinaldosimoes/ai-photo-critic)                                                                           | 先让视觉模型描述图片，再从摄影知识库检索构图、光线等原则，最后生成个性化点评。                               | 将“看图”和“套用方法论”分开，减少泛泛而谈。                                               |
+| [PicSpeak](https://github.com/AsaZhou923/picspeak)                                                                                             | 对构图、光线、色彩、影响力和技术执行打分，解释可见证据，并把弱项转成下一次拍摄动作；还支持原图与重拍图比较。 | 把点评延伸成“下一次怎么拍、改完是否变好”的练习闭环。                                     |
+| [Nodaro Image Critic](https://github.com/nodaroai/app.nodaro.ai/blob/main/docs/nodes/ai-image/image-critic.md)                                 | 画布节点接收图片、参考图和 Prompt，按阈值输出 `approved` 或 `rejected`，反馈可直接接入修改图片节点。         | 适合把批改结果接到自动质检、重试和生成工作流。                                           |
+| [Facet](https://github.com/ncoevoet/facet)                                                                                                     | 本地批量分析照片，在审美、构图、锐度、人脸、曝光、色彩等多个维度评分，再用于筛选和整理图库。                 | 可作为低成本的批量预筛选层；详细点评不必每张都调用大模型。                               |
+| [Grounding-IQA](https://arxiv.org/abs/2411.17237)                                                                                              | 将图像质量描述和局部区域定位结合，并支持针对局部区域的质量问答。                                             | 支持“问题必须能落到图上”，也说明了定位需要单独校验。                                     |
+| [Q-Ground](https://github.com/Q-Future/Q-Ground)                                                                                               | 专门定位和描述图像质量失真，并通过质量 grounding 数据和 mask decoder 训练提升区域定位。                      | 说明“审美判断”和“精准定位”是不同任务；第一版借鉴其任务拆分和评估思路，但不引入专用模型。 |
+| [Aestheval](https://github.com/mediatechnologycenter/Aestheval) / [The Photographer’s Eye](https://github.com/daiqing98/The-Photographers-Eye) | 从摄影社区的真实评论中整理、改写、过滤训练数据，让模型学习摄影师式的解释，而不只是输出通用图像描述。         | 后续如需提升审美质量，应积累真实创作者反馈，而不是无限堆 Prompt。                        |
+
+补充参考：[NIMA 实现](https://github.com/idealo/image-quality-assessment)和 [CLIP+MLP aesthetic predictor](https://github.com/christophschuhmann/improved-aesthetic-predictor)更偏向快速评分或排序，适合做底层筛选，不足以单独承担“为什么、改哪里、怎么改”的批改任务。
+
+### 2.1 共同规律
+
+1. 成熟产品不会只返回一句“这张图不错/不好”，而是拆成维度、证据和动作。
+2. “分数”适合排序和筛选，“文字解释”适合教学和修改，两者最好分工。
+3. 创作意图会影响判断。同样的居中构图、强烈高光或低饱和处理，可能是错误，也可能是有意选择。
+4. 真正有价值的反馈需要进入下一轮创作，而不是停在报告页面。
+5. 让模型定位问题区域，比让模型单纯描述问题更难，需要单独的 grounding 和复核步骤。
+
+## 3. 产品目标和边界
+
+### 3.1 目标
+
+- 帮创作者快速发现 0～5 个真正值得处理的问题；没有可靠问题时明确告诉用户“本轮未发现重点问题”。
+- 解释问题为什么影响画面表达，而不是机械套用“三分法”。
+- 给出可以转成下一轮提示词、修图动作或拍摄动作的建议。
+- 在原图上标出问题的大致区域，无法可靠定位时明确使用“全局”。
+- 对可定位的局部问题输出一个可解释的矩形证据框；无法可靠定位或属于整体关系的问题使用“全局”，不伪造精确框。
+- 保存报告和输入指纹，图片变化后提醒重新批改。
+- 为后续的修正版生成、重拍比较和自动质检预留接口。
+
+### 3.2 第一版不做
+
+- 不把审美压成一个绝对总分。
+- 不自动覆盖或修改输入图片。
+- 不默认生成修正版图片。
+- 不在每次分析时动态抓取互联网文章作为知识来源。
+- 不一开始引入新的任务队列、数据库表或独立后端服务。
+- 不在第一版部署本地视觉定位模型；先复用现有云端模型渠道验证 grounding 质量。
+- 不把任意第三方 React 代码直接注入主应用运行。
+
+## 4. 推荐用户流程
+
+```mermaid
+flowchart TD
+    A[启用 AI 审美批改插件] --> B[在画布添加批改节点]
+    B --> C[连接一张图片]
+    C --> D[可选：填写创作意图、用途和需要保留的内容]
+    D --> E[点击开始批改]
+    E --> F[读取图片并生成输入指纹]
+    F --> R[场景路由：只判类型与意图，不找错]
+    F --> G1[构图与叙事 Reviewer]
+    F --> G2[色彩与调色 Reviewer]
+    F --> G3[光线与曝光 Reviewer]
+    F --> G4[结构、比例与透视 Reviewer]
+    R --> H[保守裁判：去重、验来源、允许 0 个问题]
+    G1 --> H
+    G2 --> H
+    G3 --> H
+    G4 --> H
+    H -->|有可靠 issue| I0[先展示报告初稿：问题与建议，无矩形框]
+    I0 --> I[定位问题区域]
+    H -->|没有可靠 issue| L[清晰报告：本轮未发现重点问题]
+    I --> J[云端 Grounding：只返回矩形框]
+    J --> K[独立复核可靠性]
+    J --> Q1[AI Prompt Writer：生成局部修改提示词]
+    K --> L[原图 SVG 标注 + 报告面板]
+    Q1 --> L
+    L --> M[复制动作或生成下一轮提示词]
+    M --> N[修改或重新生成]
+    N --> O[上传新版本]
+    O --> P[按同一套标准比较前后变化]
+```
+
+第一版的最短路径仍然是“连接图片 → 点击批改 → 查看报告”。意图输入应当是可选的，不能成为第一次使用的阻碍。
+
+## 5. 交互方案
+
+### 5.1 画布节点
+
+- 名称：AI 审美批改。
+- 输入：图片；第一版只消费第一张已连接且可读取的图片。
+- 右侧输出：第一版关闭，避免用户误以为它会产生新图片。
+- 节点状态：未开始、运行中、已完成、失败、待更新。
+- 节点内展示：输入图片预览、当前阶段、问题数量、报告摘要和主按钮。
+- 插件关闭后：已有报告可以只读查看，没有报告时提示先启用插件。
+- 节点图标：标题栏、添加节点菜单和节点卡片统一使用 `ScanSearch`（扫描并查找问题），不使用通用 AI 闪光图标，避免把分析节点误解成图片生成节点。
+- 图标职责：图标由宿主前端静态渲染，只承担节点识别；问题原因由 AI 分析，坐标由定位阶段返回，矩形框和 SVG 由前端绘制，三者不混在图标层实现。
+
+### 5.2 批改弹窗
+
+左侧是原图和 SVG 标注，右侧是报告：
+
+- 整体判断：一句话总结，不强制输出总分。
+- 画面优点：先说值得保留的内容，避免批改只剩否定。
+- 重点问题：只展示通过证据门槛的 `issue`，按优先级展示，并支持构图、色彩、光线、比例筛选。
+- 可选方向：将主观风格建议单独展示，不使用错误色标，也不计入问题数量。
+- 无问题状态：明确显示“本轮未发现需要优先修改的问题”，不能显示为空白或失败。
+- 问题详情：问题是什么、为什么、把握度、严重程度。
+- 修改建议：目标、具体动作、需要保留的优点、预期效果。
+- 降级提示：哪些阶段失败、哪些标注被降级为全局范围。
+
+### 5.3 创作意图上下文
+
+建议提供一个轻量的“批改上下文”入口，而不是复杂表单。可选字段包括：
+
+- 图片类型：人像、风景、产品、插画、概念设计、建筑等。
+- 创作目的：作品集、海报、分镜、封面、社交媒体、概念探索等。
+- 视觉重点：主体、动作、情绪、空间或产品信息。
+- 风格与技法：低饱和、强逆光、长曝光、拼贴、故意不对称等。
+- 必须保留：人物、构图、色调、品牌元素或叙事重点。
+
+没有填写时由模型估计，但报告应标记为“基于图片推断”，避免把推断当成用户意图。
+
+## 6. AI 分析链路
+
+> 评审修订：原方案虽然已经拆成两个并行调用，但两个 Reviewer 都会收到全量 Rubric，职责仍然偏宽。本方案改为“轻量场景路由 + 多个窄职责 Reviewer 并行 + 保守裁判”，并明确允许返回 0 个问题。
+
+### 6.1 当前 Prompt 和规则匹配（以代码为准）
+
+当前画布弹窗实际调用的是 `web/src/lib/art-critique/pipeline.ts` 的 `runArtCritiquePipeline`。它最多发起 9 次模型调用，使用设置中的同一个视觉/文本模型，但每次是独立请求。场景路由与四个 Reviewer 现在会同时启动，场景结果只用于后续本地过滤和聚合；Grounding 完成后，Verification 与 AI Prompt Writer 同时启动；聚合完成后先回传一份不显示矩形框的报告初稿，后续阶段完成后再更新最终标注和可复制提示词。没有候选时会跳过后续聚合、定位、复核和提示词生成：
+
+| 阶段            | 当前 Prompt 的核心内容                                                                      | 当前行为                                                                                  | 主要风险                                                                   |
+| --------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
+| Scene Router    | “只理解图片类型、主体、意图和视觉上下文，不评价问题，不提交批改候选。”                      | 只输出场景理解，不输出问题。                                                              | 场景意图是模型推断，不应被当成用户明确要求。                               |
+| 四个窄 Reviewer | 每个请求只注入自己的 Rubric 子集：构图、色彩、光线、结构分别处理；都明确允许返回 0 个候选。 | 并行输出带 `kind`、`checkId`、证据和置信度的候选。                                        | 同一个模型仍可能有视觉误判，因此还需要本地门槛和独立复核。                 |
+| Aggregator      | “只能从真实候选中去重、合并和排序；0 个问题合法；主观方向放到 `options`。”                  | 最多输出 5 个 `issue` 和 4 个 `option`，并带真实 `sourceCandidateIds`。                   | 聚合器仍可能错误引用或混淆候选，必须由本地再次校验。                       |
+| Grounding       | “唯一任务是把已有问题绑定到图片中的位置。”                                                  | 继续复用当前云端视觉模型，但作为独立请求，只返回一个主矩形框或 `global`，并附定位置信度。 | 通用模型可以理解目标，但坐标仍可能偏移，需要候选约束、复核和降级。         |
+| Verification    | “没有参与前面判断的 fresh visual reviewer”逐项返回 `confirmed`、`uncertain` 或 `rejected`。 | 对已有问题做证据复核。                                                                    | 只有在前面已经生成问题后才触发，不能阻止前面的负面偏置。                   |
+| Prompt Writer   | “只为已有问题生成可直接用于局部编辑的提示词；严格依据 `target` 和 `targetDescription`。”    | 为每个问题输出 `issueId` 对应的 `editPrompt`，不新增问题、不生成坐标。                    | 提示词仍是模型生成文本，缺失时必须明确提示，不能用本地模板伪装成 AI 结果。 |
+
+当前的“规则匹配”不是一个真正能够看图的确定性规则引擎，而是“Prompt 约束 + 模型返回 `checkId` + 本地结构过滤”：
+
+1. `buildArtCritiqueRubricPrompt()` 会按 Reviewer 注入对应 Rubric 子集；完整 Prompt 才会附带四类规则和参考方法，每条规则都包含 `check`、`flagWhen`、适用图片类型、最低置信度、证据要求和合并关键词。
+2. Reviewer 返回 `checkId`、类别、观察、原因、证据、严重程度、置信度和目标区域描述。
+3. 本地解析会过滤未知规则、类别不匹配、Reviewer 越权、缺少证据、低于规则最低置信度的候选，并在场景识别后按图片类型继续过滤。
+4. 聚合结果会严格校验 `sourceCandidateIds` 必须真实存在，且同一个聚合项的来源必须是同类别、同 `kind` 的候选；否则过滤该结果。通过来源校验后，本地还会按来源交集和同根因主题做保守去重合并。`issue` 和 `option` 分开排序与展示。
+5. `web/src/lib/art-critique/review.ts` 仍保留旧的单次批改适配，但数量提示已改为允许 0 个可靠问题；当前弹窗默认使用多阶段管线。
+
+所以测试中出现“没有明显问题也一定挑毛病”，并不一定是某一条构图规则写错，更可能是以下组合：规则清单过宽、模型被要求持续寻找可报告项、`confidence` 是模型自报而非校准值，以及聚合器可以重新创造问题。当前实现已通过窄 Rubric、0 问题约束、`issue` / `option` 分离、候选来源校验和独立复核逐层收紧。
+
+### 6.2 准备阶段
+
+1. 检查是否有可读取的图片，没有图片时不发起模型请求。
+2. 从现有资源系统读取 data URL 或可访问的媒体数据。
+3. 生成轻量输入指纹，不把图片 URL、Cookie 或完整图片内容写入节点状态。
+4. 读取可选的创作上下文和当前 Rubric 版本。
+5. 启动轻量的 Scene Router 与四个窄 Reviewer；Scene Router 只负责判断图片类型、主体、可见性、可能的创作意图和需要启用的检查通道，不产生问题，不得输出“画面缺陷”。
+
+### 6.3 更多并行的窄职责 Reviewer
+
+Scene Router 与 Reviewer 并行启动；Reviewer 先依据原图和默认场景上下文工作，场景结果返回后再由本地按图片类型过滤候选。每个 Reviewer 使用 `Promise.allSettled` 并只接收自己的 Rubric 子集，不再接收全量规则：
+
+- **Composition / Narrative Reviewer**：主体位置、视觉平衡、留白、视觉动线、裁切、景深，以及这些选择是否损害当前表达。
+- **Color / Palette Reviewer**：主辅色关系、冷暖、明度、饱和度、色彩分离；不评价光源方向和人物结构。
+- **Lighting / Exposure Reviewer**：光源方向、曝光、局部对比、体积、主体光线分离；不重复评价构图和色彩偏好。
+- **Structure / Anatomy / Geometry Reviewer**：人物比例、物体相对尺寸、透视、遮挡、细节一致性；先并行检查，再依据场景类型、规则适用性和可见证据过滤候选。
+
+后续可针对插画或 AI 生成图增加独立的 **Artifact / Style Consistency Reviewer**，但不作为第一版默认通道。Reviewer 只返回“可靠候选”或明确的 `clean`，不生成最终总结、坐标和修图 Prompt。
+
+这里的“更多并行”不要求立刻采购多个模型。即便四个请求暂时使用同一个模型，它们也拥有独立上下文、独立职责和独立规则，注意力负担已经从“一次处理全部审美维度”降为“一次只判断一个维度”。后续有条件时，再为结构或技术检查配置更适合的专用模型。
+
+### 6.4 反“鸡蛋挑骨头”的 Reviewer 合同
+
+每个 Reviewer 的系统 Prompt 必须明确以下底线：
+
+```text
+你的任务不是证明图片有问题，而是判断是否存在“有证据、影响表达、值得现在修改”的问题。
+允许返回 0 个问题；不要为了覆盖规则、满足数量或显得有帮助而制造问题。
+只有同时满足以下条件才提交候选：
+1. 能指出图片中看得见的具体事实；
+2. 能说明这个事实如何影响当前主体、叙事、视觉层级或可信度；
+3. 能提出针对这个事实的可执行修改动作；
+4. 判断不是个人偏好、风格选择、正常透视或看不清的细节。
+没有创作意图时，主观构图和色彩判断只能作为“可选方向”，不能写成错误。
+如果证据不足、影响很小、或你无法排除这是有意为之，请不要提交候选。
+```
+
+本地还要设置硬门槛，不能只相信模型自报的 `confidence`：
+
+| 门槛     | 规则                                                                 | 不满足时               |
+| -------- | -------------------------------------------------------------------- | ---------------------- |
+| 规则适用 | `checkId`、类别、Reviewer 通道和图片类型全部匹配                     | 丢弃候选               |
+| 证据完整 | 至少有一个具体可复核的画面事实，并有影响说明                         | 丢弃候选               |
+| 意图关系 | 没有用户意图时，主观项必须标为可选方向；只有明确损害表达才进问题列表 | 降级为 `option` 或丢弃 |
+| 候选来源 | 聚合问题的 `sourceCandidateIds` 必须是已存在候选的子集               | 丢弃该聚合问题         |
+| 数量     | 0～5 是上限，不是目标；允许输出“未发现需要优先修改的问题”            | 不补问题               |
+| 复核     | `uncertain` 不能显示成确定性错误；高置信度 `rejected` 必须过滤       | 过滤或标记待确认       |
+
+建议把输出分成两类：`issue` 是有充分证据且值得修改的问题；`option` 是“如果你想往某种风格走，可以考虑”的方向。`option` 不使用红色错误标记，也不计入问题数量。这样模型即使有审美建议，也不会把每个建议都包装成缺陷。
+
+### 6.5 保守聚合阶段
+
+聚合器的职责收缩为“编辑已有候选”，而不是第二个批评家：
+
+- 只能引用和合并已有候选，不能凭空创建新的问题。
+- 删除重复问题，保留共同根因和最清楚的证据。
+- 对客观结构问题和主观审美方向分别处理，不把个人偏好升级为错误。
+- 如果没有候选通过门槛，输出清晰的“未发现需要优先修改的问题”，并保留真实优点；不为了让报告看起来完整而补问题。
+- 只有 `issue` 才进入定位和复核；`option` 作为低强调建议展示。
+
+如果聚合调用失败，使用本地规则整理已经通过硬门槛的候选；如果所有 Reviewer 都失败，则整体任务失败，不伪造报告。
+
+### 6.6 云端通用模型 Grounding（第一版方案）
+
+第一版不再要求审美 Reviewer 同时负责精确坐标，也不部署本地视觉定位模型。定位阶段继续复用现有云端通用多模态模型，但使用独立请求和更窄的输出合同：**它只绑定已有问题，不重新评价图片，也不创建新问题**。
+
+这里的“精准”定义为：返回一个能解释问题证据的矩形区域，而不是承诺框住每一个异常像素。第一版只向用户展示 `box` 和 `global`；现有合同中的 `point`、`points`、`polygon` 暂不作为云端定位器的输出，未来有专用模型时再开放。
+
+#### 6.6.1 四类请求的职责
+
+```text
+Request A：审美判断
+  图片 + 创作意图 + Rubric
+  -> issue、checkId、evidence、targetDescription
+
+Request B：区域定位
+  图片 + 场景 + 已有 issue
+  -> 每个 issue 一个 box 或 global + groundingConfidence
+
+Request C：位置复核
+  图片 + issue + box 对应的裁剪/标注预览
+  -> confirmed / uncertain / rejected
+
+Request D：AI 修改提示词
+  图片 + 场景 + issue + 已定位的区域 + 修改建议
+  -> 每个 issueId 一个可直接用于局部编辑的 editPrompt
+```
+
+Request A 的 `targetDescription` 必须是可定位目标，而不是抽象结论。例如：
+
+```text
+“主人物的脸部区域”
+“画面右上角的高光背景”
+“前景桌面上的物体”
+“主体与右侧画面边缘之间的留白关系”
+```
+
+不要把“视觉平衡差”“色彩不统一”“氛围不够集中”直接作为定位短语；这类问题应由审美模型先指定可见证据对象，定位器再框出该对象。若不存在稳定的局部证据，直接返回 `global`。
+
+#### 6.6.2 定位输出合同
+
+逻辑格式如下，实际传输继续适配现有的 `ArtCritiqueTarget`：
+
+```json
+{
+  "issueId": "human-proportion",
+  "target": {
+    "type": "box",
+    "points": [
+      { "x": 0.42, "y": 0.48 },
+      { "x": 0.61, "y": 0.76 }
+    ]
+  },
+  "groundingConfidence": 0.86
+}
+```
+
+约束如下：
+
+1. 坐标使用原图左上角 `0,0`、右下角 `1,1` 的归一化坐标，不使用展示容器坐标。
+2. `box` 只使用左上角和右下角两个点，并校验边界、宽高和方向。
+3. 每个 `issue` 默认只有一个主矩形框；多个互不相连的区域不强行包成一个大框，必要时拆成独立问题，否则降级为 `global`。
+4. `groundingConfidence` 只能作为筛选信号，不能代替验证；模型自报高置信度不等于位置正确。
+5. 参考区域坐标必须标记为 `reference`，不能伪装成云端模型检测结果。
+
+#### 6.6.3 按审美维度选择定位策略
+
+| 审美维度         | 定位器寻找的证据对象                     | 位置判断方式                                                                       |
+| ---------------- | ---------------------------------------- | ---------------------------------------------------------------------------------- |
+| 构图与视觉层级   | 主体、前景、背景、视觉焦点、边缘干扰物   | 云端模型返回对象框；主体位置、留白和边距由审美模型解释，必要时由本地几何逻辑计算。 |
+| 色彩             | 主体、背景、局部色块或明显跳出的区域     | 先框出可见对象，再用原问题和局部裁剪复核；没有稳定色块目标时使用 `global`。        |
+| 光线             | 脸部、主体、高光、阴影、背景光区         | 优先框出受影响主体或光区；不要把整张图的光照判断伪装成局部框。                     |
+| 比例、结构与透视 | 人物、脸、手、物体、建筑结构或透视参照物 | 框出实体后再判断比例、遮挡和透视关系；不让定位器单独判断“是否畸形”。               |
+
+对于主体偏移、物体相对大小和边距等问题，矩形框表示“被评价的主体/证据对象”，不是数学意义上的“错误像素”。这能让标注既能解释问题，又不会制造虚假的精确感。
+
+#### 6.6.4 复核与降级
+
+复核请求应同时看到原图、问题文本和候选框对应的局部区域，重点确认：
+
+- 候选框内是否包含问题描述中的对象。
+- 框内是否有支持问题的可见证据。
+- 框是否偏离主体、落在相邻对象或只覆盖无关背景。
+- 这个问题是否其实是全局关系，而不是局部缺陷。
+
+通过本地几何校验且复核为 `confirmed` 时，`targetSource` 才记为 `model`。复核为 `uncertain` 时保留文字问题但显示待复核提示；复核为 `rejected` 时过滤该标注。云端 grounding 失败、框无效或置信度不足时，优先使用带来源提示的参考区域；没有明确位置线索才使用 `global`。
+
+这套方案与 [Grounding-IQA](https://github.com/zhengchen1999/Grounding-IQA) 的“质量描述 + 局部区域问答”任务拆分一致，也吸收 [Q-Ground](https://github.com/Q-Future/Q-Ground) 对质量 grounding 单独训练和评估的做法；但第一版仍使用当前云端通用模型，暂不引入它们的专用训练模型。
+
+#### 6.6.5 云端模型调用边界
+
+第一版不锁定某一家云端模型，也不新增专用模型服务；继续使用当前配置和现有请求适配。被选中的云端模型必须满足：
+
+- 支持图片输入，并能看到原图而不是只接收文字描述。
+- 支持函数调用或等价的严格结构化输出。
+- 能接收原图、场景上下文和已有问题，单独执行 grounding。
+- 能在复核请求中理解“问题文本 + 候选框对应区域”的关系。
+
+同一个云端模型可以承担审美分析、定位和复核，但三者必须是独立请求、独立系统职责和独立输出合同。这样既保留当前渠道的可替换性，也避免模型在同一次回答中先猜问题、再为自己的猜测补坐标。
+
+如果某个渠道不支持严格结构化输出或对图片细节支持不足，不应在前端增加特殊解析和坐标修补逻辑；应切换模型配置或降级为参考区域/全局。
+
+### 6.7 独立复核阶段
+
+复核器不参与前面的判断，只逐项检查：
+
+- 问题是否真的有图像证据。
+- 问题是否会影响主体表达或视觉层级。
+- 位置是否与问题描述一致。
+- 是否把正常透视、特殊技法或创作意图误判为错误。
+
+被明确判定为不可靠且置信度足够高的问题被过滤；不确定的问题保留，但在界面上标为“待复核”。当最终没有可靠问题时，界面应显示正常的“本轮未发现重点问题”空状态，而不是错误状态。
+
+### 6.8 AI 修改提示词阶段
+
+Grounding 完成后，Prompt Writer 与独立复核并行运行。它接收原图、场景上下文、已有问题、`target`、`targetDescription` 和结构化建议，只负责把这些信息写成可直接交给图像编辑模型的自然语言指令：
+
+- 每个返回项必须通过 `issueId` 对应已有问题。
+- 必须说明修改区域、要解决的问题、具体动作、必须保留的主体/构图/风格和预期效果。
+- 不重新评价图片，不新增、合并或删除问题，不生成坐标 JSON，不输出 Markdown 代码块。
+- 结果写入 `issue.editPrompt`；详情页只有在该字段存在时启用“复制提示词”。请求失败或返回不完整时保留报告，但不使用本地模板冒充 AI 生成结果。
+
+### 6.9 建议阶段
+
+每个 `issue` 的建议必须回答四件事：
+
+1. 这次修改的目标是什么。
+2. 创作者具体要做什么，例如移动主体、裁切、调整视角、改变局部光线或重生成。
+3. 哪些已有优点必须保留。
+4. 改完后预期会有什么变化。
+
+`option` 只需要说明适用的风格方向和可能收益，不应使用“必须”“错误”“需要修复”等措辞。这一步的产物应当能直接复制到下一轮图片生成或修图 Prompt 中。
+
+## 7. 评分和知识库策略
+
+### 7.1 不采用单一总分
+
+单一分数容易制造“审美有标准答案”的错觉，也不利于解释为什么要修改。建议第一版使用：
+
+- 问题类别。
+- 严重程度：优先处理、建议处理、可选优化。
+- 判断置信度。
+- 位置置信度。
+
+后续如果需要排序或批量筛选，可以增加构图、光线、色彩、技术质量等维度分数，但不默认合成为一个总分。
+
+### 7.2 Rubric 先本地化
+
+第一版采用版本化的本地 Rubric，作为稳定的评价框架；不在每次请求时抓取互联网内容。这样可以保证：
+
+- 同一张图重跑时标准相对稳定。
+- 不引入不可信或互相矛盾的网页内容。
+- 便于测试、回归和解释报告。
+- 后续可以按项目、品牌或导演风格替换 Rubric。
+
+知识库或 RAG 可以作为后续增强项，用于补充摄影教学内容，不应直接决定问题是否成立。
+
+## 8. 画布数据合同
+
+### 8.1 输入
+
+```ts
+type ArtCritiqueInput = {
+  imageNodeId: string;
+  sourceFingerprint: string;
+  imageData: string; // 只在请求生命周期内使用
+  intent?: {
+    imageType?: string;
+    purpose?: string;
+    focus?: string;
+    style?: string;
+    preserve?: string[];
+  };
+};
+```
+
+### 8.2 报告
+
+报告至少包含：
+
+- `summary`：整体判断。
+- `strengths`：已有优点。
+- `issues`：最多 5 个重点问题；没有可靠问题时可以为空。
+- `options`：最多 4 个可选风格方向，不计入问题数量。
+- `category`、`severity`、`confidence`：问题分类和可信度。
+- `target`：第一版主要使用归一化的矩形框或全局范围；现有合同保留点、多点、多边形的兼容空间，但云端通用 grounding 暂不输出它们。定位失败时可为带明确提示的参考区域。
+- `suggestion`：目标、动作、保留项、预期效果。
+- `editPrompt`：由独立 AI Prompt Writer 根据最终问题和定位区域生成的局部编辑提示词；缺失时不使用本地拼接替代。
+- `sourceFingerprint`：报告对应的图片版本。
+- `rubricVersion`、`createdAt`、`modelLabel`：可追溯信息。
+- `pipelineWarnings`、`verificationSummary`：降级和复核信息。
+
+### 8.3 节点状态和过期
+
+- 报告保存到节点 metadata 中，不保存原图二进制。
+- 节点保存输入节点 ID 和输入指纹。
+- 输入图片变化后，报告显示为 `stale`，不能继续伪装成最新报告。
+- 刷新画布后，已完成报告可以恢复。
+- 取消时恢复为可再次运行的状态，不留下半份成功报告。
+
+## 9. 后续输出设计
+
+第一版可以保持“分析终点”形态，先保证体验完整。第二阶段建议增加可选的逻辑输出，而不是默认输出图片：
+
+| 输出                    | 用途                                                   |
+| ----------------------- | ------------------------------------------------------ |
+| `report`                | 给报告查看器、历史记录或导出使用。                     |
+| `nextPrompt`            | 将重点问题和修改动作转成下一轮生成/修图提示词。        |
+| `approved` / `rejected` | 用于自动质检和失败重试；不能只由审美总分决定。         |
+| `retakeContext`         | 将本次问题、目标和成功检查传给下一张重拍或重生成图片。 |
+
+其中 `approved` / `rejected` 需要补充通用插件输出协议，不能只在本节点内部临时实现。
+
+## 10. 版本规划
+
+### P0：当前已接通
+
+- 在画布项目页挂载 `AiArtCritiqueModal`。
+- 在 `CanvasNodeActionContext.Provider` 注入 `openArtCritique`。
+- 复用现有节点 metadata 更新和画布保存机制。
+- 支持插件启用、图片连接、弹窗打开、开始/取消/失败/重试。
+- 专项测试覆盖节点注册、入口菜单、报告解析、窄 Rubric、来源过滤和标注降级。
+
+当前代码已经有插件清单、节点渲染器、报告合同、分析管线、弹窗组件和画布页面接线；浏览器中的真实模型调用仍需要按部署环境做人工冒烟。
+
+### P1：当前可靠性版本与后续增强
+
+- 已将全量 Rubric 改为按 Reviewer 通道注入的窄 Rubric，拆成构图、色彩、光线、结构四个并行 Reviewer。
+- 已删除“必须输出 3～5 个问题”的数量暗示，允许 Reviewer 和最终报告返回 0 个问题。
+- 已增加 `issue` / `option` 语义和本地候选硬门槛，聚合器只能引用真实候选，不能凭空新增问题。
+- 采用云端通用多模态模型的独立 grounding 请求：审美 Reviewer 输出 `targetDescription`，Grounding 只返回一个矩形框或 `global`，不新增问题。
+- 将 grounding 复核输入明确为“原图 + 问题 + 候选框对应区域”，并区分 `model`、`reference`、`global` 三类定位来源。
+- 待增加轻量创作意图上下文，让主观判断有更明确的参照。
+- 待将“下一步动作”和“成功检查”加入报告。
+- 已在问题详情的“改进”区域提供“复制提示词”动作；文本由独立 AI Prompt Writer 生成，且与 Verification 并行执行，前端不再本地拼接提示词。
+- 已明确显示报告依据的图片和 Rubric 版本。
+- 已优化定位失败、模型部分失败和取消时的提示。
+
+### P2：接入画布创作闭环
+
+- 增加 `nextPrompt` 和 `retakeContext` 逻辑输出。
+- 支持从报告直接创建新的修改 Prompt 或图片生成任务。
+- 保存原图、修改版和批改报告之间的关系。
+- 用同一套 Rubric 比较前后版本，并计算变化；分数差异由本地确定性逻辑计算，不能完全交给模型。
+
+### P3：批量和自动质检
+
+- 增加低成本技术预检，例如清晰度、曝光、色彩和主体可见性。
+- 支持批量图片筛选和最佳候选排序。
+- 支持 `approved` / `rejected` 分支和有限次数自动重试。
+- 用真实项目图片评估云端 grounding 的框选稳定性；只有云端方案无法达到验收标准时，再评估 [Florence-2](https://huggingface.co/microsoft/Florence-2-base)、[Grounding DINO](https://github.com/IDEA-Research/GroundingDINO) 等本地定位模型或专用质量 grounding 模型。
+
+## 11. 验收标准
+
+### 用户验收
+
+用户不阅读实现细节，也应能回答：
+
+1. 这张图有什么优点？
+2. 最先该改哪几个问题？
+3. 每个问题大概在图上的什么位置？
+4. 为什么是问题，而不是单纯的审美偏好？
+5. 下一步具体怎么改？
+6. 修改后如何判断真的变好了？
+
+### 工程验收
+
+- 没有图片时不发起模型调用。
+- 模型返回非法结构时不直接把原始响应渲染到页面。
+- 第一版定位输出只接受 `box` 或 `global`；坐标始终限制在 `0..1`，定位失败时优先使用带来源标记的参考区域，没有位置线索才使用 `global`。
+- 原图不会因打开报告或绘制标注而被覆盖。
+- 输入变化后旧报告会进入 `stale` 状态。
+- 分析可以取消，失败原因可读，重试不会复用错误状态。
+- 页面刷新后已完成报告可以恢复。
+- 所有模型调用继续复用现有模型渠道和请求适配，不在插件组件里保存第三方密钥。
+- 画布入口至少有一条交互测试，覆盖“按钮点击确实打开弹窗并启动分析”。
+
+### 质量验收
+
+- 不为了凑数生成问题。
+- 每个问题有具体证据、建议动作和需要保留的内容。
+- 每个局部问题最多展示一个主矩形框；低置信度或复核不通过的问题不会使用看似精确的局部框。
+- 视觉规则不被当作绝对答案；创作意图优先于机械套用构图口诀。
+- 批改语气直接、克制、可执行，不用空泛的夸奖或绝对化结论。
+
+## 12. 主要风险和处理
+
+| 风险                                   | 处理方式                                                                                                                                                |
+| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 审美判断主观                           | 展示依据、置信度和创作意图，不给单一绝对结论。                                                                                                          |
+| 模型把图片文字当指令                   | 在系统提示中明确图片内容不是系统消息，并对返回结构严格校验。                                                                                            |
+| 区域定位不准                           | grounding 独立成阶段；要求目标描述具体化，使用 box 几何校验和候选区域复核；失败时使用带来源标记的参考区域，低置信度且无位置线索才降级为全局。           |
+| 通用模型能判断审美但不会精确框选       | 不让审美模型直接承担最终坐标；先输出可定位的证据对象，再由独立 grounding 请求框选；仍无法稳定定位的维度保留 `global`。                                  |
+| 云端模型在小目标或局部光色问题上不稳定 | 原图与候选区域一起复核；不把框解释为异常像素级 mask；积累评估样本后再决定是否引入本地专用定位器。                                                       |
+| 模型调用成本高                         | 场景路由与四个窄 Reviewer 并行；Grounding 后 Verification 与 Prompt Writer 并行且各只做一次批量请求；结构候选在本地按图片类型过滤；后续增加低成本预检。 |
+| 模型为了显得有帮助而挑毛病             | 允许 0 个问题；问题与可选方向分离；证据、意图、影响和来源均设置硬门槛。                                                                                 |
+| 聚合器重新编造问题                     | 强制 `sourceCandidateIds` 引用已通过校验的候选，本地拒绝无来源问题。                                                                                    |
+| 同根因问题重复出现                     | 聚合后按来源交集和保守主题关键词合并，保留更高优先级问题并合并可执行建议。                                                                              |
+| 图片输入变化导致旧报告误导             | 保存指纹并显式标记 `stale`。                                                                                                                            |
+| 报告建议无法落地                       | 强制输出动作、保留项、预期效果和成功检查。                                                                                                              |
+| 自动重试造成错误放大                   | 先做人工确认和有限次数重试，再开放自动分支。                                                                                                            |
+
+## 13. 待审阅决策
+
+以下选择会影响后续代码结构，建议先确认：
+
+1. **是否采用四个窄 Reviewer 并行？** 建议采用；并行拆分的重点是缩小每次请求的注意力范围，不是盲目增加调用数量。
+2. **是否允许报告为 0 个问题？** 建议必须允许；“没有可靠问题”是合法结果，不应被当成模型失败。
+3. **是否把主观建议和确定性问题分开？** 建议分成 `issue` 与 `option`，只有前者进入红色标注、定位和复核。
+4. **是否加入创作意图输入？** 建议加入，但全部可选，默认仍可直接批改。
+5. **是否加入维度分数？** 建议第一版不加总分；如有批量筛选需求，再加维度分数。
+6. **是否马上增加输出连线？** 建议 P0 保持分析终点，P2 再补 `nextPrompt`、`retakeContext` 和质检分支。
+7. **是否马上接入 RAG？** 建议先使用版本化本地 Rubric，等真实反馈积累后再接知识库。
+8. **是否马上支持原图/修改版对比？** 建议作为 P2 主线，它比“再生成一张图”更能证明批改是否有效。
+9. **第一版是否采用云端通用模型做独立 grounding？** 建议采用；审美和定位分开请求，定位只输出矩形框或 `global`，暂不部署本地模型。
+10. **是否要求第一版框选到异常像素？** 不建议；第一版定义为“可解释的证据矩形框”，不是像素级缺陷分割。
+
+## 14. 最终建议
+
+最小可行路线不是继续堆更多审美检查项，而是先完成这条可靠链路：
+
+```text
+接通入口
+  -> 看懂图片
+  -> 由窄 Reviewer 并行检查
+  -> 只保留有证据的重点问题（允许 0 个）
+  -> 云端独立 Grounding 返回矩形框
+  -> 用原图和候选区域复核
+  -> 给出可执行动作
+  -> 能进入下一轮创作
+  -> 能比较改前改后
+```
+
+因此建议优先级为：
+
+1. 修复当前画布入口缺口，让已有 MVP 真正可用。
+2. 加入可选创作意图和“成功检查”。
+3. 将报告动作接到下一轮 Prompt 或生成节点。
+4. 增加原图与新版本比较。
+5. 用真实样本评估云端框选稳定性；只有达不到验收标准时，再考虑本地定位模型、专用质量模型和自动重试。
--- a/docs/index.md
+++ b/docs/index.md
@@ -14,6 +14,8 @@

 - [肖像权可识别性排查画布插件实施规格](design/portrait-clearance-canvas-plugin.mdx)：TypeScript 重写、画布节点与全屏工作台、项目模型复用、本机 ONNX/百度识图/候选去重、任务合同、报告和验收方案。

+- [AI 审美批改画布插件方案](design/ai-art-critique-solution.md)：云端视觉分析、并行 Reviewer、问题定位、AI 修改提示词与前端 SVG 标注的职责边界和交互设计。
+
 - [LLM、Image、Video 主流请求协议全景与影策兼容性调查](design/model-request-protocol-landscape.md)：主流原生协议、聚合网关、图片/视频异步任务、参考素材 role、当前插件映射缺口与 MiniMax H3 专项审计。

 ## 本地协作文档（不随仓库分发）
@@ -24,6 +26,7 @@

 功能、代码地图、待办、待测试分别维护在以下页面；尚未建立的专题会在对应任务中补齐：

+- [AI 审美批改画布插件](content/docs/plugins/ai-art-critique.mdx)
 - [功能](content/docs/overview/features.mdx)
 - [本地开发](content/docs/backend/local-development.mdx)
 - [后端数据库](content/docs/backend/backend-database.mdx)