人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载导读本文围绕 gsd 扩展中的slice-context.md模板系统讲解在规范驱动开发Spec-Driven Development中如何为每个切片Slice编写高质量上下文文件——从 frontmatter、Goal、Scope 到 Integration Points、Open Questions 的全部字段设计与填写要领并结合仓库中auto-prompts.ts、auto-dispatch.ts等源码揭示该文件在 Agent 工作流中的真实消费链路。读完你将掌握一套可直接落地的切片上下文编写规范让长时运行的自治 Agent 在执行阶段不丢失目标、不越界、不盲干。一、切片上下文在整个工作流中的位置gsd 是一个元提示 上下文工程 规范驱动开发系统它把一次大范围工程交付拆解为Milestone里程碑→ Slice切片→ Task任务的三级粒度。其中roadmap.md 定义里程碑愿景、成功标准与切片序列context.md 承载里程碑级上下文用户可见结果、验收标准、架构决策、风险等slice-context.md 承载切片级上下文也就是本文的主角plan.md 承接切片上下文展开可执行的任务清单执行完成后由 slice-summary.md 与 milestone-summary.md 沉淀结果与前向情报Forward Intelligence。模板顶部注释对边界做了明确声明Slice-scoped context. Milestone-only sections (acceptance criteria, completion class, milestone sequence) do not belong here — those live in the milestone context.即验收标准、完成等级、里程碑序列这类里程碑级信息一律不写入切片上下文只写本切片自身的内容。这是整个模板的第一条纪律一个切片一份上下文越界即污染。二、frontmatter让上下文成为可被解析的结构化记录模板文件顶部是一段 YAML frontmatter--- id: {{sliceId}} milestone: {{milestoneId}} status: {{draft|ready|in_progress|complete}} ---id切片的全局唯一标识如M001/S02与 roadmap 中的切片编号一致milestone所属里程碑 ID用于把切片上下文挂回里程碑上下文与后续 slice-summary 的parent字段status四个枚举值draft → ready → in_progress → complete反映上下文文件自身从起草到完成的生命周期。从源码看这一结构化前缀并非装饰。在 auto-prompts.ts 中系统通过resolveSliceFile(base, mid, sid, CONTEXT)定位当前切片对应的上下文文件再经inlineFileOptional(sliceContextPath, sliceContextRel, Slice Context (from discussion))把其正文内联进后续执行提示词并记录trackPromptContext(..., slice-context, inline | skipped, ...)遥测——文件存在与否、是否成功内联都被纳入上下文预算统计。而在 auto-dispatch.ts 中自动分发逻辑会先检查resolveSliceFile(basePath, mid, state.activeSlice.id, CONTEXT)是否存在存在即视为讨论已完成可继续执行否则可能要求先补齐讨论。换句话说上下文文件本身就是一个状态信号——它的存在与否直接参与 Agent 的下一步决策。三、Goal 与 Why this Slice先回答做什么与为什么现在做Goal模板要求一句话说明切片完成时交付什么{{sliceGoal}}写作要领用可验证的结果描述而不是过程动作。例如提供结构化的任务状态端点含持久化的失败诊断信息优于实现状态功能。这与 roadmap 中成功标准写成可观察的事实是同一条原则的切片级落点。Why this Slice!-- Why this slice is being done now. What does it unblock, and why does order matter? -- {{whyNowAndWhatItUnblocks}}这一节要求回答两个问题它解锁了什么顺序为什么重要在依赖驱动的切片编排中这个答案决定了切片排序的合理性——如果一个切片的存在价值只是为以后铺路那么它很可能是一条横切层layer而不是垂直可演示的增量increment。这与 roadmap.md 中每个切片都必须是垂直、可演示的增量的规划质量规则互相印证。四、Scope用明确的 In/Out 给 Agent 划出执行边界## Scope ### In Scope - {{inScopeItem}} ### Out of Scope - {{outOfScopeItem}}Scope 是切片上下文中最防跑偏的防线。规范强调In Scope本切片实际要做的事逐条列出具体到可以据此写任务对应 plan.md 的 Must-HavesOut of Scope明确写出不做什么。非目标non-goals写清楚能防止 Agent 在执行中顺手优化相邻模块、越权改动边界外的代码。一个高质量的非目标条目示例不做认证中间件的全量重构——仅在 dashboard 路由上接入既有 auth 中间件。Out of Scope 不是偷懒而是把上下文预算花在刀刃上避免长时自治执行被无关细节稀释。五、Constraints把不可违反的前提钉进上下文## Constraints !-- Known constraints: time-boxes, hard dependencies, prior decisions this slice must respect. -- - {{constraint}}Constraints 收集三类信息时间盒time-boxes如本切片最多 2h不扩时硬依赖如必须等待 S01 的边界契约落地后方可开始先前决策prior decisions如延续 D002 的决策不在本切片重新讨论数据库选型。这些约束是执行阶段禁止触碰的红线。在规范驱动的工作流中它们直接约束 plan.md 的任务设计与 plan.md 中Threat Surface / Requirement Impact等质量段。写约束时应区分工程事实与偏好凡是会影响下游契约的约束必须显式记录防止 Agent 在执行中灵活变通破坏既有约定。六、Integration Points声明消费与产出的边界契约## Integration Points ### Consumes - {{fileOrArtifact}} — {{howItIsUsed}} ### Produces - {{fileOrArtifact}} — {{whatItProvides}}这一节是切片上下文的接口清单Consumes本切片运行时读取、依赖的已有文件或子系统并说明如何使用。它锚定了切片的起点也是 plan.md 任务inputs字段的来源Produces本切片将产出的文件或子系统并说明它对外提供什么。它声明了交付物的稳定表面供下游切片见 roadmap 的 Boundary Map依赖。命名要求与 roadmap 的 Boundary Map 一致要具体到文件、类型、接口、数据形状或不变式。Produces: auth system 太含糊Produces: 将已认证用户附加到请求上下文的 session middleware 才是有用的契约描述。这些产出通常也会进入后续 slice-summary 的provides/requires/key_filesfrontmatter形成跨切片的依赖图谱。七、Open Questions允许带着问号开工的前提## Open Questions !-- Unresolved questions at planning time. Answer them before or during execution. -- - {{question}} — {{currentThinking}}规范承认规划阶段不可能消灭所有不确定性。这一节用{{question}} — {{currentThinking}}的格式登记尚未解决的问题与当前猜想并要求在执行开始前或执行过程中回答它们。它的作用有三让风险显式化悬而未决的问题若不记录执行阶段会被 Agent 悄悄猜测掉给后续讨论留抓手plan-slice / guided-discuss-slice 等流程会围绕这些问题收敛与 roadmap 的 Key Risks / Unknowns 呼应切片级的开放问题汇聚起来就是里程碑级风险清单的来源。八、完整填充示例从模板到真实切片上下文将以上各节整合一个填充完毕的切片上下文大致如下--- id: M001/S02 milestone: M001 status: ready --- # M001/S02: 结构化任务状态端点 — Context ## Goal 提供带持久化失败诊断信息的任务状态查询端点。 ## Why this Slice S01 已落地任务分发与持久化但没有可观察的运行时状态 本切片解锁失败可诊断是后续 S03 自动化恢复的依赖前提。 ## Scope ### In Scope - 新增 GET /tasks/:id/status 端点 - 持久化 last_error、retry_count、phase、timestamp 字段 - 为端点补充集成测试 ### Out of Scope - 不修改既有任务分发协议 - 不做告警推送归属 S04 ## Constraints - 复用 S01 的 task_leases 表不新增存储 - 端点响应契约冻结后续切片不得破坏 ## Integration Points ### Consumes - src/dispatch/ledger.ts — 读取任务当前阶段与重试计数 ### Produces - src/status/endpoint.ts — 暴露 GET /tasks/:id/status供 S03 恢复逻辑与运维侧读取 ## Open Questions - 失败原因是否需要 PII 脱敏后输出— 当前猜想至少屏蔽 token 与密钥字段九、编写自检清单写完一份切片上下文后逐项检查是否只含切片级内容——验收标准、完成等级、里程碑序列等一律移除归入 context.mdGoal 是否一句话可验证——不是动作而是结果Out of Scope 是否具体——每条都能直接挡住一次越界执行Consumes/Produces 是否命名了具体文件或契约——含糊描述等于没有Open Questions 是否都有当前猜想——只列问题不给猜想Agent 依旧会盲猜frontmatter 的 id/milestone/status 是否与 roadmap、plan 保持一致——这是 auto-prompts.ts 定位文件、auto-dispatch.ts 判定讨论完成状态的结构化依据。十、模板族与相关文件索引切片上下文模板slice-context.md里程碑上下文模板context.md切片计划模板plan.md切片收尾模板slice-summary.md里程碑收尾模板milestone-summary.md里程碑路线图模板roadmap.md需求追踪模板requirements.md上下文内联与遥测实现auto-prompts.ts讨论完成判定实现auto-dispatch.ts赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐GSD-2 上下文工程实战以 God-Tier Context Engineering 十诫构建长期自主 Agent 的上下文系统GSD 2 上下文工程实战以 God Tier Context Engineering 十诫构建长期自主 Agent 的上下文系统 本文围绕 gsd 2 项目人工智能AI Agent代码智能体Agent 编排CLIAI 应用Langfuse 仓库自主 Agent 安全标准为 LLM 驱动的 CI 自动化构建可信执行边界Langfuse 仓库自主 Agent 安全标准为 LLM 驱动的 CI 自动化构建可信执行边界 Langfuse开源 AI 工程平台提供 LLM eva人工智能LLMOps可观测性AI 评测LLM 网关后端前端Agent Hypervisor 实战指南为 AI Agent 构建执行环、会话隔离与 Saga 补偿的运行时治理层Agent Hypervisor 实战指南为 AI Agent 构建执行环、会话隔离与 Saga 补偿的运行时治理层 Agent Hypervisor 是 a人工智能AI AgentAI 安全治理策略引擎认证鉴权Agent 沙箱可观测性上一篇如何快速搭建企业级审批流程系统5步完整部署指南下一篇8个革命性Adobe Illustrator智能插件彻底改变设计工作流创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gsd 切片上下文（Slice Context）模板实战指南：为长时自治 Agent 构建规范驱动的执行边界
人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载导读本文围绕 gsd 扩展中的slice-context.md模板系统讲解在规范驱动开发Spec-Driven Development中如何为每个切片Slice编写高质量上下文文件——从 frontmatter、Goal、Scope 到 Integration Points、Open Questions 的全部字段设计与填写要领并结合仓库中auto-prompts.ts、auto-dispatch.ts等源码揭示该文件在 Agent 工作流中的真实消费链路。读完你将掌握一套可直接落地的切片上下文编写规范让长时运行的自治 Agent 在执行阶段不丢失目标、不越界、不盲干。一、切片上下文在整个工作流中的位置gsd 是一个元提示 上下文工程 规范驱动开发系统它把一次大范围工程交付拆解为Milestone里程碑→ Slice切片→ Task任务的三级粒度。其中roadmap.md 定义里程碑愿景、成功标准与切片序列context.md 承载里程碑级上下文用户可见结果、验收标准、架构决策、风险等slice-context.md 承载切片级上下文也就是本文的主角plan.md 承接切片上下文展开可执行的任务清单执行完成后由 slice-summary.md 与 milestone-summary.md 沉淀结果与前向情报Forward Intelligence。模板顶部注释对边界做了明确声明Slice-scoped context. Milestone-only sections (acceptance criteria, completion class, milestone sequence) do not belong here — those live in the milestone context.即验收标准、完成等级、里程碑序列这类里程碑级信息一律不写入切片上下文只写本切片自身的内容。这是整个模板的第一条纪律一个切片一份上下文越界即污染。二、frontmatter让上下文成为可被解析的结构化记录模板文件顶部是一段 YAML frontmatter--- id: {{sliceId}} milestone: {{milestoneId}} status: {{draft|ready|in_progress|complete}} ---id切片的全局唯一标识如M001/S02与 roadmap 中的切片编号一致milestone所属里程碑 ID用于把切片上下文挂回里程碑上下文与后续 slice-summary 的parent字段status四个枚举值draft → ready → in_progress → complete反映上下文文件自身从起草到完成的生命周期。从源码看这一结构化前缀并非装饰。在 auto-prompts.ts 中系统通过resolveSliceFile(base, mid, sid, CONTEXT)定位当前切片对应的上下文文件再经inlineFileOptional(sliceContextPath, sliceContextRel, Slice Context (from discussion))把其正文内联进后续执行提示词并记录trackPromptContext(..., slice-context, inline | skipped, ...)遥测——文件存在与否、是否成功内联都被纳入上下文预算统计。而在 auto-dispatch.ts 中自动分发逻辑会先检查resolveSliceFile(basePath, mid, state.activeSlice.id, CONTEXT)是否存在存在即视为讨论已完成可继续执行否则可能要求先补齐讨论。换句话说上下文文件本身就是一个状态信号——它的存在与否直接参与 Agent 的下一步决策。三、Goal 与 Why this Slice先回答做什么与为什么现在做Goal模板要求一句话说明切片完成时交付什么{{sliceGoal}}写作要领用可验证的结果描述而不是过程动作。例如提供结构化的任务状态端点含持久化的失败诊断信息优于实现状态功能。这与 roadmap 中成功标准写成可观察的事实是同一条原则的切片级落点。Why this Slice!-- Why this slice is being done now. What does it unblock, and why does order matter? -- {{whyNowAndWhatItUnblocks}}这一节要求回答两个问题它解锁了什么顺序为什么重要在依赖驱动的切片编排中这个答案决定了切片排序的合理性——如果一个切片的存在价值只是为以后铺路那么它很可能是一条横切层layer而不是垂直可演示的增量increment。这与 roadmap.md 中每个切片都必须是垂直、可演示的增量的规划质量规则互相印证。四、Scope用明确的 In/Out 给 Agent 划出执行边界## Scope ### In Scope - {{inScopeItem}} ### Out of Scope - {{outOfScopeItem}}Scope 是切片上下文中最防跑偏的防线。规范强调In Scope本切片实际要做的事逐条列出具体到可以据此写任务对应 plan.md 的 Must-HavesOut of Scope明确写出不做什么。非目标non-goals写清楚能防止 Agent 在执行中顺手优化相邻模块、越权改动边界外的代码。一个高质量的非目标条目示例不做认证中间件的全量重构——仅在 dashboard 路由上接入既有 auth 中间件。Out of Scope 不是偷懒而是把上下文预算花在刀刃上避免长时自治执行被无关细节稀释。五、Constraints把不可违反的前提钉进上下文## Constraints !-- Known constraints: time-boxes, hard dependencies, prior decisions this slice must respect. -- - {{constraint}}Constraints 收集三类信息时间盒time-boxes如本切片最多 2h不扩时硬依赖如必须等待 S01 的边界契约落地后方可开始先前决策prior decisions如延续 D002 的决策不在本切片重新讨论数据库选型。这些约束是执行阶段禁止触碰的红线。在规范驱动的工作流中它们直接约束 plan.md 的任务设计与 plan.md 中Threat Surface / Requirement Impact等质量段。写约束时应区分工程事实与偏好凡是会影响下游契约的约束必须显式记录防止 Agent 在执行中灵活变通破坏既有约定。六、Integration Points声明消费与产出的边界契约## Integration Points ### Consumes - {{fileOrArtifact}} — {{howItIsUsed}} ### Produces - {{fileOrArtifact}} — {{whatItProvides}}这一节是切片上下文的接口清单Consumes本切片运行时读取、依赖的已有文件或子系统并说明如何使用。它锚定了切片的起点也是 plan.md 任务inputs字段的来源Produces本切片将产出的文件或子系统并说明它对外提供什么。它声明了交付物的稳定表面供下游切片见 roadmap 的 Boundary Map依赖。命名要求与 roadmap 的 Boundary Map 一致要具体到文件、类型、接口、数据形状或不变式。Produces: auth system 太含糊Produces: 将已认证用户附加到请求上下文的 session middleware 才是有用的契约描述。这些产出通常也会进入后续 slice-summary 的provides/requires/key_filesfrontmatter形成跨切片的依赖图谱。七、Open Questions允许带着问号开工的前提## Open Questions !-- Unresolved questions at planning time. Answer them before or during execution. -- - {{question}} — {{currentThinking}}规范承认规划阶段不可能消灭所有不确定性。这一节用{{question}} — {{currentThinking}}的格式登记尚未解决的问题与当前猜想并要求在执行开始前或执行过程中回答它们。它的作用有三让风险显式化悬而未决的问题若不记录执行阶段会被 Agent 悄悄猜测掉给后续讨论留抓手plan-slice / guided-discuss-slice 等流程会围绕这些问题收敛与 roadmap 的 Key Risks / Unknowns 呼应切片级的开放问题汇聚起来就是里程碑级风险清单的来源。八、完整填充示例从模板到真实切片上下文将以上各节整合一个填充完毕的切片上下文大致如下--- id: M001/S02 milestone: M001 status: ready --- # M001/S02: 结构化任务状态端点 — Context ## Goal 提供带持久化失败诊断信息的任务状态查询端点。 ## Why this Slice S01 已落地任务分发与持久化但没有可观察的运行时状态 本切片解锁失败可诊断是后续 S03 自动化恢复的依赖前提。 ## Scope ### In Scope - 新增 GET /tasks/:id/status 端点 - 持久化 last_error、retry_count、phase、timestamp 字段 - 为端点补充集成测试 ### Out of Scope - 不修改既有任务分发协议 - 不做告警推送归属 S04 ## Constraints - 复用 S01 的 task_leases 表不新增存储 - 端点响应契约冻结后续切片不得破坏 ## Integration Points ### Consumes - src/dispatch/ledger.ts — 读取任务当前阶段与重试计数 ### Produces - src/status/endpoint.ts — 暴露 GET /tasks/:id/status供 S03 恢复逻辑与运维侧读取 ## Open Questions - 失败原因是否需要 PII 脱敏后输出— 当前猜想至少屏蔽 token 与密钥字段九、编写自检清单写完一份切片上下文后逐项检查是否只含切片级内容——验收标准、完成等级、里程碑序列等一律移除归入 context.mdGoal 是否一句话可验证——不是动作而是结果Out of Scope 是否具体——每条都能直接挡住一次越界执行Consumes/Produces 是否命名了具体文件或契约——含糊描述等于没有Open Questions 是否都有当前猜想——只列问题不给猜想Agent 依旧会盲猜frontmatter 的 id/milestone/status 是否与 roadmap、plan 保持一致——这是 auto-prompts.ts 定位文件、auto-dispatch.ts 判定讨论完成状态的结构化依据。十、模板族与相关文件索引切片上下文模板slice-context.md里程碑上下文模板context.md切片计划模板plan.md切片收尾模板slice-summary.md里程碑收尾模板milestone-summary.md里程碑路线图模板roadmap.md需求追踪模板requirements.md上下文内联与遥测实现auto-prompts.ts讨论完成判定实现auto-dispatch.ts赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐GSD-2 上下文工程实战以 God-Tier Context Engineering 十诫构建长期自主 Agent 的上下文系统GSD 2 上下文工程实战以 God Tier Context Engineering 十诫构建长期自主 Agent 的上下文系统 本文围绕 gsd 2 项目人工智能AI Agent代码智能体Agent 编排CLIAI 应用Langfuse 仓库自主 Agent 安全标准为 LLM 驱动的 CI 自动化构建可信执行边界Langfuse 仓库自主 Agent 安全标准为 LLM 驱动的 CI 自动化构建可信执行边界 Langfuse开源 AI 工程平台提供 LLM eva人工智能LLMOps可观测性AI 评测LLM 网关后端前端Agent Hypervisor 实战指南为 AI Agent 构建执行环、会话隔离与 Saga 补偿的运行时治理层Agent Hypervisor 实战指南为 AI Agent 构建执行环、会话隔离与 Saga 补偿的运行时治理层 Agent Hypervisor 是 a人工智能AI AgentAI 安全治理策略引擎认证鉴权Agent 沙箱可观测性上一篇如何快速搭建企业级审批流程系统5步完整部署指南下一篇8个革命性Adobe Illustrator智能插件彻底改变设计工作流创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考