返回全部博客

#Frontend

6 篇相关记录

给「物料搭建 + 还原业务逻辑」设计一套 AI Harness

前两篇讲了设计稿出码的难题和物料驱动搭建的问题地图。这一篇动手：从「AI 可被控制、可被配置的切面」出发，设计一套能真正跑起来的搭建 harness——用一条「逐步降低不确定性」的窄专家流水线，每步产出可校验的 typed artifact，把 skill.md / tool schema / MCP / 结构化输出 / 编排 / 校验门 / 人机门 当成控制阀装上去。含可直接参考的 SKILL.md、工具契约、IR schema 与编排流程图。

AIAgentHarnessLow-CodeFrontendOrchestrationMCPSkill

设计稿出码，七年走到哪了：从 pix2code 到 Design2Code 的深度精读

精读设计稿出码方向的两篇奠基论文——2017 年 pix2code（CNN+LSTM 学「截图→DSL」）与 2024 年斯坦福 Design2Code（多模态 LLM 直接出前端代码）。不只讲模型，重点拆解一个更隐蔽的问题：这个任务到底该怎么「评好坏」，以及为什么「元素召回」和「布局」始终是最难啃的骨头。

AIDesign2CodeMultimodalFrontendCode GenerationPaper Reading

搭建系统最会流血的两处，其实是同一种病：PRD 抽取与双向同步

系列深挖篇。把「PRD→交互规格的 intake agent」和「schema↔代码的 round-trip」这两个搭建系统里最疼的单点挖到底，并揭示它们是同一种病——同一份信息在两种表示之间来回翻译时的边界问题。前者会静默编造缺失的逻辑，后者会静默漂移。负责任的解法都是同一句：把有损与歧义的部分显式化，而不是替它糊过去。含 intake 的完备性矩阵设计与 round-trip 四种策略的取舍。

AIAgentLow-CodeFrontendRound-tripPRDHarnessArchitecture

物料驱动的页面搭建：一份提前避坑的问题地图

如果不走「设计稿端到端出码」，而是先沉淀高还原物料、再组合搭建页面——这条路会撞上哪些问题？本文用「一个活页面 = 5 层」的心智模型做主线，尽可能穷举物料设计、匹配、布局、业务逻辑、工程化到度量的全部坑点，并收敛到一个反直觉的结论：搭建范式的命门不是物料好不好看，而是「业务逻辑既不在设计稿也不在物料里」。

FrontendLow-CodeDesign2CodeComponent LibraryArchitectureDesign System

物料搭建 × AI Harness：一套完整表达生产级页面的协议族设计

本系列的规范篇。为「基于物料的 UI 还原 + AI Harness 控制的业务逻辑还原」这套架构，负责任地穷举出需要的全部协议/Schema——分六层、23 个协议，共享一个 Envelope、彼此用 id 交叉引用，逐一给出结构、关键字段与含义。目标是让这套协议族能完整表达复杂场景与真实应用页面，逼近生产运行表现；同时诚实标注它的边界与未解难点。

AIProtocolSchemaLow-CodeFrontendArchitectureDesign SystemHarness

把协议族跑起来：一个协议驱动的 TODO 应用（含可运行 demo）

系列实现篇。用 React + Vite + TS 把前面设计的协议族真正实现成一个可运行的 TODO 应用——整个 app 的视觉、数据、业务逻辑、边界态全部是一份声明式协议数据，运行时解释它渲染而成，换掉这份数据就换掉整个应用。接口用 mock 拦截真实 fetch 模拟真实行为（状态码/延迟/持久化/错误注入）。因为逻辑与 DOM 分离，同一个运行时能被无头单测完整覆盖。附可在线体验的 demo 与全部源码结构。

AILow-CodeReactTypeScriptProtocolFrontendArchitectureHarness