1. 我为什么从“AI帮我写代码”转向“AI陪我写工程”
先说一个我自己的真实状态变化。最早接触Vibe Coding的时候，我完全是把它当“AI帮我写代码”来用的。想法特别简单：脑子里有一个画面，比如一个数据看板，左侧是筛选器，右侧是趋势图，点击某个节点能弹出详情弹窗——然后我就把这个画面丢给大模型，让它“先来个能跑的东西”。半小时后，真的跑起来了，那一刻的爽感是没法形容的。但爽完之后，紧接着就是一连串头疼的事：加一个筛选条件，改了三个文件还带出一个新Bug；同一个页面，我上午让AI改的样式，下午再让它加功能，它告诉我“这个组件我没见过，要我帮你新建吗”；最崩溃的一次，一个看起来只改按钮文案的小需求，我让AI连着重构了两次，最后整个页面在手机上直接白屏。
这几件事凑到一起，我才开始认真思考一个问题：Vibe Coding这个名字本身就很有迷惑性——它强调的是“氛围”“感觉”“跟着直觉走”，但工程交付这件事，最不缺的就是直觉，最缺的是边界。灵感驱动的写法可以让我们在十分钟内拥有一个Demo，却无法让我们在十天后还拥有一个能继续开发、能交给别人维护、能经得起业务变化的产品。换句话说，Vibe Coding的真正难点，从来不是“怎么让AI写出第一版”，而是“怎么让这个从灵感里长出来的东西，最后变成一个可以交付的工程”。这篇文章想聊的，就是我在这几个月里反复试错之后沉淀下来的方法论——不否定Vibe Coding的创造力，而是给它套上一套工程化的骨架，让它从“写出来爽”变成“交付了也爽”。
这篇文章适合谁看呢？我觉得是所有正在用AI辅助编程、尤其是已经体验到“Demo跑起来很快、项目长不大”这种落差的人。不管你是个人开发者做自己的小工具，还是在团队里负责某个模块的探索性开发，只要你的工作流里已经出现了“让AI写代码”这个动作，这套方法论就值得你花二十分钟看完，并且可以立刻用在你手头的项目上。
2. 灵感驱动式开发的真实工作模式：它为什么会火，又为什么会翻车
想给Vibe Coding立规矩，得先看清楚它到底是一种什么样的工作模式。我把它拆成五个阶段，这五个阶段几乎是所有Vibe Coding玩家的共同路径，也是后面所有工程化改造的着眼点。
2.1 Vibe Coding的典型五段式工作流
第一阶段是画面驱动。你想做一个东西，脑子里通常先有一个“画面”，而不是一份需求文档。可能是某个工具用着不爽，你想象了一个更顺手的交互；可能是看到别人展示了一个效果，你觉得自己也能做一个。这个画面往往是不完整的——只有主界面，没有空态、异常态、边界条件，但没关系，它足够具体，大到可以丢给AI。
第二阶段是描述生成。你把画面翻译成一段自然语言描述，比如“帮我做一个番茄钟，要有圆形的进度环，下面有开始暂停和重置按钮，时间到了要弹窗提醒”。语言口语化、逻辑松散、甚至还有前后矛盾，但AI能听懂，而且会主动帮你把缺的部分补上。这是Vibe Coding体验最好的时刻——你觉得自己在跟一个懂行的同事描述想法，而这个同事永远有耐心。
第三阶段是快速验证。AI生成的代码直接跑起来，你会立刻获得一个可交互的Demo。这里有个心理学上的关键点：Demo能跑的那一刻，你的“拥有感”会被极大满足，你会不自觉地进入“这已经算完成了”的错觉状态。这也是为什么很多Vibe Coding项目会止步于Demo，因为大脑已经拿到了奖励，继续打磨的动力就被消解了。
第四阶段是迭代叠加。你需要加功能、改交互、修Bug，于是继续用自然语言去指挥AI。这个阶段开始出现裂缝：AI会忘记最初的结构，你也会忘记自己让它改过什么，改A坏B的情况开始频繁出现。因为你没有给AI建立一个“持续更新的上下文”，每次对话都是拿着旧地图找新路。
第五阶段是交付挣扎。当你终于想把项目拿给别人看、或者部署上线的时候，问题集中爆发：没有错误处理，没有配置管理，代码里散布着AI自作主张写的“魔法数字”，甚至有些功能是AI自己加戏加上去的。你面对一个“能跑但不敢动”的代码库，陷入重构还是重写的两难。
2.2 为什么“能跑”不等于“能交付”
很多人会辩解说：Vibe Coding本来就是用来做原型、做小工具的，谈工程化不是抬杠吗？我的回答是：你当然可以只拿它做一次性原型，但只要你有一天想把这个原型变成产品，那些工程问题就一定会找上门，只是时间早晚的问题。
我用一个生活化的类比来解释“能跑”和“能交付”的区别。你在家里搭一个地台，用泡沫垫拼一拼，人能睡，叫“能跑”。但你如果想把这个地台送进家具店卖，就得考虑承重、防火、甲醛、边缘割手、地台会不会滑动、拼接处会不会积灰——这些不是“更高的追求”，而是“能交付”的基本线。代码也一样：能跑是私人的，能交付是公共的。一旦你的代码要被别人运行、被别人修改、被别人依赖，它就必须满足一些它自己不会主动满足的条件。
具体到软件工程里，“能交付”至少包含这几个硬指标：
- 可复现：换一台机器、换一个人，按照同样的步骤能把项目跑起来。
- 可修改：改一个需求，你知道要动哪几个文件，且大概率不会牵连出无关的Bug。
- 可验证：你有一套办法判断这次改动是好的还是坏的，而不是靠肉眼盯着屏幕。
- 可交代：代码写完之后，你能说清楚每一块是干什么的，为什么这么写，哪些地方是临时的、哪些是要长期保留的。
这四条，每一条都正好打在Vibe Coding的软肋上。不信的话，你现在打开手边最近一个让AI写的项目，逐条对照一下，大概率会发现每条都勉强达标或直接不达标。
2.3 Vibe Coding翻车的三种典型死法
我把自己和身边朋友踩过的坑总结成三种典型的“死法”，每一种都很常见。
第一种是上下文漂移死。你从第一轮对话开始，让AI做了很多次修改，但每一次修改都没有留下结构化的记录。AI逐渐忘记最初的设计意图，你也在对话历史里迷失。到后期，你跟AI说“把那个列表改成卡片样式”，AI问“哪个列表？”，你才意识到，代码里已经有三个列表了，而且你根本分不清哪个是哪个。这种死法最隐蔽，因为它不是立刻爆发的，而是让你的沟通成本一点点变高，直到你失去耐心。
第二种是技术债爆雷死。AI生成代码的特点是“量多但不深”——它擅长覆盖功能表面，但很少考虑错误处理、边界条件、性能退化。我在一个项目里就遇到过，AI为了实现一个文件上传功能，顺手在全局安装了三个npm包，其中两个功能重复，还有一个版本冲突导致整个项目安装失败。当你开始花大量时间收拾AI留下的烂摊子时，Vibe Coding就变成了Vibe Debugging。
第三种是需求错位死。你让AI做出来的东西，你以为完成了，但实际跟你的真实需求差了好几个维度。最典型的情况是：你描述“用户登录”，AI给你做了一个完整的前端登录页面，表单校验、社交登录按钮、忘记密码跳转全都有，但你实际需要的只是给内部工具加一个最简陋的密码门禁。AI在“过度响应”你的描述，而你因为不懂代码，看不出这个偏差，等发现的时候已经付出了两天的无用工作量。这种死法在非技术背景的Vibe Coding玩家身上尤其高发。
3. 破局的起点：把“灵感”当作需求线索，而不是需求结论
搞清楚了Vibe Coding为什么会翻车，方法论的第一步就很明确了：你要在“灵感”和“代码”之间，加一道叫“需求整理”的工序。这一步是很多人不愿意做的，因为它看起来特别不“Vibe”——本质上，这等于要求你把脑子里那团模糊的直觉，翻译成一套连AI都能准确理解的结构化约束。但恰恰是这个不Vibe的动作，能帮你避免前面说的需求错位和技术债爆雷。
3.1 把“画面”翻译成三个层次
面对一个灵感，我建议你花十五分钟，把它拆成三个层次：
第一个层次是体验层。就是你脑子里那个画面，用户会看到什么、会点什么、会感觉到什么。这个层次不需要技术词汇，用大白话写就行。重点是把它写下来，不要只存在脑子里。因为当你把画面写到纸上的时候，它才会从一团感觉变成一个可以被审视的对象。
第二个层次是逻辑层。你要回答一个问题：这个产品/功能，它的核心操作路径是什么？用户进来第一眼看到什么，然后能做什么，做完之后得到什么？比如你做番茄钟，核心路径就是：看到一个计时器→点击开始→专注25分钟→听到提示→记录完成。把这条路径写出来，你就已经建立了一个最简单的验收框架——之后AI做出来的东西，你只要对着这条路径一步步走，就能立刻判断它到底算不算完成了。
第三个层次是条件层。这层难度最高，也是Vibe Coding最容易漏掉的。你要提前想清楚：这个功能在什么情况下会变得复杂？比如番茄钟，如果用户点到一半切到别的App，计时还准吗？如果用户打开多个番茄钟标签页，声音是重复响吗？如果系统时间是12点跨零点，数据统计算哪一天？这些边界条件不需要你全部想齐，但你需要至少列出三到五个你觉得最可能出问题的场景，把它们作为待验证项交给AI，让AI帮你处理。
3.2 一份“十五分钟需求卡”的具体模板
我给自己设计了一个极简模板，每次开始Vibe Coding之前都填一遍，大约只需要十五分钟。你可以直接抄走用：
- 我想做什么：一两句话描述最终体验，不写技术名词。
- 核心操作路径：用户从进入到离开的3到5步关键动作。
- 我不想做什么：明确列出边界，比如“我不需要用户系统”“我不做移动端适配”“暂时不需要数据持久化”。这条特别重要，它能刹住AI过度加戏的倾向。
- 我最担心的三个点：你预感会出问题的场景，或者你不确定应该怎么处理的地方。
- 验收时我会怎么试：你准备用哪些具体操作来判定它做完了。
这份需求卡不用发给任何人看，它的作用是让你在启动Vibe Coding之前，脑子里已经有了一个关于“什么算完成”的坐标。有了这个坐标，你后面跟AI对话的质量会完全不一样——因为你不再是“我有个感觉你帮我做出来”，而是“这是我想要的体验，这是我关心的边界，请你在这个范围内工作”。
3.3 一个真实的对比：填卡前后，AI的输出质量差多少
我之前做过一个特别小的工具，就是一个茶饮配方换算器，输入茶的克数和水量，按比例换算成不同杯量。第一次我什么都没填，直接跟AI说“做一个茶饮配方换算工具”，AI给了我一个很通用但完全不贴合实际使用的页面——它默认按“一人份”换算，还加了很多我完全用不上的星级评分功能。第二次我填了需求卡，明确写了“我不需要评分”“我最担心的是小数位太多，希望结果保留整数”“核心路径是：输入当前克数→选择目标杯量→看到建议克数”。第二次AI生成的页面，一眼看过去就是我脑海里的那个画面，几乎没有多余的装饰，所有逻辑都对得上。
填卡这件事的本质，不是限制AI的创造力，而是把“自由发挥”限定在你真正想要的范围内。AI越自由，生成的内容越发散；你的约束越具体，生成的内容越精准。这个体验上的巨大差异，你试一次就能感受到。
4. 可交付工程导向的Vibe Coding四层方法论
需求卡解决的是“做什么”的问题，接下来的方法论要解决“怎么做才能交付”的问题。我把整个Vibe Coding过程重新组织成四个层级，每一层都有明确的输入、操作和产出。这四层是递进关系，但你不需要严格按顺序走完一遍才动手——实际上，你应该在动手的前两轮内，就同时把这四层的种子都埋下去。
4.1 第一层：模块边界层，让AI只改它该改的
Vibe Coding最常见的失控方式，是让AI一次性生成一个巨大的单体文件，然后后续的每一轮修改都在这块巨石上打补丁。要解决这个问题，你不需要懂多深的架构理论，只需要在第一次对话时，就给AI设定一个最基本的文件组织约定。
具体操作是：在需求卡里加一条“技术约束”，明确写出你希望的代码组织方式。比如：
- 页面结构、交互逻辑、样式文件分离，不要全部写在一个文件里。
- 通用的数据处理函数单独放一个文件，方便后续复用和测试。
- 所有可配置的常量（颜色、阈值、默认值）集中在一个配置文件里。
你不用告诉AI具体怎么拆，只要给它这个约束，它就会天然地生成一个结构更清晰的项目。而我实测下来，这个约束带来的收益特别直接：后续你再提修改需求时，AI能更准确地定位到应该修改的文件，而不是每次都在整个项目里Search一番然后给出一版让你眼前一黑的“全量重构”。
如果你用的是像某代码编辑器自带的那种AI对话模式，你可以直接把这句话加在提示词里：“请按以下结构组织代码：页面、逻辑、样式分离；通用函数独立成文件；常量集中配置。”这一句话，就能把项目从“一次性代码”拉向“可维护代码”一个很大的身位。
4.2 第二层：可执行度层，把“帮我做”改成“按计划做”
很多人跟AI的对话是“帮我做一个番茄钟”，这是一个典型的“结果导向指令”，AI会自己决定实现的路径和细节。而工程化导向的Vibe Coding，要求你把“结果导向指令”拆解成“计划导向指令”，也就是让AI先出方案、再动手。
我现在的习惯是，第一轮对话先不让AI写任何代码，而是要求它做两件事：输出一个实现要点列表，以及给我3到5个需要我确认的关键决策点。比如我让它做番茄钟，我希望它先告诉我：它将用哪种计时方案（浏览器原生计时是否可靠）、数据存在哪里（要不要做持久化）、通知用哪种方式（浏览器通知还是页面内弹窗）。等它列完，我来做决定，它再动手。这个过程看起来多了一轮对话，但它把你从“被AI带着走”变成了“指导AI往前走”。
这一层还有一个重要的操作：每次对话都要带上一个“变更记录”区块。就是你在提新需求之前，先告诉AI当前项目处于什么状态，上一轮完成了什么、有没有遗留问题。实测下来，AI在拥有明确的“当前状态+目标状态”信息时，生成代码的准确率和稳定度会明显高于“从零开始猜你的上下文”。这也解释了为什么很多人Vibe Coding到后期越来越卡——因为AI丢失了上下文，而你还在期待它能像第一天一样懂你。
4.3 第三层：工程护栏层，让AI生成的代码具备基本抗风险能力
有了一堆AI生成的代码之后，你要做的第一件事不是继续加功能，而是给它装上几道“工程护栏”。这不是什么高深的事，就是一组最基础的前置条件：
- 版本管理。不管项目多小，第一天就放进版本管理仓库里，并建立初始提交。这一步的意义不是装样子，而是给你一个“随时可以回退”的心理安全网。有了这个网，你才敢大胆地让AI尝试各种改法，因为你知道最坏的情况不过是回退到上一个版本。没有这个网，你每次让AI改代码都像走钢丝。
- 环境配置。把运行依赖、启动命令、环境变量写进一个说明文件里。AI生成的代码通常不会自己写文档，但你可以在项目生成之后，专门用一轮对话让AI补一个最小的运行说明。这个说明文件存在的意义是：一周之后的你、或者接手项目的同事，能不看代码就搞懂怎么把项目跑起来。
- 错误边界。让AI给所有用户输入和外部接口调用加上异常处理。这一条特别重要，因为AI默认生成的代码往往是“快乐路径”代码——所有条件都符合预期、所有操作都成功。真实使用中，用户一定会输入非法值，网络一定会抖动，接口一定会偶尔挂掉。没有错误处理的代码，在这些时刻会直接白屏或崩溃，而你作为开发者，在那一瞬间会觉得自己是个门外汉。
- 基础测试。不要求全面的单元测试，但至少让AI给它写的核心逻辑函数加上几个基本断言。比如换算工具，至少得确认“输入100克，目标杯量300毫升，输出不会是负数”。这一层护栏的价值在于，当它存在时，你后续每一轮AI修改，都能用一条命令验证“原有的功能有没有被改坏”。
你可能会觉得这些操作太“重”了，跟Vibe Coding的自由气质相悖。我的看法是：这些护栏其实是在保护你的Vibe Coding体验。有护栏的情况下，你每次让AI改东西，都能快速确认“这次改动有没有破坏原有功能”，于是你越改越敢改；没有护栏，你越改越怕，最后变成“这个项目我不敢动了”。哪个更Vibe，你自己可以比较一下。
4.4 第四层：验收复盘层，用“走查剧本”替代“肉眼确认”
最后一个层级，也最容易被忽略，就是验收。Vibe Coding的玩家验收功能的方式，通常是“把页面打开看一眼，觉得不错就完事了”。这种方式的问题在于，你的“看一眼”和真实用户的“用一下”之间，隔着一整套操作细节。
我建议你在需求卡的基础上，给每个功能写一份“走查剧本”——就是你把核心操作路径和边界条件，翻译成一系列具体的操作步骤，然后一步步执行，实际验证AI生成的代码是否真的符合预期。比如番茄钟的走查剧本可以是：
- 打开页面，确认计时器显示25:00。
- 点击开始，等待5秒，确认倒计时在走。
- 切换到其他应用，再切回来，确认计时没有重置。
- 点击暂停，再点击开始，确认能接着之前的时间走。
- 把专注时长临时改成0.1分钟，确认时间到之后会弹窗提示。
- 重复点击开始两次，确认不会出现两个计时器叠加。
走查剧本不用写得很花哨，但它的核心价值在于：你在“交给AI去改”之前，先建立了一份“什么算通过”的基准。当AI改完一版，你只需要把剧本过一遍，就立刻知道这版是好了、还是坏了、还是引入了新问题。我在实际项目里，越来越依赖这份剧本——它让我跟AI之间的协作，从“玄学”变成了“流水线质检”。
5. 一套经过验证的Vibe Coding协作流程：从零到可交付的六步走
方法论说完，我把它压缩成一套可以直接照做的六步流程。这套流程我试了很多次，每一步都踩过坑、做过调整，最后留在下面这个版本。你可以先按原样跑一遍，跑通了之后再根据自己的习惯微调。
5.1 准备阶段：十五分钟需求卡，磨刀不误砍柴工
第一步，打开一个新文档，把需求卡的五个问题填好。我建议这一步一定不要省，尤其是“我不想做什么”和“我最担心的三个点”这两个问题，它们在后面对话里的价值最大。你要相信，花十五分钟想清楚边界，能帮你省掉后面可能长达数小时的拉锯战。
这十五分钟里，你还可以补一个动作：把“技术约束”这一条写进去。如果你的经验不多，可以用我前面给的默认三条：页面、逻辑、样式分离；通用函数独立成文件；常量集中配置。如果你已经有自己的习惯，按自己的来就行。
5.2 启动阶段：先让AI出方案，而不是先出代码
第二步，把需求卡的内容发给AI，但明确要求它“先不要写代码，而是给我一个实现方案”。具体你可以这样说：
“这是一个[工具/页面/功能]的需求说明。在我确认方案之前，请不要生成代码。请你先给我：1）你打算如何组织文件和模块；2）你需要用到哪些关键技术或库，以及理由；3）你认知中的三个关键设计决策，需要我来确认。请用简洁的要点回复我。”
这个请求有两个作用。一是让你在正式开工之前，有机会对AI的思路做一次“方向校正”，而不是由它自己闷头决定。二是给你输入“你是在主导项目”的位置，这会直接影响到后面AI听你话的程度。实测下来，经历过方案确认环节的AI，在后续修改时明显更配合、更少“自作主张”。
5.3 开发阶段：一小步、一小步地走，每一步都提交
第三步，进入生成阶段。这时候要克制一个冲动：不要一次性让AI输出整个项目。你应该按功能模块来，一次生成一个可以独立验证的单元。
举个例子，做番茄钟，我建议第一轮只让它做主计时器，不包括设置、统计、通知。生成之后，立刻运行、肉眼验证核心逻辑，然后做一个“初始提交”。第二轮再加暂停/重置，第三轮再加通知，第四轮再加设置页面。每一轮都走“生成→验证→提交”的小循环。
这样做的好处有两点。一是每次改动之后，你都清楚地知道新引入了什么，出了问题能精准定位；二是提交历史本身就是一份天然的开发记录，之后AI丢失上下文时，你可以把提交记录丢给它，快速重建上下文。
5.4 修改阶段：使用“当前状态+目标状态”的对话公式
第四步，是贯穿整个开发过程的对话公式。每一轮想让AI改东西时，不要只丢一句需求过来，而是带上项目的当前状态和目标状态。我常用的模板是：
“当前状态：番茄钟的主计时器、暂停、重置已完成并提交。核心代码在timer.js，样式在style.css。已知问题：计时精度在切换标签页时可能有偏差。目标状态：我需要增加一个自定义专注时长的设置入口，用户可以输入1到120之间的整数分钟。请在现有结构上修改，不要重构，不要改变已有API。完成后告诉我你改了哪些文件。”
你把这样一段丢给AI，它接收到的信息密度和单纯那句“加一个自定义时长设置”完全不是一个量级。前者让AI确切知道自己在改什么、不能动什么、改完要汇报什么；后者则让AI在两个小时的摸索里逐渐迷失。
这里有一个关键技巧：好的Vibe Coding不是“让AI自己管理项目”，而是“你来充当项目管理的中枢”。AI是执行者，你是协调者，所有的任务拆解、进度跟踪、状态汇总，都是你的事。不要把这个职责外包给AI，否则项目一定会失控。
5.5 验收阶段：走查剧本逐条过，用日志留下证据
第五步，每当一个功能开发完，就拿出需求卡里写好的走查剧本，一条一条地过。过的时候注意记录结果——不用很正式，就在剧本旁边标注“通过”或“不通过”即可。
这一步有一个容易犯的认知偏差：你总觉得AI刚生成完的东西“看起来没问题”，就不仔细测了。但经验告诉我，AI生成的Bug往往不在“看起来”的地方，而在“操作到某一步”的时候才出现。比如空态下点击按钮、快速连续点击、输入超长文本、切换系统主题，这些都是AI代码的重灾区。走查剧本的价值就在于，它在你“觉得没问题”的时候，逼你把所有操作路径都走一遍，用证据替代感觉。
5.6 收尾阶段：锁定范围，整理文档，完成结项
第六步，收尾。这一步的目标是让项目处于“即使半年后再打开，也能快速恢复上下文”的状态。
你需要做三件事。第一，锁定范围：明确告诉自己和AI，这个版本做到这里为止，不再新增需求。这一条能防止你陷入“再加一个小功能”的无限循环。第二，命令AI补一份简短的“项目摘要”，包括目录结构、核心逻辑位置、已知问题和下一步建议。这份摘要可以放在代码仓库的根目录里。第三，把需求卡、走查剧本、项目摘要三份文档放在一起，做一个“结项归档”。如果这个项目以后要继续做，你只需要重新启动一个AI对话，把这三份文件丢给它，它就能在很短时间内恢复工作状态。
6. 一个小型项目的完整复盘：走一遍方法论的真实案例
光是讲方法论，你可能还是觉得隔了一层。我带你看一个具体的小项目，把上面六步走完整走一遍，包括每一步发生了什么、我踩了什么坑、最后交付的结果长什么样。
6.1 项目背景与需求卡填充
大概两三个月前，我想给自己做一个“会议纪要时间轴”工具。背景是：我每周参加很多个线上会议，有些需求要逐段track进度，但对着一整份纯文本纪要，找“上次说改动启动时间”这种信息特别费劲。我的想法是做一个本地网页工具，把会议纪要粘贴进去，然后按发言段落生成一条时间轴，每条可以打标签（比如“待办”“决策”“风险”），点击标签可以筛选。
填需求卡时我写的是：
- 我想做什么：一个本地网页，粘贴会议纪要后自动分段，生成可打标签的时间轴。
- 核心操作路径：粘贴文本→点击生成→看到分段时间轴→给某段打标签→按标签筛选→刷新页面后数据还在。
- 我不想做什么：不要用户登录，不要云同步，不要移动端适配，不做权限管理。
- 我最担心的三个点：自动分段会不会切错；刷新后标签和筛选结果能不能保留；数据量很大的时候页面会不会卡顿。
- 验收时我会怎么试：粘贴一份十段以上的纪要，生成后手动检查每段是否完整；打三个标签并筛选；刷新页面看标签是否还在。
这个卡片我大概花了十分钟填完。现在回头来看，这十分钟是整个项目里性价比最高的一笔投入。
6.2 逐步生成与每一次关键决策
第一轮对话，我按照方案确认的要求，让AI先输出实现方案。AI给出的方案是：用原生HTML/CSS/JavaScript，不做构建工具，数据存在浏览器的本地存储里，分段逻辑先用“空行+发言人标识”作为规则。它提出了两个需要我确认的决策点：一是要不要支持手动合并分段，二是分段规则是固定的还是可配置的。
我当时的决定是：先不要手动合并（因为属于低频操作，以后再加），分段规则可以先按“发言人+空行”跑，如果效果不好再调。确认之后，AI才开始生成代码。
第一版生成出来，页面是一个简洁的文本框加一个生成按钮，粘贴内容后可以生成时间轴卡片列表，每张卡片右下角有三个预设标签（待办、决策、风险），点击标签会进入筛选模式。这个版本基本满足了我的核心需求，我提交了初始版本。
接着第二轮，我处理“刷新后数据保留”的需求。这里用了一个比较稳妥的方案：把数据存进浏览器的本地存储，每次编辑都自动同步。第三轮，我发现AI生成的分段逻辑在“同一发言人连续说两段话、中间没有空行”的情况下会把两段合并成一段，我对这个结果不满意。于是我按照“当前状态+目标状态”的公式给它发了一段描述，让它增加一个“按时间戳分割”的辅助策略，同时保留现有的空行规则，两边取并集。
这轮修改产生了一个新问题：时间戳分割把部分文本误切成了过细的碎片。我走了一遍走查剧本，定位到是分割规则用了“所有以数字开头的内容”作为边界，导致正文里的“1. 项目背景”这种序号也被当成时间戳。我把这个问题反馈给AI，让它把时间戳规则收敛为“时分秒格式且出现在段首”的内容。改完后，分割准确率明显提升，误切现象基本消失。
6.3 这个项目最终交付了什么
最终交付的形态是一个零依赖的单页面工具，就是双击HTML文件就能在浏览器里跑起来。核心功能四条：粘贴会议纪要生成时间轴、给任意段落打标签、按标签筛选、刷新后数据自动恢复。整个开发过程，我没有手写过一行代码，但我做了产品决策、步骤规划、验收测试和问题定位。项目从开始到结项大概用了两天，总耗时不到四个小时，这是我用传统方式完全达不到的速度。
更重要的是，这个工具在我后续的日常工作中被高频使用，我也敢在它上面继续加需求——后来我还加了一个“导出Markdown”的功能，整个过程是按照同样的六步走下来的，项目没有因为加了需求而变质。这让我对Vibe Coding的信心真正建立起来了：它确实可以从灵感出发，但完全可以到达工程的彼岸，前提是你在中途做了那几件最关键的事。
7. 团队场景下的Vibe Coding：需要额外补充的三条协作纪律
前面讲的方法基本都适用于个人开发者，但如果你所在的环境是团队协作，Vibe Coding带来的挑战会成倍增长。这里有三条额外的纪律，是我在跟团队一起尝试Vibe Coding之后总结出来的。
7.1 纪律一：AI生成代码必须有明确的“所有者”
团队协作的第一条原则是：任何代码进入工作区之前，都必须有一个明确的人类所有者。这条看起来是废话，但Vibe Coding恰恰容易模糊它——当所有人都能用AI生成代码时，很容易出现“这块代码谁都能改、谁都不负责”的状态。
我的建议是，在项目开始前，就把每个模块的所有者指定清楚。比如A负责时间轴模块，B负责筛选逻辑，C负责导入导出。当AI生成代码时，生成结果先经过对应所有者的审查，他有权决定是接受、修改还是打回。这条纪律能保证代码质量有人兜底，而不是出了问题大家面面相觑。
7.2 纪律二：AI对话记录必须沉淀为项目文档
个人开发时，你跟AI的对话历史不重要，因为这周的你记得上周的自己说过什么。但团队协作时，对话历史是别人完全无法读取的“私人笔记”。如果不把AI对话中产生的决策和约定沉淀成文档，同事翻开代码仓库时会完全不知道这些代码是为什么这么写的。
所以，每完成一个需求，我用AI做第三件事：要求它生成一份“修改说明”，内容包括本次变更涉及的文件、变更的原因、遗留的风险点、以及与下一阶段计划的衔接点。这份说明被追加到项目文档里。久而久之，这个文档就变成了一个“团队版的AI对话记忆库”。任何人接手项目，先读这份文档，再决定要不要去问原作者。
7.3 纪律三：用走查剧本代替口头描述作为验收标准
团队协作里，描述一个功能“好不好”是特别消耗沟通成本的事。你跟你同事说“这个功能感觉不太行”，他听不懂；你说“这个筛选按钮在无结果时应显示空态而不是报错”，他就完全清楚了。走查剧本在这里的价值被放大了，因为它提供了一种跨人的、无歧义的功能验收语言。
我们在团队里约定：每个用户故事上线之前，开发者先用AI生成一版走查剧本，然后产品经理和测试同事逐条确认并补充场景，再转入开发。这样，验收标准在开发前就已经对齐了，AI生成的代码有了明确的“及格线”，团队之间的沟通负担也大幅下降。
8. 关于Vibe Coding“能不能用于生产”我的最终判断
文章写到这里，我想把一个最关键的态度放在最后：Vibe Coding到底能不能用于生产环境？我的答案是——可以，但要看你有没有完成那套“把灵感变成工程”的转换工作。
Vibe Coding的天赋是带宽。它让你从“把想法翻译成代码”的低效劳动中解放出来，直接进入了“把想法翻译成自然语言，再由AI翻译成代码”的高速通路。这套通路的极限很高，但它的地基也很浅——如果你不主动做模块切分、不做状态管理、不做验收验证、不留下文档，它就只能停留在“写Demo”的水平。
我见过不少人对Vibe Coding的两种极端态度：一种是全盘否定，“AI写代码就是垃圾，只能做玩具”；另一种是全盘拥抱，“代码不用人写了，以后就没有程序员了”。我的感觉是，这两种态度都像是因为不会游泳就骂水、或是因为水花好看就跳进去。实际的情况是，Vibe Coding是一个工具，它的价值高度依赖于使用者的工程素养。一个懂软件工程的人，能用它十倍速地交付一个结构完整的项目；一个不懂软件工程的人，会用它十倍速地制造一个结构混乱的代码库。工具没有变，变的是握着工具的人。
我个人的体会是，Vibe Coding带来的不是“编程门槛消失”，而是“编程门槛上移”。以前你做一个小工具，最大的门槛是语法、框架、配置，现在这些被AI代劳了，门槛移动到了更上游的位置：你有没有想清楚你想要的体验？你有没有预见边界条件？你有没有能力判断那坨代码是不是真的好？这个门槛其实更考验人，但也更接近做产品、做工程的本质。所以我对Vibe Coding的态度，是认真地把它的创造力套进一套工程骨架里，让灵感可以走得更远，而不是被一句“能跑就行”留在原地。
