摘要：本文探讨了 vibe coding 在评论和互动链路中的实践价值。作者认为，这类边界清晰、闭环完整的小功能（如点赞、收藏、评论审核）特别适合作为 AI 协作开发的样本。文章分析了互动链路的特点：用户效果直观、接口边界清楚、前后端都能落地、易于验证。通过前台互动 API、文章详情页交互逻辑和后台评论管理页的代码示例，展示了如何为 AI 设定清晰的任务边界，避免其跑偏。最后总结了判断功能是否适合交给 AI 的三点标准：输入输出清楚、影响范围可控、改后容易验证。

说到 vibe coding，很多人第一反应是“快速做一个新功能”。
但我自己现在更喜欢把它用在那些边界清楚、闭环完整、前后端都能快速验证的小功能上。

Sourcelin Blog 里的评论、点赞、收藏、关注，就是我最常拿来做 AI 实战样本的一类能力。

我现在越来越觉得，vibe coding 真正好用的场景，不是“大而全”的重构，而是边界清楚、交互明确、前后端都有落点的小闭环功能。

Sourcelin Blog 里，评论、点赞、收藏、关注这类互动链路，就是特别适合拿来做 AI 实战的样本。

为什么我喜欢拿互动链路给 AI 做

因为这类功能同时具备几个特点：

• 用户效果很直观
• 接口边界比较清楚
• 前端和后端都能落到真实文件
• 改完之后很容易验证

而且就算让 AI 参与，也不至于一下子把整个系统带偏。

前台互动 API 已经比较清楚

前台共享互动 API 在：

• sourcelin-ui/sourcelin-ui-platform/src/shared/api/interaction.api.ts

比如点赞接口就是这样：

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

这种能力特别适合让 AI 处理，因为：

• 路径明确
• 参数明确
• 返回明确
• 错误处理也容易统一

前台文章详情页已经把这些能力串起来了

在 useArticleDetail.ts 里，点赞和收藏行为已经被收进交互方法：

const handleLike = async () => {
  if (!isLoggedIn.value) return requireLogin()
  try {
    if (isLiked.value) {
      await unlikeTarget('article', articleId.value)
      ...
      return
    }
    await likeTarget('article', articleId.value)
    ...
  } catch (error) {
    ...
  }
}

这段逻辑为什么适合当文章示例？
因为它能很好地说明一件事：

vibe coding 不是随手让 AI“加个按钮”，而是先把一段交互链路的边界描述清楚，再让它补完。

后台评论管理也很适合拿来讲

后台评论页在：

• sourcelin-ui/sourcelin-ui-admin/src/views/blog/comment/index.vue

它已经把评论审核、来源筛选和共享壳结合起来了：

<ModuleListShell
  title="评论管理"
  description="评论审核、来源追踪与删除治理。"
  :module-api="CommentAPI"
  :query-fields="queryFields"
  :columns="columns"
  :form-fields="formFields"
  :row-actions="rowActions"
/>

这类页面也很适合用来说明：
AI 不一定非要从零生成一个复杂页面，完全可以在既有壳上做一轮“有边界的扩展”。

Vibe Coding 任务流程

下图展示了为一个互动链路功能（如点赞）进行 vibe coding 的典型流程：

我一般怎么给 AI 下这类 vibe coding 任务

请基于 Sourcelin Blog 现有互动链路完成一个小闭环功能。
要求：
1. 优先复用现有 API、composable 和共享壳
2. 只处理一个目标能力，例如点赞、收藏、评论审核或关注
3. 前台和后台各自遵守既有目录边界
4. 不要顺手重构无关页面
5. 修改后给出验证点

我个人判断“这类功能适不适合交给 AI”的标准

下图总结了判断一个功能是否适合交给 AI 进行 vibe coding 的决策标准：

我通常看这三点：

1. 输入输出是不是清楚
2. 影响范围是不是可控
3. 改完之后是不是容易验证

评论和互动功能大多满足这三点，所以特别适合做系列文章里的 AI 示例。

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

• 一次碰太多交互点
• 顺手改掉页面结构
• 把登录校验和业务交互混成一坨
• 没有把失败提示和通用错误处理分层

我现在更愿意把 vibe coding 理解成一种“选择题”：
不是所有任务都适合，但互动链路这种边界清楚的小闭环，确实很适合拿来跑出效果，也很适合写成别人愿意读完的实战文章。

项目地址

• 在线演示：https://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 支持一下。