用稳定的行为约定交接 Agent 任务

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你把 CLI 的 JSON 输出修复排到下周，文件可能在此期间改名。教学接口 reportResult(result, options) 服务于查询命令；当前成功时输出 JSON，失败时输出纯文本。要求 –json 下两种结果都可解析，同时保留成功退出码 0、失败退出码 1。

具体做法

交接写明当前与目标行为、可独立验证的输入/输出和范围，提供稳定接口名与版本背景。行号可以作为当前观察证据，但不能成为任务的唯一要求。接手者在现有代码中重新定位接口，修复行为并执行验收；不因文件改名就失去目标。

反例

下周打开 handler.ts 第 80 行，加一个 switch。做完就算 JSON 输出修复完成，不需要说明失败输出或退出码。

改进写法

修复查询命令的 reportResult 输出行为：--json 模式下，成功与失败都输出可解析 JSON，保留 0/1 退出码；错误 JSON 应含可辨识错误信息。非 JSON 模式与其他命令不变。先在当前代码定位接口；用成功和失败输入分别验证 JSON 解析与退出码。当前文件位置仅作线索，改名不改变这些要求。

为什么这样改

位置型任务描述依赖当前布局，又没有明确完成行为。稳定接口和观察得到的前后差别能跨越文件移动，验收样例则让接手者知道修改是否解决了原问题。

如何验证

教学验收分别提供一个查询成功和一个查询失败输入，捕获标准输出和进程退出码。两者在 –json 下可解析，成功为 0、失败为 1；普通文本模式仍按原契约工作。

把接口文件改名后再阅读简报，仍应能确定目标。仅添加 switch、只修成功路径或改成错误也返回 0，都不通过。

适用边界

稳定的行为契约仍需真实版本与接口核对，名称也可能变更。即时缺陷证据可引用精确行号，不需要禁止所有路径；本方法避免的是把短期位置当唯一长期需求。