产线工程:人机协同构建任何系统的统一方法论

一篇独立长文。 它从「在线书城 → AI 写书工厂」的真实协作过程中抽象而来,但目标不是复述某个项目,而是提炼一套可迁移到任何系统的构建方法——软件产品、内部工具、数据平台、运营流程、乃至 AIGC 工厂,都共用同一套骨架。

读者假设:你有一个模糊想法,手边有 Opus 4.8(或同级推理模型)和 Cursor(或同级 agent IDE),想把想法变成可运行、可演进、可放量的系统。

一、我们在解决什么问题

1.1 两种失败的构建方式

失败方式 A:作坊式构建

开一个对话,扔一段 prompt,得到一段代码或文档,复制粘贴,再开下一个对话。
特征:无计划、无状态、无复用、无验证、上下文随对话蒸发。
结果:能做出惊艳的片段,拼不出稳定的系统;第二遍几乎从零开始。

失败方式 B:瀑布式构建

先写厚需求、画全架构、列全模块,Months 后才开始写第一行能跑的代码。
特征:前期假设过多,第一次集成往往很晚,第一次集成往往很痛。
结果:方向可能在集成前就已偏了;变更成本极高;团队(或人机)在漫长前期失去反馈。

1.2 产线工程要替代的,是这两种极端

产线工程(Production Line Engineering) 的核心主张:

构建任何系统,都应像建一座工厂,而不是开一间作坊,也不是画一张永远落不了地的蓝图。

工厂思维要求五样东西同时成立:

意图清晰(知道造什么)
结构显式(知道东西怎么流转)
切片可通(整条链路先跑通,再加深)
资产可复(越做越厚,边际成本递减)
交付可证(每一级都有实证,不靠声称)

这套方法不绑定 React、FastAPI、MiniMax 或 Docker。它们是某次实例化的材料;骨架才是可迁移的。

1.3 本文与《AIGC 工厂方法论》的关系

aigc-factory-methodology/ 是领域版:把骨架落在「AI 批量生产内容」上,含写书案例、网文技巧库、LLM 适配层等具体映射。

本文是元版:只谈骨架,并给出跨域映射表——让你能把同一套步骤用到 ERP、爬虫平台、客服机器人、甚至非软件的运营 SOP 上。

二、元模型:任何系统 = 意图 × 结构 × 执行 × 演化

在谈步骤之前,先固定一个高度抽象的系统定义。任何「系统」,无论软硬,都可以被拆成四个正交维度:

维度	回答的问题	若缺失会怎样
意图 Intent	为谁、解决什么、边界在哪	越做越散,无法验收
结构 Structure	元素如何组织、如何流转、状态如何变化	无法并行、无法自动化、无法排错
执行 Execution	谁/什么在什么时候做什么动作	只有图,没有产线
演化 Evolution	反馈如何进入下一轮、资产如何沉淀	一次性交付,无法逼近正确

关键洞见:大多数构建失败,不是「执行能力」不够,而是在结构未显式化之前就开始执行,或在意图未对齐时就开始结构。

产线工程做的,就是强制四个维度按可验证的顺序展开——这就是后面的七步法。

flowchart LR
    I["意图\nIntent"] --> S["结构\nStructure"]
    S --> E["执行\nExecution"]
    E --> V["验证\nEvidence"]
    V -->|反馈| I
    E -.沉淀.-> A["资产\nAssets"]
    A -.复用.-> E

三、三个不变量(贯穿任何系统、任何技术栈)

在七步的具体动作之上,有三条不变量。违反任意一条,系统迟早塌:

不变量 1:决策上行,执行下行

你(人) 保留:愿景、品味、关键取舍、红线、最终验收。
Opus 保留:结构化、规划、实现、推理、跨文件一致性。
Cursor 保留:读写文件、跑命令、查库、验证回路。

决策不能无声地下沉到模型里(模型会替你「赌」架构岔路);执行不能反复上行来找你点按钮(你会变成流水线工人)。

检验法:回顾最近一次构建,有哪些架构级选择是 AI 默默替你做的?那些都应被拉回到「分层澄清」里由你拍板。

不变量 2:先通切片,再挖深井

垂直切片(Vertical Slice):用最小真实实现,把「输入 → 全工序 → 输出」整条链路跑通一次;允许中间环节是 mock/占位/手工。

垂直深井(Vertical Silo):先把某个模块(如「支付」「写作」「报表」)做到极深,再考虑和上下游对接。

为什么切片优先:集成风险是乘法——模块各自 90 分,串起来可能是 0 分。切片把集成风险前置且最小化;深井把集成风险后置且最大化。

跨域例子:

电商:先「假库存 + 假支付 + 真下单流」跑通,再接真实支付。
数据平台:先「假数据源 + 真调度 + 真落库」跑通,再接生产数据源。
运营 SOP:先「纸面走通全流程一次」,再工具化每一段。

不变量 3:实证先于声称

「应该可以」「我觉得没问题」「理论上能跑」——在产线工程里不算交付。

交付必须附带可复现的实证,且分级递进:

占位/mock 级(证明结构通)
单元/适配级(证明关键边界正确)
真实依赖级(证明接真实世界仍成立)
目标环境级(证明在 Docker/生产形态仍成立)
回归级(证明没破坏已有能力)

检验法:你的项目里,有没有任何一个「已完成」事项,是没有对应命令输出、测试日志或产物字节数佐证的?

四、七步法:构建任何系统的统一流程

七步不是「做软件的项目管理」,而是任何系统从模糊到可交付的通用路径。每一步给出:定义 → 输入 → 输出 → 具体动作 → 完成判据(DoD) → 反模式 → 跨域映射。

整体顺序:

① 愿景对齐 → ② 分层澄清 → ③ 计划契约 → ④ 垂直切片
→ ⑤ 资产化 → ⑥ 质检与人在环 → ⑦ 验证驱动交付 → (反馈) → ① …

第①步:愿景对齐 —— 把模糊压缩成「可复述的一句话」

定义把多方(至少:你 + Opus)对「要建什么」的理解,压缩成一句话,且双方确认无歧义。

输入

模糊意图(可以很不完整)
已知约束(时间、预算、合规、技术偏好——若有)

输出

愿景句:为 [谁] 在 [场景] 提供 [能力/价值], 受 [关键约束] 限制, 当前阶段目标是 [里程碑].
复述确认:Opus 用它的语言重述,并列出隐含假设。

具体动作(按序执行)

你写愿景句(哪怕很粗糙)。
Opus 复述 + 列出隐含假设 + 指出歧义点(不问细节,只问「理解是否一致」)。
你纠正,直到双方对同一句话点头。
禁止在此步讨论技术选型、表结构、UI 配色。

DoD

愿景句双方书面一致。
愿景句里没有实现细节(那些属于第②③步)。

反模式

愿景 = 功能清单(「要有 A、B、C、D…」)——那是范围,不是愿景。
跳过复述,直接开干。

跨域映射

系统类型	愿景句示例
在线书城	为读者提供可购买且可在线阅读的电子书体验,先本地 Docker 可跑
AI 写书工厂	为运营者提供从选题到 PDF 上架的批量生产能力,人机协同、可并行
内部审批流	为财务提供报销从提交到打款的全链路可审计流程,先覆盖 80% 场景
数据标注平台	为算法团队提供样本分发、标注、质检、回灌的一站式平台

第②步:分层澄清 —— 用最少问题锁死架构岔路

定义在不展开实现的前提下,用分层、带选项的决定性问题,消除会显著改变结构的不确定性。

输入

已对齐的愿景句

输出

决策记录:每个决定性问题 → 你的选择 → 一句话理由
通常 6–12 条决策,分 3 层,每层 ≤3 题

三层澄清模型(通用)

层	问什么	典型问题形态
定位层	系统「是什么 / 不是什么」	核心对象是什么?边界外什么不做?
范围层	本期交付 vs 后置	哪些能力本期必须有?哪些明确不做?
结构层	形态与依赖	单体还是分布式?同步还是异步?谁依赖谁?

决定性问题必须满足:

答案会显著改变数据模型、模块边界、或工作量一个数量级。
现在不问,后面返工成本高。

具体动作

Opus 按三层各提 ≤3 题,每题必须:选项 A/B/C + 推荐 + 推荐理由。
你做选择题(可以选推荐,也可以 override)。
所有选择写入决策记录(后续计划的约束)。

DoD

没有「重大架构后果」的问题还悬而未决。
决策记录可读、可引用。

反模式

开放式问答题:「你想怎么做?」
琐碎题:不影响结构的 UI 细节。
决策不记录,导致后面争论「当时不是说好了吗」。

跨域映射

系统类型	定位层示例	范围层示例	结构层示例
书城	卖+读 vs 只卖	支付 mock vs 真实	前后端分离 vs 一体
写书工厂	产线 vs 单次工具	多角色权限本期 vs 后置	Anthropic 端点 vs OpenAI 端点
审批流	仅报销 vs 全费用	移动端本期 vs 后置	嵌入现有 OA vs 独立系统

第③步:计划契约 —— 把「怎么做」变成可勾选的合同

定义产出一份结构化计划:有依赖顺序的 todo、每条可独立验收、标注人机责任;过大则分期。

输入

愿景句 + 决策记录

输出

Todo 列表:每条含 id、描述、依赖、DoD、责任(AI/人)
分期边界(若需要):Plan 1 / Plan 2…
人必做清单:无法自动化的项(合规、开户、物理世界动作)单独列出

Todo 合格标准(每条必须满足)

可独立完成:不隐含「顺便把别的也做了」。
可验收:完成与否可二元判断。
范围有界:通常 0.5–2 天人机协同可完成;过大则拆。

具体动作

Opus 根据决策记录拆 todo,标依赖(如:数据模型 → API → UI)。
标注 AI / 人 / AI+人。
把合规、资质、上架审批等抽成 SOP-人,不混进代码 todo。
你审范围:砍不必要的、确认分期。
计划落盘(文件/todo 工具),作为单一事实源。

DoD

全部 todo 满足合格标准。
你确认「这一期做完 = 可交付的切片或增量」。

反模式

「做后端」「做前端」——不可验收。
计划只在对话里,不落盘——上下文蒸发后全丢。
一期塞入三期工作量——必然烂尾。

第④步:垂直切片 —— 用 mock 证明「管道是通的」

定义在不追求单点深度的前提下,实现最小版本,使真实数据(或占位数据)能沿全部工序从头流到尾。

输入

计划中的 todo(至少覆盖主路径)
对外部依赖的识别(第三方 API、支付、模型、硬件…)

输出

可运行的主路径:从触发到最终产物/状态的一次完整流转
外部依赖的适配层 + mock 实现
显式状态机(系统/工单/实体在工序间的状态)
端到端 smoke 实证

具体动作(通用模板)

画主路径状态机:列出所有工序与状态转移(这是自动化的前提)。
识别外部依赖:对每个依赖定义接口,实现 mock/stub。
实现最薄真实逻辑:工序可调用、状态可持久、UI/API 可触发。
禁止在此步优化单点质量(内容好看、性能极致、UI 精美)。
跑 E2E smoke:一次完整触发 → 检查最终状态/产物存在。

DoD

mock 模式下主路径跑通。
切换 mock → 真实依赖的开关已就位(配置/适配层)。
有 smoke 实证(日志/截图/产物)。

反模式

先做「最难模块」三个月,不串联。
mock 与真实逻辑耦死,无法切换。
无状态机,只有「一堆接口」——无法知道「现在到哪了」。

跨域映射

系统类型	主路径	mock 什么
书城	浏览→加购→下单→支付→解锁阅读	支付回调
写书工厂	立项→大纲→写作→质检→导出→上架	LLM 返回占位文本
审批流	提交→审批→财务→打款	银行接口
标注平台	领任务→标注→提交→质检→回灌	模型推理

本案例的关键设计:LLM 适配层 + mock 供应商,使无 API Key 时整条写书管线仍真实流转——这是垂直切片在 AI 系统里的标准范式。

第⑤步:资产化 —— 把「一次性劳动」变成「可复用资产」

定义识别系统中会被反复使用的元素,将其数据化、入库、可检索、可组合,使第二轮构建边际成本下降。

输入

已跑通的主路径
你对业务「什么会复用」的判断

输出

资产库(一种或多种):模板、规范、人格/角色、技巧片段、组件、脚手架…
生成 → 入库 → 套用 闭环
种子数据:开箱即用的首批资产

资产化的判据(满足任一条就应考虑)

会在 ≥3 次交付中重复出现。
变更时应改一处、全局生效,而非改 N 份拷贝。
可由 AI 生成草案,人审定后入库。

具体动作

列出候选资产(你定「什么值得沉淀」,Opus 定「怎么存、怎么接」)。
为每类资产设计:数据模型 + CRUD + 在流水线中的注入点。
把「工艺知识」从代码里抽到数据(prompt 片段、配置、模板),而非 hardcode。
写种子,让系统空载可用。
逐个工序把 mock 换成真实实现,并加深质量。

DoD

至少一类资产库可用、可生成、可在新产品/新任务中组合。
真实依赖已接入主路径。

反模式

每个项目 copy-paste 改一份模板。
资产库有了但流水线不注入——库成了摆设。

跨域映射

系统类型	典型资产
写书工厂	选题库、作者人格、写作 skill、HTML 模板
前端产品	组件库、设计 token、页面模板
数据平台	指标口径、SQL 片段、质检规则
客服系统	话术库、意图模板、升级策略

第⑥步:质检与人在环 —— 给系统装「闸门」,不是「提醒」

定义在关键节点设置可量化、可阻断的检查;在必须人担责的节点保留人工;全程留痕。

输入

质量基线(你定):什么算达标、什么算失败
红线(你定):什么绝对不能碰
必审节点(你定):哪些步骤不能自动放行

输出

自动检查 + 阈值 + 状态机联动(不达标 → 打回/阻断)
合规/标识/审计机制(视领域而定)
人工复审入口 + 结论留痕
调用/流转/决策 追溯记录

四道防线(任何系统通用)

源头约束:在生成/执行前注入规范(提示词、schema、校验规则)。
自动质检:量化指标 + 阈值 + 阻断。
合规闸门:红线命中 → 停 → 人审。
人工抽检/必审:正常路径抽检;红线/上架/对外发布必审。

DoD

不达标产物无法静默进入下一阶段。
必审节点有人工入口且留痕。
你能回答:「这个产物何时、经何工序、谁批准、花多少成本」。

反模式

质检只打 log 不阻断。
自动化把「上架/对外发布/合规签字」也自动掉。
无留痕——出事后无法定责。

第⑦步:验证驱动交付 —— 分级实证,实证才算数

定义按固定级别逐级验证,每级产出可复现证据;你基于证据做最终验收。

验证阶梯(任何系统通用)

级别	证明什么	典型证据
L0 mock	主路径结构正确	E2E smoke 通过
L1 单元/适配	关键边界正确	桩测试输出
L2 真实依赖	接真实世界仍成立	真实 API 调用、真实产物指标
L3 目标环境	部署形态成立	容器/预发/生产 smoke
L4 回归	未破坏已有能力	构建通过、全量/关键用例

具体动作

按 L0→L4 顺序执行,不可跳级声称完成。
出错:先读日志/产物定位根因,再改(禁止靠猜)。
清理临时脚本与测试垃圾。
你验收:只看证据,不看口头承诺。

DoD

L0–L4 中本期承诺的级别均有证据。
已知问题写入「未来债」清单,而非假装不存在。

反模式

只在开发机验证,不上目标环境。
把「构建失败但功能应该没问题」当交付。

五、五层元架构:任何系统的「厂内布局」

七步是时间上的流程;五层是空间上的结构。任何系统都可以被映射进这五层——名字可以换,职责不变:

flowchart TB
    subgraph L5["⑤ 仪表 Observability"]
        m["指标 / 告警 / 成本 / 良率"]
    end
    subgraph L4["④ 质检 Quality Gates"]
        q["自动检查 / 合规 / 人审"]
    end
    subgraph L2["② 工位 Pipeline"]
        p["工序状态机 / 可独立触发"]
    end
    subgraph L3["③ 工装 Assets"]
        a["可复用模板 / 规范 / 组件"]
    end
    subgraph L1["① 原料 Inputs"]
        r["结构化输入库 / 需求池"]
    end
    L1 --> L2
    L3 -.注入.-> L2
    L2 --> L4 --> L5

元层	抽象职责	软件产品	非软件流程
① 原料	结构化、可检索的输入	需求池、工单、样本	客户需求池、订单池
② 工位	有状态的工序链	状态机、流水线 stage	审批节点、生产工序
③ 工装	可复用工艺	组件库、模板、skill	SOP 模板、检查表
④ 质检	阻断式关卡	测试、lint、安全扫描	检验工序、合规签字
⑤ 仪表	可观测	日志、指标、成本	产能报表、良率

再加三条传动轴(任何系统都应有):

依赖适配轴:外部能力(模型、支付、存储…)经接口接入,可 mock、可切换。
并行/编排轴:无顺序依赖的单元可并行;整体可被调度器/Agent 驱动。
留痕轴:每次动作可追溯——自动化程度越高,越救命。

六、螺旋演化:系统不是设计出来的,是长出来的

不要追求一次规划出终态系统。 正确预期是多圈螺旋,每圈交付一个可运行增量:

圈 1: 最小可交付(如:书城能卖能读)
圈 2: 核心能力扩展(如:AI 生产管线)
圈 3: 工厂化(如:工作室 + 并行 + 多格式)
圈 N: 自动化 + 分发 + 商业化闭环 …

每圈复用上一圈的:

适配层(不必换模型就换整套代码)
资产库(作者/模板/组件越积越厚)
验证体系(在原有 L0–L4 上追加,而非重写)

每圈回到第①步,但带着真实反馈:

「控制台感觉没接后端」→ 发现 mock 默认值造成认知偏差 → 下一圈改可观测性。
「create job 500」→ 发现 schema 未迁移 → 下一圈补迁移机制。

这就是「演化 > 规划」:方法论的价值不是一次全对,而是每圈都交付、都复用、都更接近终态。

七、从手动到无人值守:自动化的普适路径

自动化不是第七步的附属,而是系统成熟后的升维。但顺序不能错:

手动(L1) → 一键串行(L2) → 事件/定时驱动(L3)
                ↑                    ↑
           前提:状态机显式      前提:质检闸门阻断式
                              前提:成本/熔断/急停

L3 无人值守 的五部件(与具体工具无关):

触发器:定时、事件、Webhook、库存阈值…
编排器:队列、调度、重试、持久化、DAG
Worker:执行单元(可以是脚本,也可以是有界自主的 Agent)
质量闸门:不达标进不了交付;异常进人工队列
仪表 + 反馈:产能/成本/良率回流,调节并发与模型

Worker 的「有界自主」(Bounded Autonomy)——无论 OpenClaw、Hermes、Cursor Agent 还是 Temporal Activity,都必须:

目标边界(工单含 DoD)
工具边界(最小权限)
资源边界(token/费用/时长/重试上限)
质量边界(过闸门才算完成)
升级边界(红线/超限 → 停 → 找人)

再次强调:没有第⑥步的阻断式质检,就不要开 L3。否则你是自动化地批量制造废品。

八、扩展到「任何系统」:一张总映射表

方法论要素	AIGC 写书工厂	普通 SaaS	数据/ML 平台	运营/组织流程
愿景对齐	批量产书盈利	解决某垂直场景	样本→模型闭环	降本增效可度量
分层澄清	热点源/PDF引擎/权限	租户模型/计费/集成	批流/特征存储	审批层级/例外
计划契约	Plan1/Plan2 分期	MVP/GA 分期	采集→训练→ serving	阶段 rollout
垂直切片	mock LLM 跑通管线	假支付跑通交易	假数据跑通 pipeline	纸面走通全流程
资产化	作者/skill/模板库	组件/设计系统	特征/规则/口径库	SOP/检查表库
质检	字数/重复/敏感/标识	测试/安全/性能	分布漂移/准确率	检验/审计
验证	mock→真实→Docker	单测→集成→预发	离线→在线→回滚	试点→推广
自动化	并行写章→批次产书	CI/CD→定时任务	调度→AutoML	RPA→人机协同

结论:行在变,列(七步 + 五层 + 三轴)不变。学会列,就能迁移行。

九、人机协同构建任何系统:一页纸总纲

9.1 流程总纲(七步)

① 愿景对齐   — 一句话,双方复述一致,无实现细节
② 分层澄清   — 定位/范围/结构,决定性问题,选项+推荐,决策记录
③ 计划契约   — 可验收 todo,人机责任,过大则分期,落盘
④ 垂直切片   — 状态机 + 适配/mock + 主路径 smoke,先通后深
⑤ 资产化     — 复用元素入库,生成→套用,种子,接真实依赖
⑥ 质检人在环 — 阻断式闸门,合规,必审留痕
⑦ 验证交付   — L0→L4 分级实证,出错先看日志,你只看证据验收
∞  反馈回环   — 带着真实问题回①,复用资产与适配层

9.2 结构总纲(五层 + 三轴)

原料(输入库) → 工位(状态机流水线) ← 工装(资产库)
                    ↓
              质检(阻断) → 仪表(指标)
依赖适配轴 | 并行编排轴 | 留痕追溯轴 — 贯穿全厂

9.3 三个不变量

决策上行,执行下行
先通切片,再挖深井
实证先于声称

9.4 自动化前提(开 L3 前自检)

[ ] 状态机显式且持久化
[ ] 工序幂等,重试安全
[ ] 单工单有成本/时长/重试上限
[ ] 质检不达标会阻断,不是只警告
[ ] 红线有人工升级队列
[ ] 全程留痕
[ ] 仪表可见产能/成本/良率
[ ] 有全局急停

十、收束:从「做项目」到「建产线」

大多数人在用 AI 构建系统时,仍在做项目——目标是一次性交付,交付完团队(或对话)解散,经验随风而去。

产线工程要求你做产线——目标是一台能反复运行、越跑越顺、越跑越便宜的机器。项目问「这次交付了吗」;产线问「下一轮能不能更省力、更稳、更便宜地交付」。

Opus 4.8 × Cursor 不是来替代你当厂长的。它们是:

一个能在几小时内产出过去几周代码量的总工;
一个能 7×24 跑命令、读日志、改文件的车间;

而你,是那个定义产品、拍板岔路、守住红线、决定何时放量、对最终后果负责的人。

构建任何系统,最终都是同一件事:

把意图变成结构,把结构变成可通的切片,把切片变成可复用的资产,把资产放进带闸门的产线,用实证证明产线在跑,然后一圈圈把它养大。

这就是产线工程。产品会变,技术会变,模型会变;这套骨架不变。

本文与 aigc-factory-methodology/ 互为元版与领域版:本文讲「如何建任何系统」;该系列讲「如何建 AIGC 工厂」并含完整案例与 SOP。建议先读本文建立骨架,再读该系列看落地。