规范驱动编程：AI 工具 Kiro 前端验证及调整实测

接下来看一下前端的代码输出。

前端结构

前端生成的位置经过指令指示，要求放到已有的工具模块下，生成的位置是准确的，如下：

文章配图

API

前后端交互的 API，AI 并没有参照项目现有情况，根据自行生成了一套跟后端自己设计的接口一致的 API，如下：

import { COMMON_METHOD } from '@/constant/common'
import request from '@/config/axios'
import type { LifeSettingsRequest, LifeSettingsResponse, ApiResponse } from '../view/lifeCalendar/types'

const moduleName = 'tool'

// 生命日历设置 API
export const lifeCalendarSettingApi = {
  /**
   * 获取用户生命日历设置
   */
  getSettings(): Promise<ApiResponse<LifeSettingsResponse>> {
    return request.get({
      url: `/${moduleName}/lifeCalendarSetting/settings`
    })
  },
  /**
   * 保存用户生命日历设置
   */
  saveSettings(data: LifeSettingsRequest): Promise<ApiResponse<LifeSettingsResponse>> {
    return request.post({
      url: `/${moduleName}/lifeCalendarSetting/settings`,
      data
    })
  },
  /**
   * 更新用户生命日历设置
   */
  updateSettings(data: Partial<LifeSettingsRequest>): Promise<ApiResponse<LifeSettingsResponse>> {
    return request.put({
      url: `/${moduleName}/lifeCalendarSetting/settings`,
      data
    })
  }
}

我手工调整回统一规范与风格，如下：

import { COMMON_METHOD } from '@/constant/common'
import request from '@/config/axios'

const moduleName = 'tool'

// 配置
export const lifeCalendarSetting = Object.assign({}, COMMON_METHOD, {
  serveUrl: '/' + moduleName + '/' + 'lifeCalendarSetting' + '/',
  // 获取配置
  getMyConfig() {
    return request.get({
      url: this.serveUrl + 'getMyConfig'
    })
  }
})

常量

Kiro 在常量文件中定义了一堆，目前看上去还正常，先放在这里，待结合功能再看是否有不合理的地方，如下：

// 生命日历设置相关常量
export const LIFE_CALENDAR_SETTING = {
  // 网格配置
  GRID: {
    ROWS: 80, // 80 年
    COLS: 52, // 52 周
    TOTAL_CELLS: 4160, // 总格子数
    CELL_SIZE: 8, // 基础格子大小（像素）
    CELL_SPACING: 1 // 格子间距（像素）
  },
  // 缩放配置
  ZOOM: {
    MIN: 0.5,
    MAX: 3.0,
    DEFAULT: 1.0,
    STEP: 0.2
  },
  // 颜色配置
  COLORS: {
    LIVED: '#606266', // 已过时间 - 深灰色
    CURRENT: '#f56c6c', // 当前周 - 红色
    FUTURE: '#f0f0f0', // 未来时间 - 浅灰色
    BORDER: '#e0e0e0' // 边框颜色
  },
  // 预期寿命范围
  LIFESPAN: {
    MIN: 60,
    MAX: 150,
    DEFAULT: 80
  },
  // 响应式断点
  BREAKPOINTS: {
    SMALL_SCREEN: 
  }
}


   = {
  : ,
  : ,
  :  *  *  * 
}


   = {
  : ,
  : 
}

页面

接下来就是关键的页面了，看代码结构，采用了组件化策略，分为上中下三个区域，上面是进度展示组件，中间是网格组件，下方是设置组件，最后用一个组件组装起来，整个拆分是规范合理的。

整体效果

我将路由和权限配置好，挺顺利地展示出来了，超出预期，直接看看页面效果吧。

文章配图

虽然中间区域网格显示有点问题，但整体上美观大方，尝试修改了下出生日期和预期寿命，功能看上去也是正常的。

网格标题显示异常

人工看了下行列的显示问题，逻辑如下：

<!-- 行标题 -->
<div class="row-headers" v-if="showRowHeaders">
  <div v-for="(header, index) in rowHeaders" :key="`row-${index}`" class="row-header" :style="getRowHeaderStyle(index)">{{ header }}</div>
</div>

/**
 * 生成简化的行标题（每 5 年显示一次）
 * 用于小屏设备或缩小视图
 * @returns 简化的行标题数组
 */
public generateSimplifiedRowHeaders(): Array<{ index: number; label: string }> {
  const headers: Array<{ index: number; label: string }> = []
  for (let i = 0; i < GridService.TOTAL_ROWS; i += 5) {
    headers.push({
      index: i,
      label: `${i + 1}`
    })
  }
  return headers
}

header 里放了一个对象，包括索引和标签，显示为行标题的时候，应该显示标签而不是整个对象，因此，把 {{ header }} 更改为 {{ header.label }} 就可以了，修改后效果图正常了，如下：

文章配图

鼠标悬浮位置偏移

这里有个明显的问题，鼠标悬浮的时候，显示当前人生的第几年和第几周，其位置并没有跟随鼠标，而是偏移了很大一块，甚至于在屏幕之外，这问题让 Kiro 来解决吧。

文章配图

消耗一个点，用时 1 分钟，但经测试，没有效果，于是给了 Kiro 一张截图用来排查和修正。

文章配图

经测试，还是没用。

文章配图

这个思考过程很像人了，发现中间步骤错了，再撤销~

这次总算测试效果通过了，如下图：

文章配图

总共进行了 3 轮修复，每次消耗 1 点，约 1 分钟，问题算是彻底解决了。

周次计算问题

当前时间是 2026 年的 2 月 9 号，是第 7 周，但显示是第 28 周，看上去明显是有问题的，继续把问题抛给 Kiro。

文章配图

Kiro 的思考过程显示，计算方法本身其实没有错，而是计算规则问题，当前是从出生日期开始算总天数，然后除以 52，我自己思考了下，通常 1 年 52 周，实际是 364 天，而不是 365 天，这样 7 年就能差出一周来，而且四年一个闰年，又多 1 天，以 1982 年 10 月 3 日计算，可能偏移量是 9 个周左右，但是从第 7 周偏移到第 28 周，粗略估算还是不太对啊。

问题抛给 Kiro，然后给了修复，同时显示两种信息，如下图：

文章配图

这问题消耗了 2.67 个点，真不小~

然后找了个简单的数据验证数据的正确性，将生日设置为了 2026 年的 1 月 1 日，计算结果如下：

文章配图

看上去是正确的。

但是把自己的生日代入进去，计算结果还是怪怪的，因此询问 Kiro 计算过程：

如果是 1982 年 10 月 3 日出生，到今天 2026 年 2 月 10 日，实际不到 44 周岁，显示人生第 44 年第 28 周是如何算出来的

文章配图

调整后的结果是：

文章配图

虽然不满 44 周岁，但是按照 1982 年视为第 1 年也没问题，然后除以整年后，剩余的作为周数，约等于从上一个生日即 2025 年 10 月 3 日到现在 2026 年 2 月 10 日，是 19 个周左右，这个结果是看上去比较自然的。同理，上图中的年度进度，也是 19 除以 52，大概得出 36% 的数据，而不是当前是 2026 年的第 7 个周，用 7 除以 52 得到的结果。

后端交互

页面基本调试完成了，再来处理与后端交互，当前 Kiro 生成的与后端交互都是按照先前的逻辑，需要调整为与风格一致的，还得编写一个比较复杂的提示词告诉 Kiro 怎么做。

文章配图

后端交互问题修复总结

主要改进正确使用 COMMON_METHOD 的增删改查方法 ✅

首次保存：使用 lifeCalendarSetting.add() 方法新增记录

后续修改：使用 lifeCalendarSetting.modify() 方法更新记录

获取配置：使用 lifeCalendarSetting.getMyConfig() 方法获取用户配置完善的数据流程 ✅

初始化流程：

调用 getMyConfig() 尝试从后端获取配置

如果返回 404（未找到），尝试从本地存储加载

如果都没有，显示空状态，等待用户设置

保存流程：

判断是否为新记录（通过 id 字段判断）

新记录调用 add() 方法

已有记录调用 modify() 方法

保存成功后同步到本地存储

如果网络失败，使用本地存储作为备份本地缓存同步 ✅

从后端加载成功后，自动保存到本地存储

保存到后端成功后，同步更新本地存储

网络失败时，使用本地存储作为降级方案

记录离线变更，便于后续同步类型定义完善 ✅

在 LifeSettingsResponse 中添加可选的 id 字段

用于区分新增和修改操作错误处理优化 ✅

404 错误特殊处理（用户未设置）

网络错误降级到本地存储

所有错误都有适当的日志记录

不会因为网络问题阻塞用户使用

数据流程图

用户首次访问

调用 getMyConfig()

返回 404 → 尝试本地存储 → 无数据 → 显示空状态

用户设置生日和预期寿命

调用 add() 新增 → 保存到本地存储

后续修改

调用 modify() 更新 → 同步到本地存储

现在生命日历功能的后端交互已经完全符合项目规范，支持离线使用和数据同步！

然后测试发现前后端的字段名对应错了，让其修正：

文章配图

单次花费 3.6 个点，比预期的多。

其他调整

最后，又人工调整了一下小问题，比如把不合适的 card 卡片标题'人生日历设置'删掉，清理点击单元格的 console.log 输出，预期寿命从 60~150 调整为 1-130 等。

并且让 Kiro 把生命网格悬浮的时候，增加日历年显示，如下图：

文章配图

此外，测试发现生命网格固定显示 80 年，应根据用户设置动态调整，如下：

文章配图

这任务居然消耗了 6 个多点，调整后效果如下：

文章配图

规范驱动编程：AI 工具 Kiro 前端验证及调整实测

前端结构

API

常量

页面

整体效果

网格标题显示异常

鼠标悬浮位置偏移

周次计算问题

后端交互

其他调整

更多推荐文章

相关免费在线工具

规范驱动编程：AI 工具 Kiro 前端验证及调整实测

前端结构

API

常量

页面

整体效果

网格标题显示异常

鼠标悬浮位置偏移

周次计算问题

后端交互

其他调整

微信扫一扫，关注极客日志

更多推荐文章

相关免费在线工具