做软件这件事，跟盖房子差不多。画设计图，选材料，搭骨架，做内装，再检查有没有漏水的地方。

整个过程中最耗时间的，不是砌砖本身，而是决定砖往哪儿砌、怎么砌，以及砌完之后确认有没有砌对。Claude Code和Cowork正是在这个「决策与验证」的环节，替开发者和产品经理减轻负担。

这一章跟前面第1到第6章性质不同。虽然涉及代码，但没有编程经验的读者也能跟着完成需求定义文档（PRD）撰写、测试用例文档生成之类的策划工作，门槛刻意压低了。至于智能体团队运作、代码迁移这些需要开发经验的领域，重点放在概念理解上，实际操作面向中级以上的读者。

1 基于智能体团队的并行作业

一个人干四个人活的开发者的一天

假设要做一个Web应用。

得做用户看到的界面（前端），得搭界面背后处理数据的服务器（后端），得设计存储数据的数据库。还得收尾测试这三者能不能顺畅地咬合运转。

一个人按顺序做这四件事，前一项没做完就没法开始下一项。后端没写好，前端就没法调数据；数据库结构没定下来，后端代码就没法写。这种串行瓶颈，是拉长开发周期的头号原因。

实际企业里靠团队来解决这个问题。前端开发、后端开发、数据库管理员、QA工程师各管各的，同时推进，需要的时候互相沟通协调。智能体团队（Agent Teams）就是用AI复刻了这种人类团队的结构。

什么是智能体团队

智能体团队是多个Claude Code实例（Instance，同时运行的独立AI会话）各自承担不同角色，并行推进同一个项目的功能。2026年2月随Claude Opus 4.6发布，以研究预览（Research Preview）的形式公开。

在此之前已经有子智能体（Sub-agent）的概念。

子智能体的工作方式是：主智能体下达任务，子智能体独立执行后只把结果送回来。问题在于子智能体之间无法互相对话。前端子智能体没办法直接告诉后端子智能体「API地址改了，你把代码改一下」。所有消息都必须经过主智能体中转，这个瓶颈导致复杂项目中代码冲突频发。

智能体团队改变了这个结构。团队成员之间可以直接收发消息。通过共享任务列表（Shared Task List）查看谁在做什么，一项任务完成后自动领取下一项。由担任团队负责人（Team Lead）角色的智能体统筹全局，但实际业务沟通在成员之间直接进行。

[知识补充] 什么是智能体实例？指一个Claude Code会话。每个实例拥有自己独立的上下文窗口（Context Window，AI一次能记住的信息范围），独立运行。Claude Opus 4.6支持每个实例100万token（约75万个单词）的上下文窗口，可以把大规模代码库整个加载进来工作。

智能体团队怎么用

（1）基本用法：激活智能体团队并首次运行。智能体团队属于实验功能，需要手动开启。

① 打开Claude Code的配置文件（settings.json）。

② 添加这一行：「CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS」: 「1」

③ 保存配置，重启Claude Code。

④ 在终端中输入如下指令：「请分析这个项目的README.md文件和整个文件夹结构，然后创建一个由安全审查负责人和代码质量审查负责人组成的两人智能体团队，执行代码审查。」

⑤ Claude Code自动担任团队负责人角色，生成两个成员智能体。终端上会显示每个智能体的活动日志。

⑥ 成员智能体各自分析代码，把发现的问题通过消息互相共享。团队负责人汇总结果，生成最终的审查报告。

（2）进阶用法：用tmux分屏显示各智能体。装好tmux（终端复用工具）之后，可以把各智能体的工作画面分屏同时观察。

① 在tmux已安装的状态下运行智能体团队，屏幕会分成多个面板，每个智能体的终端单独显示。

② 按Shift + 方向键切换到某个智能体的面板，可以单独给那个智能体下达指令。

「前端智能体，把刚做的登录页面上的按钮颜色从蓝色改成藏青色。」

③ 该智能体收到指令后执行修改，并将变更通知其他团队成员。

（3）实战案例：搭建博客平台项目。以构建一个中小规模博客平台为场景。

① 在项目文件夹中准备好需求文档。（PRD的写法会在本章第2节介绍。）

② 对Claude Code输入如下指令：

「请读取这份PRD，创建由后端API负责人、前端UI负责人、数据库Schema负责人、测试编写负责人组成的智能体团队。后端智能体用Node.js和Fastify实现REST API，前端智能体用React实现UI。数据库智能体先确定PostgreSQL的Schema，再共享给其他智能体。测试智能体为每个API端点编写单元测试。」

③ Claude组建团队并分配任务。数据库智能体先确定Schema，随后后端智能体和前端智能体以该Schema为基准同时编写代码。

④ 工作推进期间，团队负责人会汇总进度并展示。如果出现冲突，会判断优先级后加以解决。

使用智能体团队需要知道的事

智能体团队的token消耗量很大。每个成员维持独立的上下文窗口，还要互相收发消息，同样的工作用单个智能体做的话，成本可能翻4到7倍。写个小脚本、整理几个文件这类事情，没必要动用智能体团队。

智能体团队发挥作用的场景很明确：需要同时触及多个层级（前端、后端、数据库、测试）的项目，需要同时验证不同假设的调试工作，以及大规模代码审查这种并行探索能产生实质价值的情况。

还有一点。智能体团队产出的代码，单独看可能挺干净，但放到整个系统的语境下，可能引发意想不到的冲突。一个智能体为了性能引入的缓存结构，

可能跟另一个智能体写的实时同步逻辑撞在一起。智能体写代码的速度是快了，但判断这些代码在整个系统中如何运作，这个责任仍然在人身上。

遇到这些问题怎么办

（1）创建了智能体团队，但只发了一条消息就断开了。检查settings.json中的智能体团队配置是否正确保存，确认双引号和冒号的位置无误，然后彻底退出Claude Code再重启。

（2）成员智能体同时修改同一个文件，导致代码损坏。在提示词中明确文件所有权。加上一句「每个智能体只修改自己负责的文件夹内的文件，其他智能体的文件只读不写」，可以减少冲突。

（3）token用量远超预期。减少团队成员数。3个人就够的工作塞5个人进去，只会增加协调成本。Pro套餐不如Max套餐适合智能体团队作业。

2 软件需求定义文档与架构文档化

为什么「做个带支付功能的App」注定失败

让AI写代码，最常见的失败原因不是AI能力不够，而是指令太模糊。你说「帮我做一个带支付功能的项目管理App」，AI就会自己填补大量空白：支付方式是银行卡还是转账？用户认证用邮箱还是社交登录？项目管理的单位是团队还是个人？AI自行填入的假设一旦偏离用户意图，产出的东西谁都不想要。

需求定义文档（PRD，Product Requirements Document）就是提前把这些空白填好的文件。要做什么、给谁用、成功标准是什么、这次不做什么，全部写清楚。PRD的质量决定项目的成败。

二 Claude Code生成的PRD长什么样

用Claude Code的计划模式（Plan Mode），AI一行代码都不写，只专注于分析和设计。你把脑子里零散的想法输进去，AI会抛出一连串系统性的问题来补上漏洞，再把结果整理成几十页的规划文档。

最终产出包含这些内容：服务目标和成功标准、核心用户旅程（User Journey）、功能需求和非功能需求（性能、安全、可用性）、数据库Schema（表间关系、数据类型、约束条件）、系统架构（技术栈、基础设施部署、认证体系），以及测试场景。

三 动手做一份PRD

(1) 基础用法：从创意中提炼问题清单

① 打开Claude Code终端，切换到计划模式。

② 输入以下内容。

「我想做一个二手物品交易App。基于位置的搜索、聊天、托管支付是核心功能。在写代码之前，为了减少对我项目的假设，请提出至少10个澄清问题。」

③ Claude会给出如下问题：「基于位置搜索的默认半径设为多少公里？」「聊天中是否支持发送图片？」「托管支付的手续费率定多少？」「注册采用邮箱验证还是社交登录？」「是否需要卖家认证流程？」

④ 逐一回答每个问题。

⑤ Claude根据所有回答生成PRD初稿。

(2) 进阶用法：加入数据库Schema和API规范

① 确认基础用法中生成的PRD初稿后，输入补充指令。

「基于这份PRD，用Prisma格式设计数据库Schema。包含User、Product、Transaction、Chat、Review表，标明各表关系和索引。再把核心API端点整理成OpenAPI格式。」

② Claude生成Prisma Schema文件和OpenAPI规范。

③ 打开生成的文档，逐项审查内容。

(3) 实战应用：将PRD作为智能体团队的执行指南。PRD真正的价值在于，它是编码的起点。

① PRD完成后，初始化Claude Code会话。上下文窗口混入之前的对话会造成混乱。

② 在新会话中输入以下指令。

「读取这个文件夹里的PRD.md、schema.prisma和openapi.yaml。按照文档描述组建智能体团队来实现这个App。后端用Fastify，前端用React，数据库用PostgreSQL。」

③ 智能体团队以PRD为「唯一事实来源（Source of Truth）」开始工作。

四 AI生成的PRD不能直接用的原因

AI生成的PRD是起点，不是定稿。AI擅长搭建逻辑严密的结构，但无法完全理解商业语境中的微妙差异。韩国的托管支付法规、个人信息保护法的数据留存要求、目标用户年龄段对应的UX偏好，这些现实约束必须由人来审核。

审核顺序建议这样安排：产品负责人确认目标和范围；工程师评估技术可行性；安全负责人检查认证、加密和日志策略；运维负责人审视部署和监控体系。好的设计文档不是一次写完的东西，而是在反复审核中把每个决策记录清楚的东西。

五 非开发者也能做的事

写PRD不需要编程经验。用语言描述服务创意、回答AI的提问，这个过程靠的是商业判断力。在Cowork的桌面界面中同样可以完成整个流程，不习惯终端的读者建议从Cowork开始。

六 遇到问题怎么办

(1) PRD太笼统，感觉不贴合自己的项目。跳过澄清问题阶段直接要PRD就会出现这种情况。先让AI提问，具体回答之后再生成文档，质量会明显提升。

(2) 生成的数据库Schema缺少必要的表。像这样具体指定遗漏的部分就行：「请补充审计日志（Audit Log）、通知（Notification）、文件附件（Attachment）表。」

3 代码迁移与自动化测试

一 技术债务：看不见的欠账

技术债务（Technical Debt）是陈旧代码日积月累堆出来的隐性成本。每次加新功能，意想不到的地方就会报错；新开发者加入团队，光是读懂代码就要花好几周；想打安全补丁，又陷入依赖关系的泥潭。所以企业会定期做代码迁移（Migration），把旧框架切换到新框架。

这是开发团队最不愿意碰的工作之一。因为不是在做新功能，而是在保持现有功能不变的前提下只改内部结构。用户看不到任何变化，投入的时间和成本却非常大。

二 Claude Code辅助迁移的方式

Claude Opus 4.6的100万token上下文窗口，可以一次性分析数十万行代码。以前的AI工具需要把代码切碎分批输入，容易遗漏文件间的依赖关系；现在可以在掌握全局结构的状态下制定转换计划。

迁移大致经过四个阶段。第一步，摸清现有代码的边界，把路由、中间件、认证、错误处理、数据库访问、外部API调用分离出来。第二步，用OpenAPI或JSON Schema锁定当前API的结构。第三步，按照新框架的架构重新组织代码。第四步，把旧版本和新版本并排运行，验证行为差异。

三 从Express迁移到Fastify

(1) 基础用法：生成迁移分析报告。① 将现有Express项目文件夹连接到Claude Code。② 输入以下指令。

「分析整个项目。找出所有使用Express的app.get、app.post模式的路由，映射中间件链，整理数据库查询的执行位置。不要修改代码，只做一份迁移分析报告，按1（低）到5（高）评估迁移到Fastify时的风险等级。」

③ Claude扫描项目后，生成一份包含全部文件交叉引用关系和风险要素的分析报告。

(2) 进阶用法：分步执行迁移

① 审核完分析报告后，从风险等级最低的模块开始迁移。

「先把风险等级1到2的路由转换成Fastify格式。将Express的req、res对象替换为Fastify的request、reply对象，并为每个路由添加基于JSON Schema的请求校验。」

② Claude对这些文件进行转换。这不是机械式的替换，而是反映了Express中间件模式与Fastify插件模式之间的结构性差异。

(3) 实战应用：自动生成测试并验证

迁移代码固然重要，确认迁移后的代码能否正常运行同样关键。

① 按如下方式下达指令。②「请为每个转换后的Fastify路由生成单元测试。涵盖正常请求、错误参数、认证失败、资源不存在、服务器错误等场景。使用Fastify的inject方式，不开启网络端口即可完成测试。」

② Claude为每个端点生成测试代码。

③ 运行生成的测试，确认是否全部通过。「请把刚才创建的测试全部跑一遍。」

④ Claude执行测试，如果有失败项，会分析原因并修改代码。这个过程会反复进行，直到所有测试全部通过为止。

如果还需要E2E（端到端）测试，可以集成Playwright（浏览器自动化工具）。「请用Playwright编写一个E2E测试，模拟用户登录、搜索商品、加入购物车、完成结算的完整流程。」

四、AI生成测试的局限性

AI生成的测试会原样验证代码的当前行为。如果当前行为本身存在Bug，就可能生成把Bug当作正常行为的测试。所以AI生成的测试代码也需要人工审查。「这个测试验证的行为，是否确实是我们预期的行为」，这个确认过程无法自动化。

过去开发者留下的看似不合理的逻辑，实际上可能是为了绕过特定运行环境中的Bug而采取的权宜之计。AI不了解这些背后的历史，可能会直接把代码清理掉。在迁移过程中判断哪些东西必须保留，这是人的职责。

五、遇到这些问题怎么办

(1) 迁移过程中反复出现「Cannot find module」错误，，这说明依赖包与新框架不兼容。可以指示Claude：「请分析package.json中的依赖列表，找出与Fastify不兼容的包。」

(2) 测试全部通过，但实际服务仍然报错，，这意味着测试没有覆盖到某些场景。需要将生产环境中的真实数据模式、网络延迟等条件纳入测试。

4 UI/UX网页设计与Figma同步

一、设计师与开发者之间那道古老的鸿沟

设计师在Figma（基于网页的设计工具）中精心制作的设计稿，一旦由开发者用代码实现，总会产生微妙的偏差。间距差了4像素，字重用了Bold而不是Semi Bold，阴影的透明度也不一样。将设计稿交给开发者的过程叫做交付（Handoff），这个环节一直是产品开发中摩擦最大的节点之一。

AI正在减少这种交付摩擦。从三个方向切入。

二、什么是Figma MCP对接

MCP（Model Context Protocol）是AI与外部工具和数据进行通信的协议规范。Figma提供了MCP服务器之后，Claude Code就能直接读写Figma画布上的设计信息。2026年2月17日发布的「Code to Canvas」功能实现了双向同步。

Figma MCP服务器不只是看截图的像素。它能读取组件的层级结构、色值、字号、间距数值、Design Token（定义设计基本单位的数值）等结构化信息。

三、连接Figma与Claude Code并实际使用

(1) 基本使用：配置Figma MCP服务器

① 将Figma桌面应用更新到最新版本。

② 在Claude Code终端中输入以下命令。

claude mcp add --transport http figma https://mcp.figma.com/mcp

③ 在Claude Code中输入/mcp命令，确认Figma服务器是否已连接。

④ 当Figma请求授权时，点击「Allow Access」。

(2) 应用案例：将Figma设计转换为代码

① 在Figma中选择想要转换的Frame（画面单元）。

② 将Figma链接粘贴到Claude Code中，按如下方式指示。

「请分析这个Figma设计，转换为React组件。使用Tailwind CSS，应用响应式断点。设计中定义的色值和字号请原样保留。」

③ Claude通过Figma MCP读取设计的结构化信息，生成React组件代码。

④ 在本地服务器上运行生成的代码，与设计稿进行对比。

(3) 实战应用：从代码反向传输到Figma

这个功能是实现双向同步的核心。开发者用代码构建的UI可以发送到Figma画布上，设计师收到的是可编辑的Frame。

① 在Claude Code中启动本地服务器后，按如下方式指示。

「请启动我的应用本地服务器，截取当前画面并发送到一个新的Figma文件中。」

② Claude会打开浏览器窗口并显示截取工具栏。可以截取整个页面、特定元素，或连续截取多个画面。

③ 截取完成后，Claude会提供Figma文件链接。打开这个链接，截取的画面已经转换为可编辑的Figma Frame。

④ 设计师在Figma中修改颜色或间距后，Claude Code能检测到这些变更并反映到代码中。「请检查Figma中这个Frame的变更内容，只将变更的部分同步到代码中。」

四、需要了解的限制条件

Figma MCP服务器的部分功能仅在特定条件下可用。Code to Canvas功能目前仅支持Claude Code、OpenAI Codex和VS Code。Figma套餐也需要Dev或Full席位，以及Organization或Enterprise方案。API调用存在速率限制（Rate Limit），大量Frame同时转换时速度可能变慢。

AI生成的UI代码在视觉精确度上正在提高，但无法自动满足无障碍（Accessibility）标准。屏幕阅读器（Screen Reader，视障人士使用的屏幕朗读程序）兼容性、键盘导航、色彩对比度等细节需要人工验证。拖放、无限滚动、复杂表单校验等交互逻辑，AI生成的代码质量参差不齐。

设计的外观，AI可以快速生成。但用户指尖感受到的响应速度、滚动时画面出现的节奏、错误提示传达的语气，这些依然是需要人来打磨的领域。

五、实际导入分三步走

想一口气把所有功能都接上，团队会被拖垮。第一步，先熟悉将设计稿转换为代码的基本流程。第二步，接入Figma MCP，把设计上下文（配色、间距、组件层级）喂给AI。第三步，配置Code Connect（一种将Figma设计组件与代码仓库中

实际组件关联起来的工具），让AI不再凭空发明新组件，而是直接调用团队已有的组件。按部就班地往上走，反而是最快的路。

六、遇到这些问题怎么办

(1) 连接了Figma MCP服务器，却看不到generate_figma_design工具。如果之前连接过的Figma MCP实例还残留着，就会产生冲突。先断开旧连接，重启Claude Code，再重新连接。通过Figma插件安装的方式更稳定。

claude plugin install figma@claude-plugins-official

(2) 从Figma转换出来的代码跟原稿差别很大。光看截图去猜，和通过MCP读取结构信息，结果天差地别。用/mcp命令确认MCP是否正常连接，并在提示词中写明「请从Figma MCP获取设计上下文后再做转换」。

(3) Code to Canvas功能无法使用。该功能仅通过远程MCP服务器(https://mcp.figma.com/mcp)提供支持。如果只连接了本地MCP服务器（桌面应用的Dev Mode MCP Server），从代码推送到Figma的功能就不会生效。需要额外连接远程服务器。

本章讨论的四个领域各自独立，但在实际项目中，它们串成一条完整的流程。

用PRD定义需求，Agent团队实现代码，自动测试验证质量，Figma同步缩小设计与代码之间的差距。AI写代码的速度比人快。可是决定该做什么、判断做出来的东西是否契合业务场景，这件事仍然属于坐在屏幕前的人。在机器搭好的骨架上，叠加我们团队独有的判断和经验，这才是正确使用这些工具的方式。