Vibe Coding 指的是个人写代码的方式变了：从自己手写，变成让模型生成。
Vibe Native 指的是团队层面的变化：原生使用 Coding Agent 开发一个完整项目，完整地使用 Agent 的特性，并围绕这些特性和全新的“人-智能体”组织关系，重构团队的工作流程。
个人层面的转变已经发生，工具也不断涌现。但今天的问题是团队层面的：当一个团队里的每个人都在用 Agent 产出代码，甚至每个人同时开着好几个 Agent，原来为“人手写代码”设计的工具和流程开始失效。VS Code 仍然是一个好的编辑器，Git 仍然是一个好的版本控制系统，但它们都假设代码是人一行一行写出来、一个 PR 一个 PR 看过去的，这个假设已经不再成立，尤其不适合多人联合 Vibe Coding 一个大型项目。
任务要求
我们在真实的团队实践中观察到下面四个问题。它们互相关联，但可以分开解决：
- A：知识与决策的同步： 一个项目的知识不只在代码里。为什么选这个框架，为什么这个接口这么设计，上次为什么放弃了某个方案，这些沟通过程和经验大部分散落在飞书、微信和会议里。在 Vibe Native 的团队中这个问题更严重：每个人的 Agent 只知道这个人告诉它的东西，A 和 A 的 Agent 做了一个决定，B 和 B 的 Agent 并不知道，于是 B 的 Agent 按照旧的理解写了一整个模块。人与人、人与 Agent，以及属于不同人的多个 Agent 之间，知识和决策如何同步？
- B：Review 的失效： Agent 产出代码的速度远超人阅读代码的速度，一个下午可以产出几千行改动，涉及几十个文件。传统的逐行 Review 在这种速度下不可持续，Reviewer 要么走马观花地通过，要么陷在里面，Review 到一半已经忘了前面看过的文件改了什么，也忘了自己为什么觉得某处有问题。如果人的时间和注意力是最稀缺的资源，Review 应该变成什么样？
- C：能跑不等于能用： 模型生成的代码经常“看起来完成了”：界面很好看，但按钮点下去就报错；后端接口返回了数据，但那是写死的假数据，前端根本发现不了；还有很多功能实现出来和需求方设想的完全不是一回事，或者根本没有人要求过。这些问题在 Demo 阶段不明显，一到真实使用就集中爆发。如何在代码进入生产之前，系统性地发现“能跑但不能用”和“实现了但不是我要的”这两类问题？
- D：脉冲式的忙碌： Vibe Coding 的节奏是脉冲式的：开发者发出指令，然后等待，等待期间很“闲”；模型返回以后，开发者又需要在短时间内阅读大量内容并做出判断，出现“认知过载”。反过来，当开发者在忙着阅读和决策时，模型是闲置的。人和模型交替空闲，整体速度被两边的空闲拖慢，如何让这个过程变得平滑？或者至少变得有趣？
（首先排除「原神启动」）
本题希望你针对上述问题中的一个或多个，设计并实现一个系统，解决 Vibe Native 时代团队协同和管理面临的困难。
最终验收内容需要包括：一个“最小可用”的产品，并对应设计一个评估方式，说明你的系统确实改善了目标问题。单人完成本题时，产品应至少解决其中一个问题；组队完成时，应至少解决两个问题（需要串联整合起来，放在一个产品中）。
技术选型和产品形态不限：你可以做一个独立工具，也可以做一个现有 Coding Agent（Claude Code、Codex、Pi Agent、dsh 等）的扩展，通过 MCP、Hook、插件或者修改开源 Agent 源码的方式接入；也可以是一套新的工作流加上支撑它的最小工具集。与题目重点关系不大的部分，例如聊天软件的消息拉取、浏览器自动化、Diff 渲染，可以直接使用成熟方案。
“最小可用”的标准是：你在完成本题的过程中，愿意并且实际使用它。请在做题的过程中就使用你自己的系统，答辩时如实说明它解决了什么、没解决什么、用起来什么感觉。
提示与启发
可能的解决方式很多，以下只是启发，不要被它们限制（直接照搬下方方案、没有自己思考和取舍的，将酌情降低分数）：
- 对于问题 A，可以把决策从聊天记录和 Agent 会话中自动提取出来，变成结构化的、人和 Agent 都能读取的项目记忆
- 对于问题 B，可以让 Review 的对象从代码变成意图，先看 Agent 理解的需求是什么，再看它的实现计划，最后才看代码，并为 Reviewer 保存 Review 的状态和上下文，让中断和恢复成为常态
- 对于问题 C，可以在代码生成之前先生成验收标准和测试代码，让另一个 Agent 用真实的浏览器或者客户端去验收，或者检测前后端接口实现的不一致，识别写死的返回值和没有接线的界面
- 对于问题 D，可以为开发者维护一个注意力队列，把多个 Agent 的待决策事项按重要性排序，在开发者空闲时推送，或者在模型运行期间为开发者预先准备好这次修改的摘要、需要重点确认的地方和可能的风险
加分项
- HITL（Human in the loop）交互过程的可观测性：Vibe Native 团队里最难回放的不是代码变更，而是“为什么会这样改”。你的系统如果能记录人与 Agent 之间的交互过程，包括人给出的指令和决策、Agent 提出的方案和被否决的方案、Review 中提出的问题和处理结果、验收发现的问题和修复过程，并且能把这些记录和最终的代码变更关联起来，会是一个很大的加分项。
- 多人多 Agent 的组织设计：当一个团队里有多个人，每个人有多个 Agent，人和 Agent 之间的权限、责任和信任应该如何设计？谁对 Agent 生成的代码负责？一个人的 Agent 能否直接使用另一个人的 Agent 的产出？请给出设计并在至少两个人的协作中验证。
- 跨工具的知识流动：团队的知识同时存在于飞书、Git、Issue 和各个 Agent 的会话中。能否让这些来源的信息双向流动，而不是再造一个需要人手动维护的知识库？
思考题
- Vibe Native 的团队里，还需要“代码所有权”这个概念吗？
- Agent 应该被当作团队成员，还是工具？这个选择如何影响你的系统设计？
- 如果一个团队的知识都被结构化地记录下来供 Agent 使用，人还需要知道多少？
- Review 的目的是发现缺陷，还是让人理解代码？如果是后者，人是否还需要理解每一行？
- 开发者不再需要等待，是否一定是好事？等待期间的思考有没有价值？
- 当 Agent 生成的代码出了生产事故，责任应该如何界定？你的系统能为这个问题提供什么证据？
这些问题没有标准答案。我们更关心你如何定义问题、做出取舍，并解释自己的设计。