20 个章节 · 支持关键词组合搜索
架构、流程与人机泳道
实践 / 建议架构与流程：五个责任面，一条可验收交付链
知识回答业务和规则，技能描述可重复执行的方法，平台管理任务和运行，项目承载实现， 独立验证确认交付事实。人从 idea、需求和多渠道信息出发，与 AI 澄清方案后委托自主工作流； 诸葛从巡检和运行问题进入同一交付链。人保留目标、关键取舍与风险责任，通用流程保留合并及生产发布的人审门。 新核对的 IDP 项目另有自动合并和发布执行约定，须按明确的项目政策适配，详见项目可观测与操作能力包。
五张图展示双入口、系统架构、人机验证与推荐整合状态。部门虚机和诸葛入口已有；贯通全部环节仍需按后文演练验收。 Golden Path 的 MR 顺序采用用户给出的详细顶层方案：分支线下验证、独立评审后创建 MR。 平台介绍页与详细方案表述存在差异，实际模板接入时应登记版本并核对。
人提出方向，机器完成更多端到端工作
人的主要输入包括 idea、客户诉求、企信讨论、TAPD 缺陷、用户反馈、经营观察与历史复盘。 AI 可辅助归并、去重、追溯来源和找冲突；人关注真正的问题、收益、约束和优先级， 通过 Multica 或 PC 客户端反复对话，形成方案、需求和可验证的验收条件。 需要独立评审时形成关联的 PRD/DESIGN/TECH Issue，再确认当前合同与执行边界，驱动 Agent 工作流。
泳道按高频协作排列为“人 → Multica → 开发 Agent → GitLab → 发布验证/独立评审 → 诸葛”。 开发 Agent 与 GitLab 相邻，GitLab 与发布验证相邻；诸葛保留自主发现问题与发布后复核的入口。 PC 对话也收敛到同一合同，图中 Multica 泳道承担编排与共享过程记录，不限定人的对话客户端。
人不必逐步批准机器的每次读文件、改代码或运行测试。 在授权范围内，机器可以连续完成分解、实现、分层/E2E 自验、CI 反馈修复、测试环境验证与 MR 准备。 只有范围/验收变化、重大风险、证据不足、重试超限和既定人工门需要交人判断。 图中“人”是职责总称，实际每个任务仍要登记具体责任人，不能因为合并了泳道名称而失去责任归属。
自主范围的扩大应有验证能力支撑：可重建环境、可信且可复现的测试、受保护检查器、 实际制品/环境证据、观测与回退，以及可执行的暂停/接管机制。 先从单仓到固定跨仓组合，从局部自验到真实业务旅程验证，按试点结果逐步扩大授权。 可验证性提升会减少人的重复检查，使人更关注需求价值、验收标准、关键取舍和上线后的实际效果； 它不自动取消当前 MR 合并及生产发布的人审要求，也不把没有覆盖的风险判定为通过。
两个研发交互入口，统一 GitLab Issue SSOT
用户已明确公司的研发交互方式，本文据此更新此前多来源需求账本的概括：
- 直接在 Multica 聊天界面把需求、范围和验收聊清楚，形成或关联 Multica Issue。
- 在个人 PC 的 Codex、Claude 等客户端澄清需求，创建 GitLab Issue 或 Multica Issue。
两条路径最终以 GitLab Issue 为需求与验收的 SSOT，Multica 关联它。 GitLab Issue/MR 保留进展摘要与验收证据，CI reports/artifacts 保存对应原始报告； 详细执行过程和测试结果保存在 Multica Issue 与 topic 的 reply 中，并与 GitLab 证据双向关联。 PC 本地会话是入口和临时工作上下文；跨人、跨 Agent、跨设备交接必须能从关联记录恢复。 诸葛的企信受理、告警和巡检仍是运行问题入口；转入研发修复后收敛到同一 GitLab 任务合同。
下列为落实这一模式的建议约定，不表示已核验所有同步接口上线。
| 记录位置 | 保存内容 | 谁负责保持一致 |
|---|---|---|
| GitLab Issue 正文 | 当前有效目标、范围/非目标、验收标准、风险、依赖、责任与 Multica 关联 | 需求责任人确认，指定同步入口更新 |
| GitLab Issue 备注 | 需求确认、阶段结果、阻塞/接管、范围变更、验证结论、MR/交付摘要及详细记录链接 | 人或受控执行桥写入，标明执行者与来源 |
| Multica Issue | 执行计划、分解、运行/角色状态、重试、交接与 GitLab 关联 | Multica 运行流程维护 |
| Multica topic reply | 详细讨论、实现与验证过程、失败分析、评审往返、过程证据链接 | 对应参与者/Agent 追加，保留先后与来源 |
| GitLab CI/制品/证据系统 | 扫描与测试原始报告、日志、制品摘要和实际部署事实 | 原执行系统生成；GitLab 保存验收证据或稳定引用，Multica 关联过程与结果 |
“SSOT”指需求、范围和验收最终以 GitLab 的当前有效合同为准； 无需把 Multica 全部过程数据复制进 GitLab，也不能把模型摘要作为实际测试结果的权威来源。
GitLab Issue 还可以分别承载 PRD、DESIGN、TECH 等独立文档产物，通过类型命名、标签和关联组织。 每个产物的正文是其唯一维护源；需要整合时由 FEATURE Issue 索引当前采用版本。 文档任务不必有代码或 MR，完成条件是对应内容与评审验收；代码任务才进入实现、测试、CI/MR 流程。 具体命名、关系、状态与按类型验收见三个协作空间与 Feature 文档生命周期。
两种创建顺序都支持，但执行前补齐唯一关联
GitLab 先建时，Multica 创建或关联执行 Issue，并写入 GitLab 完整引用。 Multica 先建时，可以先充分讨论；进入正式自主开发前，建议创建或关联 GitLab Issue， 把确认后的合同写入 GitLab，再回填双向链接。这个同步步骤可由平台自动完成，无须人重复录入。 如果平台当前无法自动完成，就显示“待建立 SSOT 关联”，保留草稿并明确下一步。
关联键至少包含 GitLab 实例、project ID/path 与 issue IID，不能只用跨仓重复的 #123。
一个 GitLab Issue 可以关联多轮 Multica run/topic；本地修复、平台接续都沿用同一主任务。
若分解为可独立验收的子需求，再建 GitLab 子 Issue 并声明父子关系；纯执行步骤可以只在 Multica 分解。
重复创建或同步重试时先按关联键对账，同名标题不能作为去重依据。
摘要回写与需求变更
建议在需求确认、阶段交接、阻塞/接管、验证完成、MR 就绪、合并等里程碑追加摘要。 工具调用细节与逐轮失败留 Multica，避免 GitLab 备注成为日志流。 摘要只保留必要事实和可访问的证据指针；团队成员能从 GitLab 找到对应 topic/reply。
[阶段摘要] 验证完成 / 有阻塞
需求版本：本次读取的 GitLab Issue 内容版本或内容摘要
完成范围：AC-1、AC-2；未完成：AC-3（测试环境不可用）
代码输入：仓库、分支、commit；制品与验证报告链接
结论：BLOCKED_ENV；下一步：补齐环境后重验
详细过程：Multica Issue / topic / reply 链接或可定位 ID
关联 MR：如已创建则填写；责任人与下一检查点
需求在任一入口发生实质变更时，先保留讨论，再由责任人确认并更新 GitLab 当前合同， 追加变更摘要，通知在途执行者重读。建议派单固定合同的内容摘要或系统可用版本标记； 发现 验收标准/范围变更就暂停受影响步骤并重新评估，不能按两边最后写入时间盲目覆盖。 若实现阶段发现新事实，应提交变更建议，不能让编码 Agent 自行降低 验收标准。 Multica 重试/阶段完成可以自动更新执行状态，但 GitLab 关闭须满足该 Issue 的验收和关闭政策。
PC 与 Multica 同时开发同一任务时，建议指定一个当前执行权持有者； 通过分支/SHA 和交接摘要切换执行权，避免两个 Agent 并发覆盖同一实现。 详情暂不可访问时保留摘要和证据链接，不能凭空宣称已复核；恢复后按来源事件对账。
本节依据： 公司开发平台、Golden Path 详细方案。
五张图依次展示双入口与记录分工、系统架构、人机验证、问题闭环和交接责任。用户确认的入口与 SSOT 已纳入，跨系统自动化仍按建议合同验收。