如果最近有一部电影能同时让 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_id=supplier.id, items=order_draft.items, total_amount=calculate_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, level=2) 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(id=999, verified=False) repo = MemoryRepo() supplier_repo = MemoryRepo([unverified_supplier]) approval_service = ApprovalService() draft = OrderDraft( supplier_id=999, items=[OrderItem(sku="A001", quantity=2, unit_price=Decimal("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/checkout@v4 - uses: actions/setup-python@v5 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 开发工具真正值得被信任的方式。
