在 AI 大模型蓬勃发展的时代，如何将 AI 能力有效融入产研全流程，成为技术团队提效的关键挑战。本文详细分析了知乎舰桥平台圈子运营模块使用 AI 为产研全流程赋能实践案例，通过 Cursor AI 在需求细化、技术方案设计、编码实现到测试验收的全流程应用，实现了整体研发效率提升 38.6% 的成果。
文章深入探讨了 AI 辅助产研各环节的具体实践方法与量化收益，同时客观分析了当前存在的问题和未来发展方向，为技术团队探索 AI 赋能产研提供了可落地的经验参考。
项目背景与挑战
量化收益总结
AI 赋能产研全流程探索细节
存在的问题和未来展望
Q&A
项目背景与挑战
一、需求背景
知乎圈子作为用户社区互动的重要场景，其创建和运营管理工作曾完全依赖开发人工配置。随着业务增长，运营需求日益频繁，每次新建圈子约需服务端+算法配置，日常运营如置顶、主理人变更等每次配置也需要研发进行配置，严重影响工作效率。
二、AI 提效背景
面对这一挑战，我们决定开发舰桥平台的圈子运营模块，并尝试使用 AI 辅助产研全流程，对 AI 赋能产研全流程进行探索。
三、AI 提效使用方案
完全对话模式。即完全使用 Cursor 的 Agent 模式（用于编写和修改代码）和 Ask 模式（用户画图和了解项目情况），尽量不直接编辑原始代码，即使已知需要修改的位置，也尽量采用对话的形式让 AI 来改，除非遇到 2 次具体描述也无法改正的细节，再进行人工直接修改，最大程度的对比纯 AI 和纯人工的效率差异。（测试版本 Claude-3.7-sonnet + Cursor 0.47）
量化收益总结
▲产研流程图
一、项目提效成果
项目产品+ 研发 + QA人力 44 pd 降低至 27pd，节约 38.6%，产出 1.6w 字方案，有效代码 2.21w 行，用例 131 例，有效比 52.4%
1、需求细化：3pd 降低到 1pd，节约 66.7%，产物 7.3k 文字、14 张原型图、4 张动线图、1 张用户故事图的 RFC
2、技术 RFC： 2pd 降低至 1pd，节约 50%，产物 7.7k 文字、41 个接口梳理、33 个依赖方梳理
3、前端&服务端（舰桥）：
前端开发&自测：5pd 降低至 3pd，节约 40%，17 个文件变更，7713 行前端代码变更（排除 pnpm-lock 等）
服务端开发&自测：9pd 降低至 5pd，节约 45%，99 个文件变更，8825 行服务端代码变更（排除 go.mod 等）
测试修 bug：5pd 占 50% 精力，节约 50%
4、服务端（圈子）：
开发&自测：10pd 降低至 7pd，节约 30%，70 个文件变更，5609 行服务端代码变更（排除 go.mod 等）
测试修 bug：5pd 占 50% 精力，节约 50%
5、QA：
用例产出：总用例 250 例，P0 84 例，AI 可用用例数：131，占比 52.4%。
测试时间：5pd
二、分职能提效成果
产品 PM
1、产品工作包括
开发前：收集与分析、方案沟通、 需求细化
开发后：验收、宣发
2、AI 赋能提效
产品方案阶段：3pd 降低到 1pd，节约 66.7%
效果：细节补充、原型图绘制、动线梳理绘制、依赖点梳理等
包含：7.3k 文字（排除掉项目协调部分）、14 张原型图、4 张动线图、1 张用户故事图
其他节点
与沟通和协同关系较大，暂无可对比提效
研发 RD
1、研发工作包括：
技术评审、排期、开发、联调、自测验收、测试阶段修 bug
2、AI 赋能提效
技术方案阶段：2pd 降低至 1pd，节约 50%
效果：依赖方梳理、接口梳理、流程梳理等
包含：7.7k 文字、41 个接口梳理、33 个依赖方梳理
3、功能开发阶段
舰桥前端开发和自测：5pd 降低至 3pd，节约 40%
17 个文件变更，7713 行前端代码变更（排除 pnpm-lock 等）
舰桥服务端开发和自测：9pd 降低至 5pd，节约 45%
99 个文件变更，8825 行服务端代码变更（排除 go.mod 等）
圈子服务端开发和自测：10pd 降低至 7pd，节约 30%
70 个文件变更，5609 行服务端代码变更（排除 go.mod 等）
4、联调、测试、验收：2 x 5pd 占用 50% 精力，节约 50%（共 250 个用例、P0 84 例）
研发：50% 精力投入，待 QA 反馈 bug 和复现路径后修复，剩余精力可以安排其他事项。
总计 Bug 14 例，修复时间 2 x 2.5pd
测试 QA
1、测试工作包括：
用例编写、用例评审、测试阶段
2、AI 赋能提效
用例生成：总用例 250，P0 84，AI 可用用例数：131
测试阶段：执行测试用例阶段暂无提效
AI 赋能产研全流程探索细节
一、需求文档的智能细化与生成
表现
传统需求细化和文档编写耗时长且容易遗漏关键点。借助 Cursor AI，我们实现了：
1、需求框架智能构建：通过简单描述业务痛点，介绍需要落地的产品功能点，AI 辅助完成完整的需求文档框架和内容
2、场景细节丰富化：输入核心业务流程，AI 自动扩展多个典型用户故事和运营动线
3、原型图设计辅助：根据功能描述和用户交互流程，AI 提供界面布局和组件选择建议，生成详细的原型设计说明，大幅降低了从需求到原型的转化时间
4、非功能需求补全：AI 根据系统特点自动推荐并补充性能、安全、可用性等方面的要求
5、风险预判与建议：预先识别潜在风险点并提供应对建议
效果：需求文档编写时间从原来的 3 天缩短至 1 天，同时文档的完整度显著提升。
成果演示
▲详实的需求细节和原型图
▲美观的产品原型图
▲运营动线示例
▲用户故事示例
二、技术方案设计与架构优化
表现
1、接口设计自动化：描述功能需求后，AI 自动生成 RESTful API 设计方案
2、数据模型智能推导：根据业务描述自动推导并生成数据库表结构设计
3、架构优化建议：针对日志记录、权限管理等关键模块，AI 提供了多层架构设计建议
4、依赖分析与集成方案：自动识别与圈子服务端团队的依赖关系，生成详细的集成方案
效果：技术方案设计时间减少 50%。
成果演示
依赖方盘点：
▲依赖方 RPC 梳理
功能和接口拆解：
▲HTTP 接口盘点
4、依赖分析与集成方案：自动识别与圈子服务端团队的依赖关系，生成详细的集成方案
效果：技术方案设计时间减少 50%。
三、舰桥前端开发和自测
表现
开发周期从 5 人天缩短至 3 人天，提效 40%，17 个文件变更，7713 行前端代码变更（排除 pnpm-lock 等）主要体现在以下几个方面：
1、代码编写加速
组件架构智能构建：AI 根据功能需求快速生成了 RingForm、ModeratorModal 等核心组件框架，省去了手动搭建结构的时间。
高效表单验证生成：复杂的表单验证逻辑（如字节长度校验、Emoji支持等）由 AI 快速生成，避免了繁琐的手写验证函数。
表单状态管理优化：AI 协助设计表单状态管理逻辑，自动生成 useState 相关代码，减少样板代码编写时间。
2、问题解决与调试
异常处理代码智能补全：AI 主动推荐并生成异常处理代码，提高了代码健壮性，同时减少了编写时间。
问题快速定位：API 调用问题和数据结构不一致等开发中常见问题，通过 AI 分析迅速得到解决方案，缩短调试时间。
边界情况自动补充：AI 帮助识别并处理多种可能的边界情况，如数据加载失败、权限校验等，避免了后期返工。
3、优化与重构
代码智能重构：重复逻辑被 AI 自动识别并提取为公共函数，提高了代码复用性和可维护性。
性能优化建议：AI 针对图片上传、列表渲染等性能敏感区域提供了优化建议，减少了优化尝试的时间成本。
跨组件逻辑协调：多个弹窗组件之间的状态同步和通信逻辑由 AI 协助设计，减少了复杂度和错误率。
4、开发流程优化
需求快速转化为代码：从产品需求描述到代码实现，AI 帮助快速生成实现方案，减少了理解和转化时间。
组件 API 接口设计：AI 基于最佳实践，提供了清晰的组件 Props 设计方案，提高了组件的可复用性和一致性。
代码质量保障：AI 持续检查并提供改进建议，减少了代码审查和修复的时间。
成果展示
功能交付 MR 包含：17 个文件变更，7713 行前端代码变更（排除 pnpm-lock 等）
▲列表界面
▲表单界面
▲主理人编辑界面
▲操作日志界面
四、舰桥服务端开发和自测
表现
开发周期从 9 人天缩短至 5 人天，提效 45%，99 个文件变更，8825 行服务端代码变更（排查 go.mod 等），不仅保障了功能的完整性，也大幅提升了开发效率和代码质量，具体见下方情况：
1、代码自动生成与结构优化
标准化代码结构生成：利用 AI 根据业务需求自动生成了标准的 Goframe 层次结构，包括 logic、service 和 controller 层的骨架代码，使架构更加清晰统一
RPC 接口封装：AI 辅助完成了 9 个核心文件的 RPC 调用封装，自动处理了参数转换和错误处理，减少了 60% 的重复编码工作
模型转换代码：自动生成了各种 Thrift 模型到业务对象 (BO) 的转换逻辑，例如 fillRingInfoList 和 convertRingToRingInfo 等方法，提高了代码一致性
2、复杂逻辑实现加速
批量处理函数：AI 根据单个处理逻辑，快速推导并生成了批量处理函数，如 BatchGetRingDetail 和 BatchGetRingTags，提升了开发效率约 40%
嵌套对象处理：针对复杂数据结构（如 ringAdditionalInfo），AI 生成了完整的数据填充和处理逻辑，避免了人工编写时可能出现的遗漏
标签系统：在实现最复杂的标签管理部分（663行代码），AI 根据少量示例生成了完整的标签处理逻辑，准确率达 95%
3、错误处理与日志规范化
一致性错误处理：通过模式识别，AI 自动为所有函数实现了统一的错误封装和日志记录模式，减少了约 30% 的样板代码
参数验证优化：自动生成了各类接口的参数验证逻辑，如 CheckRingExists 方法，提升了代码健壮性和安全性
日志级别智能设置：根据操作重要性自动设置了适当的日志级别 (Debug/Info/Error)，增强了系统可维护性
4、性能优化与问题诊断
批量查询优化：AI 识别出高频查询场景，自动实现了数据批量获取和缓存逻辑，如用户信息和标签信息的批量获取
性能瓶颈预测：在 fetchAdditionalRingInfo 等关键方法中，AI 自动提出了并发优化建议，并生成了相应代码
代码冗余识别：分析识别出代码中的重复模式，提取为公共方法如 batchGetTagNames，提高代码复用率
5、开发协作与质量保障
代码注释自动化：AI 为所有函数生成了符合团队规范的注释，包括参数说明和返回值描述，提升了代码可读性
Lint 问题预防：在代码生成阶段自动规避了常见的 golangci-lint 问题，减少了约 80% 的 lint 修复工作
并发安全保障：自动识别并发场景，提供了线程安全的实现方案，如在用户信息处理时的映射操作
6、技术提效总结
开发周期缩短：从模块规划到完整实现，开发周期从原计划的 15 天缩短至 7 天
代码质量提升：AI 辅助生成的代码一次通过率达 92%，比人工实现高出约 30%
知识积累与传承：AI 自动提取和应用了项目内最佳实践，如错误处理模式和日志记录标准，促进了团队整体能力提升
成果展示
功能交付 MR 包含：99 个文件变更，8825 行服务端代码变更（排查 go.mod 等），41 个接口、33 个依赖函数、51 个功能子函数，包括：圈子基础管理、主理人管理、标签系统、内容排序、用户静默等完整功能链路。
五、圈子服务端开发和自测
表现
1、开发效率提升
服务层代码：生成准确率接近 100%，几乎无需人工调整
逻辑层代码：90% 由 AI 生成，人工剩下的微调和变更
数据层自动生成：DAO 代码生成效率达 90%，自动处理缓存策略和查询条件优化
编写测试数据脚本：自动生成对应的测试脚本，直接运行脚本验证数据
协助数据迁移：将 apollo 中的配置，按照数据库表的要求，生成 SQL 语句
2、实际提效表现
开发周期压缩：从 10pd 减少至 7pd，整体提效 30%
问题修复效率：测试阶段 bug 修复工作量降低 50%
代码一致性：自动生成的代码保持 95% 的风格一致性，提升可维护性
成果展示
成果交付 MR 包含：70 个文件变更，5609 行服务端代码变更（排除 go.mod 等）
六、测试阶段
表现
1、AI 赋能测试用例生成有明显效果
大规模测试用例智能生成：AI 协助生成了 131 个可用测试用例，占总用例数 250 个的 52.4%，为节省了大量编写用例的时间。
测试用例结构规范化：AI 生成的用例遵循统一结构，包含明确的前置条件、操作步骤和预期结果，提高了测试团队执行效率。
关键流程优先覆盖：AI 识别出核心业务流程，如圈子创建、权限修改、等级设置等，确保 P0 级用例全面覆盖关键功能。
测试文档一致性保障：AI 帮助维护了测试文档的术语和格式一致性，减少了人工编写时可能出现的差异和歧义。
2、虽然在测试执行阶段暂无明显提效，但 AI 辅助测试执行仍有潜力可以探索
自动化测试脚本生成：基于现有测试用例，未来可探索 AI 直接生成自动化测试脚本，进一步提高测试效率。
缺陷预测与优先级排序：AI 可通过分析代码修改和历史缺陷模式，预测高风险区域，优化测试资源分配。
测试结果智能分析：在执行阶段引入 AI 辅助分析测试结果，快速定位失败原因并提供修复建议。
成果展示
存在的问题和未来展望
一、当前存在的问题
1、代码理解与可维护性挑战：AI生成的大量代码（如圈子模块的 663 行标签处理逻辑）虽然功能完整，但开发人员对代码细节的理解程度有限，后续维护时需要理解这段代码。
2、风格不一致问题 ：AI 生成的代码虽然功能完整，但与项目既有代码风格存在差异，需要人工调整以符合团队规范。
3、业务理解深度不足：AI 对圈子运营等特定业务场景的理解仍有局限，生成的组件结构需要基于业务逻辑进行调整。
4、组件间依赖关系复杂：在处理如 RingForm 与各种 Modal 组件间的交互逻辑时，AI 难以全面理解组件间的依赖和状态传递。
5、安全边界意识不足：AI在生成参数验证、权限检查等安全相关代码时，可能存在考虑不全面的情况，如用户身份验证的理解不足
6、依赖问题难以智能解决：在处理复杂RPC调用依赖链（如圈子模块中的29个RPC调用）时，AI对服务间关系理解有限，容易导致无法将需求转化成实际调用的先后顺序。
7、版本控制协作问题：AI 生成大块代码时，与团队并行开发和版本管理产生冲突，增加了合并成本。
8、过度依赖风险：开发人员可能过度依赖 AI 生成代码，弱化对底层原理的理解和掌握。（Cursor 戒断综合征）
二、未来展望
1、编码能力增强
需求直译代码能力增强：未来AI将能直接从产品需求文档生成完整的服务端服务框架，包括 API 定义、数据模型和业务逻辑实现
知识图谱辅助开发：构建技术知识图谱、业务知识图谱，使 AI 能精准理解业务领域模型和服务依赖关系，提升代码生成的准确性和合理性（构建业务资料知识库）
项目级代码理解：未来 AI 将能够理解整个项目结构和业务领域知识，生成与现有架构高度一致的代码，实现"知乎风格"的代码生成。（建立项目级的 .cursorrule）
自适应学习团队规范 - AI 工具可以从团队已有代码库学习，形成特定于项目的编码风格模型，生成符合团队习惯的代码。（建立团队风格 .cursorrule）
2、开发流程革新
需求到代码的直接转化：从产品文档直接生成符合需求的组件框架和实现代码，进一步压缩开发周期。
智能化代码审查：AI 对提交的代码进行自动审查，检测性能问题、安全漏洞和设计缺陷，同时给出修改建议。
自动化测试生成：基于组件功能自动生成单元测试和集成测试，并进行智能测试执行和问题定位。
3、团队协作增强
知识沉淀与传承：AI 助手记录和整理团队的技术决策和解决方案，形成知识库，帮助新成员快速上手。
跨角色协作桥梁：在产品、设计、开发和测试之间建立面向 AI 的信息传递机制，减少沟通成本。（如本次通过产品需求 markdown、原型图 html、流程图 uml 进行传递）
Q&A
1、关于「AI 生成大块代码时，与团队并行开发和版本管理产生冲突，增加了合并成本」这块有什么建议么？
A：目前有 3 个实践经验，在组内尝试：
开发流程：
拆分代码：模块内代码文件尽量拆细成多个文件；
拆 MR：避免长周期大 MR，小步快跑；
管理办法：
同时间不同需求间尽量均衡，尽量不集中在同一个功能中。以上无法避免就 rebase 解决。
2、项目开发过程中 Bug 多吗？是否会因为引入 AI 增加 Bug？
A：先从时间上来看，分两阶段来看：
开发阶段：开发加自测时间降低，总时长降低。
表现：开发时间明显降低；自测时间变长；
总结：说明工作右移，的确引入了一些 AI 带来的 Bug，但发现 Bug 后修 Bug 效率也比较高，可通过耗时更少且必须要执行的自测来节约开发时间。
测试阶段：
表现：研发在测试阶段工作被明显提效；
总结：一共 250 个测试用例，QA 测试中发现 14 个 bug，修复方式为研发对话告知 AI 具体错误，AI 自动修复，同时问题均在上线前修复，比例不高。
3、关于「项目级代码理解：未来 AI 将能够理解整个项目结构和业务领域知识，生成与现有架构高度一致的代码，实现"知乎风格"的代码生成。（建立项目级的 .cursorrule）」这块有什么样例吗？
A：目前实践中不同项目自身特点 rule 是有差异的。找到几个比较有用的 rule 的类型：
语言和基本环境以及风格的介绍（期望优先用的特性）；
框架的介绍（例如 goframe 框架不同功能文件放哪里，用什么工具自动生成等）；
项目目录和目录功能的简介（什么类型的代码放哪里，能提供什么功能）；
期望的开发流程（比如我目前加了一条每次改完后都要跑一下 cilint 没问题后才算完成）；
对话中经常出现的错误（比如某个问题偶尔就会写的就不对，需要提示修改，那么可以放在 rule 里面）；
示范性代码（例如某某功能的实现代码是 xx yy zz，你的所有代码实现都要参考这种写法） 目前试验中，AI模仿照抄表现要比提要求表现好。
项目期间用的是 0.47 版本的 Cursor，就在编写本文的同时 0.49 版本于 4.15 号更新，期间增加了 /Generate Cursor Rules 命令，可以根据项目开发的过程经验，方便的产生 cursorrule，降低编写 cursorrule 的成本。
知乎技术沙龙干货分享 | 大模型推理框架 ZhiLight 实践
知乎技术沙龙干货分享 | 云原生技术如何重塑企业 IT 架构
