企业官网建设流程全解析

1. 从“用AI写代码”到“AI Native团队”的认知跃迁

这两年我参与过不少团队的研发流程改造，从最早大家偷偷用AI补全代码，到后来公司统一采购AI编程助手，再到现在很多团队开始喊“我们要做AI Native团队”。说实话，大部分团队对“AI Native”的理解还停留在“给每个人配一个AI助手”的阶段，这跟真正的AI Native差着十万八千里。

AI Native团队的核心不是“用AI工具”，而是整个软件开发生命周期（SDLC）围绕AI Agent的能力边界来重新设计。传统SDLC是为人设计的：需求评审、技术方案、编码、测试、部署、运维，每个环节都假设执行者是人。AI Native SDLC则假设执行者可能是Agent，或者至少是人机协作——这时候流程、文档、代码组织方式、甚至团队角色定义都要变。

我见过最典型的误区，就是团队花大价钱买了AI编程工具，结果开发流程一点没改，只是让AI帮忙写写函数、补补测试。这就像给马车装了个发动机，但轮子还是木头的，跑不快还容易散架。真正的AI Native改造，需要从上下文工程、Agent编排、验证闭环三个层面同时下手。

这份手册要解决的，就是“知道AI Native好，但不知道怎么落地”的问题。我会把过去一年多在实际项目中踩过的坑、验证过的方案、以及那些文档里不会写的经验，完整地拆开讲。适合正在推动团队AI转型的技术负责人、想搭建Agent工作流的架构师，以及任何对AI Native研发范式感兴趣的一线开发者。不管你现在团队规模是三个人还是三百人，里面的思路和具体操作都能直接参考。

2. AI Native SDLC的整体设计与核心思路拆解

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

传统SDLC的底层假设是“执行者是人”，所以流程设计围绕人的认知特点展开：人需要文档来传递上下文，需要会议来对齐认知，需要代码评审来保证质量，需要测试来兜底。但Agent的认知模式和人有本质区别——Agent没有“遗忘曲线”，但它的上下文窗口有限；Agent不需要“理解业务背景”，但它需要精确的指令和可验证的反馈；Agent不会“累”，但它会在错误的路径上反复尝试直到耗尽token。

我举个实际例子。传统流程里，一个需求从产品经理到开发到测试，中间要经过需求文档、技术方案、接口文档、测试用例等多层传递。每一层传递都会丢失信息，但人可以通过沟通来弥补。换成Agent之后，如果你还是用自然语言文档传递需求，Agent要么理解偏差，要么在细节上反复追问，效率反而更低。

所以AI Native SDLC的第一个设计原则就是：把“给人看的文档”变成“给Agent执行的规范”。这不是说不要文档，而是文档的形态要变。比如CLAUDE.md这种文件，本质上就是给Agent的“项目宪法”，里面写清楚技术栈、代码规范、目录结构、常用命令、禁止事项。Agent每次启动都会读这个文件，相当于每次都给Agent做了一次完整的项目上下文注入。

2.2 AI Native SDLC的四个核心支柱

经过多个项目的迭代，我总结出AI Native SDLC的四个核心支柱，缺一个都会导致落地效果打折扣。

第一个支柱是上下文工程。这是最容易被忽视但最重要的一环。Agent的能力上限很大程度上取决于你给它什么上下文。上下文工程包括：项目级上下文（CLAUDE.md、README、架构文档）、任务级上下文（需求描述、验收标准、相关代码片段）、会话级上下文（历史对话、已尝试的方案、失败原因）。我见过太多团队抱怨Agent“笨”，其实是因为给它的上下文太粗糙。

第二个支柱是Agent编排。单个Agent的能力有限，复杂任务需要多个Agent协作。比如一个负责需求拆解的Agent、一个负责编码的Agent、一个负责测试的Agent、一个负责代码评审的Agent。编排的关键是定义清楚Agent之间的接口和交接标准。这里有个经验：Agent之间的交接最好用结构化数据，而不是自然语言。比如测试Agent给编码Agent的反馈，应该是“第23行空指针异常，输入参数为null时触发”，而不是“代码有点问题，你再看看”。

第三个支柱是验证闭环。Agent最大的问题是“自信地犯错”。它会在没有验证的情况下声称任务完成。所以AI Native SDLC必须内置验证机制：单元测试、集成测试、静态检查、类型检查。而且这些验证必须是自动化的，Agent能自己触发、自己读取结果、自己修复。没有验证闭环的Agent工作流，就是在裸奔。

第四个支柱是Plan Mode。这是Claude Code等工具引入的一个关键概念。Plan Mode的核心思想是：Agent在执行任务前，先输出一个执行计划，人类确认后再执行。这解决了两个问题：一是避免Agent在错误方向上浪费大量token，二是让人类在关键决策点保持控制权。我实测下来，开启Plan Mode后，复杂任务的首次成功率能提升40%以上。

2.3 方案选型：为什么是CLAUDE.md + Agent + Plan Mode

市面上Agent框架很多，LangChain、Dify、CrewAI各有优劣。但在实际项目中，我最终选择的是以CLAUDE.md为上下文载体、以Claude Code为Agent运行时、以Plan Mode为控制机制的方案。原因有三：

第一，上下文注入的简洁性。CLAUDE.md就是一个Markdown文件，放在项目根目录，Agent自动读取。不需要额外的向量数据库、不需要embedding、不需要RAG。对于大多数项目来说，项目级上下文用文件就够了，过度工程化反而增加维护成本。

第二，Agent能力的完整性。Claude Code这类工具已经内置了文件读写、命令执行、代码搜索等基础能力，不需要自己从头搭建Agent基础设施。团队可以把精力放在业务逻辑和流程设计上，而不是造轮子。

第三，Plan Mode的天然优势。Plan Mode让Agent先规划再执行，这符合人类工程师的工作习惯。而且Plan Mode的输出本身就是一份可评审的技术方案，人类可以在执行前介入调整。

当然，这套方案不是银弹。如果你的项目需要复杂的多Agent协作、需要接入大量外部系统、需要精细的权限控制，可能需要更重的框架。但对于大多数中小团队来说，这套方案的上手成本和维护成本都是最低的。

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

3.1 CLAUDE.md的编写规范与常见误区

CLAUDE.md是整个AI Native工作流的基石。它相当于给Agent的“入职培训手册”，写得好不好直接决定Agent的表现。我见过很多团队的CLAUDE.md，要么太简略（只有几行技术栈说明），要么太冗长（把整个架构文档都塞进去），这两种都不可取。

一个好的CLAUDE.md应该包含以下模块：

# 项目概述 一句话说明项目是做什么的，目标用户是谁。 # 技术栈 - 语言：TypeScript 5.x - 框架：Next.js 14 (App Router) - 数据库：PostgreSQL + Prisma - 测试：Vitest + Playwright - 包管理：pnpm # 目录结构 - src/app：页面和API路由 - src/components：可复用组件 - src/lib：工具函数和业务逻辑 - src/server：服务端逻辑 - tests：测试文件 # 常用命令 - pnpm dev：启动开发服务器 - pnpm test：运行单元测试 - pnpm lint：代码检查 - pnpm build：生产构建 # 代码规范 - 使用函数式组件，禁止class组件 - 所有API路由必须有输入校验（zod） - 错误处理统一使用Result类型，禁止throw - 组件文件使用PascalCase，工具函数使用camelCase # 禁止事项 - 禁止直接修改数据库schema，必须通过migration - 禁止在客户端组件中引入服务端代码 - 禁止使用any类型 - 禁止提交console.log

这个模板看起来简单，但每一条都是踩坑之后总结出来的。比如“禁止使用any类型”这条，是因为Agent在不确定类型时倾向于用any来绕过类型检查，结果导致运行时错误。“错误处理统一使用Result类型”这条，是因为Agent默认会用try-catch，但团队约定是Result类型，不写清楚Agent就会按自己的习惯来。

注意：CLAUDE.md不是一次写完就完事的。每次发现Agent犯同类错误，就应该在CLAUDE.md里加一条规则。我习惯在项目初期每周更新一次CLAUDE.md，把Agent踩过的坑都记进去。一个月后，Agent的犯错率会明显下降。

还有一个常见误区是CLAUDE.md写得太抽象。比如“代码要清晰易读”这种话，Agent根本不知道怎么执行。要写成“函数不超过50行，超过就拆分”、“变量名必须能表达用途，禁止用data、temp、result这类泛化命名”。规则越具体，Agent执行越准确。

3.2 Plan Mode的正确打开方式

Plan Mode是Claude Code的一个核心功能，但很多人不知道怎么用。简单说，Plan Mode就是让Agent在动手之前先输出一个计划，人类确认后再执行。这个功能看起来简单，但用好了能省大量时间。

我通常这样使用Plan Mode：

第一步，给Agent一个明确的任务描述。比如“在用户设置页面增加一个修改密码的功能，需要旧密码验证、新密码强度校验、修改成功后发送邮件通知”。

第二步，Agent输出计划。计划通常包括：需要修改哪些文件、每个文件改什么、需要新增哪些文件、需要安装哪些依赖、测试怎么写。

第三步，我审查计划。重点看几个地方：有没有遗漏的边界情况（比如旧密码错误怎么办、新密码和旧密码相同怎么办）、有没有引入不必要的依赖、文件修改范围是否合理。

第四步，确认后Agent执行。执行过程中如果遇到问题，Agent会暂停并询问。

这里有个关键经验：Plan Mode的计划要保存下来。我习惯让Agent把计划写入一个plans/目录下的Markdown文件，文件名用日期加任务名。这样做的好处是，后续如果任务中断或者需要回溯，可以直接看计划文件。而且多个Agent协作时，计划文件可以作为交接文档。

提示：Plan Mode不是万能的。对于非常简单的任务（比如改个文案、修个typo），开Plan Mode反而浪费时间。我的经验是，预计修改超过3个文件或者涉及逻辑变更的任务，才值得开Plan Mode。

还有一个进阶用法：让Agent在Plan Mode中输出多个方案。比如“方案A：直接修改现有组件；方案B：抽取新组件复用”。然后人类选择方案。这比让Agent直接选一个方案要好，因为人类对业务的理解更全面。

3.3 Agent Skill的设计与复用

Agent Skill是最近很火的概念，简单说就是把Agent的能力封装成可复用的模块。比如“生成API文档”是一个Skill，“运行测试并修复失败用例”是一个Skill，“将网页保存为Markdown”也是一个Skill。

在实际项目中，我通常把Skill分为三类：

第一类是项目级Skill，跟具体项目强相关。比如“按照我们的代码规范生成React组件”、“按照我们的API格式生成接口文档”。这类Skill通常放在项目的.claude/skills/目录下，跟项目一起版本管理。

第二类是团队级Skill，跨项目复用。比如“代码评审检查清单”、“安全漏洞扫描”、“性能分析”。这类Skill可以放在团队的共享仓库里，通过软链接或者包管理工具引入。

第三类是通用级Skill，跟具体业务无关。比如“将网页保存为Markdown”、“生成Mermaid图表”、“格式化JSON”。这类Skill可以直接用社区现成的，也可以自己写。

写Skill的关键是定义清楚输入输出。一个好的Skill应该像函数一样：给定明确的输入，产出明确的输出。比如“代码评审Skill”的输入是代码diff，输出是评审意见列表，每条意见包含文件、行号、严重程度、建议。

# Skill: 代码评审 ## 输入 - 代码diff（通过git diff获取） - 项目CLAUDE.md（获取代码规范） ## 输出 评审意见列表，每条包含： - 文件路径 - 行号 - 严重程度（blocker/critical/major/minor） - 问题描述 - 修改建议 ## 检查项 1. 是否符合CLAUDE.md中的代码规范 2. 是否有未处理的错误情况 3. 是否有潜在的空指针或类型错误 4. 是否有性能问题（如循环内查询数据库） 5. 是否有安全风险（如SQL注入、XSS）

这个Skill写好后，每次代码评审都可以直接调用，Agent会按照固定格式输出评审意见。比让Agent“随便看看代码有没有问题”要靠谱得多。

注意：Skill不是越多越好。我见过团队写了上百个Skill，结果Agent不知道该用哪个。我的建议是，项目级Skill控制在10个以内，团队级Skill控制在20个以内。每个Skill都要有明确的触发条件和使用场景。

3.4 Agent安全与沙箱机制

Agent安全是很多团队忽视的问题。Agent有文件读写和命令执行权限，如果被恶意利用或者自己犯错，后果可能很严重。我听过最离谱的案例是Agent在执行“清理临时文件”任务时，把整个项目目录删了。

所以AI Native团队必须建立Agent安全机制。我通常从三个层面入手：

第一层是权限控制。Agent不应该有无限权限。比如生产环境的数据库，Agent只能读不能写；部署命令，Agent只能执行预定义的脚本，不能执行任意命令。Claude Code支持通过配置文件限制Agent的权限，这个一定要配。

第二层是沙箱隔离。Agent执行命令时，应该在沙箱环境中执行。比如用Docker容器隔离，或者用专门的沙箱工具。这样即使Agent执行了危险命令，影响范围也有限。

第三层是操作审计。Agent的每一步操作都要有日志记录。包括读了哪些文件、执行了哪些命令、修改了哪些内容。这样出问题时可以回溯。

# 示例：限制Agent只能执行白名单命令 # 在项目配置中定义 allowed_commands: - "pnpm test" - "pnpm lint" - "pnpm build" - "git diff" - "git status"

提示：Agent安全不是一次性工作，而是持续过程。每次给Agent新增权限时，都要问自己：这个权限真的必要吗？有没有更小的权限集能满足需求？

还有一个容易被忽视的点是Agent的记忆安全。Agent在会话中会记住很多信息，包括代码片段、配置、甚至密钥。如果这些信息被写入日志或者持久化存储，可能造成泄露。所以Agent的会话记录要定期清理，敏感信息要脱敏。

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

4.1 从零搭建AI Native工作流的完整步骤

假设你现在有一个中等规模的TypeScript项目，团队5个人，想改造成AI Native工作流。下面是我实际用过的步骤，按顺序执行即可。

第一步：初始化CLAUDE.md。在项目根目录创建CLAUDE.md，按照3.1节的模板填写。初期不用追求完美，先把技术栈、目录结构、常用命令写清楚。代码规范和禁止事项可以后续逐步补充。

第二步：配置Agent权限。在项目配置中定义Agent可以执行哪些命令、可以读写哪些目录。建议初期权限收紧，只开放必要的命令。比如只允许pnpm test、pnpm lint、git diff，不允许git push、rm、curl。

第三步：建立Plan Mode工作流。约定所有非平凡任务都必须先出计划。计划文件统一放在plans/目录下，命名格式为YYYY-MM-DD-任务名.md。计划文件要纳入版本管理，方便回溯。

第四步：编写核心Skill。初期先写三个Skill：代码生成Skill、代码评审Skill、测试生成Skill。这三个覆盖了日常开发的大部分场景。Skill文件放在.claude/skills/目录下。

第五步：建立验证闭环。配置CI流水线，确保每次代码提交都自动运行测试、lint、类型检查。Agent在本地执行任务后，也要触发这些验证。验证不通过时，Agent要能读取错误信息并尝试修复。

第六步：迭代优化。每周回顾一次Agent的表现，把常见错误补充到CLAUDE.md中，把重复操作封装成Skill。这个过程持续一个月左右，工作流就会比较稳定。

4.2 一个完整任务的实操记录

我拿一个真实任务来演示整个流程。任务描述：“在用户设置页面增加修改密码功能，需要旧密码验证、新密码强度校验、修改成功后发送邮件通知。”

阶段一：Plan Mode规划

我给Agent的指令是：“在用户设置页面增加修改密码功能。要求：1）旧密码验证；2）新密码强度校验（至少8位，包含大小写字母和数字）；3）修改成功后发送邮件通知。请先输出执行计划。”

Agent输出的计划如下：

# 执行计划：修改密码功能 ## 需要修改的文件 1. src/app/settings/page.tsx - 添加修改密码表单 2. src/server/routes/user.ts - 添加修改密码API 3. src/lib/validators.ts - 添加密码强度校验函数 4. src/lib/email.ts - 添加密码修改通知邮件模板 5. tests/user.test.ts - 添加测试用例 ## 需要新增的依赖 - 无（使用现有依赖） ## 实现步骤 1. 在validators.ts中添加validatePasswordStrength函数 2. 在user.ts中添加POST /api/user/change-password路由 3. 在email.ts中添加sendPasswordChangedEmail函数 4. 在settings/page.tsx中添加表单组件 5. 编写测试用例 ## 边界情况处理 - 旧密码错误：返回401，提示“旧密码不正确” - 新密码强度不足：返回400，提示具体哪项不满足 - 新密码与旧密码相同：返回400，提示“新密码不能与旧密码相同” - 邮件发送失败：记录日志，但不影响密码修改结果 ## 测试计划 - 单元测试：validatePasswordStrength函数 - 集成测试：修改密码API的各种情况 - E2E测试：表单提交流程

我审查这个计划，发现两个问题：一是没有考虑“用户未登录”的情况，二是邮件发送失败的处理需要确认。我跟Agent沟通后，Agent补充了未登录返回401的处理，并确认邮件发送失败只记录日志。

阶段二：Agent执行

确认计划后，Agent开始执行。执行过程中，Agent每完成一个文件就运行一次相关测试。比如写完validators.ts后，立即运行pnpm test validators。测试通过后继续下一个文件。

执行到API路由时，Agent遇到一个问题：现有的错误处理中间件不支持返回自定义错误码。Agent暂停并询问：“现有错误处理中间件只支持500错误，需要修改中间件还是用其他方式返回400/401？”我回复：“修改中间件，支持自定义错误码。”Agent继续执行。

阶段三：验证与修复

所有文件写完后，Agent运行完整测试套件。发现两个测试失败：一个是密码强度校验的边界情况（正好8位但只有小写字母），一个是邮件模板的变量替换。Agent读取错误信息后，自动修复了这两个问题，再次运行测试通过。

阶段四：代码评审

我调用代码评审Skill，Agent输出评审意见：

# 代码评审意见 ## src/server/routes/user.ts - 第45行：旧密码验证使用了===比较，建议使用bcrypt.compare（critical） - 第52行：新密码强度校验在服务端和客户端重复实现，建议抽取共享函数（major） - 第67行：邮件发送失败只记录了日志，建议增加重试机制（minor） ## src/app/settings/page.tsx - 第23行：表单提交后没有禁用按钮，用户可能重复提交（major） - 第34行：错误提示没有做国际化处理（minor）

我根据评审意见，让Agent修复了critical和major问题，minor问题记录到待办事项。

阶段五：提交与部署

所有验证通过后，Agent生成commit message，我确认后提交。CI流水线自动运行，全部通过后合并到主分支。

这个任务从开始到完成，实际耗时约40分钟，其中我介入的时间约10分钟（审查计划、回答问题、确认评审意见）。如果没有AI Native工作流，这个任务大概需要2-3小时。

4.3 多Agent协作的编排实践

单个Agent能处理的任务有限，复杂任务需要多Agent协作。我常用的多Agent编排模式是“规划-执行-验证”三段式。

规划Agent负责拆解任务、制定计划、分配子任务。它的输出是一份结构化的任务列表，每个任务包含：任务描述、负责的Agent、输入、预期输出、验收标准。

执行Agent负责具体实现。每个执行Agent专注于一个子任务，比如“实现API路由”、“实现前端组件”、“编写测试”。执行Agent之间不直接通信，通过规划Agent协调。

验证Agent负责检查执行结果。它读取执行Agent的输出，对照验收标准检查，输出通过或不通过的结论。不通过时，验证Agent给出具体问题和修改建议，规划Agent重新分配给执行Agent。

# 任务分配示例 ## 任务1：实现密码强度校验函数 - 负责Agent：执行Agent-A - 输入：需求描述、CLAUDE.md - 预期输出：src/lib/validators.ts中的validatePasswordStrength函数 - 验收标准：单元测试覆盖率100%，边界情况全部处理 ## 任务2：实现修改密码API - 负责Agent：执行Agent-B - 输入：任务1的输出、API规范 - 预期输出：src/server/routes/user.ts中的路由 - 验收标准：集成测试通过，错误处理完整 ## 任务3：验证所有输出 - 负责Agent：验证Agent - 输入：任务1和任务2的输出 - 预期输出：验证报告 - 验收标准：所有测试通过，代码评审无critical问题

这种编排模式的好处是职责清晰，每个Agent只关注自己的任务。坏处是通信开销大，规划Agent需要维护全局状态。我的经验是，任务数量在5-10个时效果最好，超过10个建议拆分成多个批次。

注意：多Agent协作时，上下文传递是关键。执行Agent-B需要知道执行Agent-A的输出，但不能把A的全部上下文都给B，否则B的上下文窗口会爆。我的做法是只传递接口定义和关键代码片段，不传递完整文件。

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

5.1 Agent“自信地犯错”怎么破

这是最常见的问题。Agent会在没有验证的情况下声称任务完成，或者在没有理解需求的情况下开始编码。我总结了几个应对方法：

方法一：强制验证。在CLAUDE.md中明确规定：“任何任务完成后，必须运行相关测试并确认通过。测试不通过时，禁止声称任务完成。”这条规则能过滤掉大部分“自信犯错”。

方法二：要求Agent输出证据。让Agent在声称完成时，附上验证证据。比如“测试运行结果：23 passed, 0 failed”、“lint检查：无错误”。没有证据的完成声明一律不认。

方法三：Plan Mode前置。让Agent先出计划再执行，人类在计划阶段就能发现理解偏差。这比执行完再返工要省时间。

方法四：小步快跑。把大任务拆成小任务，每个小任务完成后立即验证。不要等所有任务都完成再验证，那样错误会累积。

5.2 上下文窗口不够用怎么办

Agent的上下文窗口有限，复杂任务很容易超出。我的应对策略是分层管理上下文：

项目级上下文放在CLAUDE.md中，Agent每次启动自动读取。这部分要精简，只放最核心的信息。

任务级上下文放在任务描述中，只包含当前任务相关的信息。比如修改密码任务，只需要用户模型、认证中间件、邮件服务的相关信息，不需要整个项目的架构文档。

会话级上下文通过摘要压缩。当会话过长时，让Agent总结之前的对话，只保留关键决策和未解决问题。然后开启新会话，把摘要作为初始上下文。

# 会话摘要示例 ## 已完成 - 密码强度校验函数已实现并测试通过 - 修改密码API已实现，集成测试通过 ## 进行中 - 前端表单组件开发中，遇到表单验证库版本兼容问题 ## 待办 - 邮件通知模板 - E2E测试 ## 关键决策 - 错误处理使用自定义错误码，已修改中间件 - 邮件发送失败只记录日志，不阻塞密码修改

5.3 Agent执行中断或报错怎么处理

Agent执行中断的原因很多：命令执行失败、上下文超限、网络问题、权限不足。我的排查顺序是：

第一步，看错误信息。Agent通常会输出错误原因，比如“command not found”、“permission denied”、“context length exceeded”。根据错误信息定位问题。

第二步，检查权限配置。如果是权限问题，确认Agent是否有执行该命令的权限。没有的话，要么开放权限，要么换一种实现方式。

第三步，检查上下文长度。如果是上下文超限，压缩上下文或者拆分会话。

第四步，重试。有时候是临时问题，重试一次就好了。但重试前要确认Agent的状态，避免重复执行已完成的操作。

提示：Agent执行中断后，不要直接重新开始。先让Agent输出当前状态：“已完成哪些操作、当前在做什么、下一步计划是什么。”根据状态决定是继续还是回滚。

5.4 常见问题速查表

5.5 独家避坑技巧

技巧一：给Agent起名字。在多Agent协作时，给每个Agent起个名字（比如“前端Agent”、“后端Agent”、“测试Agent”），比用“Agent-A”、“Agent-B”要清晰得多。Agent自己也会在输出中引用名字，减少混淆。

技巧二：用注释给Agent留线索。在代码中写// TODO(agent): 这里需要处理空数组的情况，Agent读到这个注释就会知道这里需要特殊处理。比在CLAUDE.md中写规则要精准。

技巧三：定期清理Agent的“记忆”。Agent的会话记录会越来越长，影响性能。我习惯每天结束工作时，让Agent总结当天的工作，然后开启新会话。总结文件放在agent-logs/目录下，按日期命名。

技巧四：用Agent生成Agent配置。让Agent根据项目情况生成CLAUDE.md和Skill配置，人类再审查调整。这比从零写要快，而且Agent更了解自己的需求。

技巧五：建立Agent错误库。每次Agent犯错，都记录到agent-errors.md中，包含错误现象、原因、解决方案。这个文件可以作为CLAUDE.md的补充，也可以用来训练新Agent。

# Agent错误库 ## 错误001：使用any类型绕过类型检查 - 现象：Agent在不确定类型时使用any - 原因：CLAUDE.md中未明确禁止any - 解决方案：在CLAUDE.md中添加“禁止使用any类型” - 日期：2024-01-15 ## 错误002：忘记处理空数组 - 现象：Agent写的函数在输入空数组时崩溃 - 原因：Agent默认假设输入非空 - 解决方案：在CLAUDE.md中添加“所有数组操作必须处理空数组情况” - 日期：2024-01-18

这套错误库积累下来，就是团队最宝贵的AI Native资产。新项目启动时，直接把错误库复制过去，Agent的犯错率会大幅降低。

6. 团队角色与协作模式的重新定义

AI Native团队不只是工具升级，团队角色和协作模式也要跟着变。我观察到的变化主要有三个。

第一个变化是“提示词工程师”角色的出现。传统团队没有这个角色，但现在需要有人专门负责CLAUDE.md的维护、Skill的编写、Agent的调优。这个角色不一定是专职的，但必须有明确的责任人。我通常让团队里对AI最熟悉的工程师兼任，每周投入20%的时间。

第二个变化是代码评审的重点转移。传统代码评审关注代码逻辑、边界情况、性能。AI Native团队的代码评审，除了这些，还要关注“Agent是否遵循了CLAUDE.md中的规范”、“是否有Agent特有的错误模式”。比如Agent倾向于用any类型、倾向于忽略空数组、倾向于在循环中查询数据库。这些模式要在评审中重点检查。

第三个变化是测试策略的调整。Agent写的代码，测试覆盖率通常很高，但测试质量参差不齐。Agent会写很多“形式正确但实际无用”的测试，比如测试一个函数返回了非null，但不测试返回值是否正确。所以AI Native团队的测试策略要强调“测试的有效性”，而不是“测试的数量”。

协作模式上，我推荐“人类定方向、Agent做执行、人类做验收”的模式。人类负责需求分析、方案设计、关键决策、最终验收。Agent负责编码、测试、文档、重复性工作。中间的交接点用Plan Mode和验证闭环来保证质量。

这种模式下，一个5人团队的实际产出能顶传统模式10-15人。但前提是团队每个人都理解AI Native的工作方式，而不是只有一两个人会用。

7. 从单点工具到研发范式的演进路径

很多团队问我：“我们想搞AI Native，第一步该做什么？”我的建议是分三个阶段走，不要一步到位。

第一阶段是工具普及。让团队每个人都用上AI编程工具，熟悉基本的交互方式。这个阶段的目标是让每个人都能用AI辅助日常编码，比如生成函数、写测试、解释代码。这个阶段通常需要2-4周。

第二阶段是流程改造。引入CLAUDE.md、Plan Mode、验证闭环，把AI从“辅助工具”变成“工作流的一部分”。这个阶段的目标是让AI参与到完整任务中，而不是只做零散的工作。这个阶段通常需要1-2个月。

第三阶段是范式转型。重新定义团队角色、协作模式、质量标准和交付流程。这个阶段的目标是让AI Native成为团队的工作方式，而不是额外负担。这个阶段通常需要3-6个月。

每个阶段都有明确的标志。第一阶段完成的标志是：团队每个人都至少用AI完成过一个完整任务。第二阶段完成的标志是：团队有一半以上的任务是通过AI Native工作流完成的。第三阶段完成的标志是：新成员加入时，默认就按AI Native方式工作，不需要额外培训。

我个人在实际操作中的体会是，最难的不是技术，而是习惯。工程师习惯了“自己写代码”，对Agent写的代码总是不放心，忍不住要逐行审查。这其实是用人的标准要求Agent，效率反而低。正确的做法是建立验证机制，让机制来保证质量，人类只审查关键决策和验证结果。这个心态转变，比学任何工具都重要。

最后再分享一个小技巧：每周花30分钟，让Agent总结本周的工作，包括完成了哪些任务、遇到了哪些问题、有哪些改进建议。这个总结比人类自己写的周报要客观得多，而且能发现很多被忽视的模式。我坚持了三个月，Agent总结出来的问题清单，比团队自己发现的还要全面。