作为一名前端开发者，在使用像 Cursor 这样的 AI 编辑器后，深刻感受到编程工作方式正在悄然改变。AI 不再只是辅助搜索的工具，而是真正参与到编码、文档、沟通乃至产品思维的各个环节。
本文将从三个维度出发，分享我在实际工作中使用 AI 的经验和观察：
- 作为项目负责人，如何利用 AI 编辑器提升团队协作与代码质量
- 作为项目成员，如何借助 AI 辅助编码、调试和文档理解
- 作为开发者，如何构建自己的 AI 产品，探索更具前瞻性的应用场景
AI 编辑器的使用者：项目负责人
高质量的知识库
我用的 AI 编辑器是 Cursor，在了解到它具备“使用文档”的能力时，我感到十分惊喜。
我长期面临的一个难题是团队成员在编码过程中风格不统一，尤其在人员不断更替的情况下，这一问题愈发突出。借助 Cursor 的使用文档功能，我可以将团队的开发规范与代码风格整理为文档，提供给 Cursor 作为参考，从而自动生成风格统一、符合规范的代码。
相比过去反复强调编码规范，如今通过 Cursor 生成的代码既是样例也是答案，不仅提升了执行力，也让我能够更加轻松地在团队内部建立起清晰一致的协作规范。
我一直鼓励团队成员编写各类文档，包括 API 文档、开发手册和项目说明书，然而，实践中却频频遇到阻力：有些人不愿写，文档质量参差不齐，甚至还有写了也没人读的情况，最终导致“有文档等于没文档”。
但 Cursor 编辑器改变了这一切。它不会“偷懒”，也不会忽略我提供的文档内容。只要我愿意投入时间产出一份高质量的使用文档，Cursor 就能以此为依据，生成符合规范的代码。我需要做的，不再是一遍遍催促团队成员写文档、看文档，而是专注于把文档写好、写清楚，让它真正成为可执行的规则和可落地的生产力工具。
对于 Cursor 来说，一份真正高质量的知识库，是结构清晰、语言精确、歧义最小化的内容集合，而非信息的堆积。它需要像代码一样可被解析和执行。
换句话说，这类文档应当具备明确的层次结构、术语统一的表达方式，并尽可能减少模糊描述。同时，还应包含具有“行为指令”性质的示例，例如：
“在编写表单组件时，应优先使用统一封装的
<FormInput>，而非直接使用原生<input>标签
——这样 Cursor 才能准确理解并按规范生成代码。
高质量的知识库，本质上是在告诉 Cursor：“我希望你怎么做”，而不仅仅是“这件事是什么”。这是人与 AI 协作的前提。
AI 的适用边界
AI 归根结底是一种工具，它的适用边界，是我在使用之初首先认真思考的问题。AI 擅长执行清晰、具体的指令，却并不擅长应对模糊、多变的“可能性”。总体而言，AI 更适用于目标明确、规则稳定、重复性高的任务；而在那些需要判断力、策略性博弈、或依赖人类经验积累的场景中，它仍然表现有限。
但这并不意味着这些局限无法被减轻。对于许多依赖经验判断的任务，例如：
- 线上故障排查（常见问题归因、处理流程梳理）
- 项目初始化配置（如 Webpack/Vite 配置的最佳实践）
- 异常处理策略（如鉴权失败后的重定向逻辑）
我们可以通过结构化总结，将这些经验转化为清晰可读的规范文档，整理进知识库中供 Cursor 学习参考。通过“教会”AI，我们逐步将其嵌入到开发流程之中，从一个外部工具变成团队工作的一部分。
在前端开发中，常见任务包括：
- 获取网络数据
- 编写通用工具函数
- 状态管理与路由配置
- UI 组件开发
- 响应式设计实现
- 性能优化
- 代码重构与模块抽离
- 单元测试编写
- 国际化处理
- 安全性保障等
其中，AI 表现较为突出的任务包括：网络请求封装、工具函数编写、代码重构、错误检测、单元测试生成、路由与状态框架搭建，以及部分依赖项较少的 React/Vue 组件。
而 AI 在以下任务中的表现相对薄弱：
- 性能优化：这要求开发者具备全局视角，深入理解需求场景，并在用户体验与运行效率之间做出合理权衡。而 AI 无法准确评估业务优先级，常常忽略懒加载、资源预取等策略。例如，AI 可能无法判断某个组件是否应该进行懒加载，因为它无法评估该组件在用户体验中的重要性。
- 安全性设计：AI 的训练数据主要来自公共代码库，其中不乏过时或存在安全漏洞的写法，甚至可能被恶意投毒。而安全问题常常直接影响业务稳定性和用户数据保护，必须由开发者主动掌控。
- 复杂业务逻辑实现：这类任务往往依赖领域知识与隐含规则，AI 难以理解上下文语义，容易生成“看起来正确、实际上错位”的代码。更合适的做法是将复杂逻辑拆分为更小单元，利用 AI 进行点对点增强。
- 国际化与多语言支持：目前 Cursor 尚未支持自动提取文本进行翻译，也无法智能判断哪些字段需要本地化处理，仍需人工配合。
提示词模版
开发提示词模板的首要目的，是为 AI 模型提供精准明确的指令，从而提升其生成代码的专业性、可用性与可维护性。
从短期来看，设计提示词模板确实增加了工作量。它要求我们更加细致地拆分场景、系统化地采集参数，并以规范化方式组织输入。但这并不是无谓的堆砌。
提示词模板通过系统化设计，压缩了模糊输入带来的猜测空间，放大了 AI 的执行能力，从而显著提升生成结果的准确性和一致性。
从长期来看，提示词模板的价值更为显著——它能够沉淀经验、构建知识资产，将原本零散、依赖个人感知的工作流程，转化为可以被反复调用、持续优化的系统能力。
开发流程也因此得以从：
“每次拍脑袋交互 → AI 自由发挥 → 人工修正” 这一低效、不可控的模式，
演进为
“标准输入 → 稳定输出 → 快速集成” 的高质、可扩展系统流程。
这是一次短期负担、长期收益的策略性投入。
我曾就此写过一篇完整的实践分享文章——《让 AI 写出靠谱代码：一套提示词模板设计实践》，欢迎点击查看详情。
AI 编辑器的使用者：项目成员
拆分能力
“将大需求拆成小需求”这类口号式建议，如果缺乏配套的范式与实战例子，对一线开发者而言往往过于抽象，难以落地。为此，我在实践中将前端代码划分为三个层级：视图层、基础支撑层、业务逻辑层，并分别总结了适用于 AI 编辑器的拆解方法。
1. 视图层：遵循“稳定性优先”，从组件向外展开
拿到设计稿时，人类可以按照“页面 ➜ 容器组件 ➜ 原子组件”的层级结构，自下而上地生成代码。而AI 擅长处理输入清晰、边界稳定的任务，因此应优先从最小单元着手，遵循“原子组件 → 复合组件 → 页面”的生成顺序。
2. 基础支撑层：职责单一、稳定性高，适合预生成
基础支撑层包括工具函数、网络请求封装、权限管理等。这部分代码的特点是职责明确、变动频率低、可测试性强、复用价值高。在项目初期即可交由 AI 大量生成，快速搭建出骨架，为后续开发节省大量时间。
3. 业务逻辑层：遵循“触发 ➜ 处理 ➜ 反馈”的流程性范式
相比视图层，业务逻辑的拆分更依赖抽象能力。建议按照“用户行为触发 → 状态/数据处理 → 界面反馈展示”的路径，将复杂业务逻辑划分为小的可控段落，逐步调用 AI 实现。
我曾在另一篇文章中详细解析过这一思路——
《AI 编辑器提升团队开发效率，从组件到逻辑的全流程解析》，欢迎查阅。
验证能力
AI 生成代码只是第一步，开发者仍然需要承担“验收”的角色，确保代码真正符合项目要求。在实际工作中，我通常会从以下几个关键维度进行验证：
- 是否可运行：首先要确保生成的代码能够顺利通过构建、运行在预期环境中，并完成基本交互流程。这是最基础的要求。
- 是否复用了已有组件：为了避免重复造轮子，提高维护效率，我们要检查 AI 是否复用了项目中已有的组件，尤其是在统一设计体系或组件库已搭建的前提下。
- 依赖关系是否合理：AI 有时会引入不必要的依赖，或者遗漏某些必须的引入。开发者需要手动校验依赖的完整性、正确性，以及其对项目包体积和构建速度的影响。
- 性能是否达标：生成的代码是否包含冗余计算、无意义的状态更新、阻塞性操作等，会直接影响页面性能与用户体验。这些通常需要结合具体业务场景进行人工判断。
AI 是“高效生成者”，但当前阶段它还不是“可靠审核者”。开发者的判断力和经验，仍然是将生成结果落地为高质量产品的关键一环。
结语
目前，我正在使用 微信小程序 + 云开发能力 打造一款属于自己的 AI 产品。如果你对这类产品的开发流程、技术选型或实际应用场景感兴趣，欢迎参与我和子曰(微信号: yuhang-ziyue)在本周六晚 8:00～9:00 的直播分享。直播链接会提前转发到我的【低代码 + AI】交流群中，感兴趣的朋友可以提前扫码进群。
我也欢迎你留言，分享你的使用经验与困惑，帮助更多开发者更好地融入 AI 协作的新范式。
我是《低代码平台开发实践：基于react》的作者，目前主要关注低代码平台和生成式 AI 的结合，比如：
- 用自然语言生成 UI 组件
- AI 辅助生成前端代码
- 探索 AI 在企业级低代码系统中的标准接入方式
