企业官网建设流程全解析

1. 先说清楚：Vibe Coding断片到底丢了什么

1.1 这不是“忘了代码”，而是“断了决策链”

不知道你有没有过这种经历：一个重构任务推进到一半，你正跟AI助手聊得火热，思路连贯得仿佛代码自己会生长，结果一条办公IM消息弹出来说“有个线上问题，你来看一下”。你切过去处理了二十分钟，回来后光标停在编辑器的空白处，盯着半截函数发呆——刚才我要改什么来着？为什么我把这行注释写在这里？

我跟很多同事聊过这件事，发现它特别普遍，而且跟传统编程的“打断”完全不是一回事。过去写代码，你的上下文主要装在大脑里，打断之后花几分钟重新看看代码，基本就能续上。但在Vibe Coding的状态下，你的思维是高度外化的：很大一部分设计判断、演进方向、甚至对当前代码状态的认知，都存在AI会话的对话框里、终端输出里、暂时还没落盘的临时修改里。大脑反而更像是“踩着冲浪板的那个人”，靠的是AI这条浪的推力，而不是自己完整地记着底下的浪形。

所以Vibe Coding被打断，真正丢掉的往往不是某个具体代码块的记忆，而是一条完整的“决策链”：我为了让新功能跟既有模块不冲突，刚才选择了什么方案；我为了让某个历史遗留问题不碍事，临时绕开了哪个分支；我手头这个改动，和上一次提交之间还有多少差距。这些东西只要续不上，回来之后看着代码，每一行都认识，但大脑完全拼接不出“我正要去哪”的画面。

1.2 上下文散落在五个地方，哪一个先丢？

我把一次典型的Vibe Coding工作会话拆开看，上下文其实同时存在五个位置，跟我以前纯手写代码时很不一样。

其中最容易丢、丢了最难受的，不是代码，而是前两项，尤其是AI会话里那些“正在形成但还没定稿”的判断。代码丢了可以重写，但如果连“代码为什么长这样”都丢了，就算对着diff也只能恢复表面，恢复不了灵魂。我后来意识到，要把恢复上下文当成一个有方法论的事来做，而不是每次都靠拍脑门重新推演一遍。

1.3 恢复的本质：补计算出错前的“决策余额”

我自己的理解是，编程本质上是不断做决策的过程，每个文件都是决策的沉淀。Vibe Coding能跑得快，靠的不是少做决策，而是把很多小决策“外包”给了AI，自己只在关键节点把一把方向。这种模式的问题在于，大脑不负责保存完整的决策过程，它只保存“当前怎么想”和“接下来做什么”。一旦打断，这个脆弱的记忆结构立刻塌方。

所以恢复上下文，本质上是重新补足那笔“决策余额”，不是把代码再读一遍，而是把下面这些问题的答案重新算出来：

• 我这次改动要解决的最核心问题是什么？
• 我已经完成到哪一步了？还剩哪几步？
• 我刚才选择了什么方案，为什么这么选？放弃了什么备选？
• 下一步最具体的动作是什么，在哪里动手？

把这四个问题答上来，编码状态就基本回来了。答不上来，就算把代码从头到尾读一遍，也还是不知道从何下手。

2. 把恢复成本前置：编码前的防断片设计

2.1 每次会话都给AI读一遍“会话头”

既然会话上下文容易丢，最朴素有效的做法就是不要只依赖AI去记，而是自己写一个极度简练的“会话头”，放在每次打开新会话时的第一段提示里。我试过很多格式，最后固定下来的是一个很小的模板，大概长这样：

项目：订单模块导出功能 目标：在现有订单列表页面新增CSV导出，复用已有的权限校验中间件。 当前进度：列表查询已调通，正在写导出部分的字段映射。 约束：不走存储过程；导出的字段顺序必须和页面表格一致；单次导出上限1万行。 上一步结论：字段映射放在服务端做，不在前端拼CSV。 下一步：先把OrderExportService的接口签名定下来，再补单测。

这段文字看上去平淡无奇，但它把“目标、进度、约束、结论、下一步”五要素一次性钉在了会话最开头。之后无论AI怎么聊都不会跑偏，更关键的是，当你被打断再回来，直接回看这段就会非常迅速地想起“我刚才在干嘛”。我甚至建议把它作为每个新会话的第一条消息，因为AI也会基于这段话帮你矫正方向，这是成本最低的一道保险。

2.2 全局规则文件，让新会话直接继承记忆

另一个我踩过坑的地方是：项目做大了以后，上下文不是一条会话能装下的。你可能上午在调接口，下午在改数据库脚本，每个会话的话题都不一样，但底层有很多“公开的常识”，比如项目用的是什么技术栈、代码风格偏好、不允许引入哪个方向的依赖、测试要跑哪条命令。这些常识如果每次都要重新跟AI解释一遍，不仅浪费token，而且每次解释得还不一样，AI的行为就会漂移。

我的做法是，在仓库根目录维护一个项目级别的“规则文件”，把那些“每个会话都必须默认知道的事情”写进去，然后在会话头里固定写一句“先读项目规则文件，再回答我的问题”。规则文件里通常包括：

• 技术栈和目录结构，哪个模块对应哪块代码
• 编码约束和禁用的依赖
• 测试与构建命令怎么写
• 常见的坑，比如某个历史包袱代码不能直接删、某个目录里的文件是生成的

这样就算会话断了，甚至隔了一天再从零开新会话，只要这个规则文件在，AI的“基本盘”就不丢。人回来只需要恢复“这个具体任务”的上下文，而不用把整个项目的常识重新教一遍，恢复速度会快很多。

2.3 决策注释：把聊天内容写进代码里

我发现一个很有意思的现象：在Vibe Coding状态下，我跟AI聊天时产生的“设计讨论”往往是最有价值的信息，但也是最不稳定的信息。因为它藏在对话流里，完全没有固化到代码里。等到会话一关，那些“当时觉得特别重要的理由”就随风飘散了。

针对这个，我养成了一个写“决策注释”的习惯——遇到重大取舍时，不只在聊天里跟AI说清楚，还要顺手在代码里留下一两句话，说清楚为什么这么做。比如：

# 这里不直接查库，而是通过OrderService统一取数， # 是为了保持与列表页的行权限逻辑一致，避免二次校验。

或者：

// 注意：导出上限这里先硬编码为1万行，等产品确认后再挪到配置中心。 // 之前直接读配置，结果配置不存在时静默走了全量导出，出过一次事故。

这种注释看起来很简单，但它对恢复上下文的作用非常大。当你被打断回来，只需要扫一眼这些注释，就能复现当时的思维路径，根本不需要去翻聊天记录。说白了，我是把“跟AI说过的关键话”同步复制了一份给未来的自己，这笔账非常划算。

2.4 埋一个 @ctx 标记，找回时靠搜索

除了上面的做法，还有一个我个人很喜欢的小技巧：在代码里埋“恢复点标记”。具体来说，就是当自己正在做一件还处于半成品状态的事，直接在对应代码处留下统一格式的标记，比如：

// @ctx 恢复点：正在给订单导出加权限校验，接口在OrderExportService， // 下一步是把ExecutionContext里的userId传进去，别走旧的token解析。

为什么要用统一的@ctx前缀？因为它让“找回上下文”变成一次全仓库搜索就能搞定的事。我被打断回来之后，先全局搜一下@ctx，就能看到我留下的所有未完成事项，相当于给自己的状态打了个书签。而且不只是自己能搜到，AI也能搜到，新会话里让AI去搜这个标记，它瞬间就知道你干活干到哪了。这个小习惯成本几乎为零，收益却立竿见影。

3. 断片后的五分钟急救流程

3.1 前30秒：趁热倒出“残念”

被打断的一瞬间，大脑里还有一点点余温，这时候最忌讳的是直接切换去做别的事情，把这点余温也浪费掉。我现在的习惯是：不管打断有多急，只要条件允许（哪怕只是30秒），先在某个随手能打开的地方快速写下当前大脑里还热乎的几个要点，不用讲格式，不用写完整句子，像是：

导出功能！刚确定字段映射放服务端，正在写接口签名。 下一步：OrderExportService.addExport方法，注意别碰列表页的查询逻辑。

这个动作的本质，是抓住“决策余额”尚未蒸发的那短短几秒，把它固化到外部存储。你可以记在便签里、放在项目临时TODO里、甚至直接作为一条git stash的message存起来，关键是别让这30秒的付出形成额外负担。写得越随意越好，越随意的机制越能坚持下来，一旦写成正经文档，大脑反而会本能地抗拒。

3.2 1到2分钟：用git状态重新定位“我在哪”

如果断片后你有了一两分钟，别急着打开某个文件从头读起，先去git那看一眼。因为git会诚实地告诉你，你实际做到哪一步了，它不依赖你的记忆。我惯用的几个命令组合是这样：

git branch --show-current git status git diff --stat git log --oneline -5

branch告诉你当前在做什么大方向，status和diff --stat告诉你手头改了哪几个文件、大概动了多少，log告诉你最近提交的节奏。这一套下来，你脑海里基本上会浮现出一个模糊的进度雏形：“哦，我确实在主分支旁边拉了个临时分支，改了3个文件，导出相关的东西应该只动到一半。”这时候再去看那个@ctx标记，和手头的临时记录对在一起，上下文的拼图就已经完成一半了。

3.3 3到5分钟：先跑系统，不要先读代码

很多人恢复状态的第一反应是重新读代码，但我觉得这是效率最低的路径。代码是静态的，读代码只能告诉你“现状是什么样的”，不能告诉你“刚才想干什么”。相比之下，运行时反馈要高效得多——跑一次测试、启动服务、刷新一下页面，让系统用报错或日志告诉你当前代码的状态支离破碎到什么程度。

打个比方，你是一个正在做饭的人，锅里的菜已经炒到一半，你被叫去接了个电话。回来后，盯着菜谱和锅里看一眼，你只能知道“哦，切好的肉已经下锅了”，但只有把火重新打开、尝一口、看看焦没焦，才能真正找到“接下来该放盐还是该加水”的手感。代码也一样，跑一下最近涉及的测试：

pytest tests/test_export.py -x

它过了，说明你做到的那部分没大问题，接下来继续写就行；它挂了，报错点往往就是你离开时正在纠结的地方。运行结果会把你的注意力精准地拽回未完成的那根线上，好过漫无目的地翻10个文件。

3.4 该续会话还是冷启动新会话

不是所有的断片都值得“恢复”，有些时候直接开新会话反而更快。我自己一般按这条经验来判断：如果离开时间很短（比如10到20分钟），且旧会话里的讨论已经收敛到具体方案，那就尽量续上旧会话，把最后那截思路接着走完；但如果中间隔了大半天，或者旧会话里有一堆没结论的废话，与其在旧会话里翻半天找线索，不如请AI基于历史内容做一个速记，然后开一个干干净净的新会话重新出发。

这里还要考虑一个指标：你在旧会话里浪费的token和脑力。如果旧会话已经聊了很长，AI已经被各种试错方向带偏了，你硬要继续，它可能会把你往回拽。我通常会在以下情况选择直接冷启动：

• 旧会话超过一小时，话题早从“导出功能”漂到“为什么测试框架会报时区错误”
• 我已经对方案做出了新的判断，和旧会话里的结论不一样
• 离开期间另一个任务的上下文已经占据了主要记忆，换新话题成本更低

4. 把AI变成恢复工具，而不是第二个负担

4.1 让AI先“背规矩”，再从历史里要清单

既然问题出在上下文丢失，那么最顺手的恢复工具其实还是AI自己，关键是怎么用它。很多人打开新会话后直接问“帮我看看导出功能怎么写的”，AI会一脸茫然，或者给你一段泛泛而谈的架空方案。我的做法是先让AI进入“恢复模式”，也就是给它一个身份和一套明确的指令，它才真的能帮上忙。

比如新会话的第一条消息大概是这种感觉：

我在做一个项目，仓库里有项目规则文件，请先读取。现在我的编码上下文丢失了， 请按下面的方式帮我恢复： 1. 检索仓库中所有带有 @ctx 前缀的注释，汇总其中提到的未完成任务。 2. 查看最近的git diff和未提交的改动，基于你看到的代码，推断我最可能在做什么。 3. 列出你认为是“下一步最该做的一件事”。 请不要泛泛而谈，不要给完整方案，先给我一份恢复速记。

这个提示词的精髓在于，它明确限制了AI的输出范围——不要急着写代码，先把上下文交还给我。实测下来，AI会根据仓库里的痕迹，给出几段非常像样的复盘：“看起来你在OrderExportService里建了类但还没实现导出方法，近期的改动集中在字段枚举上，而且有个注释说要注意行权限……”看到这段话，你脑子里原本雾蒙蒙的画面瞬间就清晰了。

4.2 反向提问校准法：假装失忆让AI问关键问题

有时候你连仓库里有哪些痕迹都懒得去搜，或者搜到的信息太碎，这时候可以换一个思路：反向让AI先提问。我把它叫作“失忆测试法”。你在新会话里直接对AI说：

我刚刚被人打断，完全忘了自己在这个项目里做到哪一步了。 请先别急着给方案。基于项目规则文件、git状态和最近的改动， 向我提出最重要的5个问题，用来帮你判断我当前的任务状态。 我来回答，你再帮我整理成一份恢复计划。

这招很妙，因为AI被问到“该问什么问题”时，它会主动去扫描代码库和改动痕迹，然后问出一些非常聚焦的问题，比如：“你最近在改订单导出的字段映射，是不是准备把导出放到服务端做？请问这个导出要支持筛选条件吗？”这些问题本身，就是最高效的上下文唤醒剂。我在回答问题的过程中，经常能想起之前的一些具体判断。这比自己对着代码干瞪眼高效得多。

4.3 把当前的diff直接甩给AI反推意图

如果你连“自己做到哪一步了”都不太确定，还有一个损招，就是把git diff直接交给AI，让它反推你的意图。这个技巧对那种已经写了一半、但你自己都忘了为什么这么写的场景特别有效。操作很简单，先执行：

git diff > /tmp/current_change.diff

然后把这段diff内容粘贴给AI，告诉它：“这是我未提交的改动，请根据diff内容推测我原本想实现的功能，说明我在哪些地方可能还没做完，哪些地方只是临时调试用的。”AI读了diff之后，通常能给出类似这样的判断：“你新加的这段字段枚举映射，看起来是为了让导出列的顺序跟页面保持一致；但有个接口还没被引用，推测是残留代码，另外有个TODO说明你正准备处理分页边界。”这种视角很像让一个细心的结对同事帮你复盘半小时，一下就能把你从“全是代码”的泥潭里拉出来。

4.4 一次实际恢复的完整演示

为了说清楚整套恢复流程跑起来是什么样，我描述一个典型的场景：我正在给订单模块写导出功能，代码还没提交，这时来了个紧急告警，我离开了一个多小时。回来后，我做的事情依次是：

先花30秒写下一句模糊的速记：“导出，字段映射，服务端，还没写完”。然后打开终端，跑了一遍git status和git diff --stat，发现自己改了4个文件，且都在导出相关目录。接着没有去读代码，而是直接跑了一次刚接触过的测试，结果测试没过，报错正好在字段映射那一行。我把这个报错、diff内容和那句速记一起丢给一个新开的AI会话，附上项目规则文件路径，让AI先汇总。AI搜到@ctx标记里写着“下一步把userId传进去”，结合报错位置，给出了一个非常具体的判断：“你正准备把当前用户信息传入导出服务，但那一块的参数还没接全，所以测试才在字段枚举阶段就挂了。”整个过程大概六七分钟，我就已经回到一个可以继续敲代码的状态，没有浪费半小时去把整个服务再通读一遍。

5. 长期做法：把“被打断”当成正经开发事件来管

5.1 每个任务维护一张上下文卡

急救流程跑得再顺，也只是事后的补救，长期来看，更划算的是把“可恢复性”设计进日常工作流里。我现在每个稍微有点分量的任务，都会在本地建立一个极简的“上下文卡”文件，它就放在任务相关的目录下，甚至可以直接命名成ctx-card.md。里面的内容非常固定，五段话：

• 任务目标：一句话说清楚要交付什么
• 关键决策：最近几次重要取舍，以及理由
• 当前进度：已完成的部分、未完成的部分
• 下一步行动：最具体的一件事（不是“继续做导出”，而是“在xxx接口里把userId传进去”）
• 坑与备注：任何踩过的雷、绕行的理由

这个文件不需要天天写，每天开始干活时花两分钟更新，或者每次开新会话前更新一次就够。它最大的价值在于，就算你隔了一周才回来接手这个任务，或者干脆是另一个同事接手，打开这张卡片，基本上十分钟内就能无缝对接。我把这看成是给自己写的一种“交接文档”，只不过交接对象的默认是不靠谱的未来的自己。

5.2 会话命名与归档规范，让一周后的你能搜到

AI会话工具如果不做管理，很快会变成一个巨大的“什么都有但什么都找不到”的垃圾场。我以前吃过这个亏：一个会话里聊了三个不同功能，一周后想找当时关于权限校验的一段讨论，翻了半天都没找到，最后只能凭记忆重推一遍。现在我会强制自己在每个阶段性的会话开始时，给会话起一个“项目-模块-目标”格式的名字，比如“订单导出-服务端字段映射-确定方案”。如果会话里聊着聊着跑题了，我会主动另起新会话再拉回来，不把多个意图搅在一趟对话里。

与此同时，每隔一段时间（我一般是一个功能分支收尾时），我会让AI根据当前会话生成一段摘要，然后粘贴到刚才说的ctx-card.md里，或者归档进一个专门的“AI会话备忘”笔记里。这段摘要不需要很文艺，只要留住“当时确定了什么、否掉了什么、遗留了什么”就行。等以后再搜关键词，能一下子找到当时的结论，而不是重新读一遍几百行对话。

5.3 一个被低估的做法：故意人为制造一次“冷恢复”演练

最后分享一个我自己觉得很有意思、但很多人不太会用的小技巧：主动训练自己的恢复能力。简单说就是在任务做得正上脑的时候，刻意停下来，隔一段时间再回来，全程不看任何恢复提示，先凭记忆写一段“我现在要做到哪了”的描述，然后再对照ctx-card和代码，看自己漏掉了多少。

这个做法听起来有点自虐，但效果出奇地好。我第一次这样测试的时候，发现自己凭记忆只能恢复出大概40%的上下文，好多关键决策都沉没在对话里了。排查完之后才知道，我平常的“以为自己在跟踪进度”其实是一种幻觉，大脑早就把记忆外包给了外部工具。从那以后，我不但更勤快地维护上下文信息，还对“什么时候该主动休息一下再把状态找回来”这件事有了更理性的预期——恢复不是一瞬间的事，而是一个需要持续训练肌肉记忆的过程。

慢慢地，你会发现自己不再怕被打断了。因为无论在哪里、以什么姿势停下，你都已经知道怎么在几分钟内把自己重新拉回那条编码的浪上。这才是Vibe Coding真正该有的样子：享受AI带来的流畅感，但不让这份流畅感变成不可恢复的依赖。被打断是常态，能被快速接回来，才算真正掌握了节奏。