邮件

工程师的邮件沟通困境

技术团队的邮件往来常常承载着评审意见、方案讨论与排错复盘，但实际协作中普遍存在三类问题：评审意见零散、缺乏优先级，作者不知道哪些问题必须先改；技术方案邮件结构混乱，背景、选型与风险混在一起，导致决策反复澄清、延迟；线上问题复盘邮件只有结论没有证据链，下次故障仍然靠猜。这些痛点本质上是缺少一套结构化的输出框架。

技能如何工作

该技能将工程协作拆成 6 个可触发的能力，覆盖 review/评审/CR、设计/方案、debug/排查、选型/对比、接口/API、规范/最佳实践 等触发词，收到对应请求即进入相应模式：

• 代码评审：输入 PR 或 diff，产出检查清单并按 阻断/建议/可选 三级标注，先判正确性与安全，再谈命名与风格。
• 技术方案设计：按「背景 / 目标 / 选型 / 风险」模板组织内容，要求每个候选方案附带利弊、适用规模与回滚路径。
• 调试排错：遵循「稳定复现 → 隔离变量 → 查看日志/链路 → 二分验证 → 修复回归」流程，输出定位树而非直接改代码。
• 架构权衡 / API 设计 / 工程规范：分别产出选型表、RESTful 字段契约与反模式清单。

核心工作流强调两个原则：评审时正确性优先于风格，并逐条给出理由；排错时先复现再动手，用日志与指标排除假设，避免盲猜根因。

适用边界

它不替代专业判断，也不接入任何外部账号、密钥或付费服务：

• 涉及密钥、凭证时仅提供脱敏示例，不处理真实敏感信息。
• 评审结论是辅助参考，最终合并决策仍由负责人承担。
• 模板需要结合团队实际语言与框架调整，例如小团队照搬微服务方案可能适得其反。
• 临时方案、缺失可观测性、只覆盖主流程的测试都属于常见反模式，应在输出中显式规避。

总的来说，这套方法的价值在于把「写邮件」变成「套用工程模板」：评审意见有了分级，方案有了取舍论证，排错有了证据链，跨团队协作时上下文更完整，沟通成本自然下降。