CodeArts + AI 编程：把前端重复劳动交给流水线的四步实战

前端团队的时间大部分不是花在"写业务逻辑"上，而是花在重复动作上：复制一个 CRUD 页面改字段、对齐设计稿的间距、补一堆没人看的单测、在 Code Review 里反复指出同一个规范问题。

这些工作有个共同点——规律性极强、上下文明确、容错成本低。这正是 AI 辅助编程最擅长的地方。但直接把 AI 当成"自动补全工具"，收益往往停留在个人效率层面，很难沉淀成团队能力。

这篇文章记录我用华为云 CodeArts 把 AI 编程接入工程流程的四个步骤：模板化、生成、门禁、度量。核心思路是：AI 负责产出"有规律的部分"，流水线负责守住"不能破的底线"。

一、为什么"Copilot 式使用"不够

大多数团队的 AI 编程现状是这样的：

• 每个人各自开各自的 AI 插件，模型版本、提示词习惯、使用深度完全不同
• 生成的代码直接提交，没人 review 生成过程，只 review 结果
• 一旦模型升级或换了工具，之前积累的"手感"全部归零
• 没有任何数据能回答"AI 到底帮我们省了多少时间"

换句话说，AI 能力停留在个人层面，没有变成工程资产。要改变这一点，得让 AI 的输出进入一条可复现、可校验的流水线。

二、方案全景

我把整个链路拆成四层，CodeArts 各服务的位置如下：

需求/设计稿  →  [模板仓库 Repo]  →  [AI 生成 + 人工校验]
                                        ↓
                                  [CodeArts Check 门禁]
                                        ↓
                                  [Pipeline 构建/单测]
                                        ↓
                                  [Artifact 制品 + 度量报表]

• CodeArts Repo：存放脚手架模板与代码规范配置，作为 AI 生成的"上下文基线"
• CodeArts Snap（智能开发助手）：代码生成、单测生成、代码解释、注释补全
• CodeArts Check：静态检查门禁，拦截 AI 生成的高频问题
• CodeArts Pipeline：把检查、构建、单测串成一条必过流水线

关键点：模板仓库不是给人看的，是给 AI 看的。目录结构、命名约定、请求封装、错误处理范式，写得越清楚，生成质量越高。

三、步骤一：把规范写成 AI 能读的模板

传统前端脚手架只解决"项目初始化"，我把它扩展到"页面级初始化"。

以列表页为例，模板仓库里放一份完整可运行的参考实现：

src/
├── api/
│   └── user.ts              # 请求函数：统一走 request 封装，禁止裸 fetch
├── hooks/
│   └── useTable.ts          # 分页/筛选/loading 的公共逻辑
├── pages/
│   └── user-list/
│       ├── index.tsx        # 页面骨架
│       ├── columns.ts       # 表格列定义
│       └── schema.ts        # 表单校验规则

同时在仓库根目录放一份 AI-CONTEXT.md，用直白的话告诉 AI 这个项目的约定：

# 项目约定（给 AI 阅读）

## 技术栈
- React 18 + TypeScript 5 + Vite
- 状态管理：Zustand（禁止引入 Redux）
- 样式：CSS Modules（禁止新增全局样式）

## 硬性规则
1. 所有接口调用必须走 `src/api/*`，页面里禁止出现 URL 字符串
2. 列表页必须复用 `useTable` hook，不允许自己写分页逻辑
3. 时间格式化统一使用 `src/utils/date.ts` 中的 `formatDate`
4. 不允许生成 any，不允许写 `// @ts-ignore`

## 命名约定
- 组件文件使用大驼峰，工具函数使用小驼峰
- 事件处理函数统一 `handleXxx` 前缀

这份文件的作用比想象中大。实测下来，把"禁止项"写清楚之后，AI 生成代码被静态检查拦下的比例明显下降——因为它知道边界在哪。

四、步骤二：AI 生成 + 结构化校验

有了模板和上下文，生成一个 CRUD 页面就变成一次有约束的对话。我给 CodeArts Snap 的提示词模板长这样：

参考 src/pages/user-list 的实现方式，生成 src/pages/order-list。

接口定义：
GET  /api/order/list?page&size&keyword  → { list: OrderItem[], total: number }
POST /api/order/update                  → { code, msg }

字段：id, orderNo, customerName, amount, status(0待付款/1已付款/2已关闭), createTime

要求：
1. 复用 useTable hook
2. 状态用 Tag 组件展示，按 status 映射颜色
3. 金额列右对齐，保留两位小数
4. 生成后补一份对应的单测，覆盖分页和筛选

值得强调的是校验清单。AI 生成完之后，我不看代码，先跑三件事：

# 1. 类型检查
npx tsc --noEmit

# 2. 规范检查
npx eslint src/pages/order-list --max-warnings 0

# 3. 单测
npx vitest run src/pages/order-list

三关全过再看代码逻辑，效率比肉眼逐行 review 高得多。这一步的本质是：把 AI 的"幻觉"交给机器去发现，把人的注意力留给业务正确性。

五、步骤三：把校验做成流水线门禁

本地跑三件套靠自觉，团队层面必须固化。CodeArts Pipeline 的配置大致如下（示意）：

version: 2.0
stages:
  - name: 代码检查
    jobs:
      - name: Check
        steps:
          - uses: codearts/check
            with:
              language: nodejs
              failOnError: true

  - name: 构建与测试
    jobs:
      - name: Build
        steps:
          - uses: codearts/build
            with:
              command: |
                npm ci
                npm run build
                npm run test:ci

这里有两个细节值得注意：

1. failOnError: true 必须开。AI 生成的代码问题集中在几个固定类型：未处理的 Promise、缺失的 loading 状态、useEffect 依赖数组不全。这些恰好是静态检查能抓的。
2. 单测覆盖率卡在增量而非全量。AI 生成单测很容易凑数量，卡全量覆盖率只会让它写无意义的断言；卡增量覆盖率（新增代码 ≥ 60%）更有效。

六、步骤四：用数据回答"AI 值不值"

没有度量的改进都是玄学。我关注三个指标：

第三个指标最值得关注，但也要看清楚它的边界：缩短的是**“从零到能跑"这一段，而需求澄清和前后端联调的时间几乎没有变化**。这一点必须提前跟业务方对齐预期，否则很容易被误认为"AI 能压缩整个交付周期”，最后反而让团队背锅。

另外提醒一句：度量指标别搞得太复杂，两三个能自动采集的就够了。指标一旦需要人工统计，三个月后必然荒废。

七、四个踩过的坑

坑一：AI 会自己"发明"接口字段。
生成的代码里出现了后端从未定义的字段名，而且看起来非常合理。对策：把接口定义（哪怕是 Swagger 片段）原文贴进提示词，不要用自然语言描述。

坑二：依赖版本幻觉。
AI 给出的第三方库版本号经常不存在，或者用法是旧版本的。对策：模板仓库锁死依赖版本，提示词里明确"只使用 package.json 中已存在的依赖"。

坑三：安全问题被生成代码带进来。
最典型的是把用户输入直接拼进 innerHTML、把 token 打在日志里。对策：把这类规则写进 CodeArts Check 的自定义规则集，让它成为硬门禁，而不是靠人记。

坑四：团队对"AI 写的代码"有心理抵触。
老同学会觉得 review 一遍比自己写还累。对策：先从单测生成和注释补全这类低风险场景切入，让大家先尝到甜头，再推进到业务代码生成。

八、小结

把 AI 编程接进 CodeArts 流水线之后，最大的变化不是"写得更快"，而是团队对代码质量的底线从"人的自觉"变成了"流水线的硬约束"。

AI 的产出质量取决于两个东西：喂给它的上下文，和校验它的机制。前者靠模板仓库，后者靠流水线门禁。这两件事做好，AI 才真正从"个人外挂"变成"团队基础设施"。

下一步我打算试试把设计稿转代码这一步也接进去，用视觉模型识别组件结构，再用同一套模板约束生成。如果跑通了再写一篇。

本文为个人工程实践记录，涉及的产品能力以华为云 CodeArts 官方文档为准。