评估战略性用例

识别并构建 Devin 的战略性用例

战略性用例是指可以拆分为独立、可重复子任务的大型高业务价值项目。每个切片对应一个 Devin 的工作量,因此应当简单直接(人工工程时间少于 90 分钟)且可增量完成。

要点总结 — Devin 用例要求:

1. 大量可重复的子任务(切片)
2. 初级工程师难度级别的子任务
3. 相互独立且可增量完成的子任务
4. 具备客观验证机制的子任务
5. (推荐):尽量减少项目依赖

必要特征

从战略角度来看，理想的 Devin 使用场景应当是_浅而广*，而不是*深而窄_。

复杂的全新功能（即便是重复性的）通常难以在大规模应用中保持足够的可靠性。

在进行水平扩展时，大量横向且简单的改动（例如 SonarQube 报告的问题）可以带来极高的投资回报（ROI）。

任务切分得越简单，整体项目就越可靠。

切分使用场景 [重要]

迁移、重构、现代化改造以及技术债务积压工作都是非常适合的使用场景。例如，可以考虑一次代码迁移。

将这次迁移拆分成相互独立的切片，每个任务在单独的 Devin 会话中完成。

验证

一个 slice 应该是项目中最小的原子单元（文件、notebook 或模块），并且需要满足：

1. 人工工程工作量少于 90 分钟
2. 有验证代码变更的方式（测试、构建、CI 检查或自定义验证脚本）

每个 Devin 必须能够客观判断自己是否已成功完成任务。在完成验证之前，它应当继续迭代，利用详细的堆栈追踪或错误日志进行排查。

每个 slice 应尽量避免依赖过多组件或需要与过多平台交互。让 Devin 专注在代码变更本身！

每个 slice 必须是_隔离的且增量的_。利用 Devin 的并行能力，一次完成一个 slice 的迁移。在人工审查之后，将每个 PR 依次合并到 master。

Devin 用例的整体模型：

Devin 必须在单个 slice 级别上尽可能可靠，这样在对数千个 slice 进行并行处理时，才能在大规模下保持高可靠性。即使错误率很小，在规模放大后也会导致大量错误变更。

由客户提供

• 为每个切片中的每一步提供清晰、详细的说明（对端到端流程进行详细撰写或录制视频会非常有效）
• 多个代码变更的前后示例（输入/输出对）
• 为每个切片中所需的所有依赖项向 Devin 授予访问权限

示例

持续性的技术债务任务（例如 PR 审查或 QA 测试）也是非常适合的用例，前提是它们可以被拆分成多个小块。

当迁移、现代化改造和重构可以以增量方式进行时，它们是 Devin 的高价值用例。需要在同一时间将整个代码库一次性升级到新系统的迁移（而不是分批、按切片迁移）则不推荐。

延伸阅读： Nubank 迁移案例研究