3.4 KiB
3.4 KiB
title, type, tags, date
| title | type | tags | date | ||||
|---|---|---|---|---|---|---|---|
| Minimal Change Engineer Agent | source |
|
2026-05-02 |
Source File
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 应独立于原型工作，原型阶段允许快速迭代，最终生产代码遵循最小变更原则
- 对方观点：快速原型阶段不应受最小变更约束，需快速验证后再重构