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