AI 能否完成复杂项目的开发

53 天前
 rossroma

写在正文之前

背景:从“Hello World”到复杂工程的鸿沟

当前,人工智能( AI )在代码生成领域展现了惊人的能力。许多开发者初次体验 AI 编写一个简单的“TODO List”应用时,无不为其效率和完整性感到震撼。我们只需给出一句指令,AI 便能迅速生成一个功能完备且可运行的项目。这自然引发了人们对未来软件开发的无限遐想:是否有一天,我们不再需要编写任何代码,只需通过自然语言与 AI 对话,就能完成所有开发工作?

然而,当我们将 AI 应用于真实、复杂的商业项目中时,理想与现实的差距便显现出来。AI 一次性生成的代码往往难以完全满足预期,可能存在功能偏差,或者干脆无法运行。开发者在反复的调试和沟通中,不仅消耗了大量时间和计算资源( Token ),还可能陷入“修复一个问题,引出三个新问题”的困境。最终,很多人在耐心耗尽后,只能发出一声“AI 不过如此”的感叹。

那么,让 AI 独立开发复杂项目,这条路真的走不通吗?

问题分析:复杂任务下的“黑箱”与“连锁错误”

要回答这个问题,我们首先需要剖析其根本症结。在处理复杂项目时,AI 开发的核心挑战在于其“黑箱”特性和由此引发的“连锁错误”效应。

当我们向 AI 下达一个模糊或复杂的指令时(例如“开发一个电商系统”),AI 需要在其内部决策空间中补完大量未明确的细节。由于我们无法观测其内部的“思考”过程,也无法理解它做出特定决策的依据,这就形成了一个“黑箱”。使用者无法在过程中给予关键性的指导,只能被动地接受最终结果。当结果不符合预期时,我们很难定位问题的根源,自然也难以提出有效的修正建议。

这个“黑箱”进一步导致了“连锁错误”。我们可以用一个简单的概率模型来说明:假设 AI 在处理一个定义清晰的、单一的子任务时,其准确率为 99%,这看起来相当可靠。但如果一个复杂项目需要 AI 连续正确地完成 100 个这样的子任务,那么整个项目完全正确的概率将骤降至 (0.99)^{100} ≈ 36.6%。这意味着,随着任务复杂度的指数级增长,AI 独立完成任务的成功率会急剧下降。任何一个环节的微小偏差,都可能在后续环节中被放大,最终导致整个项目的失败。

解题思路:模拟人类软件工程,引入“人机协同”

既然当前的大语言模型在底层技术上模拟了人类的神经网络,我们何不让它在工作流程上也模拟人类的软件开发过程呢?

让我们回顾一下一个标准的人类软件项目是如何运作的:

这个模式的核心在于通过分工和流程将复杂问题拆解,并在关键节点进行验证。这恰好可以弥补 AI 在处理复杂任务时的短板。

因此,我们的解题思路是:放弃让 AI 成为一个全能的“黑箱开发者”,而是将其视为一个由人类专家指导的多角色“AI 执行团队”。在这个“人机协同”的模式中,人类不再是需求的被动提出者,而是扮演项目经理、架构师和技术专家的角色,在关键节点对 AI 的产出进行审核、验证和修正,确保每一步都走在正确的轨道上。

这种模式的优点在于:

  1. 风险可控:将复杂任务分解,当出现问题时,只需回溯到上一个验证节点,排查和修复的成本极低。
  2. 质量可期:人类的专业知识和判断力弥补了 AI 在创造性、商业理解和模糊决策上的不足,确保最终产出物的质量。

缺点也同样明显:

  1. 效率瓶颈:人工的介入和验证会减慢开发速度,无法实现“一键生成”的理想效率。
  2. 对人的要求高:主导者需要具备跨领域的综合能力,既要懂产品、懂设计,也要懂技术和项目管理,才能有效地指导和纠正 AI 。

AI 辅助开发的模拟流程

为了更具体地说明这种“人机协同”模式,我们可以模拟一个开发流程。在这个流程中,我将扮演项目经理( Human PM )的角色,负责在每个关键环节进行把关。而 AI 则需要根据我的指令,扮演不同的角色(如 AI 产品经理、AI 设计师、AI 工程师等),并输出相应的工作成果。

以下是这个 AI 辅助开发过程的流程图:

通过这个流程,我们将一个不可控的、巨大的“黑箱”任务,拆解成了一系列可控、可验证的“白盒”子任务。虽然牺牲了极致的速度,但换来的是项目的确定性和最终的成功。这或许才是当前阶段,我们利用 AI 完成复杂项目开发的最优解。

2131 次点击
所在节点    程序员
12 条回复
tetora
53 天前
没有界面或者界面 ui 简单的可以慢慢从 0 开始做可以完成复杂项目,但是像做游戏那些带稍微复杂点界面或者操作的就不太行做的像一坨屎,暂时还没有一个 mcp 能完成 unity 自动绑定脚本到游戏对象上
cat
53 天前
这排版,第一反应拉到最底下,竟然没有二维码 没有链接
Feeli
53 天前
看不惯 AI 润色的文章 一股味儿...
ihainan
53 天前
文章有种截然而止的感觉…
rossroma
53 天前
@tetora 我认为管理后台或者 ToB 类的项目,是可行的,界面个性化较高或复杂交互类的,就不太适合
rossroma
53 天前
@Feeli 是有一股味,简而言之就是水词、套话比较多,但相对于我自己写的初稿,我认为在阅读流畅性、结构合理性和语言逻辑性上是更好的
SoviaPhilo
53 天前
好消息是 CRUD 仔有饭吃了, 给 AI 打下手。
坏消息是只有销售是一等公民,AI 的助手有的是
shawnhill
53 天前
黄框部分会超出 Human PM 的知识边界或审阅能力。无法解决错误累积的问题。
uuundefined
53 天前
TOKEN 还是太少了, 自己得有技术总监实力,才能拆分模块,解耦,让 AI 在有限的 TOKEN 下写简单的代码,
那种变迁很多的库,AI 一用就会出岔子。
文档资料没被 AI 训练齐的库,AI 动不动少写一两行代码, 可以让你找上大半天
lunatic5
53 天前
戛然而止,看着有点不过瘾
rossroma
53 天前
@ihainan @lunatic5 我目前只想到了这些,真的要落地实践的化,感觉还有很多工程化问题要解决
rossroma
53 天前
@shawnhill 项目初期会有很多 0-1 的问题,比如数据库设计、项目结构、公共方法和组件的封装、初始代码、语法风格等等,这些工作会比较耗时,需要 Human PM 的深度介入。当进行到 1-n 的工作时,AI 最擅长的照葫芦画瓢的能力就可以充分发挥了,只要参照 PRD 和以后的代码结构,AI 就能产出相当可靠的结果。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1150126

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX