规范驱动编程系列——亚马逊AI编程工具Kiro工具实测6——前端验证及调整
接下来看一下前端的代码输出。
前端结构
前端生成的位置经过指令指示，要求放到已有的工具模块下，生成的位置是准确的，如下：
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'// 生命日历设置APIexportconst 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'// 配置exportconst lifeCalendarSetting = Object.assign({},COMMON_METHOD,{serveUrl:'/'+ moduleName +'/'+'lifeCalendarSetting'+'/',// 获取配置getMyConfig(){return request.get({url:this.serveUrl +'getMyConfig'})}})常量
kiro 在常量文件中定义了一堆，目前看上去还正常，先放在这里，待结合功能再看是否有不合理的地方，如下：
// 生命日历设置相关常量exportconstLIFE_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}}// 时间计算常量exportconstTIME_CONSTANTS={WEEKS_PER_YEAR:52,DAYS_PER_WEEK:7,MS_PER_DAY:24*60*60*1000}// 本地存储键名exportconstSTORAGE_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 简化的行标题数组 */publicgenerateSimplifiedRowHeaders(): Array<{index: number; label: string }>{constheaders: 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() 更新 → 同步到本地存储
现在生命日历功能的后端交互已经完全符合项目规范，支持离线使用和数据同步！
Credits used: 3.42
Elapsed time: 2m 48s
然后测试发现前后端的字段名对应错了，让其修正：
单次花费 3.6 个点，比预期的多。
其他调整
最后，又人工调整了一下小问题，比如把不合适的 card 卡片标题“人生日历设置”删掉，清理点击单元格的 console.log 输出，预期寿命从 60~150 调整为 1-130 等。
并且让 kiro 把生命网格悬浮的时候，增加日历年显示，如下图：
此外，测试发现生命网格固定显示 80 年，应根据用户设置动态调整，如下：
这任务居然消耗了 6 个多点，调整后效果如下：
