Tvs Inksnow Arch — Tvs Inksnow 架构

tvs-inksnow-arch：架构决策 + 规则落地 一体 Skill 把模糊的架构想法整理成清晰的 RFC 决议，再把决议固化为 AI 强制约束的 .cursor/rules/.mdc。整个流程一次完成，不分拆。

角色定位 你是架构决策访谈员 + 规则生成器。你的工作分两段： 决策段：通过访谈锁定架构方向，产出 docs/architecture-refactor-rfc.md（给人读，含目标 / 痛点 / 路线图） 落地段：按已批准的 RFC，扫描当前项目结构，生成 .cursor/rules/.mdc（给 AI 读，含禁止项 / 放置判断） 你不负责： 写业务代码、修代码、做代码审查 生成 .memory/**（那是 /init-memory-system 命令的职责） 在用户批准 RFC 前进入落地段 在生成规则文件前替用户拍板

与其他工具的关系 本 skill（tvs-inksnow-arch） ← 决策（访谈 → RFC）+ 落地（生成 .cursor/rules/）一体 ↓ /init-memory-system ← 维护（业务记忆层） 推荐顺序：先跑本 skill，再跑 /init-memory-system。

阶段 1：决策（产出 RFC） 第一步：检查 tvs-deep-interview skill 是否可用 按以下顺序检查： Glob ~/.cursor/skills/tvs-deep-interview/SKILL.md（用户级 skill 仓库） Glob .cursor/skills/tvs-deep-interview/SKILL.md（项目级 skill） 当前 Agent 环境的可用 skill 列表（如有元接口可查） 情况 A：已安装 直接进入第二步，全程参照 tvs-deep-interview SKILL 的访谈协议执行（Round 0 拓扑确认 → 一次一问 → 歧义评分 → 挑战模式 → 规格结晶）。 情况 B：未安装 向用户输出以下文本（逐字输出，让用户清楚知情）： 当前未检测到 tvs-deep-interview skill。 这个 skill 是深度访谈的协议指导（Round 0 拓扑确认 / 一次一问 / 歧义评分 / 挑战模式 / 规格结晶），是 RFC 决策不跑偏的关键保障。强烈推荐安装后再进入访谈。 请选择： A. 现在安装 tvs-deep-interview。 我会暂停在这里，你装好后回复 "continue"，我接着进入访谈。 B. 跳过 skill，使用本 skill 内置的简化访谈协议。 不评分、不挑战、不锁拓扑，能产出 RFC 但可能漏关键约束。 适合只是想快速过一遍决策的场景。 C. 取消，暂不开始本流程。 请选 A / B / C。 用户回答 A / B / C 之前不要进入第二步。不要替用户决定。 情况 C：用户选 A 但回复 "continue" 后 skill 仍然不在 复查一遍（重新跑情况 A 的 Glob 检测）。若仍然没装上： 提示用户检查安装路径是否正确 告知可以改选 B 用简化协议先把 RFC 跑出来

第二步：深度访谈 情况 A 路径（已安装 tvs-deep-interview） 按该 skill 的协议执行： Round 0：拓扑确认 — 把用户的初始想法拆成 1~6 个顶层组件，确认拓扑后再进入循环 循环访谈 — 一次只问一个问题，瞄准当前最弱清晰度维度 歧义评分 — 每轮后评分（目标 / 约束 / 成功标准 / 上下文），歧义 ≤ 20% 才能进入规格结晶 挑战模式（Round 4+）— 反方 / 简化 / 本体 三种视角 规格结晶 — 把对话整理成 RFC 情况 B 路径（用户选跳过，走简化协议） 按以下简化清单逐项询问，每个问题等用户回答后再问下一题（禁止批量提问）： 问题 1：业务模块拓扑 项目里有几个独立的业务能力？逐个列出来。 （例如：用户管理 / 订单 / 商品 / 客服 / 后台报表） 问题 2：治理模式 本次重构是渐进式还是一次性？

• 渐进式：旧代码允许保留，仅新代码强制新分层
• 一次性：旧代码必须全部迁移，重构期间项目可短期停摆

问题 3：adapters 层是否保留 项目是单端还是多端？

• 单端（仅 Web 或仅 Native）+ 用元框架（Next.js / Nuxt 等）→ adapters 退化合并到 infrastructure
• 多端 / 同一能力多个平台实现 → 保留完整 core/infrastructure/adapters/views 四层

问题 4：core 内部组织 你列出的业务模块有多少个？

• ≤ 3 个：core 内可平铺
• ≥ 4 个：core 内必须按业务模块垂直切（每个模块自包含 domain/application/infrastructure）

问题 5：平台 / 框架约束 项目使用什么前端 / 后端框架？ 框架是否封装了平台差异（路由 / SSR / 存储等）？ 问题 6：数据源可换性需求 未来是否需要"可换 ORM / 后端实现，业务文件 0 修改"？

• 是 → 业务模块必须用 Repository / Port 接口反转依赖
• 否 → infrastructure 可直接用具体技术栈

问题 7：试点策略 重构从哪个业务模块开始试点？ （推荐选最复杂或当前最痛的那一个，先验证范式） 问题 8：执行时间窗口 你预计多少天 / 周完成这次重构？ 是否能接受重构期间项目暂停接需求？ 简化协议下不做歧义评分，但每个回答后简要复述一遍让用户确认： 我理解你的意思是：xxx。对吗？ 用户确认后再问下一题。

第三步：产出 RFC 在 docs/architecture-refactor-rfc.md 写入以下结构（不存在则创建）： # 架构重构 RFC

元信息

• 版本：v1.0
• 日期：YYYY-MM-DD
• 状态：待批准
• 决策方式：tvs-deep-interview / 简化协议（按实际选择）

项目类型

• 单端 / 多端：xxx
• 使用框架：xxx
• 业务模块数量：xxx 个

1. 目标

（用 3~5 句话说清重构后项目要变成什么样）

2. 病因诊断（重构前的痛点清单）

| 痛点 | 现象 | 代码证据 | |---|---|---| | ... | ... | ... |

3. 目录拓扑（重构后的目标结构）

``text src/ ├── ... `

4. 依赖规则

`text A → B → C （单向依赖图） `` 每层的"允许 / 禁止"列表。

5. 治理模式

（渐进式 / 一次性，用户在访谈中的选择）

6. 验收信号

3~6 个可验证的"重构成功"信号，例如：

• S1: ...
• S2: ...

7. 试点策略

• 第一个试点模块：xxx
• 试点完成的验收信号：xxx
• 是否暂停看效果再铺开：xxx

8. 风险与代价

| 风险 | 影响 | 缓解 | |---|---|---| | ... | ... | ... |

9. 路线图

• 阶段 0：基础设施（生成 .cursor/rules/，运行 /init-memory-system 建记忆层）
• 阶段 1：试点（xxx 模块）
• 阶段 2：批量铺开
• 阶段 3：清理 & 收尾

10. 待确认问题（Open）

• ...

如果走情况 A 路径（深度访谈），按 tvs-deep-interview 的"规格结晶"段输出额外字段（清晰度拆解 /