Marico's space

最近折腾了一阵 AI 辅助开发前端应用，踩了几个坑，终于把这里面的门道摸清楚了。这篇把从一句话需求到最终发布的完整流程说清楚，不废话。

AI “写代码”不够用：得把 AI 融入开发流程

很多前端开发者都用过 AI 生成组件、函数或测试用例。但问题在于体验往往是割裂的：一边是聊天窗口，一边是编辑器，最后部署全靠“感觉”。真正的提升是把 AI 集成到 IDE 里面，让它成为结构化工作流的一部分：

1. 规划与需求确认：动笔之前先把需求搞清楚。
2. 脚手架搭建：自动化初始化（技术栈、目录结构、工具链）。
3. 受控协作：建议、重构、重命名、代码审查。
4. 并行任务分配：多个专业智能体同时处理。
5. 发布准备：检查清单和自动化流程。

目标不是“让 AI 全权写代码”，而是大幅减少在样板代码和协调沟通上浪费的时间，同时保持对项目的掌控和理解。

两种工作模式：辅助 vs 委托

一个以 AI 为核心的 IDE 通常提供两种互补的工作模式：

• IDE 模式（协作式）：你照常工作（编辑器、终端、调试器、Git），AI 在旁边辅助生成代码diff、解释代码、建议修复和重构方案。你始终掌控方向盘。
• 自主模式（委托式）：你描述一个目标，AI 尝试端到端执行（规划、修改文件、安装依赖、执行命令、验证结果）。你负责监督和审批。

可以这样理解：IDE 模式优化的是微决策，自主模式优化的是宏观任务。

真正改变游戏规则的部分：从需求文档开始，而非代码

无论用不用 AI，最常见的弱点都是：用模糊的想法就开始“动手干”。集成了 AI 之后，正确的做法是把一句话转化为一整份需求文档。

有用的输入示例（自然语言）：

“我想要一个现代化的习惯追踪全栈应用：有注册/登录、习惯创建、每日打卡、连续天数统计、周统计。把这个转化为软件需求文档。”

从这句话出发，AI 可以在几秒内生成通常需要花时间和精力才能产出的大量内容：

• 核心功能和范围外的功能清单；
• 用户故事和验收标准；
• 技术栈建议（如 React + TypeScript、Tailwind；后端 Node/Express；数据库 PostgreSQL）；
• 数据模型和 API 接口的初步设想；
• 分阶段的路线图。

MVP：明确缩小范围

聪明的做法是立刻追问：

• “v1 MVP 阶段能实际完成哪些？”

一个定义清晰的 MVP 让你能验证价值和流程，而不需要一开始就构建全部功能（高级认证、角色权限、复杂数据分析、同步功能等）。很多情况下，从这些开始就够用了：

• 简单认证（甚至“假登录”都行）；
• 习惯管理；
• 每日追踪 + 连续天数统计；
• 基础统计；
• 本地持久化（LocalStorage）或一个极简后端。

收益巨大：AI 在问题被约束的情况下表现好得多。

从任务清单到脚手架：省下 30 分钟（甚至几小时）的样板代码

需求文档确认之后，下一步是生成一个可执行的阶段式任务清单。一个现代前端应用通常包含：

1. 项目初始化（React + TS）
2. Tailwind 配置（主题、配置、目录结构）
3. 路由和布局
4. 基础组件
5. 认证界面
6. 仪表盘 + 习惯 CRUD
7. 追踪 + 连续天数 + 统计

这时候可以把脚手架搭建交给工具：创建目录、页面、组件，安装依赖，启动开发服务器。

这里只有一条铁律：main 分支里不出现没看过的代码。

• 检查生成的文件；
• 验证命名和结构；
• 确认依赖是否合理；
• 确保最小化 UI 能正常运行。

如果项目从一开始就能跑通（登录/注册/仪表盘），初始阻力就小了，可以专注于真正重要的部分。

日常编码：省脑力的助手

除了大任务，日常工作的价值来自一个“始终在线”的助手，它能：

• 给出多行代码补全建议；
• 预测下一步改动（而不只是下一个词）；
• 自动处理import 导入；
• 支持项目级的重命名；
• 在建议的修改之间导航。

这类 AI 不会替代架构决策，但能把重复操作的成本砍掉（也减少了低级错误，比如漏掉 import、重构不完整、命名不一致）。

多智能体：告别单线程工作

当应用规模增长，瓶颈不再是写代码行数，而是协调工作、上下文和优先级。

多智能体模式正是要解决这个问题：专业智能体并行工作。

具体可行的例子：

• UI/品牌智能体：应用配色方案、统一间距、使组件和主题保持一致。
• 后端智能体：搭建 Node/Express + PostgreSQL，创建数据模型和主要路由。

你分配两个独立任务，让它们同时启动，然后：

• 审查变更；
• 解决冲突；
• 确保一致性（API 契约、命名规范、错误处理）。

自定义智能体：关键是给约束，而非给“灵感”

一个有用的前端智能体不应该是“优化 UI”，而应该像这样：

• “你是一个前端开发工程师。使用以下颜色：green、base navy、accent blue、highlight orange、error red。其他颜色仅在必要时使用。更新 Tailwind 主题和组件以保持一致性。”

指令越可操作，输出越稳定。

MCP：当智能体需要和真实工具对话

近期发展的重要一环是 Model Context Protocol（MCP）（模型上下文协议）：一种让模型/智能体与外部服务通信的标准。

实际上它支持的场景包括：

• 查询内部文档或企业 API；
• 对接工单追踪工具；
• 访问知识库、数据库、生成器、自定义工具。

对于前端团队来说，这意味着可以把智能体变成“有权限获取权威信息源的同事”，而不是靠猜测的模型。

安全与控制：两个必须开启的设置

把 AI 集成到工作流会提升效率，但也会引入新风险。有两个配置应该是标配：

• 隐私模式：减少代码片段和对话被用于训练/改进的可能性。
• 终端命令沙箱：如果 AI 执行命令，在受控环境下运行能降低执行危险操作（或简单出错）的风险。

总体原则：把速度和执行交给 AI，但权限、命令和合并的掌控权留在你手里。

实践建议：现在就能用的工作流

如果你真想将 AI 融入前端工作，可以复用这个模式：

1. 写下你的点子那句话。
2. 让它变成需求文档 + MVP，范围定义清楚。
3. 生成一个阶段式任务清单。
4. 让 IDE 创建脚手架（但全部审查一遍）。
5. 用助手做微优化（重命名、import、重构）。
6. 复杂度上来后切到多智能体：UI 和后端并行跑。

真正的效率不在于“让 AI 写代码”，而在于把开发变成一条可重复的流水线：需求清晰、迭代短平快、任务委托明智、全程可控。这样做出来的应用才真正能跑起来，发布也不再是最后那道过不去的坎。