为什么做 Harness

AI 参与前端研发后，单个页面的生成速度提高了，但交付的不确定性没有自动消失。真正反复出问题的地方，通常不是“有没有代码”，而是这些问题：

• Agent 读到的 PRD、原型、视觉稿和接口信息不一致。
• 开发者不知道某个实现细节来自哪份证据。
• 页面能跑起来，但 PRD/RP 中的状态、弹窗、返回路径没有完整覆盖。
• 不同 Agent 供应商各有一份规则，时间一长就互相漂移。
• 验证命令、报告路径和完成标准依赖个人习惯，无法稳定交接。

fe-harness 解决的是这层协作结构，而不是替业务写页面。它把项目中应该长期存在的工程事实固定下来：输入、约束、配置、验证和历史。

不是脚手架，而是工程协议

普通脚手架通常解决“如何快速创建一个项目”。fe-harness 更关注创建之后的生命周期：

• 新输入进来时如何登记。
• Agent 开始任务前应该读哪些文件。
• 接口字段应该来自 OpenAPI 还是 PRD 猜测。
• 什么时候算完成。
• 哪些验证失败是环境问题，哪些是业务问题。
• 完成后如何留下不可变快照。

所以它既包含 create，也包含 init、inputs、task、doctor、verify、skills 等后续工作流。

为什么强调业务无关

如果 Harness 把某个业务页面、状态枚举、品牌色或接口路径写进 Core，它就会很快退化成某个项目的私有工具。这样短期看方便，长期会让复用和维护都变差。

当前架构把责任拆开：

• Core 只理解配置、诊断、验证、报告和安全写入。
• Profile 描述产品形态，比如 Consumer H5。
• Platform 描述运行环境，比如 Web Mobile。
• Stack 描述技术栈，比如 uni-app。
• 项目自己持有业务事实和 Design Token。

这种拆分让 Harness 能服务不同项目，同时不抢走项目自己的产品判断权。