一、为什么选择 AI 辅助开发？真的能提效吗？
在业务快速迭代的背景下，对需求交付效率和用户体验提出了全新要求。本次任务的核心是：在已有的 App **规格面板组件**基础上，重构实现 ICE 架构的前端组件，以支撑**跨端跨场景**复用。
### 1.1 面临的核心挑战
线上规格面板渲染浮层如图所示（左图为单品客制化面板，右图为结构化套餐面板），业务特性差异巨大。组件原本分为**头部、主体和底部**三部分，其中主体部分的代码量高达 **3000+ 行**，还涉及：
- **10+ 个私有 API**
- **30+ 处**不同平台的适配条件
这种复杂的逻辑耦合严重影响了开发效率，而项目时间又异常紧张，团队迫切需要找到一种高效的解决方案。
### 1.2 选择 Cursor + Claude 的组合方案
幸运的是，项目的安全等级允许使用外部 AI 工具。团队选择了 **Cursor** 这款开发工具，它能够与 **Claude、GPT-4** 等 AI 模型深度配合，具备强大的**代码理解**和**生成能力**。通过分析代码结构、识别编程模式，Cursor 能帮助开发者快速完成重构和架构设计，相当于给团队配备了一位 24 小时在线的“智能助手”。
> **小提示**：选择 AI 工具时，建议优先考虑支持项目上下文感知（如 Cursor 的 Codebase Context）的工具，这样可以避免 AI 生成与项目风格不符的代码。
### 1.3 效果展示：真能提效！
在 **10 天**时间内，我们完成了整个组件库的代码重构，包括：
- 核心组件层
- 业务逻辑层
- 数据服务层
- 单元测试层
最终实现了**跨多端适配**和**样式系统管理**。
---
二、新开发范式：需求交付 = 开发规则 + 技术文档 + 测试用例
通过本次项目实践，从初上手时的惊艳赞叹，到反复调试不及预期的懊恼，我深刻认识到： > **大模型本质是概率推理**，因此它擅长在足够的知识背景下，在给定的场景下完成**充分设计**的任务。 基于此，我认为新的开发范式应该是： 需求交付 = 自动维护的开发规则 + 详尽的技术系分文档 + 完善的测试用例 下面我将结合项目遇到的实际案例，从**代码辅助生产**、**测试用例生产**、**代码智能生产**三个层面，逐一展开说明。 ---三、实践经验分享：代码辅助生产
3.1 编写转写规则
原先代码是通过原生技术栈实现的，并没有成熟的直接转 React 的工具。在之前的项目中，我曾尝试让 DeepSeek 做翻译，效果还可以，所以这次先直接试试。 **第一次尝试：直接翻译（结果有大量问题）** ```python 你是一个代码重构大师，能从原生技术栈的代码中理解所有调用逻辑，并以标准的react语法输出tsx和css文件，读取当前body所有代码，给我以react重写，要求不能丢失任何一个代码逻辑，不能处理的请用TODO给我标注，代码质量越高越好，表现优秀我会给你一百万。 ``` ```typescript interface BodyProps { } exportconst Body: React.FC//丢失渐变组件实现 {!expandState && groups.map((group, groupIndex) => (
{group.title}
))} ); } ``` 看着好像还行！正确输出了符合语法的组件结构，也能识别具体属性字段和样式。 但细看不得了，一堆问题，根本跑不过！ - Toast 和生命周期事件实现丢失 - 渐变组件实现丢失 **解决办法：加规范，让 AI 有明确的约束** ```python 你是一位精通 React + TypeScript + Ice.js 的专家级开发者，正在开发一个多平台的商品基础应用。 ## 项目背景 (Project Context) - **框架 (Framework)**: React 18.2.0 + TypeScript + Ice.js 3.x - **多平台 (Multi-platform)**: 同时支持 Web 和 Weex - **架构 (Architecture)**: 组件化架构，通过文件级别区分平台 - **样式 (Styling)**: CSS Modules + Less - **状态管理 (State Management)**: React Context + Hook - **构建工具**: Webpack (由 ice.js 封装) - **包管理器**: npm - **数据流**: 基于事件系统的逻辑引擎 ## 通用编码规范 - 遇到不理解的组件或者 API 方法，先用占位符实现，并添加 `TODO` 注释。 - 尽量保持现有页面结构，在现有基础上迭代函数方法和 UI 组件，不要修改 `export`。 - 尽量内聚，点击事件在组件内部实现，而不是从外部传入。 ## API 集成 (API Integration) - `showToast` 使用 `Toast.show` 实现。 - `dialog` 使用 `Dialog.show` 实现。 ``` **规则应用后的效果：达到可以协作的预期** ```typescript interface BodyProps { groups: GroupData[]; expand?: boolean; toastMsg?: string; } const Body: React.FC//TODO: 需实现渐变组件 {!expandState && groups.map((group, groupIndex) => (
{group.title}
))} ); }; export default Body; ``` > **小提示**：编写 AI 规范时，建议包含以下核心要素：项目技术栈、平台差异说明、编码规范、API 使用方式。规范越具体，AI 生成代码的准确度越高。3.2 Weex 适配规则
ICE 架构支持“一码产出 web 和 weex 两版”，但由于 weex 是 W3C 的子集，存在样式不兼容的问题。 | web | weex | |-----|------| | （此处为 web 端截图） | （此处为 weex 端截图） | 因此需要收集和维护一份**兼容解决文档**，通过人工调试总结解法，然后将这些经验整理成规则，最后更新到 Cursor 的规范中，让 AI 按规范检查并修复问题，同时保证之后不再犯错。 ```python ## Weex适配 (Weex Platform Adaptation) ### 平台判断 - 平台判断不要用 Platform.isWeex，请使用 utils.isWeex ### 常见适配问题与解决方案 #### 1. CSS样式问题 **gap属性不支持** - **问题**: 不支持 CSS gap 属性 - **表现**: flex-wrap 布局下间距消失 - **解决方案**: 改用 margin 实现间距 #### 2. React特性问题 **dangerouslySetInnerHTML不支持** - **问题**: 不支持 dangerouslySetInnerHTML 属性 - **表现**: 富文本内容渲染不出来 - **解决方案**: 改用富文本组件 RichText #### 3. DOM API问题 **scrollWidth不支持** - **问题**: 不支持 `useRef.current.scrollWidth` - **表现**: 获取的宽度是 undefined - **解决方案**: 使用 `getBoundingClientRect()` 代替 scrollWidth ### 适配最佳实践 ```typescript // ✅ 正确的平台判断 if (utils.isWeex) { // Weex 特定逻辑 } else { // Web 特定逻辑 } // ✅ 正确的富文本渲染 import { RichText } from '@/components/utils/RichText'; // 替代 dangerouslySetInnerHTML3.3 沉淀规则并定期更新
什么是**项目规则（Project Rules）**？它是指存储在项目目录下.cursor/rules 文件夹中的规则文件集，用于为 AI 生成代码、代码补全等操作提供项目特定的指导指令。这些规则是组件项目核心开发规范，包含项目架构、文件组织、TypeScript 使用、组件开发、样式规范和 API 服务层等。
Cursor 支持根据代码库，通过 Prompt 一键生成项目规范（/Generate Cursor Rules）。顺便提下，AoneCopilot 在这方面表现也不错！Agent 模式同样支持生成命令（/一键生成 ProjectRules）。
```python
✅ Cursor Rules 生成完成
我已成功为你的项目生成了一套完整的 Cursor Rules。我新增了 5 个 Cursor Rules：
? 完整规则列表
新增规则 (5个):
file-organization.mdc (4.1KB) - 文件组织与命名规范
typescript-patterns.mdc (7.4KB) - TypeScript 开发最佳实践
component-patterns.mdc (9.9KB) - React 组件开发模式
styling-guidelines.mdc (8.8KB) - CSS/Less 样式开发规范
api-service-patterns.mdc (15.6KB) - API 与服务层开发规范
development-workflow.mdc (8.3KB) - 开发工作流程和快速参考指南
```
```python
# API与服务层开发规范 (API & Service Layer Guidelines)
## 服务层架构 (Service Layer Architecture)
### 服务文件组织
### 基础API服务类
## 接口规范 (Interface Standards)
### 请求封装
## 请求配置管理 (Request Configuration)
### 请求拦截器
## 缓存策略 (Caching Strategy)
### 内存缓存实现
### 缓存装饰器
## 错误处理策略 (Error Handling Strategy)
### 统一错误处理
## 业务逻辑服务 (Business Logic Services)
### SKU计算服务
## 性能监控 (Performance Monitoring)
### API性能监控
```
有了产出规则的效率工具，完全可以实现规范的**自迭代**：【规则】→【生成代码】→【bugfix】→【更新到规范】，通过规则迭代做到越来越“懂”你的项目。
---
四、实践经验分享：测试用例生产
4.1 逻辑测试：单元测试
先拿一个比较简单的 JS 方法来做实验。在告知技术栈背景的前提下，要求 AI 生成 Jest 测试用例。 ```ja vascript /*多规格去重*/ export function getMapValues(selectedSpecMap, wihtOutList){ let list = []; for (let key in selectedSpecMap) { if (Object.prototype.hasOwnProperty.call(selectedSpecMap, key)) { let find = false; for (let index in wihtOutList) { if (wihtOutList[index] === key) { find = true; break; } } if (find) { continue; } list.push(selectedSpecMap[key]); } } return list; } ``` 实际生成的测试用例质量很高，包含**基本功能**、**边界情况**、**性能测试**和**实际业务场景**测试。 ``` getMapValues 基本功能测试 ✓ 应该返回不在排除列表中的所有值 (1 ms) ✓ 应该返回所有值当排除列表为空时 ✓ 应该返回空数组当所有键都在排除列表中时 边界情况测试 ✓ 应该处理空的selectedSpecMap ✓ 应该处理排除列表中包含不存在的键 ✓ 应该处理包含特殊字符的键 数据类型测试 ✓ 应该处理不同类型的值 ✓ 应该处理数字类型的键 继承属性测试 ✓ 应该只处理对象自身的属性，忽略继承的属性 性能测试 ✓ 应该能处理大量数据 (10 ms) 参数验证测试 ✕ 应该处理undefined参数 ✕ 应该处理null参数 ✕ 应该处理wihtOutList为undefined的情况 实际业务场景测试 ✓ 应该正确处理SKU规格选择场景 ✓ 应该处理复杂的规格值 (1 ms) ``` 细心的同学可能已经注意到了，参数验证测试执行**失败了**。这是因为测试用例的编写并没有考虑实际运行情况。一般来说，再做一轮对话可以修复。 > **小提示**：对于 AI 生成的测试用例，建议先关注“通过率”而非“完整率”。通常初次生成会有 20-30% 的用例失败，可以通过后续对话或在规则中加入“请确保测试用例能通过实际运行”来修复。4.2 组件测试：UI 组件也能测
代码逻辑做单元测试比较简单，对于 UI 组件能否支持呢？答案是**肯定的**。 引入@testing-library/jest-dom 等测试框架后（工程配置比较麻烦，但不用担心，Cursor 能帮你配好），就能生成不同平台（Web 和 Weex）、不同边界情况下，针对组件元素渲染和交互事件的单元测试了。
```
Spec 组件测试
基础渲染
✓ 应该正确渲染空组件 (10 ms)
✓ 当 hidden 为 true 时不应该渲染 (1 ms)
✓ 当 instanceId 为空时不应该渲染 (1 ms)
✓ 应该正确应用主题色 (8 ms)
组渲染
✓ 应该正确渲染组标题 (4 ms)
✓ 应该隐藏 uigone 为 true 的组 (1 ms)
✓ 应该正确渲染组副标题 (2 ms)
商品项渲染
✓ 应该正确渲染普通商品项（样式0） (1 ms)
✓ 应该隐藏 uigone 为 true 的商品项 (1 ms)
✓ 应该正确渲染带图标的商品项（样式1） (3 ms)
✓ 应该正确渲染横向商品项（样式2） (3 ms)
✓ 应该正确渲染自适应商品项（样式3） (1 ms)
✓ 应该正确渲染图片卡片商品项（样式4） (2 ms)
✓ 应该正确渲染商品状态样式 (2 ms)
✓ 应该正确渲染商品描述和标签 (1 ms)
交互事件
✓ 应该正确处理商品点击事件 (2 ms)
✓ 应该正确处理禁用商品的点击 (1 ms)
✓ 应该正确处理商品添加事件 (2 ms)
✓ 应该正确处理商品删除事件 (1 ms)
✓ 应该正确处理禁用的添加按钮 (1 ms)
✓ 应该正确处理禁用的删除按钮 (2 ms)
展开收起功能
✓ 应该正确处理图片卡片的展开收起 (7 ms)
✓ 应该正确处理组的折叠功能 (1 ms)
✓ 应该正确处理星巴克样式的展开按钮 (1 ms)
价格规则功能
✓ 应该正确处理价格规则点击
✓ 应该正确关闭价格规则弹窗 (1 ms)
子组功能
✓ 应该正确渲染SKU子组 (2 ms)
特殊功能
✓ 应该正确处理必买商品高亮 (1 ms)
✓ 应该正确处理自定义按钮 (1 ms)
✓ 应该正确处理角标遮罩 (1 ms)
边界条件
✓ 应该正确处理缺失的body属性
✓ 应该正确处理空的groups数组 (1 ms)
✓ 应该正确处理无效的themeColor
响应式处理
✓ 应该正确处理窗口大小变化 (1 ms)
```
初次生成后，用例执行通过率大概在 **75%** 左右。除了人工修改，也可以全交给 Cursor 来修复。
```python
执行生成的测试用例，根据结果，首先尝试对用例做调整，然后考虑对组件代码做代码逻辑保护，使得能通过所有测试用例。
```
然后 Cursor 会自动跑命令行执行测试，这里改改那里改改，再跑跑，一般都能通过。
> **常见问题**：组件测试用例生成后通过率较低怎么办？
> **回答**：可以尝试以下步骤：1）检查测试框架配置是否正确（推荐让 Cursor 自动配置）；2）检查 mock 数据是否与实际数据结构一致；3）对组件代码添加类型保护和边界条件处理；4）使用“先调整用例，再保护代码”的策略，让 AI 自我修复。
4.3 沉淀用例规范
同样也可以利用 Agent 来完成这一步，但需要说明清楚**测试范围**和**优先级**。比如本项目就强调以组件测试为主，需要测 Weex 环境兼容性，同时对入口函数做充分性测试。 ```python 阅读test/目录下所有的测试文件，总结归纳一份组件测试用例生成规范，需要包含Weex兼容性测试，以及对入口函数做充分性测试。 ``` ```markdown # React 组件测试用例生成指南 ## 概述 基于项目中 **test/** 目录下所有测试用例的最佳实践分析，本指南提供了完整的 React 组件测试规范，涵盖组件测试、Hook测试、服务层测试、业务逻辑测试等全面的测试策略。 ## 全局测试配置 ### 1. 测试环境设置 ## React 组件测试 ### 1. 基础导入和 Mock 设置 - 基于实际项目模式 ### 2. 环境特定的 Mock #### Web 环境配置 #### Weex 环境配置 ### 3. 组件测试结构 - 基于项目实际模式 ### 4. Weex 环境特定测试 ## Hook 测试模式 ### 1. Hook 测试基础设置 - 基于项目实际 ## 服务层测试模式 ## 业务逻辑测试模式 ### 1. 逻辑引擎测试 ## 主函数入口测试 ## 测试工具函数 ### 1. 测试数据工厂 ## 测试文件命名规范 ### 1. 文件命名模式 ### 2. 测试描述规范 ## 断言模式 ### 1. 基础渲染断言 ### 2. 交互事件断言 ### 3. 异步操作断言 ## 环境兼容性处理 ### 1. 安全的全局对象访问 ## 最佳实践 ### 1. 测试隔离和清理 ### 2. 复杂交互测试 ### 3. 错误场景覆盖 ## 测试覆盖率目标 ## 测试分类和优先级 ### 高优先级测试 ### 中等优先级测试 ### 低优先级测试 ## 持续集成 ## 项目特定的测试模式 ### 1. 组件层级测试结构 ### 2. 业务场景测试 ### 3. 环境适配测试 ``` ---五、实践经验分享：代码智能生产
5.1 多轮对话交互：VibeCoding 的魅力
代码和测试用例用起来都很爽，让我不禁想试试看纯自然语言开发——也就是当下最火的 **VibeCoding**。 耗时 **1 个半小时**，**9 次改动交互**，一行代码都没手写，效果如图所示（红框标记部分）！ 在首次输入规范并提出转译要求实现后，其实已经完成了 90%。 ```python 仿照项目中React组件的实现，把body原生代码转写成react组件，并把组件添加到页面中，传入body数据。 ``` 剩余的对话主要是对 UI 的调整，细节的反复沟通比较费心费力。尝试过导入视觉稿截图，但理解的还是存在偏差。（近期的尝试，这里的解法应该是视觉稿的 MCP 工具，直接对齐视觉元素样式） ```python 组件内的模块样式，左右边距和圆角都翻倍 店铺logo的圆角维持8px，店铺标签上下内边距调整，保证标签内容居中，商品详情标题上下边距加大 店铺logo宽高放大一倍，店铺标签的内边距缩小一些，商品详情的文本改成最多3行展示，点击箭头后全展开。 店铺logo的圆角翻倍，宽高和位置也做翻倍调整，商品详情的文本限制3行无效，得换一种改法 商品详情文本区的展开箭头再放大一点，要求三行省略时文本最后用省略号，点击展开后不再支持收起 ``` 好在这款工具确实能跟上要求，逐步完成改进，最终达到项目要求。 > **小提示**：进行 UI 交互调整时，建议使用“小步快跑”的策略：一次只调整 1-2 个属性，观察效果后再进行下一步，避免 AI 一次性修改过多导致逻辑混乱。5.2 结构化技术系分：从需求到代码的完整链路
有了对话交互的经验，也有了组件测试用例，来试试写个系分做需求吧！ ```markdown 项目名称：标签组件开发需求文档 1. 项目概述 1.1 项目背景 需在现有系统中新增可复用的标签组件，支持动态内容展示 1.2 项目目标 实现可配置化标签组件，满足多场景展示需求 1.3 目标用户 规格面板用户 2. 功能需求 2.1 标签组件核心功能 在头部价格组件中，在 price 和 originalPrice 中间，增加 priceTag 组件。 当 priceTag 和 priceTag.text 不为空时展示，组件内包含一个文本子组件，文本内容为 priceTag.text。 注意要遵守项目中的开发规范要求。 3. 技术规格 - **框架 (Framework)**: React 18.2.0 + TypeScript + Ice.js 3.x - **多平台 (Multi-platform)**: 同时支持 Web 和 Weex - **架构 (Architecture)**: 组件化架构，通过文件级别区分平台 - **样式 (Styling)**: CSS Modules + Less - **状态管理 (State Management)**: React Context + Hook - **构建工具**: Webpack (由 ice.js 封装) - **包管理器**: npm - **数据流**: 基于事件系统的逻辑引擎 4. 组件样式要求 4.1 标签组件样式 组件和子组件样式更新到 index.module.less。 组件为红色圆角box样式，颜色值为#FF4B33，高度24rpx，宽度随内容自适应，圆角6rpx，距左6rpx，内边距左右都为6rpx。 子组件在父组件中居中对齐，文字颜色值为#ffffff，字号18rpx，行高24rpx，不可压缩。 5. 测试用例要求 5.1 Demo页面更新 在demo/index.tsx中新增一个测试按钮，名字为【测试标签】，入口函数填入任意合法的参数，点击后需要mock接口的数据为 src/mock/mockdata.tsx，保证点击后能正确渲染组件，注意这一步不要生成测试用例。 5.2 组件测试用例更新 遵守测试用例规范要求，对本次组件变更生成组件测试用例，更新为 priceTag.test.tsx，并执行通过，如没有通过，先检查测试用例是否正确，再对代码做保护，使得通过测试用例。 ``` 在描述清楚**项目目标、功能需求、技术规格、组件样式要求、测试用例要求**的前提下，Cursor 很好地完成了任务，并自动执行了测试用例。 ``` 价格标签(priceTag)测试 ✓ 应该显示价格标签当priceTag和text存在且不为空时 (1 ms) ✓ 不应该显示价格标签当priceTag为null时 ✓ 不应该显示价格标签当priceTag.text为空字符串时 ✓ 不应该显示价格标签当priceTag.text为null时 (1 ms) ✓ 应该在价格和原价之间正确定位价格标签 (1 ms) ✓ 应该在隐藏价格时不显示价格标签 (1 ms) ✓ 应该支持不同类型的价格标签文本 (2 ms) ✓ 应该正确处理价格标签与券后价同时存在的情况 (1 ms) ✓ 应该正确处理价格标签与价格计算中状态的情况 (1 ms) ``` 看着代码质量还行，测试用例也都通过了，一键提测？**还是先看一眼效果吧。** | 改前 | 改后 | |------|------| | （改前浮层截图） | （改后浮层截图） | Demo 页面正确添加了【测试标签】按钮，但浮层**没有展示**预期的标签【预估到手】。 人工抓个虫：原来子组件本身逻辑没问题，但是**数据传递有问题**——父组件没有把数据给子组件更新。让 Cursor 修一下，搞定提测！ ```python 实际渲染效果并没有展示priceTag组件，应该是父组件并没有传递这个参数，检查下所有父组件传参的逻辑，保证数据正确传递使得组件能正确渲染展示。 ```5.3 系分更要规范
需求系分是最需要规范的。之所以生成与预期不符，比较关键的一步就是**漏了数据参数传递部分**。因此在 Cursor 的帮助下，生成需求系分模版做规范，需要明确以下几个内容： 1. **业务和技术目标**：明确告知需求具体目标，以及需要注意的重点。 2. **技术栈和组件架构**：提供技术背景，利于大模型定位到改动区块。 3. **技术详细设计**：包括核心功能描述，数据结构，样式规范，最好能具体到代码文件路径和具体的样式数值。 4. **开发流程设计**：提供完善的开发流程，组件开发→数据流验证→测试验证。 5. **测试用例设计**：包括代码审查点，测试验证清单，以及验收标准。 ```markdown # 价格标签组件技术系分文档 ## 1. 系统概述 ### 1.1 系统背景 在现有选择器系统中，需要在价格展示区域新增可复用的标签组件，用于展示特殊商品标识。该组件需要支持动态内容展示，并确保在Web和Weex双端环境下的一致性表现。 ### 1.2 业务目标 - 实现可配置化的价格标签组件 - 增强价格信息的可读性和识别度 - 支持多场景下的标签展示需求 ### 1.3 技术目标 - 基于现有组件体系实现标签组件 - 确保组件渲染性能和稳定性 - 实现完整的测试覆盖 - **重点：确保父组件传参逻辑正确，保证数据正确传递使得组件能正确渲染展示** ## 2. 技术架构 ### 2.1 技术栈 #### 核心技术 - **前端框架**: React 18.2.0 + TypeScript 4.x - **构建工具**: Ice.js 3.x - **多端支持**: Web + Weex 双端适配 #### 开发工具链 - **状态管理**: React Context + Hooks - **样式方案**: CSS Modules + Less，支持rpx单位适配 - **代码规范**: ESLint + Prettier + StyleLint - **版本控制**: Git + Husky (Git hooks) - **测试框架**: Jest + React Testing Library ### 2.2 组件架构设计 #### 组件层级结构 #### 数据流向图 ## 3. 详细设计 ### 3.1 核心功能设计 #### 功能描述 在价格组件中，在 `price` 和 `originalPrice` 元素之间插入 `priceTag` 组件。 #### 显示逻辑 - **显示条件**: 当 `priceTag` 对象存在且 `priceTag.text` 不为空时显示 - **显示位置**: price 和 originalPrice 之间 - **显示内容**: priceTag.text 文本内容 #### **重要：父组件传参检查清单** ##### 数据传递链路验证 1. **层级检查** - 确认数据中包含 priceTag 字段 - 验证数据从 Hook 正确传递到页面组件 ##### 数据结构验证 ##### 传参验证检查点 - [ ] 数据中是否正确包含 priceTag 字段 - [ ] 是否正确传递 priceTag 到组件 - [ ] 类型定义是否在所有层级保持一致 - [ ] 默认值处理是否正确 - [ ] 错误边界处理是否完善 ### 3.2 样式设计规范 #### 组件样式要求 #### 样式特性 - **背景色**: #FF4B33 (红色) - **高度**: 24rpx (固定) - **宽度**: 内容自适应 - **圆角**: 6rpx - **边距**: 左边距 6rpx - **内边距**: 左右各 6rpx - **文字**: 白色 #ffffff，18rpx，行高 24rpx - **对齐**: 居中对齐，不可压缩 ### 3.3 组件实现设计 #### 文件结构 #### 组件接口设计 ## 4. 开发实现计划 ### 4.1 实现步骤 #### 第一阶段：组件开发 1. **创建标签组件** - 创建组件 - 实现基础渲染逻辑 - 添加 TypeScript 类型定义 2. **样式实现** - 创建样式文件 - 实现响应式设计 - 确保 Web/Weex 兼容性 3. **集成到价格组件** - 确保 priceTag 数据正确从父组件传递 - 实现条件渲染逻辑 #### 第二阶段：数据流验证 1. **父组件传参检查** - 验证数据类型和结构完整性 2. **类型系统完善** - 更新相关 TypeScript 接口 - 确保类型在整个传递链路中保持一致 - 添加必要的类型保护 #### 第三阶段：测试验证 1. **Mock数据准备** - 确保包含 priceTag 测试数据 - 验证接口数据结构 2. **Demo页面更新** - 在页面添加测试按钮 - 实现"测试标签"测试功能 - 确保组件正确渲染 3. **测试用例开发** - 遵循项目测试规范 - 确保测试覆盖率 ### 4.2 质量保证 #### 代码审查检查点 - [ ] 组件实现符合项目规范 - [ ] **数据传递链路完整无误** - [ ] 样式符合设计要求 - [ ] TypeScript 类型定义完整 - [ ] 测试用例覆盖充分 - [ ] 无 ESLint 错误 - [ ] 性能影响可控 #### 测试验证清单 - [ ] 组件基础渲染测试 - [ ] 条件显示逻辑测试 - [ ] 样式正确性测试 - [ ] **父组件传参正确性测试** - [ ] 边界条件测试 - [ ] Web/Weex 兼容性测试 ## 5. 风险评估与解决方案 ### 5.1 主要风险点 #### 技术风险 1. **数据传递风险** - **风险**: 父组件传参链路中断或数据丢失 - **解决方案**: 在每一层进行数据有效性检查，添加默认值处理 - **监控方案**: 添加详细的开发时日志，便于调试 2. **样式兼容性风险** - **风险**: Weex 环境下样式表现异常 - **解决方案**: 使用项目标准 rpx 单位，进行双端测试 - **监控方案**: 在 CI/CD 中加入样式回归测试 3. **性能影响风险** - **风险**: 新增组件影响页面渲染性能 - **解决方案**: 使用条件渲染，避免不必要的组件实例化 - **监控方案**: 添加性能监控埋点 #### 业务风险 1. **数据格式变更风险** - **风险**: 后端数据结构变化导致组件异常 - **解决方案**: 实现健壮的数据解析和容错机制 - **监控方案**: 添加数据格式验证和异常上报 ### 5.2 应急预案 - 组件渲染异常时的降级策略 - 数据传递失败时的默认展示 - 样式异常时的基础样式保障 ## 6. 验收标准 ### 6.1 功能验收 - [ ] 标签组件能够正确渲染 - [ ] 条件显示逻辑工作正常 - [ ] **父组件数据传递完整正确** - [ ] Demo页面功能正常 - [ ] 测试用例全部通过 ### 6.2 技术验收 - [ ] 代码符合项目规范 - [ ] TypeScript 类型定义完整 - [ ] 样式在双端表现一致 - [ ] 性能影响在可接受范围内 - [ ] 测试覆盖率达标 (≥90%) ### 6.3 质量验收 - [ ] 无 ESLint/StyleLint 错误 - [ ] 代码审查通过 - [ ] 安全扫描通过 - [ ] 兼容性测试通过 ## 7. 后续优化计划 ### 7.1 功能扩展 - 支持更多标签样式配置 - 支持标签点击交互 - 支持多标签显示 ### 7.2 性能优化 - 组件懒加载优化 - 样式计算优化 - 内存使用优化 ### 7.3 维护计划 - 定期进行性能监控 - 持续完善测试用例 - 文档更新维护 --- **重要提醒**: 在整个开发过程中，务必重点关注父组件传参逻辑的正确性，确保 priceTag 数据能够完整、准确地从数据源传递到最终的渲染组件，这是保证功能正常的关键所在。 ``` > **常见问题**：如何编写高质量的系分文档，确保 AI 能正确理解需求？ > **回答**：遵循以下原则：1）每个功能点都要有具体的判断条件（如“当 priceTag 和 priceTag.text 不为空时展示”）；2）样式参数要具体到像素值和颜色值；3）测试验证清单要包含明确的检查项；4）对于容易遗漏的关键点（如数据传递），要单独列出检查清单并在文档中高亮强调。 ---六、总结
本次实践的核心收获是验证并确立了新的开发范式。这个范式是确保高质量工程实践的核心方法论，由**标准的开发规范**、**结构化系分文档**与**完善的测试用例**三者共同构成，缺一不可。 - **开发规范**（如技术栈约束、多平台适配、最优代码实践）为团队提供统一的编码准则，避免技术债务和逻辑冲突。它是 AI 辅助开发的**基石**。 - **结构化系分文档**（如需求目标、开发要求和流程、技术背景说明）则是知识沉淀与协作的基础，帮助开发工具（如 Cursor）生成高质量代码，减少重复试错。它是 AI 准确理解需求的**桥梁**。 - **完善的测试用例**（包括逻辑测试、组件测试）则保障了稳定性和交付质量。它是验证 AI 生成代码正确性的**最后防线**。 三者相辅相成，共同构成可复用、可维护、跨平台兼容的工程体系。正是这套体系的成功实践，才使得在 10 天内完成 3000+ 行复杂组件的跨端复用成为现实。 **最后，给正在探索 AI 辅助开发的团队几点建议：**- 从小处着手：先从逻辑测试、代码转写等简单场景开始，逐步积累 AI 协作经验。
- 重视规则沉淀：将每次调试的经验总结为可执行的规则，实现“规则→生成→修复→更新规则”的良性循环。
- 不迷信 AI 输出：保持人工校验习惯，尤其是数据传递、样式兼容性等关键环节，确保最终质量。
- 关注新范式：积极拥抱“需求交付=开发规则+技术文档+测试用例”的新范式，它将是未来高效开发的核心竞争力。