从 PRD 到部署:用 SDD + Harness 打通 AI 全流程研发实战

上篇聊了 AI 编程提效的困局:出码率翻倍了,效率纹丝不动。根本原因是编码只占交付链路的一小段,"氛围编程"在存量项目里容易翻车,大任务又超出了 AI 单次处理的能力。

解决思路是两套东西:SDD,先把需求写成结构化规范再让 AI 动手;Harness,通过信息供给、物理约束、自我修正、人工兜底四道防线,让 AI 在受控环境里执行。

搭知识库

AI 要在一个项目里干好活,前提是它得"懂"这个项目。靠的不是模型本身的通用能力,而是你给它准备的知识。

阿里高德团队的做法是按三层来组织,我们可以借鉴一下:

项目层:这个项目是什么、目录结构怎么组织的、架构怎么分的、用了什么技术栈。核心是维护一个 README.md 作为信息入口,AI 需要了解项目的任何信息,都从这里按需加载。一个基本原则是:不在文档里的信息,对 AI 来说不存在。

技术层:编码规范、中间件和三方库的使用方式、团队沉淀的最佳实践、踩过的坑和解决方案。这些跟具体项目无关,可以跨项目复用。

资产层:历史代码片段、通用组件、模板、以前的需求文档和技术方案、归档的测试用例。相当于团队的"零件库",AI 遇到类似场景可以直接复用,不用每次从零开始。

落地的时候,三层知识各自有目录,用一个索引文件串联。AI 不需要一次性读取所有内容,那样既浪费上下文又容易信息过载。按当前任务的需要,加载对应的知识就行。

还有个配套机制叫 Memory,和知识库是互补的关系。知识库存的是静态信息,即"项目是什么";Memory 存的是动态状态,即"之前做了什么决策、现在进行到哪了、还有哪些待办"。一个管"背景",一个管"进度"。AI 只有同时掌握了这两个维度的信息,才能在正确的上下文里做出正确的判断,而不是每次打开都失忆。

目前主流 AI 编程工具都在往"知识供给"这个方向发力,我举一些栗子~

Claude Code 的做法最直接:用 CLAUDE.md 做项目级规则,用 MEMORY.md 记录会话间的动态状态,官方称之为双层记忆系统。优点是零配置、开箱即用,缺点是只在自己的生态里生效。

claude-code-memory

Cursor 的 .cursorrules 走的是另一条路,它搞了五层规则体系——从用户全局配置到项目特定规则,层层叠加,精细度很高。适合团队协作场景,大家共享同一套编码规范。

Windsurf 的思路跟上面两个类似,但它有个亮点:除了你手写的 Rules,它还会自动生成 Memories,把你的操作习惯和项目特征默默记下来。相当于一个主动学习的知识库,不用你刻意维护。

跨仓库场景可以看看 Sourcegraph Cody,它能感知整个 monorepo 的上下文,而不仅仅是当前打开的文件。然后Swimm 是走文档路线,AI 驱动的代码文档平台,文档跟代码自动同步,代码改了文档跟着更新,解决了"文档永远过时"的老问题。

HITL

知识库准备好了,下一步是处理需求。

注意这里的处理方式不是把 PRD 往 AI 那一扔就能直接开干,而是走一个 Spec 流程,让 AI 和人一起把模糊的需求文档变成精确的结构化规范。

这个过程需要人参与,有个术语叫 HITL(Human-In-The-Loop,人在回路)

绝大多数需求文档里都藏着大量"大家都知道所以没人写"的隐性信息,就拿"支持用户登录"这个功能来说,需求文档可能就写了一句话,但背后要澄清的东西太多了:比如支持哪些登录方式,手机号、邮箱、还是第三方账号、登录状态保持多久、密码有什么强度要求、连续输错怎么办、锁定还是弹验证码……

通过 Spec 流程,AI 会主动发现这些模糊点,向开发者提问,一步步把隐性信息补全。最终输出一份包含三块内容的规范:

  • 数据层面:涉及哪些数据实体、字段怎么定义、实体之间什么关系
  • 接口层面:API 的输入输出格式、错误码定义、是否要求幂等
  • 验收标准:这块是重中之重。每一条都必须是可测试、可验证的。"登录成功后跳转首页"不算数;"输入正确密码后 3 秒内跳转至首页,顶部显示用户昵称"才算合格

有了这份规范,AI 就不是在"猜需求"了,而是拿着明确的施工图纸干活。

HITL 落地到工具层面,核心是两个环节:代码审查和执行审批。

代码审查方面,GitHub Copilot Code Review 是最基础的方案,AI 先做一轮初审标记问题,人工再终审确认,效率比纯人工高不少。CodeRabbit 是个独立的 PR 审查机器人,它的优势在于跨文件影响分析——不只看你改了哪几行,还能分析出这个改动会影响哪些其他模块。Greptile 走的是"全仓库索引"路线,审查时能理解整个代码库的上下文,给出的建议更贴合项目实际情况。

CodeRabbit截图

如果你的团队经常遇到大 PR 审不动的问题,可以试试 Graphite。它主打 Stacked PR 工作流,把一个大改动拆成一组小 PR 按顺序提交,审查者每次只需要看一小块改动,认知负荷大幅降低。

执行审批方面,Claude Code Plan Mode 是个典型的 HITL 机制:AI 先输出完整的执行计划,你确认无误后才真正开始执行,相当于"先看方案再施工"。Cline(前身是 Claude Dev)更进一步,Plan 和 Act 两个阶段明确分离,每个步骤都需要你点确认才能继续,控制粒度更细。

Claude Code Plan Mode截图

多角色分任务执行

规范定好了,进入执行阶段。高德团队这里的做法是多角色协作,也就是专家团队,根据任务类型,把活分给不同角色的 Agent。有专门负责前端的、负责后端的、负责写测试的、负责架构评审的,类似一个真实开发团队里的角色分工。

执行流程是:AI 先根据规范生成完整的执行计划,把一个大任务拆成若干个小任务。每个小任务都有明确的输入条件、预期产出和验收标准。然后按照任务类型分配给对应角色的 Agent,逐个执行。

这种拆分方式直接解决了"大任务 AI 处理不了"的问题。一个涉及十几个模块的重构,拆成几十个小任务后,每个小任务的复杂度都在 AI 的能力范围内。AI 不需要同时处理所有信息,只要做好手头这一个任务就行。

还有一个设计我觉得挺重要的:人在执行过程中可以随时介入。不是说交给 AI 就不管了,你可以随时调整方向、取消不合理的任务、补充遗漏的信息。

多角色协作是目前 AI 编程最前沿的领域,各家方案差异挺大的。

最轻量的是 Claude Code Agent Teams,它用 Lead + Teammate 的模式组织多个 Agent,每个 Teammate 在独立的 git worktree 里工作,互不干扰,真正做到了并行开发。适合中小型任务拆分,上手门槛低。

Claude Code Agent Teams截图

需要更灵活编排的可以看 LangGraph,它用有向图来定义工作流,支持并行边和条件分支,理论上能描述任意复杂的多 Agent 协作流程。

LangGraph截图

云端方案方面,OpenAI Codex Agent 把每个任务放在独立的云端沙箱里并行执行,不需要本地环境。Devin 作为"AI 软件工程师"的代表,支持 Parallel Cloud Agents 多任务并行,但目前还是偏演示阶段,离真正的工程落地还有距离。

部署上线

代码生成完了、测试也过了,最后一步是部署。这一步最容易被人忽略:如果 AI 只能写代码但不能部署,那最后还是要人去各种平台手动操作,效率就卡在这最后一公里了。

部署环节用的是 MCP,通过 MCP 接入 CI/CD 之后,运维 Agent 能做的事情包括:触发构建流水线、执行部署脚本、查询部署状态、遇到异常自动回滚。开发者在部署过程中负责给agent做比较关键的决策。

再加上和部署流程相关的Skills,比如数据库操作 Skill,让 AI 能直接查表改数据,做上线前的数据准备和验证;接口测试 Skill,让 AI 能模拟请求来验证接口行为。不同的项目场景可以按需配置不同的 Skills。

部署环节的 AI 化,目前主要靠 MCP 协议打通。

GitHub MCP Server 是 GitHub 官方出的,让 AI 能直接操作 GitHub Actions——触发流水线、查看构建状态、管理 Release,不用再切换到网页上去点。如果你团队用 Jenkins,Jenkins MCP Server Plugin 是 Jenkins 官方的 MCP 接入方案,把 Jenkins Pipeline 的能力暴露给 AI Agent。企业级场景可以看 Azure DevOps MCP Server,微软官方出品,覆盖 Pipeline 管理、Work Item 跟踪、制品管理等完整链路。

GitHub MCP Server截图

部署平台本身也在集成 AI 能力。Vercel 配合 v0 基本做到了一键部署,前端项目从开发到上线可以全程不离开 IDE。Railway 作为现代 PaaS,内置了 AI 助手,你说一句话它就能帮你配置环境变量、扩缩容、查日志。

到这里,从知识库搭建、需求规范化、分任务执行、到最终部署上线,整条链路就通了。

串起全流程

把四个步骤放一起,逻辑是这样:知识库给 AI 提供理解项目的基础背景;Spec 流程把模糊的需求变成精确的规范,人参与审核把关;多角色执行把大任务拆小,分给不同 Agent 并行完成;MCP + Skills打通部署和验证,形成闭环。

每一步的产出都是下一步的输入。知识库支撑 Spec 的质量,Spec 决定执行的精确度,执行结果通过 MCP 进入部署。人在整个流程中的参与点很集中:澄清需求、审核规范、验收结果。其余的交给 AI 和自动化。

写在最后

其实,写规范这件事本身就不是那么容易的事,虽然有 AI 辅助提问,但把模糊需求变成精确规范,人工介入的量还是不少。目前还没有做到"扔一个 PRD 就能自动出一份高质量规范"的程度。

然后是多agents协作,现在的模式基本是"拆任务 → 分配 → 各自执行",这就像是流水线。更高级的协作方式,比如多轮迭代、角色之间动态调整,目前还做不到。

知识库维护的长期维护也是有高成本的,如果是一个几百万行级别的大项目,那知识库本身就非常庞大了。

不过这套方案的方向是对的,AI 编程正在从"个人工具"变成"团队基础设施"。出码率只是看得见的那个数字,看不见的变化是整个研发方式的升级。

如果你觉得有帮助,请点点关注 点点赞~

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐