Update nexus wiki content

wiki/sources/engineering-minimal-change-engineer.md

@@ -0,0 +1,51 @@
+---
+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 应独立于原型工作，原型阶段允许快速迭代，最终生产代码遵循最小变更原则
+  - 对方观点：快速原型阶段不应受最小变更约束，需快速验证后再重构