企业官网建设流程全解析

1. 问题+标签驱动开发的核心思路拆解

1.1 为什么传统开发流程在AI协作时代开始失灵

过去几年我跟不少团队聊过开发流程的问题，发现一个很普遍的现象：任务管理工具用得挺全，看板、甘特图、燃尽图一个不落，但真正落到每天的编码环节，大家还是靠脑子记、靠聊天记录翻、靠“我记得上次好像改过这里”。这种模式在人少、需求稳定的阶段勉强能跑，一旦引入AI辅助编码，问题就暴露得特别快。

AI不像人，它没有“上下文记忆”这回事。你让它改一个函数，它不知道这个函数属于哪个需求、之前为什么这么写、改了之后会影响哪些模块。你每次都得重新把背景喂给它，喂少了它改错，喂多了它抓不住重点。更麻烦的是，AI改完代码之后，你很难判断它到底完成了多少、有没有遗漏、下一步该做什么。进度变成了一个模糊的感觉，而不是一个可以看见、可以追踪的东西。

问题+标签驱动开发就是冲着这个痛点来的。它的核心逻辑很简单：把每一个开发动作都挂在一个明确的“问题”上，再用“标签”给这个问题打上状态、类型、优先级等维度，让AI和你都能通过这套标记系统快速定位当前进度和下一步动作。说白了，就是给开发过程装上一套“路标系统”，人看得懂，AI也读得懂。

1.2 问题驱动和标签驱动各自解决什么

先拆开看这两个概念。

问题驱动的意思是，你不再以“文件”或“功能”为单位来组织开发，而是以“问题”为单位。这里的问题不一定是bug，它可以是一个需求、一个优化点、一个待验证的假设、甚至一个技术债清理项。每个问题有唯一的编号、标题、描述、验收标准。你打开编辑器，第一件事不是想“我要改哪个文件”，而是想“我现在要解决哪个问题”。

这样做的好处是，AI拿到问题描述之后，能直接理解意图，不需要你反复解释背景。而且问题本身就是一个天然的进度单元——解决了就关闭，没解决就挂着，状态一目了然。

标签驱动则是在问题之上加了一层维度。一个问题是“待处理”还是“进行中”还是“待验证”，这是状态标签。一个问题是“前端”还是“后端”还是“数据层”，这是领域标签。一个问题是“高优先级”还是“可以等等”，这是优先级标签。标签的好处是，你可以用任意维度去筛选、分组、统计，而不需要改变问题本身的结构。

两者结合起来，就形成了一套轻量但足够表达力的开发语言。你不需要复杂的项目管理软件，一个支持标签的简单问题列表就够了。关键是这套语言AI能理解，你也能理解，双方在同一个频道上对话。

1.3 可视化进度到底在可视化什么

标题里提到“可视化你和AI的开发进度”，这里需要说清楚可视化的对象是什么。

不是可视化代码行数，那个指标意义不大。不是可视化提交次数，那个容易被刷。真正值得可视化的是三件事：

第一，问题的流转状态。有多少问题待处理、多少在进行中、多少待验证、多少已完成。这个分布能告诉你当前是在推进还是在卡壳。

第二，标签的分布情况。比如“高优先级”的问题里有多少还挂着，“前端”相关的问题是不是堆积了，“技术债”标签的问题有没有在持续清理。这些分布能暴露流程中的瓶颈。

第三，你和AI各自贡献了什么。哪些问题是AI独立解决的，哪些是你介入之后才推进的，哪些是双方反复拉扯的。这个维度能帮你判断AI在哪些类型的任务上靠谱，在哪些类型上还需要你兜底。

可视化的形式可以很简单，一个按标签分组的列表、一个状态统计的小面板、甚至就是终端里打印出来的彩色标签汇总。重点不是好看，而是让你在每天开始工作之前，花十秒钟就能知道“现在该干什么”。

1.4 这套方法适合谁、不适合谁

适合的场景很明确：你已经在用AI辅助写代码，但觉得协作过程有点乱；你的项目规模不大不小，大到需要追踪进度，小到不值得上重型项目管理工具；你愿意花一点时间在写代码之前先把问题描述清楚。

不适合的场景也说一下：如果你的项目就是一次性脚本，写完就扔，那没必要搞这套；如果你团队里所有人都不愿意写问题描述，只想直接改代码，那这套方法推不动；如果你已经在用一套很成熟的需求管理流程，并且AI已经能很好地接入那套流程，那也不需要重复建设。

我自己的判断是，这套方法最适合独立开发者和小团队，尤其是那些“一个人加几个AI”的工作模式。人多了之后需要更正式的协作协议，但人少的时候，这套轻量标记系统刚刚好。

2. 核心细节解析与实操要点

2.1 问题描述怎么写才能让AI一次读懂

这是整套方法里最关键的细节。问题描述写得好，AI一次就能给出靠谱的修改；写得不好，你得来回解释五六轮，效率反而比手写还低。

我试过很多种写法，最后沉淀下来一个模板，包含四个必填字段：

• 背景：一句话说明这个问题是在什么场景下出现的。比如“用户上传图片后，预览区域在移动端显示不全”。
• 期望：一句话说明你希望改成什么样。比如“预览区域在移动端应该自适应宽度，不出现横向滚动”。
• 约束：列出不能破坏的东西。比如“不能改变现有上传接口的入参格式”“不能引入新的第三方依赖”。
• 验收：给出可验证的标准。比如“在宽度375px的视口下，预览图完整显示且无横向滚动条”。

这四个字段加起来不超过一百字，但信息密度足够高。AI拿到之后，不需要猜你的意图，也不需要问你“要不要考虑某某情况”，因为它知道约束和验收标准了。

注意：约束字段特别重要。AI在没有约束的时候，会倾向于用最“通用”的方案，而通用方案往往引入你不想要的依赖或改动。把约束写清楚，能省掉大量返工。

2.2 标签体系怎么设计才不臃肿

标签最容易出的问题是越加越多，最后变成一团乱麻。我见过一个项目里光状态标签就有“待处理”“待确认”“待排期”“进行中”“暂停”“待验证”“待合并”“已完成”“已关闭”“已归档”十种，实际上常用的就三四种。

我的建议是，标签分三组，每组不超过五个值：

状态组：待处理、进行中、待验证、已完成。四个就够了。“待验证”这个状态很关键，它是AI改完之后、你确认之前的缓冲区。没有这个状态，你要么过早关闭问题，要么把“进行中”一直挂着。

类型组：功能、修复、优化、技术债。四个值覆盖绝大多数情况。类型标签的作用是帮你统计“我最近是不是一直在修修补补，没有推进新功能”。

领域组：根据你的项目来定，但建议不超过五个。比如前端、后端、数据、部署、文档。领域标签的作用是帮你发现“某个领域的问题是不是堆积了”。

三组标签组合起来，一个问题的完整标记大概是“进行中 + 修复 + 后端”这样。你在看板上一眼就能看出当前工作的分布。

实操心得：标签值一旦定下来，就不要轻易加新的。如果发现某个标签很少用，就删掉。标签体系的价值在于稳定，频繁变动会让历史数据失去参考意义。

2.3 问题编号和标签的命名规范

编号这件事看起来小，但不规范的话后面筛选和引用会很麻烦。我的做法是用“类型首字母 + 四位数字”的格式，比如F001表示第一个功能类问题，B002表示第二个修复类问题。这样编号本身携带了类型信息，你在提交信息里写“解决F001”的时候，一眼就知道是功能还是修复。

标签的命名统一用小写英文加连字符，比如in-progress、tech-debt、front-end。不要用中文，不要用空格，不要用大写。原因是这些标签经常要在命令行、提交信息、配置文件里出现，中文和空格会带来转义问题，大写容易和别的系统冲突。

问题标题的命名也有讲究。我习惯用“动词 + 对象 + 条件”的格式，比如“修复移动端预览区域溢出问题”“优化图片上传的压缩逻辑”。避免用“关于某某的讨论”“某某问题跟进”这种模糊标题。标题是AI理解问题的第一入口，写得具体一点，AI的第一次回复质量会明显提高。

2.4 可视化面板的最小实现

可视化不一定需要图形界面。我目前用得最顺手的是一个终端脚本，每次开始工作前跑一下，输出大概是这样的：

状态统计： 待处理 12 进行中 3 待验证 2 已完成 28 类型分布（未完成）： 功能 5 修复 4 优化 3 技术债 5 领域分布（未完成）： 前端 6 后端 5 数据 3 部署 3

这个输出不到二十行，但信息量足够。你能看到待处理的问题是不是太多了，技术债是不是积压了，某个领域是不是卡住了。如果待处理超过十五个，我就知道该停下来清理一下，而不是继续往里加新问题。

实现方式很简单，问题列表存成一个Markdown文件或者JSON文件，每个问题带标签，脚本读取之后按标签分组统计。用Python写的话大概三十行代码，用Shell写也差不多。关键是养成每天看的习惯，而不是追求面板多漂亮。

提示：如果你用Git，可以把问题列表文件纳入版本管理。这样每次提交都能看到问题状态的变化，回溯的时候特别方便。

3. 实操过程与核心环节实现

3.1 从零搭建问题列表文件

我以Markdown文件为例，因为可读性最好，AI也容易解析。文件名叫ISSUES.md，放在项目根目录。每个问题的格式如下：

## F001 修复移动端预览区域溢出 - 状态：进行中 - 类型：修复 - 领域：前端 - 背景：用户上传图片后，预览区域在移动端显示不全 - 期望：预览区域在移动端自适应宽度，不出现横向滚动 - 约束：不改变上传接口入参格式，不引入新依赖 - 验收：375px视口下预览图完整显示且无横向滚动 - 备注：AI已提交第一版修改，待验证

这个格式的好处是，人读起来清晰，AI解析起来也简单。你可以在文件开头加一个说明，告诉AI这个文件的用途和字段含义，这样AI在需要的时候可以自己读取和更新。

问题列表不需要一次性写全。我的习惯是，每天开始工作前花五分钟，把今天要做的事情写成问题条目。写的时候不用太细，但背景、期望、约束、验收这四个字段尽量填上。填不上的说明你还没想清楚，那就先别开始写代码。

3.2 用标签驱动AI的第一次修改

当你把问题描述写好之后，下一步是让AI基于这个问题进行修改。这里的关键操作是：把问题描述作为提示词的核心部分，而不是只给一个模糊的指令。

我试过两种方式。一种是直接说“帮我改一下预览区域的样式”，另一种是把F001的完整描述贴给AI，然后说“请根据这个问题描述进行修改”。后者的第一次回复质量明显更高，因为AI知道了约束和验收标准，不会给出引入新依赖或者破坏接口的方案。

具体操作上，我习惯在对话开头加一句：“当前项目的问题列表在ISSUES.md，我现在要处理F001，请先读取该问题的完整描述，然后给出修改方案。”这样AI会先去读文件，理解上下文，再动手。虽然多了一步读取，但省掉了后面反复解释的时间。

实操心得：如果AI给出的方案超出了问题描述的范围，不要直接接受。先问它“这个改动和F001的约束是否冲突”，让它自己检查一遍。很多时候它会意识到问题并调整方案。

3.3 状态流转和验证环节的操作细节

问题从“进行中”到“待验证”的流转，是整个流程里最容易被忽略的环节。很多人AI改完就直接关闭问题，结果后面发现改错了或者改漏了，又得重新打开，状态历史就乱了。

我的做法是，AI完成修改后，先把状态改成“待验证”，然后在备注里写清楚“AI已提交修改，修改内容概述如下”。然后我自己跑一遍验收标准，确认没问题了，再把状态改成“已完成”。如果验收不通过，状态改回“进行中”，备注里写清楚哪里没通过。

这个流程看起来多了一步，但实际上帮你保留了完整的修改历史。后面如果发现类似问题，你可以翻看之前的问题记录，看看当时是怎么验收的、AI改了什么、有没有踩过坑。这些记录积累下来，就是你自己项目的知识库。

验证环节还有一个技巧：不要只验证“期望”是否达成，还要验证“约束”是否被遵守。AI有时候会为了达成期望而悄悄破坏约束，比如为了实现自适应而引入了一个新的CSS框架。验收的时候把约束字段拿出来逐条检查，能避免很多隐性技术债。

3.4 每日进度回顾的具体做法

我每天结束工作前会花三分钟做一次进度回顾，具体做三件事：

第一，更新问题状态。把今天实际完成的问题改成“已完成”，把还在进行中的问题备注一下卡在哪里。

第二，检查标签分布。看看“待处理”是不是超过十五个了，“技术债”是不是又增加了，“高优先级”里有没有挂太久的。如果发现异常，第二天优先处理。

第三，写一句当日总结。比如“今天主要在处理前端布局问题，AI在CSS修改上表现不错，但在响应式断点选择上需要我介入”。这句话积累下来，一个月后你就能看出AI在你项目里擅长什么、不擅长什么。

这个回顾不需要工具支持，就是打开ISSUES.md，手动改几个字段，写一句话。但坚持下来之后，你会发现自己对项目进度的感知变得非常清晰，不再有“好像做了很多但又说不清做了什么”的感觉。

3.5 和版本控制的配合方式

问题列表文件和代码一起纳入版本控制，提交信息里引用问题编号。比如提交信息写“F001 修复移动端预览溢出”，这样你在翻提交历史的时候，能直接对应到问题记录。

更进一步的做法是，在问题条目的备注里记录相关的提交哈希。比如“备注：AI已提交修改，commit abc1234，待验证”。这样从问题能追溯到代码，从代码也能追溯到问题，双向可查。

如果AI直接帮你提交代码，记得在提交之前检查一下提交信息里有没有引用问题编号。没有的话手动补上。这个习惯看起来小，但后面排查问题的时候特别有用。你能快速知道某次改动是为了解决什么问题，而不是对着一堆“update”“fix”的提交信息发呆。

4. 常见问题与排查技巧实录

4.1 问题描述写得太模糊导致AI反复改错

这是最常见的问题。典型表现是AI改了一版，你觉得不对，让它再改，它又改了一版，还是不对，来回五六轮之后你放弃了，自己手动改。

根因通常在于问题描述里缺少“约束”和“验收”字段。AI不知道什么不能动，也不知道什么算改好了，只能凭感觉猜。猜对了是运气，猜错了是常态。

排查方法很简单：把问题描述拿给一个不了解上下文的人看，问他“你知道我要改成什么样吗”。如果他说不知道，那AI大概率也不知道。补上约束和验收标准，再让AI试一次，通常一轮就能到位。

避坑技巧：如果一个问题你发现自己没法用一百字描述清楚，那说明你还没想清楚要做什么。这时候不要急着让AI动手，先花十分钟把问题想明白，写清楚，再开始。

4.2 标签越加越多导致筛选失效

前面提过标签臃肿的问题，这里说具体的排查和清理方法。

每隔两周，把标签列表拉出来看一遍。统计每个标签下有多少问题。如果一个标签下只有一两个问题，考虑合并到相近的标签里。如果一个标签连续两周没有新增问题，考虑删掉。

清理的时候注意保留历史数据的可读性。比如你把“待确认”合并到“待处理”，那之前标记为“待确认”的问题要批量改成“待处理”，而不是留着旧标签不管。否则后面筛选的时候会漏掉。

我的经验是，标签体系稳定下来之后，每两周清理一次就够了。清理的时候顺便看看有没有长期挂着的“进行中”问题，如果有，要么推进，要么改回“待处理”，不要让它一直挂着占位。

4.3 AI修改超出问题范围怎么处理

AI有时候会“顺手”改一些你没让它改的东西。比如你让它修一个样式问题，它顺便把相邻组件的逻辑也重构了。这种改动往往不在你的验收范围内，但已经发生了。

处理方式分两种情况。如果改动是合理的、你认可的，那就把它记录成一个新问题，标记为“已完成”，备注里说明“由F001的修改附带完成”。这样进度记录不会丢，后面回溯的时候也知道这个改动是什么时候发生的。

如果改动不合理或者你不确定，那就回退。不要因为“改都改了”就勉强接受。AI的附带改动往往没有经过你的约束检查，可能引入隐性风险。回退之后，在问题备注里写一句“AI修改超出范围，已回退”，提醒自己下次在提示词里把约束写得更明确。

4.4 进度可视化数据不准怎么排查

可视化面板的数据来自问题列表文件，如果数据不准，通常是两个原因：要么问题状态没有及时更新，要么标签拼写不一致导致统计遗漏。

排查步骤：

1. 检查最近关闭的问题，看状态字段是不是真的改成了“已完成”。有时候你口头说完成了，但文件里还写着“进行中”。
2. 检查标签拼写。比如“front-end”和“frontend”会被当成两个不同的标签，统计的时候就会漏。
3. 检查有没有问题条目缺少标签字段。缺少标签的问题不会出现在任何分组里，相当于隐形了。

我自己的习惯是，每次更新问题状态之后，跑一下统计脚本，看看总数对不对。如果总数和预期不符，说明有问题的状态或标签没写对，当场修掉，不要拖。

4.5 常见问题速查表

这张表我贴在显示器旁边，遇到问题先查表，大部分情况都能快速定位。查不到的再深入分析，分析完把新发现补到表里，慢慢就形成自己的排查手册了。

4.6 几个我踩过的坑和对应的解法

第一个坑是问题编号重复。早期我没有用类型首字母加数字的格式，而是简单地从001开始递增。结果功能类和修复类混在一起，后面想按类型筛选的时候发现编号没有规律，只能靠标签。后来改成F/B/O/T开头，编号本身携带类型信息，筛选方便多了。

第二个坑是备注写得太简略。一开始我只写“已修改”，后来发现回溯的时候完全想不起来改了什么。现在备注里至少写三件事：改了什么文件、改了什么逻辑、验证结果如何。写的时候多花三十秒，后面省三十分钟。

第三个坑是可视化面板太复杂。我试过用图形界面做面板，花了两天时间，结果后面维护成本太高，慢慢就不用了。现在回归到终端脚本，三十行代码，零维护成本，反而坚持下来了。工具越简单，越容易持续用。

第四个坑是AI读取问题列表时解析失败。Markdown格式虽然人读着舒服，但AI解析的时候偶尔会把字段认错。后来我在文件开头加了一段固定的格式说明，告诉AI每个字段的标识符是什么，解析成功率就上去了。这段说明大概五十字，但省了很多麻烦。

4.7 怎么判断这套方法适不适合你当前的项目

一个简单的判断标准：如果你发现自己每天开始工作时，需要花超过五分钟才能决定“今天先做什么”，那这套方法就值得试。如果你已经有一套很顺手的任务管理方式，并且AI能很好地接入，那不需要重复建设。

另一个标准是看AI修改的返工率。如果你让AI改三次以上才能达到预期，说明问题描述环节有问题，这套方法里的约束和验收字段能帮上忙。如果AI一次就能改对，那说明你的描述已经足够清晰，继续保持就行。

我自己的体会是，这套方法最大的价值不在于工具本身，而在于它强迫你在动手之前先把问题想清楚。很多时候，写问题描述的那五分钟，比后面改代码的一小时还值钱。想清楚了再动手，人和AI都省力。