如果最近有一部电影能同时让 IT 圈的人和公司管理者坐进同一个放映厅那大概是《奥德赛》。很多人的关注点并不在于剧情本身而在于一个反复出现的隐喻AI 已经能生成一个又一个逼真的世界但那个世界是否真正遵循某种物理法则、社会规则和因果链条你从画面上一眼看不出差距。这个隐喻放在软件开发里几乎一模一样。过去两年AI 编程工具的进步速度快到让人眩晕给一段需求描述一次回车页面能生成接口能生成数据库表能生成连 Dockerfile 都能顺手补齐。于是很多团队开始兴奋地讨论“程序员是不是要被替代了”。可真正在企业系统里试过一遍的人往往会遇到另一种困惑AI 生成的代码确实快但系统里真正负责“企业真实世界”的那部分反而变得很难推进——不是写不出来而是不知道该怎么定义。这篇文章想回答一个问题为什么 AI 可以快速搭建软件却搭不出企业的真实世界以及当我们接受这个边界之后到底应该怎么用 AI 开发软件才能既享受速度又不丢掉企业系统最需要的确定性。文章不会只停留在观点层面我会用一个采购订单模块的最小案例把“代码能跑”和“业务正确”之间的差距拆开来看再给出一条适合团队落地的实践路径。这篇文章真正要解决的问题先说结论AI 擅长的是把“已经定义清楚的需求”快速翻译成代码但它不擅长定义需求本身。企业软件之所以复杂不是因为代码量大而是因为业务规则藏在组织流程、历史数据、合规要求和人的决策习惯里。很多团队在引入 AI 开发工具时真正遇到的不是“代码质量问题”而是“上下文缺失问题”。AI 可以生成一个非常标准的 HTTP 接口但接口背后的审批流、校验规则、数据权限、幂等策略、与第三方系统的闭环并不会因为提示词写得漂亮就自动出现。这些内容必须由人先定义清楚再让 AI 去实现。这篇文章适合三类读者第一类是正在评估“AI 能否替代研发部门”的技术管理者。你需要看到 AI 的能力边界避免把 Demo 当成生产系统。第二类是真正使用 AI 编程工具的开发者。你需要理解为什么 AI 生成的代码偶尔“看起来很对跑起来出事”以及怎么用测试和架构约束把这些风险堵住。第三类是参与企业数字化转型的人。你需要知道AI 的价值不在生成代码那一瞬间而在把业务规则结构化、可验证、可演化的整个过程中。电影《奥德赛》与 AI 软件生成的共同点像不等于真《奥德赛》里最震撼的画面往往是那些由算法生成的宏大场景。你看到一个世界它符合视觉上的直觉光影正确、物体清晰、海面有波涛。但如果你追问这片海域的潮汐规律是什么这位船长根据什么数据决定航线船上的物资能在海上支撑多少天电影并不会回答因为算法生成的只是“看起来合理”的画面而不是一个有完整物理和社会规则的模拟世界。AI 生成软件也是同理。你用 AI 做一个订单管理后台它能生成表单、按钮、表格能创建订单、更新状态、计算金额。表面上这已经是一套能跑的软件了。但企业真正关心的问题往往不在这个表面上订单金额超过多少需要二级审批供应商资质过期了能不能继续下单同一个客户在不同渠道的订单能不能合并结算这些规则如果不在提示词里AI 默认不会知道也不会主动问。这就引出了一个核心概念软件的表面真实和本质真实是两回事。表面真实是代码能编译、接口能请求、页面能交互本质真实是软件在特定企业的组织、流程、合规和商业目标下能否持续输出正确结果。AI 生成软件的速度越快我们越容易把表面真实误当成本质真实。电影里的世界可以只追求“像”企业系统里的世界却不能只要“像”它必须“是”。AI 开发工具的能力边界它擅长什么不擅长什么先把 AI 开发工具能做好的事情说清楚避免走向另一个极端。AI 非常擅长以下几类工作样板代码和脚手架工程。比如生成一个新的服务模块、CRUD 接口、前端页面、数据库迁移脚本。代码解释和遗留系统分析。给 AI 一段老代码让它总结逻辑、标注潜在问题通常效率比人逐行读高得多。单测和边界测试生成。给定一个函数和输入输出示例AI 可以生成不少有价值的测试用例。跨语言翻译和框架迁移。把 Java 代码改成 Go把 Spring Boot 迁移成其他框架AI 能完成大部分机械工作。文档生成和维护。根据代码生成接口文档、数据库字段说明、部署说明能省不少时间。但 AI 不擅长的地方恰好是企业软件最核心的地方定义业务边界。同一个“订单”在电商、制造业、医疗、物流行业里含义完全不同。AI 默认会用互联网常见的订单模型而不是你们公司的订单模型。识别业务不变量。比如“库存不能为负”“每人每周最多提交 3 次申请”“退款金额不能大于实付金额”。这些规则通常散落在制度文件和老员工的脑子里。处理历史包袱。生产环境里的脏数据、旧系统的接口协议、被多个团队共享的数据库表AI 看不到也不会理解。判断非功能需求。接口要在几毫秒内返回数据最多能丢几秒审计日志要保留几年这些问题直接影响系统设计却不能靠“生成”解决。如果把 AI 当成一个极其高效的外包程序员它确实合格。但如果把它当成了解你公司业务的资深架构师它一定不合格。问题的关键不在于 AI 能不能写代码而在于“谁负责把真实世界翻译成 AI 能理解的上下文”。从“订单模块”看真实世界一个最小案例概念讲多了容易飘我们用一个小而完整的采购订单模块来拆解。4.1 AI 生成的“表面正确”代码假设某制造企业需要开发一个采购订单创建接口。你给 AI 一个很常见的 prompt用 Python FastAPI 实现一个采购订单创建接口。请求参数包括供应商ID、商品列表、总金额。AI 大概率会生成类似下面的代码# 文件路径main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class PurchaseOrder(BaseModel): supplier_id: int items: list total_amount: float orders [] app.post(/purchase_orders) def create_po(order: PurchaseOrder): orders.append(order) return {id: len(orders), status: created}这段代码能运行吗能。写入数据了吗写入了。但在真实企业里这段代码大概率不能直接上线。原因不是语法而是它缺少对一个真实采购系统的全部上下文。4.2 真实业务规则开始出现后现在把企业的真实规则加进来。比如只有通过认证的供应商才能创建采购订单。订单总金额超过 100 万时必须进入两级审批。同一供应商如果已经有一笔待审批订单且采购品类相同则不能重复创建。金额计算必须使用 Decimal不能用 float避免精度问题。这些规则看起来不难但每一条都意味着代码结构的变化。下面是加入部分规则后的服务层实现# 文件路径services/purchase_order_service.py from decimal import Decimal from domain.purchase_order import PurchaseOrder, OrderStatus from domain.business_rule_error import BusinessRuleViolation def create_purchase_order(repo, supplier_repo, approval_service, order_draft): supplier supplier_repo.find_by_id(order_draft.supplier_id) if supplier is None or not supplier.verified: raise BusinessRuleViolation(supplier must be verified) po PurchaseOrder( supplier_idsupplier.id, itemsorder_draft.items, total_amountcalculate_total(order_draft.items) ) existing repo.find_pending_po_by_supplier_and_category( supplier.id, po.category ) if existing is not None: raise BusinessRuleViolation(duplicate pending po) if po.total_amount Decimal(1000000.00): po.status OrderStatus.PENDING_APPROVAL approval_service.start_flow(po, level2) repo.save(po) return po def calculate_total(items): return sum((Decimal(str(item.unit_price)) * item.quantity) for item in items)这仍然是一个简化版本但已经能看出来真实业务规则会影响函数输入、状态流转、依赖服务和异常处理。AI 能不能生成这段代码如果提示词写得很细它大概率也能生成。但问题是这些规则从哪来不是 AI 能凭空想出来的而是业务人员、财务人员、采购专员坐在一起经过很多次讨论后才确定下来的。4.3 用测试把业务规则变成可执行约束要保证 AI 生成的代码不会破坏业务规则最有效的方法是把规则转成测试。下面是一个针对“未认证供应商不能下单”的测试# 文件路径tests/test_purchase_order_service.py import pytest from decimal import Decimal from services.purchase_order_service import create_purchase_order from domain.business_rule_error import BusinessRuleViolation def test_cannot_create_po_from_unverified_supplier(): unverified_supplier Supplier(id999, verifiedFalse) repo MemoryRepo() supplier_repo MemoryRepo([unverified_supplier]) approval_service ApprovalService() draft OrderDraft( supplier_id999, items[OrderItem(skuA001, quantity2, unit_priceDecimal(50.00))] ) with pytest.raises(BusinessRuleViolation): create_purchase_order(repo, supplier_repo, approval_service, draft)写这个测试的意义比写业务代码本身更重要。因为它把一条看不见的规则变成了一个每次提交代码都会自动运行的“守门员”。AI 可以快速生成代码但只有人才能决定哪些规则必须被测试固化下来。运行测试的命令很简单pytest tests/test_purchase_order_service.py -v预期输出tests/test_purchase_order_service.py::test_cannot_create_po_from_unverified_supplier PASSED如果这条测试失败说明供应商校验逻辑没有被实现或者被后续 AI 重构时改坏了。企业系统的可靠性本质上就是这样一条一条测试堆起来的而不是靠某一次“生成”完成的。为什么真实世界不能被一次性“喂”给 AI很多人会想既然 AI 生成代码需要上下文那我多写一点提示词把规则全部塞进去不就行了理论上可以但实践中行不通。5.1 企业软件的“上下文”远大于提示词一个运行五年以上的企业系统它的真实上下文包括几十张数据库表的历史含义、多个系统之间对账规则、不同业务部门对同一字段的解释差异、还有因为特殊情况留下的兼容逻辑。这些内容不可能全部写进一次对话的提示词里。更现实的做法是把企业级的上下文拆成两类一类是稳定的业务规则比如“价格必须大于 0”“订单不能重复提交”另一类是不断变化的环境比如某个客户生命周期在某个阶段需要特殊处理。前者可以结构化地描述给 AI后者必须靠持续运维和反馈闭环来修正。5.2 AI 不知道你不知道的规则这是最容易被忽略的一点。企业在招聘新人的时候老员工会告诉他“我们这个系统里有个特殊逻辑三年前因为某个大客户要求加的文档里没写。” AI 也一样它不知道你们企业内部那些“只可意会”的规则。如果 AI 生成代码时没有这些规则它就会用自己从海量公开代码里学到的“通用世界模型”来填空。通用模型对大多数 Demo 有用但对特定企业来说很可能就是错的。尤其是在金融、医疗、制造等强合规行业用通用模型填充特定业务风险极高。5.3 企业系统的确定性要求电影生成允许随机性这次生成的画面不满意可以再生成一次。但企业系统对同一输入必须保证同一输出。订单提交后不能因为某个模型参数变化导致金额计算不同。这种确定性要求决定了 AI 不能作为业务逻辑的唯一决策来源。正确的模式是AI 负责生成实现人负责定义确定性规则测试负责固化规则架构负责隔离变化。只要这个分工清晰AI 才能真正进入企业开发流程而不是停留在玩一玩的层面。企业引入 AI 开发容易踩的四个坑在实际落地过程中我经常看到团队把 AI 开发工具用成“麻烦制造机”问题通常出在以下四个地方。第一个坑把 AI 生成的结果当成需求完成。AI 给出一个订单接口团队直接把接口联调上线但没人校验“审批流是否接入”“金额精度是否正确”。等业务发现数字对不上问题已经埋进生产环境。第二个坑业务人员直接用 AI 工具自建系统。业务部门响应速度慢于是有人用 AI 写脚本处理核心数据比如把手工 Excel 里的数据批量导入数据库。这些脚本没有经过审查没有日志出错后连备份都没有。这实质上是把未受管制的逻辑放进了生产链路。第三个坑AI 生成了大量样板代码却没人维护。AI 一天能生成 3000 行代码很快代码库就膨胀起来。但企业系统维护成本不是按代码行数算的而是按业务逻辑复杂度和依赖关系算的。样板越多依赖越乱后续改动越难。第四个坑让 AI 直接修改生产代码缺少回归测试。AI 重构很快就完成了但没跑测试没看影响范围。上线后出现数据不一致只好回滚。回滚本身并不可怕可怕的是你根本不知道它改了几处地方。这四类问题的根源都一样我们已经非常信任 AI 的执行能力却还没有建立起相应的治理和验证机制。一套落地的 AI 辅助开发流程既然 AI 解决不了“真实世界缺失”的问题那我们应该把它放在一个合适的流程里让它的速度为企业所用同时让企业规则不被稀释。7.1 先写决策记录再让 AI 动手建议在项目里引入轻量级的决策记录文档不需要很长但一定要写清楚为什么会做某个技术选型、为什么某条业务规则存在。比如# ADR-001采购订单金额使用 Decimal ## 背景 财务结算要求金额不能有误差。 使用 float 可能出现 0.1 0.2 不等于 0.3 的问题。 ## 决策 所有金额字段使用 Decimal禁止使用 float。 ## 影响 API 层需要做类型转换数据库字段映射为 decimal 类型。把 ADR 放在仓库里并让 AI 在生成代码前阅读这些文档。如果使用编程 Agent 一类的工具可以把 ADR 作为工作区上下文。这样AI 生成的代码就更容易符合团队已经做过的决策。7.2 用“结构化提示 测试先行”锁定业务规则不要只给 AI 一句话需求而是把业务规则、输入样例、测试预期都写清楚。下面的 prompt 模板比较适合企业场景请基于以下规则实现采购订单创建接口 业务规则 1. 只有已认证供应商可以创建订单。 2. 订单总金额超过 100 万时需要二级审批。 3. 同一供应商、同一品类、存在待审批订单时禁止重复创建。 4. 所有金额使用 Decimal禁止使用 float。 工程约束 - 使用 FastAPI。 - 服务层不直接依赖 HTTP 层。 - 输出单元测试。 请在代码注释中标出每条业务规则对应的实现位置。关键不是 prompt 写得多长而是让 AI 把一个明确规则映射到代码和测试。如果规则有歧义不要直接问 AI“你觉得怎么做”而是让人先开会把歧义消除。7.3 用 CI/CD 守住质量边界AI 生成代码进入主分支之前至少应该经过自动化测试、静态检查和依赖扫描。一个很基础的 CI 配置长这样# 文件路径.github/workflows/ci.yml name: ci on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.12 - name: Install dependencies run: | pip install -r requirements.txt pip install pytest - name: Run tests run: pytest -v如果 AI 生成的代码不能通过这条流水线就不应该进入人工评审环节。这样AI 的“快”和企业的“稳”之间就有了一个强制隔离点。常见问题与排查思路下面这张表列出企业在使用 AI 开发时最容易碰到的问题以及对应的排查方式。遇到问题不要先怀疑 AI 能力先按表里的顺序看。问题现象可能原因排查方式解决方案AI 生成的代码能运行但业务结果不对只描述了功能没有描述业务规则对照需求文档和代码中的规则分支把业务规则写成测试用例建立规则清单AI 重构旧代码后原有功能被破坏回归测试缺失测试覆盖太少查看 git diff运行全量测试在改动前补上关键路径测试小步提交业务人员用 AI 建脚本处理核心数据正常需求响应太慢治理缺失检查有没有未受管制的脚本、报表或数据库连接建设需求通道和自助数据平台同时规范 AI 使用AI 生成依赖有安全漏洞依赖版本过新或存在已知漏洞运行 pip-audit / npm audit 等工具锁定版本加入依赖扫描流程团队内代码风格混乱缺少格式化和架构约束检查 review 记录和静态扫描结果引入 formatter、lint 和架构测试AI 在中间步骤产生幻觉调用了不存在的接口上下文不完整工具权限过高查看 AI 执行日志确认模型上下文缩小任务范围提供准确的接口文档最佳实践与工程建议想让 AI 长期稳定地辅助企业软件研发建议把下面几件事当成制度而不是临时动作。第一先建模后生成。业务边界、领域对象、状态机、权限模型这些高层决策必须由人来定义。AI 可以帮你画草图但负责判断和拍板的一定是团队。第二把业务规则变成资产。为每条核心规则编号例如 R-001、R-002并且在代码里通过注释或测试用例引用对应编号。这样后续 AI 在修改代码时更容易通过上下文找到要遵守的规则。第三测试从业务规则出发而不是只追求覆盖率。覆盖率高低不是核心目标是否正确覆盖了关键不变量才是。一个 60% 覆盖率但覆盖了所有核心规则的测试套件要好过一个 95% 覆盖率却只测了正常路径的测试套件。第四给 AI 工具设置权限边界。不要让 AI 直接操作生产环境数据库也不要让它直接往 main 分支推代码。你要的不是一个“足够自由”的助手而是一个“在边界内高效工作”的助手。第五人工审查不要流于形式。AI 生成的代码审查者必须能回答三个问题这段代码真的满足业务规则吗如果规则变化哪里会受影响异常路径里数据是否保持一致如果审查时回答不了说明上下文还没建好。第六把线上的异常反馈变成新的测试。生产环境出现数据不一致不要只修数据更要追问为什么测试没有提前发现然后把反馈转成测试用例不断逼近企业的真实世界。这些实践看起来不酷但企业系统恰恰是靠着这种“不酷”的确定性才敢支撑每天数百万笔交易。AI 的价值在于压缩实现时间而不是压缩验证和治理环节。结语AI 加快建造但定义世界仍是人的工作回到《奥德赛》那个比喻。AI 可以生成无数个视觉上足够真实的场景但在一场真正的航行中你需要的不是一帧好看的画面而是清晰的航线、可靠的船体结构以及在风暴来临时仍然有效的判断规则。软件也一样。AI 可以把代码这座“建筑”砌得很快但只有人才知道这座建筑为什么存在、给谁使用、哪根柱子不能动。企业的真实世界不是一个提示词就能覆盖的它是一个由组织流程、数据历史、合规要求和人组成的持续演化的系统。如果你正在推进 AI 辅助开发下一步不是去收藏更多的 prompt 模板而是回到办公室里和业务负责人一起把你最核心的订单、审批、对账规则写清楚。把这条规则变成测试放进 CI再让 AI 在那个边界里尽情发挥。这才是 AI 开发工具真正值得被信任的方式。 
长河君 · 2026/8/29 5:26:26 · 阅读 1.2k AI能生成代码，却生成不了企业的真实世界：能力边界与实践路径
如果最近有一部电影能同时让 IT 圈的人和公司管理者坐进同一个放映厅那大概是《奥德赛》。很多人的关注点并不在于剧情本身而在于一个反复出现的隐喻AI 已经能生成一个又一个逼真的世界但那个世界是否真正遵循某种物理法则、社会规则和因果链条你从画面上一眼看不出差距。这个隐喻放在软件开发里几乎一模一样。过去两年AI 编程工具的进步速度快到让人眩晕给一段需求描述一次回车页面能生成接口能生成数据库表能生成连 Dockerfile 都能顺手补齐。于是很多团队开始兴奋地讨论“程序员是不是要被替代了”。可真正在企业系统里试过一遍的人往往会遇到另一种困惑AI 生成的代码确实快但系统里真正负责“企业真实世界”的那部分反而变得很难推进——不是写不出来而是不知道该怎么定义。这篇文章想回答一个问题为什么 AI 可以快速搭建软件却搭不出企业的真实世界以及当我们接受这个边界之后到底应该怎么用 AI 开发软件才能既享受速度又不丢掉企业系统最需要的确定性。文章不会只停留在观点层面我会用一个采购订单模块的最小案例把“代码能跑”和“业务正确”之间的差距拆开来看再给出一条适合团队落地的实践路径。这篇文章真正要解决的问题先说结论AI 擅长的是把“已经定义清楚的需求”快速翻译成代码但它不擅长定义需求本身。企业软件之所以复杂不是因为代码量大而是因为业务规则藏在组织流程、历史数据、合规要求和人的决策习惯里。很多团队在引入 AI 开发工具时真正遇到的不是“代码质量问题”而是“上下文缺失问题”。AI 可以生成一个非常标准的 HTTP 接口但接口背后的审批流、校验规则、数据权限、幂等策略、与第三方系统的闭环并不会因为提示词写得漂亮就自动出现。这些内容必须由人先定义清楚再让 AI 去实现。这篇文章适合三类读者第一类是正在评估“AI 能否替代研发部门”的技术管理者。你需要看到 AI 的能力边界避免把 Demo 当成生产系统。第二类是真正使用 AI 编程工具的开发者。你需要理解为什么 AI 生成的代码偶尔“看起来很对跑起来出事”以及怎么用测试和架构约束把这些风险堵住。第三类是参与企业数字化转型的人。你需要知道AI 的价值不在生成代码那一瞬间而在把业务规则结构化、可验证、可演化的整个过程中。电影《奥德赛》与 AI 软件生成的共同点像不等于真《奥德赛》里最震撼的画面往往是那些由算法生成的宏大场景。你看到一个世界它符合视觉上的直觉光影正确、物体清晰、海面有波涛。但如果你追问这片海域的潮汐规律是什么这位船长根据什么数据决定航线船上的物资能在海上支撑多少天电影并不会回答因为算法生成的只是“看起来合理”的画面而不是一个有完整物理和社会规则的模拟世界。AI 生成软件也是同理。你用 AI 做一个订单管理后台它能生成表单、按钮、表格能创建订单、更新状态、计算金额。表面上这已经是一套能跑的软件了。但企业真正关心的问题往往不在这个表面上订单金额超过多少需要二级审批供应商资质过期了能不能继续下单同一个客户在不同渠道的订单能不能合并结算这些规则如果不在提示词里AI 默认不会知道也不会主动问。这就引出了一个核心概念软件的表面真实和本质真实是两回事。表面真实是代码能编译、接口能请求、页面能交互本质真实是软件在特定企业的组织、流程、合规和商业目标下能否持续输出正确结果。AI 生成软件的速度越快我们越容易把表面真实误当成本质真实。电影里的世界可以只追求“像”企业系统里的世界却不能只要“像”它必须“是”。AI 开发工具的能力边界它擅长什么不擅长什么先把 AI 开发工具能做好的事情说清楚避免走向另一个极端。AI 非常擅长以下几类工作样板代码和脚手架工程。比如生成一个新的服务模块、CRUD 接口、前端页面、数据库迁移脚本。代码解释和遗留系统分析。给 AI 一段老代码让它总结逻辑、标注潜在问题通常效率比人逐行读高得多。单测和边界测试生成。给定一个函数和输入输出示例AI 可以生成不少有价值的测试用例。跨语言翻译和框架迁移。把 Java 代码改成 Go把 Spring Boot 迁移成其他框架AI 能完成大部分机械工作。文档生成和维护。根据代码生成接口文档、数据库字段说明、部署说明能省不少时间。但 AI 不擅长的地方恰好是企业软件最核心的地方定义业务边界。同一个“订单”在电商、制造业、医疗、物流行业里含义完全不同。AI 默认会用互联网常见的订单模型而不是你们公司的订单模型。识别业务不变量。比如“库存不能为负”“每人每周最多提交 3 次申请”“退款金额不能大于实付金额”。这些规则通常散落在制度文件和老员工的脑子里。处理历史包袱。生产环境里的脏数据、旧系统的接口协议、被多个团队共享的数据库表AI 看不到也不会理解。判断非功能需求。接口要在几毫秒内返回数据最多能丢几秒审计日志要保留几年这些问题直接影响系统设计却不能靠“生成”解决。如果把 AI 当成一个极其高效的外包程序员它确实合格。但如果把它当成了解你公司业务的资深架构师它一定不合格。问题的关键不在于 AI 能不能写代码而在于“谁负责把真实世界翻译成 AI 能理解的上下文”。从“订单模块”看真实世界一个最小案例概念讲多了容易飘我们用一个小而完整的采购订单模块来拆解。4.1 AI 生成的“表面正确”代码假设某制造企业需要开发一个采购订单创建接口。你给 AI 一个很常见的 prompt用 Python FastAPI 实现一个采购订单创建接口。请求参数包括供应商ID、商品列表、总金额。AI 大概率会生成类似下面的代码# 文件路径main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class PurchaseOrder(BaseModel): supplier_id: int items: list total_amount: float orders [] app.post(/purchase_orders) def create_po(order: PurchaseOrder): orders.append(order) return {id: len(orders), status: created}这段代码能运行吗能。写入数据了吗写入了。但在真实企业里这段代码大概率不能直接上线。原因不是语法而是它缺少对一个真实采购系统的全部上下文。4.2 真实业务规则开始出现后现在把企业的真实规则加进来。比如只有通过认证的供应商才能创建采购订单。订单总金额超过 100 万时必须进入两级审批。同一供应商如果已经有一笔待审批订单且采购品类相同则不能重复创建。金额计算必须使用 Decimal不能用 float避免精度问题。这些规则看起来不难但每一条都意味着代码结构的变化。下面是加入部分规则后的服务层实现# 文件路径services/purchase_order_service.py from decimal import Decimal from domain.purchase_order import PurchaseOrder, OrderStatus from domain.business_rule_error import BusinessRuleViolation def create_purchase_order(repo, supplier_repo, approval_service, order_draft): supplier supplier_repo.find_by_id(order_draft.supplier_id) if supplier is None or not supplier.verified: raise BusinessRuleViolation(supplier must be verified) po PurchaseOrder( supplier_idsupplier.id, itemsorder_draft.items, total_amountcalculate_total(order_draft.items) ) existing repo.find_pending_po_by_supplier_and_category( supplier.id, po.category ) if existing is not None: raise BusinessRuleViolation(duplicate pending po) if po.total_amount Decimal(1000000.00): po.status OrderStatus.PENDING_APPROVAL approval_service.start_flow(po, level2) repo.save(po) return po def calculate_total(items): return sum((Decimal(str(item.unit_price)) * item.quantity) for item in items)这仍然是一个简化版本但已经能看出来真实业务规则会影响函数输入、状态流转、依赖服务和异常处理。AI 能不能生成这段代码如果提示词写得很细它大概率也能生成。但问题是这些规则从哪来不是 AI 能凭空想出来的而是业务人员、财务人员、采购专员坐在一起经过很多次讨论后才确定下来的。4.3 用测试把业务规则变成可执行约束要保证 AI 生成的代码不会破坏业务规则最有效的方法是把规则转成测试。下面是一个针对“未认证供应商不能下单”的测试# 文件路径tests/test_purchase_order_service.py import pytest from decimal import Decimal from services.purchase_order_service import create_purchase_order from domain.business_rule_error import BusinessRuleViolation def test_cannot_create_po_from_unverified_supplier(): unverified_supplier Supplier(id999, verifiedFalse) repo MemoryRepo() supplier_repo MemoryRepo([unverified_supplier]) approval_service ApprovalService() draft OrderDraft( supplier_id999, items[OrderItem(skuA001, quantity2, unit_priceDecimal(50.00))] ) with pytest.raises(BusinessRuleViolation): create_purchase_order(repo, supplier_repo, approval_service, draft)写这个测试的意义比写业务代码本身更重要。因为它把一条看不见的规则变成了一个每次提交代码都会自动运行的“守门员”。AI 可以快速生成代码但只有人才能决定哪些规则必须被测试固化下来。运行测试的命令很简单pytest tests/test_purchase_order_service.py -v预期输出tests/test_purchase_order_service.py::test_cannot_create_po_from_unverified_supplier PASSED如果这条测试失败说明供应商校验逻辑没有被实现或者被后续 AI 重构时改坏了。企业系统的可靠性本质上就是这样一条一条测试堆起来的而不是靠某一次“生成”完成的。为什么真实世界不能被一次性“喂”给 AI很多人会想既然 AI 生成代码需要上下文那我多写一点提示词把规则全部塞进去不就行了理论上可以但实践中行不通。5.1 企业软件的“上下文”远大于提示词一个运行五年以上的企业系统它的真实上下文包括几十张数据库表的历史含义、多个系统之间对账规则、不同业务部门对同一字段的解释差异、还有因为特殊情况留下的兼容逻辑。这些内容不可能全部写进一次对话的提示词里。更现实的做法是把企业级的上下文拆成两类一类是稳定的业务规则比如“价格必须大于 0”“订单不能重复提交”另一类是不断变化的环境比如某个客户生命周期在某个阶段需要特殊处理。前者可以结构化地描述给 AI后者必须靠持续运维和反馈闭环来修正。5.2 AI 不知道你不知道的规则这是最容易被忽略的一点。企业在招聘新人的时候老员工会告诉他“我们这个系统里有个特殊逻辑三年前因为某个大客户要求加的文档里没写。” AI 也一样它不知道你们企业内部那些“只可意会”的规则。如果 AI 生成代码时没有这些规则它就会用自己从海量公开代码里学到的“通用世界模型”来填空。通用模型对大多数 Demo 有用但对特定企业来说很可能就是错的。尤其是在金融、医疗、制造等强合规行业用通用模型填充特定业务风险极高。5.3 企业系统的确定性要求电影生成允许随机性这次生成的画面不满意可以再生成一次。但企业系统对同一输入必须保证同一输出。订单提交后不能因为某个模型参数变化导致金额计算不同。这种确定性要求决定了 AI 不能作为业务逻辑的唯一决策来源。正确的模式是AI 负责生成实现人负责定义确定性规则测试负责固化规则架构负责隔离变化。只要这个分工清晰AI 才能真正进入企业开发流程而不是停留在玩一玩的层面。企业引入 AI 开发容易踩的四个坑在实际落地过程中我经常看到团队把 AI 开发工具用成“麻烦制造机”问题通常出在以下四个地方。第一个坑把 AI 生成的结果当成需求完成。AI 给出一个订单接口团队直接把接口联调上线但没人校验“审批流是否接入”“金额精度是否正确”。等业务发现数字对不上问题已经埋进生产环境。第二个坑业务人员直接用 AI 工具自建系统。业务部门响应速度慢于是有人用 AI 写脚本处理核心数据比如把手工 Excel 里的数据批量导入数据库。这些脚本没有经过审查没有日志出错后连备份都没有。这实质上是把未受管制的逻辑放进了生产链路。第三个坑AI 生成了大量样板代码却没人维护。AI 一天能生成 3000 行代码很快代码库就膨胀起来。但企业系统维护成本不是按代码行数算的而是按业务逻辑复杂度和依赖关系算的。样板越多依赖越乱后续改动越难。第四个坑让 AI 直接修改生产代码缺少回归测试。AI 重构很快就完成了但没跑测试没看影响范围。上线后出现数据不一致只好回滚。回滚本身并不可怕可怕的是你根本不知道它改了几处地方。这四类问题的根源都一样我们已经非常信任 AI 的执行能力却还没有建立起相应的治理和验证机制。一套落地的 AI 辅助开发流程既然 AI 解决不了“真实世界缺失”的问题那我们应该把它放在一个合适的流程里让它的速度为企业所用同时让企业规则不被稀释。7.1 先写决策记录再让 AI 动手建议在项目里引入轻量级的决策记录文档不需要很长但一定要写清楚为什么会做某个技术选型、为什么某条业务规则存在。比如# ADR-001采购订单金额使用 Decimal ## 背景 财务结算要求金额不能有误差。 使用 float 可能出现 0.1 0.2 不等于 0.3 的问题。 ## 决策 所有金额字段使用 Decimal禁止使用 float。 ## 影响 API 层需要做类型转换数据库字段映射为 decimal 类型。把 ADR 放在仓库里并让 AI 在生成代码前阅读这些文档。如果使用编程 Agent 一类的工具可以把 ADR 作为工作区上下文。这样AI 生成的代码就更容易符合团队已经做过的决策。7.2 用“结构化提示 测试先行”锁定业务规则不要只给 AI 一句话需求而是把业务规则、输入样例、测试预期都写清楚。下面的 prompt 模板比较适合企业场景请基于以下规则实现采购订单创建接口 业务规则 1. 只有已认证供应商可以创建订单。 2. 订单总金额超过 100 万时需要二级审批。 3. 同一供应商、同一品类、存在待审批订单时禁止重复创建。 4. 所有金额使用 Decimal禁止使用 float。 工程约束 - 使用 FastAPI。 - 服务层不直接依赖 HTTP 层。 - 输出单元测试。 请在代码注释中标出每条业务规则对应的实现位置。关键不是 prompt 写得多长而是让 AI 把一个明确规则映射到代码和测试。如果规则有歧义不要直接问 AI“你觉得怎么做”而是让人先开会把歧义消除。7.3 用 CI/CD 守住质量边界AI 生成代码进入主分支之前至少应该经过自动化测试、静态检查和依赖扫描。一个很基础的 CI 配置长这样# 文件路径.github/workflows/ci.yml name: ci on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.12 - name: Install dependencies run: | pip install -r requirements.txt pip install pytest - name: Run tests run: pytest -v如果 AI 生成的代码不能通过这条流水线就不应该进入人工评审环节。这样AI 的“快”和企业的“稳”之间就有了一个强制隔离点。常见问题与排查思路下面这张表列出企业在使用 AI 开发时最容易碰到的问题以及对应的排查方式。遇到问题不要先怀疑 AI 能力先按表里的顺序看。问题现象可能原因排查方式解决方案AI 生成的代码能运行但业务结果不对只描述了功能没有描述业务规则对照需求文档和代码中的规则分支把业务规则写成测试用例建立规则清单AI 重构旧代码后原有功能被破坏回归测试缺失测试覆盖太少查看 git diff运行全量测试在改动前补上关键路径测试小步提交业务人员用 AI 建脚本处理核心数据正常需求响应太慢治理缺失检查有没有未受管制的脚本、报表或数据库连接建设需求通道和自助数据平台同时规范 AI 使用AI 生成依赖有安全漏洞依赖版本过新或存在已知漏洞运行 pip-audit / npm audit 等工具锁定版本加入依赖扫描流程团队内代码风格混乱缺少格式化和架构约束检查 review 记录和静态扫描结果引入 formatter、lint 和架构测试AI 在中间步骤产生幻觉调用了不存在的接口上下文不完整工具权限过高查看 AI 执行日志确认模型上下文缩小任务范围提供准确的接口文档最佳实践与工程建议想让 AI 长期稳定地辅助企业软件研发建议把下面几件事当成制度而不是临时动作。第一先建模后生成。业务边界、领域对象、状态机、权限模型这些高层决策必须由人来定义。AI 可以帮你画草图但负责判断和拍板的一定是团队。第二把业务规则变成资产。为每条核心规则编号例如 R-001、R-002并且在代码里通过注释或测试用例引用对应编号。这样后续 AI 在修改代码时更容易通过上下文找到要遵守的规则。第三测试从业务规则出发而不是只追求覆盖率。覆盖率高低不是核心目标是否正确覆盖了关键不变量才是。一个 60% 覆盖率但覆盖了所有核心规则的测试套件要好过一个 95% 覆盖率却只测了正常路径的测试套件。第四给 AI 工具设置权限边界。不要让 AI 直接操作生产环境数据库也不要让它直接往 main 分支推代码。你要的不是一个“足够自由”的助手而是一个“在边界内高效工作”的助手。第五人工审查不要流于形式。AI 生成的代码审查者必须能回答三个问题这段代码真的满足业务规则吗如果规则变化哪里会受影响异常路径里数据是否保持一致如果审查时回答不了说明上下文还没建好。第六把线上的异常反馈变成新的测试。生产环境出现数据不一致不要只修数据更要追问为什么测试没有提前发现然后把反馈转成测试用例不断逼近企业的真实世界。这些实践看起来不酷但企业系统恰恰是靠着这种“不酷”的确定性才敢支撑每天数百万笔交易。AI 的价值在于压缩实现时间而不是压缩验证和治理环节。结语AI 加快建造但定义世界仍是人的工作回到《奥德赛》那个比喻。AI 可以生成无数个视觉上足够真实的场景但在一场真正的航行中你需要的不是一帧好看的画面而是清晰的航线、可靠的船体结构以及在风暴来临时仍然有效的判断规则。软件也一样。AI 可以把代码这座“建筑”砌得很快但只有人才知道这座建筑为什么存在、给谁使用、哪根柱子不能动。企业的真实世界不是一个提示词就能覆盖的它是一个由组织流程、数据历史、合规要求和人组成的持续演化的系统。如果你正在推进 AI 辅助开发下一步不是去收藏更多的 prompt 模板而是回到办公室里和业务负责人一起把你最核心的订单、审批、对账规则写清楚。把这条规则变成测试放进 CI再让 AI 在那个边界里尽情发挥。这才是 AI 开发工具真正值得被信任的方式。