多 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 没有同步更新,最后失去权威。
以 spec.md 为锚点,再选择对应工具的交接模板。
可以放在 docs/specs、.specs,或仓库已有约定的任务目录里。
只要是有意义的行为变更,就建议提交,让规格和实现证据一起移动。
以 spec.md 为事实来源;继续让 agent 执行前,先明确更新 spec.md。
稳定的 spec.md 能让 AI 工具帮忙,而不是让产品决策消失在提示词里。
生成规格包