我会如何试用一个 AI Coding 开源项目

试用 AI Coding 项目，不能用“帮我写一个函数”这种无上下文任务。更有区分度的测试是：在同一个旧仓库里补失败测试、修边界 bug、解释 diff、运行检查并撤销错误方向。

三个候选的公开证据

| 项目 | 技术栈与形态 | release/tests/docs/demo | 许可边界 | | --- | --- | --- | --- | | Aider | Python 终端工具，围绕 git 仓库编辑 | Releases、tests、文档、README 示例 | 以仓库当前 LICENSE 为准 | | Continue | TypeScript 为主的 IDE/CLI 历史基线；仓库已停止主动维护并只读 | 最终 2.0.0 于 2026-06-19 发布；旧测试、文档与配置可用于回顾设计，不代表后续兼容维护 | Apache-2.0；只适合历史复测或迁移评估 | | OpenHands | 带运行环境和轨迹的自主开发代理 | Releases、tests、docs、演示入口 | 开源代码为 MIT，同时存在 enterprise 目录和商业边界，需按目标路径核对 |

这些目录和页面说明项目公开了哪些材料，不构成本站安装、兼容性或性能实测。Continue 的只读状态与最终版日期按 2026-07-15 官方 README/Release 页面核验，因此本文不会把它列入新项目推荐。

适合场景也要先分开：Aider 面向习惯终端与 git 的开发者，OpenHands 面向愿意在隔离执行环境验证自主任务的团队；Continue 只用于研究旧 IDE 上下文方案、复测现有部署或规划迁移。三者不是按“自动化程度”从低到高的同一产品。

共同考题

选择有测试和 lint 的小型仓库，固定同一个 commit。任务是修复一个空输入边界 bug，不改变公共 API，并新增回归测试。给三个工具相同 issue、允许修改的目录和验证命令。

为了让任务接近真实工作，可以选一个已有 30 到 50 个测试、包含贡献指南和类型检查的旧仓库。先由人工定位：空数组进入聚合函数后返回错误类型，正确修改只应涉及实现文件和一个测试文件。然后新建三个相同副本，禁止工具读取副本外目录。这个规模既需要理解上下文，又不会把结果混入架构设计能力。

记录时不要只写“修好了”。Aider 是否主动要求加入相关文件，OpenHands 是否在运行命令前解释权限，都属于当前候选结果；Continue 是否引用了正确规则文件，只在历史复测或存量迁移时记录。若一个工具通过删除失败测试获得绿灯，另一个工具正确报告现有测试本身有问题，后者更值得投入。评测要奖励诚实暴露冲突，而不是只奖励终端最后一行绿色。

先测上下文，不测生成速度

记录工具主动读取了哪些文件、是否找到贡献指南和相关测试、是否误碰生成文件。当前候选比较 Aider 的终端/git 路径与 OpenHands 的环境轨迹；Continue 的 IDE 上下文只保留在历史证据列，不参与新项目推荐排序。

再测四个动作

第一轮只让它补失败测试；第二轮允许修改实现；第三轮要求解释每个 diff；第四轮故意给出错误方向并要求撤销。没有可读 diff、无法恢复工作区或隐瞒未运行测试，直接记为失败。

上手成本怎样控制

Aider 可先投入约一小时验证终端流程；Continue 若是存量环境，只安排迁移清点，不再为新项目投入集成时间；OpenHands 还涉及运行环境与更高权限，应从隔离工作区开始。时间是试验预算，不是对安装速度的承诺。

结果表只写可观察事实

记录提交哈希、工具版本、输入材料、修改文件、执行命令、测试输出、人工退回原因、token/费用字段和清理结果。没有实际运行就保持“未测试”，不能根据 README 预填“通过”。

为什么 release 和测试仍不够

活跃 release 说明维护者在发布，测试目录说明项目有自动化资产，docs/demo 说明存在学习入口；它们无法证明工具理解你的私有代码、不会泄露上下文或能遵守团队审查规则。公开证据只决定是否值得进入试用。

最终选择标准

优先选择能限制范围、留下清晰 diff、执行既有检查并诚实报告失败的工具。生成更多代码不是优势；减少不可审查改动才是。

常见失败：三种工具用了三套题

有人会给 Aider 一个小修复，再让 OpenHands 从零搭应用，最后比较“完成度”；也有人把只读的 Continue 旧结果与当前候选混成同一维护结论。这些结果只反映题目或时间点差异。另一种失败是只保存最终 diff，不保存工具版本、输入上下文和被拒绝的尝试，导致升级后无法复测。

同一轮必须固定代码仓库、commit、issue 文本、允许目录、模型和验证命令。IDE 自动提供的上下文、终端手工加入的文件和自主代理读取的目录都要记下来；上下文获取方式本身就是比较对象，不能藏在结果之外。

替代方案和是否值得投入

若任务主要是单文件补全，编辑器自带补全或一次人工修改就是更低成本基线；若任务需要跨文件解释但不允许自动执行，代码搜索加聊天式助手可能比自主代理更合适；只有重复的仓库级修改需要运行测试、处理失败并产生可审查轨迹时，才值得评估 OpenHands 这类执行环境。

我的投入顺序是先人工基线，再试 Aider，最后才开放隔离环境给 OpenHands。Continue 只在团队已有存量配置时进入迁移复测。任何当前候选若连续两次扩大修改范围、没有实际运行测试却声称完成，或清理后无法复现，就停止投入，不用为了写测评继续消耗代码审查时间。

安全边界检查

把测试仓库换成不含客户代码和生产凭证的副本；关闭不需要的网络与写权限；明确工具能否读取父目录、shell 历史和环境变量。尤其是自主执行型工具，默认权限应比人工开发环境更小。若文档没有解释隔离方式，就把它列为待验证项，而不是自行假定安全。

最小试用步骤与判定表

分别给上下文命中、diff 范围、测试执行、错误说明、撤销能力和敏感信息处理写“通过/失败/未验证”。任何一项未实际运行都不得根据 demo 填通过。最终结论应保留工具版本和仓库 commit，方便下次升级后复测。

动作顺序固定为：建立人工基线，复制三份工作区，执行同一任务，复核 diff 与命令，最后恢复干净状态。完成一轮后只选择最有希望的候选做第二个任务，避免把试用变成同时维护三套开发环境。

同一任务至少由人工先做一次，形成可接受改动范围；否则无法判断工具是在减少工作，还是把审查成本转移给后来的人。

复盘时还要比较人工审查分钟数，而不只比较生成秒数。一个候选快两分钟，却让评审多读五个无关文件，整体效率反而下降；这类成本应写进结论。

最终记录应允许团队下次原样复测。