企业官网建设流程全解析

先说一个我自己观察到的现象：过去半年，几乎所有团队都在“用 AI”，但绝大多数只是把 AI 当成了高级自动补全——写完代码让 AI 帮忙 review 一下、报错了问一句、要写个正则让它生成一段。这不是 AI Native，这只是给老流程套了一层 AI 皮肤。

真正的 AI Native 团队，是把 AI 当作研发流程里的“原生公民”：需求、设计、编码、测试、发布、复盘，每一个环节都有 AI 参与决策和执行，人的角色从“亲手写每一行”变成“定义方向、验收结果、处理异常”。这篇手册就是我结合自己带团队落地的经验，从概念拆解、组织调整、工具链选型、全流程改造、可信度保障、常见坑六个方面完整拆一遍，给准备转型或者正在转型路上的团队一份能直接抄的作业。

1. 别把“用AI写代码”当成AI Native——先想清楚革谁的命

1.1 四个层级：你团队现在站在哪一级

我习惯把一个团队对 AI 的使用深度分成四个层级，方便做现状评估和转型目标设定：

很多团队觉得自己已经很“AI Native”了，其实只是在 L1 和 L2 之间徘徊。判断标准很简单：如果“需求文档 -> 技术方案 -> 代码实现 -> 测试用例”这条链路里，人和 AI 还需要频繁来回传话，每一步都要人手动把上下文喂给 AI，那它就是 L1 的增强版，谈不上范式改变。

L3 最特别的地方在于，人的工作对象从“代码”变成了“规格”和“边界条件”。我举个例子：传统开发里，一个后端工程师写支付回调接口，要自己写签名校验、幂等表、异常处理；在 L3 团队，工程师只描述接口行为、约束和兼容性要求，AI 直接生成完整实现和配套测试，工程师做的是代码评审和安全验证。这不是天方夜谭，现有模型配合良好上下文已经能完成这类任务。

1.2 AI Native 团队与“AI辅助开发”的本质差异

我见过很多团队花大价钱买了最新的模型，但效率没起来，核心原因是他们一直在“AI 辅助”的模式里打转。AI 辅助模式和 AI Native 模式有三个本质差异，想清楚这三个差异，才能明白转型的真正含义。

第一，上下文流动方向不同。辅助模式是“人找上下文喂给 AI”，Native 模式是“上下文围绕任务自动装配”。前者把 AI 当搜索引擎，后者把 AI 当作一个有完整背景资料的协作者。我踩过的坑是：曾经让团队用五个不同的 AI 工具分别处理写代码、找 bug、写测试、查文档、做 code review，结果同一个需求在五个工具之间来回拷贝粘贴上下文，时间全浪费在“喂养 AI”上了。

第二，任务颗粒度不同。辅助模式里 AI 做的是“语句级”任务，比如生成一个函数、解释一段报错；Native 模式里 AI 做的是“模块级”任务，比如“基于这份接口文档，实现完整的用户模块，包含 CRUD、权限校验、单元测试和 OpenAPI 注释”。颗粒度变大之后，人的价值才真正从“写代码”转移到“定义问题”上。

第三，质量保障机制不同。AI 辅助模式里，代码质量靠写代码的人兜底；AI Native 模式里，必须建立一套围绕 AI 产出的验证与评测体系，否则团队就是在给生产环境埋雷。后面第 5 章我会专门讲怎么做质量兜底。

这里我想给一个生活化类比：AI 辅助相当于你雇了一个很聪明但没工牌的实习生，你做一步教一步；AI Native 相当于这个实习生熟悉你们团队的规范、代码库、历史决策，你只需要把一个模块的目标说清楚，它交付后你验收。显然后者的管理成本和组织要求更高，但产出的杠杆也大得多。

2. 组织与角色：AI Native落地第一刀砍向哪里

2.1 新增三个关键角色，而不是裁掉人

很多管理者一听“AI 能写代码”就想缩减编制，这是最危险的决策。我见过的情况恰恰相反：AI Native 团队初期根本人手不够，因为新增了三种过去没有的职能，缺一个都会在落地中段卡壳。

第一个角色是 AI 平台/基础设施工程师。这个人负责模型接入、Prompt 模板治理、上下文工程、工具链路搭建和成本控制。他不是传统意义上的后端工程师，而是懂得如何让“模型能力”在工程体系里稳定输出的人。没有这个人，团队往往停在“每个工程师各玩各的 AI”的状态，工具碎成一地，上下文断层，效率不升反降。

第二个角色是 Agent 编排与治理负责人。到 L2/L3 阶段，AI 不是单个帮你补全代码的程序，而是由多个 Agent 协作完成复杂任务：一个 Agent 读需求，一个 Agent 写代码，一个 Agent 跑测试，一个 Agent 做评审。这些 Agent 之间怎么分工、怎么传递结果、出问题怎么回退，需要专门的人来设计。

第三个角色是 AI 质量与评测工程师。AI 生成代码的最大问题不是“能不能跑”，而是“看起来能跑但不一定对”。这个人负责建立评测集、追踪 AI 产出的正确率、设计回归验证体系，让团队对 AI 的能力边界有客观认知，而不是靠感觉。

小团队不用急着招三个人，完全可以由现有成员兼任，但职责必须明确到人头。我见过比较顺的配置是：10 人左右的研发团队，一名资深后端兼职做 AI 设施，一位测试负责人兼职做质量评测，技术 TL 自己兼 Agent 编排。

2.2 能力模型重构：工程师要补哪些新基本功

角色只是骨架，真正决定转型成败的是团队每个人的能力结构。AI Native 团队里，工程师的核心能力不再是“背诵 API”和“手写复杂算法”，而是被一组新能力取代：

• 规格描述能力：能把模糊的业务需求拆解成机器可执行的输入。这比写代码更难，因为“把话说清楚”需要更高层次的抽象能力。
• 上下文管理能力：知道给 AI 喂什么、喂多少、什么顺序喂。同样的模型，有人用它 5 分钟搞定一个模块，有人磨了半小时还在跟它纠缠同一个报错，差距几乎全在上下文组织上。
• 结果批判性审查能力：对 AI 的产出保持“专业怀疑”。不是看到测试通过就放心，而是要追问边界条件、异常路径、安全风险这些 AI 容易遗漏的地方。
• 架构决策能力：AI 可以写代码，但“这个模块该不该拆微服务、数据一致性用什么方案、接口要不要做幂等”这类决策仍然必须由人来做。这种能力不仅没有贬值，反而更加值钱。

我在实际带团队过程中发现一个规律：给同样的 AI 工具，资深工程师的产出质量比初级工程师高出一大截，不是因为前者代码写得快，而是因为前者更擅长“定义问题”。所以 AI Native 转型对团队的要求不是降低，而是提高了——只是提高的方向从“实现”变成了“定义与判断”。

3. 基础设施选型：AI Native 团队的技术地基怎么打

3.1 模型接入层：自建网关还是直接用平台

AI Native 团队的地基是模型接入层，这一步选型直接决定了后面所有工作的稳定性。当前实践里主流有三种方式，我对它们的评价是：

我的建议是分两步走：先在验证期用公有云 API 快速跑通业务链路，同时开始搭建一层轻量网关。网关不必一开始就做得很重，能把三件事管住就行：第一，统一 API Key 和权限，避免工程师各自注册账号、月底账单爆炸；第二，记录每一次调用的成本、耗时、模型版本；第三，支持多模型路由，比如重逻辑用强模型，简单生成用便宜模型，这个在后面讲成本控制时会再展开。

网关这个事，我吃过亏。最早我们没做网关，团队五个人各自开通了账号，一个月下来费用高得离谱，而且出了问题根本查不到是哪个模型、哪个请求引起的。后面上了网关，所有调用走统一入口，成本立刻降了四成，因为很多简单任务根本不需要用旗舰模型。

3.2 三个必须提前定下的工程规范

模型接入搞定之后，还有三个工程规范必须在全团队铺开之前就定下来，否则后面返工成本极高。

第一个规范是模型版本锁定。AI 模型不是越新越好，对工程团队来说，稳定比先进更重要。上线前把模型版本固定住，比如用某一天的快照版本，这样同一个 Prompt 在两周前和两周后输出不会有太大漂移。模型升级必须走灰度发布流程，先在非核心场景跑几天，确认回归指标没恶化再全量切。

第二个规范是输出格式约定。任何时候让 AI 产出结构化内容，都要在 Prompt 里规定好输出格式。我通常强制要求 JSON 输出，并且给出明确的字段说明和示例。这一步看起来笨，实际上是在给下游自动化铺路：AI 写的代码本身也要有固定结构，比如新建文件必须包含文件头注释、异常处理和集成测试，否则评审和后续维护都是灾难。

第三个规范是敏感信息过滤。所有发给外部模型的 Prompt 必须经过脱敏处理，生产环境的数据、未公开的代码逻辑、客户的个人信息，一律不允许出现在请求里。这个不能靠自觉，要在网关层做关键字和正则匹配的拦截。我在内部推了一个简单脚本，提交代码前自动扫描有没有把密钥或连接串硬编码进请求里，效果很好。

4. 全流程改造：从需求到发布，AI在每个环节干什么

4.1 需求环节：让 AI 先读文档，再让产品读 AI

AI Native 流程不是从写代码那一刻开始的，而是从需求阶段就变了。传统流程是产品经理写 PRD，工程师读 PRD 然后凭经验理解，理解偏了就是返工。在 AI Native 流程里，我会让 AI 先读一遍 PRD，输出一份“需求理解确认单”，内容包括功能列表、用户故事、验收标准、潜在风险点和不明确项。

用法很简单：把 PRD 文本丢给模型，用固定模板让它输出结构化结果。下面是我在团队里一直在用的 Prompt 骨架：

请阅读以下产品需求文档，并输出： 1. 核心功能清单（每项一句话描述） 2. 用户故事（格式：作为[角色]，我想要[功能]，以便[价值]） 3. 验收标准（可测试、可量化） 4. 风险点与不明确项（列出需要产品经理澄清的问题） 5. 技术影响面（涉及哪些现有模块/服务） 输出格式：Markdown 列表，不额外解释。

这个流程的关键动作是“让产品经理读 AI 的产出，而不是让自己读 PRD”。PRD 往往冗长且信息密度低，AI 把它压缩成结构化的验收清单之后，产品经理能快速发现自己写的需求有哪些地方存在歧义。这个环节把绝大多数需求理解偏差消灭在编码之前，返工率明显下降。

4.2 编码环节：AI 负责生成，人负责验收

编码环节是大家最熟悉的，但 AI Native 的做法和“用 Copilot 补全代码”完全不同。我们现在的标准流程是“Agent 生成 + 三重验收”：

工程师先写技术方案，把模块拆成任务列表，每个任务包含输入、输出、约束条件、参考文档，然后交给 Agent 生成实现。Agent 产出代码的同时，必须一并产出一批配套内容：单元测试、集成测试用例、变更影响说明和潜在风险清单。这一步是硬性要求，只给代码不给测试的 Agent 输出一律打回。

人负责的验收分三层：第一层是架构符合性检查，主要看有没有引入不合适的依赖、有没有偏离既定的分层规范；第二层是边界条件审查，重点关注 AI 容易忽略的异常路径，比如超时、重试、并发、数据一致性；第三层是安全审查，看有没有注入风险、敏感信息泄露、越权访问等问题。

我见过最典型的问题模式：AI 生成的代码主流程完美跑通，但异常处理全是糊弄的。比如文件上传模块，正常上传没问题，一旦磁盘满了或者文件名非法，直接裸抛异常。所以我把“异常路径完整性”列为人验收 AI 代码的第一要素，宁可主流程代码丑一点，也要让异常处理经得起拷问。

4.3 测试与发布：自动化的自动化

到了测试环节，AI Native 的优势开始叠加放大。传统自动化测试是人写一堆用例然后跑 CI，AI Native 里测试用例本身就由 AI 生成，而且是由需求文档直接生成，形成一个完整的对应关系。

我们实践下来最有价值的是三种 AI 测试能力：一是“基于验收标准的用例自动生成”，需求里有几条验收标准，AI 就生成对应几条测试，并在测试名称里标注对应的标准编号，这样测试和需求之间形成可追溯链；二是“边界和异常自动补充”，AI 会根据代码实现自动补一批程序员容易漏掉的边界用例，比如空值、超大值、字符串超长、并发冲突；三是“契约测试自动生成”，微服务场景下，AI 根据接口文档生成调用方和被调用方双方的契约测试，联调问题大幅减少。

发布环节同样有 AI 的活。我们的 CI 流程里加了两个 AI 相关步骤：第一个是 AI 自动生成变更说明，根据代码 diff 和关联需求生成发布摘要，并标注可能影响的功能模块；第二个是 AI 告警预分析，根据发布内容自动匹配历史相似故障，提醒发布负责人关注哪些监控指标。这些能力单看都不算酷，但组合起来确实把发布的人为心智负担降了一大截。

5. 代码可信度问题：怎么防止AI一本正经地胡说八道

5.1 AI 代码的三道人工闸门

AI 生成代码最可怕的问题不是“不工作”，而是“看起来能工作但结果是错的”。我遇到过 AI 写的日期处理函数，单元测试全过，结果夏令时切换那天时间全部错位。这种问题靠测试套件发现不了，必须靠机制兜底。我在团队里设置了“三道闸门”，任何 AI 生成的代码都必须依次通过。

第一道闸门是架构闸门：AI 生成的代码不允许直接进入主干分支，必须先过架构评审，确认方案和现有架构没有冲突。这里的要点是“AI 可以做实现方案，但不可以做架构决策”。简单说，如果 AI 想引入一个新的缓存组件或者消息队列，它应该被驳回，由工程师决定整体架构走向。

第二道闸门是人工代码评审闸门：虽然 AI 生成代码的质量在快速提升，但让它自己审自己会陷入“舒适区”。我们要求每次 AI 生成的 PR 必须由至少一名真人评审，且评审者不参与该模块的 AI Prompt 编写，保证“制造者”和“检验者”分离。评审清单固定在三个维度：异常路径、安全漏洞、边界条件。

第三道闸门是分级发布闸门：AI 改动影响面不能直接全量上。核心交易链路必须先走金丝雀发布，AI 生成模块的流量只放 5%，观察一段时间再逐步扩大。这一步不是为了防 AI，是为了给整个团队留一个安全缓冲，让大家敢用 AI、敢交付 AI 的产出。

除了闸门本身，我强烈建议做“AI 代码标记”。方式很简单：AI 生成的提交信息里加一个标记，比如[ai-gen]，或者文件头加注释说明来源。别小看这个动作，它让团队能统计“多少比例的代码来自 AI”、能对 AI 产出集中的模块做额外质量抽检、能帮管理层建立对 AI 生产力的客观认知。

5.2 用评测集给团队装一个“AI质检仪”

很多团队在 AI Native 落地过程中最迷茫的一点是“不知道该不该相信 AI”。管理层看到 AI 代码质量时好时坏，工程师也觉得不稳定，但又说不出具体差在哪。解法是建一套属于自己团队的评测集，给 AI 装一个质检仪表盘。

评测集不需要一开始就很庞大，但必须覆盖三类样本：第一类是历史 Bug 回归集，把过去半年团队犯过的典型错误整理成输入输出对，要求 AI 在处理类似任务时不再犯错；第二类是标准能力集，把团队最常写的功能类型抽象成几十个标准化任务，每个任务有明确验收标准，定期让 AI 执行并统计通过率；第三类是边界对抗集，专门挑那些 AI 普遍容易翻车的高难度场景，比如多级缓存一致性、并发账务处理、跨时区日期计算。

跑评测的频率也不用太高，每次模型升级或者 Prompt 模板大改时跑一轮，产出是两个数字：任务完成率和代码可验收率。有了这两个数字，团队讨论“AI 到底行不行”时就不再是拍脑袋，而是看数据说话。我自己做下来最有用的场景是模型选型：评测集跑完一轮，预算充足的旗舰模型和性价比模型差距一目了然，很多场景根本不需要上旗舰模型。

6. 团队落地AI Native的五个典型坑

6.1 坑一：工具碎成一地，上下文断层

这是我在落地第一个月踩得最深的坑。团队里有人用 A 工具做问答，有人用 B 工具写代码，有人用 C 工具做 review，每个工具都有自己的上下文体系，同样的需求在工具之间转来转去时，所有上下文都要人肉重新输入一遍，效率反而比纯人工开发还低。

破局办法是“收敛入口”。要么选择一个生态能力比较完整的 AI 开发平台作为统一入口，要么自建一个轻量 Agent 编排层，把不同工具的服务统一收口。收敛之后要做的是“上下文协议化”：需求信息、代码库结构、团队规范、历史决策，统一放在一个团队知识库里，所有工具通过检索的方式获取，而不是靠人复制粘贴。

6.2 坑二：把 AI 当审查工具，一线工程师反而抵触

很多团队落地 AI Native 时喜欢自上而下推“AI 必须用起来”，然后管理层天天盯着 AI 使用率看板，一线工程师感觉自己在被 AI 监控，抵触情绪很快就起来了。

我的经验是反过来的：让使用 AI 的规则由一线工程师自己定。先选一个业务痛点最轻、收益最容易展示的模块，让两三个对 AI 感兴趣的工程师试点，跑出两周内可感知的成果（比如某类需求工时缩短 40%），然后再由试点工程师去给全组做内部分享，而不是管理层发令。工程师之间的经验传递比任何管理指令都有效，而且他们自己总结出来的用法最贴合实际场景。

6.3 坑三：成本失控，一个 sprint 烧掉一个月的预算

AI Native 看起来是省人力，但如果模型用量管理不好，省下来的人力成本会在 API 账单里加倍吐回去。我们当时第一轮全流程接入，光代码生成和自动测试的 token 消耗，一个迭代直接干掉了原预算的三倍。

成本控制三板斧：第一，分层用模型，把简单任务路由到便宜模型。比如代码格式化、注释生成这类用轻量模型，复杂逻辑生成和架构分析才上旗舰模型，综合成本直接砍半。第二，开启语义缓存，相同或相似的请求直接返回缓存结果，这个对测试用例生成尤其有效，因为同类接口的用例结构高度相似。第三，给每个工程师设置个人调用预算和告警阈值，让成本意识下沉到一线，而不是月底统一看账单。

6.4 坑四：没有评测，团队不知道自己是变好了还是变差了

有一段时间我们的管理层问“AI 落地到底有没有效果”，团队里谁也答不上来。说效率提升了，拿不出硬数据；说质量变好了，也没有对比基线。这是没有建立评测体系导致的典型症状。

其实不需要很复杂的机制，回到第 5.2 节的评测集，再补一个“横向对比”：选取应用 AI 之前的三个典型迭代，按同样口径统计平均交付周期、缺陷密度、返工率。AI Native 流程跑两三个迭代之后，用同一套口径再统计一次，对比结果会让所有人闭嘴。没有数据的转型就是耍流氓，这个原则在任何技术变革里都成立。

6.5 坑五：全员 Prompt 水平参差，产出质量波动大

同一个模型，有人 5 分钟生成一个可以合入的模块，有人折腾一小时产出一堆逻辑漏洞百出的代码。这不是模型能力问题，是 Prompt 能力问题。但我不建议团队花大把时间去全员培训 Prompt 技巧，因为产出不稳定，沉淀机制比自己学更重要。

做法是把好用的 Prompt 全部模板化、资产化。每当我们发现一个高质量 Prompt，就把它存进团队 Prompt 库，按场景分类并附上适用条件和输出示例。新成员不需要从零摸索，直接拿来适配即可。这个库要从第一天就建，哪怕只是一个小表格，随着场景积累它会成为团队最值钱的 AI 资产之一。

最后聊点实在的

我在带团队跑 AI Native 的过程中最大的体会是：转型最难的从来不是技术，而是组织惯性。工具选型、Prompt 模板、评测集，这些都有明确解法；真正消耗精力的是让每个人愿意把原来“亲手做”的任务交出去，同时保持足够的批判精神和验收能力。

我常对团队成员说一句话：别急着追求 AI 替代人，先把 AI 从“玩具”变成“工具”，再把“工具”变成“同事”。这个过程没有捷径，但也没有想象中那么难。难的是每个成员都愿意把自己的一部分工作交出去，然后认真盯住 AI 的产出。

如果你们团队也想走这条路，我的建议是别一上来就全流程铺开，先挑一个模块、一个小团队、一个迭代周期，把 AI Native 的模式在巴掌大的地方跑通，让数据自己说话。跑通了一个，再复制到第二个；复制不顺的，回到评测集找原因。就这样一点一点地长出来，比任何轰轰烈烈的变革都靠谱。