整合并行智能体改动，同时保留文件责任归属
本文目录
CueSpec 工作流编辑组撰写 · AI 辅助团队编辑。
让一个角色对组合结果负责，再依据已知基线和预期行为整合每份交付物。两个分支各自都可能通过局部检查，却在某项共享设置上互相矛盾。真正需要回答的是：组合后的代码与配置是否实现了同一项功能。
下面的虚构示例包含两个模块改动，以及对一个配置文件的相互竞争的修改。所有补丁都是原创教学提案；这里没有报告实际的仓库合并或应用运行。
确定共享基线
搜索功能应当启用，输入达到两个字符后开始搜索，并显示匹配条目的数量。输入是一组标题为字符串的条目。在这个小示例中，匹配仍区分大小写；相关性排序和考虑语言特性的匹配不在变更范围内。
基线 search-config.json：
{
"enabled": false,
"minChars": 3,
"showCount": false
}
基线 search-items.js：
export function searchItems(items, text, config) {
if (!config.enabled) return [];
return items.filter(item => item.title.includes(text));
}
基线 search-view.js：
export function describeResults(matches, config) {
return "Search";
}
将这个示意快照称为 BASE-SEARCH-v1。实际交付时，应记录真实的基线修订版本和确切补丁引用，而不能只依赖分支名称。
阅读两份提案
匹配模块执行者提议启用搜索，并加入两个字符的检查：
--- a/search-config.json
+++ b/search-config.json
@@ -1,5 +1,5 @@
{
- "enabled": false,
- "minChars": 3,
+ "enabled": true,
+ "minChars": 2,
"showCount": false
}
--- a/search-items.js
+++ b/search-items.js
@@ -1,4 +1,4 @@
export function searchItems(items, text, config) {
- if (!config.enabled) return [];
+ if (!config.enabled || text.length < config.minChars) return [];
return items.filter(item => item.title.includes(text));
}
视图执行者提议添加数量标签，但同时建议将共享配置中的阈值改为一个字符：
--- a/search-config.json
+++ b/search-config.json
@@ -1,5 +1,5 @@
{
"enabled": false,
- "minChars": 3,
- "showCount": false
+ "minChars": 1,
+ "showCount": true
}
--- a/search-view.js
+++ b/search-view.js
@@ -1,3 +1,3 @@
export function describeResults(matches, config) {
- return "Search";
+ return config.showCount ? `Search (${matches.length})` : "Search";
}
对 describeResults 的模块级检查，可以使用预先准备的匹配列表，完全不经过匹配模块。这样的检查既无法解决阈值分歧，也不能表明组合后的功能已经启用。
Git 的合并文档说明了如何相对于共同祖先组合改动，以及如何解决冲突编辑。文本合并不会替你选择产品规则。这里的决定很明确：需求规定的阈值是两个字符。
将共享部分交给一名整合者负责
| 文件或决定 | 负责角色 | 其他执行者如何参与 |
|---|---|---|
search-items.js |
匹配模块执行者 | 视图执行者引用双方约定的输入输出契约 |
search-view.js |
视图执行者 | 匹配模块执行者提供预期结果样例 |
search-config.json |
整合者 | 执行者提交设置提案并说明理由 |
| 阈值规则 | 功能决策负责人 | 依据需求解决一个字符与两个字符的分歧 |
| 组合改动与检查 | 整合者 | 执行者协助调查组合检查中发现的具体问题 |
如果交付物中已经存在重叠改动，应将这些补丁片段视为提交给整合者的提案。整合进行期间，不要让双方再次替换共享文件。
让冲突决策可检查
| 设置 | 基线 | 匹配模块提案 | 视图提案 | 组合选择及理由 |
|---|---|---|---|---|
enabled |
false | true | 不变 | true：需求中的功能必须能够运行 |
minChars |
3 | 2 | 1 | 2：已明确提出的功能规则 |
showCount |
false | 不变 | true | true：需求要求数量标签 |
组合后的拟议配置如下：
{
"enabled": true,
"minChars": 2,
"showCount": true
}
采用匹配模块的阈值条件，以及视图的数量显示实现。相对于同一基线的最终改动见组合提案补丁；两份原始提案也分别提供为 A 和 B。
按可追溯的顺序整合
- 确认基线，并与负责人一起保留无关的工作区改动。
- 检查每份确切交付物，将模块编辑与共享文件提案分开。
- 接受任何一份共享配置补丁片段之前，先记录阈值决定。
- 将两个模块改动和选定配置组装为一个候选版本。
- 检查完整候选版本，查找遗漏或非预期改动。
- 检查组合行为，并将结果记录到该候选版本的实际修订版本上。
这个顺序用于理解依赖，并非要求将改动合入实际使用中的分支。本示例不包含合并、重置、推送或部署命令。
检查组合结果
使用以下虚构条目：
[
{"id": "a", "title": "apple"},
{"id": "b", "title": "apricot"},
{"id": "c", "title": "berry"}
]
| 查询 / 配置 | 匹配模块的预期结果 | 预期标签 | 实际结果 |
|---|---|---|---|
a，组合配置 |
空列表 | Search (0) |
— |
ap，组合配置 |
ID 为 a、b，按此顺序 | Search (2) |
— |
zz，组合配置 |
空列表 | Search (0) |
— |
ap，enabled=false |
空列表 | 经结果描述函数处理时为 Search (0) |
— |
ap，showCount=false |
ID 为 a、b | Search |
— |
这些是拟议函数下的预期结果。实际应用还需要检查调用方和界面：是否传入了选定配置，是否显示了返回的状态？表中没有填入任何应用实测结果。
明确回退对象，而不只是表达模糊意向
组合候选版本引用：
基线修订版本：
匹配模块交付引用：
视图交付引用：
共享设置决定：
实际执行的检查及其证据：
回退对象：
[同时包含模块和配置的组合改动或发布版本。]
需要保留的状态：
[无关工作，以及任何独立的数据或模式影响。]
恢复基线检查：
[按选定回退流程操作后，哪些内容必须再次与基线一致？]
在这个示例中，代码和配置应作为整体处理。只恢复旧配置，可能会禁用功能，却将两个新模块都留在原处；只保留某一位执行者的配置，可能丢失另一项需求行为。实际回退流程取决于仓库和发布状态，因此操作前要先明确候选版本。
清晰的整合记录能告诉下一位审阅者：各份交付贡献了什么、为何作出共享决策，以及检查的是哪种组合。这样的交接比转发两条彼此独立的“已完成”消息更充分。