摘要：本文基于 Sourcelin Blog 前台开发实践，探讨前端项目中如何有效利用 AI 辅助编码。核心观点是：前端并非不能交给 AI，关键在于先明确架构边界——页面、组件、API、composable 各司其职。文章以文章详情模块为例，展示了 API 层保持纯粹、composable 收拢复杂状态、页面仅负责装配的理想结构，并分享了给 AI 提需求的具体方法、推荐的分步改造流程，以及 AI 在实际编码中最容易跑偏的常见问题。清晰的边界划分能让 AI 在前端开发中既高效又可控。

前端是最容易让人误判 AI 能力的地方。
因为它往往改完就能看到效果，所以很多人很自然会觉得：页面类工作最适合交给 AI。

但我在 Sourcelin Blog 里做前台时，后面越来越明确一件事：
前台不是不能让 AI 接手，而是一定要先把页面、组件、API、composable 的边界分清楚。

前端最容易给人一种错觉：看起来简单，改起来也最快。

但我在 Sourcelin Blog 里做前台时，后面越来越明确一件事：
前端如果一开始不把页面、组件、API、composable 分清楚，AI 连做几轮之后，结构会比后端更容易发散。

这个项目前台怎么拆，其实已经写在规则里了

博客前台目录边界是：

• 页面：src/modules/**/pages/*.vue
• 组件：src/modules/**/components/*.vue
• 逻辑：src/modules/**/composables/*.ts
• API：src/modules/**/api/*.api.ts

也就是说，页面文件本身不应该承载大段请求和状态编排。

文章详情这块，是一个很好的 AI 实战样本

前台文章相关目录在：

• sourcelin-ui/sourcelin-ui-platform/src/modules/article/api/article.api.ts
• sourcelin-ui/sourcelin-ui-platform/src/modules/article/composables/useArticleDetail.ts
• sourcelin-ui/sourcelin-ui-platform/src/modules/article/pages/ArticlePage.vue

API 层这段写法就很稳：

export function getArticleDetail(id: number) {
  return requestData<ArticleDetail>({
    url: `/front/articles/${id}`,
    method: 'get'
  })
}

它做的事情很单纯：

• 对齐接口路径
• 声明返回类型
• 不掺 UI 状态

真正复杂的逻辑，被放到了 composable

useArticleDetail.ts 里处理的是页面状态、点赞、收藏、关注、目录、分享这些行为：

const reload = async () => {
  if (!articleId.value) return
  loading.value = true
  error.value = ''
  try {
    const payload = await getArticleDetail(articleId.value)
    article.value = {
      ...payload,
      isCollected: toBoolean(payload.isCollected),
      isFollowed: toBoolean(payload.isFollowed),
      followId: toNumber(payload.followId) || undefined,
      isLike: toBoolean(payload.isLike)
    }
    ...
  } finally {
    loading.value = false
  }
}

这就是我现在特别喜欢让 AI 学的一种前台结构：

• 页面做装配
• API 做数据入口
• composable 收复杂状态

我一般怎么给 AI 提这种任务

请在博客前台 article 模块中实现或调整某个页面功能。
要求：
1. 页面放在 pages
2. 组件放在 components
3. 请求和状态逻辑拆到 composables
4. API 放到对应 *.api.ts 文件
5. 页面不要直接写大段异步请求编排
6. 保持现有主题和 S* UI 抽象体系

我自己更推荐的改法

第一步：先让 AI 看同类页面

例如文章详情、标签页、分类页。
不要让它凭空发挥。

第二步：这轮只碰一个页面边界

比如：

• 只改文章详情交互
• 只改文章列表分页
• 只改标签页查询

第三步：先拆逻辑，再补展示

这一步很关键。
一上来就让 AI 优化模板，最后容易把请求、状态、展示糊成一层。

一段很适合拿去讲的真实链路

比如点赞和收藏，在前台共享 API 里已经收成了单独能力：

export function likeTarget(targetType: InteractionTargetType, targetId: number) {
  return requestData<void>({
    url: `/front/interactions/likes/${targetType}/${targetId}`,
    method: 'put'
  })
}

这类能力很适合做 AI Coding 示例，因为它边界清楚、效果直观、又不会大到失控。

这类任务里 AI 最容易跑偏的点

• 把请求直接写进页面
• 在页面里顺手做太多状态转换
• 跳过类型定义直接返回 any
• 直接在业务组件里用 Naive UI 原子组件，绕开现有抽象

我现在越来越觉得，前台这类任务不是不能 vibe coding，而是得先把边界搭好。
边界清楚之后，AI 的速度和效果其实都很好，这也是我愿意把这类经验整理成系列文章的原因。

项目地址

• 在线演示：http://sourcelin.cn
• Gitee：https://gitee.com/my_lyq/sourcelin-cloud-blog
• GitHub：https://github.com/SourceLin/sourcelin-cloud-blog

如果你刚好在找一个：

• 微服务博客系统
• Spring Cloud Alibaba 实战项目
• Vue 3 + Java 全栈项目
• 毕设 / 课程设计参考项目
• 支持 AI 协作开发的开源仓库

可以看一下这个项目。欢迎试用、提 Issue，也欢迎点个 Star 支持一下。