用 AI 做个旅行规划工具:从技术设计到开发计划

这是一篇【用 AI 做个旅行规划工具】系列中的文章，文末有链接可以阅读合集。

上一期的文章里，我们简要介绍了这个项目技术架构的全景，这篇继续深入，把技术架构落实到开发计划上。

相关文章：

• 用 AI 做个旅行规划工具：一览全局版
• 用 AI 做个旅行规划工具：讨论技术架构
• 用 AI 做个旅行规划工具：技术架构全景

总计划

我让 AI 先回顾了一下之前的技术架构文档，让它分析这些文档是否足够支撑开发。如果足够，再列一个具体的开发计划。

我强调说这个计划要具备可实施性、可测试性，并且能阶段上线，不能规划成全部开发完成后一起上线的模式，要按阶段合理规划。

它倒没说有啥问题，包含 5 个阶段的开发计划很快就出来了：

我本来还期待它能一步到位，但看来我还是把它想象得太厉害了。

这个计划跨度太大，而且每个阶段的任务描述得并不是很清楚，为了能平稳落地，我决定先让它把前两个阶段再详细计划一下。

第一步

我让 AI 把前两个阶段单独写成一个分册，并强调要认真展开。设计时要考虑分工和测试过程，比如前端能否单独测试、后端能否单独上线等。

结果仍然还不够详细。

它问我要不要直接排期。我告诉它我没有团队，它自己就是我的团队，需要它考虑如何调动多个 subagent 并行开发来提高效率。

它的计划里只提到了要先把 API 冻结下来，但是并没有说怎么做，我便告诉它要想好项目文件怎么组织，脚手架怎么搭建等。

它于是把我的这些意见都一一落实到了这个开发计划里。

文档职责

我发现它把项目目录结构都写进了开发计划里，于是我告诉它要搞清楚 Plan 和 Tech 的区别：Plan 只涉及 Who、What、When；具体做法属于 How，应该放在 Tech 里。

AI 很虚心地接受了我的建议，并新开了一个 Tech 文档把设计补充了一下。

计划与设计

这是按阶段、按角色整理出的任务清单：

这是它推荐的项目文件结构：

这是它对各目录的解释：

只有详细到这一层，我才能相信它排的计划是可落实的。

向 AI 学习

一开始我觉得这套设计有点复杂，但跟 AI 请教了一轮后，感觉这样安排确实也挺好：

为什么 apps/web 还要分两层？

这是在做轻量前瞻。因为虽然今天只有 web，但未来可能出现：

• • apps/admin（运营后台）
• • apps/docs-site（文档站）
• • apps/storybook（组件展示）
• • apps/mock-console（联调控制台）

即使未来没有第二个 app，这个两层成本也很低，但换来了更清晰的边界和 CI 分工。

packages 要不要放到 apps/web 下面？

不建议，因为这些代码不仅 web 可能用，e2e、脚本、甚至未来其他前端入口都可能复用。

openapi 目录里到底放什么？

它是结构化的接口文档，包括：

• • openapi.yaml：
• API 路径、方法、请求体、响应体、错误码、鉴权方式

• • schemas/*.yaml：
• 公共数据结构（如 SchemeBundle、MutationRequest）

• • examples/*.json：
• 请求/响应示例，供 mock 和测试复用

• • README.md：
• 维护规则：如何变更、如何生成 client、版本策略

为什么不用纯 TS interface 定义 API？

TS interface 很适合前端内部模型，但不足以单独承担跨边界 API 协议：

• • TS interface 对 HTTP 协议语义表达不足
• • 对非 TS 组件与测试工具链兼容性较弱。

总结与体会

这个项目推进到现在，从需求到设计，再到当前的开发计划，AI 确实加速了很多。但随着合作深入，我也越来越能感受到它的能力边界。

AI 能给出宏观建议，也能完成具体功能，但它还不能在合理架构下，一口气把整个项目代码写完。就像它能写短篇小说，却不擅长写长篇小说。那种从全局到局部收放自如的思考能力，依然是人类的智力优势。

至少目前还没有被 AI 超越，但留给人类的时间已经不多了。

以上就是这次分享的主要内容。如果你也在用 AI 做项目，希望这些记录对你有帮助；如果你也有独特实践，也欢迎交流。