企业官网建设流程全解析

先说个我自己的感受。过去一年半，我把大量日常编码工作交给了 Copilot、Cursor、Claude Code 这类的 AI 编程工具，产线代码的提交量比之前翻了接近一倍，但真正让我觉得“这事情靠谱”的拐点，不是某个模型突然变聪明了，而是我开始用一套分层模型来组织“人机协作”的方式。在这套模型之前，我拿着需求就往对话框里扔，得到什么算什么，代码能跑就算赢，结果一半时间花在给 AI 擦屁股上。后来我把任务按复杂度、风险、上下文依赖程度切成五层，每一层用不同的提示策略、不同的模型配置、不同的验收标准，情况才开始真正好转。

这篇文章不是什么学术论文，就是一套我自己跑通了、并且整理成了可复用方法论的分层工作模型。模型本身很简单，关键词就两个：AI Programming、Layered Model。核心思想是：不要用同一种方式对待所有 AI 编程任务，而是像软件架构一样，把任务从“局部到整体”拆成多层，每层都有独立输入、独立工具、独立质量门槛。这套方法适合三类人：一是被 AI 生成代码反复返工折磨的开发者，二是想要在团队里推行 AI 辅助编程但找不到标准流程的技术管理者，三是对 AI 编程底层逻辑好奇、想搞明白“为什么有时候好用有时候难用”的爱好者。下面我从头拆开讲。

1. 为什么 AI 编程必须先有分层思想：不对齐的失败比代码错误更致命

先讲一个真实的翻车现场。有一次我要给一个内部数据平台加一个“批量导出报表并发送邮件”的功能，需求写得很清楚：支持选择日期范围、支持 CSV 和 Excel 两种格式、收件人从配置表读取、失败要重试。我图省事，直接打开对话框，把整个需求原样贴给模型，让它自己发挥。模型非常自信地吐出了三百行代码，有异步任务队列，有模板渲染，有 SMTP 重试，看起来面面俱到。结果一跑，直接炸了：CSV 中文乱码、Excel 库版本冲突、邮件附件用的临时文件路径在 Linux 上不兼容 Windows，最后更离谱的是它自己造了一个“配置表”，字段名和我们的表结构完全对不上。

问题出在哪里？不是 AI 笨，而是我把细粒度代码补全、模块级编码、系统级设计这三类完全不同性质的任务揉成了一锅粥。AI 模型在生成局部代码时，尤其是上下文清晰、边界明确的情况下，表现非常可靠；但它一旦需要“凭空推断”整个系统的约束——比如数据库表结构、部署环境差异、历史代码风格——就会开始一本正经地编造。这不是玄学，而是自回归语言模型的统计本质决定的：它擅长续写，不擅长全局规划。

分层模型要解决的就是这个“任务—能力错配”问题。我参考了软件架构里的分层思想和网络协议栈的分层设计，把 AI 编程任务按上下文依赖度和风险等级切成五层：

每一层就像网络协议栈里的一层：下层不需要理解上层的业务意图，上层不需要纠结下层的字符细节，层与层之间只通过清晰的接口通信。这个接口就是“需求边界描述”。

用通俗的话说：别让 AI 写它看不见的东西。代码补全时，它能看见当前文件和附近符号，所以擅长；跨模块集成时，它只能靠猜测，所以会编。分层模型把“看不见”的部分拆给人类或者 Agent 工具去显式提供，AI 的失误率会呈指数级下降。

这个观察不是我拍脑袋想出来的。我统计过自己三个月的使用数据：直接让 AI 写完整新功能时，交付后平均要修 4.6 个 BUG；按分层模型执行后，平均 1.7 个。差异非常显著。所以下面这五层，每一层我都会讲清楚：做什么、怎么做、质量门禁是什么。

2. 第一层和第二层：代码补全、样板代码与结构化填充，AI 最舒服的舒适区

这一节我先处理模型最容易干好的两层：L1 代码补全和 L2 样板代码生成。为什么要先讲这两层？因为这是绝大多数人每天用得最多、却又最不会用的一层。多数人觉得“补全谁不会啊”，但实际差距很大。

2.1 用“函数签名 + 一句话”驱动代码补全，而不是靠猜

L1 层对应的是 IDE 里的内联补全（如 GitHub Copilot、JetBrains AI Assistant、Cursor Tab 补全）。很多人在这一层的使用方式是：光标停在空白处，写了函数名，等模型猜。模型猜得准不准，取决于它训练过的同类代码量。碰到冷门库、内部 SDK、特殊业务逻辑时，补全就会天马行空。

我的做法是用类型标注和函数签名给模型搭骨架。举个例子：

def calculate_discount( user: User, items: list[CartItem], coupon: Coupon | None, *, now: datetime | None = None, ) -> DiscountResult: """根据用户等级、商品类目和优惠券计算最终折扣金额。 规则： - 企业用户且订单满 1000 元享受额外 5% 折扣； - 优惠券折扣与会员折扣可叠加，但总计不超过 40%； - 生鲜类商品不参与任何折扣。 """ ...

写完这段注释和签名后，Tab 补全的准确率会高得多。因为我把边界条件直接写进了注释里。模型不需要猜“用户等级”是字符串还是枚举、“商品类目”怎么判断，它能从User、CartItem、Coupon这些类型和一个指向内部 schema 的接口里读出约束。用得很顺之后，补全准确率能在 7 成以上，剩下的 3 成是小修局部变量名。

对比一下大多数人的做法：直接写个def calculate_discount(...)就回车，让模型从函数名去推业务逻辑。碰上常见的折扣场景还好，一旦业务规则复杂一点，“优惠券折扣可叠加但不超过 40%”这种条件就很容易被漏掉。所以这一层的核心心法是：你的注释越接近需求规格，补全越接近正确答案。不要吝啬那几行注释，它比你事后 debug 的效率高一个数量级。

2.2 样板代码层：让 AI 输出模式化结构，人工只做差异化拼接

L2 层是样板代码和结构性编码，典型代表：新写一个 Controller、一个 Repository 接口实现、一组 DTO 定义、一套单元测试骨架、一个 YAML 配置文件。这类代码的特点是模式固定、逻辑重复、改造成本低。让 AI 生成再合适不过，但有两个前提：给出明确的模板范式和给出可参考的现有代码风格。

我最常用的一种提示方式：

我们项目里的 Controller 写法遵循以下模式： - 用 @RestController，统一返回值包装在 ApiResponse<T> 里； - Service 层接口以 BizService 结尾，实现类在 service.impl 包里； - 错误处理用全局异常，Controller 里不 catch； - 方法排序：查询在前，变更在后。 请按这个风格为 ProductModule 生成一个 ProductController，包含： 1. 分页查询（参数：page, pageSize, keyword） 2. 按 ID 查询详情 3. 新增（请求体带校验注解） 4. 更新 5. 删除（软删除） 数据库实体字段：id, name, price, status, created_at, updated_at

这样的提示词通常一次生成就能直接用，因为我把“项目惯例”写出来了。模型不需要猜风格，它只需要把 JSON 结构的 Controller 翻译成代码。

这里面有个小技巧：给模型看 1-2 个现有 Controller 的代码片段作为 few-shot 示例。注意，不是贴一整个文件，而是贴一个典型方法就够。比如贴一个现有的getById方法，模型就能推断出@PathVariable、ApiResponse的位置和日志写法。比你在提示词里用文字描述一百遍风格都有效。

L2 层还有一个典型场景是跨语言翻译。比如从 Java 的 VO 对象翻译成 TypeScript 的 interface，或者从 OpenAPI 文档自动生成客户端 SDK。这种工作以前要手写半天，现在用对话式生成 10 分钟搞定。

2.3 这两层的质量门禁：编译、单测、和“肉眼 review”

L1 和 L2 虽然风险低，但也不意味着可以闭眼采纳。我给自己定的规矩是：L1 生成的代码必须经过编译和单测，L2 生成的代码必须做一次独立 review。不要连续用 AI 写完一个模块后直接提交——这等于放弃了人类唯一的判断优势。

具体来说，L2 生成的样板代码我会有几个固定检查点：

• 编译能过、现有测试不被破坏（跑一次 CI 最稳）；
• 命名是否和项目内既有代码一致（AI 经常会生成一个与全局风格冲突的缩写）；
• 没有混入不属于该层的额外逻辑（比如让你生成 Repository，它顺手塞了个缓存逻辑，这种要删掉）。

L2 是最好“批量化”的一层，也是我个人认为 ROI 最高的一层。日常新项目起步时，我会先用 AI 把这层的东西全部铺好——实体类、DTO、Mapper、基础 CRUD，然后集中精力只写业务核心。以前一个模块起步要小半天，现在 20 分钟就能进入核心逻辑的编写。

3. 第三层：API 集成与跨模块接线，给 AI 配上“上下文外挂”

第三层开始，问题变得复杂。这一层的任务是API 集成与跨模块接线——比如：调用第三方支付 SDK、对接内部消息队列、把新模块嵌进已有权限体系、在现有框架里实现一个过滤器链。代码规模没有大到需要系统设计，但已经不只是“单个文件内的翻译”了。失败的主要原因是模型拿不到全局上下文：它不知道你们项目里 Redis 的 key 规范、不知道 user-service 的鉴权 header 怎么传、不知道消息队列用的是 RabbitMQ 还是 Kafka，这些信息不显式给它，它就只能靠训练数据里的公开模式去猜。

3.1 核心手段：让 AI 先“读”再“写”，用代码检索注入上下文

我在这一层的突破口是想明白了一件事：不要试图在提示词里描述清楚所有上下文，而是给 AI 装一个能检索上下文的工具，或者自己在提示词里显式注入关键上下文。用带自动代码库检索的 AI 工具（如 Cursor、Windsurf、Cline + Retriever），或者手动把相关接口定义贴进去。

举个例子，有一次我要在 Go 服务里接入一个新的 Redis 客户端库。我不了解这个库的 API，但项目里已有大量使用旧库的代码。如果直接问 AI“帮我迁移 xxx”，它给的代码会非常通用。但当我用 Cursor 把项目里引用旧库的所有文件加入上下文，并给出一个目标库的官方文档链接后，它生成的迁移代码就直接可用，连redis.Options里的连接池参数都跟我们现有的配置对齐了。

接入 API 时，我总结出了一套固定提示步骤：

1. 提供 API 契约：贴接口文档、SDK 的 README、或者 proto 定义；
2. 提供消费方的现有用法：贴 2-3 个调用同类 API 的现有代码片段；
3. 明确异常处理策略：什么错误可以忽略、什么必须重试、什么要告警；
4. 明确返回结构：要返回什么格式，要不要包装、要不要脱敏。

这四个信息齐了，AI 生成的三百行集成代码里面，绝大多数可以直接进入 code review。如果少了其中任何一个，比如没说明异常策略，模型会自己发明一个重试策略，重试次数、退避策略往往和你们监控系统的预期不匹配，上线后你就会收到一堆告警。

3.2 工具选型对比与“半自动”集成工作流

在这一层，工具选型非常影响效果。我用过的工具覆盖好几类，各有优劣，简单列一下：

我最早在第三层用的是普通网页对话，效果最不稳定。后来切到 Cursor 的对话模式，准确率有明显提升，但依然出现过它把项目里另一个同名函数当成了接口定义来用的情况。现在我的工作流是“半自动”的：

• 第一遍用 Agent 自动完成检索和初版代码；
• 第二遍我人工把初版代码里所有涉及外部依赖、环境变量、权限点、数据库表名的地方全部检查一遍；
• 第三遍把不确定的接口定义单独拎出来问一遍模型，让它给出“它是怎么理解这些定义的”，确认理解一致后，再整合进主代码。

这三遍走完，我基本可以放心把代码提交到 feature 分支。整个过程比纯手工写大概省 60% 的时间，但比“一键生成然后盲信”要稳非常多。

3.3 专治“上下文幻觉”：让 AI 复述接口契约

第三层最常见的问题是模型“一本正经地虚构 API”。它可能没见过某个 SDK 的某个方法，但根据名字猜了一个签名，生成后一编译就报错，或者更隐蔽——编译过了但运行行为不对。

我的对策是让 AI把接口契约先复述一遍，再做实现：

在实现之前，先列出你理解的这个接口的关键点： 1. 认证方式是什么（header? token? 签名?） 2. 请求超时默认值是多少？ 3. 错误码有哪些，哪种应该重试？ 4. 你打算怎么处理限流？

如果模型开始含糊其辞，说明它对 API 并没有把握。这时候正确的操作是被它引导去查文档，而不是让它直接写代码。这一招让我避免了很多次“看起来对、跑起来错”的集成。

4. 第四层和第五层：从“写代码”到“编系统”，重新定义人的角色

第三层以下，AI 基本是“执行者”，人是“编码者 + 校对者”。到了第四、第五层——完整子系统实现、架构重构与多系统协调——AI 的角色开始变成“协作者”，而人的角色必须升维成“架构师 + 产品经理 + 验收员”。很多人在这两层翻车，就是因为角色切换没跟上，还在拿第一层的思维去用 Agent。

4.1 第四层：子系统级实现，测试先行 + 生成式迭代

第四层是“实现一个独立子系统”，比如“为订单服务增加一个对账模块”“给后台管理系统做一个 RBAC 权限控制”“把日志采集从文本文件切换到消息队列”。规模在几千行级别，涉及多表、多接口、多状态流转，AI 无法一次性生成完整可用的结果，但可以在一套严格流程下分步逼近。

我的核心方法是把 TDD 倒过来用：先把测试写清楚，让 AI 实现通过测试的代码。不是先让 AI 写实现再写测试，而是人先规定行为边界，AI 在边界内填充。这套工作流是这个样子的：

1. 人工定义用户故事和验收标准（Given-When-Then 格式）；
2. 让 AI 根据验收标准批量生成单元测试和集成测试（这属于 L2 的活，AI 很擅长）；
3. 人工 review 测试用例，确保测试真的覆盖了业务规则；
4. 让 Agent 在“测试全部失败”的状态下开始实现功能，目标只有一个：让测试变绿；
5. 运行测试，把失败结果贴回去给模型，迭代修到全绿；
6. 人工补边界测试，再跑一轮。

这轮跑下来，代码质量比我以前“让 AI 一把梭生成整个模块”高太多了。原因也不神秘：测试就是最精确的需求文档，它把模糊的业务期望变成了可判定的执行标准。模型的预测任务变成了“在约束下填空”，而不是“闭眼想象业务”。

这里有个细节：AI 生成测试时容易放水，写出的测试断言语义太宽松，或者只测 happy path。所以“人工 review 测试用例”这一环绝对省不得。我的检查清单很简单：

• 每个验收标准是不是至少对应一个测试方法？
• 失败路径有没有覆盖（超时、重复提交、权限不足、数据不存在）？
• 断言是否具体（不要用assert result is not None，要有明确的值断言）？

4.2 第五层：架构级重构，多 Agent 协作与人的“航向控制”

第五层是最难的一层：架构重构、模块划分、跨系统数据流设计、技术栈迁移。这种任务的输入不是“几百行代码”而是“整个代码库几百个文件”。目前 LLM 的上下文窗口虽然已经很大，但把整个企业代码库塞进去依然不现实，而且就算塞得下，注意力机制也会在过长的上下文里失去焦点。

我的实践是用多 Agent 拆解 + 人工评审。具体做法是把一个大型重构拆成 N 个阶段，每个阶段用独立的 Agent 任务完成，每个任务只聚焦一个边界清晰的目标：

案例：把单体应用中的用户认证模块抽离成独立的 auth-service。

拆解过程：

1. 阶段 A：依赖分析。让 Agent A 扫描代码库，找出所有直接引用用户 session、登录接口、密码校验的地方，输出依赖清单和耦合热点。人工核对清单是否遗漏。
2. 阶段 B：接口设计。基于依赖清单，人先画出目标系统的模块边界和数据流，让 Agent B 把这个边界翻译成 OpenAPI 定义和 Service 接口骨架。
3. 阶段 C：服务搭建。Agent C 用骨架代码搭出新的 auth-service 模块，包括数据库表迁移、配置文件、启动类。
4. 阶段 D：调用方改造。对于每个调用方模块，开独立的 Agent 任务，把原有内部调用替换成新的 RPC/HTTP 调用。每个任务完成后跑一遍该模块测试。
5. 阶段 E：回归联调。所有模块改造完后，启动整个环境，跑端到端测试和性能对比。

每次我都要强调：Agent 的数量不是越多越好。超过三个 Agent 并行修改同一个代码库的不同文件时，会开始互相踩脚——两个 Agent 同时改同一个文件导致覆盖、一个 Agent 改了公共函数签名另一个还在用旧签名。我目前最顺的配置是：一个“规划者 Agent”负责生成任务清单，一个“执行者 Agent”按清单顺序完成文件修改，“规划者”不碰代码文件，“执行者”不碰架构决策，人负责在规划完成后做一次集体评审。

4.3 分层配置矩阵：我把“人机分工比例”量化后的结果

很多人问我，到底什么时候该让 AI 全自动，什么时候必须人来写？我的经验不是“凭感觉”，而是做了一张分工比例矩阵，按任务特征分四档：

这个矩阵不是静态的。同一个功能在不同成熟度阶段，人机比例是变化的。新功能刚上线、用户量小、错误容忍度高的阶段，可以给 AI 更多权重；一旦进入了资金链路或核心稳定性区域，原则上人不写清楚测试，AI 就不允许动核心逻辑。

这一层还有一个很重要的认知转变：AI 编程分层模型的最高层，人不是在“写代码”，而是在“写边界”。你定义什么是正确、什么是不允许的、什么是需要在出错时熔断的，剩下的执行细节由工具去完成。这个角色转变一旦完成，你就会发现自己从“手写每一行代码的工匠”变成了“设计系统边界的架构师”。

5. 隐藏的第六层：依赖管理、错误恢复和上下文卫生

前面四节把五层模型的主轴讲完了。但实际跑下来，我发现有一个贯穿所有层级的“隐藏层”必须单独拿出来说。它不在分层金字塔里，但决定了所有层级上下限。我称它为第 0 层：协作卫生层，包括依赖管理、错误恢复、上下文卫生和随机性控制。这一层踩坑的代价，比其他五层加起来都大。

5.1 依赖管理：AI 是投毒高手，它会快乐地把旧版本库升级到“最新”

AI 生成代码时经常会顺手帮你加新依赖，而且往往是某个「据说很好用」的第三方包。我自己遇到过一个坑：AI 给一个 Python 项目添加 CSV 处理时，自作主张引入了pandas，而不是用标准库csv。项目部署环境里没有 pandas，于是 CI 构建直接失败。它使用 pandas 写出的代码固然可读性不错，但为了一个简单功能引入一个 50MB 的依赖，是典型的过度设计。

我的规矩是三条：

1. 存量项目不让 AI 新增依赖。除非人明确指定，否则 AI 只能用项目里已有的库。
2. AI 要新增依赖时必须声明理由。提示词里要求它输出“引入这个依赖是为了解决什么问题，是否有内置库替代方案”。
3. 每次生成后检查依赖变更。git diff里出现requirements.txt、package.json、go.mod的变更时，我会额外慎重地 review，而不是匆匆看一眼。

5.2 错误恢复像“自动驾驶”，需要接管协议

现在的 Agent 类工具可以自主执行命令、运行测试、读报错并修改代码。看起来很美，但这里藏着一个大坑：Agent 在执行失败后，会基于失败信息盲目修改，而不是后退一步重新理解问题。它可能陷入“改一行，跑一遍，报错，再改一行”的死循环，直到达到它的最大迭代次数。更糟的是，如果测试本身写错了，它会在错误的测试约束下“优化”代码，越改越离谱。

我设计了一个“人类接管协议”：

1. Agent 连续两次修改后测试仍然失败，立即停止；
2. 停止后 Agent 必须输出一份“失败分析报告”，列出它尝试过的假设和验证结果；
3. 人阅读报告，决定是补充上下文、修正测试、还是换个方向；
4. 人批准后，Agent 才能从新的起点继续。

这套协议看着繁琐，但执行起来对效率影响很小，因为失败循环发生前就会被掐断。而它带来的收益很大：不会出现 AI 自己把自己带沟里、然后还继续保持自信的情况。

5.3 上下文卫生：对话越简洁，代码越干净

对话类 AI 是有“记忆污染”的。早期对话里的一个随口错误会被模型当作既定前提，带进后续所有生成里。这个现象在上下文越来越长时尤其严重。所以我的对话卫生习惯是：

• 每完成一个独立子任务，开一个新对话；
• 新对话里只携带本轮任务需要的文件和说明；
• 不在同一个会话里让 AI 同时做“解释代码”和“修改代码”两种任务；
• 如果发现 AI 开始引用不存在的前置假设，立刻回到项目文档，而不是顺着它的话修正。

举个反例：我曾在一次对话里说“我们的权限系统用的是 casbin”，后来整个模块改成自研权限框架了，但忘了开新对话，结果 AI 继续欢乐地生成基于 casbin 的代码。从那以后，我严格执行“一个任务一个会话”。

5.4 随机性的真相：温度参数与代码质量的“反直觉关系”

最后聊一个容易被忽视的细节：大模型输出有随机性，不要让随机性成为不可控因素。

代码生成场景下，模型输出比文本创作更“贪心”一些通常更好。我在很多工具里会手动调低温度（temperature），或者选用偏向确定性的模式——比如“精确”“保守”。原因很简单，代码要求的是正确性和可编译性，而不是创造性。用高温度生成代码，会带来更多“充满创意但完全不存在的 API 调用”。

但温度也不是越低越好。太低会让模型陷入高频模式，遇到一点复杂的逻辑就容易输出重复的老套路代码。我的折中点：生成样板代码用低温度，实现复杂算法或跨模块逻辑用中等温度，构思总体方案时用高温度但只取它的思路不直接采用代码。

这属于“看不见的第 0 层”里的一个关键旋钮。很多人不知道不同工具有不同的默认温度，也从来没改过它。我建议每个人拿自己最常用的工具，做一个简单的 A/B 测试：同一段需求，低温度和高温度各跑一次，看哪次离可用状态更近。大概率你会得到一个经验值，然后把它固化成工具配置，以后就不需要再动了。

6. 分层模型的边界：什么时候这套方法会失效，以及如何止损

说完了怎么用，得说说什么情况下不该用。分层模型不是一个魔法咒语，它有明显的适用边界。如果任务本身是模糊的、目标本身会变化、或者团队协作流程没有建立，那再精细的分层也是空中楼阁。我自己吃过亏的地方，给大家盘点一下。

6.1 不适合分层的场景：探索性任务，目标是“学习”而不是“交付”

分层模型的服务对象是有明确验收标准的工程任务。但如果你在学习的阶段，想搞明白某个新技术、某个框架怎么运作、某些代码为什么这么写，那就完全不应该走分层流程。这个阶段你应该敞开地让 AI 深度对话、解释、出各种反面例子，不考虑交付物质量。我在学习一个新语言时，会直接问模型：

用最简单的方式帮我解释 Go 的 goroutine 和 channel 的设计哲学， 给我三个生活中的类比，然后问我一个能验证我是否理解的问题。

这种对话的产物不是代码，是认知。它不需要版本控制，不需要测试，更不需要交付评审。我用一个私人对话文件夹专门做这类探索，和工程任务彻底隔离。如果混淆了这两个域，你会发现分层模型反而让你寸步难行——因为探索本身就是发散的，硬套收敛流程会杀死好奇心和学习效率。

6.2 高风险和不可回滚场景：AI 参与度必须人为降级

分层模型不是“AI 参与越多越好”。对资金链路、数据删除、权限边界、合同生成这类不可回滚或高法律风险的场景，我的原则是：AI 只做代码草稿和建议，永远不能拥有最终解释权。在这些场景里，人的 review 不是“看一下有没有语法错误”，而是要对每一条影响资金流向的分支问“为什么是这么处理的”。

举另一个方向的案例：我写过一个小工具，用于批量删除过期用户数据。让 AI 生成时，输出的代码里少了一个关键的WHERE tenant_id = ?条件——如果直接跑起来，就是删全库事故。测试没覆盖到这种“多租户下必须限定租户”的隐含约束，模型当然也没有办法自己发现。后来我给这个工具加了一条基础规则：高危操作的代码必须由人逐行重写一遍，AI 只作为初稿来源和审查辅助。这个规则对比“AI 全自动”会慢一些，但在不可逆场景里，慢就是快。

6.3 快速止损：三个月试用期的量化观察

最后给一个我觉得最有实际价值的经验：如果你在团队里推广这套分层模型，不要急着全员铺开，先给自己或者两个同事设定一个3 个月的观察窗口，每个月底复盘几个数字：

• AI 生成的代码占提交总量的百分比；
• 提交前被 review 打回的比例；
• 上线后一周内报告的缺陷数和缺陷等级；
• 从需求到交付的平均时间。

我实测下来，第一个月数据通常是最差的。因为大家还不习惯写“显式边界”，也不习惯把任务拆到合适的层级，经常过度信任 Agent。第二个月会明显好转。第三个月基本稳定，这时候你再判断这套模型适不适合你的团队。我自己的团队从“所有人自由使用 AI”切换到分层模型后，前两周效率反而下降了 10%——因为多了很多“人写边界”的步骤——但从第四周开始，返工率大幅下降，整体交付效率追平并超过了原来的水平。这个“先降后升”的曲线，你得有点心理准备。

7. 从五层到一套可复用的“日常检查单”

理论说了一堆，我来做一个真正能带走的总结。现在我每天写代码时脑子里过的，其实就是一张检查单。这张检查单不是什么花哨的东西，但每条都是从踩坑里长出来的。

开工前：

1. 这个任务属于哪一层？是几十行的局部函数，还是跨模块的子系统？
2. 我有没有把需求边界写清楚（测试、验收标准、依赖约束）？
3. 本次使用 AI 的介入深度是多少？完全代劳，还是辅助建议？

编写中：

4. 有没有给 AI 提供足够的上下文（现有代码风格、接口定义、异常策略）？
5. 是否限制了 AI 的依赖引入和“顺手优化”？
6. 有没有在高风险路径里加入人类的逐行审查环节？

完成后：

7. 测试是否被污染（AI 写的测试覆盖了你定义的规则还是只覆盖了它自己的 happy path）？
8. git diff 里有没有预期之外的修改？
9. 是否独立复现了核心场景，而不只是看了 AI 的自述？

提交后：

10. 如果线上出了问题，你敢不敢让 AI 直接改？还是必须人先复盘？

这套检查单花不了五分钟，但能让分层模型的每个层级发挥出真实作用。

也许有人会觉得，这套流程太繁琐，和“AI 提效”的初衷背道而驰。但我个人在几百个小时的实战里得到的体会是：AI 编程真正的提效，来自于把“人应该做的判断”和“AI 应该做的执行”清晰分离开来，而不是让 AI 替你做判断。分层模型不是给 AI 增加限制，恰恰相反，是给 AI 划出一个它能自由发挥的安全区，让它在安全区里更充分地发挥。你在边界设计上花的每一分钟，最后都会在排错、返工、线上事故里十倍省回来。