没有需求文档怎么写代码？基于大模型与 Agent 的“自迭代”开发工作流探索

没有需求文档怎么写代码？基于大模型与 Agent 的“自迭代”开发工作流探索

摘要：传统软件工程将需求文档视为编码的前提，但在个人开发、原型验证与探索性项目中，“没有需求文档”才是常态。大模型与 Agent 的介入并未消解这一矛盾，反而将其放大：模糊的提示词只会换来自信却偏离的代码。本文提出一条“自迭代”开发工作流：以行为规格替代静态文档，以执行反馈驱动规格演化，以角色协作约束生成质量。结合 SpecForge、HoH、Agentless 与 Self-Collaboration 等前沿研究，本文拆解了从“一句话意图”到“可工作软件”的四阶段闭环，并给出可落地的提示词模板与工程参数。核心结论是：需求文档的缺失并非致命，致命的是缺失可验证的反馈回路；Agent 的自迭代能力，恰恰是在没有文档时构建文档、在没有需求时发现需求的过程。

关键词：大模型 Agent；自迭代开发；行为规格；代码生成；工作流

1. 引言：当“先写文档”成为不可能

软件工程教科书给出的标准流程是：需求分析 → 设计文档 → 编码实现 → 测试验收。这条流水线在团队协作中运转良好，因为它将“想清楚”的责任前置到了产品经理与架构师身上。但当一个后端工程师被要求独自扛起一个全栈项目，或者一个创业者需要在两周内验证产品假设时，这套流程就失效了。失效的原因不在于开发者懒惰，而在于需求的模糊性本身就是待解决问题的一部分。

阿里云开发者社区的一篇文章精准地描述了这种困境：后端转全栈最大的坑不是学不会前端框架，而是“拿到需求就动手写代码”。长期处于流水线中段的开发者，习惯了接收“已经想清楚”的文档，一旦需要自己面对模糊需求，返工率会急剧上升。该文引用了一个典型场景：需求说“做一个内部工具，管理项目文档”，开发者理解成上传下载，对方要的却是在线协作编辑，三周工作归零。

大模型的出现本应缓解这一问题，实际效果却常常相反。微软在 Vibe Coding 培训材料中明确指出：采用自然语言描述需求的方式，并不会消除产品规划的必要性，定义完善的需求会带来更精确的 AI 建议和更少的反复迭代。问题在于，没有产品经理帮你写 PRD 时，你丢给模型的“一句话需求”本质上是一个欠定问题：解空间无限大，模型只能依据训练数据中的统计先验去补全，补全的方向大概率不是你想要的。

那么，有没有一种工作流，能够在没有需求文档的情况下，让大模型 Agent 自己“长出”需求，并在迭代中逐步逼近可工作的软件？本文的答案是：有，但前提是你得放弃“一次性描述清楚”的幻想，转而设计一个让规格与代码共同演化的反馈回路。

2. 核心矛盾：为什么“没有文档”不等于“没有约束”

2.1 大模型不擅长处理“真空”

一个常见的误解是：模型足够强，你只要说“做一个记账 App”，它就能做出可用的东西。事实是，即便最先进的编码模型，在完全开放的指令下也会产生大量“合理但错误”的设计选择。Agentless 团队在 SWE-bench Lite 上的分析揭示了一个关键发现：该数据集中有 4.3% 的问题在描述里直接包含了正确补丁，10% 的问题缺失关键信息，5% 的问题甚至包含误导性方案。真实世界的需求输入从来不是干净的，模型需要的是可操作的约束，而非自由发挥的空间。

2.2 规格不是文档：从“描述意图”转向“描述可观测行为”

SpecForge 论文提出了一个对实践极具启发性的区分：文档的目标是人类可读，而行为规格的目标是让代码生成模型能够据此重建正确实现。换言之，规格的优劣不由“写得多漂亮”衡量，而由一个操作性的指标决定：给定这份规格，模型生成的代码能通过多少测试。

这一区分是“无文档开发”工作流的基石。你不需要写一份给领导看的 PRD，你需要写的是每一段自然语言描述都能被测试用例验证的微型规格。例如，与其写“用户管理模块支持增删改查”，不如写：

create_user(email, password)：当 email 不含@时抛出InvalidEmailError；当 email 已存在于users表时抛出DuplicateUserError；成功时返回{id, email, created_at}，password以 bcrypt 哈希存储，cost=12。

后者的“文档性”很差，但“规格性”极强。模型据此生成的代码，你可以直接写测试验证。SpecForge 的实验表明，通过迭代精炼这类行为规格，编码 Agent 在 DEVEVAL+ 上的解决率可达 94.9%，比最强基线平均高出 5.7 个百分点，且优化后的规格可以跨语言翻译和新功能实现中复用。

2.3 没有文档时，反馈回路替代了文档的功能

文档在传统流程中承担三项功能：记忆（决策不丢失）、对齐（多方理解一致）、验证依据（做完了对不对）。在没有文档的场景下，这三项功能需要被工作流中的其他机制替代：

这条替代路径的核心逻辑是：既然无法在编码前获得完整需求，就让需求在“编码—执行—失败—修正规格”的循环中逐步显形。

3. 自迭代工作流的四阶段闭环

基于上述研究，我将无文档场景下的 Agent 自迭代开发拆解为四个阶段。每个阶段的设计原则不是“让模型一次做对”，而是“让模型在犯错后能以最低成本纠正方向”。

3.1 阶段一：意图锚定——把“一句话”拆成可失败的断言

目标：将模糊的初始意图转化为一组可执行、可失败的最小断言集合。

方法：不要要求模型“设计整个系统”，而是要求它生成一组“如果这些断言通过，我就认为第一版可接受”的验收条件。这一步的关键是反向操作：先不写功能，先写“什么算失败”。

以“做一个文件分享工具”为例，第一轮锚定产物不应是架构图或数据库设计，而应是类似下面的清单：

text

断言 1：调用 POST /upload 传入一个 10MB 的 txt 文件，返回 201 和 {url}。 断言 2：GET {url} 返回的文件内容与上传内容逐字节一致。 断言 3：上传 11MB 文件返回 413。 断言 4：未上传文件直接 GET 任意 url 返回 404。

这四个断言不涉及“用户系统”“权限管理”“UI 美化”——它们刻意被排除在第一版可接受范围之外。微软的 Vibe Coding 指南将这一步称为“定义 MVP 的核心功能”，但更精确的说法来自 SpecForge：规格的每一句话都应该能够被一个测试用例“杀死”或“放行”。

工程要点：让模型生成断言时，明确要求它标注每个断言对应的不确定性。例如：

断言 3 的 11MB 阈值是我假设的，如果你的目标场景不同，请告诉我实际限制。

这一步的价值在于：它把“我不知道自己要什么”这个隐性困境，转化成了若干条可讨论、可修改的显性假设。即便你无人可讨论，修改一条断言的成本也远低于重写一个模块。

3.2 阶段二：规格生长——用失败驱动规格细化

有了断言集合，下一步是让 Agent 在尝试满足这些断言的过程中，自动生长出更细粒度的行为规格。这正是 SpecForge 的核心机制：给定代码实体（函数、类、方法）的初始规格，生成代码并运行测试，根据哪些实体通过、哪些失败，反向优化规格描述，再进入下一轮。

SpecForge 识别出的核心挑战叫输出耦合（output coupling）：天真地迭代精炼会导致“修好一个函数，弄坏另一个”，因为规格修改之间存在相互干扰。它的解法是依赖引导的多前沿树搜索：利用调用图确定实体间的依赖关系，优先修改那些“被依赖且失败”的实体规格，并维护多个候选规格束（bundle），用帕累托选择保留在“已解决实体数”和“每实体通过率”两个维度上都不差的候选。

对实践者的简化版本是：按调用链自底向上迭代。先让 Agent 实现并测试最底层的工具函数（如hash_password、validate_email），只有底层实体的测试全绿后，才允许它向上层推进。每轮迭代的产物是一份已通过测试的行为规格清单，这份清单逐渐替代了不存在的那份需求文档。

华为 MindScale 中的 EvoFabric 组件提供了另一个视角：工作流本身可以从自然语言文档与历史工具库中生成，且记忆模块利用轨迹和评估结果形成经验，实现“越用越好”。这意味着你甚至不需要手动维护规格，Agent 可以把每轮迭代中“哪些断言通过了、哪些失败了、失败原因是什么”写入持久化记忆，下一轮自动加载。

可操作参数：建议将单轮迭代的实体数量控制在 3–5 个。HoH 论文在 GameCraft-Bench 上的实验显示，将开发范围限定为“小而可验证的增量”是跨多日自主开发中维持改进的关键设计原则之一。

3.3 阶段三：角色协作——用分工弥补“没有评审人”

个人开发最大的劣势不是技术能力，而是没有第二双眼睛。Self-Collaboration 框架提供了一条低成本替代方案：用同一个模型实例化多个角色，通过角色指令（role instruction）让模型在 Analyst、Coder、Tester 三个身份间切换。

该框架的关键发现是：角色扮演的效果优于直接让模型“既分析又编码又测试”。当模型以 Analyst 身份工作时，它的输出被明确要求包含“问题分解与边界条件枚举”；切换到 Coder 后，输入是 Analyst 的产物而非原始需求，认知负担被分割。在多个代码生成基准上，这种自协作方式使 GPT-3.5 的表现超过了 GPT-4 的单体直接生成。

CodeCoR 在此基础上增加了剪枝机制：Prompt Agent 生成多个思维链提示，Test Agent 生成多组测试用例，低质量或冗余的中间产物在传递给下游 Agent 之前被过滤掉。这一机制对无文档场景尤为重要：因为没有人类评审人来否决糟糕的设计，Agent 必须自己承担“质检员”的职责。

落地模板（可直接用于系统提示词）：

text

你是 Tester Agent。你的唯一职责是：给定一份行为规格和一份候选代码实现，生成恰好 3 个测试用例——其中至少 1 个必须测试规格中明确声明的边界条件，至少 1 个必须测试规格中未明确声明但逻辑上隐含的异常路径。你不负责修复代码，也不负责评价代码风格。输出格式为纯 JSON 数组，每个元素包含 {test_name, input, expected_output_or_exception}。

这套分工的代价是 token 消耗增加约 2–3 倍，但换来的是一轮迭代内发现问题的概率显著提升。对于没有代码评审伙伴的独立开发者，这笔交易通常是划算的。

3.4 阶段四：记忆固化——让下一轮不从零开始

自迭代工作流如果每一轮都从空白上下文开始，效率会低到不可接受。Hermes Agent 的实践展示了一种轻量但有效的方案：在多次执行后触发Skill Review，由 Review Agent 检查执行轨迹中的错误与修复过程，将可复用的经验固化为结构化 Skill 文件，写入持久化存储。

在其公开示例中，第一次部署 Flask 应用到 Kubernetes 需要 12 次工具调用，经历 ImagePullBackOff 和 livenessProbe 路径错误两次失败。Review Agent 据此创建了flask-k8s-deploySkill，包含步骤列表和 Pitfalls 清单。第二次部署 Django 应用时，调用次数降至 9 次，已知坑被绕过；Agent 遇到 Django 特有的ALLOWED_HOSTS问题后，再次修补 Skill。第三次部署 FastAPI 微服务，6 次调用，零错误。

这个案例的启示不在于 K8s 部署本身，而在于无文档开发的核心资产是“踩过的坑”而非“写过的代码”。需求文档记录的是“要做什么”，而 Skill 记忆记录的是“做什么的时候会在哪里摔倒”。在需求本身就不清晰的情况下，后者的价值远高于前者。

HoH 论文将这一思想推向了更系统的层面：它维护版本化的项目历史，并“逐步暴露交付物、角色专用工具和技能”，鼓励复用而非重建。在超过 70 轮迭代的多日部署中，HoH 自主开发出了一款具备连贯剧情、完整核心机制、可游玩体验和打磨过的视听效果的第一人称射击游戏。平均相对增益 52.25%，最高 82.86%。如果“没有需求文档”的极端测试是“从零做一个游戏”，这组数据提供了目前最有力的可行性证据。

4. 一个被忽视的警告：Agent 不是越多越好

在展开工作流细节之前，有必要插入一个来自 Agentless 论文的反直觉发现。该研究在 SWE-bench Lite 上比较了复杂 Agent 架构与一种极简的“定位—修复—验证”三阶段无 Agent 方法。结果是：Agentless 以 32.00% 的解决率超过了当时所有开源 Agent 方案，且成本更低。OpenAI 随后将 Agentless 作为 GPT-4o 和 o1 系列模型编码能力的官方展示方案。

Agentless 的核心洞察是：让 LLM 自主决定“下一步该做什么”在复杂软件任务中引入的方差，往往大于它带来的灵活性收益。分层定位（先找文件、再找类/函数、最后找编辑位置）和简单的 diff 格式补丁生成，配合复现测试的验证，构成了一条确定性远高于自主 Agent 的流水线。

这对“自迭代工作流”的启示是：自迭代不等于放任 Agent 自由循环。每一轮迭代的输入输出格式、验证条件、推进规则，都应该由工作流引擎（或你写的脚本）硬编码约束，而非交给模型自行判断。HoH 的设计原则也印证了这一点：它“约束可验证输出，而非规定 Agent 工作流”。

5. 工程参数与避坑清单

基于上述研究，以下参数与规则可作为工作流的默认配置。

5.1 迭代终止条件

不要用“模型说完成了”作为终止条件。可用的终止信号按优先级排列：

1. 全部预定义断言通过：阶段一锚定的断言集合全部为绿。
2. 连续两轮新增通过实体数为零：表明当前规格粒度已无法驱动进一步改进，需要回到阶段一补充断言或调整规格。
3. HoH 式增量耗尽：每轮迭代必须产生至少一个“此前未通过、本轮通过”的实体。如果连续三轮没有新实体通过，触发人工介入（或由 Review Agent 标记为“需要重新分解”）。

5.2 上下文管理

SpecForge 的树搜索之所以必要，是因为规格之间存在依赖耦合。在单线迭代中，一个简化的替代方案是：每轮只加载与当前目标实体有直接调用关系的规格。Hermes 的经验是使用skill_view按需加载，而非把所有 Skill 注入系统提示词。对于个人开发者，这意味着你的规格文件应该按模块拆分，而不是塞进一个巨大的requirements.md。

5.3 安全边界

当 Agent 能够修改自己的规格文件和记忆存储时，攻击面随之扩大。Hermes 在memory_tool.py中实现了一层基于正则的威胁模式扫描，拦截诸如ignore previous instructions之类的提示注入尝试。在无文档工作流中，一个务实的规则是：规格文件的修改必须通过结构化操作（如 JSON Patch）完成，禁止 Agent 直接覆写整个文件。这样可以保留变更历史，也降低了单次错误修改的破坏半径。

5.4 避坑清单

• 不要在断言集合为空时启动编码。没有断言，就没有“失败”的定义，迭代就退化为随机漫步。
• 不要信任 Agent 对自己代码的评价。用 Tester Agent 或外部测试脚本做判断，而不是问 Coder“你写的对吗”。
• 不要跨轮复用未经验证的规格。SpecForge 的实体通过率向量是逐轮更新的；一条规格如果在当前代码基上未被测试覆盖，它就不应该被当作“已知正确”带入下一轮。
• 不要在单轮中处理超过 5 个实体。HoH 的小增量原则是有实验支撑的。
• 接受“第一版很丑”。自迭代工作流的产出在早期阶段代码质量通常低于人类手写，它的优势在于方向纠偏成本低，而非首版质量高。

6. 结语：文档会消失，规格不会

回到标题的问题：没有需求文档怎么写代码？

答案不是“让大模型替你写一份文档”——那只是把文档的写作负担转移给了模型，而你仍然需要判断它写得好不好。真正的答案是：用一组可执行、可失败、可迭代的断言和规格，替代静态文档的功能。这些规格最初可能只有三五条，粗糙且不完整，但它们有一个文档不具备的性质：它们可以被运行。运行失败就是信号，信号驱动规格细化，细化后的规格驱动下一轮代码生成。

SpecForge 证明了行为规格可以在不更新模型权重的情况下实现递归自我改进；HoH 证明了多日自主开发中持续改进的可行性；Hermes 的实践则表明，经验固化为 Skill 后，Agent 的表现可以在三次会话内从 12 次调用 2 个错误降到 6 次调用 0 个错误。这些证据共同指向一个结论：需求文档的缺失之所以致命，是因为它切断了反馈回路；而 Agent 的自迭代能力，恰恰可以用来重建这条回路。

你不需要在写代码之前想清楚一切。你需要的是让第一版代码尽快跑起来、尽快失败、然后让失败告诉你下一版该想清楚什么。

参考文献

1. Microsoft Learn. 識別產品需求和程式代碼撰寫指導方針. Vibe Coding Training, 2026.
2. Yan H, et al. Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement. arXiv:2609.01481, 2026.
3. 量子位. 华为升级行业Agent算法架构！MindScale自己写prompt和工作流. 知乎专栏, 2026.
4. SpecForge: Recursive Self-Improvement for Coding Agents via Behavioral Specifications. arXiv:2610.15708.
5. Dong Y, et al. Self-collaboration Code Generation via ChatGPT. ACM TOSEM, 2024.
6. Xia C S, et al. Demystifying LLM-Based Software Engineering Agents. Proceedings of the ACM on Software Engineering, 2025.
7. 阿里云开发者社区. 需求文档驱动的全栈开发：如何用流程消除文档与代码两张皮. 2026.
8. AutoGPT Devloop: An Autonomous AI Development Framework. IEEE Xplore, 2026.
9. 深入源码：Hermes Agent 如何实现 “Self-Improving”. 知乎专栏, 2026.
10. CodeCoR: An LLM-Based Self-Reflective Multi-Agent Framework for Code Generation. arXiv:2501.07811.