10个 关键问题 Q&A

1. Q：Agentic SDLC 和软件工厂的核心区别是什么？ A：Agentic SDLC 只是智能体参与开发流程；软件工厂是一套完整生产系统，定义权责、校验、权限与故障兜底。
2. Q：什么是 L4 软件工程？ A：限定业务域内，系统可自主走完授权变更流程、完成核验与安全止损，故障遏制不需要人工紧急接管。
3. Q：优先级 “系统＞智能体＞LLM” 怎么理解？ A：大模型和智能体只是能力组件，系统决定它能拿到什么信息、做什么动作、输出上线需要哪些证据。
4. Q：L3 和 L4 最核心分界线？ A：L3 故障或审批必须依赖人兜底接管；L4 可自主遏制风险，仅在进入安全态后才请求人协助。
5. Q：为什么不优先追求 L5 黑灯工厂？ A：L5 要求覆盖全部软件工程工作，不确定性和风险极高，有边界 L4 才是可落地的务实目标。
6. Q：迈向 L4 首先要做什么？ A：划定适用边界：仓库、变更类型、权限、开销上限，明确哪些任务禁止自主执行。
7. Q：如何避免智能体 “骗过测试”？ A：搭建独立校验体系，验收规则受保护，配套仿真、场景用例，校验主体不能由生成智能体控制。
8. Q：评估工厂好坏应该看哪些指标？ A：合格任务正确率、人工干预频次、逃逸问题数量、故障损失，而不是智能体数量、代码行数。
9. Q：软件工厂 “所有权” 指什么？ A：团队掌控上下文、架构、验收标准、权限、运行边界，能够诊断故障、持续改造这套生产系统。
10. Q：L4 工厂落地的迭代方式？ A：从小范围低风险场景试点，记录每一次人工干预，区分是补充能力还是永久禁止自治，渐进扩容。

智能体驱动的软件开发生命周期（Agentic SDLC）本身并不等同于软件工厂，工程团队需要清醒认知二者差异，并牢牢把握主导权。

工程师可以抽身处理其他事务，与此同时，智能体独立完成编码、执行测试、响应评审意见、提交合并请求。把多个这类智能体串联起来，就能覆盖软件开发生命周期里的大部分环节（当然，如果设计不当、缺少沙箱隔离，也可能引发意外风险）。规划环节交由智能体完成，编码实现交由智能体完成，评审与测试同样交由智能体完成。

这无疑是一场意义重大的变革。但在我看来，行业的步子迈得太快了：大家直接从 “智能体参与软件开发生命周期” 跳到了 “我们已经拥有软件工厂”。

而这两个论断之间的空白地带，正是当下软件工程工作的重心所在（也是正在发生变革的地方）。工程团队最持久的竞争优势，也蕴藏于此 —— 哪怕工厂里大部分能力都是外购而来。

我坚信，软件工厂是我们所有人应当奔赴的正确方向。当编码实现的成本持续降低，真正的机会在于优化整套体系：把一个想法，转化为可发布、可监控、高质量的软件。关键在于，这个可行的目标是有边界的自主能力：一套工厂系统，能够完成指定类型的工作、产出可证明成果满足需求的证据，并且在任务失败时自主处置，不必每次都等待工程师介入救场。

我把这个目标定义为 L4 级软件工程。

为什么工厂才是优化的核心单元

编码提速改变了软件开发的成本结构，但并不会自动提升交付质量。如果生成一段代码变更只需要几分钟，而厘清它带来的连锁影响要耗费数小时，那么生成能力只是加速了整个流程里的其中一环。剩余的工作还包括：确定到底要改什么、守住架构约束、核查下游影响、确认改动真正符合用户需求。

工厂模式，让我们可以主动、系统性地打磨这套完整流程。我们可以优化需求转化为可执行校验规则的方式、让组织知识精准触达对应的智能体、完善变更验证机制、把失败案例沉淀为后续任务的经验。对这套系统的一次优化，能够惠及后续成千上万次代码变更。

在一些头部团队的落地实践中，这一趋势已经显现。OpenAI 的《Harness Engineering》一文提到，工程师着力搭建运行环境、沉淀仓库知识、固化架构约束，并围绕编码智能体搭建反馈闭环。最重要的转变在于：工程投入的价值开始复利累积。

对我而言，优先级排序是：系统 > 智能体 > 大模型。模型能力很重要，智能体的设计也很重要。但系统决定了这些能力承接什么样的工作、可以调用哪些信息、允许执行哪些操作、输出上线前必须提供哪些校验证据。

更强的模型可以优化这套系统，但单凭模型本身，无法定义一家组织能够承受的风险边界。

智能体驱动的 SDLC 描述的是 “参与度”；而工厂定义的是 “责任边界”。

一套智能体 SDLC，虽然每个环节都有智能体参与，但依然依赖人串联各个阶段、处理所有高难度的判断。工程师需要澄清需求、修正方案、解读失败的测试结果、核查下游依赖、最终判定变更是否可以上线。

这套工作流可以拥有很高的产出效率，代码甚至几乎全部由智能体生成。但这两点，都无法说明交付系统本身拥有多大自主能力。

Stripe 的技术博客《Minions: Stripe’s One-Shot End-to-End Coding Agents》清晰点明了这个区别。Stripe 搭建了无人值守智能体，能够承接任务，走完编码、持续集成流程，最终产出等待人工评审的合并请求。这已经是很高程度的自动化，但人工评审环节被明确保留。

本文语境下所说的软件工厂，是承载这项工作的整套生产体系：输入信息、上下文环境、执行沙箱、校验规则、权限体系、发布机制与反馈链路。工厂可以具备不同等级的自主能力。在全生命周期接入智能体，是迈向工厂的重要一步，但这不代表工厂可以承接哪些责任。

核心问题在于：这套系统，能否在授权范围内走完一整套变更流程，而不需要人反复介入、补齐关键判断。

从自动驾驶自主分级获得的启发

软件自主能力分级体系早已有人提出。Dan Shapiro 的文章《The Five Levels from Spicy Autocomplete to the Software Factory》就是一例。我认为这个类比很有价值，但需要提前说明：下文这套软件工程分级只是一个提议框架，并非行业标准。

自动驾驶领域最关键的分界是 L3 和 L4。依据 SAE J3016 标准：L3 自动驾驶可以在限定条件下运行，但随时要求人类接管；L4 在限定运行域内运行，不需要人类接管来规避风险；L5 自动驾驶则覆盖人类可以驾驶的全部场景。

由此可见，L4 不等于无所不能、无处不在。它的运行边界，是其能力的根基。

迁移到软件工程领域，我做如下定义：

• L0
  人主导执行，搭配传统自动化工具
• L1
  AI 辅助单点工作，工程师全程主导任务走向
• L2
  智能体执行大块任务，但工程师持续监督、校验、串联结果
• L3（智能体 SDLC）
  系统可以在限定条件下运行交付流程，但人是必要的审批方或者故障兜底方
• L4（常态化自主软件工厂）
  针对某一类划定范围的变更，可以独立走完授权流程，包含校验、允许范围内的发布动作、安全降级，出现故障时不需要人紧急介入止损。“常态化自主” 不代表工程师退场，他们依然掌握工厂边界的定义权与迭代权
• L5（全自主黑灯工厂）
  把这套自主能力拓展到软件工程所有类型工作。这个目标宏大得多，即便达成，依然需要明确目标、权限与问责机制。

这些分级必须绑定特定工作流与业务域。一个团队可以针对内部服务的常规变更做到 L4，而支付鉴权相关变更依旧保持严格人工管控。如果笼统宣称整个组织达到 L4，就掩盖了这个最核心的差异。

关键一步：设计边界

从智能体 SDLC 迈向 L4，我们必须明确：哪些场景下，自主执行是被允许的。

首先界定工作本身：包含哪些代码仓库、变更类型、依赖项、运行环境？权限范围、资源开销上限是多少？哪些任务不允许交给自主流程？常规依赖包升级和核心鉴权模型修改，不该拥有同等权限 —— 哪怕同一个智能体都能尝试处理这两类任务。

其次，把成功标准转化为系统可以评估的形式。工单描述很少是一份完备规格书。相关需求可能散落在架构决策文档、故障历史、客户承诺、工程师的经验里。工厂必须获取这些上下文，并且在编码落地、把假设固化成功能之前，识别出模糊不清的地方。

校验机制，还必须抵御代码生成环节本身的投机倾向。StrongDM 的工厂网站提出两个极具冲击力的准则：“代码不由人类编写”、“代码不由人类评审”。更值得关注的是支撑这两条准则的底层机制：场景用例、验证套件、外部依赖的行为模拟器。StrongDM 将场景用例独立于代码库之外存放，避免智能体只是单纯 “骗过测试用例”，却没有实现预期业务行为。

这指向一条通用要求：负责生成变更的智能体，不能私自修改判定变更是否通过的校验条件。

独立校验，需要有受保护的验收标准、独立权限、基于可观测行为的核验。仅仅给第二个智能体贴上 “评审员” 标签，算不上独立校验。两个智能体完全可能共享同一个错误假设。

Anthropic 的工程文章《Harness Design for Long-Running Apps》也印证了这点：拆分评估环节会有帮助，但评估智能体本身也需要校准，并且存在固有局限。校验体系本身就是一套需要持续评估的工程系统。

Dex Horthy 的视频提出了一个很现实的挑战：完成短期任务通过测试，和在数月周期里维持代码库可维护性，是两个完全不同的目标。我不会把当下测试用例全部跑通，当作工厂能够保障未来系统可修改的证据。架构与程序设计必须设置显式约束，持续追踪多次变更叠加带来的长期影响。

证据优先，而非主观信心

工厂应当产出一份可审计记录，说明一项变更为什么允许推进：它解决了什么需求、通过了哪些检查、遵守了哪些约束、部署结果如何、还有哪些未消除的不确定性。

一部分证据来自确定性校验；一部分来自仿真、对抗测试、模型辅助评审、线上观测。没有任何一种方式可以绝对证明代码正确。但所有证据结合起来，可以支撑在既定边界内做出决策。

这套严谨标准同样适用于对工厂本身的评估。智能体数量、生成代码行数、无人值守运行时长，只能体现工作量。我更关心：符合准入条件的任务正确完成率、剩余人工工作量、哪些问题绕过了校验、故障带来的损失。被驳回的任务、紧急人工干预，都要纳入统计。

证据体系同样要支撑故障发生时的处置。这也是自动驾驶 L4 类比里最有价值的一点。

在软件场景里，安全兜底方案可以是暂缓发布、停止灰度、关闭功能、回滚版本。但回滚不是永远可行，破坏性的数据迁移就无法回滚。工厂启动执行之前，运行边界就必须把这类风险纳入考量。

系统可以在进入安全状态之后再请求人类协助。真正让这套流程达到 L4 的核心是：遏制故障恶化，不需要人立刻复盘完整运行过程、接管处置。

这个标准，远高于让智能体通宵跑任务。

所有权优先于编码实现

如果这就是我们前进的方向，工程团队必须掌握自家软件工厂的主导权。

这里所说的所有权，指掌控决定工厂产出、判定结果是否合格的关键决策：组织上下文、架构规范、验收标准、权限、证据规则、运行边界。团队同时要有能力诊断故障、迭代这套生产系统本身。

一套可落地的工厂，会融合团队原生工作流、专用智能体与平台。举个例子，专门的代码评审智能体，需要配套上下文、工具集、面向缺陷发现的评估体系。选型时，要评估它能不能对照整套系统与组织标准，有效审视变更。评审质量本身就是一项需要持续投入、持续度量的能力。

智能体周边的基础设施同理。问题记录、修复方案、例外事项、发布决策，都沉淀为可追溯记录，报表要持续暴露风险点、展示质量变化趋势。依赖关系、架构决策、历史故障知识库需要保持更新，并且推送给需要这些信息的智能体。维护这份记录与上下文，是长期工程工作。

对很多团队而言，采购专项能力是搭建工厂的合理路径。一套维护上下文、管控标准、汇总校验证据的平台，可以作为生产系统底座，支撑大量工作流与智能体。采购云服务，不等于工程师不用负责架构设计、组件串联、业务开发与运维；软件工厂也是同理：外购能力只是积木，整套系统终究要由团队搭建、运维。

工程组织需要设计、落地串联各项能力的工作流，供给上下文，把发现的问题转化为行动。团队要对完整系统做测试，定义每个环节需要的证据与权限，搭建监控和故障恢复机制。产品团队输出领域知识、对业务结果负责；平台与安全团队提供公共基础设施与管控规则。各方协同，要能够核查结果、质疑结论、在效果不达预期时调整工作流。

这和 Kief Morris 在 Martin Fowler 专栏《Humans and Agents》里的观点高度契合：工程师的价值在于优化生产机制。故障出现时，修复眼前这段变更只是一部分工作；更深层的机会，是完善上下文、约束规则、校验逻辑或者工作流，让后续任务不再重蹈覆辙。

凡是反复需要人工做出的判断，只要条件允许，都要转化成规则、测试用例或者持久化知识库。如果每一轮执行，都要人反复纠正同一个架构问题，说明工厂还没有吸收团队已有的经验。把这类判断固化下来，本身就是搭建生产系统的一环。

这类知识是战略资产。它记录组织搭建软件的方式、从故障中学到的教训、以及哪些决策可以授权出去。随着智能体承接越来越多编码工作，掌握这份知识的主导权，变得愈发重要。

稳步搭建有边界的 L4

我的建议是：先选定一类价值明确、需求和风险都足够清晰的工作。划定准入规则、搭建校验体系、限制权限范围、设计降级兜底方案。先在人工监督下试运行，统计所有人工介入的场景。

每一次人工介入，都说明存在能力缺口或是边界定义不全。一部分缺口可以通过优化工具、补充上下文解决；另一部分则说明这类工作暂时不适合自主运行。目标是明确：系统在哪些场景下，已经具备承接更多责任的条件。

之后，基于持续验证的良好表现，再逐步扩大工厂适用范围；对于后果重大、不确定性高的场景，继续保留严格限制。每家公司的选择都会不同，因为业务系统、合规义务、故障容忍度各不相同。

所以我认为，有边界的 L4，远比尚在设想中的 L5 更适合作为务实目标。它给工程团队一个清晰的建设对象，以及一套可衡量的评估标准。

智能体驱动的 SDLC，帮我们铺垫基础，让生命周期里更多环节可以交给智能体执行；而软件工厂，把这些能力整合进一套拥有明确权限、证据链路、故障恢复机制的生产体系。

工程团队的战略机会，就是掌握这套系统，并持续迭代优化。团队的竞争力，将越来越取决于：这套系统能否稳定把业务意图转化为软件交付，以及每一次交付结果，能不能反过来持续优化下一次执行。

翻译说明

1. 术语统一

• Agentic SDLC：智能体驱动的软件开发生命周期
• bounded autonomy：有边界的自主能力
• lights-on factory：常态化自主工厂（对应 L4，人掌控边界，日常可自主运行）
• dark factory：黑灯工厂（对应 L5，全自主）
• fallback：降级 / 兜底处置
• eligibility rules：准入规则