柚漫剧 AI全流程提效拆解---从单点提效到工程融合
柚漫剧团队深度拆解其如何通过构建Prompt友好型PRD、设计即代码、AI Coding基建与AI Agent测试等核心能力，打通“需求-设计-开发-测试”全链路智能闭环的实战经验。 以柚漫剧APP为锚点，开启AI赋能全链路的深度实验。通过打通‘需求-设计-开发-测试’的智能提效闭环，实现从“人力驱动”向“AI驱动”的范式跃迁，为产研模式升级提供实战样本。 AI 赋能产品经理从单点提效到全流程串联的实践与思考 提效心得： 这个环节的核心价值在于：AI帮我们解决了‘从0到60分’的信息收集与处理工作。我们不需要再花大量时间去做重复性的信息整理，而是可以直接站在AI给的基础上，去做深度的、判断性的工作。 目前局限性：AI目前无法完全替代深度体验，尤其是竞品的交互流程细节。所以我目前使用场景是“AI做前置整理 + 人做深度分析” 提效心得： 这个环节的核心价值在于：AI帮我们建立了一个‘可行需求’的标准化模板。它不是一个自动写需求的工具，而是一个帮助我们确保需求质量的协作者。好的产品需求到底需要哪些维度？AI可以帮我们定义出来，并且在每一次撰写时提醒我们 前提条件：AI辅助撰写的前提是输入足够清晰。如果输入模糊，AI输出也会模糊。所以PM需要先想清楚自己要什么。 原型设计阶段：产品与设计的协同，快速搭建demo原型 产出线上demo体验实际操作流程 思路比结果更重要，AI 不是替代产品经理做判断，而是把产品经理最耗时、最重复、最容易漏的工作，系统化提效。AI帮我们做好信息输入、深度拆解、问题定位、方案生成、风险兜底。 设计师不再被动接收碎片化、模糊的需求，而是主动为 PM 提供标准化的模版及工具，通过AI辅助需求澄清，确保“源头高质量”。 3.1.1 提效原型生成 · Prompt组件模板 通过预设一套包含组件基础功能、交互逻辑的 Prompt 撰写及组件模版，PM 只需输入业务核心逻辑，即可利用模版快速拼搭生成原型。 3.1.2 Prompt友好 · 需求撰写新模板 通过prompt撰写规则，反推需求模板，提取需求中的关键词，与prompt词模版比对查缺补漏，结合交互表述明晰需求撰写结构化/标准化要求，提供单页面0-1、单页面1-2、多页面流程3种常见类型需求撰写模板，以填空形式帮助梳理产品逻辑，生成内容完整、逻辑严密的需求文档，提升撰写及后续链路阅读友好性。 3.1.3 实践案例 当 PM使用AI 完成 60 分的“毛坯房”后，设计师将精力集中在最具溢价的专业领域：效果调优。 实践案例 guidelines撰写 撰写规则可将设计规范主要内容交给deepseek，把内容润色成合理的guidelines描述 研发不再是被动接收图纸，而是通过前置干预，让设计产出即为最终方案，交付给研发的是已经过设计校验、符合底层代码规则的“逻辑成品”。实现了从设计到实现的像素级自动化还原。 实践案例 通用技术 Prompt 模板： 2025 年Q4开始，漫剧研发团队陆续接入了 Zulu（AI 辅助编码）、F2C（设计稿转代码）、AI CR（智能代码审查）、AI 单测等一系列 AI 工具。从渗透率看，团队很快做到了"人人都在用"。 接下来的问题自然就变成了：用起来之后，效果到底怎么样？ 在持续推进的过程中，我们发现仅靠工具本身还不够——AI 对我们的自研框架、端能力接口一无所知，每次生成都需要人工反复纠正。这促使我们开始投入 Rules、MCP 等基建能力，让 AI 真正理解我们的工程上下文。而当基建逐步成熟后，我们还在漫剧官网项目上做了一次多角色协同的尝试——UE 使用 Figma Make 直接生成代码，研发在此基础上做工程化处理，代码本身成为了产研协作的中间态。 本篇章将围绕单点提效、基建驱动、协作模式变化三条线展开，分享我们的实际经验。 我们先在各个研发环节把 AI 用起来，看看哪些场景能直接见效，哪些还有问题。 4.2.1 AI 辅助编码（Zulu / Coding Agent） 日常编码中，Zulu 和 Coding Agent 是使用频率最高的工具，主要覆盖： 实际体感是：AI 辅助编码在"有明确上下文、标准化程度高"的任务上效果好，但在涉及业务逻辑判断、跨模块依赖的场景下，仍然需要人工主导。 4.2.2 F2C（设计稿转代码） F2C 能力主要用于将设计稿直接转换为前端样式代码，减少传统的标注-切图-还原流程。 我们在实践中发现： 在实际使用中，我们发现 F2C 的生成质量不只取决于工具本身的能力，还高度依赖两个输入条件：一是上下文 Rules 的完善程度，二是设计稿本身的规范程度——图层结构、AutoLayout 使用、分组命名等是否清晰，直接影响生成代码的可读性和可维护性。为此，研发侧和 UE 侧协同制定了一套 F2C 设计规范，从源头提升生成质量。 关键经验是：F2C 适合按模块使用，不适合整页一次性生成。 标注好模块边界再逐个处理，效果远好于"一把梭"。 4.2.3 AI CR（智能代码审查） 在 commit 和 CR 阶段引入 AI SA + AI CR，针对 Android、iOS、Go 等方向做问题召回。初期存在误报率较高的问题，QA 团队针对标记的问题进行了分析，按不同语言进行了针对性优化，有效率持续提升。 AI CR 更详细的实践经验将在 QA 方向的分享中展开，这里不做赘述。 4.2.4 AI 单测 前端新增业务模块接入了 AI 单测流程，重点覆盖复杂分支、异常链路与回归路径。对于减少手工漏测、提升分支覆盖率有明显帮助，新增模块的平均行覆盖率稳定在较高水平。 这里同样遇到了自研框架带来的挑战：它的组件结构和生命周期与主流框架不同，AI 默认生成的单测代码在 mock 方式、组件挂载、事件模拟等方面都存在偏差。因此，我们同样需要通过 Rules 来补充 自研框架的测试规范，让 AI 生成的单测能够正确运行。同时，单测也是我们后续 Skills 建设的首个落地场景（详见 3.3 节）。 4.2.5 小结 单点提效的价值在于见效快、推进阻力小，能让团队建立起对 AI 工具的基本信任。 但在这个过程中，一个规律性的问题也逐渐浮现：同样的纠正，我们在反复做。 AI 不认识自研框架，每次生成的组件写法都要手动改；端能力的调用方式它查不到，每次都要人工补；编码规范和项目约定它不知道，每次都要逐条修正。工具本身的能力没问题，但它对"我们的工程"一无所知——每次对话都像从零开始教一个新人。 这促使我们反过来想：既然每次纠正的内容都差不多，为什么不把这些规则直接告诉 AI，让它从一开始就按我们的方式来？ 上面那个问题的本质是：AI 不理解我们的技术栈和工程约束。这不是工具的问题，而是信息没有以 AI 可消费的方式组织起来。 我们在三个方向上做了基建投入：Rules、MCP 工具和 Skills。 4.3.1 Rules：教 AI 认识自研框架 漫剧前端在跨端开发中使用的是 一个自研跨端框架。这个框架在公开的模型训练数据和互联网资料中几乎没有任何信息，AI 对它一无所知。 这意味着，如果不额外做些什么，AI 在涉及 自研框架 的场景下生成的代码基本不可用——语法不对、API 不存在、组件用法错误。 解决方案是 Rules（规则文件）。 我们把 自研跨端框架 的框架概念、组件用法、API 约定、编码规范等信息，结构化地写入 Rules 文件，让 Coding Agent 在生成代码时能够读取和遵循这些规则。 这个过程本身也是一个不断迭代的过程： 目前，我们围绕 自研跨端框架 建设的 Rules 体系已覆盖 25 个规则文件 按职责分为四类： 基础规则（必读）——项目结构、San 组件语法、样式属性白名单、常见布局最佳实践，任何代码生成前都会加载。 组件 & 能力专项规则（按需加载）——覆盖 自研框架 的 6 个内置组件（img / list / swiper / video / pagview / refresh）和 3 类能力（BOM-DOM-路由 / 端能力调用 / CSS 动画），每条规则包含属性表、事件表、注意事项和正反示例。 工程专项规则——项目配置、CLI 创建、单元测试（vitest）、AI Code Review 评审标准，保证 AI 在非编码环节也能对齐团队规范。 迁移规则——完整的框架迁移链路（项目结构 / API 替换 / 组件标签 / 样式转换 / 目录优化），支撑存量项目的渐进式迁移。 所有规则通过一个入口调度文件（ 核心启发：Rules 的建设不是"提前规划"出来的，而是被真实的痛点倒逼出来的。 当 AI 在某个场景反复出错时，就是需要补充 Rules 的信号。 4.3.2 MCP 工具：让 AI 查到端上的能力 漫剧是一个跨端项目，前端经常需要调用客户端提供的端能力（如原生组件、系统接口等）。传统流程中，前端需要查阅端上的接口文档，或者直接找客户端同学确认。 为了让 AI 在编码时也能获取这些信息，客户端团队提供了对应的 MCP 工具——当 Coding Agent 在生成代码过程中需要调用端能力时，可以通过 MCP 工具直接查询可用接口、参数格式和调用方式。 这解决的是跨角色信息不对称的问题：以前前端要"问人"才能知道端上有什么能力、怎么调用，现在 AI 可以直接"问工具"。 4.3.3 Skills：从"知道规则"到"会跑流程" Rules 解决的是"AI 知不知道"的问题，但有些任务不只需要知识，还需要固定的执行流程——比如单测生成，需要先分析模块分支、再结合框架约束生成用例、最后补充到项目中，步骤是确定的，但每次手动引导 AI 走一遍成本不低。 最近，基于前期积累的 Rules，我们开始在业务中尝试 Skills 的建设。Skill 本质上是可复用的任务流程封装，把 Rules 中的知识和固定的操作步骤组合在一起，让 AI 能够自主完成一个完整任务，而不再需要人工逐步引导。 目前已经落地的典型场景是前端单测 Skill：给定一个业务模块，Skill 自动分析其分支和边界，结合 自研框架 的测试 Rules 生成测试代码并补充到项目中。这将单测从"人工驱动 AI 逐步生成"升级为"Skill 驱动 AI 一键完成"。 如果说 Rules 是教 AI"认识我们的工程"，那 Skills 就是教 AI"按我们的方式做事"。 4.3.4 基建的本质 Rules、MCP 工具和 Skills 看起来是三个不同层面的事情，但它们解决的是同一类问题：把团队内部的隐性知识和工作方式，转化为 AI 可消费的显性资产。 没有这些基建，AI 工具只能在通用场景中发挥作用；有了这些基建，AI 才能真正进入我们的工程上下文，生成贴合实际的代码。而当基建能力逐步成熟后，一个更值得关注的变化也随之出现。 在单点提效和基建能力都有了一定基础后，我们在漫剧官网项目上做了一次多角色协同的尝试——UE 使用 Figma Make 直接生成代码，FE 从技术视角全程参与（这部分协作细节已在 UE 侧的案例中分享）。 这次实践中最值得关注的变化是协作中间态的改变。传统产研流程中，PM 输出 PRD，UE 输出设计稿，研发再基于设计稿编码——每个环节的交付物形态不同，信息在转换中不断损耗。而在这次实践中，代码本身成为了贯穿全流程的中间态：UE 通过 Figma Make 直接产出可运行的代码，FE 在此基础上做工程化处理，而不再从零还原。 我们认为，这种"以代码为中间态"的协作模式，可能是未来产研合作的一个趋势方向——各角色不再各自交付不同形态的产物然后"翻译"，而是围绕同一份代码资产进行协作和迭代。 当然也必须承认边界：这套模式目前更适合重交互、无历史包袱的新项目。对于有历史包袱、技术栈复杂的存量项目，更现实的做法是拆分模块——UE 负责关键模块的动效代码输出，FE 根据耦合程度选择直接采用或作为参考输入给 Coding Agent 进行工程适配。 经验一：基建是单点到系统的桥梁 AI 工具用起来不难，但要让它在你的工程中持续产出可用代码，必须投入基建——Rules 让 AI 理解你的框架，MCP 让 AI 查到你的能力接口，Skills 让 AI 按你的流程做事。这些基建不是提前规划的，而是被真实痛点倒逼出来的。 经验二：先找"高闭环任务"建立信任 优先选择标准化程度高、反馈周期短的任务（如样式拼装、单测补齐、规范化 CR）形成 AI 闭环样板。让团队看到实际效果，再推进更复杂的场景。 经验三：跨角色协同需要前置对齐架构 不同角色的思维方式不同。研发习惯自上而下设计架构，设计习惯自下而上打磨细节。在 AI 参与的多角色协同中，如果不在生成前对齐整体结构，后续的返工成本会很高。 经验四：承认边界，分场景落地 AI Coding 不是万能的。重交互、无包袱的新项目适合整体生成流程；有历史包袱的存量项目更适合模块化、渐进式地引入 AI 能力。认清这一点，反而能让落地更扎实。 全链路智能化测试（持续升级） 交付新模式：通过两大角色（主Agent + 数字员工-"度小智"）+ 六大专业Agent + 工具生态 + 交付工程记忆，从"人用工具"升级到"人机协同" △ AIQA 架构图 △ 主动感知+持续测试 实践效果（以 v1.0 为例） AIQA：落地需求占比100%；根据提测内容分析判定、自动发送提测报告QA反馈正向，根据需求准出标准自动拦截未达标需求；支持如流侧边栏形式、便捷观测需求和版本维度风险。 智能测试：打通端到端全流程链路、完成从需求生成到测试准出全AI化；其中客户端需求用例生成占比74%、稳定自动化用例占比10%，服务端打通新需求接口用例生成占比81%、稳定自动化用例占比2% △ 自动发送提测报告 △ 需求准出自动拦截 △ case自动生成-8s △ case单步执行-1min △ 通过 △ 不通过 △ 自动断言 △ 自动签章 提测阶段：AICR（持续完善） △ Commit阶段 △ CR阶段融合 △ 优化前 △ 优化后 走查阶段： AI Checker茶茬（建设中） △ 架构图 △ web首页 △ 报告示例 △ 效果示例导读
01 PMO
1.1 背景&目标
1.2 全流程落地总述
02 产品
2.1 需求方案阶段
2.2 交互视觉阶段
2.3 AI在产品经理工作流中经验总结
03 设计
3.1 向上游赋能：设计师作为“需求架构师”
3.2 设计师的核心深耕：从“生产”转向“效果精修”
**忽略theme.css的设计规范，所有组件的设计规范基于design.json**
# 字号
单列标题用subtitle-lg，用户名文字用subtitle-xs，按钮字号用caption-lg，来源信息用caption-md，标签文字用caption-sm，内容用标题展示最多两行
# 字体加粗
标题用regular
# 圆角
标签用rounded-xxs，图片用rounded-md，卡片用rounded-lg，按钮用rounded-full
# 间距
标签内部用space-6xs，卡片内信息上下间距用space-xl，卡片内信息左右间距用space-xl，文字与图片间距用space-md
# 颜色
标题用text，来源和辅助信息用text-slim
# 图片
单图大图比例16:9，三图的图片比例3:2，三图只有第一张左边和第二张右边加圆角
请基于以下设计规范，使用 `design.json` 中的设计令牌（Design Tokens）来定义组件样式，并完全忽略 `theme.css` 中的任何现有规则。
### 设计依据与整体要求
* **唯一设计源**：所有组件的样式定义必须严格基于 `design.json` 文件中的令牌值。
* **组件类型**：请假设这些规范应用于一个“卡片”组件及其内部元素。
### 具体样式规范
请将以下设计描述映射到 `design.json` 中对应的令牌：
1. **文字与排版**
* **字号**：
* 卡片主标题：使用 `subtitle-lg`。
* 用户名：使用 `subtitle`。
* 按钮内文字：使用 `caption-lg`。
* 信息来源/辅助文字：使用 `caption-md`。
* 标签内文字：使用 `caption-sm`。
* 主要内容正文：使用标题样式展示，并限制最多显示两行。
* **字重**：主标题的字重为 `regular`（常规，不加粗）。
* **颜色**：
* 标题：使用 `text` 颜色。
* 来源、时间等辅助信息：使用 `text-slim` 颜色。
* 分割线：使用`divider` 颜色。
2. **圆角**
* 标签：使用 `rounded-xxs`。
* 图片：使用 `rounded-md`。
* 卡片容器：使用 `rounded-lg`。
* 按钮：使用 `rounded-full`（完全圆形或胶囊形状）。
3. **间距**
* 标签内部（文字与边框之间）：使用 `space-6xs`。
* 卡片内部，上下区域之间的间距：使用 `space-xl`。
* 卡片内部，左右两侧的内边距：使用 `space-xl`。
* 文字内容与图片之间的水平间距：使用 `space-md`。
* 信息来源/辅助文字之间间距：使用 `space-md`。
* 三图图片间距：使用 `space-4xs`。
* 分割线距离页面边缘间距：使用 `space-xl`。
4. **图片布局**
* **单图大图模式**：图片宽高比为 **16:9**。
* **左文右图模式**：图片宽高比为 **3:2**。
* **三图并列模式**：
* 图片宽高比为 **3:2**。
* 仅对第一张图片的**左上角、左下角**和第三张图片的**右上角、右下角**应用圆角（`rounded-md`），其余图片边角保持直角。
### 输出要求
请根据以上规范，生成相应的样式实现方案或配置代码，确保所有值均引用自 `design.json`。
3.3 向下游交付：实现“无需走查”的代码集成
### 精密视口与高度适配 (Engineered Viewport Logic)
* **PC 优先架构：** 以 **1440px** 为核心设计基准。默认样式即为 PC 端，通过 `max-width` 断点向下兼容。
* **动态高度计算 (Dynamic Calc)：** \* **禁止**使用 `100vh` 或 `100%` 处理全屏容器。
* **实现方案：** 必须通过计算逻辑（如监听 `resize` 结合 `requestAnimationFrame` 或使用现代 CSS 变量注入）动态更新 `--vh` 单位。
* **公式应用：** 容器高度应通过 `calc(var(--vh, 1vh) * 100)` 实现，确保在移动端动态工具栏伸缩时，布局能进行精密重绘或保持稳定，避免内容被遮挡或溢出。
* **比例锁定：** 核心展示组件优先使用 `aspect-ratio` 配合 `calc()` 进行自适应缩放，而非硬编码高度。
* **存量优化：** 会影响整体高度内容区域, 检查并优化不符合要求的100vh
### 动效性能与 DOM 生命周期 (State-Driven Lifecycle)
* **非视口静默策略 (Off-screen Silencing)：**
* **目标：** 不在当前视口内的元素，其计算逻辑（如 JS 循环、Canvas 渲染、高频计时器）必须**彻底挂起**。
* **DOM 优化：** 在不破坏进场/退场动画连贯性的前提下，利用**状态驱动渲染**（State-driven rendering）。当元素处于“非活跃且无过渡动画”状态时，尽可能将其从 DOM 树中移除，以减轻内存压力和浏览器的层合成负担。
* **动效解耦：** 动效实现需与业务逻辑解耦，支持“动画预判”。通过组件的生命周期钩子（如 `useEffect` 销毁函数或 `cancelAnimationFrame`）**确保没有任何无效的后台计算在静止页面上运行。确保不影响现有的动效及显示效果**
prompt参考
帮我生成一个如图所示的官网界面，背景的漫画从下至上无限滚动，同时按以下要求做优化：
### 精密视口与高度适配 (Engineered Viewport Logic)
* **PC 优先架构：** 以 **1440px** 为核心设计基准。默认样式即为 PC 端，通过 `max-width` 断点向下兼容。
* **动态高度计算 (Dynamic Calc)：** \* **禁止**使用 `100vh` 或 `100%` 处理全屏容器。
* **实现方案：** 必须通过计算逻辑（如监听 `resize` 结合 `requestAnimationFrame` 或使用现代 CSS 变量注入）动态更新 `--vh` 单位。
* **公式应用：** 容器高度应通过 `calc(var(--vh, 1vh) * 100)` 实现，确保在移动端动态工具栏伸缩时，布局能进行精密重绘或保持稳定，避免内容被遮挡或溢出。
* **比例锁定：** 核心展示组件优先使用 `aspect-ratio` 配合 `calc()` 进行自适应缩放，而非硬编码高度。
* **存量优化：** 会影响整体高度内容区域, 检查并优化不符合要求的100vh
### 动效性能与 DOM 生命周期 (State-Driven Lifecycle)
* **非视口静默策略 (Off-screen Silencing)：**
* **目标：** 不在当前视口内的元素，其计算逻辑（如 JS 循环、Canvas 渲染、高频计时器）必须**彻底挂起**。
* **DOM 优化：** 在不破坏进场/退场动画连贯性的前提下，利用**状态驱动渲染**（State-driven rendering）。当元素处于“非活跃且无过渡动画”状态时，尽可能将其从 DOM 树中移除，以减轻内存压力和浏览器的层合成负担。
* **动效解耦：** 动效实现需与业务逻辑解耦，支持“动画预判”。通过组件的生命周期钩子（如 `useEffect` 销毁函数或 `cancelAnimationFrame`）**确保没有任何无效的后台计算在静止页面上运行。确保不影响现有的动效及显示效果**
04 研发
漫剧研发侧 AI Coding 落地实践：从单点提效到基建驱动
本文从研发视角出发，分享漫剧团队在 AI Coding 落地过程中的实际经验。核心观点：AI 工具本身不难用起来，难的是让它在真实工程环境中持续产出可用代码——这背后需要 Rules、MCP 等基建能力的支撑。同时，我们也看到了"代码作为产研协作中间态"的趋势可能。
4.1 背景：AI 工具全面接入
4.2 单点提效：先让每个环节跑起来
4.3 基建驱动：让 AI 理解"我们的工程"
start.mdr）统一管理，按"先读基础规则 → 按场景匹配专项规则 → 再执行生成"的三步流程强制加载，确保 AI 每次生成代码前都带着完整的框架认知。
4.4 协作模式展望：代码作为产研协作的中间态
4.5 经验总结
4.6 下一步方向
一句话总结：AI Coding 落地不是"用工具"的问题，而是"建基建"的问题。把团队的隐性知识变成 AI 可消费的显性资产，让代码成为产研协作的统一中间态——这不仅是当下的提效手段，也是未来研发协作方式演进的方向。
05 测试
5.1 AI模式升级：从Copilot 到"AI Agent" 的范式转移
5.2 AI助力测试左移
一句话总结：AI改变了测试模式、模糊了角色概念，就像是修仙最牛 debuff "小绿瓶"，让我们的每一步走的意料之外、情理之中，是我们最好的伙伴！