【AI 辅助开发一周实践感悟：从「能用」到「好用」的关键是什么？】

AI 辅助开发一周实践感悟从「能用」到「好用」的关键是什么我深度使用 Cursor AI Agent 完成了两个截然不同的项目一个是某委托单系统的常规功能迭代另一个是某 ELN 系统提交超时的性能排查与优化。一个偏「写」一个偏「查」。两个项目跑下来对 AI 辅助开发这件事有了更立体的感受——它不是银弹但用对了方法确实是一把好刀。一、两个项目两种 AI 协作范式项目 A委托单系统 — 功能迭代型这是本周的主战场。两周内交付了打印预览、Excel 导入、对接第三方平台的开案双按钮等 6 个功能涉及前后端、导入管线、审批签章等多个模块。AI 承担了大量 coding 工作从 Spec 到 Plan 到 Implement 一气呵成。核心协作模式Ask澄清需求→ Plan制定方案→ Agent执行实现→ 人工验收。项目 BELN 提交超时 — 问题排查型用户反馈提交卡 100 秒后报超时。这是一个典型的性能排查场景AI 的定位不是「写代码」而是「带着你一起查问题」。从埋点到假设验证到根因定位整个过程像一场侦探游戏。核心协作模式假设驱动 → 日志验证 → 方案设计 → 代码实现 → 效果对比。两种范式差别很大但有一些共同的「做对了」和「没做好」的地方值得记录。二、做得好的这四个实践很有价值2.1 SDD规格驱动开发让 AI 不跑偏这是两周下来最受益的一个实践。简单说就是功能还不确定的时候先在 Ask 模式里把需求聊透落地成表格或 Spec再让 AI 动手写代码。以「开案双按钮」为例用户在 Ask 阶段和我对齐了这些边界维度发送开案信息查询开案记录触发打开表单打开列表业务校验需要不需要提交后行为关窗关窗权限同一权限控制函数同这张表格定了之后AI 后面 Plan、Implement 几乎零返工。把模糊的口语需求变成结构化的约束表是 AI 协作效率的分水岭。对比之下如果一上来就扔一句「帮我加个查询按钮」AI 大概率会写出一个表面功能对但边界全错的东西然后陷入反复修 bug 的泥潭。2.2 规则体系用 .cursorrules 约束 AI 行为两周下来.cursor/rules/目录成了我对 AI 的「家规」。几个规则发挥了实际作用07-git.mdc明确要求 AI 完成 Implement 后不自动提交。之前 AI 会在交付末尾顺手贴一个git commit命令块用户一度以为要被自动提交。现在改成了「只说明改动范围用户说提交再提交」交付清晰多了。00-global.mdc/01-sdd-spec.mdc要求先写 CHG 变更文档再改代码代码中标注spec/change。这让代码回溯成本大幅降低——翻 commit 看到change: CHG-2026-0529就能直接定位到完整的变更需求。05-api.mdc在 ELN 项目中触发——AI 为了提速提出了一个 Delete 方案被用户标记后写入规则「禁止 Agent 自动写删除类操作」。这个规则的价值不是「防止 AI 犯错」而是「把一次教训沉淀成永久约束」。感悟规则不是一次写完就完事的它应该在每次「AI 做了不该做的事」之后更新。这有点像训练小狗——每次犯错后的纠正比一开始给一本厚厚的规则手册更有效。2.3 假设驱动的性能排查AI 是很好的「推理搭档」ELN 超时排查是一次教科书级的 AI 人协作。核心方法是埋点先不猜原因在前后端关键路径打上分阶段计时日志列假设AI 提出 5 个假设前端序列化慢上传慢数据存储慢业务写入慢逐个用日志数据验证定位根因最终锁定Storageable在 Oracle 上逐行 MERGE 343 条数据耗时 129 秒设计方案AI 提出批量 upsert 方案本人审核后采纳否决了 Delete 方案。最终从131 秒 → 2.2 秒性能提升约60 倍。这件事情让我意识到AI 在排查场景下的核心价值不是「猜得准」而是「穷举得快」——人类排查问题容易思维定势AI 能系统地列出所有可能瓶颈然后逐条用数据说话。人的价值在于知道什么假设合理、什么操作不能做比如 Delete、什么方案适合上线。2.4 知识图谱方向对落地还欠火候项目中维护了一个 Graphify 代码知识图谱约 2800 节点、3800 边覆盖 AST 级别的代码关系。用了两周最大的感受是建图容易用图难。好的一面Plan 阶段打开graph-business.html能看到模块间的依赖关系确实比纯 Grep 更直观。比如看工具栏组件到状态管理模块的调用链一眼就知道改工具栏组件会波及哪些 Store 方法。不好的一面实际开发中 AI 更习惯用 Grep Read 定位代码知识图谱更像是「备选工具」而非「首选入口」。这周有一次 AI 在澄清需求时直接 Grep 搜索压根没想起来先graphify query一把被用户指出来后才补上。改进方向把graphify query设为 Plan 阶段的强制入口写入规则——不是「建议使用」而是「不先用图谱就别写 Plan」。三、做得不好的四个真实的痛点3.1 AI 不能「看图」截图交互是个盲区用户习惯贴截图说明需求比如「把两个按钮放这里」但 AI 拿到的其实是系统生成的image_description文本不是原图。大多数情况下够用但碰到像素级需求按钮是否 disabled、文案是否正确、间距是否对齐AI 就容易判断错。目前的经验截图配文字描述效果好于纯截图像素级 UI 以用户口头确认为准不要让 AI「看图说话」。3.2 Spec 文档滞后于代码本周打印预览和开案双按钮的代码都写完了但部分 Spec / Change 文档还在工作区没提交。不是 AI 没写——AI 是写了文档的——而是因为代码改了好几轮文档也有好几版最后哪版对应最终代码需要人工确认后才能一起提交。改进方向功能验收时把「文档是否同步」作为验收项之一代码和文档同批次提交避免「代码上了、Spec 滞后」。3.3 AI 的「过度自信」需要规则兜底HTD 项目中AI 为了加速 upsert第一版方案是「先全量 Delete 再 BulkInsert」。从纯技术角度看确实最快但业务上——不允许擅自删数据库记录哪怕之后会插回去也不行。这个教训说明AI 的优化本能缺少业务风险意识。它不知道「Delete 操作在金融/检测系统中意味着什么」只能通过规则来约束。好在当时用户立刻叫停写入了05-api.mdc规则从此 AI 在这个项目里再也没提过 Delete。启示每次 AI「越界」都是一次完善规则的机会。规则体系不追求完美追求迭代。3.4 渐进式补充需求的隐形成本用户习惯分轮补需求「先这样」「哦对了查询不用 LIMS」「编辑也要关窗」这种方式降低了一次性描述的压力但增加了 AI 的返工风险——如果在 Plan 之后才补关键边界前面的工作可能白做。现状本周把「定稿」节点明确放在 Plan 之前。Ask 阶段可以分轮补但一旦进入 Plan 写方案需求必须锁定。这个约束目前靠人的自觉执行还没写进规则——也许应该。四、与 AI 协作的几个「反直觉」感悟4.1 慢就是快最反直觉的一点花 15 分钟对齐需求表比省下这 15 分钟直接让 AI 写代码要快得多。开案双按钮的需求对齐用了约 20 分钟Ask 阶段但 Plan Implement 只花了约 40 分钟且零返工。反观之前一些「一句话需求」直接 Agent 实现往往要来回修 3-4 轮。4.2 AI 在「查问题」上可能比「写代码」更好用排查 ELN 超时的时候AI 列了 5 个假设、分析了上百行日志、交叉验证了前后端时序——这些工作量如果纯人工做可能要半天。但 AI 几分钟就出结论了。我的感受是AI 写 CRUD 代码的提效大概是 2-3 倍但 AI 辅助排查复杂 Bug 的提效可能是 5-10 倍。因为写代码考验的是「准确性」AI 有时会跑偏排查考验的是「广度」和「系统性」这正是 AI 的强项。4.3 规则的价值不在「约束 AI」在「省去每次重复沟通」07-git.mdc最典型的场景没有规则前每次 AI 交付完用户都得补一句「别提交啊」有了规则后AI 自己就知道不提交。规则本质上是一种「持久化的上下文」一次说清楚以后不用再说。4.4 AI 搭档 一个执行力超强、但缺乏常识的初级工程师这是我两周下来对 AI 最准确的定位。它能快速理解代码结构、写出高质量的 CRUD 和测试系统性地穷举排查假设严格遵循已成文的规则但它不能理解业务风险比如为什么不能 Delete看图识别 UI 细节主动判断「这个需求是否需要先对齐再动手」所以一个好的 AI 协作流程就是人做好 AI 不擅长的事判断、决策、风险把控把 AI 擅长的事编码、搜索、穷举交给它。五、后续改进计划根据两周的实践接下来准备做这几件事强化 Plan 入口检查在规则中约束新需求的 Plan 阶段必须先graphify query避免有效武器束之高阁。增加「需求定稿」规则Ask 阶段可以迭代但 Plan 开始前需求必须锁定写入规则作为硬约束。文档与代码同批次提交功能验收单中加入「Spec / CHG 文档同步检查」项。持续迭代规则体系每次 AI 越界或犯错当天更新对应规则文件把教训变成永久约束。尝试更多排查型场景ELN 的排查体验很好后续碰到类似性能/异常问题优先用假设驱动 AI 协作的模式推进。写在最后两周前我还在摸索「怎么让 AI 不捣乱」两周后已经在思考「怎么让 AI 配合得更好」。这个转变不是因为 AI 变聪明了而是因为配合方式变聪明了——有了 SDD 流程、有了规则体系、有了 Plan 前的需求对齐、有了排查场景的假设驱动方法。AI 不是替代开发者的超人而是放大开发者能力的杠杆。你用得好它帮你省 80% 的编码时间你用不好它帮你多浪费 80% 的 debug 时间。与所有在 AI 辅助开发路上探索的朋友共勉。记录于 2026 年 5 月 29 日基于某委托单系统和某 ELN 系统两周 AI 协作实践。