AI 时代工程师能力转型
核心主题：AI 时代，“写代码”的本质正在从亲手输入语法，转向定义问题、编排 Agent、评估质量和设计系统。
1. 一句话结论
工程师的核心价值正在从“代码生产者”升级为“系统设计者 + Agent 管理者 + 质量负责人”。
过去厉害的工程师，主要体现为：
- 写得快。
- 语法熟。
- API 记得多。
- 能独立实现复杂功能。
AI Agent 时代厉害的工程师，主要体现为：
- 知道要构建什么。
- 能把模糊目标拆成清晰任务。
- 能指挥多个 Agent 并行工作。
- 能判断 AI 生成的代码是否可靠。
- 能建立测试、Review、CI、发布和回滚的验证体系。
2. 原文核心信息
| 主题 | 关键内容 | 对我的启发 |
|---|---|---|
| AI 代码比例变化 | Cursor 企业客户中，一年前约 85% 代码由人类写，现在约 75% 代码由 AI 生成 | 亲手写语法不再是唯一核心竞争力 |
| 开发模式变化 | 从手工写代码，到 Copilot 补全，再到 Agent 端到端完成任务 | 我要从使用 AI 补全，升级到管理 AI 完成任务 |
| Cursor 内部数据 | Cursor 内部已有约 30% PR 由 Agent 从头到尾独立完成 | Agent 已经能承担完整工程任务，不只是生成片段 |
| Agent 请求增长 | Agent 请求在一年内增长超过 15 倍，并超过 Tab 补全 | 工作重心从补全几行代码，转向委派整块工作 |
| Agent Teams 实验 | Agent 团队一周生成 300 万行代码，从零做出浏览器原型 | 多 Agent 并行会成为新的工程组织方式 |
| 最大瓶颈 | 不是生成代码，而是信任、Review、质量验证 | 我必须加强架构判断和验证体系 |
3. 我需要理解的底层变化
3.1 软件开发的成本不只是写新代码
原文强调，真正难的不是从零写一个小脚本，而是在几千万行已有代码中做正确修改。
软件复杂性通常是隐藏的：用户看到的是几个按钮，工程师面对的是大量历史逻辑、依赖关系、边界条件和兼容问题。
我的理解：
- 需求看起来小，不代表工程成本小。
- 改代码之前，理解上下文比直接动手更重要。
- Agent 能生成代码，但如果不了解系统重量，也会制造更大的混乱。
3.2 三个开发时代
| 阶段 | 工作方式 | 人的角色 | AI 的角色 |
|---|---|---|---|
| 手工时代 | 人一行一行写代码 | 主要生产者 | 基本不存在 |
| Copilot 时代 | AI 做 Tab 补全和局部建议 | 主导者 | 辅助者 |
| Agent / Teams 时代 | 人描述任务，Agent 执行大块工作 | 指挥者、审阅者、系统负责人 | 执行者、协作者 |
我当前不能只停留在“让 AI 补代码”，要逐步练习“让 AI 完成一个可验收的任务”。
3.3 工程师正在变成 Agent 管理者
原文里“幽灵同事”这个比喻很关键：以后一个工程师身边可能不是一个 AI 工具，而是一批可以并行工作的 Agent。
这意味着我要学会：
- 给 Agent 布置清楚任务。
- 让不同 Agent 处理不同分支。
- 检查 Agent 的产出质量。
- 处理多个 Agent 之间的冲突。
- 决定什么能合并，什么必须退回重做。
4. 需要重点加强的能力
4.1 系统性思维与产品直觉
目标：从“怎么写”升级到“该做什么、为什么做、做到什么程度算完成”。
我要练习：
- 把模糊需求改写成明确目标。
- 明确用户、场景、痛点和验收标准。
- 在让 AI 写代码前，先让 AI 帮我澄清需求和拆任务。
- 判断一个功能是否真的解决问题，而不是只完成表面页面。
练习模板：
需求背景：
目标用户：
要解决的问题：
成功标准：
不做什么：
验收方式：
4.2 架构判断力与代码鉴别力
目标：AI 可以写代码，但我必须判断它是否写得对、写得稳、写得长期可维护。
我要练习：
- 判断代码是否符合现有架构。
- 判断改动影响范围。
- 识别技术债、重复逻辑、隐式依赖和过度抽象。
- 发现边界 case、安全风险、并发问题和回滚风险。
Review 检查清单：
- 是否解决了真正的问题？
- 是否改动了不该改的模块？
- 是否引入新的全局状态或隐式依赖？
- 错误处理是否完整？
- 测试是否覆盖主路径和失败路径？
- 未来别人维护时是否能快速理解？
4.3 Agent 管理与任务编排
目标：从“我自己做完”变成“我设计任务，让 Agent 做，我负责验收”。
我要练习：
- 把大任务拆成探索、实现、测试、文档、Review。
- 限定 Agent 的修改范围。
- 给每个 Agent 明确输入、输出、约束和验收标准。
- 学会并行处理多个任务，而不是一直盯一个 Agent。
Agent 任务模板：
背景：
目标：
需要读取的文件/模块：
允许修改的范围：
禁止修改的范围：
输出要求：
验收标准：
风险点：
4.4 可信度评估与质量体系
目标：不盲信 AI 输出，用流程建立信任。
我要练习：
- 每次 AI 改代码后都做 Review。
- 建立构建、测试、手测、回归检查。
- 对高风险改动要求更严格的验证。
- 用工具和自动化减少人工 Review 压力。
质量门禁：
| 改动级别 | 验证方式 |
|---|---|
| 小改动 | 构建通过 + 相关功能手测 |
| 中等改动 | 构建通过 + 测试 + Review |
| 高风险改动 | 测试 + Review + 回滚方案 + 数据兼容检查 |
5. 可以相对弱化的能力
5.1 语法和 API 记忆
语法细节和 API 记忆不再是核心护城河。
新定位：
- 知道有哪些能力即可。
- 具体写法可以让 AI 辅助。
- 但必须能看懂、能判断、能纠错。
5.2 机械性 CRUD 实现
标准增删改查、表单、列表、接口胶水代码，可以更多交给 AI。
我的重点：
- 字段是否正确。
- 权限是否正确。
- 数据流是否正确。
- 用户体验是否正确。
5.3 局部代码技巧
不要过度追求某段代码写得多短、多巧。
更重要的是：
- 系统可维护。
- 团队能理解。
- 未来能扩展。
- 出问题能回滚。
6. 我的 30 天学习计划
第 1 周：需求拆解训练
每天找一个真实需求，写清楚：
- 背景
- 目标
- 边界
- 输入输出
- 验收标准
- 风险点
目标：练习先定义问题，再让 AI 做事。
第 2 周：AI 代码 Review 训练
每天让 AI 生成一段代码或方案，然后专门 Review：
- 架构是否合理。
- 是否漏边界 case。
- 是否引入技术债。
- 是否有测试。
- 是否能长期维护。
目标：从“能跑就行”升级到“能长期维护”。
第 3 周：Agent 编排训练
选择一个小功能，拆成多个 Agent 任务：
- 探索现有代码。
- 实现核心逻辑。
- 补测试。
- 写文档。
- 做 Review。
目标：学会像项目负责人一样管理 AI 产出。
第 4 周：质量体系训练
为一个真实项目建立检查清单：
- 构建命令。
- 测试命令。
- 手测路径。
- 回归范围。
- 风险和回滚方式。
目标：让 AI 生成的东西可验证、可回滚、可维护。
7. 每次使用 AI 编程前的自检
- 我有没有说清楚业务目标？
- 我有没有给足上下文？
- 我有没有限定修改范围？
- 我有没有定义验收标准？
- 我有没有要求 AI 说明风险？
- 我有没有检查生成结果？
- 我有没有运行构建、测试或手动验证？
- 我有没有避免把私密内容误发布？
8. 对我当前工作的启发
结合我的知识库、理财记录和开发工作，我可以这样练：
- 写知识库时，让 AI 帮我整理结构，但我决定哪些内容公开、哪些内容私密。
- 写投资记录时，让 AI 帮我算表格和复盘，但我负责确认数据来源和口径。
- 做项目时，让 AI 先读代码和拆任务，不要一上来就改。
- 提交前必须检查 Git 状态，避免误提交 Obsidian 自动文件或私密内容。
- 每次重要改动后，至少跑一次构建或测试。
9. 长期目标
成为能管理 AI 产出的工程师，而不是只会让 AI 代写代码的人。
具体目标：
- 能定义值得做的问题。
- 能拆解复杂系统任务。
- 能指挥多个 Agent 并行工作。
- 能判断代码和架构质量。
- 能建立可靠的验证流程。
- 能把 AI 变成自己的工程放大器。
10. 个人行动准则
- 先想清楚，再让 AI 写。
- 先定义验收，再开始实现。
- AI 负责生成，我负责判断。
- 不把能跑当完成，要把可维护当完成。
- 不追求写得快，追求交付得稳。
- 不盲信 AI，也不排斥 AI，把它当成需要管理的同事。