AI 协同开发这半年被讲了很多次。但一线工程师真正关心的，从来不是"它会不会写代码"，而是：它到底能不能进入真实研发流程，解决那些带着业务约束、性能要求和兼容边界的问题。
我们最近就用一个不算大的需求，认真验证了这件事。
这个需求是：在 Android 端实现歌词逐字同步展示。
听上去它像一个普通 UI 功能。
但真开始做时，很快就会发现，这个需求里几乎把 AI 协同开发最容易"露馅"的地方都带上了：
-
有明确业务目标
-
有实时数据驱动
-
有性能压力
-
有兼容边界
-
还必须从需求澄清一路走到代码交付
也正因为如此，这个案例比"让 AI 写一个页面"更有说服力。
它更像一线工程师真实会接到的需求，也更适合回答那个核心问题：
AI 协同开发，到底能不能落地。
一、为什么偏偏是这个需求，最适合验证 AI 协同开发
很多人会觉得，只有复杂的大项目，才值得拿来验证 AI 协同开发。
恰恰相反。
真正能看出协同质量的，往往是这种中等复杂度需求：目标很清楚，规模不算大，但里面埋着真实的工程问题。
拿"歌词逐字同步"来说，表面上只是一个 UI 效果，实际上至少有三层难点。
1. 进度信号不够密
业务侧提供的 SEI 回调，并不是为逐字动画准备的。
如果 UI 完全跟着原始信号走，歌词高亮就会呈现明显的跳变感，看起来不够顺滑。
2. 高频刷新会直接冲击渲染性能
逐字效果天然依赖高频更新。
一旦把实时进度粗暴地传进 Compose 状态树，整段歌词都可能跟着频繁重组，性能压力会很快冒出来。
3. 歌词格式并不统一
这类需求很少只面对一种理想数据。
既要支持 QRC 这种逐字结构，也要兼容 LRC 这种行级结构，解析和渲染逻辑都不能简单写死。
所以，这不是一个"把代码写出来就结束"的功能。
它更像一个带着约束条件的工程问题。
而我们真正想验证的是：在这样的问题里，AI 能不能不只参与编码，而是参与整个推进过程。
二、真正有效的，不是"一次性生成"，而是结构化协同
这次实践里，我们没有让 AI 一上来就生成大段代码。
原因很简单：如果问题本身还没被组织清楚，代码生成越快，返工往往也越快。
"歌词逐字展示"这几个字，看起来已经足够明确，但真正落到工程上，其实还缺很多关键边界。
比如：
-
QRC 和 LRC 应该怎么统一建模？
-
高亮效果是跳变，还是连续填充？
-
性能目标是"能跑"，还是"接近产品级丝滑"？
-
状态更新的责任边界到底放在哪一层？
-
最终交付标准是 demo 可演示，还是线上可稳定扩展？
这些问题如果不先摊开，AI 很容易沿着最直白的方向，给出一个"看起来能跑"的实现。
但"能跑"和"工程上成立"，从来不是一回事。
所以这次我们采用的是更接近真实研发的推进方式：
先澄清需求，再整理方案，再拆分任务，最后进入实现。
这个顺序并不新鲜，但对 AI 协同开发特别重要。
因为一旦流程是结构化的，AI 的价值就不只是"写得快"，而是能更稳定地参与每个阶段：
-
在需求阶段，帮助暴露隐含问题
-
在方案阶段，协助整理候选路径和权衡点
-
在任务阶段，把大目标拆成可以验证的小步骤
-
在实现阶段，补齐代码、测试和文档链路
换句话说，AI 真正发挥作用的前提，不是 prompt 写得多花哨，而是问题有没有被组织好。
三、这个案例里，真正改变结果的两个技术决策
如果说流程决定了协作能不能持续推进，那么下面两个技术决策，决定了这次实现能不能真正成立。
决策一：不把 SEI 当成唯一驱动，而把它当成"校准点"
逐字高亮想要自然，关键不在"有没有进度"，而在"进度是不是连续的"。
如果只在收到 SEI 时更新 UI，那么歌词高亮一定会表现为一种离散跳变。
它可以工作，但不会顺滑。
我们的做法是：把每一次外部进度更新，当成一个校准点。
也就是说，每次收到新进度时，记录两件事：
-
当前进度值
-
当前系统时间
然后在本地协程里，以大约 16ms 的周期持续运行，根据已经过去的系统时间去线性推算当前应到达的位置。
这本质上就是一个很典型的插值补帧思路。
它的价值非常直接：
-
不需要业务侧把信号频率提高很多
-
不需要额外引入复杂动画系统
-
就能把离散进度，转成更接近连续时间轴的体验
这一步很有代表性。
因为它说明，AI 协同开发真正有价值的地方，不是帮你补一个 API 调用，而是能参与把问题重新建模。
一个"歌词动画不够顺"的问题，最终被转换成了一个"时间同步与插值"的问题。
这类转化，才是工程质量开始拉开差距的地方。
请至钉钉文档查看附件《Screen_recording_20260417_143742.mp4》
决策二：不压刷新频率，而是压刷新范围
补帧之后，新的问题马上就会出现：
UI 更新变多了，性能怎么办？
很多实现会本能地去减少刷新次数，但这并不是最关键的。
对逐字歌词这种效果来说，刷新本身并不可怕，可怕的是刷新扩散到了整段歌词、整屏 UI。
所以我们最终采取的不是"强行降低更新频率"，而是严格限制高频状态的传播范围。
具体来说：
-
只有当前活跃歌词行，接收实时变化的
currentTime -
其他非活跃行，只接收稳定常量
这样一来，高频变化不会把整屏歌词都卷进去。
Compose 真正需要重组的，只剩下当前这一行内部的字级渲染。
这个设计看起来像个实现细节，但实际上非常关键。
因为很多声明式 UI 的性能问题，根本原因并不是"计算太重"，而是状态扩散得太远。
如果说插值补帧解决的是"看起来顺不顺"，那么局部隔离解决的就是"跑起来稳不稳"。
两者缺一不可。
四、AI 在这次实践里，具体帮了什么
如果只看最后的代码结果，很容易把这次实践理解成：
AI 帮我们补全了一段实现。
但真实情况并不是这样。
它在不同阶段扮演的角色，其实完全不同。
在需求阶段，它更像"问题整理器"
很多工程师脑子里其实已经隐约知道问题在哪，但没有被系统化表达出来。
比如：
-
进度信号频率不够
-
平滑度目标是什么
-
QRC / LRC 的兼容边界在哪
-
UI 性能风险会集中爆在哪里
AI 在这个阶段最大的价值，不是替我们回答，而是帮助我们把问题更快拉到台面上。
在方案阶段，它更像"结构化助手"
到了技术方案阶段，AI 很适合协助整理：
-
数据模型怎么定义
-
模块边界怎么划分
-
哪些任务应该先做
-
哪些点必须验证
最终拍板的人还是工程师，但 AI 确实能显著降低思考过程里的切换成本。
在实现阶段，它才像大家熟悉的"编码助手"
进入实现后，它的价值才回到大家更熟悉的部分：
-
生成初版逻辑
-
补齐测试样例
-
协助梳理文档沉淀
-
让整条实现链路持续往前滚
所以，这次实践真正被验证的，不是"AI 能不能编码"。
而是：
AI 能不能作为协同者，进入一个真实需求的推进过程。
从结果看，答案是可以。
但前提是，工程师必须先给出一个足够清晰的协作框架。
五、哪些地方，仍然必须由工程师主导
这次实践还有一个非常明确的感受：
AI 协同开发不会削弱工程师的重要性，反而更凸显工程判断的价值。
因为真正决定结果的，始终不是"代码有没有生成出来"，而是这些判断：
-
要不要接受线性插值这条路线
-
QRC 和 LRC 的兼容边界怎么定义
-
状态应该落在 ViewModel、UI 状态，还是更细粒度的渲染层
-
性能目标是"可用"还是"产品级丝滑"
-
最终交付标准是 demo 成立，还是线上可稳定扩展
这些问题没有一个是 AI 能脱离业务上下文独立完成决策的。
它可以帮助你更快看见问题、列出路径、组织方案。
但最后负责的人，仍然必须是工程师。
这也是为什么我们更愿意把它叫做"协同开发"，而不是"自动开发"。
六、对一线工程师来说，这次最值得复用的三点
回头看，这个案例里最值得复用的，并不是某一段代码，而是下面三条方法。
1. 先给上下文，再要结果
脱离上下文时，AI 最擅长给出"看起来合理"的标准答案。
但只有把它放进真实代码结构、组件边界和数据约束里，它才更可能给出真正能接进去的实现。
2. 不要跳过需求、方案和任务拆解
很多人觉得这些步骤会拖慢效率。
但对 AI 协同开发来说，它们不是额外成本，而是降低返工率的前置投入。
3. 非功能性要求一定要主动说出来
平滑度、局部刷新、兼容降级、可扩展性，这些不会因为一句"实现歌词逐字效果"就被自动考虑进去。
真正工程化的部分，仍然需要工程师主动提出。
最后
如果只是问：AI 能不能做一个歌词逐字功能？答案当然是可以。
但这次实践真正让我们看清的，是另一件事：
AI 协同开发能不能成立，关键不在模型会不会输出代码，而在团队有没有把研发流程整理到足够适合协作。
当需求是清楚的，方案是被推敲过的，任务是被拆开的，边界是被说明白的，AI 就不再只是一个"写点代码很快"的工具。它会更像一个能够持续参与推进的协作对象。它不会替工程师做判断。AI 协同开发真正值得讨论的，已经不是"它能不能写"。
而是：
我们有没有准备好，和它一起把事做成。
以上是本期分享。如果你想和我们进一步交流技术问题、获取独家干货，欢迎扫码加入花椒技术交流群。
