AI编程的一些思考
AI编程的一些思考
任务的划分
我们不妨将任务按照如下标准进行划分
- 对于上下文的依赖
- 问题的确定性
对于上下文依赖度有两个评价 高 / 低: 高的上下文依赖度指的是: 如果一个任务无法从少的信息中找到解决方案, 例如需要读相关的多个文件/文档/DB才能够有解决方案, 那么我们可以认为这是高上下文依赖.
问题的确定性指代的是: 目标和解决路径是否清晰, 判断标准是否是客观的. 如果能够给出一个详细的解决方案(修复XX文件的XXbug), 有明确的判断标准(API接口返回XXX), 我们可以认为这个问题的确定性是高的.
按照这两个维度, 我们可以划分出四类任务:
- 高依赖, 高确定: 修复BUG
- 高依赖, 低确定: 设计产品的架构, 拆分微服务
- 低依赖, 高确定: 实现算法 / 写一个脚本
- 低依赖, 低确定: 构建产品 demo / mvp
哪些任务AI完成的好呢? 依赖越低, 确定性越高的任务, AI完成的越好.
如果一个任务难以完成, 那么可能是什么问题?
我觉得可以归类为两个主要原因:
- 需要构建的上下文非常的复杂, 无法靠CodeIndex或者context engine 完成构建完整的信息
- 指令不够清晰: 需要在XX条件下, 解决XX文件, 验证方式是XX, 参考XX
Code Agent能够一定程度上解决问题1, 因为会主动的通过文件读取/Grep的方式来填充上下文, 但是对于问题2, 是几乎无法解决的: PM给你提了一个一句话需求.
信息与指令
上下文的本质就是填充信息和指令
-
信息: 是否包含解决问题的线索, 实际上就是上下文依赖性
-
指令: 是否明确的指出来要解决的问题, 怎么解决, 怎么验证, 实际上就是问题确定性
信息
Coding应该填充什么信息: 人和AI需要知道的信息一样多.
或者这样说: 我们是怎么解决一个问题 / 实现一个需求的?
我觉得一个误区是: 除了Repo之外, Coding就不需要任何上下文了, 可是现实世界里: 从0-1的了解一个项目, 开始写代码需要多少准备?
- 项目的背景 / 业务 / 目标用户群体
- 产品需求 / 迭代方式 / 历史项目的功能
- 环境依赖 / 三方依赖 / 服务依赖 / 约定 & 配置
- 代码结构 / 服务架构 / 封装的命令 / 以及一些Tricky的小设计
完成以上准备之后, 我们才能够基本认为能够开始接受写一些简单的功能开始更快的上手.
但是当我们开始使用AI Coding时, 我们几乎立刻忽略了AI每一次都在从头开始, 几乎每一次都从Context里重新学习这些信息.
为什么总是觉得AI表现不够稳定, AI老是乱改你的代码...
我觉得这就是原因: LLM一直在一个狭小的鸟笼中起舞, 一直在一个几乎可以被称之为严苛的环境中工作.
一个基本的启示是: 用各种rules也好, 用context engine也好, 给出充分的信息 或者 给出获取信息的线索(例如去哪里读文件之类的)
指令
指令是什么?
解决什么问题, 怎么解决问题, 怎么验证问题.
但是很不幸的是, 能够说清楚这三点的是少数人.
前端时间的SPEC / SOLO做的都是一样的事情: 试图填充更多的信息, 试图用看起来更清晰的指令来获得更好的编程效果.
但是答案是: 不够好.
你没有办法在一个不够好的底座(一个不清晰的需求/问题)上建造摩天大厦. 换句话说: 你要在一开始就给出一个出色的的指令.
出色的指令? 可是什么是出色的指令?
- 简单清晰, 可读可理解的表达方式
- 详细描述遇到的问题, 复现的步骤
- 如有: 给出参考的解决步骤(例如使用recorder做过录制), 可能的解决思路
- 如有: 哪些代码/文件夹下可能会有帮助
- 怎么验证问题, 是否要验证问题
如果对应到新的需求开发上, 那就变成了:
- 简单清晰, 可读可理解的表达方式
- 背景 / 历史相关功能 / 用户故事
- 详细的需求描述
- 如有: 技术架构 等等信息
- 如何判断为可以使用
总之: 不是仅仅给出一个报错 / 一个一句话需求 / 特别发散但是没有客观评判标注的指令.