★ FEATURED ARTICLE 简介这份PDF资料源自北大青鸟人工智能研究院与北大计算机学院等团队的内部研讨面向无编程经验的教师、产品经理、技术创业者以及有编程基础的开发者、CTO与架构师系统梳理AI编程从辅助编程、氛围编程Vibe Coding到智能代理式编程Agentic Coding的演进脉络。内容涵盖Vibe Coding的核心特征与技术支撑SPEC Coding、ID Coding等范式的发展并深度剖析Cursor、Claude Code、Trae、Qoder、CodeBuddy等主流工具的架构与适用场景提供基于价格、上下文窗口、SWE-bench分数的横向对比与选型逻辑。资源包为1个PDF文件约8.92MB结构完整、图文并茂便于通读与检索。目前已有387人学习。读者可借此建立AI编程的系统框架与产品视角理解多智能体协作、企业级生态与开源Skill市场等趋势同时认识数据隐私、代码可维护性下降等风险进而从“如何实现”转向“定义问题”与“价值判断”向具备业务洞察与系统思维的“超级个体”进化。1. 从 Vibe Coding 到 Agentic Coding北大这份 PDF 到底在讲什么你可能已经在用 Cursor 或 Claude Code 写代码了感觉挺爽——说句话代码就出来了。但有没有发现一个问题让它改个稍微复杂的模块它就开始胡编 API、忘记上下文、改完 A 又坏了 B这不是工具不行是你还停在 Vibe Coding 阶段没跨进 Agentic Coding 的门。北京大学这份《Agentic Coding从 Vibe Coding 到超级个体的进化之路》PDF讲的就是这个跨越——从「凭感觉对话写代码」到「用智能体系统化交付软件」的范式演进。它适合两类人一是已经用过 AI 编程工具但总觉得「差点意思」的开发者二是想搞清楚 AI 编程下一步往哪走的技术负责人。核心不是教你某个工具怎么按按钮而是帮你建立一套 Agentic Coding 的思维框架和落地路径。2. Vibe Coding 与 Agentic Coding 的分水岭提示词、上下文与工具调用2.1 两种范式的本质差异Vibe Coding 这个词最早由 Andrej Karpathy 提出描述的是那种「完全沉浸在感觉里跟 AI 对话生成代码不看 diff 直接接受」的状态。它的核心交互是单轮或短多轮的自然语言对话你给提示词AI 吐代码你复制粘贴或者点接受。这种模式在原型验证、写脚本、做 demo 时效率极高但一旦项目超过几百行、涉及多个文件、需要持续维护问题就暴露了。Agentic Coding 则完全不同。它的核心是让 AI 成为一个有自主规划、工具调用、环境感知和迭代修正能力的智能体。你不再是一句一句地喂提示词而是给智能体一个目标、一套工具读写文件、执行命令、搜索代码库、运行测试、一个反馈循环让它自己拆解任务、执行、验证、修正。Vibe Coding 是你在开车AI 是副驾帮你递水Agentic Coding 是你设定目的地AI 是司机你坐在后排看它开偶尔纠正路线。这个分水岭的关键在于三个东西提示词工程、上下文管理、工具调用协议。Vibe Coding 时代提示词就是一切你写得好它就写得好你写得模糊它就胡编。Agentic Coding 时代提示词只是起点更重要的是智能体能不能自己维护上下文、能不能调用外部工具验证自己的输出、能不能在失败后自己回滚重试。2.2 从对话到智能体一个可复现的演进路径如果你现在还在 Vibe Coding 阶段想往 Agentic Coding 走我建议按下面这个路径来。这不是 PDF 里直接写的是我自己踩过坑之后总结的但和 PDF 里讲的范式演进逻辑一致。第一步把提示词从「祈使句」升级为「规格说明」。不要再说「帮我写个登录功能」而是给出输入输出、边界条件、错误处理、依赖约束。比如# 不要这样写提示词 # 写一个用户登录的 API # 要这样写 实现一个用户登录 API要求 - 输入JSON body包含 email 和 password 两个字段 - 输出成功返回 200 JWT token失败返回 401 错误码 - 边界email 格式校验、password 最少 8 位、连续失败 5 次锁定 15 分钟 - 依赖使用项目现有的 User model 和 bcrypt 库 - 错误处理数据库连接失败返回 503不要暴露堆栈信息 逻辑说明Vibe Coding 的提示词是「意图描述」Agentic Coding 的提示词是「可验证的规格」。参数说明边界条件和错误处理是区分业余和专业的关键AI 不会自己想到这些你必须显式写出来。第二步给 AI 装上「眼睛」和「手」。纯对话式 AI 只能看到你粘贴给它的代码片段它不知道项目里其他文件长什么样、不知道依赖版本、不知道测试有没有过。Agentic Coding 要求 AI 能自己读文件、搜代码库、跑命令。常见做法是使用支持工具调用的框架比如让 AI 通过 function calling 去执行read_file、search_codebase、run_tests这些操作。# 一个简化的工具调用循环示意伪代码展示逻辑 tools [ {name: read_file, description: 读取指定路径的文件内容}, {name: search_codebase, description: 在代码库中搜索关键词}, {name: run_tests, description: 运行测试套件并返回结果}, {name: apply_patch, description: 对文件应用代码补丁}, ] def agentic_loop(goal, max_iterations10): context build_initial_context(goal) for i in range(max_iterations): response llm_call(context, tools) # AI 决定调用哪个工具 if response.is_final: return response.output tool_result execute_tool(response.tool_name, response.tool_args) context.append(tool_result) # 把工具结果喂回上下文 return 达到最大迭代次数任务未完成逻辑说明这个循环是 Agentic Coding 的心脏。AI 不是一次性输出代码而是「思考→调工具→看结果→再思考」的迭代过程。参数说明max_iterations是安全阀防止 AI 陷入死循环context的维护策略决定了 AI 能记住多少历史信息常见做法是滑动窗口加摘要压缩。第三步建立验证闭环。Vibe Coding 最大的坑是「AI 说写完了你就信了」。Agentic Coding 必须让 AI 自己验证自己的输出。最常见的手段是让 AI 写完代码后自动跑测试、跑 lint、跑类型检查失败了就自己修。# 一个典型的验证闭环命令序列 python -m pytest tests/ -x --tbshort # 跑测试-x 表示第一个失败就停 python -m mypy src/ --strict # 类型检查 python -m ruff check src/ # lint 检查逻辑说明这三条命令是 AI 写完代码后的「后悔药」。参数说明-x让测试快速失败避免浪费时间--strict让类型检查更严格提前暴露问题ruff比 flake8 快很多适合频繁调用。2.3 上下文管理Agentic Coding 的隐形战场Vibe Coding 的人很少关心上下文窗口因为对话短。但 Agentic Coding 的任务可能持续几十轮工具调用上下文爆炸是迟早的事。PDF 里提到了「超级个体」的概念我的理解是一个人加上一套好的 Agentic 工作流能顶一个小团队。但前提是你的上下文管理不能崩。常见做法是分层管理系统提示词层放角色定义和全局约束任务层放当前目标的规格说明工作记忆层放最近几轮的工具调用结果长期记忆层放项目结构、关键文件摘要、历史决策记录。当上下文快满时把工作记忆层压缩成摘要保留关键决策和未解决问题。# 上下文压缩的简化逻辑 def compress_context(full_context, max_tokens8000): if count_tokens(full_context) max_tokens: return full_context # 保留系统提示词和任务规格 preserved full_context[:2] # 对中间的工具调用历史做摘要 history full_context[2:] summary llm_summarize(history, 提取关键决策、未解决问题、已修改文件列表) return preserved [summary]逻辑说明这个压缩策略的核心是「丢细节、留决策」。参数说明max_tokens要根据你用的模型来定不要卡太死留 20% 余量给输出。3. 搭建 Agentic Coding 工作流从工具选型到第一个可运行智能体3.1 工具选型不要一上来就追求全自动市面上 Agentic Coding 的工具大概分三类IDE 集成型如 Cursor、Windsurf、命令行智能体型如 Claude Code、Aider、可编程框架型如 LangChain、CrewAI。PDF 里没有具体推荐哪个工具但根据我的实操经验选型逻辑是这样的如果你主要写业务代码从 IDE 集成型开始学习成本最低。如果你需要批量处理、自动化流水线命令行智能体型更合适。如果你要定制智能体的行为、接入私有工具那就得用可编程框架。但不管选哪个不要一上来就追求全自动。我见过太多人配了一堆工具结果 AI 乱改代码把项目搞崩最后还得手动回滚。正确的做法是先让 AI 做「建议者」你做「执行者」等信任建立起来再让 AI 做「执行者」你做「审核者」。3.2 第一个可运行智能体从「改一个 bug」开始不要拿新项目练手拿一个你熟悉的老项目找一个明确的、范围可控的 bug让智能体去修。这样你能清楚看到它每一步在干什么出了问题也知道是哪一步错了。# 一个最小化的 Agentic Coding 工作流示例 # 目标修复一个已知的 bug比如「用户列表分页在第 3 页之后返回空」 import subprocess import json def run_agentic_bugfix(bug_description, repo_path): # 第一步让 AI 定位相关文件 search_result subprocess.run( [grep, -r, pagination, repo_path, --include*.py], capture_outputTrue, textTrue ) relevant_files search_result.stdout # 第二步让 AI 读取相关文件并分析 context fBug 描述{bug_description}\n相关文件{relevant_files} analysis llm_call(context \n请分析 bug 根因给出修复方案) # 第三步让 AI 生成补丁 patch llm_call(analysis \n请生成 unified diff 格式的补丁) # 第四步应用补丁并验证 with open(fix.patch, w) as f: f.write(patch) subprocess.run([git, apply, fix.patch], cwdrepo_path) test_result subprocess.run( [python, -m, pytest, tests/test_pagination.py], cwdrepo_path, capture_outputTrue, textTrue ) # 第五步如果测试失败让 AI 根据错误信息修正 if test_result.returncode ! 0: retry_context f补丁应用后测试失败{test_result.stderr}\n请修正补丁 corrected_patch llm_call(retry_context) # ... 重复应用和验证逻辑说明这个工作流展示了 Agentic Coding 的核心循环——搜索、分析、生成、验证、修正。参数说明grep的--include*.py限定搜索范围避免噪音git apply比直接写文件安全可以回滚测试文件要选针对性的不要跑全量测试太慢。3.3 提示词模板让智能体输出可预测Agentic Coding 的提示词和 Vibe Coding 不一样它需要结构化、可解析、带约束。我常用的模板是这样的## 角色 你是一个资深 Python 后端工程师擅长调试和重构。 ## 任务 修复以下 bug[bug 描述] ## 约束 - 只修改与 bug 直接相关的文件 - 不要引入新的第三方依赖 - 保持现有代码风格 - 每个修改必须附带测试用例 ## 输出格式 1. 根因分析不超过 200 字 2. 修改文件列表 3. unified diff 格式的补丁 4. 新增/修改的测试用例逻辑说明这个模板的关键是「约束」和「输出格式」。约束防止 AI 过度发挥输出格式让你能程序化解析结果。参数说明根因分析限制字数是为了强制 AI 抓重点不写废话。3.4 验证与回滚Agentic Coding 的安全网智能体会犯错而且错得很有创意。所以每一步都要有验证和回滚机制。常见做法是每次修改前自动 git commit修改后跑测试测试不过就git reset --hard回到上一个 commit。# 一个安全的 Agentic Coding 操作序列 git add -A git commit -m checkpoint before agentic edit # 存档 # ... AI 执行修改 ... python -m pytest tests/ -x --tbshort if [ $? -ne 0 ]; then git reset --hard HEAD # 回滚到存档点 echo 测试失败已回滚 fi逻辑说明这个模式叫「检查点-验证-回滚」是 Agentic Coding 的后悔药。参数说明git add -A会把所有改动都存档包括未跟踪文件git reset --hard HEAD会丢弃所有未提交改动所以存档必须在修改前做。4. 避坑指南Agentic Coding 落地时最容易翻车的五个地方4.1 坑一上下文污染导致 AI「失忆」现象智能体在前几轮还能正确引用项目里的函数名到后面开始编造不存在的 API或者忘记之前已经修改过的文件。原因上下文窗口被大量无关的工具调用结果填满关键信息被挤出去了。或者多个任务的上下文混在一起AI 分不清哪个是当前任务。解决每个任务开独立的会话不要在一个会话里连续做多个不相关的任务。定期清理工具调用历史只保留关键决策和文件摘要。如果框架支持使用「上下文隔离」——每个子任务有自己的上下文空间。4.2 坑二工具调用权限过大导致误操作现象AI 执行了rm -rf或者git push --force把不该删的删了把不该覆盖的覆盖了。原因给智能体的工具权限没有做限制或者没有人工确认环节。解决危险操作必须加确认。常见做法是维护一个「白名单命令」列表只有列表里的命令能自动执行其他命令需要人工批准。文件删除操作一律走「移动到回收站」而不是直接删。# 危险命令拦截示例 DANGEROUS_PATTERNS [rm -rf, git push --force, DROP TABLE, chmod 777] def safe_execute(command): for pattern in DANGEROUS_PATTERNS: if pattern in command: raise PermissionError(f危险命令被拦截{command}) return subprocess.run(command, shellTrue, capture_outputTrue)逻辑说明这个拦截器很粗糙但有效。参数说明DANGEROUS_PATTERNS要根据你的实际环境补充比如数据库操作、部署命令等。4.3 坑三测试覆盖不足导致「假成功」现象AI 说「测试全部通过」但你手动一跑就报错。原因AI 只跑了它自己写的测试或者测试用例太弱没覆盖边界条件。更坏的情况是 AI 修改了测试用例来「通过」测试。解决测试用例必须由人审核不能让 AI 自己写自己跑。关键模块的测试覆盖率要设阈值低于阈值就拒绝合并。定期用变异测试mutation testing检查测试用例的有效性。4.4 坑四过度依赖导致代码质量下降现象项目能跑但代码越来越臃肿重复逻辑到处都是命名混乱没人看得懂。原因AI 倾向于「能跑就行」不会主动重构。每次修改都是打补丁时间长了就成了一团乱麻。解决定期让 AI 做「重构专项」但重构必须有人工审核。设置代码质量门禁比如圈复杂度、重复率、函数长度超过阈值就拒绝合并。我一般会每周跑一次radon和pylint看看 AI 有没有把代码写烂。4.5 坑五安全漏洞被 AI 悄悄引入现象AI 生成的代码里有 SQL 注入、硬编码密钥、不安全的反序列化。原因AI 的训练数据里就有大量不安全的代码它不知道什么是「安全」的。解决在 CI 里加安全扫描比如bandit、semgrep。提示词里明确要求「不要硬编码密钥」「使用参数化查询」「验证所有用户输入」。关键安全模块的代码必须人工审核不能全交给 AI。# 安全扫描命令 bandit -r src/ -f json -o bandit_report.json semgrep --configauto src/ --json -o semgrep_report.json逻辑说明这两条命令分别做通用安全扫描和模式匹配扫描。参数说明-r递归扫描-f json输出 JSON 格式方便集成到 CI。5. 从超级个体到团队协作Agentic Coding 的进阶玩法5.1 多智能体协作让 AI 自己开会单个智能体能力有限但多个智能体可以分工。常见模式是「规划者-执行者-审核者」三角规划者拆解任务执行者写代码审核者检查质量和安全。PDF 里提到的「超级个体」概念我的理解是一个人通过编排多个智能体能完成以前需要团队才能做的事。# 多智能体协作的简化编排 class PlannerAgent: def decompose(self, goal): return llm_call(f将以下目标拆解为可执行子任务{goal}) class ExecutorAgent: def execute(self, subtask): return llm_call(f执行子任务并输出代码{subtask}) class ReviewerAgent: def review(self, code): return llm_call(f审核以下代码的安全性和质量{code}) def orchestrate(goal): planner PlannerAgent() executor ExecutorAgent() reviewer ReviewerAgent() subtasks planner.decompose(goal) for task in subtasks: code executor.execute(task) review reviewer.review(code) if review.approved: apply_code(code) else: # 打回执行者重新做 code executor.execute(task f\n审核意见{review.feedback}) apply_code(code)逻辑说明这个编排模式的关键是「审核者」有否决权。参数说明review.approved是一个布尔值由审核者智能体输出review.feedback是具体的修改意见。5.2 验证 Agentic Coding 效果三个可量化的指标不要凭感觉说「AI 编程真好用」要量化。我一般看三个指标首次通过率AI 第一次提交的代码能通过测试的比例、平均修复轮次从开始到测试通过需要几轮迭代、人工干预率需要人工修改的提交占比。这三个指标能告诉你智能体到底是在帮你还是在给你添乱。指标健康值危险信号首次通过率 60% 30%平均修复轮次 3 5人工干预率 20% 50%5.3 一个具体技巧用「反向提示」让 AI 自己找漏洞这是我最近半年最常用的技巧。写完代码后不要问 AI「这样写对吗」而是问「这段代码在什么情况下会失败」。反向提示能逼 AI 跳出「确认偏误」主动找自己的问题。# 反向提示示例 code read_file(src/payment.py) vulnerabilities llm_call(f 以下代码在什么情况下会失败请列出所有可能的边界条件和异常场景 {code} ) # 然后让 AI 针对每个失败场景写测试用例 for vuln in vulnerabilities: test_case llm_call(f为以下失败场景写一个测试用例{vuln}) append_to_test_file(test_case)逻辑说明这个技巧的核心是「让 AI 攻击自己的代码」。参数说明vulnerabilities是一个列表每个元素是一个失败场景描述测试用例要追加到现有测试文件不要覆盖。从那以后我每次让 AI 写完关键模块都强制走一遍「反向提示→生成测试→跑测试」的流程。这个习惯帮我拦住了至少三次潜在的线上事故。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
