抄写员

问题在哪

多团队对齐后，常见产物是散落的会议纪要、口头约定和半成品设计稿。到了实施与测试阶段，工程师面对的是「快速」「安全」「用户友好」这类无法判定通过/失败的需求，以及 PRD、SRS、HLD 混在同一文件里、ID 各写各的的情况。IIBA 行业调查里，相当比例的项目失败与需求语言含糊直接相关；忽视可测量的 NFR 同样是集成后期的典型坑。

Scribe（抄写员）的定位是：把想法和决策落成可移交、可审查、可测试的规范文档，而不是替你做功能构思、架构权衡或写实现代码。

它怎么工作

• 选对文档形态：按任务选用 PRD、SRS、HLD/LLD、实施/审查/发布清单、测试规范等模板；避免把多种关切塞进一个文件。
• 可追溯 ID：按 REQ-*、CFR-*、AC-{FEATURE}-{NNN}、TEST-* 等方案编号（兼容旧版 FR-*/NFR-*），并在 SRS 等场景可伴随 .traceability.yaml 分类账，便于与 Accord、Radar、Judge 等下游对齐。
• 可测试需求：拒绝无法产生二元通过/失败结论的条目；NFR 要落到具体阈值（例如 P95 响应时间）；验收标准用 Given-When-Then。
• 代理可读规范：需要给 AI 执行时，遵循 AGENTS.md 约定（命令、测试期望、目录结构、安全与约定），控制篇幅，把规范当作版本化契约。
• 工作流：UNDERSTAND → STRUCTURE → DRAFT → REVIEW → FINALIZE → INSCRIBE；子命令如 prd、srs、hld、lld、testspec、adr、runbook、api-doc 等，首 token 匹配则走对应配方。
• 上下游：接收 Vision/Spark/Helm/Gateway/Atlas/PDM 等输入；输出给 Builder、Artisan、Radar、Voyager、Judge、Sherpa、Morph、Lore 等。若交付物需对接 Spec-Kit 管道，可产出与 spec/、plan/、tasks/ 布局兼容的工件。

边界与注意点

• 不要用 Scribe：功能优先级与构思 → Spark；API 设计 → Gateway；架构决策 → Atlas；写代码 → Builder；行内代码注释 → Quill。
• 会先问清楚：文档类型不明、需求矛盾、范围膨胀、或必须先有 Atlas/Gateway 结论才能写规格时。
• 从不：无依据编造需求、把技术选型写进「需求」、省略审阅者与受众、用模糊形容词替代可测量标准。
• 合规敏感域（GDPR/HIPAA/SOC 2 等）需在范围中显式确认，不宜默认假设。