传统代码、制造业甲方、低代码、AI开发：我的四段从业经历

先说结论

• 实现手段前后换了三种，从写代码、低代码到 AI，有一点没有变过：最难的是判断这条规则、这个口径是不是这家工厂真实的样子。
• 乙方要交的，除了一套能跑的系统，还有这几样：换了人也接得住，改错了能退回去，每一次改动说得清来由。
• 工具一直在换，交付的规矩不该跟着换；每进一家工厂，先挑最痛的一段跑通，再往外扩。
• 我的判断落成两句话：交付不止于上线，要可持续，这些做法我沉淀成了 APSer-Atelier；应用交付之后应当是可进化的，这是我正在自己的项目中尝试的方向。

这篇文章写我自己的从业经历。从 2002 年算起，我在四种位置上做过企业信息化：在软件公司写代码、做项目；在制造业外资企业做甲方的 IT 主管；自己开公司，用低代码平台为客户做了七年交付；2026 年起，自研产品，并用 AI 做定制交付。

乙方和甲方两边都站过以后，我更想做让客户真正用起来、用得满意的交付，让信息化、数字化、智能化落到实处。这是我 2018 年自己出来开公司的原因，也是贯穿这篇文章的一条线。

每一段先写做了什么，再写那一段想明白的事。几段串起来能看到的几条共性，集中放在最后「以下是我的看法」一节。本栏目《二十余年企业信息化的观察》写的是行业的演进，这一篇写的是一个从业者在其中的经历，两篇可以对照着看。

四段的时间、角色和体会，先概括在下表里，每一段的细节见后文。

2002 起 · 写代码的年代：做过开发、测试、实施、售前、顾问，想明白了什么？

这一段做了什么

2002 年，我在软件公司开始做企业信息化，站在乙方，也就是为客户做系统的一方。

这一段我先后做过开发、测试、实施、售前和顾问。在一个项目里，前几个岗位是前后相接的：售前和顾问在签约前把需求问清楚、把方案讲明白，开发把方案写成代码，测试核对写得对不对，实施把系统装进客户现场、导入数据、教会使用的人。

这一段想明白的事

售前演示和沟通的功能，落地时普遍有差异。 这一段我既做过售前，也做过实施，两头都经历过：售前阶段演示的多是标准产品或样板数据，沟通的是方案上的功能；到了实施，才碰上这家客户真实的数据、流程和例外情况，演示时顺畅的功能，落地时要么对不上，要么要返工。这在行业里是普遍的痛点，客户在签约前看到的，和最后用上的，中间常常隔着一段距离。后面几段里，低代码让客户更早看到按自己业务搭出的系统，原型工具把需求拆成每一步都摊开给客户看，都是在缩短这段距离。

「系统问题归根到底是业务问题」这句话，是这一段的实施经历和下一段的甲方经历一起让我意识到的，放到下一段一起说。

2010 起 · 在制造业外企做甲方 IT 主管，想明白了什么？

这一段做了什么

2010 年，我换到了甲方，在一家千人规模的制造业外资企业做 IT 主管、经理，其间主导过 MES 系统的改造。

从这时起，我的位置倒了过来：之前是给客户做系统的一方，现在是用系统、管系统，也要去找软件公司做系统的一方。

这一段想明白的事

做实施时，我是把系统装进客户现场的人；到了甲方，我是天天用系统、管系统的人。两边的经历合在一起，让我意识到：系统问题，归根到底是业务问题。

2018 起 · 用低代码做了七年交付，想明白了什么？

这一段做了什么

2018 年，我创办了青岛艾普仕软件科技，起因就是开头说的那件事：想做让客户真正用起来、用得满意的交付。

公司名 APSer 最初取的是「APS 团队」的意思，现在的含义是 AI Powered Service。

那时我一直在想一个问题，2020 年在一次公开课上讲「中小企业信息化的难题与对策」时，归纳成了三条。一是预算有限：中小企业没法像大企业那样一次性采购和实施大型系统，只能小步快跑。二是知识储备有限：信息化需要的知识，除了 IT 技术，更重要的是把业务流程分析清楚、讲清楚的能力。三是需求一直在变：成品软件很难按一家企业的需要灵活调整；最初做系统的人一换，新接手的人对系统和业务都不够了解，需求一变就很难及时跟上。对做信息化服务的一方来说，问题就变成：有没有一种做法，能在企业有限的预算里做到按需定制、随需而变。

我前后评估过几类低代码产品，最后选了葡萄城活字格低代码平台，作为这七年交付的主要实现手段。当时看重的几条是：能部署在客户自己的服务器上，支持手机端，能多人协同开发，价格合适；遇到复杂一些的业务，可以直接操作数据库，也可以写代码扩展。

这七年做过的项目，方向包括工厂、实验室、设备选型和成本指标管理等。

举一个我在 2021 年底一次低代码研讨会上分享过的项目。客户是一家原材料加工企业：一套成品 ERP 用了近十年，没法二次开发；财务系统独立在外，缺少接口；还有一套早年自己搭的报价系统，近几年又买了在线的客户管理和办公系统。数据散在好几处，对不上。这个项目先把报价、进销存、生产管理、发货、应收与发票、客户管理这些功能整合进一个系统，再在上面补上办公流程和车间看板，把业务数据和财务数据打通。为了降低培训成本，新系统的界面和老系统保持一致，员工原来怎么操作，上了新系统还怎么操作。

这一段想明白的事

唯有定制，才能真正解决好制造业场景的整体需求。 原材料加工那个项目里，成品 ERP、独立的财务系统、早年自己搭的报价系统、后来买的在线客户管理和办公系统，单看每一套都能用，放在一起却对不上：每一套只照顾自己那一段，工厂的整体需求落在几套系统之间的缝隙里。把报价、进销存、生产、发货、应收与发票接成一条线，只能按这家工厂自己的流程来做。制造业每家工厂的工艺、口径和管理习惯各不相同，成品软件能覆盖其中一段，整体要靠定制才接得住。这是我后来把定制交付当作主业的原因，《唯有定制：把系统做进每一家工厂自己的工艺流》专门写过这条主张。

低代码降低了做一套贴身系统的成本。 表单、流程、报表可以很快搭起来，客户能更早看到、更早用上，改起来也快。葡萄城活字格的新版本已经对 AI 开放，低代码和 AI 可以在同一次交付里配合使用。

新系统要先接住已有的数据和习惯。 原材料加工那个项目的顺序，是先整合、把数据对上，再扩展新功能；界面沿用老系统，是为了让员工不必从头学起。

2026 起 · 用 AI 做自研平台、产品与定制交付，想明白了什么？

这一段做了什么

2026 年 4 月，我把 AI 正式引入交付流程。我的想法是把 AI 当放大器：把多年的交付经验、踩过的坑、沉淀下来的方法，做成 AI 能复用的工具和规矩，每一项改动都有计划、有审核、有验证记录，可追溯、可回退。

现在的青岛艾普仕是一人公司：由我主导交付，AI 编程工具承担大量执行工作。2026 年用的工具主要是两家：4 月起以 Claude Code 为主，8 月上旬转到 Codex，8 月底起两家并用。

2026 年上半年，我做了一个给同行用的小工具：把客户几句话的需求分四步变成一套可演示的原型，每一步的产出都能单独看、单独改、单独重跑；模型默认在本地运行，客户资料不离开开发者的电脑。

这一年做的事，大体分三块。

定制交付。 制造业深度定制化交付仍是主业，做过的行业有注塑、五金、电子整机、铸造、假发、化工等。2026 年在做的定制交付里，有电子整机行业的生产排程（APS）项目；铸造里精密熔模铸造这一细分的工艺特点与数字化切入点，写在《精密熔模铸造的数字化：先看清工艺链，再决定从哪里下手》里。

自研产品。 APSer-One 是制造运营管理平台，APSer-Aps 是生产排程系统，两款产品是我做定制交付的底座，按工厂的实际情况组合与定制。APSer-One 在 2026 年成型，APSer-Aps 目前处在试点共创阶段。APSer-Aps 怎样搭建、大模型在里面做哪几件事，写在《APSer-Aps 的技术选型、系统架构与 AI 能力：思考与实践》里。

自研平台。 APSer-Atelier 是我在自己交付中使用的工作平台，定位是「可持续交付的底座」。它起步时只想解决几件具体的事，后来每碰到一个真实的痛点，就长出一种做法：换一段对话，进度就接不上；汇报说完成了，其实没有在真实环境里核过；几件事同时推进，改动互相覆盖；换了 AI 工具，原来的规矩悄无声息地失效；上线的改动出了问题，找不回上一个验证过的版本。它的来历和边界，写在《APSer-Atelier 的场景锚定与价值定位，以及实践总结》里。APSer-Atelier 目前仍在持续打磨中。

这一段想明白的事

写的成本降了，判断的成本没降。 AI 写界面、写报表、写常规代码很快；生成的逻辑是否符合这家工厂的真实口径，仍要懂行的人逐条确认。改动变快以后，计划、复核、留痕、回退这几件事的分量反而更重了。

自己检查自己，容易看不出问题。 这一年体会最深的两点：执行的一方核对自己的结果，往往看不出错；只写在提醒里的规矩，忙起来就会被跳过。所以产出和检查要分开，一家工具写完，由另一家只读复审；最要紧的几条规矩放进日常流程，让流程自己把关，不靠记性。

规矩和知识要放在任何一家工具之外。 换工具时最费力的，是那些只写在一家工具专用文件和私有记忆里的规矩与经验。项目的知识写进项目自己的、多家工具都能读的开放格式文档，换人、换工具都能接手。

每一步摊开，客户才能跟着改。 那个原型小工具的取舍，是把每一步的产出都摊开给人看：客户改一句需求，只需动其中一两步，不必从头重跑。模型默认在本地运行，客户资料不离开开发者的电脑。本地部署的现实考量，我在《数据不出厂：制造企业用大模型时，本地部署的现实考量》里单独写过。

以下是我的看法

以下是我个人的看法，来自上面四段经历，没有统计数据支撑，您可以对照自己的经验判断。

一、信息化、数字化、智能化，要落到实处。 乙方和甲方两边都站过，我更想做让客户真正用起来、用得满意的交付，这是我 2018 年自己出来开公司的原因。落到实处，在我看来就是下面几条：弄清业务、交得完整、规矩稳定、先让一段真正用起来。

二、系统问题，归根到底是业务问题。 这句话是实施的经历和甲方的经历一起让我想明白的。后来做低代码交付，我在公开课上讲，信息化需要的知识，更重要的是把业务流程分析清楚、讲清楚的能力。到了用 AI 的这一年，写代码的成本降下来了，最难的仍是判断：这条规则、这个口径，是不是这家工厂真实的样子。实现手段换了几代，这一点没有变过。

三、站过甲方，才知道乙方该交什么。 一套系统交出去，客户要用上好几年。2020 年我在公开课上讲过，最初做系统的人一换，新接手的人对系统和业务都不够了解，这是中小企业信息化的一个难处。所以乙方要交的，除了一套能跑的系统，还有这几样：换了人也接得住，改错了能退回去，每一次改动说得清来由。2026 年做 APSer-Atelier，追的也是这几件事：每一次改动可追溯，出了问题能回到上一个验证过的版本，项目知识写在开放格式的文档里，交付给客户的系统独立运行。系统上线之后由谁来照看，我在《系统上线之后，谁来对它负责》里专门写过。

四、工具一直在换，交付的规矩不该跟着换。 从 2002 年写代码，到 2018 年起用低代码平台，再到 2026 年用 AI，实现手段前后用过三种。我以前写过一句话：这些年换过几种角色，有一条主线没变，就是用最少的技术债，解决最具体的业务问题。2026 年换 AI 工具时，我吃过一次亏：规矩写在一家工具的专用文件里，换了工具，规矩悄无声息地失效了。规矩稳定下来，工具才可以放心地换。

五、先把一段跑通，再往外扩。 中小企业预算有限，只能小步快跑，这是我 2020 年在公开课上讲的第一条难处。原材料加工那个项目，也是先整合、打通数据，再补看板和办公流程。2026 年做制造业交付也是这样：每进一家工厂，先挑最痛的一段跑通，再往外扩。

二十多年实践下来，我的判断落成了哪两句话？

AI 的浪潮汹涌澎湃，企业应用何去何从？回头看这三十多年，潮流一波接一波：1990 年代的办公自动化（OA）、流程再造与 ERP，2000 年代的商业智能（BI）、业务流程管理（BPM）、云与 SaaS 订阅，企业应用也在这时按业务域被切成 ERP、MES、APS、SRM、CRM 各管一段的套件；2010 年代的低代码与中台，再到这几年的本体论、AI 原生与智能体。二十多年，从写代码的乙方，到管系统的甲方，再到自己做交付、做产品，我在实践里的判断落成了两句话。

第一，交付不止于上线，要可持续。 一套系统交到客户手里，要用上好几年。每一次改动都有计划、有核验、有记录；改坏了，能回到上一个验证过的版本；项目知识写在开放格式的文档里，换人、换工具都接得住。我把这些做法沉淀成了 APSer-Atelier，它是我给自己的交付搭的「可持续交付的底座」。模型和工具会一代代更替，这块底座上的规矩不变。

第二，应用交付之后，应当是可进化的。 过去的企业系统，交付那天往往就是它最贴合业务的一天：业务在变，系统跟不上，只能等下一轮项目。让系统在交付之后自己跟着业务变，业内几十年里反复尝试过：自主计算、让用户自己改系统、用模型推导代码，却一直没能真正落地，这段历史我梳理在《企业系统交付之后如何持续变化：六十年理念谱系与教训》里。我在实践中感受到，这个思路在 AI 加持下有了新的机遇：大模型把「改」的成本降下来了，可持续交付的底座把「改对、改稳、改错能退」管住了，两者合在一起，我相信应用可以在交付之后继续生长：在客户的日常使用中积累业务规则和现场经验，由懂业务的人确认，小步、可追溯、可回退地持续改进，越用越贴合这家工厂。这是我正在自己的项目中尝试的方向，《APSer-Atelier 的场景锚定与价值定位，以及实践总结》里写过它的由来。

这两句话，一句管「交付之后不塌」，一句管「交付之后还能长」。

青岛艾普仕以制造业深度定制化交付为主业，做过注塑、五金、电子整机、铸造、假发、化工等行业，自研 APSer-One 制造运营平台与 APSer-Aps 生产排程系统。如果您的工厂正在考虑上一套系统，或者希望手里的系统越用越好，欢迎预约交流。