AI代理的品牌无关紧要，工作项的质量决定成败。如果交给代理的需求是非结构化的自由文本，每个代理都会猜测，且每次猜测结果都不同。将Azure DevOps工作项改造成机器可读的规范（Given/When/Then行为描述 + YAML模式定义），任何代理（Copilot Studio、Claude Code、Codex等）都能据其生成可复现的组件，并保持可追溯性。
失败根源：验收标准散落在过时的wiki、Teams消息或某人的脑子里，代理只能猜意图。换代理不能解决缺口，缺的是规范。一次会话生成的解决方案不可重复、不可审计，是披着效率外衣的单点故障。UAT中发现的返工成本约为设计阶段的5倍。
解决方案：用一致的工作项模板承载结构化块——验收条件用Gherkin格式（Given/When/Then），实体和表定义用围栏YAML，业务规则用条件与结果，安全角色显式命名。代理读取字段而非“氛围”，所以要为解析器而非站会写工作项。通过Azure DevOps REST API或MCP服务器程序化拉取工作项，输入结构化规范，输出Dataverse表、Power Automate流、插件代码，且每个产出物自动回链到工作项ID（AB#语法）。可追溯性锚定在Git提交和PR中，而非Dataverse元数据。
禁止区：代理绝不能进入生产环境、不能触碰托管解决方案、不能编辑安全角色或环境变量、不能绑定实时凭据，更不能修改它收到的规范。最经济的护栏是使用一个范围限定为开发环境且拥有自定义安全角色（非系统管理员）的应用注册身份，并配合DLP策略阻止生产连接器。运行前检查清单：规范含围栏块、身份仅限开发、DLP就绪、目标分支为feature、CI验证门控、人工PR审批者、提交模板强制AB#链接。如果七项不能全部满足，代理就不应运行。
将验收标准作为测试预言机：在CI中运行Given/When/Then场景验证生成解决方案，偏离规范即构建失败。目前这是一个需要自行组装（Power Apps Test Engine + 自定义脚本 + Build Tools任务）的模式，并非微软官方产品。人工PR审批者检查的是规范到工件的映射，而非每行代码。
用例演示：一个工项包含案例路由需求（YAML模式 + Given/When/Then），代理读取后生成Dataverse表、路由流和审批流，提交到feature分支，CI门控运行场景验证，开发身份使生产区物理不可达。从chat构建转向规范驱动构建后，可复现、可追溯、有治理。
正文小结：在下一个sprint之前，将一个Feature转换为围栏规范模板并提交。一条工项，包含YAML模式和Given/When/Then块，后续一切由此衍生。代理是可替换的细节，规范是常量。
#开发者 #工具 #AzureDevOps #PowerPlatform #AI #规范驱动 #ADO #代理开发 #CopilotStudio
@DevToolboxHub