企业官网建设流程全解析

我和一个做独立开发的朋友聊天，他说了一句让我印象很深的话：“现在 AI 写代码的速度确实很吓人，但我反而找不着北了。”以前自己写代码，模块进行到哪一步、哪块逻辑还没闭合，心里都有数。现在把需求丢给 AI，它唰唰生成几百行，你对着屏幕只能反复问“这算完成了吗”。最要命的是如果同时推进三四个任务，AI 到底改到哪个文件、改到什么程度，完全是个黑盒。

后来我总结出一套办法：用问题+标签驱动开发，把 AI 当成一个正式的开发成员来管理。所有任务一律先建 Issue，用标签标明 AI 的介入程度和任务状态，再用看板把进度摊开。这套方法跑了快两个月，帮我从“凭感觉管理 AI”变成了“看板管理 AI”。这篇文章会完整拆解我的流程设计、标签体系、落地配置、可视化方案和踩坑记录。如果你也在用 AI 参与正经项目的开发，这套东西可以直接抄走，不需要额外买工具，用现有的代码托管平台就能实现。

1. 让 AI 参与开发后，最先崩塌的是“进度感”

这一章先别急着上方案，我们把问题看清楚。传统软件开发里有一套很成熟的“任务追踪”心智模型，人脑天然知道“这个模块写到一半了”“那个接口还差参数校验”。AI 加入之后，这套心智模型开始失灵，具体体现在三个断层上。

1.1 断层一：任务拆分的粒度对不上

人工开发的时候，我们习惯把“实现用户登录模块”拆成十几个小函数、小步骤，心里有一棵任务树。AI 没有这种任务树意识。你给它一个大需求，它倾向于一次性把整个模块“演”完——从建表语句写到前端回调，中间没有任何检查点，也没有“停下来让我确认一下”的机制。

于是产出物看起来完成度很高，但内部逻辑、异常处理、边界情况参差不齐。有的函数写得像教科书范例，有的函数是只覆盖主路径的“快乐路径版本”。问题不在于 AI 能力不够，而在于任务边界太宽，它的注意力被摊薄了。用 Issue 驱动之后，我会强制把大需求拆到“一个 Issue 只解决一个可验证问题”的粒度，比如“补齐登录接口的验证码过期判断”“把订单详情页的金额精度改为分存储”。粒度越小，AI 的产出越可控，进度越容易被追踪。

1.2 断层二：“完成”的定义变了

人工开发的“完成”有一个隐含标准：代码通过编译、测试通过、逻辑闭环。AI 写代码时不一样，它一次生成太多文件，经常处于“文件改了一大堆但整体不可运行”的中间态。以前我们用文件变化来判断进度，现在这招不管用了。

更麻烦的是，AI 自己会宣称“完成了”。你问它“这个功能做好了吗”，它通常回答“已经实现了”，但如果你真的把代码跑一遍，可能会发现它漏掉了异常分支，或者有个依赖没有引入。这不是 AI 在撒谎，而是它对“完成”的理解是语义层面的，不是编译和执行层面的。所以状态模型里必须增加一个特殊状态：AI 认为完成，但还没经过人工验证。我后面在生命周期小节会详细讲这条状态设计。

1.3 断层三：上下文无法自动延续

这是最隐蔽但也最致命的一层。大语言模型不会主动记忆上一次任务的结论。今天你和它确认过“依赖注入统一走构造函数”，明天让它改另一个模块，它可能又按旧习惯写出了服务定位器。如果这些决策只存在于你的脑海里，AI 协作的上下文就一直是断裂的。

Issue 恰好是最好的上下文载体。把决策、约束、验收标准写进 Issue 描述或评论区，下次开发时把 Issue 链接或描述片段给 AI，它就拿到了完整的“历史记忆”。这也是“问题驱动”在 AI 协作时代的新价值：它不只是管理任务，更是在替 AI 管理上下文。

2. 问题+标签驱动开发：把 AI 当成一个“不太自觉的开发成员”

问题驱动开发的思想并不新，很多团队都在用。新的地方在于标签体系：以前标签只用来打类型、打优先级，现在我把它扩展成一套“AI 协作协议”，让标签承载人机分工和进度状态。

2.1 信息模型的核心字段

我在项目里对每个 Issue 强制维护下面几个维度的信息：

这套模型的本质，是把“人写代码”和“AI 写代码”统一抽象成同一种工作单元：Issue。区别只体现在标签上。这样整个 DevOps 流程不需要重新发明轮子，只是在一个成熟的流程之上，给 AI 参与的任务打上特殊标记，就能获得可视化的能力。

2.2 介入模式标签：标注 AI 在这件事里的角色

四个介入模式标签我用了很久，已经形成了固定的使用习惯：

• ai-write：AI 独立完成代码初稿，人只做验收和必要修正。适合规格明确、改动范围封闭的小任务，比如“给某工具函数补充单元测试”“修复某个有明确复现路径的 Bug”。
• ai-pair：人机结对。AI 输出草案，人负责架构判断和关键逻辑整合。适合逻辑复杂、需要权衡取舍的任务，比如重构一个核心模块的数据流。
• ai-review：人写代码，AI 做代码评审，提出改进意见。这是很多团队忽略的场景，实际上最能体现 AI 的价值。它不会累，逻辑覆盖也全，用来做质量复盘非常高效。
• manual：完全不用 AI。比如一些因为合规要求或安全限制不能外发代码的模块，就明确打上这个标签，防止流程上出现误操作。

这套标签的设计意义在于“可视化分工”。看板上统计一下各标签的数量，就能立刻知道这个项目里 AI 到底分担了什么、人又守住了哪些阵地。有一个明显的好处是，当你发现某个模块的 ai-write 标签占比过高，而模块又是核心支付链路，你自然会意识到需要加大人工审查力度。

2.3 一个 Issue 的完整生命周期

我用一个真实场景走一遍完整的流程。假设任务是“修复订单金额精度问题”，它会经历下面这些阶段：

1. 我创建 Issue，打上bug、p1、ai-write，状态置为todo。
2. 我开始处理，把状态改为in-progress，把 Issue 描述和上下文文件清单交给 AI。
3. AI 生成代码并提交 PR，它需要把变更摘要、测试结果、遗留风险写进 PR 描述。此时我把状态改为ai-completed。注意，这一步非常关键：只要 AI 说“我做完了”，任务卡片绝不进入终态，只进入待人工验证队列。
4. 我或另一个开发者 review PR，该改的改完、该测的测完，状态改为in-review。
5. PR 合并，验收通过，状态改为done。
6. 如果测试阶段发现问题，我会把 Issue 重新打开，状态回到in-progress，并附上失败原因，让 AI 在既有上下文中修复。标签仍然保留原来的介入模式。

为什么要单设一个ai-completed状态而不是直接进done？因为 AI 的完成置信度不可靠。你直接在落盘代码面前验证过的东西才叫完成，AI 嘴里的完成只是一个“待验证的假设”。这个状态位看着简单，却让我少踩了很多坑。以前没有它的时候，我经常看着一张标着 done 的卡片，心里却在怀疑“它到底行不行”。

3. 落地配置：一套可以直接抄走的 Issue 模板与标签集

这一章给出可以直接照搬的配置。我假设你已经有一个代码仓库，用常见的问题追踪和看板功能，下面就是具体怎么搭。

3.1 Issue 模板：让需求一次说清楚

没有模板的 Issue 写出来千奇百怪，有的只有一句话“用户登录有问题”，这种需求丢给 AI 基本必翻车。我用的模板长这样：

## 背景 为什么需要做这个改动？当前代码有什么不便或缺陷？ ## 目标 这个 Issue 要达成的最终效果是什么？ ## 验收标准 1. 带格式的、可以逐条打勾的检查清单 2. 必须可测试，禁止使用“性能要好”这类模糊表述 ## 技术约束 - 必须遵守的现有架构约定 - 禁止引入的依赖或模式 ## 需要修改的文件 - 只列出允许 AI 碰触的路径，尽量收敛到最小范围 ## 参考实现 - 相关的代码片段、数据库表结构、接口文档链接 ## 禁止事项 - 不要跨路径修改其他模块 - 不要顺手重构无关代码

每条字段都有存在理由。“技术约束”和“参考实现”是给 AI 减少试探成本用的；“禁止事项”是为了约束 AI 喜欢扩散改动范围的习惯。我后面会在踩坑部分再次强调这条。“验收标准”则决定了一次性成功率——写得越可测，返工越少。

3.2 标签集定义与看板列映射

我维护的标签集合分四组，每组用独立的颜色体系区分。状态类标签用冷色系，介入模式标签用暖色系，这样看板上扫一眼颜色就能快速分类。

看板设置方面，把列和状态标签一一对应：Todo、In Progress、AI Completed、In Review、Done。卡片在列之间拖动时，顺手更新状态标签。介入模式标签不参与列映射，它们只负责给卡片“着色”。优先级标签用于排序筛选。

3.3 提交规范与低摩擦自动化

流程能否跑起来，取决于操作成本够不够低。如果每完成一个任务要在五个地方手动更新信息，那没人能坚持。我的做法是定三条硬规范：

1. 分支命名：从 Issue 直接创建分支，命名feat/123-short-name或fix/123-short-name。分支后面的短横线名字可以读就行，机器只认编号。
2. 提交信息：统一写成feat(#123): 完成自动续期逻辑。用#123引用 Issue 编号，代码托管平台会自动建立提交和 Issue 的关联。
3. PR 描述强制三段落：变更摘要、测试说明、遗留问题。我给仓库配置了 PR 模板，AI 提交的 PR 也必须按这个格式填，不填不合并。

自动化的重心放在“状态更新”上。我的经验是：状态标签的更新权保留给人，不交给 AI。AI 可以在提交信息里写“完成了某功能”，但最终把卡片从 ai-completed 拖到 done 这个动作，必须由人工完成。这样虽然多了一步，却保证了看板数据的可信度。它还带来一个副产品：每天花五分钟把这些动作处理完，其实就是在强迫自己做 review。

4. 进度可视化：看板、统计报表与 AI 周报

标题里说的“可视化你和 AI 的开发进度”，到这一章才真正落地。可视化不只是把看板调出来看看，而是要让数据告诉你下一步该干什么。

4.1 看板视图：卡片状态与颜色的双重编码

看板是最直接的进度可视化载体。我的看板布局非常简单：五列对应五个状态，卡片通过介入模式标签着色。每天打开看板，我只需要回答一个问题：“现在手上积压最多的是哪种卡片？”

如果暖粉色卡片（ai-write）大量堆在 AI Completed 列，说明瓶颈在我自己——AI 已经把活干完了，我却没去 review。如果暖绿色卡片（ai-pair）堆在 In Progress 列，说明有任务卡在结对协作中，可能是我的上下文给得不够，导致 AI 反复提问。如果冷灰色卡片（manual）积压很多，说明有大量被迫人工处理的杂务，这时候应该考虑是不是任务拆分方式有问题。

另一个好用的技巧是善用过滤器。我保存了两个常用视图：一个按介入模式筛选，只看“当前所有 AI 参与的任务”；另一个按里程碑筛选，绑定一个大版本需求下的全部 Issue。里程碑视图特别适合发布会前的冲刺阶段，能清晰看到哪些子任务还悬而未决。

4.2 数据统计：AI 完成度、人工介入度、返工率

看板适合日常监控，但想要更高层面的判断，需要定期拉数据做统计。我自己写了个小脚本，通过代码托管平台提供的 API 拉取 Issue 和关联的 PR，聚合成一张统计表：

import requests # 伪代码示意，实际使用时换成自己的 API 认证方式 issues = requests.get("https://api.example.com/repos/myproject/issues?state=all") for issue in issues: labels = {label["name"] for label in issue.labels} agent_mode = labels & {"ai-write", "ai-pair", "ai-review", "manual"} status = labels & {"todo", "in-progress", "ai-completed", "in-review", "done"} reopened_count = issue.reopens # 记录 reopen 次数 # 聚合：按 agent_mode 分组统计数量、平均存活天数

统计口径我固定看四个指标：

• 任务总量与关闭率：这个项目当前还剩多少存量。
• 按介入模式分布：AI 独立写的、人机结对的、全人工的各占多少。
• 平均处理周期：从 Issue 创建到 PR 合并的天数，按介入模式分组对比。
• 返工率：发生过 reopen 的任务数量除以总完成任务数。

这些数字最大的价值不是证明“AI 有多快”，而是用来发现问题。比如返工率偏高，往往不是 AI 写代码水平的问题，而是需求描述质量太差，验收标准写得太虚。这时候应该去改 Issue 模板，而不是责怪 AI。

4.3 AI 周报：让 AI 自己汇报这一周干了什么

可视化进度的最后一层，是让 AI 生成本周的工作总结。具体做法是：每周五下午，我收集本周关闭的任务列表、仍在进行中的任务列表、CI 构建状态这三块数据，拼成一段上下文，要求 AI 生成一份结构化周报。提示词大概长这样：

你是一个开发项目助手。以下是本周项目数据： - 已关闭的 Issue：[列表] - 进行中的 Issue：[列表] - 待 review 的 PR：[列表] - 失败的 CI 任务：[列表] 请输出一份简洁周报，包含： 1. 本周完成的事项 2. 这些事项里 AI 起草和人工主导的分别有哪些 3. 当前最阻碍进度的问题是什么 4. 给下周的建议，最多三条

生成出来的周报我会当作工作日志存档，也会把需要我处理的事项提炼成下周的待办卡片。我最看重的其实是第二点——它会逼着我把 AI 的贡献和人工的介入放在同一个尺子上衡量。当这份 AI 周报和看板事实放在一起比对时，如果 AI 在周报里写“本周完成了 7 个任务，其中 5 个由 AI 起草”，那就意味着我的流程里有两件事做得不错：任务拆得清楚，且每个任务确实被完整收口了。反过来，如果 AI 写周报时发现大量任务“悬在半空”，那本身就是流程失效的信号。

5. 跑了两个月的真实记录：实效、问题与调整

只讲方法论不讲实际效果是耍流氓。以下是我在一个内部工具项目上实际运行这套流程的观察。样本量不大，数据只能当参考，但过程里的问题和调整思路很有代表性。

5.1 实际效果：任务边界变可控了，速度是副产品

我在一个大约一万行代码的内部工具项目上，跑了两周严格采用问题+标签驱动的流程。期间一共创建 37 个 Issue，关闭 29 个，其中有 21 个任务由 AI 起草实现，13 个被返工过一次以上。单任务平均周期从原先无规则使用 AI 时的约 2.3 天，降到 1.1 天左右。

我注意到一个反直觉的现象：用这套流程后，写代码本身并没有变快多少，真正的收益在别处。第一是“变更边界可控”。以前 AI 改一个功能会顺手碰两个无关文件，现在每个 PR 基本上只碰 Issue 里列出的文件，review 成本和合并冲突都明显下降。第二是“上下文可复用”。每个 Issue 的标题、描述、评论构成了完整上下文链。同一个模块的第二个 Issue 处理时，我可以直接把上一个 Issue 的验收标准贴给 AI，它一次性走对的概率高很多。速度提升其实主要来自少返工，而不是生成更快。

5.2 踩过的坑：标签膨胀、状态幻觉与跨边界改动

有四个坑值得展开讲，它们几乎都会在第一次跑这套流程时遇到。

第一个坑是标签膨胀。刚开始我给标签体系增加了不少“灵感类”标签，比如“性能优化”“待升级”“技术债”。两周后标签总数翻了番，筛选时眼花缭乱。后来我做了强约束：一个 Issue 最多打三个标签，类型加优先级加介入模式，状态标签不进卡片列表而是跟随看板列。其他所有想法用 Issue 正文和评论表达，不进标签体系。标签是给人过滤用的，不是给人收藏用的。

第二个坑是 AI 自报状态不可信。我一度允许 AI 在提交信息里写“#123 done”来标完成，结果发现它会把只完成了一半的逻辑也标成 done。我并没有要 AI 虚报的意思，但它对“完成”的感知确实偏乐观。解决方案前面已经说过：状态标签的最终修改权只保留给人，AI 的表达止步于“我提交了什么”，卡片是否 close 由人确认。

第三个坑是 AI 跨 Issue 改动代码。任务写的是“只改 auth 模块”，它提交的 PR 里却带上了 util 工具函数的重构。这类问题反复出现后，我在 Issue 模板里加了一个必填的“禁止事项”字段，并且在喂给 AI 的上下文里显式声明路径边界。效果立竿见影，可以大幅减少“意外改动”。

第四个坑是验收标准写得太抽象。写“性能要好”等于没写，AI 生成的代码在语义上确实“性能好了”，实际压测却可能完全不合格。后来所有验收标准都改成可测表述，比如“并发 100 时 95% 请求响应时间在 200 毫秒内”“后端返回中新增字段 x 与前端展示一致”。能断言、能跑测试、能打勾，才算验收标准。

5.3 这套方法适合什么场景，不适合什么场景

跑了一段时间后，我也明确了这套流程的适用边界。它特别适合这几类任务：改造老模块，因为任务边界清晰；补齐单元测试和修复已复现的 Bug，因为验收目标明确；以及各类样板代码生成，因为规格基本上是固定的。

它不太适合纯探索性质的架构设计。这类任务的 Issue 本身就拆不细，验收标准写不出来，AI 也容易陷入茶壶里风暴的循环。我的建议是：探索性工作先放在独立实验仓库里做技术验证，验证成熟后再拆成普通 Issue 进入流程。硬要用标签去套它，只会既浪费力气又得不到有效进度反馈。

最后分享一个让我受益最大的小技巧。我给项目建了一个.ai-context/目录，把每天给 AI 的关键上下文、决策记录和验收标准沉淀成文件，命名与 Issue 编号对齐。时间久了，它就不只是流程工具，而是一个不断增值的“AI 协作经验库”。下次遇到相似任务，直接把对应文件打开，把上下文和验收标准复制给 AI，一次性成功率会明显提升。问题+标签驱动开发这件事，做深了之后你会发现，它管理的早已不只是进度，而是你和 AI 之间的默契程度。