关于 AI 辅助编程，我为什么说"重上下文，轻模板"？

📌 核心观点

最近深度体验了一些 AI 辅助编程框架（比如 bmad-method、spec-kit），发现它们虽然有亮点，但在项目实战中，往往会遇到一个核心问题：框架的”模板”和”内置指令”占了太大的比重，反而稀释了我们项目自身的”上下文”。

这导致 AI 产出的方案不够贴合我们项目当前的代码现状，编码过程更像是在执行框架的指令，而不是在解决项目的实际问题。

想要让 AI 辅助编程（Vibe Coding）真正落地、高效，我们需要将重心从 “死板的框架模板” 转移到 “项目的深度上下文”。

---

🧐 为什么”模板”会让我们跑偏？

刚开始，这些 Web Coding 框架的完整性确实让人惊艳——它们考虑周全，一次性就能生成大量文档。但问题在于：

1. 不够聚焦： 一上来就想面面俱到（功能、体验、文档等），不符合我们先核心功能，再完善细节的开发习惯。
2. 修改成本高： 生成的方案过于庞大和规范化，人很难有耐心看完，需要进行大量的修改和适配。
3. 项目被”框架化”： 编码和思考过程被框架的内置 command 和模板牵着走，AI 更多的是在遵循框架规则，而不是在分析**“如何与现有代码兼容”**。

---

💡 更贴合项目的 Vibe Coding 三步走：核心是文档传递上下文

真正高效、踏实的 AI 辅助开发过程，应该更像一个**“人与 AI 协作、并通过文档传递上下文”**的协作模式。

我们发现，这个过程其实只需要聚焦在 “三个核心文档” 上，并且要允许 AI 在技术方案上灵活发挥，少受模板限制：

1. 📝 文档一：需求草案（原始输入）

• 作用： 明确目标。
• 内容： 尽可能清晰地描述你想要做什么。可以详细，也可以简略，关键是目标要清晰。这是整个流程的起点。

2. 📋 文档二：详细技术方案/执行计划（最核心的一步）

• 作用： 让 AI 深度结合项目现状，产出”接地气”的方案。
• 过程： AI 需要根据需求草案 + 项目当前代码实现，来生成一份详尽的技术方案或实现计划。
• 这才是重中之重！ 它必须回答：要引入什么概念？如何与现有代码融合？要在哪些类上修改？如何保持兼容性？
• 关键： 这里不需要复杂的模板控制。 方案内容要核心且精炼，由模型自由生成。我们（开发者）在这个阶段的工作是：不断地修改和完善 AI 产出的方案，直到满意为止。

3. ✅ 文档三：To-Do List 与任务跟进记录

• 作用： 拆分任务，跟踪进度，留存记录。
• 内容： 根据最终敲定的技术方案，将其拆分为几个可执行的、有明确完成条件的步骤。
• AI 依此列表逐个完成任务。
• 人或 AI 需记录： 任务已达成、具体做了哪些事（如 Commit 记录、关键修改点）。
• 规范化建议： 这个文档可以采用一个简单的模板来管理 To-Do List 和完成记录，方便追踪。

你看，这个流程其实和我们人自己开发很像！ 只不过我们将大脑中”任务拆解、方案思考、进度记录”的过程，通过这三个文档结构化地传递给了 AI。

---

🚀 我们的建议：管理”结构”胜过管理”模板”

我们的工作重点，应该是对项目中的这些文档目录和结构进行管理（比如，放在哪里、如何命名），而不是过度地去设计和控制文档模板。

只有在 “To-Do List 和任务记录” 上，我们才需要一个简单的结构模板。在**“需求草案”和”技术方案”**上，越轻量、越灵活越好。

此外，我们还需要一些灵活的命令（Command） 来辅助：

• 生成方案： 提供 根据草案生成方案 的 Command，并在这个 Command 中加载我们对项目特定的规则约束（比如，公司或团队的编码规范）。
• 执行步骤： 提供 实现To-Do List中的某一步骤 的 Command，让 AI 聚焦于执行 To-Do List 中的一个特定、有限的任务，并将完成情况自动记录到文档三中。
• 生成测试： 提供 生成测试用例 的 Command，同样加载项目的测试约束。

人的价值从未如此凸显

在这个流程中，人的作用是无可替代的：

1. 提出草案： 尽可能清晰地描述目标。
2. 严格 Review 方案： 对 AI 生成的技术方案进行严格审核和迭代修改。
3. Review 执行与代码： 对 AI 执行的每一步骤和最终产出的代码进行细致的 Review。

AI 负责执行和思考细节，人负责把控方向和质量。 这是一个扎实、高效、并且让 AI 真正服务于项目上下文的 Vibe Coding 实践。