实现一个小功能

目标

完成一次范围受控的软件修改，并在交付前核对代码差异、测试结果和遗留风险。

准备

• 先完成理解一个现有项目，或至少知道相关模块与测试入口。
• 使用 Git 或其他方式保存干净基线；Captain Who 不替代版本控制和备份。
• 确认项目可以在本机运行现有测试。
• 初次练习建议使用“默认”权限，让文件修改和命令在关键位置等待你的确认。

步骤

1. 写清楚验收条件

选择一个小而完整的需求，例如修复一个显示问题、增加一个校验或补充一个已有接口。示例：

请为搜索框增加“清空后恢复完整列表”的行为。

验收条件：
- 清空按钮只在有输入时显示；
- 点击后清空查询并把焦点放回输入框；
- 键盘 Escape 也能清空；
- 补充覆盖这三个行为的测试；
- 不改变搜索算法和其他页面样式。

请先检查现有实现和测试，给出简短方案；确认范围后再修改。完成后运行最小相关测试并总结差异。

真实任务中，把示例替换为你的需求、边界和可观察结果。

2. 先审方案，再允许修改

检查 Agent 找到的文件是否合理，是否遗漏数据层、协议或测试。如果方案明显扩大范围，先要求缩小；不要等到产生大量 diff 才纠正。

3. 逐项处理审批

Agent 提交文件补丁、写入或命令时，审批卡片会显示安全摘要。重点核对：

• 路径是否属于当前项目；
• 修改是否触及凭据、构建发布或无关模块；
• 命令是否会安装依赖、删除数据或访问网络；
• “本轮不再询问”是否真的适合后续同类操作。

不确定时选择拒绝，并在理由中要求使用更窄的方法。

4. 要求运行最小验证

让 Agent 先运行与改动直接相关的测试、类型检查或静态检查。只有在必要时再扩大到全量检查，避免把无关的历史失败混入本次判断。

5. 人工检查改动

在右侧栏“审阅”或你的外部 Git 工具中查看最终差异。核对是否存在调试输出、意外格式化、生成文件或未说明的行为变化。

可以继续问：

请根据当前实际 diff 做一次自审：逐条对应验收条件，列出已验证证据、未验证项和可能的回归风险。不要继续修改。

预期结果

最终交付应包含有限且可解释的代码差异、对应测试、实际执行过的验证结果，以及没有被掩盖的限制。测试“已编写”和测试“已运行通过”必须分开说明。

失败处理

• 修改范围失控：停止当前 Run，保留已有结果后开启新对话，用更小验收条件重新开始。
• 文件发生冲突：不要反复覆盖。重新读取最新文件，让 Agent 基于当前版本生成新修改。
• 测试失败：先区分本次引入的失败与项目已有失败，再决定修复或记录。
• 命令结果未知：不要立即重复可能产生副作用的命令；先检查文件、进程或外部系统的实际状态。
• 模型只声称完成：要求提供 diff、测试输出和文件位置。如果没有证据，就按未完成处理。

更复杂的需求可以参考管理大型项目和使用多个 Agent 并行工作。