两个编程助手同时工作一个写页面一个写查询。各自检查通过合并时也没有文字冲突页面却展示不出结果。与此同时更多候选修改进入待审队列用户能使用的功能并没有相应增加。这两种现象有关联工作被分散得更快接收和组合的能力却没有自动增长。有效协作既需要保护各自的修改也需要管理共享约定、先后依赖和正在等待的工作。下面沿一个假设的笔记搜索功能说明这些关系。文章目录分开的任务需要真正分开的写入范围共享约定保护的是彼此对行为的理解尽早接通一条完整路径比最后集中拼装更稳妥开工数量要服从接收能力共同节奏最终要保留责任与理解分开的任务需要真正分开的写入范围页面任务负责关键词输入和结果展示查询任务负责查找数据。这样的分工只说明职责名称还没有说明它们会接触哪些资源。如果两个助手编辑同一个目录其中一个调整依赖、切换代码状态或覆盖配置另一个任务就可能在不知情时改变运行条件。Git 分支是一条独立发展的版本历史不会因为创建分支就自动多出一个文件夹。需要同时使用不同文件状态时可以安排独立工作目录Git 的 worktree 功能提供了让同一仓库的不同分支分别出现在不同目录中的方式。目录隔离保护当前文件分支记录各自修改两者解决的问题不同。外部资源仍可能共享。两个目录可以连接同一数据库、占用同一服务端口或者操作同一测试账户。即使代码互不覆盖一个任务清理数据也可能破坏另一个任务正在使用的样例。因此独占范围需要覆盖实际写入资源不能只写“前端归你后端归我”。在搜索例子中页面与查询都可能需要修改统一请求客户端。这个文件应当有明确负责人或者先完成双方依赖的公共调整再分别推进。把同一份修改同时交给两方并不会自动得到双倍速度更可能得到覆盖和重复决策。适合并行的工作是当前已经具备输入、能够独立推进并且不会频繁改变对方依据的部分。任务数量本身不能说明并行程度如果第二项工作始终等待第一项确定字段它只是提前进入了等待队列。共享约定保护的是彼此对行为的理解假设页面以为查询直接返回笔记列表查询实现却返回一个同时包含列表与总数的对象。两种结构单独都合理直接连接却不兼容。问题并不发生在同一行文本所以版本工具不会把它报告为合并冲突。并行前需要先固定跨边界的承诺关键词怎样传入结果用什么结构返回没有匹配时如何表达服务故障怎样与空结果区分。这个约定还应包含数据含义例如只返回当前用户有权查看的笔记以及结果采用什么排序。共享约定不必管住每个内部细节。页面怎样组织组件、查询怎样构造条件可以由各自负责。真正需要共同决定的是另一方必须依赖的部分。边界过粗会留下猜测边界过细则让本来独立的实现也持续等待批准。几个共同使用的请求和响应示例通常能让分歧更早显现。它们应当来自同一份有效约定而不是双方各自编造一套符合自己实现的数据。如果测试中的假返回恰好复制了各自误解两边都可能通过真实连接依然失败。过程中发现约定必须改变时应先通知直接依赖方说明新增条件和衔接方式。不能让页面继续按旧结构完善展示等查询全部完成后再要求重写。共享约定减少的是未来返工真正有用的时间点在依赖方还来得及调整之前。尽早接通一条完整路径比最后集中拼装更稳妥独立工作时间越长双方对共同系统的假设越容易分开。字段一直没变查询可能已经为分页调整排序页面却仍默认按照更新时间展示。这是行为不兼容也不会因为文件能够自动合并而消失。搜索功能可以先接通一条窄路径输入一个关键词查询返回一页结果页面正确展示。它仍然经过页面、请求和数据访问但已经形成一个能够判断的完整结果。按用户行为切出小块完整能力通常称为纵向切分。之后增加分页或筛选时双方已有共同运行基础。相比页面一次写完全部交互、查询一次完成全部规则再进行大规模拼装早期连接能够更快暴露字段、排序和失败表达的差异。拆小并不意味着把每个函数都变成独立任务。过碎的交接会增加说明和接收成本也可能让所有片段都只能单独编译没人能判断整体行为。合适的单位应当足够小又保留可观察的业务结果。必要权限与失败处理属于这个结果成立的条件不能被挪到遥远的“后续优化”。把小变化经常放入共同版本并获得反馈是持续集成的核心实践常简称 CI。自动运行项目检查能支撑这种反馈但共同版本是组合后的新状态仍应确认双方连接的约定。两个分支分别通过只能证明它们各自当时的条件不能直接相加为组合正确。集成责任也应提前明确。需要有人接收组合结果、处理约定偏差并确认最终差异没有混入无关工作。多人都写完自己的部分之后如果没有人负责最后这个接收任务就会停在“各自完成、整体未完成”的状态。开工数量要服从接收能力AI 能快速生成候选代码团队理解和审查这些变化仍需要时间。如果一个人刚交出搜索页面就去启动另一个功能查询作者也不断生成新修改待审队列可能持续增长。等待期间主线继续变化旧任务收到反馈时又要重新恢复背景返工成本随之增加。已经开始、尚未达到完成条件的工作称为在制品。对它设置数量限制是为了让拥堵暴露出来并把能力用于推动结束。它不要求大家降低效率而是防止入口速度长期超过接收速度。例如待审工作已经超出当前接收能力时继续启动新任务未必有帮助。作者可以先缩小难以理解的改动、补齐共享约定或解决阻塞集成的具体疑点。能减少审查者重新调查的内容比再生成一批无人及时阅读的代码更接近交付。限制没有普遍适用的固定数字。任务大小、外部等待和人员能力都会改变合理范围。也不能通过把未完成任务改名为“基本完成”来隐藏负担只要它仍占用修改、审查和集成能力就仍在流动过程里。工作状态应当对应真实边界。等业务决定、等环境和等审查需要不同动作统称“处理中”只会让团队继续催促。记录当前缺什么、谁能提供以及接下来怎样接收通常比增加许多漂亮状态更有效。紧急故障可以打断常规安排但需要承认它占用了能力其他承诺因此如何变化也应可见。共同节奏最终要保留责任与理解候选修改经过团队以后应当有人能够解释搜索请求经过哪里、权限在哪里判断、结果从哪份数据取得以及失败时用户看到什么。不需要每个人背下全部生成代码但关键路径不能只存在于某次 AI 对话中。负责人还需要知道为什么采用当前方案。例如选择现有存储中的查询是因为当前规模和响应要求能够满足后续何种变化会迫使团队重新评估。这类条件比把每行代码翻译成中文更适合交接也比完整保留所有讨论更容易找到当前有效结论。审查因此也承担知识进入团队的作用。围绕一个数据约定和一个失败结果展开讨论会让接手者形成可用理解。只在绿色状态旁边批准可能省下当前时间却把理解成本留到故障发生时。需要多深的审查取决于后果责任不会因为代码由 AI 生成而转移给工具。工作节奏可以有不同安排。固定时间组织一个短期目标并检查结果的团队可以使用 Scrum 这样的迭代框架持续接收维护请求的团队可以用看板观察流动与在制品。它们的价值都在于促成实际调整会议数量或看板列数本身不是效果。对于这项搜索工作值得观察的是从开始到接通用了多久哪些地方等待最久合并后又返工了什么以及维护者能否接手。代码生成加快以后优先修正的可能是共享约定、审查队列或责任空缺。并行只有穿过这些接收环节才会变成用户真正得到的结果。参考资料Git worktree 文档Martin FowlerContinuous IntegrationThe Kanban GuideScrum GuideSoftware Engineering at GoogleCode Review。AI 工程知识库 
长河君 · 2026/10/29 21:32:40 · 阅读 1.2k 多人协作与工作节奏：让并行产出真正汇成结果
两个编程助手同时工作一个写页面一个写查询。各自检查通过合并时也没有文字冲突页面却展示不出结果。与此同时更多候选修改进入待审队列用户能使用的功能并没有相应增加。这两种现象有关联工作被分散得更快接收和组合的能力却没有自动增长。有效协作既需要保护各自的修改也需要管理共享约定、先后依赖和正在等待的工作。下面沿一个假设的笔记搜索功能说明这些关系。文章目录分开的任务需要真正分开的写入范围共享约定保护的是彼此对行为的理解尽早接通一条完整路径比最后集中拼装更稳妥开工数量要服从接收能力共同节奏最终要保留责任与理解分开的任务需要真正分开的写入范围页面任务负责关键词输入和结果展示查询任务负责查找数据。这样的分工只说明职责名称还没有说明它们会接触哪些资源。如果两个助手编辑同一个目录其中一个调整依赖、切换代码状态或覆盖配置另一个任务就可能在不知情时改变运行条件。Git 分支是一条独立发展的版本历史不会因为创建分支就自动多出一个文件夹。需要同时使用不同文件状态时可以安排独立工作目录Git 的 worktree 功能提供了让同一仓库的不同分支分别出现在不同目录中的方式。目录隔离保护当前文件分支记录各自修改两者解决的问题不同。外部资源仍可能共享。两个目录可以连接同一数据库、占用同一服务端口或者操作同一测试账户。即使代码互不覆盖一个任务清理数据也可能破坏另一个任务正在使用的样例。因此独占范围需要覆盖实际写入资源不能只写“前端归你后端归我”。在搜索例子中页面与查询都可能需要修改统一请求客户端。这个文件应当有明确负责人或者先完成双方依赖的公共调整再分别推进。把同一份修改同时交给两方并不会自动得到双倍速度更可能得到覆盖和重复决策。适合并行的工作是当前已经具备输入、能够独立推进并且不会频繁改变对方依据的部分。任务数量本身不能说明并行程度如果第二项工作始终等待第一项确定字段它只是提前进入了等待队列。共享约定保护的是彼此对行为的理解假设页面以为查询直接返回笔记列表查询实现却返回一个同时包含列表与总数的对象。两种结构单独都合理直接连接却不兼容。问题并不发生在同一行文本所以版本工具不会把它报告为合并冲突。并行前需要先固定跨边界的承诺关键词怎样传入结果用什么结构返回没有匹配时如何表达服务故障怎样与空结果区分。这个约定还应包含数据含义例如只返回当前用户有权查看的笔记以及结果采用什么排序。共享约定不必管住每个内部细节。页面怎样组织组件、查询怎样构造条件可以由各自负责。真正需要共同决定的是另一方必须依赖的部分。边界过粗会留下猜测边界过细则让本来独立的实现也持续等待批准。几个共同使用的请求和响应示例通常能让分歧更早显现。它们应当来自同一份有效约定而不是双方各自编造一套符合自己实现的数据。如果测试中的假返回恰好复制了各自误解两边都可能通过真实连接依然失败。过程中发现约定必须改变时应先通知直接依赖方说明新增条件和衔接方式。不能让页面继续按旧结构完善展示等查询全部完成后再要求重写。共享约定减少的是未来返工真正有用的时间点在依赖方还来得及调整之前。尽早接通一条完整路径比最后集中拼装更稳妥独立工作时间越长双方对共同系统的假设越容易分开。字段一直没变查询可能已经为分页调整排序页面却仍默认按照更新时间展示。这是行为不兼容也不会因为文件能够自动合并而消失。搜索功能可以先接通一条窄路径输入一个关键词查询返回一页结果页面正确展示。它仍然经过页面、请求和数据访问但已经形成一个能够判断的完整结果。按用户行为切出小块完整能力通常称为纵向切分。之后增加分页或筛选时双方已有共同运行基础。相比页面一次写完全部交互、查询一次完成全部规则再进行大规模拼装早期连接能够更快暴露字段、排序和失败表达的差异。拆小并不意味着把每个函数都变成独立任务。过碎的交接会增加说明和接收成本也可能让所有片段都只能单独编译没人能判断整体行为。合适的单位应当足够小又保留可观察的业务结果。必要权限与失败处理属于这个结果成立的条件不能被挪到遥远的“后续优化”。把小变化经常放入共同版本并获得反馈是持续集成的核心实践常简称 CI。自动运行项目检查能支撑这种反馈但共同版本是组合后的新状态仍应确认双方连接的约定。两个分支分别通过只能证明它们各自当时的条件不能直接相加为组合正确。集成责任也应提前明确。需要有人接收组合结果、处理约定偏差并确认最终差异没有混入无关工作。多人都写完自己的部分之后如果没有人负责最后这个接收任务就会停在“各自完成、整体未完成”的状态。开工数量要服从接收能力AI 能快速生成候选代码团队理解和审查这些变化仍需要时间。如果一个人刚交出搜索页面就去启动另一个功能查询作者也不断生成新修改待审队列可能持续增长。等待期间主线继续变化旧任务收到反馈时又要重新恢复背景返工成本随之增加。已经开始、尚未达到完成条件的工作称为在制品。对它设置数量限制是为了让拥堵暴露出来并把能力用于推动结束。它不要求大家降低效率而是防止入口速度长期超过接收速度。例如待审工作已经超出当前接收能力时继续启动新任务未必有帮助。作者可以先缩小难以理解的改动、补齐共享约定或解决阻塞集成的具体疑点。能减少审查者重新调查的内容比再生成一批无人及时阅读的代码更接近交付。限制没有普遍适用的固定数字。任务大小、外部等待和人员能力都会改变合理范围。也不能通过把未完成任务改名为“基本完成”来隐藏负担只要它仍占用修改、审查和集成能力就仍在流动过程里。工作状态应当对应真实边界。等业务决定、等环境和等审查需要不同动作统称“处理中”只会让团队继续催促。记录当前缺什么、谁能提供以及接下来怎样接收通常比增加许多漂亮状态更有效。紧急故障可以打断常规安排但需要承认它占用了能力其他承诺因此如何变化也应可见。共同节奏最终要保留责任与理解候选修改经过团队以后应当有人能够解释搜索请求经过哪里、权限在哪里判断、结果从哪份数据取得以及失败时用户看到什么。不需要每个人背下全部生成代码但关键路径不能只存在于某次 AI 对话中。负责人还需要知道为什么采用当前方案。例如选择现有存储中的查询是因为当前规模和响应要求能够满足后续何种变化会迫使团队重新评估。这类条件比把每行代码翻译成中文更适合交接也比完整保留所有讨论更容易找到当前有效结论。审查因此也承担知识进入团队的作用。围绕一个数据约定和一个失败结果展开讨论会让接手者形成可用理解。只在绿色状态旁边批准可能省下当前时间却把理解成本留到故障发生时。需要多深的审查取决于后果责任不会因为代码由 AI 生成而转移给工具。工作节奏可以有不同安排。固定时间组织一个短期目标并检查结果的团队可以使用 Scrum 这样的迭代框架持续接收维护请求的团队可以用看板观察流动与在制品。它们的价值都在于促成实际调整会议数量或看板列数本身不是效果。对于这项搜索工作值得观察的是从开始到接通用了多久哪些地方等待最久合并后又返工了什么以及维护者能否接手。代码生成加快以后优先修正的可能是共享约定、审查队列或责任空缺。并行只有穿过这些接收环节才会变成用户真正得到的结果。参考资料Git worktree 文档Martin FowlerContinuous IntegrationThe Kanban GuideScrum GuideSoftware Engineering at GoogleCode Review。AI 工程知识库