当一个人拥有AI软件工厂:我是如何用一天时间构建制造业产品知识操作系统的

当一个人拥有AI软件工厂：我是如何用一天时间构建制造业产品知识操作系统的

副标题：产品元认知（二）｜从架构设计到运行服务，一个AI时代的软件工程实践案例

过去二十多年，我参与过不少企业数字化项目。

ERP、MES、WMS、CRM、SRM、OA，一路做下来，我对软件开发形成了一套很稳定的认识：先调研，后立项；产品经理整理需求，架构师设计方案，开发人员写代码，测试人员验证，实施顾问再把系统带到现场。

一个企业应用，从需求讨论到能跑起来，几周很正常，几个月也不稀奇。

但今天，我经历了一次完全不同的软件生产过程。

从制造业产品知识的领域模型开始，到 PostgreSQL 运行环境、Schema、Migration、ORM，再到产品身份、证据、关系、审核和审计服务，以及相应的 API 基础，一套产品知识操作系统的后端骨架，在一天内建立起来并完成了第一轮运行验证。

我必须先说明：这不是说一天做完了一套可以直接全公司上线的成熟系统。

生产部署、性能、安全、监控、数据迁移、用户体验和现场推广，仍然要继续做。今天完成的是一个边界清楚、能够运行、可以继续迭代的后端基础。

即便如此，这件事还是让我重新理解了“软件开发”。

一、我不是让AI帮我写几段代码

很多人把 AI 编程理解成：把需求丢给 ChatGPT，让它生成几个函数，遇到报错再让它修。

如果只是这样使用，AI 的确只是一个更快的代码助手。它能提高局部效率，却很难改变项目的整体质量。

今天真正发生的，不是“AI替我写代码”，而是我和 AI 组成了一个小型软件工厂。

整个过程沿着一条连续的工程主线展开：

战略目标，决定这个系统为什么存在；

领域模型，定义产品、产品族、产品平台、主型、变体和 ERP 实体之间的关系；

架构设计，确定数据、服务、接口和权限怎样分层；

治理规则，约束证据、审核、版本和审计如何发生；

数据库设计，把业务对象变成可运行的 Schema；

工程实现，再逐步进入 Migration、ORM、Service 和 API；

最后通过测试和回滚验证，确认这套基础不是“看起来完整”，而是真的能够运行。

AI 在这条链上不是一个随叫随到的代码生成器。它更像一组可以高速协作的工程角色：整理文档、展开方案、实现代码、补充测试、检查遗漏、汇报结果。

而我负责的是另一类工作：判断方向、定义边界、冻结架构、处理取舍、决定什么可以接受。

这两类工作不能倒过来。

二、一天为什么能推进到过去一两周的位置

表面看，这是开发速度变快了。

但我今天最深的感受是，真正被压缩的并不是敲键盘的时间，而是项目中大量看不见的等待、转述和知识损失。

1. 业务理解不再层层转译

传统项目中，业务先向产品经理讲一遍，产品经理写成需求；架构师读需求后形成设计，开发再根据设计理解业务；测试人员最后从功能角度重新解释一次。

每转一层，信息都会损失一点。

到了开发现场，经常只剩下一句“这个字段要不要必填”，却没人再记得这个字段背后原本要控制什么经营风险。

今天的协作方式缩短了这条链路。

我可以直接把业务判断转成领域模型，再把领域模型转成架构和任务；AI 在同一上下文中继续实现和验证。为什么这样设计、哪些方案已经否定、哪些边界不能突破，都留在同一条工程记忆里。

这相当于给项目建立了一个持续工作的数字项目大脑。

2. 方案讨论和工程实现不再彼此等待

过去，架构方案写完，要等开发理解；开发发现问题，再约架构师讨论；数据库有调整，又要通知接口和测试。很多项目时间不是花在创造上，而是花在排队上。

AI 协作把这些动作拉近了。

领域对象一旦确定，就可以马上检查数据约束；Schema 确定后，可以立即生成 Migration 并验证；Service 实现后，接口和测试可以接着推进。

这不是跳过工程步骤，而是让原本串行等待的工作形成高密度反馈。

3. 规范在编码之前进入项目

很多软件项目慢，不是因为团队能力不足，而是代码开始得太早，架构结束得太晚。

需求还没讲清楚，表先建了；权限还没定义，接口已经写了；版本和审计没有设计，数据却开始导入。后面每解决一个遗漏，都要牵动一片代码。

今天我们先确定领域边界、身份规则、证据来源、审核机制、审计要求和 Migration 策略，再进入实现。

先设计，形成约束，再写代码。

前面多想半小时，后面可能少返工几天。

三、今天到底完成了什么

今天完成的，是制造业产品知识操作系统的后端基础形态。

第一部分是产品知识领域模型。

我们不再把“产品”等同于一个 ERP 料号，而是区分产品族、产品平台、产品主型、产品变体和 ERP 实体。这样才能解释同一基础机型为什么会因为颜色、材料、尺寸、客户要求和包装方式形成多个业务身份。

第二部分是数据运行基础。

PostgreSQL 运行环境、Schema、Migration 和 ORM 已经建立起来。业务概念不再停留在文档和图里，而是变成可以创建、变更、回滚和查询的数据结构。

第三部分是核心业务服务。

产品身份服务负责回答“它是谁”；Evidence 服务负责记录“这个判断依据什么”；Relationship 服务连接产品、物料、图纸和其他知识对象；Review 服务承接人工审核；Audit 服务记录谁在什么时间做了什么变更。

第四部分是应用接口基础。

Product、Identifier、Evidence、Relationship 和 Review 等 API 已经形成第一版。后续无论是管理后台、知识工作台，还是 AI Agent，都可以在同一套受控服务上继续生长。

这还不是一个完整产品，但已经不再是演示页面。

Demo 的目标是证明一个想法能被看见；工程基础的目标，是让后续能力能够在边界内持续增加。

四、AI速度很快，质量会不会失控

会。

如果把一句模糊需求交给 AI，让它自行决定数据模型、权限和接口，然后看到程序能启动就宣布完成，质量很可能比传统开发更差。

AI 最大的风险并不是不会写代码，而是它可以非常快地把一个错误假设实现得很完整。

所以，AI 软件工厂必须有质量闸门。

今天的质量控制不是最后“跑一下看看”，而是分布在工程主线里：Schema 要评审，Migration 要正向执行也要考虑回滚，权限要验证，审核状态要测试，Audit 要确认关键动作是否留下记录，服务和 API 还要检查边界是否一致。

人的验收不能只看代码数量，也不能只看页面能不能打开。

要看业务对象是否定义正确，关系是否允许错误合并，证据是否可追踪，权限是否可能越界，变更失败后能否恢复。

AI 提高的是工程吞吐量。工程标准不能因此降低，反而要更早、更明确。

五、一个人真的可以替代七到十个人吗

这个问题很诱人，但答案不能说得太轻率。

传统小型企业软件团队，往往包含产品经理、架构师、后端开发、数据库工程师、测试和项目经理。AI 软件工厂确实可以把其中大量文档、编码、测试准备和工程整理工作压缩到一个人加一组 AI 协作者上。

但这不等于一个人天然拥有七到十个人的全部能力。

一个人真正被放大的，是已经具备的判断力。

如果他理解业务，做过系统，知道数据为什么会失真，也经历过权限、版本和组织协同的问题，AI 可以把这些经验迅速转成模型、代码和测试。

如果他不理解业务，只会不断发指令，AI 同样会放大他的盲区。

所以，我更愿意把这件事理解为“组织杠杆”，而不是简单减员。

过去，一个有经验的人要通过会议、文档和团队分工把想法变成系统。现在，他可以先拥有一支随时可调用的数字工程队伍，把自己的判断更快地变成可验证的工程结果。

到了生产化、复杂前端、现场实施、安全攻防和大规模运维阶段，专业人员仍然重要。AI 改变的是团队起步方式和角色密度，不是宣布所有专业分工从此消失。

六、制造业为什么尤其需要AI软件工厂

制造业并不缺系统，也不缺文件。

真正难的是，知识长期分散在人和部门之间。

产品负责人知道产品规划，销售知道客户叫法，研发知道图纸，工程知道 BOM 和工艺，生产知道什么东西做不稳，品质知道问题从哪里反复出现，财务知道哪些产品看起来卖得多却没有利润。

这些知识很难直接交给一个通用软件公司。

外部团队可以开发功能，却需要很长时间理解企业为什么这样做；企业内部的人懂现场，却常常没有足够的研发资源把认识变成软件。

AI 软件工厂刚好把这两端拉近。

懂业务的人可以先把产品认知变成领域模型，把经验变成规则，把规则变成数据和服务，再让专业团队在这个基础上继续强化。企业不必从一张空白需求表开始，也不必把所有判断外包给供应商。

这对制造企业尤其重要，因为可以外包开发工作，但不能外包产品认知和业务裁决。

七、真正改变的，是软件生产关系

过去的软件工业建立在专业分工上。分工解决了规模问题，也带来了沟通成本。

AI 软件工厂没有取消工程纪律，它改变了知识在项目里的流动方式。

一个业务判断可以更快进入模型，一个模型可以更快进入数据库，一个规则可以更快变成服务，一个问题也可以更快回到设计源头。

未来有价值的软件工程人才，未必是写代码最多的人。

他要能定义问题，建立模型，管理复杂度，识别风险，也要知道怎样把任务交给不同的 AI 工具，并对结果负责。

这个角色越来越接近“数字产品架构师”：既懂企业，又能设计系统；既能驾驭 AI，也知道什么时候不能相信 AI。

八、这一天真正证明了什么

今天没有证明“软件从此可以一天做完”。

它证明了另一件更实际的事：一个懂业务、懂架构、懂管理的人，在方法、流程和工程纪律的约束下，可以拥有过去一个小型软件团队在项目早期阶段的生产能力。

这个能力不是来自某一句神奇提示词，也不只属于某一个模型。

它来自一套可以迁移的工作方式：把战略目标转成领域模型，把领域模型转成架构约束，把架构约束转成工程任务，再通过测试、审计和回滚把结果收回来。

模型可以更换，工具会继续变化，但这套方法可以留在企业手里。

这也是我最看重的地方。

企业未来不一定需要无限扩大程序员队伍，但需要培养一批真正的数字产品架构师。他们懂现场，能建立模型，会管理 AI，也能把一次项目成果沉淀成企业自己的数字资产。

结语：软件工厂不是少几个人，而是让经验开始复利

今天，我们没有完成一个简单的软件功能。

我们做了一次新的软件生产实验：让个人经验进入领域模型，让领域模型进入软件工程，再让软件工程承载制造业知识。

一天只是这次实验的时间尺度，不是值得炫耀的数字。

真正值得重视的是，过去只能留在一个人脑中的判断，开始变成可以运行、可以审核、可以迭代的系统能力。

当一个人拥有 AI 软件工厂，他获得的不是一支永远正确的自动编程队伍。

他获得的是一种新的可能：把多年积累的业务经验，以过去难以想象的速度，转化为企业能够长期使用的数字资产。

这可能才是 AI 时代软件工程最有价值的变化。