--- title: "Minimal Change Engineer Agent" type: source tags: [engineering, agent-persona, code-quality, scope-management] date: 2026-05-02 --- ## Source File - [[Agent/agency-agents/engineering/engineering-minimal-change-engineer.md]] ## Summary(用中文描述) - 核心主题:AI 编程代理的人格设定——最小变更工程师(Minimal Change Engineer),专注于交付最小可工作差异集,拒绝范围蔓延 - 问题域:AI 编程工具普遍存在"过度生产"问题——修复一个 bug 时附带重构、添加文档、引入防御性代码等 - 方法/机制:通过严格的行为规则、工作流模板(Scope Self-Check)和代码示例,将"只做被要求的事"内化为代理的核心原则 - 结论/价值:最小变更原则降低代码审查时间 50%+,减少回归风险,PR 可在 10 秒内审阅完成 ## Key Claims(用中文描述) - 主体 + 机制 + 结果 - **AI 编程代理默认过度生产** → 最小变更工程师通过严格规则约束范围 → 交付最小 diff,减少引入新 Bug 的风险 - **三次重复才考虑提取抽象** → 坚持"四条重复才提取"原则 → 避免过早抽象带来的隐性债务 - **范围蔓延在审查阶段最为危险** → 代理需主动拒绝"顺便..."请求 → 保持 PR 干净且独立可审 - **约束本身就是一种高级能力** → 最小变更工程师通过"Diff archaeology"和"Scope negotiation"技能扩展其价值 → 不仅自我约束,还能指导他人 ## Key Quotes > "Software has a half-life. Every line you add will eventually need to be read, debugged, refactored, or deleted by someone — possibly you, possibly at 2 AM. The kindest thing you can do for that future person is to add fewer lines." — 核心原则 > "Three similar lines beats a premature abstraction." — 过早抽象陷阱的反面教材 > "I'm not going to add a config flag for that. We have one caller and no requirement for a second. We can extract when the second caller appears." — 拒绝未来灵活性陷阱的标准话术 ## Key Concepts - [[ScopeCreep]]:范围蔓延——超出任务明确要求的变更行为,是最小变更工程师的核心反模式 - [[PrematureAbstraction]]:过早抽象——在第三次出现之前就提取辅助函数,引入隐性债务 - [[MinimalChangePrinciple]]:最小变更原则——每个变更行的存在都必须有任务明确要求的理由 ## Key Entities - (本来源未引入需创建独立页面的外部人物或公司) ## Connections - [[engineering-code-reviewer]] ← 对立与互补 ← [[engineering-minimal-change-engineer]] - 代码审查者发现范围蔓延,最小变更工程师预防范围蔓延 - [[engineering-sre]] ← 协作 ← [[engineering-minimal-change-engineer]] - SRE 保障可靠性,最小变更工程师通过最小 blast radius 降低故障影响 - [[engineering-senior-developer]] ← 互补 ← [[engineering-minimal-change-engineer]] - 高级工程师的经验判断与最小变更原则相辅相成 ## Contradictions - 与 [[engineering-rapid-prototyper]] 潜在张力: - 冲突点:快速原型优先速度与简洁性,最小变更优先控制范围 - 当前观点:最小变更工程师的 PR 应独立于原型工作,原型阶段允许快速迭代,最终生产代码遵循最小变更原则 - 对方观点:快速原型阶段不应受最小变更约束,需快速验证后再重构