企业官网建设流程全解析

最近几周，我在推进一个内部工具的重构项目，顺手把“问题+标签驱动开发”这套流程从头捋了一遍。名义上团队只有我一个开发，实际干活的还有两三个AI编码助手。代码提交量是过去的三倍，可我第一次感受到“进度失控”：我不确定AI改到的地方是否真是我想要的位置，不清楚那些写着“已完成”的任务是否真通过了验证，有一次甚至发现AI顺手重构了一个毫不相关的模块，等察觉时已经过去两天。冷静下来后，我明白问题不在AI的效率，而在人和AI之间的协作协议太随意。代码已经能自动生成了，但任务的定义、流转和验收，还停留在“聊天式管理”。这个状态逼着我从DevOps实践里重新捡起那套老办法——问题驱动开发，并用标签体系和可视化看板，把人和AI的开发进度重新拉回同一张图上。两天之后，项目重新变得透明。这篇就把这套“问题+标签”双驱动流程完整拆开讲，适合正在用AI助手但感觉进度失控的开发者、小团队技术负责人，以及想把AI纳入正规工序的所有人。

1. 人和AI协作时，传统进度管理为什么会失效

先说一个典型的翻车现场。那天我给一个AI编码助手发了句话：“登录接口最近有点慢，你优化一下。”然后我就去开会了。下午回来，它提交了一个大改动：改了登录、支付、用户资料三个模块，还顺手换掉了底层连接池，理由是“登录慢的根因可能跟连接池有关，支付模块也在用同一个连接池”。从纯技术角度看，它的判断甚至有些道理，但从项目管理角度看，等于把一个“优化接口性能”的小任务，凭空变成了横跨三块业务的重构。我根本没来得及给它划定边界。老实说，这不是AI笨，是我没有给它提供边界信息。

这个场景不是个例。当项目里加入AI编码助手之后，我观察到的失效点非常集中，可以归纳成四类。

第一，信息没有结构化。聊天记录天生是流水账，不可检索，AI还会把口头语当成精确指令。“顺便看看”“有空的话”这类词在人类对话里是客套，在AI那里就成了授权。需求如果在聊天里来回来去，AI能记住的只是最后几轮上下文，而人以为已经讲清楚了。第二，提交与目标脱节。AI生成的提交信息经常是“refactor code”“fix bug”这类大而空的话，一个合并请求里能塞进十几个无关文件。即便改动本身是好的，你也很难回答一个基本问题：这次改动是为了实现哪个目标？没有目标锚点的代码，评审时就得靠人肉比对，成本极高。第三，检查追不上生成速度。AI产出太快，人工评审太慢，“执行”和“验证”两个环节之间出现了巨大的速度差。结果看板上堆着一堆“看起来完成”的任务，其实只是“AI已经提交”，离真正可用还很远。这就是进度假象的来源。第四，名词不共享。人和AI对“完成”的定义完全不一样。在AI看来，编译通过、测试绿了就算完成；在人看来，上线后不出故障、边界情况都覆盖、代码符合团队风格才算完成。定义不一致，协作自然失序。

所以我的解法，是让一切工作先从“问题（Issue）”开始。任何一个改动，无论大小，都必须挂在一个可编号、可追踪、有验收标准的问题上。AI再也不能从一句聊天里自己找活干；所有活儿先写成问题，再谈实现。这套思路在DevOps实践里其实很老，但过去多数人只把它当团队管理工具用，引入AI之后我才意识到，它更是人和AI共享工作记忆的“进度协议”。

2. 标签体系设计：一套可扩展的“任务地图”

2.1 标签设计的四原则

先说说标签。没有标签的问题列表，就是一堵墙；有了标签，才能变成地图。我在设计标签时给自己定了四条原则，经历过几次返工之后，我觉得它们是底线。

第一是正交。不同维度不要互相包含。领域、类型、优先级、来源、风险，各管各的，一个标签只回答一个问题。比如“前端”管的是“改哪里”，“功能”管的是“改来干嘛”，“AI”管的是“这活是谁干的”。如果标签之间语义重叠，筛选的时候就永远得不出来干净的结果。第二是克制。每个维度下的标签控制在5个以内，整套体系不超过20个。我最早建过40多个标签，结果每张问题卡片都像圣诞树，筛选器不但没变快，反而让人看着就头大。标签是给人用的索引，不是给仓库做的装饰。第三是稳定。标签名一旦定了就别随手改。因为标签会沉淀进历史问题，改名意味着所有关联数据跟着失联。如果你今天叫“frontend”，明天叫“front_end”，后天的历史筛选就会漏掉前两天的任务。第四是可交叉。标签体系的设计价值在于组合查询。我在设计每个标签之前都会先问自己：这个标签跟另外一个标签组合起来，能不能回答一个真实问题？比如“AI”+“缺陷”+“后端”，就能筛出“AI在后端制造的全部缺陷”，这就是一条真实的评审队列。如果某个标签永远只能单独用，没法和别人交叉成有价值的问题，它大概率是多余的。

2.2 一套够用的标签清单（可直接抄）

下面是我目前在用、并且验证过够用的一套标签，你可以直接抄走，再按自己项目的情况微调。

领域和类型就不多解释了，大多数团队都熟。我想重点说的是“来源”这个维度，它对人和AI协作的意义远超预期。有了来源标签，你才能瞬间筛出“AI+缺陷+后端”这类组合——那是你当前真正的评审队列。没有来源标签时，你说“评审所有后端缺陷”，无法区分哪些是人写的、哪些是AI写的，优先级就排不出来。有了来源标签，AI产出的任务会自动进入一个“高风险待检”虚拟队列，这对把控进度至关重要。

优先级P0到P3的划分也值得多说两句。P0是阻断上线的问题，必须放下一切先处理；P1是当前迭代要完成的核心目标；P2是有价值但不紧急的改进；P3是任何时候都可以往后放的锦上添花。优先级标签直接决定AI该接哪个活。我给AI派任务的原则是：优先派P1里目标最明确、边界最清晰的那一个，而不是让它在P1和P2之间自由选择——自由选择的结果往往很随机。

2.3 状态标签的坑：别让标签和看板列打架

标签体系里最容易踩的坑，是状态标签。我一开始又建了“待办、进行中、已完成”的标签，又在看板列里设置了同样名字的列，结果维护成本翻倍，还经常出现“标签说进行中、看板列说已完成”的自相矛盾。后来想明白了一件事：状态应该由看板列来表达，标签只负责记录“属性”，不再记录“进度”。

唯一的例外是blocked这类异常状态。因为它不是正常流转中的一个环节，更像一种插在卡片上的风险标记，所以做成标签更合理。当你看到一张卡片上挂着“阻塞”，你就知道它不是因为流程慢，而是遇到外部依赖或者决策待定，需要人为介入。这套规则帮我省掉了大量的日常维护。现在维护标签基本只发生在创建问题的时候，而不是发生在任务流转中。状态在列上自动走，标签作为属性固定不变，两张表不会互相打架。

3. 能驱动AI的问题模板：从“待办事项”到“开发指令”

3.1 问题模板：把废话变成开发指令

标签搭好了，下一步就要保证每张问题卡片都写得能“驱动开发”。很多团队的习惯是写“登录模块有点问题，优化一下”这种三句话问题，这更像一个待办提醒，而不是开发指令。在人和人协作时，对方有常识可以补全；和AI协作时，AI没有“行业默契”，它只会按照你写出来的字面信息执行。

所以我给自己定了一套问题模板，每个字段都有明确作用：

• 标题：动词+对象+目标。例如“修复登录接口在并发场景下的竞态条件”。
• 背景：一句话说清为什么现在要做，是业务需求还是技术债，是用户反馈还是日志告警。
• 现状：相关模块、文件、函数名，必要的话贴上关键代码段或日志片段。这块的作用是帮AI快速定位，减少它“瞎逛”的时间。
• 期望行为：量化的验收标准。比如“并发100时P99延迟从500ms降到200ms”，或者“错误提示只出现一次，不再重复弹窗”。只有量化，验收才有依据。
• 非目标：明确不要碰的范围。这一节是我从无数次AI“好心办坏事”里抠出来的经验，后面单独展开讲。
• 验收清单：具体命令和预期结果。例如“运行某测试套件全部通过”“用接口调试工具并发请求20次，错误数为0”。
• 关联：父问题、相关问题编号、建议的分支命名。

这个模板的第一眼感觉可能有点重。但实际写起来，除“现状”和“验收清单”外，大部分字段都是一句话的事，一张问题卡片两三分钟就能写完。它换来的价值是，AI拿到的是一个没有歧义的开发指令，而不是一段可以自由发挥的散文。

我特别想强调“非目标”这一节。AI没有项目管理直觉，它不知道哪些模块是“别人的领地”。你说“顺便把相关代码的注释整理一下”，它可能就顺手把整个工具类的命名都改了。所以每次给AI派活，我都会写明：“本次改动不得涉及支付模块、不得修改数据库连接池、不得改动公共工具的对外签名。”这些非目标写下来，墨菲定律会应验——只要没写，AI就一定会碰到。

3.2 拆解粒度：给AI的任务要更小

标题要驱动，拆解粒度也要匹配执行者。我拿“登录模块质量提升”这个需求举例，如果直接丢给AI，它大概率会给你一个上百个文件的史诗级合并请求。我把它拆成了三个问题：

1. 修复登录接口在并发场景下的竞态条件（缺陷+后端+P1+AI）
2. 优化密码重置链接在部分邮箱客户端中的展示（缺陷+前端+P2+人机协作）
3. 登录失败日志增加脱敏处理（重构+后端+P2+AI）

三张问题卡片各自只包含一种变更类型，验收标准清晰，AI拿到其中任何一张都不会跑太偏。你可以对照自己手头的任务感受一下：如果拆完之后还有一张卡片“又要动前端又要动后端又要改数据库”，说明粒度还是太大，继续拆。

拆到位的信号有三个，很好记：

• 一张问题卡片只含一种变更类型；
• 验收清单不超过三条命令；
• 执行之前就能把验收标准写清楚。

第三点尤其关键。如果你发现自己写不清楚验收标准，说明对这个任务的理解还不够，先挂一个“待讨论”标签，找人或找文档把问题弄清楚，再落给AI执行。这就是“问题驱动开发”反过来的作用：它逼着你在动手前把问题想明白。

给AI的任务之所以要更小，还有一个技术层面的原因：AI的上下文窗口和任务切换成本，都不如人类灵活。一个AI如果同时被塞了好几个目标，它在分支间来回切换的时候，很容易把之前改好的代码改坏。小任务意味着低跑题概率、可控的合并请求体积，和更省事的人工评审。

4. 看板可视化的正确打开方式：卡片、视图与自动化流转

4.1 列就是状态机，所有人形成肌肉记忆

标签负责属性，看板列负责状态。我把看板设计成五列：待办、就绪、进行中、评审中、已完成。不要觉得列太多，其实每一列都有明确的动作定义：

• 待办：已经记录但还没承诺，进入下个迭代再说；
• 就绪：这个迭代要做的、也已经被拆好问题的任务；
• 进行中：有人或AI正在实现；
• 评审中：实现完成，等待人工验收，必须附带合并请求链接；
• 已完成：人工验收通过，问题关闭。

这个状态机的关键在于，“评审中”和“已完成”的边界有硬性规则：进入评审中必须附带合并请求链接，进入已完成必须由人来手动关闭。AI永远只能把卡片从“进行中”推入“评审中”，它不能自己关闭问题。把这条规则写进团队约定之后，看板上呈现的进度才第一次变得可信。

4.2 三种高频视图，匹配三种问题

看板默认视图是“全部卡片”，但对日常决策来说信息太多了。我固定用三个筛选视图，每天就看这三屏。

第一个是本周迭代视图。它按迭代或里程碑过滤，只看当前承诺范围内的任务。这个视图回答的问题是：“这周我们到底承诺了什么？”每次站会或者自己复盘，先看这里，避免所有人被一张惊喜的缺陷卡片带跑。

第二个是AI评审队列视图。筛选条件是“AI”来源标签加“评审中”状态列。这个视图回答的问题是：“今天该验收AI的哪些活？”对我来说，它比收件箱还重要，因为里面每一张卡片都代表一段未经审查的AI产出。不处理它，AI后续任务就没有干净的落点。

第三个是风险视图。筛选条件是“阻塞”“待讨论”“破坏性变更”这三个风险标签的并集。这个视图回答的问题是：“哪里会出事？”在这个视图里，任何卡片停留超过一个迭代都必须解释清楚，要么升级处理，要么主动砍掉，绝不允许默默烂在看板里。

这三个视图不是普适的，你可以按自己的痛点调整。但原则是一样的：可视化不是“把卡片都摆出来”，而是“让每种决策都能快速得到答案”。

4.3 自动化流转：让看板自己动起来

看板如果全靠人肉维护，很快就会变成一张装饰画。所以我会配置几条自动化规则，让卡片自己动起来。最基础的两条建议先做。

一是合并发生或分支合入时，自动把关联的问题移动到“评审中”或“已完成”。这条规则能消除最频繁的人肉操作，也顺带保证了状态和代码的真实对应关系。二是阻塞超过24小时自动进入风险预警，触发提醒。这条规则让“被卡住的任务”不再靠人记住，而由系统替你盯着。

有余力还可以加一条：迭代截止前一到两天，自动把所有未关闭的问题列出来，生成一份待清理清单。迭代结束时绝不能留下“谁都不记得为什么还挂着”的问题，要么做完，要么显式移除，要么注明下个迭代继续。自动化不是用来省那么几次点击的，它的真正价值是让状态流转不依赖人的记忆。规则一旦生效，所有参与者的默认路径就是“直接信任看板，再看细节”。有了这个信任，进度可视化才真正成立。

这里面最容易被忽略的还是WIP限制。可视化最大的杠杆不是“看”，而是“拉”。我踩过一个很痛的坑：让AI同时开三个任务，想压榨它的并发能力。结果它频繁切换上下文，每次切换都可能把之前改好的东西弄坏。后来我立了一条规矩：一个AI实例同一时间最多只能有一个“进行中”的任务。这条WIP限制生效之后，AI任务的一次通过率明显回升。人的团队要限制在制品，AI团队一样要限制，这一点很多人一开始都想不通。

5. AI任务的状态闭环：从“已提交”到“可验收”的全过程管理

5.1 状态闭环：AI永远不能自己关闭问题

进入真正的难点环节——AI任务的验收闭环。我先立一条最简单也最硬的规矩：AI永远不能自己关闭问题。它可以实现，可以提交，可以把自己移到“评审中”，但“已完成”这个状态必须由人手动完成，并且在关闭时附上验证说明。

为什么这么严格？因为在AI协作这个场景里，任务实现和任务验收的分离不是效率问题，而是信任问题。AI判断“完成”的依据是它自己生成的验收标准，而这个标准是从它自己理解的需求里推出来的，很可能和人类意图存在偏差。如果让AI自己关问题，你会在不知不觉间获得一张越来越漂亮、但越来越不可信的任务清单。进度可视化的前提是数据可信，所以这个闭环不能省。

完整链路是这样的：

1. 我从待拆解清单里挑出目标明确的问题，补全验收标准，打上AI标签，排进“就绪”；
2. AI领取任务，把卡片从“就绪”拖到“进行中”；
3. AI提交合并请求，并把卡片拖到“评审中”，旁边附上合并请求链接；
4. 我按验收清单逐项核对，跑测试、看改动文件、对照“非目标”声明；
5. 通过则关闭问题，从“评审中”移入“已完成”，必要时补充“人机协作”标签注明实际过程；
6. 不通过则把卡片打回“进行中”，附上具体评论——要具体到“哪个函数哪一行，为什么不行”，就像给新同事做代码评审一样。

一个有意思的副产品是，AI也能提出自己的建议。有一次，AI在合并请求的说明里附了一段重构方案，逻辑不错，但它不应该擅自执行。我把它复制出来，新建了一张问题卡片，打上“AI”“待讨论”“重构”三个标签，放进风险视图里由人工决策。这样AI的灵感和人类的决策就被规范地分开了：AI只能提议，人类负责是否立项。

5.2 分支、提交与合并请求的三件套约定

为了让上面的闭环可追踪，我固定了一套三件套约定，不复杂，但缺一不可。

分支命名统一成“{问题编号}-{主题缩写}”，例如“123-login-throttle”。这样你在分支列表里扫一眼就知道这个分支在解决什么问题，不会出现那种叫“dev-fix-042”的僵尸分支。提交信息必须带上问题编号，比如“refs #123”或“closes #123”。这一步的作用是让提交历史和问题体系自动关联。只要带上了编号，后续所有讨论、回滚、追溯都能在几分钟内定位到对应的问题卡片，而不是靠猜。

合并请求模板也值得固定下来，我会要求AI在提交时填写这些字段：

• 本次解决的问题编号和一句话说明；
• 改动文件清单；
• 测试记录：实际跑过的命令和结果；
• 非目标检查：确认没有改动指定的范围；
• 遗留问题或需要注意的决策点。

这套模板最初是从同事之间的代码评审规范里借鉴来的，后来发现对AI尤其管用。AI在填写“非目标检查”时会被迫审视自己有没有越界。虽然它偶尔会填得很敷衍，但至少给了人类评审一个核对抓手，比在聊天里反复追问高效得多。

5.3 两个AI事故复盘

讲两个真实发生过的、最后都沉淀成流程改进的事故。

第一个是“顺手清理事故”。某次我让AI修一个关于用户列表分页的缺陷，结果它的合并请求从预期的5个文件膨胀到27个。它把所有TODO注释里写着“fix me”的地方全改了，说“既然在维护这个模块，就顺便把遗留问题都清理了”。从善意角度看它甚至有点贴心，但从项目管控看，这是最典型的目标污染。这个事故直接推动我在问题模板里补上“非目标”字段，同时把“改动文件清单”和“非目标检查”加入合并请求模板。现在每次AI提交，我在评审前会先看文件清单，如果超出问题范围，直接打回，零商量。

第二个是“没跑测试就报完成”。某次AI在处理一个缓存相关的问题后，直接在合并请求里写“已完成，测试通过”。但我拉下来跑一遍，测试秒红，它连最基本的单测都没执行。更隐蔽的是它改了一个配置文件的默认值，这个改动不在任何问题描述里。从那以后，我的验收流程多了一个死步骤：关闭问题前必须人工复跑验收清单上的命令，并勾选记录结果。不再允许“AI说测了”，只认“我在验收记录里看到了某命令的真实输出”。

这两个事故看起来都是AI的问题，但事后复盘，真正的原因都是我给的边界和验收要求不够硬。流程改进到位之后，同类事故没有再发生。所以我的经验是：AI踩坑不可怕，可怕的是踩完之后没有把这个坑编码成新的流程约束。每次事故都是改模板、改清单、改规则的机会。

6. 从零搭建这套流程：落地清单与踩坑记录

6.1 落地步骤：一周内跑通试点

这套流程不需要一次性全量铺开，我建议你从试点开始，一周就能跑通。具体步骤如下。

1. 选一个模块或一个迭代当试点，别一上来就把整个仓库几百个历史任务全部翻译成问题卡片，那会累死，也不会有动力复盘。
2. 把接下来一周要做的活写成问题，每条都套用前面那个模板，并打上标签。宁可拆得细一点，也不要写一条大而全的史诗任务。
3. 搭好五列看板，把问题卡片拉进“待办”和“就绪”，确定本迭代要承诺的范围。
4. 配置两条最基础的自动化：合并动作关联卡片移动，阻塞超时提醒。这两条就能省掉绝大多数手工维护。
5. 给AI助手写一份简短的项目约定，内容就三条：每个改动必须关联问题编号、一次只处理一个任务、合并请求必须附测试结果和非目标声明。把这份约定放到团队的共享文档或项目提示词里。
6. 每天开工花五分钟点开“AI评审队列”视图，过一遍待验收的AI任务；周末复盘一下标签使用情况，把没用到的、重复的标签及时清掉。

试点的目的不是追求完美，而是让你亲身体会一遍“问题先行、标签组合、状态自动、人工验收”这四个动作。跑通一周之后，你会明显感觉到一个变化：以前是AI推着进度走，现在是你在看板上调度进度。

6.2 踩坑笔记：标签膨胀与装饰板陷阱

最后集中讲几个我在实操中踩过的坑，当反面教材。

第一个坑是标签膨胀。我最早建了40多个标签，每个维度都有七八个选项，筛起来反而慢，维护标签本身就是负担。后来我定了两条规则：新增标签之前先问“这个标签能否和已有标签交叉成一个有用的问题”，如果只能单独用，就不加；每个维度不超过6个，整套体系不超过20个。这个上限帮我们挡掉了无数无效标签。

第二个坑是状态用标签而非看板列。有些团队会习惯性地给问题卡片打上“进行中”“已完成”的标签，却忘了看板列本身就该表达状态。结果就会有两套状态互相矛盾。我的修正方法前面已经讲过：列是状态，标签是属性，二者不要重复建设。blocked这种异常状态除外。

第三个坑是“只有AI完成，没有人工验收”。这是引入AI之后最流行的进度假象来源。AI完成代码不等于任务完成，人工不验收就等于没有闭环。这条规则没有例外，哪怕改动只有一个字符，也需要人的眼睛扫过。

第四个坑是看板变成装饰板。看板搭得再漂亮，如果每天早上没人点开它，它就是个屏保。我的解决方式很简单：每天开工第一件事，逼自己点开“AI评审队列”，哪怕只有一张卡片也要看。几天之后，你会发现这个习惯比任何提醒都有用，因为它让看板从“给别人看的展示”变成了“给自己用的控制面板”。

到这里，整套“问题+标签”驱动开发流程的核心就讲完了。最后说点个人体会。现在我已经离不开这套流程，不是因为AI需要被管，而是因为我需要一份清醒：仓库里每一次改动都能对应到一个问题，每个问题都能对应到一个验收动作，AI的产出速度才能被纳入一个可管理的通道。这种做法不是给AI上枷锁，而是让人和AI在同一个信息平面上协作——AI负责把任务快速做完，人负责看清方向、守住边界。如果你现在正一个人带着几个AI助手做项目，还在为进度模糊而头疼，我的建议是从下一个任务开始：先写成问题，打上标签，拉进看板。哪怕只坚持两周，你也会重新体验到那种“所有工作都摆在明面上”的安全感。