用 AI 做个旅行规划工具:开发计划扑街了

这是【用 AI 做个旅行规划工具】系列文章的第 13 篇文章。在上一篇文章里，我们明确了要做的系统，列出了开发计划，甚至明确了文件结构。就差一个程序员了。

这一期来讲讲这个苦逼程序员的故事。

相关文章：用 AI 做个旅行规划工具：从技术设计到开发计划

顺利开始

虽然之前的文档已经很齐全了，但在请出 AI 程序员时，我还是先让它判断这些文档是否足够支撑开发，先列 todo list，再逐条执行。我还特意跟它强调：不要亲自写实现，而是把任务分给 subagent，自己只负责监督和汇报，这样才能在合适时机并行调度多个 subagent。

它规划的路线基本跟开发计划一致：定义子模块接口，先把联动关系打通。

前两个任务执行得很顺，OpenAPI 的定义写好了。目录结构也建好了。

并行失败

第三个任务开始出问题。它反馈说由于“变更扩大化”，不得不向我报告，让我决定怎么办，刚开始我还有点懵，这啥意思？我追问后才明白，说是多个 subagent 改同一批文件，互相覆盖，谁也收拾不干净。

这是并行任务切分不合理的原因，说明 AI 的规划能力还是不太行。

我让它别并行开发了，改成一个任务一个任务串行推进。

后面几个任务就这样慢慢做完了。

自动化

前面几个任务里，每完成一个任务，AI 都会停下来让我确认状态。我一般会让它直接 commit 到 Git 里，这样后面要回退版本会更容易。

但后续任务还挺多，我想反正它每次停下来我也不看，干脆让它自己继续。

于是我让它按任务自行 commit，做完一个就接着下一个。

等我再次回到电脑前，发现它已经停下来了。它告诉我活都干完了，如果我愿意可以继续下一阶段。

意料之中的问题

一般来说，软件开发都不会这么顺利：

启动报错，重启报错，修复之后页面能打开，但后端接口也报错。

这些情况都还能接受，毕竟也不能指望 AI 写的程序不调试就直接上线。

但页面明显没经过设计：布局简单、几乎没样式，和之前的原型页面差得很远。

我怀疑是不是有任务漏执行了，就让 AI 再检查一遍。它说已经把之前规划的前两个阶段都做完了。

前两个阶段是指：

• • 阶段 0：接口定稿与工程脚手架
• • 阶段 1：方案域最小闭环

所谓最小闭环，按理说应该是所有功能都能正常运转，只是没有接第三方数据而已。

但显然这个样子是不对的。

归因分析

我又回头看了这次开发时让 AI 参考的几份文档，发现确实写得不够具体。

1. 1. 没有提页面要参考原型页面来开发
2. 2. 没有明确的数据结构
3. 3. 没有提到系统内的文件目录结构

如果按层来看，这批文档和代码之间还缺了一层文档，这一层应该包含具体字段定义、方法和返回值定义、文件与目录设计等。

这一层本来要靠程序员在开发过程中逐步补齐。很多时候也不会单独写成文档，而是直接体现在代码里。

AI 程序员在这一层的表现还不够好。不同模型的能力差异，可能就主要体现在这里。

退回小项目模式

我放弃了“让 AI 自动写完全部代码”的思路，先带着它把前端功能做扎实。

我先跟 AI 讨论这个前端项目的设计文档，包含技术选型、架构设计、目录和文件组织，以及配套约束。并且明确告诉它：这个子系统里不允许直接依赖其他子系统；如果一定要依赖，就先在系统内做一层适配器。

我还让它明确 UI 页面怎么开发和美化。讨论后的分工是：它先用前端框架实现基本功能；功能稳定后，我再找设计师基于现有页面出视觉方案。设计师只负责美化，不改业务逻辑；最后我再把设计稿交给它完成页面调整。

至于设计稿怎么做出来，我现在还没有想清楚，不过目前这个事情还不重要。

带实习生

方案出来后，我就带着 AI 一点一点把前端项目往前推。

先搭项目框架，再做页面实现，接着修正数据结构和接口、调整页面元素。过程很像在带一个干活很快但经验不足的实习生，最后才算把前端一步步做出来了。

这个过程跟自己开发相比，差异还是很大。效率确实快了不少，但更明显的是心态变化。以前返工成本高，通常要先想清楚再动手；现在迭代和重构没那么难，局部开发可以边做边想：先出一版，再慢慢重构，逐步完善。

大项目依然是工程问题

之前和 AI 聊需求、聊设计时，会觉得它考虑得很全面；但真正落到细节，才发现还有很多步骤需要反复磨合。

AI 对开发效率的提升很明显，但主要局限在实现层。即使文档写得足够清楚，也还是需要人盯着它的产出；对于大项目，人的参与依然必不可少。

所以问题并不是“AI 能不能替代开发”，而是我们能不能把问题描述、结构划分和协作流程设计得更好，尽量减少过程中的人工介入。

这次先记录到这里。项目还没结束，欢迎关注后续更新，看看 AI 开发到底能走多深、走多远。