企业官网建设流程全解析

1. 这半年我到底拿 AI 做了什么，以及为什么说是"真实项目"

先交代一下背景。过去半年，我在一个持续迭代的内部业务系统上重度使用 AI 辅助编码。这个系统不是玩具 Demo，不是算法刷题，而是有真实用户、有历史包袱、有上线压力的项目——涉及几十张数据表、权限模型、审批流、消息通知、报表导出，还有一堆没法轻易重构的老接口。我选择在这个项目上长期测试 AI 编码工具，就是想回答一个很多人问过我、也问过自己的问题：AI 写代码到底靠不靠谱？

先说结论：靠谱，但靠谱的方式可能和你想的不一样。它不是"你把需求说完，它把系统写完"那种靠谱，也不是"它能解决所有 bug"那种靠谱。真正靠谱的地方在于——帮你把重复劳动的体力活基本消灭掉，把有难度的部分重新变成有创造性的协作过程。它在 CRUD 接口、单元测试、正则表达式、配置脚本、胶水代码这些场景下，效率提升是实打实的；在复杂的领域逻辑、跨模块状态流转、老代码兼容这些问题上，它会给你一个不错的起点，但离"直接可用"还差很远。

这半年我大致统计了一下，在保证代码质量、不降低测试覆盖率的前提下，纯编码时间大概省了四成左右。注意，我说的是"编码时间"，不是"项目总时间"。因为 AI 生成的代码多了之后，Code Review 的工作量会明显上升，排查问题的上下文切换也变多了，只看表面的话，省下的时间会被这些环节吃掉一部分。

这篇文章不是来吹 AI 编码的，也不是来泼冷水的。我会把这半年的真实用法、踩过的坑、总结出的判断标准全部摊开讲。如果你也在纠结要不要在团队里引入 AI 辅助编码，或者已经在用但总感觉"哪里不对劲"，那这篇应该能给你一些超出直觉的参考。

1.1 为什么选择这个项目作为测试场

选项目很关键。如果你拿一个绿地的、没有任何历史包袱的新项目去测 AI 编码，得出的结论会偏乐观，因为所有代码都是干干净净的，AI 给出的方案大概率是整个代码库里最"标准"的写法。而真实世界全是脏代码：老表结构字段命名混乱、历史接口不敢随便动、业务规则散落在各个 service 里。

我选的这个业务系统，恰好同时具备三个特征：第一，有相当比例的增删改查，二，有几个复杂的核心流程（比如审批流和计费逻辑），第三，有大量历史代码需要适配。这三个特征基本能覆盖大多数后台管理类项目的真实情况。

结果也很有意思：凡是接口定义清晰、数据模型明确的模块，AI 的完成度非常高；凡是业务规则含糊、历史行为依赖强的模块，AI 给的东西几乎都不能直接用，甚至会让问题更复杂。所以我后来总结出一条经验，那就是 AI 编码能力更像是"超级加速器 + 超级实习生"，加速器体现在标准化部分，实习生的水平体现在不确定部分。你什么时候该用加速器，什么时候该把实习生叫停，这才是真正的核心技能。

2. 我用 AI 写代码的三种工作模式，以及各自的效率真相

这半年我并不是只用一种方式和 AI 合作，而是根据任务类型切换了三种模式。很多反馈说"AI 不好用"的人，往往是只用了一种方式去套所有任务，自然得出很片面的结论。实际上，模式选对了，效率翻倍；选错了，心态崩盘。

2.1 模式一：自然语言描述需求，让 AI 直接生成代码

这是大多数人最先尝试的方式。你在对话窗口里描述"帮我写一个分页查询用户列表的接口，支持按用户名模糊搜索、按状态筛选，返回结果里除了用户基本信息还要带上最近一次登录时间"，然后看 AI 输出一串代码。把它拷贝到项目里，运气好的话能跑通，运气不好就需要来回纠错。

我用下来，这个模式最适合以下类型：

• 独立的、边界清晰的通用函数或工具类，比如日期处理、字符串加密、文件解析、数据脱敏等接口定义得比较清晰的代码。
• 标准化的 CRUD 接口，尤其是你们项目里已经有很多类似的先例可以参考。
• 测试代码，特别是单元测试。AI 生成测试用例的速度比人写快太多，而且覆盖路径的全面性往往不错。
• 一次性脚本、数据迁移脚本、格式化工具。
• 原型验证阶段的代码，最快速度看到效果，不追求完美结构。

但在真实业务项目中，这个模式有几个明显的边界。当你给的信息不足时，AI 会自动"脑补"出合理但不符合你项目实际的逻辑。比如它可能默认你的用户表叫 user，而你们项目里实际叫 biz_user_info；它默认用 MyBatis-Plus，而你们项目用的是 JPA；它默认返回结构是 {code, data, msg}，而你们项目的老接口有的是 {success, rows, total}。这些细节才是真正浪费时间的点。

所以后来我调整了用法：如果项目里有现成的接口写法可以作为参照，我会直接在提示词里贴一小段同类代码作为风格锚点；如果领域逻辑复杂，我就先不写代码，而是让 AI 帮我把字段、状态、边界条件全部列出，先做设计再写代码。这个调整让直接生成的可用率从五六成提升到了七八成。

2.2 模式二：人写关键逻辑，AI 负责补全与提速

这个模式是我中期用得最多的。具体做法是：核心算法、核心业务规则、跨模块的流程编排，我自己亲自写；AI 负责把外围的、重复的、机械的部分补全——比如 DTO 的字段映射、VO 的组装、各个状态下的校验规则、异常分支的补全、日志埋点、参数校验、分页封装等。

举个例子，我写了一个核心的库存扣减逻辑，里面涉及超卖判断、多仓库优先级、锁的粒度和事务边界，这部分必须人肉搞清楚。但扣减完之后需要生成库存流水、更新缓存、发送异步通知、写审计日志，这些事情一个比一个枯燥，AI 可以在你给我一个明确的调用位置和数据结构之后，一遍就把这四件事的代码写出来，而且风格基本统一。

这个模式的优势很明显：

• 出错的概率大幅下降，因为 AI 没有碰核心逻辑，只在外围做机械拼接。
• 代码一致性更好，不会出现 A 文件里用 MapStruct，B 文件里手写 getter/setter 的情况。
• 压力最小，因为你始终掌握着系统的关键链路，AI 只是你的高阶辅助。

我后来把这个模式总结成一句话：把 AI 当成一个手速极快、但不太懂行的同事。你负责"做什么"和"为什么"，它负责"快点把这段外壳敲出来"。这句话听起来简单，但真的实践起来，需要很强的自我克制力——很多人写着写着就把核心逻辑也丢给 AI 去发挥了，然后陷入漫长的修补循环。

2.3 模式三：AI 帮我搭骨架，我来填肉

这种模式更适合从零开始搭建一个新模块。比如新做一套"优惠券发放系统"，模块该有哪些表、哪些接口、哪些状态流转，心里大概有个框架，但细节都是空的。

我会先让 AI 基于一个宽泛的描述，生成一个结构化的模块设计——包括实体类的字段建议、表结构的初步设计、核心接口清单、状态机草案、各接口的入参出参结构。然后我来审核和修正这些设计，确定方案后，再让 AI 按模块、按接口逐个生成代码。

这里有个关键点：AI 搭的骨架，不是让你直接往里面填肉的，而是给你一张"可评审的地图"。它的价值在于快速覆盖所有可能性，避免你漏掉某些边界字段或状态。但它生成的字段命名、依赖选择、权限控制方案，十有八九需要按你项目的实际情况调整。

我统计过，用这种方式搭建一个新模块（不含需求分析），从设计确认到接口跑通的整体时间，大概是原先的六成左右。但前提是，我花在评审设计上的时间一点都不能少，甚至更多了。AI 把执行时间压缩之后，你省下来的精力必须转移到思考和审查上，如果你把这部分也省了，后面返工的成本会以指数级翻倍。

2.4 三种模式的效率对照，以及什么场景选什么

这里需要额外强调的是，即便效率提升最明显的场景，也千万不能跳过后面的 Code Review。我刚开始用 AI 生成代码的时候，Review 只花一分钟扫一眼就合进去了，后来线上出过几次问题，都是那种看起来完全合理、边界条件却处理错的代码。从那以后我养成了习惯：AI 生成的代码，Review 的力度只会比人写的更严格，绝不会更宽松。

3. 从"能用"到"好用"的关键：喂给 AI 的上下文才是成败手

很多人说 AI 生成的代码"没法看"，其实一半以上的问题出在输入侧。你给 AI 的信息越含糊，它给出的代码就越"通用"，通用到无法兼容你的项目。这个道理和带新人是一模一样的——你跟一个刚入职的同事只说一句"帮我做个用户管理的接口"，他大概率会写出一版你觉得完全没用的东西；但如果你把项目里的表结构、命名规范、现有编码风格、异常处理方式都告诉他，他写出来的东西基本就是你要的。

AI 编码工具吃亏的地方在于，它没有你项目的记忆。所以有效使用 AI 的第一原则，就是主动、充分、结构化地提供上下文。

3.1 上下文信息的具体清单

根据我半年的实践，一份高质量的编码提示词至少应该包含以下内容：

1. 技术栈与框架版本。比如"Spring Boot 2.7 + MyBatis-Plus 3.5，Java 8"，比"用 Java 写个接口"有效十倍。版本不同，API 用法差异很大，AI 默认生成的往往是最新版本的写法，而你的项目可能还在用老版本。
2. 项目既有代码风格片段。复制一段你们项目里同类接口的现有写法作为例子，告诉 AI"按照这个风格写"。风格包括：是否使用 Lombok、是否在建实体类时使用 Builder、Controller 是薄是厚、异常是统一处理还是逐层抛出、返回值结构长什么样。
3. 数据表和字段清单。不一定要全表结构，但关键表和关键字段必须给。字段命名差异很重要，比如你们用 create_time 而不是 createdAt，AI 就要按这个写。
4. 业务规则的边界条件。比如"库存不能为负数""优惠券每人限领一张""审批通过后不能再次修改"这类必须满足的规则。这些条件你不写，AI 大概率就会漏。
5. 不做什么的约束。比如"不要用 MapStruct，项目里都是手写转换""不需要考虑软删除，项目里就是物理删除""不要加 Redis 缓存，这个接口查询频率不高"。这类否定性约束很关键，因为 AI 特别爱自作主张加优化，而且加的优化往往不是你的项目需要的。

我把这些信息组织成一个简单的模板，每次要用 AI 生成重要代码时，直接把模板填好贴进去。刚开始觉得麻烦，后来习惯了反而不累，因为这套上下文同时也是我自己理清需求的过程。很多时候我填完这份上下文，还没等 AI 写代码，我自己已经知道该怎么写了，AI 只是把我脑子里的方案快速落成代码而已。

3.2 上下文组织的典型反例与正例对比

拿"写一个分页查询用户接口"来说，如果我只写一句话，AI 给出的代码往往是这样：

• 默认表名 user，字段 id、name、email
• 返回 PageResult 结构
• 用 LambdaQueryWrapper
• 不处理任何复杂过滤条件

而如果我把项目里真实的表结构、现有代码风格、返回值格式贴上去，AI 给出的代码会是：

• 表名 biz_user_info，按你们项目约定带 tenant_id 隔离
• 字段多一个 deleted 标记字段，而且状态枚举同时返回 code 和 desc
• 类名按你们项目的命名规范（*Controller，*Service，*ServiceImpl）
• 分页使用的是项目自定义的 PageResult，内部用的是 PageHelper 插件
• 接口返回结构包含 traceId 和耗时统计

后者基本就是在原有代码基础上"按套路再写一个"，几乎可以直接合并。就是你想要的效果。

这个过程让我想明白了一个本质问题：AI 编码的价值不在于替代人的思考，而在于把"想清楚的需求"快速变成"符合规范的代码"。你的思考质量直接决定了 AI 的输出质量，这不是一句空话，而是我踩了无数小时的坑之后总结出来的核心经验。

3.3 上下文文件与持久化维护

还有一个技巧，很实用。我在项目里创建一个 docs/ai-context.md 文件，专门用来维护当前项目的 AI 上下文信息。里面记录了：

• 项目的技术栈、目录结构、模块划分
• 数据库命名规范和常见表结构摘要
• 接口返回值规范、异常处理规范、日志规范
• 常用的代码风格示例（Controller、Service、Mapper 各一段）
• 项目中常见的坑（比如某张表的 status 字段含义和历史遗留行为）

每次让 AI 生成代码时，我大概率会直接引用这个文件，或者让 AI 先读一下这个文件。效果是这样的：AI 生成的代码从一开始就符合项目的大多数潜规则，我只需要在细节上做微调。半年下来，这个文件被我整理了好几轮，它本身也变成了一份可复用的团队知识资产。新同事来了，先把这份文档给他看，再让他上手写代码，犯低级错误的概率低很多。这也算是一个意外收获。

4. 我在真实项目里踩过的 AI 编码深坑，以及完整的排查链路

这半年，我在 AI 编码这个事上踩过的坑可以说是"集大成者"。这些坑基本都不是 AI 直接给我制造一个 500 错误，而是看起来一切正常，实际逻辑却有隐藏缺陷的坑。这类问题最恶心，既不好发现的，也不是单元测试能轻易兜住的。我挑三个有代表性的讲，每一个都是真实发生过然后慢慢排查出来的。

4.1 坑一：AI 生成的分页查询，因一个"默认排序"让全表数据顺序失控

这个问题的表象特别隐蔽。AI 帮我写了一个分页查询订单列表的接口，我在提示词里没有明确排序要求，结果 AI 默认加了 ORDER BY id DESC。看起来没什么问题是吧？在数据量小的时候，排序确实没影响。但这个接口后来被导出的报表功能直接查询复用，而报表模块会在某个特殊条件下不传任何排序字段，于是订单导出的顺序变成了乱序。

刚开始排查时，我一度以为是前端传参的问题，后来翻遍了整条链路才发现，问题出在 AI 生成的分页查询里有一个"隐性的默认排序"——它默认 ORDER BY id DESC，但导出功能走的是另一个查询入口，没有这个默认排序，所以两边数据顺序不一致。

这个坑的教训是：只要涉及排序、默认值、空值处理、时间边界这类"看起来不重要"的细节，必须格外小心地审查 AI 生成的代码。这类细节，AI 通常不会主动问你，而是会选一个一般不会出错的默认方案，但"一般不会出错"在真实业务里往往意味着"在某种条件下出错"。

后面我把所有 AI 生成的分页查询都增加了一条硬性规范：无论 AI 怎么写，最终代码里的排序字段必须显式声明，且要和真实业务场景匹配。不能依赖"默认排序"这种隐式行为。如果业务真的不需要排序，也必须在 SQL 中明确写出"不排序"，不给"隐式默认"留机会。

4.2 坑二：AI 自动加了一个"看似优化"的缓存，导致数据一致性隐患

这个坑更典型。我让 AI 帮我写一个商品的详情查询接口，输入内容只描述了查询逻辑，没提缓存。AI 直接加了 Spring Cache 的 @Cacheable 注解，缓存 key 是商品 ID，缓存过期时间设置的 30 分钟。

初看这个代码，逻辑上完全自洽，性能还"优化"了。但问题在于，这个商品详情接口并不是一个只读接口的附属品。项目里，管理后台有一个"更新商品信息"的操作，直接会对商品表做 update。按照这个项目的业务规则，更新商品后，前台详情必须立刻展示新数据。但 AI 生成的缓存注解让前台详情在 30 分钟内还停留在旧数据上。

这个坑排查过程也是典型的"看起来一切正常"：接口返回 200，数据不报错，只有当你盯着某个商品反复修改并刷新页面时，才会意识到数据没变。这时候是个人都会先去查数据库，确认更新成功了，然后再查接口，发现返回旧值，最后才想到是不是有缓存。

排查到这一步，再回看 AI 生成的代码，才发现它在没有任何提示的情况下自行引入了缓存。这就是 AI 编码最大的一个特点：它倾向于"过度设计"和"过度优化"。只要你的提示词没有明确禁止，它就默认你想让它做得更好，但做的更好往往意味着引入了你项目里没有的复杂度。

吸取教训后，我在提示词模板里增加了一条硬性约束：除非明确要求，否则不要加缓存、不要加消息队列、不要加分布式锁。这样的否定性约束，几乎能根除这类问题。

4.3 坑三：AI 在事务边界上"自作聪明"，导致部分成功的数据写入

这个坑最严重，也最值得展开讲。背景是项目里有一个"创建订单并扣减库存"的接口。AI 生成的代码，方法上标注了 @Transactional，看起来事务处理没问题。

但真实业务里，这个接口的调用链是：先创建一个订单主记录，然后扣减库存，再创建订单明细，最后发送一条 MQ 消息。AI 生成的代码，@Transactional 注解加在了最外层的方法上，看起来一切正常。

问题出在事务边界和 MQ 消息发送之间的时序上。项目里使用的是本地消息表 + 定时任务扫表的方式，而不是同步发送 MQ。也就是说，事务提交之后，会往消息表里插一条记录，然后定时任务去轮询处理。AI 生成代码时，根本不了解这个机制，它默认消息应该同步发出去，于是把发 MQ 的逻辑放在了事务提交之前。

这个问题的后果很隐蔽：如果事务回滚了，MQ 消息却已经发出去了，下游消费者拿到一个根本不存在的订单。生产环境出现这个问题后，排查了很久。先查订单表，发现订单确实创建成功了；再查库存，发现扣减也成功；但下游系统里的订单却不见了。后来把事务日志打开，才发现创建订单的事务在提交前发生了异常回滚，但 MQ 消息已经发出去，下游已经消费了。

这个坑的根源，不是 AI 写错了代码，而是AI 缺乏对系统整体架构的了解。它对"事务"和"消息"的理解是教科书级别的，但真实系统的消息机制、事务边界、本地消息表方案，这些隐性的架构约束，AI 是完全不知道的。

所以从那以后，我是真真正正地把"涉及整个调用链、事务、异步消息"这类代码划为高危代码区。凡是涉及跨系统、跨模块、跨事务交互的代码，绝不交给 AI 独立完成，哪怕它只是帮你打个框架，核心的时序和边界也必须我亲手写。这不是对 AI 能力的不信任，而是对真实系统的复杂性的敬畏。

4.4 关于排查链路的一个完整复盘

这三个坑，加上平时遇到的一堆小问题，让我逐渐形成了"AI 代码上线前必须多问几个为什么"的检查清单：

1. AI 只写了你提示词里的功能，还是顺带加了一些"附加功能"？如果加了，是什么？
2. 生成的代码里有没有隐式的默认行为，比如默认排序、默认缓存、默认重试、默认尝试加锁？
3. 代码涉及事务时，事务的边界和你业务真实的边界是否一致？事务范围内有没有包含异步操作？
4. 代码里有没有对项目现有机制的假设，比如假设消息是同步发送的、假设 redis 可用、假设并发量不高？
5. 有没有把不该耦合的模块耦在一起？比如商品详情接口，有没有掺入库存判断逻辑？
6. 异常处理是"吞掉"还是"抛出"？AI 特别喜欢在 catch 块里打日志然后返回 null，这在真实业务里很危险。

每次过完这个清单，再合代码，我心里就有底得多。我不会把 AI 生成的代码直接当作"已完成品"，而是当作"一份需要按我的标准来验收的半成品"。心态变了，行为就变了，效率和质量的平衡自然就找到了。

5. AI 编码的"不能做什么"清单，比"能做什么"更重要

经过半年的实践，我心里逐渐形成了一张"AI 不要碰"的清单。这些场景，要么是 AI 再怎么努力也做不好的，要么是让 AI 做了反而会画蛇添足的。把它列出来，比告诉你"AI 能做什么"更有价值。

5.1 涉及分布式事务与跨系统一致性，AI 不擅长

真实项目里，一次操作往往涉及多个系统：本地业务系统、下游清算系统、通知服务、消息队列。这些系统之间的数据一致性，不是靠一个 @Transactional 注解能解决的。AI 不理解你们系统之间靠什么机制保证最终一致，它只会按照教科书的方式"加个事务"，而真正的解决方案往往是基于本地消息表、事务消息、对账任务等一套复杂的组合拳。

这类代码我从不交给 AI。不是它不能写，是它根本不了解你们系统之间的信任模型和契约。你花在让它理解这些的时间，足够自己把代码写两遍了。

5.2 涉及"熵增型"业务逻辑，AI 无法建模

这类逻辑的特点是：规则本身就不是静态的，而是会随着运营策略不断变化的。比如优惠券的叠加规则、不同用户等级的折扣系数、各种运营活动的参与门槛。

这类业务，AI 能帮你写一个"看起来正确"的静态实现，但一旦需求调整，这个实现就成了累赘。因为 AI 生成的代码风格通常偏"硬编码"，它不会为了后续扩展预留策略模式、规则引擎之类的弹性架构。

所以我的建议是：领域逻辑的建模和核心算法的演进，必须人来主导。AI 可以作为讨论对象，帮你列出潜在状态组合，但最终落地的架构决策，尤其是那些影响未来半年需求迭代的关键决策，不能交给 AI 凭直觉做。

5.3 涉及性能敏感或架构演进的关键路径，AI 只能提供参考

如果你的系统正处在一个从单体拆分成微服务的过渡期，或者正在做一个大规模数据迁移，或者要设计一个新的缓存分片规则——这些场景的编码工作量可能并不大，但决策的复杂度极高。AI 生成的代码无法帮助你权衡"是缓存穿透还是缓存击穿""是最终一致还是强一致""是秒级同步还是分钟级对账"这类架构层面的取舍。

在这些场景下，AI 可以作为一个快速生成几种候选方案的工具，帮助你扩展思路，但最终的选择和落地方案必须经过严谨的架构评审。我不会让 AI 直接生成这类代码，但我会让它帮我生成不同方案下的骨架代码，用来做对比验证。这两种用法有本质区别。

5.4 涉及"老代码兼容"的细节，AI 常常直接忽略

真实项目里，大量代码是在"前人埋雷、后人填坑"的循环中生存的。某个字段在下单时是 A 状态，但实际上老订单里可能存了 B 状态。某个接口的入参虽然是必填，但老客户端就是不传。这些"历史遗留行为"，AI 是完全无感的。

它会用干净利落的逻辑处理一切事务，而真实世界全是脏数据、老逻辑和兼容性要求。遇到这类兼容性代码，我绝对是手写，不碰 AI。就算 AI 写出了 99% 正确的代码，那 1% 的兼容性分支，也足以让生产环境炸一次。因为兼容逻辑是"从前的业务约束残留在今天"，AI 没有对"从前"的任何概念。

6. AI 编码的一年之后，我重新审视的几个核心认知

半年时间说长不长，说短不短。但足以让我对一些基本概念有了新的理解。这里我不做宏观预测，只谈几个基于真实操作得出的认知，希望能帮你少走一些弯路。

6.1 代码量不再是衡量产出的有效指标

过去我们评价一个工程师能不能干活，很多时候会下意识地看"他写得多不多"。但半年前的 AI 帮我写了一个包含大量样板代码的完整服务之后，我突然意识到，未来的产出衡量，必须从"写了多少代码"转向"解决了多少问题、做了多少关键决策"。

AI 能把一万行代码在半小时内写出来，但这一万行代码里，真正需要人拍板的地方可能只有不到十处。一个人的真正价值，集中体现在那十处决策上。你是选择用乐观锁还是悲观锁？是让这张表加一个冗余字段还是拆分一张子表？是把超时时间设为 3 秒还是 5 秒？这些决策，每一处都源于你对业务的理解、对系统全局的把握。AI 给不出这些答案背后的"为什么"。

想明白这件事之后，我反而没那么焦虑了。哪怕 AI 真有一天能自动生成整个模块，它生成的那部分价值，会越来越便宜，越来越不重要；真正贵的，永远是人基于复杂现实做出的决策判断。

6.2 让 AI 写代码，本质上是在"训练团队的下限"

团队里每个人的水平不一样。有的同事写的代码风格工整，有的代码则比较"野路子"。我在团队里引入了 AI 编码 + 统一上下文文件之后，一个明显的效果是：新同事写出来的代码，一开始就能达到团队平均水平，而不是从"野路子"慢慢纠正。

AI 属于一个良好的"编码下限提升器"。它把最低水平的代码质量往上拉了一大截，但同时也让高水平工程师的优势不再体现在"编码速度"上，而是体现在"代码设计能力"、"边界思考能力"、"系统架构能力"上。如果团队里有人说"AI 让我失去优势"，那我反而认为，那是他本来就没有多少真正的优势——他的优势只是手速快而已。

6.3 编码协作的"人机信任模型"

最后一点，也是最有感触的一点。和人合作久了，你会逐渐形成一种信任模型：你知道哪些事可以放心交给某人，哪些事必须亲自把关。和 AI 协作，同样需要建立一个"人机信任模型"。

这个模型的核心，不是"信不信 AI"，而是"在什么边界内信任 AI"。我的边界是这样的：

• 信任它在标准化的、有明确范例的场景中能做好；
• 信任它能在我给出的清晰上下文中写出高质量代码；
• 不信任它在没有上下文时能做出合理的架构取舍；
• 不信任它理解我项目的隐性业务规则和历史坑。

建立这个模型之后，你会发现 AI 编码从一件让人心里打鼓的事情，变成了一件有确定性的工程工具。你会知道什么时候按时是安全的，什么时候必须亲自上。这里的确定性，其实比 AI 本身的能力提升更宝贵。

7. 我现在的 AI 编码工作流长什么样，以及给新手的建议

说到最后，我把这半年实践下来的完整工作流分享出来，给刚想上手 AI 编码的读者一个可复用的参考。它不是某个公司的内部流程，而是我个人在真实项目中打磨出来的一套"输入-生成-审查-验收"的闭环。

7.1 具体的每日工作流

1. 任务拆解：拿到一个需求，先不急着写提示词，而是手动拆解成"核心决策"和"外围执行"两类。
2. 上下文填充：打开维护的 ai-context.md，按提示词模板把当前任务相关的上下文信息补充完整。这一步大概花 3~5 分钟。
3. AI 生成草案：让 AI 基于详细的提示词生成代码草案，我会明确标注"这是草案，不是最终版本"。
4. 人工审查：核心决策部分我亲手重写；外围执行部分按清单逐行检查 AI 生成的代码，重点看隐式默认行为、异常分支、边界条件。
5. 单元测试补充：AI 生成的代码，我让它顺便生成对应的单元测试，覆盖正常路径 + 若干边界情况。测试必须是强制性的，不能因为代码是 AI 写的就跳过测试。
6. Review + 合并：把通过审查和测试的代码合入主干。合并前，我会再通读一遍 diff，确保没有"额外的惊喜"。

7.2 给新手的五个建议

如果你刚接触 AI 编码，建议按这个顺序摸索，不要一上来就在复杂项目里硬试：

1. 从最底层的工具函数开始。写一个日期工具类、一个加密工具类、一个字符串解析器，感受一下 AI 的生成质量和边界处理能力，建立起初步的"人机信任模型"。
2. 把提示词从"要什么"升级为"要什么 + 不要什么"。否定性约束能减少 80% 的"自作主张"问题。
3. 每段 AI 代码都要过一遍那六个检查问题。不要因为"看起来对"就合入。
4. 给自己一个"缓冲期"。前两周不要追求效率提升，而是追求"错误模式收集"。记录 AI 在哪些场景下会出错，错的类型是什么，这些记录会是你未来判断能否放权的宝贵依据。
5. 保持批判性，但也保持开放。不要因为一次两次的错误，就一棍子打死 AI 编码。本质上这是一个需要磨合的工具，磨合期不会太短，但收益也确实是真的。

7.3 一个标准的提示词模板（最后的干货）

最后把我在项目里高频使用的提示词模板直接放出来，你可以直接复用：

项目背景：这是一个订单管理后台系统，Spring Boot 2.7 + MyBatis-Plus 3.5，Java 8。项目统一使用 Lombok，Controller 只做参数校验和结果包装，业务逻辑全部在 Service 层，Mapper 只做数据操作。 数据库表：biz_order（字段：id, order_no, user_id, amount, status, create_time, update_time, deleted）；biz_order_item（字段：id, order_id, sku_id, spec_id, quantity, price, total_price）。 现有风格参考：见下方代码片段（Controller / Service / Mapper 各贴一段）。 任务：帮我写一个"分页查询订单列表"的接口。入参：pageNum, pageSize, userId（按用户精确过滤）, status（按状态精确过滤），返回结果按 create_time 倒序排序。出参结构使用项目的 PageResult 包装，包含订单主信息和订单明细列表。 硬性约束： - 不要加缓存注解，本项目不使用 Spring Cache。 - 不要自定义异常，统一使用项目已有的 BizException。 - 订单明细查询不要使用循环，用批量查询。 - 注意数据权限，订单表有租户概念，查询时需要拼接租户过滤条件。 请按上述要求生成完整可运行的代码，包括 Controller、Service、Mapper 接口和 XML 文件。

这个模板的质量，比你在聊天框里随便丢一句"帮我写个订单分页"高出无数倍。你把这个模板跑通一遍，再对比一下之前随意的写法，就会深刻理解"AI 编码靠不靠谱"这个问题，答案其实取决于你怎么提问，而不完全取决于 AI 本身。

半年下来，我对 AI 编码的最终感受可以浓缩为一句话：它不是用来替代你的，是用来逼你把问题想得更清楚的。每一次成功的 AI 编码协作，都建立在一个前提上——你自己足够清楚自己要什么。这句话听起来很悖论，但做着做着，你就发现它其实是这半年最值钱的收获。