人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载导读DevFlow 是 agent-core-java 仓库内内置的一套规范驱动开发SDD TDD Clean Code技能体系其中第一层 SDD 的目标是解决需求含糊 → 模型靠猜补全 → 做出来的不是用户要的东西这一核心失败模式。本文围绕 DevFlow 规格阶段的 spec.md 模板devflow-specify的默认产物模板展开完整讲解模板的每个章节、每个字段的填写规则并深入 EARS 句式、Given/When/Then 验收、Change Type 变更分类、NFR 的 QAS 五要素等底层判定标准。读完本文你将掌握如何把一句话需求澄清并结构化为一组每条都可测试的需求条目如何初始化 traceability.md 追溯矩阵与 plan.md 执行计划骨架以及如何通过 R1 规格评审门禁。模板定位spec.md 是模型与人之间的第一份契约本模板的正式名称与用途见模板文件首行与devflow-specify技能说明它是devflow-specify生成组件根下features/id-slug/spec.md的默认模板。注意两条使用前提团队约定优先若组件仓库根AGENTS.md声明了等价路径或模板优先遵循团队约定微小修改可裁剪微小修改几行、无接口变化、风险低可以按using-devflow的裁剪规则压缩本模板但需求条目的可测试性要求不变——压缩的是文档量不是质量门槛。模板文件本身位于 .claude/skills/devflow-specify/references/requirement-template.md配套技能与规则文件包括文件用途.claude/skills/devflow-specify/SKILL.md规格阶段工作流收集上下文、澄清Capture→Challenge→Clarify、写条目、NFR 转 QAS、粒度检查、初始化追溯与计划、自检与 R1 评审.claude/skills/devflow-specify/references/nfr-quality-attribute-scenarios.mdNFR 的 QAS 五要素格式与实时性/内存/并发/资源/错误/安全六个完整示例.claude/skills/devflow-specify/references/granularity-and-split.md过大需求条目的检测信号G1-G8与拆分规则.claude/skills/devflow-specify/references/traceability-template.mdtraceability.md 追溯矩阵模板spec-design-code 一致性约束.claude/skills/devflow-review/references/spec-review-rubric.mdR1 规格评审检查项与 verdict 指引判断一份规格好不好的唯一标准每条需求都可测试——能直接落成一个失败的测试用例RED并且两个不同的人读完会写出相同的测试。写规格时对抗的失败模式是需求含糊 → 模型靠猜补全因此规格阶段的纪律是澄清而不臆造可以追问、可以提出方案让人选择但不能替人决定业务规则、优先级和验收阈值。spec.md 模板整体结构模板由八个章节构成各章节职责如下章节必填性解决的问题身份信息必填工作项的类型、ID、组件归属与上游追溯背景与目标必填问题来源是什么做完后什么变得不同范围 / 非范围必填本轮做什么、明确不做什么需求条目FR/NFR/CON/ASM/EXC必填每条核心需求的可测试契约接口候选契约IFC涉及对外接口时必填语义级接口契约供设计阶段落地Open Questions必填待决问题显式分类防止猜测走私进规格假设与依赖必填假设失效对规格的影响身份信息工作项的类型、ID 与上游追溯模板第一节是一张五字段的身份信息表其中类型与上游追溯是两个最容易出错的字段字段内容类型AR / DTS / CHANGEID工作项编号所属组件组件根下的组件名上游追溯IR / SR / 缺陷单 / 输入文档锚点状态draft / 已确认三种类型对应三种工作项路径见 .claude/skills/using-devflow/SKILL.mdAR新功能工作项走完整的 specify → design → tdd → review → ship 生命周期CHANGE变更工作项通常触及既有行为、接口或阈值modify/remove类条目占比高DTS缺陷工作项通常先经devflow-fix产出复现与根因fix.md再回到规格阶段。上游追溯不接受口头要求Source 必须是指向上游单据或文档锚点如SR-1234 §3.2的可核对位置。这是规格评审 rubric 的硬性检查项见 spec-review-rubric.md。背景与目标、范围与非范围背景与目标两个子项写法上注意区分问题与目标## 背景与目标 - 背景与问题来源: 为什么现在要做问题在哪里 - 目标做完后什么变得不同: 可验证的变化而不是更好/更强这类不可判定描述范围 / 非范围## 范围 / 非范围 - 范围: 本轮明确要做的事 - 非范围: 本轮明确不做的事非范围的写法纪律以后再做的能力必须显式落在非范围、EXC 条目或新工作项里不能埋在正文里。规格评审 rubric 的边界纪律检查项会核对范围/非范围是否闭合——把没打算做的事藏起来等于让实现阶段产生意料之外的猜测空间。需求条目每条核心需求都是一个结构化条目模板的核心是需求条目区。每条核心需求是一个结构化条目不是一段散文。条目按前缀分类前缀含义FR-功能需求可观察的系统行为NFR-质量需求实时性、内存、并发、安全等必须有阈值CON-硬性约束目标平台、编译条件、ABI 兼容等IFR-接口需求对外服务契约、协议、错误码ASM-假设失效会改变规格的事实EXC-显式排除项本轮不做的事FR 条目字段每一条 FR 必须包含以下字段### FR-001 标题 - Statement: EARS 句式 - Acceptance: - Given …When …Then … - Given …When 异常条件Then 保护/反馈行为 - Priority: Must / Should / Could - Source: 上游锚点 - Change Type: new / modify / remove - Existing Behavior: modify/remove 必填旧行为基线new 写 N/AStatement 用 EARS 句式Statement 必须使用 EARS 句式目的是让条目可以被冷读判断不依赖作者补充解释就能判断对错。五种模式模式句式常驻行为主体 必须 持续成立的能力或约束事件触发当 触发条件 时主体 必须 可观察结果状态约束在 状态/前置条件 下主体 必须 行为结果异常路径如果 异常条件主体 必须 保护/反馈/恢复行为可选配置在启用 配置 时主体 必须 行为结果两条硬约束主体写本组件/该模块不写无主体的系统应该Statement 里不出现实现细节函数签名、数据结构、库名、并发原语——那些属于设计阶段不属于规格。模板对接口候选契约特别强调不写语言级函数签名、私有数据结构、重试次数、线程模型。Acceptance 用 Given/When/Then验收标准的规则见 devflow-specify/SKILL.md每条 FR 至少一个正向验收 关键失败路径各一条必须能形成明确的通过/不通过判断禁止体验良好足够快这类不可判定词一条验收只验证一个行为验收要能直接落成 RED 测试用例——这是规格与 TDD 的接口。以技能文档中的正例说明完整条目长什么样### FR-001 模式切换 - Statement: 当组件 X 收到 SetMode 请求且 mode ∈ {NORMAL, SAFE} 时 必须在下一控制周期内将运行模式更新为请求值并发出 ModeChanged 事件。 - Acceptance: - Given 当前 modeSAFEWhen 调用 SetMode(NORMAL) Then 下一控制周期内 ModeChanged.eventNORMAL返回 OK。 - Given 当前 modeSAFEWhen 调用 SetMode(INVALID) Then 返回 ERR_INVALID_ARGmode 仍为 SAFE不发出 ModeChanged。 - Priority: Must - Source: SR-1234 §3.2 - Change Type: modify - Existing Behavior: 旧实现对非法 mode 返回 ERR_UNSUPPORTED_MODE 本条将错误码改为 ERR_INVALID_ARG已获需求负责人批准。对比同文件给出的反例理解什么不是规格❌ FR-001: 系统应该处理用户请求 无主体、无触发、无结果不可测试 ❌ NFR-001: 性能要好 无阈值落不成测试 ❌ FR-002: 增加一个环形缓冲区处理协议解析 混入实现决策环形缓冲区是设计的事 ❌ FR-003: 无效 mode 返回 ERR_UNSUPPORTED 实际修改了既有错误码语义却未标 modify、未写旧行为Change Type 按对既有可观察行为的影响分类Change Type 不是按是不是新工作项判断而是按是否改变既有可观察行为类型判定要求new新增能力且不改变任何既有接口语义、错误码、状态机、阈值基线写N/Amodify改变既有行为、错误语义、默认值、阈值、兼容承诺必须写旧行为基线Acceptance 覆盖保留的行为与批准的破坏remove移除/禁用/废弃既有能力或兼容承诺必须写被移除行为、已知消费者、删除后的可观察语义关键纪律一条需求同时含 new 与 modify 信号 → 拆条不能拆 → 按更高风险归类。碰了旧路径却标new是规格阶段最危险的伪装它会让回归风险消失在评审视野里——spec-review-rubric 把变更风险显式列为不过即 critical 的检查项。devflow-specify的评估用例evals/evals.json专门覆盖了这种伪装成 new 的 modify场景要求重分类为 modify、补充旧行为基线与回归验收并在混合信号时拆条。NFR 条目字段模板中 NFR 的字段结构### NFR-001 标题 - 类别: ISO 25010 维度 - QAS: - Stimulus Source / Stimulus / Environment / Response / Response Measure含阈值 - Acceptance: 与 QAS 一致的 Given/When/Then - Source / Change Type / Existing Behavior: 同上NFR 必须写成 QAS不允许无阈值口号配套文件 nfr-quality-attribute-scenarios.md 规定每条核心 NFR 的最小契约是以 ISO/IEC 25010 为质量模型分类用 Quality Attribute ScenarioQAS格式表达。一句话规则每条核心 NFR 都必须能写成 QAS给出 Stimulus Source / Stimulus / Environment / Response / Response Measure 五要素。如果写不出来 → 说明 NFR 描述还不够具体回 Open Questions 找需求负责人/模块架构师补阈值。QAS 五要素约束要素含义约束Stimulus Source触发方用户/上游组件/外部系统/中断/监控告警/攻击者具体角色或源头不写用户Stimulus触发事件请求/中断/故障/负载 spike/配置变更可观察的具体事件Environment触发时系统所处状态正常/降级/启动/中断上下文/高负载必须明确状态不允许默认正常Response系统必须展现的响应行为可观察、可判断Response Measure响应的量化阈值或判定准则必须含阈值数字/百分比/时间/明确判定准则不允许足够快ISO/IEC 25010 质量模型维度模板按 devflow 主场景嵌入式/实时/控制的相关性排序质量维度前四行是高频区维度子维度选嵌入式典型问题Performance EfficiencyTime behavior, Resource utilization, Capacity控制周期 latency、jitter、CPU/内存占用、栈深度、消息队列容量ReliabilityAvailability, Fault tolerance, Recoverability看门狗、故障安全、降级模式、软复位行为、失败恢复时间MaintainabilityModularity, Testability, Analyzability组件边界稳定性、可单测性、日志可追溯性、静态分析友好度SecurityConfidentiality, Integrity, Authenticity, Non-repudiation, Accountability配置完整性校验、敏感数据保护、安全启动、签名校验CompatibilityInteroperability, Co-existence跨版本/跨平台 ABI/API 兼容、与既有协议栈共存Functional SuitabilityCorrectness, Appropriateness功能正确性是否被独立验证一般通过 acceptance 而非 NFR 表达UsabilityOperability, Accessibility在嵌入式 CLI/HMI 场景下相关纯固件较少PortabilityAdaptability, Installability跨目标平台移植OTA 升级不必覆盖所有维度每个 spec 按本工作项范围挑选相关维度不相关的维度显式标注本 work item 不适用不要默认省略。六个完整 QAS 示例配套文件给出了实时性、内存、并发、资源生命周期、错误处理、安全六个领域的完整示例这里摘录两条最有代表性的实时性Performance Efficiency / Time behavior### NFR-001 ModeSwitch 关键路径延迟 - 类别: Performance Efficiency / Time behavior - 优先级: Must - 来源: SR-1234 § 4.1目标平台 X 控制周期 10 ms QAS: - Stimulus Source: 子系统 Y 的调度器 - Stimulus: 调用 Service.SetMode(NORMAL) - Environment: 目标平台 X 在常规负载下控制周期 10 ms无未决高优先级中断 - Response: 在下一控制周期内完成模式切换并发出 ModeChanged - Response Measure: 95th percentile 切换延迟 ≤ 5 ms100% 在 10 ms 控制周期内完成 Acceptance: - Given 组件 X 在 NORMAL 调度上下文When 1000 次连续 SetModeThen 95th ≤ 5 ms 且 max ≤ 10 ms可由 latency 直方图证据验证。内存Performance Efficiency / Resource utilization### NFR-002 ModeService 静态内存预算 - 类别: Performance Efficiency / Resource utilization - 优先级: Must QAS: - Stimulus Source: 编译期链接器 / 启动期分配器 - Stimulus: 链接生成镜像运行期初始化 ModeService - Environment: 目标平台 X 链接配置 LinkerCfg.AROM/RAM 限制按团队基线 - Response: ModeService 不引入超过预算的静态内存且不使用动态分配 - Response Measure: ModeService 引入的 .data .bss 段 ≤ 4 KiBmalloc / new 调用次数 0由静态分析与 size 工具证据验证其余四个示例中断上下文写入约束、句柄获取与释放配对、非法输入校验、配置完整性校验位于 nfr-quality-attribute-scenarios.md均遵循同一五要素结构。NFR 写法约定与下游衔接每条核心 NFR 至少 1 个 QAS若无法写出 QAS → 不够具体回澄清Response Measure 必须含阈值Environment 必须写清系统状态不允许默认正常一条 NFR 覆盖多个不同质量维度时拆成多条 QAS不要塞进一条AcceptanceBDD Given/When/Then通常从 Response Response Measure 派生必须与 QAS 一致不能 QAS 写 5 ms、Acceptance 写 10 ms。QAS 与下游的衔接链devflow-design的测试设计章节把 QAS 映射到具体 unit/integration/simulation 测试用例devflow-tdd把 Response Measure 转为 RED 步的判定latency 直方图、size 工具输出、leak detector 报告devflow-review反向核对每条适用 NFR 是否被测试覆盖或有明确 N/A 理由。CON / ASM / EXC 条目模板为约束、假设、显式排除项预留了统一条目区按需添加### CON-001 / ASM-001 / EXC-001 … 约束 / 假设 / 显式排除项按需CON约束硬性约束如目标平台、编译条件、ABI 兼容可测试的 CON 会进入追溯矩阵ASM假设失效会改变规格的事实记录失效影响EXC显式排除项本轮不做的事是范围/非范围的条目化形式。接口候选契约涉及对外接口时必填当需求涉及对外接口IFR 条目存在或接口语义被修改时spec 必须给出语义级接口候选契约### IFC-001 接口/服务语义名 - Provider / Consumer: - Operation触发条件与操作语义: - Inputs语义级字段、单位、范围: - Outputs / 可观察结果: - Error Semantics错误码、失败语义、幂等性: - Sync/Async 与时序预期: - Compatibility兼容/版本/弃用策略: - Covers: FR/IFR IDs填写边界纪律见 devflow-specify/SKILL.md 与 spec-review-rubric写provider / consumer / 操作语义 / 输入输出含单位与范围/ 错误语义 / 同步异步与时序预期 / 兼容策略不写语言级函数签名、私有数据结构、重试次数、线程模型——那些是设计决策说不清 provider 或错误语义时写 Open Question不猜。这条契约会在设计阶段被devflow-design细化成可冷读的接口契约六项输入与前置条件、输出与后置条件、错误语义、副作用、并发与时序、兼容性实现者拿着契约不看代码就能写出测试。Open Questionsblocking / non-blocking 显式分类## Open Questions | ID | 问题 | 类型 | 负责人 | 阻塞什么决策 | |---|---|---|---|---| | OQ-001 | | blocking / non-blocking | | |每个开放问题必须标注blocking阻塞规格确认或non-blocking、负责人、它阻塞了什么决策blocking 问题闭合前规格不能确认把待决问题藏在正文里而不列出来等于把猜测走私进规格。业务方向、优先级、验收阈值答不上来时列入 Open Questions 交回提出人不自己编——这正是澄清而不臆造的落地动作。假设与依赖## 假设与依赖 | ID | 内容 | 失效影响 | |---|---|---| | ASM-001 | | |假设与依赖表记录每个假设失效时会改变规格的哪些事实供后续阶段在假设不成立时回溯修正。粒度检查过大条目的检测信号与拆分规则模板配套文件 granularity-and-split.md 规定一条需求过大时验收标准会失焦、测试设计会爆炸、实现会变成大切片。出现以下任一信号时做粒度检查一条 FR 包含多个角色/多个目标/多个独立结果验收标准开始覆盖大量互不相同的路径当前范围和以后再做的能力混在同一条里用户同时提到 MVP、后续版本、第二期能力。过大信号 G1-G8ID信号检测特征拆法G1多角色打包同一条 FR 里 ≥2 个角色/模块做不同动作按角色/模块拆G2CRUD 打包创建/查询/修改/删除写成一个管理功能按独立行为拆G3场景爆炸需要 ≥4 个彼此独立的验收场景才能说清拆主行为和关键分支G4关注点跨层主业务动作 后台处理 运维动作混在一条按各自可感知的独立结果拆G5多状态混写覆盖 ≥3 个状态/模式下的不同规则按状态族拆G6时间耦合即时结果和延时/定时/异步结果绑在一条拆即时与延时结果G7中断/任务混写嵌入式同一行为同时覆盖中断上下文与任务上下文按上下文拆中断侧通常只做最小写入调度G8跨编译条件嵌入式同时覆盖多个编译条件/目标平台的差异行为按平台/配置拆拆分规则子条目沿用父条目的 Source不丢失追溯锚点每个子条目重写自己的 Acceptance不允许写同父需求拆分后仍命中 G1-G8 → 继续拆拆掉的需求不允许暗自消失显式记成EXC或注明已拆出新工作项。机械拆分 vs 范围塑形拆分只改表达、不改范围把复合条目拆成更清晰的子条目→ 直接修改了范围/优先级/上下游归属部分子条目移出当前工作项、构成独立可发布能力→ 先回需求提出人确认拆出新工作项原 spec 的EXC中注明指向。注意DevFlow 不维护跨工作项的 deferred backlog拆出的能力去向是新工作项由需求负责人决定何时启动。配套工件traceability.md 追溯矩阵与 plan.md 骨架模板使用说明明确规格不是孤立的 spec.mddevflow-specify阶段必须同步初始化两个配套工件参考 traceability-template.md 与 plan-template.md。traceability.mdspec-design-code 一致性的显式约束初始化features/id-slug/traceability.md此后各阶段只追加自己负责的列specify 填需求与上游锚点design 填设计章节与测试设计用例tdd 填任务/代码/测试/证据。追溯矩阵是 spec-design-code 一致性的显式约束任何一列对不上说明工件之间已经漂移。# Work Item ID 追溯矩阵 - 工作项类型: AR / DTS / CHANGE - 工作项 ID: - 所属组件: ## 追溯行 | 需求条目 | Change Type | 上游锚点 | 组件设计章节 | 设计章节 | 测试设计用例 | 任务可多个 | 代码文件/函数 | 测试代码 | 验证证据 | |---|---|---|---|---|---|---|---|---|---| | FR-001 | modify | SR-1234 §3.2 | §6.2.1 | §4.2 / §7.1 | TC-001, TC-002 | T1 | src/mode.c:mode_set | test/mode_test.cpp | plan.md#T1 |填写规则要点每条核心 FR/NFR/IFR/可测 CON 一行ASM/EXC 不作为实现追溯行放入备注或范围说明CON 无法运行时验证时验证证据列写构建/静态分析/配置检查证据不能空着某列不适用时标N/A并简述理由modify/remove行必须能从基线追溯到回归/删除语义的验证证据测试设计用例必须能在 design.md 测试设计章节找到对应条目形成双向锚点一条需求拆到多个任务时任务列写多个 plan 锚点如plan.md#T1, plan.md#T3。plan.md 骨架运行模式、门禁表、计划边界按 plan-template.md 建立features/id-slug/plan.md骨架写入组件根、工件根、运行模式工作流启动时向用户确认的 attended/unattended、门禁状态表、计划边界。任务拆解留给devflow-tdd在设计评审通过后细化。spec-review-rubric 明确traceability.md 或 plan.md 骨架缺失 → verdict 为需修改没有磁盘工件的规格不能通过 R1。规格阶段的完整工作流与 R1 门禁结合 devflow-specify/SKILL.md 与 using-devflow/SKILL.md规格阶段的完整流程是收集上下文读取用户原始请求、上游单据、相关长期文档、组件仓库根AGENTS.md先按using-devflow的路径解析纪律确定组件根与工件根判断工作项类型AR/CHANGE/DTS澄清Capture → Challenge → Clarify按顺序追问——目标与成功标准 → 核心行为与触发条件 → 边界/异常路径/失败行为 → 既有行为基线 → 接口与兼容性 → 非功能约束每轮结束总结已锁定与待确认只剩 1-2 个问题时合并问写需求条目按本模板的结构化字段填写Statement 用 EARSAcceptance 用 Given/When/ThenNFR 写成 QAS五要素 含阈值的 Response Measure粒度检查按 G1-G8 信号拆分过大条目初始化追溯矩阵与执行计划骨架traceability.md plan.md自检并交评审通过后进入R1 门禁——派发devflow-review按 spec rubric 做独立评审并落盘记录这是必经节点不是可选预审verdict 通过后attended 模式把评审记录与 verdict 呈人确认。R1 门禁未通过含 attended 下未确认前不进入设计。评审是 human-on-the-loop 的支点作者不自审、评审者不动手修、没有记录的评审等于没有评审评审记录落在features/id/reviews/。规格评审的核心怀疑是两个不同的人读这份规格会做出同一个东西吗关键检查项包括每条 FR/IFR 的 Acceptance 是 Given/When/Then 且能直接落成一个失败测试每条核心 NFR 有 QAS 五要素且 Response Measure 有阈值无足够快/合理/必要时/体验良好等不可判定词触及既有接口/错误码/状态机/阈值的条目没有被伪装成newStatement/Acceptance 无实现细节走私。规格阶段自检清单把模板落到磁盘前逐项过一遍作者侧标准每条 FR/IFREARS 句式 Statement 可落成 RED 用例的 Acceptance Source每条核心 NFRQAS 五要素 含阈值的 Response Measure每条 FR/NFR/IFR/CON 有 Change Typemodify/remove 有旧行为基线与回归验收范围与非范围显式本轮不做的事在 EXC 或新工作项里不埋在正文涉及接口时有语义级接口候选契约Open Questions 已分类blocking 项已闭合或显式交回负责人通篇没有实现细节签名、数据结构、库、并发原语traceability.md 已初始化每条核心需求有行需求/Change Type/上游锚点列已填plan.md 骨架已建立组件根、工件根、运行模式已向用户确认、门禁状态表、计划边界。风险信号与裁剪边界规格阶段要警惕的风险信号来自 devflow-specify/SKILL.md把用户原文逐句改写成条目就当规格写完了原文 ≠ 规格必须经过澄清与结构化验收标准只是把 Statement 换个说法重复一遍没有新增判定口径NFR 写尽快合理并打算实现时再定碰了既有接口/状态机/错误码却全部标new自己猜了 Open Question 的答案并补进规格在 Statement 或 Acceptance 里指定数据结构、函数名、库选择。裁剪边界来自 using-devflow/SKILL.md微小修改几行、无接口变化、风险低时spec 可压缩成 plan.md 里的一段验收标准design 可省略R1/R2 随之合并入 R3但 TDD、R3 评审与 clean code 不裁剪纯重构不需要 spec/design但必须有覆盖现有行为的测试先行且代码评审照做。拿不准时不裁剪——裁剪的是文档量永远不是质量门槛。结语spec.md 模板的每一处结构设计都指向同一个目的让要做什么清晰到不需要猜。身份信息锚定上游、范围/非范围闭合边界、FR 用 EARS Given/When/Then 保证可测试、NFR 用 QAS 强制阈值、Change Type 显式暴露变更风险、接口候选契约预留设计入口、Open Questions 堵住猜测、traceability.md 建立全程追溯。当一条需求能直接落成一个失败测试并且两个不同的人读完会写出相同的测试时规格阶段就真正完成了它的使命——为后续的devflow-design、devflow-tdd、devflow-review、devflow-ship提供一份可靠的第一份契约。赞分享人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习【免费下载链接】agent-core-javaopenJiuwen agent core Java是 openJiuwen Core的 Java版本提供AI Agent开发、运行、调优与演进相关的全套SDK能力。项目地址https://gitcode.com/openJiuwen/agent-core-java点击查看免费下载相关推荐openJiuwen agent-core-java 的 DevFlow 规格实践用「可测试规格」把一句话需求变成第一份契约openJiuwen agent core java 的 DevFlow 规格实践用「可测试规格」把一句话需求变成第一份契约 本篇技术指南聚焦于 openJi人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习DevFlow NFR 规格化用 Quality Attribute ScenariosQAS把「性能要好」改写成可验证、可追溯的质量需求DevFlow NFR 规格化用 Quality Attribute ScenariosQAS把「性能要好」改写成可验证、可追溯的质量需求 导读 NFR人工智能AI AgentAgent 框架工具调用Agent 工作流RAGMCP Clients强化学习agentic-awesome-skills 之 Rex 分析师技能把模糊需求转成可执行规格说明agentic awesome skills 之 Rex 分析师技能把模糊需求转成可执行规格说明 导读 本篇文章围绕开源仓库 agentic awesomeAI 技能AI 插件上一篇3分钟掌握原神账号完整数据的终极查询指南如何用UID一键获取深度游戏分析下一篇3分钟成为原神数据分析师免费工具一键查询完整玩家数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
