摘要本文基于 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/*.tsAPIsrc/modules/**/api/*.api.ts也就是说页面文件本身不应该承载大段请求和状态编排。文章详情这块是一个很好的 AI 实战样本前台文章相关目录在sourcelin-ui/sourcelin-ui-platform/src/modules/article/api/article.api.tssourcelin-ui/sourcelin-ui-platform/src/modules/article/composables/useArticleDetail.tssourcelin-ui/sourcelin-ui-platform/src/modules/article/pages/ArticlePage.vueAPI 层这段写法就很稳exportfunctiongetArticleDetail(id:number){returnrequestDataArticleDetail({url:/front/articles/${id},method:get})}它做的事情很单纯对齐接口路径声明返回类型不掺 UI 状态真正复杂的逻辑被放到了 composableuseArticleDetail.ts里处理的是页面状态、点赞、收藏、关注、目录、分享这些行为constreloadasync(){if(!articleId.value)returnloading.valuetrueerror.valuetry{constpayloadawaitgetArticleDetail(articleId.value)article.value{...payload,isCollected:toBoolean(payload.isCollected),isFollowed:toBoolean(payload.isFollowed),followId:toNumber(payload.followId)||undefined,isLike:toBoolean(payload.isLike)}...}finally{loading.valuefalse}}这就是我现在特别喜欢让 AI 学的一种前台结构页面做装配API 做数据入口composable 收复杂状态我一般怎么给 AI 提这种任务请在博客前台 article 模块中实现或调整某个页面功能。 要求 1. 页面放在 pages 2. 组件放在 components 3. 请求和状态逻辑拆到 composables 4. API 放到对应 *.api.ts 文件 5. 页面不要直接写大段异步请求编排 6. 保持现有主题和 S* UI 抽象体系我自己更推荐的改法第一步先让 AI 看同类页面例如文章详情、标签页、分类页。不要让它凭空发挥。第二步这轮只碰一个页面边界比如只改文章详情交互只改文章列表分页只改标签页查询第三步先拆逻辑再补展示这一步很关键。一上来就让 AI 优化模板最后容易把请求、状态、展示糊成一层。一段很适合拿去讲的真实链路比如点赞和收藏在前台共享 API 里已经收成了单独能力exportfunctionlikeTarget(targetType:InteractionTargetType,targetId:number){returnrequestDatavoid({url:/front/interactions/likes/${targetType}/${targetId},method:put})}这类能力很适合做 AI Coding 示例因为它边界清楚、效果直观、又不会大到失控。这类任务里 AI 最容易跑偏的点把请求直接写进页面在页面里顺手做太多状态转换跳过类型定义直接返回any直接在业务组件里用 Naive UI 原子组件绕开现有抽象我现在越来越觉得前台这类任务不是不能 vibe coding而是得先把边界搭好。边界清楚之后AI 的速度和效果其实都很好这也是我愿意把这类经验整理成系列文章的原因。项目地址在线演示http://sourcelin.cnGiteehttps://gitee.com/my_lyq/sourcelin-cloud-blogGitHubhttps://github.com/SourceLin/sourcelin-cloud-blog如果你刚好在找一个微服务博客系统Spring Cloud Alibaba 实战项目Vue 3 Java 全栈项目毕设 / 课程设计参考项目支持 AI 协作开发的开源仓库可以看一下这个项目。欢迎试用、提 Issue也欢迎点个 Star 支持一下。
我怎么用 AI 改前台文章详情和列表能力，而不是把页面越改越乱
发布时间：2026/5/21 18:48:24
摘要本文基于 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/*.tsAPIsrc/modules/**/api/*.api.ts也就是说页面文件本身不应该承载大段请求和状态编排。文章详情这块是一个很好的 AI 实战样本前台文章相关目录在sourcelin-ui/sourcelin-ui-platform/src/modules/article/api/article.api.tssourcelin-ui/sourcelin-ui-platform/src/modules/article/composables/useArticleDetail.tssourcelin-ui/sourcelin-ui-platform/src/modules/article/pages/ArticlePage.vueAPI 层这段写法就很稳exportfunctiongetArticleDetail(id:number){returnrequestDataArticleDetail({url:/front/articles/${id},method:get})}它做的事情很单纯对齐接口路径声明返回类型不掺 UI 状态真正复杂的逻辑被放到了 composableuseArticleDetail.ts里处理的是页面状态、点赞、收藏、关注、目录、分享这些行为constreloadasync(){if(!articleId.value)returnloading.valuetrueerror.valuetry{constpayloadawaitgetArticleDetail(articleId.value)article.value{...payload,isCollected:toBoolean(payload.isCollected),isFollowed:toBoolean(payload.isFollowed),followId:toNumber(payload.followId)||undefined,isLike:toBoolean(payload.isLike)}...}finally{loading.valuefalse}}这就是我现在特别喜欢让 AI 学的一种前台结构页面做装配API 做数据入口composable 收复杂状态我一般怎么给 AI 提这种任务请在博客前台 article 模块中实现或调整某个页面功能。 要求 1. 页面放在 pages 2. 组件放在 components 3. 请求和状态逻辑拆到 composables 4. API 放到对应 *.api.ts 文件 5. 页面不要直接写大段异步请求编排 6. 保持现有主题和 S* UI 抽象体系我自己更推荐的改法第一步先让 AI 看同类页面例如文章详情、标签页、分类页。不要让它凭空发挥。第二步这轮只碰一个页面边界比如只改文章详情交互只改文章列表分页只改标签页查询第三步先拆逻辑再补展示这一步很关键。一上来就让 AI 优化模板最后容易把请求、状态、展示糊成一层。一段很适合拿去讲的真实链路比如点赞和收藏在前台共享 API 里已经收成了单独能力exportfunctionlikeTarget(targetType:InteractionTargetType,targetId:number){returnrequestDatavoid({url:/front/interactions/likes/${targetType}/${targetId},method:put})}这类能力很适合做 AI Coding 示例因为它边界清楚、效果直观、又不会大到失控。这类任务里 AI 最容易跑偏的点把请求直接写进页面在页面里顺手做太多状态转换跳过类型定义直接返回any直接在业务组件里用 Naive UI 原子组件绕开现有抽象我现在越来越觉得前台这类任务不是不能 vibe coding而是得先把边界搭好。边界清楚之后AI 的速度和效果其实都很好这也是我愿意把这类经验整理成系列文章的原因。项目地址在线演示http://sourcelin.cnGiteehttps://gitee.com/my_lyq/sourcelin-cloud-blogGitHubhttps://github.com/SourceLin/sourcelin-cloud-blog如果你刚好在找一个微服务博客系统Spring Cloud Alibaba 实战项目Vue 3 Java 全栈项目毕设 / 课程设计参考项目支持 AI 协作开发的开源仓库可以看一下这个项目。欢迎试用、提 Issue也欢迎点个 Star 支持一下。
