数字化转型

你在什么情况下会卡住

PR 来了却没有统一的评审维度；要写技术方案时背景、选型、风险各写一块却凑不成文档；线上告警堆在面前，复现路径和证据链都说不清；微服务还是单体、REST 还是 RPC，争论停在口号上；接口字段和错误码前后端各一套，联调才暴露契约缺口。这些都不是缺工具，而是缺可重复的结构。

技能如何组织交付

本技能把常见工程诉求路由到六类能力，听到对应触发词即可进入（如 review/评审、设计/方案、debug/报错、选型/对比、接口/API、规范/最佳实践）。输入侧尽量具体：diff/PR、需求与约束、报错与上下文、场景与规模、资源与操作、语言与框架。

| 能力 | 典型输出 |
|------|----------|
| 代码评审 | 检查清单 + 阻断/建议/可选分级 |
| 技术方案 | 背景、目标、选型、风险模板 |
| 调试排错 | 定位树、复现步骤、修复与验证 |
| 架构权衡 | 利弊、适用规模、成本对比表 |
| API 设计 | REST 约定、字段契约、错误码 |
| 工程规范 | 清单与反模式 |

代码评审建议顺序：先读改动意图，再查正确性与边界（并发、空值），然后安全与可维护性，最后给出带理由的分级结论。线上排错强调先稳定复现、隔离环境/数据/版本，用日志与链路支撑假设，再修复并回归；避免未复现就改代码。

在「数字化转型」主题下，把人群、场景与约束写进输入，通用模板会替换成该领域的表述，产出仍是对应能力的结构化文档。

边界与注意

• 不提供专业资质判断，不接入付费服务，不处理真实密钥或凭证（仅脱敏示例）。
• 评审与方案输出供参考，合并与上线决策仍由负责人承担。
• 不鼓励绕过安全机制或访问未授权系统。