柚漫剧 AI全流程提效拆解¶
Ch01.645 柚漫剧 AI全流程提效拆解¶
📊 Level ⭐⭐ | 5.1KB |
entities/柚漫剧-ai全流程提效拆解-从单点提效到工程融合.md
柚漫剧 AI全流程提效拆解---从单点提效到工程融合¶
来源：原文存档
核心要点¶
微信文章：柚漫剧 AI全流程提效拆解---从单点提效到工程融合
相关实体¶
- Harness Engineering Jk Launcher Baijiajie
- Baidu Comate Coding Agent Feedback Loop Wanpeng
- Skill Formal Theory Survey 10Papers
- Ai Skill Evolution底层逻辑
- Tencent Skill Writing Complete Playbook Jackjchou
→ 原文存档
深度分析¶
柚漫剧的 AI 提效实践代表了中国移动互联网团队从"单点 AI 工具使用"到"系统性 AI 工程化"演进的典型路径。这个案例的独特价值在于其完整性——覆盖了产品、设计、研发、测试四个角色，且每个环节都有具体的规则沉淀（Rules）和工具集成（MCP/Skills）。 从"工具"到"基建"的认知升级：柚漫剧研发团队的核心洞察是"AI 不认识我们的工程"——这是所有企业在引入 AI coding 工具后必然遇到的墙。通用模型在公开代码上表现出色，但对内部框架（自研跨端框架）、私有 API、端能力接口一无所知。这个问题的解法不是换一个更贵的模型，而是把团队的隐性知识转化为 AI 可消费的显性资产——Rules（规则文件）、MCP（工具）、Skills（流程封装）。 Rules 的建设规律：柚漫剧 25 个规则文件不是一次规划的结果，而是被真实痛点倒逼出来的——每当 AI 在某个场景反复出错，就写一条规则。这种"从错误中学习"的方式值得借鉴：不要试图一开始就建立完备的 Rules，而是先让工具跑起来，当 AI 开始在某个场景产生可识别的错误模式时，立即将其 formalize 成规则。 "代码作为产研协作中间态"的协作模式变革：传统产研流程是 PRD → 设计稿 → 代码，每个环节的交付物形态不同，信息在转换中不断损耗。柚漫剧探索的是 UE 使用 Figma Make 直接生成代码，FE 在此基础上做工程化——代码本身成为贯穿全流程的统一中间态。这个模式的约束条件是"无历史包袱的新项目"，对于有大量存量代码和技术债务的系统，这种模式的可迁移性有限。
实践启示¶
- Rules 先于模型选择：在评估 AI coding 工具之前，先评估你的工程上下文的可编码程度——你的框架是否有公开文档？API 是否有 machine-readable 的 schema？如果这些基础设施不完善，先做 Rules 建设，再引入 AI 工具。
- F2C 的正确使用方式：柚漫剧的经验是"F2C 适合按模块使用，不适合整页一次性生成"。设计稿标注好模块边界再逐个处理，效果远好于"一把梭"。同时，F2C 生成质量高度依赖设计稿规范程度——图层结构、AutoLayout、命名规范等需要提前与设计团队对齐。
- AI CR 误报率需要分语言优化：柚漫剧发现 Android、iOS、Go 的误报模式各不相同，针对性优化后有效率才提升。这意味着 AI CR 不是开箱即用的，需要根据自己团队的代码库特点做 tuning。
- 单测 AI 的特殊挑战：自研框架的组件结构和生命周期与主流框架不同，AI 默认生成的单测在 mock 方式、组件挂载、事件模拟等方面都有偏差。必须为自研框架写专用的测试 Rules，不能依赖通用单测规则。
- Skills 是工程化成熟度的标志：当 Rules 积累到一定规模后，单个 Rules 的调用顺序和依赖关系开始变得复杂，此时需要 Skills 层来封装"固定流程"。Skills 建设的首个落地场景选单测是正确的——单测的流程固定（分析分支 → 生成用例 → 补充到项目），但每次手动引导 AI 成本高，Skill 正好可以自动化这个过程。
- 多角色协同的前置对齐：在 AI 参与的多角色协同中，如果不在生成前对齐整体结构，后续返工成本会很高。研发习惯自上而下设计架构，设计习惯自下而上打磨细节——这两种思维方式的冲突在 AI 工具介入后会被放大，需要在协作流程设计层面提前解决。