Home / Brainwave / General · Undated

AI产品研发思路

General#AI设计#ai系统#ai产品经理#ai开发路径#ai技能

claude

模型回复

这是一个很值得深入探讨的架构决策问题。让我用一个交互框架来呈现思考维度。补充几个核心思考角度，帮你在具体系统中定位：传统系统 LLM 重构框架

切入点识别重构策略落地模式风险矩阵

找切入点的核心原则：哪里的人工处理成本最高、哪里的非结构化信息最多、哪里的规则最难穷举，那里就是 LLM 最大价值点。

高价值非结构化输入处理：用户输入、客服对话、邮件工单——原本靠人工分类路由，现在 LLM 直接理解意图规则引擎替代：审批、合规、推荐——规则超过 200 条时维护成本高，LLM 用语义理解替代穷举

中价值内容生成节点：报告生成、摘要提炼、通知撰写——原来模板硬编码，现在动态生成搜索与检索升级：关键词搜索 → 语义检索，知识库、文档库首先受益

渐进价数据洞察与解读：BI 报表 + LLM 解读层，让数字变成可直接行动的语言结论交互层自然语言化：表单/按钮 → 对话式操作，降低使用门槛，适合 ToB 后台

三种重构路径，选择取决于系统现状和业务容忍度：

外挂层（Wrapper）策略 — 最快、风险最低

在不改原系统的前提下，在其上方叠加 LLM 交互层。原系统 API 不动，LLM 负责理解意图、调用 API、组织返回结果。适合遗留系统、无法动核心代码的场景。

改动最小上线最快适合内部工具

管道替换（Pipeline Swap）策略 — 平衡改造

识别系统中的处理节点，逐个用 LLM 组件替换高价值节点。其他节点保持不变。例如把「分类模块」从规则树换成 LLM prompt，把「摘要模块」从模板换成动态生成。

模块化推进可回滚需要 A/B 测试

以 Agent 为核心重新设计（Full Rebuild）— 最彻底

重新定义系统的核心架构：LLM 作为「编排大脑」，原有功能模块变成工具（tool）。系统不再是流程图驱动，而是目标驱动。适合业务逻辑本身已经不稳定、需要大幅提升灵活性的场景。

架构级变革周期长适合新赛道

常见的落地设计模式，每种解决不同的架构问题：

改造过程中的关键风险，以及对应的缓解策略：

⚠

幻觉与不一致输出

LLM 输出非确定性，同一输入可能得到不同结果。缓解：结构化输出约束 + 验证层 + 关键路径保留规则兜底。

⚠

延迟与成本

LLM 调用比传统逻辑慢 10-100x，成本不可控。缓解：缓存高频 prompt、分级处理（简单请求走规则，复杂才走 LLM）、批量异步处理。

⚠

可观测性缺失

传统系统故障有明确日志，LLM 失效模式难以追踪。缓解：记录每次 prompt/completion、建立 eval 体系、监控关键指标的漂移。

⚠

数据安全与合规

敏感数据通过 LLM API 存在合规风险。缓解：数据脱敏 pipeline、私有化部署评估、明确哪些字段不能进入 prompt。

⚠

过度依赖单一模型

模型升级/降级/价格变化影响整个系统。缓解：抽象 LLM 调用层、保持模型可替换性、关键功能保留规则兜底逻辑。

找切入点的三个诊断问题

第一，这个模块里人类在做什么"理解"工作？如果一个岗位的核心职责是「读材料、判断、写结论」，这就是典型的 LLM 替代或增强场景——理解、判断、生成这三个动作 LLM 天然擅长。

第二，这里有多少隐式知识无法被规则穷举？老系统的规则引擎往往只覆盖 80% 的情况，剩下 20% 靠老员工经验处理。LLM 的价值恰好在这个 long tail——这里往往也是业务最痛的地方。

第三，哪里的接口是"人"？有些系统之所以复杂，是因为它的很多模块之间靠人工来传递信息和做判断。把这些「人类中间件」替换成 LLM agent，往往能同时降成本和提速。

改造节奏的建议

不要从最核心的业务逻辑开始。优先选一个「失败成本低、改造价值高」的模块做 pilot——比如通知文案生成、工单分类、内部搜索。跑通评估体系（eval pipeline）之后，再向核心逻辑扩展。这个 eval 体系本身就是最重要的基础设施投入，没有它你永远不知道 LLM 改造是否真的在变好。

如果你有具体的系统类型（ERP、CRM、审核系统、内容平台等），可以进一步定向分析。

User

提问

你回答的太虚了，你看看你竞争对手的回答，重新回答一次：这是一个很有价值的架构转型设想：将传统项目改造成 “以IM为交互界面、以AI为处理核心” 的工作流系统。本质是把原来分散的菜单、按钮、表单页面，变成对话驱动的任务执行环境。

一、切入点：选择一个“高频率、低耦合、可分解”的典型任务

不要一开始就重构整个系统，而是选一个最痛点、最适合对话模型的子流程作为试点。判断标准：

· 高频且查询/操作频繁：比如客服工单、审批流转、数据报表请求、任务分配。用户每天要多步点击或跳转多个页面才能完成。 · 逻辑可自然语言描述：任务的输入、步骤、输出能用“当我说A，你就做B”清晰表达。 · 与现有系统耦合低：该任务对外部依赖少，或已有清晰API接口，方便“对话→API调用→返回结果”的链路。 · 结果可以简洁呈现：最终返回的内容适合在IM消息框中展示（如卡片、短文本、表格），不需要复杂的大屏交互。

典型切入点案例：

· 运维告警处理 → 用IM收到告警，AI自动分析并建议执行命令（需用户确认后调用API重启/扩容） · 内部数据查询 → 用户问“上季度华北区销售额”，AI转SQL → 查库 → 以表格/文字回复 · 项目任务创建 → 用户说“帮我在XX项目下建一个‘周报审核’任务，派给张三，明天截止”，AI调用任务系统API完成创建

二、从哪些角度思考重构（五个核心维度）

交互范式：从“界面驱动”转为“对话驱动”

· 原模式：用户需要知道去哪里找按钮、填表单、提交。 · 新模式：用户只需用自然语言表达意图，由AI理解并转化成系统可执行的指令。 · 设计要点： · 设计意图分类器：区分用户是想查询、操作、还是闲聊/求助。 · 设计槽位提取：从消息中抽取出所需参数（时间、对象、动作等），缺失时主动反问。 · 提供快捷命令与建议回复按钮，降低纯文本输入的门槛。

任务编排：从“固定流程”转为“弹性 Agent 流程”

传统项目的工作流往往是表单驱动的固定步骤（如填单→送审→审批→归档）。围绕IM+AI后，流程可以变得动态：

· AI作为路由中枢：根据用户意图决定调用哪个API、是否需要人工介入、是否需要多层确认。 · 引入“执行-确认”模式：高风险操作（删除、修改权限）让AI先输出计划，用户回复“确认”后再执行。 · 支持多轮补充：用户不必一次性提供全部信息，可以像跟同事说话一样分步告知。

系统集成：从“UI调用API”转为“AI+语义层”

这是技术核心。传统项目前端直接调后端接口；改造后需要增加一个 “语义执行层”：

用户消息 → IM适配器 → LLM（意图+参数）→ 语义执行器 → 调用原有API/查库 → 生成回复 → 发回IM

· 关键组件： · 函数声明（Tools/Function Calling）：为每个现有API写语义描述（名称、参数、用途、约束），LLM据此决定调用哪个。 · 参数映射：LLM提取的自然语言值（如“明天下午三点”）→ 转成API需要的格式（2026-05-04T15:00:00Z）。 · 错误处理：AI调用失败时，返回给用户可理解的提示，并建议下一步。

数据与权限：从“页面级权限”转为“对话级安全性”

IM+AI模式下，用户可以看到别人的对话记录吗？AI能否代表用户执行越权操作？

· 原则：AI不得拥有超过当前用户的权限。每次API调用前，需要传递用户身份（OAuth token），由后端再做权限校验。 · 敏感操作：强制二次确认；在回复中明确提示“你将要执行X操作，请回复‘确认’”或使用IM的按钮交互（如飞书卡片按钮）。 · 对话审计：所有AI与用户的交互记录应持久化，方便事后审计。

反馈与迭代：从“版本发布”转为“持续提示工程”

传统项目改bug后发版；AI项目则需要持续优化提示词、示例、RAG知识库。

· 建立“对话日志标注”流程：每天抽样查看对话，标记哪些回答不好（意图识别错、参数漏、回答生硬），修正提示词或增加Few-shot示例。 · 构建评估集：收集50-100条真实用户问题，每次改动后跑回归测试，确保准确率不下降。

三、具体实施路线（四步推进）

Step 1：搭建IM机器人基础通道

· 选择IM平台（企业微信、飞书、钉钉、Slack），申请机器人，能接收消息并回复。 · 搭建一个简单的回调服务，先做echo（你发什么我回什么），验证连通性。

Step 2：实现第一个“对话到API”的完整闭环

· 选择切入点那个高频任务。例如：查数据库的某个视图。 · 编写LLM调用逻辑：系统提示词 + 定义该任务的function schema。 · 实现function的实际调用逻辑，并将结果格式化发回IM。 · 目标：用户问“查询今天的异常订单”，机器人回复正确列表。

Step 3：增加多轮对话和确认机制

· 实现槽位反问：例如用户说“查订单”，AI回复“请问查哪天的？哪个客户？” · 对危险操作增加确认步骤（可用消息卡片带“确认”“取消”按钮）。 · 增加快捷回复按钮（点击按钮等于发送预设文本），提升易用性。

Step 4：泛化与平滑迁移

· 将更多业务API按同样模式封装成tools。 · 在IM中提供“帮助”命令，告诉用户现在能做什么。 · 保留原有界面入口，让用户可以随时切回老界面，降低迁移风险。

四、常见坑与避坑建议

坑建议用户自由输入太啰嗦，AI理解错误预设几类典型话术作为示例，引导用户“请用‘查询X时间段内Y的Z’这类句式” 网络延迟 + LLM响应慢，IM回复卡顿先回复“收到，正在处理…”异步再给结果；或流式输出 AI擅自执行危险操作凡是写操作（POST/PUT/DELETE）必须走确认流程，且确认消息不可与用户输入合并大模型凭空编造数据禁止模型直接生成数据；所有数据必须来自API/数据库，模型只负责翻译和格式无法处理长对话上下文限制保留最近N轮（如10轮），并压缩历史摘要；尽量让每个用户消息独立可调用

总结

围绕IM+AI重构传统项目，最实际的切入点是一个查询或执行类的高频任务。思考角度应从交互范式、任务编排、系统集成、权限安全、持续迭代五个方面入手。不要试图一次把所有界面搬到IM里，而是让AI成为“能用语言操控系统的智能代理”，原有的后台API和数据库几乎可以保留不变，核心价值是降低用户的操作门槛，提高任务执行效率。

Claude

模型回复

传统系统围绕 LLM 重构的切入点与思路

一、找切入点的判断标准

不要从最核心的业务逻辑开始，先找一个满足以下条件的子流程：

高频 + 操作繁琐：用户每天要点多个页面、填多个表单才能完成的事。这类场景用对话替代收益最明显。

逻辑可以用自然语言描述：如果一个任务能被描述成"当用户说X，系统做Y"，它就适合 LLM 处理。反之，纯数值计算、强事务一致性的场景不适合。

与现有系统耦合低，或已有清晰 API：改造不需要动核心数据库和业务逻辑，只需要在上层加一个"语义执行层"。

结果可以在消息框里呈现：表格、短文本、卡片都行。需要复杂大屏交互的场景先不碰。

典型的好切入点：内部数据查询、工单创建与流转、运维告警处理、审批状态查询。

二、五个核心改造角度

1. 交互层：从界面驱动变成意图驱动

原来用户需要知道去哪个菜单、点哪个按钮。改造后用户只需表达意图，系统理解并执行。

技术上需要做两件事：意图分类（用户是要查询、操作、还是求助）和槽位提取（从自然语言里抽出时间、对象、动作等参数，缺失时主动反问）。同时提供快捷按钮降低纯文本输入门槛，不要让用户完全靠打字。

2. 任务编排：从固定流程变成弹性 Agent

传统系统是表单驱动的线性流程。引入 LLM 后，流程可以动态决策：根据意图调用不同 API，高风险操作先输出执行计划让用户确认，用户可以分多轮补充信息而不是一次性填完。

关键原则：写操作（创建、修改、删除）必须走"AI 出计划 → 用户确认 → 执行"，不能让 AI 直接执行。

3. 系统集成：加一个语义执行层

这是技术核心。原来前端直接调后端 API，改造后链路变成：

用户消息 → LLM（意图+参数提取）→ 语义执行器 → 调用原有 API → 格式化结果 → 返回用户

原有的后端 API 和数据库基本不用动。核心工作是为每个 API 写 Function Calling 的语义描述（名称、参数、用途、约束），以及处理 LLM 提取的自然语言值到 API 格式的映射（比如"明天下午三点" → 2026-05-04T15:00:00Z）。

4. 权限与安全：对话级别的权限控制

LLM 不能拥有超过当前用户的权限。每次 API 调用必须传递用户身份 token，由后端做权限校验，不能在 LLM 层面做权限判断。敏感操作强制二次确认，所有对话记录持久化留审计。

5. 迭代方式：从发版变成持续提示工程

传统项目改 bug 发版；AI 项目要持续优化 prompt、补充 few-shot 示例、更新 RAG 知识库。需要建立对话日志标注流程——每天抽样看哪些回答不好（意图识别错、参数漏提、回答生硬），针对性修正。同时建立 50-100 条真实问题的评估集，每次改动后跑回归，确保准确率不下降。

三、四步落地路线

Step 1：搭通基础通道 选一个 IM 平台（企业微信/飞书/钉钉），搭机器人，先做 echo 验证连通性。

Step 2：跑通第一个完整闭环 选切入点那个高频任务，写 system prompt + function schema，实现"用户问 → LLM 解析 → 调 API → 回复结果"全链路。目标是一个任务从头到尾跑通，不求覆盖所有情况。

Step 3：加多轮对话和确认机制 实现槽位反问、危险操作二次确认、快捷回复按钮。这一步决定了产品体验是否顺滑。

Step 4：泛化并平滑迁移 把更多 API 按同样模式封装成 tools。保留原有界面入口，让用户可以随时切回老系统，不要强迫迁移。

四、常见坑

坑	怎么避
用户输入太随意，AI 理解错	预设典型话术示例，引导用户用固定句式；用按钮补充自由输入
LLM 响应慢，IM 卡顿	先回"收到，处理中…"，异步返回结果
AI 擅自执行危险操作	写操作全部走确认流程，硬编码，不走 LLM 判断
模型凭空编造数据	禁止模型直接生成业务数据，所有数据来自 API/数据库，LLM 只负责理解和格式化
长对话上下文爆炸	只保留最近 N 轮，历史做摘要压缩

核心结论：原有后端 API 和数据库基本不动，改造的核心是在上层加一个语义执行层，把"用户意图"翻译成"系统调用"。 从一个高频低耦合的子流程切入，跑通闭环，再逐步扩展。

perplexity

模型回复

可以把这件事理解成：不要先问“怎么把代码改成 AI 写”，而要先问“系统里哪些环节本来就适合由 LLM 作为主执行者，哪些环节必须被约束和验证”。真正的切入点通常不是从“整仓库重写”开始，而是从“最有信息密度、最适合语言建模、且最能通过反馈闭环验证”的局部入口开始。你之前一直在讨论 harness、spec-driven workflow、DIG/OpenSpec，这其实已经指向了正确方向：Memory+2

先找切入点

最好的切入点通常有三类：

文本密集型环节：需求澄清、工单拆解、方案评审、接口文档、变更说明、测试用例生成、故障复盘。
规则明确但人工作业重的环节：配置迁移、脚手架生成、重复性编码、批量修复、兼容性检查、回归测试。
强反馈闭环环节：能立刻跑测试、看日志、比对输出、自动修复的流程，因为 LLM 的价值在于迭代，而不是一次性“猜中”。Memory+2

相反，不要先从核心交易逻辑、复杂分布式状态机、强实时链路、强安全链路直接重构。这些地方一旦出错，LLM 的随机性会放大风险；更合适的做法是先把它们包在稳定外壳里，再逐步让 AI 接管外围流程。Memory+1

用什么视角看

你可以用五个视角来判断一个老系统是否适合围绕 LLM 重构：

任务本质：它是“计算问题”还是“解释、协调、判断、生成问题”？
状态复杂度：状态是否少而明确，还是强耦合、强事务、难回滚？
验证能力：结果能不能自动测、自动验、自动回归？
变化频率：需求是否经常变，文案、流程、规则是否经常改？
人力瓶颈：当前最耗人的地方，是写代码、写文档、做判断，还是做协调？Memory+1

如果一个模块“高变化 + 高文本 + 可验证”，它非常适合先 LLM 化。
如果一个模块“低变化 + 强状态 + 难验证”，它更适合先做边界封装，而不是直接让 LLM 重写。Memory+1

重构的顺序

比较稳的顺序是：

先重构入口，不先重构内核。把需求、工单、知识、约束、验收标准变成结构化输入，而不是散落聊天记录。
先重构工作流，不先重构业务代码。先让 AI 能分析、拆解、生成、验证、归档，再逐步接管实现。
先重构外围系统，不先重构核心交易。例如文档、测试、配置、脚手架、回归、告警、日志、自动修复。
先做可回滚的局部闭环，再做全局替换。每一步都要能验证、能撤销、能对比旧系统表现。Memory+2

这和你前面讨论的 harness 思路一致：不是把模型直接扔进老系统，而是先给它一个能稳定工作的环境、规则和反馈循环。Memory+1

迁移的分层

把老系统转成 AI 原生系统，可以分成四层：

层级	老系统做法	AI 原生做法
交互层	人工提需求、人工查资料	结构化意图输入、自然语言+模板约束
编排层	人工拆任务、人工分配	代理路由、任务状态机、自动分派
执行层	手写代码、手工修 bug	LLM 生成、工具调用、自动修复
验证层	人工验收为主	测试、lint、回归、日志、门禁自动化

如果这四层没有拆开，AI 往往只会变成“更会聊天的编辑器”；
只有拆开后，AI 才有机会变成“系统的一部分”。Memory+1

组织和治理

真正的迁移不是技术改造单独完成的，而是治理方式也要变。你前面一直在关注 spec、ITERATIONS、DECISIONS、HARNESS、QUALITY 这些文件，本质上就是在把“知识”变成“可执行治理”。Memory+2

这意味着：

需求要可追溯。
变更要可回放。
测试要可自动判定。
失败要可归因。
经验要可沉淀。
规则要能反向进入系统本身。Memory+1

如果没有这套治理，LLM 化只会带来更多不确定性，而不是更高生产力。Memory+1

一个实用判断

你可以用一句话判断切入点是否正确：

这个模块能不能让 AI 在“看得懂输入、做得出输出、测得出对错、错了能修回来”的条件下工作？

如果能，它就是优先切入点。
如果不能，就先别碰实现，先补文档、补测试、补边界、补状态可观测性。Memory+2

应该长什么样

最常见、也最稳的形态是“四层架构”：

交互层：用户输入目标、约束、上下文，系统把自然语言转成结构化任务。
编排层：负责拆解任务、分派角色、维护状态机、控制重试与回滚。
执行层：由 RAG、工具调用、代码执行、API 调用、数据库操作组成。
验证层：负责测试、lint、结构检查、回归、观测和自动修复反馈。martinfowler+2

如果任务本身很简单，可能只需要 RAG + 规则引擎。
如果任务是多步骤、强状态、要持续迭代的老系统改造，通常就要上到“RAG + workflow + agent + feedback loop”的组合。orq+2

三种能力分工

可以把三者的职责分清楚：

RAG 负责“知识补全”，比如查规范、查历史方案、查工单、查代码上下文。
流程编排 负责“过程控制”，比如需求确认、任务拆分、审批、测试、发布、归档。
Agent 负责“动态决策”，比如遇到异常时选择工具、判断是否重试、是否改 spec、是否触发重构。techment+2

所以不是在 RAG、流程、agent 之间三选一，而是根据任务性质组合。
经验上，知识密集用 RAG，流程稳定用编排，决策不确定用 agent。orq+1

设计原则

设计 AI 系统架构时，最重要的原则不是“能不能用最酷的模型”，而是“能不能稳定地产生可验证结果”。OpenAI 和相关 harness 讨论都强调，真正难的不是提示词，而是环境、反馈回路和控制系统。augmentcode+2

我建议用下面这组原则：

先确定闭环，再确定智能度。先保证能输入、能执行、能验证、能纠错，再谈多智能体和复杂推理。martinfowler+1
把不确定性关在边界内。LLM 只负责它擅长的部分，状态转换、权限、发布门禁尽量交给确定性系统。okta+1
让错误可被机器读懂。错误信息要能直接驱动自修复，而不是只给人看。alexlavaee+1
把知识、规则、验证分开。知识放 RAG，规则放约束文件，验证放测试和门禁，不要揉成一锅。alexlavaee+1
优先局部自治，避免全局自治过早。先让一个子流程自动跑通，再扩大到更大系统。orq+1
默认可观测。日志、轨迹、指标、样本回放必须成为架构一部分，而不是上线后补。martinfowler+1

怎么选架构

一个实用判断法是看这四个维度：

维度	倾向 RAG	倾向编排	倾向 Agent
知识复杂度	高	中	高
步骤稳定性	低到中	高	中到低
任务不确定性	低	低到中	高
需要自治修复	低	中	高

如果一个项目的核心问题是“找资料、找上下文、找规则”，那先做 RAG。
如果核心问题是“把复杂流程稳定执行完”，那先做 workflow orchestration。
如果核心问题是“中途经常变化、需要自我判断、需要工具链协作”，那就需要 agent 层。techment+2

老系统改造建议

对于存量系统，最好的方式通常不是推倒重来，而是把 AI 放在外围控制面上：

先让 AI 接管需求理解、工单拆解、知识检索、文档生成。
再让 AI 接管测试生成、回归分析、故障排查、修复建议。
最后再逐步让 AI 参与局部执行和流程编排。augmentcode+2

这样做的好处是，老系统内核不必立刻变动，但系统的“智能入口”和“反馈回路”已经开始 AI 化。
这也是把传统系统转成 AI 原生系统最现实的路径。alexlavaee+1

如果你愿意，我下一步可以直接给你画一版**“老系统改造为 AI 原生系统”的参考架构图**，并按“知识层、编排层、执行层、验证层”给出每层该放什么组件。

User

提问

这样的架构设计前提下，当前流行的openspec、superpowers等ai开发工具在其中扮演的角色是什么，某一个环节的某一个任务的自主开发吗？

perplexity

模型回复

不是，它们通常不是“某一个环节里的单个任务自主开发工具”，而是更像围绕某一类开发活动的工作流控制层：把“需求 → 规范 → 计划 → 实现 → 测试 → 归档”这些步骤标准化，然后让 agent 在这个框架里自动推进。augmentcode+2

它们各自的角色

OpenSpec 更像“规格与变更控制层”。它把需求变化拆成 proposal / apply / archive 这类阶段，强调 brownfield 场景里的增量修改、审批门禁和规格同步，所以它更适合做“存量系统改造时的变更入口”和“意图的版本控制”。intent-driven+2

Superpowers 更像“agent 执行与技能编排层”。公开资料把它描述为一个基于 composable skills 的软件开发工作流，覆盖 design refinement、spec writing、implementation planning、subagent execution、review 等阶段，因此它更接近“让 coding agent 按工程化流程工作”的运营层，而不是单点编码插件。youtube aiagentstore

它们适合放在哪一层

如果按你前面说的架构分层来看：

OpenSpec 主要放在编排层前端，负责把需求和变更变成可审阅、可追踪、可归档的 spec 流。
Superpowers 主要放在执行层上方，负责把一个任务拆成可执行技能、子代理和质量步骤。
真正的代码生成、测试执行、工具调用，还是由底层 agent 和工具链完成。linkedin+2

所以它们更像“让 AI 开发过程有秩序”的系统，而不是单独替你写某一行代码的工具。aiagentstore+1

在老系统改造里怎么用

在老系统改造场景里，这类工具最有价值的地方是：

把改造需求结构化，避免口头需求直接进代码。
把复杂任务拆成阶段性产物，减少一次性大改导致的失控。
把验证和归档变成流程的一部分，防止后续迭代改坏既有功能。intent-driven+2

也就是说，它们不是最终目标，而是你 AI 原生架构里的“治理工具”。
真正的目标是让它们服务于你的主系统：知识检索、流程编排、agent 执行、测试验证、反馈闭环。augmentcode+1

设计原则

如果你要把这类工具纳入系统架构，建议遵循一个原则：工具不要直接承载业务真相，只承载过程控制。业务真相应该落在你的 spec、architecture、tests、decisions、iterations 这些仓库资产里；OpenSpec / Superpowers 只负责推进状态、规范步骤、约束行为。aiagentstore+2

更直白一点说：

OpenSpec 负责“这次要改什么，改到什么程度算批准”。
Superpowers 负责“批准后怎么拆解、怎么执行、怎么复核”。
你的系统本体负责“代码、数据、权限、状态、可观测性”。hashrocket+2

如果你愿意，我下一步可以直接给你画一张**“OpenSpec / Superpowers / RAG / Agent / Workflow” 在同一套 AI 架构里的位置图**，并标出每一层该放哪些文件、哪些工具、哪些自动化检查。

User

提问

那你给我出一个完整的流程描绘，ai项目的开发，都包括什么阶段，阶段目标是什么，产出物是什么，使用什么样的工具，上下游如何衔接，如果是多人参与，如何保证一致性等。

Perplexity

模型回复

可以，我给你一套完整的 AI 项目开发流程，按“阶段目标 → 产出物 → 工具 → 上下游衔接 → 多人一致性”来拆。它适用于从传统系统改造到 AI 原生系统，也适用于新建 AI 项目。triare+2

总体结构

最稳妥的 AI 项目不是“一口气写代码”，而是一个连续闭环：定义问题 → 结构化规范 → 方案设计 → 任务拆解 → 实现 → 验证 → 发布 → 监控 → 迭代。orq+2
如果项目是 spec-driven 的，还会把“需求澄清、计划、任务、实现”做成显式阶段，确保所有人和 agent 都从同一份规格工作。epam+1

阶段一：问题定义

这一阶段的目标，是确认项目到底解决什么问题、成功标准是什么、哪些事情不做。产出物通常是产品目标、范围说明、用户场景、风险边界、验收标准和初始优先级。labelyourdata+2

常用工具包括 PRD 文档、问题陈述模板、会议纪要、工单系统、以及知识库检索工具。
上下游衔接的关键是：下一阶段不能直接进入实现，必须先把目标改写成可执行的规范或 spec。reddit+1

阶段二：规范与澄清

这一阶段的目标，是把模糊需求变成机器和人都能读懂的结构化约束。产出物通常是 spec、约束文件、术语表、验收条件、边界条件、非功能要求，以及需要澄清的问题列表。epam+1

常用工具包括 OpenSpec 一类 spec-driven 工具、文档模板、评论审阅、RAG 检索、以及需求评审流程。augmentcode+2
这里最重要的衔接规则是：没有澄清完的需求不进入计划阶段，否则后面只会把歧义放大。robearlam+1

阶段三：方案设计

这一阶段的目标，是把“要做什么”变成“怎么分层、怎么协作、怎么验证”。产出物包括架构图、模块边界、数据流、状态流、权限模型、错误处理策略、以及风险清单。developer.harness+2

工具通常是架构文档、图表工具、设计评审、RAG 检索历史案例、以及对现有代码库的静态分析。
上下游衔接上，方案设计的输出要能直接转成计划和任务，而不是只停留在讨论层面。robearlam+1

阶段四：计划拆解

这一阶段的目标，是把设计变成可执行的任务序列，并明确依赖关系、负责人、验收方式和优先级。产出物通常是 implementation plan、task list、依赖图、里程碑、以及阶段性回归点。epam+1

常用工具包括项目管理系统、issue tracker、task board、以及 spec-driven workflow 工具。
如果是多人参与，这一步尤其关键，因为它决定了谁做什么、先做什么、以及哪些任务可以并行。developer.harness+1

阶段五：实现开发

这一阶段的目标，是把计划转成代码、配置、提示词、工作流和脚本。产出物包括实现代码、配置文件、prompt 模板、工具封装、子代理任务、以及必要的单元测试和集成测试。triare+1

常用工具通常是 Cursor、Claude Code、Superpowers 这类 agent 开发工具，再配合仓库内的 spec、plan、rules、AGENTS 文件作为约束。youtubeaiagentstore+2
上下游衔接要求是：实现必须严格对齐计划，不能边写边改目标；如果目标变了，应该回到规范和计划阶段更新，而不是在代码里悄悄漂移。robearlam+1

阶段六：验证测试

这一阶段的目标，是证明实现满足规范，并且没有破坏既有功能。产出物包括测试用例、评测集、回归样本、lint 结果、截图或日志证据、以及通过/失败判定记录。triare+2

常用工具包括单元测试、集成测试、端到端测试、静态检查、行为回放、以及 AI 特有的 prompt testing 和 behavior regression checks。orq+1
上下游衔接上，验证失败不能直接合并，应该回到实现阶段修复；如果失败暴露的是规范缺陷，则应该回到 spec 或 plan 重新修订。triare+1

阶段七：发布部署

这一阶段的目标，是把通过验证的版本安全地送到目标环境。产出物包括 release note、部署包、变更记录、回滚方案、以及发布审批记录。developer.harness+1

常用工具包括 CI/CD、发布编排、环境变量管理、灰度发布、审批流、以及监控告警。
上下游衔接里，部署不是终点，而是进入生产反馈循环的入口，因为 AI 系统上线后还要持续观察行为偏差和成本变化。orq+2

阶段八：监控迭代

这一阶段的目标，是基于真实运行数据持续修正系统。产出物包括日志分析、失败案例、性能指标、成本指标、用户反馈、问题归档、以及下一轮迭代项。orq+1

常用工具包括可观测性平台、trace、metrics、prompt/behavior 评估、问题归档系统，以及 spec/decision 的版本化管理。
上下游衔接上，监控结果应该反向喂给 spec、plan、tests 和 harness，而不是只停留在运维层。robearlam+1

多人协作

多人参与时，最重要的不是“大家都能干”，而是大家都按同一套事实工作。这意味着必须有统一的 spec、统一的目录结构、统一的状态机、统一的测试门禁、统一的命名和版本规则。epam+1

比较有效的做法是：

一份当前生效的 spec，作为单一事实源。
一份明确的 plan，作为任务分配依据。
一份 decisions/iterations 记录，保留历史变化。
一套 quality gate，保证所有人用同一标准判断通过与否。
一套 run-state 或 workflow state，避免多人同时改同一阶段的内容。epam+1

一致性机制

要保证一致性，核心是把“共识”从人脑搬到仓库和流水线里。最关键的是：同一事实只在一个地方定义，其他地方只能引用。reddit+2

我建议至少加这几种机制：

规范一致性检查，防止 spec、plan、code 互相打架。
术语表和 ID 系统，防止多人对同一概念有不同叫法。
分阶段门禁，防止未完成的内容进入下一阶段。
回归样本库，防止老问题在新迭代里被改坏。
运行状态文件，防止多人并发时推进错阶段。robearlam+1

最小可落地结构

如果你要把这套流程直接落到仓库里，最小结构可以是：

GOAL.md：项目目标与范围。
SPEC.md：当前生效规范。
ARCHITECTURE.md：系统结构与边界。
PLAN.md：当前迭代计划。
ITERATIONS.md：每轮改动记录。
QUALITY.md：测试与门禁标准。
DECISIONS.md：关键决策记录。
HARNESS.md：反馈循环与执行规则。
AGENTS.md：agent 工作规范。epam+1

这套结构的价值不在于“文件多”，而在于它把项目从“人对人沟通”变成“人和 agent 都能遵守的系统”。robearlam+1

如果你愿意，我下一步可以把这套流程进一步整理成一张端到端流程图，把每个阶段的输入、输出、责任人、工具和门禁全部画清楚。

User

提问

两个问题： 1. 按照上面的流程，完全可以使用cursor/claude code+ opensped等工具组合完成所有开发任务吗？其中如果涉及有rag、dify这样的环节呢 2. 上面的操作，其实完全可以通过openclaw来出触发和跟踪调用，在spec都明确的前提下，我的理解对吗。

Perplexity

模型回复

是的，你的理解大方向是对的：在 spec 已经明确的前提下，很多开发工作都可以通过 Cursor、Claude Code、OpenSpec、OpenClaw 这类工具组合来完成，尤其适合“把规范推进成实现”的过程。aimagicx+2
但它们不是“完全替代所有环节”的万能工具，而是分别覆盖不同层：有的偏编辑与交互，有的偏多文件执行，有的偏 spec 流转，有的偏触发、跟踪和持续代理。skywork+2

1. 工具组合能不能覆盖全部开发任务

可以覆盖大部分实现型任务，但前提是你的系统已经把问题拆成了清晰的 spec、任务边界、验收标准和测试门禁。Spec-driven 工具本身就是为了让 agent 依照规范生成实现、测试和文档，而不是让人从零散聊天里临时指挥。github+2

更准确地说：

Cursor 更适合高频编辑、局部修改、快速查看和 inline 交互。nxcode+1
Claude Code 更适合跨文件重构、执行命令、读测试输出、做结构性修改。reddit+2
OpenSpec 更适合把变更变成规范化流程，管理 proposal、spec、archive 之类的状态流。intent-driven+2

所以它们可以组成一个很强的开发栈，但“全部开发任务”仍然要依赖底层仓库、测试框架、CI/CD、代码执行环境和人工审批点。developer.harness+2

2. 遇到 RAG / Dify 怎么处理

如果项目里有 RAG 或 Dify，这些就不只是“代码任务”，而是系统能力任务，需要把“检索、索引、评估、提示词、编排、权限、数据源”一起纳入架构。triare+2

这种情况下，AI 开发工具的角色是：

用 Cursor / Claude Code 去实现 RAG 服务、检索链路、评测脚本、配置和前后端接入。aimagicx+1
用 OpenSpec 去规范 RAG 的输入输出、文档边界、验收条件和变更记录。github+1
用 Dify 这类平台去承载 workflow、retrieval、agent 编排、模型管理等现成能力，尤其适合需要快速拼装 AI 应用的场景。x+1

也就是说，RAG/Dify 不应该被看成“工具外的例外”，而应该看成系统中的一个子域：它照样要有 spec、测试、监控和回归。orq+1

3. OpenClaw 能不能做触发和跟踪

你的理解也基本正确：如果 OpenClaw 的定位是持续运行的 agent / 任务触发 / 追踪层，那么它很适合作为“流程发动机”或“事件协调器”。公开资料里对 OpenClaw 的描述也偏向持续工程助手、任务触发、子代理调度、日志/追踪一类能力。sparkco+1

在这个模式下：

OpenClaw 负责“什么时候启动、触发谁、记录什么、下一步交给谁”。skywork+1
OpenSpec 负责“这次要改什么、规范是什么、何时算完成”。intent-driven+1
Cursor / Claude Code 负责“具体怎么改、怎么重构、怎么修复、怎么验证”。nxcode+2

所以它更像一个控制平面，而不是单纯的代码生成器。sparkco+1

4. 但要注意一个前提

前提是：spec 必须真的足够清楚，而且“状态机”必须足够稳定。
如果 spec 只是大致方向，而没有明确输入、输出、验收、回滚条件，那 OpenClaw 这类触发跟踪工具只会加速混乱，而不是加速交付。robearlam+1

真正能跑通的方式是：

OpenSpec 定义变更。
OpenClaw 监听事件并分派任务。
Claude Code / Cursor 执行具体实现。
测试与 CI 判定通过。
结果回写 spec / iteration / archive。skywork+2

5. 结论

所以你的判断可以改写成一句更精确的话：

**在 spec 明确的前提下，Cursor / Claude Code / OpenSpec / OpenClaw 完全可以组成一个“开发执行 + 变更治理 + 任务触发”的闭环；如果项目里还有 RAG / Dify，它们也应该作为同一套架构中的子系统被规范化管理。**aimagicx+3

如果你愿意，我下一步可以直接给你画出一张**“OpenSpec + OpenClaw + Cursor/Claude Code + Dify/RAG”的完整责任分层图**，并把每一层对应的文件、触发器、产出物和门禁列出来。

User

提问

好的给我下一步的内容，按照1人推动，可以落地的思路

Perplexity

模型回复

可以，1 人推动时最实用的方式不是做“全自动大系统”，而是做一个单人可控的半自动流水线：你负责定义目标、验收和关键决策，工具负责拆解、执行、验证、跟踪与回写。
核心思想是把工作分成“人必须做的少数步骤”和“工具可以连续跑的多数步骤”，这样一个人也能推动较大的 AI 项目落地。

单人闭环

最推荐的单人流程是：目标 → spec → plan → execute → verify → archive → next iteration。
在这个流程里，OpenSpec 负责把需求固定成可追踪的变更，Claude Code 负责多文件执行，Cursor 负责局部编辑和检查，OpenClaw 负责触发、记录和持续跟踪。

你可以把自己定义成“项目控制者”，而不是“逐行写代码的人”。
你的任务是让每一轮都满足三个条件：输入清楚、输出可验、失败可回退。

1. 目标定义

这一阶段只做一件事：把要做的东西写成一个短而硬的目标说明。
产出物是 GOAL.md 或 SPEC.md，里面要有业务目标、范围、非目标、成功标准、风险边界和验收标准。

单人场景下，最重要的是不要一开始就开工写代码，而是先把“什么算做完”写清楚。
否则后面 OpenClaw 或 Claude Code 只会加速不一致，而不会加速交付。

2. 方案拆解

这一阶段把目标拆成几块：知识、流程、执行、验证。
如果项目涉及 RAG，就把检索源、索引方式、召回目标、提示词模板、评测集单独列出来；如果涉及 Dify，就把 workflow、agent、模型、工具连接、权限与环境变量列出来。

产出物通常是 ARCHITECTURE.md、PLAN.md、任务列表和依赖图。
这一阶段最适合你自己来做，因为它决定了后续工具到底怎么跑、边界在哪里。

3. 执行开发

这一阶段主要交给 Claude Code 和 Cursor。
Claude Code 更适合让它按任务清单跨文件改造、跑命令、修测试、做多步执行；Cursor 更适合你自己边看边改、快速查看 diff、处理局部问题。

在单人流程里，建议把实现拆成小块，每次只让工具完成一个可验证闭环。
不要一次给太大任务，否则上下文会变脏，修复成本会迅速升高。

4. 验证门禁

这一阶段是整个单人闭环里最重要的部分。
每个任务都要有明确测试命令、通过标准、失败处理方式，以及是否允许自动修复的规则。

产出物包括测试结果、回归样本、日志、截图、变更说明和 QUALITY.md 里的记录。
如果是 RAG 或 Dify，还要额外加检索质量、回答质量、工具调用成功率、workflow 成功率这些验收项。

5. 触发与跟踪

你的理解基本正确：OpenClaw 很适合承担“触发 + 跟踪 + 持续运行”的角色。
它更像一个事件驱动的调度器：当 spec 或状态发生变化时，它负责发起任务、记录进展、观察结果、推进下一步。

单人场景下，OpenClaw 最有价值的地方不是“替你决定项目方向”，而是把流程自动跑起来。
你只需要在关键节点确认方向、审批变更、处理异常，它就可以替你盯住任务状态和链路追踪。

6. 一致性保障

单人做项目最大的优势是没有多人冲突，但最大的风险是“你自己今天和明天不一致”。
所以一定要把一致性写进仓库，而不是写在脑子里：当前 spec、当前计划、当前迭代记录、当前质量标准、当前决策，都必须有唯一版本。

最有效的做法是：

SPEC.md 作为单一事实源。
PLAN.md 作为当前执行计划。
ITERATIONS.md 记录每轮改了什么。
DECISIONS.md 记录为什么这么定。
QUALITY.md 记录测试和门禁。
HARNESS.md 记录触发、回收、修复规则。

7. 单人推荐分工

如果只有你一个人，我建议这样分工：

阶段	你负责	工具负责
定义	目标、范围、验收	文档整理、上下文检索
设计	架构、边界、流程	方案草稿、历史对照
实现	关键判断、代码审阅	Claude Code / Cursor 执行
验证	接受或拒绝	测试、回归、修复建议
运行	决策与升级	OpenClaw 触发、追踪、回写

这样你不会被琐碎实现吞掉，而是始终站在系统控制面。
这也是单人推动复杂 AI 项目时最现实、最可持续的方式。

8. 一个可落地版本

如果你要马上开始，我建议直接用这个最小闭环：

写 SPEC.md，只定义一个子问题。
写 ARCHITECTURE.md，把 RAG / workflow / agent 的边界画清楚。
写 PLAN.md，拆成 3 到 5 个任务。
让 Claude Code 执行第一轮。
用 Cursor 做局部审查和修补。
用测试和回归判定是否通过。
用 OpenClaw 跟踪状态并触发下一轮。
把结果写回 ITERATIONS.md 和 DECISIONS.md。

如果你愿意，我下一步可以直接给你输出一份**“单人推进版 AI 项目仓库模板”**，把每个文件该写什么、每轮怎么跑、OpenClaw 怎么接、Claude Code 怎么接，整理成可直接复制的目录结构和流程卡。

User

提问

说好的：直接给你画出一张**“OpenSpec + OpenClaw + Cursor/Claude Code + Dify/RAG”的完整责任分层图**，并把每一层对应的文件、触发器、产出物和门禁列出来。这个内容呢

Perplexity

模型回复

可以，我把这张“OpenSpec + OpenClaw + Cursor/Claude Code + Dify/RAG”责任分层图直接给你落成文字版，按控制面 / 编排面 / 执行面 / 知识面 / 验证面来拆。OpenClaw 更偏系统级工作流与触发编排，Cursor/Claude Code 更偏 IDE/终端里的具体实现，Dify 更偏 RAG 与应用编排平台，OpenSpec 则是规格与变更治理层。

总体分层

1. 规格层

这一层负责“做什么、为什么做、做到什么算完成”。OpenSpec 放在这里，产出物是 GOAL.md、SPEC.md、PLAN.md、DECISIONS.md、ITERATIONS.md，它们定义唯一事实源、变更边界和阶段状态。

2. 触发层

这一层负责“什么时候启动、谁来跑、跑到哪一步停”。OpenClaw 放在这里，做事件监听、任务触发、状态跟踪、审批门禁和日志回写，适合把工作流变成可持续运行的系统。

3. 执行层

这一层负责“具体怎么改代码、怎么修 bug、怎么跑测试”。Cursor 和 Claude Code 放在这里，Cursor 更适合交互式局部编辑，Claude Code 更适合跨文件、多步骤、带命令执行的任务。

4. 知识层

这一层负责“找什么知识、用什么上下文、如何回答业务问题”。Dify 或自建 RAG 放在这里，承载文档检索、知识库问答、流程节点、模型接入和可视化编排。

5. 验证层

这一层负责“怎么判断对不对、能不能合并、是否回归”。它包括单测、集成测、E2E、RAG 评测、workflow 评测、日志检查、截图检查和门禁规则。

责任分层图

┌──────────────────────────────────────────────┐ │                OpenSpec 层                  │ │  目标 / 范围 / 约束 / 变更 / 归档 / 决策     │ │  文件：GOAL, SPEC, PLAN, DECISIONS, ITER...  │ └──────────────────────────────────────────────┘                      ↓ ┌──────────────────────────────────────────────┐ │                OpenClaw 层                  │ │  触发 / 调度 / 跟踪 / 审批 / 状态机 / 回写   │ │  事件：spec 变更、定时、手动 run、失败重试    │ └──────────────────────────────────────────────┘                      ↓ ┌──────────────────────────────────────────────┐ │        Cursor / Claude Code 执行层           │ │  拆任务 / 改代码 / 跑命令 / 修测试 / 重构     │ │  输出：代码、补丁、测试、文档、修复记录       │ └──────────────────────────────────────────────┘                      ↓ ┌──────────────────────────────────────────────┐ │             Dify / RAG 知识层                │ │  检索 / Chunk / Embedding / Workflow / Tools │ │  输出：上下文、答案、检索证据、流程节点       │ └──────────────────────────────────────────────┘                      ↓ ┌──────────────────────────────────────────────┐ │                验证门禁层                    │ │  单测 / 集成测 / E2E / 评测 / 回归 / 监控     │ │  输出：通过 / 失败 / 回滚 / 进入下一轮        │ └──────────────────────────────────────────────┘

这个图的关键是：OpenSpec 负责真相，OpenClaw 负责推进，Cursor/Claude Code 负责实现，Dify/RAG 负责知识与流程能力，验证层负责裁决。

每层文件

OpenSpec 层文件

GOAL.md：项目目标、范围、非目标。
SPEC.md：当前有效需求与行为定义。
PLAN.md：本轮迭代计划。
DECISIONS.md：关键设计决策。
ITERATIONS.md：每轮改动、问题、风险、下一步。

OpenClaw 层文件

workflow.yaml 或 workflow.json：触发与步骤定义。
state.json：当前任务状态。
gates.yaml：审批与阻断条件。
audit.log：运行记录与事件历史。

Cursor / Claude Code 层文件

AGENTS.md：工作规则。
tasks/*.md：单任务说明。
patches/：补丁与修改记录。
tests/：对应测试。

Dify / RAG 层文件

knowledge/：文档源。
retrieval_config.yaml：检索参数。
prompts/：提示词模板。
workflow_app.json 或平台导出配置。
evals/：RAG 评测集。

验证层文件

QUALITY.md：质量门槛。
test_plan.md：测试计划。
eval_cases.md：评测样本。
monitoring.md：运行监控标准。

触发器设计

OpenClaw 触发器

spec_changed：SPEC/PLAN 更新后触发实现任务。
test_failed：测试失败后触发修复任务。
schedule：定时回归、定时索引、定时清理。
manual_run：人工确认后启动高风险流程。
archive_ready：任务完成后归档和总结。

OpenSpec 触发点

需求变化。
约束变化。
验收标准变化。
风险升级。
归档条件满足。

Dify / RAG 触发点

新文档入库。
数据源更新。
索引重建。
Workflow 节点切换。
模型或 prompt 变更。

Cursor / Claude Code 触发点

任务单进入 ready 状态。
需要局部重构。
测试失败需要修复。
需要人工 review 的 patch。

产出物流转

一条比较标准的流转链是：

SPEC.md 定义本轮要做什么。
PLAN.md 拆成可执行任务。
OpenClaw 读取状态并触发任务。
Claude Code / Cursor 具体实现和修复。
Dify/RAG 提供知识检索、上下文补全或 workflow 节点。
测试和评测层裁决是否通过。
结果写回 ITERATIONS.md、DECISIONS.md、audit.log。

这条链的核心是：每个层只对自己的产出负责，不跨层乱写事实。

门禁规则

OpenSpec 门禁

需求未澄清，不进入计划。
计划未定义验收，不进入实现。
变更未记录，不允许归档。

OpenClaw 门禁

高风险动作必须人工确认。
连续失败超过阈值，暂停自动推进。
状态不一致时，禁止继续下游执行。

Cursor / Claude Code 门禁

没有测试就不能合并。
实现必须对齐 spec。
失败后优先修测试或 spec 漂移，再修代码。

Dify / RAG 门禁

新知识入库前要经过清洗与版本化。
检索源必须可追溯。
回答必须能追到证据或来源。

验证层门禁

功能测试通过。
回归样本不退化。
关键路径指标不下降。
生产监控异常不超过阈值。

单人落地方式

如果是你一个人推动，建议只保留一个主入口：OpenSpec 作为事实源，OpenClaw 作为推进器，Claude Code 作为主执行器，Cursor 作为人工校验器，Dify/RAG 作为知识与应用子系统。

最小落地方式可以这样：

先写 SPEC.md 和 PLAN.md。
再写 workflow.yaml 给 OpenClaw。
然后让 Claude Code 按任务跑。
Cursor 用来审 diff、补局部问题。
Dify/RAG 只在确实有知识检索或流程编排需求时接入。
所有结果都回写到 ITERATIONS.md 和 DECISIONS.md。

如果你愿意，我下一步可以把这张图继续展开成一份**“仓库目录结构 + 文件模板 + 工作流 YAML + 状态机”**的可直接开工版本。

AI产品研发思路

传统系统围绕 LLM 重构的切入点与思路

一、找切入点的判断标准

二、五个核心改造角度

三、四步落地路线

四、常见坑

先找切入点

用什么视角看

重构的顺序

迁移的分层

组织和治理

一个实用判断

推荐路线

应该长什么样

三种能力分工

设计原则

怎么选架构

老系统改造建议

它们各自的角色

它们适合放在哪一层

在老系统改造里怎么用

设计原则

总体结构

阶段一：问题定义

阶段二：规范与澄清

阶段三：方案设计

阶段四：计划拆解

阶段五：实现开发

阶段六：验证测试

阶段七：发布部署

阶段八：监控迭代

多人协作

一致性机制

最小可落地结构

1. 工具组合能不能覆盖全部开发任务

2. 遇到 RAG / Dify 怎么处理

3. OpenClaw 能不能做触发和跟踪

4. 但要注意一个前提

5. 结论

单人闭环

1. 目标定义

2. 方案拆解

3. 执行开发

4. 验证门禁

5. 触发与跟踪

6. 一致性保障

7. 单人推荐分工

8. 一个可落地版本

总体分层

1. 规格层

2. 触发层

3. 执行层

4. 知识层

5. 验证层

责任分层图

每层文件

OpenSpec 层文件

OpenClaw 层文件

Cursor / Claude Code 层文件

Dify / RAG 层文件

验证层文件

触发器设计

OpenClaw 触发器

OpenSpec 触发点

Dify / RAG 触发点

Cursor / Claude Code 触发点

产出物流转

门禁规则

OpenSpec 门禁

OpenClaw 门禁

Cursor / Claude Code 门禁

Dify / RAG 门禁

验证层门禁

单人落地方式