很多人问过我同一个问题：一个人做项目，代码量摆在那里，时间又只有那么多，到底怎么扛下来？我的回答一直没变——我一个人，但身后有一队AI。这队AI的核心指挥中枢，就是Claude Code。过去大半年，我把Claude Code从一个"能写代码的聊天工具"调教成了真正的工作区：里面有负责架构的、写代码的、测试的、查文档的，甚至还有专门处理重复性脏活的。这篇文章不聊概念，就聊我实际怎么搭、怎么用、踩过哪些坑，以及一个关键问题：让一队AI替你干活之前，你自己得先想清楚什么。
这篇文章适合谁？如果你用过Claude、Cursor这类AI编程工具，但觉得"单个问答"的效率不够高；如果你是个独立开发者、小团队技术负责人，手里同时压着好几个任务；如果你试过让AI写代码，但总觉得它"干一步停一步"，需要你不断喂指令——那么这篇内容应该能给你一张完整的地图。我会从架构设计、环境搭建、协作机制、完整工作流、踩坑记录五个维度，把我当前的工作区全貌拆开给你看。
1. 为什么要让一队AI替我干活：单人作战的协作困境
先说痛点。独立开发或者小团队里，最贵的资源从来不是服务器，是你的注意力。我同时维护的工具链包括几个开源项目、一个内部平台、一堆一次性脚本，外加日常的代码审查和文档输出。以前的做法是：先写代码，再切出去查资料，再切回来改Bug，再被IM消息打断去处理另一个项目。一天下来，真正深度工作的时间可能不到三小时。你缺的不是能力，是切换上下文时消耗掉的那部分精力。
Claude Code改变我的方式，在于它把"AI写代码"从对话式变成了任务式。普通的ChatGPT用法是"你问我答"：我给你一段需求，你给我一段代码，中间全靠我来补充细节、指出问题、再把代码粘贴到项目里。这对小片段没问题，但项目一复杂，这种模式的上下文连续性就断了——AI不记得项目结构，不记得你之前定过的变量命名规范，更不记得三天前它自己写过一个模块的接口约定。Claude Code是跑在终端里的智能体，它直接读你的文件系统、执行终端命令、运行测试、追踪跨文件的修改。这意味着它工作的位置就是你的项目本身，信息不会丢。
真正让我下决心搭"一队AI"的契机，是我接手一个需要同时推进的排期：一个功能重构、一个线上Bug排查、一个依赖升级。三件事性质完全不同，放在一个会话里做会互相干扰，放在三个项目里手动来回切又让人崩溃。当时我试了一个很笨的方案：开三个终端窗口，每个窗口单独跑一个Claude Code实例，分别处理三个项目。结果意外地好用。每个实例独立维持自己的上下文，我在边上当"项目经理"，只负责拆解任务、检查产出、在关键节点上拍板。从那天起，我开始认真思考怎么把这套"一人多AI"的模式系统化，也就是现在这个工作区的雏形。
这个转变背后有一个认知：AI智能体不应该被当作"加强版搜索引擎"或者"代码补全插件"，它更像一个能理解项目上下文、能执行操作的实习生。既然是实习生，你就得有分工、有培训、有检查机制。你不可能指望一个实习生同时做架构设计、写核心逻辑、跑测试还写文档——不是他不行，是任务类型切换会损耗效率。所以我的工作区设计原则很简单：把不同类型的工作拆给不同的AI角色，用一套统一的机制管理它们，让每个角色专注在自己的领域里，我负责所有需要判断力的部分。
2. 工作区架构设计：我的AI团队成员与它们的分工
先给你看一张我当前工作区的"团队架构表"，然后逐个拆解为什么这么分工。
| 角色 | 承载方式 | 核心职责 | 使用频次 | 典型任务示例 |
|---|---|---|---|---|
| 架构师 | Claude Code + 独立项目目录 | 需求拆解、方案设计、技术选型 | 每次新任务开始 | 把模糊需求变成可执行步骤 |
| 主力开发 | Claude Code + 主开发分支 | 编码实现、重构、集成 | 高频 | 实现新功能模块、修复技术债 |
| 测试专员 | Claude Code + 测试目录 | 写测试、跑测试、补用例 | 每周固定 | 为功能补齐单元测试 |
| 文档助手 | Claude Code + docs目录 | README、接口文档、CHANGELOG | 低频但固定 | 生成项目使用说明 |
| 代码审查员 | Claude Code + 独立审查会话 | PR审查、静态检查、质量兜底 | 每次合入前 | 检查是否需要拆分PR |
| 脏活机器人 | Shell脚本 + Claude Code | 批量改名、依赖升级、模板生成 | 随机 | 批量替换废弃API |
这张表不是一开始就有的，是踩了不少坑之后演化出来的。最开始我只是一个Claude Code实例跑所有任务，结果是上下文里既有架构讨论又有具体实现还有测试报告，塞得太多之后，它开始"忘记"前面定过的约束。后来我学到一课：给AI分工的本质，是在物理上隔离不同任务的上下文，避免互相污染。
先解释架构师角色。架构师通常跑在一个干净的项目副本或者独立目录里，我会把需求写成一个.md文件丢给它，它负责输出技术方案、任务拆解清单、风险点。这个角色不需要写业务代码，所以它的上下文中不需要有具体的源码细节，只需要项目整体结构和约束条件。隔离的好处是，方案讨论不会被实现过程中的"这个函数参数不对"这种琐碎问题打断。
主力开发和测试专员的隔离，是实践中最受益的一个设计。以前让同一个会话既写代码又写测试，AI常常陷入"自己写代码、自己给代码擦屁股"的循环里——它写的测试永远适配它写的实现，等于既当运动员又当裁判。现在我把开发任务和测试任务拆到两个独立会话，测试专员看到的接口文档是主力开发产出的，它按文档写测试，反而更容易暴露实现和文档不一致的地方。
代码审查员这个角色比较特殊。它不是每次都用，而是在准备合入代码前开启一个全新会话，让它在不带着"这是我写的代码"的偏见下，从干净的角度审查diff。这个做法参考了人类团队里"审查者不应是作者"的原则，实测效果非常好——AI在审查自己刚写的代码时，往往会自我辩护；换成全新上下文之后，它指出问题要直接得多。
脏活机器人则是把重复劳动脚本化的产物。比如某个依赖库升级后API全变了，需要批量改调用点，我会先让Claude Code分析变更范围，生成一个改动脚本，然后人工review脚本逻辑，再执行。这类任务的价值不在于AI写得有多聪明，而在于它能把"机械劳动+防漏检查"一次做完，省下的时间非常可观。
3. 从零搭建工作区：安装、配置与IDE集成的完整链路
命令装好只是第一步，真正的工作区配置才是关键。我把完整链路拆成几段，每段都标注了为什么这么做。
3.1 安装入口与验证
Claude Code的安装有两条主流路径：一是通过npm全局安装，适合已经使用Node.js生态的开发者；二是使用官方安装脚本，适合想省事的用户，它会自动检测系统环境并安装到默认路径。
# 路径一：npm全局安装 npm install -g @anthropic-ai/claude-code # 路径二：官方安装脚本 curl -fsSL https://claude.ai/install.sh | bash安装之后，在终端里输入claude就能启动交互界面。但真正进入工作区之前，你还需要认证。官方支持两种方式：一种是用Claude账号登录，另一种是设置ANTHROPIC_API_KEY环境变量。我个人推荐API Key路线，因为它在命令行和CI/CD环境里更稳定，不会因为浏览器会话过期而失效。
# 设置API Key（建议写进shell配置文件） export ANTHROPIC_API_KEY="你的API密钥"验证是否装好有个很实用的方法：进入一个项目目录，运行claude，然后输入一句"请查看当前目录结构并总结这个项目做什么"。如果它能正确列出文件并概括项目，说明终端权限和文件读取都正常。这一步能排查80%的初装问题。
3.2 CLAUDE.md项目记忆：工作区的天花板
Claude Code有个核心机制我强调过很多次：CLAUDE.md文件，这是项目根目录下专门给AI读的"团队手册"。它决定了AI对你的项目了解有多深，直接决定了你的工作区是"一个聪明的工具"还是"一个懂你的队友"。
首次进入项目时，输入/init命令，Claude Code会自动扫描项目结构并生成一份初始的CLAUDE.md。但自动生成的永远只是骨架，真正有价值的项目记忆需要手写。我当前的CLAUDE.md包含这几个部分：
# 项目概览 - 项目定位与目标用户 - 技术栈清单及版本约束 # 架构约束 - 目录结构说明：src/service/scripts放什么 - 关键模块间的数据流约定，禁止绕过xx层直接操作DB # 编码规范 - Python代码遵循PEP8，类型注解必须完整 - 错误处理必须显式，不允许裸except # 常用命令 - 测试：python -m pytest tests/ - 启动：uvicorn app.main:app --reload # 禁止事项 - 不自动安装依赖，需询问 - 不修改migrations目录下的历史文件有了这份手册，AI在每次会话开始时都会自动读取，等于新实习生入职第一天拿到了一本完整的项目规章制度。很多人觉得Claude Code写代码不够精准，80%的情况其实是项目记忆没建好，AI在靠猜。
3.3 VS Code集成与桌面版选择
终端场景够强，但大部分人的日常还是在IDE里。Claude Code的VS Code扩展支持直接在编辑器里打开会话面板，能读取当前打开的文件作为上下文，方便你在代码和对话之间来回切换。我的经验是：纯终端适合"AI自主执行"的批量任务，VS Code集成适合"你主导、AI辅助"的交互式开发。
安装扩展之后，配置两个关键点。一是把Claude Code设为默认的Code Actions执行引擎，这样遇到"帮我重构这个函数"这类操作可以直接交给它。二是打开扩展设置里的文件自动读取，让AI能看到当前编辑中的文件，减少"你先把文件发给我"之类的来回。
桌面版则是把工作流从"每个项目一个终端窗口"升级成"一个应用管理所有项目会话"。它的好处是会话历史更直观，可以同时挂多个项目的后台任务。我目前的习惯是：桌面版开架构师和主力开发的会话，终端窗口跑测试和脏活机器人，各司其职。
3.4 接入第三方API与本地模型：cc-switch的正确用法
工作区要真正"一个带一队"，不能只依赖单一模型供应商。尤其在实际项目中，我经常需要用不同模型对比产出质量，或者在不方便使用云端服务时切换到本地模型。这里有一个实用工具：cc-switch，它专门用来管理Claude Code的API接入配置。
# 安装cc-switch npm install -g cc-switch # 查看当前配置 cc-switch list # 添加一个使用第三方的配置（以DeepSeek为例） cc-switch add # 按提示填写名称、api地址、api keycc-switch的核心原理是改写Claude Code的环境变量配置，把默认的API端点切换到兼容Anthropic协议的其他服务。我用它接过的模型包括DeepSeek、Qwen、GLM等，切换只需要一行命令，不需要动项目里的任何代码。这个工具在实际工作中的价值在于：本地上线前用低成本模型跑批量任务（比如代码格式化评审），核心逻辑切换回能力更强的模型，整体成本能压到纯旗舰模型方案的三分之一。
本地模型的路线也不复杂。LM Studio启动后会提供一个本地API服务，这时需要设置两个环境变量指向它：
export ANTHROPIC_BASE_URL="http://localhost:1234" export ANTHROPIC_AUTH_TOKEN="local-model-token"需要注意，本地模型的能力上限和云端旗舰模型有差距，Claude Code在规划复杂任务时可能做出一个"看起来合理但实际错误"的方案。所以本地模型路线我只用来做单点任务，比如解释某段代码、生成测试数据，真正的架构设计和重构仍然走云端。这里面的权衡，后面会详细展开。
4. 让AI团队真正跑起来：任务分发、上下文管理与权限边界
工作区的环境和角色都建好了，接下来的问题是：怎么让这个团队高效地协作，而不是各个成员各干各的、产出互相矛盾？这就要解决三个核心问题：任务怎么分发、上下文怎么管理、权限怎么设。
4.1 任务分发：从"你直接做"到"先给我方案"
我踩过最深的坑，是习惯性对Claude Code说"你把这个功能实现一下"。这句话听起来没问题，但对AI来说太模糊了——它不知道功能边界在哪里、和现有代码的衔接点是什么、验收标准是什么。结果就是它想当然地写了一个"应该能用"的版本，然后我需要在一大堆代码里挑毛病，花费的时间比自己写还长。
现在我要求自己遵循一条规则：任何任务交代给AI之前，至少要包含背景、边界、验收标准三个要素。背景让AI理解为什么做这件事，边界告诉它不要碰哪些代码，验收标准让它在结束时能自检。基于这个原则，我设计了一个简单的任务分发格式，直接作为提示词模板使用：
任务：给用户列表页增加按标签筛选功能 背景：用户反馈列表太长难以定位，产品决定在侧边栏增加标签筛选器 边界： - 只允许修改 app/views/user_list.py 和对应模板 - 不动数据模型，不动现有查询逻辑 - 标签数据已有的接口直接复用 验收标准： 1. 勾选标签后列表刷新并只显示带该标签的用户 2. 取消勾选恢复全量列表 3. 当前分页参数需保留 4. 所有现有测试通过把这段模板贴在会话里，Claude Code的执行质量会上升一个量级。原因在于：它不需要猜测你的意图，全部的精力都花在执行上，而不是在"理解需求"上反复试探。我把这个模板写进了CLAUDE.md里，并让它作为所有任务执行的默认格式。
4.2 上下文管理：别让AI患上"记忆混乱"
上下文是智能体最宝贵的资源，也是最容易失控的资源。Claude Code的上下文窗口虽然大，但塞的东西一多，它会开始忽略早期信息、做出矛盾决策。我的工作区会定期执行三步清理：
第一步，任务结束后主动/clear清空会话，不让上一个任务的残留影响下一个任务。第二步，如果会话太长，用/compact让AI把当前的重要信息压缩成摘要，再继续执行。第三步，把需要长期记住的内容写进CLAUDE.md或CLAUDE记忆文件中，而不是依赖会话里的对话历史。
一个关键认知是：AI的"记忆"不应该靠对话里说一次来保证，而应该靠项目文件来固化。凡是希望AI长期遵守的规则，只放在对话里是不够的，因为下一轮新会话它就忘了。正确的做法是写进项目文档，让每次新会话自动读取。这就是为什么我的工作区里"文档即记忆"——CLAUDE.md和docs目录下的架构决策记录，比任何聊天记录都可靠。
4.3 权限边界：从全自动批准的教训说起
Claude Code的优势在于能直接执行终端命令和修改文件，但这也是最大的风险点。我的工作区曾经出过一次事故：某次我开启了全自动批准模式，让AI自主执行一个"清理无用代码"的任务。结果它把几个其实还在引用的工具函数判断成了无用代码直接删除，等测试跑挂了才发现。那次事故之后，我把权限体系重新梳理了一版。
现在的配置分三档：
- Plan模式：只读，允许AI阅读代码、分析问题、给出方案，但不允许修改任何文件。用于架构设计和代码审查。
- 默认模式：允许修改文件和执行常见命令，但关键操作（安装依赖、删除文件、修改锁文件）需要我手动确认。
- 高危白名单：只有我明确授权的命令（比如
python -m pytest tests/）才允许自动执行，其他一律询问。
这套权限分级，本质上模拟的是一个真实团队里"实习生能做什么、要请示什么"的规则。执行终端命令是Claude Code的重要能力——它能跑测试、抓日志、做静态检查——但权限配置上，我宁愿多几次确认，也不愿意再经历一次"自作主张删文件"的灾难。
4.4 多任务并行：一个项目多会话的调度经验
回到开头说的场景：同时推进多个任务时，我采用"一个任务一个会话、多个会话并行"的调度方式。具体操作是，在同一个项目目录下开多个终端窗口，分别启动Claude Code实例，每个实例只聚焦一个任务。
并行调度有一个前提条件：任务之间不能有文件级别的冲突。如果两个会话同时在改同一个文件，后写入的会覆盖先写入的，产生隐藏的丢失更新问题。所以我排任务时会给每个会话指定明确的文件范围，并约定在完成前做一次git status检查，确认没有动到不属于它的文件。听起来复杂，实际操作起来只要在分派任务时多写一句"你只允许修改app/controllers/目录"，冲突概率就会大幅下降。
5. 一场完整的AI团队工作流：从需求到合入的全过程实录
理论说了不少，我拿一次真实的迭代来演示整个工作区的运转过程。这是一个内部工具的新功能：给报表模块增加"定时导出"能力，需要支持配置导出时间、格式和推送渠道。
5.1 第一步：架构师角色产出方案
我没有直接让AI写代码。而是先在桌面版开一个架构会话，丢给它需求文档和一段命令："请阅读需求，参照现有报表模块的代码结构，产出一个可以实现定时导出的技术方案。方案里必须包含：改动的文件清单、新增依赖、数据流、风险点。"
架构师角色跑完，输出了三页方案。核心判断是：现有项目已经有定时任务的基础设施（APScheduler），不需要额外引入Celery；导出逻辑可以复用已有的报表生成函数，只需要包一层异步任务；推送渠道先只做邮件和Webhook。它还指出一个风险点：现有报表生成函数在数据量大时会超时，建议在方案里加入数据分片。这个判断很关键，如果不是一开始就检查，后面实现完才发现，修改成本就大了。
我review这个方案时主要看几点：技术选型是否符合项目现状而非"为了用新技术而用"、改动范围是否和需求匹配、风险点是否被充分暴露。确认无误后，把方案存为一个 .md 文件，作为后续开发会话的输入。
5.2 第二步：主力开发实现功能
拿到方案，我开启新的会话，把方案文件和任务模板一起作为上下文。
请按方案 docs/export_plan.md 实现定时导出功能。 关键点： - 严格按方案中的文件清单一个一个改 - 先写核心的异步任务函数，再写配置界面 - 每改完一个文件，运行一次对应的测试 - 不要修改方案清单之外的文件这次执行相对顺利。AI按文件清单逐个修改，每完成一个模块会运行一次相关测试，过程中主动发现了一个问题：方案里提到的Webhook推送地址需要做格式校验，但项目现有的校验工具没有覆盖URL格式，它自己补了一个。这个行为很典型——当项目记忆和任务背景足够清晰时，AI会开始"主动发现边界问题"，而不是机械照做。
5.3 第三步：测试专员独立验证
开发会话提交的代码我没有马上验看，而是开启第三个会话：测试专员。上下文是开发会话产出的改动说明 + 测试模板。
请为本次定时导出的改动编写完整的单元测试。 覆盖范围： - 定时任务注册是否正确 - 导出格式参数传递 - Webhook推送的成功和失败分支 - 分片导出的数据正确性 写完测试后运行全量测试，报告任何失败。测试专员跑完后提交了报告：新增测试16个，其中有2个失败。失败的原因指向一个async函数没有被正确await。我拿到报告后切回开发会话，把失败信息丢给它，它很快定位到问题并修复。这个"开发—测试—反馈—修复"的闭环在一个小时内完成，放在以前手动操作，至少需要半天。
5.4 第四步：代码审查员做合入前检查
功能测试通过之后，进入合入前的审查环节。我开启一个全新会话，不提供任何开发背景，只给一个命令："请审查当前工作区未合入的改动，重点关注：逻辑正确性、边界情况、安全风险和代码风格。请给出必须修复的问题清单和可以优化的建议清单。"
这个角色分离的设计我很坚持。当AI没有"这些代码是我写的"这个包袱时，它的审查会犀利很多。这次审查列出了三个必须修复项：一个在极端输入下可能产生的除零错误、一个日志中可能泄露内部路径的隐患、一个和现有代码风格不一致的命名。我确认后把清单转给开发会话修复，然后重新跑全量测试，通过后合入。
整个流程走下来，我的实际参与时间大约两小时，包括方案review、中间检查、修复确认。剩下的代码实现、测试编写、问题修复这些耗时环节，全都由AI团队并行消化了。这就是"一个人带一队AI"的效率模型：你花在判断上的时间无法省，但花在执行上的时间可以大幅压缩。
6. 工作区里的故障与排障：那些AI团队让我抓狂的时刻
任何工具都不可能一直顺滑。这里把我过去几个月遇到的典型故障和排查思路整理出来，它们比成功经验更值得参考。
6.1 上下文"污染"导致的连锁错误
有一次主力开发会话执行一个重构任务，改到一半突然开始改动和任务无关的一个配置文件。我打断它询问原因，它回复说"因为前面的讨论中提到过这个文件需要优化"。这句回复暴露了一个关键问题：任务目标在长会话中被逐渐扭曲，AI在执行中"自作主张"扩大了范围。排查下来，原因是早期讨论中提到过一个相关文件，这个信息虽然过期，但仍在上下文里占据位置，影响了决策。
解决方法是梳理上下文管理纪律：每个会话只保留和当前任务相关的信息，任务中要做"只修改清单内文件"这样明确的约束；遇到跨会话的关联需求，不是靠"记住"，而是写成新任务重新分发。这个故障推动我给所有会话模板加了一条固定命令："在任务开始时先列出你识别到的任务边界，并在执行中遵守。"
6.2 第三方API兼容性引发的疑难杂症
接入第三方模型时，我遇到过一类隐蔽的问题：代码表面上执行正常，但某些工具调用（比如读文件后的权限确认、长上下文的请求分片）行为异常。排查到最后，定位是第三方API对Anthropic协议某些扩展字段的支持不完整，导致Claude Code依赖的部分功能退化了。
这个问题的排查链路值得记录一下：先在cc-switch里切换回官方API端点，发现同样的任务正常，判断问题出在模型服务而非工作区配置；再对比两种模式下Claude Code的日志输出，锁定是工具调用阶段的请求格式差异；最后选择在跑"需要复杂工具链的任务"时始终使用官方API端点，第三方模型只用于单轮问答和代码片段生成。结论很简单：第三方API可以省钱，但不能省在复杂任务上。
6.3 本地模型的能力错觉
用LM Studio接本地模型时，我踩过一个典型的"能力错觉"坑。本地模型在处理定义清晰的小任务时表现尚可，但当我让它规划一个涉及多文件重构的任务时，它给了一个逻辑上完整但实际无法落地的方案，甚至在方案里发明了一个不存在的API。系统给的报错信息也直指源，"claude code might not be available"这类提示多半和配置环境有关。
排查经历加深了一个教训：本地模型适合"执行者"角色，不适合"规划者"角色。架构师和主力开发的工作区，我始终使用云端模型；本地模型的定位被锁死在脏活机器人这个角色里——批量格式化、生成测试数据、简单代码解释。认清模型的边界，比追求"全部本地化"重要得多。
6.4 权限放太宽的代价
上文提到过全自动批准的教训，这里补充排查过程。事故表现是：AI在"清理无用代码"时删除了三个仍在使用的工具函数，全量测试跑挂。定位后复盘发现，问题不在AI的判断力，而在权限设置——我在那次任务前把文件删除操作加入了自动批准白名单。
排查路径本身不复杂，但教训很深刻：权限配置的本质是风险管理，不是效率优化。全自动模式省掉的每次确认时间，抵不上一次误删带来的回滚成本。现在我维护的红线是：删除类操作、依赖安装、锁文件修改、生产环境命令，永远不进白名单。效率上的损失可以接受，安全上的风险不行。
6.5 错误提示与版本升级的应对
还有一类频发问题是版本升级带来的行为变化。Claude Code迭代速度很快，某次升级后，我日常使用的一个命令格式变了，导致自动化脚本失灵。排查时发现官方文档已经更新，而我的脚本还在用旧参数。
这类问题的应对方法是：每次升级后主动查看更新日志，而不是等脚本报错再去查。自动化的脚本和模板要尽量少依赖"当前版本有效"的细节，多用稳定的、长期不变的接口。此外，把常用模板（任务分发模板、角色prompt、CLAUDE.md）放在独立文件中管理，版本升级后如果某个行为变了，只需要改模板文件，不需要逐个会话去调。
7. 我的最终体会：工作区的未来形态
如果把"一队AI"的工作区比作真实团队，Claude Code是执行层，而我是决策层。它能高效处理"怎么写""怎么测""怎么改"，但"做什么""为什么做""边界在哪"这些核心判断，目前仍然需要人来完成。
个人经验里最想强调的一点是：不要一开始就追求全自动。我见过很多朋友把权限开到最大、把多个AI串成复杂流水线，结果机器错误地在几秒内跑偏，浪费的时间远超手动作业。我自己的路径是：先让AI做单点任务，用顺了再扩展到一个角色的完整职责，最后才尝试多角色协作。整个过程中，CLAUDE.md和任务模板是投入产出比最高的东西——它们花的时间不多，但每优化一次，整个工作区都会受益。
如果你打算照这套思路搭自己的AI团队，我最后再给你两个具体的起步建议。第一，从"给现有项目补CLAUDE.md"开始，哪怕只有一页，你会发现之后的每次AI交互质量都明显上升。第二，选一个小型但完整的任务，比如"给某个模块补充单元测试"，走完"分派—执行—检查"这个闭环，积累一次真实的协作经验。等这两步走顺了，你自然知道下一步该往哪个角色扩展。
一队AI围着我转的日子听起来很科幻，实际上手之后会发现，它并没有替代判断和思考，只是把我从重复劳动里捞了出来。这大概就是一个人带一队AI最好的状态：我负责方向，它们负责跑量，我们一起把东西做出来。
