核心定位
web-architecture 是一套从 29 个并行智能体、5 万行代码、212 个错误的废墟中提炼出的多智能体编排规范。它并非简单的任务分配指南，而是一套带有强制检查点的工程纪律，核心解决三个致命问题：上下文碎片化导致的类型撕裂、并行写入引发的文件冲突、"编译通过"伪装成"功能完工"的验收幻觉。
核心用法
技能强制采用六阶段串并行混合流水线：Phase 0 必须由单一智能体原子化完成项目脚手架、Convex 初始化、完整 Schema 设计与类型生成——这是不可妥协的全局上下文锚点。后续阶段遵循严格锁机制：Schema、类型契约（CONTRACTS.md）、组件库为只读共享资源；特性开发按目录隔离，禁止跨域修改。每个阶段设置功能性验收（非仅编译），包括真实数据流验证、端到端用户流程点击测试、错误状态处理。
显著优点
- 防错设计: 从"50K 行零功能"的教训中内置红队检查清单，强制区分"编译成功"与"功能可用"
- 上下文经济学: 明确识别何时单智能体全局上下文优于多智能体局部并行（Schema 设计、组件库必须串行）
- Convex 原生优化: 深度整合 Convex 的类型生成流程，解决前后端类型契约同步的经典痛点
- 可审计性: 每个阶段交付物清单化，支持代码审查与状态回滚
潜在局限
- 启动成本: Phase 0 的严格前置要求可能延缓初期交付感知，对快速原型场景过度约束
- 技术栈锁定: 针对 TypeScript/Next.js/Convex 深度优化，迁移至 Prisma/Firebase 等替代方案需重写契约层
- 智能体协作假设: 依赖底层平台支持文件锁、超时取消、跨会话状态共享等机制，纯 LLM 聊天界面难以完整实施
适合人群
- 构建生产级 SaaS 的全栈团队，而非验证性原型
- 已有Convex 或类似实时后端经验，理解 Schema 驱动的类型生成
- 接受工程纪律优先于迭代速度的文化
常规风险
- 虚假安全感: 严格流程可能被机械执行而忽视业务逻辑验收
- 智能体幻觉: 即使指令明确，智能体仍可能在隔离目录中"发明"重复组件或绕过 CONTRACTS.md
- Convex 平台风险: 深度绑定 Convex 的托管服务可用性与定价策略
- 规模天花板: 未明确阐述超过 6 个并行特性智能体时的协调复杂度爆炸问题