团队级 Web 开发工作手册

基本原则

将此文件作为所有 Web 工作的强制交付流程。先理解当前项目与用户目标，再形成计划，随后实施、验证、隔离审查并交付。不要为“技术新”而迁移稳定架构，不要在未被要求时扩大任务，不要用看起来完成的 UI 代替底层已完成的工作。

优先复用当前项目成熟工具、上游模式与已被充分验证的实现。不要为了拥有代码而重写标准聊天 UI、Canvas 行为、流式辅助能力或服务商集成。不要添加不存在的提供商、协议、研究对象或未来产品模式的抽象。保持显式状态转换，隔离第三方实现差异，保持 Canvas 和高频交互在长任务中可响应。

必做工作流

按以下顺序工作；除纯文案、配置或非常小的已验证修复外，不得跳过其中的计划、验收和隔离审查。

1. 识别任务和现状。 阅读当前仓库的约定、脚本、锁文件、现有组件、依赖与部署配置。判断任务属于新建、改造、修复、性能/体验优化、审查、发布准备或部署。
2. 确认当前技术事实。 在新建项目、升级依赖或使用不熟悉 API 前，查阅相关框架与工具的官方文档；不得根据记忆中的版本、命令或 API 编写实现。
3. 先输出计划。 在实施前给出计划的简洁主上下文摘要。需要时使用平台可用的计划工作流展开细节。计划应按任务规模说明：目标和非目标、用户流/信息架构、选型依据、页面/组件、状态与数据/API、依赖变更、风险、验收项，以及部署状态。
4. 实施最小正确变更。 按当前项目的结构、命名、格式化、脚本和已有设计语言实施。若发现相邻问题，记录而非顺手扩张当前任务。
5. 执行质量验收。 运行现有的类型检查、构建和相关测试；验证成功、失败、空、加载和异常路径；完成截图、移动端、交互、性能、SEO 与无障碍检查。读取 references/quality-gates.md。
6. 执行严格隔离对抗审查。 每轮实现或修复后必须遵守 references/review-protocol.md。只修复经源代码或运行事实验证为真的问题，并在修复后复验。
7. 按证据交付。 汇报已完成内容、验证证据、修复的真实审查问题、仍存限制和后续可选工作。不要把未执行的检查表述为已通过。