第 03 篇2026.10.06

让 Agent 按你的想法继续改

从自己的第一次修改开始，让 Codex 或 Claude Code 接住任务、检查结果，再学会留规则和交接。

当你已经用 Codex 或 Claude Code 做过一次修改，接下来要学的是怎样把下一条任务说清楚，让它沿着已有项目继续做，并检查改动有没有生效。

先发一条小任务#

沿用你已经能打开的项目，用自己刚才的操作来描述想改的地方。在 Codex 或 Claude Code 的同一项目里，可以这样说：

我想把当前应用里的：[说清你要改的位置和行为]，改成：[你希望看到的结果]。
请先查看相关实现，保留已有可用功能，完成这次修改。
改完运行检查，告诉我该怎么亲手确认。

把方括号里的内容换成自己的需求。

你负责说明想要的结果和实际反馈；Agent 负责查看项目、实现和检查。检查后再给下一条任务。

留一个短入口，把资料放回项目#

项目入口应能找到目标、组件边界、运行命令、配置说明和当前任务。长期约束放在规则文件，具体进行到哪一步放在接力记录；避免把易过期状态写成永久规则。

轻联的入口是几份随 npm 包公开的文件：

项目入口（轻联）
  README.md             能做什么、怎么启动、尚未提供什么
  CONTRIBUTING.md       运行命令、必须保留的约束、安全禁区
  docs/architecture.md  两个运行位置、模块分工
  docs/roadmap.md       已实现、后续候选

CONTRIBUTING.md 只有几段，却把 Agent 最容易走偏的地方都写了：用 Node.js 24，依次是 npm ci --ignore-scripts、npm run dev、npm run check、npm test，没有前端构建步骤；保留紧凑侧栏、真实的设备状态和分开的内存、磁盘读数；GET 请求和 MCP 永远不能触发 SSH 连接；测试注入子进程结果，不连接真实主机；不要只为验证一个界面修改，就去安装服务或部署 Docker。

入口文件用你所用客户端支持的方式加载。文件写在仓库里，不等于 Agent 已经读过；第一步让它复述目标与约束，能发现不少理解偏差。

先分清这几样东西#

模型分析材料，Agent 根据目标选择下一步，工具执行实际操作。Skill 提供某类任务的做法，项目规则留下长期边界，工作流安排检查过程。MCP 是连接工具与数据的协议；接上它之后，仍要知道工具有哪些权限。

01 / 一次任务需要哪些材料

从上到下是一轮处理。Skill 和规则提供方法与边界，工具结果要回到下一轮判断。

拿轻联举例。把本机 /mcp 加到 Agent 后，它能用六个工具：四个本机只读工具（读取连接器状态、列出资源、列出 SSH 配置里的别名、解释连接模型），再加同账号设备查询和获准的日志读取。读资源清单不会发起 SSH；device_center_list_ssh_candidates 只读配置里的别名，不读密钥，也不连接主机。日志要目标设备单独授权才能读，不能用 MCP 给自己授权。

设备说明里的文字也只是描述性数据，不能充当提示指令、操作授权或身份验证。接上 MCP 之后，能不能做某件事，仍由服务自己判断。

给 Agent 的材料也要挑。例如给设备加一条用途说明，它需要知道设备记录存在哪里、MCP 工具返回哪些字段、改完怎样检查。相关代码与原始失败记录比整个聊天历史更有用。不要为了“上下文多”把无关目录、凭据和全部日志一起塞进去。

一次只改一条能验证的路径#

“把设备管理做好”很难验收。“在设备说明里填上名称和用途，保存后刷新还在，本机 Agent 读资源清单时能看到”就明确得多。把允许修改的范围、不能跟着变的东西、预期结果和检查方式一起交给 Agent。轻联的设备说明文档就写明：改名不改变主机名、SSH 别名、密钥、配对或日志权限。

02 / 小步实现的检查循环

箭头表示工作推进；侧边返回线表示需要修正时再循环，不是让 Agent 无限重试。

检查失败时，先保留输入、期望、实际结果和版本。让 Agent 根据这份材料修正，不要只说“你再认真检查一下”。完成以后，留下文件变更与验收证据，下一次任务就有可靠起点。

规则、Skill 与记忆分别放什么#

规则写长期有效的边界，例如轻联的“GET 请求和 MCP 不能触发 SSH 连接”。Skill 写反复出现的方法，例如改完界面后，怎样用独立的预览数据库和当前电脑的真实读数做浏览器验收。记忆保存经过验证的经验，例如“待刷新”只说明快照旧了，不代表密钥过期；旧经验还要按当前环境重新判断。

03 / 长期材料与本次状态

两列是不同更新频率的材料。把它们分别维护，能减少旧状态误导新会话。

Skill 不是另一套模型，也不会自动扩大操作权限；怎样把一套方法整理成别人也能用的 Skill，放到第 17 篇再讲。我的创建技能、技能盘点和技能同步可作辅助材料。

轻联是怎么做的#

当时想解决什么。 资源能读到之后，Agent 仍然不知道每台设备适合做什么，而这正是我最初想省掉的那段解释。

交给 Agent 什么。 一次范围明确的修改：给设备加名称、类型、用途、标签和手动登记的服务清单，再加一个“采集一次”按钮。边界写在 docs/device-profiles.md 里：服务与应用只由用户手动登记，不扫描应用、端口或进程；名称最多 80 字符、用途最多 240 字符；多人同时修改时，拒绝覆盖较新的版本。

得到什么。 这次修改随 10 月 7 日的 0.2.0-beta.2 发布。设备卡片显示名称、类型、最多三个标签和一行用途，搜索能按用途和服务名查找；本机 MCP 的 device_center_list_resources 同时返回名称、原始名称和设备说明。

怎样检查。 自动测试覆盖字段校验、保存与刷新、并发修改冲突、离线时保留旧数据和 MCP 可读性等；浏览器验收用独立的本机预览数据库和当前电脑的真实读数，没有连接真实的远程主机。

为什么调整。 有两件事这次没做，都写进了文档：本机说明和云端说明还不能双向同步，两边各自生效；旧 Driver 要升级后才能响应云端的手动采集。同步放进了路线图的后续候选。把“没做什么”写清楚，下一个会话就不会以为它已经完成。

换成你自己的项目#

用第二章的产品单页，挑一条最小路径，让 Agent 先补入口，再小步实现，最后留下交接记录。

请先读 docs/product-brief.md 和项目里现有的说明文件，用几句话复述目标和约束，等我确认后再动手。

1. 补齐项目入口（按当前客户端支持的方式，例如 AGENTS.md、CLAUDE.md 或 CONTRIBUTING.md）：运行与检查命令、必须保留的约束、不能做的事。
2. 只实现产品单页里的这一条路径：[写出这条路径]。改完运行检查，告诉我怎样亲手确认。
3. 把已做、未做、检查结果和下一步写进 docs/handoff.md。

不改与这条路径无关的代码，不写入密钥或私人路径。

把方括号里的内容换成自己的需求。

做完以后另开一个会话，只给它项目入口和 docs/handoff.md，问它当前缺什么、下一步做什么。

Agent 复述的目标和约束与入口文件一致，有偏差的地方已经补进入口文件
这条路径亲手走通，检查输出记在 docs/handoff.md 里
docs/handoff.md 分开写了已做、未做、证据和下一步
新会话只读入口和交接记录，就能准确指出当前缺口

如果第二个会话开始重写已完成的代码，先补入口与状态，不急着堆更多提示词。下一章把服务边界画出来，让 Agent 知道每段代码应该放在哪里。

格式说明可查 Agent Skills，连接概念可查 MCP 官方入门。