AI 编程从原型到上线的完整流程

来自版块 深度
32
0
01工具的对比与选择工具大致分为两类:

全包式应用:帮你搞定一切(托管、数据库、部署)

AI助手:给你更多控制权,但需要你自己管理基础设施

如果你刚入门,从全包式应用开始。当你需要更多控制权,或碰到工具上限时,再转向AI助手。

我尝试过Replit、Lovable、Codex和Claude Code。Claude Code是我目前的首选。

但小项目我更喜欢Lovable(比如宠物的健康追踪管理),不用操心UX,界面又好看。

Vibe Coding工具

Nwujh0bl4ZuOZNBoFtP6.png
AI 编程智能体
jEdN0v87OaeJNbCrtLlS.png

VS Code、Windsurf、Cursor 这类集成开发环境(IDE)我没有列入清单,不过它们很多都内置了自己的编码助手。Cognition 也做了编码助手 Devin,但感觉也不太适合放在这里对比。

也没有包含只做设计原型的工具,因为今天我们的重点是搭建应用。

02 会在哪里出问题选好工具之后,就可以开始干活了。

然而大多数项目就是从这里开始跑偏的。如果不清楚自己想要什么,或者频繁改主意,最后就会得到一堆混乱的代码。

Vibe Coding的恶性循环是:总在修复同一个bug

我们在过程中经常会发现,你报了bug,AI说修好了,但其实没有。

无论怎么说、怎么做,都很难真正修复。让人非常崩溃。

cQm8cgHTAqur8A6trfZC.png


这类问题通常源于几个原因:

  • 你对想要的东西描述不够清晰
  • 频繁改主意,代码里全是这些反复横跳的痕迹
  • 中途切换了技术栈,代码不同部分用了不同技术(通常也是需求频繁变更导致的)

要避免这种情况,你需要稍微理解软件是如何运作的。软件有三层:

  • 数据层:数据存储的地方
  • 控制层:软件运行的逻辑
  • 视图层:你在界面上看到的内容
大部分问题,都出在这三层不同步。

当你最开始描述需求时,它会对需要存什么数据、逻辑如何运行、界面显示什么做出假设。

改主意时,AI必须记得同时更新这三层。

Sud5j5uSPTTEz7Q230y5.png

如果只做简单的界面修改,可能只影响视图层,AI通常能直接处理好。

但如果是复杂的界面改动——比如想改变排序方式——可能会影响全部三层。可能需要修改数据存储方式、数据获取时机,才能改变界面排序。

这就是容易出错的地方。当AI忘记跨三层同步修改,或是修改不一致时,就会出现难以解决的bug。

前面提到给宠物做的健康追踪管理就是这样。随着不断迭代,需求一直在变。我想优化界面让输入更方便,但有些优化意味着数据存储方式也要改。改得越多,应用里的隐蔽bug就越多。

而且问题会不断累积。助手工作时,会倾向于遵循它看到的代码模式。如果它看到的是过时的视图层,在更新数据层时就可能做出错误决策。

这就是打破原有的项目重头再来的原因。第二次描述应用时,我已经清楚自己想要什么,需求没有变。Lovable才能正确搭建三层结构,我才能得到完全符合预期的结果。

03规划–评审–修正先想清楚,再开始工作。

每个优秀的产品经理都知道,一个想法在理论上听起来再好,一旦开始细化规格,问题就全出来了。细节才是成败关键。

用vibe coding时,如果我们边写代码边细化细节,成本很高——就算是AI助手写也一样。而且很容易产生bug。

AI会犯错。每次你改主意,都会带来一点技术债——旧想法的痕迹还留在代码里。这些技术债会迷惑后续处理,导致恶性循环,bug越来越多。

永远从规划开始,在规划方案上迭代。

有时只有一个模糊想法,要和AI一起把它变具体;有时我想法很明确,只需要写下来。无论哪种方式,每一次都要从规划开始。

不是PRD或者技术文档,而是小批量、迭代式的方式工作,不是传统大型项目那套流程。

系统性学习PMP的敏捷流程对个人小项目真的很有用。

实操案例

比如做一个回答产品探索相关问题的知识库。我对它有宏大愿景,希望它成为全能的coach。但需要时间一步步实现。

第一个目标,是能访问我所有写过的内容,这样它就能回答那些我已经有文字答案的常见问题。但我不知道怎么实现。于是找Claude帮忙,一起制定方案。

Claude梳理出了端到端的实现方式,解释了很多我不懂的东西,帮我选择服务商(比如向量数据库和嵌入API)。在讨论中,我不断补充和细化需求。我们用Markdown一起迭代,而不是用代码。

方案成熟后,也不是立刻开始写代码。而是把方案交给AI评审。

在和Claude的初始对话中,Claude会学到我的偏好(这是好事),也会学到我的偏见(这是坏事),它会继承我的思维盲区。我们俩都很可能漏掉关键细节,这些细节在实现时会引发问题。

方案评审的任务,就是用全新视角评估方案。

用来验证:

方案是否符合项目的编码规范和架构

没有过度设计

找出逻辑缺陷、思考漏洞、思维盲区,或任何值得注意的问题

不修复方案,只反馈问题。

然后我把评审的意见发给规划助手,一起整合有效反馈。我们重复这个循环,直到三方都满意:我、规划、方案评审。

这个循环对避免“死活修不好bug”的恶性循环至关重要。从一份扎实的方案开始,意味着我们不是在代码里思考,而是在文档里思考,只有确定至少第一个小模块要做什么时,才开始code。

用AI做规划时,记住这些方法:

频繁开启新对话:对话越长,AI表现越差,这叫“上下文腐烂”。我常分块规划:先做整体概览,理解端到端流程,写成文档,然后开新对话。下一轮对话深入某个模块,完成后清空上下文,再做下一部分。这样能保证助手始终输出高质量结果。

不只依赖AI的训练数据:我经常让第二个AI调研我们要做的东西,研究最佳实践,找出人们最常犯的错误,再把报告交给规划助手。

质疑AI的建议:如果某条建议听起来不对劲,或你不确定,让它澄清甚至解释理由。你不一定是专家,但你应该理解选择,并确保走在正确的路上。

让AI解释所有你不懂的东西:碰到不熟悉、不理解的内容,直接让AI解释。如果还不懂,告诉它哪里困惑,让它再讲一遍。

04实现–评审–修正方案准备好后,我会开启全新对话,重置上下文窗口。让新AI按方案实现功能。

如果规划做得好,AI应该能独立完成实现。完成后,它通常会让我测试改动。但我不会立刻测试。相反,我要让另一个AI检查编码的工作。

这就是AI代码评审的作用。AI代码评审会阅读方案、浏览代码库、评估改动,查找:

bug

重复代码

不必要的新模式或技术

过度设计

AI代码评审的核心目标,就是帮我们避开恶性循环,确保编码遵循良好的软件工程实践。

我会让代码评审重点关注三块:

异常处理

测试覆盖率

安全性

刚开始做时,我对这三块一窍不通,但一路学到了很多。这里我简单讲一下技巧。

全部评论 0

您需要登录后才可以回帖 立即登录
说说你的想法......
0
0
0
返回顶部