最近一年，我使用 AI 编程工具的方式变了很多。

最初，我会把一段报错贴进去，或者让它生成一个函数。效果好的时候很惊喜，效果不好就当搜索引擎。后来工具开始能够读取仓库、修改文件、运行命令，我才感到它不再只是“回答问题”，而是在进入开发流程。

这也带来一个反直觉的变化：能力越强，我越少直接接受结果。

我现在通常先让它做这些事情：

  1. 找到相关代码和调用链；
  2. 复述它对问题的理解；
  3. 列出准备修改的文件；
  4. 实施尽量小的改动；
  5. 运行测试或给出无法验证的原因；
  6. 展示最终差异。

这个流程看起来比“直接生成”慢，但返工少了很多。

参与多 AI 编程源看板的适配时，我也发现真正麻烦的不是多接一个模型，而是如何把不同来源放进同一种工作流。它们的会话结构、状态、配置方式和输出格式不同，需要 Provider 层转换为统一模型。否则每增加一种来源，页面和业务逻辑都会增加一套分支。

Agent 的工程问题与普通后端并不遥远。工具调用要有 Schema，任务要有状态，外部服务要有超时，危险操作要确认，过程要能审计。区别在于模型输出具有不确定性，因此每一层边界都更重要。

我给自己保留了几条使用约束：

  • 不把密钥、客户数据和完整私有代码随意发给外部服务；
  • 不因为代码“看起来对”就跳过编译和测试；
  • 不让 AI 擅自扩大修改范围；
  • 不用它编造自己没有做过的性能数字和项目成果；
  • 遇到陌生 API，回到官方文档核对。

AI 最有价值的时候，不是代替我打字，而是让我能更快建立上下文、比较方案和验证想法。它扩大了个人能处理的范围，也把“是否真的理解改动”这件事变得更重要。