2026/8/11 7:32:11
FEATURED · 精选文章 
1. 从文档到代码一个AI辅助开发者的日常如果你和我一样是个经常在飞书里写产品需求文档PRD然后转头就要去编辑器里敲代码的开发者那你肯定也幻想过要是PRD能自己变成代码该多好。这听起来像是天方夜谭但过去一年我通过将飞书、AI编程助手比如Cursor、Codex和一些自动化工具串联起来还真摸索出了一套能极大提升效率的“AI编程workflow”。它不是一个全自动的“许愿机”而是一个将需求澄清、原型设计、代码生成和审查验证流程化的“增强回路”。核心价值不在于替代思考而在于将开发者从重复、琐碎的信息搬运和基础代码编写中解放出来让你能更专注于架构设计和核心逻辑。这套流程特别适合独立开发者、创业团队的小步快跑或者任何需要快速将想法落地的场景。简单来说我的工作流始于飞书文档终于可运行的代码仓库中间由AI作为核心的“翻译官”和“初级工程师”。接下来我会拆解这个工作流的每一个环节包括工具选型背后的“为什么”、具体的操作步骤、以及我踩过无数坑才总结出的“避坑指南”。你会发现真正提升效率的往往不是某个单一的“神器”而是一套贴合你习惯的、顺畅的协作机制。2. 工作流基石为什么是飞书AI编程助手在构建任何自动化流程前工具选型是地基。我选择“飞书”作为需求起点“AI编程助手”作为核心引擎是经过深思熟虑和反复对比的绝非随意跟风。2.1 飞书文档不止于PRD的“活”知识库很多人把飞书文档仅仅当作一个在线Word来用那就大材小用了。在我的工作流里飞书文档扮演着唯一可信源的角色。首先飞书文档强大的多维表格、流程图、思维导图嵌入能力能让PRD变得极其结构化。我不再写大段的、模糊的自然语言描述而是用表格定义API接口字段用流程图描述核心业务流程用思维导图梳理功能模块。这种结构化的表达本身就是对需求的第一次“编译”它极大地消除了歧义也为后续AI的理解提供了高质量的、格式清晰的输入。其次飞书的“云文档”属性至关重要。无论是产品经理的修改还是我自己补充的技术设计思考所有迭代都实时同步、版本清晰。我不需要再处理“PRD_v1.2_final_真的最终版.docx”这种令人头疼的文件。更重要的是飞书开放平台提供了完善的API这意味着文档内容可以被程序化地读取和加工这是实现自动化的前提。最后飞书与代码仓库如GitHub、项目管理工具如Jira的集成能力让信息流转成为可能。虽然在我的核心工作流中不直接依赖这些集成但它们为工作流的扩展提供了无限可能。2.2 AI编程助手从Cursor到Codex的选型逻辑AI编程助手是工作流的核心引擎。市面上选择很多我主要深度使用过Cursor和基于OpenAI Codex的各类工具包括早期的GitHub Copilot。我的选择逻辑基于以下几个维度1. 代码生成与理解的“对话感”Cursor在这方面做得非常出色。它不仅仅是一个代码补全工具更是一个可以针对整个项目上下文进行“对话”的编程伙伴。你可以直接打开一个飞书文档链接或粘贴文档内容然后对它说“根据这个PRD为UserService实现一个用户注册方法需要密码加盐哈希并处理用户名重复的情况。” Cursor能够结合你已有的项目代码生成非常贴合上下文的代码片段甚至附带简要的注释。这种基于项目级上下文的“对话式开发”是它区别于传统补全工具的核心优势。2. 对项目全局的感知能力这也是我偏爱Cursor的原因之一。它能分析你打开的所有项目文件在生成代码、回答问题时会综合考虑项目结构、已有的类定义、依赖库等信息。比如你问“怎么在这里集成Redis缓存”它会参考你项目里已有的pom.xml或package.json给出适配你当前技术栈的代码建议而不是通用的模板代码。3. Codex类工具特定场景的利刃以OpenAI Codex为模型的工具包括某些定制化部署的版本在代码生成的“原始能力”上非常强大。对于一些非常明确、模式固定的代码块生成比如根据JSON Schema生成对应的数据模型类POJO/Entity或者根据SQL语句生成CRUD操作代码它们速度极快且准确率高。我的工作流中有时会用一些调用Codex API的脚本工具来处理这类高度结构化的转换任务。选型结论我的主力是Cursor因为它提供了最接近“与资深同事结对编程”的体验。而对于一些批量的、模板化的代码生成任务我会准备一些调用Codex API的脚本作为补充。这并不是说Copilot不好而是在深度项目理解和交互式对话这个特定场景下Cursor的形态更贴合我的需求。注意AI编程助手会消耗Token产生费用。Cursor有免费额度但对于重度使用需要考虑订阅成本。自行调用OpenAI API则更需要精细控制Token用量避免意外账单。3. 核心工作流四步法从PRD到Pull Request我的工作流可以概括为四个步骤需求结构化、AI辅助设计、迭代式开发、审查与集成。每一步都离不开人与AI的协作。3.1 第一步需求结构化与澄清这是所有后续工作的基础也是最容易被忽视的一步。AI不是神给它一堆模糊、矛盾的需求它只能生成一堆模糊、矛盾的代码。操作流程撰写PRD在飞书中使用“用户故事”或“用例”的格式描述功能。例如“作为一个用户我希望能够通过邮箱和密码注册账号以便使用系统服务。” 紧接着使用多维表格来定义“用户”对象的字段username字符串唯一email字符串唯一password_hash字符串等。绘制流程图使用飞书自带的流程图工具画出核心业务的时序图或活动图。比如“用户注册流程图”包括前端提交、后端验证、查重、密码加密、数据入库、发送验证邮件等节点。这个图形化的表达能帮你和AI理清逻辑脉络。定义API契约在文档中用一个独立的章节使用类似OpenAPI的格式即使不写YAML也用清晰的列表定义接口。包括端点URL、HTTP方法、请求体格式JSON示例、响应体格式、可能的错误码。与AI进行“需求评审”将这份结构化的PRD内容或分享文档链接在Cursor中打开然后对它进行提问。我会问“请总结一下这个PRD要实现的三个核心功能点。” “这个注册流程中你认为有哪些边界情况需要处理比如邮箱格式、密码强度、网络超时” AI的回答能帮你发现自己遗漏的细节。这个过程本质上是一个强制性的自我澄清能暴露出PRD中不明确的地方。避坑经验切忌大段粘贴不要将几十页的PRD直接扔给AI。先自己做好摘要和结构化或者分模块、分功能地与之交互。明确专业术语如果你的项目里有“租户”、“SKU”、“溯源链”等特定领域术语先在文档里给出简短定义并在与AI对话时再次明确避免它用通用含义来理解。设定技术栈上下文在第一次就新项目与Cursor对话时先用一句话明确技术栈“本项目是一个基于Spring Boot 3的Java后端项目使用MySQL数据库MyBatis-Plus作为ORM框架。” 这能确保后续生成的代码在技术选型上是正确的。3.2 第二步AI辅助设计与原型生成需求清晰后并不直接开始写业务代码而是先进行高层设计和生成基础代码结构。操作流程生成系统设计在Cursor中基于PRD提问“基于上述需求请为一个微服务架构的后台管理系统设计用户模块的代码目录结构package structure并说明每个目录的职责。” AI会给出类似com.example.user.controller,.service,.mapper,.entity,.dto等的建议你可以在此基础上调整。创建基础文件根据AI建议的目录结构在项目中手动创建这些空的包和文件。然后可以开始让AI填充内容。生成数据模型Entity将PRD中定义字段的多维表格内容复制给Cursor并指令“根据以下字段定义生成对应的Java Entity类使用Lombok注解并包含JPA注解Entity,Table。” 它就能快速生成近乎完美的User.java。生成API接口骨架Controller/DTO将API契约部分复制给Cursor指令“根据这个API定义生成Spring Boot的Controller类和对应的请求/响应DTO类。” AI会生成带有RestController,PostMapping等注解的骨架代码以及UserRegisterRequest、UserResponse等DTO类。生成数据库访问层Mapper/Repository指令“为User实体生成一个MyBatis-Plus的Mapper接口。” 这通常是一个简单的接口继承自BaseMapperUser。至此一个包含Controller、Service接口、Entity、DTO、Mapper的空项目骨架就搭建好了。整个过程可能只需要十几分钟而手动创建这些文件并确保注解正确可能需要更长时间且容易出错。3.3 第三步迭代式开发与“对话调试”这是工作流的核心循环也是最体现“增强”而非“替代”的环节。AI负责生成代码草案和提供建议我负责决策、修改和整合。操作流程实现Service层逻辑打开之前生成的UserService接口在Cursor中定位到需要实现的方法然后使用CmdKMac或CtrlKWindows打开Chat面板输入具体的实现要求“请实现这个register方法需要检查邮箱和用户名是否已存在密码使用BCrypt加密将用户信息保存到数据库并返回用户ID。注入UserMapper和PasswordEncoder。” AI会生成完整的Service方法代码。代码审查与修改绝对不要直接接受AI生成的代码。把它当作一个初级工程师提交的代码进行仔细审查。我会检查逻辑是否正确特别是边界条件、异常处理是否完备是否捕获了可能的数据层异常、性能是否有问题比如在循环里查询数据库、是否符合项目编码规范比如日志打印格式、常量定义。发现问题后可以直接在Chat里指出“这里密码加密前应该先做非空校验。”或者“重复性检查应该放在一个事务里避免并发注册问题。” AI会根据你的反馈修改代码。“对话调试”与逻辑补全当遇到复杂逻辑时可以和AI进行多轮对话。例如“我需要在用户注册成功后异步发送一个欢迎邮件。请帮我修改代码引入一个MailService并使用Spring的Async实现异步发送。同时需要考虑邮件发送失败后的补偿机制比如记录日志稍后重试。” AI不仅能修改代码还能解释它为什么这样改这本身就是一个学习过程。生成单元测试这是AI非常擅长的领域。在写完一个Service方法后可以指令“为这个UserService.register方法生成JUnit 5的单元测试使用Mockito模拟UserMapper和PasswordEncoder并覆盖成功、用户名重复、邮箱重复等场景。” AI生成的测试用例通常结构良好能覆盖主要分支你只需要稍作调整即可。核心心法在这个阶段我的角色是架构师和审查者AI的角色是快速的执行者和想法的碰撞者。我提出“做什么”和“做到什么标准”AI提供“怎么做”的多个选项我来选择和优化。3.4 第四步自动化集成与知识沉淀当功能开发完成后工作流并未结束还需要将代码整合到团队协作流程中并沉淀经验。操作流程运行与测试在本地运行生成的单元测试和集成测试确保功能正常。AI生成的代码有时会遗漏一些Spring上下文依赖或配置需要手动补全比如在测试类上加SpringBootTest。提交代码使用Git命令行或IDE工具提交代码。提交信息Commit Message也可以让AI帮忙润色使其更规范。可选自动化流水线如果团队有CI/CD这一步是自动的。但我个人会配置一个简单的Git钩子pre-commit在提交前自动运行代码格式化工具如Spotless和静态检查如SonarLint确保代码风格统一。知识沉淀回飞书这是一个非常重要的闭环。在飞书的PRD文档末尾我会新增一个“技术实现纪要”章节。记录下本次开发中AI生成的哪些代码模式特别好用例如一种优雅的异常处理方式。遇到了哪些典型的“AI坑”例如AI可能会生成过时的API用法。针对某个复杂逻辑与AI进行了几轮对话才最终厘清。本次开发中手动修改最多的部分是哪里这往往是业务逻辑最复杂或AI最不擅长的部分。 这份纪要会成为未来类似需求开发的宝贵经验也能帮助团队其他成员更快上手这套工作流。4. 实战避坑那些只有踩过才知道的“坑”这套工作流听起来很美好但在实际落地中我遇到了无数挑战。下面分享几个最具代表性的“坑”及其解决方案。4.1 坑一AI的“幻觉”与逻辑缺失AI特别是大型语言模型存在“幻觉”问题即它会生成看似合理但完全错误或不符合事实的代码。典型案例让AI生成一个“根据用户ID分页查询订单”的SQL语句。它可能会生成语法完全正确的SQL但却使用了项目中不存在的表名或字段名。或者在生成Java代码时使用了一个不存在的方法或类而且这个方法的命名看起来非常“合理”。我的应对策略永远保持怀疑对AI生成的每一行代码尤其是涉及核心逻辑、第三方库API调用、数据库操作的部分必须进行验证。不要假设它是正确的。要求AI提供解释或出处在Cursor中可以追问“你生成的这个Cacheable注解的keyGenerator参数具体指向哪个Bean请在我现有的项目代码中找出来或者告诉我需要如何配置。” 如果AI无法在上下文中找到它通常会承认并给出更正建议。小步快跑即时验证不要让它一次性生成一个几百行的复杂类。应该分模块、分方法地生成生成一个方法就立刻在IDE里检查是否有编译错误逻辑是否符合预期。建立“安全清单”对于你已知的、AI容易出错的点比如特定的日期处理、复杂的多线程同步在开发时格外警惕甚至预先写好注释或TODO提醒自己这里需要手动重点检查。4.2 坑二上下文丢失与“失忆”AI工具有上下文窗口限制。在开发一个大型功能时你可能会和AI进行长达几十轮对话。有时它会“忘记”很早之前约定的技术栈、项目结构或业务规则。典型案例在讨论了半小时如何用Redis缓存用户会话后你让它生成一个工具类它可能会忽略之前约定的Jackson序列化方式而使用默认的Java序列化导致缓存读取失败。我的应对策略重要的上下文反复重申在开始一个新的、相对独立的子任务时即使在同一对话中也重新用一两句话声明核心前提。例如“我们继续在之前的Spring Boot用户项目里工作现在需要实现一个登录日志功能请记住我们使用MySQL和MyBatis-Plus。”使用“项目知识库”功能像Cursor允许你上传项目文件作为永久上下文。将项目的关键配置文件如application.yml、pom.xml、核心的架构说明文档上传能有效减少“失忆”。分会话进行对于逻辑上相对独立的大模块可以开启新的Chat会话。在新的会话中首先通过“/”命令将相关文件设置为上下文然后开始工作。这样能保证该会话内的上下文纯净且充足。4.3 坑三代码风格与项目规范冲突AI基于海量公开代码训练其默认代码风格可能与你所在团队的规范冲突。典型案例AI可能生成使用java.util.Date的代码而你的团队规范要求必须使用java.time包下的新API。或者AI生成的日志语句是System.out.println而你们要求用SLF4J。我的应对策略在指令中明确规范在第一次对话或生成重要代码前明确给出规范。例如“请使用java.time.LocalDateTime处理时间。” “所有日志请使用log.info()并确保log是org.slf4j.Logger的实例。”利用IDE的格式化工具在代码生成后统一使用项目配置的代码格式化工具如IntelliJ IDEA的Reformat Code或Spotless、Prettier进行格式化可以快速解决缩进、空格、换行等基础风格问题。创建代码模板或片段对于项目中反复出现的、有固定模式的代码如Controller的通用响应包装、统一异常处理可以自己写好模板或者让AI学习这些模板。在Cursor中你可以选中一段符合规范的代码然后告诉AI“以后生成类似功能的代码时请参考这种风格和模式。”4.4 坑四对业务复杂性的理解不足AI擅长处理模式化的、技术性的任务但对于深度的、充满例外和特殊规则的业务逻辑它往往力不从心。典型案例一个电商的优惠券计算规则可能包含“商品品类限制”、“用户等级叠加”、“限时折扣并行计算”、“满减门槛”等一系列复杂且互斥的规则。AI很难一次性理解所有这些规则并生成正确的代码。我的应对策略人类负责业务规则拆解这是必须由人来完成的工作。你需要将复杂的业务规则拆解成一个个清晰的、可执行的步骤或决策树。这个拆解过程本身也是对业务的再理解。让AI实现“零件”将拆解后的规则变成一个个独立的方法或函数描述让AI去实现这些“零件”。例如“请写一个方法输入商品ID列表返回这些商品是否都属于‘电子产品’品类。” “请写一个方法根据用户历史订单金额计算其当前等级。”人类负责“组装”与“协调”由你来编写主流程代码调用这些由AI生成的“零件”方法并处理它们之间的协调关系、异常传递和事务边界。业务复杂性的核心在于“组装逻辑”这部分目前必须由人来掌控。5. 进阶技巧让工作流更智能高效在熟练运用基础工作流后可以通过一些进阶技巧进一步释放生产力。5.1 构建可复用的“提示词Prompt库”你会发现很多指令是重复的。比如“生成Spring Boot Entity”、“生成MyBatis-Plus Mapper”、“生成单元测试”。你可以将这些高频、有效的指令保存下来形成一个你自己的“提示词库”。我的做法在飞书或任何笔记软件里建立一个“AI开发提示词”文档。分类存放例如项目初始化类“初始化一个Spring Boot Web项目结构包含controller, service, mapper, entity, dto包。”代码生成类“根据以下JSON示例生成对应的Java DTO类使用Lombok的Data注解。”代码审查类“审查以下代码找出可能的空指针异常、资源未关闭问题并提供修改建议。”调试求助类“我遇到了一个TransactionRollbackException以下是相关代码和错误堆栈请分析可能的原因。”下次需要时直接复制粘贴稍作修改即可省去了重新组织语言的时间。5.2 利用飞书机器人实现轻度自动化飞书开放平台能力强大可以实现一些轻量级的自动化将工作流串联得更紧密。一个简单场景自动将PRD中的API定义转换成Markdown格式的接口文档。写一个简单的脚本Python或Node.js调用飞书API读取文档指定区块的内容。使用正则表达式或解析库提取出接口定义URL, Method, Request, Response。调用OpenAI的Chat Completion API使用gpt-3.5-turbo即可提示它“将以下文本格式的API描述转化为标准的Markdown表格形式。” 然后将结果写入一个api.md文件或直接发布到团队的Wiki。 这个脚本可以配置在本地通过一个命令触发实现“一键生成接口文档草稿”。更进阶的想法你可以创建一个飞书机器人当你在PRD文档中这个机器人并输入“生成项目骨架”时机器人自动读取文档调用AI服务生成基础代码并提交到一个新的Git分支然后在飞书群里通知你。这需要更多的开发工作量但代表了未来AI工作流的方向无缝、自然的人机交互。5.3 将AI作为“学习伙伴”与“技术雷达”除了写代码我经常用AI来快速学习新技术或评估技术选型。学习新技术当需要在项目中使用一个我不太熟悉的库比如Apache Kafka我会在Cursor中问“用简单的例子解释一下Kafka的Producer和Consumer在Spring Boot中如何配置和使用。” 然后让它基于我当前的项目依赖生成一个可运行的配置示例和代码片段。这比漫无目的地搜索文档要高效得多。技术选型咨询“为了做一个实时通知功能在WebSocket和Server-Sent EventsSSE之间从实现复杂度、浏览器兼容性、消息模型的角度我该如何选择” AI能提供一个结构化的对比帮助我快速做出初步判断。当然最终决策还需要查阅官方文档和社区反馈但AI提供了一个高质量的起点。6. 心态调整与AI协作的正确姿势最后也是最重要的一点是开发者自身心态的转变。拥抱AI编程不是交出控制权而是升级你的武器库。1. 从“编写者”到“设计者与审查者”你的核心价值不再是逐行敲出for循环和if-else语句而是定义清晰的问题边界、设计优雅的架构、制定严谨的规范并对最终产出的代码质量负全责。AI是强大的执行工具但方向盘和刹车始终在你手里。2. 接受“不完美”追求“快速迭代”AI生成的代码很少是100%完美、可直接交付的。接受这一点把第一版AI代码看作一个“可运行的草稿”。你的目标不是一次得到终极代码而是快速得到一个可以讨论、可以测试、可以迭代的基础。开发周期从“长时间编写”变为“短时间生成审查修改”整体迭代速度反而更快。3. 培养“提问的能力”与AI协作的效率极大程度上取决于你“提问”的质量。模糊的问题得到模糊的答案精确的问题得到精确的代码。学会如何将复杂问题拆解成AI能理解的、结构化的指令是一项新的核心技能。这本质上锻炼的是你的逻辑思维和沟通能力。4. 保持学习保持批判AI工具迭代速度极快新的模型、新的功能层出不穷。需要保持关注和学习。同时对AI生成的内容要保持技术人的批判性思维。它给出的方案不一定是最优解它推荐的库可能有更现代的替代品。你的经验和判断力是AI无法替代的护城河。这套“从飞书PRD到代码实现”的AI编程工作流已经深度融入我的日常开发。它没有让我失业而是让我能更专注于那些真正需要创造力、深度思考和复杂决策的部分。它处理了那些我“知道怎么做但懒得写”的模板代码让我有更多时间去思考系统扩展性、业务瓶颈和用户体验。如果你也厌倦了在文档和代码间反复横跳不妨尝试构建属于你自己的AI增强工作流它很可能成为你职业生涯中一次重要的效率革命。
AI编程实战：从飞书PRD到代码生成的高效工作流设计
1. 从文档到代码一个AI辅助开发者的日常如果你和我一样是个经常在飞书里写产品需求文档PRD然后转头就要去编辑器里敲代码的开发者那你肯定也幻想过要是PRD能自己变成代码该多好。这听起来像是天方夜谭但过去一年我通过将飞书、AI编程助手比如Cursor、Codex和一些自动化工具串联起来还真摸索出了一套能极大提升效率的“AI编程workflow”。它不是一个全自动的“许愿机”而是一个将需求澄清、原型设计、代码生成和审查验证流程化的“增强回路”。核心价值不在于替代思考而在于将开发者从重复、琐碎的信息搬运和基础代码编写中解放出来让你能更专注于架构设计和核心逻辑。这套流程特别适合独立开发者、创业团队的小步快跑或者任何需要快速将想法落地的场景。简单来说我的工作流始于飞书文档终于可运行的代码仓库中间由AI作为核心的“翻译官”和“初级工程师”。接下来我会拆解这个工作流的每一个环节包括工具选型背后的“为什么”、具体的操作步骤、以及我踩过无数坑才总结出的“避坑指南”。你会发现真正提升效率的往往不是某个单一的“神器”而是一套贴合你习惯的、顺畅的协作机制。2. 工作流基石为什么是飞书AI编程助手在构建任何自动化流程前工具选型是地基。我选择“飞书”作为需求起点“AI编程助手”作为核心引擎是经过深思熟虑和反复对比的绝非随意跟风。2.1 飞书文档不止于PRD的“活”知识库很多人把飞书文档仅仅当作一个在线Word来用那就大材小用了。在我的工作流里飞书文档扮演着唯一可信源的角色。首先飞书文档强大的多维表格、流程图、思维导图嵌入能力能让PRD变得极其结构化。我不再写大段的、模糊的自然语言描述而是用表格定义API接口字段用流程图描述核心业务流程用思维导图梳理功能模块。这种结构化的表达本身就是对需求的第一次“编译”它极大地消除了歧义也为后续AI的理解提供了高质量的、格式清晰的输入。其次飞书的“云文档”属性至关重要。无论是产品经理的修改还是我自己补充的技术设计思考所有迭代都实时同步、版本清晰。我不需要再处理“PRD_v1.2_final_真的最终版.docx”这种令人头疼的文件。更重要的是飞书开放平台提供了完善的API这意味着文档内容可以被程序化地读取和加工这是实现自动化的前提。最后飞书与代码仓库如GitHub、项目管理工具如Jira的集成能力让信息流转成为可能。虽然在我的核心工作流中不直接依赖这些集成但它们为工作流的扩展提供了无限可能。2.2 AI编程助手从Cursor到Codex的选型逻辑AI编程助手是工作流的核心引擎。市面上选择很多我主要深度使用过Cursor和基于OpenAI Codex的各类工具包括早期的GitHub Copilot。我的选择逻辑基于以下几个维度1. 代码生成与理解的“对话感”Cursor在这方面做得非常出色。它不仅仅是一个代码补全工具更是一个可以针对整个项目上下文进行“对话”的编程伙伴。你可以直接打开一个飞书文档链接或粘贴文档内容然后对它说“根据这个PRD为UserService实现一个用户注册方法需要密码加盐哈希并处理用户名重复的情况。” Cursor能够结合你已有的项目代码生成非常贴合上下文的代码片段甚至附带简要的注释。这种基于项目级上下文的“对话式开发”是它区别于传统补全工具的核心优势。2. 对项目全局的感知能力这也是我偏爱Cursor的原因之一。它能分析你打开的所有项目文件在生成代码、回答问题时会综合考虑项目结构、已有的类定义、依赖库等信息。比如你问“怎么在这里集成Redis缓存”它会参考你项目里已有的pom.xml或package.json给出适配你当前技术栈的代码建议而不是通用的模板代码。3. Codex类工具特定场景的利刃以OpenAI Codex为模型的工具包括某些定制化部署的版本在代码生成的“原始能力”上非常强大。对于一些非常明确、模式固定的代码块生成比如根据JSON Schema生成对应的数据模型类POJO/Entity或者根据SQL语句生成CRUD操作代码它们速度极快且准确率高。我的工作流中有时会用一些调用Codex API的脚本工具来处理这类高度结构化的转换任务。选型结论我的主力是Cursor因为它提供了最接近“与资深同事结对编程”的体验。而对于一些批量的、模板化的代码生成任务我会准备一些调用Codex API的脚本作为补充。这并不是说Copilot不好而是在深度项目理解和交互式对话这个特定场景下Cursor的形态更贴合我的需求。注意AI编程助手会消耗Token产生费用。Cursor有免费额度但对于重度使用需要考虑订阅成本。自行调用OpenAI API则更需要精细控制Token用量避免意外账单。3. 核心工作流四步法从PRD到Pull Request我的工作流可以概括为四个步骤需求结构化、AI辅助设计、迭代式开发、审查与集成。每一步都离不开人与AI的协作。3.1 第一步需求结构化与澄清这是所有后续工作的基础也是最容易被忽视的一步。AI不是神给它一堆模糊、矛盾的需求它只能生成一堆模糊、矛盾的代码。操作流程撰写PRD在飞书中使用“用户故事”或“用例”的格式描述功能。例如“作为一个用户我希望能够通过邮箱和密码注册账号以便使用系统服务。” 紧接着使用多维表格来定义“用户”对象的字段username字符串唯一email字符串唯一password_hash字符串等。绘制流程图使用飞书自带的流程图工具画出核心业务的时序图或活动图。比如“用户注册流程图”包括前端提交、后端验证、查重、密码加密、数据入库、发送验证邮件等节点。这个图形化的表达能帮你和AI理清逻辑脉络。定义API契约在文档中用一个独立的章节使用类似OpenAPI的格式即使不写YAML也用清晰的列表定义接口。包括端点URL、HTTP方法、请求体格式JSON示例、响应体格式、可能的错误码。与AI进行“需求评审”将这份结构化的PRD内容或分享文档链接在Cursor中打开然后对它进行提问。我会问“请总结一下这个PRD要实现的三个核心功能点。” “这个注册流程中你认为有哪些边界情况需要处理比如邮箱格式、密码强度、网络超时” AI的回答能帮你发现自己遗漏的细节。这个过程本质上是一个强制性的自我澄清能暴露出PRD中不明确的地方。避坑经验切忌大段粘贴不要将几十页的PRD直接扔给AI。先自己做好摘要和结构化或者分模块、分功能地与之交互。明确专业术语如果你的项目里有“租户”、“SKU”、“溯源链”等特定领域术语先在文档里给出简短定义并在与AI对话时再次明确避免它用通用含义来理解。设定技术栈上下文在第一次就新项目与Cursor对话时先用一句话明确技术栈“本项目是一个基于Spring Boot 3的Java后端项目使用MySQL数据库MyBatis-Plus作为ORM框架。” 这能确保后续生成的代码在技术选型上是正确的。3.2 第二步AI辅助设计与原型生成需求清晰后并不直接开始写业务代码而是先进行高层设计和生成基础代码结构。操作流程生成系统设计在Cursor中基于PRD提问“基于上述需求请为一个微服务架构的后台管理系统设计用户模块的代码目录结构package structure并说明每个目录的职责。” AI会给出类似com.example.user.controller,.service,.mapper,.entity,.dto等的建议你可以在此基础上调整。创建基础文件根据AI建议的目录结构在项目中手动创建这些空的包和文件。然后可以开始让AI填充内容。生成数据模型Entity将PRD中定义字段的多维表格内容复制给Cursor并指令“根据以下字段定义生成对应的Java Entity类使用Lombok注解并包含JPA注解Entity,Table。” 它就能快速生成近乎完美的User.java。生成API接口骨架Controller/DTO将API契约部分复制给Cursor指令“根据这个API定义生成Spring Boot的Controller类和对应的请求/响应DTO类。” AI会生成带有RestController,PostMapping等注解的骨架代码以及UserRegisterRequest、UserResponse等DTO类。生成数据库访问层Mapper/Repository指令“为User实体生成一个MyBatis-Plus的Mapper接口。” 这通常是一个简单的接口继承自BaseMapperUser。至此一个包含Controller、Service接口、Entity、DTO、Mapper的空项目骨架就搭建好了。整个过程可能只需要十几分钟而手动创建这些文件并确保注解正确可能需要更长时间且容易出错。3.3 第三步迭代式开发与“对话调试”这是工作流的核心循环也是最体现“增强”而非“替代”的环节。AI负责生成代码草案和提供建议我负责决策、修改和整合。操作流程实现Service层逻辑打开之前生成的UserService接口在Cursor中定位到需要实现的方法然后使用CmdKMac或CtrlKWindows打开Chat面板输入具体的实现要求“请实现这个register方法需要检查邮箱和用户名是否已存在密码使用BCrypt加密将用户信息保存到数据库并返回用户ID。注入UserMapper和PasswordEncoder。” AI会生成完整的Service方法代码。代码审查与修改绝对不要直接接受AI生成的代码。把它当作一个初级工程师提交的代码进行仔细审查。我会检查逻辑是否正确特别是边界条件、异常处理是否完备是否捕获了可能的数据层异常、性能是否有问题比如在循环里查询数据库、是否符合项目编码规范比如日志打印格式、常量定义。发现问题后可以直接在Chat里指出“这里密码加密前应该先做非空校验。”或者“重复性检查应该放在一个事务里避免并发注册问题。” AI会根据你的反馈修改代码。“对话调试”与逻辑补全当遇到复杂逻辑时可以和AI进行多轮对话。例如“我需要在用户注册成功后异步发送一个欢迎邮件。请帮我修改代码引入一个MailService并使用Spring的Async实现异步发送。同时需要考虑邮件发送失败后的补偿机制比如记录日志稍后重试。” AI不仅能修改代码还能解释它为什么这样改这本身就是一个学习过程。生成单元测试这是AI非常擅长的领域。在写完一个Service方法后可以指令“为这个UserService.register方法生成JUnit 5的单元测试使用Mockito模拟UserMapper和PasswordEncoder并覆盖成功、用户名重复、邮箱重复等场景。” AI生成的测试用例通常结构良好能覆盖主要分支你只需要稍作调整即可。核心心法在这个阶段我的角色是架构师和审查者AI的角色是快速的执行者和想法的碰撞者。我提出“做什么”和“做到什么标准”AI提供“怎么做”的多个选项我来选择和优化。3.4 第四步自动化集成与知识沉淀当功能开发完成后工作流并未结束还需要将代码整合到团队协作流程中并沉淀经验。操作流程运行与测试在本地运行生成的单元测试和集成测试确保功能正常。AI生成的代码有时会遗漏一些Spring上下文依赖或配置需要手动补全比如在测试类上加SpringBootTest。提交代码使用Git命令行或IDE工具提交代码。提交信息Commit Message也可以让AI帮忙润色使其更规范。可选自动化流水线如果团队有CI/CD这一步是自动的。但我个人会配置一个简单的Git钩子pre-commit在提交前自动运行代码格式化工具如Spotless和静态检查如SonarLint确保代码风格统一。知识沉淀回飞书这是一个非常重要的闭环。在飞书的PRD文档末尾我会新增一个“技术实现纪要”章节。记录下本次开发中AI生成的哪些代码模式特别好用例如一种优雅的异常处理方式。遇到了哪些典型的“AI坑”例如AI可能会生成过时的API用法。针对某个复杂逻辑与AI进行了几轮对话才最终厘清。本次开发中手动修改最多的部分是哪里这往往是业务逻辑最复杂或AI最不擅长的部分。 这份纪要会成为未来类似需求开发的宝贵经验也能帮助团队其他成员更快上手这套工作流。4. 实战避坑那些只有踩过才知道的“坑”这套工作流听起来很美好但在实际落地中我遇到了无数挑战。下面分享几个最具代表性的“坑”及其解决方案。4.1 坑一AI的“幻觉”与逻辑缺失AI特别是大型语言模型存在“幻觉”问题即它会生成看似合理但完全错误或不符合事实的代码。典型案例让AI生成一个“根据用户ID分页查询订单”的SQL语句。它可能会生成语法完全正确的SQL但却使用了项目中不存在的表名或字段名。或者在生成Java代码时使用了一个不存在的方法或类而且这个方法的命名看起来非常“合理”。我的应对策略永远保持怀疑对AI生成的每一行代码尤其是涉及核心逻辑、第三方库API调用、数据库操作的部分必须进行验证。不要假设它是正确的。要求AI提供解释或出处在Cursor中可以追问“你生成的这个Cacheable注解的keyGenerator参数具体指向哪个Bean请在我现有的项目代码中找出来或者告诉我需要如何配置。” 如果AI无法在上下文中找到它通常会承认并给出更正建议。小步快跑即时验证不要让它一次性生成一个几百行的复杂类。应该分模块、分方法地生成生成一个方法就立刻在IDE里检查是否有编译错误逻辑是否符合预期。建立“安全清单”对于你已知的、AI容易出错的点比如特定的日期处理、复杂的多线程同步在开发时格外警惕甚至预先写好注释或TODO提醒自己这里需要手动重点检查。4.2 坑二上下文丢失与“失忆”AI工具有上下文窗口限制。在开发一个大型功能时你可能会和AI进行长达几十轮对话。有时它会“忘记”很早之前约定的技术栈、项目结构或业务规则。典型案例在讨论了半小时如何用Redis缓存用户会话后你让它生成一个工具类它可能会忽略之前约定的Jackson序列化方式而使用默认的Java序列化导致缓存读取失败。我的应对策略重要的上下文反复重申在开始一个新的、相对独立的子任务时即使在同一对话中也重新用一两句话声明核心前提。例如“我们继续在之前的Spring Boot用户项目里工作现在需要实现一个登录日志功能请记住我们使用MySQL和MyBatis-Plus。”使用“项目知识库”功能像Cursor允许你上传项目文件作为永久上下文。将项目的关键配置文件如application.yml、pom.xml、核心的架构说明文档上传能有效减少“失忆”。分会话进行对于逻辑上相对独立的大模块可以开启新的Chat会话。在新的会话中首先通过“/”命令将相关文件设置为上下文然后开始工作。这样能保证该会话内的上下文纯净且充足。4.3 坑三代码风格与项目规范冲突AI基于海量公开代码训练其默认代码风格可能与你所在团队的规范冲突。典型案例AI可能生成使用java.util.Date的代码而你的团队规范要求必须使用java.time包下的新API。或者AI生成的日志语句是System.out.println而你们要求用SLF4J。我的应对策略在指令中明确规范在第一次对话或生成重要代码前明确给出规范。例如“请使用java.time.LocalDateTime处理时间。” “所有日志请使用log.info()并确保log是org.slf4j.Logger的实例。”利用IDE的格式化工具在代码生成后统一使用项目配置的代码格式化工具如IntelliJ IDEA的Reformat Code或Spotless、Prettier进行格式化可以快速解决缩进、空格、换行等基础风格问题。创建代码模板或片段对于项目中反复出现的、有固定模式的代码如Controller的通用响应包装、统一异常处理可以自己写好模板或者让AI学习这些模板。在Cursor中你可以选中一段符合规范的代码然后告诉AI“以后生成类似功能的代码时请参考这种风格和模式。”4.4 坑四对业务复杂性的理解不足AI擅长处理模式化的、技术性的任务但对于深度的、充满例外和特殊规则的业务逻辑它往往力不从心。典型案例一个电商的优惠券计算规则可能包含“商品品类限制”、“用户等级叠加”、“限时折扣并行计算”、“满减门槛”等一系列复杂且互斥的规则。AI很难一次性理解所有这些规则并生成正确的代码。我的应对策略人类负责业务规则拆解这是必须由人来完成的工作。你需要将复杂的业务规则拆解成一个个清晰的、可执行的步骤或决策树。这个拆解过程本身也是对业务的再理解。让AI实现“零件”将拆解后的规则变成一个个独立的方法或函数描述让AI去实现这些“零件”。例如“请写一个方法输入商品ID列表返回这些商品是否都属于‘电子产品’品类。” “请写一个方法根据用户历史订单金额计算其当前等级。”人类负责“组装”与“协调”由你来编写主流程代码调用这些由AI生成的“零件”方法并处理它们之间的协调关系、异常传递和事务边界。业务复杂性的核心在于“组装逻辑”这部分目前必须由人来掌控。5. 进阶技巧让工作流更智能高效在熟练运用基础工作流后可以通过一些进阶技巧进一步释放生产力。5.1 构建可复用的“提示词Prompt库”你会发现很多指令是重复的。比如“生成Spring Boot Entity”、“生成MyBatis-Plus Mapper”、“生成单元测试”。你可以将这些高频、有效的指令保存下来形成一个你自己的“提示词库”。我的做法在飞书或任何笔记软件里建立一个“AI开发提示词”文档。分类存放例如项目初始化类“初始化一个Spring Boot Web项目结构包含controller, service, mapper, entity, dto包。”代码生成类“根据以下JSON示例生成对应的Java DTO类使用Lombok的Data注解。”代码审查类“审查以下代码找出可能的空指针异常、资源未关闭问题并提供修改建议。”调试求助类“我遇到了一个TransactionRollbackException以下是相关代码和错误堆栈请分析可能的原因。”下次需要时直接复制粘贴稍作修改即可省去了重新组织语言的时间。5.2 利用飞书机器人实现轻度自动化飞书开放平台能力强大可以实现一些轻量级的自动化将工作流串联得更紧密。一个简单场景自动将PRD中的API定义转换成Markdown格式的接口文档。写一个简单的脚本Python或Node.js调用飞书API读取文档指定区块的内容。使用正则表达式或解析库提取出接口定义URL, Method, Request, Response。调用OpenAI的Chat Completion API使用gpt-3.5-turbo即可提示它“将以下文本格式的API描述转化为标准的Markdown表格形式。” 然后将结果写入一个api.md文件或直接发布到团队的Wiki。 这个脚本可以配置在本地通过一个命令触发实现“一键生成接口文档草稿”。更进阶的想法你可以创建一个飞书机器人当你在PRD文档中这个机器人并输入“生成项目骨架”时机器人自动读取文档调用AI服务生成基础代码并提交到一个新的Git分支然后在飞书群里通知你。这需要更多的开发工作量但代表了未来AI工作流的方向无缝、自然的人机交互。5.3 将AI作为“学习伙伴”与“技术雷达”除了写代码我经常用AI来快速学习新技术或评估技术选型。学习新技术当需要在项目中使用一个我不太熟悉的库比如Apache Kafka我会在Cursor中问“用简单的例子解释一下Kafka的Producer和Consumer在Spring Boot中如何配置和使用。” 然后让它基于我当前的项目依赖生成一个可运行的配置示例和代码片段。这比漫无目的地搜索文档要高效得多。技术选型咨询“为了做一个实时通知功能在WebSocket和Server-Sent EventsSSE之间从实现复杂度、浏览器兼容性、消息模型的角度我该如何选择” AI能提供一个结构化的对比帮助我快速做出初步判断。当然最终决策还需要查阅官方文档和社区反馈但AI提供了一个高质量的起点。6. 心态调整与AI协作的正确姿势最后也是最重要的一点是开发者自身心态的转变。拥抱AI编程不是交出控制权而是升级你的武器库。1. 从“编写者”到“设计者与审查者”你的核心价值不再是逐行敲出for循环和if-else语句而是定义清晰的问题边界、设计优雅的架构、制定严谨的规范并对最终产出的代码质量负全责。AI是强大的执行工具但方向盘和刹车始终在你手里。2. 接受“不完美”追求“快速迭代”AI生成的代码很少是100%完美、可直接交付的。接受这一点把第一版AI代码看作一个“可运行的草稿”。你的目标不是一次得到终极代码而是快速得到一个可以讨论、可以测试、可以迭代的基础。开发周期从“长时间编写”变为“短时间生成审查修改”整体迭代速度反而更快。3. 培养“提问的能力”与AI协作的效率极大程度上取决于你“提问”的质量。模糊的问题得到模糊的答案精确的问题得到精确的代码。学会如何将复杂问题拆解成AI能理解的、结构化的指令是一项新的核心技能。这本质上锻炼的是你的逻辑思维和沟通能力。4. 保持学习保持批判AI工具迭代速度极快新的模型、新的功能层出不穷。需要保持关注和学习。同时对AI生成的内容要保持技术人的批判性思维。它给出的方案不一定是最优解它推荐的库可能有更现代的替代品。你的经验和判断力是AI无法替代的护城河。这套“从飞书PRD到代码实现”的AI编程工作流已经深度融入我的日常开发。它没有让我失业而是让我能更专注于那些真正需要创造力、深度思考和复杂决策的部分。它处理了那些我“知道怎么做但懒得写”的模板代码让我有更多时间去思考系统扩展性、业务瓶颈和用户体验。如果你也厌倦了在文档和代码间反复横跳不妨尝试构建属于你自己的AI增强工作流它很可能成为你职业生涯中一次重要的效率革命。 
