做 AI 编程最容易踩的坑不是模型能力不够而是启动顺序不对。很多人拿到需求的第一反应是打开 Claude Code 说“帮我把代码写出来”。但如果你没有先把 MVP 的边界、Cola 架构的分层约束以及验收标准定下来AI 写得越快后面返工越狠。这篇文章把我实际用 Cola 加 Claude Code 做 MVP 的流程拆开讲重点解决一个问题AI 编程到底应该按什么顺序推进才能从“能跑”走到“能维护”。先说结论AI 编程真正该花时间的部分恰恰是写代码之前的需求定义和架构设计。工具负责执行你负责约束。约束给得越清楚Claude Code 生成代码的准确率和可用性就越高。下面按我实际落地时的顺序拆一遍。1. 为什么“先写代码”在 AI 编程里是最差策略1.1 代码生成快不代表返工成本低Claude Code 这类工具最直观的优势是把“从想法到可运行代码”的时间压缩得很短。一个 CRUD 接口、一个页面、一个脚本几句话就能生成完。但这个速度也容易带来错觉既然生成这么快是不是可以跳过设计直接把需求丢给 AI我见过最多的失败案例恰恰出现在这里。AI 生成的代码“第一版能跑”但它是围绕你当时那句话生成的不是围绕整个项目生成的。等你要加一个状态字段、改一条调用链、换一种存储方式就会发现原来那版代码里几乎没有预留扩展位置。单文件改起来容易跨模块改就是另一个量级的工作量。AI 花 10 分钟写出来的代码你可能要花 3 小时去拆、去理解、去重构。1.2 需求不落地AI 每一步都可能跑偏AI 编程工具不会主动判断需求是否完整。你给一句“做一个订单管理”它只会按自己对订单管理的通用理解生成一套功能。结果往往是字段比你实际需要的多、流程比你预期的复杂、权限和状态转换完全没覆盖。它不是做错了而是因为你没有给约束。所以 AI 编程的第一步不是打开终端而是先写需求。写需求不等于写长篇文档而是要回答四个问题给谁用、处理什么输入、产出什么结果、哪些情况明确不处理。这些约束后面会变成 prompt 里的关键信息也会变成验收时判断代码是否合格的标准。1.3 新会话上下文丢失本质是项目缺少外部记忆Claude Code 在同一个会话里能记住不少上下文但新开会话后之前的对话记忆不会完整保留。实际项目很少能一个会话写完跨会话是常态。这时候如果项目本身没有结构文档、架构说明和任务清单AI 在下一个会话里很容易“失忆”。网上经常有人反馈“新开会话丢失上下文”这不算工具故障而是项目缺少外部化的上下文载体。我自己的做法是所有需要在会话之间传递的信息全部落盘成文件放在项目里。需求说明、架构说明、任务清单、验收标准都是项目的一部分。任何新会话进来只要先读这几个文件就能快速恢复上下文。这个习惯比换工具、换模型更管用。2. MVP 不是“少做功能”而是把边界钉死2.1 先把输入、输出和验收标准写清楚MVPMinimum Viable Product最小可行产品在很多人的理解里是“功能做得少一点”。这个理解不完整。MVP 的核心不是砍功能而是把不确定的部分先砍掉把最核心的业务闭环跑通用最小成本验证核心假设。具体到 AI 编程里MVP 的价值体现在三处一是给 AI 明确的任务边界避免它生成超出范围的功能二是给验收一条清晰标准判断“做完了”到底是什么意思三是给后续迭代留出空间不用在第一版背上全部需求。写需求时至少明确四个要素要素要回答的问题例子使用场景谁在什么情况下用运营人员在后台录入新商品核心输入系统接收什么商品名称、价格、库存、图片 URL核心输出系统返回什么创建成功后的商品 ID 和详情页地址验收标准什么算成功什么算拒绝必填项缺失返回 400正常输入返回商品 ID这四项写清楚比堆砌功能列表重要得多。AI 真正需要的是判断依据而不是功能名词。2.2 用 MVP 矩阵把“做、不做、后置”列出来实操中我会画一张简单的 MVP 矩阵把功能按两个维度放进去一是业务必须程度缺了它流程能不能闭环二是验证价值有了它能不能验证核心假设。然后分成四类P0不做就无法闭环必须进 MVPP1做了能明显提升体验但缺失时还有替代方案P2锦上添花放到二期P3需求模糊、当前不确定先不做。这张矩阵的另一个作用是给 AI 编程提供“拒绝请求”的依据。你明确告诉 Claude Code“只实现 P0P2 不用管”它生成的内容会明显收敛。否则 AI 倾向于给你一个“完整系统”登录、权限、分页、国际化全部一起上代码量直接翻三倍而且大部分是你现在不需要的。2.3 需求文件要短但必须可执行我见过不少团队把需求文档写到几十页结果 AI 编程时根本用不上。原因很简单模型上下文有限长文档里大量的背景介绍、讨论记录、备选方案会把关键信息稀释掉。更好的做法是维护一份 1 到 2 页的核心需求文件只放项目一句话目标、用户与场景、P0/P1/P2/P3 功能清单、关键流程、验收标准。这份文件放在项目根目录比如 REQUIREMENTS.md。Claude Code 每次开工时先让它读取这份文档再动手。实测下来AI 写出的代码第一次就贴近需求的概率会明显提高。这个文件不是写给别人看的是写给 AI 和未来的自己看的。3. Cola 架构给 AI 编程当“骨架”3.1 Cola 的分层思想为什么适合 AI 协作Cola 是阿里巴巴开源的一套应用架构框架COLAClean Object-oriented and Layered Architecture整洁面向对象分层架构。它强调在业务系统里做清晰的层次划分接口层负责接收外部请求应用层负责用例编排领域层承载核心业务规则基础设施层处理数据访问和外部服务。这套思想对 AI 编程的意义不是逼你只能用 Java、只能照搬阿里内部规范而是给你一个“结构模板”。当 AI 生成代码时如果没有结构约束它倾向于把所有逻辑堆在一个文件里。你给它一个分层约定后它就能把代码放回对应的位置。单模块项目里这个差异不明显一旦项目有三个以上模块或者要持续加功能差别会非常大。Claude Code 在明确的分层指引下生成的代码结构会稳定很多。3.2 先定领域对象和状态机再让 AI 动手Cola 生态里有一个组件叫 cola-statemachine专门处理业务状态机。之所以单独提它是因为大量业务系统的复杂度不是来自增删改查而是来自状态流转订单从待支付到已支付、从已支付到已发货每一步都有前置条件和副作用。在让 AI 写代码之前如果能先把状态机定义清楚——有哪些状态、哪些事件触发流转、转换时执行什么操作——后面生成代码会顺很多。Claude Code 在实现明确的“状态列表 事件列表”时准确率很高因为它能直接把这张表转成可执行逻辑。反过来如果这些信息不给它就会自己猜状态和流转规则。猜对算运气猜错就是返工。3.3 没有架构约束时AI 代码会乱成什么样我实际跑过一个对比同一个需求一组直接让 AI 写另一组先给 Cola 风格的分层约束再让 AI 写。第一组代码的特点是接口层里直接写数据库查询、业务层里拼 SQL、工具类里混着参数校验。功能确实能跑但改一个字段要翻三四个文件而且每个文件的职责边界模糊后续会话里的 AI 也没法判断该去哪里改。第二组前期多花了半小时定义分层和状态机但后续每个需求变更AI 都能根据“这次变更属于哪一层”快速定位。代码可读性和可维护性高出一截。结论很直接架构约束不是对 AI 的限制而是对 AI 的保护。你给它稳定的骨架它才能稳定地输出。没有骨架每次生成都是一次碰运气。4. Claude Code 的落地姿势从最小任务开始4.1 环境和第一轮最小验证Claude Code 是 Anthropic 推出的命令行编程助手在终端里运行可以直接读取和修改项目文件也可以执行命令。首次使用前先确认两件事本机 Node.js 环境是否满足要求工具本身是否安装成功。具体安装方式和依赖版本以官方文档为准不同版本可能有差异。装好之后先不要进真实项目。找一个临时目录放一个 README 文件让工具做一次“读文件、改文件、运行命令”的最小循环。这一步的目的不是测功能而是确认环境链路是通的。很多新手直接在大项目里跑报错了就以为是模型问题实际往往出在环境变量、依赖版本、目录权限或模型配置上。先花五分钟跑通最小循环后面排查问题会省大量时间。4.2 用项目说明文件固定长期上下文Claude Code 支持通过 CLAUDE.md 这类项目说明文件注入项目信息。这个文件相当于项目的“长期记忆”每次会话开始时都会被读取。我会在里面写清楚项目是什么、目录结构、技术栈、编码约定、当前进度、已完成和待办。文件放在项目根目录内容控制在两三百行以内以机器能理解、人能维护为标准。正因为新会话会丢上下文项目说明文件才更重要。每次开工前先让工具读取 CLAUDE.md再开始动手。如果项目里还没有这个文件可以让工具先生成一版再手工补充项目特有约定。我见过很多团队把上下文寄托在模型记忆上换一个会话就断片最后整个项目越写越乱。文件才是真正可靠的上下文。一个简化示例# 项目商品管理系统 ## 技术栈 - 后端Java 17 Spring Boot 3.x - 数据库MySQL 8.x - 架构COLA 分层接口层 / 应用层 / 领域层 / 基础设施层 ## 目录结构 - controller外部接口 - application用例编排 - domain领域模型与状态机 - infrastructure数据访问与外部服务 ## 当前进度 - 已完成商品创建接口P0 - 进行中商品状态流转 - 待办库存扣减4.3 一个会话只做一个任务输出以文件为准我自己的习惯是一个会话只做一件相对独立的事。比如“实现订单创建接口”“完成用户列表页前端交互”“修复登录接口空指针”。这样每个会话的上下文足够聚焦AI 不会因为同时维护太多信息而出现遗漏。当一个任务跨多个模块时先在任务清单里把步骤编号第一步定义领域模型第二步生成仓储接口第三步实现应用服务第四步补外部接口。每个会话只推进一到两个步骤。前一步的输出必须落盘成文件后一个会话再读取。文件本身就是上下文传递的桥梁比依赖模型记忆可靠得多。你会发现虽然前期节奏慢了一点但整体返工率大幅下降。4.4 权限批准和配置检查Claude Code 在运行时会请求各种操作权限比如读文件、改文件、执行命令、调用终端。交互窗口里会给出批准提示。这里不要急着全部允许也不要全部拒绝。先让工具做小范围修改人工检查改动内容确认没问题后再放行更大范围的操作。批是这个工具给出的操作流程用键盘就能快速确认。另外如果项目里接入了第三方模型或自定义网关要留意模型名称和工具版本的兼容性。模型标识写错或版本不匹配经常报类似“模型不存在”或“此版本的 Claude Code 无法识别该模型”的提示。遇到这种报错先检查模型名、接口地址、认证信息和版本号多半就能定位。这不算工具故障属于配置层面的排查。5. 一套可复用的 AI 编程工作流5.1 五步工作流需求、架构、拆解、编码、验证把前面几部分串起来我实际使用的 AI 编程工作流是五步写需求文件定义 MVP 边界和验收标准定架构骨架明确分层和领域对象有状态流转就画状态机拆任务清单把 MVP 拆成多个可独立验证的小任务用 Claude Code 逐个实现每步检查改动和运行结果按验收标准测试通过后再进入下一个任务。前两步看起来和“AI 编程”没关系但它们恰恰决定后三步的效率。需求写不清楚AI 生成的代码就会偏架构没定代码就会乱任务没拆一个会话塞太多内容就会丢上下文。这套顺序适合从零开始的新项目也适合给现有项目加功能。核心思想一致先让 AI 理解边界再让它写代码。5.2 示例 prompt给 AI 验收标准而不是只给功能名给 Claude Code 下任务时最忌讳只写一句“帮我实现订单模块”。更好的格式是分块描述背景项目是商品管理系统需求文件见 REQUIREMENTS.md架构约束见 CLAUDE.md。 任务实现订单创建接口对应用例编号 UC-01。 约束 - 只修改应用层和接口层不动领域层 - 订单状态初始值必须是“待支付” - 创建成功后写入订单表和订单明细表使用同一事务。 验收 - 输入合法创建请求返回订单 ID - 商品库存不足时返回明确错误码 - 必填参数缺失返回 400 和错误说明。 完成标志相关测试通过且不影响已有商品创建接口。把验收标准写进 prompt是减少返工最有效的手段。AI 不需要你反复交代“怎么做”但需要你明确“什么算对”。这两者之间有本质区别。你给的是判断标准它输出时就会自动往这个标准靠拢。5.3 MVP 跑通后怎么迭代MVP 跑通之后再进入迭代阶段。这时候的节奏和前期不一样每次迭代只选一个 P1 功能先更新需求文件再更新任务清单最后才让 AI 写代码。关键点是保持需求文件、架构文件、任务清单和代码四者同步。如果发现 AI 改代码时频繁破坏已有功能不要急着怀疑模型能力先检查四者是否同步。需求文件里已经删掉的字段代码里还留着架构文件里已经改成的事件状态机里还是旧逻辑。这些不一致才是项目混乱的根源。AI 编程工具本身没有“项目全局意识”它每一次都只按当前输入和项目文件里的信息执行。项目文件不一致它就会照着旧信息改出新问题。6. 常见报错和排查顺序6.1 把问题分成三类起不来、写不对、跑了挂做 AI 编程遇到问题先分类别急着改代码。我一般把问题分成三类工具起不来安装失败、命令找不到、登录或订阅权限被限制代码写不对生成内容不符合需求、逻辑遗漏、格式错代码跑了挂编译错误、运行时报错、接口测试失败。分类的作用是确定排查方向。起不来的问题十有八九是环境或权限写不对的问题大概率是需求描述和上下文不足跑了挂的问题要先看代码改动范围再决定是修代码还是回滚。6.2 优先排查环境、模型配置、上下文三件事按我自己的经验以下三类原因占了大多数问题。第一环境不一致。Node.js 版本、依赖包版本、系统权限、网络环境都可能影响工具行为。遇到报错时先把报错信息里的关键段复制出来搜索再对照本机环境逐项检查。不要凭感觉卸载重装那样经常越搞越糟。第二模型名称或配置错误。如果你使用了第三方模型、自定义网关或代理配置要确认模型标识、接口地址、认证信息和工具版本完全匹配。报“模型不存在”“版本无法识别”时优先检查配置而不是怀疑工具坏了。第三上下文和输入格式问题。Claude Code 读不到文件、读错文件、输出路径不对多数是因为没有在 prompt 里明确文件路径或者项目文件本身组织混乱。把需求文件、架构文件放在固定位置并在 prompt 里明确指向能减少大量这类问题。6.3 多会话协作用文件代替模型记忆如果你的项目需要多个会话协作建议从第一天就建立“输出即文件”的习惯。每个会话结束前必须产出一个可落盘的结果新写的代码、修改记录、补充的约束、遗留的风险。新会话开始时先让工具读取这些文件再开始新任务。这样即使某个会话丢了上下文项目本身也没有丢。我也建议定期让 Claude Code 把项目当前状态整理成一个进度文件包含已完成、进行中、待办、风险四部分。这个文件既是下一次会话的输入也是你判断项目健康度的依据。AI 编程不是一个人跟一个工具的对话而是一个团队围绕一套文件在协作。文件组织得清楚效率才会有质的提升。最后留一个我自己的判断标准如果你的 AI 编程项目已经改了三轮需求代码还没有乱成一团说明前面的 MVP 边界、架构约束和任务拆解做得是对的。如果已经乱了回到需求文件和架构文件把边界重新钉一遍再让 Claude Code 继续动手。先定骨架再填肉这就是 AI 编程最值得坚持的顺序。
做 AI 编程最容易踩的坑不是模型能力不够而是启动顺序不对。很多人拿到需求的第一反应是打开 Claude Code 说“帮我把代码写出来”。但如果你没有先把 MVP 的边界、Cola 架构的分层约束以及验收标准定下来AI 写得越快后面返工越狠。这篇文章把我实际用 Cola 加 Claude Code 做 MVP 的流程拆开讲重点解决一个问题AI 编程到底应该按什么顺序推进才能从“能跑”走到“能维护”。先说结论AI 编程真正该花时间的部分恰恰是写代码之前的需求定义和架构设计。工具负责执行你负责约束。约束给得越清楚Claude Code 生成代码的准确率和可用性就越高。下面按我实际落地时的顺序拆一遍。1. 为什么“先写代码”在 AI 编程里是最差策略1.1 代码生成快不代表返工成本低Claude Code 这类工具最直观的优势是把“从想法到可运行代码”的时间压缩得很短。一个 CRUD 接口、一个页面、一个脚本几句话就能生成完。但这个速度也容易带来错觉既然生成这么快是不是可以跳过设计直接把需求丢给 AI我见过最多的失败案例恰恰出现在这里。AI 生成的代码“第一版能跑”但它是围绕你当时那句话生成的不是围绕整个项目生成的。等你要加一个状态字段、改一条调用链、换一种存储方式就会发现原来那版代码里几乎没有预留扩展位置。单文件改起来容易跨模块改就是另一个量级的工作量。AI 花 10 分钟写出来的代码你可能要花 3 小时去拆、去理解、去重构。1.2 需求不落地AI 每一步都可能跑偏AI 编程工具不会主动判断需求是否完整。你给一句“做一个订单管理”它只会按自己对订单管理的通用理解生成一套功能。结果往往是字段比你实际需要的多、流程比你预期的复杂、权限和状态转换完全没覆盖。它不是做错了而是因为你没有给约束。所以 AI 编程的第一步不是打开终端而是先写需求。写需求不等于写长篇文档而是要回答四个问题给谁用、处理什么输入、产出什么结果、哪些情况明确不处理。这些约束后面会变成 prompt 里的关键信息也会变成验收时判断代码是否合格的标准。1.3 新会话上下文丢失本质是项目缺少外部记忆Claude Code 在同一个会话里能记住不少上下文但新开会话后之前的对话记忆不会完整保留。实际项目很少能一个会话写完跨会话是常态。这时候如果项目本身没有结构文档、架构说明和任务清单AI 在下一个会话里很容易“失忆”。网上经常有人反馈“新开会话丢失上下文”这不算工具故障而是项目缺少外部化的上下文载体。我自己的做法是所有需要在会话之间传递的信息全部落盘成文件放在项目里。需求说明、架构说明、任务清单、验收标准都是项目的一部分。任何新会话进来只要先读这几个文件就能快速恢复上下文。这个习惯比换工具、换模型更管用。2. MVP 不是“少做功能”而是把边界钉死2.1 先把输入、输出和验收标准写清楚MVPMinimum Viable Product最小可行产品在很多人的理解里是“功能做得少一点”。这个理解不完整。MVP 的核心不是砍功能而是把不确定的部分先砍掉把最核心的业务闭环跑通用最小成本验证核心假设。具体到 AI 编程里MVP 的价值体现在三处一是给 AI 明确的任务边界避免它生成超出范围的功能二是给验收一条清晰标准判断“做完了”到底是什么意思三是给后续迭代留出空间不用在第一版背上全部需求。写需求时至少明确四个要素要素要回答的问题例子使用场景谁在什么情况下用运营人员在后台录入新商品核心输入系统接收什么商品名称、价格、库存、图片 URL核心输出系统返回什么创建成功后的商品 ID 和详情页地址验收标准什么算成功什么算拒绝必填项缺失返回 400正常输入返回商品 ID这四项写清楚比堆砌功能列表重要得多。AI 真正需要的是判断依据而不是功能名词。2.2 用 MVP 矩阵把“做、不做、后置”列出来实操中我会画一张简单的 MVP 矩阵把功能按两个维度放进去一是业务必须程度缺了它流程能不能闭环二是验证价值有了它能不能验证核心假设。然后分成四类P0不做就无法闭环必须进 MVPP1做了能明显提升体验但缺失时还有替代方案P2锦上添花放到二期P3需求模糊、当前不确定先不做。这张矩阵的另一个作用是给 AI 编程提供“拒绝请求”的依据。你明确告诉 Claude Code“只实现 P0P2 不用管”它生成的内容会明显收敛。否则 AI 倾向于给你一个“完整系统”登录、权限、分页、国际化全部一起上代码量直接翻三倍而且大部分是你现在不需要的。2.3 需求文件要短但必须可执行我见过不少团队把需求文档写到几十页结果 AI 编程时根本用不上。原因很简单模型上下文有限长文档里大量的背景介绍、讨论记录、备选方案会把关键信息稀释掉。更好的做法是维护一份 1 到 2 页的核心需求文件只放项目一句话目标、用户与场景、P0/P1/P2/P3 功能清单、关键流程、验收标准。这份文件放在项目根目录比如 REQUIREMENTS.md。Claude Code 每次开工时先让它读取这份文档再动手。实测下来AI 写出的代码第一次就贴近需求的概率会明显提高。这个文件不是写给别人看的是写给 AI 和未来的自己看的。3. Cola 架构给 AI 编程当“骨架”3.1 Cola 的分层思想为什么适合 AI 协作Cola 是阿里巴巴开源的一套应用架构框架COLAClean Object-oriented and Layered Architecture整洁面向对象分层架构。它强调在业务系统里做清晰的层次划分接口层负责接收外部请求应用层负责用例编排领域层承载核心业务规则基础设施层处理数据访问和外部服务。这套思想对 AI 编程的意义不是逼你只能用 Java、只能照搬阿里内部规范而是给你一个“结构模板”。当 AI 生成代码时如果没有结构约束它倾向于把所有逻辑堆在一个文件里。你给它一个分层约定后它就能把代码放回对应的位置。单模块项目里这个差异不明显一旦项目有三个以上模块或者要持续加功能差别会非常大。Claude Code 在明确的分层指引下生成的代码结构会稳定很多。3.2 先定领域对象和状态机再让 AI 动手Cola 生态里有一个组件叫 cola-statemachine专门处理业务状态机。之所以单独提它是因为大量业务系统的复杂度不是来自增删改查而是来自状态流转订单从待支付到已支付、从已支付到已发货每一步都有前置条件和副作用。在让 AI 写代码之前如果能先把状态机定义清楚——有哪些状态、哪些事件触发流转、转换时执行什么操作——后面生成代码会顺很多。Claude Code 在实现明确的“状态列表 事件列表”时准确率很高因为它能直接把这张表转成可执行逻辑。反过来如果这些信息不给它就会自己猜状态和流转规则。猜对算运气猜错就是返工。3.3 没有架构约束时AI 代码会乱成什么样我实际跑过一个对比同一个需求一组直接让 AI 写另一组先给 Cola 风格的分层约束再让 AI 写。第一组代码的特点是接口层里直接写数据库查询、业务层里拼 SQL、工具类里混着参数校验。功能确实能跑但改一个字段要翻三四个文件而且每个文件的职责边界模糊后续会话里的 AI 也没法判断该去哪里改。第二组前期多花了半小时定义分层和状态机但后续每个需求变更AI 都能根据“这次变更属于哪一层”快速定位。代码可读性和可维护性高出一截。结论很直接架构约束不是对 AI 的限制而是对 AI 的保护。你给它稳定的骨架它才能稳定地输出。没有骨架每次生成都是一次碰运气。4. Claude Code 的落地姿势从最小任务开始4.1 环境和第一轮最小验证Claude Code 是 Anthropic 推出的命令行编程助手在终端里运行可以直接读取和修改项目文件也可以执行命令。首次使用前先确认两件事本机 Node.js 环境是否满足要求工具本身是否安装成功。具体安装方式和依赖版本以官方文档为准不同版本可能有差异。装好之后先不要进真实项目。找一个临时目录放一个 README 文件让工具做一次“读文件、改文件、运行命令”的最小循环。这一步的目的不是测功能而是确认环境链路是通的。很多新手直接在大项目里跑报错了就以为是模型问题实际往往出在环境变量、依赖版本、目录权限或模型配置上。先花五分钟跑通最小循环后面排查问题会省大量时间。4.2 用项目说明文件固定长期上下文Claude Code 支持通过 CLAUDE.md 这类项目说明文件注入项目信息。这个文件相当于项目的“长期记忆”每次会话开始时都会被读取。我会在里面写清楚项目是什么、目录结构、技术栈、编码约定、当前进度、已完成和待办。文件放在项目根目录内容控制在两三百行以内以机器能理解、人能维护为标准。正因为新会话会丢上下文项目说明文件才更重要。每次开工前先让工具读取 CLAUDE.md再开始动手。如果项目里还没有这个文件可以让工具先生成一版再手工补充项目特有约定。我见过很多团队把上下文寄托在模型记忆上换一个会话就断片最后整个项目越写越乱。文件才是真正可靠的上下文。一个简化示例# 项目商品管理系统 ## 技术栈 - 后端Java 17 Spring Boot 3.x - 数据库MySQL 8.x - 架构COLA 分层接口层 / 应用层 / 领域层 / 基础设施层 ## 目录结构 - controller外部接口 - application用例编排 - domain领域模型与状态机 - infrastructure数据访问与外部服务 ## 当前进度 - 已完成商品创建接口P0 - 进行中商品状态流转 - 待办库存扣减4.3 一个会话只做一个任务输出以文件为准我自己的习惯是一个会话只做一件相对独立的事。比如“实现订单创建接口”“完成用户列表页前端交互”“修复登录接口空指针”。这样每个会话的上下文足够聚焦AI 不会因为同时维护太多信息而出现遗漏。当一个任务跨多个模块时先在任务清单里把步骤编号第一步定义领域模型第二步生成仓储接口第三步实现应用服务第四步补外部接口。每个会话只推进一到两个步骤。前一步的输出必须落盘成文件后一个会话再读取。文件本身就是上下文传递的桥梁比依赖模型记忆可靠得多。你会发现虽然前期节奏慢了一点但整体返工率大幅下降。4.4 权限批准和配置检查Claude Code 在运行时会请求各种操作权限比如读文件、改文件、执行命令、调用终端。交互窗口里会给出批准提示。这里不要急着全部允许也不要全部拒绝。先让工具做小范围修改人工检查改动内容确认没问题后再放行更大范围的操作。批是这个工具给出的操作流程用键盘就能快速确认。另外如果项目里接入了第三方模型或自定义网关要留意模型名称和工具版本的兼容性。模型标识写错或版本不匹配经常报类似“模型不存在”或“此版本的 Claude Code 无法识别该模型”的提示。遇到这种报错先检查模型名、接口地址、认证信息和版本号多半就能定位。这不算工具故障属于配置层面的排查。5. 一套可复用的 AI 编程工作流5.1 五步工作流需求、架构、拆解、编码、验证把前面几部分串起来我实际使用的 AI 编程工作流是五步写需求文件定义 MVP 边界和验收标准定架构骨架明确分层和领域对象有状态流转就画状态机拆任务清单把 MVP 拆成多个可独立验证的小任务用 Claude Code 逐个实现每步检查改动和运行结果按验收标准测试通过后再进入下一个任务。前两步看起来和“AI 编程”没关系但它们恰恰决定后三步的效率。需求写不清楚AI 生成的代码就会偏架构没定代码就会乱任务没拆一个会话塞太多内容就会丢上下文。这套顺序适合从零开始的新项目也适合给现有项目加功能。核心思想一致先让 AI 理解边界再让它写代码。5.2 示例 prompt给 AI 验收标准而不是只给功能名给 Claude Code 下任务时最忌讳只写一句“帮我实现订单模块”。更好的格式是分块描述背景项目是商品管理系统需求文件见 REQUIREMENTS.md架构约束见 CLAUDE.md。 任务实现订单创建接口对应用例编号 UC-01。 约束 - 只修改应用层和接口层不动领域层 - 订单状态初始值必须是“待支付” - 创建成功后写入订单表和订单明细表使用同一事务。 验收 - 输入合法创建请求返回订单 ID - 商品库存不足时返回明确错误码 - 必填参数缺失返回 400 和错误说明。 完成标志相关测试通过且不影响已有商品创建接口。把验收标准写进 prompt是减少返工最有效的手段。AI 不需要你反复交代“怎么做”但需要你明确“什么算对”。这两者之间有本质区别。你给的是判断标准它输出时就会自动往这个标准靠拢。5.3 MVP 跑通后怎么迭代MVP 跑通之后再进入迭代阶段。这时候的节奏和前期不一样每次迭代只选一个 P1 功能先更新需求文件再更新任务清单最后才让 AI 写代码。关键点是保持需求文件、架构文件、任务清单和代码四者同步。如果发现 AI 改代码时频繁破坏已有功能不要急着怀疑模型能力先检查四者是否同步。需求文件里已经删掉的字段代码里还留着架构文件里已经改成的事件状态机里还是旧逻辑。这些不一致才是项目混乱的根源。AI 编程工具本身没有“项目全局意识”它每一次都只按当前输入和项目文件里的信息执行。项目文件不一致它就会照着旧信息改出新问题。6. 常见报错和排查顺序6.1 把问题分成三类起不来、写不对、跑了挂做 AI 编程遇到问题先分类别急着改代码。我一般把问题分成三类工具起不来安装失败、命令找不到、登录或订阅权限被限制代码写不对生成内容不符合需求、逻辑遗漏、格式错代码跑了挂编译错误、运行时报错、接口测试失败。分类的作用是确定排查方向。起不来的问题十有八九是环境或权限写不对的问题大概率是需求描述和上下文不足跑了挂的问题要先看代码改动范围再决定是修代码还是回滚。6.2 优先排查环境、模型配置、上下文三件事按我自己的经验以下三类原因占了大多数问题。第一环境不一致。Node.js 版本、依赖包版本、系统权限、网络环境都可能影响工具行为。遇到报错时先把报错信息里的关键段复制出来搜索再对照本机环境逐项检查。不要凭感觉卸载重装那样经常越搞越糟。第二模型名称或配置错误。如果你使用了第三方模型、自定义网关或代理配置要确认模型标识、接口地址、认证信息和工具版本完全匹配。报“模型不存在”“版本无法识别”时优先检查配置而不是怀疑工具坏了。第三上下文和输入格式问题。Claude Code 读不到文件、读错文件、输出路径不对多数是因为没有在 prompt 里明确文件路径或者项目文件本身组织混乱。把需求文件、架构文件放在固定位置并在 prompt 里明确指向能减少大量这类问题。6.3 多会话协作用文件代替模型记忆如果你的项目需要多个会话协作建议从第一天就建立“输出即文件”的习惯。每个会话结束前必须产出一个可落盘的结果新写的代码、修改记录、补充的约束、遗留的风险。新会话开始时先让工具读取这些文件再开始新任务。这样即使某个会话丢了上下文项目本身也没有丢。我也建议定期让 Claude Code 把项目当前状态整理成一个进度文件包含已完成、进行中、待办、风险四部分。这个文件既是下一次会话的输入也是你判断项目健康度的依据。AI 编程不是一个人跟一个工具的对话而是一个团队围绕一套文件在协作。文件组织得清楚效率才会有质的提升。最后留一个我自己的判断标准如果你的 AI 编程项目已经改了三轮需求代码还没有乱成一团说明前面的 MVP 边界、架构约束和任务拆解做得是对的。如果已经乱了回到需求文件和架构文件把边界重新钉一遍再让 Claude Code 继续动手。先定骨架再填肉这就是 AI 编程最值得坚持的顺序。
