选择一个有用的首个 AI 任务

选择可以验证的任务

首个有用的任务应帮助你了解工具在当前环境中如何工作，也应产生可以检查的结果。针对已知缺陷的小修复通常能同时满足这两个条件。

不要仅因为演示效果出色就选择某项任务。大范围重新设计可以带来许多可见变化，同时掩盖错误假设。小任务可以显示智能体是否阅读指令、遵守范围，并准确报告失败的检查。

不必选择最简单的任务。应选择团队能够识别正确结果，并解释其正确原因的任务。

考虑报表应用中的三个虚构请求。

解释任务帮助你检查推理与证据。回归测试增加了一项受控操作。架构任务以后可能有价值，但需要更完善的任务说明和审查流程。

首次练习应选择回归测试。使用虚构日期和本地分支。明确生产访问、依赖升级和无关重构都不在范围内。

“改进日期处理”留下了太多解释空间。使用具体条件：“输入包含无效日历日期时，返回验证错误。对于有效日期，保留文档规定的输出。”

补充有效和无效输入的示例。指出现有测试命令。要求智能体先检查当前行为，再修改文件。修改后，要求简要说明缺陷及相关证据。

区分任务结果与活动。“智能体写了一个测试”描述的是活动。“测试能够检出已知缺陷”描述的才是证据。如果测试在正确和错误代码上都通过，就不能证明实现了预期保护。

练习过程中，记录智能体在哪些地方需要更多上下文。检查它是否阅读相关代码仓库指令。注意它是否修改范围外的文件，或者在没有新证据时重复无效方法。

不要立刻纠正每个细小选择。让智能体完成获准且可逆的工作，以便评估结果。如果下一项操作越过边界，或者后续工作依赖尚未解决的要求，再介入。

完成后，审查 diff 并执行相关检查。记录智能体用时，也记录自己的准备和审查时间。这些观察有助于选择下一个任务，并改进工作指令。

练习成功后，只提高一个维度的复杂度。可以从单个函数扩展到两个相关模块，也可以增加一项有文档说明的集成。始终明确权限和验证要求。

如果练习失败，先找出原因，再扩大范围。上下文缺失、要求不清、测试环境不可用和模型能力受限，需要不同的解决方法。增加自主权限不能解决全部四类问题。

如果原型持续使用，就指定维护负责人。即使代码没有变化，新的漏洞信息也可能要求采取行动。参见持续漏洞管理。