从一个概念到成品中间缺什么
从一个概念到成品中间缺什么
早在20世纪60年代，日本的大型科技企业日立、东芝就开始尝试将制造业流水线理念引入软件生产；80年代，CASE工具试图实现全流程自动化；21世纪初，MDA试图通过UML图直接生成代码。它们有一个共同的梦想——软件工厂（Software Factory）——但无一例外地失败了。原因很简单：硬件是标准化的，而软件需求充满了不确定性、非标准化和创造性，刚性流水线处理不了"软"的复杂性。
但这一次，可能不一样了。大语言模型（LLM）能力的爆发与Agentic Workflow的成熟，让我们第一次拥有了能够理解"非标需求"并将其转化为"标准代码"的通用推理引擎。于是，那个老问题被重新推到了台前：从一个模糊的概念，到一份可交付的成品，中间到底缺了什么？
一、传统软件工程的遗产：流程与文档的"重工业"尝试
传统软件工程对这个问题的回答是：用流程和文档来弥补表达的不足。需求规格说明书、概要设计、详细设计、测试计划——每份文档都是一道"翻译"工序，试图将模糊理解逐步收敛为可执行的工程指令。
日本企业将品控哲学移植到软件开发：分阶段门禁、逐级评审、文档驱动。这套方法论在需求稳定、变更代价高的领域确有成效，但致命前提是：你得先一次性把事情说清楚。现实是，大多数项目的需求，启动时连核心利益相关方自己都没想透。
这引出了一个根本矛盾：以"一次性说清楚"为前提的工程方法，面对的恰恰是人类"说不清楚"的现实。
二、敏捷的历史使命，与轻文档的未尽之事
敏捷开发是针对这个矛盾的范式级回应。它用"拥抱变化"替代了"抗拒变化"，用短迭代替代了长周期，用"可工作的软件胜过详尽的文档"替代了厚重的规格说明书。但敏捷宣言中那句名言在二十年传播中被不断简化，最终在很多团队演变成了"文档不重要"甚至"文档是累赘"。
这偏离了敏捷的本意。敏捷反对的不是文档本身，而是那种写完就束之高阁、与代码长期脱节的"死文档"。当"轻文档"变成"零文档"的通行证，一个新问题浮现了：迭代跑得飞快的团队和文档齐备但反应迟缓的团队，掉进了同一条沟的两侧——核心问题都没解决。
退一步看：不论是重文档路线还是轻文档路线，本质上都在应对同一个问题——人类不能一次性把想要的说清楚。前者用流程和文档来"逼迫"说清楚；后者接受说不清楚，用快速反馈来逼近。2025年，《敏捷已死，架构重回舞台》一文引发热议，作者Craig Adam的判断很明确：钟摆正在从"氛围编码"摆回"有意图的设计"——文档和设计的重要性，不只是为人类准备的，更是为即将生成下一万行代码的AI准备的。
AI时代提供了一条新路径：不是让人类更努力地说清楚，而是让AI来帮助人类说清楚。这就是规范驱动开发（Spec-Driven Development，SDD）的核心主张——以规范作为软件开发的第一性产物，让规范不只指导人类，更能直接驱动AI完成设计和实现。但SDD也面对一个关键追问：规范本身，怎么来？
三、从一个概念到成品，要把哪些事情说清楚
回到最本质的问题：一个软件概念到成品的过程中，需要被澄清的维度到底是什么？拆解下来，至少四个范围需要覆盖：
业务范围——系统要解决什么问题？谁是用户？价值主张是什么？流程边界在哪里？这需要对业务领域的结构化理解：利益相关方分析、业务规则梳理、异常场景枚举。
技术范围——用什么技术栈？系统如何分层？模块间用什么接口契约？非功能需求（性能、安全、可扩展性）的基线是什么？
数据范围——涉及哪些数据实体？数据从哪里来、流向哪里？数据字典的粒度和一致性如何保证？合规审查的边界在哪里？
应用范围——系统部署在哪？用户如何接入？运维监控怎么做？灰度发布和回滚策略是什么？
这四个范围不是先后关系，而是相互咬合的并行维度。业务范围的决策会影响技术选型；技术约束会反作用到数据设计；数据合规要求又会影响部署方案。在传统模式下，四个维度的对齐依赖大量的会议、邮件和对关键人物的隐性知识。而在AI时代，真正的挑战在于：能否将这种跨维度的协同，变成一套可被Agent理解和执行的工程流程？
四、Agile Skill Warehouse的实践：三个Agent Skillset的分工与协作
在mcp.smartmoves.com.cn上，Agile Skill Warehouse技能仓库正在尝试给出答案。目前已实现三个核心Agent Skillset——BA-Master、PM-Master、SA-Master——它们的设计思路，本质上是在回答同一个问题：如何让AI Agent来承担从概念到成品过程中"说清楚"这个关键环节？
BA-Master（业务分析师助手）锁定业务范围。它是一套四阶段渐进式流程：根目的发现→领域知识加载→三维度需求澄清→结构化输出。它产出的是结构化PRD，包含业务流程建模（泳道图、状态机）、数据字典、用户故事及追溯关系、UI规格和合规审查。关键是，每个阶段的输出都是下一阶段的输入约束——"验收闭环"式的推进，而非开放式的撒网。
SA-Master（系统架构师助手）划定技术范围和数据范围。它基于BA产出的PRD，按七个维度——总体架构、分层设计、模块划分、接口契约、数据架构、部署架构、非功能需求——逐维确认再产出，最终整合为标准化的《系统技术架构设计说明书》。每个维度的设计决策都有上游BA产出作为追溯依据。
PM-Master（项目经理助手）承担跨范围编排的角色，驱动BA和SA并行工作，统筹从项目启动到交付的全生命周期管理。在"迭代0计划"中，PM-Master以概念输入为起点，通过三维并行范围定义、范围确认、MVP排期，产出9章计划文档加执行流程图——将BA、SA、开发三路工作在正确节点上对齐。
这三个Skillset的分工，恰好覆盖前述四个范围：BA-Master锁定业务范围，SA-Master框定技术范围和数据范围，PM-Master统筹应用范围和全局节奏。
五、文档即上下文，文档即Harness
这三个Skillset的设计，隐含了一个关键判断：在AIGC时代，"文档"的角色需要被重新定义。它不是写给人类看的辅助材料，而是AI Agent执行任务的上下文和约束边界——文档即Harness（套件）。
Harness Engineering是Martin Fowler和Thoughtworks团队近期提出的重要概念：在让Agent写代码之前，先为它搭好"安全带"——高密度自动化测试、严格类型检查、边界清晰的模块沙盒、可自动回滚的快照机制。本质上，它不是让AI"更聪明"，而是让AI"无法犯错"。
在Agile Skill Warehouse中，BA-Master产出的PRD、SA-Master产出的架构说明书，正是这种Harness。它们不只"描述系统长什么样"，更定义了系统不能长成什么样——边界条件、异常场景、合规红线、接口契约，这些约束成为后续所有AI动作的校验基准。
这意味着，敏捷宣言中"可工作的软件胜过详尽的文档"的观点，需要在AIGC时代进行工程化的调整。不是回到重文档时代，而是让文档从"给人看的"变成"给AI用的"。一份好的Spec，不再是项目初期的面子工程，而是贯穿系统全生命周期的"真理之源"。
六、文档怎么来：只是一个'/spec'就够了吗？
当前行业中涌现了大量"一键生成PRD""一句话出架构"的工具，共同逻辑是：输入一句模糊需求，AI一次性输出一份看似完整的文档。但根本缺陷在于：它跳过了"说清楚"这个核心过程本身。
Agile Skill Warehouse的路径不同。它的交互模型是"你让AI干活 → AI逐级问你问题，迭代渐进式形成验收闭环式文档"。BA-Master会反问你：这个需求的根目的是什么？场景的异常分支有哪些？数据字段的合规约束是什么？每个回答锁死一部分不确定性，同时打开更深的问题。几轮交互下来，形成的不是"看起来完整"的文档，而是"每一行都被验证过"的文档。
这个过程中，还有两个关键支撑：RAG知识库和经验累积机制。知识库让Agent在提问时加载领域最佳实践和行业模板；经验累积让上一次的澄清成果作为下一次的起点复用。这正是"团队共享"的真正含义——不是共享一份文档，而是共享一套"如何把事儿说清楚"的方法论积淀。
结语
从一个概念到成品，中间缺的不是代码能力，甚至不是AI能力——缺的是一套结构化地"把事儿说清楚"的工程方法论，以及能执行这套方法论的Agent体系。
传统软件工程试图用重流程弥补表达的不足，敏捷用短反馈绕过表达的困难。AI时代给出的第三条路径，是用Agent承担"说清楚"这个核心工程环节——通过渐进式提问、结构化澄清、验收闭环约束，让"说不清楚"本身成为一种可被管理的工程过程，而非无解的前提。
Agile Skill Warehouse的三个Agent Skillset，是这个方向上的初步实践。它们不替代BA、PM或SA，而是要把这些角色工作中最隐性、最难标准化的那部分——"帮别人把事情说清楚"——变成可持续积累、持续优化的工程能力。
这是一条需要长期演进的路。但方向本身，大概率是对的。
参考资料：
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
1
0- 0
已为社区贡献4条内容
所有评论(0)