随着企业系统复杂度攀升，研发团队面临着需求变化快、协作链路长、交付节奏紧的挑战。在日常工作中，诸如重复编码、规范检查、文档检索等可自动化环节逐渐累积，成为影响交付质量的隐形成本。
传统的研发模式主要依赖人力和经验，而AI的引入，犹如为每位工程师配备了一位“技术合伙人”。它能在架构设计、文档编写、编码调试等多个环节提供反馈，减轻我们的工作量，让我们能将精力聚焦于更具创造性的方向。简而言之，脏活累活交给AI，我们负责把控大方向。
AI辅助研发的意义，远不止于提升效率。它更在于帮助技术团队在日益复杂的时代背景下，持续保持高质量交付和快速演进的能力。实践反复证明，善用AI能够显著降低开发成本、缩短交付周期，并提升团队的整体产能。
接下来，本文将从“企业级工具开发”与“个人跨领域成长”两个维度，结合具体案例，分享我在AI辅助研发方面的落地经验与思考。本文不会涉及具体的代码实现细节，而是聚焦于分享如何借助AI完成需求分析、方案规划等“软性”工作的方法论。
一、企业级 VSCode 插件开发实践
1.1、背景与痛点
在前端开发体系不断演进的今天，API已成为贯穿业务、页面与服务的关键纽带。但在实际开发中，接口管理仍面临诸多痛点：
- 接口来源分散：项目依赖的接口往往存放在YAPI或第三方文档平台，查找与核对成本高昂。
- 类型维护成本高：虽然TypeScript提升了类型安全，但每次接入新接口或调整字段时，都需要手动补充/修改对应的请求与响应类型。
- 重复性劳动频繁：接口结构变更后，开发者需反复同步文档、更新类型文件、调整调用方式，这类机械操作既耗时又易出错。
- 组件库使用体验不佳：日常开发中，查阅组件属性、用法、文档是高频动作，但在编辑器内缺乏统一的补全、提示与跳转能力。
以下是一个典型的繁琐接口定义示例：
/**
* @description 是否开启智能体-query请求参数
* @url https://yapi.xxx.com/project/0000/interface/api/817314
* @updateDate 2025-08-21 15:23:33
*/
export interface IApiProjectJudgementAiAgentIsOpenGetReqQuery {
id?: string;
}
/**
* @description 是否开启智能体-响应体
* @url https://yapi.xxx.com/project/0000/interface/api/817314
* @updateDate 2025-08-21 15:23:33
*/
export interface IApiProjectJudgementAiAgentIsOpenGetResBody {
success?: boolean;
result?: boolean;
code?: string;
message?: string;
}
/**
* @description 是否开启智能体
* @url https://yapi.xxx.com/project/0000/interface/api/817314
*/
export async function apiProjectJudgementAiAgentIsOpenGet(
params: IApiProjectJudgementAiAgentIsOpenGetReqQuery,
): Promise<IApiProjectJudgementAiAgentIsOpenGetResBody> {
return request('/api/project/judgement/ai/agent/isopen', {
method: 'get',
params,
});
}
组件属性查看也同样不便，需要频繁在代码和文档间切换。
这些问题叠加，让本该高效的API管理流程变得琐碎低效，影响团队开发体验与交付质量。
1.2、辅助研发流程
基于长期使用AI工具的实践，我们总结出一套适用于当前阶段的研发协作流程，旨在保障工程质量的前提下，充分发挥AI的辅助价值。流程分为两个阶段：
阶段一：AI 主导、人工辅助（方案生成阶段）
本阶段目标是快速形成结构化、可评审的整体方案，利用AI的归纳发散能力降低前期设计成本，由人工把控关键决策。
- 需求分析：明确用户痛点、目标用户、核心功能和界面设计。
- 技术方案/规划：利用AI归纳整理架构、模块划分、技术选型，生成方案文档。
- 实现步骤规划：基于需求与技术方案，将功能拆解为可执行任务，安排开发流程。
阶段二：人工主导、AI 辅助（实施与验证阶段）
本阶段目标是高质量落地方案并提升研发效率，由人工主导设计与决策，AI作为效率工具参与执行。
- 编码实现：人工主导核心逻辑与关键模块开发，AI辅助完成重复性代码生成、代码结构整理、问题排查等。
- 功能测试：进行系统性测试与验证。
为什么不将阶段二的主要开发工作交给AI？
尽管AI代码生成能力强大，但目前仍不适合作为企业级项目的主要开发主体，原因如下：
- 对稳定性与可维护性要求更高：企业级工具需要清晰的结构、可预测的行为和便于交接的工程质量，这些高度依赖人工经验与架构把控。
- 生成代码质量与一致性存在不确定性：AI在实现方式统一性、业务上下文理解、边界条件覆盖等方面仍存在风险，会增加后期维护成本。
- 开发过程是团队能力建设的重要部分：完全交由AI会削弱团队对系统的“所有权”和理解深度，不利于技术积累。
- 责任归属与风险控制需要明确主体：在企业环境中，代码质量、系统稳定性和安全风险最终需由具体团队和责任人承担。
1.3、插件能力规划（需求分析）
我们先将问题抽象，借助AI从更高视角给出解决方案。关键前提是：将自己的问题描述清楚，而不是急于让AI给出答案。
1.3.1、AI 辅助规划需求分析
我们使用了以下提示词引导AI：
我想设计并开发一款VSCode插件，用于解决企业内部API管理难题，解决前端开发在获取API信息上的繁琐，难点如下：
1. 接口来源于 YAPI 平台中，开发需要反复核对(接口更新后需要人为修改等)
2. 类型维护困难，项目普遍使用 TypeScript 来保证类型安全，每次接入新接口、调整字段结构时，我们都需要手动补充/修改对应的请求与响应类型
3. 内部组件库文档查询频繁，开发者通常需要一边撰写代码，一边查询组件API
根据以上内容，整理一份需求分析文档。
提示词的关键在于完整、详细地还原开发场景下的问题与约束，而非追求“高级”词汇。
💡 提示：构建工具类产品，应从最小可行产品（MVP）开始，验证核心价值链路是否成立，再逐步扩展，避免过度设计。
1.3.2、需求分析总结
AI的输出并非最终方案，开发者需保持判断与校验意识。例如，在AI生成的“界面设计要点”中，我们识别出需调整之处：对于多人协作的内部项目，配置应具备可共享性，更适合以项目级配置文件形式存在，而非插件面板设置。
我们将问题抛回给AI进行修改：
@docs/需求分析文档.md:61-80 这里的界面设计不合理，项目由多人进行开发维护，配置需要可以共享，那么就不应该作为插件的面板设置，而是应该是项目级的，跟随项目来走
最终，我们明确了插件的三大核心能力模块：
- 一键拉取 YAPI
- 自动生成TS类型（核心）
- 接口类型更新提示（核心）
- 组件 API 智能提示
- 钉钉通知整合
1.3.3、规则定制规范 AI 输出
使用Cursor、Trae等AI编辑器时，可通过定制规则让输出更符合个性化要求。以Cursor为例：
- 创建规则文件：打开Cursor设置，进入“Rules and Commands”面板，在“Project Rules”下点击“Add Rule”并选择“Custom Rule”。
- 输入规则名称后，会在项目根目录生成规则文件。
- 编辑规则：编辑生成的
.mdc文件，定义规则内容。规则格式灵活，AI模型会自行解析。
以下是我使用的需求分析文档规则示例：
---
description: 需求分析文档规则
globs: *.md
alwaysApply: true
---
# 需求分析文档规范
## 角色定位
你是一个专业的技术文档助手，严格遵循文档结构，提供完整的信息。
## 文档结构模版
# [产品名称]-需求分析文档
> 简要给出一个符合当前需求语境的产品名称，若用户已提供则直接使用。
## 1、项目背景
简单介绍一下项目的背景与痛点，以及期望解决的问题或者达到的效果。
## 2、目标用户
| 用户类型 | 使用场景 |
|---------|---------|
## 3、核心功能需求
介绍一下项目想要实现的各个功能点，以及相关的描述等信息
### 3.1、功能概览
### 3.2、xx功能
### 3.3、yy功能
...
## 4、界面设计要点
本节用于描述主要界面形态与交互结构，使用`ASCII`字符，通过结构示意帮助理解功能布局
```markdown
┌────────────────────────────────────┐
│ 🎬 xx工具 │
├────────────────────────────────────┤
......
```
结构图仅用于辅助理解，不作为最终交付物
## 5、技术约束与限制
从需求层面说明可能存在的限制条件，例如：使用环境限制（仅限某些编辑器或平台）、数据来源依赖、权限或安全相关约束
本节不涉及具体技术方案或实现方式。
## 6、后续迭代方向
描述可能的后续演进方向，用于辅助决策与规划：功能增强方向、用户体验优化方向、与其他工具或系统的联动可能性
本节内容不一定可行，需在后续阶段评估可行性
## 7、其他说明
例如，专业术语、修订的记录等等
### 专业术语
| 术语 | 说明 |
|-----|------|
### 修订记录
| 版本 | 日期 | 修订内容 | 作者 |
|-----|------|---------|-----|
1.4、技术设计与规划
在探索实现路径时，AI在信息归纳、对比分析与结构化表达方面的优势可作为重要辅助。
1.4.1、AI 辅助的最佳实践
- 提供参考资料给AI：包括市面上已有的同类产品、解决方案链接、相关文档（如需求文档、YApi官方文档）。
- 引导 AI 进行整体分析：对比总结不同产品的功能划分、能力侧重点，提炼共性与差异，抽象出通用能力模型。
- 输出辅助成果：如系统架构示意图、功能模块拆分建议、技术实现思路概览。
⚠️ 提示：AI输出仅作参考，开发者需结合实际业务场景进行判断与优化。
1.4.2、插件技术架构概览
结合调研和需求分析，可借助AI生成一份技术架构示意图，帮助理解同类型插件的实现原理和关键点。
+-------------------------------------------------------------+
| VS Code 插件前端（Webview） |
| React + Messaging |
| |
| ┌───────────────────┐ ┌─────────────────────────────┐ |
| │ 主界面模块 │ │ 初始化配置模块 │ |
| │ (入口 + 布局) │ │ (首次使用指引、Token配置等) │ |
| └───────────────────┘ └─────────────────────────────┘ |
| │ │ |
| ▼ ▼ |
| ┌───────────────────┐ ┌─────────────────────────────┐ |
| │ 数据检索模块 │ │ 数据状态管理（Hook） │ |
| │（搜索 | 缓存 | 筛选）│ │ - 关键词缓存 │ |
| └───────────────────┘ │ - 搜索请求封装 │ |
| │ │ - 接口返回预处理 │ |
| ▼ └─────────────────────────────┘ |
| ┌────────────────────────────────────────────────────────┐ |
| │ API 树展示模块 │ |
| │（接口树结构、接口项展示、交互操作） │ |
| └────────────────────────────────────────────────────────┘ |
| │ │ │ |
| ▼ ▼ ▼ |
| ┌──────────┐ ┌────────┐ ┌──────────────────────────────┐ |
| │ 接口项UI │ │ 配置中心 ││ 前端数据处理逻辑 │ |
| └──────────┘ └────────┘ └──────────────────────────────┘ |
| |
| ┌────────────────────────────────────────────────────────┐ |
| │ 可展开容器组件（折叠/展开内容区） │ |
| └────────────────────────────────────────────────────────┘ |
| |
| ┌────────────────────────────────────────────────────────┐ |
| │ 批量处理进度模块（批量生成代码进度展示） │ |
| └────────────────────────────────────────────────────────┘ |
+-------------------------------------------------------------+
│
│ VS Code Extension Messaging（双向通信）
▼
+-------------------------------------------------------------+
| VS Code 插件后端 |
| (Extension Host Runtime) |
| |
| ┌────────────────────────────────────────────────────────┐ |
| │ YAPI 数据服务层 │ |
| │ - 获取项目列表 │ |
| │ - 查询接口详情 │ |
| │ - 接口变更检测 │ |
| │ - Token 校验 │ |
| └────────────────────────────────────────────────────────┘ |
| |
| ┌────────────────────────────────────────────────────────┐ |
| │ 代码生成引擎 │ |
| │ - 根据接口结构生成 TypeScript 类型/方法 │ |
| │ - 写入文件系统 │ |
| │ - 调用格式化工具（如 Prettier） │ |
| │ - 自动打开/更新文件 │ |
| └────────────────────────────────────────────────────────┘ |
+-------------------------------------------------------------+
│
│ HTTP 调用（YAPI API v1/v2）
▼
+-------------------------+
| YAPI 服务端 |
+-------------------------+
1.4.3、AI 辅助生成技术方案
将需求分析文档等相关资料提供给AI，使用类似以下的提示词生成技术方案文档：
- 使用AI编辑器（以Cursor为例）：
请根据 @需求分析文档.md，@YApi，https://github.com/zhixiaoqiang/yapi2code生成一份技术方案文档。
注意，这只是一个技术方案文档，不需要写具体的代码实现，只需要写技术方案设计即可。
结果帮我保存到 技术方案文档.md 中
- 使用智能体对话形式：
请根据前面的需求分析文档和相关参考资料，生成一份 VSCode 插件技术方案文档，仅包含技术方案设计，不涉及代码实现。
生成的技术方案文档应包含功能要点分析、技术架构设计、核心技术方案、业界方案调研、项目规范设计、技术选型总结、风险评估等模块。
同样，可以为技术方案文档定制规则模板，引导AI按固定结构输出。
1.4.4、AI 辅助实现步骤规划
在需求和技术方案明确后，可借助AI进行具体的实现步骤规划。提示词需包含项目约束，例如：
请你根据 @docs/需求分析文档.md @docs/技术方案文档.md ，帮我规划一下项目的具体实现步骤。
注意一下几点：
1、开发人力为2人，均为前端开发
2、开发不是全天投入，你可以按照人均3.0工时计算，非工作日不算。
3、可以分阶段实现，以一个可运行的Demo划分
内容帮我写入到 实现步骤规划文档.md中
借助AI辅助，可以高效完成阶段划分与流程规划，使研发工作能够按照既定路线循序推进。
1.5、实践成果
在AI的持续辅助下，我们最终完成了具备以下核心能力的VSCode插件：
1.6、AI 辅助研发小结
- AI在规划与信息整理方面具备天然优势。
- AI是研发过程中的协作助手，而非人工编码的完全替代。
- 效率提升将反向推动团队对AI的更深度使用。
- 高质量提示词是发挥AI价值的关键前提。
- 新工程应始终坚持“文档先行”的研发原则。
- 对AI生成的内容一定要仔细判别，不要全盘接受。
二、AI 赋能个人成长：3D建筑导航Demo实践
面对感兴趣但陌生的技术领域，AI正显著降低探索门槛。以下是我借助AI探索3D可视化技术，完成一个简易建筑导航Demo的实践。
2.1、尝试原因与目标
- 原因：对3D可视化技术感兴趣但门槛较高；希望验证AI在跨领域学习中的实际价值。
- 目标：构建一个具备基础交互的3D建筑可视化Demo，支持楼层切换、区域展示，验证在AI辅助下能否完成从0到1的探索。
2.2、实践成果
最终完成了一个具备基础交互能力的3D建筑可视化Demo，主要功能包括：
- 功能一：整体预览
- 功能二：其它楼层透明化
- 功能三：单楼层预览
整个项目从零开始到产出可用Demo，大约花费了2天时间。我严格遵循「文档先行」的原则推进，流程可抽象为：
“AI分析需求” -> “生成技术方案与实现路径” -> “页面与交互设计” -> “项目初始化” -> “按步骤分阶段实现功能” -> “测试与问题修复” -> “优化与完善”
在这一过程中，我更多扮演需求校验者与方向决策者的角色，判断AI给出的方案是否符合预期，并进行调整与收敛。
2.3、最终收获
- 对AI能力边界有了更清晰认知：AI是随时可调用的技术合作者，能显著降低试错成本和起步门槛，但不能替代人的判断。
- 验证了一种可复用的跨领域实践路径：明确目标 -> 文档方案先行 -> 拆解为小步骤 -> 人工判断收敛。
- 对“学习成本”的认知发生转变：在AI辅助下，可以“先做出来，再逐步理解”，在实践中反向补齐认知。
- 视角从“是否能做到”转向“是否值得去做”：更关注技术的适用场景而非单纯的技术实现。
三、AI辅助研发的方法论总结
综合以上实践，可以总结出一套相对稳定、可复用的AI协作模式：
- 让 AI 做结构性工作：如需求拆解、技术方案设计、项目结构规划。AI的价值在于快速构建一个完整且可讨论的结构框架。
- 让 AI 做重复性与机械性工作：如模板代码生成、API示例整理、文档补全。将人从琐事中解放，聚焦于需要思考判断的部分。
- 你负责判断与优化（方向把控）：AI负责“给可能性”，人负责“做选择”。判断方案是否符合真实需求，识别并避免过度设计，在多种路径中做取舍。
- 涉及未知领域时：先解决“能不能跑起来”，再追求优雅；将目标拆解为“可验证的小成果”；对AI输出保持“参考而非权威”的心态。核心在于降低进入门槛与心理负担。
四、结语
AI辅助研发并非简单的“用AI写代码”，而是一种分工明确、责任清晰的人机协作模式：
- AI擅长发散、整理、生成；
- 人类擅长判断、取舍、收敛。
当二者边界清晰、职责明确时，AI才能真正成为研发效率的放大器，而非新的复杂度来源。希望本文的两个实践案例与总结的方法论，能为你在云栈社区或其他技术探索之路上带来一些启发。
发表于 1 小时前
|
查看: 0|
回复: 0
