Claude Code 与 Cursor 能否从 SaaS 底座推导架构规范？
SaaS 项目底座（Boilerplate）的质量，会直接影响 Claude Code、Cursor 等 Coding Agent 能否在缺少冗长 Prompt 的情况下理解既有架构。它们是否可以不再依赖人工逐项规定 Pundit 权限处理、Solid Queue 异步任务用法，而是从代码本身把握架构逻辑？
验证以专为 Agent 优化、面向生产的 Rails 底座 Rails Baseline 为对象。新的 Claude 会话只收到项目压缩包和一项产品需求：构建具备反馈功能的看板系统，没有附带一整套架构说明。
具体需求包括：用户创建看板、游客留言反馈、基于订阅等级限制看板数量上限，以及为付费用户提供 CSV 导出。
测试期间未提供任何架构指引：没有指定使用 Current.account 执行租户隔离，没有要求使用 Pundit 进行权限校验，没有说明通过 Entitlements 模块实施功能限制，也没有强调 URL 必须遵循 HasPublicId 公有 ID 模式。验证重点在于 Agent 能否通过研读现有代码库，自主归纳这些未被明说的规范。
结果显示，Agent 对既有模式表现出显著的模式识别能力，过程也出乎意料地顺畅。创建记录时，它自动将记录关联至 account；权限控制无缝沿用既有 Policy 模式；计费逻辑依据预设的 plan-limit 边界管控看板数量，没有直接修改数据库；公有 URL 也正确应用了既有的 ID 转换约定。
过程中仅出现一次 Policy-scope 偏差，但 Agent 在自检环节自行完成了修正。它生成的不只是看似整洁的代码，还能与工程规范保持对齐，避免破坏账号隔离，这种表现远优于表面整洁却无视账号隔离的代码。
此次验证表明，构建 AI 工作流或内部工程底座时，相比继续追求完美 Prompt，更应关注打造自解释性强的工程规范。当代码库逻辑自洽且模式统一时，Agent 无需步步引导，也能遵循既定路径。
测试也暴露出一处短板：CSV 导出涉及文件存储，但 Agent 无法确定具体应采用 Active Storage 还是 S3，因而陷入停滞。这印证了底座标准化还需进一步覆盖深层 IO 决策。
全部回复 （4）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
给它看个 Controller 样板，它确实能自动对齐规范，但更关键的是，当底层底座（如 Rails Baseline）在租户隔离、权限逻辑和多租户隔离等隐性规范上都有明确模式时，Agent 甚至不需明确提示就能自主识别——比如在代码中自动识别 Current.account 的使用，直接关联到租户记录，而无需手动指定 Pundit 权限校验或 Entitlements 模块的存在。不过，在涉及文件存储场景（如 CSV 导出）时，Agent 仍需依赖底座对 Active Storage 或 S3 的明确约定，否则会因为缺乏具体方案而停滞。
直接把 Rails Baseline 的压缩包试用后，效果确实稳定且逻辑清晰，特别是当新项目需求涵盖反馈功能、租户隔离（如通过 Current.account 实现）以及多租户权限（如 Pundit 模式）时，Agent 完全能够自主解析架构逻辑，无需冗长的指令细节。我用“构建具备反馈功能的看板系统”这一单一需求，并特别排除了对 Entitlements 模块或 HasPublicId 模式的明确提及，结果却能准确识别出租户隔离、权限校验（如 Policy 继承）、计费边界（通过 plan-limit 约束）以及 URL 公有化规则，仅在 CSV 导出场景上一度因不明确选择 Active Storage 还是 S3 而暂停，但这也暴露了底座中 IO 决策层面的标准化需求。
把项目目录结构（比如
app/policies/、app/serializers/、app/services/这些 Rails 标准分层）整理成.cursorrules的 JSON 格式，AI 就能直接“读懂”哪些文件对应权限（Pundit）、哪些是异步任务（Solid Queue），甚至自动匹配Current.account的租户隔离逻辑，而不需要你一句句解释“用户权限校验放在 Policy 里”。比如，当你写“构建看板系统”时，它会主动在app/policies/board_policy.rb里生成规则，而不是硬塞到 Prompt 里“记得用 Pundit”。配置规则确实比死磕 Prompt 管用，但偶尔还是会写出逻辑断层的代码，比如完全忽略了
Current.account这种核心租户隔离机制，直接在数据库里操作记录。不过，如果底座设计足够自洽，比如 Rails Baseline 这种专为 AI 优化的生产级框架，模型至少能自动识别并遵循现有的account关联逻辑，而不是硬生生造出一堆破坏隔离的代码。当然，也不是万能的——比如在 CSV 导出这类场景下，如果底座没有明确标注是用 Active Storage 还是 S3，它还是会卡壳，暴露出深层 IO 决策的标准化问题。