你的需求文档就是新代码！黄叔揭秘「结构化提示词」(SPEC)如何驱动AI完成开发 | 43 Talks

你的需求文档就是新代码！黄叔揭秘「结构化提示词」(SPEC)如何驱动AI完成开发 | 43 Talks 你的需求文档就是新代码！黄叔揭秘「结构化提示词」(SPEC)如何驱动AI完成开发 | 43 Talks Modified September 11, 2025 • 左端： 100%人类干预。AI每生成一行代码，你都要像监工一样去审查、修改、确认。 • 右端： 100% AI自主。你给出一个清晰的目标，AI就能自主规划、编辑、甚至跨文件操作，完成整个项目。 以知名的AI编程工具Cursor为例，它的进化路径完美诠释了“自主滑块”的移动。 "拿Cursor来举例，它有个演进过程：一开始大家更多用它的Tab做代码补全，但现在慢慢变成了，基本就让大家把中间的页面关掉，只需要右侧去跟它聊。现在它还上线了background agent（后台代理），可以同时有四个任务在云端运行，直接为你生成代码。" Karpathy认为，随着模型能力的进化，会有越来越多的自主权可以交给AI。这意味着，权力的天平正在倾斜，“自主滑块”会不断向右移动。因此， 对应的结构化提示词也更重要了。 03. "Everything is a SPEC" 黄叔引用了OpenAI一个研究员的观点" Everything is a SPEC "，虽然标题有点像暴论，但核心观点很有价值： 1. "If you can communicate, you can program." 会沟通，就会编程 2. " Communication first, code second." 沟通先行，代码随至 3. 代码只决定了10 20%的成败，其余的80 90%源自“结构化沟通” 4. 结构化的沟通包含在整个产品设计过程 5. 沟通中已经全部包含了生成代码所需的所有必要要求 （注：SPEC是一种定义软件需求的结构化范式，它虽然用自然语言编写，却拥有代码般的严谨与精确，从而充当了人类意图与AI执行之间那个高精度、无歧义的接口，让AI可以直接生成软件） "如果要开发一个应用程序，作为产品做了好多年，这一套很熟悉：需要沟通很多轮，要做产品需求文档，不停地跟团队battle，上线之前要测试。这里面很多都是要沟通的。我们过去一个产品需求评审，经常被diss说需求文档写得不够详细，边界情况描述得不够清楚。" 04. 顶级IDE的共识： 向SPEC驱动的方向进化 黄叔还观察到，全球顶级的AI开发工具（IDE），早已不约而同地朝着SPEC这个方向狂奔。它们都在用自己的方式，告诉你同一个道理： 先有SPEC，后有代码。 • Cursor的Rules系统： 开发小程序、网页、APP，每种场景都有预设的规则（Rules），告诉模型该用什么技术栈、遵循什么规范。 "比如我开发微信小程序、开发APP、开发前端网页，每一种情况下都有对应的rules去约束，告诉模型应该用哪些技术栈，应该怎样开发，有什么样的边界情况。" • Kilo的强制三步走： 堪称“SPEC原教旨主义者”。强制你必须走完“需求 需求文档 系统框架 To do List”的流程，才能开始写代码。 "最近也很火，它最火的就是SPEC，自己官宣的上面就是SPEC driven。在开发过程中，强制要求三步必须一步步给出来：先输入需求，必须生成需求文档，基于需求文档再构建整个系统框架，然后再出todo list。它严格规定，必须先出文档，再进入开发阶段。" • Claude Code的Plan Mode： 黄叔最喜欢的工具之一。进入“计划模式”，AI不会直接写代码，而是先出一份详尽的文档和你确认。 "我最近最喜欢的，按住Shift+Enter，它就会进入Plan Mode（计划模式）。这时候跟它说任何事情，它不会直接进入代码开发。比如说我跟他说一个需求，或者有了bug让他解决，在这个模式里，他会先出一系列文档跟你确认。" • Trickle.so的Knowledge模块： 这个网页开发神器，有一个专门的“知识库”模块，记录了项目的PRD、技术架构等，所有开发都必须遵循这个“宪法”。 "它在里面专门有个模块叫knowledge，可以看到readme里面非常清晰，就是一个类似于PRD的MD，包括技术架构、页面结构。所有开发都会遵循这样的指令，使得它是我们见过开发网页效果最好的编程工具。" 05. 黄叔亲授： 实战案例，看SPEC带来的降维打击 理论总是抽象的，为了让大家更具体地理解“结构化沟通”的魔力，黄叔还分享了几个亲身经历的实战案例，展示如何通过SPEC，让 AI 成为我们可靠的、可复现的生产力伙伴。 案例一： 用 ASCII 码，画出可复现的产品蓝图 这个想法来自黄叔的朋友“刘小白”。他想用 AI 辅助产品设计，但如何确保 AI 的理解和我们的构想完全一致，并且这个构想可以被精确传递呢？ 黄叔的方法是： 用 ASCII 画草图 1. 初步构想： 让 AI 先用 ASCII 画一个产品界面的大概样子，就可以对布局有个基本感知。 2. 迭代优化： 让它生成五个不同版本，挑选最满意的一版，再上传一张参考图片，并让它遵循该图片进行优化。 3. 生成 SPEC： 当草图最终敲定后，让它总结成一个详细的文档。 4. 压力测试： 第二天，让它根据这份文档，复原出最终的产品草图。 5. 结果令人惊喜：AI 几乎能 100% 复原出前一天那个一模一样的 ASCII 画作。 “这就是一种SPEC的逻辑，只要有了这个SPEC，谁来都能画出这个东西。” 案例二： 从一次性任务中提取“万能配方” 黄叔“得到”上课时，发现他们有大量的私域运营工作是，每周要把几篇文章变成一个HTML网页发给所有私域用户。 他的建议非常直接： 1. 生成网页： 打开 Gemini 1.5 Pro，把这几个文档上传上去，让它生成一个好看的HTML网页。 2. 提炼配方： 调几版之后，得到了满意的页面，让它把提示词抽出来。它的结构非常精细。 3. 跨平台复用： 拿着这个结构，随便用 DeepSeek、Kimi 或者豆包，都能够80% 90%复现那个结果。这也是一个非常结构化的提示词。 这个被提炼出来的“结构化提示词”，就是一个可复用的 SPEC。它把一次成功的创作，变成了一套可靠的生产流程。 案例三： 跨模型开发，用“高级 IDE”为“初级 IDE”写代码 今年 2 月，黄叔与 Kimi 团队合作制作一个教程。当时 Kimi 刚上线，对于模型理解，比如 system prompt 这些做得不好，上下文也比较短。 有一次，调试提示词很久也无法给出想要的结果。在挫败中，黄叔转换了思路： 1. 寻求外援： 我直接打开了另一个Web 服务，将同样的需求输入进去，结果一下子就得到了想要的结果。 2. 反向工程： 让那个服务提取出能一次成功的提示词 3. 降维打击： 再把这个提示词复制到 Kimi 里面。 结果，Kimi 也立刻生成了正确的结果。这个过程，有点像是高级IDE到低级IDE的开发复刻。好多学员拿着类似提炼出来的提示词，基本都能在很短的步骤里面复现同样的结果。 案例四： 打造 90% +复现率的“UI 设计”指令 Claude 4 Sonnet 刚出来的时候，黄叔研发了一套提示词，会给它几个必须严格遵循的大概事项。用户输入他们想要的，比如做一个点单APP，他就会自己去生成对应的前端样式。 这套提示词里把UI风格、设计规格和一些边界问题都写得清清楚楚。所以只要用 Claude 加上这个提示词，大概率都能出非常不错的UI，复现率在90%以上。 最后，黄叔还进行了总结，在软件3.0时代，SPEC 就是 Code。随着模型越来越厉害，SPEC 就越来越接近于 Code。越往后，模型能力越强，SPEC 占的权重就会往这边挤压。 非常重要的是，SPEC 这种结构化的表达就是“Write once, run everywhere”。一旦这个结构出来了，你放在任何地方，它都能输出非常接近的结果。当然也需要注意的是，不同的模型可能对于这种平时的遵循不太一样。 本文根据黄叔在43 Talks现场分享整理而成，部分内容有删减和编辑。 关于43 Talks 本次分享干货满满，后续我们还将整理 更多嘉宾的精彩内容， 敬请关注 。 • 左端： 100%人类干预。AI每生成一行代码，你都要像监工一样去审查、修改、确认。 • 右端： 100% AI自主。你给出一个清晰的目标，AI就能自主规划、编辑、甚至跨文件操作，完成整个项目。 以知名的AI编程工具Cursor为例，它的进化路径完美诠释了“自主滑块”的移动。 "拿Cursor来举例，它有个演进过程：一开始大家更多用它的Tab做代码补全，但现在慢慢变成了，基本就让大家把中间的页面关掉，只需要右侧去跟它聊。现在它还上线了background agent（后台代理），可以同时有四个任务在云端运行，直接为你生成代码。" Karpathy认为，随着模型能力的进化，会有越来越多的自主权可以交给AI。这意味着，权力的天平正在倾斜，“自主滑块”会不断向右移动。因此， 对应的结构化提示词也更重要了。 03. "Everything is a SPEC" 黄叔引用了OpenAI一个研究员的观点" Everything is a SPEC "，虽然标题有点像暴论，但核心观点很有价值： 1. "If you can communicate, you can program." 会沟通，就会编程 2. " Communication first, code second." 沟通先行，代码随至 3. 代码只决定了10 20%的成败，其余的80 90%源自“结构化沟通” 4. 结构化的沟通包含在整个产品设计过程 5. 沟通中已经全部包含了生成代码所需的所有必要要求 （注：SPEC是一种定义软件需求的结构化范式，它虽然用自然语言编写，却拥有代码般的严谨与精确，从而充当了人类意图与AI执行之间那个高精度、无歧义的接口，让AI可以直接生成软件） "如果要开发一个应用程序，作为产品做了好多年，这一套很熟悉：需要沟通很多轮，要做产品需求文档，不停地跟团队battle，上线之前要测试。这里面很多都是要沟通的。我们过去一个产品需求评审，经常被diss说需求文档写得不够详细，边界情况描述得不够清楚。" 04. 顶级IDE的共识： 向SPEC驱动的方向进化 黄叔还观察到，全球顶级的AI开发工具（IDE），早已不约而同地朝着SPEC这个方向狂奔。它们都在用自己的方式，告诉你同一个道理： 先有SPEC，后有代码。 • Cursor的Rules系统： 开发小程序、网页、APP，每种场景都有预设的规则（Rules），告诉模型该用什么技术栈、遵循什么规范。 "比如我开发微信小程序、开发APP、开发前端网页，每一种情况下都有对应的rules去约束，告诉模型应该用哪些技术栈，应该怎样开发，有什么样的边界情况。" • Kilo的强制三步走： 堪称“SPEC原教旨主义者”。强制你必须走完“需求 需求文档 系统框架 To do List”的流程，才能开始写代码。 "最近也很火，它最火的就是SPEC，自己官宣的上面就是SPEC driven。在开发过程中，强制要求三步必须一步步给出来：先输入需求，必须生成需求文档，基于需求文档再构建整个系统框架，然后再出todo list。它严格规定，必须先出文档，再进入开发阶段。" • Claude Code的Plan Mode： 黄叔最喜欢的工具之一。进入“计划模式”，AI不会直接写代码，而是先出一份详尽的文档和你确认。 "我最近最喜欢的，按住Shift+Enter，它就会进入Plan Mode（计划模式）。这时候跟它说任何事情，它不会直接进入代码开发。比如说我跟他说一个需求，或者有了bug让他解决，在这个模式里，他会先出一系列文档跟你确认。" • Trickle.so的Knowledge模块： 这个网页开发神器，有一个专门的“知识库”模块，记录了项目的PRD、技术架构等，所有开发都必须遵循这个“宪法”。 "它在里面专门有个模块叫knowledge，可以看到readme里面非常清晰，就是一个类似于PRD的MD，包括技术架构、页面结构。所有开发都会遵循这样的指令，使得它是我们见过开发网页效果最好的编程工具。" 05. 黄叔亲授： 实战案例，看SPEC带来的降维打击 理论总是抽象的，为了让大家更具体地理解“结构化沟通”的魔力，黄叔还分享了几个亲身经历的实战案例，展示如何通过SPEC，让 AI 成为我们可靠的、可复现的生产力伙伴。 案例一： 用 ASCII 码，画出可复现的产品蓝图 这个想法来自黄叔的朋友“刘小白”。他想用 AI 辅助产品设计，但如何确保 AI 的理解和我们的构想完全一致，并且这个构想可以被精确传递呢？ 黄叔的方法是： 用 ASCII 画草图 1. 初步构想： 让 AI 先用 ASCII 画一个产品界面的大概样子，就可以对布局有个基本感知。 2. 迭代优化： 让它生成五个不同版本，挑选最满意的一版，再上传一张参考图片，并让它遵循该图片进行优化。 3. 生成 SPEC： 当草图最终敲定后，让它总结成一个详细的文档。 4. 压力测试： 第二天，让它根据这份文档，复原出最终的产品草图。 5. 结果令人惊喜：AI 几乎能 100% 复原出前一天那个一模一样的 ASCII 画作。 “这就是一种SPEC的逻辑，只要有了这个SPEC，谁来都能画出这个东西。” 案例二： 从一次性任务中提取“万能配方” 黄叔“得到”上课时，发现他们有大量的私域运营工作是，每周要把几篇文章变成一个HTML网页发给所有私域用户。 他的建议非常直接： 1. 生成网页： 打开 Gemini 1.5 Pro，把这几个文档上传上去，让它生成一个好看的HTML网页。 2. 提炼配方： 调几版之后，得到了满意的页面，让它把提示词抽出来。它的结构非常精细。 3. 跨平台复用： 拿着这个结构，随便用 DeepSeek、Kimi 或者豆包，都能够80% 90%复现那个结果。这也是一个非常结构化的提示词。 这个被提炼出来的“结构化提示词”，就是一个可复用的 SPEC。它把一次成功的创作，变成了一套可靠的生产流程。 案例三： 跨模型开发，用“高级 IDE”为“初级 IDE”写代码 今年 2 月，黄叔与 Kimi 团队合作制作一个教程。当时 Kimi 刚上线，对于模型理解，比如 system prompt 这些做得不好，上下文也比较短。 有一次，调试提示词很久也无法给出想要的结果。在挫败中，黄叔转换了思路： 1. 寻求外援： 我直接打开了另一个Web 服务，将同样的需求输入进去，结果一下子就得到了想要的结果。 2. 反向工程： 让那个服务提取出能一次成功的提示词 3. 降维打击： 再把这个提示词复制到 Kimi 里面。 结果，Kimi 也立刻生成了正确的结果。这个过程，有点像是高级IDE到低级IDE的开发复刻。好多学员拿着类似提炼出来的提示词，基本都能在很短的步骤里面复现同样的结果。 案例四： 打造 90% +复现率的“UI 设计”指令 Claude 4 Sonnet 刚出来的时候，黄叔研发了一套提示词，会给它几个必须严格遵循的大概事项。用户输入他们想要的，比如做一个点单APP，他就会自己去生成对应的前端样式。 这套提示词里把UI风格、设计规格和一些边界问题都写得清清楚楚。所以只要用 Claude 加上这个提示词，大概率都能出非常不错的UI，复现率在90%以上。 最后，黄叔还进行了总结，在软件3.0时代，SPEC 就是 Code。随着模型越来越厉害，SPEC 就越来越接近于 Code。越往后，模型能力越强，SPEC 占的权重就会往这边挤压。 非常重要的是，SPEC 这种结构化的表达就是“Write once, run everywhere”。一旦这个结构出来了，你放在任何地方，它都能输出非常接近的结果。当然也需要注意的是，不同的模型可能对于这种平时的遵循不太一样。 本文根据黄叔在43 Talks现场分享整理而成，部分内容有删减和编辑。 关于43 Talks 本次分享干货满满，后续我们还将整理 更多嘉宾的精彩内容， 敬请关注 。 🔗 原文链接： https://mp.weixin.qq.com/s/xXqkDnLC... https://mp.weixin.qq.com/s/xXqkDnLC... 原创 言晏 43 Talks2025年08月21日 18:04 北京 你有没有想过，有一天开发一个APP，不再需要你苦哈哈地写上成千上万行代码，而只需要你—— 把需求说清楚 ？ 这不是幻想，正在成为现实。在近期由 43 College 与 易论AI 联合发起的 43 Talks 首期 “共话Vibe Coding：从探索到落地” 线下思辨沙龙中，重磅嘉宾 AI产品黄叔 为我们揭示了这个颠覆性的未来。 本文根据黄叔的现场分享整理而成，他的核心观点振聋发聩： 一个新时代正在到来，而“结构化提示词”（SPEC），就是这个时代的“新代码” 。 01. Karpathy的预言： 最热门的编程语言是英语 你还在卷Python、Java吗？特斯拉前AI总监、OpenAI创始成员Andrej Karpathy早就给出了他的答案。 黄叔特别推崇Karpathy的观点。在分享中，将Karpathy的 “软件演进三段论” 讲得明明白白： • 软件1.0： 传统的手工敲代码 • 软件2.0： 开始训练模型权重 • 软件3.0 ： 通过给LLM提示词，直接生成应用程序 这听起来很遥远？但它已经来了。 黄叔提到一个近期发布的产品“马卡龙”，你可以跟他聊天，他是一个personal agent。它的神奇之处就在于：你跟它聊天，它就能帮你把需求生成一个应用程序。 “你跟他说‘帮我每天早上8点钟生成一个昨天我们聊天的内容摘要’，它会直接帮你生成一个应用程序。你跟他说话，他就帮你生成应用程序！” 这就是软件3.0的魔力： 提示词Prompt 就是程序，编程语言是英语。 而提示词到底有多重要？ Karpathy认为，模糊指令导致验证失败，会陷入反复修改的恶性循环。但花时间精确描述需求，则能够显著提升成功率。因此，诞生了一句新格言："Code is cheap. Show me the prompts."（“代码已廉价，亮出提示词。”） 02. “自主滑块”： 从人肉监工到AI主导，权力正在交接 那么，我们该如何从“敲代码”过渡到“说需求”？ 黄叔抛出了一个极其关键，却鲜为人知的概念—— “自主滑块”（Autonomy Slider） 。 想象一个滑块：