软件研发的“工艺方差“，AI能熨平吗？
软件研发的“工艺方差”，AI能熨平吗？
一个观察：同样的需求，天差地别的交付
做了近二十年软件研发，有一个现象反复出现，让我始终耿耿于怀：
同样一份需求文档，交给A团队和B团队，交付周期能差一倍，代码质量能差一个数量级，上线后的维护成本甚至不在同一个坐标系里。你说这是“能力差距”？不全是。更深层的问题是——A团队的那套“怎么干活”的方法，没法变成B团队的资产。
这不是一个“团队管理”问题，这是一个“工艺资产化”问题。
传统行业的“工艺”为什么能资产化？
传统制造业的“工艺”是有形的。冲压的模具、焊接的参数、质检的SOP——每一个步骤都有明确的输入、输出和容差。一条产线的工艺可以被复制到另一个工厂，良品率偏差控制在个位数百分点以内。
软件行业呢？我们有过方法论，而且名字还不少：瀑布、敏捷、DevOps、TDD、SRE。但它们的颗粒度在哪儿？敏捷告诉你“响应变化高于遵循计划”，但它不会告诉你，一个需求变更来了，你该先改接口定义还是先调数据库schema。
这就导致了：方法论是天花板的高度，但工地上的活儿还是靠师傅带徒弟。
我把它归结为两个根因：
第一，方法论颗粒度不够。传统工艺能细化到“拧这颗螺丝用3.5N·m的扭矩”，软件研发的“最佳实践”还停留在“考虑使用策略模式”这种层次。两者之间的精度差，不是一个数量级。
第二，过程可度量性差。产线的节拍时间、良品率、OEE都是实时量化的。软件研发中，一个架构设计的好坏，定性讨论都能吵一个下午，定量评估几乎无从下手。“这段代码质量怎么样？”——“review的人说了算”，这就是行业现状。
所以结论很直接：传统行业的工艺能固化为资产（产线、模具、标准作业书），软件研发的工艺极少能以资产形态沉淀。工具做了一些尝试，但坦率讲，差强人意。
AI带来的结构性变量
自ChatGPT之后，两个变化让这个局面出现了转机。
第一，模型能力的跨越。参数规模的跃迁、多模态融合、MoE架构的落地，让模型对复杂、长链条任务的理解力和执行力有了质的提升。
第二，Agent的架构化。从单一对话，进化为“会话—上下文—记忆—技能—工具—知识”的模块化结构。这是一个被低估的变化——它意味着AI从“黑箱应答器”变成了“可组装的执行引擎”。
两者叠加，正在催生一个关键的反转：AI从工艺的旁观者（给你查资料、给建议），转向工艺的执行者（真的去干活）。这不是趋势预判，这是正在发生的现实。
一个假设，一个原型
基于以上判断，我形成了一个核心假设：
利用AI Agent的结构化能力，将研发团队的隐式经验——怎么设计、怎么实现、怎么测试、怎么写文档、怎么部署——转化为可复用、可执行、持续迭代的“技能资产”，从而大幅压缩软件研发的“工艺方差”。
假设不验证就是空谈。我搭了一个原型平台来做这件事：Agent MCP Warehouse（mcp.smartmoves.com.cn）。
架构图请参见原文：Agent MCP Warehouse
核心逻辑一句话：把Skillsets装进容器，将“技能的构建”和“技能的执行”拆开。
- 构建——由懂业务、懂技术的团队负责，把组织的领域经验结构化地写入Skill
- 执行——由Agent承担，按照Skill定义的标准“工艺”去干活
- 治理——中间有Housekeeper角色，负责技能资产的版本、质量、调度、迭代
这背后需要澄清的话题不少，先列在这里，后续逐一展开：
- User + Agent = 门槛降低，效率与有效性双提升
- Housekeeper角色的必然性
- “工艺”资产的持续维护与迭代
- LLM已经无所不知，为什么还要单独管理“知识”？
- “知识”与“经验”的持续精炼闭环
- 与现有组织结构的集成
…
To be continued
软件研发的“工艺资产化”，在AI Agent的加持下，可能有了一条看得见的技术路径。这条路能不能走通，取决于我们能把多少“人脑子里的隐式经验”变成Agent可执行的“技能资产”。
方向看起来是对的。剩下的，就是把它做出来。
后续我会围绕这个命题，持续分享基于实践的观点，欢迎关注与讨论
原型站点（含 help-doc）：https://mcp.smartmoves.com.cn