问题：手动优化既慢又容易出错
你写了一个能工作的函数，但它太慢了。或者你的API响应时间在逐渐增加。或者你的测试套件需要20分钟而不是5分钟。你知道有改进的空间，但优化过程就像在黑暗中摸索。
你尝试修改一个地方，运行测试，检查数据。然后尝试另一个修改，再次运行测试。一小时后，你做了五种不同的修改，现在不确定哪个有帮助，哪个让情况更糟。你忘了提交好的版本，所以你在手动回滚更改。整个过程繁琐、容易出错，而且精神上令人疲惫。
这种情况发生是因为优化本质上是迭代的。你需要尝试不同的方法，测量结果，并保留有效的方法。但手动完成意味着你不断地在编码、运行命令、解析输出和做决定之间切换上下文。你的大脑会疲劳。你会犯错。你会忘记尝试过什么。
好的解决方案应该改变什么
更好的方法应该让你能够：
- 预先定义明确的成功标准（你在优化什么指标，如何测量？）
- 自动化尝试-测量-保留或回滚的循环，这样你就不必盯着每个实验
- 维护干净的git历史，每个实验都是一个单独的提交，可以干净地回滚
- 持续运行实验直到你中断，而不是每次实验后都停下来请求许可
- 保留所有实验的日志，这样你可以看到什么有效，什么无效
目标不是取代你的判断——而是处理优化循环中的重复部分，让你专注于定义问题和审查结果。
介绍Autoresearch技能
autoresearch技能是一个用于编程任务的自主实验循环。它引导你定义优化目标、用于衡量成功的指标以及允许更改的范围。然后它运行一个持续循环：进行代码更改、运行测试、测量结果，并根据是否改进了你的指标来保留或回滚更改。
这个技能的灵感来自Andrej Karpathy的autoresearch概念，但从机器学习训练推广到任何具有可衡量结果的编程任务。它不是魔法优化器——而是一个系统化运行实验的结构化框架。
实际工作原理
该技能分三个阶段运行：
阶段1：设置（交互式）
在任何实验开始之前，该技能会引导你定义：
- 目标：你想改进什么？（执行时间、内存使用、测试通过率等）
- 指标：如何衡量成功？什么命令产生指标？越低越好还是越高越好？
- 范围：哪些文件可以修改？哪些是禁区？
- 约束：对每次实验的时间、依赖项、API兼容性等有任何限制吗？
- 实验预算：运行多少次实验，或者运行到中断为止？
这个设置阶段是交互式的——该技能直接向你提问并记录你的答案。它不会假设任何事情或跳过步骤。
阶段2：分支和基线
一旦你确认设置，该技能会：
- 创建一个新的git分支（例如，
autoresearch/mar17） - 读取所有范围内文件以理解当前代码
- 初始化结果日志（
results.tsv）来跟踪实验 - 在未修改的代码上运行基线测量
阶段3：实验循环
然后它进入一个持续循环：
- 思考：分析之前的结果并生成假设
- 编辑：对范围内文件进行集中、最小的更改
- 提交：创建带有描述性消息的git提交
- 运行：执行你的指标命令
- 测量：从输出中提取指标
- 决定：如果改进了指标则保留更改，如果没有则回滚
循环会持续进行，直到你中断它或达到实验预算。每个实验都记录在results.tsv中，包括提交哈希、指标值、状态（保留/回滚）以及更改的描述。
这个技能何时适合你的工作流程
autoresearch技能是为特定类型的问题设计的。当以下情况时它工作得很好：
- 你有可衡量的指标：你可以量化什么是“更好”（更快的执行、更低的内存使用、更高的测试通过率等）
- 优化是迭代的：你需要尝试多种方法并观察什么有效
- 更改是局部的：你可以定义可能被修改的文件的清晰范围
- 你想探索解决方案空间：与其确切知道要更改什么，不如让代理尝试不同的方法
良好的使用场景
- 性能调优：优化慢函数、减少API延迟、提高数据库查询性能
- 内存优化：减少数据处理管道中的内存使用
- 测试套件优化：在保持覆盖率的同时减少测试执行时间
- 构建时间优化：加快编译或打包速度
- 代码简化：在保持功能的同时降低复杂性
- 基准改进：提高标准化基准测试的分数
何时不应使用
这个技能不适用于：
- 一次性任务：如果你确切知道要做什么更改，直接做就好了
- 简单的错误修复：如果修复是显而易见的，不要运行实验循环
- 代码审查：这不是用来审查现有代码的
- 没有可衡量指标的任务：如果你无法量化成功，该技能就无法评估实验
- 探索性编码：如果你是在试图理解问题而不是优化解决方案
评估这个技能是否满足你的需求
在使用autoresearch技能之前，考虑以下问题：
你有明确的指标吗？
最重要的要求是一个可衡量的指标。你需要：
- 一个命令来产生指标（例如，
npm run benchmark、pytest --tb=short、time ./build.sh） - 一种提取命令输出中数值指标的方法
- 一个方向：越低越好（如执行时间）还是越高越好（如测试通过率）？
如果你无法定义这些，该技能就不适合你的用例。
你能定义范围吗？
你需要指定代理可以修改哪些文件。这对安全性很重要——你不希望代理更改配置文件、文档或不相关的代码。要具体说明什么在范围内，什么是禁区。
你对自主操作感到舒适吗？
一旦循环开始，该技能就会自主运行。它不会在每次实验前请求许可。它会自动进行更改、运行测试和回滚更改。你需要对这种自动化水平感到舒适，并相信你定义的约束会保持其安全。
你有时间审查结果吗？
该技能会产生所有实验的日志，但你需要审查结果以理解什么有效。自主循环节省了尝试-测量-回滚循环的时间，但你仍然需要分析结果。
实际考虑和安全性
设置要求
该技能需要：
- Git：你的项目必须是一个git仓库
- 终端访问：该技能需要在你的终端中运行命令
- 可衡量的指标：如上所述
安全功能
该技能有几个内置的安全机制：
- 范围约束：它只修改你明确允许的文件
- Git提交：每个实验在运行前都会提交，这样你可以回滚任何更改
- 基线测量：在进行任何更改之前建立基线
- 自动回滚：不改进指标的更改会自动回滚
- 简单性策略：默认情况下，它更喜欢更简单的解决方案而不是复杂的解决方案，即使改进较小
使用前需要检查什么
在运行该技能之前，你应该：
- 审查仓库：该技能来自GitHub的awesome-copilot仓库，拥有超过37,000个星标，并且积极维护
- 检查许可证：它是MIT许可证，所以你可以自由使用
- 理解约束：该技能不会在未经你批准的情况下安装新的依赖项或进行环境更改
- 测试指标命令：确保你的指标命令正常工作并产生一致的输出
- 定义清晰的边界：具体说明哪些文件在范围内以及哪些约束适用
需要考虑的限制
- 不适用于所有任务：如前所述，它只适用于具有可衡量指标的任务
- 需要明确的目标：像“让它更好”这样模糊的目标不会奏效——你需要具体、可衡量的目标
- 可能找不到全局最优解：像任何爬山方法一样，它可能会陷入局部最优
- 时间投入：虽然它自动化了实验循环，但你仍然需要时间来设置它和审查结果
开始使用
如果你已经确定autoresearch技能适合你的工作流程，以下是处理方法：
- 从一个明确的问题开始：识别一个具有可衡量指标的具体优化机会
- 准备你的环境：确保你的项目是一个git仓库，并且你的指标命令有效
- 仔细定义你的约束：具体说明范围、约束和实验预算
- 运行设置阶段：让该技能引导你定义所有参数
- 审查基线：在开始实验之前确保基线测量有意义
- 让它运行：启动循环并让它自主工作
- 审查结果：在循环完成（或你中断它）后，审查实验日志以理解什么有效
autoresearch技能不会解决每个优化问题，但对于正确的用例，它可以通过自动化迭代实验的繁琐部分来节省大量时间和精力。