vibe coding 完整学习路径：从自然语言驱动到工程化落地

最近圈子里总有人问vibe coding 是不是就是“偷懒式编程”用大白话把需求丢给 AI它啪一下给你生成几百行代码看起来确实很爽但也确实不靠谱。有的朋友照着网上教程试了两次发现 AI 写出来的东西根本跑不通或者跑通了但一改需求就崩转过头就下结论说“这东西就是个玩具”。我在实际项目里把 vibe coding 这套流程完整跑了大半年从最初的一两句话生成小工具到后来带着 agent 开发一个带完整前后端交互的业务模块中间确实踩了不少坑但也总结出一条相对可靠的路径自然语言驱动开发不是没有章法地让 AI 自由发挥而是要在“让 AI 写代码”之前先把需求和边界讲清楚在 AI 写完代码之后用工程手段把质量和风险兜住。这篇文章就把我整理出来的完整学习路径拆给大家从零基础怎么上手到怎么把 vibe coding 的产出真正工程化落地一次讲透。1. vibe coding 的本质从“写代码”到“描述代码”很多初学者对 vibe coding 最大的误解是把“用自然语言让 AI 写代码”等同于“自己完全不懂编程”。但实际上vibe coding 改变的是编码的姿势不是编码背后的思考方式。它真正解决的问题是当你的脑子里已经有了清晰的功能预期却不想把时间耗费在语法细节、框架样板代码和繁琐的 API 调用上时你可以直接用自然语言把“要什么”告诉 AI让它去补全“怎么做”。1.1 自然语言驱动开发的内在逻辑vibe coding 的运转逻辑本质上是一条翻译链路人类的模糊意图 → 自然语言描述 → AI 理解并拆解 → 生成代码 → 运行验证 → 反馈修正。这条链路里有几个关键环节容易被忽略但它们恰恰决定了最终产出质量。第一AI 不是“听见什么就写什么”而是“根据你的描述推断你大概率想要什么”。比如你说“帮我写一个用户登录功能”AI 会默认你用的是主流框架默认你需要数据库存储用户信息默认你要做密码加密。这些默认值符合大多数场景但如果你不补充细节——比如“数据库用 SQLite”“密码用 bcrypt 加密”“登录失败要记录日志”——AI 就会自由发挥生成的结果往往是“能跑但和你想要的差异很大”。所以vibe coding 的最核心能力不是会写需求而是会把需求里的“已知条件”和“期望行为”说清楚。第二AI 生成的代码本质上是“概率性输出”不是你写代码时的“确定性输出”。它有极大的可能引入一些小毛病——变量命名混乱、边界条件没考虑、依赖版本不稳定。这意味着你不可能把 vibe coding 当成“一键出活”的魔法而必须带着“我会验收、我会改”的心态去使用它。第三也是最重要的一点vibe coding 能极大降低“从 0 到 1”的门槛但对“从 1 到 100”帮助有限。你让 AI 从零搭一个项目骨架它会做得又快又好但你要在一个已经运行了半年、有 20 个模块的工程里让 AI 精准改一个功能那就要考验你对 AI 的“上下文管理能力”——把相关代码喂给 AI、把约束条件写清楚、把改动范围圈定好这个能力本质上比手写代码还难一些。1.2 哪些场景适合 vibe coding哪些现在还不适合拿我自己的实践经历来说不是所有开发任务都适合用 vibe coding 来跑。我梳理了一张“适合程度”表格新手可以拿它来做参考任务类型适合程度典型例子一次性脚本/工具很高文件批量重命名、数据清洗、爬虫脚本独立小项目从零搭建很高个人博客、TODO 应用、简单 API 服务前端页面/组件开发高响应式页面、表单组件、图表展示既有项目的功能迭代中在已有代码里加字段、加接口、改逻辑复杂业务系统整体设计偏低电商订单系统、权限系统含多角色性能敏感/并发复杂的模块低高并发消息队列、实时通信底层安全敏感场景低支付、鉴权、密钥管理为什么会有这种差异根本原因在于 AI 的训练数据里常见场景的代码质量远高于极端场景。一个批量重命名文件的脚本网上有海量的高质量例子AI 生成的代码几乎不会跑偏但一个包含库存扣减、订单状态机、支付回调幂等处理的电商系统在真实世界里的实现细节高度依赖具体业务约束AI 没见过“你这套系统”的完整全貌它只能在每个局部给你一个“看起来合理但未必适配全局”的答案。我自己用得最多的场景有两个一是把“手写要花半小时、但 AI 秒出”的工具脚本交给 AI比如日志分析、文件格式转换、定时任务二是从零搭建项目骨架把路由配置、数据库连接、基础目录结构这些模板化的工作交给 AI再把精力留给真正复杂的业务逻辑。2. 从 0 到 1第一次跑通“一句话→能运行的代码”如果你是零基础或者刚接触 vibe coding 没多久不建议一上来就挑战大项目。先把“让 AI 从一句话生成一个能运行的代码”这件事跑通建立正反馈再逐步加深。这个阶段的核心目标是搞明白 AI 生成代码的工作方式、学会看懂报错信息、学会把报错扔回给 AI 让它自己修。2.1 工具选型不同工具对上手难度影响很大现在市面上的 AI 编程工具有很多我实测过的主要是这几类第一类是“对话式编程助手”典型代表包括 Claude、ChatGPT 等通用大模型。它们的优点是进入门槛最低会打字就能用不需要额外配置适合学习 prompt 写法、理解 AI 的思维习惯。缺点是“一次性味道”比较重——你需要手动把代码贴来贴去项目文件多了以后上下文容易丢失。第二类是“IDE 集成式 AI”典型代表是 Cursor、Windsurf、通义灵码、CodeGeeX。它们把 AI 直接塞进代码编辑器里能看到你当前打开的整个项目文件能直接帮你修改文件、创建文件、运行命令。这个体验比通用大模型好很多因为 AI 能“看到”项目结构而不是仅凭你贴进去的片段做判断。第三类是“Agent 式开发工具”比如 Claude Code、Cursor Agent 模式、OpenAI Codex。这类工具不仅能写代码还能自己执行命令、安装依赖、跑测试、看报错、自己修正是一个完整的自动化工作流。上手难度最高但在工程化场景里价值也最大。我给新手的建议是先用通用大模型或 IDE 内 AI 学习“如何描述需求”等你能熟练把自己想要的逻辑说清楚时再切到 Agent 工具去自动化整个流程。一上来就上 Agent往往会被它一堆“自作主张”的操作搞晕。2.2 第一次实操把一句话需求变成可运行项目我来带大家走一个完整的实操例子。假设我现在想在本地快速做一个“待办事项管理”的小工具技术栈希望用 Python Flask SQLite网页可以增加待办、标记完成、删除待办。第一步我打开 Cursor或 Claude 的项目模式输入一段描述性的 prompt帮我用 Python Flask 写一个待办事项管理的小应用 1. 使用 SQLite 存储数据数据库文件放在项目根目录下 2. 页面功能包括展示所有待办、新增待办、标记完成/未完成、删除待办 3. 界面用简单的 HTML 模板不引入复杂前端框架 4. 启动入口是 app.py默认端口 5000 请先创建项目文件结构再逐个写代码文件最后运行起来。这里有几个关键词是 AI 依赖的锚点技术栈Flask SQLite、功能列表、存储方式、界面要求、运行方式。信息给得越具体AI 生成的代码就越贴合你的预期。AI 一般会生成一个类似这样的文件结构todo_app/ ├── app.py ├── database.py ├── templates/ │ └── index.html └── requirements.txt然后它会告诉你运行步骤pip install -r requirements.txt python app.py如果你用的是 Claude Code 或 Cursor Agent它们会直接帮你执行这些命令。如果用的是通用大模型你需要自己复制代码、创建文件、安装依赖。这一步跑通之后你会第一次体验到“自然语言驱动开发”的爽感一个完整的增删改查应用从无到有只要几分钟。2.3 提示词写得好不好直接决定代码质量在 vibe coding 的学习路径里用自然语言表达需求是核心基本功。我总结了几个比较实用的写法要点把需求拆成“功能点列表”。不要只写一句“做个待办应用”而是明确列出一二三。AI 对结构化信息的理解远好于对一大段散文的理解。写清楚“技术栈和约束”。如果不指定语言和框架AI 大概率会猜一个。猜对了还好猜错了你就会拿到一个“要重装一堆依赖但你根本没听说过”的方案。我平时会在 prompt 里固定写清“语言 框架 数据存储方式 关键约束”哪怕这听起来很技术流。这也是为什么我建议哪怕零基础也要先花一天时间搞懂“什么是框架、什么是依赖”这类基本概念——不是要你学会手写而是要你能听懂 AI 在说什么。贴报错信息让 AI 自己修。AI 写的代码第一次跑通是运气跑不通是常态。当执行报错时直接把报错信息全文贴给 AI不要自己先瞎猜。尤其要注意把报错发生的上下文带上——是在安装依赖时报错还是运行时还是点击按钮时信息越完整AI 的自我修复越准确。给 AI 一个“验收标准”。你可以告诉 AI“运行后访问 http://localhost:5000 应该能看到页面点击新增按钮后页面上能出现新的待办刷新之后数据仍然在”。AI 会拿着这个标准自查代码提前补上它遗漏的逻辑。这个阶段的打磨其实是在训练一件特别重要的事情把脑子里的“大概感觉”翻译成 AI 能执行的“明确指令”。这个能力越强后面工程化路线的地基就越稳。3. 从“能跑”到“敢用”工程化视角的重新审视vibe coding 最大的争议点在于AI 生成的代码能跑但它经不经得起推敲安全性如何扩展性如何可维护性如何如果以后有新需求要加是改得动还只能推倒重来我第一次把一个 vibe coding 写的内部工具丢给同事用时同事随手就发现了一个 bug——在输入框里输入特殊字符会导致页面报错。AI 当时生成的代码确实“能跑”但它没有考虑输入校验、异常处理这类工程上必须有的细节。这件事让我意识到vibe coding 的价值要真正兑现必须引入工程化环节来“兜底”。否则它只停留在一个“会帮你写代码的玩具”阶段。3.1 用“代码审查者”视角去要求 AIAI 生成代码之后不要拿到就用。我在实际操作中会给 AI 追加一轮“代码审查优化”的要求。常用的 prompt 是请用资深工程师的视角审查你刚才生成的代码重点关注 1. 是否存在输入校验缺失的问题 2. 是否存在 SQL 注入 / XSS 等安全风险 3. 是否存在内存泄漏或资源未释放的问题 4. 是否有关键逻辑缺少 try/except 处理 5. 代码风格是否统一、命名是否清晰 发现问题后请直接修改代码。听起来有点“自问自答”的意味但这轮操作是有实际效果的。因为大模型的生成机制导致它“写的时候可能没多想”但当你主动要求它用审查者视角回看它会调用另一套知识——关于代码规范的、关于安全最佳实践的——来审视并修正自己刚才的输出。换句话说AI 本身“懂”这些工程要求你不提醒它、它默认不会主动套用但你提醒之后它能做得像模像样。实际体验是这一轮审查通常能揪出 70% 左右的低级别问题尤其是输入校验、空值处理、依赖缺失。更复杂的架构问题它不一定能发现但用工程化习惯把 AI 的产出过一遍“防守性检查”产出质量会肉眼可见地提升。3.2 给代码补上“边界”和“异常”的课AI 生成代码还有一个通病它在处理“理想路径”时表现很好但在“非理想路径”上往往很单薄。举例来说让 AI 写一个读取 Excel 文件并返回统计结果的函数它会把“正常读取文件、计算数据、输出结果”的主流程写得行云流水但处理“文件不存在怎么办”“文件格式不是 Excel 怎么办”“某一列为空怎么办”这类问题时往往直接给个 pass 或简单的 raise。这个问题不能指望 AI 自己想到而要你在写需求时就把边界情况喂给 AI。比如你可以在 prompt 里明确补一句“以上逻辑需要考虑文件不存在、格式错误、内容为空等情况提前做好异常处理”。这会显著提升 AI 输出的健壮性。另一个更通用的做法是在代码生成之后追加一段“请你补充输入校验与异常处理”的指令。在 vibe coding 的流程里这比你自己逐行去看、去改效率高得多——毕竟你连让 AI 写这段逻辑的时间成本都节省了再加一轮“防御性补强”的时间也不大整体仍远快于纯手写。3.3 引入测试与版本管理让“改得动”成为可能从“能跑”走向“敢用”的最后一道关卡是让代码具备可维护性。这里有两个基本功必须建立测试和版本管理。先说测试。我最早做 vibe coding 时从不写测试因为我觉得“反正代码也不是我一行行写出来的跑一下能跑通不就行了”。后来被现实教育了AI 生成的代码在你改动一个接口返回格式的时候极容易连带破坏另一个调用它的函数——这比“从来不写测试但代码是你自己写的、你天然知道改动会波及哪里”的场景危险得多。因为你可能根本记不清 AI 在哪些地方引用了这个接口。我的解决方案是小工具可以不写测试但稍微涉及多文件协作的项目就让 AI 用 pytestPython或同类工具补一组基础测试至少覆盖核心业务逻辑的正常路径和关键异常路径。然后每次 AI 改完代码、或者你自己手动改动之后跑一遍测试通过的信心就足了。再说版本管理。很多初学者会问“AI 都帮我写了代码我还要学 Git 吗”答案是必须学而且至少要掌握 add、commit、branch、checkout、merge 这几个命令。原因是 vibe coding 的探索过程往往充满大胆试错——AI 前一版改出来的效果你不满意想让 AI 回退到上一版思路如果没有 Git 历史记录你只能重新描述一遍需求让 AI 重写语义早已变异结果极不稳定。有了 Git 提交点随时能在代码层面回滚这个“后悔药”值得一学。你不用理解 Git 的底层原理把它当成一个“随时存档、能读档”的机制就好。4. spec-driven 与 vibe coding什么时候该走哪条路线随着我对 vibe coding 的实践深入慢慢接触到一种思路——是不是从一开始就应该用更工程化的方式来约束 AI而不是让它先自由发挥再打补丁这就引出了最近讨论度很高的 spec-driven 开发规格驱动开发。vibe coding 与 spec-driven 的区别简单来说就是“先做后画框”与“先画框再做”。两者不是非此即彼而应组合成一个完整的工作流。4.1 spec-driven 的核心把需求变成 AI 可以执行的规格说明书Spec-driven规格驱动开发的核心思想是在让 AI 写任何代码之前先用结构化的方式把“要做什么、不做什么、成功标准是什么”写成一份规格说明AI 只按规格执行不允许自由发挥。听起来比 vibe coding 繁琐但在复杂项目里它省掉的是后面无穷无尽的返工。举个例子。用 vibe coding 的思路写“增加用户注册”模块AI 会直接生成注册页、接口、数据库表。但同一句话到了 spec-driven 体系里前置材料是这样一份文档这是一个用户注册模块的规格说明 1. 功能需求用户在注册页填写 email、密码、昵称提交后创建账号 2. 业务规则email 必须唯一密码至少 8 位且含数字和字母昵称可不填默认取 email 前缀 3. 异常处理email 已被占用时提示“该邮箱已注册”两次密码不一致时提示“两次密码输入不一致” 4. 交付标准后端接口 /api/register 接收 JSON创建成功返回 200 和 userId参数不合法返回 400 错误码 5. 非目标不做邮箱验证、不做第三方登录、不做找回密码这份规格包含几个关键元素功能范围、业务规则、异常路径、交付标准、非目标。其中“非目标”那条尤其重要——它是在告诉 AI“这些事你别擅自做”因为自由发挥的 AI 经常会给你加料把登录、验证码、第三方登录全给实现了。规格驱动的核心价值就是把“需求边界”锁死。4.2 两种开发方式的取舍以及对“工程化落地”的理解vibe coding 和 spec-driven 不是零和博弈。在我实际使用中更准确的用法是“组合”体量小、期限紧、探索性质的任务偏向 vibe coding——先快速出原型跑通周期长、业务复杂、多人协作的任务则在关键模块上切到 spec-driven——先写规格文档再让 AI 照章办事。一个实用判断标准是如果今天 AI 设计出来的方案错了你“损失”的时间是多少损失 10 分钟随便 vibe损失 1 天甚至 1 周请先写规格。这是一个非常划算的“成本判断法”。然而只有 spec 还不足以支撑一个项目的健壮演进——agent 还需要“约束”。这就是所谓 harness 概念一套包住 agent 的脚手架让 AI 的行为更可控比如限制代码行数、要求每个接口至少有一个测试、强制变更前先跑一遍 lint或定义“哪些目录 AI 不许动、哪些命令 AI 必须用”。把 spec 理解为“告诉 AI 要做什么”把 harness 理解为“控制 AI 怎么做”。spec 负责方向harness 负责约束vibe coding 负责把 AI 的高自由度释放到 spec 和约束允许的范围里三层叠加才是我见过接近于可持续工程化的落地形态。如果你以后真的要在团队里推 agent 写代码在起步时就把 spec 文档模板和 harness 约束规则定下来远比事后要求大家“认真审查 AI 的代码”有效得多。在组织层面流程性约束比态度性提醒可靠得多。5. 学习资源与进阶路径规划vibe coding 虽然听起来“零基础友好”但它毕竟是一门技能需要刻意学习才能掌握。很多人卡在某一步不知道怎么往下走主要是因为缺乏一套体系化的路径规划。我这里根据自己学习的路线给出一份可照抄的进阶参考。5.1 不同阶段应该学什么、怎么学我把学习 vibe coding 到工程化落地的完整路径拆成了四个阶段。每个阶段都配套对应的实践练习你可以根据自己的基础选择从一个合适的位置切入。第一阶段是“搞懂原理和工具”了解 AI 编程工具的基本操作、提示词写法、大模型的局限了解代码运行环境的基本常识。如果你连计算机网络、HTTP 接口的基础都不清楚建议花几天时间先补基础概念知道“接口”“请求”“数据库”“依赖”这些词各指什么。这个阶段的练习目标是完成 10 个一次性小工具比如自动整理下载目录的脚本、批量压缩图片的工具、把 CSV 转为 JSON 的转换器。小到一次会话能完成核心是建立对 AI 生成代码的体感。第二阶段是“掌握小型项目流程”开始接触由多个文件构成的完整小项目练习“写需求 → AI 生成 → 跑通 → 发现问题 → 让 AI 修改”的循环。这个阶段的练习目标是独立完成 3 个完整小项目比如个人博客、记账本、简单 API 服务。重点是学会管理项目上下文让 AI 在项目语境里理解你的需求。第三阶段是“引入工程化习惯”学习 Git 版本管理、pytest 单元测试、代码审查、异常处理、调试技巧。这个阶段的练习目标是把一个已有的小项目重构并补上完整测试。学到这里你已经有能力把 AI 生成的产出放在一套标准下衡量与维护。第四阶段是“Agent 工作流与团队协作”使用 Agent 工具自动执行“写代码 → 跑测试 → 修 bug → 再测试”的循环并学习用 spec-driven 和 harness 思路给 Agent 设定边界和验收标准再去参与一个更大的系统。这个阶段更考验综合交付能力靠的已经不是一句 prompt 的运气了。5.2 向我验证有效的“刻意练习”经验我看到不少人学 vibe coding 是“遇到问题搜一下、让 AI 写一下”结果始终停留在“咒语”随机拼凑的水平。我后来体会下来最有效的学法其实是把一个实际想做的项目从头到尾做完整过程中不要逃避那些“看不懂报错”“不知道怎么描述”的时刻每一次卡住都是学习的节点。我个人有一个极笨但极其有效的训练法找 5 个不太复杂的 GitHub 开源项目比如 500 行以内的脚本或工具不看源码先用自己的话把它的功能写成一份自然语言需求文档再逐步让 AI 根据你的描述重新实现一版。然后把 AI 的产出与开源原版对比观察哪些关键逻辑你漏说了、哪些边界条件你没考虑到。这个对比训练做 10 次之后你写需求、圈定边界的能力会有质变你也能更清楚地看到“哪些是 AI 擅长的、哪些必须靠人盯”。最近不少大厂也发布了面向零基础的 vibe coding 学习资源里面通常已经整理好“提示词模板”“项目案例库”“常见错误清单”这类资源适合作为快速上手的入口但说实话真正沉淀下来的能力永远只有在你自己的实操项目里产生——资料能帮你少踩壳替代不了动手。6. 常见问题与排查技巧实录走到这里我再把这半年多被问得最多、也是最容易出现的问题整理成一份“避坑清单”每一条背后都有一次真实的“翻车”经历。6.1 AI 生成的代码永远能跑但不是你的应用能跑同一个 prompt在 Claude、GPT、Cursor 里生成的结果各不相同同一个模型在不同的采样参数下也可能生成不同逻辑。最直观的体现是函数命名、代码结构、依赖选择。这带来一个体验你用工具 A 生成时代码走通了复制到工具 B 却报错。原因往往不是“AI 变蠢了”而是它给了一个完全不同的实现方案前置依赖不同。遇到这种情况不要在同一段代码里反复让不同 AI 修补选择一个作为主工具把上下文和约束讲透改成在它里面保持一致。6.2 “AI 把需求理解偏了”文档与需求边界模糊用户希望做成 A 功能AI 做成了 B 功能这是 vibe coding 里最挫败的时刻。原因有两种一是提示词里 A 功能的特征描述不够AI 只能从上下文里猜测二是用户描述里同时包含 B 功能相关的词AI 按最大概率把 B 作为主路径输出了。解决方式是反向检查如果 AI 做错了先把自然语言需求拆得更细然后主动用“非目标”来划清边界。例如不只是讲“我要下载功能能输入链接解析资源”还要明确“不要做定时下载、不要做批量下载、不要做断点续传”。范围讲清楚AI 犯方向性错误的概率会大幅下降。6.3 中文变量名、注释风格混乱代码风格的统一问题AI 对技术栈本身没有偏好但代码风格和注释风格会随 prompt 的语种与描述方式漂移。如果你通篇中文自然语言混杂着英文关键词AI 很可能会生成一个“中英混合”的项目变量名从 py 拼音到英文缩写都有注释风格在行号和段落间漂移。只要你的代码不打算长期给团队维护这种风格混乱的代价很小但如果代码要进仓库就必须在项目启动时让 AI 约定统一的风格规范例如“变量名用英文小驼峰注释只保留行注释代码中不建议出现拼音”。这些约定要放到项目的 README 或约束文件里作为长期上下文被 AI 加载。6.4 AI“自信地”把不存在的库写进依赖当 AI 需要借助第三方库实现某个功能时它有时会生成它“熟悉”的库名但这个库在真实环境里未必存在、未必兼容、未必是你要的版本。这种幻觉在 vibe coding 里非常常见。排查技巧是在 AI 跑完安装依赖后立刻检查 requirements.txt 或 package.json逐条核实每个依赖是否真实存在、最新的稳定版号是多少。我建议用“只装最新稳定版 最少依赖”的原则来要求 AI装额外库之前必须先向你说明用途。这个约束能避免不少“为了用而用”的不必要依赖拖累项目。6.5 把“AI 能写”当成“AI 能修”让它是修而不是重写vibe coding 最常见的翻车现场是让 AI 改了一段代码结果 AI 把整段逻辑都换了新逻辑引入了新的 bug。AI 不会天然理解“我要的是小改动不是重构”。在 prompt 里明确写“你不要改动与我提出需求无关的代码只做最小修改”能降低这种情况的概率。和 AI 沟通修改时先圈定文件或函数的范围再给“原有逻辑”留一个快照。一旦 AI 开始重写而不是修补你就要中断重来重新强调“最小改动”原则。7. 一个完整的落地案例复盘前面讲了方法论最后来个实例复盘。我自己最近用 vibe coding 做了一个“内部周报汇总工具”这项目不大但完整走了一遍“自然语言 → spec → agent 开发 → 测试 → 交付”的流程很能说明 vibe coding 和工程化组合的实战效果。背景很简单团队每周都要写周报周报格式是 Markdown存在一个共享目录里。我的需求是做一个网页能读取目录下的周报文件按人汇总、按周筛选、并生成一个合并的 Markdown 导出内容。最开始我直接用 vibe coding 的方式一句话丢给 AI“帮我写一个周报汇总网页”。AI 很快生成了一个 Flask 应用读取目录、展示列表、支持筛选。但测试的时候发现了问题第一它把目录路径写死了换一台电脑就要改代码第二它读取文件时没有处理文件编码同事的中文内容偶尔乱码第三它没有考虑“图片在 Markdown 里的路径要相对周报文件位置解析”这种细节。这些问题都不难修但你能看到没加规格的 vibe coding 确实容易留坑。于是我换了思路写了一份简短但结构化的规格文档项目目标一个本地网页应用用于汇总团队成员的个人周报 Markdown 文件 技术栈Python Flask 原生前端 功能要求 1. 配置一个目录路径可通过 config 文件指定不写死在代码中 2. 页面默认展示所有周报的时间线列表支持按作者、按周份筛选 3. 点击某个作者时合并其所有周报为一个 Markdown 视图并提供导出按钮 4. 文件读取使用 UTF-8 编码遇到无法解码的文件应提示而不是报错崩溃 5. Markdown 渲染时图片的相对路径需基于周报文件所在目录解析 交付标准本地运行 python app.py 后浏览器打开即用无外部数据库依赖 非目标不做多人同时在线编辑、不做权限控制、不做远程部署这份 spec 之后我把内容交给 Agent 式工具让它在项目目录下按规格实现。整个过程里Agent 自主完成了搭建文件结构、安装依赖、代码开发、启动服务、跑通核心路径、修改编码问题等一连串工作。遇到报错时它会自己看日志修复遇到拿不准的比如图片路径解析细节会把问题抛出来问我我再补充说明。最终交付用时大约一个半小时纯手写这套东西我估计要至少半天到一天而且初期版本一定不会比这更完整。更重要的是我不需要提心吊胆地维护它——因为有 spec、有测试、有 Git 记录同事提出修改需求时我能精准地告诉 AI “改动范围在哪个模块”而不是把整个项目重新解释一遍。这个案例给我最大的体感是自然语言驱动开发不是一种取代工程能力的“魔法”而是把“写代码”这个体力活压缩甚至外包掉把精力重新聚焦到“定义问题”“描述边界”“验收质量”这些本来就该由人来做的事情上。当你完成了从“让 AI 写代码”到“让 AI 在没有明确约束时不乱动、在有明确规格时高质量执行”这个意识的转变vibe coding 才真正从玩具变成了生产力工具。