组件库实战：完成前 5 个阶段任务开发
在本章节中，我们将演示一种与 AI 协同工作的开发模式，从零开始构建一个现代化的 Web 应用。我们将以一个 Markdown 微信渲染器（md-wx）项目为例，全程委托给名为 Builder with MCP 的 AI Agent 来执行具体的编码任务。
我们将从一个空目录开始，根据前面制定的相关文档，分为五个环环相扣的开发阶段，一步步见证 AI 如何理解需求、搭建脚手架、实现核心功能、修复 Bug、响应需求变更，并最终给我呈现出一个网页应用。
优先实现任务中的以下 5 个阶段：
- 阶段一：项目基础架构搭建
- 阶段二：核心预览功能开发
- 阶段三：主题系统开发与 AI 协同调试
- 阶段四：代码块增强与需求动态调整
- 阶段五：响应式布局与视图模式切换
1. 阶段一：项目基础架构搭建
项目开始的第一步是搭建一个稳定、可扩展的基础架构。我们将引导 Builder Agent 完成项目的初始化和基本配置。
1.1. 初始化项目
我们向 Builder 提供了需求分析、技术架构和设计指南等文档，并下达了第一个任务：完成任务 1.1：项目初始化和配置。我们明确要求它不要超出任务范围。
由于这是一个全新的项目，工作目录是空的。AI 首先检测到目录中已存在文件（是我们的 docs 目录），这一步需要我们手动选择，选 “忽略文件并继续”的选项，然后 AI 会自己使用 npm create vite@latest . --template react 命令来初始化项目。
接下来，Builder 按照技术架构文档的要求，逐步创建了 package.json、vite.config.js、.eslintrc.cjs、.prettierrc 等配置文件，并建立了规范的目录结构。整个过程完全自动化，无需人工干预。
它甚至还运行了 npm run format 和 npm run build 来确保一切正常。
1.2. 完善基础样式
在完成项目初始化后，我们接着让 Builder 完成任务 1.2，即基础样式系统的构建。它根据需求创建了全局样式文件和多个主题的 CSS Modules 文件。
1.3. 阶段成果预览
当第一阶段的所有任务完成后，AI 启动了开发服务器。我们可以看到一个初步的界面，预览区域显示“预览组件开发中...”，这标志着项目的基础架构已成功搭建。值得注意的是，AI 在完成指定任务后便停止了，完美地遵循了我们的指令。
2. 阶段二：核心预览功能开发
在搭建好基础架构后，我们进入了核心功能的开发阶段。
2.1. Markdown 渲染引擎
我们向 Builder 发出了新指令，要求完成“任务 2.1：Markdown 渲染引擎”的开发。
Builder 接收到指令后，首先分析了当前的项目结构，检查了 package.json 以确认依赖是否已安装。然后，它创建了 Previewer 核心组件，并集成了 react-markdown 和 remark-gfm 来实现 Markdown 的解析和渲染。
2.2. 预览容器组件
任务 2.1 完成后，AI 并未擅自继续，而是给出了下一步的建议，询问我们是继续开发“预览容器组件”还是“主题管理系统”。这种互动模式确保了开发节奏的可控性。得益于我们的项目规则制定。
我们选择继续开发预览容器组件。AI 随即创建了 PreviewContainer 组件，实现了预览头部、内容区域、玻璃拟态效果和响应式布局。
当任务 2.2 也完成后，它再次总结了成果，并创建了一个测试文档来验证功能。（注意，有时候 AI 会创建测试文档来验证，但验证完成后也不会删除，这种要么在制定项目规则时候，我们要求它删除，要么在任务完成后，我们手动删除。）
查看代码结构，基本上是按照我们的项目规则来实现的。
2.3. 阶段成果预览
最后，我们打开预览页面，可以看到 Markdown 输入区域的内容已经被成功渲染到了预览区域，包括标题、列表、代码块等元素都已正确显示。这标志着我们的核心预览功能已经开发完成。
3. 阶段三：主题系统开发
在完成核心功能后，我们进入了 UI 和用户体验优化的阶段。本阶段将着重于开发主题系统，并展示如何通过与 AI 的多轮交互来修复错误和完善细节。
3.1. 开发主题系统与设置面板
我们首先向 Builder 下达了“任务 3.1: 主题管理系统”和“任务 3.2: 设置面板组件”的开发指令。这两个任务可以合并执行，也可以分开。
3.2. AI 辅助调试：从报错到修复
在 AI 完成初步开发后，我们启动预览，但页面直接报错了。这是一个非常真实的开发场景。我们可以直接将报错页面的截图反馈给 AI，让它来诊断和修复。
AI 迅速定位了问题：useTheme.js 文件包含了 JSX 语法，但文件扩展名却是 .js。它立刻将文件重命名为 useTheme.jsx，解决了这个崩溃问题。
3.3. AI 辅助迭代：从功能 Bug 到完善
解决了报错问题后，我们发现新功能存在 Bug：点击主题切换按钮，主题并不会改变。
同样，我们通过截图和文字描述“点击切换主题不会变化，还是‘极简白’”来向 AI 反馈这个问题。
AI 在接收到反馈后，立刻开始排查 ThemeSelector 组件的状态管理、事件处理以及 useTheme Hook 的实现逻辑，进而定位并修复了问题。
3.4. AI 辅助优化：精细化样式调整
最后，我们希望对预览样式进行微调，要求“H2 ~ H6 标题前面增加竖线，星号包括的文字颜色跟主题变化”。我们描述得越清晰，并辅以参考图，AI 理解和执行的效果就越好。
AI 准确地理解了我们的需求，并立刻着手修改 Previewer 组件的样式文件。
3.5. 阶段成果预览
经过多轮的开发、调试和优化，主题系统终于完美地呈现在我们面前。从最终的预览效果可以看到，不仅主题切换功能正常，标题样式也按照我们的要求得到了更新。
4. 阶段四：代码块增强
在开发过程中，我们经常会遇到需求变更或初期设想不周全的情况。本阶段将以“代码块”功能的开发为例，展示如何与 AI 协作，动态调整任务，并对细节进行打磨。
4.1. 初版实现与需求调整
我们首先向 Builder 下达了“任务 4.1: 代码块组件”的开发指令。
AI 完成初版开发后，我们发现效果并不符合最终预期。于是，我们向 AI 提出了更具体的需求：“代码块期望在所有主题下保持一致，使用 github-dark 风格的高亮主题，语言标识和自定义组件替换都不需要。”
这个场景演示了 AI 的一个重要能力：动态任务调整。我们可以随时根据实际情况修正任务描述，AI 会理解新的需求并更新 task_breakdown.md 文档，确保任务目标与我们的预期保持一致。
4.2. 执行优化后的任务
在任务描述更新并聚焦后，我们让 AI 重新执行“任务 4.2: 代码块集成”。
4.3. 细节打磨：精准移除 UI 元素
任务执行完成后，代码块的高亮风格已经符合要求，但其顶部依然显示了文件名和语言标识等我们不需要的 UI 元素。
此时，我们可以借助 Trae IDE 的“选择元素”功能，直接在预览界面中点击我们不想要的部分，添加到聊天窗口。Trae 会更快的、更准确的定位到对应的代码，并生成移除指令。这种“所见即所得”的交互方式，比用文字描述要精准和高效得多。
4.4. 最终效果预览
经过这一系列的调整和打磨，代码块组件最终达到了我们想要的简洁、统一的视觉效果。
5. 阶段五：响应式和视图模式
我们依次向 Builder 下达了“任务 5.1: 视图模式切换”和“任务 5.2: 响应式优化”的指令。
这个阶段的开发过程非常顺利，AI 准确地理解了我们的需求，在设置面板中加入了“手机”和“桌面”的视图模式切换器，并对整体布局、边距、字体大小等进行了响应式优化。
最终的预览效果也完全达到了我们的预期，应用能够在不同视图下完美适配。
总结
本篇以一个 Web 应用的完整开发过程为例，演示了如何通过五个阶段的任务拆解，利用 AI Agent 高效完成项目。文中重点展示了开发者角色的转变：从具体的编码工作，转变为通过下达指令、提供反馈（如截图、文字说明）来引导 AI，并结合 IDE 工具处理需求变更、修复错误，全面呈现了人机协作解决真实开发问题的流程。
这个五个阶段相对还好，没有太复杂的内容，AI 基本上也能理解，并完成任务。下一篇会有些难度！