与 AI 和 Agent 协作

现在的大模型已经能很好地理解自然语言，Coding Agent 也能自己阅读项目、搜索代码和执行命令，所以日常使用不需要一套复杂的方法论。多数时候，只要把任务说清楚，让 AI 获得足够的信息，并在最后检查实际结果，就已经能够完成相当多的工作。

1. 明确任务的内容

Prompt 就是我们提供给模型的输入。它可以是一句话，也可以包含代码、日志、图片、文件和之前的对话。对于现在的大模型，没有必要为了写一个 Prompt 专门套用固定格式，大多数任务直接用正常语言描述即可。

例如：

解释一下 C++ 中的虚函数。

对于一个简单的知识问题，这已经足够。如果希望回答更符合自己的情况，可以继续补充背景：

我已经学过 C++ 的类和继承，但是刚开始学多态。解释一下虚函数主要解决什么问题，并结合一小段代码说明。

工程问题通常更依赖上下文。比如：

帮我分析一下这个 CAN 通信为什么会超时。

这句话本身能够提供的信息很少。如果实际情况是：

STM32H743 使用 FDCAN 控制 8 个电机，控制任务频率为 1 kHz。加入 FreeRTOS 之后，运行过程中偶尔会出现某个电机反馈超时。下面是 CAN 接收和任务调度相关代码。先分析可能的原因，不要直接修改。

模型此时知道了硬件平台、通信方式、控制周期、问题出现前后的变化以及当前任务，给出的分析一般会具体很多。

实际使用时，可以重点考虑三件事：要做什么、当前是什么情况、有什么重要限制。 这三项不需要每次都写全。简单问题一句话就能解决，复杂任务再逐步补充信息。遇到自己也说不清的问题，也可以先描述现象，然后让 AI 反过来询问：

现在只能确定机器人运行一段时间后偶尔会出现关节掉线。你先告诉我还需要哪些信息，不要急着判断原因。

2. 完成一次任务

假设现在有一个 STM32 电机控制工程，希望增加一个简单功能：

如果某个电机超过 100 ms 没有收到反馈，将它标记为离线。

进入仓库后启动 Coding Agent，例如：

cd robot_controller
codex

具体使用 Codex、Claude Code 还是其他 Agent 并不重要，下面的交互方式基本通用。

2.1 先让 Agent 认识项目

刚进入一个自己没有和 Agent 讨论过的工程时，可以先让它阅读：

阅读一下这个项目，重点看电机驱动、CAN 接收和任务调度相关代码。告诉我电机反馈目前是怎么保存和更新的，先不要修改任何文件。

这一步很有用。可以先判断 Agent 有没有找对模块，也能顺便确认它对现有架构的理解。如果连现有代码都理解错了，继续让它修改通常只会产生更多问题。

对于简单项目，不需要每次都走这一套。如果只是“把这个函数参数改成 const&”这种很明确的小任务，直接让 Agent 修改即可。

2.2 提出修改任务

确认 Agent 对项目有基本认识以后，再给出需求：

我希望增加电机离线检测。每次收到反馈时更新时间戳，如果连续 100 ms 没有收到某个电机的反馈，就把这个电机标记为 offline。先分析一下放在哪一层实现比较合适，以及预计需要修改哪些文件。

这里先让 Agent 分析方案，主要是为了避免它一上来就在不合适的位置加入逻辑。例如同样是“判断电机掉线”，可以写在 CAN 回调、Motor Driver、控制任务或者上层状态管理中，放在哪里会直接影响后面的代码结构。

如果方案没有明显问题，就可以继续：

按这个方案修改。尽量保持当前项目的代码风格，不要顺手重构其他模块。修改完成后编译一次。

接下来 Agent 会修改代码并执行构建。如果编译出现问题，可以直接让它根据错误继续处理，不需要把 Terminal 的报错重新复制到聊天窗口。

这就是 Agent 和普通代码生成工具一个很明显的区别：它能够形成一个连续过程。

阅读工程
→ 分析任务
→ 修改代码
→ 编译
→ 读取错误
→ 继续修改

实际开发时，这个过程不需要严格遵守固定顺序。小修改可以直接做，复杂问题可以先分析；Agent 做到一半发现方向不对，也可以立即打断并补充条件。

不要把 Agent 当成一次性代码生成器

Coding Agent 很适合通过多轮交流逐渐完成任务。

比如修改完成以后发现实现里每次都遍历所有电机，可以继续问：

现在这个实现会不会增加 1 kHz 控制任务的执行时间？分析一下当前开销，有必要的话再优化。

或者发现它动了太多文件：

这次任务只需要增加离线检测，为什么修改了 control_task.cpp？先解释原因，如果没有必要就恢复这部分修改。

开发者仍然控制任务方向。Agent 只是能够自己完成更多中间步骤，因此我们可以把精力更多放在需求、架构和结果判断上。

3. 检查 Agent 做了什么

Agent 最后的回答通常会写“修改已完成”“测试通过”之类的话，这只能作为执行过程的说明。真正应该关心的是项目里到底发生了什么。

如果项目使用 Git，最简单的方法就是查看：

git status
git diff

至少确认它改了哪些文件，增加和删除了哪些内容，有没有碰到任务之外的代码。对于规模不大的修改，Diff 通常几分钟就能看完，可以避免很多莫名其妙的问题。

之后根据任务做实际验证。代码修改至少应该编译；有单元测试就运行测试；脚本和算法最好真正执行一次；接口和依赖相关的问题可以再核对官方文档。机器人控制代码还需要经过仿真和实机测试。

这里需要区分两件事情：

编译通过说明语法、类型和链接等问题基本成立，但不能证明控制逻辑正确。

例如 Agent 把角度单位理解错了，代码完全可能正常编译；控制周期写错一个数量级，也不一定产生任何编译错误。

发现 Agent 改坏了也不用太紧张，这正是使用版本控制的意义。如果当前修改没有价值，可以恢复文件或者回到之前的 Commit，再换一个方案。使用 Agent 以后，保持比较清晰的 Git 工作流反而更加重要，因为代码变化速度会明显加快。

4. 权限、安全与使用边界

Coding Agent 能力越完整，能够执行的操作也越多。读取文件、修改代码和运行编译通常风险较低，但执行系统命令、删除文件、修改环境、操作远程仓库时需要更加注意。

例如下面这些操作的影响范围就完全不同：

cmake --build build
pip install ...
sudo apt ...
rm -rf ...
git reset --hard
git push

不需要因为存在风险就禁止 Agent 执行所有命令，否则很多自动化能力也失去了意义。更实际的做法是：普通开发操作可以正常交给 Agent，涉及大量删除、系统权限、远程仓库和不可逆修改时，知道它准备做什么再确认。

另一个容易忽略的问题是数据。Agent 在处理项目时可能会读取源代码、配置文件和终端输出，然后把这些内容发送给模型服务。因此要特别注意：

• API Key 和各种 Token；
• SSH 私钥；
• 密码和账号信息；
• .env 等配置文件；
• 未公开的团队代码和文档。

如果使用官方模型服务，需要了解对应产品的数据政策；如果使用第三方 API、中转站或者其他 Provider，更应该清楚自己的代码最终会经过谁的服务器。涉及敏感内容时，不要默认一个“能用”的服务就一定适合发送私有数据。

机器人开发还有一个和普通软件项目差别很大的地方：代码最终可能直接控制真实硬件。Agent 修改网页代码出现问题，通常只是程序不能正常工作；如果错误出现在电机使能、力矩控制、关节限位或者故障保护中，机器人可能直接产生异常动作。

因此涉及实际执行器的修改，仍然要按照正常的机器人调试流程处理。根据具体系统，可能包括仿真测试、检查关节方向和单位、限制速度与力矩、悬空测试、低功率运行以及准备急停。尤其是 Agent 修改过安全保护、通信异常处理和控制参数以后，不应该因为程序成功编译就直接进行完整实机测试。

AI 和 Agent 可以承担很多代码阅读、实现和调试工作，但最终仍然需要开发者知道机器人即将执行什么。

到这里，日常使用 AI 和 Coding Agent 所需要的基本方法其实已经介绍得差不多了。把任务说清楚，让模型获得足够的上下文；让 Agent 去处理代码搜索、修改和验证等可以自动完成的步骤；最后查看实际修改和运行结果。剩下的大多数能力，都可以在真正遇到需求以后再继续学习。