副标题：从“知道如何验证正确”，到“设计一种更容易正确的工作方式”。
0. 这份手册解决什么问题
前一版方法论已经给出了一个总判断：AI 时代的开发者，核心能力正在从“亲手写出代码”，迁移到“定义正确性、设计验证信号、驾驭生成—验证回路”。但落到日常工作里，程序员面对的不是抽象理论，而是一类类具体问题：需求怎么构建？Issue 怎么定位？前端页面怎么避免只做 happy path？后端接口怎么保证事务、幂等和权限？测试怎么避免只有覆盖率、没有杀伤力？SRE 怎么让 AI 辅助排障而不制造事故？
这份手册的目标，是把“理论”落到“操作”。它不只回答“最后怎么验证才是对的”，还回答更前置的问题：
核心思想可以概括为三句话：
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
| 把业务规则、事务边界、幂等、安全、并发契约、外兼容变成可验证的工程约束。
|
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、清洗脚本。但口径和链路可信度是数据工程的核心难点。
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 可以辅助代码审计、日志分析、安全检查清单。但安全判断不可外包——它依赖上下文、攻击者视角和系统思维。
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
| 在技术约束、业务节奏、团队能力和未来变化之间做负责任的取舍。
|
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 时代的所有“最佳实践”，本质都是一件事：
这不是工具升级，而是工作方式升级。
它的核心动作是：
- 把模糊愿望拆成显式约束；
- 把大任务拆成小闭环；
- 把“最后 review”前移到“每一步都有验证锚点”；
- 把隐含假设变成显式记录；
- 把个人判断变成团队可继承的 SOP、ADR、缺陷库。
写代码变快是表面的，让人更容易做对、更容易发现错、更容易撤回错——才是真正的能力。
未来最重要的程序员，不是最会让 AI 写代码的人，而是最会回答这三个问题的人：
1
2
3
| 什么是对？
怎么证明对？
错了如何不炸？
|
这三句话，也是这份手册的全部。
📚 系列导航
这是「AI 时代程序员方法论」三篇系列的第三篇 — 岗位最佳实践手册（怎么做）。建议按顺序阅读：
- ➡️ 思考手册：核心是驾驭生成—验证回路，理解“为什么要这么干”（先读这篇建立心智）。
- ➡️ 9 岗位完整版：把方法论展开到 9 个岗位，回答每个岗位的核心正确性、验证信号、AI 委托边界、新护城河。
- ✅ 岗位最佳实践手册（本文）：把方法论落到操作——9 个岗位的常见问题、错误做法、最佳实践、通用场景 SOP，让“正确更容易发生、错误更早暴露、更容易回滚”。