2025-06-21 基于 AI 的快速软件开发流程

UP主: 少个分号 · 时长: 2h52m · 🔗 B站原视频

标签: AI编程 · 软件开发 · MVP · 效率提升 · 大模型应用

传统开发模式向 AI 工具链的转型背景

各位好，今天主要给大家分享的主题是关于基于 AI 工具链的快速软件开发流程。

近一个月我们在近期将整个开发模式由传统软件开发完全切换到了基于各种 AI 工具链。无论是快速搭建产品的 MVP，还是将 MVP 迭代成最终产品，我们做了一部分实践，整体效率提升以及开发人员的反馈都特别不错。所以想借此机会给大家做个分享，一块讨论未来大模型和 AI 应用爆炸式增长下的开发模式。

最开始我在将近 5 年前在上海做计算机视觉（CV）。当时给我的感觉是，大家在 CV 领域的技术力其实拉不开很大差距，更多是从产品角度考虑如何更好地服务客户、解决痛点。但自从 ChatGPT 出来之后，短短三四年内大模型的发展速度，对于我之前做 CV 的人来讲，震撼是不可言喻的。完全没有想到 AI 的发展可以这么迅速。

后来我去做产品时，体验了各大厂的 AI 工具，带给我的效果和体验与之前完全不同。往年我们做产品要经过非常冗长的设计到编码的流程，周期长短受团队技术力差异影响很大。但现在完全切换到基于 AI 的开发工具链后，最大的感受是想法落地不再困难。以前说从 0 到 1 最难，现在只要地基搭好，从 1 到 100 通过不断迭代去盖楼其实都不困难。

现在市面上的 AI 产品一波接一波出现，如果我们还抱着之前的开发理念，是完全跟不上时代的。

基于 AI Agent 的完整开发工作流

我们是怎么做基于 AI Agent 的完整开发工作流的呢？

首先，重心依然是编写产品需求。以前产品需求由产品经理写 PRD 文档，交给技术经理转化为技术设计，再由研发人员编码实现。我本身是开发出身，对文档比较关注，但有些开发同行其实不太关注文档的重要性。当我们完全基于 AI Agent 工作流时，文档的重要性远比代码怎么设计更重要。因为 AI Agent 担当的是开发同伴的角色，非常考验开发人员的表达能力，怎么把想要的东西描述清楚。所以在 AI Agent 开发工作流中，文档占比的重要性特别高。目前产品需求还是由专职产品经理来写，因为只有产品经理才清楚究竟想要什么。

第二步是原型设计。我们会采用 UI 设计工具（如 Stitch），它是一个由大模型驱动的 UI 设计平台。它可以根据我们描述的产品需求（需求本身就是提示词）转化成视觉设计，智能布局并生成组件，保证设计一致性。有了 UI 设计后，我们会拿去跟客户沟通确认。确认后，将其导出成 Figma 工程。

第三步是代码生成。有了 Figma 工程后，我们会采用 Vercel 推出的 v0 平台。v0 可以通过 Figma 工程直接生成基于 React 或 Next.js 的现代前端界面代码，包含布局、样式（如 Tailwind）和简单的交互，并且会自动做移动端响应式适配。

第四步是业务逻辑开发。把 v0 生成的工程拉下来放到 GitLab 或 Git 等代码托管工具里，然后基于 Cursor 完成剩余的代码开发。因为 v0 专注于前端工程，实际的业务逻辑还需要开发人员通过 Cursor 配合一个叫 RAP5 的协议（提示词）来完成。

最后是持续迭代改进。整个生态链比以往手写代码更加高效，设计门槛大大降低，设计的调整也不再是负担，只需描述修改哪一部分，具体工作都由大模型完成。

RAP5 协议：规范 AI 编码的五个阶段

在传统软件开发中，设计和开发经常脱节，开发周期长，沟通容易丢失信息，代码质量不好保证，迭代速度慢，最终导致产品缺乏竞争力。为了解决这些问题，我们需要引入 RAP5 协议。

RAP5 实际上是指功能开发的五个阶段：Research（研究）、Brainstorm（头脑风暴/创新）、Plan（规划）、Execute（执行）、Review（审查）。这个工作流的主要目的是确保从 v0 产出的代码到最终功能完整实现，整个质量是有保证的。在 Cursor 中，Agent 会完全按照这五个阶段进行工作。

RAP5 协议基于四个原则编写 Prompt：

1. 系统思维：要求 Agent 思考问题时从整体架构考量，考虑影响范围，再到具体怎么做。
2. 辩证思维：要求 Agent 提出多种解决方案，并评估每个方案的优劣势。
3. 创新思维：要求 Agent 提出一些创造性的想法或我们不知道的解决方案（但在实际开发中占比不高，因为软件开发更需要稳定落地）。
4. 批判性思维：在审查阶段，要求 Agent 对自己的工作提出质疑，并给出改进方案。

具体的工作模式如下：

• Research（研究模式）：目的是收集项目和需求信息。允许 Agent 阅读大部分代码文件，分析代码结构和系统架构，提出问题，并创建一个任务文件记录发现。此阶段不允许做规划和修改代码，只能观察和提问。
• Brainstorm（创新模式）：针对需求讨论并产出多种解决方案，评估优劣势。
• Plan（规划模式）：根据选定的方案出一份实施清单，精确到文件路径和函数名。此阶段不写代码，只在任务文件中记录详尽的实施规范。
• Execute（执行模式）：按照清单一步步自动化操作，生成代码、修改函数、创建或删除文件。
• Review（审查模式）：回顾执行模式所做的事情，比对文件内容和质量，检查实施清单中有没有漏掉的地方。

每个模式的转换都需要开发人员发出明确的信号。开发人员的参与主要是给 AI 提供更多上下文，回答它的问题。这套 Prompt 比较挑模型，在 Gemini 2.5 上表现不好（会不受模式转换控制），但在 Claude 3.5、3.7 和 Claude 4 上效果更好。

V0 与 Cursor 的实际应用演示

在 v0 中，我们只需要告诉模型要构建什么样的系统。比如我写了一个简单的 Prompt，告诉它要构建一个管理 Agent 的 Web 应用，使用 Next.js 和 SQLite，并列出需要的 UI 功能。提交后，它会进行实际的代码编写。v0 生成的代码质量其实比很多研发人员写的要好很多，代码组织结构很 OK。我们现在做很多产品为了快速落地，甚至不分前后端，全部用 Node 一把梭完成，部署成本也不高。

在 Cursor 中，我们演示一个生成管理 Docker/Kubernetes 服务 Shell 脚本的需求。 首先把 RAP5 协议的 Rules 引入进来。新建 Chat 时，它默认进入 Research 模式，创建一个 Task 文件夹和任务文件，记录研究日志、目标和发现的问题。开发人员需要观察任务文件，必要时提供上下文。 接着进入 Brainstorm 模式，它提出了四种方案及优缺点，并推荐了其中一种。我们可以干涉它，比如要求方案 A 和方案 B 的混合实现。 确定方案后进入 Plan 模式，它会出具体的技术实施清单。开发人员检查清单是否合理。 最后进入 Execute 模式，它会按照清单一步步执行，每次执行都会更新记录，做完后还会自己做测试和修复。

这套工作流的价值在于规范了研发人员的工作流程。研发人员的思维从“怎么用技术实现代码”转变为“真正理解业务需求”，从用户角度出发告诉 AI 想要什么效果。研发人员变成了提出需求和验收工作的角色。经过两个多月的实践，开发效率有非常大的提升，以前需要一两周的功能，现在从 0 到 1 跑通主流程只需一周。

互动问答 (Q&A)

提问：整个流程中每个环节大概都是什么角色在做？比如 v0 是产品经理在生成吗？ 回答： 是的，因为我们人员有限，所以教产品经理去使用 v0。产品经理除了写 PRD，也会做后续 v0 的生成工作。

提问：如果觉得 AI 生成的实施清单不合理，可以直接手动修改那个 Markdown 任务文件吗？ 回答： 尽量不要手动修改。建议通过 Chat 让 AI 来改。因为这个 Task 文件的目的是给 Agent 提供类似 Memory Bank 的东西，如果你手动干预，可能会丢失信息。AI 在执行时会结合 Cursor 提供的历史会话和这个文件一起看。

提问：这套流程对模型的上下文窗口要求多大？ 回答： 120K 的上下文是完全足够的。因为实现一个功能不可能一次性写好，会不断通过 Chat 让它修复，上下文会越来越长。这也是为什么我们选择 Claude 4。如果用 DeepSeek，它的指令遵循效果在长上下文中会变差，做着做着就会有自己的想法，不按预定逻辑执行了。所以代码生成这块，Claude 3.5 或 4 的效果是比较好的。

提问：整个过程是一个人控制，还是团队讨论决策？ 回答： 是一个开发人员从头到尾控制。我们在实际开发中，会在 Rules 中规定项目的基础架构、布局结构、编码要求等，作为硬性规范附加到每次对话中。

提问：测试是手工测试还是自动化测试？有人做 Code Review 吗？ 回答： 是研发人员自己做手工测试，按照实际业务流程走一遍看有没有问题。研发人员自己会看 AI 生成的代码，因为要快速出产品，只要功能 OK 就行。在大部分增删改查的场景下，AI 生成的代码质量其实比普通研发人员写的要高。

提问：有没有碰到过代码太复杂，比如上万行，AI 搞不定的情况？ 回答： 目前没遇到过。我们一个模块一次功能开发最多 7 到 10 个文件。AI 生成时会按照最佳实践做合适的代码拆分，不会把所有代码写在一个地方。

提问：如果新功能开发出来后测试发现 Bug，RAP5 协议怎么用到修 Bug 里？ 回答： 是一样的。不管是从零开始还是已有项目，只要通过 Rules 把项目情况、模块划分、依赖管理等背景信息提供给模型，RAP5 协议同样适用。Rules 和 Protocol 是相互补充的关系。

提问：为什么选择 RAP5 协议，而不是直接用 Copilot？ 回答： 我之前是 Copilot 的重度用户，发现它在解决复杂功能时经常跑偏，修改时会忘记之前的操作。后来在 Cursor 论坛看到 RAP5 协议，它通过一套 Prompt 完全改变了 Agent 的工作模式，强迫它遵循我们人类开发时的思考流程。实际使用下来，确实比不使用 Prompt 直接用 Cursor 效果好很多，能把两三天的开发工作缩短到两天。

提问：程序员用这个不怎么写代码，编程能力会不会退化？万一哪天 Cursor 宕机了怎么办？ 回答： 确实会退化。我现在完全脱离不了 Cursor 及相关 AI 工具链，确实感觉到编码能力有退化。但 AI IDE 有很多，不止 Cursor 一家。目前体验下来，如果不搞 RAP5 这种“奇技淫巧”，效果最好的 AI IDE 可能是 Augment Code，生成的代码基本完全可用，但价格太贵（50刀一个月）。

提问：我用 Claude 和 GPT 时，发现它们对提示词的规则是选择性遵守，或者因为上下文不足导致遗忘，怎么解决？ 回答： 建议使用 Instruct（指令）模型而不是 Reasoning（推理）模型（如 DeepSeek-R1 或带 Thinking 的模型）。Reasoning 模型本身用于解决复杂推理任务，容易添加自己的想法，不完全遵循严格的步骤约束。如果工作步骤明确，尽量用 Instruct 模型配合优秀的 Prompt。另外，大模型的 Attention 机制会导致它更关注 Prompt 的头部和尾部（Lost in the Middle 现象），尽量把核心规范写在开头或结尾。

提问：AI 总是百分百执行我的需求，不会对我的设计提出质疑或反驳，这让我很苦恼。 回答： 它毕竟只是一个自然语言模型，不具备真正的独立思考能力。你可以尝试在 Prompt 中明确要求它使用 COT（思维链）模式，从反例去思考并提出质疑，但这需要你在指令上明确告诉它。

提问：你们的公文生成项目，怎么解决上万字长文本生成的上下文丢失问题？ 回答： 我们把单一 Agent 架构优化成了 Multi-Agent（多智能体）架构。流程是：协调者 Agent 接收请求 -> Outline Writer 生成大纲 -> 派生出多个 Section Writer 并行编写章节。每个 Section Writer 会通过 RagFlow 进行 Chunk 检索，结合 Deep Researcher 的网络检索，用 Rerank 算法重排序后附加到 Prompt 尾部。最后由一个总结 Agent 收集结果。长文本的主题连贯性我们参考了解决 "Lost in the Middle" 问题的相关论文算法，在 Prompt 层面做调整。

提问：我们做标书生成，历史标书有几百兆，里面全是图片，怎么把图片塞到知识库里？ 回答： 我们用 Docling 和 MinerU 做数据清洗，把 Word/PDF 转成 Markdown。遇到图片时，调用 VLM（视觉大模型，如通义千问 VL）去解释图片内容，把识别出来的文本描述和图片关联。在做 Graph RAG 时，把图片文本识别为独立实体建立关系。存储时只存图片的 UUID，最后返回给用户时再替换成实际的图片地址。这样既能保证检索准确率，又能大幅缩小文件体积。

提问：用了 AI 以后，发现自己解决的问题更多了，边界扩展了，但时间并没有节省太多，反而陷入了试错的无底洞，怎么评估工作量？ 回答： AI 确实扩展了开发者的边界（比如前端现在也能写后端和运维）。但如果对某个领域本身不熟悉，验证 AI 给出的结果确实会增加额外成本。不要神化 AI，它只是辅助工具。AI 帮你解决了 0 到 1 的技术难题，实际上是逼着你去直面更难的“产品问题”——你的产品优势在哪？用户画像是谁？别人为什么付费？这才是真正需要思考的。至于领导对 AI 期望值过高（以为一周的活半天就能干完），这就需要做好向上管理，合理控制领导的预期。