2026-06-26 AI 辅助研发模式

这份文档用于记录我当前阶段的研发工作方式。它不是一套抽象方法论，而是我在真实业务研发过程中，对需求理解、方案设计、编码实现、质量验证和运维辅助等环节的实际做法总结。

1. 需求理解与方案前置

在当前研发流程里，我的上游协作主要来自产品与设计。

在正式编码前，我会先进入方案设计阶段。这个阶段的重点不在具体代码实现，而在于把边界先想清楚。

我通常会优先关注这些内容：

我比较认同的一点是：协议和 DB 这样的边界一旦确定，后续具体实现细节反而没那么重要；如果边界没有想清楚，后续再漂亮的实现也容易返工。

因此这个阶段我会和 AI 进行多轮会话，不断对不清晰的需求点进行澄清和对齐。如果 PRD 本身表述不明确，也会在这个阶段尽量暴露问题。对我来说，这一步不仅是生成技术方案，更是一个帮助自己真正熟悉需求的过程。

进入开发阶段后，我通常会拆分出多类不同用途的 SKILL。

设计稿并不等同于前端实现。

不同页面类型、不同尺寸、不同布局密度，实际落地方式都不一样。因此这部分我没有完全依赖现成模板，而是把它当成一个持续迭代的 SKILL。只要某类页面做过一次，后续就会逐步把这一类经验补进现有规则里。

前端代码开发、后端代码开发、存储层设计开发，这三类是我最常用的核心 SKILL。

这几类 SKILL 我会始终坚持几个原则：

换句话说，我不会把 AI 当作自由发挥的代码生成器，而是更像一个受约束的工程执行器。核心目标不是“写得多新”，而是“写得稳、写得像、写得能接进现有系统”。

除了直接做业务实现的 SKILL，我还会补充一些辅助类 SKILL，用于支持研发、质量和运维过程。

例如：

只要某项能力有明显自动化价值，我通常都会尝试把它规范化。因为这些能力一旦沉淀下来，不只是当下开发能用，后续质量验证、问题排查和运维操作也都能复用。

在质量阶段，我会刻意把“需求理解”和“实现验证”分开处理。

我会先基于 PRD 去生成 case list，而不会让 AI 参考我的技术方案或代码实现。

原因很直接：在 AI 时代，如果技术方案本身就带有错误理解或幻觉，那么再基于它继续生成测试内容，只会把错误闭环起来。反过来，让 case 直接回到 PRD，可以更独立地验证需求是否真的被满足。