算力规划

解决的问题

工程师在算力规划相关工作里，大多数卡点不在不会写代码，而在缺少一套可复用的工程骨架：

• PR 打开后只看到风格问题，正确性、并发、安全没人把关；
• 方案文档写了半页背景就没下文，选型理由全靠口头；
• 线上报错一堆日志，凭直觉改代码，改完又炸一次；
• A/B 两个方案各有利弊，评审会上没人能给出结构化对比；
• 接口字段和错误码各端各写，联调阶段才发现契约对不上。

@kunlungrowth/kunlun-compute-planning 把这类反复出现的工程动作沉淀成方法、模板和检查清单，不做外包式执行，只做你的评审与设计脚手架。

核心能力

1. 代码评审：输入 diff / PR，输出检查清单并按阻断 / 建议 / 可选三级分级。评审先看正确性（逻辑、边界、空值、并发），再看安全（注入、越权、敏感信息），最后谈命名与测试。原则是给理由，不给命令。

2. 技术方案设计：输入需求与约束，产出包含背景 / 目标 / 选型 / 风险的模板。核心不是堆功能，而是写清楚「为什么选 A 不选 B」，并把回滚方案列为必选项。

3. 调试排错：报错信息 + 上下文 → 稳定复现 → 隔离变量（环境/数据/版本）→ 看证据（日志、链路、指标）→ 二分假设 → 修复后回归复盘。最大的坑是没复现就动代码。

4. 架构权衡：输出选型表（利弊 / 适用规模 / 长期成本）。渐进式演进，避免一次性大重构，技术债显性化排期。

5. API 设计：从资源与操作推导 RESTful 规范、字段契约与错误码，幂等、限流、鉴权三件套缺一不可。

6. 工程规范：按语言或框架产出清单与反模式。

另外附一张五维代码质量量表（正确性 / 可读性 / 测试 / 安全 / 性能），每维 1–5 分，方便在评审中形成共识。

适用边界

• 它是辅助参考，不替代负责人的最终合并决策，也不提供任何专业资质判断；
• 纯方法论与模板，不接付费服务、不调用外部 API、不需要密钥；
• 涉及凭证、密钥的内容只给脱敏示例，不处理真实敏感凭据；
• 不鼓励绕过安全机制或访问未授权系统。

输出贴合度取决于你喂进去的信息，人群 / 场景 / 约束写得越具体，交付物越能直接用。