没有需求文档怎么写代码基于大模型与 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 哈希存储cost12。后者的“文档性”很差但“规格性”极强。模型据此生成的代码你可以直接写测试验证。SpecForge 的实验表明通过迭代精炼这类行为规格编码 Agent 在 DEVEVAL 上的解决率可达 94.9%比最强基线平均高出 5.7 个百分点且优化后的规格可以跨语言翻译和新功能实现中复用。2.3 没有文档时反馈回路替代了文档的功能文档在传统流程中承担三项功能记忆决策不丢失、对齐多方理解一致、验证依据做完了对不对。在没有文档的场景下这三项功能需要被工作流中的其他机制替代文档功能替代机制技术支撑记忆版本化项目历史 记忆库HoH 的 versioned historiesHermes 的 Skill 持久化对齐角色分工与中间产物校验Self-Collaboration 的 analyst/coder/testerCodeCoR 的剪枝机制验证执行反馈驱动的规格迭代SpecForge 的 pass-rate 目标函数这条替代路径的核心逻辑是既然无法在编码前获得完整需求就让需求在“编码—执行—失败—修正规格”的循环中逐步显形。3. 自迭代工作流的四阶段闭环基于上述研究我将无文档场景下的 Agent 自迭代开发拆解为四个阶段。每个阶段的设计原则不是“让模型一次做对”而是“让模型在犯错后能以最低成本纠正方向”。3.1 阶段一意图锚定——把“一句话”拆成可失败的断言目标将模糊的初始意图转化为一组可执行、可失败的最小断言集合。方法不要要求模型“设计整个系统”而是要求它生成一组“如果这些断言通过我就认为第一版可接受”的验收条件。这一步的关键是反向操作先不写功能先写“什么算失败”。以“做一个文件分享工具”为例第一轮锚定产物不应是架构图或数据库设计而应是类似下面的清单text断言 1调用 POST /upload 传入一个 10MB 的 txt 文件返回 201 和 {url}。 断言 2GET {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 迭代终止条件不要用“模型说完成了”作为终止条件。可用的终止信号按优先级排列全部预定义断言通过阶段一锚定的断言集合全部为绿。连续两轮新增通过实体数为零表明当前规格粒度已无法驱动进一步改进需要回到阶段一补充断言或调整规格。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 的自迭代能力恰恰可以用来重建这条回路。你不需要在写代码之前想清楚一切。你需要的是让第一版代码尽快跑起来、尽快失败、然后让失败告诉你下一版该想清楚什么。参考文献Microsoft Learn. 識別產品需求和程式代碼撰寫指導方針. Vibe Coding Training, 2026.Yan H, et al. Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement. arXiv:2609.01481, 2026.量子位. 华为升级行业Agent算法架构MindScale自己写prompt和工作流. 知乎专栏, 2026.SpecForge: Recursive Self-Improvement for Coding Agents via Behavioral Specifications. arXiv:2610.15708.Dong Y, et al. Self-collaboration Code Generation via ChatGPT. ACM TOSEM, 2024.Xia C S, et al. Demystifying LLM-Based Software Engineering Agents. Proceedings of the ACM on Software Engineering, 2025.阿里云开发者社区. 需求文档驱动的全栈开发如何用流程消除文档与代码两张皮. 2026.AutoGPT Devloop: An Autonomous AI Development Framework. IEEE Xplore, 2026.深入源码Hermes Agent 如何实现 “Self-Improving”. 知乎专栏, 2026.CodeCoR: An LLM-Based Self-Reflective Multi-Agent Framework for Code Generation. arXiv:2501.07811. 
长河君 · 2026/10/26 10:25:14 · 阅读 1.2k 没有需求文档怎么写代码？基于大模型与 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 哈希存储cost12。后者的“文档性”很差但“规格性”极强。模型据此生成的代码你可以直接写测试验证。SpecForge 的实验表明通过迭代精炼这类行为规格编码 Agent 在 DEVEVAL 上的解决率可达 94.9%比最强基线平均高出 5.7 个百分点且优化后的规格可以跨语言翻译和新功能实现中复用。2.3 没有文档时反馈回路替代了文档的功能文档在传统流程中承担三项功能记忆决策不丢失、对齐多方理解一致、验证依据做完了对不对。在没有文档的场景下这三项功能需要被工作流中的其他机制替代文档功能替代机制技术支撑记忆版本化项目历史 记忆库HoH 的 versioned historiesHermes 的 Skill 持久化对齐角色分工与中间产物校验Self-Collaboration 的 analyst/coder/testerCodeCoR 的剪枝机制验证执行反馈驱动的规格迭代SpecForge 的 pass-rate 目标函数这条替代路径的核心逻辑是既然无法在编码前获得完整需求就让需求在“编码—执行—失败—修正规格”的循环中逐步显形。3. 自迭代工作流的四阶段闭环基于上述研究我将无文档场景下的 Agent 自迭代开发拆解为四个阶段。每个阶段的设计原则不是“让模型一次做对”而是“让模型在犯错后能以最低成本纠正方向”。3.1 阶段一意图锚定——把“一句话”拆成可失败的断言目标将模糊的初始意图转化为一组可执行、可失败的最小断言集合。方法不要要求模型“设计整个系统”而是要求它生成一组“如果这些断言通过我就认为第一版可接受”的验收条件。这一步的关键是反向操作先不写功能先写“什么算失败”。以“做一个文件分享工具”为例第一轮锚定产物不应是架构图或数据库设计而应是类似下面的清单text断言 1调用 POST /upload 传入一个 10MB 的 txt 文件返回 201 和 {url}。 断言 2GET {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 迭代终止条件不要用“模型说完成了”作为终止条件。可用的终止信号按优先级排列全部预定义断言通过阶段一锚定的断言集合全部为绿。连续两轮新增通过实体数为零表明当前规格粒度已无法驱动进一步改进需要回到阶段一补充断言或调整规格。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 的自迭代能力恰恰可以用来重建这条回路。你不需要在写代码之前想清楚一切。你需要的是让第一版代码尽快跑起来、尽快失败、然后让失败告诉你下一版该想清楚什么。参考文献Microsoft Learn. 識別產品需求和程式代碼撰寫指導方針. Vibe Coding Training, 2026.Yan H, et al. Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement. arXiv:2609.01481, 2026.量子位. 华为升级行业Agent算法架构MindScale自己写prompt和工作流. 知乎专栏, 2026.SpecForge: Recursive Self-Improvement for Coding Agents via Behavioral Specifications. arXiv:2610.15708.Dong Y, et al. Self-collaboration Code Generation via ChatGPT. ACM TOSEM, 2024.Xia C S, et al. Demystifying LLM-Based Software Engineering Agents. Proceedings of the ACM on Software Engineering, 2025.阿里云开发者社区. 需求文档驱动的全栈开发如何用流程消除文档与代码两张皮. 2026.AutoGPT Devloop: An Autonomous AI Development Framework. IEEE Xplore, 2026.深入源码Hermes Agent 如何实现 “Self-Improving”. 知乎专栏, 2026.CodeCoR: An LLM-Based Self-Reflective Multi-Agent Framework for Code Generation. arXiv:2501.07811.