AI写代码前，我先和智能体反复规划

为什么规划要先于编码

很多开发者习惯直接把需求丢给 AI，期待它立刻生成可运行的代码。但 YouTube 博主在分享自己的工作流时给出了不同答案：先规划，再编码。他会在动手之前，与接入 Spaceship 的 AI 智能体进行多轮讨论，探索不同方案、拆解代码组件，确保对问题有概念性理解之后，才着手制定计划。

这种做法看似拖慢了起步速度，实际上减少了后期返工。当 AI 在不清楚上下文的情况下直接写代码，往往需要反复修改；而前期投入时间做规划，能让后续的编码过程更有方向感。

规划是一个迭代探索的过程

博主强调的不是一次性写完计划，而是多轮迭代。他会和 AI 智能体讨论不同的想法，探索代码的不同组件，逐步收敛到可行的方案。这种迭代式规划的价值在于：

• 暴露盲区：在讨论中发现自己没想到的边界情况
• 比较方案：让 AI 列出多种实现路径的优劣，而不是直接选第一条路
• 建立共识：确保自己对要解决的问题有清晰的概念理解，而不是模糊地“让 AI 看着办”

这种做法把 AI 从“代码生成器”变成了“设计讨论伙伴”。博主描述自己的流程是：先进行初始讨论，在概念层面理解问题，然后才构建出计划。

一个真实案例：Semantic Router 的改进计划

博主展示了自己正在推进的一个小型计划——围绕 Semantic Router 的改进。他的目标很明确：

1. 让 Semantic Router 更快
2. 提升可扩展性和可靠性
3. 使其能够与决策模型集成

这份计划是快速整理出来的草稿，并非最终文档。但正是这种“先有粗略计划”的做法，让后续与 AI 的协作有了锚点。

从这段分享可以看出，计划本身不需要完美。博主用的是“small-ish plan”“rough plan”“quickly thrown together”这样的描述——重点不在于计划有多精细，而在于它是否足够清晰地表达了目标和约束，让 AI 能在正确的方向上提供帮助。

Semantic Router 是一种用于语义路由的开源工具，通常基于向量嵌入（embedding）对用户查询进行意图分类，从而将请求动态分发到合适的处理逻辑或模型。它常被用于构建智能体系统、RAG 流水线或多模型调度场景：系统先计算查询与预设「路由」描述的语义相似度，再决定走哪条路径。这类路由器的性能瓶颈往往在嵌入计算与索引查找上，因此「更快」「可扩展」和「与决策模型集成」是常见的改进方向——前者涉及缓存、批处理或更轻量的嵌入模型，后两者则关系到路由规则的组织方式以及如何把路由结果交给下游决策模型使用。

这种工作流适合谁

对于使用 AI 编程工具的开发者来说，这套方法有几个可借鉴之处：

把讨论和编码分开。在让 AI 写第一行代码之前，先用对话把问题聊透。Spaceship 这类工具支持接入多个智能体，正好可以用来做方案对比。

接受计划的粗糙度。不必等到计划完美才动手，一份快速整理的目标清单就足以启动协作。

用计划约束 AI 的输出。有了明确的目标（更快、更可扩展、可集成决策模型），AI 生成的代码建议就有了评估标准，而不是盲目接受。

博主没有展开讲具体的代码实现细节，但这条工作流本身传递的信号很清楚：AI 编程的效率提升，不只来自模型能力，也来自人如何使用它。规划环节投入的思考，最终会体现在代码质量上。

文中提到的 Spaceship 属于一类支持接入多个 AI 智能体的开发环境/平台，其特点是可以在同一个工作区内切换或并行调用不同的模型与智能体，并保留对话上下文。这类工具的价值不只是「能调用模型」，更在于让开发者把多轮讨论、方案对比和计划整理都沉淀在同一个可追溯的会话里。相比单次问答式工具，多智能体环境更适合做「设计讨论」——可以让不同智能体分别扮演方案提出者与批判者，从而在编码前暴露更多问题。