Ultra 模式个人作品集网站：从附件到部署闭环复盘
入档：2026-07-28 项目：林见微 AIGC 视觉设计师虚构作品集 Demo 项目目录（库外裸路径）：
C:\Users\Administrator\Documents\个人作品集 Demo\portfolio-site生产站点：lin-jianwei-gaze.saliticidae.chatgpt.site 验证状态：⚠️ 首次 Ultra 模式完整建站案例；没有普通模式对照组
事实记录（不可修改区）
- 目标：把一份虚构简历 PDF 与《凝视》作品集 ZIP 制作成可浏览、可上线的个人作品集网站。
- 输入：PDF 1 份（约 2.01 MiB）；ZIP 1 份（约 39.53 MiB），内含同一系列的 6 张竖版 PNG。
- 用户决策：在 A / B / C 三个视觉方向中，明确选择 A「暗红时装志」。
- 成品结构：单页依次包含 Hero、Project、Works、Process、About、Experience、Contact；《凝视》作品位于主叙事前部，简历信息后置承接。
- 资产结果：6 张源图转换为 24 个生产图（AVIF / WebP × 720 / 1400 两档），约 4.31 MiB；另生成 64×64 favicon。
- 工程结果：源码提交到
main，提交为73cb1d05a4d014745f448ec2b9e0227049a9f34f；48 个文件、14,124 行新增。 - 测试结果：2026-07-28 复盘时重跑
npm test，Vinext 五阶段构建通过，2 项 SSR / 资产测试全部通过。 - 上线结果：Codex Sites 项目状态为
active，版本号 1，生产地址已存在；站点明确标注为虚构 Demo，没有把虚构履历包装成真人资料。 - 用户反馈：用户原话为「效果这么好！」。这是明确的主观验收信号，不等于招聘转化、性能或通用审美结论。
- 未验证：没有 Lighthouse 数据、真实网络性能、屏幕阅读器审计、完整浏览器矩阵、招聘方反馈或 A / B / C 同条件对照测试。
以上先按 复盘事实先行原则 冻结。下文所有「有效」只指本次交付链成立，不外推成 Ultra 必然优于其他模式。
一句话结论
这次 Ultra 的可见价值，不是替我决定审美，而是把素材审计、内容校准、资产生产、约束核查和交付验证并行压进同一条主线；真正决定成品是否收得住的，仍是明确的素材边界、一次人工审美裁决和最后由主代理完成的单线闭环。
一、实际走通的链路
- 先审附件，不先写页面：分别确认 PDF 能提供人物定位与履历，ZIP 只能支撑一个《凝视》系列；因此没有虚构第二个项目，也没有把页面做成项目数量不足的「作品墙」。
- 先给选择题，再冻结审美变量：三种方向只承担一次关键分叉。用户选择 A 后，酒红 / 黑 / 暖白、时装编辑式大标题、作品先行的页面秩序成为统一约束。
- 并行处理互不冲突的证据任务：内容审阅、素材核验、starter 约束、资产准备等分别处理；主线保留信息架构、最终文案、实现、测试与发布裁决。
- 让真实作品成为视觉锚：不额外生成主视觉，直接用 6 幅《凝视》建立色彩、裁切与节奏；只补确定性的响应式转码和 favicon。
- 单线实现并交付：一次完成页面、响应式、动效降级、虚构身份声明和测试，再由同一主线提交源码、保存 Sites 版本并部署。
信息架构沿用了 长期更新展示站_两层结构与无头卡片量产_v1 的边界判断：本次只有一个主系列，单页叙事比「目录 + 详情」更合适；将来作品增加到多个独立项目，再升级为两层结构。
二、Ultra 真正放大的环节
1. 放大的是取证带宽，不是审美权威
多个边界清楚的子任务可以同时回答「简历能说什么」「素材包真实有什么」「技术骨架不能破坏什么」「文案有没有越界」。这延伸了 子代理并行批量生成与校验组装_v1 的核心：并行单元应互斥，最终组装与验收必须集中。
但 A / B / C 哪个方向更适合，仍由用户裁决；代理只能把差异讲清楚，不能把「被选中」写成「客观最优」。
2. 放大的是闭环密度，不是一步到位
同一轮里可以连续完成：
附件事实 → 内容结构 → 视觉方向 → 资产 → 页面 → 构建测试 → 版本 → 生产部署
这减少了跨会话交接和上下文丢失，但并不等于过程没有失败。真正重要的是每次失败都能在主线内换路径，且不丢掉已经冻结的事实与设计决策。
3. 放大的是验证覆盖，不是成功叙事
资产数量、尺寸、格式、SSR 内容和 starter 残留适合机器检查；人物语义、favicon 裁切和整体观感仍需人眼；站点是否真正交付则要看生产状态与真实 URL。三层不能互相替代，具体纪律见 交付前实测证伪律_v1。
三、阻塞与恢复
| 阻塞 | 事实原因 | 恢复方式 | 沉淀 |
|---|---|---|---|
| 视觉方向无法直接定案 | 「做个人作品集」不足以确定审美语言 | 给 A / B / C 三个差异明确的方向，由用户选 A | 把主观分叉压缩成一次可逆决策 |
| 图片文件名不能可靠表达画面 | 部分命名截断，角色语义容易混淆 | 逐图视觉核验，再固定 6 个稳定 slug | 先做语义映射，再批量转码 |
| Windows 命令与 starter 脚本不完全兼容 | PowerShell 转义与 POSIX 写法不同 | 改用 Windows 可执行入口并调整命令写法 | 环境适配属于交付链，不是旁支 |
| 设计预览选择器无法正常交付预览 | 当时的本地预览通道受限 | 退为结构化文字方案，让用户仍能完成方向裁决 | 工具失效时保住决策本身 |
| 「仓库完成」容易被误写成「已经上线」 | commit、测试文件、Sites project_id 都不能单独证明生产可用 | 重跑构建测试，并读取 Sites 的 active 状态、版本与 live URL | 交付结论必须由多项证据共同成立 |
四、可复用方法
方法 1：先冻结素材边界，再设计信息架构
- 核心：先回答「真实有什么、最多能讲到哪里」，再决定页面模块。
- 来源：一份简历 + 一个 6 图系列最终收敛为单项目叙事。
- 验证状态：⚠️ 首次发现。
- 操作规则：先列输入清单、可公开事实、缺口和禁止补写项；页面只消费这张清单。
- 反例 / 边界：已有完整内容模型和项目清单时可直接消费；不能为了让页面显得丰富而补造作品、数据或剧情。
方法 2：并行任务按证据域拆，主线按决策链收
- 核心：子代理处理互不覆盖的证据域，主代理保留跨域决策、改代码和验收。
- 来源：内容、素材、工程约束、资产准备并行；页面实现与发布集中。
- 验证状态：⭐⭐ 二次案例，属于对「互斥拆分 + 集中校验」的异构任务扩展；不是对批量 JSON 流程的原样复现。
- 操作规则：每个子任务写清输入、只读 / 可写边界、输出格式和禁止事项；不要让多个代理同时改同一主文件。
- 反例 / 边界：强叙事连续写作、同一组件的高耦合重构不适合并行拆碎。
方法 3：只把一次关键审美判断交还给人
- 核心：AI 先把方向差异做成可比较选项，人只裁决最影响全局的一次分叉。
- 来源：A / B / C → 用户选择 A「暗红时装志」。
- 验证状态：⚠️ 首次发现。
- 操作规则：每个方向同时写清色系、字体气质、构图和适用场景；选定后冻结 token，后续不反复摇摆。
- 反例 / 边界：已有品牌规范时直接执行，不应额外制造选择疲劳；「用户选了」不等于「方案客观更优」。
方法 4：作品先行，简历承接
- 核心：视觉岗位先让代表作证明审美，再用方法、经历和工具解释能力。
- 来源：Hero / Works → Process / About / Experience / Contact。
- 验证状态：⚠️ 首次发现。
- 操作规则：主系列承担约 2/3 的页面注意力；履历压缩到能解释作品的方法与经历。
- 反例 / 边界：资质、论文、管理履历决定可信度的岗位，可能需要证书或经历前置；本次没有招聘数据，不能宣称提高转化。
方法 5：验证分成机器、人眼、真实环境三层
- 核心：机器证明完整性，人眼证明语义与观感，真实环境证明可用。
- 来源：资产 / SSR 自动测试 + 关键图视觉核验 + Sites active / live URL。
- 验证状态：⚠️ 首次完整闭环。
- 操作规则：三层各留至少一项可复查证据；测试文件存在不算测试通过，部署配置存在不算已经上线。
- 反例 / 边界：机器断言不能评价审美；一次人工预览不能替代性能、无障碍和跨设备测试。
五、下次怎么把 Ultra 复盘做得更硬
- 从开工就记录对照指标：总耗时、用户决策次数、返工次数、构建失败次数、子任务重叠率。没有普通模式对照，就只说观察，不说因果。
- 保留三案同尺寸预览：这次预览通道受限，只有文字裁决；下次应保留三张真实首屏图，才能复盘方向差异。
- 补真实质量数据：至少跑 Lighthouse、键盘导航、屏幕阅读器基础检查和桌面 / 移动真机抽测。
- 建立附件到页面的 source map：让每段文案、每张作品都能回溯到 PDF / ZIP，降低虚构内容混入风险。
- 作品增多再升级架构：当前单页是正确边界，不预支多项目系统；出现第二、第三个完整项目后，再迁移到目录 / 详情模型。
一句话律（暂存，待跨项目验证）
Ultra 不替代判断；它把取证、生产和验证压进同一闭环。前提是主线唯一、子任务有边界、验收能执行。
这条目前只能标为 ⚠️ 首次观察，不能写成 Ultra 的稳定产品结论。
关联文档
- 复盘事实先行原则 —— 先冻结客观交付与未验证项，避免把满意感写成因果。
- 子代理并行批量生成与校验组装_v1 —— 「互斥拆分 + 集中校验」从批量结构化内容扩展到异构网站任务。
- 长期更新展示站_两层结构与无头卡片量产_v1 —— 本次应用其边界：一次性单系列保留单页，内容增长后再拆两层。
- 交付前实测证伪律_v1 —— 构建、测试、生产状态与 live URL 共同构成交付证据。