拓冰网站定制 
后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载导读本文以 Fleet 官方架构决策记录 ADR-0010: OpenSpec Adoption 为核心完整还原了 Fleet 团队评估并拒绝将 OpenSpec 可选工具目录、.claude/CLAUDE.md 与 PR 模板 等源码证据深入剖析 Fleet 现有 AI 辅助开发工作流为何能替代一套独立的规范文件体系。读完本文你将理解spec-driven 框架在大型开源仓库中的落地成本评审负担、规范漂移、小改动开销、Fleet 以GitHub Issue 为单一事实来源 AI 生成 PR 描述 项目级 Agent 约定三条支柱构成的结构化思考机制以及 OpenSpec 这类工具在当前阶段的适用边界。一、背景ADR 是什么为何 Fleet 要评估 OpenSpec1.1 Fleet 的架构决策记录机制Fleet 仓库在 docs/Contributing/adr/ 目录维护着一套完整的 Architecture Decision RecordsADR体系已有 0010、0011、0012 等多份决策记录。每份 ADR 遵循 template.md 定义的标准结构Title描述性标题StatusProposed / Accepted / Rejected / Deprecated / SupersededContext促成该决策的上下文与问题陈述Decision最终决策及其理由Consequences决策带来的正面与负面影响References相关 issue、文档链接ADR-0010 的Status 为Rejected2026-05-21属于评估后否决型决策记录——这类记录的价值恰恰在于即使不采纳也把评估过程、否决理由和未来复审条件沉淀为团队知识防止未来重复论证。1.2 评估对象OpenSpec 是什么原 ADR 开篇定义了评估对象 OpenSpec由 Fission AI 出品它是一个spec-driven development规范驱动开发框架团队将 Markdown 规范文件提交到仓库的openspec/目录每个功能或变更对应一个文件夹内含 proposal提案、design doc设计文档、task list任务清单以及delta specs采用 Given/When/Then 场景格式的增量规范变更发布后deltas 会被归档并合并进一个描述系统当前状态的spec library规范库。其核心目标有两个其一在生成代码之前让 AI 编码代理与人类开发者对齐要构建什么其二在代码之外维护一份随系统演进的、可执行的系统行为活规范。Fleet 团队因此发起评估是否应在仓库中引入openspec/目录并开始提交 spec 文件二、决策不采用 OpenSpec以现有工作流替代2.1 最终决定Fleet 决定不采用 OpenSpec。理由非常直接现有工作流已经提供了 OpenSpec 所追求的结构化思考收益不需要再引入一套并行的规范层。2.2 现有工作流的三条支柱原 ADR 明确指出Fleet 现有的三项机制已经覆盖了 OpenSpec 想解决的问题现有机制承担的角色仓库证据带详细验收标准的用户故事定义构建什么以及如何验证Issue 与 PR 中的验收标准清单AI 生成的 PR 描述记录问题、方案、受影响层、备选方案.github/pull_request_template.md 规定的结构化模板CLAUDE.md项目约定指导 AI 代理遵循 Fleet 特有的模式、错误处理、鉴权与请求生命周期.claude/CLAUDE.md仓库中的 PR 模板 印证了第二支柱模板要求 PR 描述必须包含 Related issue、Testing、Frontend、Database migrations、GitOps 设置、fleetd/orbit 兼容性等多个固定小节并明确要求 AI 代理填写## AI段注明工具与模型 ID。这意味着结构化思考被内建在 PR 流程本身而非依赖额外的规范文件。而 .claude/CLAUDE.md 则印证了第三支柱它明确规定了后端请求流HTTP request → server/service/handler.go 路由 → endpoint 解码 → service 业务逻辑 → datastore SQL → 响应以及 Fleet 特定的代码注释风格、错误处理、术语Teams→Fleets、Queries→Reports等约定。AI 代理在写代码前就被引导到正确的模式上。2.3 关键论断Issue 是单一事实来源ADR 的核心判断是GitHub Issue 仍然是每次变更的 source of truth。规范、验收标准、设计上下文都存在于 Issue 中并直接关联到实现它的 PR。而采用 OpenSpec 会创建一个并行的规范层它大体上只是重复 Issue 中已有的内容以提交到仓库的文件形式存在需要持续维护容易同时偏离 Issue 与实际实现spec drift。换言之规范文件增加的是第三份需要同步的副本而不是更清晰的第一份定义。三、后果分析否决决策带来的正面与负面影响原 ADR 将决策后果分为三类逐一保留并展开3.1 正面后果PositivePR 评审表面积不变不引入额外的规范文件PR 的 diff 不会被成百上千行 spec Markdown 污染零维护负担无需专门维护 spec 文件与代码库的同步无工具依赖风险不依赖一个年轻、单维护者的工具评估时 OpenSpec 仍处于早期阶段。3.2 负面后果Negative放弃标准化的机器可读规范格式未来 AI 代理可能从中受益的标准化上下文缺失没有集中的spec library描述系统当前行为的职责仍由用户故事和文档承担结构化程度较低代理获取历史决策上下文的成本升高AI 代理要了解之前的决策需要调用gh api查询 Issue而不是直接读取本地可读的设计/业务逻辑决策日志——这一点原 ADR 特别强调会削弱防止产品在无意图情况下被改动的能力。3.3 未来复审条件Future considerationsADR 明确列出了三个何时重新考虑的触发条件这也是决策记录中最具操作价值的部分当前工作流在规模化后失效——当 PR 描述 Issue 的模式无法承载变更复杂度时OpenSpec 增加从规范到实现的自动化验证——即把 spec 变成可强制执行的检查enforceable checks而不仅仅是文档工具显著成熟——API 稳定、维护者基础扩大。四、备选方案评估为什么其他路径也不被采纳原 ADR 评估了三个备选方案每个都有明确的否决理由这是全文最有工程参考价值的部分。4.1 方案一全面采用 OpenSpec向仓库提交完整的openspec/目录spec library 每次变更的产物。被否决的原因有三代码评审负担Code review burden每个 PR 都要附带数百行额外的 spec Markdown。评审者要么逐一核对 spec 与实现是否一致评审工作量翻倍要么跳过核对spec 沦为未经验证的装饰。而评审吞吐量本就是团队的瓶颈规范漂移Spec drift保持 spec 准确需要每次变更后运行openspec archive并在实现中途转向时同步更新 spec——两步都是强依赖全体贡献者纪律的手动步骤。一旦漂移发生对账工作就会与发布新功能竞争资源小改动的开销不成比例Overhead for small changes社区经验表明OpenSpec 即使对简单的 bug 修复也会生成大量产物。Fleet 的变更集是琐碎改动与复杂改动混合的对前者而言开销过高。4.2 方案二仅对大型功能采用 OpenSpec选择性使用多组件大功能用、小改动不用。被否决的原因采用不一致造成困惑何时需要 spec 的规则不清晰大功能恰恰是规范漂移最快的场景多组件功能在实现过程中spec 最容易被实现偏离规范库只覆盖系统子集作为 source of truth 的价值大打折扣。4.3 方案三在 PR 描述中强制Approach结构化小节为复杂变更的 PR 描述增加轻量模板Problem / Change / Why this layer / What I considered。未被作为正式流程采纳因为 AI 生成的 PR 描述在无强制格式的情况下已经覆盖得足够好——这正是以工具能力替代流程强制的典型例证。五、仓库证据OpenSpec 在 Fleet 中的降级形态5.1 一个矛盾但自洽的现实尽管 ADR 拒绝将 OpenSpec 作为正式政策仓库根目录下却真实存在 openspec/ 目录——这正是决策的另一面工程师个人可以将 OpenSpec 作为本地思考与规划工具原 ADR 明确允许只是不强制、不纳入正式流程。该目录中的 README 定位写得很清楚OpenSpec 在本仓库中是opt-in 工具不是开发流程的必需部分。团队未将其采纳为政策没有任何 PR 被要求使用它。5.2 OpenSpec 目录的实际内容与工作流openspec/README.md工具定位、安装方式、四步流程与目录约定openspec/config.yaml项目上下文与规则配置指向.claude/CLAUDE.md作为权威项目指南。其四步流程explore → propose → apply → archive如下/opsx:explore— 思考想法不写代码、默认不生成产物/opsx:propose— 在openspec/changes/change-name/下生成proposal.md是什么 为什么、design.md怎么做、tasks.md/opsx:apply— 实现任务传变更名如/opsx:apply add-foo或由上下文推断/opsx:archive— 合并后把变更移入openspec/changes/archive/并更新openspec/specs/下的规范。openspec/README.md 还给出了明确的使用边界与原 ADR 的否决理由一一对应值得用跨 datastore / service / endpoint / UI 的横切功能触及多文件且需要先对齐形状的重构想与人或 AI 协作评审的 RFC 式设计跳过bug 修复、小功能、依赖升级、文档调整——如果一次变更能装进一个 PR 描述里那就写 PR 描述产物即文档非契约代码评审仍然是 source of truth。5.3 不可手工编辑的 vendored 文件openspec/README.md 特别警告openspec update会覆盖本地改动因此以下目录由 OpenSpec CLI 托管、禁止手工编辑.claude/skills/openspec-*/.claude/commands/opsx/需要定制时应改 openspec/config.yaml若确需分叉某个 skill应复制为新名字以避免被 updater 覆盖。六、延伸对照Fleet 对通信/规范新机制的取舍模式将 ADR-0010 放在 Fleet 的决策序列中可以清晰看到一种一致的工程取舍哲学。例如已获批准的 ADR-0011: Agent WebSocket transport 在引入新传输机制时同样做了大量备选方案评估long polling、SSE、gRPC streaming、ETag conditional requests最终只选择与现有轮询协议互补的方案并明确要求轮询保留为兜底基线。映射到 ADR-0010Fleet 对待 OpenSpec 的态度与对待 WebSocket 的态度如出一辙——新的规范/通信机制只能作为增量优化opt-in、可回退绝不取代现有可靠基线Issue PR 轮询协议。这也是理解这份拒绝型 ADR 的最重要视角否决不是排斥新工具而是拒绝让新工具成为必须维护的第二套事实来源。七、实践建议什么情况下值得重新评估综合原 ADR 的 Future considerations 与仓库现状可以给出以下可操作的判断清单均基于本仓库可见的事实不构成对未来的预测先量化维护成本如果团队发现 PR 描述 Issue 无法承载复杂变更评审反复澄清、实现偏离验收标准说明结构化程度不足——这正是 ADR 列出的触发条件一关注工具的可执行化进展若 OpenSpec 演进到能自动验证 spec 与实现一致而非纯文档其价值主张会从额外负担转为自动检查触发条件二成立观察工具成熟度stable API、多维护者基础触发条件三在采用前做小规模试点用 openspec/ 目录里已配置好的 opt-in 工作流/opsx:propose等对单个大型重构做试点实测多出的维护工时是否小于评审节省的工时再决定是否提交正式 ADR 修改该决策。八、结论ADR-0010 是一份教科书式的拒绝型架构决策记录它清晰地定义了评估对象、给出了可验证的否决理由评审负担、规范漂移、小改动开销、工具不成熟、量化了正负后果并保留了未来复审的触发条件。同时仓库中 openspec/ 目录的 opt-in 形态完美地演示了组织不采纳某流程但允许个体将其作为思考工具的工程管理艺术。对正在评估 spec-driven 开发框架OpenSpec 或其他类似工具的团队这份 ADR 的价值在于在引入任何第二套规范层之前先确认现有的 Issue PR Agent 约定体系是否已经提供了足够的结构化思考若已具备新增规范文件的边际收益将远小于其维护成本。而Issue 是唯一事实来源这一原则正是 Fleet 保持 AI 辅助开发流程与人工评审流程不脱节的基石。延伸阅读仓库内ADR-0010 原文ADR 目录与索引ADR 模板OpenSpec 可选工具说明OpenSpec 项目配置AI 代理项目指南PR 描述模板ADR-0011: Agent WebSocket transport对照参考赞分享后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载相关推荐3台旧Mac拼出700B本地推理集群exo家用分布式推理集群搭建指南3台旧Mac拼出700B本地推理集群exo家用分布式推理集群搭建指南 手里的几台 Mac 和笔记本想跑比单机内存还大的模型exo 把它们组成本地分布式推理集后端前端企业应用运维网络安全Fleet 仓库中的 OpenSpec spec-driven 变更工作流从 explore 到 archive 的完整指南Fleet 仓库中的 OpenSpec spec driven 变更工作流从 explore 到 archive 的完整指南 OpenSpec 是一套先写规后端前端企业应用运维网络安全【亲测免费】 推荐项目Fleet - 一个开源的设备管理平台推荐项目Fleet 一个开源的设备管理平台 Fleet 是一个开源的设备管理平台它提供了一个简单的方法来管理和监控大量的设备。这个平台使用 Go 语言编写上一篇React Native Circular Slider实战创建自定义圆形进度条和音量控制下一篇AL-0-SFT未来路线图模型优化与功能扩展计划创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深度剖析 Fleet 的 OpenSpec 决策：为何一个开源设备管理项目拒绝引入 Spec-Driven 开发框架
后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载导读本文以 Fleet 官方架构决策记录 ADR-0010: OpenSpec Adoption 为核心完整还原了 Fleet 团队评估并拒绝将 OpenSpec 可选工具目录、.claude/CLAUDE.md 与 PR 模板 等源码证据深入剖析 Fleet 现有 AI 辅助开发工作流为何能替代一套独立的规范文件体系。读完本文你将理解spec-driven 框架在大型开源仓库中的落地成本评审负担、规范漂移、小改动开销、Fleet 以GitHub Issue 为单一事实来源 AI 生成 PR 描述 项目级 Agent 约定三条支柱构成的结构化思考机制以及 OpenSpec 这类工具在当前阶段的适用边界。一、背景ADR 是什么为何 Fleet 要评估 OpenSpec1.1 Fleet 的架构决策记录机制Fleet 仓库在 docs/Contributing/adr/ 目录维护着一套完整的 Architecture Decision RecordsADR体系已有 0010、0011、0012 等多份决策记录。每份 ADR 遵循 template.md 定义的标准结构Title描述性标题StatusProposed / Accepted / Rejected / Deprecated / SupersededContext促成该决策的上下文与问题陈述Decision最终决策及其理由Consequences决策带来的正面与负面影响References相关 issue、文档链接ADR-0010 的Status 为Rejected2026-05-21属于评估后否决型决策记录——这类记录的价值恰恰在于即使不采纳也把评估过程、否决理由和未来复审条件沉淀为团队知识防止未来重复论证。1.2 评估对象OpenSpec 是什么原 ADR 开篇定义了评估对象 OpenSpec由 Fission AI 出品它是一个spec-driven development规范驱动开发框架团队将 Markdown 规范文件提交到仓库的openspec/目录每个功能或变更对应一个文件夹内含 proposal提案、design doc设计文档、task list任务清单以及delta specs采用 Given/When/Then 场景格式的增量规范变更发布后deltas 会被归档并合并进一个描述系统当前状态的spec library规范库。其核心目标有两个其一在生成代码之前让 AI 编码代理与人类开发者对齐要构建什么其二在代码之外维护一份随系统演进的、可执行的系统行为活规范。Fleet 团队因此发起评估是否应在仓库中引入openspec/目录并开始提交 spec 文件二、决策不采用 OpenSpec以现有工作流替代2.1 最终决定Fleet 决定不采用 OpenSpec。理由非常直接现有工作流已经提供了 OpenSpec 所追求的结构化思考收益不需要再引入一套并行的规范层。2.2 现有工作流的三条支柱原 ADR 明确指出Fleet 现有的三项机制已经覆盖了 OpenSpec 想解决的问题现有机制承担的角色仓库证据带详细验收标准的用户故事定义构建什么以及如何验证Issue 与 PR 中的验收标准清单AI 生成的 PR 描述记录问题、方案、受影响层、备选方案.github/pull_request_template.md 规定的结构化模板CLAUDE.md项目约定指导 AI 代理遵循 Fleet 特有的模式、错误处理、鉴权与请求生命周期.claude/CLAUDE.md仓库中的 PR 模板 印证了第二支柱模板要求 PR 描述必须包含 Related issue、Testing、Frontend、Database migrations、GitOps 设置、fleetd/orbit 兼容性等多个固定小节并明确要求 AI 代理填写## AI段注明工具与模型 ID。这意味着结构化思考被内建在 PR 流程本身而非依赖额外的规范文件。而 .claude/CLAUDE.md 则印证了第三支柱它明确规定了后端请求流HTTP request → server/service/handler.go 路由 → endpoint 解码 → service 业务逻辑 → datastore SQL → 响应以及 Fleet 特定的代码注释风格、错误处理、术语Teams→Fleets、Queries→Reports等约定。AI 代理在写代码前就被引导到正确的模式上。2.3 关键论断Issue 是单一事实来源ADR 的核心判断是GitHub Issue 仍然是每次变更的 source of truth。规范、验收标准、设计上下文都存在于 Issue 中并直接关联到实现它的 PR。而采用 OpenSpec 会创建一个并行的规范层它大体上只是重复 Issue 中已有的内容以提交到仓库的文件形式存在需要持续维护容易同时偏离 Issue 与实际实现spec drift。换言之规范文件增加的是第三份需要同步的副本而不是更清晰的第一份定义。三、后果分析否决决策带来的正面与负面影响原 ADR 将决策后果分为三类逐一保留并展开3.1 正面后果PositivePR 评审表面积不变不引入额外的规范文件PR 的 diff 不会被成百上千行 spec Markdown 污染零维护负担无需专门维护 spec 文件与代码库的同步无工具依赖风险不依赖一个年轻、单维护者的工具评估时 OpenSpec 仍处于早期阶段。3.2 负面后果Negative放弃标准化的机器可读规范格式未来 AI 代理可能从中受益的标准化上下文缺失没有集中的spec library描述系统当前行为的职责仍由用户故事和文档承担结构化程度较低代理获取历史决策上下文的成本升高AI 代理要了解之前的决策需要调用gh api查询 Issue而不是直接读取本地可读的设计/业务逻辑决策日志——这一点原 ADR 特别强调会削弱防止产品在无意图情况下被改动的能力。3.3 未来复审条件Future considerationsADR 明确列出了三个何时重新考虑的触发条件这也是决策记录中最具操作价值的部分当前工作流在规模化后失效——当 PR 描述 Issue 的模式无法承载变更复杂度时OpenSpec 增加从规范到实现的自动化验证——即把 spec 变成可强制执行的检查enforceable checks而不仅仅是文档工具显著成熟——API 稳定、维护者基础扩大。四、备选方案评估为什么其他路径也不被采纳原 ADR 评估了三个备选方案每个都有明确的否决理由这是全文最有工程参考价值的部分。4.1 方案一全面采用 OpenSpec向仓库提交完整的openspec/目录spec library 每次变更的产物。被否决的原因有三代码评审负担Code review burden每个 PR 都要附带数百行额外的 spec Markdown。评审者要么逐一核对 spec 与实现是否一致评审工作量翻倍要么跳过核对spec 沦为未经验证的装饰。而评审吞吐量本就是团队的瓶颈规范漂移Spec drift保持 spec 准确需要每次变更后运行openspec archive并在实现中途转向时同步更新 spec——两步都是强依赖全体贡献者纪律的手动步骤。一旦漂移发生对账工作就会与发布新功能竞争资源小改动的开销不成比例Overhead for small changes社区经验表明OpenSpec 即使对简单的 bug 修复也会生成大量产物。Fleet 的变更集是琐碎改动与复杂改动混合的对前者而言开销过高。4.2 方案二仅对大型功能采用 OpenSpec选择性使用多组件大功能用、小改动不用。被否决的原因采用不一致造成困惑何时需要 spec 的规则不清晰大功能恰恰是规范漂移最快的场景多组件功能在实现过程中spec 最容易被实现偏离规范库只覆盖系统子集作为 source of truth 的价值大打折扣。4.3 方案三在 PR 描述中强制Approach结构化小节为复杂变更的 PR 描述增加轻量模板Problem / Change / Why this layer / What I considered。未被作为正式流程采纳因为 AI 生成的 PR 描述在无强制格式的情况下已经覆盖得足够好——这正是以工具能力替代流程强制的典型例证。五、仓库证据OpenSpec 在 Fleet 中的降级形态5.1 一个矛盾但自洽的现实尽管 ADR 拒绝将 OpenSpec 作为正式政策仓库根目录下却真实存在 openspec/ 目录——这正是决策的另一面工程师个人可以将 OpenSpec 作为本地思考与规划工具原 ADR 明确允许只是不强制、不纳入正式流程。该目录中的 README 定位写得很清楚OpenSpec 在本仓库中是opt-in 工具不是开发流程的必需部分。团队未将其采纳为政策没有任何 PR 被要求使用它。5.2 OpenSpec 目录的实际内容与工作流openspec/README.md工具定位、安装方式、四步流程与目录约定openspec/config.yaml项目上下文与规则配置指向.claude/CLAUDE.md作为权威项目指南。其四步流程explore → propose → apply → archive如下/opsx:explore— 思考想法不写代码、默认不生成产物/opsx:propose— 在openspec/changes/change-name/下生成proposal.md是什么 为什么、design.md怎么做、tasks.md/opsx:apply— 实现任务传变更名如/opsx:apply add-foo或由上下文推断/opsx:archive— 合并后把变更移入openspec/changes/archive/并更新openspec/specs/下的规范。openspec/README.md 还给出了明确的使用边界与原 ADR 的否决理由一一对应值得用跨 datastore / service / endpoint / UI 的横切功能触及多文件且需要先对齐形状的重构想与人或 AI 协作评审的 RFC 式设计跳过bug 修复、小功能、依赖升级、文档调整——如果一次变更能装进一个 PR 描述里那就写 PR 描述产物即文档非契约代码评审仍然是 source of truth。5.3 不可手工编辑的 vendored 文件openspec/README.md 特别警告openspec update会覆盖本地改动因此以下目录由 OpenSpec CLI 托管、禁止手工编辑.claude/skills/openspec-*/.claude/commands/opsx/需要定制时应改 openspec/config.yaml若确需分叉某个 skill应复制为新名字以避免被 updater 覆盖。六、延伸对照Fleet 对通信/规范新机制的取舍模式将 ADR-0010 放在 Fleet 的决策序列中可以清晰看到一种一致的工程取舍哲学。例如已获批准的 ADR-0011: Agent WebSocket transport 在引入新传输机制时同样做了大量备选方案评估long polling、SSE、gRPC streaming、ETag conditional requests最终只选择与现有轮询协议互补的方案并明确要求轮询保留为兜底基线。映射到 ADR-0010Fleet 对待 OpenSpec 的态度与对待 WebSocket 的态度如出一辙——新的规范/通信机制只能作为增量优化opt-in、可回退绝不取代现有可靠基线Issue PR 轮询协议。这也是理解这份拒绝型 ADR 的最重要视角否决不是排斥新工具而是拒绝让新工具成为必须维护的第二套事实来源。七、实践建议什么情况下值得重新评估综合原 ADR 的 Future considerations 与仓库现状可以给出以下可操作的判断清单均基于本仓库可见的事实不构成对未来的预测先量化维护成本如果团队发现 PR 描述 Issue 无法承载复杂变更评审反复澄清、实现偏离验收标准说明结构化程度不足——这正是 ADR 列出的触发条件一关注工具的可执行化进展若 OpenSpec 演进到能自动验证 spec 与实现一致而非纯文档其价值主张会从额外负担转为自动检查触发条件二成立观察工具成熟度stable API、多维护者基础触发条件三在采用前做小规模试点用 openspec/ 目录里已配置好的 opt-in 工作流/opsx:propose等对单个大型重构做试点实测多出的维护工时是否小于评审节省的工时再决定是否提交正式 ADR 修改该决策。八、结论ADR-0010 是一份教科书式的拒绝型架构决策记录它清晰地定义了评估对象、给出了可验证的否决理由评审负担、规范漂移、小改动开销、工具不成熟、量化了正负后果并保留了未来复审的触发条件。同时仓库中 openspec/ 目录的 opt-in 形态完美地演示了组织不采纳某流程但允许个体将其作为思考工具的工程管理艺术。对正在评估 spec-driven 开发框架OpenSpec 或其他类似工具的团队这份 ADR 的价值在于在引入任何第二套规范层之前先确认现有的 Issue PR Agent 约定体系是否已经提供了足够的结构化思考若已具备新增规范文件的边际收益将远小于其维护成本。而Issue 是唯一事实来源这一原则正是 Fleet 保持 AI 辅助开发流程与人工评审流程不脱节的基石。延伸阅读仓库内ADR-0010 原文ADR 目录与索引ADR 模板OpenSpec 可选工具说明OpenSpec 项目配置AI 代理项目指南PR 描述模板ADR-0011: Agent WebSocket transport对照参考赞分享后端前端企业应用运维网络安全【免费下载链接】fleetOpen device management项目地址https://gitcode.com/GitHub_Trending/fl/fleet点击查看免费下载相关推荐3台旧Mac拼出700B本地推理集群exo家用分布式推理集群搭建指南3台旧Mac拼出700B本地推理集群exo家用分布式推理集群搭建指南 手里的几台 Mac 和笔记本想跑比单机内存还大的模型exo 把它们组成本地分布式推理集后端前端企业应用运维网络安全Fleet 仓库中的 OpenSpec spec-driven 变更工作流从 explore 到 archive 的完整指南Fleet 仓库中的 OpenSpec spec driven 变更工作流从 explore 到 archive 的完整指南 OpenSpec 是一套先写规后端前端企业应用运维网络安全【亲测免费】 推荐项目Fleet - 一个开源的设备管理平台推荐项目Fleet 一个开源的设备管理平台 Fleet 是一个开源的设备管理平台它提供了一个简单的方法来管理和监控大量的设备。这个平台使用 Go 语言编写上一篇React Native Circular Slider实战创建自定义圆形进度条和音量控制下一篇AL-0-SFT未来路线图模型优化与功能扩展计划创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考