1. 项目概述：一个为AI编码助手设计的“任务执行引擎”

如果你和我一样，每天都在和Claude Code、Cursor这类AI编程助手打交道，那你肯定遇到过这样的场景：你想让AI帮你开发一个包含多个文件、涉及前后端联调的新功能。你描述了半天需求，AI助手也给出了看似不错的代码片段。但当你让它继续完善时，问题就来了——它可能忘了之前的设计思路，或者在不同的文件里写出了逻辑冲突的代码，甚至把整个项目的架构带偏。最后，你不得不花大量时间手动检查和修正，感觉AI助手更像是一个需要你时刻监督的“实习生”，而不是一个能独立完成复杂任务的“资深工程师”。

这正是我最初遇到的痛点。作为一个常年在一线开发的老兵，我深知一个复杂的开发任务（比如新增一个用户认证模块）远不止是写几行代码那么简单。它需要清晰的规划、分阶段的执行、实时的验证，以及在遇到错误时能自我反思和调整的能力。现有的AI助手在单文件、单次对话的简单任务上表现惊艳，但一旦任务变得复杂、需要跨多个文件协作、并且耗时较长时，它们就容易“失忆”和“跑偏”。

于是，我动手打造了 Mission Runner 。它的核心目标不是替代AI助手，而是为它们装上一个“任务执行引擎”和“外部记忆体”。简单来说，它是一套方法论（PIR：规划-迭代-解决）和一套工具（基于文件系统的状态管理），让AI助手能够像人类工程师一样，有条不紊地处理复杂的多文件开发任务。它把任务拆解成计划，把执行过程记录在案，把错误当作学习数据，从而实现真正意义上的“自动化多文件开发”。

这个项目特别适合那些需要 构建新模块、进行大规模重构、或实现跨系统功能 的开发者。如果你厌倦了在AI对话中反复解释上下文，或者希望AI能更可靠地处理超过其单次上下文窗口的复杂工作流，那么Mission Runner就是你一直在找的解决方案。

2. 核心设计哲学：为什么是PIR与文件系统记忆？

在深入代码之前，我们必须先理解Mission Runner背后的设计哲学。这决定了它为什么有效，以及如何正确使用它。其核心可以概括为两点： PIR方法论 和 文件系统即记忆 。

2.1 PIR方法论：规划、迭代、解决的循环

传统的AI编码交互往往是线性的：用户提出请求 -> AI生成代码 -> 用户反馈 -> AI修改。这种方式对于复杂任务效率低下，因为缺乏全局观和持续的方向校准。

Mission Runner引入了 PIR（Plan-Iterate-Resolve） 方法论，这是一个受软件工程和智能体研究启发的闭环工作流：

  1. 规划（Plan） ：在动手写第一行代码之前，强制进行任务分解。这不仅仅是把大任务拆成小任务，更重要的是为每个子任务定义清晰的 成功标准 。比如，“实现用户登录API”的成功标准可能是：“POST /api/login 接口能接收JSON格式的邮箱和密码，验证成功后返回JWT令牌和用户基本信息，并在数据库中记录登录日志。” 有了这个标准，AI（和未来的你）才能明确知道“完成”意味着什么。

  2. 迭代（Iterate） ：严格遵循“一次只做一件事”的原则。每个迭代周期只完成计划中的一个任务。这避免了AI同时思考多个问题导致的注意力分散和逻辑混乱。更重要的是，每个迭代都始于 “读后决策” —— 在执行前，必须重新读取整个任务计划。这就像飞行员在每次操作前都要核对检查单，有效防止了“目标漂移”，确保每一步都朝着最终目标前进。

  3. 解决（Resolve） ：这里指的是对执行结果的验证和问题解决。每个任务执行后，必须进行验证（编译、测试、代码检查）。如果验证失败，则触发 自我反思 机制，分析失败原因并学习，而不是简单地重试。所有错误都会被记录，成为后续迭代的“经验数据”。

实操心得 ：PIR的精髓在于“慢就是快”。初期多花10分钟做细致的规划，能节省后期数小时的调试和返工时间。我见过很多开发者（包括AI）一上来就埋头写代码，写到一半发现架构有问题，推倒重来，浪费了大量精力。强制性的规划阶段是避免这种浪费的关键。

2.2 文件系统即记忆：突破上下文窗口的局限

所有基于大语言模型的AI助手都有一个硬伤：有限的上下文窗口。Claude 200K的窗口已经很大，但对于一个持续数小时、修改几十个文件的大型任务，把所有历史对话和代码变更都塞进提示词是不现实的。AI会“忘记”早期的决策和细节。

Mission Runner的解决方案非常巧妙： 把本地文件系统当作AI的长期记忆体 。所有任务计划、执行笔记、进度状态，都以Markdown和JSON文件的形式保存在项目的 _planning/ 目录下。

_planning/
├── mission_plan.md       # 主计划文件：任务列表、成功标准、进度状态
├── mission_notes.md      # 执行笔记：发现的问题、做的决策、遇到的错误
└── workflow_state.json   # （可选）工作流状态机当前状态

这样做有三大好处：

  • 持久化 ：文件不会因为对话重启或上下文滚动而丢失。你可以随时中断任务，几天后回来，AI通过读取这些文件就能立刻恢复工作状态。
  • 可审查 ：所有AI的思考过程和决策依据都白纸黑字地记录了下来。这对于调试、理解AI的行为、甚至进行项目复盘都至关重要。
  • 可操作 ：这些文件本身就是结构化的数据，AI可以方便地解析、更新和查询它们，从而驱动整个工作流。

注意事项 ：务必确保你的AI助手（如Claude Code）有权限读取和写入项目目录。 _planning/ 目录应该被添加到 .gitignore 中，因为这些是过程性文件，通常不需要纳入版本控制。

3. 完整工作流拆解与实操指南

理解了核心思想后，我们来看一个完整的Mission Runner工作流是如何运行的。我将以一个具体的例子——“为现有博客系统添加评论审核后台功能”——来逐步演示。

3.1 阶段0：初始化与规划

一切始于一个清晰的指令。你不需要一次性给出所有细节，但需要明确核心目标。

给AI助手的指令示例： 

[MISSION RUNNER - PIR MODE]

## 任务
为我的博客系统（基于Node.js + Express + MongoDB）添加一个评论审核后台功能。需要包含后端API、管理前端页面以及相关的数据库模型更新。

## 阶段0：初始化
1. 创建 `_planning` 目录。
2. 创建 `mission_plan.md` 和 `mission_notes.md` 文件。
3. 将上述任务分解为多个阶段和具体的子任务，并为每个子任务定义明确的成功标准。

## 迭代规则
1.  读后决策：每次行动前，必须读取 `_planning/mission_plan.md`。
2.  执行：每次只执行下一个标记为 `[ ]` 的任务，完成后标记为 `[x]`。
3.  验证：每个任务执行后，进行必要的检查（如语法检查、运行测试）。
4.  检查点：更新进度日志。

## 完成标准
<promise>任务完成</promise>

AI收到指令后，会首先执行 阶段0 。它不会直接去写代码，而是会在你的项目根目录创建 _planning 文件夹，并生成两个核心文件。

生成的 mission_plan.md 示例： 

# 博客系统评论审核后台 - 任务计划

**最终目标**：实现一个完整的评论审核工作流，管理员可以查看、批准或驳回用户评论。

## 阶段1：数据库与后端模型
- [ ] **任务1.1**: 扩展 `Comment` 数据库模型（`models/Comment.js`）。
    - **成功标准**：模型新增 `status` 字段（可选值：`pending`, `approved`, `rejected`），`adminReviewedBy` 字段（ObjectId引用User），以及 `reviewedAt` 时间戳。
- [ ] **任务1.2**: 创建数据库迁移脚本或更新现有数据。
    - **成功标准**：所有现有评论的 `status` 被初始化为 `approved`。提供可运行的脚本 `scripts/init-comment-status.js`。
- [ ] **任务1.3**: 创建或更新 `Comment` 模型的Mongoose模式验证和索引。
    - **成功标准**：`status` 字段有默认值 `pending`。为 `status` 和 `createdAt` 字段添加复合索引以优化查询。

## 阶段2：后端API
- [ ] **任务2.1**: 创建管理员获取待审核评论的API端点 `GET /api/admin/comments/pending`。
    - **成功标准**：接口需要管理员权限（JWT验证），支持分页和排序，返回符合格式的评论列表。
- [ ] **任务2.2**: 创建审核评论的API端点 `PUT /api/admin/comments/:id/review`。
    - **成功标准**：接口接收 `{ action: 'approve' | 'reject' }`，更新评论状态，并记录审核人和时间。

## 阶段3：管理前端
- [ ] **任务3.1**: 在前端管理区域（`/admin`）创建评论审核页面组件 `AdminCommentReview.vue`。
    - **成功标准**：组件能调用后端API获取并展示待审核评论列表，包含评论内容、作者、时间等信息。
- [ ] **任务3.2**: 在列表中添加“批准”和“驳回”操作按钮。
    - **成功标准**：点击按钮能调用审核API，成功后从本地列表移除该条目，并给出成功提示。

## 进度日志
*   **YYYY-MM-DD HH:MM**: 阶段0完成。任务计划已创建。

生成的 mission_notes.md 初始时可能是空的，用于记录后续的发现和决策。

这个规划文件就是整个任务的“宪法”和“地图”。AI和开发者都以此为准。

3.2 核心迭代循环：执行、检查、反思

初始化完成后，AI会自动进入迭代循环，从第一个 [ ] 任务开始执行。

步骤1：读后决策 AI在每次行动前，会主动打开并读取 mission_plan.md 。这确保了它始终记得整体目标和自己当前的位置，避免做出与之前计划相悖的修改。

步骤1.5：信心检查（关键协议） 这是Mission Runner一个非常实用的安全机制。在执行每个具体任务前，AI会从四个维度给自己“打分”（1-5分）：

维度 对应问题 低分（<3）的可能原因
任务理解 需求是否完全清晰？ 成功标准描述模糊，存在歧义。
方案确定性 实现方法是否唯一且明确？ 有多种实现方式，不确定哪种最优或符合项目现有规范。
依赖清晰度 涉及的API、模块是否已识别？ 不清楚需要修改哪些现有文件，或不确定外部库的用法。
风险评估 副作用是否可控？ 本次修改可能影响其他看似无关的功能。

根据平均分决定下一步：

  • 平均分 ≥ 4 (绿色) ：直接执行。
  • 平均分 3-4 (黄色) ：在 mission_notes.md 中记录下顾虑点，然后继续执行。
  • 平均分 < 3 (红色) ：暂停，并向用户提问以澄清模糊点。

例如，在执行“任务2.1”前，AI可能会自检：“当前项目的权限验证中间件是 authMiddleware 还是 adminMiddleware ？我不确定。” 如果这个问题导致“依赖清晰度”维度打分很低，它就会向你提问，而不是盲目猜测导致错误。

步骤2：执行 AI开始编写代码。 关键原则是：一次只完成一个任务 。例如，它会在 models/Comment.js 中完成模型扩展后，立即提交更改，然后进入下一步。

步骤3：验证 代码写完后，AI不会立刻标记任务完成。它会运行相关的验证命令，例如：

  • npm run lint （代码风格检查）
  • node -c path/to/new/file.js （语法检查）
  • 如果有相关单元测试，会运行 npm test -- --grep “Comment model”

步骤3.5：自我反思（当验证失败时） 如果验证失败（比如ESLint报错或测试不通过），AI不会简单地重试。它会触发 Reflexion（反思） 机制，这是一个来自AI研究的概念。AI会分析错误日志，并在 mission_notes.md 中记录：

  1. 失败根因 ：是拼写错误？逻辑错误？还是对现有代码的理解有误？
  2. 修复方案 ：具体要修改哪一行代码，如何修改？
  3. 类比学习 ：这个错误是否揭示了项目中某种需要避免的通用模式？

例如，如果因为引入新的字段而忘了更新模型的 toJSON 方法导致序列化错误，AI会记录：“错误：返回给前端的评论数据缺少新字段。根因： CommentSchema.methods.toJSON 未包含 status 字段。修复：将其加入排除列表或显式包含。类比：未来修改模型时，需同步检查所有相关的方法（ toJSON , toObject ）。”

步骤4：检查点 验证通过后，AI才会在 mission_plan.md 中将当前任务标记为 [x] ，并在“进度日志”中追加一条记录。然后，它循环回到 步骤1 ，读取计划，执行下一个任务。

3.3 状态机：引导而非束缚

Mission Runner定义了一个建议性的状态机流程（初始化 -> 读后决策 -> 信心检查 -> 执行 -> 验证 -> 检查点）。这个状态机的主要作用是 提供一种最佳实践的工作流引导 ，而不是一个不可违背的硬性规则。

AI在特殊情况下可以“跳出”这个流程，但必须在 mission_notes.md 中说明原因。例如，在验证时发现一个前置任务存在设计缺陷，AI可能会决定先回到规划阶段修改 mission_plan.md ，然后再继续。这种灵活性保证了AI能应对复杂项目中出现的意外情况。

4. 在不同开发环境中的集成与配置

Mission Runner的核心是方法论，但它提供了与主流AI编码工具集成的“技能包”，让这套流程能无缝嵌入你的日常工作。

4.1 在Claude Code中使用

Claude Code通过 .claude/skills/ 目录来管理自定义技能。集成Mission Runner非常简单。

安装步骤：

  1. 克隆仓库到本地任意位置。 
    git clone https://github.com/sputnicyoji/Claude-Skill-MissionRunner.git
  2. 在你的 项目根目录 下，创建技能目录并复制文件。 
    # 确保在你的项目文件夹内执行
mkdir -p .claude/skills/mission-runner
cp /path/to/Claude-Skill-MissionRunner/SKILL.md .claude/skills/mission-runner/
cp -r /path/to/Claude-Skill-MissionRunner/references .claude/skills/mission-runner/

使用方式： 安装后，当你在这个项目中使用Claude Code时，它就“掌握”了Mission Runner技能。你只需要在对话中发出包含 [MISSION RUNNER - PIR MODE] 触发词的指令（如第3.1节所示），Claude Code就会自动启用这套工作流。

注意事项 ：Claude Code的技能是项目级别的。如果你需要在多个项目中使用，需要在每个项目中重复上述安装步骤。 SKILL.md 文件包含了完整的提示词和规则，引导Claude Code遵循PIR流程。

4.2 在Cursor编辑器中使用

Cursor通过规则文件（ .cursorrules 或 .cursor/rules/ 下的文件）来指导AI行为。Mission Runner提供了两种集成方式。

方式一：项目级规则（推荐） 将 .cursorrules 文件复制到你的项目根目录。这是最简单直接的方式，对整个项目生效。

cp /path/to/Claude-Skill-MissionRunner/.cursorrules /path/to/your/project/

方式二：模块化规则 如果你喜欢更精细的管理，或者项目已有其他规则，可以将规则文件放入特定目录。

mkdir -p /path/to/your/project/.cursor/rules
cp /path/to/Claude-Skill-MissionRunner/.cursor/rules/mission-runner.mdc /path/to/your/project/.cursor/rules/
# 或者使用精简版
cp /path/to/Claude-Skill-MissionRunner/.cursor/rules/mission-runner-lite.mdc /path/to/your/project/.cursor/rules/

mission-runner.mdc vs mission-runner-lite.mdc ：

  • 完整版 ：包含了详尽的理论说明、工作流步骤和示例，适合深度集成和复杂项目。
  • 精简版 ：只包含最核心的指令和触发词，体积小，加载快，适合快速启动或对规则文件大小敏感的项目。

使用方式： 规则文件配置好后，在Cursor的AI聊天框中，同样使用 [MISSION RUNNER - PIR MODE] 开头的指令即可触发。Cursor的AI（通常是Claude 3系列模型）会遵循规则文件中定义的复杂行为模式。

4.3 环境配置的常见问题与排查

问题1：AI助手没有反应，不创建 _planning 目录。

  • 排查 ：首先检查技能或规则文件是否放置在了正确路径。对于Claude Code，确保 .claude/skills/mission-runner/SKILL.md 文件存在。对于Cursor，检查 .cursorrules 文件是否在项目根目录，或 .cursor/rules/ 下的文件名称是否正确。
  • 解决 ：尝试重启你的编辑器或AI助手界面，有时需要重启才能加载新的规则。

问题2：AI创建了计划，但在后续迭代中似乎“忘记”了去读取。

  • 排查 ：检查AI在每次发言前，其输入提示词中是否包含了“读后决策”的指令。这通常取决于技能/规则文件编写的好坏。Mission Runner的官方文件已经内置了强制的重读逻辑。
  • 解决 ：在对话中手动提醒AI：“请遵循PIR流程，在下一步行动前，首先读取 _planning/mission_plan.md 中的当前进度。”

问题3：信心检查机制过于频繁地打断我，询问一些显而易见的问题。

  • 排查 ：这可能是因为任务的成功标准写得不够明确，或者AI对项目上下文理解不足。
  • 解决 ：1) 优化你的任务描述，使其更加精确、无歧义。2) 在项目根目录提供一个清晰的 README.md 或 ARCHITECTURE.md ，帮助AI快速理解项目结构和技术栈。3) 如果某个问题确实简单，你可以直接命令AI：“对于此任务，信心检查维度‘任务理解’和‘方案确定性’可评为5分，请继续执行。”

5. 高级技巧与最佳实践

经过在多个真实项目中的使用，我总结出一些能极大提升Mission Runner效率的心得和技巧。

5.1 如何编写一份“AI友好”的优秀任务计划

任务计划的质量直接决定了整个自动化过程的顺畅程度。一份好的计划应该是：

  • 原子化的 ：每个任务应该是不可再分的最小工作单元。例如，“创建用户模型”是一个任务，“为用户模型添加邮箱验证字段”是另一个任务。这降低了单个任务的复杂度，便于验证和回滚。
  • 可验证的 ：每个任务都必须有明确的、客观的成功标准。避免使用“完善”、“优化”这类模糊词汇。使用“实现X功能，并通过Y测试用例”、“修改Z文件，使其符合ESLint规则”这样的表述。
  • 有序的 ：任务顺序应符合依赖关系。数据库模型改动通常在前，API次之，前端最后。在计划中明确这种顺序。

反面例子 ：“重构用户模块，使其更清晰。”（过于模糊，无法验证） 正面例子 ：“将 userService.js 中的 createUser 和 updateUser 函数拆分为独立的文件 services/userCreation.js 和 services/userUpdate.js ，并更新所有引用它们的控制器。成功标准：1. 原有功能测试全部通过。2. 新文件符合项目的ESLint配置。”

5.2 利用 mission_notes.md 进行知识沉淀

不要小看这个笔记文件。它不仅是AI的草稿纸，更是项目的 决策日志 和 经验库 。

  • 记录技术决策 ：当AI在实现过程中选择了方案A而非方案B时，让它把原因记下来。例如：“选择使用 Date.now() 而非 new Date() 生成时间戳，因为前者性能略优且在本项目中无需时区转换。”
  • 记录发现的坑 ：比如：“发现项目中的 config 模块是同步加载的，因此在模型文件中引入它时需注意循环依赖问题。”
  • 记录待办事项 ：如果AI在实现过程中发现了一个与当前任务相关但不紧急的问题（比如一个可以优化的技术债），可以记录在笔记中，并加上 TODO 标签，供后续处理。

这些笔记对于后续的团队交接、项目维护和复盘具有不可估量的价值。

5.3 处理复杂错误与“自我反思”的实战

当遇到复杂错误时，Reflexion机制是解决问题的关键。我遇到过一个典型案例：AI在添加一个GraphQL查询时，一直报“类型未定义”的错误。

AI的反思记录如下： 

## 错误反思 [任务: 2.3 添加GraphQL查询]
*   **错误现象**: 运行 `npm run generate-graphql-types` 失败，报错 `Unknown type “FilterInput”`。
*   **根因分析**: 新创建的 `FilterInput` 类型定义在 `schemas/inputTypes.graphql` 中，但类型生成脚本 `codegen.yml` 中的 `schema` 路径只包含了 `schemas/*.graphql`，而 `inputTypes.graphql` 被放在了子目录 `schemas/inputs/` 下，未被扫描到。
*   **解决方案**: 修改 `codegen.yml`，将 `schema` 从 `schemas/*.graphql` 改为 `schemas/**/*.graphql` 以包含所有子目录。
*   **类比学习**: 本项目使用文件扫描来收集GraphQL模式。未来添加新的 `.graphql` 文件时，必须确认其所在目录是否在生成工具的扫描路径内。建议将此项检查加入后续相关任务的“成功标准”。

通过这次反思，AI不仅修复了当前错误，还将这个“坑”总结为一条经验，用于指导未来的任务。这体现了从“错误中学习”的智能。

5.4 与版本控制系统（Git）的协作

_planning 目录下的文件是 过程性文件 ，记录的是达成目标的路径，而非目标本身。因此，我强烈建议将它们加入 .gitignore ：

# .gitignore
_planning/

为什么？

  1. 避免噪音 ：这些文件变化频繁，每次任务执行都会更新，如果纳入版本控制，会污染提交历史。
  2. 个人/会话特定 ：不同开发者或同一开发者在不同时间执行同一任务，生成的计划细节和笔记可能不同。
  3. 可重建性 ：任务的核心产出（源代码文件）已经被Git管理。只要任务描述（最初的指令）是明确的，随时可以重新运行Mission Runner生成新的过程文件。

当然，如果你希望将某次特别成功的任务执行过程作为案例保存，可以手动将 _planning/ 目录复制出来，存档在项目文档中。

6. 适用边界与常见误区

没有任何工具是银弹，Mission Runner也不例外。明确它的适用边界，能让你把它用在刀刃上。

6.1 最适合的使用场景（重温与深化）

  • 绿地项目的新功能开发 ：从零开始构建一个包含多层级（数据层、服务层、API层、UI层）的完整功能模块。Mission Runner的规划能力能确保架构的清晰和一致。
  • 棕地项目的模块重构 ：对现有系统中一个相对独立的模块进行大规模重构或重写。PIR流程能帮助你理清依赖，步步为营，避免破坏现有功能。
  • 跨组件/服务的集成开发 ：需要同时修改前端、后端、甚至数据库脚本才能实现的功能。文件系统记忆能帮AI牢牢记住在不同部分所做的约定和接口设计。

6.2 不推荐使用的场景

  • 简单的单文件修改 ：比如修一个具体的bug，改一个CSS样式。直接向AI描述问题会更高效。
  • 探索性编程或技术调研 ：你需要快速尝试多种方案、查阅文档、写一些一次性实验代码。这种非线性的、发散性的任务不适合严格的PIR流程。
  • 仅修改配置文件 ：更新 .env 、调整 webpack.config.js 参数等。这些任务通常步骤简单，无需复杂规划。

6.3 新手常犯的错误及避免方法

错误1：任务拆解得过于粗粒度。

  • 现象 ：计划中只有一个任务：“实现用户管理系统”。AI会感到无所适从，信心检查会失败，或者生成一个庞大而混乱的代码草稿。
  • 纠正 ：强迫自己将任务拆解到“一个任务对应一个可验证的代码变更集合”的程度。参考第5.1节的“原子化”原则。

错误2：完全放任AI，中途不进行任何监督。

  • 现象 ：启动任务后就离开，几小时后回来看结果，发现AI可能在某些细节上钻了牛角尖，或者因为一个早期的小错误导致后续全盘皆输。
  • 纠正 ：Mission Runner是“增强智能”，而非“全自动智能”。尤其是在初期，建议每隔几个任务就检查一下 mission_plan.md 的进度和 mission_notes.md 中的记录。你的少量干预（如澄清一个模糊点）可以防止后续大量的纠偏工作。

错误3：忽视“信心检查”的红色警报。

  • 现象 ：AI多次就同一个任务的模糊性提问（信心检查评分低），用户却一直命令“继续执行”。
  • 后果 ：极有可能导致AI基于错误假设生成代码，需要推倒重来。
  • 纠正 ：当AI亮起“红灯”时，务必停下来。花一分钟时间仔细阅读它的顾虑，并给出清晰、无歧义的答复。这往往是节省后续一小时调试时间的关键。

我个人在经历了从最初的怀疑，到尝试，再到依赖的过程中，最大的体会是：Mission Runner并没有让AI变得更“聪明”，而是让它变得更“可靠”。它通过一套严谨的工程化流程，约束和放大了AI在代码生成方面的优势，同时用外部记忆弥补了其上下文有限的短板。它就像给一位才华横溢但有些健忘的工程师配了一位一丝不苟的项目经理和一本详实的工程日志。对于任何需要处理非 trivial 编码任务的开发者来说，将其纳入工具箱，都能显著提升与AI协作的产出质量和心理安全感。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区