企业官网建设流程全解析

1. 从“AI辅助”到“AI Native”：一次研发范式的底层切换

“AI Native 团队完整开发落地手册”这个标题，乍看像是一份大厂内部流出的规范文档，实际上它指向的是一个正在发生的行业转折点：研发团队的组织方式、协作流程、工具链设计，正在从“人写代码、AI打辅助”过渡到“AI是默认执行者、人是编排者和审核者”。这个转变不是换个编辑器插件那么简单，它涉及整个软件开发生命周期（SDLC）的重构。

我过去一年多参与过三个不同规模的团队做 AI Native 改造，从十几人的创业小队到上百人的业务线，踩过的坑和跑通的路径都挺有代表性。这篇内容适合三类人看：一是正在考虑把 AI 引入研发流程的技术负责人，二是想搞清楚 AI Native 到底怎么落地的工程师，三是对 SDLC 演进方向感兴趣的产品和项目管理者。不管你现在用的是哪种 AI 编码工具，底层的组织逻辑是相通的。

核心关键词里出现的 CLAUDE.md、Skill、Hook，其实是这套体系里三个不同层次的抓手：CLAUDE.md 解决的是“AI 怎么理解你的项目”，Skill 解决的是“AI 怎么执行特定任务”，Hook 解决的是“AI 在什么时机被触发”。这三个东西串起来，就是一条完整的 AI Native 工作流。下面我会按实际落地的顺序，把这套手册拆开讲透。

2. AI Native SDLC 的整体设计思路

2.1 为什么传统 SDLC 在 AI 时代会失效

传统 SDLC 的假设是：需求由人提出，设计由人完成，编码由人执行，测试由人验证。AI 加入之后，如果只是把“编码”这一步换成 AI 生成，其他环节不变，你会发现效率提升非常有限，甚至更慢。原因很简单：AI 生成代码的速度远快于人审查代码的速度，瓶颈从“写”转移到了“审”和“改”。

我见过一个典型场景：团队引入 AI 编码助手后，PR 数量暴涨，但代码审查积压严重，合并周期反而变长。问题不在于 AI 写得不好，而在于整个流程没有为“AI 是主要生产者”这个前提重新设计。AI Native SDLC 的核心思路，是把人从“生产者”位置移到“编排者”和“质量守门人”位置，让 AI 承担大部分重复性、模式化的执行工作。

具体来说，传统 SDLC 和 AI Native SDLC 的差异可以用下面这张表来对照：

这张表不是理论推演，是我在实际项目中反复调整后总结出来的。最关键的一行是“需求传递”：传统方式靠文档和会议，信息损耗大；AI Native 方式靠结构化上下文文件，AI 每次执行任务时都能读到最新、最完整的项目背景。

2.2 三层架构：上下文层、执行层、触发层

AI Native 团队的开发体系可以拆成三层，对应三个核心概念：

上下文层（CLAUDE.md 等）：解决“AI 怎么理解项目”。这层文件定义了项目的技术栈、目录结构、编码规范、业务约束、常见陷阱。AI 每次执行任务前都会读取这层信息，相当于给 AI 一份持续更新的“项目说明书”。

执行层（Skill）：解决“AI 怎么完成特定任务”。Skill 是一组预定义的操作指令，告诉 AI 在遇到某类任务时应该按什么步骤、用什么工具、产出什么格式的结果。比如“生成数据库迁移脚本”是一个 Skill，“写单元测试”是另一个 Skill。

触发层（Hook）：解决“AI 在什么时机被调用”。Hook 是事件驱动的，比如代码提交前触发 lint 检查、PR 创建时触发自动审查、定时任务触发依赖更新。Hook 让 AI 的能力嵌入到研发流程的各个环节，而不是等人来手动调用。

这三层的关系是：上下文层提供知识，执行层提供能力，触发层提供时机。缺任何一层，AI Native 的流程都跑不顺。我见过只配了上下文层但没定义 Skill 的团队，AI 每次都要从头理解任务，效率很低；也见过 Skill 写得很细但 Hook 没配好的，AI 能力很强但总是“叫不动”。

2.3 落地节奏：从单点试点到全流程覆盖

AI Native 改造不能一步到位，我建议分三个阶段推进：

第一阶段：上下文层建设。先把 CLAUDE.md 这类项目上下文文件写好，让 AI 能准确理解项目。这个阶段不需要改流程，只是让现有 AI 工具用得更好。周期大概一到两周。

第二阶段：Skill 沉淀。把团队里高频、重复的任务抽出来，写成 Skill。比如代码审查、测试生成、文档更新、依赖升级。这个阶段开始改变工作方式，AI 从“被动回答”变成“主动执行”。周期大概一个月。

第三阶段：Hook 接入。把 Skill 挂到研发流程的各个节点上，实现自动触发。这个阶段完成后，AI Native 流程才算真正跑起来。周期视团队规模而定，一般两到四周。

三个阶段不是严格串行的，可以并行推进，但上下文层一定要先做，否则后面两层都是空中楼阁。

3. 上下文层：CLAUDE.md 到底该怎么写

3.1 CLAUDE.md 的定位与常见误区

CLAUDE.md 是放在项目根目录的一个 Markdown 文件，AI 编码工具在每次会话开始时会自动读取它。它的作用是给 AI 提供项目级的背景知识，让 AI 不需要每次都被重新告知“这个项目用什么框架”“代码风格是什么”“哪些目录不能动”。

我见过最常见的误区是把 CLAUDE.md 写成 README 的翻版。README 是给人看的，讲的是“这个项目是什么”；CLAUDE.md 是给 AI 看的，讲的是“在这个项目里干活要遵守什么规则”。两者的受众和目的完全不同。

另一个误区是写得太长太全。CLAUDE.md 不是越详细越好，AI 的上下文窗口有限，写太多反而会稀释关键信息。我的经验是控制在 200 到 500 行之间，只写 AI 真正需要知道的东西。

3.2 一份可复用的 CLAUDE.md 模板

下面这份模板是我在多个项目中迭代出来的，你可以直接拿去改：

# 项目上下文 ## 技术栈 - 语言：TypeScript 5.x / Python 3.11 - 框架：Next.js 14 / FastAPI - 数据库：PostgreSQL 15 + Prisma - 测试：Vitest + Playwright ## 目录结构 - src/app：页面路由，不要在这里写业务逻辑 - src/lib：工具函数，纯函数优先 - src/services：业务逻辑，所有数据库操作走这里 - src/components：UI 组件，遵循原子设计 ## 编码规范 - 所有函数必须有显式返回类型 - 禁止使用 any，用 unknown 加类型守卫 - 错误处理统一用 Result 类型，不抛异常 - 命名用 camelCase，常量用 UPPER_SNAKE_CASE ## 业务约束 - 用户数据查询必须带租户 ID 过滤 - 所有金额字段用整数分存储，不用浮点 - 对外 API 必须做速率限制 ## 常见陷阱 - Prisma 的 findMany 默认不分页，必须显式传 take - Next.js 的 server component 里不能用 useState - 测试环境的时间是冻结的，不要依赖 Date.now() ## 提交规范 - commit message 用 conventional commits 格式 - 每个 PR 必须关联 issue 编号

这份模板的关键在于“常见陷阱”那一节。这是 AI 最容易犯错的地方，也是人类工程师最容易被忽略的地方。每次发现 AI 犯了一个新错误，就把它加到这一节里，CLAUDE.md 会越来越“懂”你的项目。

3.3 上下文文件的维护机制

CLAUDE.md 不是写完就完了，它需要持续维护。我的做法是把它纳入代码审查流程：每次 PR 如果引入了新的项目约束或发现了新的常见陷阱，就必须同步更新 CLAUDE.md。这样上下文文件始终和项目实际状态保持一致。

另外，我建议给 CLAUDE.md 加一个“最后更新时间”和“维护人”字段。AI Native 团队里，上下文文件是核心资产，不能让它变成无人维护的孤儿文件。

注意：不要把敏感信息写进 CLAUDE.md，比如数据库密码、API 密钥、内部服务地址。这个文件会随代码仓库分发，写进去等于泄露。

4. 执行层：Skill 的设计与编码实践

4.1 Skill 是什么，和普通提示词有什么区别

Skill 这个词在 AI Native 语境下，指的是一组封装好的、可复用的任务执行指令。它和普通提示词的区别在于：普通提示词是一次性的，Skill 是持久化的；普通提示词只告诉 AI“做什么”，Skill 还告诉 AI“怎么做”“用什么工具”“产出什么格式”。

举个例子。普通提示词可能是“帮我写一个用户注册的 API”。Skill 则会定义：输入是用户模型定义和路由约定，步骤是先写 schema 校验、再写 service 层、再写 controller、最后写测试，输出是四个文件的完整代码，并且要符合 CLAUDE.md 里的编码规范。

Skill 的本质是把团队的最佳实践固化下来，让 AI 每次执行同类任务时都按统一标准来。这解决了 AI 生成代码质量不稳定的问题。

4.2 Skill 的编码结构

一个完整的 Skill 通常包含以下几个部分：

# Skill: 生成数据库迁移 ## 触发条件 当用户要求新增或修改数据库表结构时触发 ## 输入 - 表名和字段定义 - 变更类型（新增表 / 修改字段 / 删除字段） ## 执行步骤 1. 读取 prisma/schema.prisma 了解现有模型 2. 根据输入生成新的模型定义 3. 运行 npx prisma migrate dev --name <变更名> 4. 检查生成的迁移文件是否符合预期 5. 更新 CLAUDE.md 中的数据模型说明 ## 输出格式 - 修改后的 schema.prisma 片段 - 迁移文件路径 - 需要同步更新的代码文件列表 ## 约束 - 禁止直接修改已应用的迁移文件 - 删除字段前必须确认没有代码引用 - 所有新字段必须有默认值或允许 null

这个结构的关键是“约束”部分。没有约束的 Skill 会让 AI 自由发挥，结果不可控。约束写清楚了，AI 的执行结果就稳定。

4.3 高频 Skill 清单与优先级

不是所有任务都值得写成 Skill。我的判断标准是：如果一个任务每周至少执行三次，且步骤相对固定，就值得写成 Skill。下面是我在团队里优先沉淀的 Skill 清单：

P0 的 Skill 必须最先做，因为它们直接影响代码质量和交付速度。P1 和 P2 可以后续补充。

4.4 Skill 的版本管理与迭代

Skill 也需要版本管理。我的做法是把所有 Skill 放在项目的一个独立目录里，比如.ai/skills/，每个 Skill 一个 Markdown 文件，用 Git 管理。每次修改 Skill 都要走 PR 流程，记录修改原因和影响范围。

迭代 Skill 的触发条件通常是：AI 执行结果不符合预期、团队规范发生变化、发现了新的边界情况。每次迭代后，要在 Skill 文件里加一条变更记录，方便追溯。

实操心得：Skill 不要一次写太细。先写一个粗粒度的版本，在实际使用中发现问题再逐步细化。我见过一上来就写几百行 Skill 的，结果 AI 根本读不完，执行效果反而差。

5. 触发层：Hook 的接入与自动化编排

5.1 Hook 在 AI Native 流程中的角色

Hook 是事件驱动的触发器。它监听研发流程中的各种事件（代码提交、PR 创建、定时任务、消息通知），在事件发生时自动调用对应的 Skill。Hook 让 AI 能力从“等人来用”变成“自动运转”。

没有 Hook 的 AI Native 流程，本质上还是人在驱动 AI，只是把 AI 当成了一个更聪明的工具。有了 Hook，流程才真正变成 AI 驱动，人只在关键节点做决策和审核。

5.2 常见 Hook 场景与配置

下面是我在实际项目中配置过的 Hook 场景，按研发阶段排列：

提交前 Hook：在 git commit 之前触发，运行 lint 检查和单元测试。如果检查不通过，阻止提交。这个 Hook 可以用 husky 配置：

# .husky/pre-commit npm run lint npm run test:unit

PR 创建 Hook：在 PR 创建时触发，自动运行代码审查 Skill，把审查结果作为评论贴到 PR 上。这个 Hook 通常通过 CI 配置实现：

# .github/workflows/ai-review.yml name: AI Review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run AI Review run: | # 调用代码审查 Skill npx ai-review --skill code-review --pr ${{ github.event.number }}

定时 Hook：按固定时间触发，比如每天凌晨运行依赖更新 Skill，每周一运行日志分析 Skill。这个用 cron 或 CI 的 schedule 配置。

消息触发 Hook：当收到特定消息时触发，比如在团队聊天工具里发送“部署到测试环境”，自动触发部署 Skill。这个需要结合聊天工具的 webhook 能力。

5.3 Hook 的编排与依赖管理

多个 Hook 之间可能有依赖关系。比如代码审查 Hook 必须在测试 Hook 通过之后才能运行。这时候需要编排逻辑。

我的做法是用一个简单的状态机来管理 Hook 的执行顺序。每个 Hook 执行完后写入一个状态标记，下一个 Hook 检查前置状态是否满足。这个逻辑可以写在 CI 配置里，也可以用脚本实现。

# hook_orchestrator.py HOOK_ORDER = ["lint", "test", "review", "deploy"] def run_hooks(pr_number): state = load_state(pr_number) for hook in HOOK_ORDER: if not state.get(hook): result = execute_hook(hook, pr_number) if result.success: state[hook] = True save_state(pr_number, state) else: notify_failure(hook, result.error) return

这个编排逻辑不复杂，但能避免 Hook 乱序执行导致的问题。

5.4 Hook 的安全边界

Hook 自动执行意味着 AI 有了“自主行动”的能力，这带来安全风险。必须设置边界：

• 涉及生产环境的操作必须人工确认，不能全自动
• 涉及数据删除、权限变更的 Hook 必须加二次验证
• 所有 Hook 执行要有完整日志，便于审计
• Hook 的权限要最小化，只给必要的访问范围

注意：不要让 Hook 直接操作生产数据库。我见过一个团队配了自动数据清理 Hook，结果误删了线上数据。所有涉及生产数据的操作，必须有人工审核环节。

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

6.1 AI 不按 CLAUDE.md 规范执行怎么办

这是最常见的问题。AI 读了 CLAUDE.md 但执行时还是按自己的习惯来。排查思路：

第一，检查 CLAUDE.md 是否在项目根目录，文件名是否正确。有些工具对文件名大小写敏感。

第二，检查 CLAUDE.md 里的规范是否足够具体。“代码要规范”这种表述 AI 无法执行，“所有函数必须有显式返回类型”才能执行。

第三，检查 Skill 里是否重复了关键约束。AI 在长上下文里容易“忘记”前面的内容，在 Skill 里重复关键约束能提升遵守率。

第四，如果还是不遵守，把约束写成 Hook 里的自动检查。AI 可以犯错，但 Hook 会拦住。

6.2 Skill 执行结果不稳定怎么调

Skill 执行结果不稳定，通常是输入不够结构化。AI 对模糊输入的处理结果波动很大。解决办法是把 Skill 的输入格式定义清楚，最好用 JSON Schema 约束。

另一个原因是 Skill 步骤太多。步骤超过七步，AI 容易在中途偏离。建议把大 Skill 拆成多个小 Skill，每个 Skill 只做一件事。

还有一个原因是缺少示例。在 Skill 里加一两个输入输出示例，AI 的执行准确率会明显提升。

6.3 Hook 触发失败排查表

这张表是我在实际排查中总结的，覆盖了八成以上的 Hook 问题。

6.4 团队抵触 AI Native 流程怎么办

技术问题好解决，人的问题难。团队抵触通常来自两个原因：一是觉得 AI 抢饭碗，二是觉得流程变复杂了。

对第一个原因，要明确 AI Native 不是替代工程师，而是把工程师从重复劳动中解放出来。我通常会展示数据：引入 AI Native 流程后，团队在架构设计和技术决策上的时间增加了，在样板代码和重复调试上的时间减少了。

对第二个原因，要分阶段推进，不要一次改太多。先让团队用上 CLAUDE.md，感受到 AI 输出质量提升，再逐步引入 Skill 和 Hook。每一步都要有可见的收益。

实操心得：找一个团队里最有影响力的工程师先试点，让他成为 AI Native 的布道者。自上而下推往往阻力大，自下而上推更容易成功。

7. 从手册到实践：我的落地体会

这套手册不是理论，是我在三个团队里实际跑出来的。最大的体会是：AI Native 改造的难点不在技术，在习惯。工程师习惯了“自己写”，要转变成“让 AI 写、自己审”，需要时间。

另一个体会是：上下文文件的质量决定了 AI Native 的上限。CLAUDE.md 写得越准，Skill 执行越稳，Hook 越少误报。这三层是乘法关系，任何一层薄弱都会拖累整体。

最后分享一个具体技巧：每次 AI 执行出错，不要只改代码，要把错误原因写进 CLAUDE.md 的“常见陷阱”或 Skill 的“约束”里。这样同样的错误只会犯一次。我坚持这个习惯三个月后，团队的 AI 执行准确率从六成提升到了九成以上。这个投入是值得的。