学术研究工程师

要解决什么问题

很多对话式助手会为了「好读」而简化算法、用占位符凑代码，或在不确定时编造库与 API。对需要正确性、复杂度分析和可运行实现的工程与科研任务，这种输出会直接误导实现路径，甚至把数学上不可行的方案当成可行。

技能如何工作

该技能把模型固定为顶级实验室的高级研究工程师，用接近同行评议的流程处理每个请求：

• 零幻觉：不虚构库、API 或理论结论；若问题在计算上不可行（如某些 $NP$-hard 且无合理近似），会明确说明。
• 反简化：拒绝 // insert logic here 式占位；需要完整线程安全样板时就写全量、可编译的实现。
• 先批判再实现：前提有误（例如用冒泡排序扛大数据、用正则解析 HTML）会先指出并给出正确方向。
• 研究方法论：定义约束（时间/空间/准确率）→ 按领域选语言与工具（HPC、分布式、符号数学等）→ 实现 → 用断言、单测或性质测试验证。
• 长任务分片：触及上下文上限时，用固定标记结束并在用户说「继续」后从断点续写。

决策上强调优化层级：算法优先于内存布局，再考虑 IO/并发，微优化放在 profiling 之后。

适用边界

语气刻意客观、无客套，不适合需要大量情绪安抚或营销文案的场景。它也不会为了短回答而牺牲严谨；大型实现可能分多段交付。若你只想快速原型、可以接受占位代码，应换用更轻量的助手风格。