首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏深度学习与python

    规范驱动开发:瀑布模型回潮

    规范驱动开发(SDD)重拾了编码前撰写大量文档的旧理念——这就像是瀑布式开发时代的回响。尽管它承诺为 AI 驱动的编程提供结构框架,却可能让敏捷性被层层 Markdown 文档所掩埋。 (BMM) 若需了解这些工具的差别,Birgitta Böckeler 写过一篇精彩的文章“理解规范驱动开发:Kiro、spec-kit 与 Tessl”。 开发那个实验。若失败,返回步骤 2;否则从步骤 1 重新开始。 这里有一个示例:这款具备自适应网格功能的 3D 雕刻工具,是我与 Claude Code 耗时约 10 小时共同开发完成的。 相较于规范驱动开发,这种方法存在一个缺陷:它没有专属名称。“氛围编码”听起来有些随意,不如称之为 自然语言开发。 不过,确实有个问题困扰着我:编码代理使用文本而非视觉元素。 规范驱动开发似乎诞生于那些熟记项目管理教科书的计算机科学毕业生之手,他们梦想着将开发人员从软件开发流程中剔除。

    52810编辑于 2025-12-24
  • 规范驱动开发:AI 编程的正确姿势

    规范驱动开发,能让这个过程变得可控。 为什么需要规范驱动开发? 答案是:文档是静态的,开发是动态的。 文档写完就被遗忘,而规范驱动开发要求规范贯穿整个开发周期。 什么是规范驱动开发? 一句话概括:在写代码之前,先写规范;在实现过程中,持续回顾规范规范驱动开发不只是"先写文档",而是将规范作为开发过程的核心驱动力量。 三个层次,一个核心 规范驱动开发分三个层次,但核心只有一个:规范是活的,不是死的。 规范驱动开发的真正价值在于形成持续的反馈循环: 需求 → 规范 → 实现 → 反馈 → 更新规范 → 迭代实现 → ... 以 GSD (Get Shit Done) 为例,看看规范驱动开发如何付诸实践。

    14810编辑于 2026-06-15
  • 来自专栏深度学习与python

    规范驱动开发:让架构变得可执行

    作为这些进步的一部分,一套关键的工具出现了,集中在规范驱动开发(SDD)上。 SDD 架构 规范驱动开发(SDD)这个名字可能暗示了一种方法论,类似于测试驱动开发。然而,这种框架低估了它的重要性。 ,安全范围正在退化 没有漂移检测,SDD 就会退回到文档驱动开发。 软件系统将越来越多地受到人类驱动开发和机器驱动生成的影响,通常在同一规范表面上并行操作。系统中不再有单一的线性路径。更改可能来自开发者、AI 代理、自动化重构工具或政策驱动的生成器。 当这些能力中的任何一个缺失时,SDD 就会退回到文档驱动开发或临时代码生成。

    57610编辑于 2026-01-22
  • 规范驱动开发:AI 编程的正确姿势

    规范驱动开发:AI编程的正确姿势给AI几句模糊的提示词,然后祈祷它生成可用的代码——这就是"氛围编程"。规范驱动开发,能让这个过程变得可控。为什么需要规范驱动开发? 答案是:文档是静态的,开发是动态的。文档写完就被遗忘,而规范驱动开发要求规范贯穿整个开发周期。什么是规范驱动开发?一句话概括:在写代码之前,先写规范;在实现过程中,持续回顾规范规范驱动开发不只是"先写文档",而是将规范作为开发过程的核心驱动力量。三个层次,一个核心规范驱动开发分三个层次,但核心只有一个:规范是活的,不是死的。 为项目创建一个完整的规范文档,制定设计和实现计划,然后开始实现……但在实现过程中把规范抛诸脑后。这不是真正的规范驱动开发。 以GSD(GetShitDone)为例,看看规范驱动开发如何付诸实践。

    48210编辑于 2026-04-23
  • 来自专栏运维有术

    OpenSpec 最佳实战:3 条命令跑通规范驱动开发全流程(实战版)

    社区的反馈也很直接 - CSDN 上有篇帖子说得挺到位:AI 开发的核心问题是幻觉,生成的代码经常不符合需求、违反项目规范。根源在于需求没说清楚,AI 就开始自由发挥。 5 分钟上手,3 条命令跑通。 图 3:/opsx:propose 生成的 4 个制品关系图Step 3:用 /opsx:apply 实现任务需求对齐了,方案也审过了,接下来就是让 AI 动手写代码。 CSDN 上有个实战用户说得挺好:这个项目很有价值的应该是功能增强和多人协作开发,尤其是大型项目很多都是基于原有项目扩展和改造。 每次变更归档后,项目规范会逐步积累。AI 读到这些规范,生成的代码质量也会越来越好。这就是规范驱动开发的正循环。建议收藏这篇教程,下次给项目接入 OpenSpec 的时候翻出来跟着做一遍。

    3.9K00编辑于 2026-05-01
  • 来自专栏前端小羊

    什么是规范驱动开发以及spec-kit

    规范驱动开发与Spec-Kit深度解析规范驱动开发再理解规范驱动开发是一种以规范为中心的方法论,核心原则是:规范不仅是文档,更是可执行的开发契约。 Spec-Kit是一个具体实现规范驱动开发的工具集或框架。虽然"Spec-Kit"不是一个通用商标术语,但这个概念指的是专门为规范驱动开发设计的一整套集成工具。 商业化解决方案Postman API Network​ - 规范管理和协作平台 Apiboost​ - 专门的API规范驱动开发平台 Speakeasy​ - 基于规范的SDK生成和管理 3. 低代码集成可视化规范设计器更加普及 规范驱动的无服务器函数生成 与可视化工作流工具深度集成 3. 规范即产品API规范成为独立的产品交付物 基于规范开发者门户自动化 规范的A/B测试和特性开关 总结规范驱动开发是一种确保软件质量、提升开发效率的先进方法论,而Spec-Kit是实现这一方法论的具体工具集合

    3.9K11编辑于 2026-01-12
  • 来自专栏自动化测试实战

    locust入门 -3 脚本开发代码规范

    locust代码规范 上文我们讲了locust的基本语法,现在我们先来认识一下locust代码规范。了解这些以后我们开发脚本的时候就会思路更清晰。 SequentialTaskSet): @task def create_tags(self): print('标记为task(2)的用例') @task(3) get_access_token(self): print("标记为task(1)的用例") @task def my_test(self): print("标记为task(3) api.weixin.qq.com' wait_time = constant(2) tasks = [SequExec] 此时执行事,就会先执行create_tags一次,然后执行get_access_token3

    62720编辑于 2022-04-12
  • SDD 规范驱动 + Harness 驾驭工程 AI 全栈开发

    SDD 规范驱动 + Harness 驾驭工程 AI 全栈开发文档概述本文档深入探讨 规范驱动开发(SDD) 与 Harness 平台 如何协同赋能 AI 全栈开发,构建 规范—>代码—>部署—>验证 SDDSDD + Harness + AI需求到代码手动转换规范驱动生成AI 自动生成 + 规范校验质量保障事后测试规范即测试规范 + AI 测试生成 + Harness 门禁部署效率手动/半自动手动部署 Harness 全自动 + GitOps变更管理变更风险高规范变更可追溯规范版本管理 + Feature Flags团队协作文档同步难规范即文档规范 + AI 注释 + 自动文档1人生产力2-3倍5-8 # 事件驱动规范│ └── graphql-schema.graphql # GraphQL 规范│├── database/│ ├── schema.prisma # 日志规范 └── traces.yaml # 追踪规范2.3 规范驱动代码生成(完整示例)2.3.1 OpenAPI → 全栈代码# specs/

    19310编辑于 2026-07-01
  • 来自专栏开源物联网平台开发

    AI 编程时代的规范驱动开发:OpenSpec 实践指南

    AI 编程时代的规范驱动开发:OpenSpec 实践指南 当 AI 能写代码时,我们真正需要的是什么?不是更快的代码生成,而是更可靠的共识构建。 今天,我想分享一个解决这个问题的开源工具 —— OpenSpec,它不是一个新概念,而是一个让规范驱动开发在 AI 时代真正落地的实践框架。 什么是规范驱动开发规范驱动开发(Spec-Driven Development)的核心思想很简单:在编写代码之前,先定义清楚系统应该做什么。 这不是新概念 —— 从 BDD(行为驱动开发)到 ATDD(验收测试驱动开发),软件行业一直在尝试各种"先想清楚再动手"的方法。 但在 AI 编程时代,这个理念有了新的意义: 传统开发:需求文档 → 开发者理解 → 编写代码 AI 时代:需求描述 → AI 理解 → 生成代码 → ???

    3.9K30编辑于 2026-04-02
  • 聊一聊AI时代的规范驱动开发(SDD)

    今天想和大家聊一聊一个新的驱动开发形式:规范驱动开发(SDD) 我们正处在一个 AI 编程几乎无处不在的时代。写代码、补逻辑、生成模块、重构工程,AI 好像什么都能做。 这也是我今天想讲的核心主题:规范驱动开发。 在我看来,规范驱动开发并不是一个因为 AI 时代才突然出现的新概念。它早就存在了。 所以我认为,规范驱动开发至少可以拆成两个方向来看。 第一个方向,是我们如何对 AI 进行说明,如何让它更好地载入上下文,理解当前工程,并且在一个清晰的约束体系中进行开发和编程。 是不是只有具备高深架构能力的人,才能进行规范驱动开发? 是不是普通开发者就只能"随缘用 AI"? 我觉得也未必。 因为在代码世界里,我们早就遇到过类似的问题,而解决方式大家都非常熟悉——脚手架。 规范驱动开发并不是说,只要你选对了某个框架、某个工具,就一定能得到完美的结果。

    2.7K10编辑于 2025-12-30
  • SDD规范驱动+Harness驾驭工程AI全栈开发

    SDD(Specification-Driven Development,规范驱动开发) 的回归,与 Harness 这一现代软件交付平台相结合,为解决上述问题提供了全新的范式。 自然语言生成Pipeline:开发者可直接用自然语言描述需求(如“为我部署一个带金丝雀策略的nginx服务到prod集群”),AIDA能将其翻译为Harness Pipeline YAML,大大降低学习门槛 3. 构建工程AI全栈流水线:Step-by-Step 实践指南本章是文章的技术核心,将引导读者构建一条从代码提交到生产监控的全栈流水线。前提条件:一个Kubernetes集群。 你可以进一步通过自然语言微调:“在测试阶段增加‘集成测试’步骤,基于OpenAPI规范生成测试数据”。步骤四:构建 AI 驱动的 CD 交付流水线(金丝雀与自动回滚)这是体现AI价值的关键环节。 观察AI驱动的金丝雀分析是否能正确识别由混沌实验引入的“预期干扰”,并避免错误回滚。4. 深度思考:挑战、最佳实践与未来展望挑战:数据质量:AI的智能程度高度依赖于输入规范与监控数据的质量。

    7710编辑于 2026-07-06
  • 来自专栏李洋博客

    Html5+CSS3命名规范(前端web开发命名规范,符合SEO规范

    任何代码编程都有各自特点的常用命名规范,div+css页面设计也不例外。遵守常用的css命名规范有利于代码的升级和扩展,也有利于让别人读懂你的css代码,让你的页面显得清晰有条理。 ? css文件名命名规范 模块:module.css 基本共用:base.css 布局、版面:layout.css 主题:themes.css 专栏:columns.css 文字:font.css 表单:forms.css 补丁:mend.css 打印:print.css 页面结构元素div命名规范 头:header 内容:content/container 尾:footer 导航:nav 侧栏:sidebar 栏目:column /images/icon.gif) no-repeat #333; } /*=====搜索条结束=====*/ 注意事项: 1、一律小写; 2、尽量用英文; 3、尽量不缩写,除非一看就明白的单词; 4、 大家在日常的页面设计中要逐步养成规范命名的好习惯。

    2.2K10发布于 2021-06-15
  • 来自专栏JavaWeb

    规范-项目开发规范

    建议统一异常处理,不仅要在日志中打印异常堆栈信息,还得给前端统一格式的响应信息,而不是前端页面直接提示给用户500

    1.6K20编辑于 2022-01-12
  • 来自专栏Rust

    Claude Code 进阶必学:OpenSpec 规范驱动开发完整指南

    其核心理念只有一句话: 在写任何一行代码之前,先和 AI 就“要做什么”达成明确一致,并把这个一致记录成结构化的 Living Spec(活的规范),作为整个开发过程的单一事实来源(Single Source 主要功能包括: - 添加今日工作记录(支持多条) - 查看今日/指定日期的工作记录 - 一键生成结构化日报(支持 Markdown 格式) - 数据支持本地 JSON 文件持久化 - 支持简单分类(开发 3. 3 个月后,新增功能速度提升近 2 倍,Bug 率显著下降,新人通过 archives 目录快速上手。 掌握 OpenSpec 后,你会明显感受到开发效率、代码质量和项目可维护性的质变。

    2.3K22编辑于 2026-05-13
  • 来自专栏AI

    【转】如何使用 Spec Kit 工具进行规范驱动开发

    而进入 AI 时代,「规范驱动开发」想彻底改变这一现状,即让规范贯穿整个软件开发生命周期、让规范变得可执行、让规范成为代码。 规范驱动开发的工作流一般有三个阶段:需求 -> 设计 -> 任务如果每一阶段的规范都依赖人工完成,会给人带来不小的负担。所以,业界推出了相应的工具来自动化规范的编写和流程的管理,从而为开发者减轻负担。 本文即介绍一个「规范驱动开发」工具的使用,它叫 Spec Kit,由 GitHub 推出,与市面上流行的 AI 助手(如 Cursor、VS Code、Claude、Windsurf 等)均能很好的集成 浏览器访问相应地址,可以看到,一个博客聚合网站被使用「规范驱动开发」的方式实现了。 总体感觉,使用 Spec Kit 开发一个新项目(0 到 1)比 Vibe Coding 要靠谱一些,但 Spec Kit 这种「规范驱动开发」的模式能否胜任真实的项目演进(1 到 N),还有待进一步的探索

    3.4K10编辑于 2026-03-28
  • 来自专栏花狗在Qt

    Java开发编程规范: 3.代码格式

    3) 右大括号前换行。      4) 右大括号后还有 else 等代码则不换行;表示终止的右大括号后必须换行。 3) 方法调用的点符号与下文一起换行。       4) 方法调用中的多个参数需要换行时,在逗号后进行。      5) 在括号前不要换行,见反例。 .append("xin")...append ("huang"); // 参数很多的方法调用可能超过 120 个字符,不要在逗号前换行 method(args1, args2, args3, method(args1, args2, args3); 【强制】IDE 的 text file encoding 设置为 UTF-8; IDE 中文件的换行符使用 Unix 格式,不要使用 Windows 正例: int one = 1; long two = 2L; float three = 3F; StringBuffer sb = new StringBuffer(); 说明:增加 sb

    2.9K31发布于 2020-10-28
  • OpenSpec 完全使用指南:AI 时代的规范驱动开发

    Spec-Driven Development —— 先写规范,再写代码一、什么是 OpenSpec?OpenSpec 是一个专为 AI 编程场景设计的规范驱动开发框架。 二、四个核心 SkillOpenSpec 提供四个 Skill,覆盖完整的开发周期:Skill别名用途openspec-propose/opsx:propose提出新变更,生成 proposal / design tasks.md 逐项推进:Working on task 1/6: 实现天气查询函数 ✓Working on task 2/6: 添加 CLI 参数解析 ✓Working on task 3/ "→ (AI 引导你梳理关键决策点)→ 思路清晰后退出/opsx:propose "本地 Markdown 笔记应用"3. 多变更并行管理openspec list→ weather-cli (in-progress) 6/6→ add-todo-api (in-progress) 3/8→ md-notes (draft)

    3.5K21编辑于 2026-05-27
  • 来自专栏朱永胜的私房菜

    开发规范系列】(四)前端开发规范

    反例:DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3 杜绝完全不规范的缩写,避免望文不知义: 反例:AbstractClass“缩写 (一) Vue 编码基础 vue 项目规范以 Vue 官方规范(https://cn.vuejs.org/v2/style-guide/)[3] 中的 A 规范为基础,在其上面进行项目开发,故所有代码均遵守该规范 2.2.2 使用 Vue CLI 脚手架 使用 Vue CLI 3 来初始化项目,项目名按照上述命名规范命名。 Vue 的数据驱动更新 DOM,避免(除非万不得已)手动操作 DOM,包括增删改 DOM 元素、更改样式、添加事件等。 首发博客地址: https://blog.zysicyj.top/ [2] 系列文章地址: https://blog.zysicyj.top/categories/技术文章/后端技术/系列文章/开发规范

    1.6K21编辑于 2023-09-01
  • 来自专栏CodingToDie

    开发规范 | 代码审核规范

    规范主要参考《谷歌的代码评审指南》 ? 一、开发者 不应该在 CI 内同时包含主要风格的改动与其他代码的修改,这样会导致难以看出 CI 到底做出什么改动 格式化 commit message 优势: 提供更多的历史信息,方便快速浏览; 可以过滤某些 commit 的详细描述,可以分成多行 footer 部分只用于两种情况:1、不兼容变动;2、关闭issue 扩展:如果你使用 IDEA 进行编码,可以是使用 git commit template 插件来规范每次提交的 未来其他开发者接手时,代码是否易于理解与易用? 测试:代码是否经过正确且设计良好的自动化测试 命名:开发人员是否为变量、类、方法等选择了明确的名称? 注释:注释是否清晰有效? 风格:代码是否遵循了代码开发规范 文档:开发人员是否也同步更新了相关文档 在评论前加上“nit:”这样的前缀,表明这是一个优化性的建议,可以不影响本次上线 应在一个工作日内完成评审,并给出意见 评价只针对代码和具体业务流程

    2.4K20发布于 2021-04-13
  • 来自专栏前端flutter

    web开发规范 - 图片规范

    , 比如ad_left01.gif || btn_submit.gif; 在保证视觉效果的情况下选择最小的图片格式与图片质量, 以减少加载时间; 尽量避免使用半透明的png图片(若使用, 请参考css规范相关说明 760X100,750X120,468X60,468X95,728X90,585X140 次级页的pip尺寸360X300,336X280 游标:100X100或120X120 LOGO的国际标准规范

    1K10编辑于 2022-12-19
领券