用 SysFactory 把业务想法做成可用系统

甲方的业务专家知道很多系统应该怎样工作。谁提交、谁审核，哪些信息必须填写，什么情况需要退回，哪些例外要交给负责人。他能把业务说清楚，却经常需要经过需求文档、产品设计和开发排期，才能拿到一个可以试用的版本。

我做 SysFactory，希望缩短这段距离。业务专家用自然语言说出想要的功能，产品把需求交给 Agent 和服务端工程环境，产出带前端、后端、数据库和版本管理的可用 IT 系统。专家打开系统，用实际案例检查，再继续说出需要调整的地方。

这样，一项业务想法可以更早进入试用。流程是否合理、信息是否足够、岗位之间能否顺畅交接，都能在操作中发现。原型开发门槛降低之后，专家有机会在投入大规模建设之前，先验证业务可行性。

专家说业务，产品承接开发

此前在《别急着裁掉中层，先用 Agent 生态放大业务专家》里，我写过专家的价值。他知道规则成立的条件，见过流程失效的例外，也能判断哪些调整会牵涉成本和风险。这些经验经常藏在日常工作中，很难靠一次需求访谈完整地传递出去。

SysFactory 给这些判断提供一个更直接的出口。专家可以说“普通员工只能看自己的申请”“退回时必须填写原因”“负责人可以转交，但要留下记录”。产品负责把这些话整理成具体功能和验收条件，再落实到系统中。遇到含糊的地方，Agent 继续追问，专家补充业务规则。

对非研发人员来说，这段交互不应要求他理解 Agent 的执行方式。他不用研究上下文怎样组装、工具怎样调用，也不用决定代码放在哪个目录、测试命令怎样运行。使用者需要看见的是需求是否理解正确，功能做到哪一步，以及什么时候可以打开系统检查。

这也是我在业务专家与 AI 实习生的文章中讨论过的工作关系。专家表达目标、检查结果、纠正偏差，Agent 承担具体工作。SysFactory 把这段协作落在软件建设上，让专家在使用过程中逐步把业务规则补进系统。

用成熟 Agent 做内核，把 Harness 放进 Worker

SysFactory 直接使用 Claude Code（CC）、Codex、Pi 作为 Agent 内核，承接需求理解和编码工作。产品围绕这些内核组织业务输入、执行环境和交付结果，把编码能力接到一套完整的软件建设流程中。

服务端 Worker 内嵌 Harness 流程。这里的 Harness，可以理解为让 Agent 持续完成工作的工程环境：准备项目上下文，限定本轮修改范围，组织分析和实现，执行检查，保存结果，再推进到预览与交付。

Agent 负责理解和修改，Worker 负责把过程组织起来。一次模型回答结束后，后续构建、测试和版本处理仍由工程流程接着推进。业务专家不用把这些步骤写成提示词，也不用在不同工具之间手动搬运代码、检查结果和需求说明。

这种分工也解释了稳定性从哪里来。Agent 有明确的起点和任务范围，脚手架提供一致的基础结构，Worker 用固定流程检查产物。发现问题后，继续围绕同一份需求和项目修正，避免每轮都从零生成一个互不相干的系统。

这些工程安排需要由产品维护。专家可以了解发生了什么，但日常使用不必依赖他掌握研发流程。

Worker 把 Agent 内核、脚手架和检查流程组织在一起，业务专家通过需求与结果参与建设。

脚手架把功能落到前后端和数据库

业务专家说“我要一个申请系统”，通常已经包含了几层要求。页面负责录入和查看，后端负责校验与流程，数据库负责保存记录，权限决定谁能看到和修改什么。只有把这些部分接起来，专家才能拿业务案例完整地走一遍。

SysFactory 用业务脚手架作为建设起点。前端采用 React，后端采用 FastAPI，数据存储采用 SQLite，并配有用户、登录、角色权限和数据库迁移基础。Worker 在这个结构上建设具体业务功能，让每轮开发沿用统一的项目组织和运行方式。

以维修登记为例，专家可以这样提出需求：

做一个维修登记系统。员工提交设备和故障说明，维修负责人安排处理，申请人可以查看进度。普通员工只看自己的记录，负责人能查看全部待处理事项。

这个示例需要同时形成提交页面、列表和详情，后端的创建、查询与状态变更接口，以及保存设备、申请人和处理进度的数据结构。角色权限也要贯穿页面和接口。专家检查的是“这个人能不能完成这件事”，产品要把对应的技术部分一起组织好。

基础脚手架提供通用能力，具体业务模块由需求驱动建设。这样可以在已有结构上逐步增加字段、流程和规则。专家说“增加退回原因”，这项修改就需要一路落实到输入、校验、存储和展示，后续试用还能看到之前保存的记录。

可用的原型因此能够承载连续操作。提交后留下数据，换一个角色继续处理，再回来查看结果。业务讨论也有了具体对象，大家能围绕同一套系统核对自己的理解。

系统随着反馈迭代，也带着版本往前走

业务规则很少在第一轮就全部说完。看到页面以后，专家会发现字段顺序不顺手；换一个岗位试用，才发现权限少了一层；拿例外案例走流程，又会补出新的处理条件。

SysFactory 的工作台把业务页面和 Agent 对话放在一起。专家可以直接描述修改，也可以点选元素、框选区域或在截图上标记，再说“这里加一个筛选条件”“这个状态还要显示处理人”。页面位置和说明一起进入需求，减少双方猜测讨论对象的时间。

修改继续在同一个任务的开发环境中进行。专家看预览、补条件、检查下一轮结果，直到准备好验收。开发环境与正式版本分开，测试库和正式业务数据也分别维护，探索中的修改有自己的空间。

版本管理贯穿这段过程。需求和后续修改保留记录，代码变更进入任务工作区，检查与发布结果关联对应版本。专家可以知道这次增加了什么、正式系统现在是哪一版，以及哪些调整还在开发中。

这让原型能够继续生长。第一轮先完成主要路径，后续补上例外、报表或新的岗位流程，已有需求和数据都需要纳入下一轮考虑。版本记录也给协作留下依据，方便业务人员与技术人员核对每次调整的范围。

专家在试用中补充规则，系统持续修改，需求与版本记录跟着每轮迭代保留下来。

用可运行的系统验证业务想法

SysFactory 要降低的是尝试一项业务方案的成本。专家提出一个想法，得到可操作的系统，邀请相关岗位用案例走一遍，再决定怎样调整以及是否继续投入。

维修登记的例子里，申请人可以检查信息是否容易填写，负责人可以检查分派和处理是否顺畅。重复申请、设备信息不完整、任务转交等情况，也能拿到原型里讨论。问题会落到具体页面、数据和角色上，专家更容易指出缺的条件。

Worker 的工程检查负责确认软件按要求运行，业务专家则判断这套方案是否适合现场。系统能提交申请之后，还要看填写过程是否增加负担，处理人是否拿到了足够信息，状态变化是否符合实际工作。业务可行性由这些试用结果来支持。

如果方案需要调整，专家继续用自然语言补充需求。如果流程本身不值得推进，也可以在原型阶段停下来。每次尝试留下的规则、案例和版本，都能帮助下一轮讨论从更具体的位置开始。

我希望 SysFactory 能让业务专家把更多时间用在这些判断上：想要什么功能，哪些条件必须保留，实际使用中哪里不合适。Agent 内核、Worker 的 Harness 和业务脚手架承接开发过程，把专家的表达转成一个可以打开、操作、验证并持续修改的系统。