终端里的代理任务单：开工前把规格写到可验证

先把终端里的模糊请求变成具体故障

代理最容易把时间花在猜测上：改哪个行为、哪些文件可以动、怎样算做完。开工前先把问题压成一句可以检查的话。例如，不要只写“修好配置读取”，改成“当配置文件不存在时，命令行工具应使用默认值，并继续启动”。这个描述包含触发条件和期望行为，后面才有办法写测试。

先确认自己所在的位置和当前改动，避免代理把用户已有工作当成待清理内容：

pwd

git status --short — rg --files | head -80

如果仓库已有未提交改动，任务规格里要说明代理不得覆盖或回退它们。再用 rg 搜索相关代码和测试，不要凭文件名猜实现位置： — rg -n "config|default" src tests

用四个字段框定代理的工作范围

我会在任务单里写清楚目标、现状、允许范围和验收条件。把这些信息直接放进代理的任务输入，避免先让它自由探索，再临时补充关键要求。比如：

• 目标：配置文件缺失时使用已有默认配置，命令仍应正常启动。
• 现状：读取逻辑位于 src/config.ts，相关测试位于 tests/config.test.ts。
• 范围：只修改配置读取和对应测试，不调整命令行参数或依赖版本。
• 保护：保留工作区现有改动，不运行会删除本地数据的命令。
• 验收：缺失文件测试通过，现有配置测试通过，类型检查通过。

范围要具体，但别提前规定实现细节，除非它是项目约定或兼容性要求。这样代理可以在约束内选择简单方案，而不是照着一份脆弱的伪代码施工。

先检查项目脚本，再把验收写成命令

不同仓库的测试入口并不统一。先看项目说明和脚本，再把真实命令写入规格，避免代理凭习惯运行错误的检查： — rg -n "scripts|test|lint|typecheck" package.json README.md

如果确认仓库使用 npm，并且脚本中确实定义了这些任务，可以要求： — npm test -- --runInBand

npm run typecheck — 验收不应只写“测试通过”。要说明至少新增哪类场景、哪些既有行为不能回归，以及失败时要报告什么。例如：“新增缺失配置文件的测试；运行项目测试和类型检查；若命令失败，报告完整命令与相关错误，不要删减断言来让测试通过。”命令必须依据仓库实际脚本调整，不能把示例当作通用入口。

给代理一段能直接执行的任务规格

把前面收集的信息合成一段完整请求，减少多轮追问。下面这份文本可直接粘贴到代理会话，再按仓库改路径和命令：

请修复配置文件不存在时命令无法启动的问题。读取现有实现和测试后，确认默认配置的来源，并沿用项目现有错误处理风格。只修改配置读取逻辑及对应测试，不改命令行参数、依赖或无关文件。保留工作区已有改动，不覆盖或回退它们。新增缺失文件场景的测试，并运行项目测试与类型检查。完成后说明修改文件、行为变化、执行的命令及结果；如果验证失败，报告原因，不要声称通过。

我还会要求代理在动手前简要列出计划，发现范围外问题时先报告，不顺手扩展任务。这一条能让你在成本变大之前发现误解，也让多个小任务更容易审查。

用差异和测试结果验收，而不是只看总结

代理报告完成后，先核对它实际改了什么，再相信结论： — git diff --check

git diff --stat — git diff — 对照任务里的范围与验收条件检查差异，并确认测试命令确实执行、结果与报告一致。若改动超出范围，先要求解释，不要因为摘要写得清楚就直接合并。若规格不够准确，更新规格并明确指出新边界，再让代理继续。

日常在编辑器与终端之间切换时，短而明确的任务单比长篇背景更实用。需要从 Claude Code、Codex、Gemini CLI 或 OpenAI SDK 调用模型时，Fluxo 用一个密钥和一个基础地址 https://api.fluxorelay.com 接入 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等模型；费用按实际 token 计，包括缓存读取与写入，不收月费。比如，Claude Sonnet 5.5 可以用于实现任务，DeepSeek V4 Flash 可以用于复核规格是否有歧义。若你想把这套工作流接到现有工具，可以创建一个 Fluxo 账户试用；邀请用户付费时，邀请者也会获得推荐分成。登录后如需帮助，可在联系页面留言。