企业官网建设流程全解析

1. 从“执行者”到“协作者”：我为什么放弃让AI直接堆代码

先聊点背景。我手里这个所谓“终极指挥中心”，不是某个大厂发布的炫酷产品，而是我自己在连续做了几个AI辅助编程项目之后，被逼出来的一个工作流集合。我把它命名为Vibe Kanban。

过去很长一段时间，我的AI编码工作流非常原始：打开聊天窗口，把需求往对话框里一丢，说一句“帮我写个XXX功能”，然后等它输出一坨代码，复制粘贴到项目里，跑一跑，报错，再把报错贴回去，继续让它改。这套流程写小脚本、做一次性Demo没问题，但一旦项目膨胀到几十个文件、涉及多模块协作，AI程序员立刻变成“AI大漏勺”——改了一个函数，另外三个地方跟着崩；问它当前项目结构，它一脸茫然；让它把某段逻辑重构一下，它给你把整个文件都重写了一遍。

问题的根子不在模型智商，而在上下文的管理方式。你每次新建对话时，AI的“记忆”是从零开始的，它并不知道这个项目的全貌、之前的架构决策、哪些代码是碰不得的核心逻辑。你让一个没有项目的“全局视图”的程序员空降进一个复杂项目，还指望它不闯祸，这本来就不现实。

所以我开始琢磨：能不能换一种思路，不要让AI单纯处于“被安排写代码”的被动位置，而是让它进入“全程旁观项目状态”的协作者角色？

Vibe Kanban的雏形，就是在这个念头下长出来的。说白了，它是一个以**看板（Kanban）**为视觉核心的工程管理框架，但管理的不是人，而是AI。它把项目拆成一张张卡片，每张卡片承载一个明确的任务、对应的上下文切片、验收标准，然后让AI按卡片顺序逐张消化、逐张完成。AI不是“上来就闷头写”，而是先看板、再开工。我后来又给这套工作流加了一个“项目经理”层——也就是让AI站在更高维度做任务拆解、优先级排序和风险预警，它自己给自己派活，自己验收，我只负责审核和调整方向。

如果你也正在用AI写代码，但觉得“越用越乱”，这篇文章值得你花几分钟看完。接下来我会把这套系统的完整逻辑、卡片写法、上下文管理方案、实操步骤、踩坑记录全部摊开，你可以直接抄走用。

2. 为什么要用“看板+项目经理”模式管AI，而不是继续对话流

先说一个容易被忽略的事实：编程这件事，复杂度的大头从来不在写代码本身，而在于状态管理。

一个人写代码时脑子里要同时存着好几层信息：项目整体架构长什么样、当前要做的功能处于哪个模块、这个模块和外部接口的契约关系是什么、哪些依赖需要升级、哪些代码是历史遗留的坑。人类程序员靠着“工作记忆”硬扛，扛不住就画流程图、写设计文档。AI也是一样，它也需要一个“外置大脑”来存放这些状态信息。

对话流最大的问题，就是没有状态。每次对话都是一个新的快速记忆片段，模型只能基于当前窗口内的文字做推测。你前脚刚让它封装了一个网络请求库，后脚它在另一个文件里写接口调用时，完全不知道还有这么一个库的存在，于是又给你写了一套新的、风格还不一致的请求逻辑。这种“失忆”在越大的项目上越致命。

看板模式解决的恰恰是这个痛点。看板的本质是一个结构化、可追溯的外部状态库：

• 每张卡片对应一个原子任务，卡片内容就是该任务所需的全部上下文（ 相关代码路径、接口定义、依赖说明、验收标准）。
• 任务之间的依赖关系用卡片排序和标签表达，AI按顺序处理卡片，天然保持逻辑连续性。
• 卡片完成情况实时记录，AI在任何时刻都可以通过阅读看板，快速重建项目全局视图，而不需要重新问东问西。

那为什么还要再加一个“AI项目经理”角色？因为任务的拆解和排期，本身比执行任务更消耗脑力。

让AI直接写一个“用户登录模块”，它可能撸起袖子就开干，中途越写越偏。但如果让它先当着项目经理，面对同样的需求，它会被要求输出：功能点拆分、每个功能点的输入输出、涉及的数据表结构、需要前后端联调的接口协议、哪些任务可以并行、哪些任务有前置依赖。你会发现，一旦进入拆解视角，AI的输出列表严谨得多，而且后续写代码时，它是在给自己列出的卡片逐项打勾，走神的概率大幅降低。

我用一个类比来说明这套模式的价值：传统对话流像你雇了一个外包程序员，每次都临时拉群，项目背景靠你口头描述，他说好就好；看板+项目经理模式像你招了一个带“项目文档+任务清单+自我汇报”习惯的全职员工，他自己看文档，自己排计划，做完一项汇报一项，而你只需要做评审、改方向。

实测下来，用Vibe Kanban方式管理AI后，我项目里的无效重写次数减少了大概七成，返工率高的问题基本被压住了。

3. Vibe Kanban的骨架设计：看板、卡片、上下文切片一个都不能少

很多第一次接触这套思路的人，第一反应是“这不就是给AI用Jira或者Trello吗”。我最初也试过直接扔给AI一个维护良好的在线看板链接，结果它读了一堆卡片标题、任务描述，真正写代码时还是两眼一抹黑，因为卡片内容不达标准，AI根本没法把描述转化为代码动作。

Vibe Kanban的卡片不是普通项目管理的任务票，它是一种面向AI阅读的可执行规格说明书。我用的看板结构分成四层，每层解决一个具体问题。

第一个是列结构。我固定设置五列：待拆解、待实现、进行中、待验收、已完成。AI项目经理负责把需求从“待拆解”推进到“待实现”，每个功能点都有明确归属。这一步看起来像普通看板，核心差别是：普通看板的列转移由人类组长做，这里的列转移由AI自己判断并同步更新，人类只在验收关口介入。

第二个是卡片模板。每张卡片必须包含六段固定字段，少了任何一个都可能让AI在执行时靠猜：

• 编号与标题：标识卡片唯一身份，也方便在讨论中引用。
• 上下文路径：指向相关的代码文件、接口文档、数据模型定义，路径就是AI进入项目相关区域的“门票”。
• 任务目标：写清楚要交付什么，不是“优化代码”这种模糊话，而是“将user表查询逻辑迁移到新的UserRepository类，保持对外接口返回结构不变”。
• 约束与禁忌：明确哪些不能碰、哪些依赖不能升级，防止AI顺手把全局公共模块改了。
• 验收标准：可验证的结果描述，比如“新增单元测试覆盖3个分支场景，全部通过”。
• 关联卡片：标明前置或依赖的卡片编号，AI在实现当前卡片前可以先阅读关联卡片内容。

第三个是全局上下文池。我单独维护了一个项目级文档，记录项目的技术栈、目录结构、第三方依赖清单、已知技术债、架构约定。这个文档对所有卡片可见，AI项目经理在拆解任何任务时，都先读这个池子，再动手拆卡片。这相当于给AI补上了“项目全局记忆”。

第四个是动态状态记录。看板不仅记录“任务做了什么”，还记录“任务做的时候改了什么”。每张卡片进入完成状态时，AI必须输出变更摘要——改动了哪些文件、新增了什么函数、对外接口有没有变化。这些摘要会被归档，为后续卡片提供上下文依据。

这套骨架我只花了一个下午就搭建完毕，用的是一个Markdown仓库加脚本辅助解析。没有必要一开始就上重型系统，先让流程跑通，再慢慢补工具。

4. 实操落地的核心环节：从需求拆解到代码实现的全流程跑通

如果你现在就想把Vibe Kanban引入自己的项目，不建议一上来就做全套，容易中途放弃。我建议先按照下面的最小闭环走一遍，等感受到效果再加固。

4.1 第一步：用AI项目经理拆解需求，产出第一批卡片

选择一个中等复杂度的小功能，最好是那种你原本想直接让AI“一口气写完”的需求。拿一个真实案例说：我打算给项目加一个“标签系统”，允许给文章打标签、按标签筛选文章列表。我打开一个新的AI会话，给它的角色设定是“资深技术项目经理”，然后把三样东西喂给它：全局上下文池的内容、当前项目目录树、以及一句话需求“实现文章标签系统”。

接着我向它下发指令，注意指令要具体：

• “请先不要写任何代码。依据上下文池中的架构规范和目录结构，将上述需求拆解成适合逐张落地的开发任务卡片。”
• “每张卡片必须包含文件路径、数据模型修改建议、对外接口变化、验收标准，并标注任务之间的依赖关系。”
• “拆解完成后，将卡片写入看板目录的TODO区，并按依赖关系排序。”

AI输出了一组卡片，我记得当时一共拆出来8张：数据库标签表设计、标签与文章的关联模型、标签CRUD接口、文章筛选查询扩展、前端标签输入组件、文章列表页筛选交互、单元测试、文档更新。每张卡片都带了明确的路径和建议。我稍作调整，把数据库设计提到最前面，把测试卡合并到实现卡中，然后发出开工指令。

这一步的窍门在于：**不要让AI既当项目经理又当程序员在同一轮同时干活。**拆解阶段就要催它把卡片写到外部文件里并结束会话；进入实现阶段后再重新开会话，读卡片开工。分开的好处是上下文更纯净，拆解阶段的输出也不会被后来写代码的临时思路冲掉。

4.2 第二步：让AI按卡片逐张实现，而不是一次包圆

卡片就位后，我逐个打开实现会话。每个会话只聚焦一张卡片，我在会话里粘贴卡片全文，并补充当轮任务声明：只实现当前卡片字段中的内容，不得改动卡片约束中列出的禁区文件。

以“数据库标签表设计”这张卡片为例。AI首先根据卡片里的上下文路径读取了现有的models目录和数据库迁移脚本，发现项目中已有category表，于是参考了它的字段风格，输出了一套一致的tags表定义。这就是看板上下文切片的意义：AI不是凭空设计，而是基于既有约定做增量扩展。

让它依次处理后续卡片时，我注意到一个明显变化——实现“标签CRUD接口”时，它主动读了“数据库表设计”卡片的变更摘要，直接引用了表名和字段名，而不是自己猜一个新的命名。这在过去的对话流模式下很难发生，因为旧会话里AI根本不知道曾经定义过哪些字段。

每完成一张卡片，我都会要求AI把“动态状态记录”写的更新同步到看板：哪些文件已修改、生成了哪些接口、改动是否引入了新的依赖。然后我再人工复核一遍关键文件，再把卡片移入“待验收”。

4.3 第三步：验收关口必须由人来做，哪怕只是抽查

我不太建议完全信任AI的“自评已通过”。AI说“测试通过”和真的全部测试跑通之间，有时隔着一条巨大的鸿沟。在Vibe Kanban工作流里，我的验收步骤分两层。

第一层是自动验收，我自己写了一个极简脚本，扫描当前分支的diff文件列表，与看板卡片中记录的预期改动文件做比对，任何超范围的文件变动都会标红提示。

第二层是人工抽验。我不逐行审查AI生成的每一个函数，但会重点看三类内容：对外部API的调用是否符合既有封装、新增表结构是否与现有迁移脚本风格一致、公共模块是否被无意中修改。只看这三个方面，基本能拦住绝大多数的问题。

这个三层流程走完，一个标签系统完整落地，总耗时大约一个半小时，其中人工介入的部分不到二十分钟，剩下的都是AI在看板引导下自动完成。相比过去我在聊天窗口里跟AI反复纠缠“怎么又报错”“这里逻辑不对”动辄耗掉半天，效率提升是可以量化的。

5. AI项目经理的进阶玩法：角色切换、上下文池维护与必要的“防呆机制”

基础跑通后，我开始琢磨怎么把这套系统用得更顺手。这里分享几个实测有效、也踩过坑的进阶玩法，它们决定了Vibe Kanban到底是摆设还是真正好用的指挥中心。

5.1 角色切换的纪律：拆解会话和实现会话分开开

第一次我自己偷懒，在同一个会话里先让AI拆卡片，紧接着又说“好，现在开始写代码”，AI立刻从项目经理模式切换成程序员模式。结果它写代码写到一半时，又把整个项目的需求重新理解了一遍，前几张卡片的拆解逻辑几乎等于被丢弃。后来我定了条死规矩：**拆解会话产出卡片后立刻结束，实现会话重新起炉。**每轮会话都只给AI一个单一角色，绝不混淆。这条纪律直接让AI输出的质量上了一个台阶。

5.2 上下文池不是死文档，需要持续更新

上下文池的价值全部依赖于它的准确度。如果池里写的是旧目录结构，AI基于错误信息拆解任务，后面的卡片全都会跑偏。我现在养成了一个习惯：每个功能完成验收后，花两分钟把变更摘要合并进上下文池，删除过时内容。这相当于给AI的长期记忆做“轻量提交”。这事不能攒着月底一次性做，否则上下文池就废了，AI很快会开始胡说八道。

5.3 约束“禁忌区”必须写具体，不要写废话

卡片里的“约束与禁忌”字段，最初我写得很空泛，比如“保持代码风格统一”“注意性能优化”，AI看了等于没看。后来我改成可执行的具体约束，效果立刻不一样。举一个例子：“不要修改gateway目录下的路由注册文件，路由变更请增加在router-extend目录中独立注册”。一个具体的路径约束，能让AI避开你精心维护的核心区域。约束字段宁可多写路径，不要写形容词。

5.4 用“防呆卡片”提前拦截AI的常见低级错误

AI编码最常见的翻车模式，不是逻辑写不出来，而是“过度自信地创造了不存在的依赖”。比如它写了一个from store import client，但项目里根本没有store模块，它也不去确认，直接假设存在。我在看板里固定插入三张“防呆卡片”，不指向任何具体功能，只写检查项：全局搜索确认所有import的第三方库已安装、所有引用的变量或函数有明确的定义点、所有改动文件均符合项目现有代码风格。每批开发任务结束后，AI都会被要求执行这三张卡片的自检流程，低级错误发生率下降得非常明显。

6. 实践中踩过的坑，以及一套可行的避坑清单

再好的框架，不踩几回坑也打磨不出来。我在Vibe Kanban的实践里栽了不少跟头，把它们整理出来，希望你能避开。

6.1 坑：AI自作主张重写整个文件

有过一次经历，我让AI修改某个工具函数，它直接把整个工具模块重写了，旧函数名替换掉了，导致其他十几个文件全部报错。原因在于卡片里没有限制“仅修改指定函数”，AI只看到工具模块路径，以为整个文件都是它的舞台。

解决办法写在卡片模板里：明确标注“本卡片的改动范围仅限于指定文件内的指定函数，其余函数保持原样，禁止删除或重命名现有对外接口”。现在我的每张卡片里，“约束”字段的有效性甚至比“目标”字段还重要。

6.2 坑：AI按卡片工作时，读了一个过期的上下文

我早期上下文池没养成及时更新的习惯，某次卡片任务里我引用的数据模型路径已经在上一个功能中调整过了，AI照着旧路径去找文件，自然找不到，它发挥“聪明才智”——顺手新建了一个同名文件，差点造成两份定义并存的混乱局面。从那以后我给自己定下规矩：上下文池更新先于任何新卡片的创建，旧路径未更新前，不允许下发新卡片。

6.3 坑：看板卡片写得越细，AI越听话，但细也不能细到替AI做设计

某次我吸取“AI过度发挥”的教训，把一张卡片的字段写得极其详细，连循环里变量名都给出来了。结果AI写完代码后失去灵活性，遇到边界情况时完全没有自主调整，固守在精确指令里面。后来我总结出卡片颗粒度的平衡点：**任务目标写清楚，约束边界写清楚，但中间的实现路径留白。**AI需要的是方向和禁区，不需要每一步的步幅约定。

6.4 常见问题速查表

7. Vibe Kanban适用边界与后续扩展空间

我必须承认，这套工作流不是银弹。它最适用的场景是长期维护的代码项目、有多模块结构的业务系统、需要跨多次会话连续开发的工程任务。项目越复杂、周期越长，上下文管理带来的收益就越明显。

反过来，如果你只是临时写一个几十行的小脚本，或者做个一次性数据处理Demo，真没必要上Vibe Kanban，普通的对话流反而更轻快。用了它反而会觉得手续繁琐，效率降低。工具要匹配场景，这点我体验很深。

另外一点，Vibe Kanban的模式并不仅限于编程。我最近已经尝试把它迁移到AI辅助写文档的场景：先让AI项目经理拆解一份长报告的章节，每张卡片对应一个章节的写作任务，卡片中包含该章节需要引用的材料路径和风格要求，AI按卡片逐章写作。效果一样不错，文档前后风格统一度比传统一个会话连续写要高不少。

后续我打算给它加一个自动化的看板状态看板脚本，把卡片从Markdown字段里解析出来，生成可视化的看板网页，省去手动移动卡片位置的繁琐。但目前这套方案的问题不在工具层面，而在于一个更深的挑战：如何让AI在长时间项目周期中持续保持“状态一致性”。看板只是解决了部分问题，真正的完整记忆方案大概需要把向量数据库加进来，但现在这套流程已经比裸对话流稳太多了。

对我个人来说，Vibe Kanban带给我的最大改变，是让我重新理解了AI协作的边界——AI不是替你做一切的执行者，它更像一个记性很差但能力很强的新同事。你需要给它文档、给它清单、给它检查表。它做出来的东西是否可用，最终还是要你来把关。这个认知，比任何具体工具都值钱。