执行摘要
这场 GitHub 工作坊用复古街机项目 Mona Mayhem 展示了 Copilot CLI 不只是“包了一层聊天界面的代码补全”。工作流先用持久指令为仓库建立上下文，再通过规划和执行模式，让智能体像结构化的编码协作者一样工作。
最关键的产品启发是把上下文、规划、执行和编排拆开看。/init 生成持久的仓库指导，/plan 把模糊需求转成可审阅的实现路径，Autopilot 则用多步骤编辑和检查替代孤立的一轮提示。
后半部分进入规模化：插件市场扩展工具、Fleet Mode 运行并发本地智能体，以及 /delegate 委派给云端编码任务。对构建者来说，智能体编码质量不仅取决于模型能力，也取决于工作流设计、可见约束和任务边界。
关键要点
/init被作为第一步上下文 grounding 展示：它扫描工作区并写入仓库指令，让后续智能体行为更贴合本地约定。/plan把交互从“立刻生成代码”改成“先产出蓝图”：在改代码之前，人可以先审阅假设、数据结构和实现步骤。- Autopilot 被展示为更长周期的执行循环，能够编辑、观察结果、响应失败并继续推进多个步骤，而不是每一步都等待新的提示。
- 多模态调试和终端输出成为智能体反馈循环的一部分，因此截图、错误和验证信号本身也成了重要的产品界面。
- 插件市场扩展了 CLI 智能体可调用的能力，但也让工具治理和权限边界变得更重要。
- Fleet Mode 被定位为在可拆分任务上协调并发智能体的方式，工作流需要清晰的任务边界以减少冲突。
/delegate指向云端托管编码代理：把长耗时工作从本地终端移出，并返回可审阅的 pull request。
构建者启发
- 把仓库指令当作产品基础设施，而不是提示词装饰。持久上下文才是智能体跨多步骤工作的基础。
- 在高影响改动前，让规划产物可见、可审阅。智能体编码需要明确假设，也需要一个捕捉设计歧义的位置。
- 围绕可观察检查来设计执行循环：终端输出、测试、截图和 diff 都应该先反馈给智能体，再交给人审阅结果。
- 只有当任务能按所有权边界、文件区域或验收标准清晰拆分时，才适合使用并行智能体。
- 对于云端委派，应优先优化可审阅性：小型 pull request、清晰任务描述和可追踪验证，比单纯自治更重要。
待验证事项
- 当多个智能体同时修改强耦合文件或共享项目配置时，Fleet Mode 如何处理冲突。
- 哪些 Copilot CLI 模式和命令已经广泛可用，哪些仍属于预览、账号限制或环境依赖能力。
- 在更大仓库中，持久指令、规划产物和长周期 Autopilot 循环会带来多少 Token 与成本开销。
- 云端委派任务是否能保留足够的上下文和验证证据，让团队安全审阅。