circuit-resource-analysis

Circuit 资源分析

概述

分析资源，提取对 Circuit 产品有用的经验。重点关注关联、对比、可行性、对产品的影响，以及是否值得保存这个想法。

从一手资料入手

得出结论前，先使用最有力的可用资料。

• 如果用户粘贴了资源，就分析粘贴的内容。
• 如果资源是链接，就打开或搜索相关来源。引用用到的链接。
• 如果资源是本地仓库或代码库，就直接检查文件。
• 如果资源是 GitHub 仓库，就检查其 README、示例、文档，以及能证明相关行为的代码路径。
• 如果资源描述的是 Circuit 当前的行为，就先对照本地 Circuit 仓库验证，再判断其可行性。

处理 Circuit 仓库时，先阅读 docs/release/v1-launch-plan.md。产品词汇请参阅 UBIQUITOUS_LANGUAGE.md。判断工作流的可行性时，应优先参考当前代码和契约，而不是凭记忆判断。

Circuit 的关键参考资料：

• docs/release/v1-launch-plan.md
• UBIQUITOUS_LANGUAGE.md
• docs/flows/authoring-model.md
• docs/flows/block-catalog.json
• src/flows/catalog.ts
• src/flows/types.ts
• docs/architecture/run-process.md
• docs/ideas/README.md
• docs/ideas/catalog.json

对资源分类

分析前，先说明输入资源的类型：

• 代码库、仓库、库或工具
• 文章、随笔、论文、公告、帖子或对话
• 工作流示例
• 产品模式或竞品模式
• 其他

然后选择下面相应的分析路径。若资源属于多种类型，请结合分析。

分析代码库和文章

回答以下问题：

1. 核心想法是什么？
2. 它与 Circuit 有何关联？
3. 它与 Circuit 有何不同？
4. Circuit 可以从中学到什么？
5. Circuit 可以借鉴或采用什么？
6. 对 Circuit 来说，哪些做法不合适？为什么？

优先说明具体的产品影响，不要只泛泛总结来源内容。明确区分事实与解读。

分析工作流示例

分析工作流时，务必坦率评估其可行性：

1. 这个工作流作为 Circuit 流程是否有意思？
2. Circuit 目前能否支持它？
3. 如果可以，概述其流程结构。
4. 如果可以，说明 Circuit 如何超越所描述的工作流。
5. 如果不可以，指出缺少哪些部分。
6. 判断是否值得考虑补齐这些部分。
7. 说明这些部分会如何影响流程、模块、路由、检查、追踪或报告生态。

对于向 Slack、Linear、GitHub、电子邮件或其他工具发送内容的工作流，不要只说“有 MCP”。请明确其实际边界：

• 宿主 Agent 能否使用该工具？
• Circuit 步骤能否有意接收该工具？
• 如何处理身份验证？
• 是否需要人工审批？
• 有什么证据能证明操作已完成？
• 该操作应放在流程主体、路由、检查、报告中，还是运行流程外围的网关中？

区分以下情况：

• 目前可行：当前仓库通过现有契约支持。
• 配置后可行：无需更改引擎，但需要进行设置。
• 需要新增模块或路由：需要修改流程创作功能。
• 需要引擎改动：需要更改运行时或契约。
• 不合适：与 Circuit 的产品形态相悖。

判断是否保存

最后给出明确建议：

• 保存：当想法提出了有价值的 v1 后流程、模块、产品界面、证据模式或定位洞察时。
• 不保存：当想法过于笼统、已有相关内容、与 Circuit 关联薄弱，或主要是实现细节时。
• 或许保存：当想法有潜力，但还需要一个证明依据时。

如果建议保存，请提供：

• 简短的想法标题
• 可能的存放位置：docs/ideas/、流程待办列表、模块生态说明、发布定位说明，或“需要更多研究”
• 优先级：高、中或低
• 用一到两句话说明理由

除非用户要求记录，否则不要创建或编辑想法文档。

回复结构

除非用户要求详细说明，否则回答应保持简单、简短。

默认采用以下结构：

1. 核心结论：直接给出一个答案。
2. 资源内容：简要概述。
3. 与 Circuit 的契合度：说明关联与区别。
4. Circuit 现在能做到吗？：回答能、不能或部分能，并指出主要障碍。
5. Circuit 可以借鉴什么：列出具体经验。
6. 值得保存吗？：回答值得、不值得或不确定。

具体示例更清楚时，避免使用抽象的产品语言。