Spec Coding能省21小时不返工，但90%团队用错场景反而拖慢开发_服务软件

1. 「Github一周热点90期」规格驱动开发、AI记忆引擎、AI agent的docker、开源流媒体平台、开源电商平台和密钥管理平台

2. Spec-Driven Development: 为混乱的 AI 编程增加工程纪律

3. 【为什么你的氛围编程总是翻车？一份让你真正能交付产品的完整指南】先把话说清楚：氛围编程本身没问题，问题出在你身上。你听说可以跟AI对话就能写出软件，于是觉得自己是魔法师。打开AI，用一句话描述你的想法，然后期待奇迹降临。结果呢？代码一塌糊涂，界面颜色乱飞，页面跳转失灵，应用勉强能跑但随时崩溃。然后你怪AI不行。真相是：AI产生幻觉不是因为它坏了，而是因为你什么都没给它。没有结构，没有清晰度，没有基础。AI是翻译器，把你的意图转化成代码。但如果你的意图本身就是一团浆糊，代码自然也是浆糊。修复方法不是更好的提示词，而是更好的理解。一旦你真正知道自己在构建什么，提示词就变得简单了。+ 文档先行，代码在后这是所有人都搞错的地方。你打开Cursor，开始聊天，让AI立刻写代码。没有计划，没有参考，没有真相来源。这就是为什么你的项目在写了几个文件后就崩溃。正确的系统是：先写文档，再写代码。永远如此。在写任何一行代码之前，你应该先写好项目的规范文档。清晰、具体、没有歧义地描述你要构建什么。为什么？因为AI编码工具能力很强但确定性很低。它们在没有结构性护栏的情况下执行任务。缺乏锁定的约束和权威文档会导致AI臆造需求、擅自做架构决策、写出解决你从未提出的问题的代码。失败模式不是编码能力不足，而是纪律和上下文保持的缺失。+ 六份核心文档在动手写代码之前，你需要准备这些：PRD.md是产品需求文档，完整规格说明。你在构建什么，为谁构建，有哪些功能，什么在范围内，什么明确排除在外。这是你的契约。AI读完就知道“完成”对你意味着什么。APP_FLOW.md记录每个页面和用户导航路径。什么触发每个流程，成功时发生什么，错误时发生什么。这防止AI猜测用户如何在你的应用中移动。TECH_STACK.md锁定每个包、依赖、API和工具的精确版本。当AI看到“用React”，它可能选任何版本。当它看到“Next.js 14.1.0, React 18.2.0, TypeScript 5.3.3”，它就会精确构建你指定的东西。FRONTEND_GUIDELINES.md是你的完整设计系统。字体、精确十六进制色值的调色板、间距比例、布局规则、组件样式、响应式断点。AI为它创建的每个组件参考这份文档。BACKEND_STRUCTURE.md定义数据库模式，每个表、列、类型和关系。认证逻辑、API端点契约、存储规则和边缘情况。IMPLEMENTATION_PLAN.md是逐步构建序列。不是“构建应用”，而是：步骤1.1初始化项目，步骤1.2安装依赖，步骤2.1按前端指南构建导航栏组件。步骤越多，AI猜测越少。+ 两个会话文件CLAUDE.md是AI每次会话自动首先读取的文件。它包含每个AI会话必须遵循的规则、约束、模式和上下文。把它想象成AI针对你特定项目的操作手册。progress.txt是所有人都忽略的文件。它追踪已完成、进行中和下一步的内容。每次完成功能就更新它，每次开始新会话AI就先读取它获取上下文记忆。没有它，每个新会话都从零上下文开始。AI在会话之间没有记忆。当你关闭终端、打开新终端或开始新聊天，一切都消失了。progress.txt是你的外部记忆，是会话之间的桥梁。+ 审问系统在写文档之前，让AI把你的想法撕碎。这是改变一切的提示词：“在写任何代码之前，在规划模式下无休止地审问我的想法。不要假设任何事情。问问题直到没有假设剩下。”AI在你的清晰度结束的地方产生幻觉。所以如果你延伸你的清晰度，你就迫使AI在开始构建之前找到你思维中的漏洞。+ 理解核心概念组件是可复用的界面片段。按钮是组件，导航栏是组件，产品卡片是组件。当你说“给我建一个落地页”，AI必须决定创建什么组件。如果你不指定，它就猜测。更好的提示词：“构建一个落地页，包含这些组件：导航栏、英雄区、功能网格三张卡片、推荐轮播、行动召唤区、页脚。”状态是会变化的数据。当你点击按钮有事情发生，状态改变了。当你的按钮什么都不做，通常是状态问题。点击发生了，但没有东西告诉应用更新。响应式意味着你的网站在所有屏幕尺寸上都能工作。移动优先意味着你先为最小屏幕设计，然后为更大屏幕添加复杂性。这不是偏好，是策略。+ 工具链Cursor是你的代码编辑器，有四种模式：Ask模式只读，用于理解代码；Plan模式用于在编码前架构；Agent模式是主力，自主写代码、编辑文件、运行命令；Debug模式用于顽固的bug。Claude用于重度思考：审问想法、写六份核心文档、规划架构。Kimi K2.5是前端实现的专家。你可以给它截图或设计稿，它生成紧密匹配视觉的功能性前端代码。Codex是你的调试器和终结者。在文件和架构构建完成后使用它。当结构就位但东西在崩溃时，让它找到你遗漏的bug。多工具工作流：Claude做思考，Cursor或Claude Code或Kimi K2.5做构建，Codex做调试和收尾。+ 迭代是常态每个人的第一个输出很少是对的。这没关系。好的迭代：“产品网格在桌面端显示4列但我需要3列。卡片图片被拉伸了，应该是object-cover。数据获取时没有加载状态。”坏的迭代：“看起来不对，修一下。”具体。永远具体。+ 发布前检查在手机上能用吗？实际在手机上打开它。在不同浏览器能用吗？没有数据时会发生什么，空状态处理了吗？错误数据呢？慢网络呢？快速点击能打破它吗？不要在回答这些问题之前发布。你的用户会找到你遗漏的每一个bug。+ 完整系统总结构建前：运行审问提示词，回答每个问题，生成六份核心文档，写CLAUDE.md，创建progress.txt，收集UI截图参考，初始化git。构建中：AI每次会话先读CLAUDE.md和progress.txt，用Ask和Plan模式架构，用Agent模式实现，小块工作，给出引用文档的具体提示词，每个功能后提交git并更新progress.txt。发布前：检查移动端、错误状态、空状态，验证秘钥隐藏，端到端测试主用户流程。氛围编程不是黑魔法。它是细致的规划、系统、文档、词汇和迭代。你审问你的想法，写你的文档，设置持久化和自我改进，为每个阶段使用正确的工具，用具体术语描述工作，追踪会话间的进度，提交代码，然后发布。AI现在做所有的打字。你做所有的思考。现在你没有任何借口了。去构建点什么吧。x.com/kloss_xyz/status/2018097344345223455

4. 大型 codebase 如何用好 Claude Code？第一层：spec 文件是地基每个模块、每个功能，都要有对应的 spec 文件。不是让你写文档——而是给 Claude Code 划定工作边界：这个模块是干什么的、有哪些约束、什么情况算完成。有了 spec，Claude Code 就不会在你改 A 的时候顺手动了 B。没有 spec，它会用"它认为合理"的逻辑推断——而这个推断大概率跟你想的不一样。第二层：registry 文件体系——给 Claude Code 一个"世界观"光一个 CLAUDE.md 不够，大项目需要一整套 registry：1. plan-registry.md：当前在推进什么、优先级是什么2. spec-registry.md：各模块规格入口，Claude 改代码前必须先查3. development-registry.md：正在开发中的模块状态4. test-registry.md：测试范围和覆盖要求5. validation-registry.md：验收标准，什么叫"完成"关键认知转变：这不是给人看的文档，是 Claude Code 的项目地图。只要你每次任务后让它更新对应的 registry，它就能在大型 codebase 里持续、可靠地工作——不需要每次重新交代上下文。第三层：任务拆细，session 保持聚焦不要让 Claude Code 一次处理太多文件。任务越大，上下文越长，越容易"跑偏"。正确姿势是：一个 session 只做一件明确的事，做完就结束，下一个任务新开 session。#HOW I AI# #程序员#

5. OpenSpec：面向 AI 编程的规范驱动开发框架

6. 【让AI写代码更靠谱的秘诀：先规划，后记录，再验证】用Claude Code开发功能时，很多人直接让它动手写代码，结果往往是代码越写越乱，新开一个会话又要从头解释一遍。Drew Wilson分享了一套简单但极其有效的工作流：第一步，永远让它先写计划再动手。这一步看似多余，实则关键。解释的过程会暴露它是否真正理解了你的需求，能在错误假设变成500行代码之前就把它拦住。第二步，代码写完后让它更新一份命名清晰的文档。这份文档就是项目的长期记忆。没有它，每个新会话都要从零开始理解之前构建了什么。第三步，让它验证文档和代码是否一致。双向校验，确保两边不会脱节。之后每次让新的Agent完成任务，都要求它“更新相关文档”。文档命名得当的话，这套流程会像魔法一样顺滑。有人担心文档太多会造成上下文膨胀。其实不需要让每个新Agent读完所有文档，只需要说“读取与你工作相关的文档”，它自己会找到对应的内容。社区里还有几个补充技巧值得一提：在文件开头用100行左右的注释写清文档说明，这样Agent读取文件时自动获得上下文，省去额外调用。维护一个CHANGELOG，记录每次改了什么、为什么改。后续会话扫一眼就能快速上手，上下文成本极低。在Claude.md里建一个简单索引，标注文件名和对应内容，帮助新会话精准拉取需要的文档。还有一条容易被忽视：让它动手前先问清楚所有问题，不要自作主张做强假设。主动暴露信息缺口，比事后返工高效得多。这套方法的本质是把AI当成需要交接文档的团队成员来管理。代码会过期，但好的文档能让知识持续流转。对人类团队成员来说，review和理解系统运作也会轻松很多。看起来是“额外步骤”，实际上是在为未来的自己和团队省时间。x.com/drewwilson/status/2017496985511858352

7. Harness Engineering（驭缰工程）是 OpenAI 在 2026 年 2 月提出的工程范式：工程师不再写代码，而是设计环境、明确意图、构建反馈回路，让 AI 智能体可靠地完成工作。传统工程：人类写代码 → 机器执行代码Harness Engineering：人类设计约束 → 智能体写代码 → 机器执行代码核心转变：工程师的产出从代码变成了约束系统——AGENTS.md、架构规则、自定义 linter、反馈回路。给大家推荐一个开源项目：Harness Engineering 学习指南，感兴趣的可以了解一下 Harness Engineering 。传送门：github.com/deusyu/harness-engineering#科技先锋官##How I AI#

8. 昨天和某个明星AI公司的产品VP聊完，更加确信一点：如果这事发生在湾区公司，势必会朝这个方向演进——懂需求、懂产品的人，终将打败只懂技术的人。在这个AI逐渐平权的时代，轻量化小团队的机会，正变得越来越大。我们梳理出了未来产品经理演进的三个关键趋势：一、从文档到Demo，交互即沟通从字节到阿里，老板们已经开始要求“不看文档，只看AI生成的Demo”。比起PPT和冗长需求文档，可交互的Demo更容易理解、更接近真实体验。多年前，蒋凡开会就经常不带电脑，直接用iPad或手机演示产品原型。区别在于，过去这类Demo需要产研团队协作完成，而现在，1-3人借助AI工具就能快速实现。二、产品经理，必须成为“能Demo的工程师”未来，不会写Demo的产品经理，会像不会用相机的摄影师一样被淘汰。“Demo型工程师”正在从产品和UI岗位中诞生，而传统研发更多是“落地型工程师”。最终，所有人都会向“全栈型产品工程师”进化。最近几场黑客松也印证了这一点：快速Demo + 社交媒体获客 + 敏捷迭代，已成为新产品的标准路径。产品经理的落地能力将迎来质的飞跃——告别纸上谈兵，拥抱动手建原型。三、Spec Coding 必将普及，PRD = Code先写文档再开发，本就是产品基本功。而现在，你可以直接招产品经理，让他们学会Vibe Coding风格，从Spec直出Demo。再加上AI能生成高质量、可迭代的PRD，整个工作流正在闭环：Spec = PRD = Code而像 OpenSpec 或 SpecKit 这类工具，将进一步把所有模型规范统一起来，减少AI幻觉，让想法到代码的路径更短、更可控。为什么这个趋势不可逆？背后是效率与组织逻辑的必然结果：沟通损耗大幅降低大厂研发流程被重构，人效提升小团队凭借敏捷和低成本Demo能力，加速崛起当想法能快速被验证，团队规模就不再是执行力的天花板。最终比拼的，只剩下谁的洞察更强、谁的创意更准。

9. 目前的做大需求的工作流：1. 使用 Claude Opus 4.6 编写技术方案文档2. 使用 GPT-5.3-Codex 将文档拆解成一系列小需求3. 使用 GLM-5 逐个开发小需求4. 所有需求开发完毕后，再次使用 GPT-5.3-Codex 进行整体 Review、兜底

10. Vibe Coding 是一个基于 AI 结对编程理念打造的终极开发工作站，旨在帮助开发者高效、系统地将创意转化为可维护代码。它融合了作者多年开发经验与丰富的提示词库，形成一套严谨且灵活的流程体系，强调规划驱动与模块化设计，避免 AI 失控造成项目混乱。核心理念在于“规划就是一切”，通过定义生成器（α-提示词）与优化器（Ω-提示词）两大母体提示词，构建递归自我优化的 AI 系统，使提示词及技能持续进化，最终实现无限逼近预期目标的自我超越。Vibe Coding 提供完整的开发流程指南：从网络环境配置、开发环境搭建、IDE 设置，到项目设计文档撰写、技术栈推荐、实施计划生成，再到代码实现、测试与迭代，每一步均配合 AI 进行，确保开发高效且可控。特别强调先结构后代码，避免技术债务积累。工具链方面，推荐使用 Visual Studio Code、Neovim 等强大编辑器，配合 Claude Opus 4.5、gpt-5.1-codex 等顶级 AI 模型，实现代码生成、测试、调试、文档管理等一体化工作流。还集成了丰富的辅助工具如 Augment (上下文引擎)、Zread (代码阅读)、tmux（终端复用）、DBeaver（数据库管理）等，极大提升开发体验。项目配套了详尽的提示词库，涵盖系统提示词、编程提示词、用户提示词及辅助提示词，支持快速构建高质量的 AI 交互策略。通过严格的规则和上下文管理，确保 AI 生成代码的质量与一致性。此外，Vibe Coding 还提供丰富的实用技巧和常见问题解答，帮助开发者快速上手并解决开发中遇到的各种挑战。其开源 MIT 许可让社区能自由贡献与扩展。Vibe Coding 通过“规划驱动 + 上下文固定 + AI 结对执行”，让「从想法到可维护代码」成为一条清晰且可审计的流水线，极大提升了开发效率与代码质量。项目开源地址：github.com/tukuaiai/vibe-coding-cn无论是新手入门还是资深开发者，Vibe Coding 都能帮助你驾驭 AI 助力的开发新时代。

11. 最近vibe coding的心得是：先用google studio按直觉和线性思路，先一点一点把东西搭出来。因为google studio的页面即时可视化和UI视觉水平很不错，所以能给人很好的直观感受。然后要求stuido反过来写详细的prd和开发文档。接着用claude、kimi或gpt来modify prd和开发文档。最后把优化好的文档再让codex或claude code重新把项目做一遍。

12. 最近不少讨论或倡导 Spec 驱动开发（SDD）的又多起来了，不过对 SDD 一直有个疑虑：目前还没见过能完全通过 Spec 支撑的大型复杂系统。这很像用一份提纲去写长篇小说：LLM 生成第 50 章时，如果不能完美加载前 49 章所有的伏笔和细节，内容就会出现严重的割裂感。理论上所有子模块确实可以按 Input/Output 独立开发，但真实的业务逻辑是网状耦合的。为了消除歧义，你必须把 Spec 定义得极度细致，细到最后，你会发现写 Spec 的工作量和严谨度，其实跟直接写代码已经没什么区别了。

13. 渐进式_Spec

14. 用手工 Spec Coding 开发“基金申赎指令审核与复核”应用（附实践模板）

15. 写代码前先写文档？这才是把AI用对姿势

16. 用AI写代码，这5个习惯直接封神

17. 高频技能手册 vol. 02｜AI 接手项目总是先跑偏

18. 为什么你用AI写代码效率没提升？尤雨溪的一个习惯点醒了我

19. AI写代码又快又烂？Google工程师忍不了了，直接开源了一套"治懒"技能包

20. 别再瞎写代码了！阿里大佬都在用的"规范驱动开发"，让我准时下班的秘密武器

21. Superpowers，让 AI 写代码不再“乱来”

22. 很多人还在吹Spec驱动开发，我已不用了。我以前认真用过很多 spec-driven 工作流。

23. 2026 年 AI 编码的「渐进式 Spec」实战指南

24. 规范驱动 AI 编程实战指南

25. SDD（Spec Driven Development）规范驱动开发实践

26. AI生成代码全是屎山？2026工程化新范式

27. 规范驱动开发（Spec-Driven Development，SDD）

28. 一文带你深入理解AI SDD(规范驱动开发）开源框架SPEC KIT

29. GitHub Spec Kit

30. 用SPEC-KIT告别低效的AI编程

31. SDD入门实操

32. OpenSpec 规范驱动开发(SDD)详解

33. Spec-Kit+Copilot打造AI规格驱动开发

34. spec-kit (SDD)规范驱动开发的 Plan B

35. OpenSpec 避坑实战

36. GitHub Spec-Kit 规范驱动开发是正确方向

37. 使用 GitHub Spec Kit 的 Spec-Driven 开发教程

38. Spec 驱动开发（SDD）流程总结

39. 规范驱动开发

40. 深入了解 Spec Kit

41. Spec-Driven Development

42. spec coding 辅助工具推荐。现在都推崇spec coding了，分享几个不错的辅助编程工具👇

43. 最近一个月用 Cursor 的7条真香经验！

44. Windsurf想让AI当“总架构师”，你却当“代码审查员”？

45. AI Spec驱动开发

46. AI程序（Vibe vs. Spec）

47. 小孩子才做选择，成年人全都要

48. AI编程如何告别屎山代码

49. 代码越写越乱，重构永无止境？你可能陷入了“氛围编码”的陷阱

50. 重塑软件工程

51. GitHub SpecKit 深度解析

52. 系统软件开发中文档编写技巧的关键方法与实战指南

53. API 文档功能，让你效率翻倍

54. 内容

55. 从无人问津到巨头混战,AI为什么最先点燃了编程?

56. 系统开发文档怎么写

57. AI编程下的需求规格文档的问题及新规范

58. Comate Spec模式实测:让AI编程更精准可靠

59. Spec-Driven Development(SDD)

60. 被吐槽文档写得太烂?资深工程师教你一招翻身

61. [系列]各类文档转MarkDown的技术调研-AI考核点打分规则

62. 别再让AI瞎写代码！亲测有效的3步流程，比“直接构建”快2倍

63. 微软发布spec-kit，规格驱动开发，vibe-coding 危机，结合cursor-cli部署实战相册管理

64. 用 Codex + GitHub Spec Kit 做一次“规格驱动开发”实战

65. Github Spec Kit 轻松入门

66. 大厂集体押注 SDD！阿里、腾讯、亚马逊都在用的规范驱动开发，优势在哪？坑怎么避？

67. OpenSpec原理解析与使用详解

68. AI开发工具SpecKit深度解析：Spec-Driven Development框架

69. AI辅助工具：SpecKit、BMAD-METHOD与OpenSpec的协同整合，以降低了AI生成代码的不确定性，覆盖SDLC

70. 拥抱AI编程,用中文进行规范驱动开发:OpenSpec汉化版正式发布

71. [V0.1.0-1]规范驱动的AI辅助编程，初版代码出炉

72. Spec-kit 日更系列之初体验：spec 和 plan 对人的要求很高，是一个不能简单放权的事情

73. 关于一篇Spec-Driven文章的阅读理解

Spec Coding能省21小时不返工，但90%团队用错场景反而拖慢开发

精选参考来源