尧图网页设计 
目录摘要前置术语界定Vibe Coding / Agentic Coding / Agentic Software Engineering一、引言从 Code Change 到 Software Change 的范式转移二、Software Change 模型管理对象的精确定义三、Git 的新位置从 Software Change 控制面退回到 Source Code Control Plane四、Agentic Git Workflow把 Agent 纳入版本控制工作流五、Context Engineering把工程知识从 Prompt 升级为持久化资产六、Agent Governance四维边界模型七、VerificationRisk-adaptive 证据体系八、Software Change Record (SCR)Software Change 的可追溯实例九、AI-Native SDLC从需求到运维的端到端 Software Provenance十、VIBE CODING ENGINEERING 框架Intent / Context / Agent / Evidence / Change十一、MVP 实施路线结论摘要Vibe Coding 在 2025-2026 年迅速从AI 辅助写代码的工作方式扩展为对软件工程全链条的重组力量。本文给出的管理对象从 Code Change 升级为 Software Change的核心判断沿着 Git 工作流重设计这条具体主线逐节给出工程化落地形态在 对象层把 Software Change 精确定义为六个分量的复合对象对应为什么改 / 凭什么改 / 怎么改 / 改了什么 / 如何证明 / 谁批准。在 协议层保留 Git 作为 Source Code Control Plane 的核心地位但承认它只稳定承载 Software Change 中的 Code Change 子集其余分量由专门系统承载。在 工作流层把 Agent 纳入 Git 工作流——Plan-first、Worktree 隔离、Intent-branch、SCR 关联、Commit 保持简洁。在 Context 层把 AGENTS.md 作为组织级 Canonical Policy Layer把工具级 Rules.cursor/rules、.github/copilot-instructions.md、CLAUDE.md作为 Tool-specific Execution Layer。在 Governance 层用 Context / Capability / Execution / Approval 四维边界替代四级权限作为正式模型。在 Verification 层采用 Risk-adaptive 证据体系——不同变更类型要求不同维度证据避免必须六维齐全的过度治理。在 SCR 层把 Software Change Record 定义为跨系统聚合对象作为审计、回滚、合规的依据。在 闭环 SDLC 层从需求到运维实现端到端 Software Provenance。整篇文章的目标让 Vibe Coding 不再是AI 帮程序员写代码的浅层叙事而是 AI-Native Software Change Management 的工程化方法论。前置术语界定Vibe Coding / Agentic Coding / Agentic Software Engineering在进入正文之前必须先厘清三个常被混用的术语否则后续论证将建立在概念错位之上。三者不是严格的时间演化关系而是不同分析层次的概念术语分析层次含义关注重点Vibe Coding工作方式开发者主要通过自然语言与代码生成模型或 Agent 交互对话式编程、Context 管理、个人工作流Agentic Coding工具范式AI 具备自主规划、调用工具、迭代修复、跨文件编辑能力的编码模式Agent Loop、Tool Use、Plan/Act/ReplanAgentic Software Engineering工程范式在 Agentic Coding 之上把意图、上下文、证据、权限、责任纳入工程治理体系的完整范式Software Change、Provenance、Governance、HITL/HOTL三者是从开发者视角到工具能力视角再到工程治理视角的不同切片不是必然的演进阶段。一个组织可以同时具备三者开发者用 Vibe Coding 工作、Agent 具备 Agentic Coding 能力、组织运行在 Agentic Software Engineering 治理框架之上。后续章节讨论的全部内容都是围绕如何把 Vibe Coding / Agentic Coding 升级为 Agentic Software Engineering。另外一个需要前置界定的关键概念是 Software Change在第二章精确定义以及它的工程实现核心 Software Change Record (SCR)在第八章精确定义。一、引言从 Code Change 到 Software Change 的范式转移1.1 现象AI 不再只是补全代码把 Vibe Coding 简单理解为AI 帮程序员写代码是危险的。这种理解会让团队把治理对象仍然停留在代码差异上而错过真正的变化。实际发生的变化是工作流的重组开发者仍然在环路里但位置变了——从写代码前移到判证据。这不是工作量的简单转移而是责任分布的重构。1.2 传统代码管理体系的承载边界传统代码管理体系Git Issue Tracker CI Code Review能够稳定承载的对象是 Code Change当 Agent 成为主要代码生产者时Intent、Context、Agent Action、Evidence 反而成了更值得管理的对象——而 Git 并没有为它们提供稳定位置。1.3 结论管理对象必须升级因此本文的立论点是Vibe Coding 的工程化不是给 AI 配一把 Git 权限而是承认软件工程的管理对象已经从 Code Change 扩展为 Software Change并围绕这一扩展对象重设计工作流。后续章节将围绕这一立论给出 Git、Commit、PR、AGENTS.md、Context、Skills、Agent Governance、Verification、SCR、闭环 SDLC 与五层框架的具体落地。二、Software Change 模型管理对象的精确定义2.1 Software Change 公式Software Change 是本文对象层的核心定义也是全文唯一的主模型各分量的含义与典型载体分量含义典型载体Intent这次变更要解决的问题、任务边界、验收标准Issue / ADR / PR Title / 用户故事ContextAgent 决策时所依赖的工程知识、规则、Skills、调用链AGENTS.md / Rules / Skills / ADR / 依赖图Agent ActionAgent 实际做了什么尝试过哪些方案、调用过哪些工具、为何放弃Agent Log / Trace / Replay / Iteration HistoryCode Change代码层面发生的实际差异Git Commit / Diff / BranchEvidence证明这次变更正确、安全、符合 Scope 的证据CI 报告 / 测试结果 / 安全扫描 / Architecture 校验 / Scope 检查 / Policy 检查 / Operational 信号Human Decision谁、在什么证据下、基于什么判断最终批准了这次变更PR Review / Approve / 审批记录这个公式回答的是管理什么的问题。后文所有治理机制都是为这六个分量服务的。2.2 Evidence 进一步拆分Change-time 与 Post-deploymentOperational Evidence 与其他五类 Evidence 有根本性的时间维度差异——其他五类都属于 Change-time Evidence而 Operational Evidence 是 Post-deployment Evidence这个拆分不是定义上的简化而是生命周期上的本质差异——Operational Evidence 只有在 Release 之后才能被收集因此它是闭环 SDLC 的反馈环节详见第九章。2.3 Software Change 与传统 SCM 的对照维度传统 SCMAI-Native Software Change Management管理对象Code ChangeSoftware Change六个分量主索引Commit HashSoftware Change Record IDSCR-ID证据CI Pass/FailRisk-adaptive Pre/Post-Change Evidence责任Author ReviewerAuthor Agent Reviewer Approver Operator追溯Diff → Commit → AuthorIntent → Context → Action → Diff → Evidence → Decision → Operator三、Git 的新位置从 Software Change 控制面退回到 Source Code Control Plane3.1 Git 在新范式中的精确位置Git 仍然是源代码版本与历史的核心权威系统但它的职责被精确化为 Source Code Control Plane而 Software Change 体系的其他层面需要在 Git 之外建立专门系统3.2 一个关键判断Git 不是被 AI 取代而是从 Software Change 的完整控制面退回到 Source Code Control Plane。这个判断成立的原因是Git 的核心契约不可变哈希、分布式历史、Diff 表达是 Code Provenance 的理想载体但 Git 从未也不应被设计用来承载 Intent、Context、Agent Action、Evidence、Approval 等语义。把这些语义强塞进 Commit Message 或 PR Description会让 Git 历史被污染。3.3 Git 与 Software Change Record 的边界正确的分工是Commit 只承载 SCR-ID 的引用不承载 SCR 的全部字段。这是 Git 与 SCR 之间的边界——Commit 保持简洁SCR 在独立系统中聚合所有证据详见第八章。四、Agentic Git Workflow把 Agent 纳入版本控制工作流4.1 Branch 策略的重设计传统 Git Flow / GitHub Flow 的核心假设是一个 PR 对应一个开发者的一次提交。Agentic 时代这一假设被打破需要明确的新规则每个 PR 必须可追溯回一个明确的 Intent——不允许Agent 自己发现了一个问题就提交。失败尝试不必出现在 Git 历史里但必须出现在 Agent Trace 平台避免 Git 噪声同时保留学习价值。Branch 命名必须编码 Intent 来源agent/issue-id-short-intent例如agent/1234-fix-oom-in-worker。Worktree 是 Agent 并行工作的关键基础设施——见下文 4.2。4.2 Worktree把 Agent 隔离在独立工作目录多个 Agent 同时修改同一仓库时必须用 Git Worktree 提供文件系统级隔离避免互相覆盖关键约束每个 Worktree 必须绑定一个明确的 Intent / Issue ID。Agent 在自己的 Worktree 中拥有受控编辑权限详见第六章 Capability Boundary但默认不允许直接 push 到main。Worktree 之间通过 PR 互相集成不允许直接合并。4.3 Commit 演进保持简洁仅承载 SCR 引用Commit 在新范式中承担双重身份代码版本快照Git 原生语义——通过 Diff 表达。Code Provenance 锚点工程层扩展——通过 Commit Message 与 SCR-ID 关联。保持简洁的设计原则Commit Message 不再承载 Intent、Context、Plan、Evidence、Approver 等详细字段——这些字段全部进入 SCR。Commit 与 SCR 之间通过Change-ID单一字段引用保持松耦合。这样设计的理由Git 历史保持可读——git log不被治理字段污染。SCR 可独立演化——调整 Evidence 维度、Approval 流程时不需要重写 Git 历史。审计与 Git 解耦——审计系统直接读 SCR不需要解析 Git 历史。4.4 Signed Commit 与 Agent 身份Agent 生成的 Commit 必须用 Agent 专用签名密钥签名内容应包含这把谁实际产生了这段代码明确写入 Git 历史本身成为 Code Provenance 的基础。4.5 Pull Request 控制点重设计从 Diff-centric 到 Context-awarePR 在新范式中的角色变化PR 不再只是代码差异的请求而是 Software Change 的控制点——所有进入主干分支的 Software Change 都必须经过 PR 集中校验。PR Description 的标准模板4.6 Reviewer 的新职责Reviewer 不再只看 Diff还必须检查Intent 是否清晰——这个 PR 解决了什么问题边界在哪Scope 是否合规——有没有超出 Issue 描述的改动Context 是否充分——Agent 是否使用了合适的 AGENTS.md / Rules / SkillsEvidence 是否可信——CI 通过 ≠ 安全合规Reviewer 必须看证据清单本身。Plan 是否合理——Agent 的实现路径是否过度复杂或过度简单这五条必须全部通过PR 才算代码正确 工程正确。Approve 策略是 Risk-dependent 的高风险或不可逆 Software Change 必须设置 Human Approval Gate详见 §6.7 的 HITL 场景白名单低风险变更如文档修正、依赖补丁、格式化、生成的代码、低风险配置变更可根据组织政策采用 Policy Engine 自动化 Evidence 自动化 Approve 的路径不强制要求人工 Approve。4.7 PR 自动化与人工的边界阶段自动化人工Lint / Format✅—Unit Test✅—Security Scan✅—Architecture Check✅—Scope Check✅抽查Policy Check✅抽查Diff 阅读—✅高风险必审低风险抽样Intent / Plan 判断—✅高风险必审低风险抽样风险与回滚评估辅助✅高风险必做最终 ApproveRisk-dependent低风险可经 Policy Engine 自动通过高风险 / 不可逆变更必须 HITL✅按 Approval Policy4.8 Scope Compliance把任务边界做成可验证对象Scope Compliance 是 AI 时代最重要的治理能力之一——其重要性甚至超过AI Code Review。Scope 的三层定义Scope Check 的实现路径检查项工具支持修改文件是否全部在 In-scope 声明的模块内git diff --name-only与白名单对比新增依赖是否在 In-scope 声明的依赖列表中package.json/requirements.txtDiff是否引入了 Out-of-scope 中禁止的模式静态规则 LLM-as-judgeAcceptance 标准是否全部覆盖Issue ↔ Test Case 矩阵是否破坏了非目标模块的测试全量测试回归关键原则Scope 不可由 Agent 单方面扩大。任何超出 Issue 描述的改动都必须由人类 Reviewer 显式批准或在 Issue 中显式扩展。未来 AI Coding 真正重要的治理能力可能不是AI 能写多少代码而是AI 能否严格控制自己不应该写什么。这可以发展成 Scope-Aware Agent 或 Scope Enforcement Layer——这是值得继续发展的方向。五、Context Engineering把工程知识从 Prompt 升级为持久化资产5.1 Context 的层次结构5.2 AGENTS.md 作为 Canonical Policy LayerAGENTS.md 是受治理 Repository 的组织级 Context / Policy 基线具体工具的 Rules 文件是 Tool-specific Execution Layer其实际优先级由工具自身规则定义。这是文章对AGENTS.md Rules Prompt那种一刀切优先级声明的修正。不同 Agent / IDE 对规则加载、优先级、作用域的实现机制并不相同因此组织级政策AGENTS.md应当只声明组织约束是什么而不越权规定工具内部加载顺序。AGENTS.md 应包含的标准结构5.3 工具级 Rules 的并列存在不同工具都有自己的 Rules 文件AGENTS.md 不强行指定其优先级工具级 Rules 应在语义上继承组织级 Policy不得与其冲突具体的继承、加载与优先级机制由各工具自身实现决定。5.4 Context-as-Code 的核心原则原则含义VersionedContext 必须纳入版本控制可回溯到任意 CommitComposableContext 必须可组合而非整体替换Deterministic同一份 Context 同一任务应当产生可复现的 Agent 行为Auditable任何 Context 变更必须有 PR ReviewerDiscoverableAgent 必须能自动发现相关 Context而非靠人记住5.5 Skill ≠ MCP ≠ Tool 的清晰分层许多文章把 Skill、MCP、Tool 串成Skill → Tool → MCP的纵向链。这是错误的——MCP 不是 Tool 的下一级而是与 Tool 并列的能力访问路径。准确的分层是各层回答的是不同问题层回答的问题实例Skill如何完成一个任务能力编排deploy-service / run-migration / query-db-schemaLocal Tool进程内具体执行什么操作run-shell / edit-file / http-requestMCP ServerAgent 如何访问一个外部能力跨进程 / 跨 Agent 的协议层GitHub MCP / Kubernetes MCP / SQL Server MCPSkill → Local Tool / MCP Server 是并列的两条能力访问路径而不是纵向层级Skill 可以直接调用进程内 Local ToolSkill 也可以通过 MCP 协议访问外部 MCP Server 上的 Tools / Resources。即 Skill 编排能力Tool 提供进程内执行能力MCP 提供跨 Agent / 外部系统的能力访问协议——三者之间是编排 ↔ 执行 ↔ 协议的三角关系而非单向链路。5.6 Context Loading 的工程化Agent 在执行任务前应按以下顺序加载 Context具体优先级由工具实现决定这种由稳到不稳的加载顺序保证 Agent 决策始终建立在最稳定的工程知识之上。5.7 Context Pollution 的治理Context 污染是 Context-as-Code 的头号风险症状AGENTS.md 被塞入过多临时规则Rules 文件膨胀Skills 描述模糊。治理定期审计每季度把临时规则清理或迁移到 ADR通过 Lint 检查 Rules 文件长度与重复度。六、Agent Governance四维边界模型6.1 为什么四级权限应降级为示例把 Agent 权限简化为 L1 / L2 / L3 / L4 四级虽然便于理解但在生产环境中过于简化——权限的真实形态是多维度的边界。因此本文把 四维 Boundary 模型提升为正式治理框架把 L1-L4 降级为参考示例。6.2 四维边界模型四维边界共同构成 Agent 的行动空间缺一不可6.3 四维边界的实例描述相比L2这种标签下面这种四维描述更精确6.4 L1-L4 作为参考示例如果组织需要更简洁的权限标签可把 L1-L4 作为对四维边界的常见组合的参考示例级别名称典型四维配置典型场景L1Read-OnlyContext: 全部 / Capability: 只读工具 / Execution: 仅查看 / Approval: 无探索代码、回答问题、生成 PlanL2Sandboxed-EditContext: 限定模块 / Capability: 文件编辑 测试 / Execution: 限定 Worktree / Approval: 无生成代码、跑测试、迭代修复L3Branch-AuthorContext: 限定模块 / Capability: 完整工具集 / Execution: 限定 Branch / Approval: PR Approve提交完整 Software Change 提案L4Production-PushContext: 全部 / Capability: 完整工具集 / Execution: 主干 / Approval: 强制人类 Approve仅授予受信任的 CI/CD Agent 或人类但必须强调真实生产环境的 Agent 权限配置应当用四维边界精确描述而不是套用 L1-L4 标签。L1-L4 只是常见组合的速记。6.5 最小授权原则每个 Agent 实例必须按完成任务所需的最小权限启动禁止一启动就全部放开的反模式。Agent 的边界放宽必须在 PR / Pipeline 中逐步获得而不是一次性赋予。6.6 权限审计所有超出 Read-Only 的动作必须产生不可篡改的审计记录谁触发了 AgentOperatorAgent 的四维边界配置执行了什么动作文件修改、命令执行、网络请求经过了哪些 Approve审计记录本身就是 Software Change Record 的一部分见第八章。6.7 HITL 与 HOTL人机协作的位置从写代码前移到判证据把人类放在哪决定了责任分布的形态。常见错误是把人类放在Prompt 输入口——人类写 Prompt、Agent 输出代码。这种模式责任真空正确做法是把人类放在 Evidence 判断口HITL 的硬约束场景不允许 HOTL合并到主干Production-Push生产部署密钥 / 凭证轮换数据库 schema 变更公共 API Breaking Change架构级重构涉及 ≥3 个模块合规相关变更隐私、审计、监管报告HOTL 的可行场景必须满足前置条件L1 / L2 级别操作在限定 Worktree 内已通过 CI / Lint / 测试的常规 Bug Fix有明确 ADR 与 Acceptance 标准的 Feature已有 Approve 模板的小型重构无论 HITL 还是 HOTL每一次 Approve人类或 Policy Engine 自动都应留下Approve 时间基于哪些 Evidence ID 做出判断Approver 身份人类 Operator ID / Policy Engine IDDecision-Rationale 自由文本自动化 Approve 可采用结构化理由这些字段进入 SCR构成完整的责任链。Decision-Rationale 在受监管场景可作为强制字段在其他场景作为增强型 Decision Provenance。七、VerificationRisk-adaptive 证据体系7.1 从必须六维齐全到 Risk-adaptive文章第一版曾提出任何 Production-Push 必须六维齐全。这一规则虽然便于执行但过度治理——例如修改一个 README 要求六维证据显然不合理。更合理的设计是 Risk-adaptive EvidenceEvidence 不是最大化的而是根据 Change Risk 自动确定的。7.2 Risk-adaptive Evidence 矩阵变更类型Required Pre-Change EvidenceRequired Post-Change Evidence文档 / 注释改动FunctionalLint 通过—内部重构Functional Architecture Scope—新增功能Functional Security Architecture ScopeOperational修改公共 APIFunctional Security Architecture Scope PolicyOperational生产配置变更Functional Security Architecture Scope PolicyOperational不同变更类型要求不同维度的证据。这把 Evidence 从硬门槛变成风险自适应门槛更符合真实工程实践。7.3 证据的不可伪造性无论 Risk-adaptive 矩阵如何变化所有 Evidence 必须满足可复现他人按相同流程可得到相同结论。可追溯每条证据有 ID可关联回 Commit / PR。可审计证据生成过程本身可审计如 CI 日志、SCA 报告、Architecture Check 输出。不可被 Agent 单方面篡改证据存储在受控系统CI、Security Platform、ADR RepoAgent 只能引用不能修改。7.4 Pre-Change 与 Post-Change Evidence 的生命周期区分Operational Evidence 的特殊性在于它不在 PR 阶段就存在而是在 Release 之后从生产环境回流。因此 Operational 不应作为 PR 合并的硬门槛而应作为后续变更决策的输入信号。7.5 证据缺失的处置任何必填维度的证据缺失或失败时Software Change 必须被阻止合并并由 Reviewer 判断补充证据最常见降低变更范围拆分 PR回退变更放弃本次 Change不存在补证据后合并的捷径——补证据本身要走 PR 流程。八、Software Change Record (SCR)Software Change 的可追溯实例8.1 SCR 的定位理论到工程的桥梁如果说 Software Change 公式回答的是管理什么对象层那么 Software Change Record (SCR) 回答的就是如何落地工程层。Software Change Record 是 Software Change 公式的可追溯实例是跨 Git、Issue、Agent Trace、CI、Security、Approval 的聚合对象。8.2 SCR 的标准字段8.3 SCR 的完整性约束SCR Integrity RequirementsSCR 本质上是跨系统聚合的 Provenance Record其完整性由一组必填字段约束保证——任何必填字段缺失都视为 SCR 不完整组织可按合规要求在约束之上增强如 Decision-Rationale注意SCR 完整性约束不是物理上不可拆分而是逻辑完整性要求——它在数据模型层以完整性检查体现而非数据库层面的不可变记录。8.4 SCR 的系统形态SCR 不是单一数据库记录而是一个跨系统聚合对象。它的数据分布在多个系统中由一个 SCR Aggregator 统一索引SCR Aggregator 在这一形态下实质上是 Software Change Event Aggregator——把分散在多个系统中的事件归并到同一索引下。8.5 SCR 的生命周期每个状态变更都必须记录操作者、时间、原因。任何状态跳跃都必须有明确理由。8.6 SCR 的回滚与撤销SCR 一旦 Merged 不应被直接修改或删除。回滚通过以下方式Revert SCR创建反向 SCR 引用原 SCR。Hotfix SCR紧急变更必须新建独立 SCR不允许补丁式修改历史。Revoked 标记原 SCR 可被显式标记 Revoked但记录本身必须保留。这与 Git 的不可变历史哲学一致但把不可变的语义从 Code 层扩展到 Software Change 层。8.7 Provenance 与合规在受监管行业金融、医疗、关键基础设施Decision Provenance 是合规底线谁授权了这次变更基于什么证据是否经过独立 ReviewerAI-Native Software Change Management 应将 Decision Provenance 的完整性纳入合规检查项作为事前要求而不是事后补救。SCR 中 Provenance-Manifest 字段是双向追溯的核心——它对 SCR 的所有关键字段计算哈希签名使任何篡改可被检测。8.8 双向追溯理想的 Provenance 体系应当支持双向追溯逆向追溯在事故回滚、合规审计、漏洞归因中尤其重要。具体的时间目标例如30 分钟内完成应当作为组织可配置目标而不是技术事实——不同组织对响应 SLA 的要求不同。九、AI-Native SDLC从需求到运维的端到端 Software Provenance9.1 传统 SDLC 的断裂传统软件开发生命周期SDLC在多个环节之间存在信息断裂9.2 闭环 SDLCSCR 串联全链条AI-Native 闭环 SDLC 用 SCR 串联全链条每个环节都向 SCR 添加字段9.3 闭环Operational Evidence 反哺下一轮变更闭环的关键是 Operational Evidence 反馈回 IntentOperational Evidence 不是 SDLC 的终点而是下一轮变更的起点。这把开发与运维从接力棒关系变成螺旋上升关系。9.4 与 GitOps 的结合闭环 SDLC 与 GitOps 天然契合Git Code Provenance 主存储SCR Software Change Provenance 主存储GitOps Controller Operational Evidence 来源三者共同把代码、变更、运行状态统一到 Git 工作流之上。十、VIBE CODING ENGINEERING 框架Intent / Context / Agent / Evidence / Change10.1 框架的精确位置VIBE CODING ENGINEERING 回答的是如何治理——它是 Software Change 公式的治理框架而不是另一个对象模型。三者形成层次清晰的三段映射10.2 五层框架10.3 各层的关键工程动作层关键工程动作落地载体IntentPlan-first / Scope-first / Issue 标准化Issue / ADR / 用户故事模板ContextAGENTS.md / Rules / Skills 持久化AGENTS.md / .cursor/rules / .github/copilot-instructions.md / Skills / ADRAgentWorktree 隔离 / 四维边界 / Skills / MCP.worktrees/ / 四维边界配置 / MCP ServersEvidenceRisk-adaptive 证据自动收集 / Pre/Post-Change 拆分CI / Security / Architecture / Scope / Policy / Operational 平台ChangeSCR / Provenance / 闭环 SDLCSCR Aggregator / 审计日志 / GitOps10.4 与四维 Agent Governance 的对应十一、MVP 实施路线11.1 收敛后的引入序列VIBE CODING ENGINEERING 不应一蹴而就落地。建议按以下 MVP 序列逐步引入每一步都是独立可交付、可回滚、可验证的11.2 各阶段的验证标准阶段验证标准不通过则回滚M0AGENTS.md 通过 PR 合并至少 1 名架构师 Review不合并M1100% 新建 Issue / PR 使用模板不合规 Issue / PR 退回M2所有 Agent 操作在 Worktree 内可被审计禁止 Agent 直接编辑主干M3Pre-Change Evidence 缺失的 PR 不可合并CI 强制卡点M4每个 PR 可关联到 SCR-ID未关联则提示补录M5生产事故可回溯到 SCR缺失则事故复盘不通过M6Standard 通过架构委员会 Approve未通过则不发布M7抽样逆向追溯在组织 SLA 内完成不达标则扩大归档覆盖11.3 常见反模式实施过程中应避免的反模式一上来就 L4 全开——边界放宽应逐步获得。AGENTS.md 写成大杂烩——临时规则必须迁移到 ADR。Commit 塞满 Evidence 字段——Commit 只承载 SCR 引用详细字段在 SCR 系统。必须六维齐全硬门槛——根据 Change Risk 自适应。Prompt 当工程知识——Context 必须版本化、可审计。SCR 只是 Issue 的别名——SCR 必须聚合跨系统证据。Operational Evidence 当成 PR 门槛——Operational 是 Post-Change 反馈不是合并卡点。结论三个层次的最终总结Vibe Coding 的工程化可以归纳为三个层次的转变层次一认知转变旧认知AI 帮程序员写代码新认知软件工程的生产方式发生系统性变化管理对象从 Code Change 升级为 Software Change层次二协议转变旧协议以 Git 为中心的代码管理体系新协议以 Git 为 Source Code Control Plane以 SCR 为 Software Change Provenance 主载体的多层体系层次三治理转变旧治理以 PR Review 为核心的人工把关新治理以 Risk-adaptive Evidence Decision Provenance 四维 Agent Governance HITL/HOTL 为核心的可审计闭环全文三个核心模型模型回答章节Software Change 公式管理什么第二章VIBE CODING ENGINEERING 五层框架如何治理第十章Software Change Record (SCR)如何落地第八章这三个模型共同构成文章的方法论核心。其他机制RBAC、Scope、MCP、Skills、AGENTS、Provenance、HITL、PR、Git都是这三个模型下面的工程实现。五个应被长期记住的核心观点① Code Change → Software Change——管理对象的升级是全文第一核心创新。② Git Source Code Control Plane——Git 不消失但退回到 Software Change 的子平面是第二核心判断。③ PR Context-aware Change Control Point——PR 从 Diff Review 升级为 Intent Scope Context Plan Diff Evidence Approval 的多维控制点是最现实的工程变化。④ Agent Governance 四维 Boundary——Context / Capability / Execution / Approval 四维模型比四级权限标签更精确是治理框架的核心。⑤ SCR Software Change 的可追溯实例——跨系统聚合对象作为审计、回滚、合规的依据是工程实现的核心。真正的演进主线如果只能记住一句话Vibe Coding 的工程化不是AI 帮程序员写代码而是把软件工程从代码仓库时代推向Software Change 工厂时代——围绕 Git 构建 AI-Native Software Change Management 体系使每一次变更都 Intent 清晰、Context 可控、Agent 可审、Evidence 可信、Decision 可追。这就是 Software Provenance 的真正含义不是这段代码从哪来而是这次变更为什么发生、怎么发生、如何被验证、谁最终负责。Software Provenance 将与 Code Provenance、Data Provenance、Model Provenance 共同构成下一代软件供应链的四大支柱。而这一切的起点是对 Vibe Coding 这一现象的工程化重设计。Vibe Coding 不会消失——它只会从演示效果演化为工程体系。工程师的核心工作也将从写代码转向判证据。这就是软件工程在 AI-Native 时代的真正开始。附录 A术语对照表术语含义层次Vibe Coding通过自然语言与代码生成模型或 Agent 交互的工作方式工作方式层Agentic CodingAI 具备自主规划、工具调用、迭代修复能力的编码模式工具范式层Agentic Software Engineering在 Agentic Coding 之上纳入治理体系的工程范式工程范式层Software ChangeIntent Context Agent Action Code Change Evidence Human Decision对象层Software Change Record (SCR)跨系统聚合 Software Change 证据的 Provenance Record满足 SCR 完整性约束工程层Software Provenance围绕 Software Change 的完整追溯链顶层目标Code Provenance代码从哪来Package → Repo → Commit → Author → LicenseGit 原生能力Decision Provenance变更为什么发生、谁批准、基于什么证据治理层能力Source Code Control PlaneGit 在新范式中的精确职责源代码版本与历史Git 重新定位AGENTS.md组织级 Canonical Policy Layer持久化 ContextContext-as-CodeContext Engineering 的工程化版本控制版本Context 治理SkillsAgent 的可复用能力描述能力层MCPModel Context Protocol外部能力协议层跨工具能力共享Tool具体执行的操作run-shell / edit-file / http-request执行层四维 Agent GovernanceContext / Capability / Execution / Approval 四个边界治理框架L1-L4 参考权限示例常见权限组合的速记标签非标准答案权限示例Verification First完成前必须先收集相应证据完成判定原则Pre-Change EvidenceFunctional / Security / Architecture / Scope / Policy合并前证据Post-Change EvidenceOperational合并后证据Risk-adaptive Evidence不同变更类型要求不同维度证据证据策略HITLHuman-in-the-loop同步介入高风险场景HOTLHuman-on-the-loop异步监督常规场景WorktreeGit WorktreeAgent 文件系统级隔离并行工作基础设施Scope Compliance把任务边界做成可机器验证的硬约束Scope 治理VIBE CODING ENGINEERINGIntent / Context / Agent / Evidence / Change 五层治理框架框架整合 AI-Native Software Engineering：氛围编程的工程化与 Software Change Management
目录摘要前置术语界定Vibe Coding / Agentic Coding / Agentic Software Engineering一、引言从 Code Change 到 Software Change 的范式转移二、Software Change 模型管理对象的精确定义三、Git 的新位置从 Software Change 控制面退回到 Source Code Control Plane四、Agentic Git Workflow把 Agent 纳入版本控制工作流五、Context Engineering把工程知识从 Prompt 升级为持久化资产六、Agent Governance四维边界模型七、VerificationRisk-adaptive 证据体系八、Software Change Record (SCR)Software Change 的可追溯实例九、AI-Native SDLC从需求到运维的端到端 Software Provenance十、VIBE CODING ENGINEERING 框架Intent / Context / Agent / Evidence / Change十一、MVP 实施路线结论摘要Vibe Coding 在 2025-2026 年迅速从AI 辅助写代码的工作方式扩展为对软件工程全链条的重组力量。本文给出的管理对象从 Code Change 升级为 Software Change的核心判断沿着 Git 工作流重设计这条具体主线逐节给出工程化落地形态在 对象层把 Software Change 精确定义为六个分量的复合对象对应为什么改 / 凭什么改 / 怎么改 / 改了什么 / 如何证明 / 谁批准。在 协议层保留 Git 作为 Source Code Control Plane 的核心地位但承认它只稳定承载 Software Change 中的 Code Change 子集其余分量由专门系统承载。在 工作流层把 Agent 纳入 Git 工作流——Plan-first、Worktree 隔离、Intent-branch、SCR 关联、Commit 保持简洁。在 Context 层把 AGENTS.md 作为组织级 Canonical Policy Layer把工具级 Rules.cursor/rules、.github/copilot-instructions.md、CLAUDE.md作为 Tool-specific Execution Layer。在 Governance 层用 Context / Capability / Execution / Approval 四维边界替代四级权限作为正式模型。在 Verification 层采用 Risk-adaptive 证据体系——不同变更类型要求不同维度证据避免必须六维齐全的过度治理。在 SCR 层把 Software Change Record 定义为跨系统聚合对象作为审计、回滚、合规的依据。在 闭环 SDLC 层从需求到运维实现端到端 Software Provenance。整篇文章的目标让 Vibe Coding 不再是AI 帮程序员写代码的浅层叙事而是 AI-Native Software Change Management 的工程化方法论。前置术语界定Vibe Coding / Agentic Coding / Agentic Software Engineering在进入正文之前必须先厘清三个常被混用的术语否则后续论证将建立在概念错位之上。三者不是严格的时间演化关系而是不同分析层次的概念术语分析层次含义关注重点Vibe Coding工作方式开发者主要通过自然语言与代码生成模型或 Agent 交互对话式编程、Context 管理、个人工作流Agentic Coding工具范式AI 具备自主规划、调用工具、迭代修复、跨文件编辑能力的编码模式Agent Loop、Tool Use、Plan/Act/ReplanAgentic Software Engineering工程范式在 Agentic Coding 之上把意图、上下文、证据、权限、责任纳入工程治理体系的完整范式Software Change、Provenance、Governance、HITL/HOTL三者是从开发者视角到工具能力视角再到工程治理视角的不同切片不是必然的演进阶段。一个组织可以同时具备三者开发者用 Vibe Coding 工作、Agent 具备 Agentic Coding 能力、组织运行在 Agentic Software Engineering 治理框架之上。后续章节讨论的全部内容都是围绕如何把 Vibe Coding / Agentic Coding 升级为 Agentic Software Engineering。另外一个需要前置界定的关键概念是 Software Change在第二章精确定义以及它的工程实现核心 Software Change Record (SCR)在第八章精确定义。一、引言从 Code Change 到 Software Change 的范式转移1.1 现象AI 不再只是补全代码把 Vibe Coding 简单理解为AI 帮程序员写代码是危险的。这种理解会让团队把治理对象仍然停留在代码差异上而错过真正的变化。实际发生的变化是工作流的重组开发者仍然在环路里但位置变了——从写代码前移到判证据。这不是工作量的简单转移而是责任分布的重构。1.2 传统代码管理体系的承载边界传统代码管理体系Git Issue Tracker CI Code Review能够稳定承载的对象是 Code Change当 Agent 成为主要代码生产者时Intent、Context、Agent Action、Evidence 反而成了更值得管理的对象——而 Git 并没有为它们提供稳定位置。1.3 结论管理对象必须升级因此本文的立论点是Vibe Coding 的工程化不是给 AI 配一把 Git 权限而是承认软件工程的管理对象已经从 Code Change 扩展为 Software Change并围绕这一扩展对象重设计工作流。后续章节将围绕这一立论给出 Git、Commit、PR、AGENTS.md、Context、Skills、Agent Governance、Verification、SCR、闭环 SDLC 与五层框架的具体落地。二、Software Change 模型管理对象的精确定义2.1 Software Change 公式Software Change 是本文对象层的核心定义也是全文唯一的主模型各分量的含义与典型载体分量含义典型载体Intent这次变更要解决的问题、任务边界、验收标准Issue / ADR / PR Title / 用户故事ContextAgent 决策时所依赖的工程知识、规则、Skills、调用链AGENTS.md / Rules / Skills / ADR / 依赖图Agent ActionAgent 实际做了什么尝试过哪些方案、调用过哪些工具、为何放弃Agent Log / Trace / Replay / Iteration HistoryCode Change代码层面发生的实际差异Git Commit / Diff / BranchEvidence证明这次变更正确、安全、符合 Scope 的证据CI 报告 / 测试结果 / 安全扫描 / Architecture 校验 / Scope 检查 / Policy 检查 / Operational 信号Human Decision谁、在什么证据下、基于什么判断最终批准了这次变更PR Review / Approve / 审批记录这个公式回答的是管理什么的问题。后文所有治理机制都是为这六个分量服务的。2.2 Evidence 进一步拆分Change-time 与 Post-deploymentOperational Evidence 与其他五类 Evidence 有根本性的时间维度差异——其他五类都属于 Change-time Evidence而 Operational Evidence 是 Post-deployment Evidence这个拆分不是定义上的简化而是生命周期上的本质差异——Operational Evidence 只有在 Release 之后才能被收集因此它是闭环 SDLC 的反馈环节详见第九章。2.3 Software Change 与传统 SCM 的对照维度传统 SCMAI-Native Software Change Management管理对象Code ChangeSoftware Change六个分量主索引Commit HashSoftware Change Record IDSCR-ID证据CI Pass/FailRisk-adaptive Pre/Post-Change Evidence责任Author ReviewerAuthor Agent Reviewer Approver Operator追溯Diff → Commit → AuthorIntent → Context → Action → Diff → Evidence → Decision → Operator三、Git 的新位置从 Software Change 控制面退回到 Source Code Control Plane3.1 Git 在新范式中的精确位置Git 仍然是源代码版本与历史的核心权威系统但它的职责被精确化为 Source Code Control Plane而 Software Change 体系的其他层面需要在 Git 之外建立专门系统3.2 一个关键判断Git 不是被 AI 取代而是从 Software Change 的完整控制面退回到 Source Code Control Plane。这个判断成立的原因是Git 的核心契约不可变哈希、分布式历史、Diff 表达是 Code Provenance 的理想载体但 Git 从未也不应被设计用来承载 Intent、Context、Agent Action、Evidence、Approval 等语义。把这些语义强塞进 Commit Message 或 PR Description会让 Git 历史被污染。3.3 Git 与 Software Change Record 的边界正确的分工是Commit 只承载 SCR-ID 的引用不承载 SCR 的全部字段。这是 Git 与 SCR 之间的边界——Commit 保持简洁SCR 在独立系统中聚合所有证据详见第八章。四、Agentic Git Workflow把 Agent 纳入版本控制工作流4.1 Branch 策略的重设计传统 Git Flow / GitHub Flow 的核心假设是一个 PR 对应一个开发者的一次提交。Agentic 时代这一假设被打破需要明确的新规则每个 PR 必须可追溯回一个明确的 Intent——不允许Agent 自己发现了一个问题就提交。失败尝试不必出现在 Git 历史里但必须出现在 Agent Trace 平台避免 Git 噪声同时保留学习价值。Branch 命名必须编码 Intent 来源agent/issue-id-short-intent例如agent/1234-fix-oom-in-worker。Worktree 是 Agent 并行工作的关键基础设施——见下文 4.2。4.2 Worktree把 Agent 隔离在独立工作目录多个 Agent 同时修改同一仓库时必须用 Git Worktree 提供文件系统级隔离避免互相覆盖关键约束每个 Worktree 必须绑定一个明确的 Intent / Issue ID。Agent 在自己的 Worktree 中拥有受控编辑权限详见第六章 Capability Boundary但默认不允许直接 push 到main。Worktree 之间通过 PR 互相集成不允许直接合并。4.3 Commit 演进保持简洁仅承载 SCR 引用Commit 在新范式中承担双重身份代码版本快照Git 原生语义——通过 Diff 表达。Code Provenance 锚点工程层扩展——通过 Commit Message 与 SCR-ID 关联。保持简洁的设计原则Commit Message 不再承载 Intent、Context、Plan、Evidence、Approver 等详细字段——这些字段全部进入 SCR。Commit 与 SCR 之间通过Change-ID单一字段引用保持松耦合。这样设计的理由Git 历史保持可读——git log不被治理字段污染。SCR 可独立演化——调整 Evidence 维度、Approval 流程时不需要重写 Git 历史。审计与 Git 解耦——审计系统直接读 SCR不需要解析 Git 历史。4.4 Signed Commit 与 Agent 身份Agent 生成的 Commit 必须用 Agent 专用签名密钥签名内容应包含这把谁实际产生了这段代码明确写入 Git 历史本身成为 Code Provenance 的基础。4.5 Pull Request 控制点重设计从 Diff-centric 到 Context-awarePR 在新范式中的角色变化PR 不再只是代码差异的请求而是 Software Change 的控制点——所有进入主干分支的 Software Change 都必须经过 PR 集中校验。PR Description 的标准模板4.6 Reviewer 的新职责Reviewer 不再只看 Diff还必须检查Intent 是否清晰——这个 PR 解决了什么问题边界在哪Scope 是否合规——有没有超出 Issue 描述的改动Context 是否充分——Agent 是否使用了合适的 AGENTS.md / Rules / SkillsEvidence 是否可信——CI 通过 ≠ 安全合规Reviewer 必须看证据清单本身。Plan 是否合理——Agent 的实现路径是否过度复杂或过度简单这五条必须全部通过PR 才算代码正确 工程正确。Approve 策略是 Risk-dependent 的高风险或不可逆 Software Change 必须设置 Human Approval Gate详见 §6.7 的 HITL 场景白名单低风险变更如文档修正、依赖补丁、格式化、生成的代码、低风险配置变更可根据组织政策采用 Policy Engine 自动化 Evidence 自动化 Approve 的路径不强制要求人工 Approve。4.7 PR 自动化与人工的边界阶段自动化人工Lint / Format✅—Unit Test✅—Security Scan✅—Architecture Check✅—Scope Check✅抽查Policy Check✅抽查Diff 阅读—✅高风险必审低风险抽样Intent / Plan 判断—✅高风险必审低风险抽样风险与回滚评估辅助✅高风险必做最终 ApproveRisk-dependent低风险可经 Policy Engine 自动通过高风险 / 不可逆变更必须 HITL✅按 Approval Policy4.8 Scope Compliance把任务边界做成可验证对象Scope Compliance 是 AI 时代最重要的治理能力之一——其重要性甚至超过AI Code Review。Scope 的三层定义Scope Check 的实现路径检查项工具支持修改文件是否全部在 In-scope 声明的模块内git diff --name-only与白名单对比新增依赖是否在 In-scope 声明的依赖列表中package.json/requirements.txtDiff是否引入了 Out-of-scope 中禁止的模式静态规则 LLM-as-judgeAcceptance 标准是否全部覆盖Issue ↔ Test Case 矩阵是否破坏了非目标模块的测试全量测试回归关键原则Scope 不可由 Agent 单方面扩大。任何超出 Issue 描述的改动都必须由人类 Reviewer 显式批准或在 Issue 中显式扩展。未来 AI Coding 真正重要的治理能力可能不是AI 能写多少代码而是AI 能否严格控制自己不应该写什么。这可以发展成 Scope-Aware Agent 或 Scope Enforcement Layer——这是值得继续发展的方向。五、Context Engineering把工程知识从 Prompt 升级为持久化资产5.1 Context 的层次结构5.2 AGENTS.md 作为 Canonical Policy LayerAGENTS.md 是受治理 Repository 的组织级 Context / Policy 基线具体工具的 Rules 文件是 Tool-specific Execution Layer其实际优先级由工具自身规则定义。这是文章对AGENTS.md Rules Prompt那种一刀切优先级声明的修正。不同 Agent / IDE 对规则加载、优先级、作用域的实现机制并不相同因此组织级政策AGENTS.md应当只声明组织约束是什么而不越权规定工具内部加载顺序。AGENTS.md 应包含的标准结构5.3 工具级 Rules 的并列存在不同工具都有自己的 Rules 文件AGENTS.md 不强行指定其优先级工具级 Rules 应在语义上继承组织级 Policy不得与其冲突具体的继承、加载与优先级机制由各工具自身实现决定。5.4 Context-as-Code 的核心原则原则含义VersionedContext 必须纳入版本控制可回溯到任意 CommitComposableContext 必须可组合而非整体替换Deterministic同一份 Context 同一任务应当产生可复现的 Agent 行为Auditable任何 Context 变更必须有 PR ReviewerDiscoverableAgent 必须能自动发现相关 Context而非靠人记住5.5 Skill ≠ MCP ≠ Tool 的清晰分层许多文章把 Skill、MCP、Tool 串成Skill → Tool → MCP的纵向链。这是错误的——MCP 不是 Tool 的下一级而是与 Tool 并列的能力访问路径。准确的分层是各层回答的是不同问题层回答的问题实例Skill如何完成一个任务能力编排deploy-service / run-migration / query-db-schemaLocal Tool进程内具体执行什么操作run-shell / edit-file / http-requestMCP ServerAgent 如何访问一个外部能力跨进程 / 跨 Agent 的协议层GitHub MCP / Kubernetes MCP / SQL Server MCPSkill → Local Tool / MCP Server 是并列的两条能力访问路径而不是纵向层级Skill 可以直接调用进程内 Local ToolSkill 也可以通过 MCP 协议访问外部 MCP Server 上的 Tools / Resources。即 Skill 编排能力Tool 提供进程内执行能力MCP 提供跨 Agent / 外部系统的能力访问协议——三者之间是编排 ↔ 执行 ↔ 协议的三角关系而非单向链路。5.6 Context Loading 的工程化Agent 在执行任务前应按以下顺序加载 Context具体优先级由工具实现决定这种由稳到不稳的加载顺序保证 Agent 决策始终建立在最稳定的工程知识之上。5.7 Context Pollution 的治理Context 污染是 Context-as-Code 的头号风险症状AGENTS.md 被塞入过多临时规则Rules 文件膨胀Skills 描述模糊。治理定期审计每季度把临时规则清理或迁移到 ADR通过 Lint 检查 Rules 文件长度与重复度。六、Agent Governance四维边界模型6.1 为什么四级权限应降级为示例把 Agent 权限简化为 L1 / L2 / L3 / L4 四级虽然便于理解但在生产环境中过于简化——权限的真实形态是多维度的边界。因此本文把 四维 Boundary 模型提升为正式治理框架把 L1-L4 降级为参考示例。6.2 四维边界模型四维边界共同构成 Agent 的行动空间缺一不可6.3 四维边界的实例描述相比L2这种标签下面这种四维描述更精确6.4 L1-L4 作为参考示例如果组织需要更简洁的权限标签可把 L1-L4 作为对四维边界的常见组合的参考示例级别名称典型四维配置典型场景L1Read-OnlyContext: 全部 / Capability: 只读工具 / Execution: 仅查看 / Approval: 无探索代码、回答问题、生成 PlanL2Sandboxed-EditContext: 限定模块 / Capability: 文件编辑 测试 / Execution: 限定 Worktree / Approval: 无生成代码、跑测试、迭代修复L3Branch-AuthorContext: 限定模块 / Capability: 完整工具集 / Execution: 限定 Branch / Approval: PR Approve提交完整 Software Change 提案L4Production-PushContext: 全部 / Capability: 完整工具集 / Execution: 主干 / Approval: 强制人类 Approve仅授予受信任的 CI/CD Agent 或人类但必须强调真实生产环境的 Agent 权限配置应当用四维边界精确描述而不是套用 L1-L4 标签。L1-L4 只是常见组合的速记。6.5 最小授权原则每个 Agent 实例必须按完成任务所需的最小权限启动禁止一启动就全部放开的反模式。Agent 的边界放宽必须在 PR / Pipeline 中逐步获得而不是一次性赋予。6.6 权限审计所有超出 Read-Only 的动作必须产生不可篡改的审计记录谁触发了 AgentOperatorAgent 的四维边界配置执行了什么动作文件修改、命令执行、网络请求经过了哪些 Approve审计记录本身就是 Software Change Record 的一部分见第八章。6.7 HITL 与 HOTL人机协作的位置从写代码前移到判证据把人类放在哪决定了责任分布的形态。常见错误是把人类放在Prompt 输入口——人类写 Prompt、Agent 输出代码。这种模式责任真空正确做法是把人类放在 Evidence 判断口HITL 的硬约束场景不允许 HOTL合并到主干Production-Push生产部署密钥 / 凭证轮换数据库 schema 变更公共 API Breaking Change架构级重构涉及 ≥3 个模块合规相关变更隐私、审计、监管报告HOTL 的可行场景必须满足前置条件L1 / L2 级别操作在限定 Worktree 内已通过 CI / Lint / 测试的常规 Bug Fix有明确 ADR 与 Acceptance 标准的 Feature已有 Approve 模板的小型重构无论 HITL 还是 HOTL每一次 Approve人类或 Policy Engine 自动都应留下Approve 时间基于哪些 Evidence ID 做出判断Approver 身份人类 Operator ID / Policy Engine IDDecision-Rationale 自由文本自动化 Approve 可采用结构化理由这些字段进入 SCR构成完整的责任链。Decision-Rationale 在受监管场景可作为强制字段在其他场景作为增强型 Decision Provenance。七、VerificationRisk-adaptive 证据体系7.1 从必须六维齐全到 Risk-adaptive文章第一版曾提出任何 Production-Push 必须六维齐全。这一规则虽然便于执行但过度治理——例如修改一个 README 要求六维证据显然不合理。更合理的设计是 Risk-adaptive EvidenceEvidence 不是最大化的而是根据 Change Risk 自动确定的。7.2 Risk-adaptive Evidence 矩阵变更类型Required Pre-Change EvidenceRequired Post-Change Evidence文档 / 注释改动FunctionalLint 通过—内部重构Functional Architecture Scope—新增功能Functional Security Architecture ScopeOperational修改公共 APIFunctional Security Architecture Scope PolicyOperational生产配置变更Functional Security Architecture Scope PolicyOperational不同变更类型要求不同维度的证据。这把 Evidence 从硬门槛变成风险自适应门槛更符合真实工程实践。7.3 证据的不可伪造性无论 Risk-adaptive 矩阵如何变化所有 Evidence 必须满足可复现他人按相同流程可得到相同结论。可追溯每条证据有 ID可关联回 Commit / PR。可审计证据生成过程本身可审计如 CI 日志、SCA 报告、Architecture Check 输出。不可被 Agent 单方面篡改证据存储在受控系统CI、Security Platform、ADR RepoAgent 只能引用不能修改。7.4 Pre-Change 与 Post-Change Evidence 的生命周期区分Operational Evidence 的特殊性在于它不在 PR 阶段就存在而是在 Release 之后从生产环境回流。因此 Operational 不应作为 PR 合并的硬门槛而应作为后续变更决策的输入信号。7.5 证据缺失的处置任何必填维度的证据缺失或失败时Software Change 必须被阻止合并并由 Reviewer 判断补充证据最常见降低变更范围拆分 PR回退变更放弃本次 Change不存在补证据后合并的捷径——补证据本身要走 PR 流程。八、Software Change Record (SCR)Software Change 的可追溯实例8.1 SCR 的定位理论到工程的桥梁如果说 Software Change 公式回答的是管理什么对象层那么 Software Change Record (SCR) 回答的就是如何落地工程层。Software Change Record 是 Software Change 公式的可追溯实例是跨 Git、Issue、Agent Trace、CI、Security、Approval 的聚合对象。8.2 SCR 的标准字段8.3 SCR 的完整性约束SCR Integrity RequirementsSCR 本质上是跨系统聚合的 Provenance Record其完整性由一组必填字段约束保证——任何必填字段缺失都视为 SCR 不完整组织可按合规要求在约束之上增强如 Decision-Rationale注意SCR 完整性约束不是物理上不可拆分而是逻辑完整性要求——它在数据模型层以完整性检查体现而非数据库层面的不可变记录。8.4 SCR 的系统形态SCR 不是单一数据库记录而是一个跨系统聚合对象。它的数据分布在多个系统中由一个 SCR Aggregator 统一索引SCR Aggregator 在这一形态下实质上是 Software Change Event Aggregator——把分散在多个系统中的事件归并到同一索引下。8.5 SCR 的生命周期每个状态变更都必须记录操作者、时间、原因。任何状态跳跃都必须有明确理由。8.6 SCR 的回滚与撤销SCR 一旦 Merged 不应被直接修改或删除。回滚通过以下方式Revert SCR创建反向 SCR 引用原 SCR。Hotfix SCR紧急变更必须新建独立 SCR不允许补丁式修改历史。Revoked 标记原 SCR 可被显式标记 Revoked但记录本身必须保留。这与 Git 的不可变历史哲学一致但把不可变的语义从 Code 层扩展到 Software Change 层。8.7 Provenance 与合规在受监管行业金融、医疗、关键基础设施Decision Provenance 是合规底线谁授权了这次变更基于什么证据是否经过独立 ReviewerAI-Native Software Change Management 应将 Decision Provenance 的完整性纳入合规检查项作为事前要求而不是事后补救。SCR 中 Provenance-Manifest 字段是双向追溯的核心——它对 SCR 的所有关键字段计算哈希签名使任何篡改可被检测。8.8 双向追溯理想的 Provenance 体系应当支持双向追溯逆向追溯在事故回滚、合规审计、漏洞归因中尤其重要。具体的时间目标例如30 分钟内完成应当作为组织可配置目标而不是技术事实——不同组织对响应 SLA 的要求不同。九、AI-Native SDLC从需求到运维的端到端 Software Provenance9.1 传统 SDLC 的断裂传统软件开发生命周期SDLC在多个环节之间存在信息断裂9.2 闭环 SDLCSCR 串联全链条AI-Native 闭环 SDLC 用 SCR 串联全链条每个环节都向 SCR 添加字段9.3 闭环Operational Evidence 反哺下一轮变更闭环的关键是 Operational Evidence 反馈回 IntentOperational Evidence 不是 SDLC 的终点而是下一轮变更的起点。这把开发与运维从接力棒关系变成螺旋上升关系。9.4 与 GitOps 的结合闭环 SDLC 与 GitOps 天然契合Git Code Provenance 主存储SCR Software Change Provenance 主存储GitOps Controller Operational Evidence 来源三者共同把代码、变更、运行状态统一到 Git 工作流之上。十、VIBE CODING ENGINEERING 框架Intent / Context / Agent / Evidence / Change10.1 框架的精确位置VIBE CODING ENGINEERING 回答的是如何治理——它是 Software Change 公式的治理框架而不是另一个对象模型。三者形成层次清晰的三段映射10.2 五层框架10.3 各层的关键工程动作层关键工程动作落地载体IntentPlan-first / Scope-first / Issue 标准化Issue / ADR / 用户故事模板ContextAGENTS.md / Rules / Skills 持久化AGENTS.md / .cursor/rules / .github/copilot-instructions.md / Skills / ADRAgentWorktree 隔离 / 四维边界 / Skills / MCP.worktrees/ / 四维边界配置 / MCP ServersEvidenceRisk-adaptive 证据自动收集 / Pre/Post-Change 拆分CI / Security / Architecture / Scope / Policy / Operational 平台ChangeSCR / Provenance / 闭环 SDLCSCR Aggregator / 审计日志 / GitOps10.4 与四维 Agent Governance 的对应十一、MVP 实施路线11.1 收敛后的引入序列VIBE CODING ENGINEERING 不应一蹴而就落地。建议按以下 MVP 序列逐步引入每一步都是独立可交付、可回滚、可验证的11.2 各阶段的验证标准阶段验证标准不通过则回滚M0AGENTS.md 通过 PR 合并至少 1 名架构师 Review不合并M1100% 新建 Issue / PR 使用模板不合规 Issue / PR 退回M2所有 Agent 操作在 Worktree 内可被审计禁止 Agent 直接编辑主干M3Pre-Change Evidence 缺失的 PR 不可合并CI 强制卡点M4每个 PR 可关联到 SCR-ID未关联则提示补录M5生产事故可回溯到 SCR缺失则事故复盘不通过M6Standard 通过架构委员会 Approve未通过则不发布M7抽样逆向追溯在组织 SLA 内完成不达标则扩大归档覆盖11.3 常见反模式实施过程中应避免的反模式一上来就 L4 全开——边界放宽应逐步获得。AGENTS.md 写成大杂烩——临时规则必须迁移到 ADR。Commit 塞满 Evidence 字段——Commit 只承载 SCR 引用详细字段在 SCR 系统。必须六维齐全硬门槛——根据 Change Risk 自适应。Prompt 当工程知识——Context 必须版本化、可审计。SCR 只是 Issue 的别名——SCR 必须聚合跨系统证据。Operational Evidence 当成 PR 门槛——Operational 是 Post-Change 反馈不是合并卡点。结论三个层次的最终总结Vibe Coding 的工程化可以归纳为三个层次的转变层次一认知转变旧认知AI 帮程序员写代码新认知软件工程的生产方式发生系统性变化管理对象从 Code Change 升级为 Software Change层次二协议转变旧协议以 Git 为中心的代码管理体系新协议以 Git 为 Source Code Control Plane以 SCR 为 Software Change Provenance 主载体的多层体系层次三治理转变旧治理以 PR Review 为核心的人工把关新治理以 Risk-adaptive Evidence Decision Provenance 四维 Agent Governance HITL/HOTL 为核心的可审计闭环全文三个核心模型模型回答章节Software Change 公式管理什么第二章VIBE CODING ENGINEERING 五层框架如何治理第十章Software Change Record (SCR)如何落地第八章这三个模型共同构成文章的方法论核心。其他机制RBAC、Scope、MCP、Skills、AGENTS、Provenance、HITL、PR、Git都是这三个模型下面的工程实现。五个应被长期记住的核心观点① Code Change → Software Change——管理对象的升级是全文第一核心创新。② Git Source Code Control Plane——Git 不消失但退回到 Software Change 的子平面是第二核心判断。③ PR Context-aware Change Control Point——PR 从 Diff Review 升级为 Intent Scope Context Plan Diff Evidence Approval 的多维控制点是最现实的工程变化。④ Agent Governance 四维 Boundary——Context / Capability / Execution / Approval 四维模型比四级权限标签更精确是治理框架的核心。⑤ SCR Software Change 的可追溯实例——跨系统聚合对象作为审计、回滚、合规的依据是工程实现的核心。真正的演进主线如果只能记住一句话Vibe Coding 的工程化不是AI 帮程序员写代码而是把软件工程从代码仓库时代推向Software Change 工厂时代——围绕 Git 构建 AI-Native Software Change Management 体系使每一次变更都 Intent 清晰、Context 可控、Agent 可审、Evidence 可信、Decision 可追。这就是 Software Provenance 的真正含义不是这段代码从哪来而是这次变更为什么发生、怎么发生、如何被验证、谁最终负责。Software Provenance 将与 Code Provenance、Data Provenance、Model Provenance 共同构成下一代软件供应链的四大支柱。而这一切的起点是对 Vibe Coding 这一现象的工程化重设计。Vibe Coding 不会消失——它只会从演示效果演化为工程体系。工程师的核心工作也将从写代码转向判证据。这就是软件工程在 AI-Native 时代的真正开始。附录 A术语对照表术语含义层次Vibe Coding通过自然语言与代码生成模型或 Agent 交互的工作方式工作方式层Agentic CodingAI 具备自主规划、工具调用、迭代修复能力的编码模式工具范式层Agentic Software Engineering在 Agentic Coding 之上纳入治理体系的工程范式工程范式层Software ChangeIntent Context Agent Action Code Change Evidence Human Decision对象层Software Change Record (SCR)跨系统聚合 Software Change 证据的 Provenance Record满足 SCR 完整性约束工程层Software Provenance围绕 Software Change 的完整追溯链顶层目标Code Provenance代码从哪来Package → Repo → Commit → Author → LicenseGit 原生能力Decision Provenance变更为什么发生、谁批准、基于什么证据治理层能力Source Code Control PlaneGit 在新范式中的精确职责源代码版本与历史Git 重新定位AGENTS.md组织级 Canonical Policy Layer持久化 ContextContext-as-CodeContext Engineering 的工程化版本控制版本Context 治理SkillsAgent 的可复用能力描述能力层MCPModel Context Protocol外部能力协议层跨工具能力共享Tool具体执行的操作run-shell / edit-file / http-request执行层四维 Agent GovernanceContext / Capability / Execution / Approval 四个边界治理框架L1-L4 参考权限示例常见权限组合的速记标签非标准答案权限示例Verification First完成前必须先收集相应证据完成判定原则Pre-Change EvidenceFunctional / Security / Architecture / Scope / Policy合并前证据Post-Change EvidenceOperational合并后证据Risk-adaptive Evidence不同变更类型要求不同维度证据证据策略HITLHuman-in-the-loop同步介入高风险场景HOTLHuman-on-the-loop异步监督常规场景WorktreeGit WorktreeAgent 文件系统级隔离并行工作基础设施Scope Compliance把任务边界做成可机器验证的硬约束Scope 治理VIBE CODING ENGINEERINGIntent / Context / Agent / Evidence / Change 五层治理框架框架整合