从一句话需求到规范文档：拆解 GPT-Pilot 的 Spec Writer

从一句话需求到规范文档拆解 GPT-Pilot 的 Spec Writer【免费下载链接】gpt-pilotThe first real AI developer项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-pilot凌晨一点半产品第三次改口这个功能要保留但要换个交互。你翻出三天前的需求文档发现登录流程的描述前后对不上第三方接口该不该接也说不清。与其再开一轮拉齐会不如让机器先把矛盾找出来、把文档重写一遍——这正是 GPT-Pilot自称 the first real AI developer里 Spec Writer 这个智能体的活你给它一段大白话它还你一份能直接照着写代码的项目规范。它到底负责哪几件事Spec Writer 是 GPT-Pilot 多智能体流水线的第一棒把模糊的自然语言需求变成结构化的规范文档并为后续开发定好基调。真正的有意思的地方是它不只润色文档还顺手把项目名、认证方式、前端模板和复杂度这些开工前置项全部拍板。能力一句话说明对应源码初始规范生成调 LLM 把一句话描述扩写成完整规范并起项目名、初始化项目文件夹spec_writer.py迭代式补充需求循环追问还想加什么每次让 LLM 重写整份规范spec_writer.py复杂度判定用 LLM 把需求评为 hard / moderate / simple存进项目状态spec_writer.py认证与模板决策判断要不要登录注册按认证方式选前端模板spec_writer.py提示词约束规定规范里不写技术栈、测试和部署聚焦用户交互core/prompts/spec-writer/下面从启动到拿到第一份规范完整走一遍。跟着做从一句话到定稿规范先跑通一句话描述需求拿到第一版规范启动后描述要么来自--initial-prompt命令行参数要么交互式询问allow_emptyFalse不允许空输入。然后交给 LLM 扩写紧接着生成项目名、初始化文件系统description self.args.initial_prompt.strip() # 未提供则走交互式提问 llm self.get_llm(SPEC_WRITER_AGENT_NAME, stream_outputTrue) convo AgentConvo(self).template(build_full_specification, initial_promptdescription) llm_assisted_description await llm(convo) convo AgentConvo(self).template(project_name, descriptionllm_assisted_description) project_name (await llm(convo, temperature0)).strip() self.state_manager.project.folder_name project_name.replace( , _).replace(-, _) self.state_manager.file_system await self.state_manager.init_file_system(load_existingFalse)跑完后你会看到界面切到写规范阶段并流式输出正文知识库user_options里存下原始描述和 AI 版描述项目名落库工作目录按名字空格、连字符转下划线建好。项目名这一步用temperature0提示词 project_name.prompt 限死了2~3 个词、不超过 15 字符避免名字漂移。规范有了但一句话很难覆盖所有边角接下来进入追加循环。迭代补需求问一句还满意吗不满意就让 LLM 重写进入change_spec的循环前先确认你打算补什么。每次补充都触发整份规范的重新生成while True: answer await self.ask_question( Are you satisfied with the project description?, buttons{yes: Yes, no: No, I want to add more details}, buttons_onlyTrue, ) if answer.button yes: break user_add_to_spec await self.ask_question(What would you like to add?, allow_emptyFalse) convo convo.template(add_to_specification, user_messageuser_add_to_spec.text.strip()) if len(convo.messages) 6: convo.slice(1, 4) self.current_state.specification.description await llm(convo) convo convo.assistant(llm_assisted_description)现象是你每加一条细节规范就整段重新输出。注意 add_to_specification.prompt 的要求是重写整份规范并融入用户消息所以补充是整体重构而非追加段落消息数超过 6 条时会裁剪中间历史防止上下文撑爆。定稿认证判断与模板选择自动跑完你说满意之后后面两个决策不用你动手。先让 LLM 判断要不要登录注册need_auth.prompt需要就自动生成密钥再按认证方式挑模板auth (await llm(convo, temperature0)).strip().lower() yes if auth: self.next_state.knowledge_base.user_options[jwt_secret] secrets.token_hex(32) self.next_state.knowledge_base.user_options[refresh_token_secret] secrets.token_hex(32) if options[auth_type] api_key or options[auth_type] none: template_name vite_react_swagger else: template_name vite_react模板应用完成后specification.complexity字段也会被填上。此时规范定稿、项目名、认证方案、前端模板全部就绪交接棒递给 Tech Lead 拆 epic。拆开看它背后的两个决策复杂度为什么要交给 LLM 而不是规则匹配做个记账 App和多租户、带角色权限的记账 SaaS用关键词计数可能打平前者是 simple后者是 hard——词频规则抓不住语义。check_prompt_complexity 的做法是把整段描述丢给 LLM只允许它吐一个词hard / moderate / simpletemperature0压住发散StringParser()直接取字符串。还有一个容易忽略的参数is_feature当 epics 数量超过 2推测含义已有完整应用、这次是加新功能时提示词会额外带上完整规范让评估基于在什么底座上加功能来做而不是孤立看这句话。这个值最后落到specification.complexity供后续规划参考。模板选择为什么只按 auth_type 分支apply_template里只有一个分支api_key或none走vite_react_swagger其余走vite_react。逻辑很直白——用 API Key 或干脆不要认证的项目Swagger 文档界面比完整登录注册流程更有价值需要账号体系的就上带 auth 的模板。把模板选择从 LLM 手里拿走、压成单字段二值判断换来的是确定性同一份规范重跑模板永远一致。踩坑笔记以及接下来去哪描述写成了技术清单→ 规范生成后大段在讲 React、Node、数据库选型 → 提示词明确禁止这些内容见 build_full_specification.prompt初始描述改从用户交互写起用户能做什么、看到什么。补充需求后原文丢了→ LLM 每次重写整份规范结构可能被重排 → 定稿前通读一遍确认关键约束还在update_spec走 diff 确认ui.generate_diff就是为这类场景准备的。同一段需求两个入口结果不同→--initial-prompt非交互模式会自动选 node 栈交互模式则由 auth 决定模板 → 按最终想要的交付物选入口别混着用。复杂度评得不合理→ 后续规划节奏跟着complexity走 → 规范定稿前把关键约束补进描述让重估基于更完整的信息。这个模块比较适合中小规模、交互清晰、技术栈固定的 Web 应用规范定稿后会自动流转到 tech_lead.py 继续拆 epic。想看清规范长什么样被约束出来的翻一遍 core/prompts/spec-writer/ 目录里的提示词就行。git clone https://gitcode.com/GitHub_Trending/gp/gpt-pilot cd gpt-pilot环境配置和依赖安装步骤参考仓库自带文档 README.md。【免费下载链接】gpt-pilotThe first real AI developer项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-pilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考