ARTICLE · 1042942
AI时代你才是自己最好的产品经理-懂业务的人自己写软件
AI时代你才是自己最好的产品经理-懂业务的人自己写软件供应商交期又变了，采购员还在翻聊天记录。车间等着物料，主管催着报表。明明只想把几件事管顺，却迟迟找不到顺手的软件。 每天最清楚问题的人，能不能亲手把工具做出来？ 
我的观点很明确：“AI时代，使用者开发软件才是王道。” 
谁每天使用，谁就应当参与定义功能、验证流程、推动迭代。软件开发的起点，应该回到业务现场。 2026年9月19日晚20点，AI工程师训练营第三期第一次课程《零代码手搓软件》如期举行。30多名学员通过2个多小时的学习，多名学员在零代码基础的前提下，手搓出WEB软件，虽然只有前端，但是很多人都非常兴奋，其中一位负责采购岗位的学员。他列出新增供应商、交期维护等日常需求。借助AI，做出了SRM供应商管理系统的前端。 前端做出来，距离正式上线还有工作要做。使用者已经可以把经验，变成看得见、点得动的原型。 过去只能口头解释的需求，现在可以打开页面，逐项核对。哪个字段缺了，哪一步多余，谁该收到提醒，都能谈得更具体。 业务人员的核心价值 业务人员最有价值的能力，是知道事情究竟怎样发生。 采购知道交期为什么一改再改。班组长知道报工为什么容易漏填。质量人员知道异常为什么总关不掉。那些表格之外的判断，恰恰决定了工具是否好用。 需求经过多次转述，容易漏掉条件。比如一句“增加交期提醒”，里面就藏着许多问题：提前几天提醒？提醒采购还是供应商？交期改了，旧记录还留不留？ 使用者直接参与开发，就能把这些条件带进设计。AI负责辅助整理和实现，人负责判断业务是否成立。沟通越贴近实际操作，返工就越有机会减少。 不过，只有一句“帮我做个系统”，还不足以让AI准确理解你的工作。页面可以很漂亮，流程却可能走不通。功能可以很多，最常用的操作却可能藏得很深。 架构大师的作用 孔德高老师开发的“架构大师”，正是从需求梳理这一步切入。 它对应软件开发蓝图技能，帮助使用者把想法整理成可评审的方案。先明确谁使用、解决什么问题。再梳理业务流程、功能模块、数据关系和接口要求。 
它还会围绕项目约束，安排开发计划、验收标准与后续迭代。预算、周期和已有系统，都要进入考虑范围。开发因此有了可以核对的依据。 这份蓝图需要交给AI编程工具或开发人员继续实施。涉及权限、数据和正式上线的工作，也需要相应验证。架构大师的价值，在于帮助你把开发任务讲清楚。 从零做工具的方法 不妨以一个交期跟踪工具为例。第一版只聚焦一件事：让采购及时找到可能延误的订单。 先列清供应商、订单号、物料、承诺交期和责任人。再定义逾期怎样判断，交期变更由谁记录。随后，把“登记订单、更新交期、查看异常”做成一条完整流程。 验收也要具体：录入一笔测试订单，修改一次交期，再检查异常列表。能否看到变更记录？责任人是否明确？发现问题，就回到对应环节调整。 等这条流程稳定，再考虑送货单和供应商评分。每增加一项功能，都回答同一个问题：它解决了使用者哪件麻烦事？ 先把一个问题解决扎实，再扩大软件的能力。 第一版可以简单，业务规则必须认真。按钮能点击，只是开始；异常能处理、结果能核对，才有继续使用的基础。 对于精益管理者，改善方案还能进一步变成日常工具。把检查项目变成录入项，把异常处理变成待办，把复核要求变成验收条件。 一次改善，便有机会留下持续使用的工作方法。后续发现新问题，再由使用者提出修改，让工具跟着现场一起进步。 从小开始学习实践 学习的入口也可以很小。从自己反复填写的一张表开始，带上真实流程、现有样表和判断规则。先用脱敏样例试做，再验证结果是否符合业务要求。 把“谁在什么情况下做什么”说明白，才能判断AI的方案是否合适。懂业务的经验，由此成为开发软件的重要基础。 AI时代，企业值得培养一批能发现问题、讲清需求、验证工具的使用者。让他们从工作中提出问题，再用做出来的工具回答问题。 下一款真正适合你的软件，可以从你最熟悉的那件小事开始。 想把自己的业务经验做成工具，可以了解孔德高老师的“架构大师”与AI精益实践VIP尊享班。带着一个具体问题来，从需求梳理开始动手。下方是AI技能全景图与课程海报，欢迎扫码交流。 
01
02
03
04