AI 辅助研发：真实项目中的案例、习惯与规则沉淀（偏工程化）
摘要 ：本文记录在「已投产业务系统」里把人机协作跑顺的一类做法：如何用 AI 加速定位与实现，同时用规则约束降低幻觉与返工。后半部分摘录本仓库
.cursor/rules与项目 Skill 中的要点，便于读者迁移到自己的 Cursor / 团队规范中。
关键词：Cursor、Rules、Spec 驱动、SpreadJS、人机协作、存量系统
声明：文中案例为「场景类型」归纳，便于读者对照自己的业务替换细节；规则条文以仓库内实际文件为准，此处为导读式摘录。
一、我为什么写这篇
生产系统里用 AI，最怕两件事：一是模型「想当然」改错分层或漏边界；二是对话漂移，改着改着偏离原始目标。
本仓库通过 架构导引 Skill + SDD 四阶段规则 + 交互原则 + Git/测试/安全约束 ，把「能做什么」和「必须先满足什么」写进上下文，实践下来对 稳定产出 帮助很大。下面先写使用习惯与感悟，再写规则精华，方便一篇读完就能抄作业。
二、典型 AI 使用案例（可按类型迁移）
2.1 需求澄清与方案取舍（先于写代码）
场景 ：口头需求模糊，例如「提交前要再多校验一档」「客户页某个表格联动不对」。
做法 ：先让 AI 复述约束与成功标准 ，必要时补充「入口路由 / API / 状态枚举」；明确拒绝「无依据的大改」。
收益：减少 XY 问题（用户要解决 X，却描述成手段 Y），避免一上来就改错文件。
2.2 领域代码快速锚定（SpreadJS + 委托单流程）
场景 ：表格绑定、监听、getData/setData 链路长，单靠搜索关键词效率低。
做法 ：打开项目 Skill（项目skill）里给的 目录与流程锚点 ：保存、提交、客户提交、PE 审核各自对应的前后端路径；再让 AI 结合 Lean_docs 中长文做细节。
收益：从「在整个前端里盲搜」变成「按数据流分段精读」，改造字段或校验时不易漏链路。
2.3 后端分层与接口改造（Controller → Service → Repository）
场景 ：新增或调整 ELN 相关接口。
做法 ：先对照 Skill 中的分层表，约束 AI 禁止 在 Controller 堆业务、禁止 拼接 SQL；Oracle 参数形式等与仓库约定一致。
收益：改动集中在 Service/Repository，评审路径清晰，回归范围可控。
2.4 Spec → Plan → Tasks → Implement（功能性变更）
场景 ：必须可验收、可追踪的迭代（关联 FR / CHG）。
做法 ：先有 Spec / 变更说明，再拆 Plan 与 Tasks；实现阶段 TDD 或至少按 AC 补测试 ，代码注释带 @spec。
收益：AI 生成代码时有「单一事实来源」，减少「写了但不知道验收什么」。
2.5 工程化收尾（Lint、提交、结构性变更）
场景 ：前端改动提交；或动了目录/入口等结构性变更。
做法 ：前端提交前按规范跑 ESLint / Prettier；结构性变更同步 CLAUDE.md 并跑仓库提供的同步检查脚本。
收益：CI 与人脑记忆解耦，协作成本下降。
2.6 数据结构与 SQL（结合专用 Skill）
场景 ：要对 Oracle 表结构写 SQL 或生成实体。
做法 ：使用「查表结构」类 Skill，让产出 贴合真实库表 ，避免 AI 臆造字段名。
收益：少一轮「跑不通再改字段」的往返。
三、我总结出的「有效行为」清单
- 上下文给够，但边界写清：仓库路径、相关 Spec ID、复现步骤、期望与非目标（例如「本次不改模板格式」）。
- 先对齐目标再允许改代码：对照 conversation 规则里的「直接执行」与「深度交互」------简单任务快进，高风险任务先对齐约束。
- 让规则替你重复唠叨：把 Spec、分层、提交规范放进 Rules / Skill，减少每轮对话手动复读。
- 小步可验证：宁可多几次提交，也不要单次巨型 diff；Implement 阶段前置推送安全快照的做法尤其适合多人协作。
- 触碰存量才补课：不动无关存量；碰到旧代码再补「简化 Spec + 变更 Spec」，成本低、纪律严。
四、感悟（简短但真实）
- AI 更像「高带宽实习生」：快、勤、敢写，但需要你用 Spec、架构图式索引和代码约束告诉它「何谓正确」。
- 规则是护栏，不是形式主义 ：在投产系统里，规则换来的是 可回滚、可对账、可交接。
- 人与模型分工 ：人负责目标、优先级与验收；模型负责检索、草稿与局部实现；测试与评审仍是人的责任边界。
- 渐进式 SDD 合理 ：全盘追溯历史代码不现实；改动触发纪律更易坚持。
五、本项目中值得借鉴的 Rules（摘录与导读）
以下为 导读 ，完整条文请以仓库 .cursor/rules/*.mdc 为准。
5.1 全局与 SDD（00-global.mdc、01-sdd-spec.mdc）
- 核心 ：Spec 先行、可验证、可追踪、结构性变更同步
CLAUDE.md。 - 四阶段 ：Specify → Plan → Tasks → Implement；存量 不动 ，触碰即纳入 Spec 流程。
- 落地：代码注释关联 Spec / AC；变更文档与 Spec 「变更历史」表格联动更新。
5.2 交互与问题求解（conversation-principles.mdc）
- 结构：默认区分「直接执行」与「深度交互」，兼顾效率与防漂移。
- 澄清：不预设用户已定义清目标；歧义影响正确性时先问清。
- 路径：优先最小充分解；指出更短更稳方案；大变更说明代价与风险。
- 审慎挑战：警惕 XY 问题与高影响任务的机械执行。
5.3 Git 与协作（07-git.mdc）
- Conventional Commits；说明与正文使用简体中文。
- 功能性提交
feat(FR-XXX): 描述等形式。 - 涉及
app时，git add前执行lint:eslint与lint:prettier。 - Implement 入口：未提交变更先提交并 push 作为安全快照；结构性变更配合
check-claude-sync一类检查。
5.4 安全与测试（04-security.mdc、03-testing.mdc）
- 安全：输入验证、白名单、禁拼接 SQL/命令；认证授权与敏感数据约束。
- 测试：前端 Vitest（
.test.js同目录）、后端 xUnit + Moq；新增/变更功能需有测试覆盖思路。
5.5 前端约定（06-frontend.mdc）
- Vue 3 + Composition API、Pinia、SpreadJS 等栈；组件与 API 目录约定；单文件组件体量等约束，利于 AI 生成一致风格代码。
5.6 架构与业务导引 Skill（项目_skill）
这不算传统「rules」，但对 AI 极有用：
- 一句话业务定位、前后端入口、Controller → Service → Repository 分层表。
- 前端
src/spread与绑定/监听目录索引；保存、提交、客户、PE 等 端到端锚点。 - 与
Lean_docs新手手册、SpreadJS 详解分工：Skill 索引 + 长文细节。
六、结语
若你也在 Cursor 里维护复杂业务系统，建议优先投入三件事：给 AI 一张架构与流程地图（Skill） 、用 Spec 绑定验收 、用 Rules 固定交互与提交纪律 。
本文可作为 CSDN 正文骨架；你可把第二节换成自己的真实需求编号、截图与前后对比，会更接地气。
附录：仓库内可顺带打开的文档
.cursor/rules/：规则全集.cursor/skills/项目/SKILL.md：项目架构与流程索引Lean_docs/：新手手册与 SpreadJS 机制长文（若本地已有）