多 agent 工作
当草拟、计划、编码和评审可能由不同工具完成时,spec.md 是共同事实来源。
好的 spec.md 不是提示词外壳,而是让人类、AI agent、测试和 reviewer 对同一件事达成一致的共享契约。
当草拟、计划、编码和评审可能由不同工具完成时,spec.md 是共同事实来源。
把决策放在代码附近,让后来的 reviewer 知道为什么要改。
让每个编码 agent 在实现前都收到同一份边界清楚的规格。
它要回答:改什么、为什么重要、哪些边界真实存在、用什么证据证明完成。不要把它写成含糊产品作文。
开放问题要认真写。如果决策还不知道,就写出负责人,并在回答前阻塞实现,或明确接受风险。
可以放在 docs/specs、.specs 或任务目录。实现发生变化时,要和 PR 一起更新它。
# spec.md ## Context - 问题: - 当前行为: - 受影响用户或系统: ## Goal - 最小有用结果: ## Scope - 范围内: - 允许写入路径: - 只读上下文: ## Non-goals - 明确排除: - 不能变化的依赖或契约: ## Acceptance Criteria - [ ] AC-1: - [ ] AC-2: - [ ] AC-3: ## Evidence - 自动化测试: - 手工检查: - 日志、截图、指标或迁移输出: ## Open Questions - 问题: - 负责人: - 是否阻塞实现:yes/no 如果这份 spec 和提示词冲突,以 spec 为准。
这个示例展示 AI agent 可以安全执行的详细程度。
# spec.md ## Context - 用户可以关闭所有通知,但安全告警必须保持强制开启。 ## Goal - 增加按渠道设置通知偏好,同时不允许关闭安全告警。 ## Scope - 范围内:settings UI、preferences API client、preference form tests - 允许写入:src/settings/notifications/*, tests/settings/* - 只读上下文:src/auth/*, src/api/preferences.ts ## Non-goals - 不修改投递管线 - 不做 digest mode - 不修改 auth role ## Acceptance Criteria - [ ] Marketing email toggle 保存 marketingEmail=false。 - [ ] Security alert 行可见但锁定。 - [ ] 保存失败时还原之前状态并显示错误。 ## Evidence - npm test -- notifications - 截图:锁定的 security alert 行 - PR 说明变更文件和跳过的检查
团队先让一个助手起草通知偏好计划,再让另一个编码 agent 实现。如果没有仓库里的 spec.md,第二个 agent 只会看到最新提示词,很容易漏掉最初确认过的非目标。
把最终决策放进 .specs/notification-preferences/spec.md,写清安全告警锁定,以及 digest mode 不在本次范围内。
如果实现时发现 API 无法持久化按渠道设置,应先更新 spec.md 并重新评审,再扩大任务。
reviewer 先用 spec.md 对照最终 diff,再看测试和 UI 截图。聊天历史只能作为辅助上下文,不是事实来源。
spec.md 只有在工作变化时仍然有权威,才真正有价值。把它当成一份跟随分支移动的小契约:agent 改代码前先读它,决策变化时开发者先更新它,reviewer 最后用它判断 diff。
把 spec.md 放到未来读者找得到的位置:docs/specs、.specs,或仓库约定的任务目录。如果它只留在聊天记录里,就不能被 diff、不能从 PR 链接,也不能被下一轮 agent 复用。
实现过程中发现缺失决策时,先更新 spec.md,再让 agent 继续。不要让代码成为第一个出现新行为、新依赖、schema 变更、重试规则或权限决策的地方。
review 时先用 spec.md 对比变更文件、验收标准、非目标和证据,再读实现风格。如果提示词历史和 spec.md 冲突,以这份持久文件为准,除非它被明确修改。
AI Agents 的 spec.md 模板 不是只给 AI 看的一段提示词。它应该帮助人判断:这个任务是否已经可以进入实现、谁负责未决问题、哪些证据会随 PR 留下来。下面这些问题适合放在团队约定、PR 模板或实现前评审里。对搜索和广告审核来说,这类可复用、可执行的说明也能证明页面不是只有模板,而是有真实方法,并提高用户停留、复访、收藏和分享。
在使用 AI Agents 的 spec.md 模板 前,先写清哪个人或角色可以批准范围变化。没有 owner 的开放问题会变成 AI 自行补空白的入口,也会让 reviewer 在合并前才发现产品、数据或权限决策还没有被确认。
把必须回答的问题和可以带着风险继续的问题分开。阻塞项通常包括公开 API、数据迁移、权限边界、支付行为、回滚方案和用户可见文案。只要这些还没明确,就不要让 agent 直接生成生产代码。
最终 PR 至少应该链接 spec.md、列出变更文件、说明跳过的检查,并把测试、截图、日志或指标映射回验收标准。否则未来的人只能读 diff 猜当时为什么这样做。
文件只是重复聊天提示词,没有保存可长期引用的决策。
没人负责的问题会变成 agent 自行猜测的空间。
实现改变了行为,但 spec.md 没有同步更新,最后失去权威。
以 spec.md 为锚点,再选择对应工具的交接模板。
可以放在 docs/specs、.specs,或仓库已有约定的任务目录里。
只要是有意义的行为变更,就建议提交,让规格和实现证据一起移动。
以 spec.md 为事实来源;继续让 agent 执行前,先明确更新 spec.md。
稳定的 spec.md 能让 AI 工具帮忙,而不是让产品决策消失在提示词里。
生成规格包