背景

期望是，AI 开发完一个功能，这个需求完成的很好；但是事实是，Ai 开发完一个功能，需要运行检测，然后修改，功能完成后，先提交（保证功能没问题）。然后再手动触发 CodeReview，优化代码；然后再确认功能没问题。然后再触发 边界和影响范围分析的 Skill，生成分析报告。
在 AI 开发完一个功能之后，自动触发 CodeView 和 边界和影响范围分析的 Skill。

维护 两个 APP的感受：
理想情况是：实现了一个之后，另一个 Prompt 直接复用即可。在一个遇到的问题，第二个上面完全能避免。
实际情况是：由于代码实现的不同（比如组件封装、颜色、类名、方法名），必须微调 Prompt 才能使用；确实第一个上面的问题都避免了，但是难免会遇到不一样的问题。

理想情况是：1+1 = 1
实际情况是：1+1 = 1.5；减少了写代码的时间，但是验证效果，调试，修改问题的时间还必不可少。并且会出现 AI 排查不到问题的情况，这时候就必须人工排查，分析原因，然后把思路告诉它，让 AI 顺着这个思路分析才能解决（比如排查播放器界面返回后性能埋点统计时长不对的问题，现象很明显，但是AI 定位的原因和思路不对，所以耗费再多的 token 也解决不了）。

使用技巧：
遇到问题，先自己排查，确认代码逻辑的同时，定位问题原因，然后再让 AI 确认并修改。（比如，Task 界面改分组时，AI 做了分组和不分组两个逻辑，但是在广告的地方更新的逻辑是不分组的 UI，如果直接让他修改广告为什么没有刷新的问题，它的处理方法是添加分组 UI 的刷新；但是会有问题，不确定其他地方有没有类似刷新问题的存在，不能保证新增加 Cell 时是否会自动处理两种样式的逻辑；正确的处理是，删除不分组的逻辑，修改只刷新不分组逻辑的地方为刷新分组UI 的逻辑，但是像这样的情况，就需要自己分析，然后明确告诉AI 怎么处理。）

在使用中不断完善 Skill 和 Rule，比如（生成界面时，APP 端文案需要用多语言的方式显示，没有完善之前，每次需要查找并手动修改；补充之后，遇到APP 端文案时，自动在多语言中添加 key，并在使用的地方直接使用）

实现

总结