欢迎来到AI原生应用构建实录的第二部分。

在（上篇）中，我们详细规划了AI英语学习应用的“是什么”——从教育学基础到技术架构，绘制了一份完整的蓝图。现在，我们将直面一个更具挑战性的问题：“如何做”？

随着AI编码工具的普及，开发者很容易陷入“Vibe Coding”（凭感觉编码）的陷阱：在没有清晰规划的情况下，快速生成大量缺乏结构和文档的代码，最终留下一堆难以维护的技术债务。

本文旨在解决这一核心痛点。我们将探讨如何超越简单的代码自动补全，建立一套系统性的、由AI赋能的开发工作流。这套流程将引导我们从模糊的“感觉”走向可靠的“代码”，确保项目在高速迭代的同时，保持高质量和高可维护性。

第一部分：战略分野：Agentic CLI工作流与IDE集成助手的对比分析

在利用AI进行软件开发时，两种主流工具范式——集成开发环境（IDE）内的助手与命令行界面（CLI）的智能体（Agent）——存在着根本性的战略差异。

1.1. 范式一：IDE即驾驶舱（如 GitHub Copilot, Cursor）

此范式将AI视为无缝集成在开发者熟悉环境中的“辅助驾驶员”，核心理念是增强开发者的直接行动力。

  • 优势：直观、低摩擦的用户体验。非常适合执行快速、上下文明确的局部任务，如函数补全、生成样板代码。
  • 局限性：对项目全局上下文的理解有限。在处理跨多个文件的重构或实现涉及整个应用架构的复杂功能时效率低下。其根基依然是“辅助”而非“编排”。

1.2. 范式二：CLI即合作者（如 Cline, Roocode, Aider）

此范式将AI定位为一个独立的“合作者”，开发者通过对话式的指令在终端中进行指挥。

  • 优势：
    • 强大的控制力与可脚本化能力：与命令行工具无缝集成，自动化潜力巨大。
    • 进程隔离带来的稳定性：智能体作为独立进程运行，其错误不会导致IDE崩溃。
    • 模型选择的灵活性：大多支持“自带密钥（BYOK）”，可连接多种商业及本地模型，兼顾成本与隐私。
    • 为复杂、多步骤任务而生：天然适合执行大规模代码重构、实现新功能或进行自动化测试。
  • 权衡：学习曲线相对陡峭，初始设置更复杂。

1.3. 战略洞察：从“代码优先”到“规约优先”的伟大倒转

IDE助手倾向于“代码优先”，根据注释生成代码，这容易导致“Vibe Coding”。而Agentic CLI工具则天然适合一种更先进的模式——“规约驱动开发”（Spec-Driven Development）。

在这种模式下，开发流程被彻底倒转。开发者的首要任务不再是“写代码”，而是与AI协作，将高层次目标分解为详细的规约（Specs），包括需求文档、技术设计和任务列表。这些规约成为开发过程的“唯一真相来源”，所有代码的生成和修改都必须遵循并反向更新规约。

这标志着开发者的核心价值从“执行者”转变为“战略家”，将主要精力投入到定义问题和设计蓝图上。

表1：AI编码工具范式战略对比

特性/维度 IDE集成助手 (例如: Cursor) Agentic CLI工具 (例如: Roocode) 对项目管理的战略影响
核心工作流 增强式：AI作为IDE内的无缝辅助 协作式：AI作为独立的合作者 IDE优化个体效率，CLI侧重任务的结构化与自动化。
项目上下文范围 有限，大型项目性能可能下降 全面，更适合全局任务 CLI能更好地处理大规模重构和跨模块功能实现。
控制与粒度 有限，通过UI控制 极高，每一步操作都可审查和批准 CLI允许实施严格的、多阶段的开发流程。
模型灵活性 有限，通常绑定特定供应商 极高，支持BYOK，可连接多种模型 允许根据任务和成本灵活选择最优模型，并能保障代码隐私。
稳定性与隔离 较低，插件崩溃可能影响整个IDE 极高，作为独立进程运行，故障被隔离 在执行复杂、长时任务时更可靠。
最佳适用场景 快速原型、单文件任务、代码补全 复杂项目管理、大规模重构、自动化测试、规约驱动开发 对于中大型项目，CLI范式提供了必要的结构和控制力。

第二部分：掌握Agentic工具链：最佳实践的综合与应用

本部分将解构前沿Agentic工具的设计哲学，并提出一个在Roocode中实现的可操作开发框架。

2.1. 解构大师：次世代工具的核心哲学

  • Kiro (亚马逊): “活规约”的架构师。其核心是“规约驱动开发”，通过“钩子”机制确保代码与文档的自动同步，从根本上解决技术债务。
  • Claude Code (Anthropic): “TDD纯粹主义者”。极度强调代码的正确性，推崇严格的测试驱动开发（TDD）循环，并引入“子智能体”概念进行独立代码审查。
  • Gemini CLI (谷歌): “博学的研究员”。利用巨大的上下文窗口和内置的搜索工具，让AI在研究外部API文档、解决未知技术问题时表现出色。

2.2. 为何选择Roocode

在Cline和其分支Roocode之间，我们选择Roocode。Cline更像一个稳定但迭代缓慢的“产品”，而Roocode则是一个快速迭代、功能丰富、高度可定制的“平台”。对于希望构建定制化工作流的资深开发者而言，Roocode的平台哲学和**自定义模式（Custom Modes）**功能，是实现我们框架的完美载体。

2.3. “Vibe to Viable”框架：在Roocode中实现的可操作工作流

本框架旨在将模糊的“感觉”转化为可落地、可维护的“代码”。

第一阶段：规约定义 - 使用 SpecArchitect 模式 (灵感源自Kiro)

  • 目标：在写任何代码前，将高层次需求转化为全面的开发蓝图。
  • 实现：创建一个名为 SpecArchitect 的自定义模式，指导AI接收高层指令，然后生成三个核心规约文件：requirements.md (用户故事), design.md (技术设计、API、DB Schema), 和 tasks.md (原子化的任务清单)。

第二阶段：测试驱动实现 - 使用 TDD-Developer 模式 (灵感源自Claude Code)

  • 目标：严格遵循蓝图，以TDD方式高质量地完成每个任务。
  • 实现：创建一个 TDD-Developer 模式，它接收一个tasks.md中的任务，并严格执行TDD循环：1. 写一个失败的测试 -> 2. 写最少的代码让测试通过 -> 3. 运行所有测试 -> 4. 提交代码和测试供审查。

第三阶段：持续集成与审查 - 使用 DocuHook 和 CodeReviewer 模式

  • 目标：自动化文档更新和代码审查，杜绝技术债务。
  • 实现：
    • DocuHook：一个在Git提交钩子中运行的模式，读取git diff并自动更新design.md。
    • CodeReviewer：一个独立的审查模式，根据项目规范对变更的代码提出修改建议，但不直接修改，模拟同行评审。

2.4. 框架验证：映射开发者经验

这个框架系统性地解决了开发者在实践中遇到的常见问题，例如“先写文档，再写测试”、“任务必须具体”、“代码文件不宜过长”等。通过自定义模式和项目级规则文件(.roorules)，这些宝贵的经验教训可以被固化为自动执行的流程。

第三部分：AI原生应用的蓝图：一份规约驱动的开发计划

现在，我们将应用“Vibe to Viable”框架，为我们在上篇中设计的AI英语学习应用，提供一份具体的、分阶段的开发蓝图。

3.1. 项目初始化：智能体引导与自定义模式配置

在编码前，首先配置Roocode环境：

  1. 创建自定义模式: 在.vscode/roo-settings.json中定义SpecArchitect, TDD-Developer, ContentGenerator, CodeReviewer等模式。
  2. 创建项目规则: 在项目根目录创建.roorules文件夹，并定义product.md (产品愿景), tech.md (技术栈), structure.md (目录结构)等规则文件。

3.2. 第一阶段 (MVP)：构建核心对话与练习循环

步骤1：使用 SpecArchitect 生成MVP规约

  • 开发者指令: 
    > @mode spec-architect
I need to build the MVP for an AI English learning app. Core features: 1. User can select CEFR level and scenario. 2. System generates vocabulary/sentences for practice. 3. System provides an AI tutor for role-playing conversation. 4. Support STT/TTS. Generate the full specifications...
  • 预期工件: requirements.md, design.md, tasks.md。

步骤2：使用 TDD-Developer 实现后端API

  • 开发者指令: 
    > @mode tdd-developer
Implement Task #3 from tasks.md: 'Implement /scenarios API endpoint'.
  • 工作流: 智能体将严格按照TDD流程，先生成测试，再编写实现代码，供开发者分步审查。

步骤3：使用 ContentGenerator 生成初始学习内容

  • 开发者指令: 
    > @mode content-generator
Using the JSON schema defined in design.md, generate 10 initial vocabulary items for the 'A1 - At the Cafe' scenario. Output as a seed_data.json file.

3.3. 后续阶段：迭代开发反馈引擎与自适应循环

对于第二、三阶段的复杂功能（如发音评估、自适应学习），我们重复这个流程：

  1. 使用 SpecArchitect 模式，通过高级指令更新现有规约，生成新的设计和任务。
  2. 使用 TDD-Developer 模式，逐一完成新任务列表中的功能开发。

这种迭代式的、规约驱动的方法，确保了即使在添加复杂功能时，项目依然保持清晰的结构和高质量。

表4：第一阶段 (MVP) 开发计划示例

任务ID 描述 使用的智能体模式 预期工件/变更 验证步骤
SPEC-01 生成MVP的完整规约 SpecArchitect requirements.md, design.md, tasks.md 开发者审查并批准所有规约文件。
BE-01 初始化FastAPI项目结构 TDD-Developer 创建项目骨架 运行pytest，无错误通过。
BE-02 定义数据库模型 TDD-Developer app/models.py 运行Alembic生成并应用迁移。
BE-03 实现/scenarios API TDD-Developer app/routers/scenarios.py, tests/test_scenarios.py 运行pytest --cov，确保测试通过且覆盖率达标。
… … … … …
REVIEW-01 对整个后端代码进行审查 CodeReviewer 生成一份包含修改建议的审查报告。 开发者根据报告进行手动修改。

通过这两篇详尽的分析，我们不仅为一款AI原生应用设计了产品和技术蓝图，更重要的是，我们建立了一套科学、可控的开发哲学和工作流程。它使我们能够驾驭AI的强大能力，而不是被其创造的混乱所吞噬。

这标志着我们真正从“凭感觉编码”（Vibe Coding）迈向了“用工程构建”（Viable Code）的新时代。