三天后，一切开始分崩离析。
在过去的一年里，人工智能编程工具彻底改变了我编写软件的方式。
Cursor。
Claude Code。
GitHub Copilot。
OpenAI Codex。
它们已成为我日常工作流程的一部分。
我可以在几分钟内搭建应用程序接口（API）的骨架。
几乎可以瞬间生成 React 组件。
编写文档的速度比以往任何时候都快。
说实话，这令人印象深刻。
几个月前，我决定看看自己能将其推向何种程度。
我挑战自己，以最快的速度构建一个人工智能驱动的应用程序。
在大约三十分钟内，我就做出了一个真正能运行的东西。
用户界面看起来很简洁。
应用程序接口（API）响应正确。
演示效果令人信服。
我很兴奋。
三天后……
我发现自己不得不重写大部分代码。
这并不是因为人工智能生成了糟糕的代码。
而是因为我跳过了软件工程的关键步骤。
人工智能并非问题的根源
人们很容易归咎于工具。
但工具并不是问题所在。
代码大体上没问题。
真正的问题在于，我只优化了一个指标：
速度。
我没有花足够的时间去思考：
- 数据模型
- 业务规则
- 架构
- 服务边界
- 错误处理
- 长期可维护性
应用程序能运行。
但系统不能。
这两者之间存在巨大差异。
构建功能不等于构建系统
现代人工智能在生成代码方面表现出色。
让它构建：
- 身份验证
- 增删改查（CRUD）端点
- React 仪表板
- FastAPI 路由
- 结构化查询语言（SQL）查询
你很可能会得到一些有用的东西。
但生产环境中的软件不仅仅是功能的集合。
它是决策的集合。
例如以下问题：
- 业务逻辑应该放在哪里？
- 哪个服务拥有这些数据？
- 我们如何对应用程序接口（API）进行版本控制？
- 当下游服务失败时会发生什么？
- 哪个组件将成为唯一真实数据源？
这些不是代码生成问题。
它们是工程问题。
无人谈论的架构债务
我们经常谈论技术债务。
最近，我开始思考另一种债务。
架构债务。
当软件的增长速度超过理解速度时，就会产生这种债务。
每一个由人工智能生成的功能都会引入一个新的假设。
一个新的依赖项。
一个捷径。
一条重复的业务规则。
一切仍然正常运行……
直到它无法运行为止。
一个真实案例
最近，我为企业财务自动化项目开发了一个交易智能系统。
乍一看，这个项目像是另一个自然语言处理（NLP）管道。
获取银行对账单。
提取实体。
返回 JavaScript 对象表示法（JSON）。
很简单。
但事实并非如此。
在训练模型之前，我必须设计：
- 规范数据模型
- 业务分类法
- 合成数据集
- 实体关系
- 对账规则
- 评估管道
具有讽刺意味的是……
人工智能模型反而是较简单的部分之一。
困难的部分在于理解业务。
人工智能可以生成代码。
但它无法创造你的业务。
想象一下向人工智能助手提问：
“发票 MFG-INV-000157 已经支付了吗？”
除非有人已经构建了
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
