很多客户已经会用豆包、ChatGPT、通义千问写页面、生成脚本，甚至搭出一个可演示的雏形。但真正进入业务使用时，问题往往不在“能不能生成代码”，而在“需求是否清楚、边界是否明确、流程是否跑得通、数据是否可靠、上线后谁来维护”。
AI 擅长把明确问题快速推进到 0.8
当输入清楚、目标单一、风险较低时，AI 的效率非常高。它能帮你生成页面、接口示例、数据结构和原型代码，适合用来探索方向。
真正卡住的是最后 0.2
最后 0.2 通常包括异常流程、权限边界、数据一致性、部署安全、体验细节、业务取舍和长期维护。这些不是灵感问题，而是专业工程问题。
专业团队的价值不是替 AI 打字
专业团队要判断哪些功能先做、哪些暂缓、哪些风险必须提前处理，并把 AI 产出的效率转化成稳定可用的系统。
正确的合作方式：AI 增强，而不是 AI 代替
涧序数字更推荐用 AI 提升需求分析、方案演示和开发效率，再由技术团队负责架构、质量、交付和上线。
脱敏项目复盘：从 AI 原型到可用订单系统
一个订单原型用 AI 很快就能生成页面、表格和接口，看起来已经完成了八成。但真实业务一接入，就会出现销售改价、仓库分批发货、财务确认回款、管理员撤销误操作等问题。剩下的部分不是继续堆页面，而是把业务事实、权限和失败路径做成可靠规则。
业务与产品形态
我们先把链路压缩成报价、确认、备货、发货、回款五个状态，并明确每个状态由谁推进、允许修改什么。销售端关注客户、报价和交期，仓库端只看待拣与待发任务，财务端确认应收与回款，管理端查看异常和审计记录。同一订单因角色不同呈现不同工作台，而不是所有人共用一张万能表。
技术解决方案
后端用显式状态机约束状态迁移，把订单主表、明细、库存流水和操作日志放在事务边界内；跨模块通知通过事件和 Outbox 投递，外部支付或物流回调使用业务单号与事件号双重幂等。金额使用定点小数，关键字段保存修改前后值，接口按照业务能力划分，而不是让前端直接拼数据库字段。
难点设计
难点集中在并发扣减、重复回调、历史数据迁移和发布回滚。库存不能只做“查完再减”，而要用条件更新或版本号保证原子性；回调可能乱序，必须验证当前状态是否允许迁移；旧 Excel 中同名客户、缺失规格和负库存要先生成异常清单，不能静默导入。数据库变更遵循先兼容、再切换、最后清理，避免代码回滚后读不到旧结构。
用户体验
界面只展示当前可执行动作，禁用按钮必须解释原因。长任务显示进度和结果摘要，保存失败时保留已填内容；批量操作先预览影响范围，危险动作要求二次确认。订单时间线用业务语言展示“谁在什么时候做了什么”，让客服能直接回答客户，而不是翻技术日志。
产品效果与验收
最小版本的完成标准不是页面齐全，而是真实订单能从报价走到回款，库存账能对上，异常能恢复，操作能追溯。验收指标包括订单处理时长、库存差异、重复回调处理率、人工补录次数、错误状态拦截数和关键接口延迟。AI 可以加快代码与测试样例生成，但状态规则、数据一致性和上线责任仍需要工程团队完成。
从生成代码到可交付系统，中间缺的是工程判断
AI 很容易生成一个能创建订单、修改状态、展示列表的页面，但它不会自动知道“取消订单后是否释放库存”“重复支付回调能不能再次入账”“销售能不能看到其他团队的客户”。这些都不是语法问题，而是领域规则。工程师首先要把实体、状态、约束和责任边界定义清楚，再让代码围绕这些规则展开。
状态机必须处理正常路径之外的分支
一个订单并不是从待支付顺序走到已完成这么简单。还会出现超时关闭、部分退款、重复通知、人工改价、库存不足、履约失败和财务冲正。我们通常先画状态转换表，明确每个动作的前置状态、操作者、数据变更和副作用，再实现接口。没有状态机约束的系统，往往在上线几周后出现“页面显示一个状态、库存和财务却是另一个状态”的问题。
并发、幂等和事务决定数据会不会越跑越乱
演示环境只有一个人点击按钮，生产环境可能同时接收用户操作、定时任务和第三方回调。扣库存要考虑并发更新，支付回调要用外部流水号去重，跨服务通知要考虑本地事务与消息最终一致性。AI 可以给出常见写法，但是否使用乐观锁、唯一约束、事务消息或补偿任务，要结合业务损失和系统规模判断。
可维护性来自测试、日志和发布流程
我们更关注关键规则是否有自动化测试、错误是否带业务上下文、数据库变更是否可回滚、发布是否能快速恢复。单元测试用于锁定状态规则，接口测试覆盖权限和异常输入，端到端测试只守住最关键链路。上线后通过请求 ID 串起前端、API 和任务日志。代码能运行只是开始，出现问题时能定位、能止损、能恢复，才算完成交付。
AI 代码进入生产仓库前，要过哪些工程门槛
先服从仓库边界，再讨论代码写得快不快
成熟项目会先约定模块依赖、目录职责、接口错误格式、日志字段和配置读取方式。AI 生成的代码如果绕过 service 层直接改数据库，或者在页面里复制一套业务规则，即使当下能运行，也会在下一次修改时出现两套判断。代码评审首先检查依赖方向和业务规则落点，其次才是语法与风格。
数据库变更必须可迁移、可回滚、可重复执行
增加字段不只是写一条 ALTER TABLE。要确认历史数据怎样填充、空值是否允许、索引是否影响写入、旧版本应用能否兼容，并把变更写成受版本管理的 migration。订单提交、库存扣减和回调处理要划清事务边界，配合唯一约束或幂等键，不能把“先查再写”当成并发安全。
测试要覆盖失败路径，而不是只证明页面能点通
单元测试验证规则，接口测试验证数据库与权限，契约测试约束第三方字段，端到端测试覆盖关键业务闭环。真正容易出问题的是重复提交、超时重试、半途中断、权限不足、空数据和旧客户端请求。AI 很容易生成正常路径样例，工程师的工作是把这些边界条件补进测试，并让它们进入持续集成。
发布能力决定代码是否真的“可用”
合并前要经过静态检查、依赖漏洞检查、自动测试和人工评审；发布时要记录镜像或构建产物版本，执行数据库备份与迁移，并准备明确的回滚步骤。应用日志使用 request_id 贯穿前后端，错误监控能定位到版本和调用链。没有这些环节，代码只是完成了编写，还没有完成交付。
你可以先这样判断
- 是否已经有真实业务场景
- 是否知道最先要解决哪条流程
- 是否需要多人协作、权限或数据沉淀
- 是否准备上线给真实客户或员工使用