在使用 AI 进行编程(Agent Coding)时,经常会遇到一个问题:AI 能写代码,但结果经常偏离预期。常见情况包括:

  • 生成的代码结构混乱
  • 修复 bug 时不断重复错误
  • 不符合个人或团队的开发习惯
  • 每次任务都像从零开始

很多人可能认为这是模型能力的问题,但实际上还有一个更关键的原因:AI 不知道你是如何解决问题的。

今天看到一个观点:如果 AI 能学习我们过去的解决问题方式,Agent Coding 的稳定性可能会明显提升。下面我们来分析一下为什么这种方法可行。

一、Agent Coding 的一个缺失:经验上下文

在实际项目开发中,我们解决问题通常不会从零开始思考,而是依赖自身经验。

例如调试问题时,大多数开发者可能会遵循类似流程:

复现问题 → 查看日志 → 缩小问题范围 → 验证假设 → 修复问题

实现新功能时也往往有固定步骤:

明确需求 → 设计 → 实现最小版本 → 添加测试 → 优化

这些步骤其实就是解决问题的经验模式

但在使用 AI 编程时,我们通常只给 AI 一个目标:

实现一个用户注册 API

这类 prompt 只描述了 结果,没有提供 解决问题的方法

因此 AI 的行为就容易变得不稳定。

二、一个简单思路:让 AI 学习问题解决模式

如果换一种方式:

不仅给 AI 任务,还给 AI 解决问题的方式

例如:

实现用户注册接口。

请遵循以下开发流程:
1. 定义数据结构
2. 实现最小 API
3. 添加输入校验
4. 添加错误处理
5. 编写测试

这种 prompt 实际上在提供一种 problem-solving pattern(问题解决模式)。AI 不只是生成代码,而是在模拟一种开发流程。从系统设计角度看,这相当于给 Agent 提供了一种经验上下文(experience context)

三、构建个人的解决问题经验库

如果希望这种方法长期有效,可以把个人经验系统化。

一个简单的方法是建立解决问题经验库(Experience Library),核心可以分为三个步骤。

1. 记录解决问题的过程

很多开发者习惯记录答案,例如:「如何解决某个 bug」。但更有价值的是记录解决过程,例如:

问题:API 返回 500 错误

解决步骤:
1. 查看服务器日志
2. 检查数据库连接
3. 验证请求参数
4. 用单元测试复现问题

关键点是:记录思考路径,而不是只记录结果。

2. 抽象可复用的解决模式

当记录足够多的问题后,可以总结出一些稳定的模式,例如:

  • Debug 模式:复现问题 → 查看日志 → 缩小问题范围 → 验证假设 → 修复问题
  • 新功能开发模式:明确需求 → 设计 → 实现最小版本 → 添加测试 → 优化

这些模式其实就是经验的结构化表达

3. 将经验作为 Agent 上下文

当 AI Agent 执行任务时,可以加载这些经验模式,例如:

你是一个编程助手。

当实现新功能时,请遵循以下开发流程:
1. 明确需求
2. 设计
3. 实现最小版本
4. 添加测试
5. 优化代码

到这一步,有没发现就是 skill 的雏形了,我们可以把这个写成我们的 skill,加到不同的 Coding 编辑器里,让 AI 自行调用,感觉可以大大提高开发效率。但是这可能会导致我们失业~

上周看了篇 Claude 发布的报告整理了当前 AI 背景下使用 Claude 最多,以及可能是高失业风险的人群,里面使用占比最多,被预测为高风险的人群就是计算机行业的工程师。

参考文档:

Hoard things you know how to do

Labor market impacts of AI: A new measure and early evidence