Agent coding experience and future

Posted on 2025-06-28 In Work Note Word count in article: 3.9k Reading time ≈ 14 mins.

本文写于2025年6月28日，AI时代的日新月异导致哪怕隔了一天，本文中所写的事实与我的态度都有可能发生极大的变化，请以最新情况为准。

核心概念定义

在开始分享我的经验之前，让我先定义一下本文的核心概念（我自己定义的）：

Agent Coding 是使用AI编程助手（Coding Agent）进行软件开发，并且在这个过程下无需人类的主动干预和提示，由Coding Agent完成任务。 Vibe Coding：完全通过对话生成代码，不进行任何手动修改或代码审查 AI-assisted Coding：人机协作模式，结合AI生成和人工review，这是目前最实用的方式 Coding Agent：具体的AI编程助手工具，如Cursor、Claude Code、Augment等

本文主要探讨Agent Coding方法论下的实践经验和未来展望。

日新月异的迭代速度

去年在对比ChatGPT O1 和 Claude 3.5 Sonnet的时候，它们还只能帮我写一些简单的脚本，最厉害的可以处理一些比较难的算法题，总而言之，这个东西能够写好的代码大概在500行左右的规模。还不到一年，这些大语言模型已经进化到能够完整地写好一些甚至相对复杂的业务逻辑和产品了，朋友圈和小红书每天都有没有任何编程相关经验的人利用v0、lovable、cursor来上线新的产品。亲身体感，LLM及相关产品的迭代速度已经从23年初到24年中旬的这一轮以年为单位，到现在缩短到以季度甚至月为单位了。比如，在最开始的时候GitHub Copilot还是最好用的产品，在今年的3-4月份，Cursor还是AI-assisted coding的绝对王者，Roo Code、Cline、Windsurf还有一席之地，在Sonnet 4出来之后，Claude Code直接领先，Cursor则是因为主动降智和有限的调用额度被Augment赶上，GitHub Copilot在最近的几个月已经完全沦为低价API的调用池子了；在vibe coding 的产品里，一开始只有v0这一家，然后Lovable凭借自身生成的更好的美术风格又占据了一席之地，再到后面Google自家都推出了AI Studio和Google Stitch两个产品……

这些东西的进化速度，有一种隔了一天都会有恍如隔世的感觉，我一直在互联网上高强度冲浪，每次发了新的产品都会积极地使用，并且在高强度使用之后退订掉不好用的产品（比如，我的chat bot已经从一开始的订阅ChatGPT，再到订阅Claude，再到换用更便宜的第三方API再加上Cherry Studio这种GUI再加上公司的Gemini了；我的Coding Agent也从Cursor更换到了Augment；每个月续费的前几天我都在回顾我的使用感受来退订产品），所以代际差距并不明显。但是当我跟另外一名前不久还在用GitHub Copilot的朋友分享Cursor和Augment的使用感受的时候，他却体会到了”大清已经亡了”、“北京申奥成功了”、“天翼3G就是快”的感受。

除了这些，构建AI agent的工程实践甚至都迭代了好几轮，从一开始的embedding，再到使用grep纯全文搜索，再到使用数据库来查询，再到”优化再多不如大模型公司更新一下模型”，感觉一些经验还没来得及沉淀，就已经被迭代了，昨天还刚学的prompt engineering、chain of thought、function calling，今天就在讨论用LangGraph、LangChain、MCP。

Agent Coding的核心实践

接下来我来讲一下我在实践Agent Coding时的一些经验和感受。

让我先拿出来这一张传统的图：

Data, information, knowledge, insight, wisdom

作为上网冲浪高手，我在ChatGPT刚出来的时候就在关注它的能力，当时我对它的评价大概是一个大学毕业生的水平，而从这时候开始，GPT就已经完全改变了我学习新知识的流程，data和information的部分几乎不再需要我一个个文档地去看，一本本书地去翻，我可以直接带着问题去学习和思考，从knowledge开始。

为什么要提这个呢，请看下面这个表格：

	LLM知道	LLM不知道
你知道	你和LLM都知道	LLM以为你知道
你不知道	你以为LLM知道	LLM和你都不知道

我发现不管在我使用LLM还是在进行Agent Coding的时候，我们的工作区域都可以划分成为这四个象限：

你和LLM都知道：这一部分的工作曾一度是在23和24年上半年的时候我觉得LLM影响不大的主要原因之一，我知道LLM也知道的东西，很多时候都觉得LLM写的不好，而且效率低（需要好几次对话来纠正错误）。在24年的Claude 3.5和O1发布之后，更精确地说，在它能够进行thinking之后，LLM在这一部分远远超过了我的工作效率，我几乎只需要在极少的2-3次对话之内就可以去开始review它写的code，只需要改一些细微的部分就能够直接使用了。
你以为LLM知道：这里的工作一度是LLM带给我的最大困扰，最经典的比如LLM的知识库往往不够新，没有最新的API；LLM在工作的时候并不理解各个类和对象的依赖关系，也不知道这几个任务之间的先后关系；以及它并不清楚一些特定情况下的上下文。但是在一系列的工具出来之后，这一部分已经很明显地得到改善和增强了，并且有被解决的苗头。这些工具我会放在后面讲。
LLM以为你知道：这是我日常工作中会出最多错误的地方，经典的场景比如使用我并不熟悉的语言和库进行工作。这些地方你和LLM的信息并不对等。我目前给出的唯一解法就是多问，要逐行对代码进行code review，理解每一行代码的含义；除此之外就是生成测试，甚至可以开一个AI来帮你单独根据你的需求构建测试场景和测试样例，我可以不清楚细节但是我要确保输入和输出和我想的一模一样。
LLM和你都不知道：这是目前我唯一会不借助任何LLM来进行写代码的场景。目前LLM在这一领域给我写的代码全部都是💩。

所以我对于使用LLM或进行Agent Coding的时候，我认为最重要的核心就是context，要确保Coding Agent和你有相同的context，我和Coding Agent讨论的是同一件事情；对于我不知道的部分，我要确保在我的使用场景下，生成的代码的输入和输出和我想的一模一样。

一些有用的tips

Code review and refactor：目前我和Coding Agent大多数是以pair coding的态度进行协作。而提到pair coding就是在TW干的这几年的经验积累了，识别code smell、test driven、tasking，有意识地以这些流程来和Coding Agent合作，能够在保证质量的同时极大地提高速度。除此之外，我最近感觉Coding Agent经常犯的错误就是写很多冗余代码，有的是写了被我否决之后没删，有的是原来的类或方法已经deprecated之后没有删除，这些都需要进行code review。
Plan and Ask：在拿到任何一个需求，特别是一个故事卡级别的需求的时候，千万不要让Coding Agent直接开始写代码，而是要使用ask或者plan模式将任务进行拆分，写到md文件里，review它的solution之后，开启一轮新的对话再让它开始写。这样也可以极大地节省token，降低API的费用。
让助手阅读文档：在解决一些比较高层次或者开放性的问题的时候，可以让它去搜索最新的解决方案，比如我要引入一个库来解决我的需求，就可以让它去搜索PyPI、npm、Maven或者GitHub里面使用人数最多/星标最多的库，并且给出至少5个解决方案，做一轮深度研究。我经常做的一些流程有：
- 粘贴文档链接并要求LLM先阅读
- 要求LLM找出最新技术
- 使用任务工具让LLM对特定主题进行深度研究
Use MCP：这里的一系列工具可以极大地改善”你以为LLM知道”的工作场景，我最近每天都在用的几个列举如下：
- Context7：通过这个可以解决一部分的AI不知道最新的文档的问题
- Sequential Thinking：通过这个可以改善Coding Agent的逻辑思考能力，可以让AI知道”我需要先做什么后做什么”
- Memory：通过这个可以让Coding Agent在每一次进行新的对话的时候保留之前对话的上下文，减少”明明刚刚说过了你咋就不记得”的情况，Cursor rule和Augment memory也可以做到类似的效果
- Shrimp task manager：使用这个则可以让Coding Agent主动地去做tasking
- Feedback Enhanced：使用这个可以加快反馈进度，具体来说，在Coding Agent协作编程的时候我们是无法跟着（或者无法跟上它的速度）Coding Agent去看它修改的每一个文件，所以有的时候会发现它改了一堆之后和你想的完全不一样。使用这个它会在你的指令做到一半的时候就停下来问你的feedback，而不是在完全做完的时候，提前终止
- Playwright：这个可以让LLM能够和web前端页面进行交互和截图，对前端比较有帮助（应该）。我的使用还比较少
其他好用的MCP还可以去Smithery.ai来寻找。我目前也只是使用了一小部分。
精确Prompt：这个仍然是很重要的，给出的prompt越清晰越explicit，生成的代码越准确。除此之外，很多时候LLM也在偷懒，在这种时候告诉它要使用什么MCP，tell the model to think, to deep think and ultrathink，很多时候可以收获更好的效果，可以参考Extended thinking tips。
及时停止和中断，不要尝试一次完成：这些LLM在长的对话中经常有各种各样的问题，要及时中断和调整。并且一轮对话通常无法完成一个较大的需求

也许是未来的可能：告别逐行编码

在我多次尝试Claude Code之后，我认为在未来可能真的不需要人一行行地去写代码了，CLI模式下的Coding Agent可以天生进行并行多任务（例如，使用git worktree和让Claude Code使用Claude Code），虽然费用一路水涨船高（根据我的估算，如果我每天都使用Claude Code以这种模式进行开发的话，每个月可能花费至少500美元，但是可以提升速度一倍以上）。这种CLI模式下天生带来的多任务和并行能力，让我有一种在进行Vibe Coding的时候做的事情不再是pair coding，而是只做拆分任务、验收代码这些high level的事情的感觉，在任务拆分得好的情况下，开几个git worktree就可以并行进行多个任务互不打扰。

我在看完How I Use Claude Code这篇文章之后最近在实践和尝试的一个项目就是使用Gemini CLI根据md文件在GitHub Action上面自动生成代码并且提交PR，这里是一个成功的例子，虽然只是让它做了LeetCode 001 Two Sum（受限于我的经济能力，我也没有那么多的钱买API让它来搞复杂的项目）。

整个流程大概就是：

Requirement.md → GitHub Actions → Gemini CLI → Generated Code → Auto PR

这里面最核心的一步只需要这么几行代码


- name: Generate Code with Gemini CLI
  id: generate
  env:
    GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
  run: |
    echo "🤖 Starting code generation with Gemini CLI..."

    # Read requirement content
    REQUIREMENT_CONTENT=$(cat "${{ steps.process.outputs.requirement_file }}")
    FEATURE_NAME="${{ steps.process.outputs.feature_name }}"

    echo "📝 Processing requirement: $FEATURE_NAME"
    echo "📄 Requirement file: ${{ steps.process.outputs.requirement_file }}"


    # Create output directory
    mkdir -p generated

    # Use Gemini CLI in non-interactive mode
    # The CLI will automatically detect it's in a non-TTY environment
    echo "🤖 Generating code with Gemini CLI..."

    # Create a more specific prompt for code generation
    PROMPT="You are a code generation assistant. Based on the following requirement, you must create actual JavaScript files using the write_file tool.

    REQUIREMENT:
    $REQUIREMENT_CONTENT

    INSTRUCTIONS:
    1. Use the write_file tool to create a JavaScript file named '${FEATURE_NAME}.js'
    2. Implement the solution with proper JSDoc comments
    3. Export the function for use in other modules
    4. Follow modern ES6+ syntax
    5. Include comprehensive error handling
    6. Add unit tests if appropriate

    You MUST use the write_file tool to create actual files. Do not just provide code examples."
    # ============================================
    # 🔥CORE STEP: Using stdin with enhanced prompt and YOLO mode
    # ============================================
    # All the above is preparation work, the magic happens in this single line:
    echo "$PROMPT" | gemini --yolo > "generated/${FEATURE_NAME}_output.txt" 2>&1
    # ☝️ That's it! One command to complete AI code generation

    # Check if generation was successful
    if [ $? -eq 0 ]; then
      echo "✅ Code generation completed successfully"
      echo "📄 Gemini CLI output:"
      head -20 "generated/${FEATURE_NAME}_output.txt"
    else
      echo "❌ Code generation failed"
      cat "generated/${FEATURE_NAME}_output.txt"
      exit 1
    fi

    # Store output info for next steps
    echo "output_file=generated/${FEATURE_NAME}_output.txt" >> $GITHUB_OUTPUT
    echo "feature_name=$FEATURE_NAME" >> $GITHUB_OUTPUT

这里的requirement.md可以替换成从Jira读取新的故事卡，GitHub Action可以替换成后端的服务来控制对话的长度和工作流程（比如之前提到的tips，git worktree and let Claude Code use Claude Code），PR生成之后可以有新的action调用Gemini CLI来review code，在生成代码的过程中还可以再加上一个后台dashboard让我可以实时地给予feedback进行调整。

在这个流程下，我只需要写清楚需求和prompt，就可以一边喝茶一边压榨我的agent写代码了。

未来

我仍然无法想象出Vibe Coding和Agent Coding到底会发展到什么程度，也许会像之前风靡的低代码平台一样声势浩大但是只能解决一部分问题，也许会真的迎来我想象中的”我只需要写清楚需求和prompt”，也许LLM的发展会遇到瓶颈导致它只能完成到某一步，但是无可否认的是未来构建软件的流程和方式会有极大的不同。今年年初我还看到了Vibe Coding Manifesto，摘录如下：

💜 Flow over friction – Ride the wave, don’t fight it.

💜 Iteration over perfection – Perfection is obsolete if you can always reroll.

💜 Augmentation over automation – AI is a collaborator, not a replacement.

💜 Product thinking over code crafting – What matters is what you build, not how you write it.

💜 Rerolling over debugging – If fixing takes too long, regenerate.

💜 Human taste over technical constraints – The best tech serves great taste, not the other way around.

这让我不得不想起二十多年前的Agile Code Manifesto，而我能做的目前只有快速去学习这新一代的珍妮纺织机的用法吧。

最后，感谢thoughtworks的AIFSD提供的Claude Code，让我能够体验到最新的模型与进行尝试。

多语言版本： - English - 日本語