前言#

说来惭愧，之前Claude Code、Cursor等ai agent正火热的时候，我并没有去主动了解的想法；一直都是手搓代码，顶多在 IDEA 里装个通义灵码，加点功能、查查 bug 啥的，就当图个方便

后来也试过 Trae，但用了几下觉得不太顺手，就扔一边了，后面简单使用过trae，但仍然觉得不好用；直到前几个月空闲时尝试了codex和DeepSeek Harness，才感觉自己其实压根没用明白这些强大的工具

我一直认为兴趣是驱动我个人去探索新事物或是学习的第一要素，第一次使用这些ai agents，基本是抱着玩一玩的心态接触的，它的强大甚至会给人一种自己什么都能做的错觉，平常只有去尝试使用过一个项目，才能感受到它哪里不方便；但ai可以根据你的指令自己去尝试缓解或是解决，而自己可以从实际需求中进步学习知识

对于大部分人来说，ai的起点都很简单，让他去干重复的工作，去干你自己不想做、或是不会做的事，把你脑子里想到的丢给他即可

让ai理解你的需求#

我觉得绝大多数ai实现的效果不尽人意都是因为没说清楚需求导致的

因此我在执行长任务时都会说明需求并让ai自行生成一个逐步完成的文档，这样的话如果ai对一些步骤有歧义或是自身忘记表达的需求就能在开始任务之前自行解决，大部分agent也有让ai逐步询问你来确认需求的插件，也能达到对应的效果

另外，使用全局或针对项目使用提示词，对ai约法三章可以减少部分弱智理解或是画蛇添足等情况发生，例如下面是我当时使用的简易提示词

1
# 项目约定
2

3
## 工作语言
4
- 默认使用中文交流和生成文件
5
- 遇到专业术语时，先用普通人能够理解的话术解释
6

7
## 编码前思考
8
- 明确假设，不确定时询问而非猜测。
9
- 存在歧义时，列出多种解释，不默默选定单一方案。
10
- 如果任务有明显更简单的做法，直接指出优化思路。
11
- 发现代码矛盾、逻辑不一致时及时暂停，请求信息澄清。
12

13
## 简洁优先
14
- 用最少的代码解决问题，拒绝冗余实现。
15
- 不为一次性需求创建抽象层、复杂架构。
16
- 不盲目增加扩展性、可配置性，应对“未来可能用到”的场景。
17
- 若代码可大幅精简，主动重写优化。
18
- 校验标准：以资深工程师视角判断，代码若过于复杂，立即简化。
19

20
## 精准修改
21
- 仅修改与当前任务直接相关的代码内容。
22
- 不顺手优化相邻代码、注释、排版格式。
23
- 不重构原本可以正常运行的代码模块。
24
- 严格匹配项目现有代码风格，保留原有编码习惯。
25
- 因本次修改产生的无效导入、废弃变量，可直接删除。
26
- 发现项目中原有的死代码、冗余内容，仅做文字提醒，不擅自删除。
27

28
## 目标驱动执行
29
- 执行任务前，定义清晰、可落地的成功标准。
30
- 将“修复Bug”转化为：编写用例复现问题，再调试至用例正常通过。
31
- 将“新增校验功能”转化为：针对异常输入编写测试用例，保证全部通过。
32
- 将“代码重构”转化为：完成重构后，确保原有所有测试用例正常运行。
33
- 多步骤复杂任务，先输出简短执行计划，同时标注每一步的验证方式。

实在不知道怎么写，也可以抄抄别人的，再针对项目或是个人进行修改，让ai自己来修改

对于项目，要做好容错#

就算ai充分理解了你的需求，有时可能也会意外的搞错东西甚至进行一些破坏性操作，比如搞坏运行环境、没有完全检查引用就修改相应的函数等；

让他回到上一步的操作都没法回复完全，所以要提前做好准备，等真的碰上了麻烦，就得做好焦头烂额的准备了

我平常会让ai在运行前让他自行创建一个git仓库，每步后都自动提交；

另外，ai都很喜欢运行完任务后跑测试，一定要做好环境管理或是项目中告诉它测试流程

不然可能就会出现“我寻思要这样启动”————>“启动报错，检查发现是没有依赖”————>“下载依赖错误，是哪个地方出问题”，最后你就会白白烧掉许多钱和时间再得到一坨烂掉的项目环境

很多agent都会和windows指令打架，运行时候总是会出现几个命令出错

虽然大部分情况ai都会自行解决，但看着很不爽而且浪费token，可以安装powershell 7设置好编码或是把agent运行在wsl中解决问题

去尝试用ai定制自己的体验#

我觉得批量高效准确完成批量的任务，是ai最舒服的地方

可以多使用使用他人创建发布的skill，创建自己的skill也很简单，只需要从一次对话开始，自己查看告诉他哪些不对哪些需要注意，事情解决后告诉ai让他把刚刚做的事整理成一个skill即可，多多使用修改自然会越来越符合你的需求