AI Coding Rules指南与规则
一个页面把“如何协作使用 AI”与“规则标准骨架”放在一起，方便团队快速对齐与落地
设计灵感库
不知道怎么画好看？看看别人怎么做的，从模仿优秀案例开始
项目开发前：推荐 AI 工具与网站
先把「原型 / 视觉 / 信息架构」跑通，再进入实现，会显著降低返工成本
开发前对齐：参考与设计基线
先对齐再开发，避免边做边改导致体验与视觉漂移
开发时可以截图参考应用、APP（信息结构、交互路径、状态样式），作为实现对照
在开发前确定产品理念、体验设计，以及 design token（颜色/字号/间距/圆角等），作为全项目一致的约束
开发时前端可以用 chrome-devtools-mcp，让 AI 自动化进行调试与性能评测
Step 1
基础原则
始终显式化意图：把需求、输入/输出格式、边界条件写成提示模板
及时校验：对模型输出做 schema / 规则校验（即便是前端），避免脏数据入库
迭代式对话：逐步收窄上下文，避免一次性长指令；对齐后再生成代码
Step 2
典型工作流
设计 → 生成 → 自测：先要接口/状态设计，再生成实现，最后要求模型写自检用例或脚本
代码阅读 → 摘要 → 改动：让模型先总结文件/模块，再制定改动计划，减少“盲改”
日志/告警处理：贴错误 + 关键上下文，要求给出最小复现/定位步骤，而不只是修复建议
Step 3
防坑清单
禁止默写配置：要求给出官方文档链接或版本号，确认兼容性
涉及安全/支付/幂等：必须列出风险与校验点（签名、重放、幂等键、对账）
生成脚本前：提醒模型确认路径/环境/权限，避免删除或覆盖关键文件
可复用提示模板（节选）
直接复制到模型对话里，记得补齐上下文（文件/接口/约束）
代码改动三段式
- 理解：用 3-5 句话总结目标、输入、约束、输出格式
- 计划：列出要改的文件/模块、接口、边界条件、自测方式
- 执行：按计划实施，边改边解释关键决策，最后给自测命令
日志/告警定位
- 阅读错误：指出触发条件、堆栈关键帧、疑似根因
- 验证路径：给出最小复现步骤或实验性修改（不直接提交）
- 补充监控：建议新增/调整日志、指标、告警阈值
安全/支付/幂等变更必答
- 幂等策略：幂等键、重试策略、死信/补偿
- 签名与校验：请求/回调签名、时间戳/重放保护
- 审计与告警：记录关键字段；失败告警；对账/落账策略