AI 怎样参与完整研发流程，沉淀了哪些方案？

核心回答

AI 可以参与需求澄清、方案设计、任务拆分、代码实现、测试审查和问题排查。把它接进完整研发流程，关键是让前一阶段的结论成为后一阶段可用的输入，并让每次修改都有明确的验收方法，而不是只在编码时临时问几句话。

以“订单列表增加按状态筛选”为参考，可以先让 AI 结合现有页面和接口梳理状态含义、权限与兼容要求，再定位前后端调用链，按接口契约拆分修改；实现后运行针对性测试，审查实际 Diff，并检查筛选、分页和异常状态在页面上的表现。开发者负责业务取舍、关键边界和最终验收，AI 承担上下文整理、实现、测试补充及根据反馈修复等工作。

值得沉淀的是能够复用的成果：项目结构与测试入口、接口和领域约定、特定任务的 Skill、工具连接、验证脚本，以及典型失败案例。流程重量随任务风险调整；简单局部修改直接实现并做针对性验证，跨模块或重要状态变更再展开设计、分步执行和更广的回归。

需求到方案：先减少模型需要猜的内容

给 AI 的输入包括需求目标、已有行为、相关页面或接口、关键限制和验收条件。让它读现有实现、调用方和测试，再列出影响实现的歧义，例如：订单状态按展示状态还是数据库原值筛选，筛选后是否保留分页，用户能否查询其他租户的数据。

可以让 AI 帮忙归纳和提出候选方案，开发者结合业务确定取舍。确实需要确认的问题集中处理，已经明确的常规实现细节则继续推进。重要结论留下简短记录，避免聊天很长后，编码阶段重新猜一遍。

方案至少说明受影响模块、接口输入输出、数据变化和验证方式。对于参考例子，前后端先对齐状态取值、空条件和分页语义；如果只是沿用现有筛选模式，就不必另造一套复杂设计。

任务拆分与实现：让协作能衔接

把需求拆成可以独立验证的任务，例如后端支持筛选参数、前端提交并保留筛选条件、补充相关测试与说明。每个任务写清输入、产物、依赖和完成条件，避免只有“前端负责页面、后端负责接口”这样的笼统分工。

执行时，AI 先查找可复用的组件、接口封装和错误处理，再做范围明确的修改。反馈不只是“报错了”，而是具体测试失败、堆栈、接口响应或页面现象，便于它提出可验证的修复。

多个 Agent 并行适合职责独立、文件边界清楚的工作。共享接口先约定，存在先后依赖的任务按顺序交接；并发修改时要隔离工作区或明确文件所有权，最终仍需集成验证。Agent 越多，协调与上下文传递成本也越高，不应为简单任务增加角色。

工具按作用接入：代码搜索和终端处理仓库操作，浏览器工具检查页面，MCP 或 API 连接需求、设计和内部服务。工具连接解决访问和执行，Skill 提供特定任务的做法，Agent 根据目标组织行动。外部文档与工具返回作为资料使用，权限仍由应用和执行环境控制。

测试与审查：验证实际行为

测试可以与实现并行准备，也可以先根据已知缺陷写出失败用例。关键是预期结果来自需求、业务规则或独立样例，而不是把 AI 实现里的判断复制成断言。

参考例子中，除了正常筛选，还要检查空条件、多状态组合、无结果、分页衔接和越权范围。先运行受影响测试及必要的类型、构建检查；涉及公共接口或共享模块，再补相应集成回归。UI 变化要查看真实页面和交互，只有构建成功不足以确认使用体验。

审查从原需求回到实际 Diff：筛选条件是否进入最终查询，前后端取值是否一致，鉴权是否仍覆盖这条路径，原有调用方是否受影响，错误是否被悄悄吞掉。检查 AI 新增或修改的测试有没有削弱断言、漏掉反例。独立上下文的 AI 审查可以补充线索，仍需结合源码和运行证据判断。

交付时，AI 可以整理改动说明、验证结果和需要关注的行为变化。发布后，可辅助分析脱敏日志、失败记录和用户反馈，形成修复假设，再通过复现和验证闭环。生成发布说明、通过测试与实际部署是不同动作，按团队已有交付方式衔接即可。

沉淀什么，怎样避免越积越重

可以把一次有效协作整理成几类可维护的资产：

• 项目说明与规则： 仓库入口、目录职责、测试命令、编码与接口约定，以及容易误用的领域术语。保持简明，细节链接到对应文档。
• 任务型 Skill： 适用于某类接口开发、故障定位或代码审查的专业流程，附必要模板、脚本和参考资料，写清触发条件与完成标准。
• 工具与验证能力： 封装稳定的查询、构建、测试或浏览器检查入口，返回清楚的结果与错误，减少每次重新配置。
• 案例和回归用例： 保留典型的误解、失败原因与修复方法，把可自动验证的问题转成测试，观察后续是否再次发生。

更新资产时，看它是否减少了重复解释、漏项和返工。如果某条规则过时、重复或每次都引出不必要动作，就修订或移除。项目常驻约定不必塞进每个 Skill，低频专业资料也不必常驻上下文。

可以从一个团队高频任务试用，比较需求到可合并改动的时间、人工审查与修复量、回归问题和配置维护成本，再决定扩大到哪些场景。代码生成速度和工具使用次数只是过程信号，不能直接代替交付收益。

一个可调整的项目表达

我把 AI 协作分成需求理解、实现验证和经验沉淀三部分。需求阶段先让它结合代码确认影响范围，把业务歧义和验收条件整理出来；实现阶段按接口和模块依赖推进，结合测试与页面反馈修复；最后把稳定的项目约定、特定任务流程和典型问题沉淀下来。以订单筛选为例，重点是前后端状态口径、分页和权限边界能够贯通，而不只是生成一个筛选控件。日常小改走轻流程，跨模块任务再增加设计和集成检查。

实际回答时，可在这段结构中补充自己承担的实现、一次具体纠偏和已有交付记录，让“沉淀方案”对应到可以展示的规则、脚本或案例。

常见追问

用了 Spec，是否每一步都要人确认？

Spec 应减少重复解释。把业务取舍、执行边界和验收写清后，已明确的任务可以连续执行；遇到信息缺失、范围改变或恢复成本较高的具体动作，再处理相应决策。不需要把每个文件修改都变成一次确认。

为什么不把全部经验写进一个很长的 Prompt？

长期约定、当前任务和低频专业资料的使用频率不同。全部常驻会占用上下文，也使维护困难；按用途拆分后，当前任务读取所需内容，同时通过测试和工具结果验证执行。

流程完整是否意味着 AI 可以直接负责上线？

完整参与表示前后信息和验证能衔接，具体操作权限仍按团队职责与任务授权配置。开发、测试、审查和发布各有对应产物，是否自动执行发布取决于业务要求和现有交付机制。

对应教程

参考资料