WordPress 半定制网站 AI 交付体系

公开状态：正在内部落地 · 进行中
内部基线：首页与产品页合计约 3.5 天完成；同类页面压缩至 1—2 天的目标尚未验证

问题：Brief 到上线之间，常见断裂在哪

半定制企业站很少死在「能不能生成一段代码」。更常见的是断裂发生在交付链路中间：

多轮临时 AI 对话可以提高产量，但很难把网站需求、组件标准和验收经验稳定复用下来。结果通常是返工：不是模型突然变差，而是项目记忆与验收边界没有落在可检查的位置。

「能稳定复用」和「页面能跑」也不是同一件事。界面渲染成功，只证明一次生成有效；交付还要回答：需求变了能不能改、标准能不能交给别人执行、失败后能不能定位。

【配图待补：Brief 文档片段或需求清单截图（脱敏），对照「散落聊天记录 vs 结构化 Brief」】

当前公开的流程按顺序是：Brief → 模块化 → 多代理协作 → 截图验收 → 上线检查。下面只展开已公开的步骤，不虚构未公开的工具细节。

先写清什么叫完成：页面范围、信息架构、必有模块、禁止项、响应式与浏览器基线，以及明确不能发生的行为（例如错误表单提交、空状态缺失、关键 CTA 失效）。

Brief 的作用不是「给 AI 更多提示词」，而是让人和代理共用同一份验收条件。没有这份条件，模型只能优化「看起来像做完了」。

半定制不等于从零手写每一页。把可复用区块（页头、Hero、特性、案例、FAQ、页脚、表单等）收敛成模块与字段约定：页面由模块组合，而不是由一次性 HTML 堆叠。

模块化的直接收益是：改口径时改组件，而不是在多个页面里搜字符串；后续代理实现时也有明确边界，而不是每次重新发明布局。

【配图待补：模块化主题 / 页面搭建界面，或区块字段结构的真实后台截图（脱敏客户数据）】

公开方案采用主代理统筹，并由实现 / 视觉 / QA 代理分工：实现侧重结构与功能落地，视觉侧重还原与一致性，QA 侧重对照 Brief 与检查清单找缺口。

分工本身不保证质量，它只是降低「同一个对话既写代码又当验收方」的自我确认偏差。最终是否可交付，仍取决于 Brief、模块边界，以及后面的截图与上线检查是否真的跑过。

「打开本地预览看一眼」不够。需要按关键页面与断点留下桌面、移动截图，对照 Brief 中的布局、文案层级、CTA、表单与空状态。截图是证据，不是装饰：它让返工争论落在具体差异上，而不是「我觉得差不多」。

QA 代理可以参与对照与列问题，但截图差异的最终取舍仍由人确认——尤其是品牌语气、业务表述和「看起来对但不符意图」的情况。

上图为公开项目页的真实桌面 / 移动浏览截图，用作验收对照示例。

上线前把可重复的检查项固定下来：基础 SEO 与元信息、表单与通知通路、缓存与静态资源、权限与备份、关键链接与 404、移动端可用性等。目标不是一次列尽所有可能，而是避免临场记忆漏掉已知必查项。

流程可以随组件库成熟而变短，但「生成结束 = 交付结束」这条捷径，目前仍不采纳。

在文章《AI 工程化不是多写代码：从生成到验收的闭环》里写过同一判断：AI 写出能运行的页面往往只要几分钟；真正困难的是需求变更后能否修改、标准能否复用、错误能否定位、另一个人接手时能否理解。

本项目是那条判断在 WordPress 半定制交付上的落地尝试：把 Brief、模块、代理分工、截图验收和上线检查串成闭环，而不是把「多写几段生成代码」当成工程化。相关观点见《AI 工程化：把不确定性变成可交付系统》；验收侧对应《AI 时代更需要判断与验证》。

需要诚实说明的边界：

内部基线是首页与产品页约 3.5 天；组件库成熟后把同类页面稳定压到 1—2 天，是下一目标，尚未验证。
公开状态是正在内部落地，不是已大规模对外产品化的交付平台。
它与 AI Code Debt Radar 相邻但不相同：Radar 关注生成前后的能力检索与债务记忆；本项目关注网站交付链路里的需求、模块与验收证据。二者都是工程假设的证据，不是方法论已经成熟的证明。

更适合：

不太适合：

公开内容只描述流程结构、代理分工与已记录的内部基线；不披露客户站点、未脱敏业务文案、私有组件库细节或未验证的工期承诺。若合作涉及真实站点，交付材料按约定脱敏后再复盘；合作咨询见联系页。