企业官网建设流程全解析

Claude Code最近有个说法挺有意思：Claudeception。乍一看像是什么玄学概念，其实它描述的是一个非常实在的工作方式——让Claude Code在持续编码的过程中，不断把上一次的经验、踩过的坑、修正过的决策写回到自己的“记忆”里，成为下一次任务的输入。这种自我迭代的循环，就像一层套一层的递归，所以被起了个致敬“盗梦空间”的名字。

我第一次看这个说法时也觉得虚。AI编码工具天天在用，Claude Code我也从CLI用到桌面版、从VSCode插件用到本地模型，但多数人的用法其实是“一次性提问、一次性生成、用完即忘”。代码生成完，上下文一关，Claude对我项目结构、技术栈偏好、易错点的理解归零了。下次开工，它又是一个“初来乍到”的新人。Claudeception要解决的，就是这个问题：把一次性问答，变成可持续生长的长期记忆。

这篇内容我想认真拆一下这个机制。不聊虚的，只聊怎么搭环境、怎么设计记忆层、怎么让每一次错误修复和代码审查都变成下一轮编码的“教材”，以及这个循环的边界在哪里。

1. "Claudeception"到底指什么：一种自我迭代的编码工作流

1.1 为什么AI编程工具需要"持续学习"这个观念

先下一个简单的定义：Claudeception，是指在Claude Code的使用过程中，让工具周期性地对自己之前的产出进行审查、总结、沉淀，并把结论持久化到项目文件或技能文件中，使后续会话天然继承前序会话的经验。它不是模型本身在训练时的机器学习，而是工作流层面的自我进化。

为什么这件事值得单独拿出来讲？因为我见过太多团队用AI编码工具的姿势完全跑偏了。最常见的问题有两个。

第一个是**“没有记忆的修bug”**。项目跑出问题，把报错丢给Claude Code，它给了一个修复方案，你改了，暂时能跑了。但一周后同一个坑又出现，你不得不又把一模一样的报错丢给它，它又从头开始分析。这不是AI笨，是它没有记忆——你没有给它记忆。

第二个是**“风格不统一”**。团队里几个开发都用Claude Code，但每个人给的指令风格不同，生成的代码也五花八门。有人喜欢函数式写React，有人习惯类组件，Claude Code就只能每轮猜测你的偏好。猜错的代价，是生成的代码重写成本很高。

Claudeception的核心价值，就是让Claude Code通过一套显式的、可复查的机制，把“这次对话产生的认知”保存下来。它学到的不是参数，而是你项目的结构、你的编码偏好、你踩过的坑的解决方案。每次新会话开始，它先读“之前的自己”写下的笔记，然后基于笔记干活。这样的编码工具，用起来才像共事半年的队友，而不是每天新入职的实习生。

1.2 Claudeception与普通"把需求扔给AI"的差别

普通用法是“提问-回答”的线性模型，Claudeception是“执行-复盘-沉淀-复用”的循环模型。你可以这么对比：

这个差别在实际项目中感受非常明显。我维护一个中型Java后端项目时，最初直接用Claude Code写新模块，它总是默认用Spring的构造器注入方式，但团队实际约定是字段注入；它总是把工具类写到service包下面，但项目有单独的common模块。一次两次可以口头纠正，但每次都纠正就烦了。后来我花了一个下午把项目规范、依赖关系、易错点全部整理成记忆文件，再让Claude Code开工，生成的代码基本不需要大改。

这就是Claudeception最朴素的价值：你不需要换一个更聪明的模型，你只需要让现有的工具记住上次怎么把事做对的。

2. 搭建能跑通"自我学习"的基础环境

2.1 Claude Code的安装与运行前提

要玩Claudeception，第一步是把Claude Code跑起来。这工具本身不挑平台，Windows、macOS、Ubuntu都有对应安装路径，核心依赖是Node.js环境。

最简单的安装方式是通过npm全局安装：

npm install -g @anthropic-ai/claude-code

装完以后直接在终端输入claude就能启动交互式会话。如果你习惯在编辑器里工作，VSCode插件版和前阵子很火的桌面版体验也大同小异，本质都是同一个引擎，差别在交互外壳和文件管理的方式。

几个安装前要注意的点：

• Node版本：建议16.x以上，过老的版本会出现加载失败或者运行时报模块找不到。
• 网络连通性：它安装和启动时需要访问软件仓库和API服务，网络不稳定会导致安装到一半失败。
• 登录与授权：首次启动会让你完成账号授权。这里有好几种授权路径，具体取决于你所在组织的订阅策略。如果你在团队工作，团队管理员可能已经配置了统一的访问权限，这时不需要个人单独操作；如果终端提示你的组织禁用了订阅访问，那是组织层面的订阅策略决定，需要联系你们的管理员开通，而不是自己想办法绕过去。

安装完成后，我习惯先跑一个最简单的请求验证环境是否正常：

claude -p "Say hello"

如果正常返回，说明基础链路没问题。

2.2 Windows下常见安装坑与InternetOpenUrl错误排查

Windows用户遇到的问题最多。我在实际使用中遇到过两类高发故障。

第一类是安装过程中的权限或版本冲突。npm全局安装失败，常见原因是Node.js安装目录权限不足。解决方案是调整npm全局包的安装路径，或者用管理员身份运行终端。这算是常规操作，网上资料很多，不再展开。

第二类是启动时的网络请求错误，很多Windows用户会看到类似这样的报错：

使用CLI执行此命令时发生意外错误: InternetOpenUrl() failed. 0x800...

这个错误码的本质是系统底层的网络接口调用失败，在处理联网请求时没有得到响应。排查思路按下面顺序来：

1. 先把代理和防火墙因素排除。公司网络、安全软件、系统防火墙都可能拦截命令行工具发起的HTTPS请求。最直接的验证方式是换一个纯净网络环境再试一次。
2. 检查系统时间。Windows下如果系统时间和实际时间偏差太大，TLS握手会被证书拒掉，表现就是这种底层网络错误。
3. 查看网络栈是否有异常。在终端里执行简单的HTTPS请求测试，比如用curl访问一个常见网站，如果能通，说明基本网络没问题；如果也失败，那就是系统级网络配置的问题。

这个错误本身和工具逻辑关系不大，多半是运行环境的网络策略问题。如果你在公司网络下遇到，找网络管理员确认命令行工具的HTTPS请求有没有被安全策略拦截，比反复重装工具有效得多。

2.3 不依赖云端模型：接入本地推理服务的路径

Claudeception的循环能不能成立，前提是Claude Code得处于可用状态。但有些场景下，访问云端服务并不顺畅——离线开发环境、内网隔离的研发环境、或者你只是不想让代码上传到云端。这时候可以走本地模型推理的路径。

本地推理的思路是用一个本地运行的推理服务，替代默认的云端接口。我自己实测可行的方案是用LM Studio拉起本地模型，再通过环境变量把Claude Code指向它。大致步骤如下：

1. 在LM Studio中加载一个兼容OpenAI接口协议的模型，启动本地API服务。
2. 设置环境变量，让Claude Code将请求发往本地服务：

export CLAUDE_LLM_ENDPOINT=http://localhost:1234/v1 export ANTHROPIC_BASE_URL=http://localhost:1234/v1

3. 设置访问密钥为本地服务默认占位值，重新启动Claude Code。

需要特别说明的是：本地模型的能力上限和云端模型有明显差距。处理简单任务、快速原型、代码重构这类工作，本地模型完全够用；但处理大型项目的复杂架构推理时，本地模型的上下文理解和指令遵循能力可能不足。我自己的做法是：本地模型负责日常辅助，复杂任务切回云端服务。这种混合模式既兼顾了数据安全，又不牺牲复杂任务的完成质量。

3. 让Claude Code记住"上一次的自己"：记忆层的设计

Claudeception的实质是构建一个跨会话的记忆层。没有这个记忆层，它每次都白纸一张；有了它，每次都站在前一次的肩膀上。Claude Code里，记忆层的载体主要有三个：项目记忆文件、技能文件、设置文件。

3.1 CLAUDE.md：项目级长期记忆的载体

CLAUDE.md是Claude Code启动时会自动读取的项目级记忆文件。你可以把它理解为给AI看的项目说明书。每次新会话启动，它都会读这个文件，所以你在里面写什么，直接决定它对你项目的理解程度。

一个合格的CLAUDE.md至少应该包含这几块：

• 项目简介：这个系统是干什么的，核心业务逻辑是什么。
• 技术栈与目录结构：前端用什么框架、后端用什么语言、公共代码放在哪个模块。
• 编码规范：命名风格、文件组织、依赖注入方式、错误处理策略。
• 常用命令：如何启动开发环境、如何跑测试、如何构建。
• 已知坑点：哪些地方容易出问题，修复过一次的问题的结论。

举个实际的例子，我给一个项目写的CLAUDE.md开头是这样的：

# 项目记忆 ## 项目定位 订单履约系统，核心链路是「下单-支付-库存扣减-物流发货」。 ## 技术栈 - 后端：Java 17 + Spring Boot 3.x - 构建：Maven，私服仓库地址见 settings.xml - 数据库：MySQL 8.0，主要表结构见 docs/schema.md ## 编码规范 - Controller层只做参数校验和响应封装，不允许写业务逻辑 - Service层接口命名用动词开头：createOrder、cancelOrder - 依赖注入统一用构造器注入，禁止字段注入 - 所有对外接口必须写OpenAPI注解

写这个文件的好处是，它把原本需要反复口头交代的事情，一次性固化下来。Claude Code每次读这个文件，就相当于项目的老员工第一天被重新介绍了一遍团队规则。但要记住一点：CLAUDE.md不是写完就不动的，它应该随项目演化持续更新。这就引出了持续学习循环的核心操作——让Claude Code自己写完代码后，顺手把新发现更新进CLAUDE.md。

3.2 用Skill让工具长出"新技能"而不是单纯聊天

CLAUDE.md解决的是“背景知识”，而Skill文件解决的是“操作能力”。Claude Code的Skill机制允许你给它定义一套可复用的工作流——不再靠每次手写一堆指令，而是把某类任务的执行步骤、判断标准、输出格式预先定义好，让它遇到对应场景时自动调用。

比如“修复bug”可以是一个Skill。它的定义大致包含：

• 触发条件：用户粘贴报错信息，或者代码中出现明确异常。
• 处理步骤：先复现，再定位，再分析根因，再给出最小修复。
• 输出要求：修复后必须补充一段“问题原因与后续预防”说明，并写入项目记忆。

再比如“代码审查”也可以是一个Skill。触发后，它按固定节奏检查：安全风险、性能瓶颈、命名规范、测试覆盖，最后输出结构化报告。

Skill的目录约定一般是放在项目的.claude/skills/目录下，每个Skill一个子目录，里面是描述文件和使用说明。写Skill时最重要的不是堆命令，而是定义清楚触发条件和结束条件。触发条件模糊，它会在不该出现时乱入；结束条件模糊，它会干完活不收敛，反而拖慢节奏。

Skill机制对Claudeception特别重要，因为它是把“经验”转化为“标准操作程序”的桥梁。你踩过一次坑，可以把坑的检查点写进Skill，后续每次执行同类任务，它就会自动按新检查点走完流程。

3.3 settings.json与多项目配置隔离

Claude Code在用户目录下会有全局设置文件（settings.json），用来控制主题、默认行为、模型选择等偏好。如果你同时维护多个项目，并且各项目有不同的模型路由或上下文窗口要求，可以在项目根目录放置配置文件来实现隔离。

这里要特别提醒一个多项目混用时的坑：不要把项目A的CLAUDE.md内容带到项目B。Claude Code是支持工作目录感知的，它会自动读取当前所在项目的记忆文件，但如果你在启动会话时没有进入正确的目录，它可能读取的是全局配置或者上一个项目的残留。我习惯在每个项目目录下单独维护Ctrl类配置文件，并固定从项目根目录启动会话。

多项目模式下，我推荐的配置策略是：

全局配置管共性，项目配置管个性。这样既能保持统一使用体验，又能让每个项目拥有独立的记忆与技能体系。

4. 三环迭代法：把每一次编码变成下一轮的素材

当你把环境搭好、记忆层的载体建好，真正有意思的部分就来了：如何设计这个“持续学习”的闭环。我自己的实践是分成三个环，从小到大，每一环都在为下一环输送素材。

4.1 第一环：会话内闭环——把错误修复过程写回上下文

第一环发生在单次会话内部。Claude Code在对话过程中其实是有上下文窗口的，窗口内它能记住前面聊过的内容。但窗口有限，长时间任务跑下来，前面的细节可能被挤出去。

会话内闭环的关键操作是：在长时间任务中设置检查点。我常用一个指令模板：

当前任务已经完成到XX阶段。请总结一下这个阶段的产出、遇到的问题、解决方案， 并整理为简短摘要，供后续步骤参考。摘要格式：做了什么/怎么做的/遇到什么问题/如何解决。

这个总结动作的效果，是把散落在上下文中的过程信息压缩成精炼结论。即使后面上下文被新的内容占据，核心信息还在。相当于你在对话中不断写“会议纪要”。

另一个会话内闭环的好时机是修复错误之后。Claude Code修完一个bug，你多追问一句：“这个问题产生的根因是什么？以后怎么避免？请把结论追加到项目记忆文件中。”这一句追问，就能把修复经验固化下来。

4.2 第二环：会话间闭环——构建可复用的笔记与日志

第二环是跨会话的。核心是建立可检索的决策日志。

我会在项目docs目录下维护一个ai-log.md文件，记录每一次与Claude Code协作产生的关键结论。格式很简单：

## 2025-06-12 处理订单状态并发更新问题 - 现象：并发扣减库存时出现超卖 - 根因：事务隔离级别配置不当，库存更新不是原子操作 - 方案：改用数据库行级锁 + 乐观锁版本号 - 后续注意：新增涉及库存的操作时，务必检查并发控制

这个日志的价值在于：下次遇到类似问题时，你不再需要把完整上下文从零复述给Claude Code，而是直接告诉它“看ai-log.md里6月12日那条记录”，它立刻就知道问题的历史背景。这比任何代码注释都更直接。

更进阶的做法是让Claude Code自己维护这个日志。每次任务结束，你指令它检查本次会话有没有值得记录的新结论，有则追加写入，没有则跳过。这样做了一段时间之后，这个日志就成了项目的“踩坑百科”，也是Claudeception循环里最核心的资产。

4.3 第三环：跨项目闭环——沉淀属于自己的"编码守则"

第三环跳出单个项目，沉淀的是个人或团队的通用编码守则。我在用户级记忆文件里保存了一套自己的编码偏好，不针对某个具体项目，而是跨项目通用的：

• 后端接口一律返回统一响应结构
• 前端组件优先使用函数组件和Hooks
• 日志必须包含请求ID用于链路追踪
• 所有时间字段统一用ISO 8601格式存储
• 数据库表名一律小写下划线风格

这套守则沉淀下来之后，Claude Code不管在哪个项目里帮工，都会按这套偏好产出代码。它的来源，正是前两个环节积累的经验。比如我在某个项目里发现时间字段用时间戳存储导致跨时区解析困难，这个结论就会提炼成“时间字段统一用ISO 8601”写进守则。

跨项目闭环的意义在于，持续学习能力不再绑定某一个代码库。你换新项目、接新团队时，Claude Code随身带着你的编码风格和经验判断，降低的不仅是沟通成本，还有整个团队的磨合成本。

5. 大代码库与真实项目中的"Claudeception"实践

记忆层和迭代闭环讲通了，但真实项目永远比理想模型复杂。尤其是大型代码库、资源受限的嵌入式项目、还有多工具协同的场景，都会给这个循环带来新的考验。这一章我挑几个代表性场景展开。

5.1 从Java/STM32到巨型仓库：任务拆分与上下文管理

处理大型代码库，Claude Code最怕的一件事是**“一口吃成胖子”**。你把整个仓库的代码丢给它，让它“理解整个系统然后给我重构”绝对是灾难。上下文塞爆不说，真正关键的信息反而被海量代码冲淡。

我的经验是严格执行**“小步任务拆分”**策略。Claudeception的记忆机制正好配合这个策略：每个小任务的结论写回记忆文件，下个小任务从记忆文件读取进展，就像接力跑一样，一棒一棒传递。

接Java项目时，比如要新增一个订单导出功能，我不会直接让它生成全部代码。而是拆成四步：

1. 读取现有订单查询Service实现，理解数据模型。
2. 编写导出工具类，确认依赖已有的Excel处理库。
3. 在Controller层新增导出端点，参照现有接口的响应格式。
4. 编写单元测试，覆盖空数据和大数据量两个边界。

每一步执行完，要求Claude Code把产出和结论更新到项目记忆。这样进入下一步时，它不需要重新探索目录结构，直接基于上一步的结论继续干活。

对于STM32这类嵌入式项目，情况更特殊。嵌入式代码仓库通常混杂着芯片厂商的HAL库、业务驱动、协议栈，代码量未必大，但耦合度高。我建议让Claude Code先读芯片参考手册要点和现有驱动接口清单，然后再做业务逻辑开发。嵌入式项目里硬件约束杂、寄存器操作多，Claudeception的重点不是让AI自己探索芯片寄存器，而是把人工读手册得到的结论整理成记忆，供AI复用。这本质上是把人的经验通过记忆文件转移给AI。

5.2 用版本控制辅助AI学习：让每次diff都成为教材

Claudeception还有一个容易被忽略的素材来源：Git历史。

每次Claude Code生成的代码经过评审、修改、合并后，Git提交记录和最终diff就是一份高质量的“正确答案”。用这些历史数据反馈给Claude Code，能显著提升它对项目风格的理解。我的操作方法是：

在CLAUDE.md中加一节“参考实现”：

## 参考实现 - 订单分页查询的推荐写法：参见 `order-service` 模块 2025-06-10 提交 - 统一异常处理的实现：参见 `common` 模块最新提交

这样Claude Code在生成类似功能时，会先去翻看对应的历史提交，理解团队认可的实现方式，而不是凭空发挥。这相当于拿团队的历史代码库作为它的学习语料，而它产出的新代码，经过评审合并后，又成为新的历史。这个循环一旦转起来，AI产出会越来越贴合团队风格。

5.3 从VSCode/桌面端到CLI：协作形态的选择

Claude Code的使用形态很多：纯CLI交互、VSCode插件内嵌、桌面版独立窗口。不同形态对Claudeception闭环的影响不大，因为记忆文件是共享的，但你得注意操作节奏的差异。

CLI形态适合批量任务和管道化操作。我可以写脚本批量调用Claude Code处理多个文件的代码风格统一，输出结果直接写回项目。VSCode插件形态适合边写边审。我改完代码让插件即时检查、即时出建议，交互阻力最小。桌面版适合长任务监理。开一个独立窗口，让它跑一个大重构任务，随时查看过程日志。

我个人最常用的是VSCode插件。它的上下文能自动感知当前打开的文件，这意味着Claude Code不需要额外指定就知道你在处理哪个模块。这个特性对Claudeception非常友好，因为记忆文件里的条目可以和具体文件对应起来，触发时精准命中。

6. 常见报错与稳定性问题：别让学习循环断在半路

Claudeception最怕“循环断掉”——环境崩了、配置丢了、记忆文件误删了，之前积累的资产全部归零。所以稳定性和容错这块，值得单独讲一节。

6.1 安装与启动阶段的典型错误

安装阶段除了前面提到的Windows网络错误，还有几类高频问题：

"your organization has disabled claude subscription access"这类提示，属于账户订阅策略限制。这种情况说明你当前使用的账号或组织没有开通对应使用权限。处理方式是联系你们组织的管理员，确认订阅配置，而不是试图绕过限制。管理员在后台调整策略后，重启工具通常就能恢复。

".exe与64位版本Windows不兼容"这一类问题，多半是下载安装包时拿错了架构版本。检查系统架构确认下载包匹配，或者改走npm通道安装，基本都能解决。

Mac与Ubuntu平台的问题相对少，但Ubuntu下常见的是Node.js安装路径不在PATH里。用apt安装Node后，npm全局包的bin目录有时不在终端搜索路径中，执行source ~/.bashrc或手动配置PATH即可。

6.2 运行期的上下文溢出、订阅限制与本地模型替换

运行期最影响Claudeception循环稳定性的，是上下文溢出。Claude Code号称支持很大的上下文长度，但项目记忆文件写得越长、Skill定义越多，实际可用上下文就越少。我遇到过一次CLAUDE.md写了两千多行，结果工具加载它就要接近模型处理上限，真正干活的空间被挤压殆尽。

处理这个问题的方法是分层裁剪。CLAUDE.md只保留最核心的内容：技术栈、命令、不可违背的规范。次要信息拆到独立文档里，在需要时通过指令让Claude Code读取。比如我在CLAUDE.md里只写“接口设计规范见docs/api-conventions.md”，而不是把整个接口规范贴进去。

另外一个运行期注意点是长会话的收敛性。Claudeception鼓励在同一个会话里做多步迭代，但会话太长后，AI容易重复之前结论甚至自相矛盾。我设置了一个硬性规则：单个会话内最多包含三个大任务。三个任务结束后，强制开启新会话，让新会话从记忆文件接管进度。这个规则保证了每次会话状态都相对干净，避免递归循环退化。

6.3 误删与混淆：如何备份Claudeception的记忆资产

Claudeception的核心资产是记忆文件、Skill定义、决策日志。这些文件和源码一样需要备份版本管理。

我强烈建议，把CLAUDE.md、技能目录、决策日志全部纳入Git管理。这样每次变更都有提交记录，万一误删或改坏了，可以随时回滚。这里有个容易混淆的点：很多人的CLAUDE.md是Claude自己改的，AI自动更新文件时可能把内容改得不伦不类。所以AI更新记忆文件后的变更，一定要人工审阅再提交。

我的习惯是每周末花十分钟过一遍本周的记忆文件变更。看有没有AI自己编造的内容、有没有过时的信息、有没有冗余条目。这个“每周人工复核”步骤，是整个Claudeception循环中唯一不能省略的人工环节。它保证AI的自我学习不会跑偏。

7. 停止"无意义的自我复制"：持续学习的边界

最后谈一个很多人忽略的问题：持续学习不是无脑地让AI把所有内容都记住。学习要有边界，否则记忆文件会变成一个臃肿的“文件堆”，对后续任务的指导意义反而下降。

7.1 什么时候该让AI自己学习，什么时候必须手动介入

我总结了一套判断标准：

适合让AI自主沉淀的内容：事实性、确定性信息，比如命令、代码规范、目录结构、依赖关系、一次修必胜的bug结论。这类内容风险低，AI总结准确度很高。

必须人工介入的内容：架构层面的技术选型决策、涉及业务规则的实现细节、团队协作约定。这类内容需要判断能力和业务理解，AI插手的风险在于它可能把“一个想法”当成“既定事实”写进记忆文件。

举个具体的例子：让Claude Code记录“订单模块的数据库表结构”它完全能胜任；但如果让它自行决定“订单模块应该采用哪种分库分表方案”并且写入记忆，就很危险。前者是记录事实，后者是做决策。

7.2 避免"递归中毒"：给自我改进设置护栏

所谓递归中毒，是指自我学习的循环中混入了错误信息，导致后续环节在错误基础上继续加工错误，越滚越大。这其实和过拟合有相似之处——AI过于依赖之前记录的经验，反而失去了对当前任务本身的客观判断。

防止递归中毒，我用了三副护栏：

1. 经验来源可溯。决策日志里每条结论必须标注来源场景和日期，不允许出现无出处、无日期的泛化结论。这样任何一条经验都可以追溯到具体上下文，便于核验。
2. 定期“忘记”机制。每过一段时间，主动删掉那些已经被代码库自然取代的记忆条目。比如某个模块已经被重构掉，相关的旧经验就不再适用，保留在记忆文件里只会误导后续任务。
3. 回归测试兜底。Claudeception产出的代码质量最终要靠测试来验证。每次AI更新代码后跑一遍全量测试，测试不通过时，AI生成的“经验沉淀”优先级一律让位于测试结论。

我还在项目里设置了一个被戏称为“镜子时间”的固定动作。每周挑一个任务，让Claude Code在完成任务后，额外回答一个问题：“这次完成过程中，哪些沉淀在记忆文件里的经验起到了作用？哪些没有？哪些建议删除？”这个反思性的输出，我会亲自检查，并据此主动修剪记忆文件。

做这一步的目的很直接：持续学习不等于无脑积累，它更像是在给一个聪明的伙伴不断整理工作笔记。笔记记得好，伙伴越干越顺手；笔记记得烂，伙伴就被垃圾信息拖累。你作为主人，始终要握着那支修剪记忆的笔。

Claudeception这套方法，我实践了大概两个月后最明显的感受是：Claude Code不再是那个每次都要重新认识我项目的“新手”了。它对项目的理解、对代码风格的把握、对历史坑点的警觉，都能从记忆文件里得到支撑。而所有这些所谓“学习”，底子其实只有一个朴素的道理——把做过的事情沉淀下来，让下一次做得更好。工具迭代很快，模型替换很频繁，但这份工作方法本身，放在哪个AI编码工具上都成立。