Appearance
Vibe 编程不只是快速生成新功能，定期重构同样关键。本节通过一个游戏项目中的交互提示组件（interact-prompt）为例，演示如何让 Kiro 识别跨多个 Vue 组件的重复实现，并将其提取为统一的共享组件。你将学到：AI 会按照你给的示例上下文实现方案，因此容易产生重复代码；主动用自然语言提示 Kiro 进行 DRY 重构；以及如何验证重构后样式和布局差异是否被正确保留。
重构是 Vibe 编程的另一半
本节假设你已完成前置模块的本地启动。在此之前，我们依次完成了：
现在来聊一个 Vibe 编程中被低估的真相：如果你一半以上的 prompt 不是在做"Vibe 重构"，那你很可能已经在积累技术债。
理解问题
AI 非常擅长根据示例上下文生成新代码，但这个优势也带来一个副作用——它往往会复制已有的实现方式，导致代码重复。
先问问 Kiro 实际情况：
Where is the interact prompt implemented in the components?Kiro 会找到多个文件中类似的 interact-prompt 实现：
The interact prompt is consistently implemented across multiple interactive game objects (Computer, Workbench, Chest, Garbage, GameItem, PullLever, Dispenser)
打开 Computer.vue、Workbench.vue、Chest.vue 等文件，你会发现每个组件都有一套高度相似的 interact-prompt 实现和 CSS 样式。
但仔细观察游戏里的实际表现，会发现细微差异：拉杆（PullLever）的提示框尺寸和工作台（Workbench）的不完全一样。这正是没有统一组件时的典型问题。
执行重构
打开一个含有 interact-prompt 的文件，例如 Chest.vue，然后向 Kiro 发出重构指令：
I want to DRY the "interact-prompt" into a separate component
with standardized styles, reused across my componentsKiro 会自动扫描所有含有 interact-prompt 的组件，并将其重构为引用统一的共享组件。
验证结果
重构后需要重点检查：
- 定位方式是否保留：原始实现中，各组件的 interact-prompt 相对父元素的位置各不相同（上方、左侧、右侧等），重构后是否还正确？
- 响应式字体方案：原来有两种不同的方式来保证提示文字在不同屏幕尺寸下显示合理，AI 最终采用了哪种？
主动寻找更多重构机会
尝试向 Kiro 提问：
Look through my components. Do you see any things that should
be refactored or opportunities to implement best practices?AI 不会主动反驳你的需求，但这不代表它看不到代码中的问题。你只需要主动询问，它就会把发现告诉你。
本节小结
- Vibe 编程需要定期"Vibe 重构"，就像传统编程一样——重构不是可选项
- AI 不会主动挑战你的决策，但它有能力发现问题，关键是你要主动去问
下一节：使用 spec 处理复杂需求
常见问题
Q：重构后某些组件的样式出现了差异，怎么办？
A：先用 Kiro 检查差异来源，说明具体哪个组件的哪个样式不对，让它对照原始实现修复。重构大范围组件时，建议分批次进行，每次重构后立即验证。
Q：DRY 重构会不会让代码反而更难理解？
A：过度抽象确实可能降低可读性。好的原则是：当三处以上出现相同模式且变化规律明确时，才提取为共享组件；如果各处差异较大，保留独立实现更清晰。
Q：Kiro 做完重构后，我需要手动审查哪些内容？
A：重点检查三点：Props 接口是否涵盖了所有原始组件的差异化需求；CSS 变量或类名是否有命名冲突；旧组件的 import 是否已全部替换为新共享组件。