如何与AI结对编程：我与AI的8000行代码实践

与AI结对编程：提升工作效率的新体验

今年我提交了八千多行代码，但没有一行是我自己写的。没错，听起来有点疯，但只要体验过AI编程工具，你就会明白这种状态正在成为现实。现在每天的工作日常已经变成：给AI提需求，让它实现，出问题了给反馈，让它自己改。AI编程能力的进步速度确实惊人——去年还只能帮人补全代码，今年已经能哼哧哼哧地把整段代码撸出来了。

不妨先说说几个核心判断，再慢慢展开。

目前的当红炸子鸡当属Cursor。一开始接触Cursor，我主要用来开发AI agent的demo，比如快速搭个Gradio界面，方便演示算法微调后的对话模型。用了几天，精神上确实还把自己当程序员，但实际上更像产品经理加测试工程师。平时我们吐槽产品经理只提一句话需求，可面对Cursor时，我也忍不住希望它能从一句“做个AI对话的Gradio界面”里，读懂我内心的真实需求。

这种使用方式，不妨叫它“许愿式编程”。当然，模糊的愿望往往得不到满意的结果，下来就是反复让它推倒重来、各种改——像极了产品经理不停地提需求变更。假如AI也有内心戏，估计早就在想：“你能不能一次把需求说清楚？”

很多人用不好AI编程，根源就在这里：说不清楚需求。程序员用编程语言表达想法很顺手，但换成自然语言反而卡壳。这时候就会有一种感觉——有这个功夫把需求写清楚，我自己写都写完了。反复让AI返工，还不如自己干来得快。

但AI毕竟没有读心术，现在只能靠自然语言跟它交流。所以一个比较靠谱的认知是：把AI当做一个实习生。它没法独立完成复杂任务，需要你提供清晰的输入和反馈。一开始效率反而可能更低，因为你得花时间教它各种东西。可一旦磨合好了，效率的提升是非常明显的。

下面结合实操经验，拆开聊聊具体怎么跟AI协作。

工具选择

虽然一开始用的是Cursor，但作为一名Ja va程序员，其实并不推荐把它用在生产级Ja va项目上。Cursor更适合快速跑些Python小项目，比如批量读取数据调用大模型，做一个workflow快速验证效果——这类项目不需要精心设计，跑起来能用就行，让Cursor自由发挥没问题。

但放到生产级Ja va项目里，就不能像产品经理一样只描述需求了。这时候需要帮AI把功能点拆得非常细，经常要拆到函数级别，然后补充足够的上下文。况且生产项目涉及大量的类引用、依赖引用、日志格式规范——这些AI自己搞不定的，而IDEA在这方面已经做得相当成熟，脱离IDE写Ja va代码，体验着实不怎么样。所以去年很长一段时间，都是手动复制代码上下文粘贴到Chat界面，等AI生成代码再拷回IDEA。虽然可行，但过程多少有点折腾。

直到今年，发现了一款叫repoprompt的工具，算是把痛点解决了。它本质上是一个半自动化的Cursor，关键区别在于生成过程是白盒的。Cursor自己集成了大模型API，底层给用户的是黑盒，对小白友好；但如果追求对过程的控制，白盒方案显然更合适。而且Cursor对模型的限制挺死——只能用它们提供的模型，用不上o1-pro这类最新模型。

白盒化的另一个好处：它会逼着你思考该给大模型提供哪些上下文，把任务拆小、拆细。虽然效率没有全自动那么高，但成功率高出不少，返工时间自然就少了。

基础用法

repoprompt最基础的操作流程：打开项目，选中要提供给模型参考的上下文，写好指令，一键复制——它会自动把选中的代码文件和指令拼成一个完整的prompt，然后你只需粘贴到Chat界面等结果就行。下面举个例子：

复制后的prompt包含了文件的路径、内容以及具体的代码指令。本质上你平时用Cursor时，调用大模型的那一步就是同样的机制，只不过这里由自己来操作。把prompt贴到任意一个Chat界面，就能拿到重构后的结果，再把生成的代码贴回IDEA就行了。

进阶用法

让大模型写代码时，经常会出现它生成的跟你想的不一样。解决这个问题有个小技巧：让它“先聊再写”。具体操作是在prompt里加一句话：“先别写代码，咱们先聊聊，直到我让你写代码”。还是用上面那个例子，看看效果：

加了这句话之后，大模型会先说说自己的思路，这时候就可以提意见。比如直接让它用spring bean注入的方式来重构代码：

高阶用法

前面的方法分别解决了快速提供上下文和代码生成不符合预期的问题。那能不能让AI直接编辑文件，省掉手动粘贴的步骤？当然可以，repoprompt提供了这个能力。

需要先在XML Diff这里打勾，这样prompt指令里就会让大模型按xml格式返回代码变更：

开启XML Diff后，复制的prompt会增加两百多行指令，教大模型怎么返回xml格式的代码变更，方便后续自动合并。不过这个功能需要Claude sonnet 3.5以上版本才支持，其他模型的代码生成能力还不太够。

这段XML指令的核心，是给代码编辑助手提供了详细的格式规范。它定义了助手的角色（代码编辑助手）、能力范围（创建、重写、修改、删除文件），以及各种操作必须遵循的XML格式。

具体来说：

助手定位为代码编辑助手，能执行编辑请求，也能跟用户聊代码相关的问题。输出时必须提供完整的指令或代码行，不能放“...”这样的占位符。

• create
  ：创建新文件，如果文件不存在就创建。

• rewrite
  ：重写整个文件。

• modify
  （search/replace）：部分修改文件，需要提供查找内容和替换内容。

• delete
  ：删除文件，标签为空。

• 先写标签描述计划。
• 使用标签，action必须是对应操作。
• 每个标签内可包含多个标签，应对同一文件的多处修改。
• modify操作时，和代码块都要用===包裹，且必须与原始代码完全匹配（缩进、空格、大括号、注释一个都不能差）。
• modify的一次替换一个修改点，多个修改就要用多个。
• rewrite用于大范围重写，省略直接放新内容。
• create和delete分别对应创建新文件和删除文件。

• 搜索块不匹配：
  如果里的代码跟原文件不一致，修改就会失败。

• 括号不平衡：
  里多写或少写括号会导致整个文件结构出错。

• 单行搜索：
  太短的块因为匹配范围过大，容易引起歧义。

• 模糊搜索：
  比如有多个相同的闭括号，就不知道要替换哪一个。

• modify的必须精确匹配，哪怕少一个空格都会导致失败。
• modify只改需要改的部分，避免整段整文件替换。
• rewrite替换整个文件，尽量只在必要时使用。
• create或delete时，create要提供完整代码，delete给空。
• 文件路径要遵循用户给定的目录结构。
• 最终输出要用```XML ... ```包裹，但不能使用CDATA标签（），因为repoprompt期望的是原始XML。
• 如果要做文件变更，一定要用提供的XML格式，否则变更无法生效。
• 最终输出必须干净，不能有语法错误。

下面是大模型生成的XML格式响应示例：

修改 FileParserServiceImpl 类中的方法签名和实现逻辑，使其与 FileParserService 接口保持一致。主要变更是将返回类型从 Result 改为直接返回 T，并相应调整异常处理逻辑。 ... 更新 FileParserServiceImpl 实现类，使其方法签名与 FileParserService 接口一致 ===package com.xxx.medigw.core.service.parser.impl; ... public class FileParserServiceImpl implements FileParserService { ... } ===

点击Merge Changes，就能自动合并代码了。

回到最核心的问题：效率提升到底靠什么

回过头来，AI带来的效率提升跟程序员自身的水平是正相关的。现在的AI确实像个实习生——你必须要把它要做的事情说清楚。如果你自己都不知道如何实现一个功能，AI就更不可能替你搞定。况且，开发过程中大量的时间花在调试上，要让AI帮忙调试，提问者也必须有足够的知识储备。期望不能太高，这样才能有耐心带好这位“AI实习生”。

随着AI能力的进步，有不少人担心程序员会被取代，甚至觉得产品经理可以绕过程序员，直接让AI开发出想要的产品。作为一名在手工编程古典时代成长起来的程序员，其实并不担心这一点。

写代码本身在成熟工作中占比并不大——一旦熟悉了语法和中间件，写代码跟搬砖区别不大。真正花时间的是解决环境问题、跟上下游联调、和产品一起澄清需求这些事情。哪怕AI未来能帮我们完成全链路的联调，它也取代不了程序员。知道应该修改哪一行代码，比知道如何修改这行代码值钱一千倍。开发软件真正的难点，从来不是写代码，而是把问题定义清楚。最后，当AGI真的出现的时候，该讨论的或许已经不是程序员会不会被取代——而是碳基生物如何跟硅基生物共存了。