技能介绍

解决什么具体问题

在数据分析相关的研发链路里，麻烦通常不在单个模型或脚本本身，而在工程协作的缝隙里：一次普通的 git diff 看不出并发竞态与边界漏判；技术方案评审只有口头结论，缺少选型对比与回滚预案；线上指标突变时，团队容易跳过复现直接改代码，导致同一个问题反复出现；接口字段改了但文档没同步，联调时才发现契约已经漂移。这些问题的共同点是——缺少一套结构化、可重复执行的工程方法。

技能如何工作

该技能将工程提效拆成 6 个可组合的能力，每个能力对应明确的触发词、输入和输出：

代码评审：输入 diff 或 PR，产出带严重程度分级的检查清单（阻断/建议/可选），覆盖正确性、安全、可维护性等维度。
技术方案设计：输入需求与约束，输出包含背景、目标、选型、风险的方案模板，帮助把取舍写清楚而不是堆功能。
调试排错：输入报错信息与上下文，输出定位树、复现步骤和修复验证路径，强调先稳定复现再动代码。
架构权衡：针对场景与规模给出选型表，列出各方案的利弊、适用条件与长期成本。
API 设计：基于资源与操作生成 RESTful 规范、字段契约与错误码，减少前后端联调时的语义歧义。
工程规范：针对具体语言或框架给出清单与反模式，避免重复踩坑。

其中两条工作流最具实操价值。代码评审工作流要求先读懂改动意图，再依次检查正确性（逻辑、边界、并发、空值）、安全（注入、越权、敏感信息）、可维护性（命名、重复、测试覆盖），最后给出逐条理由的评审结论。线上排错工作流则从稳定复现出发，通过隔离环境、数据、版本等变量，结合日志、链路与指标证据进行二分假设验证，修复后完成回归与复盘。

此外还提供了代码质量的五维评分表，以及意图路由表，把「帮我看看这段代码」「用 A 还是 B」这类模糊诉求映射到具体能力。

适用边界

这套方法只提供结构化的方法论、模板与检查清单，不替代专业资质判断，不接入任何付费服务或外部 API，也不涉及外部账号或密钥。评审意见属于辅助参考，最终合并决策由负责人承担；在涉及密钥与凭证时仅提供脱敏示例，不处理真实敏感信息。它的价值在于让团队把已有的工程经验落到可执行的步骤上，而不是引入新的流程负担。