Documentation

岗位最佳实践手册：从“知道如何验证正确”到“设计一种更容易正确的工作方式”

副标题：从“知道如何验证正确”，到“设计一种更容易正确的工作方式”。

0. 这份手册解决什么问题

前一版方法论已经给出了一个总判断：AI 时代的开发者，核心能力正在从“亲手写出代码”，迁移到“定义正确性、设计验证信号、驾驭生成—验证回路”。但落到日常工作里，程序员面对的不是抽象理论，而是一类类具体问题：需求怎么构建？Issue 怎么定位？前端页面怎么避免只做 happy path？后端接口怎么保证事务、幂等和权限？测试怎么避免只有覆盖率、没有杀伤力？SRE 怎么让 AI 辅助排障而不制造事故？

这份手册的目标，是把“理论”落到“操作”。它不只回答“最后怎么验证才是对的”，还回答更前置的问题：

1

怎么做，才能让最终正确变得更简单？

核心思想可以概括为三句话：

1
2
3

1. 让正确更容易发生。
2. 让错误更早暴露。
3. 让错误更容易回滚和修复。

AI 时代的最佳实践，不是把过去的工作直接丢给 AI，而是重新设计工作方式：把模糊任务变成清晰输入，把大任务拆成小闭环，把隐含标准变成显式约束，把最终验收变成持续反馈。

1. 总模型：从“最终验证”到“过程设计”

1.1 旧问题：它最后对不对？

传统使用 AI 的方式经常是：

1

输入一个需求 → AI 生成一大段代码 → 人最后 review → 发现问题再返工

这个流程的问题是：错误出现得太晚，范围太大，人的 review 压力极高。AI 生成越快，越容易在短时间内制造大量“看起来完整、实际没人真正想清楚”的内容。

所以，不能只在最后问“它对不对”。更好的问题是：

1

我能不能把任务设计成：AI 更容易做对，人更容易检查，错了更容易撤回？

1.2 新模型：澄清 → 建模 → 拆分 → 锚定 → 生成 → 验证 → 修正 → 沉淀

AI 时代的工作流，可以从单次生成改造成连续闭环：

阶段 核心问题 典型产物
澄清 到底要解决什么问题？什么不是本次目标？ 目标、范围、非目标、待确认问题
建模 这个问题由哪些对象、流程、规则、状态组成？ 领域模型、流程图、状态矩阵、权限矩阵
拆分 如何拆成每一步都有反馈的小任务？ 任务分解、执行顺序、最小闭环
锚定 每一步怎么证明是对的？ 测试、契约、验收标准、对账规则、SLO
生成 AI 具体生成什么？ 代码、测试、配置、文档、脚本、检查清单
验证 它真的符合锚点吗？ 测试结果、Review 记录、指标对比、人工验收
修正 错在哪里，如何缩小修改范围？ 失败用例、补丁、回归测试
沉淀 下次如何更容易做对？ 模板、Checklist、SOP、失败案例库、ADR

1.3 最小原则

为了让正确更容易发生，所有岗位都可以遵循六个原则：

1
2
3
4
5
6

1. 先澄清，再生成。
2. 先建模，再实现。
3. 先失败模式，再解决方案。
4. 先验证锚点，再让 AI 写实现。
5. 一个回合只做一个修改意图。
6. 每一步都要有可检查产物和回滚点。

2. 需求工程师：把模糊愿望变成可开发、可测试、可验收的需求

2.1 岗位核心变化

AI 时代，需求工程师的价值不是“写更多 PRD 文档”，而是把模糊愿望变成可以被开发、测试、AI 和业务方共同理解的结构化规格。

过去很多需求文档写的是：

1
2
3

用户可以方便地管理项目。
优化工作台体验。
支持智能推荐。

这些表达看起来像需求，但不可验证。AI 会自动脑补对象、流程、边界和验收标准，而这些脑补经常与真实业务不一致。

需求工程师的新核心能力是：

1

把不可验证的愿望，改写成对象、动作、规则、边界、异常和验收标准。

2.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
需求只有愿景，没有边界 写一段描述，让 AI 自由发挥 显式列出 in scope / out of scope / 后续再做 范围矩阵 + 业务方签字
验收标准含糊 写“体验好”“性能快” Given-When-Then + 样例数据 + 可观测指标 验收用例可被测试直接执行
隐含业务规则未声明 让 AI 自行推断 把规则写成结构化条目 规则清单 + 反例
优先级靠争论 “老板说要” 用频率 × 价值 × 风险打分 优先级表 + 影响面数据
需求频繁口头变更 临时改需求 走变更流程 + 影响评估 + 重新确认 变更记录 + 影响分析
用户故事太泛 “用户可以管理项目” 用户 + 场景 + 任务 + 异常 + 验收 故事评审通过
成功标准不清晰 “提升活跃度” 明确业务指标 + 阈值 + 验证窗口 指标基线 + 看板
错误信息不设计 异常情况留空 每种错误有提示、引导、回退 错误路径走查

2.3 SOP：从愿望到可验收需求

1
2
3
4
5
6
7
8
9
10

收集原始信息（用户访谈、工单、数据）
→ 写问题陈述：谁、什么场景、什么痛点、为什么现在必须解决
→ 列出范围和非目标
→ 枚举主流程、异常流程、边界流程
→ 把每条写成 Given-When-Then
→ 写验收标准：可测试、可观测、可达成
→ 评估优先级与影响面
→ 与研发、测试、AI 一起评审
→ 形成基线，进入需求池
→ 变更必须走变更流程

2.4 AI 在这个岗位的最佳角色

  • 整理访谈纪要；
  • 提炼痛点和矛盾点；
  • 枚举异常场景；
  • 把模糊表达改写为验收标准；
  • 生成 PRD 初稿；
  • 充当反方挑战需求完整性。

AI 不能做的是：判断问题真实、决定优先级、判断业务价值、判断组织约束。

3. 前端工程师：让页面不是“看起来对”，而是真的状态完整、交互正确

3.1 岗位核心变化

AI 时代，前端最容易被“生成一大堆组件”淹没。组件可以生成，但状态、交互、异常、体验不能被生成决定。

前端工程师的新核心能力是：

1

把页面拆成状态、交互、视觉、异常和体验判断，并建立验证闭环。

3.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
只做 happy path 只渲染成功态 枚举空态、加载、错误、超时、弱网、无权限 状态矩阵 + 截图 diff
视觉靠肉眼 review 让 AI 直接出页面 设计稿 + 截图 diff + 设计 token 视觉回归测试
状态耦合在组件里 一个组件控制所有状态 状态外置 + 容器组件 + 展示组件 单测 + Storybook
交互只测主路径 只测点击 → 列表 覆盖键盘、触屏、辅助技术、边界输入 E2E 矩阵
错误提示模板化 写 “请求失败” 不同错误有针对性提示和引导 错误路径走查
性能事后优化 先写完再优化 设计阶段定义性能预算 Lighthouse 阈值
可访问性靠运气 不专门考虑 语义、对比度、键盘导航、ARIA axe + 人工
暗色模式残缺 不测暗色 主题 token + 全量截图 diff 视觉回归
表单校验缺失 提交时统一校验 字段级、规则化、可恢复提示 单测 + E2E
i18n 临时补 写中文硬编码 文案外置 + key 设计 + 占位符 多语言截图 diff

3.3 SOP：从页面目标到可验收页面

1
2
3
4
5
6
7
8
9
10

写页面状态矩阵：所有可能状态、所有可能交互
→ 定义组件契约：props、events、错误状态
→ 准备 mock 数据：成功、空、异常、超时
→ 让 AI 生成组件和样式
→ Storybook 验证每个状态
→ 单测组件逻辑
→ E2E 验证关键路径
→ 走查视觉和体验
→ 性能与可访问性测试
→ 小步提交

3.4 验收清单

  • 页面有哪些状态？每个状态都有设计和文案吗？
  • API 成功、失败、超时、空数据如何处理？
  • 表单校验是否清楚、错误提示是否具体？
  • 是否有 E2E 覆盖主流程和异常路径？
  • 是否有截图 diff 或视觉回归？
  • 是否考虑移动端、暗色模式、多语言？
  • AI 生成的组件是否过度耦合？
  • 用户在不看说明的情况下能完成任务吗？

4. 后端工程师：让接口不仅能跑，还能守住契约、一致性和边界

4.1 岗位核心变化

AI 时代，后端的实现成本被极大压缩。后端工程师的价值集中在“不变量、边界、契约、安全、演进”。

1

写代码变快，不等于系统变对。

后端工程师的新核心能力是：

1

把业务规则、事务边界、幂等、安全、并发契约、外兼容变成可验证的工程约束。

4.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
接口契约随意变更 字段随意加 OpenAPI + 契约测试 + 版本管理 契约测试 + 客户端兼容测试
错误码模糊 都返回 200 + msg 明确错误码 + 类别 + 文档 错误码文档 + 客户端映射
事务边界模糊 一个 Service 一锅炖 明确事务边界 + 跨服务用 Saga/Outbox 事务测试 + 集成测试
没有幂等 重复扣款 幂等键 + 唯一约束 重复请求测试
并发写脏数据 不加锁 乐观锁 / 悲观锁 / 唯一索引 并发测试
权限校验散落 漏校验 集中在中间件 / 网关 / 切面 权限矩阵 + 越权测试
日志缺失 只打印异常 关键操作 + 业务上下文 + trace id 日志规范 + trace 走查
数据迁移无回滚 直接 ALTER 影子库 + 双写 + 切换 + 回滚预案 回滚演练
性能无指标 等线上告警 接口 SLO + 压测 + 容量评估 压测报告 + 监控
老接口不兼容 直接破坏 灰度 + 兼容性测试 + 多版本 兼容测试矩阵
缓存滥用 缓存失效不一致 显式缓存策略 + 一致性级别 一致性测试

4.3 SOP：从接口需求到可上线接口

1
2
3
4
5
6
7
8

明确接口契约：路径、方法、入参、出参、错误码
→ 写业务不变量：哪些永远不能违反的规则
→ 准备用例：正常、异常、并发、重复请求、越权
→ 让 AI 实现接口、DTO、Service、测试
→ 跑单测、集成测试、契约测试
→ 人审事务、幂等、权限、迁移和日志
→ 灰度发布 + 监控
→ 沉淀常见错误码和处置 SOP

4.4 验收清单

  • 接口契约是否稳定、文档化？
  • 错误码是否清楚、可被客户端理解？
  • 事务边界在哪里？跨服务如何协调？
  • 重复请求会不会产生副作用？
  • 并发写会不会产生脏数据？
  • 权限校验在正确层做吗？
  • 有审计日志吗？能 trace 吗？
  • 数据迁移能回滚吗？
  • 兼容老版本客户端吗？
  • 有压测或容量评估吗？

5. 测试工程师：从追覆盖率，转向设计高杀伤力验证信号

5.1 岗位核心变化

AI 时代，测试用例可以快速生成。但用例数量 ≠ 验证能力。

测试工程师的价值是：

1

设计能发现真实问题的验证系统，而不是堆砌低价值用例。

5.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
只追覆盖率 100% 覆盖但全是空断言 高杀伤力用例 + 有效断言 变异测试
用例维护难 强耦合实现 行为驱动 + 解耦断言 重构时测试稳定
缺陷难复现 偶发就不管 完整环境快照 + 复现脚本 缺陷知识库
E2E 慢且脆弱 全链路一锅端 分层测试 + 关键路径 E2E 测试金字塔
自动化测试不维护 写完不管 失败测试立即处理 + 定期清理 测试健康看板
边界条件漏掉 测典型输入 边界值 + 异常值 + 异常路径 边界测试矩阵
权限测试缺失 默认全部通过 越权、缺权、错权 权限测试
性能测试只在生产 出现问题再查 设计阶段压测 + 容量评估 压测报告
测试只测实现 内部细节决定测试 测行为、契约、用户场景 重构不破坏测试
测试数据脏 临时构造 固定种子 + 构造器 测试稳定可重现

5.3 SOP：从需求到验证系统

1
2
3
4
5
6
7
8

理解需求和风险
→ 让 AI 枚举场景、边界、异常
→ 人筛选高风险路径
→ 让 AI 生成测试脚本和数据
→ 人审断言质量（是否验证了真实行为）
→ 接入 CI
→ 把线上缺陷回灌为回归用例
→ 维护缺陷知识库

5.4 验收清单

  • 这个测试能发现什么具体错误？
  • 如果实现写错，测试真的会失败吗？
  • 是否只在测试实现细节？
  • 是否覆盖异常流和边界值？
  • 是否覆盖权限、并发、重复提交？
  • 测试失败时定位成本高不高？
  • 是否有 flaky 风险？
  • 历史 bug 是否沉淀为回归用例？

6. DevOps / SRE：让 AI 辅助变更和排障，而不是放大生产风险

6.1 岗位核心变化

AI 可以生成脚本、配置、排障建议。但生产环境的风险不可外包。

DevOps/SRE 的价值是：

1

让系统稳定运行，让变更可观测、可恢复、可回滚。

6.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
变更直接上生产 不做灰度 灰度发布 + 观察期 灰度指标 + 自动回滚
没有回滚预案 出问题再想 每次变更都准备回滚 回滚演练
监控只设不调 装上 Prometheus 不看 SLO + 告警阈值 + 噪音治理 告警命中率
告警雪崩 一个故障几百条告警 收敛、抑制、分级 告警聚合
权限过大 用 root 跑脚本 最小权限 + 角色分离 权限审计
IaC 漂移 改了控制台忘了改代码 控制台操作进 IaC 漂移检测
排障靠人肉 凭经验翻日志 标准化排查 + AI 辅助 + 知识库 排障 SOP
演练缺失 出问题才学 定期故障演练 演练记录
容量评估缺失 等宕机 设计阶段定容量 + 压测 容量模型
变更窗口混乱 任意时间变更 变更窗口 + 变更审批 变更记录
事故复盘走形式 只写报告不行动 行动项必须落地 + 验证 行动项追踪

6.3 SOP：从变更意图到安全上线

1
2
3
4
5
6
7
8
9

定义变更目标和回滚条件
→ 让 AI 生成脚本或配置
→ 本地 / 测试环境 dry-run
→ 用工具验证配置（kubeval、tfsec 等）
→ 人审权限、影响范围、回滚路径
→ 灰度发布
→ 观察指标
→ 达标后扩大范围
→ 沉淀为 SOP

6.4 验收清单

  • 这次变更影响哪些服务？
  • 失败时如何回滚？回滚是否演练过？
  • 有没有 dry-run？
  • 是否有灰度方案？
  • 监控指标看什么？告警是否会触发？
  • 权限是否过大？
  • AI 生成的脚本有没有危险命令？
  • 是否会误删数据或资源？

7. 数据工程师：让 SQL / ETL 不只是能跑，而是口径正确、可对账、可追溯

7.1 岗位核心变化

AI 可以生成 SQL、ETL、清洗脚本。但口径和链路可信度是数据工程的核心难点。

1

SQL 能跑 ≠ 数据可信。

7.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
口径不清晰 每个分析师一套定义 指标口径文档 + 业务方确认 口径评审通过
源表含义不明 字段名猜意思 字段字典 + 业务说明 字段文档
时间口径混乱 用本地时间算指标 统一时区 + 时间戳标准 时间一致性测试
去重规则不固定 临时去重 明确去重 key + 业务确认 去重验证
空值处理不当 默认 0 或 NULL 显式处理 + 业务确认 空值分布
行数对账缺失 不查行数 上游/下游行数对账 对账报告
异常值无解释 不查直接用 异常检测 + 业务解释 异常清单
血缘不可追溯 表改了没人知道 自动血缘 + 影响分析 血缘图
指标口径变更无通知 直接改 SQL 影响分析 + 下游确认 变更通知
数据延迟无感知 等数据齐再算 监控延迟 + 提前预警 延迟监控
抽样验证缺失 不知真实情况 定期抽样 + 人工核验 抽样记录

7.3 SOP：从业务问题到可信数据

1
2
3
4
5
6
7
8

定义指标口径和数据契约
→ 准备样例输入和期望输出
→ 让 AI 生成 SQL / ETL
→ 跑行数、字段、分布、历史趋势校验
→ 人审业务口径和异常解释
→ 输出血缘和文档
→ 监控指标延迟和质量
→ 口径变更走流程

7.4 验收清单

  • 指标口径是否有业务确认？
  • 源表字段含义是否清楚？
  • 时间口径是什么？去重规则是什么？
  • 空值如何处理？
  • 是否有行数对账？是否有历史趋势对比？
  • 异常值如何解释？
  • 下游依赖有哪些？口径变更是否通知到位？

8. AI / LLM 应用工程师：从“调 Prompt”转向建设可评估系统

8.1 岗位核心变化

LLM 应用工程师最容易掉进的坑：调出一次看起来好的输出 ≠ 系统的有效性。

真正的能力是：

1

把“效果好不好”变成可重复、可比较、可改进的评估系统。

8.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
凭感觉调 Prompt 试几次看运气 golden set + 自动 eval 评测分数
评测集过小 测 3 个例子就上线 覆盖典型、边界、难例 评测集统计
评测维度单一 只看“像不像” 事实、格式、风格、安全分别评估 多维分数
失败案例不沉淀 线上出错就结束 失败模式分类 + 回归评测 失败案例库
RAG 检索不可控 直接塞上下文 检索命中率 + 召回评估 + 答案引用 检索指标
Agent 行为难调试 黑盒 轨迹日志 + 工具调用成功率 轨迹分析
幻觉和越权不管 只看效果 红队测试 + 越权检测 安全评测
成本失控 不算 token 成本 成本监控 + 缓存 + 模型路由 成本看板
延迟不优化 等用户抱怨 监控延迟 + 限流 + 缓存 延迟分位数
用户反馈无闭环 收集了不看 反馈回灌评测集 反馈 → 评测 循环
多轮对话状态漂移 只测单轮 多轮一致性 + 上下文测试 多轮评测
Prompt 版本混乱 改了不记录 Prompt 版本管理 + 变更评审 版本追踪

8.3 SOP：从任务到可评估系统

1
2
3
4
5
6
7
8
9

定义任务类型和成功标准
→ 建 golden set（典型、边界、难例）
→ 定义评价维度（事实、格式、风格、安全）
→ 让 AI 生成 Prompt / 流程 / 工具调用
→ 跑自动 eval
→ 人工抽检失败案例
→ 记录失败模式
→ 迭代 Prompt、工具、检索和工作流
→ 监控线上效果，反馈回灌

8.4 验收清单

  • 有 golden set 吗？覆盖典型、边界、难例吗？
  • 评价维度是什么？区分事实、格式、风格、安全吗？
  • 失败案例是否沉淀？
  • RAG 要求引用来源吗？检索命中率如何？
  • 工具调用失败怎么处理？
  • 多轮对话状态会不会漂移？
  • 成本和延迟可接受吗？
  • 有越权和敏感信息风险吗？
  • 线上反馈如何回灌到评测集？

9. 安全工程师：让 AI 做审计助手，而不是制造“已经安全”的错觉

9.1 岗位核心变化

AI 可以辅助代码审计、日志分析、生成安全检查清单、解释漏洞。但安全判断不可外包——它依赖上下文、攻击者视角和系统思维。

1

“看起来安全” ≠ “真的安全”。

9.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
漏洞扫描 = 安全 跑完扫描就结束 扫描 + 人工复核 + PoC 漏洞闭环率
权限设计模糊 默认放行 显式权限模型 + 最小权限 权限矩阵
越权测试缺失 不测越权 横向 + 纵向越权测试 越权测试报告
威胁建模靠感觉 不画 DFD DFD + 攻击路径 + STRIDE 威胁清单
日志泄露敏感信息 打印全量对象 日志脱敏 + 字段白名单 日志审计
默认密钥遗留 用默认密码上线 强制密钥轮换 + 配置审计 密钥扫描
依赖漏洞忽视 不更新依赖 SCA + SBOM + 升级策略 依赖扫描
越权/注入靠运气 不测注入 SQL 注入 / 命令注入 / SSRF 测试 渗透测试
AI 生成代码不审 直接合入 安全审计 + 静态检查 安全审计记录
风险评级模糊 “高危”“低危”随便标 用 CVSS + 业务影响打分 评级标准
修复验证缺失 修了不验 复测 + 渗透验证 修复验证记录

9.3 SOP：从系统边界到安全验证

1
2
3
4
5
6
7
8
9

画系统边界和数据流
→ 让 AI 枚举威胁和攻击路径
→ 人筛选真实风险
→ 让 AI 辅助代码审计和日志分析
→ 用工具扫描和 PoC 验证
→ 人做风险评级和修复优先级
→ 跟踪修复 + 复测
→ 形成审计记录
→ 沉淀攻击模式库

9.4 验收清单

  • 谁能访问什么资源？
  • 有没有越权路径？
  • 敏感数据在哪里存储和传输？
  • 日志是否泄露敏感信息？
  • 是否有审计记录？
  • 第三方依赖是否有高危漏洞？
  • AI 生成的代码是否引入注入风险？
  • 是否有默认密钥或过大权限？
  • 风险评级依据是什么？
  • 修复是否经过验证？

10. 架构师 / Tech Lead：让 AI 做反方、推演和记录，而不是替你做最终决策

10.1 岗位核心变化

AI 可以生成方案、对比选型、写 ADR。但长期取舍和不可逆决策不能外包。

1

列方案容易，做取舍难。

架构师的价值是：

1

在技术约束、业务节奏、团队能力和未来变化之间做负责任的取舍。

10.2 常见问题与最佳实践

常见问题 错误做法 最佳实践 验证信号
方案靠灵光一现 拍脑袋选技术 ADR + 评审记录 + 取舍依据 ADR 完整
抽象过早 还没需求就抽象 等到第三个用例再抽象 YAGNI 原则
抽象过晚 重复造轮子 识别重复模式后抽象 DRY 落地
模块边界含糊 包乱分 按业务边界 + 依赖方向 依赖图
关键路径不可扩展 设计期不思考增长 容量评估 + 演进路径 容量模型
失败会扩散 没考虑隔离 熔断、限流、降级、超时 故障演练
团队无法维护 过度设计 评估团队能力 + 渐进式 维护记录
数据方向错误 双向依赖 严格依赖方向 + 防腐层 依赖分析
演进路径缺失 一锤子买卖 路线图 + 迁移成本 演进计划
决策不可逆 没识别不可逆点 标注不可逆决策 + 沙箱验证 决策评审

10.3 SOP：从业务目标到可演进架构

1
2
3
4
5
6
7
8

先明确业务目标和约束
→ 让 AI 生成多种方案
→ 让 AI 扮演反方攻击每个方案
→ 人判断长期取舍
→ 做最小 PoC 验证关键假设
→ 写 ADR
→ 小步演进，而不是一次性大重构
→ 定期回顾架构假设

10.4 验收清单

  • 这个设计解决的核心问题是什么？
  • 有没有更简单的方案？
  • 哪些决策不可逆？
  • 未来最可能变化的地方在哪里？
  • 模块边界是否对应业务边界？
  • 数据流是否清楚？失败会不会扩散？
  • 团队是否有能力维护？
  • 迁移路径是什么？
  • 三个月后和三年后看，这个设计是否仍然合理？

11. 通用场景 SOP：所有岗位都会遇到的高频问题

11.1 接到模糊需求

1
2
3
4
5
6
7

需求：用户希望系统更智能。
→ 把“更智能”翻译成具体场景
→ 列出至少 3 个用户故事
→ 给出每条的可验证标准
→ 划定范围和非目标
→ 让 AI 输出多种实现思路
→ 评审后选定

11.2 修一个 bug

1
2
3
4
5
6
7

现象：用户反馈 X 失败。
→ 完整复现：环境、输入、步骤、期望、实际
→ 定位根因：二分、trace、日志、断点
→ 写一个能稳定复现的失败测试
→ 修实现
→ 跑测试 + 回归
→ 沉淀到缺陷库

11.3 重构一段代码

1
2
3
4
5
6
7

目标：让代码更清晰 / 更快 / 更易测。
→ 先写刻画测试，把当前行为钉住
→ 列出重构意图和验收标准
→ 小步重构（一次只改一个意图）
→ 每步都跑测试
→ 行为不变 = 重构成功
→ 沉淀重构模式

11.4 加一个功能

1
2
3
4
5
6
7

目标：让用户能 X。
→ 列场景：主流程、异常、边界
→ 定义接口契约或组件契约
→ 写测试 / 契约 / 验收标准
→ 让 AI 实现
→ 人审关键路径
→ 小步提交

11.5 改一个数据库 schema

1
2
3
4
5
6

→ 评估影响：哪些表、哪些查询、哪些缓存
→ 写迁移脚本 + 回滚脚本
→ 影子库或测试环境演练
→ 双写或灰度切换
→ 验证数据和查询正确性
→ 清理旧字段

11.6 处理线上告警

1
2
3
4
5
6

→ 看告警上下文（指标、日志、trace）
→ 二分定位：上游 / 下游 / 自身
→ 评估影响面和紧急度
→ 缓解优先（限流、回滚、降级）
→ 修复 + 复盘
→ 行动项落地

11.7 设计评审

1
2
3
4
5
6

→ 让作者先讲“解决什么问题、为什么这样做”
→ 列出备选方案和取舍依据
→ 反方逐条质疑
→ 明确不可逆决策
→ 写 ADR
→ 跟踪行动项

11.8 引入新依赖

1
2
3
4
5
6

→ 评估必要性：能不能用现有依赖？
→ 看维护活跃度、许可证、社区
→ 看安全漏洞历史
→ 小范围试点
→ 写使用规范
→ 团队培训

11.9 跨团队协作

1
2
3
4
5

→ 明确接口契约
→ 写协作 SOP
→ 约定变更流程
→ 共享监控和告警
→ 定期对齐

11.10 性能问题

1
2
3
4
5

→ 用 profiler 找热点
→ 区分 CPU / IO / 锁 / GC
→ 小步优化 + 每步验证
→ 不优化无测量的部分
→ 写压测保证不退化

12. 岗位最佳实践总表

岗位 核心原则 必须建立的产物 关键 AI 用法
需求工程师 模糊愿望 → 结构化规格 验收用例库、口径文档、变更记录 整理访谈、反方质疑、改写验收
前端工程师 状态完整 + 体验可验 状态矩阵、Storybook、E2E 生成组件、生成测试
后端工程师 守住契约、边界、一致性 OpenAPI、契约测试、幂等 key、迁移脚本 CRUD 实现、生成测试
测试工程师 高杀伤力验证信号 缺陷库、变异测试、回归用例 生成用例、辅助复现
DevOps/SRE 可观测、可恢复、可回滚 SLO、回滚 SOP、变更记录、演练 排障辅助、生成配置
数据工程师 口径一致、链路可信 口径文档、血缘、对账、异常清单 SQL 生成、ETL 编写
AI/LLM 应用工程师 效果可评估、失败可观察 golden set、eval 体系、失败案例库 Prompt 探索、自动化评测
安全工程师 攻击面可控、权限边界正确 威胁模型、权限矩阵、审计记录 审计辅助、日志分析
架构师/Tech Lead 长期取舍、不可逆决策可控 ADR、PoC、容量模型、演进路线 方案对比、反方推演

13. 最终结论：最佳实践的本质是降低正确性的获得成本

回到手册最开始的三句话：

1
2
3

1. 让正确更容易发生。
2. 让错误更早暴露。
3. 让错误更容易回滚和修复。

AI 时代的所有“最佳实践”，本质都是一件事：

1

降低“获得正确”的总成本。

这不是工具升级，而是工作方式升级。

它的核心动作是：

  • 把模糊愿望拆成显式约束；
  • 把大任务拆成小闭环；
  • 把“最后 review”前移到“每一步都有验证锚点”；
  • 把隐含假设变成显式记录；
  • 把个人判断变成团队可继承的 SOP、ADR、缺陷库。

写代码变快是表面的，让人更容易做对、更容易发现错、更容易撤回错——才是真正的能力。

未来最重要的程序员，不是最会让 AI 写代码的人，而是最会回答这三个问题的人：

1
2
3

什么是对？
怎么证明对？
错了如何不炸？

这三句话，也是这份手册的全部。

📚 系列导航

这是「AI 时代程序员方法论」专题的第三篇 — 岗位最佳实践手册（怎么做）。建议按顺序阅读：

  1. ➡️ 思考手册：核心是驾驭生成—验证回路，理解“为什么要这么干”（先读这篇建立心智）。
  2. ➡️ 9 岗位完整版：把方法论展开到 9 个岗位，回答每个岗位的核心正确性、验证信号、AI 委托边界、新护城河。
  3. ✅ 岗位最佳实践手册（本文）：把方法论落到操作——9 个岗位的常见问题、错误做法、最佳实践、通用场景 SOP，让“正确更容易发生、错误更早暴露、更容易回滚”。
© 2026 zhchxiao123
Built with & Chirpy Docs