AI时代下工程师的注意力迁移与工程实践准则

开发标准对齐

AI NATIVE · ENGINEERING ATTENTION从"让 AI 写代码"到"让 AI 完成任务"

写代码越来越容易，想清楚要做什么、判断做得对不对越来越重要。

受众：研发工程师 · 架构师 · 技术管理者
形式：AI Native 五原则培训（45 MIN）

01 · 变化 — AI 开始参与完整的工程流程

真正的变化，不只是 AI 会写代码

左侧 · 生成代码，等待人检查（CODE GENERATION）

只关心一次产出
上下文由人补齐
错误由人发现

右侧 · 完成任务，拿出验证结果（AGENTIC ENGINEERING）

理解现状和边界
规划并执行方案
验证、修正、再验证

💡 关键不在 PROMPT 长短，而在任务条件是否清楚（CODE → TASK）

02 · 来源 — 五条原则来自哪里

官方机制、一手实践、审慎归纳

⚠️ 这五条原则是根据多份资料总结出来的，不是 Anthropic 官方发布的编号清单；个人经验也不能直接当成所有团队都必须遵守的规定。

03 · 原则一：先搞清楚问题，系统怎么运作（EXPLORE FIRST）

先问清楚，再让 AI 写代码

如果还说不清要改什么、为什么改、会影响哪里，就先调查。

这个模块怎么工作？ — 先让 Agent 读懂相关代码和依赖。
为什么要这样设计？ — 查看调用关系、架构限制和 Git 历史。
还有什么没说清楚？ — 让 AI 主动提问，补齐目标和边界。

代码考古 · 需求澄清 · 架构理解（ASK BEFORE ACT）

04 · 原则二：把"想清楚"和"动手做"分开（PLAN BEFORE EDITING）

大改动前，先让 AI 做计划

四阶段流程：

阶段	做什么
1. Explore	阅读代码、查看历史、了解现状，先不修改。
2. Plan	列清方案、前提、风险、影响范围和完成标准。
3. Implement & Verify	按计划实施，再根据验证结果不断修正。
4. Commit / PR	整理改动和验证结果，交付可审查的成果。

📌 计划不用写成几十页文档，只要说清怎么做、哪里有风险、怎样判断完成。适用场景：跨文件 · 陌生代码 · 多种路径 · 高风险（EXPLORE → PLAN → EXECUTE）

05 · 原则三：告诉 AI 怎么检查，让它自己修错（VERIFICATION LOOP）

AI 不是不会写，而是不知道何时算做完。

具体实现可以交给 AI，但怎么算做对了必须提前定好。

验证闭环（5 步循环）：

圆心：看得到结果 / 判断得了对错
01 实现 → 02 运行验证 → 03 查看结果 → 04 修正问题 → 05 再次验证

验证手段：测试 · BUILD · LINT · 截图 · 日志（CLOSE THE LOOP）

06 · 原则四：用 CLAUDE.MD 写清项目规则（PROJECT INSTRUCTIONS）

它不是"AI 大脑"，而是团队共用的工作说明

有记录 — 和代码一起放进 Git，谁改了什么都能查到。
能审查 — 构建命令、架构限制和团队流程都能一起 Review。
能复用 — 这次纠正过的问题，下次会话可以直接避开。

📌 把代码里看不出来、但每次做事都要遵守的规则写下来。

⚠️ 它只是工作说明，不会自动拦住错误。必须严格执行的规则，仍要放进测试、lint、权限控制或 CI。

COMMANDS · CONVENTIONS · ARCHITECTURE · WORKFLOW（SHARED CONTEXT）

07 · 原则五：像给同事分配任务一样使用 AI（DELEGATE LIKE A TEAMMATE）

关注目标和结果，不要事事盯着每一步

委派任务五要素：

要素	内容
01 任务	要解决什么问题
02 背景	业务和项目情况
03 边界	哪些红线不能碰
04 完成标准	做到什么才算结束
05 验证方式	用什么检查结果

📌 说清目标、背景、边界和完成标准，再让模型自己选择怎么实现。

⚠️ 高风险、不可逆操作仍需权限、审批与人工确认。

AUTONOMY REQUIRES GUARDRAILS（TASK · CONTEXT · EXIT CRITERIA）

08 · 认知转折：人的注意力正在向两端转移（ATTENTION SHIFT）

从纺锤形到哑铃形：中间变轻，两端变重

传统模式（TRADITIONAL）— 纺锤形（中间大、两端小）

需求定义（小）← 技术实现（注意力最集中） → 结果判断（小）

AI 原生模式（AI NATIVE）— 哑铃形（两端大、中间小）

把问题说清楚（大） ← AI 负责主要实现（最轻）→ 检查并判断结果（大）

这不是岗位数量，也不是技术工作量，而是注意力分配的变化。（ATTENTION, NOT WORKLOAD）

09 · 工作循环：五条原则连成一套从理解到交付的工作流程（OPERATING LOOP）

五条原则不是五个零散技巧

环节	目的
01 先问清楚	避免理解错
02 先做计划	避免方向错
03 给出检查方式	避免做完却没做对
04 留下项目说明	避免下次重复犯错
05 在边界内放手	让人少盯实现细节

💡 人的工作从"每一步都亲自操作"，转向"把目标、边界和检查方式设计清楚"。这是一套系统，不是 Prompt 技巧（UNDERSTAND → PLAN → VERIFY → LEARN → DELEGATE）

10 · 输入：交给 AI 的任务应该包含什么（PROBLEM SPECIFICATION）

不是一句模糊需求，而是一份说清楚的任务

任务六大要素：

要素	说明
实际问题	用户真正遇到了什么困难
使用场景	谁在什么流程和环境中遇到问题
真实样例	输入、输出、页面、日志或历史案例
限制条件	权限、合规、兼容、性能和成本
不能出现的结果	哪些错误哪怕偶尔出现也不能接受
成功标准	看到什么结果才算问题解决

📌 尽量少让 AI 猜，同时给它选择实现方法的空间。PROBLEM + CONTEXT + EXAMPLES + CONSTRAINTS + FAILURE + SUCCESS（INPUT QUALITY）

11 · 案例：从模糊需求到清晰任务（FROM REQUEST TO TASK）

❌ 一句模糊需求：

"给客服后台做一个会话批量导出功能。"

做出按钮并不难。真正决定功能是否正确的，是权限、数据完整性、消息顺序和数据边界。

✅ 一份说清楚的任务：

标签	说明
实际问题	投诉专员无法快速收集指定范围内的完整会话证据。
使用场景	客服处理投诉工单时，需要按用户、时间和会话范围提取材料。
限制条件	只能访问当前租户和现有权限内的数据；敏感字段要脱敏；单次最多一万条。
绝不能出现	跨租户泄露、消息缺失或乱序、导出未授权字段。
成功标准	结构正确、内容完整、顺序一致，并提供检查结果。

⚠️ 实现路径可以委托，结果责任不能委托。（PROBLEM → EVIDENCE）

12 · 边界：放手到什么程度，必须看风险有多大（ENGINEERING GOVERNANCE）

让 AI 自己做，不等于放弃管理

风险渐变：低风险 · 可逆 · 易验证 ────▶ 高风险 · 不可逆 · 难验证

四象限治理原则：

人要负责最终判断 — 工程师仍要负责问题、架构、风险和最终结果。
计划仍然要有 — 执行计划要能审查，也能随时调整。
高风险操作要把关 — 仍然需要权限、审批和人工确认。
测试不是万能的 — 测试只能检查已经定义好的标准。

CONTEXT · GUARDRAILS · FEEDBACK · ACCOUNTABILITY（RISK-BASED AUTONOMY）

13 · 行动清单：动手前，先问五个问题（FIVE QUESTIONS）

从下一项复杂任务开始

编号	问题	辅助判断
01	还有哪些没搞清楚？	是否要先读代码、历史和业务资料？
02	要不要先做计划？	是否跨文件、代码陌生、风险高或有多种方案？
03	AI 怎么判断做完了？	能运行什么测试、命令、对比或检查？
04	哪些经验要留下来？	应该写进说明、Skill、测试、lint 还是 CI？
05	授权边界清楚吗？	哪里可以让 AI 决定，哪里必须由人确认？

先定义任务环境，再让 Agent 工作。（START WITH THE NEXT TASK）

14 · 回顾：五条原则，都指向同一个方向（FIVE PRINCIPLES）

把人的判断力用在最重要的地方

原则	补充
01 先问清楚	先理解，再行动
02 大改动先计划	先分析，再执行
03 给出检查方式	让 AI 自己发现并修错
04 留下项目说明	让经验下次还能用
05 像给同事派任务	说清目标、边界和反馈

📌 先把问题想清楚，再决定怎么做；先说清怎么算完成，再让 AI 动手。AI NATIVE 不是让人退出研发。（JUDGMENT RETURNS）

15 · 收束：具体实现可以交给 AI，验收标准必须提前定好（THE NEW SHAPE OF ENGINEERING）

从纺锤形到哑铃形

优秀工程师不只要把代码写对，更要找准问题、说清边界，并证明最后的结果确实解决了问题。