企业官网建设流程全解析

GitNexus 端到端工程流水线：gitnexus-lfg 的 plan → gate → work → review 四段式编排实战

【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexus

gitnexus-lfg 是 GitNexus 仓库中一个刻意保持"薄"的编排技能：它本身不携带任何工程逻辑，只负责把gitnexus-plan、gitnexus-work、gitnexus-review三个技能按固定顺序串成一条端到端流水线，并在"规划"与"执行"之间设置唯一一个阻塞式闸门。读完本文，你将掌握如何用/gitnexus-lfg一次性驱动"计划生成 → 用户确认 → 原子提交执行 → 图驱动评审"的完整闭环，理解 35 轮边界（planning boundary）的由来与治理方式，并能针对 headless 场景、结构漂移、评审返工等分支做出正确路由。

定位：一个不加工程逻辑的编排器

gitnexus-lfg的 SKILL.md（SKILL.md）开头就写明了自身定位：thin orchestrator over three existing skills。它不新增任何工程判断，只做三件事——排序、转发、设置闸门：

/gitnexus-lfg <task description> /gitnexus-lfg docs/plans/<existing-plan>.md # 跳过 lane 1，直接从闸门开始

核心纪律只有一条：每个 lane 都必须真正调用对应的技能（读取其 SKILL.md 并照做），绝不允许用"技能会做什么"的摘要来代替真实调用。这样做的直接后果是——编排层保持零逻辑重复，所有深度（plan 的 13 节结构、work 的原子提交纪律、review 的评审标准）都下沉到被编排的三个技能里，由它们各自的 SKILL.md 和references/目录负责。

在 GitNexus 仓库中，技能以多份拷贝存在：gitnexus/skills/是规范源，gitnexus-claude-plugin/skills/、gitnexus-cursor-integration/skills/等是派生的插件镜像，另有一份gitnexus-lfg出现在 gitnexus-claude-plugin/skills/gitnexus-lfg/ 下。编排时优先读取仓库内的规范源（Claude Code 插件的 SKILL.md 与规范源内容一致）。

Lane 1 — 规划：边界分诊优先

第一个 lane 由gitnexus-plan负责，但在真正规划之前，编排器必须先做一次边界分诊（boundary triage）：

• 如果任务明显低于规划边界——即平凡或小范围工作，Agent 用远少于约35 轮（turns）即可完成——编排器应当直接说明这一点，并主动提供gitnexus-work直接模式（direct mode）作为整条流水线的替代方案，然后尊重用户的选择；
• 否则，才调用gitnexus-plan执行正式规划。

这个 ~35 轮阈值不是拍脑袋的经验值，而是一条经过离线基准验证后提升（promoted）的 benchmark 策略，测量证据就记录在仓库的 eval/workflow_bench/README.md 中：历史基准数据显示，基线 Agent 能在 ≤35 轮内完成的任务，完整 plan→work 流水线的固定成本（新鲜度门禁含 analyzer 重建与重索引、完整的 13 节计划、work 阶段的再锚定）约为每任务 $9–11，在这种任务规模下无法摊薄回报；而workflow_direct（执行纪律但不做规划）与基线成本差只有 −15% 到 −55%。因此该 README 给出的路由结论与 lfg 的边界分诊完全一致：小任务走直接模式或纯 Agent，完整流水线留给跨模块工作、多会话执行、或计划文档本身即为交付物的场景。

关键约束：阈值是一条被提升的基准策略，不是永恒不变的启发式，Agent 绝不能在一次实时任务中自行修改它。它的再评估治理权属于本技能的 README（README.md § Threshold governance）——每当命名模型或工具 harness 变更时离线重跑配对基准，且至少每 90 天一次；只有当确定性提升门（deterministic promotion gate）确认无质量回退后，才允许更新 SKILL.md 中的阈值。这也与 workflow_bench 的"prompt and skill evolution loop"（候选技能必须以配对基准击败当前技能后才能被人类合入）互为表里。

调用的细节与深度问题的归属

确定需要规划后，编排器用任务文本调用gitnexus-plan，knob 覆盖参数原样透传。例如用户写出：

/gitnexus-plan impact_depth:3 depth:deep <task description>

其中depth、form、impact_depth、pdg_data_depth、freshness等配置旋钮的完整默认值表由gitnexus-plan的 SKILL.md § Configuration 定义（如impact_depth默认 2、max_primary_symbols默认 5、max_snippet_lines默认 30）。lfg 的规则很明确："规划深度问得多深"这个问题，只能由gitnexus-plan在最开始问一次——gitnexus-plan在交互式会话且调用未携带任何显式深度信号时，会以阻塞式问题给出 Quick / Standard / Deep 三档选择，并把它换算成等价的 knob 值。编排层绝不重复询问。

如果输入已经是一个计划文件路径（docs/plans/<existing-plan>.md），则直接跳过 Lane 1，从 Lane 2 闸门开始。计划产出落在docs/plans/目录，路径必须被记录下来，因为后续每个 lane 都以它为输入。

计划文档的形态

gitnexus-plan产出的计划是docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md，一份 13 节的实现就绪计划，其中第 11 节是机器可读的implementation context pack——包含acceptance_criteria、evidence_provenance、primary_symbols、files_to_modify、pdg_constraints、tests、verification_commands、avoid等字段，让后续执行 Agent 无需重新调研仓库即可开工。计划的写入与读取都只能通过字节一致的辅助脚本 scripts/evidence-provenance.mjs 完成（write-plan/read-plan），其read-planreceipt 以描述符锚定规范路径、精确 base64 字节与 SHA-256 摘要，evidence_provenance字段携带全局脏树摘要（global dirty digest）与按层排序的被引用路径清单，把工作区证据与 HEAD 一起钉死。

Lane 2 — 计划闸门：流水线唯一的人工检查点

这是整条流水线的唯一阻塞式检查点（blocking gate），目的很明确：执行是昂贵且难以回滚的，所以必须在投入执行前让用户做一次明确选择。

编排器先向用户呈现计划摘要：目标（objective）、拟议变更（proposed changes）、实施顺序（sequence）、顶级风险（top risks）、未决问题（open questions）以及计划文件路径。然后以阻塞式问题询问：

1. Proceed to work— 继续到 Lane 3；
2. Stop here— 计划文件即为交付物，流水线到此结束。

在 Claude Code 中使用AskUserQuestion工具；在不支持阻塞式工具的 CLI 上，使用聊天中的编号列表。

两条重要规则：

• 加深（deepen）不是默认选项——深度在 Lane 1 已由用户在前置决定，因此默认不再提供加深；但如果用户在闸门处显式要求加深，则执行gitnexus-plan的 Deepen 模式（/gitnexus-plan deepen docs/plans/<plan>.md），用加强后的计划回到闸门，用户要求多少次就做多少次。Deepen 模式会先通过read-plan精确解码plan_bytes_base64，重跑 Phase 1 新鲜度门禁，把计划从 §11 pack 播种进台账，再通过write-plan --replace --expected-plan-path --expected-plan-digest重写同一规范文件，任何摘要/路径不匹配都会阻止发布。
• 没有显式选择就绝不放行——闸门存在的意义正是因为它不可跳过。

Headless / 非交互运行的规则

无人能回答闸门问题时，流水线在 Lane 1 之后直接结束——计划文件是交付物（即闸门选项 2），并在最终报告中明确说明这一点。绝不自动放行到执行阶段。这与 workflow_bench 的 bare / headless 运行模式（dontAsk、无交互）设计一致：基准环境本身就是非交互的，因此它在编排上天然落到"计划即交付物"这一档。

Lane 3 — 执行：以验证过的原子提交落地

获得用户放行后，编排器用计划路径调用gitnexus-work。执行技能负责四件事：

1. 在 HEAD 处重新锚定计划——通过read-plan加载计划的精确字节，即使当前 HEAD 与计划 pin 相同，也要重算全局脏树摘要与排序的被引用路径清单（两层漂移检查），任何已变更的引用路径先重读再依赖；
2. 按实施顺序（Implementation Sequence）执行计划 §7——每条目都遵循"编辑前impact查询 → 最小实现 → 按计划场景补测试 → 提交前detect_changes {scope: "staged"}门禁 → 单条 conventional commit"的固定纪律，HIGH/CRITICAL 风险在动手前向用户暴露爆炸半径；
3. 完成后刷新知识图谱（Phase 4）——跑完整验证套件、逐条核对 §13 Definition of Done 与acceptance_criteria，最后再执行一次 Build-current/index-current 过程，对已证明为最新的索引跑detect_changes {scope: "all"}；
4. 报告偏差——完成的步骤、产生的提交、与计划的偏差及原因、未满足的假设、DoD 状态、最终索引的 commit 与 runner identity。

执行中的关键基础设施是gitnexus-work独有的Build-current/index-current 过程（SKILL.md § Phase 2）：每次图相关的impact查询前比对index.commit与当前 HEAD、要求 schema-4 的 runner identity（含gitnexus-analyzer-dependency-runtime-v4依赖载荷摘要）为 current、incomplete_reasons为空；分析器源码有变动时先cd gitnexus && npm run build再用node gitnexus/dist/cli/index.js analyze --index-only --pdg重建本地索引。任何构建/刷新/身份校验失败都会阻塞图相关的影响分析与最终完成，绝不回退到旧图。

结构漂移的分支处理

如果gitnexus-work在执行途中发现计划的结构性假设不成立（structural drift），它会路由回gitnexus-plan的 Deepen 模式——而不是硬推过去。编排器此时负责把漂移后的计划带回 Lane 2 闸门，由用户再次选择继续或停止。注意 drift 路由与普通偏差的区分：小范围、计划内的偏差由执行器自行适配并记录在 commit message 与最终报告中；只有结构性遗漏（scope、需求、关键技术决策或规划接缝失效）才触发 Deepen 回路。

Lane 4 — 评审：一次修复循环封顶

编排器对完成的工作调用gitnexus-review。目标解析的规则是：

• 存在打开的 PR 时传 PR URL 或编号；
• 否则传当前分支（branch/ref 对默认分支求 diff，merge-base 语义）；
• 如果执行后还有本地改动残留，则把local作为第二个、单独标注的评审面传入。

gitnexus-review拥有自己的目标解析逻辑（PR /base...head/base..head/ 分支 / local 多形态）、精确 SHA 检出与索引对齐（临时 detached worktree，绝不切换用户当前 worktree）、以及 merge-base 选择——SKILL.md 明令"不要在这里重复该逻辑"。

评审流程包含编号工作流（全量 diff →detect_changes对齐精确面 → 对每个行为变更符号跑impact {includeTests: true}→ 逐条核查 diff 外的 d=1 直接依赖 →context核查关键符号 → taint/依赖传递检查 + 版本与失效常量核查），外加按图聚类分组的专家透镜（expert lenses）：变更触及哪个领域就派哪个领域的透镜（ingestion、embeddings、Ladybug 等），四个跨领域透镜（架构契合、语言一致性、Definition of Done、简洁性）恒定运行，每个透镜的输出都必须落到 Finding 标准（严重级 + 精确path:line锚点 + 失败场景 + 图证据 + 补救建议）。

编排层在评审后要做的是：

1. 把评审结论与发现呈现给用户；
2. 用户希望修复的发现，按边界分流：属于gitnexus-work直接模式范围（1–2 个文件、无架构决策）→ 交给直接模式；更大的 → 回到计划闸门（用发现 Deepen 计划，或停止）；
3. 重跑本 lane 的评审一次。这次重跑不得再开启新的修复循环——即使仍有发现，也要如实报告并把用户导向/gitnexus-work（或计划闸门）以有意为之的方式继续。一次修复循环封顶（one bounded fix cycle）的硬约束，是为了防止评审-修复无限拉锯。

最终报告与后续动作

流水线以一条消息收尾，包含：计划路径、执行的加深循环次数、产出的提交、验证状态、评审结论与未解决的发现、以及明确未完成的事项（如果有）。一个重要的默认行为是：流水线不会自行 push，也不会自行开 PR——编排器把两者都作为可选的下一步提供给用户。

完整链路图与各 lane 归属速查

下表汇总整条流水线的 lane、技能归属与闸门：

三个技能对应的仓库权威文档与契约：

• gitnexus-plan的 README.md 定义了它与图谱/PDG/源码验证三层架构的交互，以及references/下五个契约文件（context-ledger、pdg-slice、plan-template、context-pack、evidence-provenance）；
• gitnexus-work的 README.md 定义了与计划的契约（§11 pack 为机器接口、evidence_provenance强制、计划永不被修改）以及唯一的新鲜度过程；
• gitnexus-review的评审输出模板（Findings / Change and blast-radius summary / Coverage and residual risk / Verdict）可以直接复用到任何 CI 评审脚本中。

阈值治理：为什么 35 轮边界可以信赖

Lane 1 的 ~35 轮边界来自 eval/workflow_bench/README.md 的测量结论：在trivial-version-alias（基线 16 轮）、inv-bug-pdg-note（基线 22 轮）、inv-feature-list-repos-filter（基线 32 轮）这类任务上，完整 workflow 的成本是基线的 3 倍以上，而workflow_direct接近基线甚至更快；真正的分水岭在cross-module-parse-retry这类跨模块任务上——workflow_direct以 52 轮 / $9.53 / 15 分钟对基线的 98 轮 / $18.03 / 34 分钟取胜（成本 −47%、墙钟 −56%），靠的正是 impact 优先导航与门禁化提交。这就是 lfg 边界分诊的实证基础：小任务走直接模式，跨模块任务才值得付完整规划的固定成本。

同时，workflow_bench 的 promotion 门对任何技能改进都要求：至少 3 对有效运行、零排除、每任务每运行都过隐藏 oracle、无单任务分辨率回退、分辨率有 ≥2 的余量、同质量下效率指标中位提升 ≥5%、单任务效率回退 ≤20%。也就是说，lfg 里那条 35 轮阈值不是谁拍脑袋写的，而是经过确定性提升门验证后才写进 SKILL.md 的受管策略——这也是为什么实时任务中的 Agent 被明确禁止自行编辑它。

何时使用 lfg：一个路由速判

• 任务平凡或 ≤35 轮可完成 → 跳过流水线，直接/gitnexus-work <small task text>直接模式，或纯 Agent；
• 跨模块、需要多会话执行、或计划文档本身是交付物 → 完整/gitnexus-lfg <task>；
• 已有现成计划文件 →/gitnexus-lfg docs/plans/<existing-plan>.md，从闸门开始；
• 无人值守 / headless / CI 环境 → lfg 会在 Lane 1 后停住，计划即交付物，绝不自动执行。

在 GitNexus 仓库里，这套编排对应的技能栈与基准基础设施全部开源可查：规范源在 gitnexus/skills/，插件镜像在 gitnexus-claude-plugin/skills/，配对基准与提升门在 eval/workflow_bench/，你随时可以按 README 中的 quick start 复现测量，或按 "Prompt and skill evolution loop" 的流程离线提交一个候选技能改动——但记住：技能的自改进永远走离线候选循环，绝不在实时任务中自我改写。

【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexus