Kiro 工具实测：前端代码生成验证与调整

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

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: 768
  }
}
// 时间计算常量
export const TIME_CONSTANTS = {
  WEEKS_PER_YEAR: 52,
  DAYS_PER_WEEK: 7,
  MS_PER_DAY: 24 * 60 * 60 * 1000
}
// 本地存储键名
export const STORAGE_KEYS = {
  LIFE_CALENDAR_SETTING_SETTINGS: 'lifeCalendarSettingSettings',
  LIFE_CALENDAR_SETTING_UI_STATE: 'lifeCalendarSettingUIState'
}

页面

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

整体效果

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

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

网格标题显示异常

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

<!-- 行标题 -->
<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 错误特殊处理（用户未设置）
• 网络错误降级到本地存储
• 所有错误都有适当的日志记录
• 不会因为网络问题阻塞用户使用

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

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

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

其他调整

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

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

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

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