工作流

解决什么问题

PR 上只剩一句"看起来不太对"；线上告警响了却不知道从哪下手；技术方案评审会上被问"为什么选 A 不选 B"，答不上来。这类问题的共同点不是能力不够，而是缺少一套结构化的打法。这个技能把工程师日常高频的六类工作固化成可复用的流程：

• 代码评审：输入 diff/PR，输出检查清单与问题分级（阻断/建议/可选）
• 技术方案设计：输入需求与约束，输出方案模板（背景/目标/选型/风险）
• 调试排错：输入报错信息与上下文，输出定位树、复现步骤与修复验证
• 架构权衡：输入场景与规模，输出选型表（利弊/适用/成本）
• API 设计：输入资源与操作，输出 RESTful 规范、字段契约与错误码
• 工程规范：输入语言/框架，输出清单与反模式

关键工作流

以代码评审为例：先读懂这次改了什么、为什么改，再依次检查正确性（逻辑、边界、并发、空值）、安全（注入、越权、泄露）、可维护性（命名、重复、测试覆盖），最后给出分级结论。常见卡点是"只看风格"和"一次性全改"——正确性优先，阻断级问题先处理。

线上排错则遵循证据链：稳定复现 → 隔离变量（环境/数据/版本）→ 看日志/链路/指标 → 二分假设验证 → 修复后回归与复盘。最大的陷阱是"没复现就改代码"和"凭直觉猜根因"；线上问题先保稳定（降级/回滚）再查根因。

适用边界

这是一套方法论与模板集合，不替代专业资质判断，不接入付费服务，也不需要密钥或外部账号。评审意见只是辅助参考，合并决策仍由负责人承担；涉及真实凭据的场景只提供脱敏示例；不鼓励绕过安全机制或访问未授权系统。工具给出"当前阶段最合适的答案"，取舍仍需你来判断。