



在AI辅助开发时代,把想法转换成代码变得前所未有的简单。本章将介绍三种不同的开发方式,从快速验证到完整规划,帮助你选择最适合的方式来实现你的想法。无论你是想快速验证一个创意,还是要开发一个完整的系统,这些方法都能帮助你更高效地完成开发。
想象一下,你突然有了一个绝妙的想法,想马上把它变成代码。在传统开发中,你可能需要先写需求文档,再画原型图,最后才开始写代码。但在AI辅助开发时代,你可以直接用一句话告诉AI,它就能帮你生成可运行的代码原型。
就像你跟朋友描述一个App的想法一样,对AI描述需求也要简单直接。一个好的一句话需求应该包含两个要素:产品类型和要解决的问题。
比如,你可以这样描述:
帮我开发一个学习计划管理应用,可以让用户创建学习目标、记录学习时间,并生成学习报告。
这句话清晰地表达了:
(1)产品类型:学习计划管理应用;
(2)要解决的问题:帮助用户管理学习目标和进度。
当你把这句话输入到AI后,它会立即为你生成一个基础的代码框架。这就像一位经验丰富的程序员听完你的想法,立刻为你打造了一个简单但可运行的版本。
在上一节的例子中,我们看到同样是一句话需求,“给我做一个俄罗斯方块游戏”和“给我做一个超级玛丽的横版游戏”产生了截然不同的结果。这种差异不仅取决于需求的复杂度,还与你所使用的大语言模型(LLM)和平台的能力息息相关。
1)LLM能力差异对一句话需求的影响
不同的LLM模型在处理简单提示时表现各异。
· 高级模型(如Claude 3.7、DeepSeek r1、GPT-o3等):能从简单提示中推断更多上下文,理解隐含的需求,自动补充缺失的细节。
· 中级模型:需要更明确的指导,对简单提示的理解有局限性。
· 基础模型:往往难以理解模糊的一句话需求,容易产生不符合预期的结果。
2)Agent功能的关键作用
一些现代AI平台(如Lovable、V0、Cursor等)配备了强大的Agent功能,这些Agent能自动将简单的一句话需求转化为复杂且完整的提示,大大提高输出质量。
用户输入:"给我做一个俄罗斯方块游戏。"
Agent内部可能的处理流程如下。
1. 分析需求类型:游戏开发——俄罗斯方块 2. 提取关键要素:方块下落、旋转、消除、计分系统 3. 构建完整的提示。 "请开发一个俄罗斯方块游戏,包含以下功能。 - 方块随机生成和下落 - 方块旋转和移动控制 - 行消除机制和计分系统 - 游戏结束判定 - 基础UI界面和操作指南 请使用HTML/CSS/JavaScript实现,确保代码结构清晰……"
这就解释了为什么同样是一句话需求,在有强大Agent支持的平台上会获得更好的结果。俄罗斯方块的例子之所以成功,部分原因是平台的Agent自动将简单的需求扩展成了更完整的提示。
3)选择合适的平台
基于这一理解,大家可以更明智地选择平台。
· 有强大Agent功能的平台:适合使用一句话需求,节省时间;
· 无Agent或Agent能力有限的平台:需要自己编写更详细的提示。
以学习计划管理应用为例,在高级LLM或强Agent平台上,一句话需求可能会生成下面这样的代码结构。
1)评估LLM和平台
· 测试平台的Agent能力;
· 对于高级平台,可以用简单提示;
· 对于基础平台,准备更详细的提示。
2)需求描述要具体
· 明确说明功能的输入和输出;
· 指出核心业务流程;
· 提供必要的业务规则。
3)保持简单直接
· 一次只描述一个主要功能;
· 避免过多的条件和限制;
· 使用日常用语表达。
小白必记
· 需求描述原则:一句话说清产品类型和核心问题
· 平台选择考量:高级LLM或强Agent平台更适合一句话需求
· 表达方式技巧:用生活化语言描述专业需求
· 功能范围控制:先做核心功能,避免过度设计
· 代码结构要求:清晰易懂,方便扩展
· 迭代准备原则:预留扩展空间,便于后续开发
· 失败处理策略:一句话需求效果不佳时,转向更详细的提示工程
在学会使用一句话需求快速开发原型后,你可能会发现,有时候我们的想法会在开发过程中不断变化和完善。就像你在画画时,可能会随着创作的深入不断调整构图一样。这时,就需要一种更灵活的开发方式——边想边做。
这种开发方式在编程界有个专业的名称,叫“敏捷开发”。它就像一个会不断进化的生命体,可以随时根据人们新的想法和需求进行调整。下面来看看如何借助AI实现这种开发方式。
想象你正在和一个经验丰富的程序员搭档,你们可以随时交流想法,快速调整方向。使用AI时也一样,你可以通过不断的对话来完善程序。
比如,还是以学习计划管理应用为例。
1)第一轮对话:实现基础功能
请帮我实现一个最基础的学习计划管理功能,需要能添加学习目标和记录学习时间。
2)第二轮对话:添加新特性
现在想给它加上数据统计功能,能够展示每周的学习时间分布。
3)第三轮对话:优化用户体验
可以添加一个提醒功能吗?当用户连续3天没有学习时发出提醒。
这种方式的好处如下。
· 快速看到实际效果;
· 随时调整开发方向;
· 逐步完善产品功能;
· 及时发现并解决问题。
1)确定最小可用版本
就像盖房子要先搭建骨架一样,首先实现最核心的功能。比如学习计划管理应用,最基础的功能就是“添加学习目标”和“记录学习时间”。
2)快速迭代优化
有了基础功能,就可以像滚雪球一样不断添加新功能。每次添加一个小功能,确保它能正常运行后,再继续添加下一个。
3)持续收集反馈
在开发过程中,要经常测试和使用自己的程序,就像给正在建造的房子做质量检查一样。发现问题及时调整,确保每个功能都好用。
下面看看如何用边想边做的方式来开发学习计划管理器。
第一轮迭代:基础功能。
第二轮迭代:添加统计功能。
1)保持代码整洁
每次添加新功能时,都要保持代码结构清晰。就像整理房间一样,东西越来越多的时候,更要注意保持整洁。
2)做好版本管理
使用Git这样的工具记录每次修改。这就像给开发过程拍照片,方便随时回顾之前的版本。
3)及时编写文档
把重要的开发决策和功能说明记录下来,就像给房子画设计图纸,方便以后查看和维护。
小白必记
· 敏捷开发原则:小步快跑,持续改进
· 功能迭代方法:先核心,后完善
· 代码管理要求:及时提交,记录变更
· 测试验证准则:边开发边测试
· 文档更新原则:同步记录,清晰说明
· 反馈处理流程:及时响应,快速调整
· 版本控制技巧:阶段性标记重要节点
当项目开始变得复杂时,仅仅用一句话描述需求可能就不够用了。就像建造一座房子,需要详细的建筑图纸一样,开发一个较大的软件项目也需要一份完整的需求文档。在这种情况下,我们通常会使用项目的README.md文件来管理需求文档。
一份优秀的README.md文档应该包含以下几个主要部分。
下面通过一个学习计划管理应用的例子,来看看如何把这个框架变成实际的文档。
在AI辅助开发时代,我们不仅可以手动编写需求文档,还可以借助强大的LLM来生成完整的产品架构设计。这种方式能够大大缩短从创意到实现的时间,并提供专业水准的架构规划。
1)生成完整架构图的重要性
在使用LLM生成软件架构时,确保生成的架构图完整而非分散是至关重要的。
(1)一次性生成完整架构:架构图必须是完整的,不能分成几个部分生成。分散的架构图难以形成整体认知,也不利于后续的开发工作。
(2)避免分块生成的问题。
· 结构不一致:分开生成的架构图各部分可能采用不同的设计理念或结构;
· 连接不明确:模块间的关系可能不清晰或矛盾;
· 重复或遗漏:可能出现功能重复或关键功能遗漏的情况。
(3)如何确保完整性:
· 使用足够强大的LLM模型(如Claude 3.7、GPT-o3等);
· 如果架构图不完整或分散,要求LLM重新生成一个完整的版本;
· 适当调整prompt以确保输出的完整性。
2)选择合适的LLM模型
在实际测试中,不同的LLM模型在架构设计能力上有显著差异。
· 高级模型(如Claude 3.7、GPT-o3)表现最佳,生成的架构设计最为全面和专业;
· 中级模型可能在复杂产品上生成的图表不够完整;
· 根据经验,使用付费版官方渠道的模型通常能获得最佳结果。
3)高效的Prompt模板
以下是一个经过优化的高效Prompt模板,可用于生成完整的软件产品架构设计。
这个模板包含了明确的角色设定、MVP原则、优先级评分标准、层次化架构和MECE原则等关键元素,能够指导LLM生成高质量的产品架构设计。这个模板的强大之处在于它的通用性,以下应用它都能生成适合的架构设计。
(1)网页应用:从电子商务到内容管理系统。
(2)移动应用:从社交媒体到生产力工具。
(3)VR/AR体验:从游戏到教育培训应用。
(4)智能硬件界面:从智能家居控制到工业设备监控。
(5)桌面软件:从设计工具到开发环境。
模板着重于分离界面层、组件层、业务流程层和数据层,使其适用于各种产品类型的架构设计。以下是使用模板后在Claude 3.5生成的智能语音音箱产品架构说明文档。
通过这种渐进式开发策略,可以快速推出MVP版本验证市场需求,同时控制开发成本,在获得用户反馈后再进行针对性优化和功能扩展。智能音箱产品架构图如图2-2所示。
在上述内容里,能看到Mermaid相关字眼的代码,如果所在的LLM平台无法将它转换成架构图,可以尝试将mermaid里面的内容复制、粘贴到以下网站转换成可视的架构图。
· Mermaid to Excalidraw平台:https://mermaid-to-excalidraw.vercel.app/;
· Mermaid Live Editor:https://mermaid.live/。
如果生成的架构图不完整或分散成多个部分,这可能会导致理解和开发困难。这时候可以重新发起LLM请求,让LLM再次生成。这个模板不仅可以生成架构图,还会提供每个模块的详细设计,具体如下。
· 模块名称和功能简述;
· 模块类型(界面层/组件层/业务流程层/数据层);
图2-2 智能音箱产品架构图
· 优先级评分(基于MVP原则);
· 与其他模块的关系和依赖;
· 输入/输出内容;
· 模块在不同界面中的应用情况。
这些详细信息对于理解和开发产品至关重要。如果你对生成的架构设计不完全满意,可以进行以下调整。
(1)针对性反馈:明确告诉LLM你想调整哪些特定模块,比如“请调整用户认证模块,增加社交媒体登录功能”。
(2)优先级调整:可以要求改变某些功能的优先级,如“请将数据导出功能的优先级从2分提高到4分”。
(3)增加或删除模块:清晰指出想添加或移除的模块,如“请添加一个通知中心模块”。
(4)层级调整:可以请求更改模块的层级,如“将设置面板从界面层调整为组件层”。
通过这种方式,可以逐步优化架构设计,直到它完全符合产品愿景和开发需求。这个模板的强大之处在于它能够为不同类型的产品提供结构化的架构设计,帮助你更清晰地规划开发路径。
除此之外,可以直接将架构图复制给Lovable或者Cursor,它可以基于架构图将完整产品开发出来。以“每日打卡”应用为例,以下也是用该Prompt生成的产品架构Mermaid代码和使用Cursor一次性生成的产品效果链接,感兴趣的读者可以自行体验一下。
每日打卡可扫码体验。
每日打卡
需求文档不是一成不变的,它会随着项目的发展而不断更新。这就像人们建房子可能会根据实际情况对图纸进行调整一样。以下是一些管理建议。
1)版本控制
把文档放在Git这样的版本控制系统中管理,就像给文档拍了很多快照,你随时可以查看之前的版本,了解文档是如何一步步演变的。
2)文档评审
定期和团队成员一起检查文档,就像请专家来验收房屋施工进度一样,确保所有人对需求都有相同的理解。
完整的需求文档特别适合以下场景。
1)企业级应用开发
比如开发一个公司的人事管理系统,需要详细规划每个功能模块。
2)多人协作项目
当多个程序员一起开发时,需要有统一的参考标准。
3)长期维护的系统
如果这个项目需要运行很多年,详细的文档可以帮助后来的维护者快速理解系统。
小白必记
· 需求文档原则:完整清晰,便于理解
· README.md结构:项目说明要分门别类
· LLM架构设计:使用强大的模型和优化的Prompt获取专业设计
· 版本控制要点:定期更新,记录变更
· 文档评审准则:团队共识,及时反馈
· 场景选择原则:项目规模决定文档深度
· 更新维护方法:持续迭代,同步代码
· 协作沟通技巧:文档先行,统一认知
在了解了3种开发方式后,你可能会问:“我应该选择哪种方式来开发我的项目呢?”这就像选择交通工具,既要考虑目的地的远近,也要考虑路况和天气。下面分析每种方式的适用场景。
1)快速验证(一句话需求开发)
· 特点如下。
■ 开发速度最快;
■ 功能相对简单;
■ 适合个人项目。
· 适用场景如下。
■ 验证创意想法;
■ 制作概念原型;
■ 学习新技术时。
· 注意事项如下。
■ 不适合复杂的项目;
■ 可能需要后期重构;
■ 文档相对简单。
· LLM和平台要求如下。
■ 需要高级LLM模型或有强Agent功能的平台;
■ 如:Claude 3.7、DeepSeek R1、Lovable、Cursor等。
2)持续迭代(边想边做开发)
· 特点如下。
■ 灵活性最高;
■ 快速响应变化;
■ 持续改进产品。
· 适用场景如下。
■ 创新型产品;
■ 用户需求不明确;
■ 需要快速试错。
· 注意事项如下。
■ 需要良好的版本管理;
■ 可能产生技术债务;
■ 要及时整理文档。
· LLM和平台要求如下。
■ 中高级LLM即可;
■ 支持上下文记忆的对话系统较佳;
■ 如:大多数现代AI编程助手。
3)系统规划(完整需求文档开发)
· 特点如下。
■ 规划最完整;
■ 文档最详细;
■ 适合团队协作。
· 适用场景如下。
■ 企业级应用;
■ 多人协作项目;
■ 长期维护系统。
· 注意事项如下。
■ 前期投入较大;
■ 变更成本较高;
■ 需要严格管理。
· LLM和平台要求如下。
■ 最强大的LLM模型;
■ 具备完整架构设计能力;
■ 如:Claude 3.7、GPT-3o、DeepSeek-R1等高级模型。
下面用决策树来帮助选择。
1)先考虑4个关键因素
· 项目规模:个人项目/小团队项目/大型项目;
· 时间紧迫度:非常紧急/一般/充裕;
· 需求明确度:非常明确/待探索/完全不明确;
· LLM和平台能力:基础/中级/高级。
2)然后根据答案来选择
· 如果你的回答是:个人项目+非常紧急+待探索+高级LLM/平台,则选择“快速验证”方式。
· 如果你的回答是:小团队项目+一般+待探索+中高级LLM/平台,则选择“持续迭代”方式。
· 如果你的回答是:大型项目+充裕+非常明确 +高级LLM/平台,则选择“系统规划”方式。
· 如果只有基础LLM/平台可用,则避免“一句话需求”,倾向于使用详细描述和手动提示工程。
在实际开发中,前面介绍的3种方式并不是互斥的,你可以根据项目的不同阶段灵活组合使用。
1)探索阶段
· 使用“快速验证”方式尝试不同想法;
· 快速验证技术可行性;
· 收集初步反馈。
2)开发阶段
· 转向“持续迭代”方式;
· 逐步完善功能;
· 收集用户反馈。
3)规模化阶段
· 补充“系统规划”文档;
· 规范化开发流程;
· 为团队协作做准备。
小白必记
· 方式选择原则:项目规模和LLM能力共同决定开发方式
· 快速验证适用:创意验证和原型开发,需要高级LLM/平台
· 持续迭代适用:创新产品和探索性项目,中高级LLM即可
· 系统规划适用:企业级和团队协作项目,需要最强大的LLM
· 混合策略技巧:不同阶段选择不同的方式
· 决策依据要点:规模、时间、需求明确度和LLM能力
· 灵活应变原则:根据项目发展和LLM表现调整方式