在AI技术飞速发展的今天，软件开发的门槛正在被逐步降低。本文作者作为一名非计算机专业的产品经理，通过亲身体验，利用AI编程工具（如Deepseek和Trae）尝试开发一款简易的APS排程软件，记录了从需求提出到软件完成的全过程。
作为一个非计算机专业的产品经理，虽然我没有任何代码基础，不懂编程，但是常年在产研团队中工作，对编程和开发工作极度渴望，是程序员升职记、while true:learn等游戏的忠实玩家，有时遇到自己感兴趣的产品想法会有动手开发的冲动，但是碍于不会编程，不得不放弃。自从去年夏天cursor爆火之后，我开始跟着网上的大佬尝试应用AI编程工具。
写这篇文章记录最近的一次AI编程尝试，利用AI编程工具开发一款简易的APS排程软件，验证一下目前的AI编程工具能否实现“动嘴”开发。同时在这次尝试的过程中，对产研团队的工作方式，产品经理的职业发展有了新的认知。
软件的基本逻辑如下：
这次开发的过程被分为了，准备、编码、测试、打包几个阶段，主要使用了在线的deepseek R1以及Trae，因为Trae最新的Claude-3.7-Sonnet模型每次请求都需要排很久的队所以这次只使用了Claude-3.5-Sonnet和Deepseek-Reasoner（R1），预测使用Claude3.7模型开发效果会更好。
因为在考虑开发这个软件之前就已经对软件的大致框架、功能逻辑有了基本的设计，所以这次尝试跳过了设计阶段直接开始准备开发，准备阶段我主要使用的是deepseek R1，在提供了基本的业务背景、业务目标、功能逻辑以及我当前的开发环境等信息后，deepseek R1根据我的情况提供了技术选型方案、大致的开发步骤以及避坑指南。
这里要非常感谢Deepseek的建议，因为在它的建议下使用了git，开发过程中代码可以回滚，避免了几次重大问题。
核心语言我选择了python、GUI框架选择了Tkinter，文件处理选择了json。
接着，我在Trae的Builder模式下输入大致的业务背景以及刚才生成技术选型的结果，提交之后，Builder开始帮我检查本地是否正确安装了开发所需的依赖环境，在运行了几个指令之后，确认了当前我本地的开发环境，并帮我安装了几个必要的库。接下来，就可以开始编码了（如果使用cursor的内容以及提前确定的设计、开发规范都可以通过rules提供给AI）。
目前一次性让Claude-3.5-Sonnet完成整个相对复杂的程序开发是不现实的，并且在看不懂代码的情况下我需要即时验证程序是否符合预期，所以，我把整个开发过程拆分成了界面搭建、数据维护功能搭建和规划求解功能搭建三个步骤，增量式地完成软件开发。
第一步，界面搭建，我们根据功能需要描述出软件的界面框架和模块结构，很快它就完成了主界面、主菜单、功能模块的搭建。
第二步，数据维护部分，需要描述每个模块数据的基本属性和增、删、改、查的规则，我们分不同的模块描述了基本的数据结构的大致规则，程序都按照要求编写出了对应的数据维护功能，调试运行，功能正常。
前几个模块描述得足够详细，后面几个模块在描述得时候就可以放飞了，简单介绍下大致内容它就会根据类似的规则编写出我们想要的标准功能。到这里，让它统计一下，我们花了大约1个小数已经写出了2850行代码，我们先在git上提交了这部分代码。
编码最后一步，规划求解，相比前面的步骤会稍复杂一些，首先尝试了直接描述模块的功能和大致规则。
结果正如预测，程序运行失败，出现了大量的报错，我们试着将这些报错发给builder让它进行修复，但是，经过几轮修复后仍然没有解决问题，于是，我们改变策略，回退代码，再次把内容拆分，我们把排程的过程拆分为了：生成排程任务、任务分配、冲突检查三个部分，分步实现每个功能，这次虽然部分情况下仍然出现报错，但是基本让它排查一次都能修复，经过十几轮对话后，基本功能搭建好了。
但是此时生成的结果是表格形式的，所以，又花了几轮对话，把排程结果改为了甘特图的样式，至此具有完整功能的第一版软件开发好了。
再此版本之上，我还尝试了让Build更换算法策略，改为使用之前Deepseek推荐的进化算法，这种情况下需要强调更改过程只改算法规则，保持页面和交互不做改动，改动后的程序能顺利运行。
在完成每个模块的功能开发后，我让builder创建一个单元测试用例，并进行测试来验证、确保基本功能的可用。
所有模块功能都验证没有问题，我们描述打包需求，让builder帮我们选择、安装打包工具并执行打包命令，打包过程比较顺利，至此，我们完成了软件的开发过程。
小结一下，经过这次尝试，可以得出结论，一般软件开发过程中的技术选型、环境搭建、编码、测试、打包工作，都可以使用AI完成，作为没有编码技能的用户可以通过AI工具实现自己的想法，想要开发商业级的软件产品，操作者仍然需要具备工程师级别的编程经验，AI编码的效率提升也需要专业程序员来进一步评估。
但是具有丰富业务经验的工程师能够使用AI工具快速应用自己不熟悉的技术栈完成产品的编码工作并不断完善产品，同时一些高度重复机械性的编码工作也可以让AI代劳。如果AI编程技术继续以现在的速度发展下去，未来我们也许真的会出现AI程序员同事。
在这次尝试的过程中，对于产研工作尤其是产品经理的工作我产生了三个认知。
在这次尝试的过程中，我和builder的主要交互模式如下：
归功于适用AI的通用通信协议，AI能够完成编码工作中的主要操作，而Trae、cursor这类编辑器在集成了这种规则的同时开发了由用户决定执行每一步操作的功能，从而形成了这种开发模式。在这种模式下，以往程序员的编码工作中很多通用的构思、大量机械的业务代码都能够通过简单的自然语言指令让AI来实现，程序员从编码的执行者变为了审核人。
我们再延伸到产品经理，对于产品经理的大部分工作同样可以利用相同的技术产生类似的AI工具产品，创造AI产品助理，来和产品经理一起进行协同产品设计、文档撰写，此时，产品经理的角色也将从执行者转变为审核人，此时会更多地要求产品经理具有比较强的商业敏感度、思辨能力和判断力，在AI助理按照你的想法提供了产品方案后，你能够根据你对产品、客户以及业务的理解发现存在的问题，洞察到新的机会和可优化点做一个合格的审核人。
新的工具出现，让编程的门槛降低，虽然我们无法直接参与到软件程序的编写工作中，但是工具为我们提供的编程能力，可以帮助我们把更多的产品想法落地到初步的demo上，在研发资源不足以分配给团队进行新的方向时，甚至产品经理可以自己开展“臭鼬工程”自己抽时间捣鼓出一个程序来进行前期的实验，在得到积极的实验反馈后，再申请相应的资源投入，这样从想法到成功落地项目的可能性将会更高。这样一来敏捷型的产品开发流程可能会演化为非技术人员先脱离产品技术栈构建新业务功能快速验证成功后再转入开发项目冲刺的超敏捷开发流程。
以前产品经理需要通过清晰的语言描述、产品原型图来向相关方陈述产品方案。但是语言具有诱导性信息传递过程会出现失真；高保真原型图绘制费时费力，低保真原型图又无法完整表达产品想法。现在我们可以通过AI工具快速将想法转变为基础的产品案例，从而提升产品设计和方案验证的效率，当然真正提升效率仍然依靠成熟可靠的AI工具和产品经理的专业性以及熟练应用工具的技能。不过当前已经有产品经理开始使用AI编程工具来开发前端页面，再将工程导入figma来快速实现高保真产品原型的搭建工作，各大产品设计软件也已经相继推出AI设计的功能，这个设想应该很快就会成为普遍现实。
当AI抹平了执行的鸿沟，我们比任何时候都更需要知道：究竟要为什么样的价值去创造
当以上的两个趋势逐步成为现实后，可以预见的一个现象就是单纯靠AI产出的内容会存在同质化严重的特点，这样以来，产品经理角色真正的价值属性就变成了脱离AI的洞察力。
我在这次尝试的过程中就能够感觉到在虽然在开发时我只需要提供相对模糊的表述，AI就可以在此基础上进一步设计程序，补充很多可能忽略的细节，但是AI的设计始终无法脱离范式。
目前AI的优势在于它完成了我们普通人无法完成的知识储备，像一个百科全书，并且已经开始具备了慢思考能力，能够进行逻辑推理，但缺点是它始终会被禁锢在已有的知识中，根据所谓的“最佳实践”产出内容，因而缺少创新性。并且我们都知道要想更加理解用户，你需要的不是成为万事通而是带着用户的思维去思考和体会，甚至成为用户，这样才能找到真正具有价值的产品机会。
我们需要能够依靠我们对业务的理解、对用户的敏锐洞察以及共情能力，发掘出产品价值，找到用户的不满、焦虑、恐惧、愤怒再借助AI工具来创造满足用户的产品。
所以从现在开始，在产品设计过程中，我们应该更多地去寻找我们相对于AI在人性理解中的优势并且刻意地训练，提高我们的敏感度，让我们相比AI更加人性化。
AI技术发展迅猛，就在我写下这篇文章的时候，网上已经有更多的AI编程、产品开发的技术应用案例出现，在不停追逐科技前沿尝试新技术的同时，我们也需要更多地进行反思，技术更新的浪潮里，我们个体的发光点在哪里，怎样在自己的职业中产生更多价值。
本文由 @Sailors 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。