用 Composer 2.5 写前端组件的方法
本文说明用 Cursor Composer 2.5 生成前端组件的有效提示方式和人工核验重点。
描述组件需求的有效方式
用 Composer 2.5 写前端组件时，参考 Cursor 官方博客[1]，只给一个模糊的功能描述（比如"做一个表单组件"），生成结果的样式和交互细节往往和预期有偏差。比较有效的方式是把关键约束一次性说清楚：用什么组件库或样式方案、需要支持哪些交互状态（加载中、错误提示、禁用状态）、是否需要适配移动端。约束给得越具体，生成结果需要返工的概率越低。
和项目现有风格保持一致
一个项目里如果已经有一批组件，新组件的命名习惯、Props 设计方式、样式组织方式最好和已有代码保持一致。可以把项目里一两个典型组件作为参考示例提供给 Composer，让它参照现有模式生成新组件，而不是每次都生成一套自成一体的风格。
效率提升的实际体现
Composer 2.5 处理这类结构相对固定、逻辑不算复杂的前端组件时，能明显减少手写重复样板代码的时间，尤其是表单、列表、卡片这类有固定模式可循的组件类型。逻辑复杂、涉及大量业务判断的组件，仍然需要更多人工介入调整细节。
适用边界
高度定制化的交互动效、需要精确像素级还原设计稿的场景，生成结果通常需要较多手动微调；标准化程度高、业务逻辑不复杂的通用组件，是 Composer 效率提升最明显的场景。
常见问题
生成的组件需要额外做无障碍访问适配吗？
需要，无障碍访问相关的属性（比如 ARIA 标签）经常容易被忽略，生成后建议专门检查一遍是否符合基本的无障碍规范。
组件生成后要不要写单元测试？
建议写，尤其是涉及状态切换和交互逻辑的组件，单元测试能帮助在后续修改时快速发现是否破坏了原有行为。
不同项目之间能不能复用同一套提示模板？
组件的通用约束（比如样式方案、命名规范）可以复用，但具体业务逻辑相关的描述需要针对每个项目单独调整。