工程师在 AI 时代的新职责
约 698 字大约 2 分钟
2026-06-01
AI 时代的工程师不是从“写代码的人”变成“写 prompt 的人”。更准确地说，工程师要对目标、上下文、执行边界、验证和长期知识负责。
代码仍然重要，但工程师的杠杆位置变了。
职责变化
| 过去更常见的职责 | AI 增强后的职责 |
|---|---|
| 亲手实现大部分代码 | 判断哪些部分适合交给 AI，哪些必须人工控制 |
| 在脑中记住项目上下文 | 把关键上下文整理成规则、spec、memory 和文档 |
| 写完后自测 | 设计验证路径，并检查 AI 是否真的运行和理解结果 |
| 做代码 review | 同时 review 目标、范围、工具调用、diff 和验证证据 |
| 解决当前问题 | 把高价值经验沉淀为 solution、skill 或模板 |
新的能力模型
| 能力 | 具体表现 |
|---|---|
| 目标定义 | 能把模糊需求转成目标、非目标、验收标准和风险。 |
| 上下文组织 | 能告诉 AI 读哪些文件、遵守哪些规则、忽略哪些噪声。 |
| 任务拆分 | 能把大任务切成可观察、可回滚、可验证的小步骤。 |
| 执行监督 | 能看懂工具调用、命令输出、diff 和失败原因。 |
| 验证设计 | 能选择合适的测试、构建、截图、人工检查或 review。 |
| 风险判断 | 能识别权限、数据、安全、性能、可维护性和范围漂移。 |
| 知识沉淀 | 能把反复出现的问题沉淀为 memory、skill 或 solution docs。 |
不该外包给 AI 的判断
AI 可以提供建议，但以下判断仍应由人负责：
- 是否符合产品目标。
- 是否接受某个安全或数据风险。
- 是否改变长期架构方向。
- 是否牺牲可维护性换短期速度。
- 是否把经验提升为团队规则。
这些判断通常依赖组织目标、用户理解、长期成本和责任边界，不是模型单靠当前上下文就能决定的。
工作方式变化
写代码
-> 定义目标
-> 组织上下文
-> 约束执行
-> 审查结果
-> 沉淀知识这不是降低工程师价值，而是把工程师从低层重复执行中推到更靠近判断和系统设计的位置。
能力进阶
Agent、Memory、Skill、MCP、Tool 和 Hook 支撑目标定义、上下文组织、执行监督和验证设计，不是零散概念，也不是高级玩法。
OpenSpec 和 Compound 分别把事实源与工程复利落到团队协作中，帮助工程师把新职责变成可执行、可审查、可复用的工作方式。
