先把工程任务变成能验收的工作

让几个 AI 同时写代码并不难。真正占用人的精力的是反复解释背景、找运行记录、确认截图有没有做对，以及提醒某个任务继续推进。我觉得小团队可以先把这些协调工作安排清楚，再考虑增加多少个伙伴。

本模块从一项界面修改开始练习，逐步补齐任务记录、执行环境、检查、交接和维护。技术案例参考 SpaceXAI 工程师 Lingxi Li 的 Grok Bot for Engineering，以及 Kin 的中文分享。下文介绍的是作者披露的工作方式，并非我们已经在同等规模下验证的结果。

把一句需求拆成看得见的变化

案例中有一项很具体的需求。移动端的“分享为模板”藏在菜单里，需要在伙伴信息页顶部、更多菜单之前增加直接入口；首页长按菜单也要包含这项操作。

这里有两个位置，不能做完其中一个就交付。按钮出现、点击有效、原有操作不受影响，也分别需要检查。给执行者的指令越接近这些可观察的结果，后续返工就越容易定位。

下面是本课练习用的任务描述，与原图的案例对象保持一致，并补充我们的验收要求。

请调整移动端的“分享为模板”入口。在伙伴信息页顶部，把它放到更多菜单之前，同时加入首页长按菜单。先说明会影响哪些页面，再修改。分别提供两个入口的修改前后截图和实际点击结果。原有分享流程需要继续可用。暂不合并，也不发布。

这份指令限定了改动对象、位置、交付物与执行范围。它没有假设 AI 能凭一句“优化体验”理解所有细节。

一项任务至少留下一条记录

聊天适合讨论，任务账本适合查看现在走到哪一步。作者让工程伙伴共同维护 Notion 数据库，以便在长对话超出上下文容量后，仍能找到当前负责人和后续动作，也让人不用翻聊天就能查看进度。

截图中可以看到任务名称、负责人、阶段和变更请求编号。我们在练习中再增加验收项、证明材料位置、阻塞原因和下次检查时间，便于接手。这些新增字段是课程建议，不是对原图隐藏列的猜测。

状态与结果要对应

原图有“处理中”“观察中 3/3”“观察中 2/3”“待评审”。文章又讨论了完成与合并。它们不能简单理解为同一条进度条。

Hogan 的入职说明强调先登记再调研、启动或调整任务，并避免重复登记其他负责人已有的变更。这里可以学到一个实用办法。先找到同一件事的既有记录，再决定是接手、补充，还是新建，能减少两个人同时修一个问题。

本课练习

选一个有两个验收点的小改动，先建任务记录，再把需求交给一个工程伙伴。保留第一次返回的材料，即使它没有做对。

完成标准是记录中能找到负责人、两个验收项和对应证据。若只拿到“完成了”的回复，任务仍停在处理中。你应能明确指出还缺哪一项，而不是重新发一遍整段需求。

配图为基于原图生成的简体中文教学示意，不是产品真实中文界面，也不是本课程已执行任务的证明。